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
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/