On Mon, Apr 29, Johannes Erdfelt wrote:
> On Mon, Apr 29, 2002, Olaf Hering <[EMAIL PROTECTED]> wrote:
> > > > > If applying only this patch reproducibly causes problems, I would be
> > > > > very suspicious of a compiler bug.
> > > >
> > > > agreed. I will try gcc3 next week.
> > >
> > > Let me know how it goes.
> >
> > I tried gcc3.1, same result with 2.4.19-pre7. I tried a few combinations
> > and thats the result:
> >
> > uhci-1 uhci-2 uhci-3 uhci-4 works
> > yes yes yes yes no
> > no yes yes yes no
> > yes no yes yes no
> > no no yes yes no
> > yes yes no yes no
> > no yes no yes no
> > yes no no yes no
> > no no no yes no
> > yes yes yes no no
> > no yes yes no no
> > yes no yes no yes
> > no no yes no yes
> > yes yes no no no
> > no yes no no no
> > yes no no no yes
> > no no no no yes
> >
> > yes means, patch is applied, no means, patch was reversed from pre7.
Here is a patch to let it work with 2.4.19-pre7. fsbr should not be NULL
and there is some gap needed in struct uhci, more than 4 bytes. If I
move *foo2 down it does not work, leaving it like that and it works
again:
diff -urNX exclude linux-2.4.19-pre7-ide.orig/drivers/usb/uhci.c
linux-2.4.19-pre7-ide/drivers/usb/uhci.c
--- linux-2.4.19-pre7-ide.orig/drivers/usb/uhci.c Wed May 1 11:59:40 2002
+++ linux-2.4.19-pre7-ide/drivers/usb/uhci.c Wed May 1 14:55:32 2002
@@ -2475,6 +2475,7 @@
}
spin_unlock(&uhci->urb_list_lock);
+ err("io_addr %u foo1 %p foo2 %p", uhci->io_addr, uhci->foo1, uhci->foo2);
uhci_finish_completion(uhci);
}
@@ -2733,7 +2734,12 @@
/* or broken setup */
reset_hc(uhci);
+ info("XXX uhci->fsbr %d ioaddr %u uhci: %p foo1: %p fsbr: %p", uhci->fsbr ,
+uhci->io_addr, uhci, &uhci->foo1, &uhci->fsbr);
+ uhci->foo1 = NULL;
+ uhci->foo2 = NULL;
+#if 0
uhci->fsbr = 0;
+#endif
uhci->fsbrtimeout = 0;
uhci->is_suspended = 0;
diff -urNX exclude linux-2.4.19-pre7-ide.orig/drivers/usb/uhci.h
linux-2.4.19-pre7-ide/drivers/usb/uhci.h
--- linux-2.4.19-pre7-ide.orig/drivers/usb/uhci.h Wed May 1 11:59:40 2002
+++ linux-2.4.19-pre7-ide/drivers/usb/uhci.h Wed May 1 15:00:11 2002
@@ -308,6 +309,8 @@
spinlock_t frame_list_lock;
struct uhci_frame_list *fl; /* P: uhci->frame_list_lock */
+ char *foo1;
+ char *foo2;
int fsbr; /* Full speed bandwidth reclamation */
unsigned long fsbrtimeout; /* FSBR delay */
int is_suspended;
This is the dmesg output with the nonworking version (*foo2 moved down):
linux:~ # dmesg | grep XXX
uhci.c: XXX uhci->fsbr 134605280 ioaddr 6208 uhci: cf933ca0 foo1: cf933d04 fsbr:
cf933d08
uhci.c: XXX uhci->fsbr 0 ioaddr 6240 uhci: cf933da0 foo1: cf933e04 fsbr: cf933e08
uhci.c: XXX uhci->fsbr 0 ioaddr 6272 uhci: cf933ba0 foo1: cf933c04 fsbr: cf933c08
And this is the working version:
linux:~ # dmesg | grep XXX
uhci.c: XXX uhci->fsbr 134605280 ioaddr 6208 uhci: cf933ba0 foo1: cf933c04 fsbr:
cf933c0c
uhci.c: XXX uhci->fsbr 1095585103 ioaddr 6240 uhci: cf933da0 foo1: cf933e04 fsbr:
cf933e0c
uhci.c: XXX uhci->fsbr 539767613 ioaddr 6272 uhci: cf9337a0 foo1: cf933804 fsbr:
cf93380c
So, something does touch fsbr. memcorruption somewhere?
Gruss Olaf
--
$ man clone
BUGS
Main feature not yet implemented...
