Date: Thu, 06 Jun 2002 21:25:06 +0900 From: "K.Sumitani" <ksumitani@mui.biglobe.ne.jp> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: ia64@FreeBSD.ORG Subject: Re: ia64 kernel does not boot SKI ? Message-ID: <20020606212522.VANVC0A8274D.C79F0C8A@mail.biglobe.ne.jp> In-Reply-To: Your message of "Wed, 05 Jun 2002 14:28:56 MST." <20020605212856.GA47618@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multipart MIME message.
--==_Exmh_4067911810
Content-Type: text/plain; charset=us-ascii
Hi,
I'm sorry that I did not write full info. The panic happens
if filesystem exists. I tracked down the problem as below.
If filesystem exists, clock(RTC or TOD) is read in mountroot-
path as:
vfs_mountroot() -> inittodr -> ski_fake_efi_get_time()
ski_fake_efi_get_time() calles ssc() and it executes break
instruction to get RTC from ski. When execute break, some
address range on ski's data window become 'xxxx' and after
then, the value of such address is read as ZERO. This ZERO
cause unaligned access in binuptime() later.
I looked into Linux kernel source and found that Linux does
not use SSC_GET_RTC. It use SSC_GET_TOD instead.
So, I modified ski_fake_efi_get_time() to use SSC_GET_TOD
as Linux and get another panic at start_init.
Below is console message and stack-trace.
----
Mounting root from ufs:/dev/sscdisk0c
sscdisk0s1: type 0xa5, start 32, end = 409599, size 409568 : OK
start_init: trying /sbin/init
recursed on non-recursive lock (sleep mutex) process lock @ /work4/current/sys/ia64/ia64/trap.c:574
first acquired @ /work4/current/sys/kern/kern_exec.c:316
panic: recurse
panic
Stopped at Debugger+0x31: nop.m 0x0
db> t
Debugger(0xe000000000788610, 0xe0000000008524a0) at Debugger+0x31
panic(0xe00000000078bf38, 0xe000000000785288, 0x13c, 0xe0000000007a0f58) at panic+0x160
witness_lock(0xa000000002c7e358, 0x8, 0xe0000000007a0f58, 0x23e, 0xe00000000088fc48, 0xe000000000a30000) at witness_lock+0x980
_mtx_lock_flags(0xa000000002c7e358, 0x0, 0xe0000000007a0f58, 0x23e) at _mtx_lock_flags+0xe0
trap(0x14, 0x0, 0xe000000000259110, 0xe0000000007917b8, 0xa000000002c7e358, 0xe000000000a30000, 0xa000000002c7e1a0, 0x0) at trap+0xc20
interruption_Data_TLB(0x14, 0x0, 0xe000000000259110) at interruption_Data_TLB+0x1f0
suword(0x9fffffffe0000000, 0x9ffffffffffffc88) at suword+0x60
setregs(0xa000000002c7e1a0, 0x40000000000001e0) at setregs+0xe0
execve(0xa000000002c7e1a0, 0xa0000000016cfb40, 0xa000000002c7e4e8, 0x0) at execve+0x13f0
start_init(0x9fffffffffffffd8, 0x9ffffffffffffff2, 0xe000000000a30000, 0xe0000000007e5442, 0xe0000000007e5438, 0x9ffffffffffffffd, 0xa000000002c7e1a0, 0xe000000000837c38) at start_init+0x9b0
fork_exit(0xe0000000007a4628, 0x0, 0xe000000000259680, 0xe000000000a30000, 0xa000000002c7e000, 0xe0000000007472d0, 0x3, 0x9fffffffffffffd8) at fork_exit+0x1f0
fork_trampoline(0xe0000000007a4628, 0x0, 0xe000000000259680) at fork_trampoline+0x30
----
Attached is ad hoc patch for ski.c.
BTW, ia64 cross(?) buildworld is broken after May 31.
contrib/libstdc++/config/cpu/ia64/bits/atomicity.h includes
ia64intrin.h but it is not on include path.
This problem is only on ia64.
# It might be already fixed. I'll try on weekend...
> > > > ia64 kernel does not boot on SKI any more ?
> > >
> > > I must say I haven't tried lately, so it's possible that we broke
> > > something. I have to check. Are you using the default SKI kernel
> > > config?
> >
> > Yes, I used fresh checked-out source.
> > The last check-out was May 31 morning in Japan.
>
> Sorry for getting back to you so late, but I tried it myself and I
> get as far as the mountroot prompt. I don't have a filesystem I
> can use right now, so before I try that, can you tell me if you
> can mount the root filesystem or if the panic happens earlier?
--==_Exmh_4067911810
Content-Type: application/x-patch ; name="ski.c.patch"
Content-Description: ski.c.patch
Content-Disposition: attachment; filename="ski.c.patch"
Index: ski.c
===================================================================
RCS file: /home/ncvs/src/sys/ia64/ia64/ski.c,v
retrieving revision 1.3
diff -c -r1.3 ski.c
*** ski.c 19 May 2002 05:40:22 -0000 1.3
--- ski.c 5 Jun 2002 14:53:53 -0000
***************
*** 90,108 ****
(EFI_RESET_SYSTEM) ski_fake_efi_proc
};
static EFI_STATUS
ski_fake_efi_get_time(EFI_TIME *time, EFI_TIME_CAPABILITIES *caps)
{
! struct ssc_time ssctime;
! ssc(ia64_tpa((vm_offset_t) &ssctime), 0, 0, 0, SSC_GET_RTC);
! time->Second = ssctime.second;
! time->Minute = ssctime.minute;
! time->Hour = ssctime.hour;
! time->Day = ssctime.day;
! time->Month = ssctime.month + 1;
! time->Year = ssctime.year + 1900;
return EFI_SUCCESS;
}
--- 90,152 ----
(EFI_RESET_SYSTEM) ski_fake_efi_proc
};
+ #define SSC_GET_TOD 74
+
+ #define SECDAY (24 * 60 * 60)
+ #define SECYR (SECDAY * 365)
+ #define POSIX_BASE_YEAR 1970
+
+ #define FEBRUARY 2
+ #define days_in_year(y) (leapyear(y) ? 366 : 365)
+ #define days_in_month(y, m) \
+ (month_days[(m) - 1] + (m == FEBRUARY ? leapyear(y) : 0))
+ #define day_of_week(days) (((days) + 4) % 7)
+
+ #define leapyear(y) ((y & 3) == 0)
+
+ static const int month_days[12] = {
+ 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31
+ };
+
static EFI_STATUS
ski_fake_efi_get_time(EFI_TIME *time, EFI_TIME_CAPABILITIES *caps)
{
! int i, year, days;
! int rsec;
! int secs;
!
! struct {
! uint32_t tv_sec;
! uint32_t tv_usec;
! } tv32;
!
! ssc(ia64_tpa((vm_offset_t) &tv32), 0, 0, 0, SSC_GET_TOD);
!
! secs = (int)(tv32.tv_sec);
! days = secs / SECDAY;
! rsec = secs % SECDAY;
!
! /* Subtract out whole years, counting them in i. */
! for (year = POSIX_BASE_YEAR; days >= days_in_year(year); year++)
! days -= days_in_year(year);
!
! time->Year = year;
!
! /* Subtract out whole months, counting them in i. */
! for (i = 1; days >= days_in_month(year, i); i++)
! days -= days_in_month(year, i);
!
! time->Month = i;
! /* Days are what is left over (+1) from all that. */
! time->Day = days + 1;
! /* Hours, minutes, seconds are easy */
! time->Hour = rsec / 3600;
! rsec = rsec % 3600;
! time->Minute = rsec / 60;
! rsec = rsec % 60;
! time->Second = rsec;
return EFI_SUCCESS;
}
--==_Exmh_4067911810--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ia64" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020606212522.VANVC0A8274D.C79F0C8A>