Andy Green wrote: > Since SDI stuff is fully sycnchronous, allowing preemption inside the > interrupt service for it doesn't obviously make trouble.
It appears that is encourages some not-so-obvious gremlins to show more presence, though. "jc" has reported seeing the following AR6k initialization failure at boot: [21474538.910000] mmc1: queuing CIS tuple 0x80 length 1 [21474538.910000] mmc1: queuing CIS tuple 0x81 length 1 [21474538.910000] mmc1: queuing CIS tuple 0x82 length 1 [21474538.910000] mmc1: new SDIO card at address 0001 [21474538.915000] sdio_ar6000 mmc1:0001:1: deviceInsertedHandler: -1 [21474538.915000] sdio_ar6000 mmc1:0001:1: kthread_stop (ar6000_io): -4 [21474538.920000] sdio_ar6000: probe of mmc1:0001:1 failed with error -4 Using commit de8460932576502fb6bf61968a37c4d2aed2d6e2 with a modified gta02_moredrivers: http://prostor.hopto.org/~jc/config Apparently, this is reproducible. As a work-around, the usual unbind/bind brings up WLAN properly: echo s3c2440-sdi >/sys/bus/platform/drivers/s3c2440-sdi/unbind echo s3c2440-sdi >/sys/bus/platform/drivers/s3c2440-sdi/bind I built and tried "the same" kernel but if course WLAN came up without a hitch. I also saw one stray failure myself: [274661.070000] mmc1: new SDIO card at address 0001 [274661.105000] ar6000_available [274661.445000] Unable to decrement the command credit count register [274661.445000] Unable to write to the device I've never seen this one before or since (in maybe a dozen boots since it happened.) Just a "heads up." I still need to hit something I can reproduce. - Werner
