One-line summary: plug-in your USB keyboard, see your machine die.
So, I have this non-name USB keyboard (with built-in 2-port USB hub)
which reliably crashes 2.6.0-test{8,9} on both x86 and ia64. In
retrospect, it's clear to me that the same keyboard also occasionally
crashes 2.4 kernels, but
On Mon, 27 Oct 2003 17:30:13 -0800, Greg KH [EMAIL PROTECTED] said:
Greg On Mon, Oct 27, 2003 at 02:35:09PM -0800, David Mosberger
Greg wrote:
One-line summary: plug-in your USB keyboard, see your machine
die.
Greg Any chance to know where the machine dies? Any oops you can
Greg
On Thu, 30 Oct 2003 07:11:42 -0800, David Brownell [EMAIL PROTECTED] said:
David David Mosberger wrote:
On x86, there is no OOps, it just freezes. On ia64, I get a nice MCA
and from that we can infer that a USB host controller read from
address 0xf000 caused the problem
After spending a bit more time on this, it looks to me like the
keyboard is crashing the system very early on. I added some
instrumentation printks and am seeing this:
# insmod hid.ko
drivers/usb/core/usb.c: registered new driver hiddev
calling usb_hid_configure()
calling hid_init_reports()
On Fri, 31 Oct 2003 08:23:54 -0800, David Brownell [EMAIL PROTECTED] said:
David.B David Mosberger wrote:
After spending a bit more time on this, it looks to me like the
keyboard is crashing the system very early on.
David.B I think there are some devices that choke the HID
David.B
On Fri, 31 Oct 2003 11:28:20 -0800, David Brownell [EMAIL PROTECTED] said:
David.B You sound alarmed! If that's alarmed enough to find out
David.B what the real problem is, maybe you'll end up fixing it
David.B ... :)
Except I know almost nothing about the USB stack.
David.B Agreed,
On Sun, 02 Nov 2003 19:46:38 -0800, David Brownell [EMAIL PROTECTED] said:
David I'm not sure that if the HID driver were to pass a null
David buffer pointer, it would be caught anywhere.
OK, I'll try to find some time to trace the I/O MMU calls to see
if something isn't kosher at
The ipaq USB driver in 2.6.0 didn't work for me. I got the attached
Badness in local_bh_enable backtrace when ppp tried to connect to my
iPaq. The quick and dirty patch to avoid the problem is this patch:
= drivers/usb/serial/ipaq.c 1.34 vs edited =
--- 1.34/drivers/usb/serial/ipaq.c
On Sat, 20 Dec 2003 17:07:10 -0800, Greg KH [EMAIL PROTECTED] said:
Greg On Fri, Dec 19, 2003 at 05:52:00PM -0800, David Mosberger
Greg wrote:
The ipaq USB driver in 2.6.0 didn't work for me. I got the
attached Badness in local_bh_enable backtrace when ppp tried to
connect to my
OK, finally a bit of progress. If you remember back in October 2003 I
reported:
One-line summary: plug-in your USB keyboard, see your machine die.
So, I have this non-name USB keyboard (with built-in 2-port USB
hub) which reliably crashes 2.6.0-test{8,9} on both x86 and ia64.
In
Typo-alert:
On Fri, 5 Mar 2004 18:08:40 -0800, David Mosberger [EMAIL PROTECTED] said:
David - HCD ends up dereferencing a bad pointer and ends up
David reading from address 0xf000, which on our ia64 machines
David is a read-only area, which then results in a machine-check
David
On Fri, 05 Mar 2004 20:55:01 -0800, David Brownell [EMAIL PROTECTED] said:
Turns out it's this patch that was causing the crashes:
http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]
David.B Maybe in 2.6.4-rc2... but not in 2.6.0-test{8,9}!!
Of course. What I'm saying is that in
On Fri, 5 Mar 2004 21:49:20 -0800, David Mosberger [EMAIL PROTECTED] said:
David It's not an issue of DMA coherency, it's an issue of DMA
David vs. interrupt ordering. I believe the WHD interrupt is
David arriving at the CPU before the DMA update to the HCCA is
David done.
Actually
On Fri, 5 Mar 2004 23:21:32 -0800, David Mosberger [EMAIL PROTECTED] said:
David (1) Start of Frame - (2) update HccaFrameNumber - (3)
David trigger SF interrupt
David Now, suppose you get a WDH interrupt between (1) and (2).
David You'd read the old frame-number yet by the time
On Fri, 05 Mar 2004 20:55:01 -0800, David Brownell [EMAIL PROTECTED] said:
Does this sound plausible?
David.B Parts of it. There's definite recent nastiness. Of the
David.B type that other eyes sometimes see better.
Here is patch #3. It also Works For Me. I was wondering whether it
On Sat, 6 Mar 2004 11:40:50 -0500 (EST), Alan Stern [EMAIL PROTECTED] said:
Alan On Fri, 5 Mar 2004, David Mosberger wrote:
What beats me is why UHCI would have the same issue. I know even
less about UHCI than I do about OHCI but perhaps there is a
similar problem.
Alan Do you
On Sat, 06 Mar 2004 09:30:31 -0800, David Brownell [EMAIL PROTECTED] said:
David.B David Mosberger wrote:
Here is patch #3. It also Works For Me. I was wondering whether
it
David.B I've had several Works For Me patches too, but then if
David.B the silicion got kicked a bit
On Sun, 7 Mar 2004 22:18:02 -0800, Grant Grundler [EMAIL PROTECTED] said:
`Such a write-buffering mechanism is clearly a type of
(write-)caching effect,
Grant No - the data is still in flight and in some deterministic
Grant time frame will become visible to the CPU. Calling it a
How about something along the following lines? The patch is relative
to 2.6.4-rc1. What it does is add a new state ED_DESCHEDULED, which
is treated exactly like ED_IDLE, except that in this state, the HC may
still be referring to the ED in question. Thus, if
ohci_endpoint_disable() finds an ED
On Tue, 09 Mar 2004 09:36:53 -0800, David Brownell [EMAIL PROTECTED] said:
David.B David Mosberger wrote:
How about something along the following lines? The patch is
relative to 2.6.4-rc1. What it does is add a new state
ED_DESCHEDULED, which is treated exactly like ED_IDLE, except
David B.,
I'll respond to your concerns about my OHCI changes later on. I
wanted to make progress on the BTC HID issue first so we have the full
picture.
Remember how I was asking what's so special about 0xf0 because
that's the address the OHCI HC was reading from that caused the crash?
Pavlik,
Below is a trivial but very important bug fix. I suspect that bug
_might_ be the reason why the BTC keyboard would cause hangs with any
host-controller, not just the OHCI HCD (which, as I reported today,
had another bug which caused machines to hang or crash). What happens
is that the
Pavlik,
Here is a small patch relative to 2.6.4-rc2 that does three things:
- In hid_init_reports(), establish a idle-period of 1ms before
initiating the Get_Request() requests. It appears there are buggy
keyboards (such as the BTC keyboard) where setting the idle period
affects not
On Tue, 09 Mar 2004 18:53:58 -0800, David Brownell [EMAIL PROTECTED] said:
David.B Whose OHCI silicon David.B are you testing with, by the way?
lspci claims it's a NEC chip:
a0:01.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: NEC Corporation USB
On Tue, 09 Mar 2004 12:39:52 -0800, David Brownell [EMAIL PROTECTED] said:
David.B David Mosberger wrote:
David Mosberger wrote: ... add a new state
ED_DESCHEDULED, which is treated exactly like ED_IDLE, except
that in this state, the HC may still be referring to the ED
According to this page:
http://www.linux-usb.org/devices.html
HID Monitor support neither exists nor is it being worked on. Is this
still correct? I was hoping it would be fairly easy to do simple
stuff like brightness control from user space (perhaps via libusb).
The monitor I'm interested
On Wed, 10 Mar 2004 08:41:04 +0100, Vojtech Pavlik [EMAIL PROTECTED] said:
Vojtech It's supposed to do that only in case it's planning to use
Vojtech the limited HID-BP protocol.
I was concerned that the firmware for our Itanium-based machines may
be turning on the HID-BP protocol. If so,
On Wed, 10 Mar 2004 09:23:34 +0100, Vojtech Pavlik [EMAIL PROTECTED] said:
If so, wouldn't/shouldn't HID force it back to the normal report
protocol?
Vojtech Maybe yes, but there are devices which crash if you try to
Vojtech do that. :(
You mean sending Set_Protocol to a keyboard
On Wed, 10 Mar 2004 08:22:26 -0800, David Brownell [EMAIL PROTECTED] said:
David.B It won't add new BUG_ON calls (WARN at worst)
I put them there mostly as assertions. What I'd really want there is
a DEBUG_BUG_ON, which is more like assert() in user-land (i.e.,
production code would drop the
On Wed, 10 Mar 2004 18:43:25 -0800, David Brownell [EMAIL PROTECTED] said:
David.B David Mosberger wrote:
The current OHCI relies on the internals of the dma_pool()
implementation. ...
David.B It'd be good if you said _how_ you think it relies on such
David.B internals.
I
David,
Here is some comments on the 2.6.4 ohci driver relative to my original
proposed patch:
- The state which I called ED_DESCHEDULED you represent with
ED_UNLINK not on the ed_rm_list
- The state which I called ED_UNLINK you represent with
ED_UNLINK on the ed_rm_list
This looks
31 matches
Mail list logo
