Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: > > correction: my driver schedules (wakes kthread in 0.7) mmc_remove_host - > noticed it only now > Ok, good. Then things are as they should on your part. > > That's why I think that simply flushing the workqueue is enough. If workqueue > is empty we know for > sure that device_add has exited. > >From -mm: http://www.kernel.org/git/?p=linux/kernel/git/drzeus/mmc.git;a=commitdiff;h=e89bac488861ebadfca3a74321af19a262dcbd08 Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
> > > > mmc_rescan > > mmc_register_card > > device_add > > mmc_block_probe > > mmc_block_alloc > > -> queue thread starts running > > add_disk > > -> issues a lot of requests; card fails, my drivers calls > > mmc_remove_host, which in correction: my driver schedules (wakes kthread in 0.7) mmc_remove_host - noticed it only now > > turn calls device_del, though we are still in device_add > > > That's why I think that simply flushing the workqueue is enough. If workqueue is empty we know for sure that device_add has exited. Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: > > mmc_rescan > mmc_register_card > device_add > mmc_block_probe > mmc_block_alloc > -> queue thread starts running > add_disk > -> issues a lot of requests; card fails, my drivers calls > mmc_remove_host, which in > turn calls device_del, though we are still in device_add > Ahhh, now I see. Well that's an entirely different kettle of fish. Removing the device in this stack is not supported (we would have a whole bunch of nasty dead lock possibilities to consider). You need to delay the removal in some form, e.g. using the mmc workqueue. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
--- Pierre Ossman <[EMAIL PROTECTED]> wrote: > Alex Dubov wrote: > > > > You'll agree, I think, that add_disk in mmc_block_probe issues a lot of > > requests (reads > partition > > table, fs superblocks and such - plenty of room for critical errors). Then, > > driver's remove > method > > will not be called before driver's probe method had finished. So mmc_block > > is quite involved, > even > > though it does not affect the problem's resolution. > > I agree that mmc_block's probe method will generate a whole bunch of requests. > But I don't see how that can be called given the scenario you describe. mmc_rescan mmc_register_card device_add mmc_block_probe mmc_block_alloc -> queue thread starts running add_disk -> issues a lot of requests; card fails, my drivers calls mmc_remove_host, which in turn calls device_del, though we are still in device_add Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
--- Pierre Ossman [EMAIL PROTECTED] wrote: Alex Dubov wrote: You'll agree, I think, that add_disk in mmc_block_probe issues a lot of requests (reads partition table, fs superblocks and such - plenty of room for critical errors). Then, driver's remove method will not be called before driver's probe method had finished. So mmc_block is quite involved, even though it does not affect the problem's resolution. I agree that mmc_block's probe method will generate a whole bunch of requests. But I don't see how that can be called given the scenario you describe. mmc_rescan mmc_register_card device_add mmc_block_probe mmc_block_alloc - queue thread starts running add_disk - issues a lot of requests; card fails, my drivers calls mmc_remove_host, which in turn calls device_del, though we are still in device_add Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: mmc_rescan mmc_register_card device_add mmc_block_probe mmc_block_alloc - queue thread starts running add_disk - issues a lot of requests; card fails, my drivers calls mmc_remove_host, which in turn calls device_del, though we are still in device_add Ahhh, now I see. Well that's an entirely different kettle of fish. Removing the device in this stack is not supported (we would have a whole bunch of nasty dead lock possibilities to consider). You need to delay the removal in some form, e.g. using the mmc workqueue. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
mmc_rescan mmc_register_card device_add mmc_block_probe mmc_block_alloc - queue thread starts running add_disk - issues a lot of requests; card fails, my drivers calls mmc_remove_host, which in correction: my driver schedules (wakes kthread in 0.7) mmc_remove_host - noticed it only now turn calls device_del, though we are still in device_add That's why I think that simply flushing the workqueue is enough. If workqueue is empty we know for sure that device_add has exited. Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: correction: my driver schedules (wakes kthread in 0.7) mmc_remove_host - noticed it only now Ok, good. Then things are as they should on your part. That's why I think that simply flushing the workqueue is enough. If workqueue is empty we know for sure that device_add has exited. From -mm: http://www.kernel.org/git/?p=linux/kernel/git/drzeus/mmc.git;a=commitdiff;h=e89bac488861ebadfca3a74321af19a262dcbd08 Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: > > You'll agree, I think, that add_disk in mmc_block_probe issues a lot of > requests (reads partition > table, fs superblocks and such - plenty of room for critical errors). Then, > driver's remove method > will not be called before driver's probe method had finished. So mmc_block is > quite involved, even > though it does not affect the problem's resolution. I agree that mmc_block's probe method will generate a whole bunch of requests. But I don't see how that can be called given the scenario you describe. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
> > This is hard to trigger problem, so I'll spare you the rather lengthy log. > > It happens if card timeouts and mmc_remove_host is called while > > mmc_register_card is still in > > progress (the hint was in crash dump). If I sleep before remove, it gives > > the > mmc_register_card > > chance to finish/mark card as dead and everything's fine. > > The remove callback of mmc_block is apparently not executed in this case > > (probably because > device > > has not finished registering). > > Let's see, you manage to call mmc_remove_host() when a detection is pending in > the workqueue? That could indeed generate new request (up until > mmc_free_host() > is called), but as the card is removed the mmc layer shouldn't be able to > detect > anything, hence mmc_block should never get involved. > You'll agree, I think, that add_disk in mmc_block_probe issues a lot of requests (reads partition table, fs superblocks and such - plenty of room for critical errors). Then, driver's remove method will not be called before driver's probe method had finished. So mmc_block is quite involved, even though it does not affect the problem's resolution. Besides this, I have a new version of the tifm driver to submit. It fixes quite a few problems and improves performance a little. Hopefully, it's better tested than the previous one. Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: > This is hard to trigger problem, so I'll spare you the rather lengthy log. > It happens if card timeouts and mmc_remove_host is called while > mmc_register_card is still in > progress (the hint was in crash dump). If I sleep before remove, it gives the > mmc_register_card > chance to finish/mark card as dead and everything's fine. > The remove callback of mmc_block is apparently not executed in this case > (probably because device > has not finished registering). Let's see, you manage to call mmc_remove_host() when a detection is pending in the workqueue? That could indeed generate new request (up until mmc_free_host() is called), but as the card is removed the mmc layer shouldn't be able to detect anything, hence mmc_block should never get involved. > > My proposition: lets flush the workqueue first thing in the mmc_remove_host > (and make sure that > nothing gets scheduled into it after this). > This is fixed in -mm. Making sure that nothing gets scheduled is the driver's responsibility. I've added checks to catch broken drivers though. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
> > I don't see how that is possible. mmc_block's remove routine waits for mmcqd > to > exit, so there can't be any code still alive that has a request going. (I am > also completely unable to reproduce this problem here). > > Add more printk:s do verify how the code in mmc_block executes. > This is hard to trigger problem, so I'll spare you the rather lengthy log. It happens if card timeouts and mmc_remove_host is called while mmc_register_card is still in progress (the hint was in crash dump). If I sleep before remove, it gives the mmc_register_card chance to finish/mark card as dead and everything's fine. The remove callback of mmc_block is apparently not executed in this case (probably because device has not finished registering). My proposition: lets flush the workqueue first thing in the mmc_remove_host (and make sure that nothing gets scheduled into it after this). Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: >> I don't actually think that is what happening. The block errors tend to >> trail a >> bit behind, so the errors you are seeing are probably the result of the queue >> being flushed out as you remove the card. I don't see any mmc debug messages >> that indicate that is trying to send more mmc requests. > > Yes, indeed - it does not issue new requests after remove. However, > mmc_remove_host does not wait > for all issued requests to complete and it is a problem. I don't see how that is possible. mmc_block's remove routine waits for mmcqd to exit, so there can't be any code still alive that has a request going. (I am also completely unable to reproduce this problem here). Add more printk:s do verify how the code in mmc_block executes. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: I don't actually think that is what happening. The block errors tend to trail a bit behind, so the errors you are seeing are probably the result of the queue being flushed out as you remove the card. I don't see any mmc debug messages that indicate that is trying to send more mmc requests. Yes, indeed - it does not issue new requests after remove. However, mmc_remove_host does not wait for all issued requests to complete and it is a problem. I don't see how that is possible. mmc_block's remove routine waits for mmcqd to exit, so there can't be any code still alive that has a request going. (I am also completely unable to reproduce this problem here). Add more printk:s do verify how the code in mmc_block executes. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
I don't see how that is possible. mmc_block's remove routine waits for mmcqd to exit, so there can't be any code still alive that has a request going. (I am also completely unable to reproduce this problem here). Add more printk:s do verify how the code in mmc_block executes. This is hard to trigger problem, so I'll spare you the rather lengthy log. It happens if card timeouts and mmc_remove_host is called while mmc_register_card is still in progress (the hint was in crash dump). If I sleep before remove, it gives the mmc_register_card chance to finish/mark card as dead and everything's fine. The remove callback of mmc_block is apparently not executed in this case (probably because device has not finished registering). My proposition: lets flush the workqueue first thing in the mmc_remove_host (and make sure that nothing gets scheduled into it after this). Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: This is hard to trigger problem, so I'll spare you the rather lengthy log. It happens if card timeouts and mmc_remove_host is called while mmc_register_card is still in progress (the hint was in crash dump). If I sleep before remove, it gives the mmc_register_card chance to finish/mark card as dead and everything's fine. The remove callback of mmc_block is apparently not executed in this case (probably because device has not finished registering). Let's see, you manage to call mmc_remove_host() when a detection is pending in the workqueue? That could indeed generate new request (up until mmc_free_host() is called), but as the card is removed the mmc layer shouldn't be able to detect anything, hence mmc_block should never get involved. My proposition: lets flush the workqueue first thing in the mmc_remove_host (and make sure that nothing gets scheduled into it after this). This is fixed in -mm. Making sure that nothing gets scheduled is the driver's responsibility. I've added checks to catch broken drivers though. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
This is hard to trigger problem, so I'll spare you the rather lengthy log. It happens if card timeouts and mmc_remove_host is called while mmc_register_card is still in progress (the hint was in crash dump). If I sleep before remove, it gives the mmc_register_card chance to finish/mark card as dead and everything's fine. The remove callback of mmc_block is apparently not executed in this case (probably because device has not finished registering). Let's see, you manage to call mmc_remove_host() when a detection is pending in the workqueue? That could indeed generate new request (up until mmc_free_host() is called), but as the card is removed the mmc layer shouldn't be able to detect anything, hence mmc_block should never get involved. You'll agree, I think, that add_disk in mmc_block_probe issues a lot of requests (reads partition table, fs superblocks and such - plenty of room for critical errors). Then, driver's remove method will not be called before driver's probe method had finished. So mmc_block is quite involved, even though it does not affect the problem's resolution. Besides this, I have a new version of the tifm driver to submit. It fixes quite a few problems and improves performance a little. Hopefully, it's better tested than the previous one. Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: You'll agree, I think, that add_disk in mmc_block_probe issues a lot of requests (reads partition table, fs superblocks and such - plenty of room for critical errors). Then, driver's remove method will not be called before driver's probe method had finished. So mmc_block is quite involved, even though it does not affect the problem's resolution. I agree that mmc_block's probe method will generate a whole bunch of requests. But I don't see how that can be called given the scenario you describe. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
> I don't actually think that is what happening. The block errors tend to trail > a > bit behind, so the errors you are seeing are probably the result of the queue > being flushed out as you remove the card. I don't see any mmc debug messages > that indicate that is trying to send more mmc requests. Yes, indeed - it does not issue new requests after remove. However, mmc_remove_host does not wait for all issued requests to complete and it is a problem. Here's my remove procedure: 1. cut off interrupt signaling call back - no tasklets will be coming from here 2. kill request completion tasklet 3. check if there's still an unfinished request - if yes, schedule a completion tasklet 3a. if I'll sleep here, just scheduled tasklet will have a chance to complete 3b. This is what happens if I don't sleep: (this line is printed by completion tasklet: tifm_sd0:3: num_bl 7, b_s 512, bsh 443) -- Feb 18 15:22:40 mortug tifm_sd0:3 : card failed to respond for a long period of time (12, 1) Feb 18 15:22:40 mortug tifm_7xx1 :06:09.3: checking media set 8 Feb 18 15:22:40 mortug tifm0 : demand removing card from socket 0:3 Feb 18 15:22:40 mortug mmc0: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 Feb 18 15:22:40 mortug tifm_sd tifm_sd0:3: ios: clock = 0, vdd = 0, bus_mode = 1, chip_select = 0, power_mode = 0, bus_width = 0 Feb 18 15:22:40 mortug tifm_sd tifm_sd0:3: after remove Feb 18 15:22:40 mortug tifm_sd tifm_sd0:3: num_bl 7, b_s 512, bsh 443 Feb 18 15:22:40 mortug mmc0: req done (CMD18): 1/0/1: 0900 Feb 18 15:22:40 mortug mmcblk0: error 1 sending read/write command Feb 18 15:22:40 mortug end_request: I/O error, dev mmcblk0, sector 0 Feb 18 15:22:40 mortug printk: 79 messages suppressed. Feb 18 15:22:40 mortug Buffer I/O error on device mmcblk0, logical block 0 Feb 18 15:22:40 mortug divide error: [1] SMP Feb 18 15:22:40 mortug CPU 0 .. Feb 18 15:22:40 mortug Call Trace: Feb 18 15:22:40 mortug [] :mmc_block:mmc_blk_issue_rq+0xf0/0x600 Feb 18 15:22:40 mortug [] __alloc_pages+0x69/0x2f0 Feb 18 15:22:40 mortug [] do_wp_page+0x4b1/0x510 Feb 18 15:22:40 mortug [] task_rq_lock+0x50/0x90 Feb 18 15:22:40 mortug [] __activate_task+0x38/0x50 Feb 18 15:22:40 mortug [] try_to_wake_up+0x42b/0x440 Feb 18 15:22:40 mortug [] elv_rb_del+0x2d/0x50 Feb 18 15:22:40 mortug [] elv_next_request+0x15d/0x1e0 Feb 18 15:22:40 mortug [] :mmc_core:mmc_queue_thread+0xd8/0x110 Feb 18 15:22:40 mortug [] :mmc_core:mmc_queue_thread+0x0/0x110 Feb 18 15:22:40 mortug [] keventd_create_kthread+0x0/0x90 Feb 18 15:22:40 mortug [] kthread+0xd9/0x120 Feb 18 15:22:40 mortug [] child_rip+0xa/0x12 Feb 18 15:22:40 mortug [] keventd_create_kthread+0x0/0x90 Feb 18 15:22:40 mortug [] kthread+0x0/0x120 Feb 18 15:22:40 mortug [] child_rip+0x0/0x12 Feb 18 15:22:40 mortug Feb 18 15:22:40 mortug Feb 18 15:22:40 mortug Code: f7 f6 41 01 c1 41 83 f8 01 19 c0 25 10 b6 fd ff 05 90 d0 03 Feb 18 15:22:40 mortug RIP [] :mmc_core:mmc_set_data_timeout+0x7c/0xb0 Feb 18 15:22:40 mortug RSP Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote:
> I removed that line altogether (it does not really needed as mmc host will
> not be accessed
> anymore). The problem is more elaborate. Here, the card fails,
> mmc_host_remove is called without
> sleep beforehand, and "after remove" message is printed immediately after it.
> Only then, mmc_block
> remembers to finish its business. If I leave the sleep in place, mmc_block's
> stuff will get
> scheduled before the mmc_remove_host and everything will be all right.
> You may also notice that host is already powered off ("Setting ... power 0"
> message) and still
> mmc_block continues to make requests like nothing happened.
>
I don't actually think that is what happening. The block errors tend to trail a
bit behind, so the errors you are seeing are probably the result of the queue
being flushed out as you remove the card. I don't see any mmc debug messages
that indicate that is trying to send more mmc requests.
You could add a printk to the queue thread in mmc_queue.c. That will allow you
to see exactly when it exits (which should be before mmc_remove_host() returns).
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: > If we are already on the topic, I would like to report two additional issues > with mmc_block: > > 1. If, for some reason, device driver cannot return the requested data > amount, but does not sets > any error, mmc_block would retry indefinitely. Of course, its always a device > driver's fault, but > may be we can set some limit on retry count (this can help a lot with > debugging). Well, we could add a check that data requests get fully satisfied. > > And the more serious: > 2. There was a write corruption problem with tifm_sd caused by missing wait > cycle (card busy/card > not busy) after stop command. It should not had been a problem (the mmc layer > was spinning around > with CMD13 untill the card become not-busy), but for some reason it was. We > are currently testing > this. The intersting part, however, is behavior of mmc_block given this > situation: > > It appears that mmc_block's instance manages to get stuck because of this. > The symptoms: module > usage count is not decremented when low level driver is unloaded and > partition block devices do > not get created afterwards. The fun part: the main block device gets created > and deleted on card > insertion/removal and its dump is correct (dd if=/dev/mmcblk0 ...); yet > partition detection does > not happens. To fix this, one have to reboot the machine or to wait about 30 > minutes for mmc_block > to regain its senses (then it becomes rmmod'able again). > > On the other hand, it may be some sort of generic block layer problem. > The block layer can get a bit fuzzy when you start yanking device out from under it. That said, the mmc block driver should be forgiving. So if you can figure out what it is up to (and more exactly how it is provoked), I'll try to fix it. -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: If we are already on the topic, I would like to report two additional issues with mmc_block: 1. If, for some reason, device driver cannot return the requested data amount, but does not sets any error, mmc_block would retry indefinitely. Of course, its always a device driver's fault, but may be we can set some limit on retry count (this can help a lot with debugging). Well, we could add a check that data requests get fully satisfied. And the more serious: 2. There was a write corruption problem with tifm_sd caused by missing wait cycle (card busy/card not busy) after stop command. It should not had been a problem (the mmc layer was spinning around with CMD13 untill the card become not-busy), but for some reason it was. We are currently testing this. The intersting part, however, is behavior of mmc_block given this situation: It appears that mmc_block's instance manages to get stuck because of this. The symptoms: module usage count is not decremented when low level driver is unloaded and partition block devices do not get created afterwards. The fun part: the main block device gets created and deleted on card insertion/removal and its dump is correct (dd if=/dev/mmcblk0 ...); yet partition detection does not happens. To fix this, one have to reboot the machine or to wait about 30 minutes for mmc_block to regain its senses (then it becomes rmmod'able again). On the other hand, it may be some sort of generic block layer problem. The block layer can get a bit fuzzy when you start yanking device out from under it. That said, the mmc block driver should be forgiving. So if you can figure out what it is up to (and more exactly how it is provoked), I'll try to fix it. -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: I removed that line altogether (it does not really needed as mmc host will not be accessed anymore). The problem is more elaborate. Here, the card fails, mmc_host_remove is called without sleep beforehand, and after remove message is printed immediately after it. Only then, mmc_block remembers to finish its business. If I leave the sleep in place, mmc_block's stuff will get scheduled before the mmc_remove_host and everything will be all right. You may also notice that host is already powered off (Setting ... power 0 message) and still mmc_block continues to make requests like nothing happened. I don't actually think that is what happening. The block errors tend to trail a bit behind, so the errors you are seeing are probably the result of the queue being flushed out as you remove the card. I don't see any mmc debug messages that indicate that is trying to send more mmc requests. You could add a printk to the queue thread in mmc_queue.c. That will allow you to see exactly when it exits (which should be before mmc_remove_host() returns). Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
I don't actually think that is what happening. The block errors tend to trail a bit behind, so the errors you are seeing are probably the result of the queue being flushed out as you remove the card. I don't see any mmc debug messages that indicate that is trying to send more mmc requests. Yes, indeed - it does not issue new requests after remove. However, mmc_remove_host does not wait for all issued requests to complete and it is a problem. Here's my remove procedure: 1. cut off interrupt signaling call back - no tasklets will be coming from here 2. kill request completion tasklet 3. check if there's still an unfinished request - if yes, schedule a completion tasklet 3a. if I'll sleep here, just scheduled tasklet will have a chance to complete 3b. This is what happens if I don't sleep: (this line is printed by completion tasklet: tifm_sd0:3: num_bl 7, b_s 512, bsh 443) -- Feb 18 15:22:40 mortug tifm_sd0:3 : card failed to respond for a long period of time (12, 1) Feb 18 15:22:40 mortug tifm_7xx1 :06:09.3: checking media set 8 Feb 18 15:22:40 mortug tifm0 : demand removing card from socket 0:3 Feb 18 15:22:40 mortug mmc0: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 Feb 18 15:22:40 mortug tifm_sd tifm_sd0:3: ios: clock = 0, vdd = 0, bus_mode = 1, chip_select = 0, power_mode = 0, bus_width = 0 Feb 18 15:22:40 mortug tifm_sd tifm_sd0:3: after remove Feb 18 15:22:40 mortug tifm_sd tifm_sd0:3: num_bl 7, b_s 512, bsh 443 Feb 18 15:22:40 mortug mmc0: req done (CMD18): 1/0/1: 0900 Feb 18 15:22:40 mortug mmcblk0: error 1 sending read/write command Feb 18 15:22:40 mortug end_request: I/O error, dev mmcblk0, sector 0 Feb 18 15:22:40 mortug printk: 79 messages suppressed. Feb 18 15:22:40 mortug Buffer I/O error on device mmcblk0, logical block 0 Feb 18 15:22:40 mortug divide error: [1] SMP Feb 18 15:22:40 mortug CPU 0 .. Feb 18 15:22:40 mortug Call Trace: Feb 18 15:22:40 mortug [88111280] :mmc_block:mmc_blk_issue_rq+0xf0/0x600 Feb 18 15:22:40 mortug [8020f199] __alloc_pages+0x69/0x2f0 Feb 18 15:22:40 mortug [802110f1] do_wp_page+0x4b1/0x510 Feb 18 15:22:40 mortug [8028d690] task_rq_lock+0x50/0x90 Feb 18 15:22:40 mortug [8028d958] __activate_task+0x38/0x50 Feb 18 15:22:40 mortug [80248ebb] try_to_wake_up+0x42b/0x440 Feb 18 15:22:40 mortug [8038d43d] elv_rb_del+0x2d/0x50 Feb 18 15:22:40 mortug [8038de2d] elv_next_request+0x15d/0x1e0 Feb 18 15:22:40 mortug [8821c9b8] :mmc_core:mmc_queue_thread+0xd8/0x110 Feb 18 15:22:40 mortug [8821c8e0] :mmc_core:mmc_queue_thread+0x0/0x110 Feb 18 15:22:40 mortug [802a4d30] keventd_create_kthread+0x0/0x90 Feb 18 15:22:40 mortug [80233169] kthread+0xd9/0x120 Feb 18 15:22:40 mortug [80262ec8] child_rip+0xa/0x12 Feb 18 15:22:40 mortug [802a4d30] keventd_create_kthread+0x0/0x90 Feb 18 15:22:40 mortug [80233090] kthread+0x0/0x120 Feb 18 15:22:40 mortug [80262ebe] child_rip+0x0/0x12 Feb 18 15:22:40 mortug Feb 18 15:22:40 mortug Feb 18 15:22:40 mortug Code: f7 f6 41 01 c1 41 83 f8 01 19 c0 25 10 b6 fd ff 05 90 d0 03 Feb 18 15:22:40 mortug RIP [8821a44c] :mmc_core:mmc_set_data_timeout+0x7c/0xb0 Feb 18 15:22:40 mortug RSP 81003ad97c98 Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
If we are already on the topic, I would like to report two additional issues with mmc_block: 1. If, for some reason, device driver cannot return the requested data amount, but does not sets any error, mmc_block would retry indefinitely. Of course, its always a device driver's fault, but may be we can set some limit on retry count (this can help a lot with debugging). And the more serious: 2. There was a write corruption problem with tifm_sd caused by missing wait cycle (card busy/card not busy) after stop command. It should not had been a problem (the mmc layer was spinning around with CMD13 untill the card become not-busy), but for some reason it was. We are currently testing this. The intersting part, however, is behavior of mmc_block given this situation: It appears that mmc_block's instance manages to get stuck because of this. The symptoms: module usage count is not decremented when low level driver is unloaded and partition block devices do not get created afterwards. The fun part: the main block device gets created and deleted on card insertion/removal and its dump is correct (dd if=/dev/mmcblk0 ...); yet partition detection does not happens. To fix this, one have to reboot the machine or to wait about 30 minutes for mmc_block to regain its senses (then it becomes rmmod'able again). On the other hand, it may be some sort of generic block layer problem. Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
If we are already on the topic, I would like to report two additional issues with mmc_block: 1. If, for some reason, device driver cannot return the requested data amount, but does not sets any error, mmc_block would retry indefinitely. Of course, its always a device driver's fault, but may be we can set some limit on retry count (this can help a lot with debugging). And the more serious: 2. There was a write corruption problem with tifm_sd caused by missing wait cycle (card busy/card not busy) after stop command. It should not had been a problem (the mmc layer was spinning around with CMD13 untill the card become not-busy), but for some reason it was. We are currently testing this. The intersting part, however, is behavior of mmc_block given this situation: It appears that mmc_block's instance manages to get stuck because of this. The symptoms: module usage count is not decremented when low level driver is unloaded and partition block devices do not get created afterwards. The fun part: the main block device gets created and deleted on card insertion/removal and its dump is correct (dd if=/dev/mmcblk0 ...); yet partition detection does not happens. To fix this, one have to reboot the machine or to wait about 30 minutes for mmc_block to regain its senses (then it becomes rmmod'able again). On the other hand, it may be some sort of generic block layer problem. Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Alex Dubov wrote:
> > I removed that line altogether (it does not really needed as mmc host will
> > not be accessed
> > anymore). The problem is more elaborate. Here, the card fails,
> > mmc_host_remove is called
> without
> > sleep beforehand, and "after remove" message is printed immediately after
> > it. Only then,
> mmc_block
> > remembers to finish its business. If I leave the sleep in place,
> > mmc_block's stuff will get
> > scheduled before the mmc_remove_host and everything will be all right.
> > You may also notice that host is already powered off ("Setting ... power 0"
> > message) and still
> > mmc_block continues to make requests like nothing happened.
> >
>
> How did you do the "after remove" detection? Patch?
>
(Power message is printed by ios callback)
Here's my current (SVN) remove function:
static void tifm_sd_remove(struct tifm_dev *sock)
{
struct mmc_host *mmc = tifm_get_drvdata(sock);
struct tifm_sd *host = mmc_priv(mmc);
unsigned long flags;
tasklet_kill(>finish_tasklet);
spin_lock_irqsave(>lock, flags);
host->flags |= EJECT;
writel(0, sock->addr + SOCK_MMCSD_INT_ENABLE);
mmiowb();
if (host->req) {
writel(TIFM_FIFO_INT_SETALL,
sock->addr + SOCK_DMA_FIFO_INT_ENABLE_CLEAR);
writel(0, sock->addr + SOCK_DMA_FIFO_INT_ENABLE_SET);
host->req->cmd->error = MMC_ERR_TIMEOUT;
if (host->req->stop)
host->req->stop->error = MMC_ERR_TIMEOUT;
tasklet_schedule(>finish_tasklet);
}
spin_unlock_irqrestore(>lock, flags);
// temporary hack
msleep(1000);
mmc_remove_host(mmc);
dev_dbg(>dev, "after remove\n");
/* The meaning of the bit majority in this constant is unknown. */
writel(0xfff8 & readl(sock->addr + SOCK_CONTROL),
sock->addr + SOCK_CONTROL);
mmc_free_host(mmc);
}
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel
bargains.
http://farechase.yahoo.com/promo-generic-14795097
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote:
> I removed that line altogether (it does not really needed as mmc host will
> not be accessed
> anymore). The problem is more elaborate. Here, the card fails,
> mmc_host_remove is called without
> sleep beforehand, and "after remove" message is printed immediately after it.
> Only then, mmc_block
> remembers to finish its business. If I leave the sleep in place, mmc_block's
> stuff will get
> scheduled before the mmc_remove_host and everything will be all right.
> You may also notice that host is already powered off ("Setting ... power 0"
> message) and still
> mmc_block continues to make requests like nothing happened.
>
How did you do the "after remove" detection? Patch?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Brad Campbell wrote: > Alex, it's still hit and miss getting this card detected. I had to > insert/remove the card over 10 times with random driver load/unloads > until it created the device entries.. And for me it's still worse, no matter what I try with 2.6.20: speedy:~ # find /sys/devices | grep tifm /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3 /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/mmc_host:mmc0 /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/driver /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/bus /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/subsystem /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/power /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/power/wakeup /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/uevent speedy:~ # find /sys/block | grep mmc speedy:~ # -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Alex Dubov wrote:
> >
> > It just occurred to me that my synopsis of the problem was utterly lame.
> > Here, the correct description:
> > When the card is pulled out, I mark the host as "ejected" (so it fast-fails
> > all the requests),
> > sleep a little for it to relax and then call mmc_remove_host. Otherwise,
> > nasty things happen.
> > Here's the example not involving mmc_block at all (command 3 failed,
> > hardware timeout was
> missed,
> > so software timeout picked it up; the sleep hack is disabled):
> >
>
> I believe your problem is line 915 of tifm_sd.c:
>
> > tifm_set_drvdata(sock, NULL);
>
> You call that before mmc_free_host() (which flushes the work queue), and I
> assume something still needs it. Put in some BUG_ON() here and there and you
> should be able to catch it.
>
I removed that line altogether (it does not really needed as mmc host will not
be accessed
anymore). The problem is more elaborate. Here, the card fails, mmc_host_remove
is called without
sleep beforehand, and "after remove" message is printed immediately after it.
Only then, mmc_block
remembers to finish its business. If I leave the sleep in place, mmc_block's
stuff will get
scheduled before the mmc_remove_host and everything will be all right.
You may also notice that host is already powered off ("Setting ... power 0"
message) and still
mmc_block continues to make requests like nothing happened.
Feb 12 22:06:55 mortug tifm_sd tifm_sd0:3: host_status 400, fifo_status 0
Feb 12 22:06:56 mortug tifm_sd: card failed to respond for a long period of time
Feb 12 22:06:56 mortug tifm_7xx1 :06:09.3: checking media set 8
Feb 12 22:06:56 mortug tifm_7xx1: demand removing card from socket 0:3
Feb 12 22:06:56 mortug tifm_sd tifm_sd0:3: Setting bus width 0, power 0
Feb 12 22:06:56 mortug tifm_sd tifm_sd0:3: after remove
Feb 12 22:06:56 mortug mmcblk1: error 1 sending read/write command
Feb 12 22:06:56 mortug end_request: I/O error, dev mmcblk1, sector 0
Feb 12 22:06:56 mortug printk: 137 messages suppressed.
Feb 12 22:06:56 mortug Buffer I/O error on device mmcblk1, logical block 0
Feb 12 22:06:56 mortug divide error: [1] SMP
Feb 12 22:06:56 mortug CPU 0
Feb 12 22:06:56 mortug Modules linked in: ...
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Pierre Ossman wrote: Brad Campbell wrote: [EMAIL PROTECTED]:/sys/block/mmcblk0$ ls -laR .: total 0 drwxr-xr-x 6 root root0 2007-02-11 23:29 . drwxr-xr-x 13 root root0 2007-02-11 23:27 .. -r--r--r-- 1 root root 4096 2007-02-11 23:28 dev lrwxrwxrwx 1 root root0 2007-02-11 23:27 device -> ../../class/mmc_host/mmc0/mmc0:b368 Is this with CONFIG_SYSFS_DEPRECATED off? It should be pointing to the ../../devices tree. Rgds No, it's currently on. I'll recompile and do a dump with it off this evening. Either way, it's still broken and in 2.6.19 it wasn't. Brad -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Brad Campbell wrote: > [EMAIL PROTECTED]:/sys/block/mmcblk0$ ls -laR > .: > total 0 > drwxr-xr-x 6 root root0 2007-02-11 23:29 . > drwxr-xr-x 13 root root0 2007-02-11 23:27 .. > -r--r--r-- 1 root root 4096 2007-02-11 23:28 dev > lrwxrwxrwx 1 root root0 2007-02-11 23:27 device -> > ../../class/mmc_host/mmc0/mmc0:b368 Is this with CONFIG_SYSFS_DEPRECATED off? It should be pointing to the ../../devices tree. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Brad Campbell wrote: [EMAIL PROTECTED]:/sys/block/mmcblk0$ ls -laR .: total 0 drwxr-xr-x 6 root root0 2007-02-11 23:29 . drwxr-xr-x 13 root root0 2007-02-11 23:27 .. -r--r--r-- 1 root root 4096 2007-02-11 23:28 dev lrwxrwxrwx 1 root root0 2007-02-11 23:27 device - ../../class/mmc_host/mmc0/mmc0:b368 Is this with CONFIG_SYSFS_DEPRECATED off? It should be pointing to the ../../devices tree. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Pierre Ossman wrote: Brad Campbell wrote: [EMAIL PROTECTED]:/sys/block/mmcblk0$ ls -laR .: total 0 drwxr-xr-x 6 root root0 2007-02-11 23:29 . drwxr-xr-x 13 root root0 2007-02-11 23:27 .. -r--r--r-- 1 root root 4096 2007-02-11 23:28 dev lrwxrwxrwx 1 root root0 2007-02-11 23:27 device - ../../class/mmc_host/mmc0/mmc0:b368 Is this with CONFIG_SYSFS_DEPRECATED off? It should be pointing to the ../../devices tree. Rgds No, it's currently on. I'll recompile and do a dump with it off this evening. Either way, it's still broken and in 2.6.19 it wasn't. Brad -- Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
--- Pierre Ossman [EMAIL PROTECTED] wrote: Alex Dubov wrote: It just occurred to me that my synopsis of the problem was utterly lame. Here, the correct description: When the card is pulled out, I mark the host as ejected (so it fast-fails all the requests), sleep a little for it to relax and then call mmc_remove_host. Otherwise, nasty things happen. Here's the example not involving mmc_block at all (command 3 failed, hardware timeout was missed, so software timeout picked it up; the sleep hack is disabled): I believe your problem is line 915 of tifm_sd.c: tifm_set_drvdata(sock, NULL); You call that before mmc_free_host() (which flushes the work queue), and I assume something still needs it. Put in some BUG_ON() here and there and you should be able to catch it. I removed that line altogether (it does not really needed as mmc host will not be accessed anymore). The problem is more elaborate. Here, the card fails, mmc_host_remove is called without sleep beforehand, and after remove message is printed immediately after it. Only then, mmc_block remembers to finish its business. If I leave the sleep in place, mmc_block's stuff will get scheduled before the mmc_remove_host and everything will be all right. You may also notice that host is already powered off (Setting ... power 0 message) and still mmc_block continues to make requests like nothing happened. Feb 12 22:06:55 mortug tifm_sd tifm_sd0:3: host_status 400, fifo_status 0 Feb 12 22:06:56 mortug tifm_sd: card failed to respond for a long period of time Feb 12 22:06:56 mortug tifm_7xx1 :06:09.3: checking media set 8 Feb 12 22:06:56 mortug tifm_7xx1: demand removing card from socket 0:3 Feb 12 22:06:56 mortug tifm_sd tifm_sd0:3: Setting bus width 0, power 0 Feb 12 22:06:56 mortug tifm_sd tifm_sd0:3: after remove Feb 12 22:06:56 mortug mmcblk1: error 1 sending read/write command Feb 12 22:06:56 mortug end_request: I/O error, dev mmcblk1, sector 0 Feb 12 22:06:56 mortug printk: 137 messages suppressed. Feb 12 22:06:56 mortug Buffer I/O error on device mmcblk1, logical block 0 Feb 12 22:06:56 mortug divide error: [1] SMP Feb 12 22:06:56 mortug CPU 0 Feb 12 22:06:56 mortug Modules linked in: ... Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Brad Campbell wrote: Alex, it's still hit and miss getting this card detected. I had to insert/remove the card over 10 times with random driver load/unloads until it created the device entries.. And for me it's still worse, no matter what I try with 2.6.20: speedy:~ # find /sys/devices | grep tifm /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3 /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/mmc_host:mmc0 /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/driver /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/bus /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/subsystem /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/power /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/power/wakeup /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/uevent speedy:~ # find /sys/block | grep mmc speedy:~ # -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: I removed that line altogether (it does not really needed as mmc host will not be accessed anymore). The problem is more elaborate. Here, the card fails, mmc_host_remove is called without sleep beforehand, and after remove message is printed immediately after it. Only then, mmc_block remembers to finish its business. If I leave the sleep in place, mmc_block's stuff will get scheduled before the mmc_remove_host and everything will be all right. You may also notice that host is already powered off (Setting ... power 0 message) and still mmc_block continues to make requests like nothing happened. How did you do the after remove detection? Patch? Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
--- Pierre Ossman [EMAIL PROTECTED] wrote:
Alex Dubov wrote:
I removed that line altogether (it does not really needed as mmc host will
not be accessed
anymore). The problem is more elaborate. Here, the card fails,
mmc_host_remove is called
without
sleep beforehand, and after remove message is printed immediately after
it. Only then,
mmc_block
remembers to finish its business. If I leave the sleep in place,
mmc_block's stuff will get
scheduled before the mmc_remove_host and everything will be all right.
You may also notice that host is already powered off (Setting ... power 0
message) and still
mmc_block continues to make requests like nothing happened.
How did you do the after remove detection? Patch?
(Power message is printed by ios callback)
Here's my current (SVN) remove function:
static void tifm_sd_remove(struct tifm_dev *sock)
{
struct mmc_host *mmc = tifm_get_drvdata(sock);
struct tifm_sd *host = mmc_priv(mmc);
unsigned long flags;
tasklet_kill(host-finish_tasklet);
spin_lock_irqsave(sock-lock, flags);
host-flags |= EJECT;
writel(0, sock-addr + SOCK_MMCSD_INT_ENABLE);
mmiowb();
if (host-req) {
writel(TIFM_FIFO_INT_SETALL,
sock-addr + SOCK_DMA_FIFO_INT_ENABLE_CLEAR);
writel(0, sock-addr + SOCK_DMA_FIFO_INT_ENABLE_SET);
host-req-cmd-error = MMC_ERR_TIMEOUT;
if (host-req-stop)
host-req-stop-error = MMC_ERR_TIMEOUT;
tasklet_schedule(host-finish_tasklet);
}
spin_unlock_irqrestore(sock-lock, flags);
// temporary hack
msleep(1000);
mmc_remove_host(mmc);
dev_dbg(sock-dev, after remove\n);
/* The meaning of the bit majority in this constant is unknown. */
writel(0xfff8 readl(sock-addr + SOCK_CONTROL),
sock-addr + SOCK_CONTROL);
mmc_free_host(mmc);
}
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel
bargains.
http://farechase.yahoo.com/promo-generic-14795097
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Pierre Ossman wrote: Brad Campbell wrote: [EMAIL PROTECTED]:/$ find sys/devices | grep mmc sys/devices/pci:00/:00:1e.0/:06:05.3/tifm_sd0:3/mmc_host:mmc0 This is strange. You should be getting more entries below that. I believe that should be the case.. /sys/block/mmcblk0/device [EMAIL PROTECTED]:/sys/block/mmcblk0$ ls -laR .: total 0 drwxr-xr-x 6 root root0 2007-02-11 23:29 . drwxr-xr-x 13 root root0 2007-02-11 23:27 .. -r--r--r-- 1 root root 4096 2007-02-11 23:28 dev lrwxrwxrwx 1 root root0 2007-02-11 23:27 device -> ../../class/mmc_host/mmc0/mmc0:b368 drwxr-xr-x 2 root root0 2007-02-11 23:27 holders drwxr-xr-x 3 root root0 2007-02-11 23:29 mmcblk0p1 drwxr-xr-x 3 root root0 2007-02-11 23:27 queue -r--r--r-- 1 root root 4096 2007-02-11 23:29 range -r--r--r-- 1 root root 4096 2007-02-11 23:27 removable -r--r--r-- 1 root root 4096 2007-02-11 23:29 size drwxr-xr-x 2 root root0 2007-02-11 23:27 slaves -r--r--r-- 1 root root 4096 2007-02-11 23:29 stat lrwxrwxrwx 1 root root0 2007-02-11 23:27 subsystem -> ../../block --w--- 1 root root 4096 2007-02-11 23:29 uevent ./holders: total 0 drwxr-xr-x 2 root root 0 2007-02-11 23:27 . drwxr-xr-x 6 root root 0 2007-02-11 23:29 .. ./mmcblk0p1: total 0 drwxr-xr-x 3 root root0 2007-02-11 23:29 . drwxr-xr-x 6 root root0 2007-02-11 23:29 .. -r--r--r-- 1 root root 4096 2007-02-11 23:29 dev drwxr-xr-x 2 root root0 2007-02-11 23:27 holders -r--r--r-- 1 root root 4096 2007-02-11 23:29 size -r--r--r-- 1 root root 4096 2007-02-11 23:29 start -r--r--r-- 1 root root 4096 2007-02-11 23:29 stat lrwxrwxrwx 1 root root0 2007-02-11 23:29 subsystem -> ../../../block --w--- 1 root root 4096 2007-02-11 23:29 uevent ./mmcblk0p1/holders: total 0 drwxr-xr-x 2 root root 0 2007-02-11 23:27 . drwxr-xr-x 3 root root 0 2007-02-11 23:29 .. ./queue: total 0 drwxr-xr-x 3 root root0 2007-02-11 23:27 . drwxr-xr-x 6 root root0 2007-02-11 23:29 .. drwxr-xr-x 2 root root0 2007-02-11 23:27 iosched -r--r--r-- 1 root root 4096 2007-02-11 23:29 max_hw_sectors_kb -rw-r--r-- 1 root root 4096 2007-02-11 23:29 max_sectors_kb -rw-r--r-- 1 root root 4096 2007-02-11 23:29 nr_requests -rw-r--r-- 1 root root 4096 2007-02-11 23:29 read_ahead_kb -rw-r--r-- 1 root root 4096 2007-02-11 23:29 scheduler ./queue/iosched: total 0 drwxr-xr-x 2 root root0 2007-02-11 23:27 . drwxr-xr-x 3 root root0 2007-02-11 23:29 .. -rw-r--r-- 1 root root 4096 2007-02-11 23:29 back_seek_max -rw-r--r-- 1 root root 4096 2007-02-11 23:29 back_seek_penalty -rw-r--r-- 1 root root 4096 2007-02-11 23:29 fifo_expire_async -rw-r--r-- 1 root root 4096 2007-02-11 23:29 fifo_expire_sync -rw-r--r-- 1 root root 4096 2007-02-11 23:29 quantum -rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_async -rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_async_rq -rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_idle -rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_sync ./slaves: total 0 drwxr-xr-x 2 root root 0 2007-02-11 23:27 . drwxr-xr-x 6 root root 0 2007-02-11 23:29 .. [EMAIL PROTECTED]:/sys/block/mmcblk0$ cd device [EMAIL PROTECTED]:/sys/block/mmcblk0/device$ ls -laR .: total 0 drwxr-xr-x 3 root root0 2007-02-11 23:30 . drwxr-xr-x 4 root root0 2007-02-11 23:27 .. lrwxrwxrwx 1 root root0 2007-02-11 23:30 block:mmcblk0 -> ../../../../block/mmcblk0 lrwxrwxrwx 1 root root0 2007-02-11 23:30 bus -> ../../../../bus/mmc -r--r--r-- 1 root root 4096 2007-02-11 23:30 cid -r--r--r-- 1 root root 4096 2007-02-11 23:30 csd -r--r--r-- 1 root root 4096 2007-02-11 23:30 date lrwxrwxrwx 1 root root0 2007-02-11 23:27 driver -> ../../../../bus/mmc/drivers/mmcblk -r--r--r-- 1 root root 4096 2007-02-11 23:30 fwrev -r--r--r-- 1 root root 4096 2007-02-11 23:30 hwrev -r--r--r-- 1 root root 4096 2007-02-11 23:30 manfid -r--r--r-- 1 root root 4096 2007-02-11 23:30 name -r--r--r-- 1 root root 4096 2007-02-11 23:30 oemid drwxr-xr-x 2 root root0 2007-02-11 23:27 power -r--r--r-- 1 root root 4096 2007-02-11 23:30 scr -r--r--r-- 1 root root 4096 2007-02-11 23:30 serial lrwxrwxrwx 1 root root0 2007-02-11 23:27 subsystem -> ../../../../bus/mmc --w--- 1 root root 4096 2007-02-11 23:30 uevent ./power: total 0 drwxr-xr-x 2 root root0 2007-02-11 23:27 . drwxr-xr-x 3 root root0 2007-02-11 23:30 .. -rw-r--r-- 1 root root 4096 2007-02-11 23:30 wakeup Alex, it's still hit and miss getting this card detected. I had to insert/remove the card over 10 times with random driver load/unloads until it created the device entries.. Brad -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: > > It just occurred to me that my synopsis of the problem was utterly lame. > Here, the correct description: > When the card is pulled out, I mark the host as "ejected" (so it fast-fails > all the requests), > sleep a little for it to relax and then call mmc_remove_host. Otherwise, > nasty things happen. > Here's the example not involving mmc_block at all (command 3 failed, hardware > timeout was missed, > so software timeout picked it up; the sleep hack is disabled): > I believe your problem is line 915 of tifm_sd.c: > tifm_set_drvdata(sock, NULL); You call that before mmc_free_host() (which flushes the work queue), and I assume something still needs it. Put in some BUG_ON() here and there and you should be able to catch it. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Brad Campbell wrote: > > [EMAIL PROTECTED]:/$ find sys/devices | grep mmc > sys/devices/pci:00/:00:1e.0/:06:05.3/tifm_sd0:3/mmc_host:mmc0 > This is strange. You should be getting more entries below that. > /sys/block/mmcblk0/device Where does this point? Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Pierre Ossman wrote: Brad Campbell wrote: I've tested both with and without CONFIG_SYSFS_DEPRECATED on, both fail the same way. hald reports that the device has no parent and decides to ignore it. Works fine here. The device tree is: /sys/devices/pnp0/00:02/mmc0/mmc0:0001/block:mmcblk0/mmcblk0p1/ Ok, following from that on my machine currently... [EMAIL PROTECTED]:/$ ls /dev/mmc* /dev/mmcblk0 /dev/mmcblk0p1 [EMAIL PROTECTED]:/$ find sys/devices | grep mmc sys/devices/pci:00/:00:1e.0/:06:05.3/tifm_sd0:3/mmc_host:mmc0 [EMAIL PROTECTED]:/$ find /sys/block/ | grep mmc /sys/block/mmcblk0 /sys/block/mmcblk0/queue /sys/block/mmcblk0/queue/iosched /sys/block/mmcblk0/queue/iosched/slice_idle /sys/block/mmcblk0/queue/iosched/slice_async_rq /sys/block/mmcblk0/queue/iosched/slice_async /sys/block/mmcblk0/queue/iosched/slice_sync /sys/block/mmcblk0/queue/iosched/back_seek_penalty /sys/block/mmcblk0/queue/iosched/back_seek_max /sys/block/mmcblk0/queue/iosched/fifo_expire_async /sys/block/mmcblk0/queue/iosched/fifo_expire_sync /sys/block/mmcblk0/queue/iosched/quantum /sys/block/mmcblk0/queue/scheduler /sys/block/mmcblk0/queue/max_sectors_kb /sys/block/mmcblk0/queue/max_hw_sectors_kb /sys/block/mmcblk0/queue/read_ahead_kb /sys/block/mmcblk0/queue/nr_requests /sys/block/mmcblk0/mmcblk0p1 /sys/block/mmcblk0/mmcblk0p1/holders /sys/block/mmcblk0/mmcblk0p1/subsystem /sys/block/mmcblk0/mmcblk0p1/stat /sys/block/mmcblk0/mmcblk0p1/size /sys/block/mmcblk0/mmcblk0p1/start /sys/block/mmcblk0/mmcblk0p1/dev /sys/block/mmcblk0/mmcblk0p1/uevent /sys/block/mmcblk0/slaves /sys/block/mmcblk0/holders /sys/block/mmcblk0/subsystem /sys/block/mmcblk0/device /sys/block/mmcblk0/stat /sys/block/mmcblk0/size /sys/block/mmcblk0/removable /sys/block/mmcblk0/range /sys/block/mmcblk0/dev /sys/block/mmcblk0/uevent [EMAIL PROTECTED]:~$ zcat /proc/config.gz | grep CONFIG_SYSFS_DEPRECATED CONFIG_SYSFS_DEPRECATED=y [EMAIL PROTECTED]:~$ uname -a Linux bklaptop2 2.6.20-git4-bkc1 #5 Sat Feb 10 23:49:52 GST 2007 i686 GNU/Linux Not sure if any of this is relevant info, but none the less, I'm not a sysfs or hal guru. Brad -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Brad Campbell wrote: > > I've tested both with and without CONFIG_SYSFS_DEPRECATED on, both fail > the same way. > hald reports that the device has no parent and decides to ignore it. > Works fine here. The device tree is: /sys/devices/pnp0/00:02/mmc0/mmc0:0001/block:mmcblk0/mmcblk0p1/ and hal correctly shows the same structure. > I've also tested both combinations against hal from ubuntu 6.06LTS and a > more recent version > > [EMAIL PROTECTED]:~$ hald --version > HAL package version: 0.5.8.1 > I'm using 0.5.9 here, but CONFIG_SYSFS_DEPRECATED should make it work with any ancient version of hal. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Hi. I can see this problem too. I have CONFIG_SYSFS_DEPRECATED set. It happens only with SD cards, with MMC everything is OK. Fabio On 2/11/07, Brad Campbell <[EMAIL PROTECTED]> wrote: Pierre Ossman wrote: > Alex Dubov wrote: >> One more problem (you may already know about it) - I was contacted by somebody from the hald >> project and indeed I can confirm that on 2.6.20 kernel hald fails to take action on card >> insertion. I can't see anything in my code so this may be a general mmc problem. >> The problem is described here: >> http://lists.freedesktop.org/archives/hal/2007-January/006960.html >> > > Odd. This might be the whole sysfs restructuring thing causing problems. Can you > check if that user has CONFIG_SYSFS_DEPRECATED on? I've tested both with and without CONFIG_SYSFS_DEPRECATED on, both fail the same way. hald reports that the device has no parent and decides to ignore it. I've also tested both combinations against hal from ubuntu 6.06LTS and a more recent version [EMAIL PROTECTED]:~$ hald --version HAL package version: 0.5.8.1 Again with and without CONFIG_SYSFS_DEPRECATED and all combinations fail. Hal appears to go looking for /sys/block/mmcblk0/mmcblk0p1/range When it can't find it, it then looks for the parent of that to check what would be /sys/block/mmcblk0/range, Complains it can't find a parent for /sys/block/mmcblk0/mmcblk0p1 and just proceeds to ignore the event. Brad -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Hi. I can see this problem too. I have CONFIG_SYSFS_DEPRECATED set. It happens only with SD cards, with MMC everything is OK. Fabio On 2/11/07, Brad Campbell [EMAIL PROTECTED] wrote: Pierre Ossman wrote: Alex Dubov wrote: One more problem (you may already know about it) - I was contacted by somebody from the hald project and indeed I can confirm that on 2.6.20 kernel hald fails to take action on card insertion. I can't see anything in my code so this may be a general mmc problem. The problem is described here: http://lists.freedesktop.org/archives/hal/2007-January/006960.html Odd. This might be the whole sysfs restructuring thing causing problems. Can you check if that user has CONFIG_SYSFS_DEPRECATED on? I've tested both with and without CONFIG_SYSFS_DEPRECATED on, both fail the same way. hald reports that the device has no parent and decides to ignore it. I've also tested both combinations against hal from ubuntu 6.06LTS and a more recent version [EMAIL PROTECTED]:~$ hald --version HAL package version: 0.5.8.1 Again with and without CONFIG_SYSFS_DEPRECATED and all combinations fail. Hal appears to go looking for /sys/block/mmcblk0/mmcblk0p1/range When it can't find it, it then looks for the parent of that to check what would be /sys/block/mmcblk0/range, Complains it can't find a parent for /sys/block/mmcblk0/mmcblk0p1 and just proceeds to ignore the event. Brad -- Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Brad Campbell wrote: I've tested both with and without CONFIG_SYSFS_DEPRECATED on, both fail the same way. hald reports that the device has no parent and decides to ignore it. Works fine here. The device tree is: /sys/devices/pnp0/00:02/mmc0/mmc0:0001/block:mmcblk0/mmcblk0p1/ and hal correctly shows the same structure. I've also tested both combinations against hal from ubuntu 6.06LTS and a more recent version [EMAIL PROTECTED]:~$ hald --version HAL package version: 0.5.8.1 I'm using 0.5.9 here, but CONFIG_SYSFS_DEPRECATED should make it work with any ancient version of hal. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Pierre Ossman wrote: Brad Campbell wrote: I've tested both with and without CONFIG_SYSFS_DEPRECATED on, both fail the same way. hald reports that the device has no parent and decides to ignore it. Works fine here. The device tree is: /sys/devices/pnp0/00:02/mmc0/mmc0:0001/block:mmcblk0/mmcblk0p1/ Ok, following from that on my machine currently... [EMAIL PROTECTED]:/$ ls /dev/mmc* /dev/mmcblk0 /dev/mmcblk0p1 [EMAIL PROTECTED]:/$ find sys/devices | grep mmc sys/devices/pci:00/:00:1e.0/:06:05.3/tifm_sd0:3/mmc_host:mmc0 [EMAIL PROTECTED]:/$ find /sys/block/ | grep mmc /sys/block/mmcblk0 /sys/block/mmcblk0/queue /sys/block/mmcblk0/queue/iosched /sys/block/mmcblk0/queue/iosched/slice_idle /sys/block/mmcblk0/queue/iosched/slice_async_rq /sys/block/mmcblk0/queue/iosched/slice_async /sys/block/mmcblk0/queue/iosched/slice_sync /sys/block/mmcblk0/queue/iosched/back_seek_penalty /sys/block/mmcblk0/queue/iosched/back_seek_max /sys/block/mmcblk0/queue/iosched/fifo_expire_async /sys/block/mmcblk0/queue/iosched/fifo_expire_sync /sys/block/mmcblk0/queue/iosched/quantum /sys/block/mmcblk0/queue/scheduler /sys/block/mmcblk0/queue/max_sectors_kb /sys/block/mmcblk0/queue/max_hw_sectors_kb /sys/block/mmcblk0/queue/read_ahead_kb /sys/block/mmcblk0/queue/nr_requests /sys/block/mmcblk0/mmcblk0p1 /sys/block/mmcblk0/mmcblk0p1/holders /sys/block/mmcblk0/mmcblk0p1/subsystem /sys/block/mmcblk0/mmcblk0p1/stat /sys/block/mmcblk0/mmcblk0p1/size /sys/block/mmcblk0/mmcblk0p1/start /sys/block/mmcblk0/mmcblk0p1/dev /sys/block/mmcblk0/mmcblk0p1/uevent /sys/block/mmcblk0/slaves /sys/block/mmcblk0/holders /sys/block/mmcblk0/subsystem /sys/block/mmcblk0/device /sys/block/mmcblk0/stat /sys/block/mmcblk0/size /sys/block/mmcblk0/removable /sys/block/mmcblk0/range /sys/block/mmcblk0/dev /sys/block/mmcblk0/uevent [EMAIL PROTECTED]:~$ zcat /proc/config.gz | grep CONFIG_SYSFS_DEPRECATED CONFIG_SYSFS_DEPRECATED=y [EMAIL PROTECTED]:~$ uname -a Linux bklaptop2 2.6.20-git4-bkc1 #5 Sat Feb 10 23:49:52 GST 2007 i686 GNU/Linux Not sure if any of this is relevant info, but none the less, I'm not a sysfs or hal guru. Brad -- Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Brad Campbell wrote: [EMAIL PROTECTED]:/$ find sys/devices | grep mmc sys/devices/pci:00/:00:1e.0/:06:05.3/tifm_sd0:3/mmc_host:mmc0 This is strange. You should be getting more entries below that. /sys/block/mmcblk0/device Where does this point? Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: It just occurred to me that my synopsis of the problem was utterly lame. Here, the correct description: When the card is pulled out, I mark the host as ejected (so it fast-fails all the requests), sleep a little for it to relax and then call mmc_remove_host. Otherwise, nasty things happen. Here's the example not involving mmc_block at all (command 3 failed, hardware timeout was missed, so software timeout picked it up; the sleep hack is disabled): I believe your problem is line 915 of tifm_sd.c: tifm_set_drvdata(sock, NULL); You call that before mmc_free_host() (which flushes the work queue), and I assume something still needs it. Put in some BUG_ON() here and there and you should be able to catch it. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Pierre Ossman wrote: Brad Campbell wrote: [EMAIL PROTECTED]:/$ find sys/devices | grep mmc sys/devices/pci:00/:00:1e.0/:06:05.3/tifm_sd0:3/mmc_host:mmc0 This is strange. You should be getting more entries below that. I believe that should be the case.. /sys/block/mmcblk0/device [EMAIL PROTECTED]:/sys/block/mmcblk0$ ls -laR .: total 0 drwxr-xr-x 6 root root0 2007-02-11 23:29 . drwxr-xr-x 13 root root0 2007-02-11 23:27 .. -r--r--r-- 1 root root 4096 2007-02-11 23:28 dev lrwxrwxrwx 1 root root0 2007-02-11 23:27 device - ../../class/mmc_host/mmc0/mmc0:b368 drwxr-xr-x 2 root root0 2007-02-11 23:27 holders drwxr-xr-x 3 root root0 2007-02-11 23:29 mmcblk0p1 drwxr-xr-x 3 root root0 2007-02-11 23:27 queue -r--r--r-- 1 root root 4096 2007-02-11 23:29 range -r--r--r-- 1 root root 4096 2007-02-11 23:27 removable -r--r--r-- 1 root root 4096 2007-02-11 23:29 size drwxr-xr-x 2 root root0 2007-02-11 23:27 slaves -r--r--r-- 1 root root 4096 2007-02-11 23:29 stat lrwxrwxrwx 1 root root0 2007-02-11 23:27 subsystem - ../../block --w--- 1 root root 4096 2007-02-11 23:29 uevent ./holders: total 0 drwxr-xr-x 2 root root 0 2007-02-11 23:27 . drwxr-xr-x 6 root root 0 2007-02-11 23:29 .. ./mmcblk0p1: total 0 drwxr-xr-x 3 root root0 2007-02-11 23:29 . drwxr-xr-x 6 root root0 2007-02-11 23:29 .. -r--r--r-- 1 root root 4096 2007-02-11 23:29 dev drwxr-xr-x 2 root root0 2007-02-11 23:27 holders -r--r--r-- 1 root root 4096 2007-02-11 23:29 size -r--r--r-- 1 root root 4096 2007-02-11 23:29 start -r--r--r-- 1 root root 4096 2007-02-11 23:29 stat lrwxrwxrwx 1 root root0 2007-02-11 23:29 subsystem - ../../../block --w--- 1 root root 4096 2007-02-11 23:29 uevent ./mmcblk0p1/holders: total 0 drwxr-xr-x 2 root root 0 2007-02-11 23:27 . drwxr-xr-x 3 root root 0 2007-02-11 23:29 .. ./queue: total 0 drwxr-xr-x 3 root root0 2007-02-11 23:27 . drwxr-xr-x 6 root root0 2007-02-11 23:29 .. drwxr-xr-x 2 root root0 2007-02-11 23:27 iosched -r--r--r-- 1 root root 4096 2007-02-11 23:29 max_hw_sectors_kb -rw-r--r-- 1 root root 4096 2007-02-11 23:29 max_sectors_kb -rw-r--r-- 1 root root 4096 2007-02-11 23:29 nr_requests -rw-r--r-- 1 root root 4096 2007-02-11 23:29 read_ahead_kb -rw-r--r-- 1 root root 4096 2007-02-11 23:29 scheduler ./queue/iosched: total 0 drwxr-xr-x 2 root root0 2007-02-11 23:27 . drwxr-xr-x 3 root root0 2007-02-11 23:29 .. -rw-r--r-- 1 root root 4096 2007-02-11 23:29 back_seek_max -rw-r--r-- 1 root root 4096 2007-02-11 23:29 back_seek_penalty -rw-r--r-- 1 root root 4096 2007-02-11 23:29 fifo_expire_async -rw-r--r-- 1 root root 4096 2007-02-11 23:29 fifo_expire_sync -rw-r--r-- 1 root root 4096 2007-02-11 23:29 quantum -rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_async -rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_async_rq -rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_idle -rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_sync ./slaves: total 0 drwxr-xr-x 2 root root 0 2007-02-11 23:27 . drwxr-xr-x 6 root root 0 2007-02-11 23:29 .. [EMAIL PROTECTED]:/sys/block/mmcblk0$ cd device [EMAIL PROTECTED]:/sys/block/mmcblk0/device$ ls -laR .: total 0 drwxr-xr-x 3 root root0 2007-02-11 23:30 . drwxr-xr-x 4 root root0 2007-02-11 23:27 .. lrwxrwxrwx 1 root root0 2007-02-11 23:30 block:mmcblk0 - ../../../../block/mmcblk0 lrwxrwxrwx 1 root root0 2007-02-11 23:30 bus - ../../../../bus/mmc -r--r--r-- 1 root root 4096 2007-02-11 23:30 cid -r--r--r-- 1 root root 4096 2007-02-11 23:30 csd -r--r--r-- 1 root root 4096 2007-02-11 23:30 date lrwxrwxrwx 1 root root0 2007-02-11 23:27 driver - ../../../../bus/mmc/drivers/mmcblk -r--r--r-- 1 root root 4096 2007-02-11 23:30 fwrev -r--r--r-- 1 root root 4096 2007-02-11 23:30 hwrev -r--r--r-- 1 root root 4096 2007-02-11 23:30 manfid -r--r--r-- 1 root root 4096 2007-02-11 23:30 name -r--r--r-- 1 root root 4096 2007-02-11 23:30 oemid drwxr-xr-x 2 root root0 2007-02-11 23:27 power -r--r--r-- 1 root root 4096 2007-02-11 23:30 scr -r--r--r-- 1 root root 4096 2007-02-11 23:30 serial lrwxrwxrwx 1 root root0 2007-02-11 23:27 subsystem - ../../../../bus/mmc --w--- 1 root root 4096 2007-02-11 23:30 uevent ./power: total 0 drwxr-xr-x 2 root root0 2007-02-11 23:27 . drwxr-xr-x 3 root root0 2007-02-11 23:30 .. -rw-r--r-- 1 root root 4096 2007-02-11 23:30 wakeup Alex, it's still hit and miss getting this card detected. I had to insert/remove the card over 10 times with random driver load/unloads until it created the device entries.. Brad -- Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Pierre Ossman wrote: Alex Dubov wrote: One more problem (you may already know about it) - I was contacted by somebody from the hald project and indeed I can confirm that on 2.6.20 kernel hald fails to take action on card insertion. I can't see anything in my code so this may be a general mmc problem. The problem is described here: http://lists.freedesktop.org/archives/hal/2007-January/006960.html Odd. This might be the whole sysfs restructuring thing causing problems. Can you check if that user has CONFIG_SYSFS_DEPRECATED on? I've tested both with and without CONFIG_SYSFS_DEPRECATED on, both fail the same way. hald reports that the device has no parent and decides to ignore it. I've also tested both combinations against hal from ubuntu 6.06LTS and a more recent version [EMAIL PROTECTED]:~$ hald --version HAL package version: 0.5.8.1 Again with and without CONFIG_SYSFS_DEPRECATED and all combinations fail. Hal appears to go looking for /sys/block/mmcblk0/mmcblk0p1/range When it can't find it, it then looks for the parent of that to check what would be /sys/block/mmcblk0/range, Complains it can't find a parent for /sys/block/mmcblk0/mmcblk0p1 and just proceeds to ignore the event. Brad -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
> > This looks like the problem with races in mmc_block again. Add some printk:s > in > the remove function so that you can see if this oops is after the remove > function (shouldn't be possible, but will cause crash if it is). It just occurred to me that my synopsis of the problem was utterly lame. Here, the correct description: When the card is pulled out, I mark the host as "ejected" (so it fast-fails all the requests), sleep a little for it to relax and then call mmc_remove_host. Otherwise, nasty things happen. Here's the example not involving mmc_block at all (command 3 failed, hardware timeout was missed, so software timeout picked it up; the sleep hack is disabled): Feb 11 02:26:08 mortug tifm_sd tifm_sd0:3: executing opcode 0x3, arg: 0x0, mask: 0x1140 Feb 11 02:26:09 mortug tifm_sd: card failed to respond for a long period of time< 7>tifm_7xx1 :06:09.3: checking media set 8 Feb 11 02:26:09 mortug tifm_7xx1: demand removing card from socket 0:3 Feb 11 02:26:09 mortug tifm_sd tifm_sd0:3: Setting bus width 0, power 0 Feb 11 02:26:09 mortug tifm_sd tifm_sd0:3: Setting bus width 0, power 0 Feb 11 02:26:09 mortug general protection fault: [1] SMP Feb 11 02:26:09 mortug CPU 0 Feb 11 02:26:09 mortug Modules linked in: tifm_sd tifm_7xx1 tifm_core mmc_block m mc_core appletalk ipx p8022 psnap llc p8023 fglrx(P) ndiswrapper snd_pcm_oss snd_ mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device eth 1394 binfmt_misc firmware_class tg3 ohci1394 yenta_socket rsrc_nonstatic ieee1394 pcmcia_core 8250_pci i2c_piix4 i2c_core snd_atiixp snd_atiixp_modem parport_pc p arport k8temp hwmon snd_ac97_codec ac97_bus joydev snd_pcm ehci_hcd serio_raw tsd ev pcspkr 8250_pnp 8250 serial_core snd_timer snd ohci_hcd evdev irda crc_ccitt s oundcore snd_page_alloc usbcore Feb 11 02:26:09 mortug Pid: 8318, comm: kmmcd Tainted: P 2.6.20 #1 Feb 11 02:26:09 mortug RIP: 0010:[] [] :mmc_ core:mmc_rescan+0x440/0x1350 Feb 11 02:26:09 mortug RSP: 0018:81002d6d5af0 EFLAGS: 00010202 Feb 11 02:26:09 mortug RAX: 2f4065766f6d6572 RBX: 2f4065766f6d6572 RCX: 0 000 Feb 11 02:26:09 mortug RDX: 81002d6d5fd8 RSI: 0286 RDI: 81002 d6d5a88 Feb 11 02:26:09 mortug RBP: 81002d6d5dc8 R08: R09: 0 00a Feb 11 02:26:09 mortug R10: R11: 88178110 R12: 81002 976a000 Feb 11 02:26:09 mortug R13: 81002976a2c0 R14: 81002adee800 R15: 81002 d6d5dc0 Feb 11 02:26:09 mortug FS: 2b8375adab00() GS:805d() knlG S:f7e066c0 Feb 11 02:26:09 mortug CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b Feb 11 02:26:09 mortug CR2: 0050e3c0 CR3: 079a2000 CR4: 0 6e0 Feb 11 02:26:09 mortug Process kmmcd (pid: 8318, threadinfo 81002d6d4000, tas k 81002ea82820) Feb 11 02:26:09 mortug Stack: 80288770 81002d6d5dc8 81002976a2ac 81002d6d5b28 Feb 11 02:26:09 mortug 80288a38 0cc03f1dc6bb 00962228 037ffe4 382562228 Feb 11 02:26:09 mortug 00ff80248e8b 00ff8001 04d0 000 1 Feb 11 02:26:09 mortug Call Trace: Feb 11 02:26:09 mortug [] task_rq_lock+0x50/0x90 Feb 11 02:26:09 mortug [] __activate_task+0x38/0x50 Feb 11 02:26:09 mortug [] unix_find_other+0x172/0x200 Feb 11 02:26:09 mortug [] __wake_up_common+0x40/0x70 Feb 11 02:26:09 mortug [] __alloc_pages+0x69/0x2f0 Feb 11 02:26:09 mortug [] do_wp_page+0x4b1/0x510 Feb 11 02:26:09 mortug [] thread_return+0x0/0xe2 Feb 11 02:26:09 mortug [] :mmc_core:mmc_wait_done+0x0/0x10 Feb 11 02:26:09 mortug [] :mmc_core:mmc_rescan+0x0/0x1350 Feb 11 02:26:09 mortug [] run_workqueue+0xb1/0x160 Feb 11 02:26:09 mortug [] keventd_create_kthread+0x0/0x90 Feb 11 02:26:09 mortug [] worker_thread+0x161/0x1a0 Feb 11 02:26:09 mortug [] default_wake_function+0x0/0x10 Feb 11 02:26:09 mortug [] default_wake_function+0x0/0x10 Feb 11 02:26:09 mortug [] worker_thread+0x0/0x1a0 Feb 11 02:26:09 mortug [] kthread+0xd9/0x120 Feb 11 02:26:09 mortug [] child_rip+0xa/0x12 Feb 11 02:26:09 mortug [] keventd_create_kthread+0x0/0x90 Feb 11 02:26:09 mortug [] kthread+0x0/0x120 Feb 11 02:26:09 mortug [] child_rip+0x0/0x12 Feb 11 02:26:09 mortug Feb 11 02:26:09 mortug Feb 11 02:26:09 mortug Code: 48 8b 03 0f 18 08 49 39 dd 0f 84 0c 04 00 00 f6 83 8 c 02 00 Feb 11 02:26:09 mortug RIP [] :mmc_core:mmc_rescan+0x440/0x135 0 Feb 11 02:26:09 mortug RSP Feb 11 02:28:09 mortug shutdown[17114]: shutting down for system halt Feb 11 02:28:09 mortug init: Switching to runlevel: 0 Feb 11 02:28:18 mortug dhcpcd[7461]: terminating on signal 15 Feb 11 02:28:21 mortug <6>ACPI: PCI interrupt for device :00:14.5 disabled Feb 11 02:28:21 mortug ACPI: PCI interrupt for device :00:14.6 disabled Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut.
Re: Recent and not-so problems with tifm_sd driver - one more
Alex Dubov wrote: > One more problem (you may already know about it) - I was contacted by > somebody from the hald > project and indeed I can confirm that on 2.6.20 kernel hald fails to take > action on card > insertion. I can't see anything in my code so this may be a general mmc > problem. > The problem is described here: > http://lists.freedesktop.org/archives/hal/2007-January/006960.html > Odd. This might be the whole sysfs restructuring thing causing problems. Can you check if that user has CONFIG_SYSFS_DEPRECATED on? Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
One more problem (you may already know about it) - I was contacted by somebody from the hald project and indeed I can confirm that on 2.6.20 kernel hald fails to take action on card insertion. I can't see anything in my code so this may be a general mmc problem. The problem is described here: http://lists.freedesktop.org/archives/hal/2007-January/006960.html Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q http://answers.yahoo.com/dir/?link=list=396545367 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
This looks like the problem with races in mmc_block again. Add some printk:s in the remove function so that you can see if this oops is after the remove function (shouldn't be possible, but will cause crash if it is). It just occurred to me that my synopsis of the problem was utterly lame. Here, the correct description: When the card is pulled out, I mark the host as ejected (so it fast-fails all the requests), sleep a little for it to relax and then call mmc_remove_host. Otherwise, nasty things happen. Here's the example not involving mmc_block at all (command 3 failed, hardware timeout was missed, so software timeout picked it up; the sleep hack is disabled): Feb 11 02:26:08 mortug tifm_sd tifm_sd0:3: executing opcode 0x3, arg: 0x0, mask: 0x1140 Feb 11 02:26:09 mortug tifm_sd: card failed to respond for a long period of time 7tifm_7xx1 :06:09.3: checking media set 8 Feb 11 02:26:09 mortug tifm_7xx1: demand removing card from socket 0:3 Feb 11 02:26:09 mortug tifm_sd tifm_sd0:3: Setting bus width 0, power 0 Feb 11 02:26:09 mortug tifm_sd tifm_sd0:3: Setting bus width 0, power 0 Feb 11 02:26:09 mortug general protection fault: [1] SMP Feb 11 02:26:09 mortug CPU 0 Feb 11 02:26:09 mortug Modules linked in: tifm_sd tifm_7xx1 tifm_core mmc_block m mc_core appletalk ipx p8022 psnap llc p8023 fglrx(P) ndiswrapper snd_pcm_oss snd_ mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device eth 1394 binfmt_misc firmware_class tg3 ohci1394 yenta_socket rsrc_nonstatic ieee1394 pcmcia_core 8250_pci i2c_piix4 i2c_core snd_atiixp snd_atiixp_modem parport_pc p arport k8temp hwmon snd_ac97_codec ac97_bus joydev snd_pcm ehci_hcd serio_raw tsd ev pcspkr 8250_pnp 8250 serial_core snd_timer snd ohci_hcd evdev irda crc_ccitt s oundcore snd_page_alloc usbcore Feb 11 02:26:09 mortug Pid: 8318, comm: kmmcd Tainted: P 2.6.20 #1 Feb 11 02:26:09 mortug RIP: 0010:[88178d30] [88178d30] :mmc_ core:mmc_rescan+0x440/0x1350 Feb 11 02:26:09 mortug RSP: 0018:81002d6d5af0 EFLAGS: 00010202 Feb 11 02:26:09 mortug RAX: 2f4065766f6d6572 RBX: 2f4065766f6d6572 RCX: 0 000 Feb 11 02:26:09 mortug RDX: 81002d6d5fd8 RSI: 0286 RDI: 81002 d6d5a88 Feb 11 02:26:09 mortug RBP: 81002d6d5dc8 R08: R09: 0 00a Feb 11 02:26:09 mortug R10: R11: 88178110 R12: 81002 976a000 Feb 11 02:26:09 mortug R13: 81002976a2c0 R14: 81002adee800 R15: 81002 d6d5dc0 Feb 11 02:26:09 mortug FS: 2b8375adab00() GS:805d() knlG S:f7e066c0 Feb 11 02:26:09 mortug CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b Feb 11 02:26:09 mortug CR2: 0050e3c0 CR3: 079a2000 CR4: 0 6e0 Feb 11 02:26:09 mortug Process kmmcd (pid: 8318, threadinfo 81002d6d4000, tas k 81002ea82820) Feb 11 02:26:09 mortug Stack: 80288770 81002d6d5dc8 81002976a2ac 81002d6d5b28 Feb 11 02:26:09 mortug 80288a38 0cc03f1dc6bb 00962228 037ffe4 382562228 Feb 11 02:26:09 mortug 00ff80248e8b 00ff8001 04d0 000 1 Feb 11 02:26:09 mortug Call Trace: Feb 11 02:26:09 mortug [80288770] task_rq_lock+0x50/0x90 Feb 11 02:26:09 mortug [80288a38] __activate_task+0x38/0x50 Feb 11 02:26:09 mortug [8049d762] unix_find_other+0x172/0x200 Feb 11 02:26:09 mortug [8028a5e0] __wake_up_common+0x40/0x70 Feb 11 02:26:09 mortug [8020f199] __alloc_pages+0x69/0x2f0 Feb 11 02:26:09 mortug [802110f1] do_wp_page+0x4b1/0x510 Feb 11 02:26:09 mortug [80265d3e] thread_return+0x0/0xe2 Feb 11 02:26:09 mortug [88178110] :mmc_core:mmc_wait_done+0x0/0x10 Feb 11 02:26:09 mortug [881788f0] :mmc_core:mmc_rescan+0x0/0x1350 Feb 11 02:26:09 mortug [80250001] run_workqueue+0xb1/0x160 Feb 11 02:26:09 mortug [8029e670] keventd_create_kthread+0x0/0x90 Feb 11 02:26:09 mortug [8024c6d1] worker_thread+0x161/0x1a0 Feb 11 02:26:09 mortug [8028a590] default_wake_function+0x0/0x10 Feb 11 02:26:09 mortug [8028a590] default_wake_function+0x0/0x10 Feb 11 02:26:09 mortug [8024c570] worker_thread+0x0/0x1a0 Feb 11 02:26:09 mortug [80233109] kthread+0xd9/0x120 Feb 11 02:26:09 mortug [80262ec8] child_rip+0xa/0x12 Feb 11 02:26:09 mortug [8029e670] keventd_create_kthread+0x0/0x90 Feb 11 02:26:09 mortug [80233030] kthread+0x0/0x120 Feb 11 02:26:09 mortug [80262ebe] child_rip+0x0/0x12 Feb 11 02:26:09 mortug Feb 11 02:26:09 mortug Feb 11 02:26:09 mortug Code: 48 8b 03 0f 18 08 49 39 dd 0f 84 0c 04 00 00 f6 83 8 c 02 00 Feb 11 02:26:09 mortug RIP [88178d30] :mmc_core:mmc_rescan+0x440/0x135 0 Feb 11 02:26:09 mortug RSP 81002d6d5af0 Feb 11 02:28:09 mortug shutdown[17114]: shutting down for system halt Feb 11 02:28:09 mortug init: Switching to runlevel: 0 Feb 11 02:28:18 mortug dhcpcd[7461]:
Re: Recent and not-so problems with tifm_sd driver - one more
Pierre Ossman wrote: Alex Dubov wrote: One more problem (you may already know about it) - I was contacted by somebody from the hald project and indeed I can confirm that on 2.6.20 kernel hald fails to take action on card insertion. I can't see anything in my code so this may be a general mmc problem. The problem is described here: http://lists.freedesktop.org/archives/hal/2007-January/006960.html Odd. This might be the whole sysfs restructuring thing causing problems. Can you check if that user has CONFIG_SYSFS_DEPRECATED on? I've tested both with and without CONFIG_SYSFS_DEPRECATED on, both fail the same way. hald reports that the device has no parent and decides to ignore it. I've also tested both combinations against hal from ubuntu 6.06LTS and a more recent version [EMAIL PROTECTED]:~$ hald --version HAL package version: 0.5.8.1 Again with and without CONFIG_SYSFS_DEPRECATED and all combinations fail. Hal appears to go looking for /sys/block/mmcblk0/mmcblk0p1/range When it can't find it, it then looks for the parent of that to check what would be /sys/block/mmcblk0/range, Complains it can't find a parent for /sys/block/mmcblk0/mmcblk0p1 and just proceeds to ignore the event. Brad -- Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
One more problem (you may already know about it) - I was contacted by somebody from the hald project and indeed I can confirm that on 2.6.20 kernel hald fails to take action on card insertion. I can't see anything in my code so this may be a general mmc problem. The problem is described here: http://lists.freedesktop.org/archives/hal/2007-January/006960.html Food fight? Enjoy some healthy debate in the Yahoo! Answers Food Drink QA. http://answers.yahoo.com/dir/?link=listsid=396545367 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Alex Dubov wrote: One more problem (you may already know about it) - I was contacted by somebody from the hald project and indeed I can confirm that on 2.6.20 kernel hald fails to take action on card insertion. I can't see anything in my code so this may be a general mmc problem. The problem is described here: http://lists.freedesktop.org/archives/hal/2007-January/006960.html Odd. This might be the whole sysfs restructuring thing causing problems. Can you check if that user has CONFIG_SYSFS_DEPRECATED on? Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: > I'm continuing to look for possible problems in my code. > This looks like the problem with races in mmc_block again. Add some printk:s in the remove function so that you can see if this oops is after the remove function (shouldn't be possible, but will cause crash if it is). Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Recent and not-so problems with tifm_sd driver
Greetings. It seems that the recent shower of error reports was caused by my not so thorough testing of the R6 handling problems (I've sent you a patch for this). However, there is this other problem with mmc_host_remove while transfer is in progress. First, I disabled my "sleep on remove" hack. Then I've set up a transfer (dd if=/dev/mmcblk0 of=/dev/null) and pulled the card out. The result was a hard crash (irq handler style) soon followed by additional one, so the numbers in this hand-grabbed dump may be inexact: elv_next_request+0x15d/0x1e0 :mmc_core:mmc_queue_thread+0x72/0x110 :mmc_core:mmc_queue_thread+0x0/0x110 keventd_create_kthread+0x0/0x90 kthread+0xd9/0x120 child_rip+0xa/0x12 keventd_create_kthread+0x0/0x90 kthread+0x0/0x120 child_rip+0x0/0x12 RIP :mmc_core:mmc_prep_request+0x4d/0x70 -- I'm continuing to look for possible problems in my code. It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Recent and not-so problems with tifm_sd driver
Greetings. It seems that the recent shower of error reports was caused by my not so thorough testing of the R6 handling problems (I've sent you a patch for this). However, there is this other problem with mmc_host_remove while transfer is in progress. First, I disabled my sleep on remove hack. Then I've set up a transfer (dd if=/dev/mmcblk0 of=/dev/null) and pulled the card out. The result was a hard crash (irq handler style) soon followed by additional one, so the numbers in this hand-grabbed dump may be inexact: elv_next_request+0x15d/0x1e0 :mmc_core:mmc_queue_thread+0x72/0x110 :mmc_core:mmc_queue_thread+0x0/0x110 keventd_create_kthread+0x0/0x90 kthread+0xd9/0x120 child_rip+0xa/0x12 keventd_create_kthread+0x0/0x90 kthread+0x0/0x120 child_rip+0x0/0x12 RIP :mmc_core:mmc_prep_request+0x4d/0x70 -- I'm continuing to look for possible problems in my code. It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: I'm continuing to look for possible problems in my code. This looks like the problem with races in mmc_block again. Add some printk:s in the remove function so that you can see if this oops is after the remove function (shouldn't be possible, but will cause crash if it is). Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
