Date: Tue, 9 Apr 2002 11:41:34 +0200 From: Cor Bosman <cor@xs4all.net> To: Nick Hibma <n_hibma@van-laarhoven.org> Cc: Cor Bosman <cor@xs4all.net>, Cor Bosman <cor@xs4all.nl>, "freebsd-bugs@freebsd.org" <freebsd-bugs@freebsd.org> Subject: Re: broadcast storms on USB controllers (Re: USB/SCSI probleem in 4.5-p2 ?) Message-ID: <20020409114134.A21093@xs4all.nl> In-Reply-To: <20020409112835.U374-100000@heather.van-laarhoven.org>; from n_hibma@van-laarhoven.org on Tue, Apr 09, 2002 at 11:29:02AM %2B0200 References: <20020409111057.W374-100000@heather.van-laarhoven.org> <20020409112835.U374-100000@heather.van-laarhoven.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Im seeing:
uhci0: <VIA 83C572 USB controller> port 0xe400-0xe41f at device 17.2 on pci0
pci_cfgintr: can't route an interrupt to 0:17 INTD
uhci0: Could not allocate irq
device_probe_and_attach: uhci0 attach returned 6
uhci0: <VIA 83C572 USB controller> port 0xe800-0xe81f at device 17.3 on pci0
pci_cfgintr: can't route an interrupt to 0:17 INTD
uhci0: Could not allocate irq
device_probe_and_attach: uhci0 attach returned 6
uhci0: <VIA 83C572 USB controller> port 0xec00-0xec1f at device 17.4 on pci0
pci_cfgintr: can't route an interrupt to 0:17 INTD
uhci0: Could not allocate irq
device_probe_and_attach: uhci0 attach returned 6
But the kernel does continue now. So this seems to have fixed/and or bypassed
the problem.
Any idea what the problem is on the USB side? I often hear about VIA chipset
problems.
Another 4.5-p2 system (exact same kernel) works fine.
usb0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
Guess the VIA chipset is broken.
Cor
On Tue, Apr 09, 2002 at 11:29:02AM +0200, Nick Hibma wrote:
>
> You should see a message like:
>
> uhci1: Could not allocate irq
> device_probe_and_attach: uhci1 attach returned 6
>
> to be complete.
>
> Nick
>
>
> On Tue, 9 Apr 2002, Nick Hibma wrote:
>
> >
> > Could you try the following patch?
> >
> > heather:root# diff -wu sys/dev/pci/pci.c~ sys/dev/pci/pci.c
> > --- sys/dev/pci/pci.c~ Sun Jan 13 15:31:21 2002
> > +++ sys/dev/pci/pci.c Tue Apr 9 11:19:05 2002
> > @@ -783,7 +783,7 @@
> > pci_add_map(pcib, b, s, f, q->arg1, rl);
> > }
> >
> > - if (cfg->intpin > 0 && cfg->intline != 255) {
> > + if (cfg->intpin > 0 && cfg->intline != 255 && cfg->intline != 0)
> > {
> > #ifdef __ia64__
> > /*
> > * Re-route interrupts on ia64 so that we can get the
> >
> > This removes the difference between the two functions that decide
> > whether or not to use an interrupt. I don't know whether this is correct
> > according to the PCI spec, but it looks incorrect to me to add intline 0
> > to the resource list for interrupts.
> >
> > The result of this patch should be that the USB controller is refused
> > while attaching and hence the interrupt on it is not enabled. This
> > doesn't make the USB controller work for you, but that problem is on a
> > totally different scale and not one that I could fix. It should however
> > make your system boot.
> >
> > The patch is for a reasonably current CURRENT, so I wouldn't expect more
> > problems with it than a bit of offset when applying the patch.
> >
> > Cheers,
> >
> > Nick
> >
> >
> > > uhci0: <VIA 83C572 USB controller> port 0xe400-0xe41f irq 0 at device 17.2 on pci0
> > > pci_cfgintr: can't route an interrupt to 0:17 INTD
> > > usb0: <VIA 83C572 USB controller> on uhci0
> > > usb0: USB revision 1.0
> > > uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> > > uhub0: 2 ports with 2 removable, self powered
> > > uhci1: <VIA 83C572 USB controller> port 0xe800-0xe81f at device 17.3 on pci0
> > > pci_cfgintr: can't route an interrupt to 0:17 INTD
> > > uhci1: Could not allocate irq
> > > device_probe_and_attach: uhci1 attach returned 6
> > > uhci1: <VIA 83C572 USB controller> port 0xec00-0xec1f at device 17.4 on pci0
> > > pci_cfgintr: can't route an interrupt to 0:17 INTD
> > > uhci1: Could not allocate irq
> > > device_probe_and_attach: uhci1 attach returned 6
> > >
> > > Cor
> > >
> > > >
> > > > What does the line specifying USB say?
> > > >
> > > > Nick
> > > >
> > > > On Mon, 8 Apr 2002, Cor Bosman wrote:
> > > >
> > > > > During boot of the kernel the system hangs just before probing the SCSI
> > > > > harddisks:
> > > > >
> > > > > APIC_IO: Testing 8254 interrupt delivery
> > > > > APIC_IO: routing 8254 via IOAPIC #0 intpin 2
> > > > > IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default
> > > > > IP Filter: v3.4.20 initialized. Default = pass all, Logging = enabled
> > > > > SMP: AP CPU #1 Launched!
> > > > > acd0: CDROM <MATSHITA CR-177> at ata0-master using PIO4
> > > > >
> > > > > It hangs here.
> > > > >
> > > > > If I remove USB support from the kernel things continue just fine.
> > > > >
> > > > > Ive read in the archives about problems in 4.4 with the BIOS not assigning
> > > > > an IRQ to USB. Is this still the case? I need to change BIOS settings
> > > > > to be able to use SCSI harddisks and USB devices?
> > > > >
> > > > > No way to fix this without BIOS changes?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Cor
> > > > >
> > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > > > > with "unsubscribe freebsd-bugs" in the body of the message
> > > > >
> > > >
> > > > --
> > > > n_hibma@van-laarhoven.org http://www.van-laarhoven.org/
> > > > n_hibma@FreeBSD.org http://www.etla.net/~n_hibma/
> > > >
> > >
> >
> >
>
> --
> n_hibma@van-laarhoven.org http://www.van-laarhoven.org/
> n_hibma@FreeBSD.org http://www.etla.net/~n_hibma/
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020409114134.A21093>