Re: [linuxdc-dev]root=/dev/gdrom

[M. R. B. <mr...@0x...>]

* mag <ma...@ro...> on Sat, Feb 09, 2002:

> ...     Uniform CD-ROM driver Revision: 
> 3.12                                            SEGA Dreamcast GD-ROM 
> driver                                                    AICA audio 
> device driver for Dreamcast Linux - ver 0.1-pre15                    
> SEGA Dreamcast MAPLE Bus 
> drivers                                                NET4: Linux 
> TCP/IP 1.0 for NET4.0                                               IP 
> Protocols: ICMP, UDP, 
> TCP                                                    IP: routing 
> cache hash table of 512 buckets, 4Kbytes                            
> TCP: Hash tables configured (established 1024 bind 
> 2048)                        NET4: Unix domain sockets 1.0/SMP for 
> Linux NET4.0.                             GD-ROM: Got larger result
>

Hmm, so can I safely assume that you're using the linux-sh-dc from CVS?
Even though we never officially said it, the linux-sh-dc is highly unstable
and experimental and is subject to random breakage (yeah, I know
development isn't *that* active, but the warning stands), so it's only
recommended for developers.

Of course the problem you're describing here has nothing to do with the
status of the tree, but I just wanted to relay our official position on
using it.

> And that's it. It is not frozen or anything, (it registers maple 
> (dis)connect events), but it's not going anywhere either. The "GD-ROM: 
> Got larger result" message looks suspicios, but as far as i could tell 
> from briefly looking at the code, is not fatal.
> 

Not fatal, but possibly dangerous.  It looks like it prints this message
when the command int handler receives the result from a command bigger than
what's expected.  In this case it truncates that data, and that's where the
danger comes in.

> Another idea that crossed my mind, was that this could be caused by me 
> trying to use devfs, but not having the devfsd (yet). But I don't think 
> that that's the problem, because I am pretty sure it does not even get 
> to the first startup scripts anyway, and that's where it is normally 
> started.  

Could you let us know if it still fails if you use the manually created
device node (`mknod gdrom b 250 0')?

Also, I've attached a patch that prints out GD-ROM command values in hex.
If the problem persists, could you send a dump of the command values
printed?

If it's something more, I'll try to look into it.

M. R.