On Tue, Jan 22, 2013 at 06:17:00AM +, Huang, Adrian (ISS Linux TW) wrote:
> Hi Alan,
>
> Recently, I'm debugging this issue (the same symptom described by Don) on my
> server. Fortunately, the issue was fixed by applying your patch posted in
> this email thread. Just checked the latest kerne
Hi Alan,
Recently, I'm debugging this issue (the same symptom described by Don) on my
server. Fortunately, the issue was fixed by applying your patch posted in this
email thread. Just checked the latest kernel (3.7.4) and the mainline
(3.8-rc4), the patch was not included in those kernels. Do y
On Thu, Oct 18, 2012 at 03:59:44PM -0400, Alan Stern wrote:
> On Tue, 16 Oct 2012, Don Zickus wrote:
>
> > > > I did not get a chance to test the patch yet.
> > >
> > > Let me know what happens.
> >
> > It might take a while as our customer's customers have trouble reproducing
> > this which mea
On Tue, 16 Oct 2012, Don Zickus wrote:
> > > I did not get a chance to test the patch yet.
> >
> > Let me know what happens.
>
> It might take a while as our customer's customers have trouble reproducing
> this which means it is difficult to tell if the problem is fixed or just
> harder to repro
On Tue, 16 Oct 2012, Don Zickus wrote:
> > What must have happened is that one of the bits in the USBSTS register
> > was set. It didn't cause an IRQ because the USBINTR register was
> > clear, but an IRQ arrived anyway from some other device sharing the IRQ
> > line.
> >
> > Since USBSTS had
On Tue, Oct 16, 2012 at 12:01:29PM -0400, Alan Stern wrote:
> On Tue, 16 Oct 2012, Don Zickus wrote:
>
> > > I dislike adding an extra test to a hot path, but there doesn't seem to
> > > be any way around it. Some of the other HCDs may need a similar
> > > change.
> >
> > I understand your con
On Tue, 16 Oct 2012, Don Zickus wrote:
> > I dislike adding an extra test to a hot path, but there doesn't seem to
> > be any way around it. Some of the other HCDs may need a similar
> > change.
>
> I understand your concern. I was curious in uhci_irq, I see the following
> fragment:
>
>
On Mon, Oct 15, 2012 at 05:31:01PM -0400, Alan Stern wrote:
> >
> > uhci_scan_schedule->
> > uhci_clear_next_interrupt->
> > uhci->term_td->status &= ~cpu_to_hc32(uhci, TD_CTRL_IOC);
> >
> > This panics becase term_td is not allocated yet.
> >
> > Now I could be wrong about the interrupts
On Mon, 15 Oct 2012, Don Zickus wrote:
> Hi Alan,
>
> I am seeing an odd panic with uhci when a 160 cpu box panics and starts
> running a kdump kernel (which is the same exact image as the boot kernel)
> for our RHEL-6 (2.6.32) kernel. Now I understand 2.6.32 is not something
> upstream supports
