| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20070620162845.GY5836@austin.ibm.com> Date: Wed, 20 Jun 2007 11:28:45 -0500 From: linas@...tin.ibm.com (Linas Vepstas) To: Sergei Shtylyov <sshtylyov@...mvista.com> Cc: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>, Stuart_Hayes@...l.com, linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [BUG] ide dma_timer_expiry, then hard lockup On Wed, Jun 20, 2007 at 12:07:19AM +0400, Sergei Shtylyov wrote: > Bartlomiej Zolnierkiewicz wrote: > > [...frmware...] Google seems to show that there is no publically available firmware updates for Maxtor disks. > >It would be useful to see hdparm --Istdout output for *both* disks. Lets do one at a time. Appended below is the one for the older, "known good" disk. > >Sergei, do you think that testing the drive with DMA disabled may > >tell us something new? FWIW, the "buggy" disk seems to work fine with DMA turned off (with hdparm). I just copied 60GB from it; although this did take about 16 hours at high cpu usage.... There were maybe a a dozen DriveReady SeekComplete Timeout errors clustered a few minutes apart. ---- Re: The libata problem. This is a hang during the read of the partition table during boot, of the "known good" disk. I turned on scsi and libata debugging, reproduced the hang, dilligently copied to a piece of paper, but then left the darned piece of paper at home. >From what I remember, the ata command was translated to scsi, by ata_queuecommand, and then handed off to the scsi subsystem. Presumably, its sent to the drive, but the drive does not respond. 30 seconds later, the scsi eh runs, and ands the error back to libata, which takes a few ineffectual shots at recovery, and then hangs. I'll try to get the details later. Is there a way of viewing the contents of he command queue on the hard drive, to see if the command actually made it across? --linas /dev/hda: multcount = 16 (on) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 24792/255/63, sectors = 398297088, start = 0 0040 3fff c837 0010 0000 0000 003f 0000 0000 0000 5936 3130 4d45 4345 2020 2020 2020 2020 2020 2020 0003 3e00 0039 5941 5234 3142 5730 4d61 7874 6f72 2036 5932 3030 5030 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 8010 0000 2f00 4000 0200 0000 0007 ffff 0001 003f ffc1 003e 0110 ffff 0fff 0000 0007 0003 0078 0078 0078 0078 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00fe 001e 7c6b 7f09 4003 7c69 3e01 4003 107f 0000 0000 0000 fffe 600d c0fe 0000 0000 0000 0000 0000 8800 17bd 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 60a5 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists