Adrian Chadd | 10 Feb 03:17 2013
Picon

Re: panic on removing urtw0

Yes to both - i think some USB stack / memory buffer changes are
responsible for your issue. :-)

Adrian

On 9 February 2013 15:51, Eitan Adler <lists <at> eitanadler.com> wrote:
> On 9 February 2013 14:01, Adrian Chadd <adrian <at> freebsd.org> wrote:
>> On 9 February 2013 06:47, Eitan Adler <lists <at> eitanadler.com> wrote:
>>> I recently encountered a kernel panic upon removing a urtw0 device.
>>> This removal occurred during machine shutdown.
>>>
>>> The crashing kernel and textdump is available upon request.
>>>
>>> Unread portion of the kernel message buffer:
>>> urtw0: failed to stop (USB_ERR_NOT_CONFIGURED)
>>
>> I'm pretty sure Hans has just fixed this for uath?
>
> I'm confused.  Does this means he fixed it for uath, but not for urtw?
>  Or does this mean that same fix likely to work for both?
>
> --
> Eitan Adler
Hans Petter Selasky | 10 Feb 09:05 2013
X-Face
Picon

Re: panic on removing urtw0

On Sunday 10 February 2013 03:17:03 Adrian Chadd wrote:
> Yes to both - i think some USB stack / memory buffer changes are
> responsible for your issue. :-)
> 

Hi,

Can you send me the backtrace of the panic and I'll fix it. I fixed panic upon 
attach.

--HPS
Eitan Adler | 10 Feb 14:19 2013

Re: panic on removing urtw0

[moving to -usb where this seemingly belongs]

On 10 February 2013 03:05, Hans Petter Selasky <hselasky <at> c2i.net> wrote:
> On Sunday 10 February 2013 03:17:03 Adrian Chadd wrote:
>> Yes to both - i think some USB stack / memory buffer changes are
>> responsible for your issue. :-)
>>
>
> Hi,
>
> Can you send me the backtrace of the panic and I'll fix it. I fixed panic upon
> attach.

[ textdump & kernel available upon request ]

Unread portion of the kernel message buffer:
urtw0: failed to stop (USB_ERR_NOT_CONFIGURED)

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x368
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff808c4be7
stack pointer           = 0x28:0xffffff8227152730
frame pointer           = 0x28:0xffffff8227152780
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 15 (usbus2)
trap number             = 12
(Continue reading)

Hans Petter Selasky | 10 Feb 14:27 2013
X-Face
Picon

Re: panic on removing urtw0

On Sunday 10 February 2013 14:19:21 Eitan Adler wrote:
> [moving to -usb where this seemingly belongs]
> 
> On 10 February 2013 03:05, Hans Petter Selasky <hselasky <at> c2i.net> wrote:
> > On Sunday 10 February 2013 03:17:03 Adrian Chadd wrote:
> >> Yes to both - i think some USB stack / memory buffer changes are
> >> responsible for your issue. :-)
> > 
> > Hi,
> > 
> > Can you send me the backtrace of the panic and I'll fix it. I fixed panic
> > upon attach.
> 
> [ textdump & kernel available upon request ]
> 
> Unread portion of the kernel message buffer:
> urtw0: failed to stop (USB_ERR_NOT_CONFIGURED)
> 

Hi,

Can you try this again with latest -current as of now. It happens because the 
nodes are freed after the IEEE802.11 adapter is gone.

--HPS
Eitan Adler | 10 Feb 20:15 2013

Re: panic on removing urtw0

On 10 February 2013 08:27, Hans Petter Selasky <hselasky <at> c2i.net> wrote:
> On Sunday 10 February 2013 14:19:21 Eitan Adler wrote:
>> [moving to -usb where this seemingly belongs]
>>
>> On 10 February 2013 03:05, Hans Petter Selasky <hselasky <at> c2i.net> wrote:
>> > On Sunday 10 February 2013 03:17:03 Adrian Chadd wrote:
>> >> Yes to both - i think some USB stack / memory buffer changes are
>> >> responsible for your issue. :-)
>> >
>> > Hi,
>> >
>> > Can you send me the backtrace of the panic and I'll fix it. I fixed panic
>> > upon attach.
>>
>> [ textdump & kernel available upon request ]
>>
>> Unread portion of the kernel message buffer:
>> urtw0: failed to stop (USB_ERR_NOT_CONFIGURED)
>>
>
> Hi,
>
> Can you try this again with latest -current as of now. It happens because the
> nodes are freed after the IEEE802.11 adapter is gone.

I can not test because the device does not attach at all on r246623.

--

-- 
Eitan Adler
(Continue reading)


Gmane