Re: FreeBSD sound distortion problems with SB Live! fixed with PREEMPTION
[ freebsd-stabl@ is now the right place for RELENG_5 ]. On Tue, Dec 07, 2004 at 11:48:40PM -0700, Travis Poppe wrote: Hello all, Back in October, I contacted the list and described a problem I was having with FreeBSD 5.X (now 5.3-RELEASE) and sound. I will reiterate the problem one more time for those of you who did not follow the posts. I was using FreeBSD 5.3-BETA7 at the time (as far as I know, all of 5.x has this problem) and have an SB Live! 5.1 which uses the emu10k1 driver. I've been told that this problem may be specific to my driver (and possibly others). The problem: When playing music with XMMS after my box had been up for at least a day or two, I'd hear these random skips and sound distortions that can be described as the sound being slowed down for 1/4th of a second and then back to normal again (a lagged sound skip). I have *exactly* the same problem on a 5.3 box (branch RELENG_5 after RELENG_5_3_BP). FreeBSD obiwan 5.3-STABLE FreeBSD 5.3-STABLE #3: Sun Nov 21 17:22:54 CET 2004 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/OBIWAN i386 A much more severe version of this can easily be reproduced by extracting the firefox source code from bz2 while playing music and can be witnessed for as long as it takes to extract the archive. Note that these are not just skips but complete sound distortion as well. If you hear very minor brief skips when running this test but no distortion, you are not witnessing the same problem. In the previous posts to -CURRENT, I was advised to increase the sound buffer which did HELP, but the problem was still there. Increasing the buffer also caused de-synced sound in games. This was not a good workaround. Anyway, today I was playing around with a few patches derived from DragonFly that make it possible to use high resolution VESA modes with syscons. I was using a 1024x768 VESA text console when I noticed that if a lot of text were to be scrolled on the screen at once, I'd hear the same sound problem described above. Frustrated, I began conversation on IRC and described my problem. A friend of mine suggested something no one else had before, and that suggestion was to enable PREEMPTION in the kernel. A GNU/Linux user in another channel also said this to me: Sounds like FreeBSD needs a preemptable kernel. So, I decided to give it a try. To my amazement, it worked completely. Enabling PREEMPTION in the kernel completely fixes this problem to the fullest extent. I have not been able to reproduce the problem since using any of the methods described above. I'm hoping that with this new information someone might be able to figure out what is truly causing this problem and can come up with a solution (or is PREEMPTION a good solution?). It seems that only a handful of drivers (emu10k1 is the one I'm having problems with) have this problem. For the record, I am not the only one who has reported this problem to the lists. You make me happy ! I noticed this problem yesterday evening, and I did'nt have time to investigate yet. It definitely seems that PREEMPTION is the good solution since these small breaks in sounds indicates that, coarsely, the kernel does not have enough time to do what it wants between two sound frames. Basically, PREEMPTION allows to interrupt the kernel in its current task if there is something more important to do, like pushing a new sound frame. (If someone wants to make a more precise description -- or even correct me if I'm wrong --, I would be graceful.) FIY, Linux folks have a dedicated preemption patch which was initially started to make things such as Jack Audio Connection Kit [1] and related softwares work fine. Regards, [1] http://jackit.sf.net/ -- Jeremie Le Hen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
painful delay during 5.3 boot
(I am posting this message to freebsd-stable because release 5.3 is allegedly now stable and freebsd-current is now beginning to concern itself with things that will belong to release 6.0. Let me know if another mailing list would be more appropriate.) When FreeBSD 5.3-RC1 was being tested I reported (in freebsd-current) a problem with the kernel pausing for about 2 minutes in the middle of the auto-configuration monologue. It was suggested that the problem was that the floppy driver mistakenly thought there was a diskette in the driver and kept probing it until some retry limit was exceeded. Someone suggested that I add some extra diagnostic code to the driver and report what it wrote during bootstrap. I did that and there were no further postings about the issue in freebsd-current. A couple of release candidates later the problem went away and I assumed it was fixed. The problem just resurfaced when I built a custom 5.3 kernel. It turns put that the problem was never fixed. The kernel on the 5.3 release installation disk now just rejects the floppy drive when it configures the floppy controller and the system comes up without the floppy drive, something I didn't notice because I was doing a CD installation. This is what the installation CD kernel says about the floppy during a verbose boot: fdc0: floppy drive controller port 0x3f7,0x3f0-0x3f5 irq 6 ... fdc0: does not respond device_attach: fdc0 attach returned 6 For reasons I don't understand, the custom 5.3 kernel I built is more tolerant. When it probes the floppy controller during a verbose boot it says: fdc0: floppy drive controller port 0x3f7,0x3f0-0x3f5 irq 6 ... fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] fd0: 1440-KB 3.5 drive on fdc0 drive 0 and later spends about 120 seconds trying to read a nonexistent diskette after writing these lines: ioapic0: routing intpin 19 (PCI IRQ 19) to cluster 0 ioapic0: routing intpin 21 (PCI IRQ 21) to cluster 0 ioapic0: routing intpin 22 (PCI IRQ 22) to cluster 0 and before writing these lines: GEOM: new disk ad0 GEOM: new disk ad1 GEOM: new disk ad4 I know the problem is with the floppy drive because the floppy activity light comes on during the 120 second pause and because popping a floppy diskette into the drive makes the system wake up and finish booting. I am pretty sure the problem is new in FreeBSD 5.3. I don't recall having this problem in any previous release (including 5.1 and 5.2) and I boot release 4.10 every day without the agonizing pause. Could this be due to a floppy hardware problem? (How can I tell? Is there any documentation anywhere about the PC floppy disk controller interface?) The floppy disk drive seems to work correctly. Dan Strick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crashdumps not working
On Tuesday, 7. December 2004 21:54, 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? FWIW, I got a real panic today (page fault) and no dump was taken there either. :-( -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpfae4p40akR.pgp Description: PGP signature
Re: 4.10 and KDE 3.3.1 == broken :(
On Tue, 7 Dec 2004 15:48, Daniel O'Connor wrote: Needless to say that is quite untested/unsupported by us, and if you've been using any packages there's a good chance things aren't fitting together so well. I do hope Xorg 6.8.1 won't break KDE on 4.x once it's in ports, but I can't discount the possibility. I built Xorg from source using patches Eric Anholt supplied. Works in 5.x ;) I guess I'll try XFree86 on this box and see if it has an effect. Well, going back to XFree86 works.. How annoying :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpbpxF0ikf3D.pgp Description: PGP signature
Re: crashdumps not working
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). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crashdumps not working
On Wed, 8 Dec 2004, 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). It this is an SMP box, you might also try setting debug.kdb.stop_cpus to 0. Normally when entering the debugger, the processor entering the debugger will send an IPI to the other CPUs to stop them in order to quiesce the system state a bit. If one or more processors are in a state where processing the top IPI isn't possible, the procesor entering the debugger will wait for them to stop ... potentially for a very long time, and in a tight loop. Changing the setting to 0 might improve the chances of getting into the debugger (etc). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crashdumps not working
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.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 0xf, 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 Syncing disks, vnodes remaining...4 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (I enabled kern.sync_on_panic only very recently for my experimenting with watchdog, dumping didn't work without it either). -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpPjREzyvVXZ.pgp Description: PGP signature
Re: crashdumps not working
On Wednesday, 8. December 2004 12:28, Robert Watson wrote: On Wed, 8 Dec 2004, 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). It this is an SMP box, It's UP (as the kernel configuration I attached to my first mail gives away :-). -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgppOpMI46oHX.pgp Description: PGP signature
Re: crashdumps not working
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 :-). Do you have a serial console on the box, or could you set one up? 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 0xf, 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. Syncing disks, vnodes remaining...4 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (I enabled kern.sync_on_panic only very recently for my experimenting with watchdog, dumping didn't work without it either). 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? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crashdumps not working
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 0xf, 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 | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpk0pV9DnNCX.pgp Description: PGP signature
Re: crashdumps not working
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 | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpv19dQklmM2.pgp Description: PGP signature
vinum crashes the Box by using more then ten disks on RELENG_4
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 [EMAIL PROTECTED]:/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=0x383fbffFPU,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 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec0 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 cff irq 13 at device 6.0 on pci1 ahc0: Adaptec aic7880 Ultra SCSI adapter port 0xfc00-0xfcff mem 0xfcfff000-0xf cff 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 0xf400-0xf7ff 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=2558DATA64,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 0xfe00-0xfe0 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 0xfe10-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 0xef00-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 0xc-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
Re: crashdumps not working
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 [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crashdumps not working
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 | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpfYonq6e9nn.pgp Description: PGP signature
vinum crashes by using more then 11 disks on RELENG_4
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 [EMAIL PROTECTED]:/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=0x383fbffFPU,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 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec0 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 cff 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 0xf400-0xf7ff 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=2558DATA64,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 0xfe00-0xfe0 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 0xfe10-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 0xef00-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 0xc-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 0xa-0xb 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
Re: crashdumps not working
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 | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crashdumps not working
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 | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpWUheyd5jYr.pgp Description: PGP signature
devfs rules
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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devfs rules
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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devfs rules
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 | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpvs0frOSGc7.pgp Description: PGP signature
Re: devfs rules
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 [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devfs rules
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 [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crashdumps not working
Robert == Robert Watson [EMAIL PROTECTED] 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: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devfs rules
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! :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: trouble installing 5.3 on soekris net4801
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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crashdumps not working
On Wed, 8 Dec 2004, David Gilbert wrote: Robert == Robert Watson [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
no internet after build world-kern install
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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Making a data DVD with 4.10 and dvd+rw-format
* nicky [EMAIL PROTECTED] [20041203 11:47]: Joan Picanyol wrote: * Michael Nottebrock [EMAIL PROTECTED] [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 operator4, 34 8 des 22:15 /dev/cd0 qvb -- pica ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ULE scheduler broken and not documented
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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE scheduler broken and not documented
On Wed, Dec 08, 2004 at 10:21:02PM +, 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.) pgp4V2nNOidQ9.pgp Description: PGP signature
5.3R crashing repeateadly
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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3R crashing repeateadly
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 pgpv6UQ9fYPUn.pgp Description: PGP signature
Re: trouble installing 5.3 on soekris net4801
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 [EMAIL PROTECTED] 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... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE scheduler broken and not documented
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 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3R crashing repeateadly
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 [EMAIL PROTECTED]:/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=0xbfebfbffFPU,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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3R crashing repeateadly
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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
More WRITE_DMA problems on 5.3
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 [EMAIL PROTECTED]:/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=0x387f9ffFPU,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 0xd000-0xd3ff 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 0xd900-0xd97f 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 0xc-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 0xa-0xb 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crashdumps not working
On Wednesday, 8 December 2004 at 11:20:34 +, 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. pgp7cj9GtXUHg.pgp Description: PGP signature
Re: trouble installing 5.3 on soekris net4801
Booting safe mode actually works. Heck, I even got to use sysinstall. =} I shall try to replicate the stuff that gets set in beastie.4th and slap it into my loader.conf. Hopefully that should be enough to get me by. Thanks! --- Lapo Nustrini [EMAIL PROTECTED] 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... 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no internet after build world-kern install
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. I had the same problem going from 5.2 to 5.3 Make sure you have: deviceether in your kernel. While you're at it, be sure to add: devicerandom devicemem to your kernel also. Jeff Love Burgh Gaming ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3R crashing repeateadly
Hello, this is just to report back that disabling hyper-threading in the BIOS made the problem go away completely. I'm sorry I didn't generate a core dump but because I installed four swap partitions each with half the size of the RAM and the handbook says I needed one swap partition with at least the same size, and I don't have the time to fiddle with partitions now. Thanks for the help, Cristóvão Mike Tancsa wrote: 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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3R crashing repeateadly
On Thu, Dec 09, 2004 at 01:42:21AM -0200, Crist?v?o Dalla Costa wrote: Hello, this is just to report back that disabling hyper-threading in the BIOS made the problem go away completely. I'm sorry I didn't generate a core dump but because I installed four swap partitions each with half the size of the RAM and the handbook says I needed one swap partition with at least the same size, and I don't have the time to fiddle with partitions now. You can limit the amount of RAM used by the system at boot time with the hw.physmem tunable, set in /boot/loader.conf. Set it to something smaller than your largest swap partition and dump there. Kris pgpvWHn5Fqa88.pgp Description: PGP signature
Re: no internet after build world-kern install
ok i still havent got this resolved yet , heres an up date of things i have tryed to no avail , swaped out eth cards, swaped out cables, hooked up the box straight upto the dsl modem, looked around on the box to see if a firewall was getting started some ware and couldnt find one . so heres a recap of whats going on. cant ping any thing out side the box weather it be domain name or numeric ip address can ping localhost , 127.0.0.1 netstat -rn shows correct settings ( or i think) output is destiongatway netif default65.102.x.x( my dsl modem ip )xl0 65.102.x.x/x( reserverd ip )link#1 xl0 65.102.x.x( my ip ) xl0 (address) lo0 65.102.x.x( my dslmodem ip )link#1 xl0 127.0.0.1127.0.0.1 lo0 NOTE: i do have 2 netcards in this box the second card is not assigned an ip address --- Original Message - From: whitevamp [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 1:00 PM Subject: no internet after build world-kern install 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DMA errors with SATA on 5.x [one fix]
At 1:01 AM -0600 12/7/04, Tim Welch wrote:
I'm getting NID not found/DMA errors on 5-STABLE with a Seagate 200gb
sata drive:
ad2: FAILURE - WRITE_DMA status=51READY,DSC,ERROR
error=10NID_NOT_FOUND LBA=268435455
This appears to be a result of 48-bit addressing. Any time a write is
attempted to the sector above, I get multiple messages like this. It
continues until I shut down. After a bit of googling I found this post:
http://lists.freebsd.org/pipermail/freebsd-hackers/2004-October/008821.html
and applied the change suggested. It seems to have fixed the problem,
and I've had no troubles from this since Nov. 18th when I applied that
patch. I'm running an Intel 875PBZ board with the ich5 controller.
The drive in question is a Seagate ST3200822AS/3.01 (as reported by
dmesg). So the question is, will this patch be committed anytime soon?
That looks like a pretty safe patch to make. The message says he
just reduced the 48-bit trigger level by one:
--- ata-lowlevel.c.orig Wed Nov 24 05:47:26 2004
+++ ata-lowlevel.c Wed Dec 8 22:45:39 2004
@@ -701,7 +701,7 @@
ATA_IDX_OUTB(atadev-channel, ATA_ALTSTAT, ATA_A_4BIT);
/* only use 48bit addressing if needed (avoid bugs and overhead) */
-if ((lba 268435455 || count 256) atadev-param
+if ((lba 268435454 || count 256) atadev-param
atadev-param-support.command2 ATA_SUPPORT_ADDRESS48) {
/* translate command into 48bit version */
If this fixes a problem with large disks for both the original
person and for you, then I suspect we should commit it. I don't
know if we need to add a comment saying why we're going with
268435454 instead of 268435455, though.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
hw.ata.ata_dma=0: can I do this during bootup at the loader prompt?
Hi, In /boot/loader.conf, I have hw.ata.ata_dma=0 to prevent a WRITE_DMA failure crash at bootup. Unfortunately, this forces my UDMA100 harddisk to operate at PIO4 speed. There are patches flying around on this mailing list that might solve the problem. I'm very keen on testing such patches, but I should remove the line in loader.conf. However, if the patch does not work, I end up with an unbootable disk. It would be nice if I can set hw.ata.ata_dma=0 at the loader prompt during bootup, so that the system at least will boot from harddisk. Is that possible? Thanks, Rob. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no internet after build world-kern install
- Original Message - From: [EMAIL PROTECTED] To: whitevamp [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 4:43 PM Subject: Re: no internet after build world-kern install 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. I had the same problem going from 5.2 to 5.3 Make sure you have: deviceether in your kernel. While you're at it, be sure to add: devicerandom devicemem to your kernel also. Jeff Love Burgh Gaming ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] i recompiled the kern with the sugestions you mad . but they didnt work.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: painful delay during 5.3 boot
The problem just resurfaced when I built a custom 5.3 kernel. It turns put that the problem was never fixed. The kernel on the 5.3 release installation disk now just rejects the floppy drive when it configures the floppy controller and the system comes up without the floppy drive, something I didn't notice because I was doing a CD installation. Could this be due to a floppy hardware problem? (How can I tell? Is there any documentation anywhere about the PC floppy disk controller interface?) The floppy disk drive seems to work correctly. Could it be bad cable or something? Or some change in fstab that tries to make connection with something on device? If it is the same computer as with previous trouble, could you try it on another one? Floppy works for me always nice and was the only device I never had head- ache with. ZK ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DMA errors with SATA on 5.x [one fix]
Garance A Drosihn wrote: At 1:01 AM -0600 12/7/04, Tim Welch wrote: I'm getting NID not found/DMA errors on 5-STABLE with a Seagate 200gb sata drive: ad2: FAILURE - WRITE_DMA status=51READY,DSC,ERROR error=10NID_NOT_FOUND LBA=268435455 This appears to be a result of 48-bit addressing. Any time a write is attempted to the sector above, I get multiple messages like this. It continues until I shut down. After a bit of googling I found this post: http://lists.freebsd.org/pipermail/freebsd-hackers/2004-October/008821.html and applied the change suggested. It seems to have fixed the problem, and I've had no troubles from this since Nov. 18th when I applied that patch. I'm running an Intel 875PBZ board with the ich5 controller. The drive in question is a Seagate ST3200822AS/3.01 (as reported by dmesg). So the question is, will this patch be committed anytime soon? That looks like a pretty safe patch to make. The message says he just reduced the 48-bit trigger level by one: Yes, I suggested that way back on the lists, and it seems to help those that had this problem. I have had it for quite some time in ATA-mkIII here as well, and since it has no real impact otherwise I've committed it to -current... -- -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
