pcmcia oops problem?

pcmcia oops problem?

[Jeff Garzik]

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

Re: pcmcia oops problem?

[Juan Quintela]

>>>>> "jeff" == Jeff Garzik <jgarzik@mandrakesoft.com> 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

Re: pcmcia oops problem?

[Richard Gooch]

Juan Quintela writes:
> >>>>> "jeff" == Jeff Garzik <jgarzik@mandrakesoft.com> 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: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: pcmcia oops problem?

[Juan Quintela]

>>>>> "richard" == Richard Gooch <rgooch@ras.ucalgary.ca> writes:

richard> Juan Quintela writes:
>> >>>>> "jeff" == Jeff Garzik <jgarzik@mandrakesoft.com> 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