Date: Thu, 9 Dec 2004 14:52:14 +0100 From: Michael Schuh <michael.schuh@gmail.com> To: freebsd-stable@freebsd.org Subject: Re:SOLVVED vinum crashes the Box... WRONG POSTING Message-ID: <1dbad31504120905523c64367e@mail.gmail.com> In-Reply-To: <20041209021125.5233216A50C@hub.freebsd.org> References: <20041209021125.5233216A50C@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, sorry for my wrong posting, it was late at night and i have *not* doublechecked my configuration. Sorry for the Trouble. Greetings michael On Thu, 9 Dec 2004 02:11:25 +0000 (GMT), freebsd-stable-request@freebsd.org <freebsd-stable-request@freebsd.org> wrote: > Send freebsd-stable mailing list submissions to > freebsd-stable@freebsd.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > or, via email, send a message with subject or body 'help' to > freebsd-stable-request@freebsd.org >=20 > You can reach the person managing the list at > freebsd-stable-owner@freebsd.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-stable digest..." >=20 > Today's Topics: >=20 > 1. Re: crashdumps not working (Michael Nottebrock) > 2. Re: crashdumps not working (Michael Nottebrock) > 3. vinum crashes the Box by using more then ten disks on > RELENG_4 (Michael Schuh) > 4. Re: crashdumps not working (Robert Watson) > 5. Re: crashdumps not working (Michael Nottebrock) > 6. vinum crashes by using more then 11 disks on RELENG_4 > (Michael Schuh) > 7. Re: crashdumps not working (Michael Nottebrock) > 8. Re: crashdumps not working (Michael Nottebrock) > 9. devfs rules (Ivan Voras) > 10. Re: devfs rules (Ivan Voras) > 11. Re: devfs rules (Michael Nottebrock) > 12. Re: devfs rules (Frank Mayhar) > 13. Re: devfs rules (Frank Mayhar) > 14. Re: crashdumps not working (David Gilbert) > 15. Re: devfs rules (Ivan Voras) > 16. Re: trouble installing 5.3 on soekris net4801 (Lapo Nustrini) > 17. Re: crashdumps not working (Robert Watson) > 18. no internet after build world-kern install (whitevamp) > 19. ULE scheduler broken and not documented (Nuno Teixeira) > 20. Re: ULE scheduler broken and not documented (Ceri Davies) > 21. 5.3R crashing repeateadly (Crist?v?o Dalla Costa) > 22. Re: 5.3R crashing repeateadly (Brooks Davis) > 23. Re: trouble installing 5.3 on soekris net4801 (Crucio) > 24. Re: ULE scheduler broken and not documented (Donald J. O'Neill) > 25. Re: 5.3R crashing repeateadly (Crist?v?o Dalla Costa) > 26. Re: 5.3R crashing repeateadly (Mike Tancsa) > 27. More WRITE_DMA problems on 5.3 (Rob) > 28. Re: crashdumps not working (Greg 'groggy' Lehey) >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Wed, 8 Dec 2004 13:16:46 +0100 > From: Michael Nottebrock <michaelnottebrock@gmx.net> > Subject: Re: crashdumps not working > To: Robert Watson <rwatson@freebsd.org> > Cc: freebsd-stable@freebsd.org > Message-ID: <200412081316.50578.michaelnottebrock@gmx.net> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > On Wednesday, 8. December 2004 12:54, Robert Watson wrote: > > On Wed, 8 Dec 2004, Michael Nottebrock wrote: > > > On Wednesday, 8. December 2004 12:20, Robert Watson wrote: > > > > On Tue, 7 Dec 2004, Michael Nottebrock wrote: > > > > > I recently enabled SW_WATCHDOG in my kernel, but when watchdog > > > > > triggers a panic, no crashdump is taken although dumps are enable= d. > > > > > What could be causing this? > > > > > > > > If you drop to the debugger by using the debug.kdb.enter sysctl, an= d do > > > > "call doadump", followed by a reset, does a dump get generated > > > > successfully? > > > > > > I don't have kdb enabled in my kernel configuration at all... > > > > I'm guessing it might be useful at this point, if possible :-). >=20 > Useful for what exactly? I'm mainly interested in getting this machine to > auto-reboot after a (watchdog-triggered) panic, crashdumps are a bonus. A= t > the moment, it will just hang on a panic (even if I do not enable crashdu= mps > in rc.conf, it won't reset), and since it's usually running X, it will ju= st > stand there while the CRTs burn in. If you think you can get a clue as to= why > it wouldn't crashdump or reset by something I can do in kdb, I will enabl= e > it ... >=20 > > Do you > > have a serial console on the box, or could you set one up? >=20 > Nope, this is the only machine with a keyboard and a monitor attached. >=20 > > > > > > I.e., are they completely broken on your system, or is this > > > > somehow a property of the particular hang you're seeing. > > > > > > See my other mail, a different (non-watchdog) panic didn't trigger a = dump > > > either. I even had the panic message in dmesg: > > > > > > kernel trap 12 with interrupts disabled > > > > > > Fatal trap 12: page fault while in kernel mode > > > fault virtual address =3D 0x14c > > > fault code =3D supervisor write, page not present > > > instruction pointer =3D 0x8:0xc0521397 > > > stack pointer =3D 0x10:0xe9794b84 > > > frame pointer =3D 0x10:0xe9794b90 > > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > > =3D DPL 0, pres 1, def32 1, gran 1 > > > processor eflags =3D resume, IOPL =3D 0 > > > current process =3D 1281 (beep-media-player) > > > trap number =3D 12 > > > panic: page fault > > > > This is a NULL pointer dereference; you can use addr2line or gdb on you= r > > kernel.debug to turn it into a line number even without a core. That > > might well be worth doing, as we might be able to debug that even witho= ut > > getting dumping working on the box. >=20 > It's a SCHED_ULE + PREEMPTION triggered panic, probably there's no point = in > investigating it at this point, as _ULE has been demoted to abandonware := -(. >=20 > > Syncing on panic is, in general, probably not going to make it work bet= ter > > than not. I guess there's no chance the box has an NMI button? >=20 > Right. I just enabled it for the SW_WATCHDOG experiments (which made me > discover that this machine would just get stuck on panics in the first > place), I already turned it off again. >=20 > -- > ,_, | Michael Nottebrock | lofi@freebsd.org > (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org > \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20041= 208/0f3ca746/attachment-0001.bin >=20 > ------------------------------ >=20 > Message: 2 > Date: Wed, 8 Dec 2004 13:19:09 +0100 > From: Michael Nottebrock <michaelnottebrock@gmx.net> > Subject: Re: crashdumps not working > To: Robert Watson <rwatson@freebsd.org> > Cc: freebsd-stable@freebsd.org > Message-ID: <200412081319.10357.michaelnottebrock@gmx.net> > Content-Type: text/plain; charset=3D"iso-8859-15" >=20 > On Wednesday, 8. December 2004 13:16, Michael Nottebrock wrote: >=20 > > > > panic: page fault > > > > > > This is a NULL pointer dereference; you can use addr2line or gdb on y= our > > > kernel.debug to turn it into a line number even without a core. That > > > might well be worth doing, as we might be able to debug that even wit= hout > > > getting dumping working on the box. > > > > It's a SCHED_ULE + PREEMPTION triggered panic, probably there's no poin= t in > > investigating it at this point, as _ULE has been demoted to abandonware > > :-(. >=20 > N.B., I'm running now SCHED_4BSD again. >=20 > -- > ,_, | Michael Nottebrock | lofi@freebsd.org > (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org > \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20041= 208/a7df61b9/attachment-0001.bin >=20 > ------------------------------ >=20 > Message: 3 > Date: Wed, 8 Dec 2004 13:25:42 +0100 > From: Michael Schuh <michael.schuh@gmail.com> > Subject: vinum crashes the Box by using more then ten disks on > RELENG_4 > To: freebsd-stable@freebsd.org > Message-ID: <1dbad31504120804251d841790@mail.gmail.com> > Content-Type: text/plain; charset=3DUS-ASCII >=20 > Hi, >=20 > Ihas following System dmesg: >=20 > Copyright (c) 1992-2004 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1= 994 > The Regents of the University of California. All rights reserv= ed. > FreeBSD 4.10-STABLE #1: Tue Nov 30 14:26:29 CET 2004 > root@pdc.sarcom.de:/usr/obj/usr/src/sys/MYGENERIC > Timecounter "i8254" frequency 1193182 Hz > CPU: Intel Pentium III (993.33-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0x686 Stepping =3D 6 > Features=3D0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MT= RR,PGE,MCA,CM > OV,PAT,PSE36,MMX,FXSR,SSE> > real memory =3D 1342169088 (1310712K bytes) > config> en apm0 > config> q > avail memory =3D 1299566592 (1269108K bytes) > Changing APIC ID for IO APIC #0 from 0 to 2 on chip > Changing APIC ID for IO APIC #1 from 0 to 3 on chip > Programming 16 pins in IOAPIC #0 > Programming 16 pins in IOAPIC #1 > FreeBSD/SMP: Multiprocessor motherboard: 2 CPUs > cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 > cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 > io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 > io1 (APIC): apic id: 3, version: 0x000f0011, at 0xfec01000 > Preloaded elf kernel "kernel" at 0xc0564000. > Preloaded userconfig_script "/boot/kernel.conf" at 0xc056409c. > Pentium Pro MTRR support enabled > md0: Malloc disk > Using $PIR table, 11 entries at 0xc00fc320 > npx0: <math processor> on motherboard > npx0: INT 16 interface > pcib0: <ServerWorks NB6635 3.0LE host to PCI bridge> on motherboard > IOAPIC #1 intpin 15 -> irq 2 > IOAPIC #1 intpin 1 -> irq 10 > IOAPIC #1 intpin 0 -> irq 11 > pci0: <PCI bus> on pcib0 > pcib1: <PCI to PCI bridge (vendor=3D8086 device=3D0962)> at device 2.= 0 on pci0 > IOAPIC #1 intpin 14 -> irq 13 > pci1: <PCI bus> on pcib1 > ahc0: <Adaptec aic7880 Ultra SCSI adapter> port 0xfc00-0xfcff mem > 0xfcfff000-0xf > cffffff irq 13 at device 6.0 on pci1 > ahc0: <Adaptec aic7880 Ultra SCSI adapter> port 0xfc00-0xfcff mem 0xfcfff= 000-0xf > cffffff irq 13 at device 6.0 on pci1 > aic7880: Ultra Single Channel A, SCSI Id=3D7, 16/253 SCBs > aac0: <Dell PERC 2/Si> mem 0xf4000000-0xf7ffffff irq 2 at device 2.1 = on pci0 > aac0: i960RX 100MHz, 54MB cache memory, no battery support > aac0: Kernel 2.8-0, Build 6089, S/N c10d0 > aac0: Supported Options=3D2558<DATA64,HOSTTIME,WINDOW4GB,SOFTERR,SGMA= P64> > xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xec80-0xecff mem > 0xfe103000-0xfe10 > 307f irq 10 at device 4.0 on pci0 > xl0: Ethernet address: 00:10:5a:d0:09:69 > miibus0: <MII bus> on xl0 > xlphy0: <3Com internal media interface> on miibus0 > xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: <Intel 82559 Pro/100 Ethernet> port 0xec40-0xec7f mem > 0xfe000000-0xfe0ffff > f,0xfe102000-0xfe102fff irq 11 at device 8.0 on pci0 > fxp0: Ethernet address 00:b0:d0:ab:58:dd > inphy0: <i82555 10/100 media interface> on miibus1 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > pci0: <ATI model 4759 graphics accelerator> at 14.0 > isab0: <ServerWorks IB6566 PCI to ISA bridge> at device 15.0 on pci0 > isa0: <ISA bus> on isab0 > ohci0: <OHCI (generic) USB controller> mem 0xfe100000-0xfe100fff > irq 5 at device > 15.2 on pci0 > usb0: OHCI version 1.0, legacy support > usb0: <OHCI (generic) USB controller> on ohci0 > usb0: USB revision 1.0 > uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > pcib2: <ServerWorks NB6635 3.0LE host to PCI bridge> on motherboard > IOAPIC #1 intpin 12 -> irq 14 > IOAPIC #1 intpin 8 -> irq 16 > IOAPIC #1 intpin 4 -> irq 17 > pci2: <PCI bus> on pcib2 > isp0: <Qlogic ISP 2200 PCI FC-AL Adapter> port 0xdc00-0xdcff mem > 0xef000000-0xef > 000fff irq 14 at device 6.0 on pci2 > xl1: <3Com 3c905B-TX Fast Etherlink XL> port 0xd880-0xd8ff mem > 0xef001400-0xef00 > 147f irq 16 at device 10.0 on pci2 > xl1: Ethernet address: 00:50:04:ed:af:2f > miibus2: <MII bus> on xl1 > xlphy1: <3Com internal media interface> on miibus2 > miibus2: <MII bus> on xl1 > xlphy1: <3Com internal media interface> on miibus2 > xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > xl2: <3Com 3c905B-TX Fast Etherlink XL> port 0xd800-0xd87f mem > 0xef001000-0xef00 > 107f irq 17 at device 14.0 on pci2 > xl2: Ethernet address: 00:50:04:53:9e:63 > miibus3: <MII bus> on xl2 > xlphy2: <3Com internal media interface> on miibus3 > xlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > orm0: <Option ROMs> at iomem 0xc0000-0xc7fff,0xc9000-0xccfff on isa0 > pmtimer0 on isa0 > fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on = isa0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > ata1 at port 0x170-0x177,0x376 irq 15 on isa0 > atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0 > atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0 > kbd0 at atkbd0 > psm0: <PS/2 Mouse> irq 12 on atkbdc0 > psm0: model Generic PS/2 mouse, device ID 0 > vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/8 bytes threshold > plip0: <PLIP network interface> on ppbus0 > lpt0: <Printer> on ppbus0 > lpt0: Interrupt-driven port > ppi0: <Parallel I/O> on ppbus0 > APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 > Waiting 15 seconds for SCSI devices to settle > aacd0: <RAID 0/1> on aac0 > aacd0: 17354MB (35542272 sectors) > SMP: AP CPU #1 Launched! > Mounting root from ufs:/dev/aacd0s1a > da0 at isp0 bus 0 target 0 lun 0 > da0: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da0: 100.000MB/s transfers, Tagged Queueing Enabled > da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da1 at isp0 bus 0 target 1 lun 0 > da1: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da1: 100.000MB/s transfers, Tagged Queueing Enabled > da1: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > cd0 at ahc0 bus 0 target 5 lun 0 > cd0: <NEC CD-ROM DRIVE:466 1.06> Removable CD-ROM SCSI-2 device > cd0: 20.000MB/s transfers (20.000MHz, offset 15) > cd0: Attempt to query device size failed: NOT READY, Medium not prese= nt > da2 at isp0 bus 0 target 2 lun 0 > da2: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da2: 100.000MB/s transfers, Tagged Queueing Enabled > da2: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da3 at isp0 bus 0 target 3 lun 0 > da3: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da3: 100.000MB/s transfers, Tagged Queueing Enabled > da3: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da4 at isp0 bus 0 target 4 lun 0 > da4: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da4: 100.000MB/s transfers, Tagged Queueing Enabled > da4: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da5 at isp0 bus 0 target 5 lun 0 > da5: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da5: 100.000MB/s transfers, Tagged Queueing Enabled > da5: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da6 at isp0 bus 0 target 6 lun 0 > da6: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da6: 100.000MB/s transfers, Tagged Queueing Enabled > da6: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da7 at isp0 bus 0 target 7 lun 0 > da7: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da7: 100.000MB/s transfers, Tagged Queueing Enabled > da7: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da8 at isp0 bus 0 target 8 lun 0 > da8: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da8: 100.000MB/s transfers, Tagged Queueing Enabled > da8: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da9 at isp0 bus 0 target 9 lun 0 > da9: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da9: 100.000MB/s transfers, Tagged Queueing Enabled > da9: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da10 at isp0 bus 0 target 10 lun 0 > da10: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da10: 100.000MB/s transfers, Tagged Queueing Enabled > da10: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da11 at isp0 bus 0 target 11 lun 0 > da11: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da11: 100.000MB/s transfers, Tagged Queueing Enabled > da11: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da12 at isp0 bus 0 target 12 lun 0 > da12: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da12: 100.000MB/s transfers, Tagged Queueing Enabled > da12: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da13 at isp0 bus 0 target 13 lun 0 > da13: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da13: 100.000MB/s transfers, Tagged Queueing Enabled > da13: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da14 at isp0 bus 0 target 14 lun 0 > da14: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da14: 100.000MB/s transfers, Tagged Queueing Enabled > da14: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da15 at isp0 bus 0 target 15 lun 0 > da15: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da15: 100.000MB/s transfers, Tagged Queueing Enabled > da15: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da16 at isp0 bus 0 target 16 lun 0 > da16: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da16: 100.000MB/s transfers, Tagged Queueing Enabled > da16: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da17 at isp0 bus 0 target 17 lun 0 > da17: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da17: 100.000MB/s transfers, Tagged Queueing Enabled > da17: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da18 at isp0 bus 0 target 18 lun 0 > da18: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da18: 100.000MB/s transfers, Tagged Queueing Enabled > da18: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da19 at isp0 bus 0 target 19 lun 0 > da19: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da19: 100.000MB/s transfers, Tagged Queueing Enabled > da19: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da20 at isp0 bus 0 target 20 lun 0 > da20: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da20: 100.000MB/s transfers, Tagged Queueing Enabled > da20: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da21 at isp0 bus 0 target 21 lun 0 > da21: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da21: 100.000MB/s transfers, Tagged Queueing Enabled > da21: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da22 at isp0 bus 0 target 22 lun 0 > da22: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da22: 100.000MB/s transfers, Tagged Queueing Enabled > da22: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da23 at isp0 bus 0 target 23 lun 0 > da23: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da23: 100.000MB/s transfers, Tagged Queueing Enabled > da23: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da24 at isp0 bus 0 target 24 lun 0 > da24: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da24: 100.000MB/s transfers, Tagged Queueing Enabled > da24: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da25 at isp0 bus 0 target 25 lun 0 > da25: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da25: 100.000MB/s transfers, Tagged Queueing Enabled > da25: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da26 at isp0 bus 0 target 26 lun 0 > da26: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da26: 100.000MB/s transfers, Tagged Queueing Enabled > da26: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da27 at isp0 bus 0 target 27 lun 0 > da27: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da27: 100.000MB/s transfers, Tagged Queueing Enabled > da27: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > WARNING: / was not properly dismounted > aac0: **Monitor** ID(0:01:0) Timeout detected on cmd[0x2a] > aac0: **Monitor** SCSI Channel[0]: Timeout Detected On 1 Command(s) >=20 > My vinum.conf > #first7 > drive disk0 device /dev/da0s1h > drive disk1 device /dev/da2s1h > drive disk2 device /dev/da4s1h > drive disk3 device /dev/da6s1h > drive disk4 device /dev/da8s1h > drive disk5 device /dev/da10s1h > drive disk6 device /dev/da12s1h > #next 7 > drive disk7 device /dev/da1s1h > drive disk8 device /dev/da3s1h > drive disk9 device /dev/da5s1h > drive disk10 device /dev/da7s1h > drive disk11 device /dev/da9s1h > drive disk12 device /dev/da11s1h > drive disk13 device /dev/da13s1h >=20 > volume big > plex name big.p0 org striped 512k > sd name big.p0.sd0 drive drive0 size 0 > sd name big.p0.sd1 drive drive1 size 0 > sd name big.p1.sd2 drive drive9 size 0 > sd name big.p1.sd3 drive drive10 size 0 > sd name big.p1.sd4 drive drive11 size 0 > sd name big.p1.sd5 drive drive12 size 0 > sd name big.p1.sd6 drive drive13 size 0 >=20 > With this configuration vinum crashes the Machine with this Message: > 15: drive disk12 device /dev/da11s1h > ** 15 : Invalid argument >=20 > If i let the last 4 disks out of my Configuration so vinum makes > all right. It sounds like vinum cannot right use more devices as 10 > da[0-9]s1h is ok > da[1-2][0-9]s1h is not. >=20 > Ah, my Target is to build a RAID10 Mirror of Stripes > might be a count problem? >=20 > Sorry thats are all error-messages that i can see. >=20 > thanks for your interest and help >=20 > michael >=20 > ------------------------------ >=20 > Message: 4 > Date: Wed, 8 Dec 2004 12:38:13 +0000 (GMT) > From: Robert Watson <rwatson@freebsd.org> > Subject: Re: crashdumps not working > To: Michael Nottebrock <michaelnottebrock@gmx.net> > Cc: freebsd-stable@freebsd.org > Message-ID: > <Pine.NEB.3.96L.1041208123155.98791J-100000@fledge.watson.org> > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII >=20 > On Wed, 8 Dec 2004, Michael Nottebrock wrote: >=20 > > > > I don't have kdb enabled in my kernel configuration at all... > > > > > > I'm guessing it might be useful at this point, if possible :-). > > > > Useful for what exactly? I'm mainly interested in getting this machine > > to auto-reboot after a (watchdog-triggered) panic, crashdumps are a > > bonus. At the moment, it will just hang on a panic (even if I do not > > enable crashdumps in rc.conf, it won't reset), and since it's usually > > running X, it will just stand there while the CRTs burn in. If you thin= k > > you can get a clue as to why it wouldn't crashdump or reset by somethin= g > > I can do in kdb, I will enable it ... >=20 > The primary goal in using KDB would be to see what parts of the crash, > dump, and reset work separately. For example, by entering KDB using the > sysctl, we can see if dumps work on your system when not in a potentially > sticky situation (i.e., not in an interrupt handler, or with interrupts > disabled, after a controller wedge, or the like). So I'm thinking it > would be nice to know: >=20 > - Can you enter and continue from kdb normally using the sysctl. > - If you can enter kdb using the sysctl, does "call doadump()" work from > kdb? > - If you can enter kdb using the sysctl, oes "reset" work from kdb? >=20 > I.e., do the individual elements work from the debugger. If they do, the= n > we can try the same from entering the debugger following the panic, and > see how things differ. >=20 > > > This is a NULL pointer dereference; you can use addr2line or gdb on y= our > > > kernel.debug to turn it into a line number even without a core. That > > > might well be worth doing, as we might be able to debug that even wit= hout > > > getting dumping working on the box. > > > > It's a SCHED_ULE + PREEMPTION triggered panic, probably there's no poin= t > > in investigating it at this point, as _ULE has been demoted to > > abandonware :-(. >=20 > ULE is temporarily without an owner, but Jeff and others have expressed > interest in working on it further. I'd not run it for the time being, bu= t > it's probably not a hopeless case. Does the above statement mean that th= e > hangs or panics you are experiencing don't happen at all if you just use > 4BSD? >=20 > > > Syncing on panic is, in general, probably not going to make it work b= etter > > > than not. I guess there's no chance the box has an NMI button? > > > > Right. I just enabled it for the SW_WATCHDOG experiments (which made me > > discover that this machine would just get stuck on panics in the first > > place), I already turned it off again. >=20 > Thanks. Just trying to keep track of and reduce the number of variables. >=20 > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Principal Research Scientist, McAfee Resear= ch >=20 > ------------------------------ >=20 > Message: 5 > Date: Wed, 8 Dec 2004 14:28:06 +0100 > From: Michael Nottebrock <michaelnottebrock@gmx.net> > Subject: Re: crashdumps not working > To: Robert Watson <rwatson@freebsd.org> > Cc: freebsd-stable@freebsd.org > Message-ID: <200412081428.10224.michaelnottebrock@gmx.net> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > On Wednesday, 8. December 2004 13:38, Robert Watson wrote: > > ULE is temporarily without an owner, but Jeff and others have expressed > > interest in working on it further. I'd not run it for the time being, = but > > it's probably not a hopeless case. Does the above statement mean that = the > > hangs or panics you are experiencing don't happen at all if you just us= e > > 4BSD? >=20 > Oh, the 'hangs' (and the reason I turned on SW_WATCHDOG) are caused by me > experimenting with somewhat volatile stuff (broken software running at > realtime priority, that sort of thing), they're perfectly expected. The p= anic > there with ULE was a one off that happened when I turned on ULE & PREEMPT= ION > to test if the warning about ULE being unstable with PREEMPTION tells the > truth... sure does. :-) >=20 > I'm going to enable the kernel debugger now... Thanks for the help btw! >=20 > -- > ,_, | Michael Nottebrock | lofi@freebsd.org > (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org > \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20041= 208/becd8b3c/attachment-0001.bin >=20 > ------------------------------ >=20 > Message: 6 > Date: Tue, 7 Dec 2004 19:19:58 +0100 > From: Michael Schuh <michael.schuh@gmail.com> > Subject: vinum crashes by using more then 11 disks on RELENG_4 > To: freebsd-stable@freebsd.org, groggy@freebsd.org > Message-ID: <1dbad315041207101974a33e86@mail.gmail.com> > Content-Type: text/plain; charset=3DUS-ASCII >=20 > Hi, >=20 > Ihas following System dmesg: >=20 > Copyright (c) 1992-2004 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 4.10-STABLE #1: Tue Nov 30 14:26:29 CET 2004 > root@pdc.sarcom.de:/usr/obj/usr/src/sys/MYGENERIC > Timecounter "i8254" frequency 1193182 Hz > CPU: Intel Pentium III (993.33-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0x686 Stepping =3D 6 > Features=3D0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,P= GE,MCA,CM > OV,PAT,PSE36,MMX,FXSR,SSE> > real memory =3D 1342169088 (1310712K bytes) > config> en apm0 > config> q > avail memory =3D 1299566592 (1269108K bytes) > Changing APIC ID for IO APIC #0 from 0 to 2 on chip > Changing APIC ID for IO APIC #1 from 0 to 3 on chip > Programming 16 pins in IOAPIC #0 > Programming 16 pins in IOAPIC #1 > FreeBSD/SMP: Multiprocessor motherboard: 2 CPUs > cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 > cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 > io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 > io1 (APIC): apic id: 3, version: 0x000f0011, at 0xfec01000 > Preloaded elf kernel "kernel" at 0xc0564000. > Preloaded userconfig_script "/boot/kernel.conf" at 0xc056409c. > Pentium Pro MTRR support enabled > md0: Malloc disk > Using $PIR table, 11 entries at 0xc00fc320 > npx0: <math processor> on motherboard > npx0: INT 16 interface > pcib0: <ServerWorks NB6635 3.0LE host to PCI bridge> on motherboard > IOAPIC #1 intpin 15 -> irq 2 > IOAPIC #1 intpin 1 -> irq 10 > IOAPIC #1 intpin 0 -> irq 11 > pci0: <PCI bus> on pcib0 > pcib1: <PCI to PCI bridge (vendor=3D8086 device=3D0962)> at device 2.0 on= pci0 > IOAPIC #1 intpin 14 -> irq 13 > pci1: <PCI bus> on pcib1 > ahc0: <Adaptec aic7880 Ultra SCSI adapter> port 0xfc00-0xfcff mem 0xfcfff= 000-0xf > cffffff irq 13 at device 6.0 on pci1 > aic7880: Ultra Single Channel A, SCSI Id=3D7, 16/253 SCBs > aac0: <Dell PERC 2/Si> mem 0xf4000000-0xf7ffffff irq 2 at device 2.1 on p= ci0 > aac0: i960RX 100MHz, 54MB cache memory, no battery support > aac0: Kernel 2.8-0, Build 6089, S/N c10d0 > aac0: Supported Options=3D2558<DATA64,HOSTTIME,WINDOW4GB,SOFTERR,SGMAP64> > xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xec80-0xecff mem 0xfe103000= -0xfe10 > 307f irq 10 at device 4.0 on pci0 > xl0: Ethernet address: 00:10:5a:d0:09:69 > miibus0: <MII bus> on xl0 > xlphy0: <3Com internal media interface> on miibus0 > xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: <Intel 82559 Pro/100 Ethernet> port 0xec40-0xec7f mem 0xfe000000-0x= fe0ffff > f,0xfe102000-0xfe102fff irq 11 at device 8.0 on pci0 > fxp0: Ethernet address 00:b0:d0:ab:58:dd > inphy0: <i82555 10/100 media interface> on miibus1 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > pci0: <ATI model 4759 graphics accelerator> at 14.0 > isab0: <ServerWorks IB6566 PCI to ISA bridge> at device 15.0 on pci0 > isa0: <ISA bus> on isab0 > ohci0: <OHCI (generic) USB controller> mem 0xfe100000-0xfe100fff irq 5 at= device > 15.2 on pci0 > usb0: OHCI version 1.0, legacy support > usb0: <OHCI (generic) USB controller> on ohci0 > usb0: USB revision 1.0 > uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > pcib2: <ServerWorks NB6635 3.0LE host to PCI bridge> on motherboard > IOAPIC #1 intpin 12 -> irq 14 > IOAPIC #1 intpin 8 -> irq 16 > IOAPIC #1 intpin 4 -> irq 17 > pci2: <PCI bus> on pcib2 > isp0: <Qlogic ISP 2200 PCI FC-AL Adapter> port 0xdc00-0xdcff mem 0xef0000= 00-0xef > 000fff irq 14 at device 6.0 on pci2 > xl1: <3Com 3c905B-TX Fast Etherlink XL> port 0xd880-0xd8ff mem 0xef001400= -0xef00 > 147f irq 16 at device 10.0 on pci2 > xl1: Ethernet address: 00:50:04:ed:af:2f > miibus2: <MII bus> on xl1 > xlphy1: <3Com internal media interface> on miibus2 > xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > xl2: <3Com 3c905B-TX Fast Etherlink XL> port 0xd800-0xd87f mem 0xef001000= -0xef00 > 107f irq 17 at device 14.0 on pci2 > xl2: Ethernet address: 00:50:04:53:9e:63 > miibus3: <MII bus> on xl2 > xlphy2: <3Com internal media interface> on miibus3 > xlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > orm0: <Option ROMs> at iomem 0xc0000-0xc7fff,0xc9000-0xccfff on isa0 > pmtimer0 on isa0 > fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > ata1 at port 0x170-0x177,0x376 irq 15 on isa0 > atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0 > atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0 > kbd0 at atkbd0 > psm0: <PS/2 Mouse> irq 12 on atkbdc0 > psm0: model Generic PS/2 mouse, device ID 0 > vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > sc0: <System console> at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/8 bytes threshold > plip0: <PLIP network interface> on ppbus0 > lpt0: <Printer> on ppbus0 > lpt0: Interrupt-driven port > ppi0: <Parallel I/O> on ppbus0 > APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 > Waiting 15 seconds for SCSI devices to settle > aacd0: <RAID 0/1> on aac0 > aacd0: 17354MB (35542272 sectors) > SMP: AP CPU #1 Launched! > Mounting root from ufs:/dev/aacd0s1a > da0 at isp0 bus 0 target 0 lun 0 > da0: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da0: 100.000MB/s transfers, Tagged Queueing Enabled > da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da1 at isp0 bus 0 target 1 lun 0 > da1: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da1: 100.000MB/s transfers, Tagged Queueing Enabled > da1: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > cd0 at ahc0 bus 0 target 5 lun 0 > cd0: <NEC CD-ROM DRIVE:466 1.06> Removable CD-ROM SCSI-2 device > cd0: 20.000MB/s transfers (20.000MHz, offset 15) > cd0: Attempt to query device size failed: NOT READY, Medium not present > da2 at isp0 bus 0 target 2 lun 0 > da2: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da2: 100.000MB/s transfers, Tagged Queueing Enabled > da2: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da3 at isp0 bus 0 target 3 lun 0 > da3: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da3: 100.000MB/s transfers, Tagged Queueing Enabled > da3: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da4 at isp0 bus 0 target 4 lun 0 > da4: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da4: 100.000MB/s transfers, Tagged Queueing Enabled > da4: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da5 at isp0 bus 0 target 5 lun 0 > da5: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da5: 100.000MB/s transfers, Tagged Queueing Enabled > da5: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da6 at isp0 bus 0 target 6 lun 0 > da6: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da6: 100.000MB/s transfers, Tagged Queueing Enabled > da6: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da7 at isp0 bus 0 target 7 lun 0 > da7: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da7: 100.000MB/s transfers, Tagged Queueing Enabled > da7: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da8 at isp0 bus 0 target 8 lun 0 > da8: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da8: 100.000MB/s transfers, Tagged Queueing Enabled > da8: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da9 at isp0 bus 0 target 9 lun 0 > da9: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da9: 100.000MB/s transfers, Tagged Queueing Enabled > da9: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da10 at isp0 bus 0 target 10 lun 0 > da10: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da10: 100.000MB/s transfers, Tagged Queueing Enabled > da10: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da11 at isp0 bus 0 target 11 lun 0 > da11: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da11: 100.000MB/s transfers, Tagged Queueing Enabled > da11: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da12 at isp0 bus 0 target 12 lun 0 > da12: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da12: 100.000MB/s transfers, Tagged Queueing Enabled > da12: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da13 at isp0 bus 0 target 13 lun 0 > da13: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da13: 100.000MB/s transfers, Tagged Queueing Enabled > da13: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da14 at isp0 bus 0 target 14 lun 0 > da14: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da14: 100.000MB/s transfers, Tagged Queueing Enabled > da14: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da15 at isp0 bus 0 target 15 lun 0 > da15: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da15: 100.000MB/s transfers, Tagged Queueing Enabled > da15: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da16 at isp0 bus 0 target 16 lun 0 > da16: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da16: 100.000MB/s transfers, Tagged Queueing Enabled > da16: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da17 at isp0 bus 0 target 17 lun 0 > da17: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da17: 100.000MB/s transfers, Tagged Queueing Enabled > da17: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da18 at isp0 bus 0 target 18 lun 0 > da18: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da18: 100.000MB/s transfers, Tagged Queueing Enabled > da18: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da19 at isp0 bus 0 target 19 lun 0 > da19: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da19: 100.000MB/s transfers, Tagged Queueing Enabled > da19: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da20 at isp0 bus 0 target 20 lun 0 > da20: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da20: 100.000MB/s transfers, Tagged Queueing Enabled > da20: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da21 at isp0 bus 0 target 21 lun 0 > da21: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da21: 100.000MB/s transfers, Tagged Queueing Enabled > da21: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da22 at isp0 bus 0 target 22 lun 0 > da22: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da22: 100.000MB/s transfers, Tagged Queueing Enabled > da22: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da23 at isp0 bus 0 target 23 lun 0 > da23: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da23: 100.000MB/s transfers, Tagged Queueing Enabled > da23: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da24 at isp0 bus 0 target 24 lun 0 > da24: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da24: 100.000MB/s transfers, Tagged Queueing Enabled > da24: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da25 at isp0 bus 0 target 25 lun 0 > da25: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da25: 100.000MB/s transfers, Tagged Queueing Enabled > da25: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da26 at isp0 bus 0 target 26 lun 0 > da26: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da26: 100.000MB/s transfers, Tagged Queueing Enabled > da26: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da27 at isp0 bus 0 target 27 lun 0 > da27: <SEAGATE ST336704FC FA55> Fixed Direct Access SCSI-3 device > da27: 100.000MB/s transfers, Tagged Queueing Enabled > da27: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > WARNING: / was not properly dismounted > aac0: **Monitor** ID(0:01:0) Timeout detected on cmd[0x2a] > aac0: **Monitor** SCSI Channel[0]: Timeout Detected On 1 Command(s) >=20 > My vinum.conf > #first7 > drive disk0 device /dev/da0s1h > drive disk1 device /dev/da2s1h > drive disk2 device /dev/da4s1h > drive disk3 device /dev/da6s1h > drive disk4 device /dev/da8s1h > drive disk5 device /dev/da10s1h > drive disk6 device /dev/da12s1h > #next 7 > drive disk7 device /dev/da1s1h > drive disk8 device /dev/da3s1h > drive disk9 device /dev/da5s1h > drive disk10 device /dev/da7s1h > drive disk11 device /dev/da9s1h > drive disk12 device /dev/da11s1h > drive disk13 device /dev/da13s1h >=20 > volume big > plex name big.p0 org striped 512k > sd name big.p0.sd0 drive drive0 size 0 > sd name big.p0.sd1 drive drive1 size 0 > sd name big.p0.sd2 drive drive2 size 0 > sd name big.p0.sd3 drive drive3 size 0 > sd name big.p0.sd4 drive drive4 size 0 > sd name big.p0.sd5 drive drive5 size 0 > sd name big.p0.sd6 drive drive6 size 0 > plex name big.p1 org striped 512k > sd name big.p1.sd0 drive drive7 size 0 > sd name big.p1.sd1 drive drive8 size 0 > sd name big.p1.sd2 drive drive9 size 0 > sd name big.p1.sd3 drive drive10 size 0 > sd name big.p1.sd4 drive drive11 size 0 > sd name big.p1.sd5 drive drive12 size 0 > sd name big.p1.sd6 drive drive13 size 0 >=20 > With this configuration vinum crashes the Machine with this Message: > 15: drive disk12 device /dev/da11s1h > ** 15 : Invalid argument >=20 > If i let the last 4 disks out of my Configuration so vinum makes > all right. It sounds like vinum cannot right use more devices as 10 > da[0-9]s1h is ok > da[1-2][0-9]s1h is not. >=20 > Ah, my Target is to build a RAID10 Mirror of Stripes >=20 > might be a count problem? >=20 > Sorry thats are all error-messages that i can see. >=20 > thanks for your interest and help >=20 > ------------------------------ >=20 > Message: 7 > Date: Wed, 8 Dec 2004 15:47:11 +0100 > From: Michael Nottebrock <michaelnottebrock@gmx.net> > Subject: Re: crashdumps not working > To: Robert Watson <rwatson@freebsd.org> > Cc: freebsd-stable@freebsd.org > Message-ID: <200412081547.14882.michaelnottebrock@gmx.net> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > On Wednesday, 8. December 2004 13:38, Robert Watson wrote: >=20 > Okay, I've now enabled the following in the kernel: >=20 > options KDB > options KDB_TRACE > options DDB >=20 > > So I'm thinking it > > would be nice to know: > > > > - Can you enter and continue from kdb normally using the sysctl. >=20 > Yes. >=20 > > - If you can enter kdb using the sysctl, does "call doadump()" work fro= m > > kdb? >=20 > Yes. >=20 > > - If you can enter kdb using the sysctl, oes "reset" work from kdb? >=20 > Yes. >=20 > > I.e., do the individual elements work from the debugger. If they do, t= hen > > we can try the same from entering the debugger following the panic, and > > see how things differ. >=20 > All of the above works when entering the debugger from the watchdog timeo= ut, > too. :-\ >=20 > -- > ,_, | Michael Nottebrock | lofi@freebsd.org > (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org > \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org >=20 > ------------------------------ >=20 > Message: 8 > Date: Wed, 8 Dec 2004 16:56:03 +0100 > From: Michael Nottebrock <michaelnottebrock@gmx.net> > Subject: Re: crashdumps not working > To: Robert Watson <rwatson@freebsd.org> > Cc: freebsd-stable@freebsd.org > Message-ID: <200412081656.07944.michaelnottebrock@gmx.net> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > I played around with the kernel debug options a little and found peculiar > things: >=20 > - With just options KDB (and no debugger backend specified), a panic will= just > cause some output scroll very fast on the console - perhaps kdb is trying= to > enter a nonexisting debugger backend and loops? >=20 > - With options KDB, KDB_UNATTENDED and DDB, a panic _does_ trigger DDB, > contrary to what the description of KDB_UNATTENDED says. >=20 > It seems to me 5.3's debugging facilities are somewhat in disarray... >=20 > -- > ,_, | Michael Nottebrock | lofi@freebsd.org > (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org > \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20041= 208/2ba0f46a/attachment-0001.bin >=20 > ------------------------------ >=20 > Message: 9 > Date: Wed, 08 Dec 2004 17:55:13 +0100 > From: Ivan Voras <ivoras@fer.hr> > Subject: devfs rules > To: stable@freebsd.org > Message-ID: <41B731F1.5030108@fer.hr> > Content-Type: text/plain; charset=3DISO-8859-2; format=3Dflowed >=20 > Is there a canonical way of preserving devfs rules (device permissions > actually) across reboots? >=20 > It seems devd.conf works only for "static" devices, not hotplugged, > while devfs rules works for those, but they vanish on reboot. >=20 > ------------------------------ >=20 > Message: 10 > Date: Wed, 08 Dec 2004 18:05:03 +0100 > From: Ivan Voras <ivoras@fer.hr> > Subject: Re: devfs rules > To: stable@freebsd.org > Message-ID: <41B7343F.3040307@fer.hr> > Content-Type: text/plain; charset=3DISO-8859-2; format=3Dflowed >=20 > Ivan Voras wrote: > > Is there a canonical way of preserving devfs rules (device permissions > > actually) across reboots? > > > > It seems devd.conf works only for "static" devices, not hotplugged, > ^^^^^^^^^ > this should have been "devfs.conf" >=20 > > while devfs(8) rules work for those, but they vanish on reboot. >=20 > ------------------------------ >=20 > Message: 11 > Date: Wed, 8 Dec 2004 18:08:49 +0100 > From: Michael Nottebrock <michaelnottebrock@gmx.net> > Subject: Re: devfs rules > To: freebsd-stable@freebsd.org > Cc: Ivan Voras <ivoras@fer.hr> > Message-ID: <200412081808.54121.michaelnottebrock@gmx.net> > Content-Type: text/plain; charset=3D"iso-8859-2" >=20 > On Wednesday, 8. December 2004 17:55, Ivan Voras wrote: > > Is there a canonical way of preserving devfs rules (device permissions > > actually) across reboots? > > > > It seems devd.conf works only for "static" devices, not hotplugged, > > while devfs rules works for those, but they vanish on reboot. >=20 > You can put rules into /etc/devfs.rules, analog to devfs.conf (there's > an /etc/defaults/devfs.rules, too, although it isn't much of a > demonstration). I think somewhat more userfriendly documentation and exam= ples > for the whole devfs stuff is sorely missed not just by me... >=20 > -- > ,_, | Michael Nottebrock | lofi@freebsd.org > (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org > \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20041= 208/9a3d0b66/attachment-0001.bin >=20 > ------------------------------ >=20 > Message: 12 > Date: Wed, 8 Dec 2004 09:23:30 -0800 (PST) > From: Frank Mayhar <frank@exit.com> > Subject: Re: devfs rules > To: Ivan Voras <ivoras@fer.hr> > Cc: stable@freebsd.org > Message-ID: <200412081723.iB8HNUTY010290@realtime.exit.com> > Content-Type: text/plain; charset=3DUS-ASCII >=20 > Ivan Voras wrote: > [ Charset ISO-8859-2 unsupported, converting... ] > > Is there a canonical way of preserving devfs rules (device permissions > > actually) across reboots? >=20 > >cat /etc/devfs.rules > [devfsrules_local=3D15] > add path 'bpf*' mode 0660 > add path 'ugen*' mode 0664 > add path 'cd*' mode 0664 >=20 > For example. For some hints, 'man devfs' and /etc/defaults/devfs.rules. > -- > Frank Mayhar frank@exit.com http://www.exit.com/ > Exit Consulting http://www.gpsclock.com/ > http://www.exit.com/blog/frank/ >=20 > ------------------------------ >=20 > Message: 13 > Date: Wed, 8 Dec 2004 09:26:14 -0800 (PST) > From: Frank Mayhar <frank@exit.com> > Subject: Re: devfs rules > To: Ivan Voras <ivoras@fer.hr>, stable@freebsd.org > Message-ID: <200412081726.iB8HQE0C010362@realtime.exit.com> > Content-Type: text/plain; charset=3DUS-ASCII >=20 > Frank Mayhar wrote: > > Ivan Voras wrote: > > [ Charset ISO-8859-2 unsupported, converting... ] > > > Is there a canonical way of preserving devfs rules (device permission= s > > > actually) across reboots? > > > > >cat /etc/devfs.rules > > [devfsrules_local=3D15] > > add path 'bpf*' mode 0660 > > add path 'ugen*' mode 0664 > > add path 'cd*' mode 0664 > > > > For example. For some hints, 'man devfs' and /etc/defaults/devfs.rules= . >=20 > Oh, and for this example, don't forget to add > devfs_system_ruleset=3D"devfsrules_local" > to /etc/rc.conf. > -- > Frank Mayhar frank@exit.com http://www.exit.com/ > Exit Consulting http://www.gpsclock.com/ > http://www.exit.com/blog/frank/ >=20 > ------------------------------ >=20 > Message: 14 > Date: Wed, 8 Dec 2004 12:27:33 -0500 > From: David Gilbert <dgilbert@dclg.ca> > Subject: Re: crashdumps not working > To: Robert Watson <rwatson@freebsd.org> > Cc: freebsd-stable@freebsd.org > Message-ID: <16823.14725.330609.631687@canoe.dclg.ca> > Content-Type: text/plain; charset=3Dus-ascii >=20 > >>>>> "Robert" =3D=3D Robert Watson <rwatson@freebsd.org> writes: >=20 > Robert> This is a NULL pointer dereference; you can use addr2line or > Robert> gdb on your kernel.debug to turn it into a line number even > Robert> without a core. That might well be worth doing, as we might > Robert> be able to debug that even without getting dumping working on > Robert> the box. >=20 > If I had an address and a debug kernel, how is this done? >=20 > Dave. >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > |David Gilbert, Independent Contractor. | Two things can only be = | > |Mail: dave@daveg.ca | equal if and only if the= y | > |http://daveg.ca | are precisely opposite.= | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3DGLO=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > ------------------------------ >=20 > Message: 15 > Date: Wed, 08 Dec 2004 18:38:00 +0100 > From: Ivan Voras <ivoras@fer.hr> > Subject: Re: devfs rules > To: stable@freebsd.org > Message-ID: <41B73BF8.9090804@fer.hr> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > Frank Mayhar wrote: >=20 > >>>cat /etc/devfs.rules > >> > >>[devfsrules_local=3D15] > >>add path 'bpf*' mode 0660 > >>add path 'ugen*' mode 0664 > >>add path 'cd*' mode 0664 > >> > >>For example. For some hints, 'man devfs' and /etc/defaults/devfs.rules= . > > > > > > Oh, and for this example, don't forget to add > > devfs_system_ruleset=3D"devfsrules_local" > > to /etc/rc.conf. >=20 > Thanks, that's what I was looking for! :) >=20 > ------------------------------ >=20 > Message: 16 > Date: Wed, 8 Dec 2004 09:38:48 -0800 > From: Lapo Nustrini <lapo@seanet.com> > Subject: Re: trouble installing 5.3 on soekris net4801 > To: crucio2004-freebsd@yahoo.com > Cc: freebsd-stable@freebsd.org > Message-ID: <0447397A-4940-11D9-83D7-000A958CDFF6@seanet.com> > Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed >=20 > Have you tried booting up in safe mode? > I have a similar issue running 5.3 STABLE on a machine which runs fine > with 5.3 BETA7. >=20 > Booting into safe mode works fine. Any other way, and it gets ATAPI > errors or SCSI errors (if I take all ATAPI stuff out of the kernel). >=20 > Still trying to find the real source of the problem... >=20 > Good luck, >=20 > Lapo >=20 > On Dec 7, 2004, at 8:31 PM, Crucio wrote: >=20 > > I am unable to install FreeBSD 5.3-RELEASE on my > > Soekris net4801, which has a SanDisk Ultra II 512MB > > Compact Flash card as a hard drive. The kernel probes > > the drive just fine but when it comes time to write or > > read from the drive, specifically in sysinstall, I > > get; > > > > ad0: TIMEOUT - READ_DMA retrying (2 retries left) > > LBA=3D0 > > ad0: FAILURE - READ_DMA timed out > > ad0: TIMEOUT - READ_DMA retrying (2 retries left) > > LBA=3D0 > > ad0: FAILURE - READ_DMA timed out > > ad0: TIMEOUT - READ_DMA retrying (2 retries left) > > LBA=3D0 > > ad0: FAILURE - READ_DMA timed out > > ad0: TIMEOUT - READ_DMA retrying (2 retries left) > > LBA=3D1 > > ad0: FAILURE - READ_DMA timed out > > > > Then sysinstall says; > > > > "ERROR: Unable to write data to disk ad0!" > > > > To do this manually, with fdisk, disklabel and newfs > > works up until the computer has rebooted and tries to > > load the root filesystem. It hangs for a little while > > then starts spitting out those READ_DMA errors and > > finally refuses to mount ad0s1a as root. > > > > Disabling DMA in loader.conf doesn't seem to have any > > effect. > > > > Any ideas here would be much appreciated. > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > > "freebsd-stable-unsubscribe@freebsd.org" > > >=20 > ------------------------------ >=20 > Message: 17 > Date: Wed, 8 Dec 2004 18:12:12 +0000 (GMT) > From: Robert Watson <rwatson@freebsd.org> > Subject: Re: crashdumps not working > To: David Gilbert <dgilbert@dclg.ca> > Cc: freebsd-stable@freebsd.org > Message-ID: > <Pine.NEB.3.96L.1041208175120.98791T-100000@fledge.watson.org> > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII >=20 > On Wed, 8 Dec 2004, David Gilbert wrote: >=20 > > >>>>> "Robert" =3D=3D Robert Watson <rwatson@freebsd.org> writes: > > > > Robert> This is a NULL pointer dereference; you can use addr2line or > > Robert> gdb on your kernel.debug to turn it into a line number even > > Robert> without a core. That might well be worth doing, as we might > > Robert> be able to debug that even without getting dumping working on > > Robert> the box. > > > > If I had an address and a debug kernel, how is this done? >=20 > There are at least three ways you can do this, depending on the amount of > information you have, and what you're trying to find out. Suppose you ge= t > a fault and the trap shows the instruction pointer is 0xc052fb46. You ca= n > use: >=20 > (1) addr2line(1) converts an address and a executable with debugging > information to a line number. Assuming your kernel and source are > properly in sync, etc, you can do: >=20 > % addr2line --exe=3Dkernel.debug 0xc052fb46 > ../../../kern/subr_prf.c:297 >=20 > (2) gdb(1) can be used on the debugging kernel, and can often return more > useful context information. For example: >=20 > % gdb kernel.debug > ... > This GDB was configured as "i386-marcel-freebsd"... > (gdb) l *0xc052fb46 > 0xc052fb46 is in printf (../../../kern/subr_prf.c:297). > 292 consintr =3D 0; > 293 va_start(ap, fmt); > 294 pca.tty =3D NULL; > 295 pca.flags =3D TOCONS | TOLOG; > 296 pca.pri =3D -1; > 297 retval =3D kvprintf(fmt, putchar, &pca, 10, ap); > 298 va_end(ap); > 299 if (!panicstr) > 300 msgbuftrigger =3D 1; > 301 consintr =3D savintr; /* reenable interru= pts */ >=20 > gdb is a little more savvy about telling you about macros, inlines, > etc, and gives you a bit of line context, so I've found it very > helpful. >=20 > (3) If you don't have debugging symbols, you can often identify at least > the function that nm(1), you can run nm on the binary, and then searc= h > down through the sumbols until you find the closest address match > before the address. I.e.: >=20 > % nm kernel.debug | more > ... > c06f9f80 d print_message > c067caf0 T printcpuinfo > c052fb38 T printf > c0523104 T printf_uuid > c05019f4 T prison_check >=20 > So the pointer is between printf() and printf_uuid(). >=20 > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Principal Research Scientist, McAfee Resear= ch >=20 > ------------------------------ >=20 > Message: 18 > Date: Wed, 8 Dec 2004 13:00:43 -0800 > From: "whitevamp" <whitevamp47@hotmail.com> > Subject: no internet after build world-kern install > To: <freebsd-stable@freebsd.org> > Message-ID: <BAY2-DAV182DAD0DFECB5ED4109830A1B60@phx.gbl> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > I have done a buildworld from 4.9 to 5.3 and also installed a new custom= kernel and after all whent ok i rebooted the box and goto ping yahoo.com a= nd i cant get out , and i also tryed pinging my outhere ip address and noth= ing on eathere one it just say destination unreachable. so i whent back and= rebuilt a new kern with all defaults execpt i added > options IPFIREWALL_DEFAULT_TO_ACCEPT > and i still cant ping out . i have checked to see if the net card was up = , if i do a ifconfig it shows it as active there, i have whent into rc.con= f and removed out my firewal script that i did have running , still nuthilg= , and durring boot its showing my net card there > so what would be causeing this? if you need more info just let me know > ohh and yea i do have a ip assigned to my net card IE:65.102.x.x > and thanks inadvance for any help that you can give me on this.From owner= -freebsd-stable@FreeBSD.ORG Wed Dec 8 21:42:33 2004 > Return-Path: <owner-freebsd-stable@FreeBSD.ORG> > Delivered-To: freebsd-stable@freebsd.org > Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) > by hub.freebsd.org (Postfix) with ESMTP id E09F016A4CE > for <freebsd-stable@freebsd.org>; > Wed, 8 Dec 2004 21:42:33 +0000 (GMT) > Received: from grummit.biaix.org (86.Red-213-97-212.pooles.rima-tde.net > [213.97.212.86]) by mx1.FreeBSD.org (Postfix) with SMTP id= 1854443D55 > for <freebsd-stable@freebsd.org>; > Wed, 8 Dec 2004 21:42:32 +0000 (GMT) > (envelope-from lists-freebsd-stable@biaix.org) > Received: (qmail 7175 invoked by uid 1000); 8 Dec 2004 21:42:43 -0000 > Date: Wed, 8 Dec 2004 22:42:43 +0100 > From: Joan Picanyol <lists-freebsd-stable@biaix.org> > To: freebsd-stable@freebsd.org > Message-ID: <20041208214243.GA4479@grummit.biaix.org> > Mail-Followup-To: freebsd-stable@freebsd.org > References: <41AE2A8D.6050003@adbulco.nl> > <Pine.BSF.4.30.0412030108260.8303-100000@vault.redlinenetworks.co= m> > <20041203094058.GA56189@grummit.biaix.org> <41B0373E.8050407@gmx.= net> > <20041203100230.GA58730@grummit.biaix.org> <41B043EC.90107@tiscal= i.nl> > Mime-Version: 1.0 > Content-Type: text/plain; charset=3Dus-ascii > Content-Disposition: inline > In-Reply-To: <41B043EC.90107@tiscali.nl> > User-Agent: Mutt/1.5.6i > Subject: Re: Making a data DVD with 4.10 and dvd+rw-format > X-BeenThere: freebsd-stable@freebsd.org > X-Mailman-Version: 2.1.1 > Precedence: list > List-Id: Production branch of FreeBSD source code > <freebsd-stable.freebsd.org> > List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stab= le>, > <mailto:freebsd-stable-request@freebsd.org?subject=3Dunsubscribe> > List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>; > List-Post: <mailto:freebsd-stable@freebsd.org> > List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=3Dhelp> > List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable= >, > <mailto:freebsd-stable-request@freebsd.org?subject=3Dsubscribe> >=20 > * nicky <nickyb@tiscali.nl> [20041203 11:47]: > > Joan Picanyol wrote: > > >* Michael Nottebrock <michaelnottebrock@gmx.net> [20041203 10:52]: > > >>Joan Picanyol wrote: > > >>>># grep atapi /usr/src/sys/i386/conf/LILO > > >>>>device atapicd # ATAPI CDROM drives > > >>>> > > >>>You don't need this, but > > >>> > > >>>device scbus > > >>>device da > > >>>device cd > > >>> > > >>Does atapicam really work without atapicd in the kernel? Just a quest= ion, > > >>I never actually tried. > > >> > > >It works for me (on RELENG_5): > > > > > >503,p3,0$ strings /boot/kernel/kernel | grep ___ | grep atapi > > >___#device atapicd # ATAPI CDROM drives > > >___device atapicam > > >504,p3,0$ camcontrol devlist > > ><HL-DT-ST RW/DVD GCC-4520B 1.00> at scbus1 target 1 lun 0 (pass0,cd0= ) > > > > > Do you have the devices /dev/cd0x etc? >=20 > Yep: >=20 > 501,p1,0$ ls -l /dev/cd0 > crw-rw---- 1 root operator 4, 34 8 des 22:15 /dev/cd0 >=20 > qvb > -- > pica >=20 > ------------------------------ >=20 > Message: 19 > Date: Wed, 8 Dec 2004 22:21:02 +0000 > From: Nuno Teixeira <nu@nunotex.freeshell.org> > Subject: ULE scheduler broken and not documented > To: freebsd-stable@freebsd.org > Message-ID: <20041208222102.GA545@nunotex.local> > Content-Type: text/plain; charset=3Dus-ascii >=20 > Hello to all, >=20 > I'm runinng RELENG_5 and I noticed that ULE scheduler is broken. > Shouldn't this be documented in UPDATING? >=20 > Thanks very much, >=20 > Nuno Teixeira >=20 > -- > SDF Public Access UNIX System - http://sdf.lonestar.org >=20 > ------------------------------ >=20 > Message: 20 > Date: Wed, 8 Dec 2004 23:45:57 +0000 > From: Ceri Davies <ceri@submonkey.net> > Subject: Re: ULE scheduler broken and not documented > To: Nuno Teixeira <nu@nunotex.freeshell.org> > Cc: freebsd-stable@freebsd.org > Message-ID: <20041208234557.GT513@submonkey.net> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > On Wed, Dec 08, 2004 at 10:21:02PM +0000, Nuno Teixeira wrote: > > > > Hello to all, > > > > I'm runinng RELENG_5 and I noticed that ULE scheduler is broken. > > Shouldn't this be documented in UPDATING? >=20 > Yes. I thought it was, but you are correct in asserting that it isn't. >=20 > Ceri > -- > Only two things are infinite, the universe and human stupidity, and I'm > not sure about the former. -- Einstein (attrib.) > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20041= 208/175b4a64/attachment-0001.bin >=20 > ------------------------------ >=20 > Message: 21 > Date: Wed, 08 Dec 2004 22:21:24 -0200 > From: Crist?v?o Dalla Costa<cbraga@desnormal.com.br> > Subject: 5.3R crashing repeateadly > To: freebsd-stable@freebsd.org > Message-ID: <41B79A84.5010909@desnormal.com.br> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > Hello >=20 > I just installed 5.3 RELEASE on a new server today and everytime I try > to compile someting for more than five minutes it crashes. >=20 > The message it said in the console is something like "page fault while > in kernel mode", excuse-me if I don't remember it verbatim but I just > drove home from the datacenter and it crashed again. >=20 > The setup is a P4 Xeon HT with a Asus PC-DL motherboard and four serial > ata drives in RAID 10 mode using vinum. I actually had to use the gvinum > hack to get the system to boot. >=20 > Why the hell doesn't it reboot after it crashes? Is there anything I can > to to make it reboot in case o a crash? And, can I somehow keep it from > crashing? >=20 > I'm a FreeBSD fan of several years, having used it exclusively for > servers since 4.3 and now I'm seriously considering throwing this thing > out and installing some sort of Linux. It took me the whole day to get > aroung the vinum troubles and now I can't install the ports because it > keeps crashing. >=20 > Furthermore, what sort of reliability can I expect from this server? > It's 10:30 pm and I'm driving to the datacenter to push the reset button > for the third time. >=20 > Thanks for any help. >=20 > Crist=F3v=E3o >=20 > ------------------------------ >=20 > Message: 22 > Date: Wed, 8 Dec 2004 16:37:13 -0800 > From: Brooks Davis <brooks@one-eyed-alien.net> > Subject: Re: 5.3R crashing repeateadly > To: Crist?v?oDalla Costa <cbraga@desnormal.com.br> > Cc: freebsd-stable@freebsd.org > Message-ID: <20041209003713.GA26248@odin.ac.hmc.edu> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > On Wed, Dec 08, 2004 at 10:21:24PM -0200, Crist=F3v=E3o Dalla Costa wrote= : > > I just installed 5.3 RELEASE on a new server today and everytime I try > > to compile someting for more than five minutes it crashes. >=20 > This sounds like hardware, but it could be a bug related to your > particular system. Do you get there errors if you boot with ACPI > disabled? What about with SMP disabled? >=20 > > The message it said in the console is something like "page fault while > > in kernel mode", excuse-me if I don't remember it verbatim but I just > > drove home from the datacenter and it crashed again. >=20 > You'll need to get a debug kernel and produce a traceback for us to have > any chance of doing anything for you. See the kernel debugging chapter > of the Developers Handbook for info: >=20 > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kern= eldebug.html >=20 > > Furthermore, what sort of reliability can I expect from this server? > > It's 10:30 pm and I'm driving to the datacenter to push the reset butto= n > > for the third time. >=20 > Until we know what's wrong we can't possiably answer that question. A > number of systems running 5.3 are in production and stable, but it's a > new release. >=20 > -- Brooks >=20 > -- > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 189 bytes > Desc: not available > Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20041= 208/cf9fc3a8/attachment-0001.bin >=20 > ------------------------------ >=20 > Message: 23 > Date: Wed, 8 Dec 2004 16:36:58 -0800 (PST) > From: Crucio <crucio2004-freebsd@yahoo.com> > Subject: Re: trouble installing 5.3 on soekris net4801 > To: Lapo Nustrini <lapo@seanet.com>, crucio2004-freebsd@yahoo.com > Cc: freebsd-stable@freebsd.org > Message-ID: <20041209003658.7184.qmail@web52006.mail.yahoo.com> > Content-Type: text/plain; charset=3Dus-ascii >=20 > I shall try this. Do you have any idea what differs > for the IDE driver (I presume ATAng) when booting into > safe mode? >=20 > --- Lapo Nustrini <lapo@seanet.com> wrote: >=20 > > Have you tried booting up in safe mode? > > I have a similar issue running 5.3 STABLE on a > > machine which runs fine > > with 5.3 BETA7. > > > > Booting into safe mode works fine. Any other way, > > and it gets ATAPI > > errors or SCSI errors (if I take all ATAPI stuff out > > of the kernel). > > > > Still trying to find the real source of the > > problem... >=20 > ------------------------------ >=20 > Message: 24 > Date: Wed, 8 Dec 2004 19:06:39 -0600 > From: "Donald J. O'Neill" <donaldj1066@fastmail.fm> > Subject: Re: ULE scheduler broken and not documented > To: freebsd-stable@freebsd.org > Message-ID: <200412081906.39668.donaldj1066@fastmail.fm> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > On Wednesday 08 December 2004 04:21 pm, Nuno Teixeira wrote: > > Hello to all, > > > > I'm runinng RELENG_5 and I noticed that ULE scheduler is broken. > > Shouldn't this be documented in UPDATING? > > > > Thanks very much, > > > > Nuno Teixeira >=20 > It's documented in errata: > (1 Nov 2004) The ULE scheduler described in the release notes has > been completely disabled to discourage its use because it has > stability problems. >=20 > Don >=20 > -- > Donald J. O'Neill > donaldj1066@fastmail.fm >=20 > ------------------------------ >=20 > Message: 25 > Date: Wed, 08 Dec 2004 23:15:44 -0200 > From: Crist?v?o Dalla Costa<cbraga@desnormal.com.br> > Subject: Re: 5.3R crashing repeateadly > To: Brooks Davis <brooks@one-eyed-alien.net> > Cc: freebsd-stable@freebsd.org > Message-ID: <41B7A740.2040601@desnormal.com.br> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > Brooks Davis wrote: >=20 > >On Wed, Dec 08, 2004 at 10:21:24PM -0200, Crist=F3v=E3o Dalla Costa wrot= e: > > > > > >>I just installed 5.3 RELEASE on a new server today and everytime I try > >>to compile someting for more than five minutes it crashes. > >> > >> > > > >This sounds like hardware, but it could be a bug related to your > >particular system. Do you get there errors if you boot with ACPI > >disabled? What about with SMP disabled? > > > > > I've disabled SMP with the kern.smp.disabled=3D1 sysctl and I'll see what > happens next. Strangely though the kernel seems to think the system has > only one cpu despite it being hyperthreaded: >=20 > # sysctl -a | grep cpu > kern.threads.virtual_cpu: 1 > kern.ccpu: 1948 > kern.smp.maxcpus: 1 > kern.smp.cpus: 1 > hw.ncpu: 1 > hw.acpi.cpu.cx_supported: C1/0 > hw.acpi.cpu.cx_lowest: C1 > hw.acpi.cpu.cx_usage: 100.00% > machdep.cpu_idle_hlt: 1 >=20 > # sysctl -a | grep machdep.hlt_logical_cpus > (no results) >=20 > # dmesg | less > FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 > root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2405.47-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0xf25 Stepping =3D 5 > Features=3D0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,P= GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,S > S,HTT,TM,PBE> > Hyperthreading: 2 logical CPUs >=20 > I'll try disabling ACPI if I have to reboot the server once more. >=20 > >You'll need to get a debug kernel and produce a traceback for us to have > >any chance of doing anything for you. See the kernel debugging chapter > >of the Developers Handbook for info: > > > >http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ker= neldebug.html > > > > > > > I'll do that. Thanks a lot for the help >=20 > Crist=F3v=E3o >=20 > > > > >=20 > ------------------------------ >=20 > Message: 26 > Date: Wed, 08 Dec 2004 20:19:07 -0500 > From: Mike Tancsa <mike@sentex.net> > Subject: Re: 5.3R crashing repeateadly > To: Crist?v?oDalla Costa <cbraga@desnormal.com.br> > Cc: freebsd-stable@freebsd.org > Message-ID: <6.2.0.14.0.20041208201757.054b2bc8@64.7.153.2> > Content-Type: text/plain; charset=3D"iso-8859-1"; format=3Dflowed >=20 > At 08:15 PM 08/12/2004, Crist=F3v=E3o Dalla Costa wrote: >=20 > >I've disabled SMP with the kern.smp.disabled=3D1 sysctl and I'll see wha= t > >happens next. Strangely though the kernel seems to think the system has > >only one cpu despite it being hyperthreaded: >=20 > You want to turn HT off in the BIOS. The scheduler will not make use of > it, and in fact will most likely hurt performance. >=20 > ---Mike >=20 > ------------------------------ >=20 > Message: 27 > Date: Thu, 09 Dec 2004 10:53:56 +0900 > From: Rob <spamrefuse@yahoo.com> > Subject: More WRITE_DMA problems on 5.3 > To: freebsd-stable@freebsd.org > Message-ID: <41B7B034.2090001@yahoo.com> > Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed >=20 > Hi, >=20 > Once again I ran into WRITE_DMA failure at bootup with one of my PCs. >=20 > Motherboard: LGM-VBX6 > Twin Processor /* not dual */ > VIA 82C693 Apollo Pro AGPset > 2Mb Flash ROM BIOS > UDMA66 support >=20 > BIOS: Award Software Inc. v4.51PG >=20 > Harddisk: IBM-DTLA-307045/TX6OA50C 43979MB >=20 > The bootup fails because of WRITE_DMA failure. The problem is resolved by > putting hw.ata.ata_dma=3D"0" in /boot/loader.conf, forcing the harddisk i= n > PIO4 mode instead of the faster UDMA66. After bootup, dmesg says: >=20 > FreeBSD 5.3-STABLE #0: Tue Dec 7 01:48:44 KST 2004 > lahaye@para.snu.ac.kr:/usr/obj/usr/src/sys/MYKERNEL > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel Pentium III (701.60-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0x683 Stepping =3D 3 > Features=3D0x387f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,M= CA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE> > real memory =3D 134217728 (128 MB) > avail memory =3D 125894656 (120 MB) > npx0: [FAST] > npx0: <math processor> on motherboard > npx0: INT 16 interface > pcib0: <Host to PCI bridge> pcibus 0 on motherboard > pir0: <PCI Interrupt Routing Table: 7 Entries> on motherboard > pci0: <PCI bus> on pcib0 > agp0: <VIA 82C691 (Apollo Pro) host to PCI bridge> mem 0xd0000000-0xd3fff= fff at device 0.0 on pci0 > pcib1: <PCI-PCI bridge> at device 1.0 on pci0 > pci1: <PCI bus> on pcib1 > pci1: <display, VGA> at device 0.0 (no driver attached) > isab0: <PCI-ISA bridge> at device 7.0 on pci0 > isa0: <ISA bus> on isab0 > atapci0: <VIA 82C596B UDMA66 controller> port 0xe000-0xe00f,0x376,0x170-0= x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 > ata0: channel #0 on atapci0 > ata1: channel #1 on atapci0 > pci0: <serial bus, USB> at device 7.2 (no driver attached) > pci0: <bridge, HOST-PCI> at device 7.3 (no driver attached) > xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xe800-0xe87f mem 0xd9000000= -0xd900007f irq 11 at device 9.0 on pci0 > miibus0: <MII bus> on xl0 > xlphy0: <3Com internal media interface> on miibus0 > xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > xl0: Ethernet address: 00:50:da:91:73:52 > xl1: <3Com 3c905B-TX Fast Etherlink XL> port 0xec00-0xec7f mem 0xd9001000= -0xd900107f irq 10 at device 17.0 on pci0 > miibus1: <MII bus> on xl1 > xlphy1: <3Com internal media interface> on miibus1 > xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > xl1: Ethernet address: 00:50:da:91:73:fd > cpu0 on motherboard > orm0: <ISA Option ROM> at iomem 0xc0000-0xca7ff on isa0 > atkbdc0: <Keyboard controller (i8042)> at port 0x64,0x60 on isa0 > atkbd0: <AT Keyboard> irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: <PS/2 Mouse> irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > fdc0: <Enhanced floppy controller> at port 0x3f0-0x3f5 irq 6 drq 2 on isa= 0 > fdc0: [FAST] > sc0: <System console> at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > unknown: <PNP0303> can't assign resources (port) > unknown: <PNP0f13> can't assign resources (irq) > unknown: <PNP0501> can't assign resources (port) > unknown: <PNP0700> can't assign resources (port) > unknown: <PNP0501> can't assign resources (port) > Timecounter "TSC" frequency 701596920 Hz quality 800 > Timecounters tick every 10.000 msec > ipfw2 initialized, divert disabled, rule-based forwarding disabled, defau= lt to accept, logging limited to 100 packets/entry by default > ad0: 43979MB <IBM-DTLA-307045/TX6OA50C> [89355/16/63] at ata0-master PIO4 > acd0: CDROM <CRD-8520B/1.00> at ata1-master PIO4 > Mounting root from ufs:/dev/ad0s1a >=20 > ---- >=20 > Rob. >=20 > ------------------------------ >=20 > Message: 28 > Date: Thu, 9 Dec 2004 12:41:10 +1030 > From: Greg 'groggy' Lehey <grog@FreeBSD.org> > Subject: Re: crashdumps not working > To: Robert Watson <rwatson@freebsd.org> > Cc: freebsd-stable@freebsd.org > Message-ID: <20041209021109.GH92212@wantadilla.lemis.com> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > On Wednesday, 8 December 2004 at 11:20:34 +0000, Robert Watson wrote: > > > > On Tue, 7 Dec 2004, Michael Nottebrock wrote: > > > >> I recently enabled SW_WATCHDOG in my kernel, but when watchdog trigger= s > >> a panic, no crashdump is taken although dumps are enabled. What could = be > >> causing this? > > > > If you drop to the debugger by using the debug.kdb.enter sysctl, and > > do "call doadump", followed by a reset, does a dump get generated > > successfully? I.e., are they completely broken on your system, or > > is this somehow a property of the particular hang you're seeing. > > (Do the above with caution and in a situation where you don't mind > > fscking, needless to say). >=20 > FWIW, I've found that the only way to dump a -CURRENT system in the > last six months or so has been to 'call doadump'. There are a number > of other problems, including getting gdb over firewire to work at all, > but I won't find time to look at them for the next few weeks. >=20 > Greg > -- > See complete headers for address and phone numbers. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20041= 209/75acca21/attachment.bin >=20 > ------------------------------ >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >=20 > End of freebsd-stable Digest, Vol 89, Issue 5 > ********************************************* >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1dbad31504120905523c64367e>