Re: My problems with GEOM
On Wed, 9 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Seth Hieronymus writes: I think your recent commits have fixed my hang on boot with an empty ZIP-drive. Thank you. Cool. It still can't even mount root for my configurations. This is because it breaks compatibility by dropping support for the devices on the first FreeBSD slice being named without a slice number (e.g., ad0a is named ad0a, not ad0smachine-dependent slice numbera). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
In message [EMAIL PROTECTED], Bruce Evans writes: On Wed, 9 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Seth Hieronymus writes: I think your recent commits have fixed my hang on boot with an empty ZIP-drive. Thank you. Cool. It still can't even mount root for my configurations. This is because it breaks compatibility by dropping support for the devices on the first FreeBSD slice being named without a slice number (e.g., ad0a is named ad0a, not ad0smachine-dependent slice numbera). ... as discussed years back. All you have to do is edit your /etc/fstab. -- 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: My problems with GEOM
On Wed, 9 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: On Wed, 9 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Seth Hieronymus writes: I think your recent commits have fixed my hang on boot with an empty ZIP-drive. Thank you. Cool. It still can't even mount root for my configurations. This is because it breaks compatibility by dropping support for the devices on the first FreeBSD slice being named without a slice number (e.g., ad0a is named ad0a, not ad0smachine-dependent slice numbera). ... as discussed years back. The maintainer of the slice code never agreed with removing the compatibility slice and always used this feature. Unfortunately, the maintainer wasn't diligent enough in fixing i386-centric documentation that says to use explicit slice numbers. All you have to do is edit your /etc/fstab. Not so. I would have to edit fstab back and forth to boot various kernels, and would also have to use devfs or MAKEDEV to get all the sliced devices created, and change boot loaders back and forth to get the slice number passed in a way that is recognized by all kernels of interest (or change ROOTDEVNAMES back and forth) Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
In message [EMAIL PROTECTED], Bruce Evans writes: All you have to do is edit your /etc/fstab. Not so. I would have to edit fstab back and forth to boot various kernels, and would also have to use devfs or MAKEDEV to get all the sliced devices created, and change boot loaders back and forth to get the slice number passed in a way that is recognized by all kernels of interest (or change ROOTDEVNAMES back and forth) Yes, you might in fact risk being dragged (kicking and screaming I'm sure) into the middle nineties. -- 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: My problems with GEOM
On Wed, 9 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: All you have to do is edit your /etc/fstab. Not so. I would have to edit fstab back and forth to boot various kernels, and would also have to use devfs or MAKEDEV to get all the sliced devices created, and change boot loaders back and forth to get the slice number passed in a way that is recognized by all kernels of interest (or change ROOTDEVNAMES back and forth) Yes, you might in fact risk being dragged (kicking and screaming I'm sure) into the middle nineties. Sorry, I don't want to go back there. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
On Wed, 9 Oct 2002, David O'Brien wrote: On Wed, Oct 09, 2002 at 07:47:06PM +1000, Bruce Evans wrote: It still can't even mount root for my configurations. This is because it breaks compatibility by dropping support for the devices on the first FreeBSD slice being named without a slice number (e.g., ad0a is named ad0a, not ad0smachine-dependent slice numbera). Also SCSI CDROM's are now only mountable as /dev/cd0, not /dev/cd0a as before. I wonder how many others got hit by that. PHK, please add back the old BSD partition types. Too many of my utilities and scripts depend on them. It's a very useful idiom to address the first FreeBSD slice on a disk. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
On Wed, 9 Oct 2002, David O'Brien wrote: Also SCSI CDROM's are now only mountable as /dev/cd0, not /dev/cd0a as before. I wonder how many others got hit by that. Apparently not as many as got hit by the block number scaling bug. I guess most users only have atapi cdroms. This is a good change, but needs time for conversion. The SCSI CDROM driver has some very nice new bugs apart from broken label contents. I have noticed the following so far: - b_pblkno seems to be unitialized. I think it is always 0, This affects mainly disksort^Wbioq_disksort(). The driver used to use b_pblkno internally and the scaling bug was introduced by replacing this by b_blkno and fixed by scaling b_blkno to the value that b_pblkno should be set to. - block sizes and offsets that are not a multiple of the sector size are now accepted, but don't work. E.g., dd with a block size of 1 byte doesn't fail, but produces garbage. - offsets beyond EOF are now accepted in software and are only rejected in hardware. This spams the console with error messages and gives wrong error handling (EIO; should be EOF (no error)). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
In message [EMAIL PROTECTED], Nate Lawson wri tes: On Wed, 9 Oct 2002, David O'Brien wrote: On Wed, Oct 09, 2002 at 07:47:06PM +1000, Bruce Evans wrote: It still can't even mount root for my configurations. This is because it breaks compatibility by dropping support for the devices on the first FreeBSD slice being named without a slice number (e.g., ad0a is named ad0a, not ad0smachine-dependent slice numbera). Also SCSI CDROM's are now only mountable as /dev/cd0, not /dev/cd0a as before. I wonder how many others got hit by that. PHK, please add back the old BSD partition types. Too many of my utilities and scripts depend on them. It's a very useful idiom to address the first FreeBSD slice on a disk. I'd prefer not to if we can avoid it, but I'll offer this patch as a sort of POLA-disturbing middle-ground: http://phk.freebsd.dk/patch/cd.patch -- 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: My problems with GEOM
In message [EMAIL PROTECTED], Bruce Evans writes: On Wed, 9 Oct 2002, David O'Brien wrote: Also SCSI CDROM's are now only mountable as /dev/cd0, not /dev/cd0a as before. I wonder how many others got hit by that. Apparently not as many as got hit by the block number scaling bug. I guess most users only have atapi cdroms. This is a good change, but needs time for conversion. The SCSI CDROM driver has some very nice new bugs apart from broken label contents. I have noticed the following so far: - b_pblkno seems to be unitialized. I think it is always 0, This affects mainly disksort^Wbioq_disksort(). The driver used to use b_pblkno internally and the scaling bug was introduced by replacing this by b_blkno and fixed by scaling b_blkno to the value that b_pblkno should be set to. - block sizes and offsets that are not a multiple of the sector size are now accepted, but don't work. E.g., dd with a block size of 1 byte doesn't fail, but produces garbage. - offsets beyond EOF are now accepted in software and are only rejected in hardware. This spams the console with error messages and gives wrong error handling (EIO; should be EOF (no error)). Yeah, I have a patch sitting in my tree which I couldn't get to work, probably because the blocksize issue obscured it, I'll get to it one of these days. -- 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: My problems with GEOM
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Nate Lawson w ri tes: On Wed, 9 Oct 2002, David O'Brien wrote: On Wed, Oct 09, 2002 at 07:47:06PM +1000, Bruce Evans wrote: It still can't even mount root for my configurations. This is because it breaks compatibility by dropping support for the devices on the first FreeBSD slice being named without a slice number (e.g., ad0a is named ad0a, not ad0smachine-dependent slice numbera). Also SCSI CDROM's are now only mountable as /dev/cd0, not /dev/cd0a as before. I wonder how many others got hit by that. PHK, please add back the old BSD partition types. Too many of my utilities and scripts depend on them. It's a very useful idiom to address the first FreeBSD slice on a disk. I'd prefer not to if we can avoid it, but I'll offer this patch as a sort of POLA-disturbing middle-ground: http://phk.freebsd.dk/patch/cd.patch I think this is probably the best option. It avoids cluttering /dev, but still DTRT for built-in finger knowledge. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
On Wed, 9 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Nate Lawson wri tes: On Wed, 9 Oct 2002, David O'Brien wrote: On Wed, Oct 09, 2002 at 07:47:06PM +1000, Bruce Evans wrote: It still can't even mount root for my configurations. This is because it breaks compatibility by dropping support for the devices on the first FreeBSD slice being named without a slice number (e.g., ad0a is named ad0a, not ad0smachine-dependent slice numbera). Also SCSI CDROM's are now only mountable as /dev/cd0, not /dev/cd0a as before. I wonder how many others got hit by that. PHK, please add back the old BSD partition types. Too many of my utilities and scripts depend on them. It's a very useful idiom to address the first FreeBSD slice on a disk. I'd prefer not to if we can avoid it, but I'll offer this patch as a sort of POLA-disturbing middle-ground: http://phk.freebsd.dk/patch/cd.patch Better than nothing. I am fine with this. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
I think your recent commits have fixed my hang on boot with an empty ZIP-drive. Thank you. Seth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
In message [EMAIL PROTECTED], Seth Hieronymus writes: I think your recent commits have fixed my hang on boot with an empty ZIP-drive. Thank you. Cool. -- 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: My problems with GEOM
From: Poul-Henning Kamp [EMAIL PROTECTED] In message [EMAIL PROTECTED], Seth Hieronymus writes: You were right. After trying both a CD, and a zip-disk in the computer (both together, and separately), having a zip-disk in the drive seems to allow the boot to continue normally. ATA(PI) or SCSI interface ZIP ? atapi. Here are some excerpts from the dmesg: atapci0: Intel PIIX4 ATA33 controller port 0x10c0-0x10cf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, USB at device 7.2 (no driver attached) pci0: bridge, PCI-unknown at device 7.3 (no driver attached) pci0: multimedia at device 15.1 (no driver attached) pci0: multimedia, audio at device 16.0 (no driver attached) pci0: input device at device 16.1 (no driver attached) pci0: serial bus, FireWire at device 17.0 (no driver attached) ad0: 28629MB ST330630A [58168/16/63] at ata0-master UDMA33 acd0: CDROM Lite-On LTN483S 48x Max at ata1-master PIO4 afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 Thanks, Seth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
On Mon, Oct 07, 2002 at 08:39:06AM -0600, Seth Hieronymus wrote: afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 PHK had me dd if=/dev/afd0 of=/dev/null with no media in the drive. I get dd: /dev/afd0: Device busy, which is what the problem is. Some where in /sys/dev/ata is an EBUSY that should be ENXIO. If you can instrument at least atapi-all.c and atapi-fd.c and help track this down it would be most helpful. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
In message [EMAIL PROTECTED], David O'Brien writes: On Mon, Oct 07, 2002 at 08:39:06AM -0600, Seth Hieronymus wrote: afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 PHK had me dd if=/dev/afd0 of=/dev/null with no media in the drive. I get dd: /dev/afd0: Device busy, which is what the problem is. Some where in /sys/dev/ata is an EBUSY that should be ENXIO. If you can instrument at least atapi-all.c and atapi-fd.c and help track this down it would be most helpful. I talked with sos@ about this today, and I'll be working on something tonight. -- 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: My problems with GEOM
From: David O'Brien: On Mon, Oct 07, 2002 at 08:39:06AM -0600, Seth Hieronymus wrote: afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 PHK had me dd if=/dev/afd0 of=/dev/null with no media in the drive. I get dd: /dev/afd0: Device busy, which is what the problem is. Some where in /sys/dev/ata is an EBUSY that should be ENXIO. If you can instrument at least atapi-all.c and atapi-fd.c and help track this down it would be most helpful. Thanks for the reply. Yes that makes sense. I'll see if I can look more at the code tonight. Seth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
My problems with GEOM
Hello, After recompiling a kernel after the GEOM transition, my boot gets as far as: Initializing GEOMetry subsystem ad0: 28629MB ST330630A [58168/16/63] at ata0-master UDMA33 acd0: CDROM Lite-On LTN483S 48x Max at ata1-master PIO4 afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 Mounting root from ufs:/dev/ad0s1a and hangs -- only a physical reset works. However, breaking into the debugger, and running a trace, I get (hand-copied): Debugger(manual escape to debugger) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db trace Debugger(c0331a32,4,1,0,1) at Debugger+0x54 scgetc(c03cc1e0,2,c031a8f5,2fd,c1876b40) at scgetc+0x445 sckbdevent(c03a6ee0,0,c03cc1e0,c034b1c0,8) at sckbdevent+0x1d0 atkbd_intr(c03a6ee0,0,c8793d0c,c01a25c2,c03a6ee0) at atkbd_intr+0x2c atkbd_isa_intr(c03a6ee0,0,c0317bac,215,c0bbf370) at atkbd_isa_intr+0x21 ithread_loop(c185fe00,c8793d48,c031790b,34d,7641000a) at ithread_loop+0x182 fork_exit(c01a2440,c185fe00,c8793d48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xc8793d7c, ebp = 0 --- Am I doing something wrong here? Thanks for any help. My pre-GEOM dmesg, and kernel config follow. A kernel and world from the day before the GEOM switch works fine. Seth Hieronymus ** Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Sat Oct 5 10:00:26 MDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/hts7 Preloaded elf kernel /boot/kernel.save/kernel at 0xc0449000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04490b0. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 698395737 Hz CPU: Pentium III/Pentium III Xeon/Celeron (698.40-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 134217728 (131072K bytes) avail memory = 125603840 (122660K bytes) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTD RSDT on motherboard Using $PIR table, 10 entries at 0xc00fdf20 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.1 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.2 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.15.0 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.15.1 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.15.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.16.0 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.16.1 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.16.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.17.0 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.17.1 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.17.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.12.0 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.7.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.7.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.7.3 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.1.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.1.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.1.3 before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.1 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.2 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12]
Re: My problems with GEOM
On Sun, Oct 06, 2002 at 05:08:00PM -0600, Seth Hieronymus wrote: Hello, After recompiling a kernel after the GEOM transition, my boot gets as far as: Initializing GEOMetry subsystem ad0: 28629MB ST330630A [58168/16/63] at ata0-master UDMA33 acd0: CDROM Lite-On LTN483S 48x Max at ata1-master PIO4 afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 Mounting root from ufs:/dev/ad0s1a and hangs -- only a physical reset works. However, breaking into the debugger, and running a trace, I get (hand-copied): Debugger(manual escape to debugger) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db trace Debugger(c0331a32,4,1,0,1) at Debugger+0x54 scgetc(c03cc1e0,2,c031a8f5,2fd,c1876b40) at scgetc+0x445 sckbdevent(c03a6ee0,0,c03cc1e0,c034b1c0,8) at sckbdevent+0x1d0 atkbd_intr(c03a6ee0,0,c8793d0c,c01a25c2,c03a6ee0) at atkbd_intr+0x2c atkbd_isa_intr(c03a6ee0,0,c0317bac,215,c0bbf370) at atkbd_isa_intr+0x21 ithread_loop(c185fe00,c8793d48,c031790b,34d,7641000a) at ithread_loop+0x182 fork_exit(c01a2440,c185fe00,c8793d48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xc8793d7c, ebp = 0 --- Am I doing something wrong here? Thanks for any help. My pre-GEOM dmesg, and kernel config follow. A kernel and world from the day before the GEOM switch works fine. I also have the aforementioned problem. I had this problem several months before GEOM was enabled so I can not vouch for it being GEOM- related. Any time I trace after this apparent hang I get a mostly identical trace as you have shown. I have no idea why it happens. I only know that it happens only with FreeBSD on my laptop. No other operating system I have tried on it has this problem. Unfortunately I cannot be more verbose (that I am aware of) than the trace. I have been unsuccessful at forcing a core dump, and I do not know why. I am at the point where if someone offers an idea to get more information I could possily be more useful. I will try adding printf's where I think would be useful but this is a needle in a haystack issue for me since I am not 100% aware of the internals. -- Carl Schmidt [Random Quote] Be different: conform. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
On Sun, 6 Oct 2002, Carl Schmidt wrote: Mounting root from ufs:/dev/ad0s1a and hangs -- only a physical reset works. However, breaking into the debugger, and running a trace, I get (hand-copied): Hmm. I actually ran into this problem on some diskless booting boxes, but it went away so I assumed it was a local nit since I was messing with VFS substantially on the boxes in question. Apparently not. (This was a month or two ago, and quite pre-GEOM as default). Here's my first suggestion: the root file system is mounted by the init process--your trace shows the stack of the current interrupt thread for keyboard I/O, since that's the foreground thread when you break to the debugger. Try using 'trace 1' to trace init instead; also, if you could provide the output from the ddb ps command, that would be very useful. BTW, you really want to be using a serial console for this sort of thing -- copying stuff out by hand is (a) a pain, and (b) very error prone :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
From: Robert Watson On Sun, 6 Oct 2002, Carl Schmidt wrote: Mounting root from ufs:/dev/ad0s1a and hangs -- only a physical reset works. However, breaking into the debugger, and running a trace, I get (hand-copied): Hmm. I actually ran into this problem on some diskless booting boxes, but it went away so I assumed it was a local nit since I was messing with VFS substantially on the boxes in question. Apparently not. (This was a month or two ago, and quite pre-GEOM as default). Here's my first suggestion: the root file system is mounted by the init process--your trace shows the stack of the current interrupt thread for keyboard I/O, since that's the foreground thread when you break to the debugger. Try using 'trace 1' to trace init instead; also, if you could provide the output from the ddb ps command, that would be very useful. BTW, you really want to be using a serial console for this sort of thing -- copying stuff out by hand is (a) a pain, and (b) very error prone :-). Thanks for the pointers. Here's the trace 1: mi_switch(c0bb9988,14,c01bbe60,c0bb98f0,1) at mi_switch+0x290 msleep(c03778a0,0,68,c03153d7,14) at msleep+0x477 g_waitidle(1,c0314e10,c18f2885,c031bd64,c0b8dc20) at g_waitidle+0x8b g_dev_clone(0,c18f2885,6,c879cc08,c0bb6d80) at g_dev_clone+0x37 getdiskbyname(c18f2880,c879cc80,c0202f87,c18f2880,c18f2880) at getdiskbyname+0xa2 setrootbyname(c18f2880,c18f2880,c879cc48,c18f2880,20302020) at setrootbyname+0x11 vfs_mountroot_try(c1867220,c01912e0,c0bb8dc0,c879cd0c,c019134b) at vfs_mountroot_try+0x127 vfs_mountroot(c034b1c0,1,c0316bc7,216,203a2065) at vfs_mountroot+0x70 start_init(0,c879cd48,c031790b,34d,726f772d) at start_init+0x6b fork_exit(c01912e0,0,c879cd48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xc879cd7c, ebp = 0 --- Here's the output from ps: pid proc addr uid ppid pgrp flag stat wmesg wchan cmd 36 c18f4c08 cd352000 0 0 0 204 norm[SLPQ nfsidl c035bdec][SLP] nfsio d 3 35 c18f4dc0 cd353000 0 0 0 204 norm[SLPQ nfsidl c035bde8][SLP] nfsiod 2 34 c18f7000 cd354000 0 0 0 204 norm[SLPQ nfsidl c035bde4][SLP] nfsiod 1 33 c1868528 c8e0d000 0 0 0 204 norm[SLPQ nfsidl c035bde0][SLP] nfsiod 0 32 c18686e0 c8e0e000 0 0 0 204 norm[SLPQ vlruwt c18686e0][SLP] vnlru 9 c1868898 c8e0f000 0 0 0 204 norm[SLPQ syncer c034c4cc][SLP] syncer 8 c1868a50 c8e1 0 0 0 204 norm[SLPQ psleep c03a2e00][SLP] bufdaemon 7 c1868c08 c8e11000 0 0 0 20c norm[SLPQ pgzero c03a68a8][SLP] pagezero 6 c1868dc0 c8e12000 0 0 0 204 norm[SLPQ psleep c03a68bc][SLP] vmdaemon 5 c18de000 cd309000 0 0 0 204 norm[SLPQ psleep c03612d8][SLP] pagedaemon 4 c18de1b8 cd30a000 0 0 0 204 norm[SLPQ g_down c0345678][SLP] g_down 3 c18de370 cd30b000 0 0 0 204 norm[SLPQ g_up c0345674][SLP] g_up 2 c18de528 cd30c000 0 0 0 204 norm[SLPQ g_read_data_busy c87d5c00][SLP] g_event 31 c18de6e0 cd30d000 0 0 0 204 new [IWAIT] irq8: rtc 30 c18de898 cd30e000 0 0 0 204 new [IWAIT] irq0: clk 29 c0bbf1b8 c87f4000 0 0 0 204 new [IWAIT] irq12: psm0 28 c0bbf370 c87f5000 0 0 0 204 norm[CPU 0] irq1: atkbd0 27 c0bbf528 c87f6000 0 0 0 204 new [IWAIT] irq7: ppc0 26 c0bbf6e0 c87f7000 0 0 0 204 new [IWAIT] irq4: sio0 25 c0bbf898 c87f8000 0 0 0 204 new [IWAIT] swi0: tty:sio 24 c0bbfa50 c87f9000 0 0 0 204 norm[IWAIT] irq6: fdc0 23 c0bbfc08 c87fa000 0 0 0 204 new [IWAIT] irq10: bktr0 22 c0bbfdc0 c87fb000 0 0 0 204 new [IWAIT] irq11: xl0 21 c1868000 c8dcd000 0 0 0 204 norm[IWAIT] irq15: ata1 20 c18681b8 c8dd2000 0 0 0 204 norm[IWAIT] irq14: ata 0 19 c1868370 c8dd3000 0 0 0 204 new [IWAIT] irq9: acpi0 18 c0bb8000 c8778000 0 0 0 204 new [IWAIT] irq13: 17 c0bb81b8 c87eb000 0 0 0 204 new [IWAIT] swi5: task queue 16 c0bb8370 c87ec000 0 0 0 204 new [IWAIT] swi5: acpitaskq 15 c0bb8528 c87ed000 0 0 0 204 norm[SLPQ sleep c036b040][SLP] random 14 c0bb86e0 c87ee000 0 0 0 204 new [IWAIT] swi4: vm 13 c0bb8898 c87ef000 0 0 0 20c norm[IWAIT] swi6: tty:sio clock 12 c0bb8a50 c87f 0 0 0 204 new [IWAIT] swi1: net 11 c0bb8c08 c87f1000 0 0 0 20c norm[Can run] idle 1 c0bb8dc0 c87f2000 0 0 0 200 norm[SLPQ g_waitidle c03778a0][SLP] swapper 10 c0bbf000 c87f3000 0 0 0 204 norm[CVQ ktrace c037a084][SLP] ktrace 0 c0346920 c04a2000 0 0 0 200 norm[SLPQ sched c0346920][SLP] swapper Hope that helps. Anything else you would like me to do? Seth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
do a 'ps' in ddb On Sun, 6 Oct 2002, Seth Hieronymus wrote: Hello, After recompiling a kernel after the GEOM transition, my boot gets as far as: Initializing GEOMetry subsystem ad0: 28629MB ST330630A [58168/16/63] at ata0-master UDMA33 acd0: CDROM Lite-On LTN483S 48x Max at ata1-master PIO4 afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 Mounting root from ufs:/dev/ad0s1a and hangs -- only a physical reset works. However, breaking into the debugger, and running a trace, I get (hand-copied): Debugger(manual escape to debugger) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db trace Debugger(c0331a32,4,1,0,1) at Debugger+0x54 scgetc(c03cc1e0,2,c031a8f5,2fd,c1876b40) at scgetc+0x445 sckbdevent(c03a6ee0,0,c03cc1e0,c034b1c0,8) at sckbdevent+0x1d0 atkbd_intr(c03a6ee0,0,c8793d0c,c01a25c2,c03a6ee0) at atkbd_intr+0x2c atkbd_isa_intr(c03a6ee0,0,c0317bac,215,c0bbf370) at atkbd_isa_intr+0x21 ithread_loop(c185fe00,c8793d48,c031790b,34d,7641000a) at ithread_loop+0x182 fork_exit(c01a2440,c185fe00,c8793d48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xc8793d7c, ebp = 0 --- Am I doing something wrong here? Thanks for any help. My pre-GEOM dmesg, and kernel config follow. A kernel and world from the day before the GEOM switch works fine. Seth Hieronymus ** Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Sat Oct 5 10:00:26 MDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/hts7 Preloaded elf kernel /boot/kernel.save/kernel at 0xc0449000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04490b0. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 698395737 Hz CPU: Pentium III/Pentium III Xeon/Celeron (698.40-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 134217728 (131072K bytes) avail memory = 125603840 (122660K bytes) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTD RSDT on motherboard Using $PIR table, 10 entries at 0xc00fdf20 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.1 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.2 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.15.0 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.15.1 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.15.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.16.0 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.16.1 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.16.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.17.0 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.17.1 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.17.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.12.0 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.7.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.7.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.7.3 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.1.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.1.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.1.3 before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.1 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9
Re: My problems with GEOM
On Sun, 6 Oct 2002, Seth Hieronymus wrote: Thanks for the pointers. Here's the trace 1: mi_switch(c0bb9988,14,c01bbe60,c0bb98f0,1) at mi_switch+0x290 msleep(c03778a0,0,68,c03153d7,14) at msleep+0x477 g_waitidle(1,c0314e10,c18f2885,c031bd64,c0b8dc20) at g_waitidle+0x8b g_dev_clone(0,c18f2885,6,c879cc08,c0bb6d80) at g_dev_clone+0x37 getdiskbyname(c18f2880,c879cc80,c0202f87,c18f2880,c18f2880) at getdiskbyname+0xa2 setrootbyname(c18f2880,c18f2880,c879cc48,c18f2880,20302020) at setrootbyname+0x11 vfs_mountroot_try(c1867220,c01912e0,c0bb8dc0,c879cd0c,c019134b) at vfs_mountroot_try+0x127 vfs_mountroot(c034b1c0,1,c0316bc7,216,203a2065) at vfs_mountroot+0x70 start_init(0,c879cd48,c031790b,34d,726f772d) at start_init+0x6b fork_exit(c01912e0,0,c879cd48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a This sounds identical (modulo geom details) to the la-la land my boxes were going off into. As I said, I never really followed up, but it looked like one of the i/o/device transactions during the root mount was getting lost, and as a result the init thread was never waking up. I'll probably have to let someone with more i/o clue take it from here. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
In the last episode (Oct 06), Robert Watson said: On Sun, 6 Oct 2002, Seth Hieronymus wrote: Thanks for the pointers. Here's the trace 1: mi_switch(c0bb9988,14,c01bbe60,c0bb98f0,1) at mi_switch+0x290 msleep(c03778a0,0,68,c03153d7,14) at msleep+0x477 g_waitidle(1,c0314e10,c18f2885,c031bd64,c0b8dc20) at g_waitidle+0x8b g_dev_clone(0,c18f2885,6,c879cc08,c0bb6d80) at g_dev_clone+0x37 getdiskbyname(c18f2880,c879cc80,c0202f87,c18f2880,c18f2880) at getdiskbyname+0xa2 setrootbyname(c18f2880,c18f2880,c879cc48,c18f2880,20302020) at setrootbyname+0x11 vfs_mountroot_try(c1867220,c01912e0,c0bb8dc0,c879cd0c,c019134b) at vfs_mountroot_try+0x127 vfs_mountroot(c034b1c0,1,c0316bc7,216,203a2065) at vfs_mountroot+0x70 start_init(0,c879cd48,c031790b,34d,726f772d) at start_init+0x6b fork_exit(c01912e0,0,c879cd48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a This sounds identical (modulo geom details) to the la-la land my boxes were going off into. As I said, I never really followed up, but it looked like one of the i/o/device transactions during the root mount was getting lost, and as a result the init thread was never waking up. I'll probably have to let someone with more i/o clue take it from here. I'm not at the machine right now, but I noticed that my work machine would hang for a long time ( 5 minutes) on bootup, then continue. I finally figured out what the problem was: it has two SCSI cdrom drives, and geom apparently needed to get info on the disks for some reason. Neither drive had a CD in it, and it had to time out a read request on both drives before it would boot. Try sticking a data CD in your cdrom and see if the hang goes away. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
On Sun, Oct 06, 2002 at 08:26:03PM -0400, Robert Watson wrote: On Sun, 6 Oct 2002, Carl Schmidt wrote: Mounting root from ufs:/dev/ad0s1a and hangs -- only a physical reset works. However, breaking into the debugger, and running a trace, I get (hand-copied): Hmm. I actually ran into this problem on some diskless booting boxes, but it went away so I assumed it was a local nit since I was messing with VFS substantially on the boxes in question. Apparently not. (This was a month or two ago, and quite pre-GEOM as default). Here's my first suggestion: the root file system is mounted by the init process--your trace shows the stack of the current interrupt thread for keyboard I/O, since that's the foreground thread when you break to the debugger. Try using 'trace 1' to trace init instead; also, if you could provide the output from the ddb ps command, that would be very useful. BTW, you really want to be using a serial console for this sort of thing -- copying stuff out by hand is (a) a pain, and (b) very error prone :-). I believe you were addressing the originator of this thread but I will go ahead and show my trace/ps: db trace 1 mi_switch(c0f014e0,cd33dca8,1,80202,c0f018f0) at mi_switch+0x1b3 ithread_schedule(c25e6b00,1) at ithread_schedule+0x10d sched_ithd(1) at sched_ithd+0x37 Xintr1() at Xintr1+0x67 --- interrupt, eip = 0xc025b5b0, esp = 0xcd33dcfc, ebp = 0xcd33dd04 --- cpu_unpend(cd33dd14,c018478d,cd33d3c,c019a750,2800) at cpu_unpend+0x28 cpu_critical_exit(cd33dd3c,c019a750,2800,1,73e) at cpu_critical_exit+0x12 critical_exit(2800,1,73e,0,c0f05c40) at critical_exit+0x21 ast(cd33dd48) at ast+0x39c doreti_ast() at doreti_ast+0x1a db ps 33 c25dd528 cddbf000000 204 norm[SLPQ psleep c02dc580][SLP] bufdaemon 9 c25dd6e0 cddc000 20c norm[RUNQ] pagezero 8 c25dd898 cddc1000000 204 norm[SLPQ psleep c02df91c][SLP] vmdaemon 7 c25dda50 cddc2000000 204 norm[SLPQ psleep c02c9b18][SLP] pagedaemon 6 c25ddc08 cddc3000000 204 norm[SLPQ g_down c02b1a58][SLP] g_down 5 c25dddc0 cddc4000000 204 norm[SLPQg_up c02b1a54][SLP] g_up 4 c2615000 d1ddf000000 204 norm[SLPQ g_events c02b1a4c][SLP] g_event 32 c26151b8 d1de000 204 new [IWAIT] irq8: rtc 31 c2615370 d1de1000000 204 new [IWAIT] irq0: clk 30 c2615528 d1de2000000 204 norm[IWAIT] irq6: fdc0 29 c26156e0 d1de3000000 204 new [IWAIT] irq3: sio1 28 c2615898 d1de4000000 204 new [IWAIT] irq4: sio0 27 c0f071b8 cd395000000 204 new [IWAIT] swi0: tty:sio 26 c0f07370 cd396000000 204 new [IWAIT] irq12: psm0 25 c0f07528 cd397000000 204 norm[CPU 0] irq1: atkbd0 24 c0f076e0 cd398000000 204 norm[RUNQ] irq5: pcm0 23 c0f07898 cd399000000 204 norm[IWAIT] irq15: ata1 22 c0f07a50 cd39a000000 204 norm[IWAIT] irq14: ata0 3 c0f07c08 cd39b000000 204 norm[CVQ cbb cv c25e074c][SLP] cbb1 2 c0f07dc0 cd39c000000 204 norm[CVQ cbb cv c25e014c][SLP] cbb0 21 c25dd000 cdd7e000000 204 new [IWAIT] irq11: cbb0 cbb1+ 20 c25dd1b8 cdd84000000 204 norm[SLPQ nothing c042473c][SLP] acpi_thermal 19 c25dd370 cdd85000000 204 norm[IWAIT] irq9: acpi0 18 c0f0 cd319000000 204 new [IWAIT] irq13: 17 c0f001b8 cd38c000000 204 new [IWAIT] swi5: task queue 16 c0f00370 cd38d000000 204 norm[IWAIT] swi5: acpitaskq 15 c0f00528 cd38e000000 204 norm[SLPQ sleep c03e1aa0][SLP] random 14 c0f006e0 cd38f000000 204 new [IWAIT] swi1: net 13 c0f00898 cd39000 204 new [IWAIT] swi4: vm 12 c0f00a50 cd391000000 20c norm[IWAIT] swi6: tty:sio clock 11 c0f00c08 cd392000000 20c norm[Can run] idle 1 c0f00dc0 cd393000000 0004200 norm[RUNQ] init 10 c0f07000 cd394000000 204 norm[CVQ ktrace c02d7c44][SLP] ktrace 0 c02b2780 c0453000000 200 norm[SLPQ sched c02b2780][SLP] swapper -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
Dan, From: Dan Nelson In the last episode (Oct 06), Robert Watson said: On Sun, 6 Oct 2002, Seth Hieronymus wrote: Thanks for the pointers. Here's the trace 1: mi_switch(c0bb9988,14,c01bbe60,c0bb98f0,1) at mi_switch+0x290 msleep(c03778a0,0,68,c03153d7,14) at msleep+0x477 g_waitidle(1,c0314e10,c18f2885,c031bd64,c0b8dc20) at g_waitidle+0x8b g_dev_clone(0,c18f2885,6,c879cc08,c0bb6d80) at g_dev_clone+0x37 getdiskbyname(c18f2880,c879cc80,c0202f87,c18f2880,c18f2880) at getdiskbyname+0xa2 setrootbyname(c18f2880,c18f2880,c879cc48,c18f2880,20302020) at setrootbyname+0x11 vfs_mountroot_try(c1867220,c01912e0,c0bb8dc0,c879cd0c,c019134b) at vfs_mountroot_try+0x127 vfs_mountroot(c034b1c0,1,c0316bc7,216,203a2065) at vfs_mountroot+0x70 start_init(0,c879cd48,c031790b,34d,726f772d) at start_init+0x6b fork_exit(c01912e0,0,c879cd48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a This sounds identical (modulo geom details) to the la-la land my boxes were going off into. As I said, I never really followed up, but it looked like one of the i/o/device transactions during the root mount was getting lost, and as a result the init thread was never waking up. I'll probably have to let someone with more i/o clue take it from here. I'm not at the machine right now, but I noticed that my work machine would hang for a long time ( 5 minutes) on bootup, then continue. I finally figured out what the problem was: it has two SCSI cdrom drives, and geom apparently needed to get info on the disks for some reason. Neither drive had a CD in it, and it had to time out a read request on both drives before it would boot. Try sticking a data CD in your cdrom and see if the hang goes away. You were right. After trying both a CD, and a zip-disk in the computer (both together, and separately), having a zip-disk in the drive seems to allow the boot to continue normally. Thanks all, Seth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
In message [EMAIL PROTECTED], Seth Hieronymus writes: Hello, After recompiling a kernel after the GEOM transition, my boot gets as far as: Initializing GEOMetry subsystem ad0: 28629MB ST330630A [58168/16/63] at ata0-master UDMA33 acd0: CDROM Lite-On LTN483S 48x Max at ata1-master PIO4 afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 Mounting root from ufs:/dev/ad0s1a and hangs -- only a physical reset works. However, breaking into the debugger, and running a trace, I get (hand-copied): I suspect that the afd0 may be involved, can you try to disconnect it and see if that solves the problem ? -- 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: My problems with GEOM
In message [EMAIL PROTECTED], Seth Hieronymus writes: You were right. After trying both a CD, and a zip-disk in the computer (both together, and separately), having a zip-disk in the drive seems to allow the boot to continue normally. ATA(PI) or SCSI interface ZIP ? -- 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
