Re: USB hub detach causing panic in 4.7p3
On Fri, Jan 17, 2003 at 10:20:24AM -0800, Darren Pilgrim wrote: > > >There are a number of brokenisms in the USB stack in -stable. As to > >whether they will get fixed or not is a matter of whether anyone has the > >time to MFC the USB stack from -current or not. It's much better over > >there, and I've already merged the framework to make it easier to MFC, > >but it is very unlikely that I will be attempting the work myself as I > >don't use USB on -stable myself. > > So the problem I'm having is a known issue when detaching a uhub device, > then? > I guess... there was a problem with hubs not working which was fixed about a year ago in -current. I don't know if the problem is with all uhubs, or just some uhubs. I work on the assumption that plug-and-play is broken in 4.x's usb stack. Try not to unplug things. If you do and it works, bonus! :). Joe msg39278/pgp0.pgp Description: PGP signature
Re: USB hub detach causing panic in 4.7p3
Josef Karthauser wrote: On Tue, Jan 14, 2003 at 12:05:37PM -0800, Darren Pilgrim wrote: I have a USB hub that's built into my Viewsonic PT775 monitor. The hub probes during boot and post-boot attach as follows: When the hub is disconnected, whether by unplugging it or turning off the monitor, I get a panic in 4.7p3 if there are no devices connected to the hub's downstream ports. Would this PR be related? http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/45579 I'm not sure? I didn't have anything running, that I could tell, that would have had the uhub device open. The machine was sitting idle at the login prompt. If someone would like to point me at a list of what I need to do to produce useful debugging information, I'll gladly do so. There are a number of brokenisms in the USB stack in -stable. As to whether they will get fixed or not is a matter of whether anyone has the time to MFC the USB stack from -current or not. It's much better over there, and I've already merged the framework to make it easier to MFC, but it is very unlikely that I will be attempting the work myself as I don't use USB on -stable myself. So the problem I'm having is a known issue when detaching a uhub device, then? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB hub detach causing panic in 4.7p3
On Tue, Jan 14, 2003 at 12:05:37PM -0800, Darren Pilgrim wrote: > > > >>I have a USB hub that's built into my Viewsonic PT775 monitor. The hub > >>probes during boot and post-boot attach as follows: > >> > >>When the hub is disconnected, whether by unplugging it or turning > >>off the monitor, I get a panic in 4.7p3 if there are no devices > >>connected to the hub's downstream ports. > > > > >Would this PR be related? > >http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/45579 > > I'm not sure? I didn't have anything running, that I could tell, that > would have had the uhub device open. The machine was sitting idle at the > login prompt. If someone would like to point me at a list of what I need > to do to produce useful debugging information, I'll gladly do so. > There are a number of brokenisms in the USB stack in -stable. As to whether they will get fixed or not is a matter of whether anyone has the time to MFC the USB stack from -current or not. It's much better over there, and I've already merged the framework to make it easier to MFC, but it is very unlikely that I will be attempting the work myself as I don't use USB on -stable myself. Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = msg39274/pgp0.pgp Description: PGP signature
Re: USB hub detach causing panic in 4.7p3
Someone's requested these already, so I've made the dmesg output and kernel config for the panicing machine available at www.lokisheathens.org/speck. On Tuesday 14 January 2003 06:51 am, Darren Pilgrim wrote: I have a USB hub that's built into my Viewsonic PT775 monitor. The hub probes during boot and post-boot attach as follows: uhub1: vendor 0x0543 product 0x00ff, class 9/0, rev 1.00/0.00, addr 2 uhub1: 5 ports with 4 removable, self powered The hub is connected and disconnected with the switching on and off of the monitor. When the hub is disconnected, whether by unplugging it or turning off the monitor, I get a panic in 4.7p3 if there are no devices connected to the hub's downstream ports. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB hub detach causing panic in 4.7p3
Anish Mistry wrote: On Tuesday 14 January 2003 06:51 am, Darren Pilgrim wrote: I have a USB hub that's built into my Viewsonic PT775 monitor. The hub probes during boot and post-boot attach as follows: >>When the hub is disconnected, whether by unplugging it or turning off the monitor, I get a panic in 4.7p3 if there are no devices connected to the hub's downstream ports. Would this PR be related? http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/45579 I'm not sure? I didn't have anything running, that I could tell, that would have had the uhub device open. The machine was sitting idle at the login prompt. If someone would like to point me at a list of what I need to do to produce useful debugging information, I'll gladly do so. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB hub detach causing panic in 4.7p3
On Tuesday 14 January 2003 06:51 am, Darren Pilgrim wrote: > I have a USB hub that's built into my Viewsonic PT775 monitor. The hub > probes during boot and post-boot attach as follows: > > uhub1: vendor 0x0543 product 0x00ff, class 9/0, rev 1.00/0.00, addr 2 > uhub1: 5 ports with 4 removable, self powered > > The hub is connected and disconnected with the switching on and off of the > monitor. When the hub is disconnected, whether by unplugging it or turning > off the monitor, I get a panic in 4.7p3 if there are no devices connected to > the hub's downstream ports. If there are devices connected to the > downstream ports, the detach/reattach process works just fine. I only have > the one hub to test this issue on. I can't say when the problem appeared as > I hadn't used FreeBSD with this hub until a few weeks ago, and I hadn't > turned the monitor off with nothing plugged into its USB ports until the > 12th. Here is the console output from the panics caused by disconnecting > the hub: > > Fatal trap 12: page fault while in kernel mode > fault virtual addres= 0x3 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc031fe04 > stack pointer = 0x10:0xc0250fb0 > frame pointer = 0x10:0xc0250fc4 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = Idle > interrupt mask = bio > trap number = 12 > panic: page fault > > > syncing disks... > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x30 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc01c2498 > stack pointer = 0x10:0xc0250d98 > frame pointer = 0x10:0xc0250da0 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = Idle > interrupt mask = bio > trap number = 12 > panic: page fault > > Later on, when I was testing various configurations and boot/plug/unplug > patterns to (try to) fix/diagnose the problem, the debug information was > different from the above, but the same for all the panics I induced while > testing. This is the output for those panics: > > Fatal trap 12: page fault while in kernel mode > fault virtual addres= 0x3 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc031fe04 > stack pointer = 0x10:0xc0250fb0 > frame pointer = 0x10:0xc0250fc4 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = Idle > interrupt mask = bio > trap number = 12 > panic: page fault > > > syncing disks... > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x30 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc01c2498 > stack pointer = 0x10:0xc0250dd0 > frame pointer = 0x10:0xc0250dd8 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = Idle > interrupt mask = bio > trap number = 12 > panic: page fault > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > > Would this PR be related? http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/45579 -- Anish Mistry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB hub detach causing panic in 4.7p3
I neglected to include from details: The USB drivers are kldloaded. The dmesg output and kernel config aren't included, but available upon request (as is any other config info or other needed data). Darren Pilgrim wrote: I have a USB hub that's built into my Viewsonic PT775 monitor. The hub probes during boot and post-boot attach as follows: uhub1: vendor 0x0543 product 0x00ff, class 9/0, rev 1.00/0.00, addr 2 uhub1: 5 ports with 4 removable, self powered The hub is connected and disconnected with the switching on and off of the monitor. When the hub is disconnected, whether by unplugging it or turning off the monitor, I get a panic in 4.7p3 if there are no devices connected to the hub's downstream ports. If there are devices connected to the downstream ports, the detach/reattach process works just fine. I only have the one hub to test this issue on. I can't say when the problem appeared as I hadn't used FreeBSD with this hub until a few weeks ago, and I hadn't turned the monitor off with nothing plugged into its USB ports until the 12th. Here is the console output from the panics caused by disconnecting the hub: Fatal trap 12: page fault while in kernel mode fault virtual addres= 0x3 fault code = supervisor read, page not present instruction pointer = 0x8:0xc031fe04 stack pointer = 0x10:0xc0250fb0 frame pointer = 0x10:0xc0250fc4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01c2498 stack pointer = 0x10:0xc0250d98 frame pointer = 0x10:0xc0250da0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault Later on, when I was testing various configurations and boot/plug/unplug patterns to (try to) fix/diagnose the problem, the debug information was different from the above, but the same for all the panics I induced while testing. This is the output for those panics: Fatal trap 12: page fault while in kernel mode fault virtual addres= 0x3 fault code = supervisor read, page not present instruction pointer = 0x8:0xc031fe04 stack pointer = 0x10:0xc0250fb0 frame pointer = 0x10:0xc0250fc4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01c2498 stack pointer = 0x10:0xc0250dd0 frame pointer = 0x10:0xc0250dd8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
USB hub detach causing panic in 4.7p3
I have a USB hub that's built into my Viewsonic PT775 monitor. The hub probes during boot and post-boot attach as follows: uhub1: vendor 0x0543 product 0x00ff, class 9/0, rev 1.00/0.00, addr 2 uhub1: 5 ports with 4 removable, self powered The hub is connected and disconnected with the switching on and off of the monitor. When the hub is disconnected, whether by unplugging it or turning off the monitor, I get a panic in 4.7p3 if there are no devices connected to the hub's downstream ports. If there are devices connected to the downstream ports, the detach/reattach process works just fine. I only have the one hub to test this issue on. I can't say when the problem appeared as I hadn't used FreeBSD with this hub until a few weeks ago, and I hadn't turned the monitor off with nothing plugged into its USB ports until the 12th. Here is the console output from the panics caused by disconnecting the hub: Fatal trap 12: page fault while in kernel mode fault virtual addres= 0x3 fault code = supervisor read, page not present instruction pointer = 0x8:0xc031fe04 stack pointer = 0x10:0xc0250fb0 frame pointer = 0x10:0xc0250fc4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01c2498 stack pointer = 0x10:0xc0250d98 frame pointer = 0x10:0xc0250da0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault Later on, when I was testing various configurations and boot/plug/unplug patterns to (try to) fix/diagnose the problem, the debug information was different from the above, but the same for all the panics I induced while testing. This is the output for those panics: Fatal trap 12: page fault while in kernel mode fault virtual addres= 0x3 fault code = supervisor read, page not present instruction pointer = 0x8:0xc031fe04 stack pointer = 0x10:0xc0250fb0 frame pointer = 0x10:0xc0250fc4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01c2498 stack pointer = 0x10:0xc0250dd0 frame pointer = 0x10:0xc0250dd8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message