smp reboot with atang
The problem of not being able to reboot without a panic seems to persist on late current with ATAng and SMP. Pete Sep 16 13:16:11 rms21 reboot: rebooted by pete Sep 16 13:16:11 rms21 syslogd: exiting on signal 15 boot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped W ia tFiantga l( mtarxa p6 01 :s epcroinvdisl)e gfeodr isnyssttreumc tpiroonc efsasu l`ts ywnhcielre' itno ksetronpe.l. .mode cpuid = 1; lapic.id = 0100 instruction pointer = 0x8:0xd70fbd0e stack pointer = 0x10:0xd70fbcec frame pointer = 0x10:0x8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 11 (idle: cpu1) kernel: type 1 trap, code=0 Stopped at 0xd70fbd0e: ??? db trace Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x8:0xc0383880 stack pointer = 0x10:0xd70fb9f0 frame pointer = 0x10:0xd70fb9f4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 11 (idle: cpu1) kernel: type 12 trap, code=0 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: smp reboot with atang
Soren Schmidt wrote: It seems Petri Helenius wrote: The problem of not being able to reboot without a panic seems to persist on late current with ATAng and SMP. The below doesn't say much actually, but I can reboot to my hearts content on my SMP box here with no problems. What else do you have in that kernel ? Removing device atapicam seems to resolve the issue. Previously I couldn´t do that but thanks to your patch I can now have a kernel without atapicam. Pete Sep 16 13:16:11 rms21 reboot: rebooted by pete Sep 16 13:16:11 rms21 syslogd: exiting on signal 15 boot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped W ia tFiantga l( mtarxa p6 01 :s epcroinvdisl)e gfeodr isnyssttreumc tpiroonc efsasu l`ts ywnhcielre' itno ksetronpe.l. .mode cpuid = 1; lapic.id = 0100 instruction pointer = 0x8:0xd70fbd0e stack pointer = 0x10:0xd70fbcec frame pointer = 0x10:0x8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 11 (idle: cpu1) kernel: type 1 trap, code=0 Stopped at 0xd70fbd0e: ??? db trace Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x8:0xc0383880 stack pointer = 0x10:0xd70fb9f0 frame pointer = 0x10:0xd70fb9f4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 11 (idle: cpu1) kernel: type 12 trap, code=0 -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ata raid crash
While the machine was bg-fscking and building a new kernel, on -CURRENT from 2 Sep after the ataraid transfer size patch, it fell over like this: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xa2b22cf4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0163ec9 stack pointer = 0x10:0xcd63abc4 frame pointer = 0x10:0xcd63ac54 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 4 (g_down) kernel: type 12 trap, code=0 Stopped at arstrategy+0x939: movl%eax,0x24(%ebx,%ecx,8) db trace arstrategy(c2928e10,0,c03ab7c7,5c,0) at arstrategy+0x939 g_disk_start(c292cea0,0,c03abd6b,15f,a) at g_disk_start+0x1a6 g_io_schedule_down(c0eaa000,2,c03abf62,6e,c01e4d50) at g_io_schedule_down+0x1ac g_down_procbody(0,cd63ad48,c03add0d,314,14ec8353) at g_down_procbody+0x48 fork_exit(c01e4d50,0,cd63ad48) at fork_exit+0xcf fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcd63ad7c, ebp = 0 --- Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
atang rebuild fails
It seems that the same bug that initially stopped ataraid working at all is there with rebuild: kompak# atacontrol rebuild 0 ad4: FAILURE - oversized DMA transfer attempted 131072 65536 ad4: setting up DMA failed kompak# atacontrol status 0 ar0: ATA RAID1 subdisks: ad4 ad8 status: REBUILDING 0% completed kompak# atacontrol status 0 ar0: ATA RAID1 subdisks: ad4 ad8 status: REBUILDING 0% completed kompak# atacontrol status 0 ar0: ATA RAID1 subdisks: ad4 ad8 status: REBUILDING 0% completed kompak# atacontrol status 0 ar0: ATA RAID1 subdisks: ad4 ad8 status: REBUILDING 0% completed kompak# ...and after the message it gets stuck on 0% probably because it never started rebuilding in the first place? Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
atapicam panic
Atacontrol detach / attach seems to panic if atapicam is complied in the kernel. Should this work or is the work to port this to ATAng still undergoing? This is current from four days ago, just after Soren's ar DMA size commit. # atacontrol detach 4 ad8: deleted from ar0 disk1 ar0: WARNING - mirror lost GEOM: destroy disk ad8 dp=0xc25f4e70 ad8: WARNING - removed from configuration # atacontrol attach 4 GEOM: create disk ad8 dp=0xc2746870 ad8: 76319MB WDC WD800JB-00CRA1 [155061/16/63] at ata4-master UDMA100 panic: mutex Giant not owned at ../../../dev/ata/atapi-cam.c:117 Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db trace Debugger(c03b00f0,c04142a0,c03af7c7,cd690a58,100) at Debugger+0x54 panic(c03af7c7,c03af902,c039de55,75,0) at panic+0xd5 _mtx_assert(c04125e0,1,c039de55,75,10) at _mtx_assert+0xec atapi_cam_attach_bus(c2588a00,c24f3980,602,c0150480,c2588a00) at atapi_cam_attach_bus+0x37 ata_attach(c258b000,0,c039bb88,14b,0) at ata_attach+0x168 ata_ioctl(c040e870,c4546101,c282d800,3,c0eb0d10) at ata_ioctl+0x457 spec_ioctl(cd690b7c,cd690c28,c027f2f1,cd690b7c,c02105dd) at spec_ioctl+0x19e spec_vnoperate(cd690b7c,c02105dd,c0415920,1,c03fc720) at spec_vnoperate+0x18 vn_ioctl(c26d3484,c4546101,c282d800,c2812780,c0eb0d10) at vn_ioctl+0x1a1 ioctl(c0eb0d10,cd690d10,c03c6e36,3eb,3) at ioctl+0x475 syscall(2f,2f,2f,805f2b7,bfbffd2a) at syscall+0x273 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x8049a3f, esp = 0xbfbff76c, ebp = 0xbfbffc18 --- db Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic while fsck
While fscking from previous panic in ufs2 code on -CURRENT from Sep 2, I got this: panic: ffs_copyonwrite: recursive call cpuid = 1; lapic.id = 0100 Debugger(panic) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db trace Debugger(c03e1565,100,c03eebf0,dd78eac8,100) at Debugger+0x55 panic(c03eebf0,c029c4f8,c448a124,0,c03e6165) at panic+0x15f ffs_copyonwrite(c4256248,ce5d0090,0,c08d43f0,dd78eb78) at ffs_copyonwrite+0x42 spec_xstrategy(c4256248,ce5d0090,dd78eb84,c0210668,dd78ebb0) at spec_xstrategy+0x112 spec_specstrategy(dd78ebb0,dd78ebcc,c0346830,dd78ebb0,0) at spec_specstrategy+0x1b spec_vnoperate(dd78ebb0,0,c08d43f0,3,ce5d0090) at spec_vnoperate+0x18 ufs_strategy(dd78ebf4,dd78ec2c,c0289dc7,dd78ebf4,1) at ufs_strategy+0xe0 ufs_vnoperate(dd78ebf4,1,c03e4e5c,35a,100100) at ufs_vnoperate+0x18 bwrite(ce5d0090,dd78ec78,c03392f9,ce5d0090,0) at bwrite+0x427 bawrite(ce5d0090,0,c03f04cd,e1,367) at bawrite+0x1c ffs_fsync(dd78eca4,0,c03e6509,ad8,0) at ffs_fsync+0x2a9 fsync(c42374c0,dd78ed10,c03f6ad5,3eb,1) at fsync+0x151 syscall(2f,2f,2f,17a2f000,97d0a60) at syscall+0x253 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (95, FreeBSD ELF32, fsync), eip = 0x2861b01f, esp = 0xbfa87eb4, ebp = 0xbfa87ed0 --- db Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATAPI burner goes as PIO4
I have a DVD drive which is recognized by the BIOS as UDMA33 and also the documentation states that UDMA33 is the fastest it goes, however with ATAng the hw.ata.atapi_dma is gone and the kernel thinks PIO4 is the way to go; acd0: DVDR HL-DT-ST DVDRAM GSA-4040B at ata7-master PIO4 it works alright if I set it to UDMA33 using atacontrol but is there a way to make the kernel to recognize it properly in the first place? Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ufs2 crashes
I´ve been getting these crashes on a DVD-RAM filesystem which gets unmounted, newfs´d, remounted and used. No specific pattern though but they are quite frequent. Not sure if these came after or before ATAng. db trace Debugger(c03e1565,0,c03f09e4,dd7309d0,100) at Debugger+0x55 panic(c03f09e4,c45b12b0,2,0,c03f099e) at panic+0x15f ufs_dirbad(c4545578,0,c03f099e,0,dd730a4c) at ufs_dirbad+0x52 ufs_lookup(dd730b0c,dd730b48,c02901f1,dd730b0c,dd730c38) at ufs_lookup+0x447 ufs_vnoperate(dd730b0c,dd730c38,dd730c4c,1147,c4030be0) at ufs_vnoperate+0x18 vfs_cache_lookup(dd730b8c,dd730ba8,c0294ea2,dd730b8c,c4030be0) at vfs_cache_lookup+0x301 ufs_vnoperate(dd730b8c,c4030be0,0,c4030be0,c4030be0) at ufs_vnoperate+0x18 lookup(dd730c24,0,c03e5b6d,a6,c4030be0) at lookup+0x302 namei(dd730c24,dd730c44,c0360b39,c04622f4,dd730c44) at namei+0x1ee stat(c4030be0,dd730d10,c03f6ad5,3eb,2) at stat+0x52 syscall(2f,2f,2f,80d9a4c,810931c) at syscall+0x253 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (188, FreeBSD ELF32, stat), eip = 0x807bd1f, esp = 0xbfbff42c, ebp = 0xbfbff4a8 --- db panic panic: from debugger cpuid = 0; lapic.id = boot() called on cpu#0 Uptime: 10h44m8s pfs_vncache_unload(): 1 entries remaining Shutting down ACPI panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled cpuid = 0; lapic.id = boot() called on cpu#0 Uptime: 10h44m8s pfs_vncache_unload(): 1 entries remaining Shutting down ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset called on cpu#0 Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Tue Sep 2 20:43:31 EEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ROMMON-SERVER5 Preloaded elf kernel /boot/kernel/kernel at 0xc056e000. Preloaded elf module /boot/kernel/acpi.ko at 0xc056e244. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (568.59-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 536805376 (511 MB) avail memory = 51328 (491 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: VIA694 AWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00fdbc0 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 IOAPIC #0 intpin 19 - irq 2 IOAPIC #0 intpin 16 - irq 5 IOAPIC #0 intpin 17 - irq 10 IOAPIC #0 intpin 18 - irq 11 agp0: VIA 82C691 (Apollo Pro) host to PCI bridge mem 0xd000-0xd3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686B UDMA100 controller port 0xc000-0xc00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xc400-0xc41f irq 2 at device 7.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xc800-0xc81f irq 2 at device 7.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered viapropm0: SMBus I/O base at 0x5000 viapropm0: VIA VT82C686A Power Management Unit port 0x5000-0x500f at device 7.4 on pci0 viapropm0: SMBus revision code 0x40 smbus0: System Management Bus on viapropm0 smb0: SMBus generic I/O on smbus0 pci0: display, VGA at device 9.0 (no driver attached) fxp0: Intel 82550 Pro/100 Ethernet port 0xcc00-0xcc3f mem 0xdc00-0xdc01,0xdc041000-0xdc041fff irq 10 at device 10.0 on pci0 fxp0: Ethernet address 00:02:b3:8a:fb:ca miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Intel 82550 Pro/100 Ethernet port 0xd000-0xd03f mem 0xdc02-0xdc03,0xdc04-0xdc040fff irq 2 at device 12.0 on pci0 fxp1: Ethernet address 00:02:b3:8a:fd:b9
ATAng raid not being detected
ATAng does not seem to detect my RAID set, while ATAold boots it fine, first boot -v with ATAng kernel and then ATAold. Any ideas if raid configs should be compatible between them? Should make sense that they are so people upgrading don't get burned... ata2-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ad4: setting UDMA100 on Promise PDC20619 chip GEOM: create disk ad4 dp=0xc2670370 ad4: WDC WD800JB-00CRA1/17.07W17 ATA-5 disk at ata2-master ad4: 76319MB (156301488 sectors), 155061 C, 16 H, 63 S, 512 B ad4: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad4 ata3-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ad6: setting UDMA100 on Promise PDC20619 chip GEOM: create disk ad6 dp=0xc2670170 ad6: WDC WD800JB-00CRA1/17.07W17 ATA-5 disk at ata3-master ad6: 76319MB (156301488 sectors), 155061 C, 16 H, 63 S, 512 B ad6: 16 secs/int, 1 depth queue, UDMA100 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:156296322 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad4s1, start 32256 length 80023716864 end 80023749119 ata4-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin GEOM: new disk ad6 GEOM: Configure ad4s1a, start 0 length 268435456 end 268435455 GEOM: Configure ad4s1b, start 268435456 length 2147483648 end 2415919103 GEOM: Configure ad4s1c, start 0 length 80023716864 end 80023716863 GEOM: Configure ad4s1d, start 2415919104 length 536870912 end 2952790015 GEOM: Configure ad4s1e, start 2952790016 length 1073741824 end 4026531839 GEOM: Configure ad4s1f, start 4026531840 length 75997185024 end 80023716863 ad8: setting UDMA100 on Promise PDC20619 chip GEOM: create disk ad8 dp=0xc25f4e70 ad8: WDC WD800JB-00CRA1/17.07W17 ATA-5 disk at ata4-master ad8: 76319MB (156301488 sectors), 155061 C, 16 H, 63 S, 512 B ad8: 16 secs/int, 1 depth queue, UDMA100 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):512/254/63 s:63 l:156296322 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad6s1, start 32256 length 80023716864 end 80023749119 ata7-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin acd0: setting PIO4 on Promise PDC20269 chip acd0: HL-DT-ST DVDRAM GSA-4040B/A104 DVDR drive at ata7 as master acd0: read 2705KB/s (2705KB/s) write 2705KB/s (2705KB/s), 2048KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: 120mm data disc GEOM: new disk ad8 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:156296322 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad8s1, start 32256 length 80023716864 end 80023749119 GEOM: Configure ad8s1a, start 0 length 268435456 end 268435455 GEOM: Configure ad8s1b, start 268435456 length 2147483648 end 2415919103 GEOM: Configure ad8s1c, start 0 length 80023716864 end 80023716863 GEOM: Configure ad8s1d, start 2415919104 length 536870912 end 2952790015 GEOM: Configure ad8s1e, start 2952790016 length 1073741824 end 4026531839 GEOM: Configure ad8s1f, start 4026531840 length 75997185024 end 80023716863 Mounting root from ufs:/dev/ar0s1a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 Manual root filesystem specification: fstype:device Mount device using filesystem fstype eg. ufs:da0s1a ? List valid disk boot devices empty line Abort manual input ad4: success setting UDMA100 on Promise PDC20619 chip ad4: WDC WD800JB-00CRA1/17.07W17 ATA-5 disk at ata2-master ad4: 76319MB (156301488 sectors), 155061 C, 16 H, 63 S, 512 B ad4: 16 secs/int, 1 depth queue, UDMA100 ad4: piomode=12 dmamode=34 udmamode=69 cblid=1 GEOM: new disk ad4 ad6: success setting UDMA100 on Promise PDC20619 chip ad6: WDC WD800JB-00CRA1/17.07W17 ATA-5 disk at ata3-master ad6: 76319MB (156301488 sectors), 155061 C, 16 H, 63 S, 512 B ad6: 16 secs/int, 1 depth queue, UDMA100 ad6: piomode=12 dmamode=34 udmamode=69 cblid=1 ad8: success setting UDMA100 on Promise PDC20619 chip ad8: WDC WD800JB-00CRA1/17.07W17 ATA-5 disk at ata4-master ad8: 76319MB (156301488 sectors), 155061 C, 16 H, 63 S, 512 B ad8: 16 secs/int, 1 depth queue, UDMA100 ad8: piomode=12 dmamode=34 udmamode=69 cblid=1 ata7-master: piomode=12 dmamode=34 udmamode=66 dmaflag=1 ata7-master: success setting PIO4 on Promise PDC20269 chip acd0: HL-DT-ST DVDRAM GSA-4040B/A104 DVD-R drive at ata7 as master acd0: read 2705KB/s (52509KB/s) write 2705KB/s (2705KB/s), 2048KB buffer, PIO4 acd0: Reads: CD-R, CD-RW, CD-DA stream, DVD-ROM, DVD-R, DVD-RAM, packet acd0: Writes: CD-R, CD-RW, DVD-R, DVD-RAM, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked
ATAng detection issues
I also noticed that earlier ATAng spits out these messages; (cutpasting boot -v is a little tedious, but I can copy it all if it helps) The err=0x01 caught my eye. Pete atapci0: Promise PDC20619 UDMA133 controller port 0x1080-0x10ff,0x1480-0x148f,0x1000-0x107f mem 0x4020-0x4021,0x4040-0x40400fff irq 9 at device 9.0 on pci2 pcib1: device atapci0 requested decoded memory range 0x4040-0x40400fff ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ata2-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 mask=01 stat0=50 stat1=00 devices=0x1ATA_MASTER ata2: reset tp3 devices=0x1ATA_MASTER ata2: at 0x4040 on atapci0 ata3: reset tp1 mask=01 ostat0=50 ostat1=00 ata3-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 mask=01 stat0=50 stat1=00 devices=0x1ATA_MASTER ata3: reset tp3 devices=0x1ATA_MASTER ata3: at 0x4040 on atapci0 ata4: reset tp1 mask=01 ostat0=50 ostat1=00 ata4-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata4: reset tp2 mask=01 stat0=50 stat1=00 devices=0x1ATA_MASTER ata4: reset tp3 devices=0x1ATA_MASTER ata4: at 0x4040 on atapci0 ata5: reset tp1 mask=01 ostat0=20 ostat1=30 ata5-master: stat=0x20 err=0x20 lsb=0x20 msb=0x20 ata5: reset tp2 mask=01 stat0=20 stat1=00 devices=0x0 ata5-master: ATA err=0x25 lsb=0x25 ata5: reset tp3 devices=0x0 ata5: at 0x4040 on atapci0 atapci1: Promise PDC20269 UDMA133 controller port 0x1490-0x149f,0x14b4-0x14b7,0x14a8-0x14af,0x14b0-0x14b3,0x14a0-0x14a7 mem 0x4030-0x40303fff irq 10 at device 10.0 on pci2 pcib1: device atapci1 requested decoded I/O range 0x1490-0x149f pcib1: device atapci1 requested decoded I/O range 0x14a0-0x14a7 pcib1: device atapci1 requested decoded I/O range 0x14b0-0x14b3 pcib1: device atapci1 requested decoded I/O range 0x14b2-0x14b2 ata6: reset tp1 mask=03 ostat0=20 ostat1=30 ata6-master: stat=0x20 err=0x20 lsb=0x20 msb=0x20 ata6-slave: stat=0x20 err=0x30 lsb=0x30 msb=0x30 ata6: reset tp2 mask=03 stat0=20 stat1=30 devices=0x0 ata6-master: ATA err=0x25 lsb=0x25 ata6-slave: ATA err=0x25 lsb=0x25 ata6: reset tp3 devices=0x0 ata6: at 0x14a0 on atapci1 pcib1: device atapci1 requested decoded I/O range 0x14a8-0x14af pcib1: device atapci1 requested decoded I/O range 0x14b4-0x14b7 pcib1: device atapci1 requested decoded I/O range 0x14b6-0x14b6 ata7: reset tp1 mask=03 ostat0=50 ostat1=00 ata7-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata7-slave: stat=0x00 err=0x00 lsb=0x00 msb=0x00 ata7: reset tp2 mask=03 stat0=00 stat1=00 devices=0x4ATAPI_MASTER ata7: reset tp3 devices=0x4ATAPI_MASTER ata7: at 0x14a8 on atapci1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng raid not being detected
Soren Schmidt wrote: It seems Petri Helenius wrote: ATAng does not seem to detect my RAID set, while ATAold boots it fine, first boot -v with ATAng kernel and then ATAold. Any ideas if raid configs should be compatible between them? Should make sense that they are so people upgrading don't get burned... Do you have device ataraid in your config file ? (se UPDATING) -Søren I didn't, sorry about that. Is the failure below because I haven't rebuilt my world yet but just the kernel? At least it blew my array configuration away. oversized DMA does not sound like it would be caused by userland utility? Pete Timecounter TSC frequency 598008457 Hz quality 800 Timecounters tick every 10.000 msec GEOM: create disk ad4 dp=0xc2670370 ad4: 76319MB WDC WD800JB-00CRA1 [155061/16/63] at ata2-master UDMA100 GEOM: create disk ad6 dp=0xc2670070 ad6: 76319MB WDC WD800JB-00CRA1 [155061/16/63] at ata3-master UDMA100 GEOM: create disk ad8 dp=0xc25f4e70 ad8: 76319MB WDC WD800JB-00CRA1 [155061/16/63] at ata4-master UDMA100 acd0: DVDR HL-DT-ST DVDRAM GSA-4040B at ata7-master PIO4 GEOM: create disk ar0 dp=0xc25f21e0 ar0: 76319MB ATA RAID1 array [9729/255/63] status: READY subdisks: disk0 READY on ad4 at ata2-master disk1 READY on ad8 at ata4-master ar1: WARNING - mirror lost GEOM: create disk ar1 dp=0xc267c1e0 ar1: 76319MB ATA RAID1 array [9729/255/63] status: DEGRADED subdisks: disk0 READY on ad6 at ata3-master disk1 DOWN no device found for this disk Mounting root from ufs:/dev/ar0s1a Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point. ad4: FAILURE - oversized DMA transfer attempted 114688 65536 ad4: setting up DMA failed ar0: WARNING - mirror lost ad8: FAILURE - oversized DMA transfer attempted 114688 65536 ad8: setting up DMA failed ar0: ERROR - array broken cat: /bin/ls: Input/output error swapon: 20: Syntax error: word unexpected (expecting )) Starting file system checks: D: not found T: not found : not found ÐÐÐ: not found ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng raid not being detected
Soren Schmidt wrote: Oh, that one :) fixed... -Søren Do you have an idea why my SMP system would crash under heavy load, like mysql shutdown, just a reboot, etc.? The system did not have any issues before ATAng was committed. This is one of the panics; Debugger(c03ded4a,100,c03f40e5,dd88fc6c,100) at Debugger+0x55 panic(c03f40e5,bfc2930c,a4c3000,c415120c,c1512800) at panic+0x15f pmap_remove_pages(c15128b0,0,bfc0,11a,dd88fcbc) at pmap_remove_pages+0x9b exit1(c432e390,0,c03dd197,65,dd88fd40) at exit1+0x59c sys_exit(c432e390,dd88fd10,c03f4371,3eb,1) at sys_exit+0x41 syscall(2f,839002f,bfa9002f,0,) at syscall+0x253 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x286196db, esp = 0xbfbffc5c, eb p = 0xbfbffc78 --- db Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATAng hang
My first try with ATAng on -CURRENT as of 18 hours ago ended up dying around reboot. Other than this, it seems to work as expected. I don't have WITNESS or INVARIANTS on this box, but I can recompile kernel with them if it helps. # reboot Aug 28 09:24:35 rms21 reboot: rebooted by root boot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped *** HANGS HERE***, I go over and powercycle... àCopyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #6: Thu Aug 28 08:31:37 EEST 2003 CPU: Intel Pentium III (568.59-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM OV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 536805376 (511 MB) avail memory = 515559424 (491 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 atapci0: VIA 82C686B UDMA100 controller port 0xc000-0xc00f at device 7.1 on pc i0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 atapci1: HighPoint HPT370 UDMA100 controller port 0xe400-0xe4ff,0xe000-0xe003, 0xdc00-0xdc07,0xd800-0xd803,0xd400-0xd407 irq 11 at device 14.0 on pci0 ata2: at 0xd400 on atapci1 ata3: at 0xdc00 on atapci1 ad0: 9541MB Maxtor 31024H2 [19386/16/63] at ata0-master UDMA100 ad3: 117800MB IC35L120AVVA07-0 [239340/16/63] at ata1-slave UDMA100 Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: (2) 5.1-R-p2 crashes on SMP with AMI RAID and Intel 1000/Pro
Related to the em driver, 82540M has not worked since sometime in
5.1-BETA time,
I filed a pr on that a few months ago but it seems the fault might be
with PCI IRQ routing,
not the em driver itself.
Pete
Hartmann, O. wrote:
On Wed, 20 Aug 2003, Colin Faber wrote:
Hi.
I first swapped the Intel 1000/PRO server NIC into the next slot and up then the
machine seems to be 'stable'. Then, two days later, I changed the PSU to 400W
units.
I think it's a IRQ routing problem since we have had this problem (spontanous reboots)
from FreeBSD 4.0 on). Changing the slot for the NIC helped, but this is a very bad
state.
I can not remember the error message I got when the system crashed, but it lookes like
yours and I always say the amr0-text in that message. ACPI is not working on the old
TYAN Thunder 2500 (S1867) main PCB.
I also changed machdep.cpu_idle_hlt = 0, but with no effect.
At the moment, I do not dare swapping the NIC again due to the fact the machine is in
a preliminary production state.
I also realized some weird things when creating and deleting files when the system
crashed.
Crashes always could be forced by accessing samba services from a PC. Crashes always
occured when heavy IO was done, but this also could be a evidence for an IRQ problem,
I think.
I do not know. The machine was 'stable' (it means: when the NIC was at the
crash-causing
slot) a whole night, but whenever our department 'got started' in the morning time and
heavy
IO was done, the machine froze. This changed when I swapped the NIC to another slot
And now I also have two 400W PSUs.
FreeBSD 5.1-p2 on the TYAN S1867 seems to have much more problems, but I do not know
whether I
should mention this here. truss for instance crashes. We use afbackup for backing up,
but
afbackup core dumps on this machine and it does not on a UP machine also running
FreeBSD 5.1-p2.
It also crashes on a UP kernel on this machine.
I tried to 'truss' an afrestore call, but I had to start the tracing three or four
times
because I got this error first time:
truss: PIOCWAIT: Input/output error
or something like this
root: /usr/local/samba/lib: truss -fae -o /tmp/afrestore afrestore -v -p
/usr/homes/kurs* -C /
truss: PIOCWAIT top of loop: Input/output error
truss: PIOCWAIT top of loop: Input/output error
truss: PIOCWAIT top of loop: Input/output error
truss: PIOCWAIT top of loop: Input/output error
or sometimes truss stops lacking in a /proc/PID-XXX/mem file.
But calling it more times will 'solve' the problem.
While writing this, I crashed the system with the above showed command, this is the
error message from the kernel when the system froze (I wrote it down from the screen):
Fatal trap 12 : page fault while in kernel mode
cpuid = 1; lapic.id =
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01b29db
stack pointer = 0x10:0xe8ff3b70
frame pointer = 0x10:0xe8ff3b84
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def 32, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 27510 (bunzip2)
trap number = 12
panic: page fault
cpuid = 1, lapic.id =
boot() called on cpu#1
syncing disks, buffers remaining ... panic: absolutely cannot call
smp_ipi_shutdown with interrupts already disabled
cpuid = 1; lapic.id =
boot() called on cpu#1
Uptime 1d20h18m55s
pfs_vncache_unload(): 6 entried remaining
Fatal double fault:
eip = 0xc03134ic
esp = 0xe8ff1ff8
ebp = 0xe8ff2014
cpuid = 1, lapic.id =
panic: double fault
cpuid = 1, lapic.id =
boot() called on cpu#1
Uptime: 1d20h18m55s
pfs_vncache_unload(): 6 entries remaining
After this, the machine was dead.
:Hi,
:
:I've got nearly the same setup in a Dell 1600SC with a gig of ram and a PERC4/Sc
(LSI MegaRAID) card.
:
:Dual 2.4GHz Xeon P4 HT CPU's and I've discovered I can lock up FreeBSD
5.1-RELEASE-p2 on command
:simply by running something to quickly create and remove a directory. i.e.:
:
: perl -e 'for(my $i = 0 ; $i ; $i++){ mkdir(abc); rmdir(abc); }'
:
:
:Having machdep.cpu_idle_hlt = 0 makes no difference.
:
:
:Kernel:
: FreeBSD 5.1-RELEASE-p2 FreeBSD 5.1-RELEASE-p2 #0: Mon Aug 11 21:40:47 MDT 2003
i386
:
:Raid:
: amr0: LSILogic MegaRAID mem 0xfcd0-0xfcd0 irq 3 at device 2.0 on pci1
: amrd0: LSILogic MegaRAID logical drive on amr0
: amrd0: 34556MB (70770688 sectors) RAID 5 (optimal)
:
:
:I suspect that your and my problems are more driver related to the amr driver and
may be exposing
:some other problem with in the kernels fs locking. I don't think (as others have
suggested) that
:your issue is power related, or related to the combination of hardware you're using.
(Other than
:the fact that you've got a MegaRAID card).
:
:The exact crash message I'm seeing is:
:
:panic: lockmgr:
Re: pci configuration
On Tue, 12 Aug 2003, Petri Helenius wrote: Is there way to view PCI / PCI-X configuration with bus-width and clock values when FreeBSD has already booted? If you know where in PCI config space to look you could use pciconf to query it. Can't say I've heard of PCI speed negotiation issues, though. I haven´t exactly had issues but every now and then somebody puts in a 32/33 card into a bus which is shared with motherboard components effectively killing performance. At this time, if I understand correctly, there is no instrumentation in the OS to figure out what´s going on, so physical inspection is neccessary instead of just making a piece of software beep to the IT monkey to go and pull the junk out. Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
pci configuration
Is there way to view PCI / PCI-X configuration with bus-width and clock values when FreeBSD has already booted? Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pci configuration
I'm not aware of any registers in the standard PCI config space that will tell you the speed of the bus. Some PCI devices will make that information available, but not in a standard way. The BIOS of some higher-end systems might also tell you this information. How about the busmaster parameters like PCI latency timer, etc? Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pci configuration
True, those parameters are available, but the original question was about reporting the bus width and frequency, which are not available. How can these parameters be displayed? (whether the original question was only for the specifically mentioned parameters is actually matter of semantics, because it used the word with instead of of, if I understand my english correctly. I could have been clearer though, so my apologies) Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
AP 3 failed
When using console redirection on SE7505VB2 Intel board I seem to get occasional failures on starting the second core of the second CPU. Also, on the same board, including device ichsmb on kernel config will result in hang on boot 100%. The sources are from yesterday. /boot/kernel/acpi.ko text=0x3c8bc data=0x16ec+0xec0 syms=[0x4+0x5b50+0x4+0x798e] Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #5: Sun Aug 3 14:17:10 EEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ROMMON-SERVER Preloaded elf kernel /boot/kernel/kernel at 0xc05c7000. Preloaded elf module /boot/kernel/acpi.ko at 0xc05c72bc. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 2392039876 Hz CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2392.04-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 2146893824 (2047 MB) avail memory = 2083590144 (1987 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 24 pins in IOAPIC #1 Programming 24 pins in IOAPIC #2 AP #3 (PHY# 7) failed! Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sil3112 controller
Should there be an option to run atacontrol in sysinstall? So that drives could be assigned to a mirror / stripe set before installing without having to build the mirror on another machine first? (in this case the BIOS does not help) Pete - Original Message - From: Soeren Schmidt [EMAIL PROTECTED] It seems Petri Helenius wrote: Just saw the support for the controller go in. Does the driver support any RAID1 style mirroring? Only our own ATA RAID (see atacontrol).. I do have an Adaptec 1210 that has RAID capabilities and I have deciphered their RAID config info, but support is not finished yet. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sil3112 controller
Soeren Schmidt wrote: So that drives could be assigned to a mirror / stripe set before installing without having to build the mirror on another machine first? (in this case the BIOS does not help) You cant boot from a stripe on a controller that doesn't have a BIOS to do it. Sure, but I can boot off a mirror, which I actually do in a few cases. Most ATA RAID controllers seem to be targeted towards home-user and thus do not support unattended operation. I just can't create the mirror while installing. I just wish there would either be more functionality in the twe driver or somebody would come out with 8-12 port SATA controller. Looking at the issues for example the Adaptec SCSI RAIDs have, it seems SATA will take them over quite quickly. Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sil3112 controller
Christian Brueffer wrote: On Sat, Aug 02, 2003 at 11:19:48AM +0300, Petri Helenius wrote: I just wish there would either be more functionality in the twe driver or somebody would come out with 8-12 port SATA controller. Looking at the issues for example the Adaptec SCSI RAIDs have, it seems SATA will take them over quite quickly. FYI, 3ware sells 8 and 12 port SATA controllers. - Christian Sure, but the visibility for the array from the operating system is zero with the twe driver? Or am I missing an utility? Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
sil3112 controller
Just saw the support for the controller go in. Does the driver support any RAID1 style mirroring? Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
bsdlabel warnings
Is this normal that multiple installations of 5.1-RELEASE complain when running bsdlabel: # /dev/ad0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 524288 634.2BSD 2048 16384 32776 b: 4194304 524351 swap c: 39102273 63unused0 0 # raw part, don't edit d: 1048576 47186554.2BSD 2048 16384 8 e: 5105 57672314.2BSD 2048 16384 28552 partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition e: partition extends past end of unit This does not seem to happen if the disk has been labeled by previous versions and upgraded from source. Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bsdlabel warnings
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Petri Helenius writes: Is this normal that multiple installations of 5.1-RELEASE complain when running bsdlabel: # /dev/ad0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 524288 634.2BSD 2048 16384 32776 b: 4194304 524351 swap c: 39102273 63unused0 0 # raw part, don't edit d: 1048576 47186554.2BSD 2048 16384 8 e: 5105 57672314.2BSD 2048 16384 28552 partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition e: partition extends past end of unit This does not seem to happen if the disk has been labeled by previous versions and upgraded from source. That sounds interesting. Can you send me the outout of: diskinfo /dev/ad0* sysctl -b kern.geom.confxml I have more than one machine which seems to have this, but there is one set of outputs; /dev/ad0512 20020396032 3910233638792 16 63 /dev/ad0s1 512 20020363776 3910227338791 16 63 /dev/ad0s1a 512 268435456 524288 520 16 63 /dev/ad0s1b 512 2147483648 4194304 416116 63 /dev/ad0s1c 512 20020363776 3910227338791 16 63 /dev/ad0s1d 512 536870912 1048576 104016 63 /dev/ad0s1e 512 17067573760 510533070 16 63 mesh class id=0xc052dba0 nameDEV/name geom id=0xc63e2480 class ref=0xc052dba0/ namead0s1e/name rank4/rank consumer id=0xc62379c0 geom ref=0xc63e2480/ provider ref=0xc63e3d00/ moder1w1e0/mode /consumer /geom geom id=0xc63e3d80 class ref=0xc052dba0/ namead0s1d/name rank4/rank consumer id=0xc6237b00 geom ref=0xc63e3d80/ provider ref=0xc63e3880/ moder1w1e0/mode /consumer /geom geom id=0xc6415000 class ref=0xc052dba0/ namead0s1c/name rank4/rank consumer id=0xc6237c00 geom ref=0xc6415000/ provider ref=0xc63e3980/ moder0w0e0/mode /consumer /geom geom id=0xc63e3b00 class ref=0xc052dba0/ namead0s1b/name rank4/rank consumer id=0xc6237d40 geom ref=0xc63e3b00/ provider ref=0xc63e3a80/ moder1w1e0/mode /consumer /geom geom id=0xc63e3e00 class ref=0xc052dba0/ namead0s1a/name rank4/rank consumer id=0xc6237e40 geom ref=0xc63e3e00/ provider ref=0xc63e3b80/ moder1w1e0/mode /consumer /geom geom id=0xc63e3e80 class ref=0xc052dba0/ namead0s1/name rank3/rank consumer id=0xc641c000 geom ref=0xc63e3e80/ provider ref=0xc6415080/ moder0w0e0/mode /consumer /geom geom id=0xc63e2400 class ref=0xc052dba0/ namead0/name rank2/rank consumer id=0xc6221d00 geom ref=0xc63e2400/ provider ref=0xc63e2500/ moder0w0e0/mode /consumer /geom /class class id=0xc0570e60 nameMBREXT/name /class class id=0xc0570e20 nameMBR/name geom id=0xc63e2380 class ref=0xc0570e20/ namead0/name rank2/rank config /config consumer id=0xc6221c80 geom ref=0xc63e2380/ provider ref=0xc63e2500/ moder4w4e2/mode config /config /consumer provider id=0xc6415080 geom ref=0xc63e2380/ moder4w4e1/mode namead0s1/name mediasize20020363776/mediasize sectorsize512/sectorsize config index0/index length20020363776/length seclength39102273/seclength offset32256/offset secoffset63/secoffset type165/type /config /provider /geom /class class id=0xc0570d60 nameBSD/name geom id=0xc63e3c00 class ref=0xc0570d60/ namead0s1/name rank3/rank config labeloffset512/labeloffset rawoffset32256/rawoffset mbroffset32256/mbroffset /config consumer id=0xc6237ec0 geom ref=0xc63e3c00/ provider ref=0xc6415080/ moder4w4e1/mode config /config /consumer provider id=0xc63e3d00 geom ref=0xc63e3c00/ moder1w1e0/mode namead0s1e/name mediasize17067573760/mediasize sectorsize512/sectorsize config index4/index length17067573760/length seclength5105/seclength offset2952790016/offset secoffset5767168/secoffset type7/type /config /provider provider id=0xc63e3880 geom ref=0xc63e3c00/ moder1w1e0/mode
ata raid crash
It seems that the ata driver still has some issues with configuring the RAID devices. Sources cvsupped today. Pete Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #11: Mon Jul 14 12:22:00 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/EMTEST Preloaded elf kernel /boot/kernel/kernel at 0xc04d7000. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 598009854 Hz CPU: Intel Celeron (598.01-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 267386880 (255 MB) avail memory = 254500864 (242 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00e8790 pcib0: Intel 82815 (i815 GMCH) Host To Hub bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pci_cfgintr: 0:2 INTA BIOS irq 5 pci_cfgintr: 0:31 INTD BIOS irq 11 pci_cfgintr: 0:31 INTB BIOS irq 9 agp0: Intel 82815 (i815 GMCH) SVGA controller mem 0x4070-0x4077,0x4400-0x47ff irq 5 at device 2.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 30.0 on pci0 pci2: PCI bus on pcib1 pci_cfgintr: 2:8 INTA BIOS irq 5 pci_cfgintr: 2:8 INTB BIOS irq 9 pci_cfgintr: 2:9 INTA BIOS irq 9 pci_cfgintr: 2:10 INTA BIOS irq 10 pci2: network, ethernet at device 8.0 (no driver attached) pci2: network, ethernet at device 8.1 (no driver attached) atapci0: Promise PDC20619 UDMA133 controller port 0x1080-0x10ff,0x1480-0x148f,0x1000-0x107f mem 0x4020-0x4021,0x4040-0x40400fff irq 9 at device 9.0 on pci2 ata2: at 0x4040 on atapci0 ata3: at 0x4040 on atapci0 ata4: at 0x4040 on atapci0 ata5: at 0x4040 on atapci0 atapci1: Promise PDC20269 UDMA133 controller port 0x1490-0x149f,0x14b4-0x14b7,0x14a8-0x14af,0x14b0-0x14b3,0x14a0-0x14a7 mem 0x4030-0x40303fff irq 10 at device 10.0 on pci2 ata6: at 0x14a0 on atapci1 ata7: at 0x14a8 on atapci1 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci2: Intel ICH UDMA66 controller port 0x2460-0x246f at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci2 ata1: at 0x170 irq 15 on atapci2 uhci0: Intel 82801AA (ICH) USB controller port 0x2440-0x245f irq 11 at device 31.2 on pci0 usb0: Intel 82801AA (ICH) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: multimedia, audio at device 31.5 (no driver attached) orm0: Option ROMs at iomem 0xe-0xe,0xd1800-0xd3fff,0xca000-0xd17ff,0xc-0xc9fff on isa0 pmtimer0 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0: parallel port not found. sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x100 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ppc1: parallel port not found. unknown: PNP0501 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0303 can't assign resources (port) Timecounters tick every 10.000 msec ad4: 76319MB WDC WD800JB-00CRA1 [155061/16/63] at ata2-master UDMA100 ad6: 76319MB WDC WD800JB-00CRA1 [155061/16/63] at ata3-master UDMA100 ad8: 76319MB WDC WD800JB-00CRA1 [155061/16/63] at ata4-master UDMA100 ad12: 76319MB WDC WD800JB-00CRA1 [155061/16/63] at ata6-master UDMA100 ar0: 76319MB ATA RAID1 array [9729/255/63] status: READY subdisks: disk0 READY on ad4 at ata2-master disk1 READY on ad8 at ata4-master ar1: WARNING - mirror lost ar1: 76319MB ATA RAID1 array [9729/255/63] status: DEGRADED subdisks: disk0 READY on ad6 at ata3-master disk1 DOWN no device found for this disk ar2: WARNING - mirror lost ar2: 76319MB ATA RAID1 array [9729/255/63] status: DEGRADED subdisks: disk0 DOWN no device found for this disk disk1 READY on ad12 at ata6-master Opened disk ad4 - 1 Opened disk ad4 - 1 Opened disk ad4 - 1 Opened disk ad4 - 1 Opened disk ad6 - 1 Opened disk ad6 - 1 Opened disk ad8 - 1 Opened disk ad8 - 1 Opened disk ad12 - 1 Opened disk ad12 - 1 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0161106 stack pointer = 0x10:0xcd22ebd4
5.1 install failure
I´m booting 5.1 install in IBM x342 with floppies (because the thing does not seem to want to boot from the CD-ROM) and when sysinstall goes into probing devices, I get a message about / filesystem being full and I´m going nowhere without my init and then the kernel panics. Any ideas how to proceed? Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Twin CPU machine running with only one cpu?
The CPUs you see are the two logical cores of one of your CPUs. The kernel HLTs one of them by default due to performance issues when running certain loads on hypethreading. Pete - Original Message - From: Brendon and Wendy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 8:17 AM Subject: Twin CPU machine running with only one cpu? Dear All, Just installed 5.1 RC1 on my Dual Prestonia Xeon box. Works great. In fact this is the first time i've had much success with the 5.x branch. Anyway, heres my question. Despite the fact that I've recompiled my kernel with SMP and IOAPIC enabled, I seem to have only one CPU running. At boot time the kernel reports starting CPU#1 at the end of boot time. The machdep.* systctls claim that I have two cpus, but no matter what I do I cannot get the CPU load over 48% (for instance running two c programs that loop infinitely with no delay)! Running top shows the C column that one only normally gets in SMP mode. However all processes are assigned to CPU zero. Is it possible that the system is using two cores on one CPU only? HTT is disabled in the BIOS... I've tried with/without ACPI. MPS 1.1/1.4/upgrading to this evenings current with no change (did not do a buildworld after current might start one when this mail is sent). The machine is a SuperMicro p4dce+. It has run SMP normally in 4.8 as well as older revisions of 5.x (where is tended to panic a lot!). Exerpts from boot process, top and sysctl are below. Thanks for any clues or suggestions. Regards, Brendon /- / top /- last pid: 1232; load averages: 0.01, 0.11, 0.13up 0+00:18:34 22:12:15 43 processes: 3 running, 40 sleeping CPU states: 0.5% user, 0.0% nice, 0.5% system, 0.2% interrupt, 98.8% idle Mem: 105M Active, 116M Inact, 58M Wired, 1120K Cache, 60M Buf, 215M Free Swap: 1003M Total, 1003M Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 1158 brendy960 26948K 22716K select 0 0:02 0.05% 0.05% kdeinit 955 root 960 276M 31060K RUN0 0:09 0.00% 0.00% XFree86 1160 brendy960 36444K 31620K select 0 0:07 0.00% 0.00% kmail 1112 brendy960 27180K 22352K select 0 0:04 0.00% 0.00% kdeinit 1182 brendy960 35776K 31140K select 0 0:02 0.00% 0.00% kdeinit 1140 brendy60 -36 8308K 7512K select 0 0:02 0.00% 0.00% artsd 1150 brendy960 29116K 24360K select 0 0:01 0.00% 0.00% kdeinit 1148 brendy960 27924K 23748K select 0 0:01 0.00% 0.00% kdeinit 1146 brendy960 27180K 22500K select 0 0:01 0.00% 0.00% kdeinit 953 root 960 2336K 1672K select 0 0:01 0.00% 0.00% top 1213 brendy960 28172K 23336K RUN0 0:00 0.00% 0.00% kdeinit 1154 brendy960 26316K 21720K select 0 0:00 0.00% 0.00% kdeinit 1156 brendy960 25596K 20736K select 0 0:00 0.00% 0.00% kdeinit 1142 brendy960 29284K 23956K select 0 0:00 0.00% 0.00% kdeinit 1145 brendy960 25496K 20556K select 0 0:00 0.00% 0.00% kdeinit 1103 brendy960 23676K 18376K select 0 0:00 0.00% 0.00% kdeinit 1106 brendy960 23372K 18044K select 0 0:00 0.00% 0.00% kdeinit /- / dmesg /- Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #1: Mon Jun 9 21:41:13 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP Preloaded elf kernel /boot/kernel/kernel at 0xc0794000. Preloaded elf module /boot/kernel/linux.ko at 0xc07941f4. Preloaded elf module /boot/kernel/acpi.ko at 0xc07942a0. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1982523548 Hz CPU: Intel(R) XEON(TM) CPU 2.00GHz (1982.52-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf24 Stepping = 4 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HT T,TM Hyperthreading: 2 logical CPUs real memory = 536805376 (511 MB) avail memory = 513204224 (489 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 Pentium Pro MTRR support
Re: 5.1-BETA em
There... http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/52835 Pete - Original Message - From: Robert Watson [EMAIL PROTECTED] To: Petri Helenius [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, May 15, 2003 9:54 PM Subject: Re: 5.1-BETA em Could you file a PR for this, if it hasn't already been resolved? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Fri, 9 May 2003, Petri Helenius wrote: I installed 5.0-RELEASE on an X31 IBM laptop and em0 worked. (1.4.x driver) Then I cvsupped -CURRENT two days ago and now the em0 probe only displays: em0: Intel(R) PRO/1000 Network Connection, Version - 1.5.31 port 0x8000-0x803f mem 0xc020-0xc020, 0xc022-0xc023 irq 11 at device 1.0 on pci2 em0: The EEPROM Checksum Is Not Valid em0: Unable to initialize the hardware The chip is supposedly Intel mobile GE, and the machine has Win XP as dual booth with FreeBSD. Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RELENG_4 to RELENG_5_1
I'm trying to upgrade RELENG_4 to RELENG_5_1 using source and make buildworld compiles a while and then stops with: Question is if this is supported and if yes, what should I do differently? Pete cc -fpic -DPIC -O -pipe -mcpu=pentiumpro -DPTHREAD_KERNEL -I/usr/src/lib/libpthread/../libc/include -I/usr/src/lib/libpthread/thread -I/usr/src/lib/libpthread/../../include -I/usr/src/lib/libpthread/arch/i386/include -I/usr/src/lib/libpthread/sys -I/usr/src/lib/libpthread/../../libexec/rtld-elf -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -c /usr/src/lib/libpthread/sys/lock.c -o lock.So building shared library libkse.so.1 thr_libc.So: In function `sigaction': thr_libc.So(.text+0x54): multiple definition of `_sigaction' thr_sigaction.So(.text+0x0): first defined here thr_libc.So: In function `sigprocmask': thr_libc.So(.text+0x34): multiple definition of `_sigprocmask' thr_sigprocmask.So(.text+0x0): first defined here *** Error code 1 Stop in /usr/src/lib/libpthread. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
Sent to you, Mark and obrien on 15th May. Didn´t copy lists nor did a send-pr. Suggestions for future bug reporting appreciated. Ouch, this is a serious bug indeed. I apologize if you reported this before and I missed it. I'll look at it today. Other than this bug (which appears to only be related to the management app), are there any other problems with aac? Note that aac is one of the few cards that even supports a management app! I returned the card, they only had 14 day return policy. I didn´t spend more time with the card since after reporting the bug I didn´t get any replies and without a management utility the card would be useless for me anyway. I´ll ask them for another loaner if needed. While we´re at it, what´s the utility command to turn off the alarm on the card? It got annoying after a while practising pulling out drives :-) Pete Scott Petri Helenius wrote: So far I´ve tried asr and aac, both cards end up in kernel panics and/or array hang in a few minutes (multiple hardware platforms so I don´t think the motherboard is to blame) After the bad experience with asr I thought I give aac a try with somewhat similar results. And asr does not work with 4G machines anyway (although I don´t put that amount of memory in the servers now, I don´t want to generate a barrier because of a disk controller) Judging from the limited set of responses, Mylex stuff seems to work. My offer to help you to debug the aac code is still valid. You mean this one as shot in the dark? I got this when configuring an array on 5.1-BETA and aaccli: lock order reversal 1st 0xc2671134 AAC sync FIB lock (AAC sync FIB lock) @ /usr/src/sys/dev/aac/aac.c:1703 2nd 0xc03f5f20 Giant (Giant) @ vm/vm_fault.c:210 Stack backtrace: backtrace(c0397297,c03f5f20,c0393ecb,c0393ecb,c03a4e34) at backtrace+0x17 witness_lock(c03f5f20,8,c03a4e34,d2,d1d33ad8) at witness_lock+0x697 _mtx_lock_flags(c03f5f20,0,c03a4e2b,d2,2) at _mtx_lock_flags+0xb1 vm_fault(c03f1940,0,1,0,c267) at vm_fault+0x59 trap_pfault(d1d33c70,0,8,d1d33c40,8) at trap_pfault+0xef trap(18,c2670010,c2670010,d26402a4,c2671000) at trap+0x39d calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc24e5959, esp = 0xd1d33cb0, ebp = 0xd1d33ce0 --- aac_handle_aif(c2671000,d2640284,d1d33cfc,d1d33d00,7d0) at aac_handle_aif+0x139 aac_command_thread(c2671000,d1d33d48,c0392341,310,0) at aac_command_thread+0x179 fork_exit(c24e36c0,c2671000,d1d33d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xd1d33d7c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc31f3959 stack pointer = 0x10:0xd1d39cb0 frame pointer = 0x10:0xd1d39ce0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 550 (aac0aif) kernel: type 12 trap, code=0 Stopped at aac_handle_aif+0x139: cmpl0x8(%edx),%ecx db trace aac_handle_aif(c2679000,d2635284,d1d39cfc,d1d39d00,7d0) at aac_handle_aif+0x139 aac_command_thread(c2679000,d1d39d48,c0392341,310,c2670260) at aac_command_thread+0x179 fork_exit(c31f16c0,c2679000,d1d39d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xd1d39d7c, ebp = 0 --- db Before that I got some message on GEOM not being properly locked but that scrolled off buffer before I could catch it. Pete - Original Message - From: Scott Long [EMAIL PROTECTED] To: Petri Helenius [EMAIL PROTECTED] Cc: Tim Robbins [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, June 01, 2003 11:20 PM Subject: Re: raidframe Petri Helenius wrote: RAIDframe is non-functional in 5.1 and -current [kern/50541] and it would be unwise to use it in 5.0 for anything other than experimentation. Hopefully it will be fixed before 5.2. Makes one wonder how broken code ever got into the tree in the first place... Pete Just settle down a bit. If you rewind to last October, RAIDFrame worked well. Unfortunately, some kernel interfaces changed in between now and then and RAIDFrame was left behind. I am remis in not fixing it, but please understand that I also have quite a few other responsibilities, and I get paid $0 to work on RAIDframe. As for hardware raid, what cards have you tried, and what problems have you experienced? You last message was jsut a shot in the dark that few of us would be able to help with. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
RAIDframe is non-functional in 5.1 and -current [kern/50541] and it would be unwise to use it in 5.0 for anything other than experimentation. Hopefully it will be fixed before 5.2. Makes one wonder how broken code ever got into the tree in the first place... Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
So far I´ve tried asr and aac, both cards end up in kernel panics and/or array hang in a few minutes (multiple hardware platforms so I don´t think the motherboard is to blame) After the bad experience with asr I thought I give aac a try with somewhat similar results. And asr does not work with 4G machines anyway (although I don´t put that amount of memory in the servers now, I don´t want to generate a barrier because of a disk controller) Judging from the limited set of responses, Mylex stuff seems to work. My offer to help you to debug the aac code is still valid. You mean this one as shot in the dark? I got this when configuring an array on 5.1-BETA and aaccli: lock order reversal 1st 0xc2671134 AAC sync FIB lock (AAC sync FIB lock) @ /usr/src/sys/dev/aac/aac.c:1703 2nd 0xc03f5f20 Giant (Giant) @ vm/vm_fault.c:210 Stack backtrace: backtrace(c0397297,c03f5f20,c0393ecb,c0393ecb,c03a4e34) at backtrace+0x17 witness_lock(c03f5f20,8,c03a4e34,d2,d1d33ad8) at witness_lock+0x697 _mtx_lock_flags(c03f5f20,0,c03a4e2b,d2,2) at _mtx_lock_flags+0xb1 vm_fault(c03f1940,0,1,0,c267) at vm_fault+0x59 trap_pfault(d1d33c70,0,8,d1d33c40,8) at trap_pfault+0xef trap(18,c2670010,c2670010,d26402a4,c2671000) at trap+0x39d calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc24e5959, esp = 0xd1d33cb0, ebp = 0xd1d33ce0 --- aac_handle_aif(c2671000,d2640284,d1d33cfc,d1d33d00,7d0) at aac_handle_aif+0x139 aac_command_thread(c2671000,d1d33d48,c0392341,310,0) at aac_command_thread+0x179 fork_exit(c24e36c0,c2671000,d1d33d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xd1d33d7c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc31f3959 stack pointer = 0x10:0xd1d39cb0 frame pointer = 0x10:0xd1d39ce0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 550 (aac0aif) kernel: type 12 trap, code=0 Stopped at aac_handle_aif+0x139: cmpl0x8(%edx),%ecx db trace aac_handle_aif(c2679000,d2635284,d1d39cfc,d1d39d00,7d0) at aac_handle_aif+0x139 aac_command_thread(c2679000,d1d39d48,c0392341,310,c2670260) at aac_command_thread+0x179 fork_exit(c31f16c0,c2679000,d1d39d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xd1d39d7c, ebp = 0 --- db Before that I got some message on GEOM not being properly locked but that scrolled off buffer before I could catch it. Pete - Original Message - From: Scott Long [EMAIL PROTECTED] To: Petri Helenius [EMAIL PROTECTED] Cc: Tim Robbins [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, June 01, 2003 11:20 PM Subject: Re: raidframe Petri Helenius wrote: RAIDframe is non-functional in 5.1 and -current [kern/50541] and it would be unwise to use it in 5.0 for anything other than experimentation. Hopefully it will be fixed before 5.2. Makes one wonder how broken code ever got into the tree in the first place... Pete Just settle down a bit. If you rewind to last October, RAIDFrame worked well. Unfortunately, some kernel interfaces changed in between now and then and RAIDFrame was left behind. I am remis in not fixing it, but please understand that I also have quite a few other responsibilities, and I get paid $0 to work on RAIDframe. As for hardware raid, what cards have you tried, and what problems have you experienced? You last message was jsut a shot in the dark that few of us would be able to help with. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
If you rewind to last October, RAIDFrame worked well. Unfortunately, some kernel interfaces changed in between now and then and RAIDFrame was left behind. I am remis in not fixing it, but please understand that I also have quite a few other responsibilities, and I get paid $0 to work on RAIDframe. Not being a native english speaker I probably didn´t understand that experimental equals broken. If that equation cannot be justified, then the release notes should have said has critical defects or broken, not just experimental. I appreciate the work you and everybody else puts in, it just does not make sense to have people go through the same hoops and hit the wall when that could be saved by a single line noting that that the wall exists. Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
FreeBSD 5.x series is slowly progressing, but is nowhere near to production quality. As the things are currently, you simply waste your time. This is only my opinion and I don't want to offend anyone. IMO, software does not magically get better but it must be actively being used and problems reported and fixed in reasonable time. So if 5.x never gets users it never gets production quality. Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
halt thread / mmap chatter
Got the chatter below on a box which had some libkse and some mmap activity when it got shutdown. Built from morning of 30th May sources. Pete May 30 08:56:08 kompak halt: hallted by root ock order reversal 1st 0xc3335aa8 sigacts (sigacts) @ kern/subr_trap.c:248 2nd 0xc3347d88 process lock (process lock) @ kern/kern_thread.c:1453 Stack backtrace: backtrace(c0394b65,c3347d88,c039176d,c039176d,c0392acc) at backtrace+0x17 witness_lock(c3347d88,8,c0392acc,5ad,0) at witness_lock+0x697 _mtx_lock_flags(c3347d88,0,c0392ac3,5ad,c3347d20,c3347d88,4000,0,0,0) at _mtx_lock_flags+0xb1 thread_signal_add(c3327390,f,c0392177,85e,80e1310) at thread_signal_add+0xe1 postsig(f,0,c0394609,f8,20800) at postsig+0x356 ast(d2f53d48) at ast+0x46f doreti_ast() at doreti_ast+0x17 Mem1: promiscuous mode disabled lock order reversal 1st 0xc3351818 vm object (vm object) @ vm/vm_object.c:512 2nd 0xc082f110 system map (system map) @ vm/vm_kern.c:325 Stack backtrace: backtrace(c0394b65,c082f110,c03a2bf2,c03a2bf2,c03a2a96) at backtrace+0x17 witness_lock(c082f110,8,c03a2a96,145,0) at witness_lock+0x697 _mtx_lock_flags(c082f110,0,c03a2a8d,145,3) at _mtx_lock_flags+0xb1 _vm_map_lock(c082f0b0,c03a2a8d,145,d2f53a40,c0211354) at _vm_map_lock+0x36 kmem_malloc(c082f0b0,1000,101,d2f53aac,c030ea00) at kmem_malloc+0x66 page_alloc(c083a240,1000,d2f53a9f,101,c03c48cc) at page_alloc+0x27 slab_zalloc(c083a240,101,c03a442f,66f,c083a924) at slab_zalloc+0x150 uma_zone_slab(c083a240,101,c03a4426,66f,0) at uma_zone_slab+0xd8 uma_zalloc_internal(c083a240,0,101,6ef,0) at uma_zalloc_internal+0x55 uma_zfree_arg(c083a900,c3368000,0,d2f53b54,c02f68d8) at uma_zfree_arg+0x2cb dev_pager_putfake(c3368000,0,c03a22ce,bc,c3351818) at dev_pager_putfake+0x3a dev_pager_dealloc(c3351818,1,c03a4335,10b,0) at dev_pager_dealloc+0xc8 vm_pager_deallocate(c3351818,0,c03a3523,25e,c03f8848) at vm_pager_deallocate+0x3d vm_object_terminate(c3351818,0,c03a3523,200,c28b5834) at vm_object_terminate+0x1f4 vm_object_deallocate(c3351818,c28b5834,c3351818,c28b5834,d2f53c24) at vm_object_deallocate+0x20f vm_map_entry_delete(c28cbd00,c28b5834,c03a2c60,86e,c03904ed) at vm_map_entry_delete+0x3b vm_map_delete(c28cbd00,0,bfc0,c28cbd00,c2677280) at vm_map_delete+0x453 vm_map_remove(c28cbd00,0,bfc0,111,c0392177) at vm_map_remove+0x58 exit1(c3327390,9,c0392177,8d8,1) at exit1+0x626 sigexit(c3327390,9,c0392177,865,0) at sigexit+0x1a7 postsig(9,0,c0394609,f8,20800) at postsig+0x164 ast(d2f53d48) at ast+0x46f doreti_ast() at doreti_ast+0x17 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks, buffers remaining... 10 10 6 5 5 done Uptime: 2h40m11s The operating system has halted. Please press any key to reboot. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
raidframe
Is there anyone actually successfully using raidframe and if yes, what kind of hardware? Same question goes for any recent SCSI RAID controllers supported by FreeBSD. I admit not having tried all combinations but it seems that using anything else than simple ahc scsi stuff results in kernel panic with 5.x. Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbuf cache
If you are asking for paper references, then I can at least tell you where to start; go to: http://citeseer.nj.nec.com/cs and look for Jeff Mogul, DEC Western Research Laboratories, Mohit Aron, Peter Druschel, Sally Floyd, Van Jacobson, SCALA, TCP Rate halving, Receiver Livelock, RICE University, Duke University, University of Utah. That will at least get you most of the papers. Then follow the references to the other papers. These seem quite network-heavy, I was more interested in references of SMP stuff and how the coherency is maintained and what is the overhead of maintaining the coherency in read/write operations and how alignment helps/screws you with different word-sizes in IA32 architechture. Writing a coarse SMP memory benchmark should be easy, I wonder if it has been done? Judging from the profiling I´ve done on both kernel and userland things, copying memory around is among the most expensive things to do in modern multi-GHz machines. Doing arithmetic to decrease memory bandwidth requirements pays off very well. The thing I´m still wondering about is how expensive is writing compared to reading. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mbuf cache
You can get to this same point in -CURRENT, if you are using up to date sources, by enabling direct dispatch, which disables NETISR. This will help somewhat more than polling, since it will remove the normal timer latency between receipt of a packet, and processing of the packet through the networks stack. This should reduce overall pool retention time for individual mbufs that don't end up on a socket so_rcv queue. Because interrupts on the card are not acknowledged until the code runs to completion, this also tends to requlate interupt load. My source seems to be a few days older than when this stuff went in, will update and try it out. This also has the desirable side effect that stack processing will occur on the same CPU as the interrupt processing occurred. This avoids inter-CPU memory bus arbitration cycles, and ensures that you won't engage in a lot of unnecessary L1 cache busting. Hence I prefer this method to polling. Anywhere I could read up on the associated overhead and how the whole stuff works out in the worst case where data is DMAd into memory, read up to CPU1 and then to CPU2 and then discarded and if there would be any roads that can be taken to optimize this. You will get much better load capacity scaling out of two cheaper boxes, if you implement correctly, IMO. Synchronization of the unformatted data can probably never get as good as it gets if you optimize the system for your case. But I agree it should be better than it is now, however it does not really seem to get any better. (unless you consider the EV7 and Opteron approaches better than the current Intel approach) Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mbuf cache
Terry Lambert wrote: Ah. You are receiver livelocked. Try enabling polling; it will help up to the first stall barrier (NETISR not getting a chance to run protocol processing to completion because of interrupt overhead); there are two other stall barriers after that, and another in user space is possible depending on whether the application layer is request/response. Are you sure that polling would help even since the em driver is using interrupt regulation by default? It might solve the livelock but it does probably not increase the performance of the mbuf allocator? Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mbuf cache
There's probably a tightloop of frees going on somewhere. It's tough for me to analyze this as I cannot reproduce it. Have you tried running your tests over loopback to see if the same thing happens? What is the definition of tightloop? The received packet mbufs are freed when the packets get processed/discarded which happens once for a packet. The received packet rate is 5-15 packets per second. If so, and it does, can you please explain how to exactly replicate the test? Mirror a port with ~300-800Mbps of IP traffic to an em port. Just enable promisc and monitor so it drops the packets after interrupt processing. The overhead beyond that is neglible compared to mb_free. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mbuf cache
Yeah, it kinda sucks but I'm not sure how it works... when are the mbufs freed? If they're all freed in a continous for loop that kinda sucks. I think there is nothing really special about the driver there? The mbufs are allocated in the driver and then freed when other parts in the kernel are done with the packet? The issue I´m having is that mb_free takes almost four times the cycles than mb_alloc for each call which does not seem to be right? I shouldn´t be having lock contention in mb_alloc because the whole thing is still under Giant, right? Nothing seems to be moving to the GEN pool. Lower the high watermark to like 512... wait for the next free... if it's still not moving, but you see that the per-cpu caches are being used (in use is changing), please let me know ASAP. It´s moving, however no change in performance. In use hovers around 7000 for mbufs and clusters alike. Now the only difference is that in pool also changes constantly because mbufs are shuffled between pools. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mbuf cache
While you are there debugging mbuf issues, you might also want to try this patch: Didn´t run profiling yet, but judging from the CPU utilization, this did not change the whole picture a lot (dunno why it should since CPU is mostly spent freeing the mbufs, not allocating them) Pete Oops, my first patch had some bugs because of quick editing. Please try the newer patch: http://www.unixdaemons.com/~hiten/work/mbuf/if_em.c.patch Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
i have yet to see a cisco ios image supporting ipv6 that was usable in production environment. and i have tried hard. This is getting OT but on the subject of repelling users, they´re probably trying hard to repel their users to the vendor J boxen. but i will admit to not having seen apollo networking for over a decade. but i probably have not been looking very widely. I´ve made a sighting in 1996 if I remember correctly. For their sake, I hope that´s gone now. seems to me that one useful question is whether the netns code being there non-trivially complicates maintenance and/or reliability of other code, and can i compile or module it out if the bits it occupies really bothers me? This is probably the right question. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
M. Warner Losh wrote: ISA support is not obsolete. All new PCs still have ISA busses. They might not have ISA Expansion Bus Slots, but they all[*] still connect their serial ports, parallel ports, and mouse/keyboard ports via ISA. Not to mention i8254 which gets to be major pain if ACPI would not be an option. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mbuf cache
This does look odd... maybe there's a leak somewhere... does in use go back down to a much lower number eventually? What kind of test are you running? in pool means that that's the number in the cache while in use means that that's the number out of the cache currently being used by the system; but if you're telling me that there's no way usage could be that high while you ran the netstat, either there's a serious leak somewhere or I got the stats wrong (anyone else notice irregular stats?) I think I figured this, the em driver is allocating mbuf for each receive descriptor regardless if it´s needed or not. Does this cause a performance issue if there is 8000 mbufs in use and we get 100k-150k frees and allocates a second (for every packet?) (I have the em driver configured for 4096 receive descriptors) Another thing I find odd about those stats is that you've set the high watermark to 8192, which means that in the next free, you should be moving buckets to the general cache... see if that's really happening... The low watermark doesn't affect anything right now. Nothing seems to be moving to the GEN pool. Can you give me more details on the exact type of test you're running? Let's move this to -current instead of -current and -net please (feel free to trim the one you want), getting 3 copies of the same message all the time is kinda annoying. :-( I´m running a snort-like application with the interface getting receive only packets. It can either connect to a netgraph node or use bpf, both seem to have similar performance (most CPU is used elsewhere) as the email I sent previously had listed. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mbuf cache
Any comments on the high cpu consumption of mb_free? Or any other places
where I should look to improve performance?
What do you mean high cpu consumption? The common case of mb_free()
is this:
According to profiling mb_free takes 18.9% of all time consumed in kernel and is
almost double to next cpu consuming function. Since I´m looking how to optimize
the system, it´s usually a good idea to start looking where most CPU is spent.
For example, I´m wondering if mbufs get unneccessarily freed and allocated or thrown
around different buckets because of the tunables are wrong. I´m not saying that
there must be something wrong with the code itself.
For example what does in use mean below: There is no way there is enough
traffic on the system to allocate 7075 mbufs when this netstat -m was taken.
mbuf usage:
GEN cache: 0/0 (in use/in pool)
CPU #0 cache: 7075/8896 (in use/in pool)
CPU #1 cache: 1119/4864 (in use/in pool)
Total: 8194/13760 (in use/in pool)
Mbuf cache high watermark: 8192
Mbuf cache low watermark: 128
Pete
bucket = mb_list-ml_btable[MB_BUCKET_INDX(m, mb_list)];
owner = bucket-mb_owner ~MB_BUCKET_FREE;
switch (owner) {
...
default:
cnt_lst = MB_GET_PCPU_LIST_NUM(mb_list, owner);
MB_PUT_OBJECT(m, bucket, cnt_lst);
MB_MBTYPES_DEC(cnt_lst, type, 1);
if (bucket-mb_owner MB_BUCKET_FREE) {
SLIST_INSERT_HEAD((cnt_lst-mb_cont.mc_bhead),
bucket,
mb_blist);
bucket-mb_owner = cnt_lst-mb_cont.mc_numowner;
}
}
That's the common path, modulo a couple checks on whether or not the
container being freed to needs to be moved or whether we're in a
starvation situation. The only thing to be done, possibly, is make
the routine smaller by moving those couple of actions to seperate
routines, but I'm not clear that this is very useful, given that
mb_free()'s usage is restricted to only inside subr_mbuf.c
Pete
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
mbuf cache
I did some profiling on -CURRENT from a few days back, and I think I haven´t figured the new tunables out or the code is not doing what it´s supposed to or I´m asking more than it is supposed to do but it seems that mb_free is being quite wasteful... Any pointers to how the new high/low watermark tunables should be used? Is it normal that after almost all traffic has been stopped there is still 8k+ mbufs in cache? Pete granularity: each sample hit covers 16 byte(s) for 0.00% of 708.90 seconds % cumulative self self total time seconds secondscalls ms/call ms/call name 18.9 134.04 134.04 778488459 0.00 0.00 mb_free [5] 10.0 204.9970.95 290131104 0.00 0.00 ether_input [8] 9.0 268.4663.47 __mcount [9] 6.3 313.4244.96 198223061 0.00 0.00 m_move_pkthdr [15] 5.1 349.6836.27 18238430 0.00 0.02 em_intr [2] 5.0 385.0935.41 778488459 0.00 0.00 mb_alloc [17] 4.8 418.8733.77 198510151 0.00 0.00 generic_bcopy [18] 4.5 450.6431.77 234113.5763.33 m_freem [4] 4.1 479.8129.17 967684 0.03 0.03 call_fast_unpend [20] 3.5 504.5324.72 17641942 0.00 0.01 em_process_receive_interru pts [3] 1.8 517.2612.73 m_pullup [6] 1.6 528.5111.25 290131104 0.00 0.00 em_get_buf [10] mbuf usage: GEN cache: 56/256 (in use/in pool) CPU #0 cache: 8138/12064 (in use/in pool) Total: 8194/12320 (in use/in pool) Mbuf cache high watermark: 4096 Mbuf cache low watermark: 128 Maximum possible: 51200 Allocated mbuf types: 8194 mbufs allocated to data 24% of mbuf map consumed mbuf cluster usage: GEN cache: 4/16 (in use/in pool) CPU #0 cache: 8188/12280 (in use/in pool) Total: 8192/12296 (in use/in pool) Cluster cache high watermark: 4096 Cluster cache low watermark: 16 Maximum possible: 25600 48% of cluster map consumed 27672 KBytes of wired memory reserved (66% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mbuf cache
Yes, it's normal. The commit log clearly states that the new watermarks do nothing for now. I have a patch that changes that but I haven't committed it yet because I left for vacation last Sunday and I only returned early this Monday. Since then, I've been too busy to clean up and commit it. In about a week or so you should notice a difference. Any comments on the high cpu consumption of mb_free? Or any other places where I should look to improve performance? Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
hype(r)threading
I seem to want to quite the opposite what other people would like to happen, we have a supermicro P4DPR board with two Xeon´s. Since lately the kernel seems to want to launch the virtual cores regardless of BIOS setting of HyperThreading being [Disabled]. Any ideas how to disable the cores since our workload is does not benefit from having more than two cores in a machine. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: hype(r)threading
After some reading around I ended up putting a return; on top of the mptable_hyperthread_fixup function and my performance is back. Setting the sysctl helps some but it does not really fix the performance issues. I would like to make the suggestion of making the HT fixup maybe a default but allow disabling with a kernel variable? Pete On Mon, 3 Mar 2003, Petri Helenius wrote: I seem to want to quite the opposite what other people would like to happen, we have a supermicro P4DPR board with two Xeon´s. Since lately the kernel seems to want to launch the virtual cores regardless of BIOS setting of HyperThreading being [Disabled]. Any ideas how to disable the cores since our workload is does not benefit from having more than two cores in a machine. Pete Currently, AFAIK, there is no way to do this. Depending on what you are doing you can increase performance slightly by setting machdep.cpu_idle_hlt=1 -Trish -- Trish Lynch[EMAIL PROTECTED] Ecartis Core Team [EMAIL PROTECTED] EFNet IRC Operator @ efnet.demon.co.uk [EMAIL PROTECTED] EFNet IRC Operator/SysAdmin @ irc.dkom.at [EMAIL PROTECTED] Key fingerprint = 781D 2B47 AA4B FC88 B919 0CD6 26B2 1D62 6FC1 FF16 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: hype(r)threading
Thanks, that´s greatly appreciated. Pete On 03-Mar-2003 Petri Helenius wrote: After some reading around I ended up putting a return; on top of the mptable_hyperthread_fixup function and my performance is back. Setting the sysctl helps some but it does not really fix the performance issues. I would like to make the suggestion of making the HT fixup maybe a default but allow disabling with a kernel variable? I'm going to add a 'HTT' kernel option that I'll backport prior to 4.8. Pete On Mon, 3 Mar 2003, Petri Helenius wrote: I seem to want to quite the opposite what other people would like to happen, we have a supermicro P4DPR board with two Xeon´s. Since lately the kernel seems to want to launch the virtual cores regardless of BIOS setting of HyperThreading being [Disabled]. Any ideas how to disable the cores since our workload is does not benefit from having more than two cores in a machine. Pete Currently, AFAIK, there is no way to do this. Depending on what you are doing you can increase performance slightly by setting machdep.cpu_idle_hlt=1 -Trish -- Trish Lynch[EMAIL PROTECTED] Ecartis Core Team [EMAIL PROTECTED] EFNet IRC Operator @ efnet.demon.co.uk [EMAIL PROTECTED] EFNet IRC Operator/SysAdmin @ irc.dkom.at [EMAIL PROTECTED] Key fingerprint = 781D 2B47 AA4B FC88 B919 0CD6 26B2 1D62 6FC1 FF16 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
raidframe issues
I'm trying to create a raid set but after hitting the end of initializing a raid5 stripe the following is displayed on the console: raid0: node (Rod) returned fail, rolling backward raid0: IO Error. Marking /dev/da2s1e as failed. raid0: node (Rod) returned fail, rolling backward raid0: IO Error. Marking /dev/da1s1e as failed. raid0: node (Rod) returned fail, rolling backward Unable to verify parity: can't read the stripe Could not verify parity raid0: Error re-writing parity! Multiple disks failed in a single group! Aborting I/O operation. Multiple disks failed in a single group! Aborting I/O operation. Multiple disks failed in a single group! Aborting I/O operation. [Failed to create a DAG] panic: raidframe error at line 459 file /usr/src/sys/dev/raidframe/rf_states.c cpuid = 0; lapic.id = boot() called on cpu#0 syncing disks, buffers remaining... panic: bdwrite: buffer is not busy cpuid = 0; lapic.id = boot() called on cpu#0 Uptime: 38m47s Shutting down raid0 Terminate ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset called on cpu#0 cpu_reset: Stopping other CPUs dmesg gives the following as disks: da0 at ahd0 bus 0 target 0 lun 0 da0: IBM IC35L036UCD210-0 S5BS Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) da1 at ahd0 bus 0 target 1 lun 0 da1: IBM IC35L036UCD210-0 S5BS Fixed Direct Access SCSI-3 device da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) da2 at ahd0 bus 0 target 2 lun 0 da2: IBM IC35L036UCD210-0 S5BS Fixed Direct Access SCSI-3 device da2: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da2: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) da3 at ahd0 bus 0 target 3 lun 0 da3: IBM IC35L036UCD210-0 S5BS Fixed Direct Access SCSI-3 device da3: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da3: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) cat /etc/raid0.conf START array 1 3 0 START disks /dev/da1s1e /dev/da2s1e /dev/da3s1e START layout 16 1 1 5 START queue fifo 100 Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
