Bug 26920
| Summary: | PCI autoconfiguration of USB, dc ether, and pccard broken on SHARP PC-AR10 | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Tony Finch <dot> |
| Component: | kern | Assignee: | Warner Losh <imp> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Tony Finch
2001-04-28 15:00:01 UTC
With all those strange values in your PCI configuration check that there is no BIOS setting that says PnP OS: yes. It should be no. Also, disable 'Legacy device support on USB' or 'USB keyboard support' if there is any. The fact that it can't start the USB controller means that somehow the thing doesn't respond to the RUN command. n_hibma@FreeBSD.ORG wrote: >With all those strange values in your PCI configuration check that there >is no BIOS setting that says > > PnP OS: yes. > >It should be no. There's no option like that. I wouldn't be surprised if the machine is so new that it assumes "yes". However, I have had fairly good luck in the past with the PNPBIOS kernel option, and when it hasn't worked it has been because I haven't specified device configurations in the kernel configuration file in enough detail, or because the BIOS's PNP config info has been in the wrong order for the console to work properly. Neither of those is the problem here. The problem as I see it seems to be independent of the PNP issue, since it is a PCI problem and AFAIK PNP problems are tied to ISA devices. I have the same problems with GENERIC, but obviously the diagnostics are less helpful. Is there a magic pciconf command I can use to give more useful information? pciconf -l seems unenlightening -- it has the same information as the dmesg I quoted. >Also, disable 'Legacy device support on USB' or 'USB keyboard support' >if there is any. The fact that it can't start the USB controller means >that somehow the thing doesn't respond to the RUN command. Yes, that's off. It looks to me as if the problem is more low level than that. I'm back in England now, so if you have time to look at the machine I can bring it round or we can have a pub meet or something... Thanks for the reply. Tony. -- f.a.n.finch <dot@dotat.at> DOVER WIGHT PORTLAND PLYMOUTH: NORTHEAST 5 TO 7, INCREASING GALE 8 FOR A TIME. OCCASIONAL RAIN. GOOD BECOMING MODERATE OR POOR. > >With all those strange values in your PCI configuration check that there > >is no BIOS setting that says > > > > PnP OS: yes. > > > >It should be no. > > There's no option like that. I wouldn't be surprised if the machine > is so new that it assumes "yes". However, I have had fairly good > luck in the past with the PNPBIOS kernel option, and when it hasn't > worked it has been because I haven't specified device configurations > in the kernel configuration file in enough detail, or because the > BIOS's PNP config info has been in the wrong order for the console > to work properly. Neither of those is the problem here. > > The problem as I see it seems to be independent of the PNP issue, > since it is a PCI problem and AFAIK PNP problems are tied to ISA > devices. I have the same problems with GENERIC, but obviously the > diagnostics are less helpful. The BIOS has to map the ports and interrupts in the cards. This 'PnP OS' switch determines whether or not the PCI interrupts and ports are mapped. > Is there a magic pciconf command I can use to give more useful > information? pciconf -l seems unenlightening -- it has the same > information as the dmesg I quoted. No the information is all there is. It shows that some PCI ports are not mapped. > >Also, disable 'Legacy device support on USB' or 'USB keyboard support' > >if there is any. The fact that it can't start the USB controller means > >that somehow the thing doesn't respond to the RUN command. > > Yes, that's off. It looks to me as if the problem is more low level > than that. I'm back in England now, so if you have time to look at > the machine I can bring it round or we can have a pub meet or > something... Are you coming to the barbie at Cameron's place? Nick n_hibma@FreeBSD.ORG wrote: > > The BIOS has to map the ports and interrupts in the cards. This 'PnP OS' > switch determines whether or not the PCI interrupts and ports are > mapped. Oh crap. This implies that fixing the problem would be non-trivial. Is anyone working on making FreeBSD do PCI resource allocation? > Are you coming to the barbie at Cameron's place? I am now that I know about it :-) Tony. -- f.a.n.finch <dot@dotat.at> TRAFALGAR: NORTH BACKING NORTHWEST 5 TO 7. THUNDERY SHOWERS. MAINLY GOOD. n_hibma@FreeBSD.ORG wrote: > >Look at www.etla.net/~n_hibma/usb > There is a patch there that forces some laptop into faking up an >interrupt I believe. You might be able to get away with doing the same >thing. Yes, that is my plan. Good to see that someone else has already blazed the trail for me :-) Tony. -- f.a.n.finch <dot@dotat.at> GERMAN BIGHT: NORTHEAST BECOMING VARIABLE 3 THEN NORTH 4 OR 5 INCREASING 6, OCCASIONALLY 7 LATER. RAIN OR SHOWERS. MODERATE OR GOOD. n_hibma@FreeBSD.ORG wrote: > >Look at www.etla.net/~n_hibma/usb > There is a patch there that forces some laptop into faking up an >interrupt I believe. You might be able to get away with doing the same >thing. Hmm, well there is now an #ifdef PCI_ENABLE_IO_MODES section where that patch would go which does the same thing in a more general way (although it needs to be added to sys/conf/options). It mostly helps me: the dc is successfully initialized and so is the USB hardware. The TI PCI 4451 still doesn't work, though, but that's not unexpected since there's no support for it in the OS at the moment. I have a copy of the data sheet, so I will try to get it working based on the info in that. Tony (happy). -- f.a.n.finch <dot@dotat.at> GERMAN BIGHT: NORTHEAST BECOMING VARIABLE 3 THEN NORTH 4 OR 5 INCREASING 6, OCCASIONALLY 7 LATER. RAIN OR SHOWERS. MODERATE OR GOOD. Tony Finch <dot@dotat.at> wrote: > > The TI PCI 4451 still doesn't work, though, but that's > not unexpected since there's no support for it in the OS at the > moment. I have a copy of the data sheet, so I will try to get it > working based on the info in that. Well adding the support turned out to be trivial since the 4451 is just a 1451 with an added IEEE 1394 OHCI. The real thing that stopped it working was that the BIOS's PnP device table didn't include an entry for a pccard controller. It works OK if I use a non-PnP configuration, but I have to disable the parallel port to get a spare IRQ for the pcic. Sigh. Here's the patch for TI 4451 support: ------------------------------------------------------------------------ --- sys/pci/pcic_p.c.orig Thu May 10 18:33:04 2001 +++ sys/pci/pcic_p.cWed Apr 18 04:36:20 2001 @@ -140,7 +140,7 @@ case 1 : strcpy(buf, "TI113X PCI Config Reg: "); /* - * Defalut card control register setting is + * Default card control register setting is * PCI interrupt. The method of this code * switches PCI INT and ISA IRQ by bit 7 of * Bridge Control Register(Offset:0x3e,0x13e). @@ -269,6 +269,9 @@ case PCI_DEVICE_ID_PCIC_TI1451: desc = "TI PCI-1451 PCI-CardBus Bridge"; break; + case PCI_DEVICE_ID_PCIC_TI4451: + desc = "TI PCI-4451 PCI-CardBus Bridge"; + break; case PCI_DEVICE_ID_TOSHIBA_TOPIC95: desc = "Toshiba ToPIC95 PCI-CardBus Bridge"; break; @@ -351,6 +354,7 @@ case PCI_DEVICE_ID_PCIC_TI1420: case PCI_DEVICE_ID_PCIC_TI1450: case PCI_DEVICE_ID_PCIC_TI1451: + case PCI_DEVICE_ID_PCIC_TI4451: ti1xxx_pci_init(dev); /* FALLTHROUGH */ default: --- sys/pci/pcic_p.h.orig Wed Apr 18 04:33:33 2001 +++ sys/pci/pcic_p.h Wed Apr 18 04:34:14 2001 @@ -48,6 +48,7 @@ #define PCI_DEVICE_ID_PCIC_TI1420 0xac51104cul #define PCI_DEVICE_ID_PCIC_TI1450 0xac1b104cul #define PCI_DEVICE_ID_PCIC_TI1451 0xac52104cul +#define PCI_DEVICE_ID_PCIC_TI4451 0xac42104cul #define PCI_DEVICE_ID_TOSHIBA_TOPIC95 0x060a1179ul #define PCI_DEVICE_ID_TOSHIBA_TOPIC97 0x060f1179ul #define PCI_DEVICE_ID_RICOH_RL5C465 0x04651180ul ------------------------------------------------------------------------ And to make my BIOS behave slightly better: ------------------------------------------------------------------------ --- sys/i386/conf/LINT.orig Thu May 10 18:51:26 2001 +++ sys/i386/conf/LINT Thu May 10 18:50:52 2001 @@ -1677,6 +1677,7 @@ # PCI options # #options PCI_QUIET #quiets PCI code on chipset settings +#options PCI_ENABLE_IOMODES #use if BIOS doesn't enable devices # The `ahc' device provides support for the Adaptec 29/3940(U)(W) --- sys/conf/options.orig Thu May 10 18:45:33 2001 +++ sys/conf/options Thu May 10 18:55:58 2001 @@ -370,6 +370,7 @@ # PCI related options PCI_QUIET opt_pci.h +PCI_ENABLE_IO_MODES opt_pci.h # NFS options NFS_MINATTRTIMO opt_nfs.h --- sys/pci/pci.c.orig Wed Apr 18 02:48:26 2001 +++ sys/pci/pci.c Thu May 10 18:56:43 2001 @@ -28,7 +28,7 @@ */ #include "opt_bus.h" - +#include "opt_pci.h" #include "opt_simos.h" #include <sys/param.h> ------------------------------------------------------------------------ These patches are sufficient to close this PR. (there might be some whitespace mangling; if so, my apologies) Tony. -- f.a.n.finch <dot@dotat.at> MALIN HEBRIDES: EASTERLY 4 OR 5. FAIR. MODERATE OR GOOD. PNP OS == no forces the BIOS to assign resources to the PCI devices rather than letting the OS do it. That's required now. On a more general note, we do need some way to allocate and assign resources for the pci bus so that cardbus can work. Eg, we need to be a PNP OS. We're not right now. Warner "M. Warner Losh" <bite-me@getlost.com> wrote: >PNP OS == no forces the BIOS to assign resources to the PCI devices >rather than letting the OS do it. That's required now. The OEM has funted this BIOS in such a way that the PNP OS option has been removed. I expect this will get more common, so proper PnP support is starting to become necessary... Tony. -- f.a.n.finch <dot@dotat.at> DOVER WIGHT PORTLAND PLYMOUTH: EAST OR NORTHEAST 2 OR 3, OCCASIONALLY 4. THUNDERY SHOWERS. MODERATE, WITH FOG PATCHES IN WEST. Responsible Changed From-To: freebsd-bugs->imp imp asked for it Can I ask that you try FreeBSD 4.4-RC as of August 22, 2001 or later? I think that things will just work now. I hve received reports of the SHARP PC-AR10 working, and my new DELL i8000 with a 4451 works great. Warner > Can I ask that you try FreeBSD 4.4-RC as of August 22, 2001 or later?
> I think that things will just work now. I hve received reports of the
> SHARP PC-AR10 working, and my new DELL i8000 with a 4451 works great.
[sorry for the late reply]
Unfortunately it still doesn't work. I just upgraded to the latest
-STABLE and the GENERIC kernel said immediately after the ata probe:
Dec 17 17:53:08 hand /boot/GENERIC/kernel: uhci0: <Intel 82371AB/EB (PIIX4) USB controller> irq 5 at device
7.2 on pci0
Dec 17 17:53:08 hand /boot/GENERIC/kernel: uhci0: Could not map ports
Dec 17 17:53:08 hand /boot/GENERIC/kernel: device_probe_and_attach: uhci0 attach returned 6
Dec 17 17:53:08 hand /boot/GENERIC/kernel: chip1: <Intel 82371AB Power management controller> port 0x2180-0
x218f at device 7.3 on pci0
Dec 17 17:53:08 hand /boot/GENERIC/kernel: dc0: <Accton EN2242 MiniPCI 10/100BaseTX> irq 11 at device 11.0
on pci0
Dec 17 17:53:08 hand /boot/GENERIC/kernel: dc0: couldn't map ports/memory
Dec 17 17:53:08 hand /boot/GENERIC/kernel: device_probe_and_attach: dc0 attach returned 6
etc.
With my patched PCI_ENABLE_IO_MODES kernel (see PR#32169 which should
really be part of this PR, sorry) I get the following at the corresponding
point in my dmesg:
Dec 17 17:54:13 hand /kernel: uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xfcc0-0xfcdf irq 5 at
device 7.2 on pci0
Dec 17 17:54:13 hand /kernel: usb0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0
Dec 17 17:54:13 hand /kernel: usb0: USB revision 1.0
Dec 17 17:54:13 hand /kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
Dec 17 17:54:13 hand /kernel: uhub0: 2 ports with 2 removable, self powered
Dec 17 17:54:13 hand /kernel: intpm0: <Intel 82371AB Power management controller> port 0x2180-0x218f irq 9
at device 7.3 on pci0
Dec 17 17:54:13 hand /kernel: intpm0: I/O mapped 2180
Dec 17 17:54:13 hand /kernel: intpm0: intr IRQ 9 enabled revision 0
Dec 17 17:54:13 hand /kernel: smbus0: <System Management Bus> on intsmb0
Dec 17 17:54:13 hand /kernel: smb0: <SMBus general purpose I/O> on smbus0
Dec 17 17:54:13 hand /kernel: intpm0: PM I/O mapped 8000
Dec 17 17:54:13 hand /kernel: dc0: <Accton EN2242 MiniPCI 10/100BaseTX> port 0xf800-0xf8ff mem 0xfedffc00-0
xfedfffff irq 11 at device 11.0 on pci0
Dec 17 17:54:13 hand /kernel: dc0: Ethernet address: 00:d0:59:29:19:fa
Dec 17 17:54:13 hand /kernel: miibus0: <MII bus> on dc0
Dec 17 17:54:13 hand /kernel: ukphy0: <Generic IEEE 802.3u media interface> on miibus0
Dec 17 17:54:13 hand /kernel: ukphy0: OUI 0x000895, model 0x0001, rev. 0
Dec 17 17:54:13 hand /kernel: ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
Dec 17 17:54:13 hand /kernel: bpf: dc0 attached
much more successful.
Tony.
I've been going through my old PRs to see which ones can be closed easily. This one has boiled down to a duplicate of PR#32169, other than some commentary on PnP compatibility. Do you want to keep it open or shall I close it? Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ LUNDY FASTNET IRISH SEA: SOUTHWEST BACKING SOUTH 5 TO 7, OCCASIONALLY 4 IN LUNDY AND IRISH SEA. OCCASIONAL RAIN. MODERATE OR GOOD. I just noticed that the PCI_ENABLE_IO_MODES option has been MFCed, so this PR has been resolved to my satisfaction. Shall I close it? Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE: SOUTHEASTERLY 4 OR 5, INCREASING 5 TO 7 FOR A TIME IN SOUTHEAST VIKING AND SOUTH UTSIRE. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. In message: <20020529011357.A11194@chiark.greenend.org.uk> Tony Finch <dot@dotat.at> writes: : I just noticed that the PCI_ENABLE_IO_MODES option has been MFCed, so : this PR has been resolved to my satisfaction. Shall I close it? Sure. Warner State Changed From-To: open->closed PCI_ENABLE_IO_MODES option is now in -STABLE |
