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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 23 Jun 2009 18:13:08 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Frans Pop <elendil@...net.nl>
Cc:	David Miller <davem@...emloft.net>, sparclinux@...r.kernel.org,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: cmd64x: irq 14: nobody cared - system is dreadfully slow

On Tuesday 23 June 2009 16:58:54 Frans Pop wrote:
> On Tuesday 23 June 2009, you wrote:
> > We might need to bisect this one.  But Frans, just for the record
> > could you simply test reverting just that hunk?  Thanks!
> 
> I'm way ahead of you :-)
> 
> Instead of a bisect [1] I decided to first see if some printks in both .26 
> and .31 would show anything useful.
> 
> With 2.6.31 and code included below I get:
> hda: ST34342A, ATA DISK drive
> FJP: id_dma_bug 0x7: &4: 0x0-0x4 no error
> hda: MWDMA2 mode selected
> hdc: Maxtor 6E040L0, ATA DISK drive
> hdd: CD-ROM 56X/AKH, ATAPI CD/DVD-ROM drive
> hdc: host max PIO5 wanted PIO255(auto-tune) selected PIO4
> FJP: ID_FIELD_VALID: 0x7 (true)
> FJP: id_dma_bug 0x7: &4: 0x0-0x4 no error
> hdc: MWDMA2 mode selected
> hdd: host max PIO5 wanted PIO255(auto-tune) selected PIO4
> FJP: ID_FIELD_VALID: 0x2 (true)
> FJP: id_dma_bug 0x2: &2: 0x1-0x1 bad modes		<-------------
> hdd: bad DMA info in identify block
> 
> Note that this included a complete revert of 8d64fcd9 (with minor conflict 
> resolved).
> 
> Here's the same output with 2.6.26.3 with equivalent debug statements:
> hda: ST34342A, ATA DISK drive
> FJP: id_dma_bug 0x7: &4: 0x0-0x0 no error
> hda: MWDMA2 mode selected
> hdc: Maxtor 6E040L0, ATA DISK drive
> hdd: CD-ROM 56X/AKH, ATAPI CD/DVD-ROM drive
> FJP: id_dma_bug 0x7: &4: 0x0-0x0 no error
> hdc: MWDMA2 mode selected
> FJP: id_dma_bug 0x2: &2: 0x0-0x0 no error		<-------------
> hdd: MWDMA2 mode selected
> 
> So it seems to me that in 2.6.26 something was broken in the way these ID 
> fields were handled, at least in this check. This is now fixed (possibly 

Great debugging work, thanks!

> by the changes around 5b90e990..48fb2688) and *that* causes the 
> regression. Note that the hard disks are also affected.

I see it now -- in commit c419993 ("ide-iops: only clear DMA words
on setting DMA mode") we fixed a bug in ide_config_drive_speed()..

[ It was a real bug resulting in incorrect data being passed to
  the user-space through HDIO_GET_IDENTITY ioctl ('hdparm -i'). ]
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ