Re:SOLVVED vinum crashes the Box... WRONG POSTING
From: Michael Schuh (michael.schuh_at_gmail.com)
Date: 12/09/04
- Previous message: Gleb Smirnoff: "Re: [TEST] ng_bridge ng_l2tp ng_lmi"
- Next in thread: Greg 'groggy' Lehey: "Re: SOLVVED vinum crashes the Box... WRONG POSTING"
- Reply: Greg 'groggy' Lehey: "Re: SOLVVED vinum crashes the Box... WRONG POSTING"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 9 Dec 2004 14:52:14 +0100 To: freebsd-stable@freebsd.org
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
>
> 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
>
> You can reach the person managing the list at
> freebsd-stable-owner@freebsd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-stable digest..."
>
> Today's Topics:
>
> 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)
>
> ----------------------------------------------------------------------
>
> 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="iso-8859-1"
>
> 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 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 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 think you can get a clue as to why
> it wouldn't crashdump or reset by something I can do in kdb, I will enable
> it ...
>
> > Do you
> > have a serial console on the box, or could you set one up?
>
> Nope, this is the only machine with a keyboard and a monitor attached.
>
> >
> > > > 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 = 0x14c
> > > fault code = supervisor write, page not present
> > > instruction pointer = 0x8:0xc0521397
> > > stack pointer = 0x10:0xe9794b84
> > > frame pointer = 0x10:0xe9794b90
> > > code segment = base 0x0, limit 0xfffff, type 0x1b
> > > = DPL 0, pres 1, def32 1, gran 1
> > > processor eflags = resume, IOPL = 0
> > > current process = 1281 (beep-media-player)
> > > trap number = 12
> > > panic: page fault
> >
> > This is a NULL pointer dereference; you can use addr2line or gdb on your
> > 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 without
> > getting dumping working on the box.
>
> 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 :-(.
>
> > Syncing on panic is, in general, probably not going to make it work better
> > 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.
>
> --
> ,_, | 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/20041208/0f3ca746/attachment-0001.bin
>
> ------------------------------
>
> 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="iso-8859-15"
>
> On Wednesday, 8. December 2004 13:16, Michael Nottebrock wrote:
>
> > > > panic: page fault
> > >
> > > This is a NULL pointer dereference; you can use addr2line or gdb on your
> > > 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 without
> > > getting dumping working on the box.
> >
> > 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
> > :-(.
>
> N.B., I'm running now SCHED_4BSD again.
>
> --
> ,_, | 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/20041208/a7df61b9/attachment-0001.bin
>
> ------------------------------
>
> 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=US-ASCII
>
> Hi,
>
> Ihas following System dmesg:
>
> 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 = "GenuineIntel" Id = 0x686 Stepping = 6
> Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM
> OV,PAT,PSE36,MMX,FXSR,SSE>
> real memory = 1342169088 (1310712K bytes)
> config> en apm0
> config> q
> avail memory = 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=8086 device=0962)> 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 0xfcfff000-0xf
> cffffff irq 13 at device 6.0 on pci1
> aic7880: Ultra Single Channel A, SCSI Id=7, 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=2558<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-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 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)
>
> 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
>
> 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
>
> With this configuration vinum crashes the Machine with this Message:
> 15: drive disk12 device /dev/da11s1h
> ** 15 : Invalid argument
>
> 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.
>
> Ah, my Target is to build a RAID10 Mirror of Stripes
> might be a count problem?
>
> Sorry thats are all error-messages that i can see.
>
> thanks for your interest and help
>
> michael
>
> ------------------------------
>
> 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=US-ASCII
>
> On Wed, 8 Dec 2004, Michael Nottebrock wrote:
>
> > > > 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 think
> > you can get a clue as to why it wouldn't crashdump or reset by something
> > I can do in kdb, I will enable it ...
>
> 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:
>
> - 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?
>
> I.e., do the individual elements work from the debugger. If they do, then
> we can try the same from entering the debugger following the panic, and
> see how things differ.
>
> > > This is a NULL pointer dereference; you can use addr2line or gdb on your
> > > 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 without
> > > getting dumping working on the box.
> >
> > 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 :-(.
>
> 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 use
> 4BSD?
>
> > > Syncing on panic is, in general, probably not going to make it work better
> > > 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.
>
> Thanks. Just trying to keep track of and reduce the number of variables.
>
> Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> robert@fledge.watson.org Principal Research Scientist, McAfee Research
>
> ------------------------------
>
> 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="iso-8859-1"
>
> 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 use
> > 4BSD?
>
> 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 panic
> there with ULE was a one off that happened when I turned on ULE & PREEMPTION
> to test if the warning about ULE being unstable with PREEMPTION tells the
> truth... sure does. :-)
>
> I'm going to enable the kernel debugger now... Thanks for the help btw!
>
> --
> ,_, | 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/20041208/becd8b3c/attachment-0001.bin
>
> ------------------------------
>
> 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=US-ASCII
>
> Hi,
>
> Ihas following System dmesg:
>
> 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 = "GenuineIntel" Id = 0x686 Stepping = 6
> Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM
> OV,PAT,PSE36,MMX,FXSR,SSE>
> real memory = 1342169088 (1310712K bytes)
> config> en apm0
> config> q
> avail memory = 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=8086 device=0962)> 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
> aic7880: Ultra Single Channel A, SCSI Id=7, 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=2558<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-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
> 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=0x300>
> 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)
>
> 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
>
> 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
>
> With this configuration vinum crashes the Machine with this Message:
> 15: drive disk12 device /dev/da11s1h
> ** 15 : Invalid argument
>
> 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.
>
> Ah, my Target is to build a RAID10 Mirror of Stripes
>
> might be a count problem?
>
> Sorry thats are all error-messages that i can see.
>
> thanks for your interest and help
>
> ------------------------------
>
> 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="iso-8859-1"
>
> On Wednesday, 8. December 2004 13:38, Robert Watson wrote:
>
> Okay, I've now enabled the following in the kernel:
>
> options KDB
> options KDB_TRACE
> options DDB
>
> > So I'm thinking it
> > would be nice to know:
> >
> > - Can you enter and continue from kdb normally using the sysctl.
>
> Yes.
>
> > - If you can enter kdb using the sysctl, does "call doadump()" work from
> > kdb?
>
> Yes.
>
> > - If you can enter kdb using the sysctl, oes "reset" work from kdb?
>
> Yes.
>
> > I.e., do the individual elements work from the debugger. If they do, then
> > we can try the same from entering the debugger following the panic, and
> > see how things differ.
>
> All of the above works when entering the debugger from the watchdog timeout,
> too. :-\
>
> --
> ,_, | Michael Nottebrock | lofi@freebsd.org
> (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
> \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
>
> ------------------------------
>
> 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="iso-8859-1"
>
> I played around with the kernel debug options a little and found peculiar
> things:
>
> - 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?
>
> - With options KDB, KDB_UNATTENDED and DDB, a panic _does_ trigger DDB,
> contrary to what the description of KDB_UNATTENDED says.
>
> It seems to me 5.3's debugging facilities are somewhat in disarray...
>
> --
> ,_, | 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/20041208/2ba0f46a/attachment-0001.bin
>
> ------------------------------
>
> 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=ISO-8859-2; format=flowed
>
> 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.
>
> ------------------------------
>
> 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=ISO-8859-2; format=flowed
>
> 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"
>
> > while devfs(8) rules work for those, but they vanish on reboot.
>
> ------------------------------
>
> 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="iso-8859-2"
>
> 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.
>
> 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 examples
> for the whole devfs stuff is sorely missed not just by me...
>
> --
> ,_, | 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/20041208/9a3d0b66/attachment-0001.bin
>
> ------------------------------
>
> 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=US-ASCII
>
> Ivan Voras wrote:
> [ Charset ISO-8859-2 unsupported, converting... ]
> > Is there a canonical way of preserving devfs rules (device permissions
> > actually) across reboots?
>
> >cat /etc/devfs.rules
> [devfsrules_local=15]
> 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.
> --
> Frank Mayhar frank@exit.com http://www.exit.com/
> Exit Consulting http://www.gpsclock.com/
> http://www.exit.com/blog/frank/
>
> ------------------------------
>
> 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=US-ASCII
>
> Frank Mayhar wrote:
> > Ivan Voras wrote:
> > [ Charset ISO-8859-2 unsupported, converting... ]
> > > Is there a canonical way of preserving devfs rules (device permissions
> > > actually) across reboots?
> >
> > >cat /etc/devfs.rules
> > [devfsrules_local=15]
> > 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="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/
>
> ------------------------------
>
> 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=us-ascii
>
> >>>>> "Robert" == 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?
>
> Dave.
>
> --
> ============================================================================
> |David Gilbert, Independent Contractor. | Two things can only be |
> |Mail: dave@daveg.ca | equal if and only if they |
> |http://daveg.ca | are precisely opposite. |
> =========================================================GLO================
>
> ------------------------------
>
> 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=ISO-8859-1; format=flowed
>
> Frank Mayhar wrote:
>
> >>>cat /etc/devfs.rules
> >>
> >>[devfsrules_local=15]
> >>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="devfsrules_local"
> > to /etc/rc.conf.
>
> Thanks, that's what I was looking for! :)
>
> ------------------------------
>
> 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=US-ASCII; format=flowed
>
> 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...
>
> Good luck,
>
> Lapo
>
> On Dec 7, 2004, at 8:31 PM, Crucio wrote:
>
> > 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=0
> > ad0: FAILURE - READ_DMA timed out
> > ad0: TIMEOUT - READ_DMA retrying (2 retries left)
> > LBA=0
> > ad0: FAILURE - READ_DMA timed out
> > ad0: TIMEOUT - READ_DMA retrying (2 retries left)
> > LBA=0
> > ad0: FAILURE - READ_DMA timed out
> > ad0: TIMEOUT - READ_DMA retrying (2 retries left)
> > LBA=1
> > 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"
> >
>
> ------------------------------
>
> 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=US-ASCII
>
> On Wed, 8 Dec 2004, David Gilbert wrote:
>
> > >>>>> "Robert" == 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?
>
> 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 get
> a fault and the trap shows the instruction pointer is 0xc052fb46. You can
> use:
>
> (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:
>
> % addr2line --exe=kernel.debug 0xc052fb46
> ../../../kern/subr_prf.c:297
>
> (2) gdb(1) can be used on the debugging kernel, and can often return more
> useful context information. For example:
>
> % 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 = 0;
> 293 va_start(ap, fmt);
> 294 pca.tty = NULL;
> 295 pca.flags = TOCONS | TOLOG;
> 296 pca.pri = -1;
> 297 retval = kvprintf(fmt, putchar, &pca, 10, ap);
> 298 va_end(ap);
> 299 if (!panicstr)
> 300 msgbuftrigger = 1;
> 301 consintr = savintr; /* reenable interrupts */
>
> 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.
>
> (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 search
> down through the sumbols until you find the closest address match
> before the address. I.e.:
>
> % nm kernel.debug | more
> ...
> c06f9f80 d print_message
> c067caf0 T printcpuinfo
> c052fb38 T printf
> c0523104 T printf_uuid
> c05019f4 T prison_check
>
> So the pointer is between printf() and printf_uuid().
>
> Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> robert@fledge.watson.org Principal Research Scientist, McAfee Research
>
> ------------------------------
>
> 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="iso-8859-1"
>
> 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 and i cant get out , and i also tryed pinging my outhere ip address and nothing 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.conf 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.com>
> <20041203094058.GA56189@grummit.biaix.org> <41B0373E.8050407@gmx.net>
> <20041203100230.GA58730@grummit.biaix.org> <41B043EC.90107@tiscali.nl>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-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-stable>,
> <mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
> 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=help>
> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
> <mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
>
> * 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 question,
> > >>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?
>
> Yep:
>
> 501,p1,0$ ls -l /dev/cd0
> crw-rw---- 1 root operator 4, 34 8 des 22:15 /dev/cd0
>
> qvb
> --
> pica
>
> ------------------------------
>
> 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=us-ascii
>
> 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
>
> --
> SDF Public Access UNIX System - http://sdf.lonestar.org
>
> ------------------------------
>
> 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="us-ascii"
>
> 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?
>
> Yes. I thought it was, but you are correct in asserting that it isn't.
>
> 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/20041208/175b4a64/attachment-0001.bin
>
> ------------------------------
>
> 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=ISO-8859-1; format=flowed
>
> Hello
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> 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.
>
> 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.
>
> Thanks for any help.
>
> Cristóvão
>
> ------------------------------
>
> 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="iso-8859-1"
>
> On Wed, Dec 08, 2004 at 10:21:24PM -0200, Cristóvão 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.
>
> 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?
>
> > 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.
>
> 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/kerneldebug.html
>
> > 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.
>
> 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.
>
> -- Brooks
>
> --
> 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/20041208/cf9fc3a8/attachment-0001.bin
>
> ------------------------------
>
> 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=us-ascii
>
> I shall try this. Do you have any idea what differs
> for the IDE driver (I presume ATAng) when booting into
> safe mode?
>
> --- Lapo Nustrini <lapo@seanet.com> wrote:
>
> > 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...
>
> ------------------------------
>
> 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="iso-8859-1"
>
> 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
>
> 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.
>
> Don
>
> --
> Donald J. O'Neill
> donaldj1066@fastmail.fm
>
> ------------------------------
>
> 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=ISO-8859-1; format=flowed
>
> Brooks Davis wrote:
>
> >On Wed, Dec 08, 2004 at 10:21:24PM -0200, Cristóvão 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.
> >>
> >>
> >
> >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=1 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:
>
> # 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
>
> # sysctl -a | grep machdep.hlt_logical_cpus
> (no results)
>
> # 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 = "GenuineIntel" Id = 0xf25 Stepping = 5
> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,S
> S,HTT,TM,PBE>
> Hyperthreading: 2 logical CPUs
>
> I'll try disabling ACPI if I have to reboot the server once more.
>
> >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/kerneldebug.html
> >
> >
> >
> I'll do that. Thanks a lot for the help
>
> Cristóvão
>
> >
> >
>
> ------------------------------
>
> 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="iso-8859-1"; format=flowed
>
> At 08:15 PM 08/12/2004, Cristóvão Dalla Costa wrote:
>
> >I've disabled SMP with the kern.smp.disabled=1 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:
>
> 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.
>
> ---Mike
>
> ------------------------------
>
> 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=us-ascii; format=flowed
>
> Hi,
>
> Once again I ran into WRITE_DMA failure at bootup with one of my PCs.
>
> Motherboard: LGM-VBX6
> Twin Processor /* not dual */
> VIA 82C693 Apollo Pro AGPset
> 2Mb Flash ROM BIOS
> UDMA66 support
>
> BIOS: Award Software Inc. v4.51PG
>
> Harddisk: IBM-DTLA-307045/TX6OA50C 43979MB
>
> The bootup fails because of WRITE_DMA failure. The problem is resolved by
> putting hw.ata.ata_dma="0" in /boot/loader.conf, forcing the harddisk in
> PIO4 mode instead of the faster UDMA66. After bootup, dmesg says:
>
> 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 = "GenuineIntel" Id = 0x683 Stepping = 3
> Features=0x387f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE>
> real memory = 134217728 (128 MB)
> avail memory = 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-0xd3ffffff 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-0x177,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 isa0
> fdc0: [FAST]
> sc0: <System console> at flags 0x100 on isa0
> sc0: VGA <16 virtual consoles, flags=0x300>
> 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, default 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
>
> ----
>
> Rob.
>
> ------------------------------
>
> 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="us-ascii"
>
> 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 triggers
> >> 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).
>
> 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.
>
> 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/20041209/75acca21/attachment.bin
>
> ------------------------------
>
> _______________________________________________
> 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"
>
> End of freebsd-stable Digest, Vol 89, Issue 5
> *********************************************
>
_______________________________________________
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"
- Previous message: Gleb Smirnoff: "Re: [TEST] ng_bridge ng_l2tp ng_lmi"
- Next in thread: Greg 'groggy' Lehey: "Re: SOLVVED vinum crashes the Box... WRONG POSTING"
- Reply: Greg 'groggy' Lehey: "Re: SOLVVED vinum crashes the Box... WRONG POSTING"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
