LK Prodigies:
This problem is current on the Linux-2.4.0-test11 kernel. Please tell me if
this has already been resolved - I am new to the list.
Here is my setup:
Motherboard: Soyo 6BA+IV (built-in PIIX4 and HPT366 IDE controllers)
CDRWs: Yamaha 4416S (SCSI) & Yamaha 8424E (EIDE)
Kernel: 2.4.0test11 -- I must use 2.3.X or 2.4.X since my main drives
are on the HPT366 channels.
IDE: Using both HPT and PIIX chipsets. Base system drives are on
HPT366 channels. / == /dev/hde. Works fine.
Software: cdrecord 1.8.1, cdrecord 1.9
Problem:
The problem lies with using my EIDE CDRW - I set it up properly using
IDE-SCSI. I can use my mp3tocdda shell script to encode mp3s to CD
(uses cdrecord as well) on the fly using either drive, however, when I
use cdrecord to write a data CD, the system hard-locks, no kernel
panic messages, and no Magic SysRQ keystroke works.
Quite odd that I could do the cdrecord for audio tracks, but not
data..
Anyhow, I moved the CDRW to the PIIX4 channels (and changed my lilo
append line to make hda=scsi, instead of hdg=scsi) and now both the
mp3tocdda script and cdrecord for data images works fine.
I'm thinking it's a problem with HPT366, since IDE-SCSI/PIIX4 worked
fine with the setup, and cdrecord has always been a working package
for me.
Also, the HPT366 setup screen (VERY simple) shows the CDRW using MW
DMA 2 and is unchangable thru the HPT366 BIOS. Is there something
I should be doing with hdparm on the CD device?
Thanks in advance,
Damacus Porteng
--
Damnit, Linus, I'm a network admin, not a kernel hacker!
On Wed, Nov 29, 2000 at 01:06:16PM -0600, --Damacus Porteng-- wrote:
> Problem:
> The problem lies with using my EIDE CDRW - I set it up properly using
> IDE-SCSI. I can use my mp3tocdda shell script to encode mp3s to CD
> (uses cdrecord as well) on the fly using either drive, however, when I
> use cdrecord to write a data CD, the system hard-locks, no kernel
> panic messages, and no Magic SysRQ keystroke works.
>
> Quite odd that I could do the cdrecord for audio tracks, but not
> data..
Strange. If you read data from the harddisk on an IDE channel and write it
(with cdrecord) to some CDRW on the same IDE channel, you have to expect
trouble: As with IDE there is no disconnect from the bus (as opposed to
SCSI), you risk buffer underruns.
A lockup however is not to be expected :-(
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
On Wed, 29 Nov 2000, Kurt Garloff wrote:
>
> On Wed, Nov 29, 2000 at 01:06:16PM -0600, --Damacus Porteng-- wrote:
> > Problem:
> > The problem lies with using my EIDE CDRW - I set it up properly using
> > IDE-SCSI. I can use my mp3tocdda shell script to encode mp3s to CD
> > (uses cdrecord as well) on the fly using either drive, however, when I
> > use cdrecord to write a data CD, the system hard-locks, no kernel
> > panic messages, and no Magic SysRQ keystroke works.
> >
> > Quite odd that I could do the cdrecord for audio tracks, but not
> > data..
>
> Strange. If you read data from the harddisk on an IDE channel and write it
> (with cdrecord) to some CDRW on the same IDE channel, you have to expect
> trouble: As with IDE there is no disconnect from the bus (as opposed to
> SCSI), you risk buffer underruns.
There shouldn't be any problems if you have the disk and CDrw drive on
different IDE busses, though, as I do. Also, provided the CDrw drive is
releasing the bus at times (which it should, presumably, since it can't be fast
enough to max out the bus all the time), you can then burst the data in from
the HDD, even on a shared bus. Even the fastest CDrw drive shouldn't get
underruns, I think.
Having said that, I'd still want to have both drives on different busses;
ideally, a SCSI CDrw and DVD drive, and ATA/100 HDDs. Now I just need to get
the numbers right on the lottery :-)
> A lockup however is not to be expected :-(
Indeed - a lockup is never the right result!
James.
Nope,
I have yet to enable ATAPI-DMA because of the nature of the hooks.
On Wed, 29 Nov 2000, --Damacus Porteng-- wrote:
> LK Prodigies:
>
> This problem is current on the Linux-2.4.0-test11 kernel. Please tell me if
> this has already been resolved - I am new to the list.
>
> Here is my setup:
> Motherboard: Soyo 6BA+IV (built-in PIIX4 and HPT366 IDE controllers)
> CDRWs: Yamaha 4416S (SCSI) & Yamaha 8424E (EIDE)
>
> Kernel: 2.4.0test11 -- I must use 2.3.X or 2.4.X since my main drives
> are on the HPT366 channels.
>
> IDE: Using both HPT and PIIX chipsets. Base system drives are on
> HPT366 channels. / == /dev/hde. Works fine.
>
> Software: cdrecord 1.8.1, cdrecord 1.9
>
> Problem:
> The problem lies with using my EIDE CDRW - I set it up properly using
> IDE-SCSI. I can use my mp3tocdda shell script to encode mp3s to CD
> (uses cdrecord as well) on the fly using either drive, however, when I
> use cdrecord to write a data CD, the system hard-locks, no kernel
> panic messages, and no Magic SysRQ keystroke works.
>
> Quite odd that I could do the cdrecord for audio tracks, but not
> data..
>
> Anyhow, I moved the CDRW to the PIIX4 channels (and changed my lilo
> append line to make hda=scsi, instead of hdg=scsi) and now both the
> mp3tocdda script and cdrecord for data images works fine.
>
> I'm thinking it's a problem with HPT366, since IDE-SCSI/PIIX4 worked
> fine with the setup, and cdrecord has always been a working package
> for me.
>
> Also, the HPT366 setup screen (VERY simple) shows the CDRW using MW
> DMA 2 and is unchangable thru the HPT366 BIOS. Is there something
> I should be doing with hdparm on the CD device?
>
>
> Thanks in advance,
>
> Damacus Porteng
>
> --
> Damnit, Linus, I'm a network admin, not a kernel hacker!
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
On Wed, 29 Nov 2000, Kurt Garloff wrote:
> Strange. If you read data from the harddisk on an IDE channel and write it
> (with cdrecord) to some CDRW on the same IDE channel, you have to expect
> trouble: As with IDE there is no disconnect from the bus (as opposed to
> SCSI), you risk buffer underruns.
> A lockup however is not to be expected :-(
It is completely expected bacause of teh active timing changes done on
this chipset design. The timings are for ATA DMA and not ATAPI.
You should expect a 100% hardlock on mistimed IO access.
Cheers,
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
Andre:
Is that to say that I'd experience this problem with any EIDE CDRW used on one
of the HPT366 channels, or is it to say that only several CDRWs aren't
supported under this chipset?
Also, in regards to Kurt, I wasn't running the CDRW on the same channel as the
source.
Intel PIIX4 HPT366
----------- ------
/dev/hda (CDRW, worked) /dev/hde (boot: 36.5G)
/dev/hdb /dev/hdf (storage: 61.4G)
/dev/hdc /dev/hdg (CDRW, failed)
/dev/hdd /dev/hdh
In the crashing setup, the boot drive was /dev/hde, source drive was /dev/hdf.
CDRW was /dev/hdg (Second channel, master.) In the working setup, boot and
source were the same, CDRW was moved to hda.
Regards,
Damacus Porteng
On Wed, Nov 29, 2000 at 10:27:17AM -0800, Andre Hedrick wrote:
> On Wed, 29 Nov 2000, Kurt Garloff wrote:
>
> > Strange. If you read data from the harddisk on an IDE channel and write it
> > (with cdrecord) to some CDRW on the same IDE channel, you have to expect
> > trouble: As with IDE there is no disconnect from the bus (as opposed to
> > SCSI), you risk buffer underruns.
> > A lockup however is not to be expected :-(
>
> It is completely expected bacause of teh active timing changes done on
> this chipset design. The timings are for ATA DMA and not ATAPI.
> You should expect a 100% hardlock on mistimed IO access.
>
> Cheers,
>
> Andre Hedrick
> CTO Timpanogas Research Group
> EVP Linux Development, TRG
> Linux ATA Development
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
--
Damnit, Linus, I'm a network admin, not a kernel hacker!
On Wed, 29 Nov 2000, Kurt Garloff wrote:
>Date: Wed, 29 Nov 2000 19:14:02 +0100
>From: Kurt Garloff <[email protected]>
>To: --Damacus Porteng-- <[email protected]>
>Cc: Linux kernel list <[email protected]>
>Content-Type: multipart/signed; micalg=pgp-md5;
> protocol="application/pgp-signature"; boundary="tmoQ0UElFV5VgXgH"
>Subject: Re: IDE-SCSI/HPT366 Problem
>
>On Wed, Nov 29, 2000 at 01:06:16PM -0600, --Damacus Porteng-- wrote:
>> Problem:
>> The problem lies with using my EIDE CDRW - I set it up properly using
>> IDE-SCSI. I can use my mp3tocdda shell script to encode mp3s to CD
>> (uses cdrecord as well) on the fly using either drive, however, when I
>> use cdrecord to write a data CD, the system hard-locks, no kernel
>> panic messages, and no Magic SysRQ keystroke works.
>>
>> Quite odd that I could do the cdrecord for audio tracks, but not
>> data..
>
>Strange. If you read data from the harddisk on an IDE channel and write it
>(with cdrecord) to some CDRW on the same IDE channel, you have to expect
>trouble: As with IDE there is no disconnect from the bus (as opposed to
>SCSI), you risk buffer underruns.
>A lockup however is not to be expected :-(
I reported this before as well. Blanking a CDRW on an IDE writer
and trying to mount a cdrom on an IDE reader on the slave on the
same IDE channel produces a dual oops. I got an initial response
from Alan, and I believe Jens Axboe, and never heard about it
again. I dunno if it was fixed or not. It still oops's though.
----------------------------------------------------------------------
Mike A. Harris - Linux advocate - Open source advocate
This message is copyright 2000, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
Be up to date on nerd news and stuff that matters: http://slashdot.org
On Wed, 29 Nov 2000, Damacus Porteng wrote:
> Andre:
>
> Is that to say that I'd experience this problem with any EIDE CDRW used on one
> of the HPT366 channels, or is it to say that only several CDRWs aren't
> supported under this chipset?
If you want to run it under PIO mode and not do DMAing then it will work.
Also it goes for any device that does ATAPI DMA and not ATA DMA.
There is a difference!
Cheers,
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
Hi Andre,
On Wed, Nov 29, 2000 at 10:25:45PM -0800, Andre Hedrick wrote:
> If you want to run it under PIO mode and not do DMAing then it will work.
> Also it goes for any device that does ATAPI DMA and not ATA DMA.
> There is a difference!
Could you work out this a little bit to make ot more clear?
What's the difference between ATAPI DMA and ATA DMA?
Is this a controller(chipset) or a device thing?
What controllers or devices are affected?
Is this only a problem for mixing such things on the same bus? The same
controller?
It boils down to one question:
What do the users have to avoid?
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security