Re: panic on boot (devfs_find)
In message [EMAIL PROTECTED], Bryan Liesner writes: Revision 1.20 / (download) - annotate - [select for diffs], Mon Mar 10 23:41:41 2003 UTC (5 days, 5 hours ago) by phk Branch: MAIN CVS Tags: HEAD Changes since 1.19: +5 -0 lines Diff to previous 1.19 (colored) If we run out of consumers while orphaning them, and the provider's geom is withering, destroy the provider when done. This was exposed by the recent change to geom_dev's orphaning logic If I reverted it back to a previous version (1.19) then the machine booted OK. BTW, I also found that adding INVARIANTS options into the kernel can prevent this problem as well. Regards, I have reverted back to rev 1.19 and all seems to be running OK. I have /dev/null, /dev/stderr, /dev/apm, and /dev/mixer back. When the faulty kernel _did_ boot (after about a million retries to coax a core dump), these devices were missing at boot, or would disappear shortly after. Thanks. I think Poul-Henning will have enough information to go with now... You guys _way_ overestimate my abilities here. Right now I have a hard time imagining what geom's eventhandling for withering geoms can possibly have to do with any non-geom device node being present in /dev or not, and even more so how INVARIANTS could affect that. The only influence I can imagine is one of timing... I don't think I'll stand a chance on this one until I can reproduce it on one of my machines :-( One thing I'd like you to try is to remove any trace of USB from your systems. USB does some ugly VOP_REVOKES which I am not happy about, and I would like to exclude them from the list of suspects. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On Sun, 16 Mar 2003, Poul-Henning Kamp wrote: I think Poul-Henning will have enough information to go with now... You guys _way_ overestimate my abilities here. Right now I have a hard time imagining what geom's eventhandling for withering geoms can possibly have to do with any non-geom device node being present in /dev or not, and even more so how INVARIANTS could affect that. The only influence I can imagine is one of timing... I don't think I'll stand a chance on this one until I can reproduce it on one of my machines :-( One thing I'd like you to try is to remove any trace of USB from your systems. USB does some ugly VOP_REVOKES which I am not happy about, and I would like to exclude them from the list of suspects. I'll try removing USB and report the results back to you. It's 3:30am here and I'm going to try to get some sleep. I'll do it sometime later today. Thanks. -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On Sun, 16 Mar 2003, Poul-Henning Kamp wrote: One thing I'd like you to try is to remove any trace of USB from your systems. USB does some ugly VOP_REVOKES which I am not happy about, and I would like to exclude them from the list of suspects. You can remove USB from your list, I tried building without USB in the kernel, and the panic remains... If you need any more info from me, don't hesitate to ask. Thanks. -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
Bryan Liesner wrote: On Sun, 16 Mar 2003, Poul-Henning Kamp wrote: One thing I'd like you to try is to remove any trace of USB from your systems. USB does some ugly VOP_REVOKES which I am not happy about, and I would like to exclude them from the list of suspects. You can remove USB from your list, I tried building without USB in the kernel, and the panic remains... Which of these flags have you been using?: #cpuI486_CPU #cpuI586_CPU cpu I686_CPU I normally use only the 686 flag, but when I included the 586 my panic-on-boot changed to a panic-on-starting-X. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
walt wrote: Bryan Liesner wrote: On Sun, 16 Mar 2003, Poul-Henning Kamp wrote: One thing I'd like you to try is to remove any trace of USB from your systems. USB does some ugly VOP_REVOKES which I am not happy about, and I would like to exclude them from the list of suspects. You can remove USB from your list, I tried building without USB in the kernel, and the panic remains... Which of these flags have you been using?: #cpuI486_CPU #cpuI586_CPU cpu I686_CPU I normally use only the 686 flag, but when I included the 586 my panic-on-boot changed to a panic-on-starting-X. I'm using I686. I also reverted from -march=athlon-xp for building to the default with the same results. -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On Sun, Mar 16, 2003 at 09:29:15AM +0100, Poul-Henning Kamp wrote: I don't think I'll stand a chance on this one until I can reproduce it on one of my machines :-( I'm not sure if that helps, but on my machine it it enough to take GENERIC kernconf file, add all GEOM_ options and comment out INVARIANTS and WITNESSES. I don't thing this it the least amount of changes, but it reliably causes trap 12: Mounting root from ufs:/dev/ad1s1a Fatal trap 12: page fault while in kernel mode fault virtual address = 0x7 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02b0ae3 stack pointer = 0x10:0xd5279934 frame pointer = 0x10:0xd527994c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32, gran 1 processor eflags= interrupt enabled, resumr, IOPL = 0 current process = 45 (init) kernel: type 12 trap, code=0 Stopped at devfs_find+0x23:movzbl 0x7(%eax),%eax db trace devfs_find(c3b15300,c058d4a0,2,c38cd3c0,2) at devfs_find+0x23 devfs_populate(c3bac200,0,c38cd3c0,0,0) at devfs_populate+0x1ea devfs_lookupx(d5279b08,1,0,c38cd3c0,6) at defvs_lookupx+0x22e devfs_lookup(d5279b08,c38cd3c0,0,c38cd3c0,c38cd3c0) at defvs_lookup+0x4b lookup(d5279c08,c3c5f400,400,d5279c24,c38cd3c0) at lookup+0x302 namei(d5279c08,0,0,0,0) at namei+0x20b revoke(c38cd3c0,d5279d10,4,c38cd3c0,1) at revoke+0x52 syscall(2f,2f,2f,bfbffdf8,0) at syscall+0x2aa Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (56, FreeBSD ELF32, revoke), eip = 0x8052c23, esp = 0xbfbffc6c, ebp = 0xbfbffc88 --- This was all copied from the screen by hand, but I hope there are no mistakes. I was unable to generate a crash dump, despite many attempts... :( Krzysztof To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
In message [EMAIL PROTECTED], Krzysztof Parz yszek writes: On Sun, Mar 16, 2003 at 09:29:15AM +0100, Poul-Henning Kamp wrote: I don't think I'll stand a chance on this one until I can reproduce it on one of my machines :-( I'm not sure if that helps, but on my machine it it enough to take GENERIC kernconf file, add all GEOM_ options and comment out INVARIANTS and WITNESSES. I don't thing this it the least amount of changes, but it reliably causes trap 12: Ok, found it. That code depends on the ref-counting I have in my tree, I've diked it out for now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On 15-Mar-2003 Bryan Liesner wrote: On Fri, 14 Mar 2003, Conrad Sabatier wrote: Now, really, am I the only one experiencing this? No, you're not. I've been unable to get a bootable kernel running for the last few days also. Booting in verbose mode, I see the last thing that occurs just before the panic is mounting root and then starting (or trying to start) /sbin/init. After an initial hang, it drops into ddb. Did it panic on devfs_find()? And, if you've seen my earlier posts, have you experienced that stuff too? Yes, exactly right. In devfs_find(). And looking back at your earlier posts, it looks like my experiences pretty much correlate with yours. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: panic on boot (devfs_find)
cheer! wilma heeft het door. guest werkt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Conrad Sabatier Sent: zaterdag 15 maart 2003 13:22 To: Bryan Liesner Cc: [EMAIL PROTECTED] Subject: Re: panic on boot (devfs_find) On 15-Mar-2003 Bryan Liesner wrote: On Fri, 14 Mar 2003, Conrad Sabatier wrote: Now, really, am I the only one experiencing this? No, you're not. I've been unable to get a bootable kernel running for the last few days also. Booting in verbose mode, I see the last thing that occurs just before the panic is mounting root and then starting (or trying to start) /sbin/init. After an initial hang, it drops into ddb. Did it panic on devfs_find()? And, if you've seen my earlier posts, have you experienced that stuff too? Yes, exactly right. In devfs_find(). And looking back at your earlier posts, it looks like my experiences pretty much correlate with yours. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas 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: panic on boot (devfs_find)
whoops wrong list... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bug Sent: zaterdag 15 maart 2003 13:25 To: Conrad Sabatier; Bryan Liesner Cc: [EMAIL PROTECTED] Subject: RE: panic on boot (devfs_find) cheer! wilma heeft het door. guest werkt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Conrad Sabatier Sent: zaterdag 15 maart 2003 13:22 To: Bryan Liesner Cc: [EMAIL PROTECTED] Subject: Re: panic on boot (devfs_find) On 15-Mar-2003 Bryan Liesner wrote: On Fri, 14 Mar 2003, Conrad Sabatier wrote: Now, really, am I the only one experiencing this? No, you're not. I've been unable to get a bootable kernel running for the last few days also. Booting in verbose mode, I see the last thing that occurs just before the panic is mounting root and then starting (or trying to start) /sbin/init. After an initial hang, it drops into ddb. Did it panic on devfs_find()? And, if you've seen my earlier posts, have you experienced that stuff too? Yes, exactly right. In devfs_find(). And looking back at your earlier posts, it looks like my experiences pretty much correlate with yours. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
--- Conrad Sabatier [EMAIL PROTECTED] wrote: Booting in verbose mode, I see the last thing that occurs just before the panic is mounting root and then starting (or trying to start) /sbin/init. After an initial hang, it drops into ddb. -- I found the same problem for the last two days. However, it seems that this problem doesn't appear in the GENERIC kernel. I have tried putting the INVARIANTS stuffs back to my custom config file and it works as well. Very strange... I may have some spare time to search for the break point later and will post if I can find any commit that causes this. Regards, __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On 15-Mar-2003 Shizuka Kudo wrote: --- Conrad Sabatier [EMAIL PROTECTED] wrote: Booting in verbose mode, I see the last thing that occurs just before the panic is mounting root and then starting (or trying to start) /sbin/init. After an initial hang, it drops into ddb. -- I found the same problem for the last two days. However, it seems that this problem doesn't appear in the GENERIC kernel. I have tried putting the INVARIANTS stuffs back to my custom config file and it works as well. Very strange... Yes, it is very strange. Yesterday, all of the kernels I compiled were bombing in devfs_find(). Today, the kernels I've tried are now bombing in devfs_vmkdir(). I compiled today using minimal CFLAGS, just -O -pipe, no -march stuff. I may have some spare time to search for the break point later and will post if I can find any commit that causes this. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On 15-Mar-2003 Shizuka Kudo wrote: I found the same problem for the last two days. However, it seems that this problem doesn't appear in the GENERIC kernel. I have tried putting the INVARIANTS stuffs back to my custom config file and it works as well. Very strange... I just built a GENERIC kernel and it booted OK. Weird. I may have some spare time to search for the break point later and will post if I can find any commit that causes this. Thanks! -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
--- Bryan Liesner [EMAIL PROTECTED] wrote: I was able to get a kernel up and running (strangely) on 3/12, but commits after that cause an immediate panic as soon as init starts. If I build a kernel from sources cut off at 3/10/2003 at 12:00, everything works fine. It is related to the sys/geom/geom_event.c commit on 3/11/2003: Revision 1.20 / (download) - annotate - [select for diffs], Mon Mar 10 23:41:41 2003 UTC (5 days, 5 hours ago) by phk Branch: MAIN CVS Tags: HEAD Changes since 1.19: +5 -0 lines Diff to previous 1.19 (colored) If we run out of consumers while orphaning them, and the provider's geom is withering, destroy the provider when done. This was exposed by the recent change to geom_dev's orphaning logic If I reverted it back to a previous version (1.19) then the machine booted OK. BTW, I also found that adding INVARIANTS options into the kernel can prevent this problem as well. Regards, __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On Sat, 15 Mar 2003, Shizuka Kudo wrote: --- Bryan Liesner [EMAIL PROTECTED] wrote: I was able to get a kernel up and running (strangely) on 3/12, but commits after that cause an immediate panic as soon as init starts. If I build a kernel from sources cut off at 3/10/2003 at 12:00, everything works fine. It is related to the sys/geom/geom_event.c commit on 3/11/2003: Revision 1.20 / (download) - annotate - [select for diffs], Mon Mar 10 23:41:41 2003 UTC (5 days, 5 hours ago) by phk Branch: MAIN CVS Tags: HEAD Changes since 1.19: +5 -0 lines Diff to previous 1.19 (colored) If we run out of consumers while orphaning them, and the provider's geom is withering, destroy the provider when done. This was exposed by the recent change to geom_dev's orphaning logic If I reverted it back to a previous version (1.19) then the machine booted OK. BTW, I also found that adding INVARIANTS options into the kernel can prevent this problem as well. Regards, I have reverted back to rev 1.19 and all seems to be running OK. I have /dev/null, /dev/stderr, /dev/apm, and /dev/mixer back. When the faulty kernel _did_ boot (after about a million retries to coax a core dump), these devices were missing at boot, or would disappear shortly after. Thanks. I think Poul-Henning will have enough information to go with now... -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic on boot (devfs_find)
I made posts here recently describing some panics which are somehow related to disappearing/never created device nodes. I am unable to produce a core dump at all, as it panics before / is mounted. The documented kern.dumpdev (unknown oid) doesn't exist and setting dumpdev=ad0s1b in loader.conf doesn't help either. I compiled the faulty kernel with ddb and found that the failure was in devfs_find(). I'm trying to gather more information. Any tips on how to get a proper core dump would be appreciated. As described in my earlier posts, this started happening sometime shortly after commits done after 3/10/2003. Now, really, am I the only one experiencing this? -Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
In message [EMAIL PROTECTED], Bryan Liesner writes: I made posts here recently describing some panics which are somehow related to disappearing/never created device nodes. I am unable to produce a core dump at all, as it panics before / is mounted. The documented kern.dumpdev (unknown oid) doesn't exist and setting dumpdev=ad0s1b in loader.conf doesn't help either. Do you have any indication which device may be causing this ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On Fri, 14 Mar 2003, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bryan Liesner writes: I made posts here recently describing some panics which are somehow related to disappearing/never created device nodes. I am unable to produce a core dump at all, as it panics before / is mounted. The documented kern.dumpdev (unknown oid) doesn't exist and setting dumpdev=ad0s1b in loader.conf doesn't help either. Do you have any indication which device may be causing this ? I suspect /dev/null. On 3/11, I had a kernel compiled that was acting strangely. It would appear to run just fine, but when I went to compile, the build process complained that /dev/null doesn't exist. I checked, and it didn't. I also lost /dev/stderr when I looked at the nightly maintenance output. stdout and others just disappeared. X wouldn't start, complaining that vga didn't exist. (this happend shortly after I successfully ran X, exited, and restarted.) I was able to get a kernel up and running (strangely) on 3/12, but commits after that cause an immediate panic as soon as init starts. If I build a kernel from sources cut off at 3/10/2003 at 12:00, everything works fine. -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On 14-Mar-2003 Bryan Liesner wrote: I made posts here recently describing some panics which are somehow related to disappearing/never created device nodes. I am unable to produce a core dump at all, as it panics before / is mounted. The documented kern.dumpdev (unknown oid) doesn't exist and setting dumpdev=ad0s1b in loader.conf doesn't help either. I compiled the faulty kernel with ddb and found that the failure was in devfs_find(). I'm trying to gather more information. Any tips on how to get a proper core dump would be appreciated. As described in my earlier posts, this started happening sometime shortly after commits done after 3/10/2003. Now, really, am I the only one experiencing this? No, you're not. I've been unable to get a bootable kernel running for the last few days also. Booting in verbose mode, I see the last thing that occurs just before the panic is mounting root and then starting (or trying to start) /sbin/init. After an initial hang, it drops into ddb. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On Fri, 14 Mar 2003, Conrad Sabatier wrote: Now, really, am I the only one experiencing this? No, you're not. I've been unable to get a bootable kernel running for the last few days also. Booting in verbose mode, I see the last thing that occurs just before the panic is mounting root and then starting (or trying to start) /sbin/init. After an initial hang, it drops into ddb. Did it panic on devfs_find()? And, if you've seen my earlier posts, have you experienced that stuff too? -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
