On Fri, 14 Apr 2006, Mayne wrote:
> On Fri, 23 Dec 2005, Guennadi Liakhovetski wrote:
> [Full quote since the discussion is a bit old]
> > > > > This is odd though. The device reset in zdusb.c probably isn't working
> > > > > properly on your machine. Perhaps 2.6 doesn't like
> > > > > usb_lock_device_for_reset/usb_unlock_device missing. Could anyone
> > > > > create a
> > > > > patch? (I don't run 2.6 here)
> > > > No. I think, reset in disconnect doesn't make any sense at all. I just
> > > > removed it and tested - of course, nothing bad heppens, as it anyway
> > > > didn't have any effect due to wrong state.
> > > The reset was introduced because of
> > > https://sourceforge.net/mailarchive/message.php?msg_id=12569588
> > > <[EMAIL PROTECTED]>
> > > . At least at that time this made sense. However, it may be possible
> > > that for example changes in the stick's firmware made the reset
> > > superfluous.
> > Ok, I see. Interesting. On one my PC - where I normally use zd1211 I got
> > the same message in the log "reset not allowed in state 0" and rmmod +
> > modprobe indeed don't work without replugging the device. Whereas on the
> > other PC rmmod produces "resetting device..." and everything is fine.
> > Moving the reset early in probe seems to work on both machines. Patch
> > below. Would be good if people seeing "reset not allowed in state 0" on
> > rmmod could test it (re-adding Fernando to CC:).
> I just found out this change seems to cause kernel panics here.
> Kernel 2.4.32, driver loaded by hotplug. The panic is due to a null pointer
> dereference in the hotplug process. If I revert the change everything seems to
> be fine. It seems moving the reset to initialization confuses hotplug's data
> I'll move the reset code to zd1211_disconnect again if there are no
Well, it will bring the old problem back under 2.6 - reloading the driver
will likely not work, as the dongle will not be resetted. Moving the reset
to the old place means effectively removing it under 2.6. That is, if
nothing in the kernel changed since the time I last checked it (the time
of that thread - last December). So, either somebody has to look how one
can corectly reset a device on module-unloading under 2.6, or make it
dependent on the kernel version... But, please, don't just put it back at
least not to bring the old bug reports back and not to cause more
confusion - why the reset doesn't work under 2.6... I don't like the reset
in module_init() either, but please, don't just put code in the driver
that is known to have no effect.
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
Zd1211-devs mailing list - http://zd1211.ath.cx/