pcmcia oops problem?
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"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.
Signature · 2 lines
In theory, practice and theory are the same, but in practice they are different -- Larry McVoy
Quoted 6 lines · Juan Quintela
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"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]
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"richard" == Richard Gooch <[email protected]> writes:
Quoted 2 lines · richard> Juan Quintela writes:
Quoted 2 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"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?
Quoted 2 lines
Quoted 2 lines
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.
Signature · 2 lines
In theory, practice and theory are the same, but in practice they are different -- Larry McVoy