Re: AARRRGGHHH! (was Re: TIMEOUT - WRITE_DMA errors in security output)
On 09/02/04 08:56 PM, Louis LeBlanc sat at the `puter and typed: SNIP The ata controller(s) are, from the /var/run/dmesg.boot: atapci0: Intel ICH5 UDMA100 controller port 0xffa0-0xffaf,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 mem 0xfebffc00-0xfebf irq 18 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] atapci1: Intel ICH5 SATA150 controller port 0xfea0-0xfeaf,0xfe30-0xfe33,0xfe20-0xfe27,0xfe10-0xfe13,0xfe00-0xfe07 irq 18 at device 31.2 on pci0 atapci1: [MPSAFE] ata2: at 0xfe00 on atapci1 ata2: [MPSAFE] ata3: at 0xfe20 on atapci1 ata3: [MPSAFE] I *think* it's an Intel MB, but I don't know which one. The machine is a Dell Dimension 8300 if that helps, and the drive is 160 Gig. atacontrol gives the following info: # atacontrol info 0 Master: no device present Slave: no device present # atacontrol info 1 Master: acd0 HL-DT-STDVD-ROM GDR8162B/0015 ATA/ATAPI rev 5 Slave: acd1 HL-DT-ST GCE-8483B/B105 ATA/ATAPI rev 0 # atacontrol info 2 Master: ad4 WDC WD1600JD-75HBB0/08.02D08 ATA/ATAPI rev 6 Slave: no device present # atacontrol info 3 Master: no device present Slave: no device present Looks like I only have to hit channel 2 for now. More detail on the disk: # atacontrol cap 2 0 ATA channel 2, Master, device ad4: ATA/ATAPI revision6 device model WDC WD1600JD-75HBB0 serial number WD-WMAL91191824 firmware revision 08.02D08 cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 31250 sectors dma supported overlap not supported Feature Support EnableValue Vendor write cacheyes yes read ahead yes yes dma queued no no 0/0x00 SMART yes yes microcode download yes yes security no no power management yes yes advanced power management no no 0/0x00 automatic acoustic management yes no 128/0x80 128/0x80 SNIP Should I restart with this script, or just try the change without rebooting? As I interpret this, the command I should use is /sbin/atacontrol mode 2 pio4 xxx Just for the record, that was definitely the wrong command. Had to boot to another kernel again. Lots of corruption on the root partition. Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ Green's Law of Debate: Anything is possible if you don't know what you're talking about. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AARRRGGHHH! (was Re: TIMEOUT - WRITE_DMA errors in security output)
On Mon, 30 Aug 2004 08:40:00 -0400, Louis LeBlanc [EMAIL PROTECTED] wrote: Well, it's probably not an old BOIS, since the machine is less than 3 months old. I checked the BIOS after the system locked up, and it was enabled. I disabled it, and still couldn't boot until I used the generic kernel. Right now, the BIOS DMA is off, but the ata_dma sysctl variable is still setting to 1. I'll check this out for a while, and see if it works. If not, I'll call Dell for a new HD and cable. Well, I read part of this thread a few days ago but haven't had time to respond until now -- sorry. I had a problem that seems to be similar if not identical to this one about three months ago -- I emailed both freebsd-questions and freebsd-hardware in that order and never got a response, though I've worked around the problem. I had been running 4.9 in a system with a new motherboard and two 120 GB Maxtor ATA133 drives that were also pretty new. I had also purchased new, custom UDMA133 round cables for the drives and everything worked just peachy under 4.9. When I upgraded to 5.2.1, however, I had problems just like what you mentioned -- WRITE_DMA warnings and failures whenever there was significant disk activity. Eventually this caused one of my vinum raid plexes to go down. Anyhow, from researching old mailings and such I noticed that I wasn't alone in this seemingly inexplicable problem under 5.1 and newer. It seems some of us with drives (someone mentioned that it seemed to be ones larger than or equal to 80 or 120 GB or something like that) on an ATA controller like the VIA 8235 have this problem unless you put the drive(s) into PIO mode. I did this (using a custom script in /usr/local/etc/rc.d that executes the atacontrol command: /sbin/atacontrol mode 0 pio4 xxx) for both of my ATA controllers and everything works fine. I wonder if the ata driver just has an incompatability with my specific VIA 8235 ata controller or something like that. Anyhow, what kind of motheboard/ata-controller do you have? Also, I noticed that others also recommended turning DMA mode off in /boot/loader.conf and that you tried it and it didn't work. I also remember reading somewhere a reason why this won't/doesn't work and that is why I do it in a /usr/local/etc/rc.d script -- there never seems to be a problem booting in DMA mode. Here's my pretty standard script: #!/bin/sh # case $1 in start|restart) if [ -f /sbin/atacontrol ] [ -x /sbin/atacontrol ]; then /sbin/atacontrol mode 0 pio4 xxx /sbin/atacontrol mode 1 pio4 xxx fi ;; stop) ;; esac P.S. Let us know what ata controller you have. O.T. Also, does anyone know why disabling DMA in /bool/loader.conf doesn't work? -- Kendall Gifford [EMAIL PROTECTED] http://www.kendallgifford.com/ +++ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AARRRGGHHH! (was Re: TIMEOUT - WRITE_DMA errors in security output)
On 09/02/04 01:23 PM, Kendall Gifford sat at the `puter and typed: On Mon, 30 Aug 2004 08:40:00 -0400, Louis LeBlanc [EMAIL PROTECTED] wrote: Well, it's probably not an old BOIS, since the machine is less than 3 months old. I checked the BIOS after the system locked up, and it was enabled. I disabled it, and still couldn't boot until I used the generic kernel. Right now, the BIOS DMA is off, but the ata_dma sysctl variable is still setting to 1. I'll check this out for a while, and see if it works. If not, I'll call Dell for a new HD and cable. Well, I read part of this thread a few days ago but haven't had time to respond until now -- sorry. Hey, I'm just glad you responded :) I had a problem that seems to be similar if not identical to this one about three months ago -- I emailed both freebsd-questions and freebsd-hardware in that order and never got a response, though I've worked around the problem. I had been running 4.9 in a system with a new motherboard and two 120 GB Maxtor ATA133 drives that were also pretty new. I had also purchased new, custom UDMA133 round cables for the drives and everything worked just peachy under 4.9. When I upgraded to 5.2.1, however, I had problems just like what you mentioned -- WRITE_DMA warnings and failures whenever there was significant disk activity. Eventually this caused one of my vinum raid plexes to go down. Anyhow, from researching old mailings and such I noticed that I wasn't alone in this seemingly inexplicable problem under 5.1 and newer. It seems some of us with drives (someone mentioned that it seemed to be ones larger than or equal to 80 or 120 GB or something like that) on an ATA controller like the VIA 8235 have this problem unless you put the drive(s) into PIO mode. I did this (using a custom script in /usr/local/etc/rc.d that executes the atacontrol command: /sbin/atacontrol mode 0 pio4 xxx) for both of my ATA controllers and everything works fine. I wonder if the ata driver just has an incompatability with my specific VIA 8235 ata controller or something like that. Anyhow, what kind of motheboard/ata-controller do you have? The ata controller(s) are, from the /var/run/dmesg.boot: atapci0: Intel ICH5 UDMA100 controller port 0xffa0-0xffaf,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 mem 0xfebffc00-0xfebf irq 18 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] atapci1: Intel ICH5 SATA150 controller port 0xfea0-0xfeaf,0xfe30-0xfe33,0xfe20-0xfe27,0xfe10-0xfe13,0xfe00-0xfe07 irq 18 at device 31.2 on pci0 atapci1: [MPSAFE] ata2: at 0xfe00 on atapci1 ata2: [MPSAFE] ata3: at 0xfe20 on atapci1 ata3: [MPSAFE] I *think* it's an Intel MB, but I don't know which one. The machine is a Dell Dimension 8300 if that helps, and the drive is 160 Gig. atacontrol gives the following info: # atacontrol info 0 Master: no device present Slave: no device present # atacontrol info 1 Master: acd0 HL-DT-STDVD-ROM GDR8162B/0015 ATA/ATAPI rev 5 Slave: acd1 HL-DT-ST GCE-8483B/B105 ATA/ATAPI rev 0 # atacontrol info 2 Master: ad4 WDC WD1600JD-75HBB0/08.02D08 ATA/ATAPI rev 6 Slave: no device present # atacontrol info 3 Master: no device present Slave: no device present Looks like I only have to hit channel 2 for now. More detail on the disk: # atacontrol cap 2 0 ATA channel 2, Master, device ad4: ATA/ATAPI revision6 device model WDC WD1600JD-75HBB0 serial number WD-WMAL91191824 firmware revision 08.02D08 cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 31250 sectors dma supported overlap not supported Feature Support EnableValue Vendor write cacheyes yes read ahead yes yes dma queued no no 0/0x00 SMART yes yes microcode download yes yes security no no power management yes yes advanced power management no no 0/0x00 automatic acoustic management yes no 128/0x80 128/0x80 Also, I noticed that others also recommended turning DMA mode off in /boot/loader.conf and that you tried it and it didn't work. I also remember reading somewhere a reason why this won't/doesn't work and that is why I do it in a /usr/local/etc/rc.d script -- there never seems to be a problem booting in DMA mode. Here's my pretty standard script: I did turn off DMA in the BIOS. I still saw a couple of the timeouts yesterday, but nothing so major it locked the system up. Another thing that I just remembered; when I initially installed 5.2.1-R on this machine, softupdates was on by default. I had a few incidents while building the kernel and world from updated source that caused the
AARRRGGHHH! (was Re: TIMEOUT - WRITE_DMA errors in security output)
On 08/28/04 09:04 AM, Subhro sat at the `puter and typed: Well it is really unfortunate that hard disks don't need a reason to die. Maybe you are right. Are you using a 40 conductor or a 80 conductor cable? You can also try disabling DMA by setting the values displayed by sysctl -a | grep dma to 0 in /boot/loader.conf Regards S. Somehow I don't think that's going to solve my problem. After adding the following line to loader.conf: hw.ata.ata_dma=0 the machine just freezes up while trying to mount the root partition. I managed to boot to an old kernel and fix that problem. Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ Grief can take care of itself; but to get the full value of a joy you must have somebody to divide it with. -- Mark Twain ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AARRRGGHHH! (was Re: TIMEOUT - WRITE_DMA errors in security output)
Although highly unlikely, but could you check your BIOS and enable DMA if there is any setting for it? Alternatively, old BIOSses are really messy about handling New hard drives. So reflashing the BIOS is also a good option if your mo'bo manufacturer offers something new. Also you did not indicate what type of cable you are using, ie 40 conductor or 80 conductor. Regards S. On Sun, 29 Aug 2004 23:16:13 -0400, Louis LeBlanc [EMAIL PROTECTED] wrote: On 08/28/04 09:04 AM, Subhro sat at the `puter and typed: Well it is really unfortunate that hard disks don't need a reason to die. Maybe you are right. Are you using a 40 conductor or a 80 conductor cable? You can also try disabling DMA by setting the values displayed by sysctl -a | grep dma to 0 in /boot/loader.conf Regards S. Somehow I don't think that's going to solve my problem. After adding the following line to loader.conf: hw.ata.ata_dma=0 the machine just freezes up while trying to mount the root partition. I managed to boot to an old kernel and fix that problem. Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ Grief can take care of itself; but to get the full value of a joy you must have somebody to divide it with. -- Mark Twain ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- Subhro Sankha Kar School of Information Technology Block AQ-13/1 Sector V ZIP 700091 India ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
