Re: Potentially serious problem with kernel-headers...
>The other type of bug it could be is that it's "#include"ing a "private"
>header in the kernel. Those are allowed to change between minor releases,
>I presume? I haven't looked for this - nor do I have the expertise to find
>this kind of bug. I'm not a kernel wonk :-)
Ah, a fair suggestion. Of course, I'll find any such instance of
this too while reading the kernel diffs. If fact, I think I'll even
place a longshot guess on hdparm.h... 20:1? :-)
>Like I said, it looks like the binary compiled with kernel headers from
>2.0.34 will work under 2.0.31. I've successfully sampled a song this way
>(it did sample REALLY slow, though. Sampling a 5 minute song took something
^^^^^^^^^^^^^^^^^^^
An entirely different problem. The worse the CDROM drive, the longer
it takes. Cdparanoia will try to fix *any* abnormality, no matter how
slight, it sees in the read.
>like 15 minutes, with no indication of a problem with the CD istelf.) If I
>use headers from 2.0.32 with kernel 2.0.34 running, it blows up immediately
>while trying to query the drive.
>
>It seems to me that we might just be really lucky that new binary works on
>old kernels, and that this could be evidence of a much larger problem.
I will find out. Personally, I'm still *really* hoping this is just
something very minor. I also appreciate being able to bring this one
before a wider forum.
Monty
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: