Re: new breakage in mounting root? a devfs issue?
On 13-Mar-01 Matthew Jacob wrote: >> Can you possibly try to narrow the differences down by tring out various >> kernel >> configs in between GPLUS and GENERIC? > > Actually- look at the diffs at least and tell me which you think it might > be. All of the diffs are either kernel support flavors for alpha, which > shouldn't matter to devfs for a damn, or drivers. > > If nobody can get to this, I'll try and look at this further, but this is > looking very very strange. It could be some driver screwing up with makedev() though one would think we'd have hit that before now. It could be something really odd relating to the size of the kernel. It could be the maxuers change resulting in kernel memory being laid out differently. *shrug* I didn't see anything in that diff that would have broken this either. Does it happen w/o devfs? I'm updating my alpha to today's current, so perhaps I'll run into this here. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new breakage in mounting root? a devfs issue?
> Can you possibly try to narrow the differences down by tring out various kernel > configs in between GPLUS and GENERIC? Actually- look at the diffs at least and tell me which you think it might be. All of the diffs are either kernel support flavors for alpha, which shouldn't matter to devfs for a damn, or drivers. If nobody can get to this, I'll try and look at this further, but this is looking very very strange. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new breakage in mounting root? a devfs issue?
On 13-Mar-01 Matthew Jacob wrote: > > To refresh memory: > >> fatal kernel trap: >> >> trap entry = 0x4 (unaligned access fault) >> a0 = 0xc3615fe1a88f382 >> a1 = 0x29 >> a2 = 0x1b >> pc = 0xfc467578 >> ra = 0xfc4627c4 >> curproc= 0xfe0009f5dbe0 >> pid = 1, comm = init >> >> Stopped at vfs_object_create+0x38: jsr >> ra,(pv),vfs_object_create+0x3c >> >> db> t >> vfs_object_create() at vfs_object_create+0x38 >> getnewvnode() at getnewvnode+0x564 >> devfs_allocv() at devfs_allocv+0xe0 >> devfs_root() at devfs_root+0x38 >> devfs_mount() at devfs_mount+0xf0 >> vfs_mount() at vfs_mount+0x910 >> mount() at mount+0xd8 >> syscall() at syscall+0x3f4 >> XentSys1() at XentSys1+0x10 > > > Interestingly enough, as Christian had also reported, a build of a GENERIC > kernel seems to solve this problem. > > This is almost more alarming than a potential bug in vfs_object_create- as > the > difference between the config file I was using should not cause this. > > *I* sure can't spot what config option might be different. I also had done a > complete removal of the build directory and complete fresh build of GPLUS. > (sounds of hair tearing). Can you possibly try to narrow the differences down by tring out various kernel configs in between GPLUS and GENERIC? -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new breakage in mounting root? a devfs issue?
> > Matthew Jacob writes: > > > *I* sure can't spot what config option might be different. I also had done a > > complete removal of the build directory and complete fresh build of GPLUS. > > (sounds of hair tearing). > > > > Can anyone suggest what below might have caused this breakage? > > One WAG is that the loader's module-loading is hosed. WAG? > I got a somewhat similar panic on alpha when loading random from the > loader prompt. > > Are you loading anything from the loader that might already be built into > a GENERIC kernel? The only thing I'm loading is ispfw (it's not part of either GENERIC or GPLUS as a static module). The ethernet interface is de, so that's static also. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new breakage in mounting root? a devfs issue?
Matthew Jacob writes: > *I* sure can't spot what config option might be different. I also had done a > complete removal of the build directory and complete fresh build of GPLUS. > (sounds of hair tearing). > > Can anyone suggest what below might have caused this breakage? One WAG is that the loader's module-loading is hosed. I got a somewhat similar panic on alpha when loading random from the loader prompt. Are you loading anything from the loader that might already be built into a GENERIC kernel? Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new breakage in mounting root? a devfs issue?
To refresh memory: > fatal kernel trap: > > trap entry = 0x4 (unaligned access fault) > a0 = 0xc3615fe1a88f382 > a1 = 0x29 > a2 = 0x1b > pc = 0xfc467578 > ra = 0xfc4627c4 > curproc= 0xfe0009f5dbe0 > pid = 1, comm = init > > Stopped at vfs_object_create+0x38: jsr ra,(pv),vfs_object_create+0x3c > > db> t > vfs_object_create() at vfs_object_create+0x38 > getnewvnode() at getnewvnode+0x564 > devfs_allocv() at devfs_allocv+0xe0 > devfs_root() at devfs_root+0x38 > devfs_mount() at devfs_mount+0xf0 > vfs_mount() at vfs_mount+0x910 > mount() at mount+0xd8 > syscall() at syscall+0x3f4 > XentSys1() at XentSys1+0x10 Interestingly enough, as Christian had also reported, a build of a GENERIC kernel seems to solve this problem. This is almost more alarming than a potential bug in vfs_object_create- as the difference between the config file I was using should not cause this. *I* sure can't spot what config option might be different. I also had done a complete removal of the build directory and complete fresh build of GPLUS. (sounds of hair tearing). Can anyone suggest what below might have caused this breakage? --- GENERIC Mon Feb 5 11:46:37 2001 +++ GPLUS Mon Mar 12 14:59:09 2001 @@ -19,56 +19,57 @@ # # For hardware specific information check HARDWARE.TXT # -# $FreeBSD: src/sys/alpha/conf/GENERIC,v 1.107 2001/02/04 15:35:08 peter Exp $ +# $FreeBSD: src/sys/alpha/conf/GENERIC,v 1.102 2000/11/07 22:09:33 obrien Exp $ machinealpha cpuEV4 cpuEV5 ident GENERIC -maxusers 32 +maxusers 128 #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" -#makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols +makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols # Platforms supported -optionsAPI_UP1000 # UP1000, UP1100 (Nautilus) +#options API_UP1000 # UP1000 (Nautilus) optionsDEC_AXPPCI_33 # UDB, Multia, AXPpci33, Noname optionsDEC_EB164 # EB164, PC164, PC164LX, PC164SX -optionsDEC_EB64PLUS# EB64+, Aspen Alpine, etc -optionsDEC_2100_A50# AlphaStation 200, 250, 255, 400 -optionsDEC_2100_A500 # AlphaServer 2000, 2100, 2100A -optionsDEC_KN20AA # AlphaStation 500, 600 -optionsDEC_ST550 # Personal Workstation 433, 500, 600 +#options DEC_EB64PLUS# EB64+, Aspen Alpine, etc +#options DEC_2100_A50# AlphaStation 200, 250, 255, 400 +#options DEC_2100_A500 # AlphaServer 2000, 2100, 2100A +#options DEC_KN20AA # AlphaStation 500, 600 +#options DEC_ST550 # Personal Workstation 433, 500, 600 optionsDEC_ST6600 # xp1000, dp264, ds20, ds10, family -optionsDEC_3000_300# DEC3000/300* Pelic* family -optionsDEC_3000_500# DEC3000/[4-9]00 Flamingo/Sandpiper family -optionsDEC_1000A # AlphaServer 1000, 1000A, 800 -optionsDEC_KN8AE # AlphaServer 8200/8400 (Turbolaser) +#options DEC_3000_300# DEC3000/300* Pelic* family +#options DEC_3000_500# DEC3000/[4-9]00 Flamingo/Sandpiper family +#options DEC_1000A # AlphaServer 1000, 1000A, 800 +#options DEC_KN8AE # AlphaServer 8200/8400 (Turbolaser) optionsDEC_KN300 # AlphaServer 4100 (Rawhide), 1200 (Tincup) optionsINET#InterNETworking -optionsINET6 #IPv6 communications protocols +#options INET6 #IPv6 communications protocols optionsFFS #Berkeley Fast Filesystem optionsSOFTUPDATES #Enable FFS soft updates support optionsMFS #Memory Filesystem optionsMD_ROOT #MD is a potential root device optionsNFS #Network Filesystem -optionsNFS_ROOT#NFS usable as root device -optionsMSDOSFS #MSDOS Filesystem +#options NFS_ROOT#NFS usable as root device +#options MSDOSFS #MSDOS Filesystem optionsCD9660 #ISO 9660 Filesystem optionsDEVFS #Device Filesystem optionsPROCFS #Process filesystem optionsCOMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] -optionsSCSI_DELAY=15000#Delay (in ms) before probing SCSI +#options SCSI_DELAY=15000#Delay (in ms) before probing SCSI +optionsSCSI_DELAY=0#Delay (in ms) before probing
Re: new breakage in mounting root? a devfs issue?
Andrea Campi <[EMAIL PROTECTED]> wrote: > Seriously, if it's a new breakage, it's not breaking for everybody. As I already reported to -alpha, it's breaking for me (sources as of ~March 10) with a custom kernel. Doesn't happen with GENERIC. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new breakage in mounting root? a devfs issue?
On Tue, 13 Mar 2001, Andrea Campi wrote: > Just today I started using DEVFS again after a long time, and it works > perfectly. From the scarce info you provide, our only apparent difference > is I don't have SCSI. > > If it weren't you, I'd ask if you are sure you have the very latest > sources, but of course I wonder you have more than enough clue to already > have checked that ;-) > > Seriously, if it's a new breakage, it's not breaking for everybody. Huh... Yeah.. it's top of tree... and it's the first devfs breakage I've had in quite a while. It may not even be that... well, we got some garbage pointer in vfs_object_create... this alpha funnies maybeguess I'll try and track it down... > > > On Mon, Mar 12, 2001 at 04:30:52PM -0800, Matthew Jacob wrote: > > > > complete fresh build, etc > > > > da0: invalid primary partition table: no magic > > start_init: trying /sbin/init > > > > fatal kernel trap: > > > > trap entry = 0x4 (unaligned access fault) > > a0 = 0xc3615fe1a88f382 > > a1 = 0x29 > > a2 = 0x1b > > pc = 0xfc467578 > > ra = 0xfc4627c4 > > curproc= 0xfe0009f5dbe0 > > pid = 1, comm = init > > > > Stopped at vfs_object_create+0x38: jsr ra,(pv),vfs_object_create+0x3c > > > > db> t > > vfs_object_create() at vfs_object_create+0x38 > > getnewvnode() at getnewvnode+0x564 > > devfs_allocv() at devfs_allocv+0xe0 > > devfs_root() at devfs_root+0x38 > > devfs_mount() at devfs_mount+0xf0 > > vfs_mount() at vfs_mount+0x910 > > mount() at mount+0xd8 > > syscall() at syscall+0x3f4 > > XentSys1() at XentSys1+0x10 > > > > > > > > > > Ummm... > > > > vfs_object_create(vp, p, p->p_ucred); > > > > > > is there actually a ucred this early in startup? > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new breakage in mounting root? a devfs issue?
Just today I started using DEVFS again after a long time, and it works perfectly. From the scarce info you provide, our only apparent difference is I don't have SCSI. If it weren't you, I'd ask if you are sure you have the very latest sources, but of course I wonder you have more than enough clue to already have checked that ;-) Seriously, if it's a new breakage, it's not breaking for everybody. On Mon, Mar 12, 2001 at 04:30:52PM -0800, Matthew Jacob wrote: > > complete fresh build, etc > > da0: invalid primary partition table: no magic > start_init: trying /sbin/init > > fatal kernel trap: > > trap entry = 0x4 (unaligned access fault) > a0 = 0xc3615fe1a88f382 > a1 = 0x29 > a2 = 0x1b > pc = 0xfc467578 > ra = 0xfc4627c4 > curproc= 0xfe0009f5dbe0 > pid = 1, comm = init > > Stopped at vfs_object_create+0x38: jsr ra,(pv),vfs_object_create+0x3c > > db> t > vfs_object_create() at vfs_object_create+0x38 > getnewvnode() at getnewvnode+0x564 > devfs_allocv() at devfs_allocv+0xe0 > devfs_root() at devfs_root+0x38 > devfs_mount() at devfs_mount+0xf0 > vfs_mount() at vfs_mount+0x910 > mount() at mount+0xd8 > syscall() at syscall+0x3f4 > XentSys1() at XentSys1+0x10 > > > > > Ummm... > > vfs_object_create(vp, p, p->p_ucred); > > > is there actually a ucred this early in startup? > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new breakage in mounting root? a devfs issue?
complete fresh build, etc da0: invalid primary partition table: no magic start_init: trying /sbin/init fatal kernel trap: trap entry = 0x4 (unaligned access fault) a0 = 0xc3615fe1a88f382 a1 = 0x29 a2 = 0x1b pc = 0xfc467578 ra = 0xfc4627c4 curproc= 0xfe0009f5dbe0 pid = 1, comm = init Stopped at vfs_object_create+0x38: jsr ra,(pv),vfs_object_create+0x3c db> t vfs_object_create() at vfs_object_create+0x38 getnewvnode() at getnewvnode+0x564 devfs_allocv() at devfs_allocv+0xe0 devfs_root() at devfs_root+0x38 devfs_mount() at devfs_mount+0xf0 vfs_mount() at vfs_mount+0x910 mount() at mount+0xd8 syscall() at syscall+0x3f4 XentSys1() at XentSys1+0x10 Ummm... vfs_object_create(vp, p, p->p_ucred); is there actually a ucred this early in startup? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
