erik quanstrom ha scritto:
I regret not to have more detailed info. I suspect there is something
changed in the detach primitives or so. But its only a very personal
opinion.
hmm. would it be too much to ask to request a ps of the processes that
failed to exit? i really would just like to know what state they're in.
i think this may have been a latent bug that just came out.
- erik
Working on a Bell I've at home, downloaded a few weeks ago.
The kernel is built using the same config used on the field,
where the wrong behaviour has been noted.
The modified usbd and thebcscan process are embedded.
After booting with the reader plugged in (normal condition):
bootes 12 0:00 0:00 336K Pread bcscan
bootes 13 0:00 0:00 336K Rendez bcscan
bootes 14 0:00 0:00 336K Rendez bcscan
bootes 19 0:00 0:00 336K Pread bcscan
Here mount /srv/bcscan /n/bc gives a readable /n/bc/bcU0/data.
Then the reader is unplugged
bootes 12 0:00 0:00 336K Pread bcscan
bootes 13 0:00 0:00 336K Rendez bcscan
bootes 14 0:00 0:00 336K Rendez bcscan
Plaese note that here we see a different case. There are three
spurious processes. On the plant (same test) there is only one.
Then the reader is plugged in again
bootes 13 0:00 0:00 336K Rendez bcscan
bootes 14 0:00 0:00 336K Rendez bcscan
bootes 432 0:00 0:00 336K Rendez bcscan
bootes 434 0:00 0:00 336K Pread bcscan
bootes 435 0:00 0:00 336K Rendez bcscan
bootes 436 0:00 0:00 336K Rendez bcscan
bootes 437 0:00 0:00 336K Open bcscan
Here mount /srv/bcscan /n/bc gives an empty /n/bc but doesn't
complain.
adriano
