On Wed, Jul 16, 2003 at 02:20:36AM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> I spotted following difference between old (<=2.4.20) and new
> (>=2.4.21 and 2.6) code. Just a guess...
>
> --- alim15x3.c.orig 2003-04-20 04:49:10.000000000 +0200
> +++ alim15x3.c 2003-07-16 02:09:05.411225464 +0200
> @@ -595,6 +595,26 @@
>
> local_irq_save(flags);
>
> + /*
> + * CD_ROM DMA on (m5229, 0x53, bit0)
> + * Enable this bit even if we want to use PIO
> + * PIO FIFO off (m5229, 0x53, bit1)
> + * The hardware will use 0x54h and 0x55h to control PIO FIFO
> + * (Not on later devices it seems)
> + *
> + * 0x53 changes meaning on later revs - we must no touch
> + * bit 1 on them. Need to check if 0x20 is the right break
> + */
> +
> + pci_read_config_byte(dev, 0x53, &tmpbyte);
> +
> + if (m5229_revision <= 0x20)
> + tmpbyte = (tmpbyte & (~0x02)) | 0x01;
> + else
> + tmpbyte |= 0x01;
> +
> + pci_write_config_byte(dev, 0x53, tmpbyte);
> +
> if (m5229_revision < 0xC2) {
> /*
> * revision 0x20 (1543-E, 1543-F)
> @@ -706,26 +726,6 @@
> chip_is_1543c_e = ((tmpbyte & 0x1e) == 0x12) ? 1: 0;
> }
>
> - /*
> - * CD_ROM DMA on (m5229, 0x53, bit0)
> - * Enable this bit even if we want to use PIO
> - * PIO FIFO off (m5229, 0x53, bit1)
> - * The hardware will use 0x54h and 0x55h to control PIO FIFO
> - * (Not on later devices it seems)
> - *
> - * 0x53 changes meaning on later revs - we must no touch
> - * bit 1 on them. Need to check if 0x20 is the right break
> - */
> -
> - pci_read_config_byte(dev, 0x53, &tmpbyte);
> -
> - if(m5229_revision <= 0x20)
> - tmpbyte = (tmpbyte & (~0x02)) | 0x01;
> - else
> - tmpbyte |= 0x01;
> -
> - pci_write_config_byte(dev, 0x53, tmpbyte);
> -
> local_irq_restore(flags);
>
> return(ata66);
>
Apply this patch and rebooting with this new kernel made no difference.
I tried a few more things as well:
Disconnect CD-ROM: Same problem as before.
Boot with 'ide0=autotune': Same problem as before
I was e-mailed a suggestion to try booting with 'noapic', and that
didn't help either. I'm currently running the patched kernel booted with
the 'ide=nodma' argument.
As things just go to pieces when reading the hard drive, maybe someone
knows if this hard drive model has known DMA issues. When starting the
machine the screens before my lilo prompt print out that the hard drive
should do UDMA. The hard drive on the ide1 channel seems to present no
problem to the ALi controller. Here is agin the hdparm info on my
troublesome drive:
$ hdparm -I /dev/hda
/dev/hda:
ATA device, with non-removable media
Model Number: ST33232A
Serial Number: GH593339
Firmware Revision: 3.02
Standards:
Supported: 2 1
Likely used: 4
Configuration:
Logical max current
cylinders 6253 6253
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 6303024
LBA user addressable sectors: 6303024
device size with M = 1024*1024: 3077 MBytes
device size with M = 1000*1000: 3227 MBytes (3 GB)
Capabilities:
LBA, IORDY(can be disabled)
Buffer size: 128.0kB bytes avail on r/w long: 4 Queue depth: 1
Standby timer values: spec'd by Vendor
R/W multiple sector transfer: Max = 16 Current = 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=383ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
Power Management feature set
SMART feature set
This hard drive is from 1996/1997; it is the original hard drive I built
this machine with. The 'Standards' line above looks odd - a clue
perhaps?
The second hard drive I added about 3 years ago. Here is info on it:
$ hdparm -I /dev/hdc
/dev/hdc:
ATA device, with non-removable media
Model Number: FUJITSU MPD3084AT
Serial Number: 05043987
Firmware Revision: DD-03-47
Standards:
Supported: 4 3 2 1
Likely used: 4
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 16514064
device size with M = 1024*1024: 8063 MBytes
device size with M = 1000*1000: 8455 MBytes (8 GB)
Capabilities:
LBA, IORDY(cannot be disabled)
Buffer size: 512.0kB bytes avail on r/w long: 4 Queue depth: 1
Standby timer values: spec'd by Vendor
R/W multiple sector transfer: Max = 16 Current = ?
Advanced power management level: unknown setting (0x0000)
DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
READ BUFFER cmd
WRITE BUFFER cmd
Host Protected Area feature set
* Look-ahead
* Write cache
Power Management feature set
Security Mode feature set
* SMART feature set
Advanced Power Management feature set
Security:
supported
not enabled
not locked
not frozen
not expired: security count
not supported: enhanced erase
24min for SECURITY ERASE UNIT.
If the hard drives seem to be alright, maybe there is some sort of BIOS
thing I should try? I've poked around in the BIOS setup numerous times
but never found anything that I could change and make things work.
Art Haas
-- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind.-Thomas Jefferson to James Smith, 1822 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:25 EST