If this message appears twice, its caused by the crappy smtp server of my ISP. Sorry.
I CCed this mail to the people in the MAINTAINERS file that i thought might have more knowledge of what
might be causing this. Gadi Oxman i fetched from ide-scsi.c
Hardware:
-----------
Abit VP6
2x PIII-1Ghz
1GB SDRAM
IBM 40GB UDMA100 7200rpm connected to 1st channel of onboard HPT370
Yamaha 8824 CDRW connected to 2nd channel of onboard HPT370
Seagate 10GB UDMA66 connected to 1st channel of onboard VIA controller
ASUS 50x CDROM connected to 2nd channel of onboard VIA controller
Empty Promise ULTRA66 card
Description:
-------------
Everytime i try to burn a CD i get these messages from the kernel:
ide-scsi: CoD != 0 in idescsi_pc_intr
hdk: ATAPI reset complete
ide-scsi: CoD != 0 in idescsi_pc_intr
hdk: ATAPI reset complete
ide-scsi: scatter gather table too small, padding with zeros
ide-scsi: CoD != 0 in idescsi_pc_intr
hdk: ATAPI reset complete
ide-scsi: scatter gather table too small, padding with zeros
ide-scsi: scatter gather table too small, padding with zeros
ide-scsi: CoD != 0 in idescsi_pc_intr
hdk: ATAPI reset complete
... and then (after a variable number of those messages) the burn fails. I tried connecting the CDR to other
controllers and the only one that doesn't have this problem is the VIA controller.
Even the promise fails. So this isn't the fault of the HPT370 driver.
I tested kernels 2.4.1 , 2.4.8 & 2.4.12, 2.4.13, 2.4.13-ac5 & ac6 and all have this problem. I then tested 2.2.18
(when i still had openlinux installed. i since installed RH 7.2) with the ide patches and it runs cleanly.
Not a single message from the kernel under the same load and using the same cdrecord binary (1.10)
and the same (or equivalent) drivers loaded. So it isn't a hardware problem either.
The only thing i can find in commom between the bug ocorrences in the HPT and the Promise is that they
both share an IRQ for their 2 IDE channels. The VIA, which does not misbehave, doesn't share interrupts.
I even tried removing the Promise and disabling USB and that does not fix it. And the fact that 2.2.18 works
proves the devices support IRQ sharing. I also found out that this problem also happens when reading from
the CDR. I did not test if it causes data corruption. Also, booting with nosmp does not fix the problem either.
Any patches i could test ? Ideas ? Something ? Is this a known problem ?
--
[------------------------------------------------][-------------------------]
|"One World, One Web, One Program" - Microsoft Ad|| [email protected] |
|"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitler||http://storm.superzip.net|
[------------------------------------------------][-------------------------]
--> thor up 2 days | sentinel up 59 days | loki up 59 days <--
Sorry for replying to my own message, but i just tested 2.2.18 & 2.2.19 with
Hedrick's ide patches and they work flawlessly. I now tested for data
corruption and on 2 subsequent reads of a CD, it produces slightly different
data or simply aborts the read. I now tested both with ide-cd and ide-scsi.
Both fail. ide-cd fails on read and ide-scsi on read & write. I plan to test
with another CDRW drive just to be sure the drive isn't the problem.
On Saturday 03 November 2001 03:31, Ricardo Ferreira wrote:
>
> I tested kernels 2.4.1 , 2.4.8 & 2.4.12, 2.4.13, 2.4.13-ac5 & ac6 and all
> have this problem. I then tested 2.2.18 (when i still had openlinux
> installed. i since installed RH 7.2) with the ide patches and it runs
> cleanly. Not a single message from the kernel under the same load and using
> the same cdrecord binary (1.10) and the same (or equivalent) drivers
> loaded. So it isn't a hardware problem either.
Sorry for replying to my own message again.
On Monday 05 November 2001 15:46, Ricardo Ferreira wrote:
> ide-scsi. Both fail. ide-cd fails on read and ide-scsi on read & write. I
> plan to test with another CDRW drive just to be sure the drive isn't the
> problem.
I just tested another CDRW drive. Exactly the same messages. Again 2.2.18 &
2.2.19 have no problems. This is surely a bug in the 2.4.x kernels. This
drive works perfectly in another computer running a 2.4.x kernel (SuSE 7.2 -
dont know the kernel version now).
Its driving me crazy.