eject weirdness on NEC disc changer, kernel 2.4.2

eject weirdness on NEC disc changer, kernel 2.4.2

[Jim Breton]

Hi all, I've gotten a response from the "eject" author and he seems to
agree that this is something in the kernel causing this issue.

Anyone got any ideas?  Thanks.

(P.S. I am not subscribed currently, please copy me on responses.
Gracias.)

----- Forwarded message from Jim Breton -----

From: Jim Breton
Date: Sat, 3 Mar 2001 21:34:47 +0000
Subject: eject weirdness on NEC disc changer, kernel 2.4.2

Package: eject
Version: 2.0.2-1
Severity: wishlist

Hi Jeff and Martin, I'm running a Debian 2.2r2 potato box which has an
ATAPI NEC cd changer:

$ grep NEC /var/log/dmesg 
hdd: NEC CD-ROM DRIVE:251, ATAPI CD/DVD-ROM drive

I have 4 audio CDs in the drive.  When I run the following command:

eject -c 1

it switches to slot 2 (as it should), but when I play a track off the
CD, it starts several seconds into the track rather than at the
beginning.

When I do the following:

eject -c 2
eject -c 3

I get the following in syslog:

Mar  3 16:11:30 tarkin kernel: VFS: Disk change detected on device
ide1(22,64)
Mar  3 16:11:51 tarkin kernel: hdd: irq timeout: status=0xd0 { Busy }
Mar  3 16:11:51 tarkin kernel: hdd: ATAPI reset complete

and the drive switches me back to the first slot.

If I have a data CD in a slot, I do not see this problem.

Any idea what is going on?  I tried a copy compiled straight from the
source and the same thing happens.  Considering data CDs do not make
this happen, do you think the kernel is doing something odd?  Should the
kernel really care what kind of CD is in the drive before I try to read
it?  Or is this something caused by eject?

Thanks.

P.S. I just tried cdctl ( http://sourceforge.net/projects/cdctl/ ) and
apparently the same thing occurs, so it's looking like this may be a
kernel issue.  My former kernel was 2.2.19pre9 and I didn't have any
problems there (or on any of my other 2.2.x kernels).

----- End forwarded message -----

Re: eject weirdness on NEC disc changer, kernel 2.4.2

[Wade Hampton]

Jim Breton wrote:
> 
> Hi all, I've gotten a response from the "eject" author and he seems to
> agree that this is something in the kernel causing this issue.
Have you had it where the drive would not eject the disc?  I seem 
to be having this on several ATAPI drives (CD-R, CD-ROM, DVD), 
all with ide-scsi running....

Note, this has forced me to reboot both 2.4.0, 2.4.1, and 2.4.2
(multiple boxes).

Cheers,
-- 
W. Wade, Hampton  <whampton@staffnet.com>  
If Microsoft Built Cars:  Every time they repainted the 
lines on the road, you'd have to buy a new car.
Occasionally your car would just die for no reason, and 
you'd have to restart it, but you'd just accept this.

Re: eject weirdness on NEC disc changer, kernel 2.4.2

[Jim Breton]

On Mon, Mar 05, 2001 at 01:42:47PM -0500, Wade Hampton wrote:
> Have you had it where the drive would not eject the disc?  I seem 
> to be having this on several ATAPI drives (CD-R, CD-ROM, DVD), 
> all with ide-scsi running....

That particular issue has not happened to me.

I have had a similar problem in the past where, for example, after
cancelling a burn session with cdrecord I am unable to eject the disc.
However that was on kernel 2.2.x and using "real" scsi (not ide-scsi).

In the case of my original post, I am also not using ide-scsi, just
regular ide.

Re: eject weirdness on NEC disc changer, kernel 2.4.2

[Walter Hofmann]

On Mon, 05 Mar 2001, Jim Breton wrote:

> I have had a similar problem in the past where, for example, after
> cancelling a burn session with cdrecord I am unable to eject the disc.
> However that was on kernel 2.2.x and using "real" scsi (not ide-scsi).

This was a bug in cdrecord which used generic scsi access to lock the
drive. The kernel cannot notice this. AFAIK this bug is fixed in
cdrecord.

Walter

Re: eject weirdness on NEC disc changer, kernel 2.4.2

[Jim Breton]

From: Walter Hofmann (walter.hofmann@physik.stud.uni-erlangen.de)
Date: Mon Mar 05 2001 - 15:19:10 EST 

>> cancelling a burn session with cdrecord I am unable to eject the disc. 
>> However that was on kernel 2.2.x and using "real" scsi (not ide-scsi). 

>This was a bug in cdrecord which used generic scsi access to lock the 
>drive. The kernel cannot notice this. AFAIK this bug is fixed in 
>cdrecord. 

K, thanks.  I will have to upgrade once I figure out why my burner box
just beeps at me when I try to turn it on.  ;-\

So, anybody know what is up with the kernel?  :)  Again the issue I
originally posted about is a problem with standard ATAPI stuff (not
ide-scsi).