Re: 2.4.2 yenta_socket problems on ThinkPad 240
You should try 2.4.6-pre5, it already includes a patch for you :) pci=assign-busses on the command line. -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2 yenta_socket problems on ThinkPad 240
I wrote:
> Does it make sense to turn pcibios_assign_all_busses into a variable
> with a default value of zero, and implement a kernel argument to set it?
After some discussion of various alternatives, including always turning it
on (bad for some systems), or writing a function to try to determine if
the configuration left by the BIOS is sane (maybe OK, but could still need
to be overridden), Linus wrote:
> Regardless, it would certainly make sense to have a manual override, with
> a kernel command line. If for no other reason than to allow for mistakes
> and let the user force the old/new behaviour.
Since I offered to generate a suitable patch, below find one against
2.4.5. This patch ONLY tries to provide for the command line override.
I had to touch more files than I would have liked, and unfortunately can
only test it on x86 even though it potentially affects other
architectures. It seems to do the right thing on my IBM ThinkPad 240.
What I've done is:
1) Replaced the pcibios_assign_all_busses() macro in each architecture
with a defined constant PCI_ASSIGN_ALL_BUSSES_DEFAULT. Note that some
architectures were using a function instead of a macro, but the function
just returned the contents of a variable.
2) Added the variable pci_assign_all_busses, which gets initialized from
the defined constant PCI_ASSIGN_ALL_BUSSES_DEFAULT.
3) Added a __setup macro and function to handle a command line argument
"pci_assign_all_busses=1" (or zero), which sets the pci_assign_all_busses
variable.
4) Changed the code in drivers/pci/pci.c to use the variable rather than
the old macro/function.
If code is added to attempt to automatically determine whether bus
configuration is needed, and if that code runs after the command line is
parsed, it might be necessary to add a second variable (or special
values of the existing one) to avoid changing the variable if the user
has specified a value on the command line, since the whole point is to
allow the user to override the default behavior.
If I've done this in a suboptimal manner, I'd be happy to hear
suggestions of better approaches. As submitting kernel patches goes,
this is my first time, so please be gentle. :-)
Thanks,
Eric
diff -uNr linux-2.4.5.orig/arch/parisc/kernel/inventory.c
linux-2.4.5/arch/parisc/kernel/inventory.c
--- linux-2.4.5.orig/arch/parisc/kernel/inventory.c Wed Dec 6 11:46:39 2000
+++ linux-2.4.5/arch/parisc/kernel/inventory.c Thu Jun 21 18:26:52 2001
@@ -138,6 +138,7 @@
ulong pcell_loc;
pdc_pat = (pdc_pat_cell_get_number(_result) == PDC_OK);
+ pci_assign_all_busses = pdc_pat;
if (!pdc_pat)
{
return 0;
diff -uNr linux-2.4.5.orig/arch/ppc/kernel/pci.c linux-2.4.5/arch/ppc/kernel/pci.c
--- linux-2.4.5.orig/arch/ppc/kernel/pci.c Mon May 21 17:04:47 2001
+++ linux-2.4.5/arch/ppc/kernel/pci.c Thu Jun 21 18:26:52 2001
@@ -47,10 +47,6 @@
static void pcibios_fixup_cardbus(struct pci_dev* dev);
#endif
-/* By default, we don't re-assign bus numbers. We do this only on
- * some pmacs
- */
-int pci_assign_all_busses;
struct pci_controller* hose_head;
struct pci_controller** hose_tail = _head;
@@ -752,11 +748,6 @@
ppc_md.pcibios_after_init();
}
-int __init
-pcibios_assign_all_busses(void)
-{
- return pci_assign_all_busses;
-}
void __init
pcibios_fixup_pbus_ranges(struct pci_bus * bus, struct pbus_set_ranges_data * ranges)
diff -uNr linux-2.4.5.orig/drivers/pci/pci.c linux-2.4.5/drivers/pci/pci.c
--- linux-2.4.5.orig/drivers/pci/pci.c Sat May 19 17:43:06 2001
+++ linux-2.4.5/drivers/pci/pci.c Thu Jun 21 18:26:52 2001
@@ -37,6 +37,19 @@
LIST_HEAD(pci_root_buses);
LIST_HEAD(pci_devices);
+
+int pci_assign_all_busses = PCI_ASSIGN_ALL_BUSSES_DEFAULT;
+
+
+static int __init pci_assign_all_busses_setup(char *str)
+{
+ pci_assign_all_busses = simple_strtol(str,NULL,0);
+ return 1;
+}
+
+__setup("pci_assign_all_busses=", pci_assign_all_busses_setup);
+
+
/**
* pci_find_slot - locate PCI device from a given PCI slot
* @bus: number of PCI bus on which desired PCI device resides
@@ -957,7 +970,7 @@
pci_read_config_dword(dev, PCI_PRIMARY_BUS, );
DBG("Scanning behind PCI bridge %s, config %06x, pass %d\n", dev->slot_name,
buses & 0xff, pass);
- if ((buses & 0x00) && !pcibios_assign_all_busses()) {
+ if ((buses & 0x00) && !pci_assign_all_busses) {
/*
* Bus already configured by firmware, process it in the first
* pass and just note the configuration.
diff -uNr linux-2.4.5.orig/include/asm-alpha/pci.h linux-2.4.5/include/asm-alpha/pci.h
--- linux-2.4.5.orig/include/asm-alpha/pci.hMon May 21 13:38:41 2001
+++ linux-2.4.5/include/asm-alpha/pci.h Thu Jun 21 18:26:52 2001
@@ -46,7 +46,7 @@
/* Override the logic in pci_scan_bus for skipping already-configured
bus numbers. */
-#define
Re: 2.4.2 yenta_socket problems on ThinkPad 240
I wrote:
Does it make sense to turn pcibios_assign_all_busses into a variable
with a default value of zero, and implement a kernel argument to set it?
After some discussion of various alternatives, including always turning it
on (bad for some systems), or writing a function to try to determine if
the configuration left by the BIOS is sane (maybe OK, but could still need
to be overridden), Linus wrote:
Regardless, it would certainly make sense to have a manual override, with
a kernel command line. If for no other reason than to allow for mistakes
and let the user force the old/new behaviour.
Since I offered to generate a suitable patch, below find one against
2.4.5. This patch ONLY tries to provide for the command line override.
I had to touch more files than I would have liked, and unfortunately can
only test it on x86 even though it potentially affects other
architectures. It seems to do the right thing on my IBM ThinkPad 240.
What I've done is:
1) Replaced the pcibios_assign_all_busses() macro in each architecture
with a defined constant PCI_ASSIGN_ALL_BUSSES_DEFAULT. Note that some
architectures were using a function instead of a macro, but the function
just returned the contents of a variable.
2) Added the variable pci_assign_all_busses, which gets initialized from
the defined constant PCI_ASSIGN_ALL_BUSSES_DEFAULT.
3) Added a __setup macro and function to handle a command line argument
pci_assign_all_busses=1 (or zero), which sets the pci_assign_all_busses
variable.
4) Changed the code in drivers/pci/pci.c to use the variable rather than
the old macro/function.
If code is added to attempt to automatically determine whether bus
configuration is needed, and if that code runs after the command line is
parsed, it might be necessary to add a second variable (or special
values of the existing one) to avoid changing the variable if the user
has specified a value on the command line, since the whole point is to
allow the user to override the default behavior.
If I've done this in a suboptimal manner, I'd be happy to hear
suggestions of better approaches. As submitting kernel patches goes,
this is my first time, so please be gentle. :-)
Thanks,
Eric
diff -uNr linux-2.4.5.orig/arch/parisc/kernel/inventory.c
linux-2.4.5/arch/parisc/kernel/inventory.c
--- linux-2.4.5.orig/arch/parisc/kernel/inventory.c Wed Dec 6 11:46:39 2000
+++ linux-2.4.5/arch/parisc/kernel/inventory.c Thu Jun 21 18:26:52 2001
@@ -138,6 +138,7 @@
ulong pcell_loc;
pdc_pat = (pdc_pat_cell_get_number(pdc_result) == PDC_OK);
+ pci_assign_all_busses = pdc_pat;
if (!pdc_pat)
{
return 0;
diff -uNr linux-2.4.5.orig/arch/ppc/kernel/pci.c linux-2.4.5/arch/ppc/kernel/pci.c
--- linux-2.4.5.orig/arch/ppc/kernel/pci.c Mon May 21 17:04:47 2001
+++ linux-2.4.5/arch/ppc/kernel/pci.c Thu Jun 21 18:26:52 2001
@@ -47,10 +47,6 @@
static void pcibios_fixup_cardbus(struct pci_dev* dev);
#endif
-/* By default, we don't re-assign bus numbers. We do this only on
- * some pmacs
- */
-int pci_assign_all_busses;
struct pci_controller* hose_head;
struct pci_controller** hose_tail = hose_head;
@@ -752,11 +748,6 @@
ppc_md.pcibios_after_init();
}
-int __init
-pcibios_assign_all_busses(void)
-{
- return pci_assign_all_busses;
-}
void __init
pcibios_fixup_pbus_ranges(struct pci_bus * bus, struct pbus_set_ranges_data * ranges)
diff -uNr linux-2.4.5.orig/drivers/pci/pci.c linux-2.4.5/drivers/pci/pci.c
--- linux-2.4.5.orig/drivers/pci/pci.c Sat May 19 17:43:06 2001
+++ linux-2.4.5/drivers/pci/pci.c Thu Jun 21 18:26:52 2001
@@ -37,6 +37,19 @@
LIST_HEAD(pci_root_buses);
LIST_HEAD(pci_devices);
+
+int pci_assign_all_busses = PCI_ASSIGN_ALL_BUSSES_DEFAULT;
+
+
+static int __init pci_assign_all_busses_setup(char *str)
+{
+ pci_assign_all_busses = simple_strtol(str,NULL,0);
+ return 1;
+}
+
+__setup(pci_assign_all_busses=, pci_assign_all_busses_setup);
+
+
/**
* pci_find_slot - locate PCI device from a given PCI slot
* @bus: number of PCI bus on which desired PCI device resides
@@ -957,7 +970,7 @@
pci_read_config_dword(dev, PCI_PRIMARY_BUS, buses);
DBG(Scanning behind PCI bridge %s, config %06x, pass %d\n, dev-slot_name,
buses 0xff, pass);
- if ((buses 0x00) !pcibios_assign_all_busses()) {
+ if ((buses 0x00) !pci_assign_all_busses) {
/*
* Bus already configured by firmware, process it in the first
* pass and just note the configuration.
diff -uNr linux-2.4.5.orig/include/asm-alpha/pci.h linux-2.4.5/include/asm-alpha/pci.h
--- linux-2.4.5.orig/include/asm-alpha/pci.hMon May 21 13:38:41 2001
+++ linux-2.4.5/include/asm-alpha/pci.h Thu Jun 21 18:26:52 2001
@@ -46,7 +46,7 @@
/* Override the logic in pci_scan_bus for skipping already-configured
bus numbers. */
-#define
Re: 2.4.2 yenta_socket problems on ThinkPad 240
You should try 2.4.6-pre5, it already includes a patch for you :) pci=assign-busses on the command line. -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: 2.4.2 yenta_socket problems on ThinkPad 240
Linus Torvalds wrote: > As far as I can tell, the yenta code should _really_ do something like > > PCI_PROMARY_BUS:dev->subordinate->primary > PCI_SECONDARY_BUS: dev->subordinate->secondary > PCI_SUBORDINATE_BUS:dev->subordinate->subordinate > PCI_SEC_LATENCY_TIMER: preferably settable, not just hardcoded to 176 Ah, nice. That produces numbers on my laptop that look a bit better. Patch attached (which conflicts with the previous yenta.c patch). I left 176 hardcoded for now, pending thinking on the rest of your message... -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | Index: drivers/pcmcia/yenta.c === RCS file: /cvsroot/gkernel/linux_2_4/drivers/pcmcia/yenta.c,v retrieving revision 1.1.1.25.4.1 diff -u -r1.1.1.25.4.1 yenta.c --- drivers/pcmcia/yenta.c 2001/06/16 19:21:56 1.1.1.25.4.1 +++ drivers/pcmcia/yenta.c 2001/06/16 21:09:40 @@ -644,9 +644,9 @@ config_writeb(socket, PCI_LATENCY_TIMER, 168); config_writel(socket, PCI_PRIMARY_BUS, (176 << 24) | /* sec. latency timer */ - (dev->subordinate->number << 16) | /* subordinate bus */ - (dev->subordinate->number << 8) | /* secondary bus */ - dev->bus->number); /* primary bus */ + (dev->subordinate->subordinate << 16) | /* subordinate bus */ + (dev->subordinate->secondary << 8) | /* secondary bus */ + dev->subordinate->primary);/* primary bus */ /* * Set up the bridging state:
Re: 2.4.2 yenta_socket problems on ThinkPad 240
Alan Cox wrote: > > > I would love to just define it unconditionally for x86, but I believe > > Martin said that causes problems with some hardware, and the way the > > BIOS has set up that hardware. (details anyone?) > > Im not sure unconditionally is wise. However turning it into a routine that > walks the PCI bus tree and returns 1 if a duplicate is found seems to be > a little bit less likely to cause suprises That would work, but is really a bandaid because we don't know what the real problem is... this still smells vaguely like yenta and pci bus core should be more than just the kissing cousins they are now. OTOH I still don't like how much we trust firmware PCI bus setup on x86.. I am pretty lucky on Alpha, we already trust the kernel PCI code implicitly by unconditionally defining pcibios_assign_all_busses to one. :) Jeff -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2 yenta_socket problems on ThinkPad 240
Alan Cox wrote: I would love to just define it unconditionally for x86, but I believe Martin said that causes problems with some hardware, and the way the BIOS has set up that hardware. (details anyone?) Im not sure unconditionally is wise. However turning it into a routine that walks the PCI bus tree and returns 1 if a duplicate is found seems to be a little bit less likely to cause suprises That would work, but is really a bandaid because we don't know what the real problem is... this still smells vaguely like yenta and pci bus core should be more than just the kissing cousins they are now. OTOH I still don't like how much we trust firmware PCI bus setup on x86.. I am pretty lucky on Alpha, we already trust the kernel PCI code implicitly by unconditionally defining pcibios_assign_all_busses to one. :) Jeff -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: 2.4.2 yenta_socket problems on ThinkPad 240
Linus Torvalds wrote: As far as I can tell, the yenta code should _really_ do something like PCI_PROMARY_BUS:dev-subordinate-primary PCI_SECONDARY_BUS: dev-subordinate-secondary PCI_SUBORDINATE_BUS:dev-subordinate-subordinate PCI_SEC_LATENCY_TIMER: preferably settable, not just hardcoded to 176 Ah, nice. That produces numbers on my laptop that look a bit better. Patch attached (which conflicts with the previous yenta.c patch). I left 176 hardcoded for now, pending thinking on the rest of your message... -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | Index: drivers/pcmcia/yenta.c === RCS file: /cvsroot/gkernel/linux_2_4/drivers/pcmcia/yenta.c,v retrieving revision 1.1.1.25.4.1 diff -u -r1.1.1.25.4.1 yenta.c --- drivers/pcmcia/yenta.c 2001/06/16 19:21:56 1.1.1.25.4.1 +++ drivers/pcmcia/yenta.c 2001/06/16 21:09:40 @@ -644,9 +644,9 @@ config_writeb(socket, PCI_LATENCY_TIMER, 168); config_writel(socket, PCI_PRIMARY_BUS, (176 24) | /* sec. latency timer */ - (dev-subordinate-number 16) | /* subordinate bus */ - (dev-subordinate-number 8) | /* secondary bus */ - dev-bus-number); /* primary bus */ + (dev-subordinate-subordinate 16) | /* subordinate bus */ + (dev-subordinate-secondary 8) | /* secondary bus */ + dev-subordinate-primary);/* primary bus */ /* * Set up the bridging state:
Re: 2.4.2 yenta_socket problems on ThinkPad 240
On 6-Jun-2001, I reported: > I upgraded my IBM ThinkPad 240 (Type 2609-31U) from Red Hat 7.0 to > Red Hat 7.1, which uses the 2.4.2 kernel and the kernel PCMCIA drivers. > Before the upgrade, all my CardBus and PCMCIA devices were working fine. > Now the yenta_socket module seems to be causing problems, and none of > the cards work. Arjan van de Ven of Red Hat tracked my problem down to a broken BIOS, which is not configuring the TI PC1211 CardBus bridge correctly. Even IBM's latest BIOS for the ThinkPad 240, IRET75WW released 17-May-2001, has this problem. Apparently IBM has issued fixes for other ThinkPads because the problem occurs with Windows 2000, but since Windows 2000 is not supported on the ThinkPad 240, it is unlikely that they will fix it. A one line change to linux/include/asm-i386/pci.h fixes it: -#define pcibios_assign_all_busses()0 +#define pcibios_assign_all_busses()1 Given that this macro exists, I surmise that other people have been bitten by similar problems. So now my question is: Does it make sense to turn pcibios_assign_all_busses into a variable with a default value of zero, and implement a kernel argument to set it? That way people with broken BIOSes could solve it by simply adding the argument in their lilo.conf. In an ideal world the BIOSes would get fixed and such a workaround would be unnecessary, but in my experience trying to get a vendor to fix a BIOS problem is an exercise in futility. If no one is opposed to my proposed change, I'll be happy to generate a suitable patch and send it in. Thanks! Eric Smith - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2 yenta_socket problems on ThinkPad 240
On 6-Jun-2001, I reported: I upgraded my IBM ThinkPad 240 (Type 2609-31U) from Red Hat 7.0 to Red Hat 7.1, which uses the 2.4.2 kernel and the kernel PCMCIA drivers. Before the upgrade, all my CardBus and PCMCIA devices were working fine. Now the yenta_socket module seems to be causing problems, and none of the cards work. Arjan van de Ven of Red Hat tracked my problem down to a broken BIOS, which is not configuring the TI PC1211 CardBus bridge correctly. Even IBM's latest BIOS for the ThinkPad 240, IRET75WW released 17-May-2001, has this problem. Apparently IBM has issued fixes for other ThinkPads because the problem occurs with Windows 2000, but since Windows 2000 is not supported on the ThinkPad 240, it is unlikely that they will fix it. A one line change to linux/include/asm-i386/pci.h fixes it: -#define pcibios_assign_all_busses()0 +#define pcibios_assign_all_busses()1 Given that this macro exists, I surmise that other people have been bitten by similar problems. So now my question is: Does it make sense to turn pcibios_assign_all_busses into a variable with a default value of zero, and implement a kernel argument to set it? That way people with broken BIOSes could solve it by simply adding the argument in their lilo.conf. In an ideal world the BIOSes would get fixed and such a workaround would be unnecessary, but in my experience trying to get a vendor to fix a BIOS problem is an exercise in futility. If no one is opposed to my proposed change, I'll be happy to generate a suitable patch and send it in. Thanks! Eric Smith - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.2 yenta_socket problems on ThinkPad 240
I upgraded my IBM ThinkPad 240 (Type 2609-31U) from Red Hat 7.0 to Red Hat 7.1, which uses the 2.4.2 kernel and the kernel PCMCIA drivers. Before the upgrade, all my CardBus and PCMCIA devices were working fine. Now the yenta_socket module seems to be causing problems, and none of the cards work. Before doing 'modprobe yenta_socket', the PCI stuff looks OK: % ls -l /proc/bus/pci total 0 dr-xr-xr-x2 rootroot0 Jun 1 12:52 00 -r--r--r--1 rootroot0 Jun 1 12:52 devices % ls /proc/bus/pci/00 00.0 07.0 07.1 07.2 07.3 09.0 0a.0 0b.0 0c.0 and lspci -vvv gives normal-looking output (which I can send if it's useful). After the 'modprobe yenta_socket': % ls -l /proc/bus/pci total 0 dr-xr-xr-x2 rootroot0 Jun 1 12:44 00 dr-xr-xr-x2 rootroot0 Jun 1 12:44 00 -r--r--r--1 rootroot0 Jun 1 12:44 devices Note the two directories with the same name. % ls -l /proc/bus/pci/00 total 0 -rw-r--r--1 rootroot0 Jun 1 12:48 00.0 % lspci -vvv pcilib: Cannot open /proc/bus/pci/00/0c.0 Has anyone seen similar behavior? Is there any way to force yenta_socket to assign the cardbus to be bus 01 rather than 00? Thanks! Eric Smith - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.2 yenta_socket problems on ThinkPad 240
I upgraded my IBM ThinkPad 240 (Type 2609-31U) from Red Hat 7.0 to Red Hat 7.1, which uses the 2.4.2 kernel and the kernel PCMCIA drivers. Before the upgrade, all my CardBus and PCMCIA devices were working fine. Now the yenta_socket module seems to be causing problems, and none of the cards work. Before doing 'modprobe yenta_socket', the PCI stuff looks OK: % ls -l /proc/bus/pci total 0 dr-xr-xr-x2 rootroot0 Jun 1 12:52 00 -r--r--r--1 rootroot0 Jun 1 12:52 devices % ls /proc/bus/pci/00 00.0 07.0 07.1 07.2 07.3 09.0 0a.0 0b.0 0c.0 and lspci -vvv gives normal-looking output (which I can send if it's useful). After the 'modprobe yenta_socket': % ls -l /proc/bus/pci total 0 dr-xr-xr-x2 rootroot0 Jun 1 12:44 00 dr-xr-xr-x2 rootroot0 Jun 1 12:44 00 -r--r--r--1 rootroot0 Jun 1 12:44 devices Note the two directories with the same name. % ls -l /proc/bus/pci/00 total 0 -rw-r--r--1 rootroot0 Jun 1 12:48 00.0 % lspci -vvv pcilib: Cannot open /proc/bus/pci/00/0c.0 Has anyone seen similar behavior? Is there any way to force yenta_socket to assign the cardbus to be bus 01 rather than 00? Thanks! Eric Smith - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
