Can you describe the pcmcia oops problem in detail?
What output do you get from a serial console?
what do you mean, oops got infinite trace? were there (a) many oops or
(b) one oops with long trace
what do you mean, double fix of /dev/XXXXX name?
is pcmcia-cs creating and removing /dev entries too?
Jeff
>>>>> "jeff" == Jeff Garzik <[email protected]> writes:
jeff> Can you describe the pcmcia oops problem in detail?
jeff> What output do you get from a serial console?
Ok, trying to get better message now.
jeff> what do you mean, oops got infinite trace? were there (a) many oops
jeff> or (b) one oops with long trace
jeff> what do you mean, double fix of /dev/XXXXX name?
I think so, but it is not possible to be sure :(
jeff> is pcmcia-cs creating and removing /dev entries too?
Ok, the problem:
plug a pcmcia card (network cards work perfect), ide_cs & modem fail).
unplug it
it just oops the kernel.
as ethX works perfect and modem & ide_cs fails, devfs is suspect
number one.
Then I boot with devfs=nomount
repeat the experiment, and everythnig works as expected (devfs is
decleared more suspect indeed).
Really devfs & devfsd are suspect.
I know that ide_cs worked before because I used it to download pics
from my camera and I had never had a single problem.
Then I boot back with kernel-linus2.4.
Everything works perfect.
In the middle, I changed devfsd from version 2.3.24 to 2.3.23, same
problems.
kernel-linus2.4 works with both devfsd.
I relaunch kernel-mdk with devfs-2.3.23, this times also oops, but it
just hangs in devfs_unregister, that calls to kmem_cache_alloc(), and
them kmem_cache_grow (here is the Ooops), this is called from a bottom
handler.
With devfsd 2.3.24, it appears that there is a stack overflow inside
devfs, and kdb is of not help to detect it (we never end the do_BUG()
function because there is a borken stack.
I have do a diff of 2.4.18 against lastest mandrake kernel and there
are:
- no devfs differences
- no changes in register/unregister calls.
that means that the problem happens as a side effect of other thing.
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
Juan Quintela writes:
> >>>>> "jeff" == Jeff Garzik <[email protected]> writes:
>
> jeff> Can you describe the pcmcia oops problem in detail?
> jeff> What output do you get from a serial console?
>
> Ok, trying to get better message now.
Can you:
- capture the Oops and decode with ksymoops
- make sure you always Cc: me on devfs-related problems (I nearly
missed this one).
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
>>>>> "richard" == Richard Gooch <[email protected]> writes:
richard> Juan Quintela writes:
>> >>>>> "jeff" == Jeff Garzik <[email protected]> writes:
>>
jeff> Can you describe the pcmcia oops problem in detail?
jeff> What output do you get from a serial console?
>>
>> Ok, trying to get better message now.
richard> Can you:
richard> - capture the Oops and decode with ksymoops
stack overflow, when we got the Oops, we have already overwrote half
the memory, i.e. the stack trace makes no sense at all :(
richard> - make sure you always Cc: me on devfs-related problems (I nearly
richard> missed this one).
Not sure what is this one, and I am beggining to think that the
problem is some subtle thing in andrea_vm.
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy