Date: Wed, 7 May 2003 03:08:39 +0100 From: Jay Cornwall <jay@evilrealms.net> To: freebsd-current@freebsd.org Subject: USB ugen_set_interface issue (+ possible patch) Message-ID: <200305070308.42781.jay@evilrealms.net>
next in thread | raw e-mail | index | archive | help
--Boundary-00=_nqGu+U2WtwwCfyj Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi =46irst of all, my humblest apologies for this perhaps slightly offtopic po= sting=20 =2D - I'm using and testing with 5.0-RELEASE at the moment, but I couldn't = find a=20 more appropriate list to post my questions. I'm currently investigating a problem with the Speedtouch software=20 (http://speedtouch.sf.net/) for the Speedtouch USB ADSL modem, and FreeBSD= =20 5.0. The software has worked up until FreeBSD 4.8, but causes kernel panics= =20 when initialising the modem in 5.0. I've done some investigative work into= =20 this, and think I have a partial solution. The problem appears to be in /sys/dev/usb/ugen.c, within the=20 ugen_set_interface function. After setting the interface, subsequent calls = to=20 ugen_destroy_devnodes result in a kernel panic, after calling destroy_dev=20 within /sys/dev/kern/kern_conf.c: if (!(dev->si_flags & SI_NAMED)) { printf( "WARNING: Driver mistake: destroy_dev on %d/%d\n", major(dev), minor(dev)); panic("don't do that"); return; } This code had been introduced since FreeBSD 4.8 for use with the new DevFS= =20 system; it appears that in previous versions this condition was not checked= ,=20 and caused no problems. I placed assertions at the start and end of ugen_set_interface to check thi= s=20 condition was true for all dev_t's that ugen_destroy_devnodes would call=20 destroy_dev on. The assertion was true at the start of the function, but=20 false at the end. A comment in the Speedtouch source code seems to confirm this: /* BUG: at least in FreeBSD 4.3, USB_SET_ALTINTERFACE does not * make the necessary devices for the interface. So we call * USB_SET_CONFIG to ensure they are created. But this will * fail if any endpoints (other than the control) are open. * Of course, the devices might already exist, so failure * to set the configuration does not mean it will not work. */ It goes on to use a USB_SET_CONFIG ioctl to create the devices, but this no= =20 longer works since the introduction of a ugen_destroy_devnodes call to=20 ugen_set_config (which causes the above-described kernel panic). I can't see any reason why ugen_set_interface shouldn't destroy the old=20 devices, and create new ones, but I'm inexperienced with this code (and USB= =20 in general). If I've made a false assumption, please correct me, as I'm=20 always willing to learn more. :) My proposal for a patch to fix this is fairly simple, and is attached to th= is=20 email. It simply adds a ugen_destroy_devnodes/ugen_make_devnodes pair to th= e=20 call, and it eliminates the kernel panic I'm seeing with the Speedtouch=20 software. I'm open to your comments. :o) (BTW, there are still further issues with the Speedtouch software, but I'm= =20 working on that :)) Cheers, Jay =2D --=20 http://www.evilrealms.net/ - Systems Administrator & Developer http://www.ic.ac.uk/ - Imperial College, 2nd year CS student =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+uGqqfJLn3O/2GbERAtBzAJ9I9w66+D2l65GXbdDcrDFjZ11idwCg5/0v tWE8IiPLawsnEoGjOk0ylGo=3D =3DcqqZ =2D----END PGP SIGNATURE----- --Boundary-00=_nqGu+U2WtwwCfyj--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305070308.42781.jay>