----- Original Message ---- > From: Hans Petter Selasky <[email protected]> > To: PseudoCylon <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected] > Sent: Fri, March 5, 2010 5:14:24 AM > Subject: Re: usb/144423: if_run panic with USB-N13 > > On Friday 05 March 2010 12:40:05 PseudoCylon wrote: > > ----- Original Message ---- > > > > > From: Hans Petter Selasky > > > To: PseudoCylon > > > Cc: [email protected]; [email protected]; > > > [email protected]; [email protected] Sent: Fri, > > > March 5, 2010 2:42:41 AM > > > Subject: Re: usb/144423: if_run panic with USB-N13 > > > > > > On Friday 05 March 2010 10:31:35 PseudoCylon wrote: > > > > >The files seem a little far from the current I am running, I just used > > > > >the updates to the usbdevs file and the unlock-lock around the > > > > > firmware load in if_run.c. > > > > > > > > Yes, there are some bits added to support RT3572 chipsets. It would be > > > > greately appreciated if you try that file if it's not too mutch > > > > trouble. > > > > > > > > >The ASUS-N13 does work when a child wlan device is created with it, > > > > >but if just "ifconfig run0 up" is done there is a page fault. I do > > > > >not know if that is expected. This occurs with or without runfw.ko > > > > >being loaded beforehand. > > > > > > > > Yes, "ifconfig run0 up" will cause page fault. The wlanN interface is > > > > should be created as an instance of the parent interface and used for > > > > actual communication. This is new feature to 8.0 and 9-current. My > > > > understanding is that if you create wlan and "ifconfig *wlan0* up", it > > > > works, but if you "ifconfig *run0* up", it causes panic. (Of cource > > > > without *. I'm trying to enphasize the point in plain text messeage.) > > > > That is what should happen. (Actually, result of "ifconfig *run0* up" > > > > is undefined.) "run0" should only be used when creating wlan. > > > > > > > > If "ifconfig *wlan0* ..." is causing problem, please let us know. > > > > > > What is the backtrace of the panic? > > > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > _witness_debugger() at _witness_debugger+0x2e > > witness_warn() at witness_warn+0x2c2 > > trap() at trap+0x2f5 > > calltrap() at calltrap+0x8 > > --- trap 0xc, rip = 0xffffffff80c5cfd7, rsp = 0xffffff8021f76880, rbp = > > 0xffffff8021f768c0 --- run_stop() at run_stop+0x67 > > run_init_locked() at run_init_locked+0x33 > > run_ioctl() at run_ioctl+0xad > > ifioctl() at ifioctl+0xde4 > > kern_ioctl() at kern_ioctl+0xc5 > > ioctl() at ioctl+0xf0 > > syscall() at syscall+0x1af > > Xfast_syscall() at Xfast_syscall+0xe1 > > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b8286c, rsp = > > 0x7fffffffe2f8, rbp = 0x7fffffffe300 --- > > > > There are number of places refers uninitialized value in run_stop() and > > run_init() if vap hasn't created, so it will cause page fault. I can move > > those instructions to other places (maybe vap_delete). It won't panic but > > device won't work without vap. > > > > Can't you add a NULL pointer check? > > It should not panic. > > --HPS
Yes. I moved draintask functions to vap_delete like other driver. some are
still in run_stop() with NULL ptr check. patch is against rev. 7
Device doesn't work with "ifconfig run0" but it won't panic at least. "ifconfig
run0 scan" gives "unable to get scan result" And. I'm sending this mail with
wlan0.
AK
__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!
http://www.flickr.com/gift/
if_run.patch
Description: Binary data
_______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[email protected]"
