Re: [PATCH] Make ide-cs work for hardware with 8-bit CF-Interface
On Tue, Sep 06, 2005 at 06:47:08PM +0200, Thomas Kleffel (LKML) wrote:
>
> The following patch is against vanilla 2.6.13.
>
> ldiff -uprN a/drivers/ide/legacy/ide-cs.c b/drivers/ide/legacy/ide-cs.c
> --- a/drivers/ide/legacy/ide-cs.c 2005-08-08 15:30:35.0 +0200
> +++ b/drivers/ide/legacy/ide-cs.c 2005-09-05 02:09:47.0 +0200
> @@ -186,7 +186,8 @@ static int idecs_register(unsigned long
> {
> hw_regs_t hw;
> memset(, 0, sizeof(hw));
> -ide_init_hwif_ports(, io, ctl, NULL);
> +ide_std_init_ports(, io, ctl);
> +hw.io_ports[IDE_DATA_OFFSET] = io + 0x08;
> hw.irq = irq;
> hw.chipset = ide_pci;
> return ide_register_hw_with_fixup(, NULL, ide_undecoded_slave);
You can't do this, at least not exactly this way. io + 0x08 may not
be a mapped IO address; it is only valid when a card is mapped with
one contiguous 16-bit IO window. PCMCIA IDE cards are not necessarily
mapped that way: they may be mapped with one 8-port window and one
1-port window, to match standard IBM PC IDE port locations. In that
case, the registers at 0x08 and 0x09 are not available. The CF spec
may impose more uniformity here than the PCMCIA spec does. I do know
that some IDE cards do end up configured with discontiguous register
allocations when used with ide-cs.c.
-- Dave
-
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: [PATCH] Make ide-cs work for hardware with 8-bit CF-Interface
On Tue, Sep 06, 2005 at 06:47:08PM +0200, Thomas Kleffel (LKML) wrote:
The following patch is against vanilla 2.6.13.
ldiff -uprN a/drivers/ide/legacy/ide-cs.c b/drivers/ide/legacy/ide-cs.c
--- a/drivers/ide/legacy/ide-cs.c 2005-08-08 15:30:35.0 +0200
+++ b/drivers/ide/legacy/ide-cs.c 2005-09-05 02:09:47.0 +0200
@@ -186,7 +186,8 @@ static int idecs_register(unsigned long
{
hw_regs_t hw;
memset(hw, 0, sizeof(hw));
-ide_init_hwif_ports(hw, io, ctl, NULL);
+ide_std_init_ports(hw, io, ctl);
+hw.io_ports[IDE_DATA_OFFSET] = io + 0x08;
hw.irq = irq;
hw.chipset = ide_pci;
return ide_register_hw_with_fixup(hw, NULL, ide_undecoded_slave);
You can't do this, at least not exactly this way. io + 0x08 may not
be a mapped IO address; it is only valid when a card is mapped with
one contiguous 16-bit IO window. PCMCIA IDE cards are not necessarily
mapped that way: they may be mapped with one 8-port window and one
1-port window, to match standard IBM PC IDE port locations. In that
case, the registers at 0x08 and 0x09 are not available. The CF spec
may impose more uniformity here than the PCMCIA spec does. I do know
that some IDE cards do end up configured with discontiguous register
allocations when used with ide-cs.c.
-- Dave
-
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: IRQ problem with PCMCIA
On Sun, Aug 21, 2005 at 03:17:39PM -0700, David Hinds wrote: > > The drivers are working correctly; the problem is with the CF flash > adapter you're using. There are two kinds of CF-to-PCMCIA adapters. > Some are 16-bit PCMCIA cards, which are in most cases limited to a bus > throughput of ~1 MB/sec, regardless of what the CF card is capable > of. There are also 32-bit CF adapter cards, that are much faster, > limited only by the speed of the CF device. Here are two: > > http://www.delkin.com/delkin_products_adapters_cardbus.html > http://www.lexarmedia.com/readers/cf32bit.html One caveat: I'm not sure if CardBus IDE devices are working under Linux?? I'd think they should work with 2.6, but don't actually know that for a fact. -- Dave - 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: IRQ problem with PCMCIA
On Sun, Aug 21, 2005 at 08:43:50PM +0200, Hesse, Christian wrote: > Hello everybody, > > seems like I have a problem with PCMCIA/PCCARD. If I transfer data > to or from a CF card inserted via adapter system waits for > interrupts most of the time: Cpu(s): 21.2% us, 7.9% sy, 0.0% ni, > 0.0% id, 1.7% wa, 69.2% hi, 0.0% si This results in a very > unresponsive system and a transfer rate of up to 1MB/s (my new > camera writes with up to 10MB/s on the card...). The drivers are working correctly; the problem is with the CF flash adapter you're using. There are two kinds of CF-to-PCMCIA adapters. Some are 16-bit PCMCIA cards, which are in most cases limited to a bus throughput of ~1 MB/sec, regardless of what the CF card is capable of. There are also 32-bit CF adapter cards, that are much faster, limited only by the speed of the CF device. Here are two: http://www.delkin.com/delkin_products_adapters_cardbus.html http://www.lexarmedia.com/readers/cf32bit.html -- Dave - 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: IRQ problem with PCMCIA
On Sun, Aug 21, 2005 at 08:43:50PM +0200, Hesse, Christian wrote: Hello everybody, seems like I have a problem with PCMCIA/PCCARD. If I transfer data to or from a CF card inserted via adapter system waits for interrupts most of the time: Cpu(s): 21.2% us, 7.9% sy, 0.0% ni, 0.0% id, 1.7% wa, 69.2% hi, 0.0% si This results in a very unresponsive system and a transfer rate of up to 1MB/s (my new camera writes with up to 10MB/s on the card...). The drivers are working correctly; the problem is with the CF flash adapter you're using. There are two kinds of CF-to-PCMCIA adapters. Some are 16-bit PCMCIA cards, which are in most cases limited to a bus throughput of ~1 MB/sec, regardless of what the CF card is capable of. There are also 32-bit CF adapter cards, that are much faster, limited only by the speed of the CF device. Here are two: http://www.delkin.com/delkin_products_adapters_cardbus.html http://www.lexarmedia.com/readers/cf32bit.html -- Dave - 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: IRQ problem with PCMCIA
On Sun, Aug 21, 2005 at 03:17:39PM -0700, David Hinds wrote: The drivers are working correctly; the problem is with the CF flash adapter you're using. There are two kinds of CF-to-PCMCIA adapters. Some are 16-bit PCMCIA cards, which are in most cases limited to a bus throughput of ~1 MB/sec, regardless of what the CF card is capable of. There are also 32-bit CF adapter cards, that are much faster, limited only by the speed of the CF device. Here are two: http://www.delkin.com/delkin_products_adapters_cardbus.html http://www.lexarmedia.com/readers/cf32bit.html One caveat: I'm not sure if CardBus IDE devices are working under Linux?? I'd think they should work with 2.6, but don't actually know that for a fact. -- Dave - 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: Sandisk Compact Flash
On Wed, Jul 20, 2005 at 12:49:00PM +0530, [EMAIL PROTECTED] wrote: > > Hi David , > > On my controller CF INPACK pin is connected to 3.3v. so Comapct > flash with DMA capabilty will not be supported , i understood this . > but i did not undesrtand why only PIO mode 1 is supported is it , > why not PIO mode 4 , is it a limitation of pcmcia driver , correct > me if i am wrong The 16-bit PCMCIA bus is maxed out at about 1 MB/sec; that's all the bandwidth there is. What your card supports is irrelevant. I'm not sure whether the PCMCIA mode actually corresponds to any of the official PIO modes 0, 1, etc. It is just "slow". -- Dave - 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: Sandisk Compact Flash
On Wed, Jul 20, 2005 at 12:49:00PM +0530, [EMAIL PROTECTED] wrote: Hi David , On my controller CF INPACK pin is connected to 3.3v. so Comapct flash with DMA capabilty will not be supported , i understood this . but i did not undesrtand why only PIO mode 1 is supported is it , why not PIO mode 4 , is it a limitation of pcmcia driver , correct me if i am wrong The 16-bit PCMCIA bus is maxed out at about 1 MB/sec; that's all the bandwidth there is. What your card supports is irrelevant. I'm not sure whether the PCMCIA mode actually corresponds to any of the official PIO modes 0, 1, etc. It is just slow. -- Dave - 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: Sandisk Compact Flash
On Sat, Jul 16, 2005 at 03:04:54AM -0400, Michael Krufky wrote: > I recommend picking up a CF-to-IDE adapter, such as this: > > http://www.acscontrol.com/Index_ACS.asp?Page=/Pages/Products/CompactFlash/IDE_To_CF_Adapter.htm That's fine if you have a spare IDE port, but unlikely if you're using a laptop. Also these do not support hot swapping. -- Dave - 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: Sandisk Compact Flash
On Sat, Jul 16, 2005 at 03:04:54AM -0400, Michael Krufky wrote: I recommend picking up a CF-to-IDE adapter, such as this: http://www.acscontrol.com/Index_ACS.asp?Page=/Pages/Products/CompactFlash/IDE_To_CF_Adapter.htm That's fine if you have a spare IDE port, but unlikely if you're using a laptop. Also these do not support hot swapping. -- Dave - 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: Sandisk Compact Flash
On Wed, Jul 13, 2005 at 07:04:38PM +0530, [EMAIL PROTECTED] wrote: > > I ma newbie to compactflash driver , I am using mpc862 PPC processor > on my custom board having 64mb ram running linuxppc-2.4.18 kernel . > i am using Sandisk Extreme CF 1GB which is 133x high speed, but > found the performance with other kingston 1GB CF with slower speed , > is both same , CF is implemented on pcmcia port , i am not sure what > is the mode set for transfer , Feature set command is used in which > it sets the PIO mode or Multiword DMA transfer mode by specifying > its value in Sector count register , i am not able to understand in > linux kernel ide driver where this is set , is it by default set , > this mode is set or we need to set it , i think we should assign > this value , right now i am not able to trace this in my code. , All Compact Flash cards, in 16-bit PCMCIA card readers, operate in PIO mode 1 (polled IO, no DMA), which means you will get only about 1 MB/sec regardless of the card's claimed tranfer speed. Some cameras also only support this mode; others will run CF cars in "TrueIDE" mode, which is required to use the DMA transfer modes. There are high performance CF card readers that can use TrueIDE mode: both CardBus ones and Firewire ones. For example: http://www.dpreview.com/news/0310/03102103delkincardbustest.asp It sounds like your card reader is one of the slow 16-bit ones. -- Dave - 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: Sandisk Compact Flash
On Wed, Jul 13, 2005 at 07:04:38PM +0530, [EMAIL PROTECTED] wrote: I ma newbie to compactflash driver , I am using mpc862 PPC processor on my custom board having 64mb ram running linuxppc-2.4.18 kernel . i am using Sandisk Extreme CF 1GB which is 133x high speed, but found the performance with other kingston 1GB CF with slower speed , is both same , CF is implemented on pcmcia port , i am not sure what is the mode set for transfer , Feature set command is used in which it sets the PIO mode or Multiword DMA transfer mode by specifying its value in Sector count register , i am not able to understand in linux kernel ide driver where this is set , is it by default set , this mode is set or we need to set it , i think we should assign this value , right now i am not able to trace this in my code. , All Compact Flash cards, in 16-bit PCMCIA card readers, operate in PIO mode 1 (polled IO, no DMA), which means you will get only about 1 MB/sec regardless of the card's claimed tranfer speed. Some cameras also only support this mode; others will run CF cars in TrueIDE mode, which is required to use the DMA transfer modes. There are high performance CF card readers that can use TrueIDE mode: both CardBus ones and Firewire ones. For example: http://www.dpreview.com/news/0310/03102103delkincardbustest.asp It sounds like your card reader is one of the slow 16-bit ones. -- Dave - 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: Why does printk helps PCMCIA card to initialise?
On Mon, 21 Feb 2005, Linus Torvalds wrote:
> On Mon, 21 Feb 2005, Russell King wrote:
> >
> > In cs.c, alloc_io_space(), find the line:
> >
> > if (*base & ~(align-1)) {
> >
> > delete the ~ and rebuild. This may resolve your problem.
>
> Unlikely. The code is too broken for words.
The original code is correct; you are misinterpreting the meaning of
the "align" variable here. PCMCIA cards can request a specific base
IO address, and can also specify how many IO address lines they
decode. The number of decoded lines determines a maximal alignment
restriction for a card; if it only decodes 3 lines, then it should not
reasonably ask for an IO region with more specificity than being on an
8 port boundary. The "align" variable here holds this alignment. The
"oddness" here is that the card is providing conflicting information,
that it needs IO ports at a specific address, but is only decoding 3
address lines (i.e. align=8).
The names of "base" and "align" have the expected meanings when a card
only specifies one or the other. It's only for the case where both
are specified that the meaning is complicated. Then, "base" is more
like an offset into a block that has "align" alignment
Given an "odd" request for a base=0x260 and align=8, the allocator
promotes this to align=0x400, and would allow addresses 0x260, 0x660,
0xa60, 0xe60, etc, subject to restrictions in /etc/pcmcia/config.opts.
The real problem here is that all the IO address ranges the card
claims to support were unavailable. I'd first try adding:
include port 0x0600-0x07ff
to /etc/pcmcia/config.opts to give the allocator more flexibility in
choosing port ranges.
-- Dave
-
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: Why does printk helps PCMCIA card to initialise?
On Mon, 21 Feb 2005, Linus Torvalds wrote:
On Mon, 21 Feb 2005, Russell King wrote:
In cs.c, alloc_io_space(), find the line:
if (*base ~(align-1)) {
delete the ~ and rebuild. This may resolve your problem.
Unlikely. The code is too broken for words.
The original code is correct; you are misinterpreting the meaning of
the align variable here. PCMCIA cards can request a specific base
IO address, and can also specify how many IO address lines they
decode. The number of decoded lines determines a maximal alignment
restriction for a card; if it only decodes 3 lines, then it should not
reasonably ask for an IO region with more specificity than being on an
8 port boundary. The align variable here holds this alignment. The
oddness here is that the card is providing conflicting information,
that it needs IO ports at a specific address, but is only decoding 3
address lines (i.e. align=8).
The names of base and align have the expected meanings when a card
only specifies one or the other. It's only for the case where both
are specified that the meaning is complicated. Then, base is more
like an offset into a block that has align alignment
Given an odd request for a base=0x260 and align=8, the allocator
promotes this to align=0x400, and would allow addresses 0x260, 0x660,
0xa60, 0xe60, etc, subject to restrictions in /etc/pcmcia/config.opts.
The real problem here is that all the IO address ranges the card
claims to support were unavailable. I'd first try adding:
include port 0x0600-0x07ff
to /etc/pcmcia/config.opts to give the allocator more flexibility in
choosing port ranges.
-- Dave
-
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: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)
On Wed, Jun 27, 2001 at 12:29:47AM -0700, Andre Hedrick wrote: > > I can not help if you have a device that not compliant to the rules. > ATA-2 is OBSOLETED thus we forced (the NCITS Standards Body) the CFA > people to move to ATA-4 or ATA-5. > > That device is enabling with its ablity to assert its device->host > interrupt regardless of the HOST...that is a bad device. > > Send me the manufacturer and I will tear them apart for making a > non-compliant device. Then figure out a way to de-assert the like > regardless if it exists without hang the rest of the driver. I don't understand the ATA spec issue, but *every* PCMCIA ATA device I know of (including all SmartMedia, CompactFlash, etc) suffers from this problem. It is not an isolated manufacturer. As far as I know, the IDE driver has always had the problem that it may trigger interrupts before it installs a handler. Are you saying that is only true of pre-ATA-4 devices, or only devices that deviate from the spec? -- Dave - 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: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)
On Wed, Jun 27, 2001 at 12:29:47AM -0700, Andre Hedrick wrote: I can not help if you have a device that not compliant to the rules. ATA-2 is OBSOLETED thus we forced (the NCITS Standards Body) the CFA people to move to ATA-4 or ATA-5. That device is enabling with its ablity to assert its device-host interrupt regardless of the HOST...that is a bad device. Send me the manufacturer and I will tear them apart for making a non-compliant device. Then figure out a way to de-assert the like regardless if it exists without hang the rest of the driver. I don't understand the ATA spec issue, but *every* PCMCIA ATA device I know of (including all SmartMedia, CompactFlash, etc) suffers from this problem. It is not an isolated manufacturer. As far as I know, the IDE driver has always had the problem that it may trigger interrupts before it installs a handler. Are you saying that is only true of pre-ATA-4 devices, or only devices that deviate from the spec? -- Dave - 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: [PATCH] rsrc_mgr.c - null ptr fix for 2.4.4
On Thu, May 24, 2001 at 12:35:17AM -0700, Praveen Srinivasan wrote:
> Hi,
> This fixes an unchecked ptr bug in the resource manager code for the PCMCIA
> driver (rsrc_mgr.c).
I would instead suggest:
--- ../linux/./drivers/pcmcia/rsrc_mgr.cTue Mar 6 19:28:32 2001
+++ ./drivers/pcmcia/rsrc_mgr.c Mon May 7 22:09:09 2001
@@ -189,6 +189,12 @@
/* First, what does a floating port look like? */
b = kmalloc(256, GFP_KERNEL);
+
+if(b == NULL){
+ printk(" kmalloc failed!\n");
+ return;
+}
+
memset(b, 0, 256);
for (i = base, most = 0; i < base+num; i += 8) {
if (check_io_resource(i, 8))
-
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: [PATCH] rsrc_mgr.c - null ptr fix for 2.4.4
On Thu, May 24, 2001 at 12:35:17AM -0700, Praveen Srinivasan wrote:
Hi,
This fixes an unchecked ptr bug in the resource manager code for the PCMCIA
driver (rsrc_mgr.c).
I would instead suggest:
--- ../linux/./drivers/pcmcia/rsrc_mgr.cTue Mar 6 19:28:32 2001
+++ ./drivers/pcmcia/rsrc_mgr.c Mon May 7 22:09:09 2001
@@ -189,6 +189,12 @@
/* First, what does a floating port look like? */
b = kmalloc(256, GFP_KERNEL);
+
+if(b == NULL){
+ printk( kmalloc failed!\n);
+ return;
+}
+
memset(b, 0, 256);
for (i = base, most = 0; i base+num; i += 8) {
if (check_io_resource(i, 8))
-
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: Cardbus conflicts...
> exclude port 0x2f8-0x2ff This exclusion is to block out the port range used by the IBM MWave DSP chip; this is your modem, not your sound card. Whatever your sound problem is, I don't think it is related to this specific item. I would recommend going to the linux-laptops site and checking out the pages devoted to the IBM TP 600E; it is likely that for a common model like this, people have put together detailed recipies for how to get sound, pcmcia, etc working. As for your specific questions, there are several better ways of handling this sort of thing automatically. If you build the PCMCIA drives with "PnP BIOS support" enabled, they will discover this and any other resource conflicts automatically. I think this option is also available in the newest 2.4.X kernels. PnP BIOS support is not enabled by default because there are compatibility problems on some systems. In the longer term ACPI support should also be able to handle this sort of conflict detection but I don't think it is sufficiently mature at this stage. -- Dave Hinds - 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: Cardbus conflicts...
exclude port 0x2f8-0x2ff This exclusion is to block out the port range used by the IBM MWave DSP chip; this is your modem, not your sound card. Whatever your sound problem is, I don't think it is related to this specific item. I would recommend going to the linux-laptops site and checking out the pages devoted to the IBM TP 600E; it is likely that for a common model like this, people have put together detailed recipies for how to get sound, pcmcia, etc working. As for your specific questions, there are several better ways of handling this sort of thing automatically. If you build the PCMCIA drives with PnP BIOS support enabled, they will discover this and any other resource conflicts automatically. I think this option is also available in the newest 2.4.X kernels. PnP BIOS support is not enabled by default because there are compatibility problems on some systems. In the longer term ACPI support should also be able to handle this sort of conflict detection but I don't think it is sufficiently mature at this stage. -- Dave Hinds - 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.2.19 aic7xxx breaks pcmcia
On Mon, Mar 26, 2001 at 05:14:13PM +1000, Keith Owens wrote: > 2.2.19 Documentation/Changes says pcmcia-cs 3.0.14. I am using 3.1.21 > and it breaks if you compile the kernel with scsi support then try to > compile pcmcia. clients/apa1480_stub.c in 3.1.21 has > #include <../drivers/scsi/aic7xxx.h> > but in 2.2.19 that file is drivers/scsi/aic7xxx/aic7xxx.h. You need at > least pcmcia-cs 3.1.25 for kernel 2.2.19 with scsi support. Correct. It is not just the header file that is at issue, though; the whole build procedure for the aic7xxx driver changed. > In the kernel and associated utilities I want to remove lines like > #include <../drivers/scsi/aic7xxx.h> > and replace them with > #include "aic7xxx.h" > with the Makefile specifying -I $(TOPDIR)/drivers/scsi (2.2.18) or -I > $(TOPDIR)/drivers/scsi/aic7xxx (2.2.19). Hard coding long path names > for #include is bad, especially when they contain '..'. It stops > kernel developers moving code around and makes it difficult to do some > of the things I plan for the 2.5 Makefile rewrite. David, how easy > would it be to change pcmcia to this style of include? It would not be too hard to do what you suggest, but would make for very long CPPFLAGS. Which is inconvenient if you like to actually see what's going on when you do a build. I think more of the include files at issue should probably be in the kernel include tree, and not hidden in the driver tree. That would make the issue moot. What are the things you're planning that will cause trouble? I would also think it would be less of an issue with 2.5 if there is some hope that in-kernel PCMCIA is going to be the standard. -- Dave - 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.2.19 aic7xxx breaks pcmcia
On Mon, Mar 26, 2001 at 05:14:13PM +1000, Keith Owens wrote: 2.2.19 Documentation/Changes says pcmcia-cs 3.0.14. I am using 3.1.21 and it breaks if you compile the kernel with scsi support then try to compile pcmcia. clients/apa1480_stub.c in 3.1.21 has #include ../drivers/scsi/aic7xxx.h but in 2.2.19 that file is drivers/scsi/aic7xxx/aic7xxx.h. You need at least pcmcia-cs 3.1.25 for kernel 2.2.19 with scsi support. Correct. It is not just the header file that is at issue, though; the whole build procedure for the aic7xxx driver changed. In the kernel and associated utilities I want to remove lines like #include ../drivers/scsi/aic7xxx.h and replace them with #include "aic7xxx.h" with the Makefile specifying -I $(TOPDIR)/drivers/scsi (2.2.18) or -I $(TOPDIR)/drivers/scsi/aic7xxx (2.2.19). Hard coding long path names for #include is bad, especially when they contain '..'. It stops kernel developers moving code around and makes it difficult to do some of the things I plan for the 2.5 Makefile rewrite. David, how easy would it be to change pcmcia to this style of include? It would not be too hard to do what you suggest, but would make for very long CPPFLAGS. Which is inconvenient if you like to actually see what's going on when you do a build. I think more of the include files at issue should probably be in the kernel include tree, and not hidden in the driver tree. That would make the issue moot. What are the things you're planning that will cause trouble? I would also think it would be less of an issue with 2.5 if there is some hope that in-kernel PCMCIA is going to be the standard. -- Dave - 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/
Bug in cardbus initialization, or am I missing something?
In drivers/pcmcia/cardbus.c in cb_alloc(), PCI_INTERRUPT_LINE and dev->irq are not filled in until after calling pci_enable_device(). The result is a cryptic message like: > PCI: No IRQ known for interrupt pin A of device 01:00.0. Please try using >pci=biosirq. Unless there is a less obvious reason for the ordering, I suggest the following one-liner. -- Dave Hinds --- cardbus.c.orig Fri Mar 2 09:49:46 2001 +++ cardbus.c Fri Mar 2 09:50:28 2001 @@ -288,7 +288,6 @@ if (res->flags) pci_assign_resource(dev, r); } - pci_enable_device(dev); /* XXX check return */ /* Does this function have an interrupt at all? */ pci_readb(dev, PCI_INTERRUPT_PIN, _pin); @@ -297,6 +296,7 @@ pci_writeb(dev, PCI_INTERRUPT_LINE, irq); } + pci_enable_device(dev); /* XXX check return */ pci_insert_device(dev, bus); } - 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/
Bug in cardbus initialization, or am I missing something?
In drivers/pcmcia/cardbus.c in cb_alloc(), PCI_INTERRUPT_LINE and dev-irq are not filled in until after calling pci_enable_device(). The result is a cryptic message like: PCI: No IRQ known for interrupt pin A of device 01:00.0. Please try using pci=biosirq. Unless there is a less obvious reason for the ordering, I suggest the following one-liner. -- Dave Hinds --- cardbus.c.orig Fri Mar 2 09:49:46 2001 +++ cardbus.c Fri Mar 2 09:50:28 2001 @@ -288,7 +288,6 @@ if (res-flags) pci_assign_resource(dev, r); } - pci_enable_device(dev); /* XXX check return */ /* Does this function have an interrupt at all? */ pci_readb(dev, PCI_INTERRUPT_PIN, irq_pin); @@ -297,6 +296,7 @@ pci_writeb(dev, PCI_INTERRUPT_LINE, irq); } + pci_enable_device(dev); /* XXX check return */ pci_insert_device(dev, bus); } - 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: [PATCH] network driver updates
On Thu, Feb 15, 2001 at 10:49:22PM +1100, Andrew Morton wrote: > > Now, the thing I don't understand about David's design is the > final one. What 3c575_cb does is: > > CONFIG_HOTPLUG=y, MODULE=true > If the hardware isn't there, register the driver and > hang around. > > Why? Merely that I was trying to disassociate the concepts of module loading and device probing, and I thought it was most consistent to then allow people to load modules whenever they want, whether or not a device was present. > BTW: How come CONFIG_PCMCIA requires CONFIG_HOTPLUG? Doesn't > it make sense to be able to have glued-in Cardbus devices? I suppose it makes sense but I don't know if it is something worth the trouble of supporting. -- Dave - 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: [PATCH] network driver updates
On Thu, Feb 15, 2001 at 10:49:22PM +1100, Andrew Morton wrote: Now, the thing I don't understand about David's design is the final one. What 3c575_cb does is: CONFIG_HOTPLUG=y, MODULE=true If the hardware isn't there, register the driver and hang around. Why? Merely that I was trying to disassociate the concepts of module loading and device probing, and I thought it was most consistent to then allow people to load modules whenever they want, whether or not a device was present. BTW: How come CONFIG_PCMCIA requires CONFIG_HOTPLUG? Doesn't it make sense to be able to have glued-in Cardbus devices? I suppose it makes sense but I don't know if it is something worth the trouble of supporting. -- Dave - 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: [PATCH] network driver updates
On Thu, Feb 15, 2001 at 12:33:43AM +1100, Andrew Morton wrote: > > > * something is wrong in the vortex initialization: I don't have such a > > card, but the driver didn't return an error message on insmod. I'm not > > sure if my fix is correct. > > That was intentional - dhinds suggested that if the hardware > isn't present the driver should float about in memory anyway. Say the driver is linked into the kernel. Hot plug drivers should not all complain about not finding their hardware. -- Dave - 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: [PATCH] network driver updates
On Thu, Feb 15, 2001 at 12:33:43AM +1100, Andrew Morton wrote: * something is wrong in the vortex initialization: I don't have such a card, but the driver didn't return an error message on insmod. I'm not sure if my fix is correct. That was intentional - dhinds suggested that if the hardware isn't present the driver should float about in memory anyway. Say the driver is linked into the kernel. Hot plug drivers should not all complain about not finding their hardware. -- Dave - 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: xirc2ps_cs driver timeouts/errors
On Fri, Feb 02, 2001 at 11:54:31PM -0500, [EMAIL PROTECTED] wrote: > > Each time I get a transmit timeout, or UDP: short packet error, > networking on my laptop seems to go down. Reinsertion of the > card temporarily fixes it, and if I leave it long enough it > also fixes itself. Does the same happen with a 2.2 kernel and the 3.1.24 PCMCIA drivers? There is a bug fix in the 3.1.24 xirc2ps_cs driver that hasn't been merged into the kernel tree yet. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: xirc2ps_cs driver timeouts/errors
On Fri, Feb 02, 2001 at 11:54:31PM -0500, [EMAIL PROTECTED] wrote: Each time I get a transmit timeout, or UDP: short packet error, networking on my laptop seems to go down. Reinsertion of the card temporarily fixes it, and if I leave it long enough it also fixes itself. Does the same happen with a 2.2 kernel and the 3.1.24 PCMCIA drivers? There is a bug fix in the 3.1.24 xirc2ps_cs driver that hasn't been merged into the kernel tree yet. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] klogd busy loop on zero byte (output from 3c59x driver)
On Thu, Jan 11, 2001 at 11:03:31PM +1100, Andrew Morton wrote: > > Yep. %02x%02x it now is. > > The code in question was snitched from pcmcia-cs's 3c575_cb.c, and > I assume David would have heard if it was busting klogd. Maybe > there's a klogd version problem, or maybe your NIC's EEPROM is hosed? I haven't heard of it before: I've never seen a card claim to have 0's for its ascii product code. What card is it, exactly? -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 Patch for 3c575
On Thu, Jan 11, 2001 at 10:55:38PM +1100, Andrew Morton wrote: > > The other problem is that in 2.4 cardmgr isn't told the > name of the interface which was bound to the newly-inserted NIC. > I don't know why more people aren't getting bitten by this > with pcmcia-cs+2.4. 2.4 cardmgr should be fixed to not even look for a device name for the NIC, since now this is /sbin/hotplug's job (though I'm not sure it is ready for that responsibility at this point). -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 Patch for 3c575
On Thu, Jan 11, 2001 at 10:55:38PM +1100, Andrew Morton wrote: The other problem is that in 2.4 cardmgr isn't told the name of the interface which was bound to the newly-inserted NIC. I don't know why more people aren't getting bitten by this with pcmcia-cs+2.4. 2.4 cardmgr should be fixed to not even look for a device name for the NIC, since now this is /sbin/hotplug's job (though I'm not sure it is ready for that responsibility at this point). -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] klogd busy loop on zero byte (output from 3c59x driver)
On Thu, Jan 11, 2001 at 11:03:31PM +1100, Andrew Morton wrote: Yep. %02x%02x it now is. The code in question was snitched from pcmcia-cs's 3c575_cb.c, and I assume David would have heard if it was busting klogd. Maybe there's a klogd version problem, or maybe your NIC's EEPROM is hosed? I haven't heard of it before: I've never seen a card claim to have 0's for its ascii product code. What card is it, exactly? -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 Patch for 3c575
On Wed, Jan 10, 2001 at 11:21:58PM -0800, Miles Lane wrote: > > There are at least two things that need to happen. ... I think you're not clear on what PCMCIA support is in the 2.4 kernel tree. The pcnet_cs driver has been in the kernel tree as long as anything else. Most PCMCIA drivers are already in the kernel tree; the ones that are not are: the memory card drivers (rarely used now), parport_cs, and wvlan_cs. The hot plug PCI drivers (3c59x, tulip, epic100) subsume the 3c575_cb, tulip_cb, and epic_cb drivers completely. > For the case where drivers don't exist yet, > the /etc/pcmcia/config* files could be migrated > into the kernel tree, so that when a kernel is > installed that is configured to use the kernel > drivers instead of pcmcia-cs drivers, then > install the modified /etc/pcmcia/config* files. I don't like this idea one bit; multiple sets of config files for different kernel versions is not workable. People want to be able to boot different kernel releases. I want a way for cardmgr to figure out on the fly, based on some feedback from the PCMCIA modules, what the right thing to do is. > This seems kind of heinous. But, these > configuration files sometimes get tweaked for > a particular machine's hardware configuration, > so it's important not to lose them. /etc/pcmcia/config should never be tweaked for anything. That's what the config.opts file is for. > I should note that I once before I modified my /etc/pcmcia/config > file so that cardmgr loaded 3c59x for my 3c575 card. I got some > errors during the card detection phase and I never got "ifup eth0" > to run automatically when I inserted the card. Getting "ifup eth0" to run when you insert a CardBus card in the new 2.4 scheme is going to be an issue with the /sbin/hotplug script, and out of the PCMCIA subsystem's control. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 Patch for 3c575
On Wed, Jan 10, 2001 at 06:56:22PM -0800, Miles Lane wrote: > > There's one other annoyance: > > The config files for pcmcia-cs expect the 3c575_cb driver, > so I either have to hack the configuration files or load > the 3c59x driver by hand. Yes, I'm not sure how to best communicate the fact that 3c59x should be used to cardmgr. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: your mail
On Wed, Jan 10, 2001 at 04:24:21PM -0200, Thiago Rondon wrote: > > Check kmalloc(). > > -Thiago Rondon > > --- linux-2.4.0-ac5/drivers/pcmcia/ds.c Sat Sep 2 04:13:49 2000 > +++ linux-2.4.0-ac5.maluco/drivers/pcmcia/ds.cWed Jan 10 16:20:53 2001 > @@ -414,6 +414,8 @@ > /* Add binding to list for this socket */ > driver->use_count++; > b = kmalloc(sizeof(socket_bind_t), GFP_KERNEL); > +if (!b) > + return -ENOMEM; > b->driver = driver; > b->function = bind_info->function; > b->instance = NULL; > As with the other kmalloc patch, this is also broken; things have been done that need to be un-done, and you can't just exit the function here. I'll come up with a better fix. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/pcmcia/cs.c
On Wed, Jan 10, 2001 at 04:23:14PM -0200, Thiago Rondon wrote: > > Check kmalloc(). > > -Thiago Rondon > > --- linux-2.4.0-ac5/drivers/pcmcia/cs.c Fri Dec 29 20:35:47 2000 > +++ linux-2.4.0-ac5.maluco/drivers/pcmcia/cs.cWed Jan 10 16:18:11 2001 > @@ -1458,6 +1458,8 @@ > s->functions = 1; > s->config = kmalloc(sizeof(config_t) * s->functions, > GFP_KERNEL); > + if (!s->config) > + return CS_OUT_OF_RESOURCE; > memset(s->config, 0, sizeof(config_t) * s->functions); > } This is not a satisfactory fix; if that kmalloc ever fails, you also need to back out various things that were done higher up. You can't bail out at this spot. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/pcmcia/cs.c
On Wed, Jan 10, 2001 at 04:23:14PM -0200, Thiago Rondon wrote: Check kmalloc(). -Thiago Rondon --- linux-2.4.0-ac5/drivers/pcmcia/cs.c Fri Dec 29 20:35:47 2000 +++ linux-2.4.0-ac5.maluco/drivers/pcmcia/cs.cWed Jan 10 16:18:11 2001 @@ -1458,6 +1458,8 @@ s-functions = 1; s-config = kmalloc(sizeof(config_t) * s-functions, GFP_KERNEL); + if (!s-config) + return CS_OUT_OF_RESOURCE; memset(s-config, 0, sizeof(config_t) * s-functions); } This is not a satisfactory fix; if that kmalloc ever fails, you also need to back out various things that were done higher up. You can't bail out at this spot. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: your mail
On Wed, Jan 10, 2001 at 04:24:21PM -0200, Thiago Rondon wrote: Check kmalloc(). -Thiago Rondon --- linux-2.4.0-ac5/drivers/pcmcia/ds.c Sat Sep 2 04:13:49 2000 +++ linux-2.4.0-ac5.maluco/drivers/pcmcia/ds.cWed Jan 10 16:20:53 2001 @@ -414,6 +414,8 @@ /* Add binding to list for this socket */ driver-use_count++; b = kmalloc(sizeof(socket_bind_t), GFP_KERNEL); +if (!b) + return -ENOMEM; b-driver = driver; b-function = bind_info-function; b-instance = NULL; As with the other kmalloc patch, this is also broken; things have been done that need to be un-done, and you can't just exit the function here. I'll come up with a better fix. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 Patch for 3c575
On Wed, Jan 10, 2001 at 11:21:58PM -0800, Miles Lane wrote: There are at least two things that need to happen. ... I think you're not clear on what PCMCIA support is in the 2.4 kernel tree. The pcnet_cs driver has been in the kernel tree as long as anything else. Most PCMCIA drivers are already in the kernel tree; the ones that are not are: the memory card drivers (rarely used now), parport_cs, and wvlan_cs. The hot plug PCI drivers (3c59x, tulip, epic100) subsume the 3c575_cb, tulip_cb, and epic_cb drivers completely. For the case where drivers don't exist yet, the /etc/pcmcia/config* files could be migrated into the kernel tree, so that when a kernel is installed that is configured to use the kernel drivers instead of pcmcia-cs drivers, then install the modified /etc/pcmcia/config* files. I don't like this idea one bit; multiple sets of config files for different kernel versions is not workable. People want to be able to boot different kernel releases. I want a way for cardmgr to figure out on the fly, based on some feedback from the PCMCIA modules, what the right thing to do is. This seems kind of heinous. But, these configuration files sometimes get tweaked for a particular machine's hardware configuration, so it's important not to lose them. /etc/pcmcia/config should never be tweaked for anything. That's what the config.opts file is for. I should note that I once before I modified my /etc/pcmcia/config file so that cardmgr loaded 3c59x for my 3c575 card. I got some errors during the card detection phase and I never got "ifup eth0" to run automatically when I inserted the card. Getting "ifup eth0" to run when you insert a CardBus card in the new 2.4 scheme is going to be an issue with the /sbin/hotplug script, and out of the PCMCIA subsystem's control. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Are PCI add-on Cardbus Readers supported by the 2.4.0 kernel?
On Sun, Jan 07, 2001 at 11:43:40PM -0800, Miles Lane wrote: > > The specs mention Win98 support. Hopefully that doesn't > mean this is some sort of "WinCardbus Reader" heap of junk. > > Has anyone gotten this board or a similar one from > another manufacturer to work? Desktop cardbus readers generally all work fine under Linux. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Are PCI add-on Cardbus Readers supported by the 2.4.0 kernel?
On Sun, Jan 07, 2001 at 11:43:40PM -0800, Miles Lane wrote: The specs mention Win98 support. Hopefully that doesn't mean this is some sort of "WinCardbus Reader" heap of junk. Has anyone gotten this board or a similar one from another manufacturer to work? Desktop cardbus readers generally all work fine under Linux. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA modem (v.90 X2) not working with 2.4.0-test12 PCMCIA services
On Wed, Dec 20, 2000 at 12:10:41PM -0700, Jeff V. Merkey wrote: > On Tue, Dec 19, 2000 at 05:05:16PM -0700, Jeff V. Merkey wrote: > > Do you think there's a solution for this problem. Sorry for bothering > you again. I'm available if you need some help retesting and fixes. I do not have a solution. I have a few reports of tx timeout problems that I have so far been unable to reproduce. It is a sufficiently nonspecific outcome that I don't have any good ideas for how to track down the problem; all my attempts so far have come up blank. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA modem (v.90 X2) not working with 2.4.0-test12 PCMCIA services
On Wed, Dec 20, 2000 at 12:10:41PM -0700, Jeff V. Merkey wrote: On Tue, Dec 19, 2000 at 05:05:16PM -0700, Jeff V. Merkey wrote: Do you think there's a solution for this problem. Sorry for bothering you again. I'm available if you need some help retesting and fixes. I do not have a solution. I have a few reports of tx timeout problems that I have so far been unable to reproduce. It is a sufficiently nonspecific outcome that I don't have any good ideas for how to track down the problem; all my attempts so far have come up blank. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA modem (v.90 X2) not working with 2.4.0-test12 PCMCIA services
On Tue, Dec 19, 2000 at 03:41:29PM -0700, Jeff V. Merkey wrote: > > On a related topic, the 3c575_cb driver on an IBM Thinkpad 765D is getting > tx errors on the 2.2.18 kernel with PCMCIA services 3.1.22. > > Card is a 3Com 3CCFE575BT Cyclone Cardbus Adapter. > > Error is: > > eth0: transmit timed out, tx_status 00 status e000. > diagnostics net 0cc2 media a800 dma 00a0 What host bridge is in the 765D? Is it perhaps a TI 1131 rev 1, or something else? Also, try adding: module "3c575_cb" opts "down_poll_rate=0" to /etc/pcmcia/config.opts and see if that makes any difference. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA modem (v.90 X2) not working with 2.4.0-test12 PCMCIA services
On Sat, Dec 16, 2000 at 05:52:30PM -0800, Miles Lane wrote: > > Socket 1: > product info: "PCMCIA", "V.90 Communications Device ", "", "" > manfid: 0x018a, 0x0001 Now I have another report of this card not working, under 2.2. Perhaps it is a Winmodem? -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA modem (v.90 X2) not working with 2.4.0-test12 PCMCIA services
On Sat, Dec 16, 2000 at 05:52:30PM -0800, Miles Lane wrote: Socket 1: product info: "PCMCIA", "V.90 Communications Device ", "", "" manfid: 0x018a, 0x0001 Now I have another report of this card not working, under 2.2. Perhaps it is a Winmodem? -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA modem (v.90 X2) not working with 2.4.0-test12 PCMCIA services
On Tue, Dec 19, 2000 at 03:41:29PM -0700, Jeff V. Merkey wrote: On a related topic, the 3c575_cb driver on an IBM Thinkpad 765D is getting tx errors on the 2.2.18 kernel with PCMCIA services 3.1.22. Card is a 3Com 3CCFE575BT Cyclone Cardbus Adapter. Error is: eth0: transmit timed out, tx_status 00 status e000. diagnostics net 0cc2 media a800 dma 00a0 What host bridge is in the 765D? Is it perhaps a TI 1131 rev 1, or something else? Also, try adding: module "3c575_cb" opts "down_poll_rate=0" to /etc/pcmcia/config.opts and see if that makes any difference. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA modem (v.90 X2) not working with 2.4.0-test12 PCMCIA services
On Sat, Dec 16, 2000 at 05:52:30PM -0800, Miles Lane wrote: > register_serial(): autoconfig failed > serial_cs: register_serial() at 0x03e8, irq 3 failed. > > "cardctl ident" shows: > > Socket 1: > product info: "PCMCIA", "V.90 Communications Device ", "", "" > manfid: 0x018a, 0x0001 Have you tried, or could you try, using this card under a 2.2 kernel for comparison? Also, the first thing I'd try would be to exclude the irq 3, port 0x3e8-0x3ef resources in /etc/pcmcia/config.opts to verify that it is not a resource conflict of some sort. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA modem (v.90 X2) not working with 2.4.0-test12 PCMCIA services
On Sat, Dec 16, 2000 at 05:52:30PM -0800, Miles Lane wrote: register_serial(): autoconfig failed serial_cs: register_serial() at 0x03e8, irq 3 failed. "cardctl ident" shows: Socket 1: product info: "PCMCIA", "V.90 Communications Device ", "", "" manfid: 0x018a, 0x0001 Have you tried, or could you try, using this card under a 2.2 kernel for comparison? Also, the first thing I'd try would be to exclude the irq 3, port 0x3e8-0x3ef resources in /etc/pcmcia/config.opts to verify that it is not a resource conflict of some sort. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial cardbus code.... for testing, please.....
On Sat, Dec 09, 2000 at 12:41:24AM -0500, Theodore Y. Ts'o wrote: > > There was is usual with these sorts of things, multiple problems I was > dealing with. The first was that I was trying to use cardmgr, and my > pcmcia config file was still trying to load epic_cb. Oops. David, you > might want to mention of this caveat in the README-2.4 file in the > pcmcia-cs package. I'm aware of the problem but I'm not actually sure what to present as the appropriate solution yet; in the new scheme, cardmgr should just ignore these cards and not load any module at all (as /sbin/hotplug should do that). But I haven't decided how cardmgr will deduce that. By the way, in my hands, PCMCIA serial cards do work ok with the 2.4 PCMCIA modules as of test12-pre7. So I'm not sure what's going on in Ted's situation, if the non-kernel PCMCIA is working: there should not be much different for 16-bit cards. I do seem to have some new problems with Cardbus cards that I wasn't having with earlier 2.4 releases but I haven't made any attempt to figure that out yet. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial cardbus code.... for testing, please.....
On Sat, Dec 09, 2000 at 12:41:24AM -0500, Theodore Y. Ts'o wrote: There was is usual with these sorts of things, multiple problems I was dealing with. The first was that I was trying to use cardmgr, and my pcmcia config file was still trying to load epic_cb. Oops. David, you might want to mention of this caveat in the README-2.4 file in the pcmcia-cs package. I'm aware of the problem but I'm not actually sure what to present as the appropriate solution yet; in the new scheme, cardmgr should just ignore these cards and not load any module at all (as /sbin/hotplug should do that). But I haven't decided how cardmgr will deduce that. By the way, in my hands, PCMCIA serial cards do work ok with the 2.4 PCMCIA modules as of test12-pre7. So I'm not sure what's going on in Ted's situation, if the non-kernel PCMCIA is working: there should not be much different for 16-bit cards. I do seem to have some new problems with Cardbus cards that I wasn't having with earlier 2.4 releases but I haven't made any attempt to figure that out yet. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial cardbus code.... for testing, please.....
On Fri, Dec 08, 2000 at 01:27:51PM -0800, Linus Torvalds wrote: > > (Of course, I use tulip instead of epic100, so maybe there's an epic > driver bug, but it's definitely hotplug-aware). There could be a problem in the epic driver; I've never had a card that uses this driver and have only limited user feedback. Some people say it works, others not... but I have not even been able to tell if the problems are actually in the epic driver or elsewhere. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial cardbus code.... for testing, please.....
On Fri, Dec 08, 2000 at 01:27:51PM -0800, Linus Torvalds wrote: (Of course, I use tulip instead of epic100, so maybe there's an epic driver bug, but it's definitely hotplug-aware). There could be a problem in the epic driver; I've never had a card that uses this driver and have only limited user feedback. Some people say it works, others not... but I have not even been able to tell if the problems are actually in the epic driver or elsewhere. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
> What information is lost? Unless you're working on a really strange > machine which does not zero bss, the following means the same from the > codes point of view: > > static int foo = 0; > static int foo; I think the argument is that "static int foo;" implies you don't actually care how "foo" is initialized, but adding the "= 0" is revealing that the code actually relies on the default value. The code is obviously equivalent. It is a readability issue, not an issue of what the code does. I would contend that it is a compiler bug in gcc if it treats the two statements differently, since they are trivially equivalent. I guess that it has been decided that linux kernel coding style dictates no zero initializers, so that's that. Personally, I prefer symmetry: if I have a list of static variables initialized to various things, I don't have to use a different form for ones that are zero initialized. Did the savings really work out to be measured in kb's of space? I would have expected compression to eliminate most of the savings. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of static foo = 0 from drivers/ide (test11)
What information is lost? Unless you're working on a really strange machine which does not zero bss, the following means the same from the codes point of view: static int foo = 0; static int foo; I think the argument is that "static int foo;" implies you don't actually care how "foo" is initialized, but adding the "= 0" is revealing that the code actually relies on the default value. The code is obviously equivalent. It is a readability issue, not an issue of what the code does. I would contend that it is a compiler bug in gcc if it treats the two statements differently, since they are trivially equivalent. I guess that it has been decided that linux kernel coding style dictates no zero initializers, so that's that. Personally, I prefer symmetry: if I have a list of static variables initialized to various things, I don't have to use a different form for ones that are zero initialized. Did the savings really work out to be measured in kb's of space? I would have expected compression to eliminate most of the savings. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Why not PCMCIA built-in and yenta/i82365 as modules
On Tue, Nov 21, 2000 at 10:44:30PM -0300, Horst von Brand wrote: > > If you have a laptop with an assortment of cards, you might want to have > the generic builtin and the cards themselves as modules. No, that's ok, and that's supported with the current config scripts. The original question was about having the generic code built in, but the socket driver (yenta) as a module. The socket driver needs to be loaded regardless of what cards you're using. So I think having one in the kernel and the other as a module is of limited utility. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Why not PCMCIA built-in and yenta/i82365 as modules
On Tue, Nov 21, 2000 at 08:10:38PM -0500, Albert D. Cahalan wrote: > > Hmmm, I'm not the only one who doesn't like modules depending > on other modules. I suppose this is part paranoia about extra > complexity leading to problems, and part desire to avoid the > module overhead for common code that will most likely get used. Since the core PCMCIA code and the socket driver are equally essential to do anything useful with PCMCIA, the only reasonable argument I could see for it would be if you are using one kernel on several systems, all of which use PCMCIA, but which need different socket drivers. So you would save... oh... perhaps 2K by having the PCMCIA shared code in the kernel. In any case, I don't think it would require much more than modifying the Config.in for the PCMCIA drivers to support this. My own paranoia would be that you would be adding a bunch of rarely used permutations of config options, that would rarely be tested. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Why not PCMCIA built-in and yenta/i82365 as modules
On Tue, Nov 21, 2000 at 11:34:45PM +0100, Tobias Ringstrom wrote: > The subject says it all. Is there any particular (technical) reason why I > must have both the generic pcmcia code and the controller support > built-in, or build all of them as modules? Is there a technical reason for this? Not that I know of; but then I also cannot think of a good reason for wanting, say, the generic code built in but the controller support as modules. I do see reasonable arguments for all-builtin or all-modules. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Why not PCMCIA built-in and yenta/i82365 as modules
On Tue, Nov 21, 2000 at 11:34:45PM +0100, Tobias Ringstrom wrote: The subject says it all. Is there any particular (technical) reason why I must have both the generic pcmcia code and the controller support built-in, or build all of them as modules? Is there a technical reason for this? Not that I know of; but then I also cannot think of a good reason for wanting, say, the generic code built in but the controller support as modules. I do see reasonable arguments for all-builtin or all-modules. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Why not PCMCIA built-in and yenta/i82365 as modules
On Tue, Nov 21, 2000 at 08:10:38PM -0500, Albert D. Cahalan wrote: Hmmm, I'm not the only one who doesn't like modules depending on other modules. I suppose this is part paranoia about extra complexity leading to problems, and part desire to avoid the module overhead for common code that will most likely get used. Since the core PCMCIA code and the socket driver are equally essential to do anything useful with PCMCIA, the only reasonable argument I could see for it would be if you are using one kernel on several systems, all of which use PCMCIA, but which need different socket drivers. So you would save... oh... perhaps 2K by having the PCMCIA shared code in the kernel. In any case, I don't think it would require much more than modifying the Config.in for the PCMCIA drivers to support this. My own paranoia would be that you would be adding a bunch of rarely used permutations of config options, that would rarely be tested. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pcmcia event thread. (fwd)
On Sat, Nov 18, 2000 at 08:03:51AM -0800, Linus Torvalds wrote: > > Strange. Your interrupt router is a bog-standard PIIX4, we know how to > route the thing, AND your device shows up: > > > # dump_pirq > > Interrupt routing table found at address 0xf5a80: > > Version 1.0, size 0x0080 > > Interrupt router is device 00:07.0 > > PCI exclusive interrupt mask: 0x > > Compatible router: vendor 0x8086 device 0x1234 Oh... the kernel pci-irq code looks for the "compatible router" if it is set; if unset, then it looks up the ID's of the router device. 0x8086, 0x1234 is not a known router type, so the kernel decides it can't interpret the routing table. 0x8086, 0x1234 is listed in pci_ids.h as an 82371MX. I'm suspicious of that: the MX chipset has an 82443MX, not an 82371. In any case, I think pci-irq.c should check both sets of ID's for a match. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4's internal PCMCIA works for me (was Re: [PATCH] pcmcia event thread)
On Fri, Nov 17, 2000 at 12:30:38PM -0800, Barry K. Nathan wrote: > > I do understand that the in-kernel support isn't as mature as the external > support yet. However, it isn't universally broken and useless either. That's certainly true; it should work fine for the large majority of configurations. I think the non-platform-specific issues are mostly resolved. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pcmcia event thread. (fwd)
> 2. Even when I specify cs_irq=27, it resorts to polling: > > Intel PCIC probe: > Intel i82365sl DF ISA-to-PCMCIA at port 0x8400 ofs 0x00, 2 sockets > host opts [0]: none > host opts [1]: none > ISA irqs (default) = none! polling interval = 1000 ms The driver means it when it says "ISA irqs". A value of 27 is not valid for cs_irq because this is an ISA irq number and must be 0..15; this is not a property of the host system, this is a property of the i82365 register specification. PCI interrupts have to be handled differently (well, the stripped-down i82365 driver just can't handle them at all) -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pcmcia event thread. (fwd)
2. Even when I specify cs_irq=27, it resorts to polling: Intel PCIC probe: Intel i82365sl DF ISA-to-PCMCIA at port 0x8400 ofs 0x00, 2 sockets host opts [0]: none host opts [1]: none ISA irqs (default) = none! polling interval = 1000 ms The driver means it when it says "ISA irqs". A value of 27 is not valid for cs_irq because this is an ISA irq number and must be 0..15; this is not a property of the host system, this is a property of the i82365 register specification. PCI interrupts have to be handled differently (well, the stripped-down i82365 driver just can't handle them at all) -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4's internal PCMCIA works for me (was Re: [PATCH] pcmcia event thread)
On Fri, Nov 17, 2000 at 12:30:38PM -0800, Barry K. Nathan wrote: I do understand that the in-kernel support isn't as mature as the external support yet. However, it isn't universally broken and useless either. That's certainly true; it should work fine for the large majority of configurations. I think the non-platform-specific issues are mostly resolved. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pcmcia event thread. (fwd)
On Thu, Nov 16, 2000 at 01:26:36PM -0800, [EMAIL PROTECTED] wrote: > > > Ted, is this true? It would be wonderfull to be able to use i82365 without > > need for pcmcia_cs... > > > I think in-kernel pcmcia crashing even on simple things *is* critical bug. It wasn't a critical bug, in the sense that because the i82365 driver did not work, it was not even offered as a config option. If anything it was merely a missing feature. And not a critical one, since the feature was available outside of the kernel. It is a moot point, since i82365 works with the new patches. > That was several months ago, and perhaps things have changed. But that > was I didn't spend time worrying about tracking PCMCIA bug reports; > there were a non-trivial number of them, and they were mostly of the > form "doesn't work on XXX hardware", "causes kernel oops on > hardware", etc. Some of these have been resolved, but some remain. They have not been easy things to decipher since they involve interactions between the PCI subsystem, PCMCIA, and specific hardware. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: Pcmcia/Cardbus/xircom_tulip in 2.4.0-test10.
> Can you try the test11-pre2 patch? It includes a bugfix to > xircom_tulip from Andrea. Andrea's fix doesn't actually solve the problem; it merely changes the set of working configurations to a set that includes Andrea's setup. I don't know whether the size of the working set gets larger or smaller. There is something fundamentally broken/weird about how the receive filter works on the Xircom cards. It is at least deterministic, but different network configurations behave very differently and I haven't been able to figure out the logic. One version of the driver will work perfectly for everyone that uses DHCP... another version will work fine for people who specify a static IP address... another version will work for people who use Red Hat's network configuration script but not the default PCMCIA script. The best I've been able to figure out, is that whether a call to set_rx_mode() will work or lock up the card depends on the history of what has gone on before (whether the card has had traffic through it), where the rx filter setup frame goes in the transmit ring, the alignment of the frame, and how many times set_rx_mode() has been called. Certain combinations work, other combinations don't. The effect of "ifconfig eth0 -multicast" (which should be a no-op) is that it calls set_rx_mode() with the same set of parameters it was called with before. Doing this one or more times may kick the card so that it starts working. The number of times is constant for a given network configuration, and varies between 0 and 3. I wasted a lot of time trying to figure out the rules for when set_rx_mode() would work and eventually gave up; I'm waiting for Xircom to give me an explanation. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pcmcia event thread. (fwd)
On Mon, Nov 13, 2000 at 03:42:34PM +, David Woodhouse wrote: > It's the socket drivers which _aren't_ in the kernel source which are most > likely to exhibit this problem. Anything in the kernel tree was probably > converted by Linus, and hence done right. As there are so few socket drivers > in his tree, the amount of code duplication wasn't immediately obvious > either. The i82365 and tcic drivers in the 2.4 tree have not been converted to use the thread stuff; as far as I know, the yenta driver is the only socket driver that works at all in 2.4. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: Pcmcia/Cardbus/xircom_tulip in 2.4.0-test10.
Can you try the test11-pre2 patch? It includes a bugfix to xircom_tulip from Andrea. Andrea's fix doesn't actually solve the problem; it merely changes the set of working configurations to a set that includes Andrea's setup. I don't know whether the size of the working set gets larger or smaller. There is something fundamentally broken/weird about how the receive filter works on the Xircom cards. It is at least deterministic, but different network configurations behave very differently and I haven't been able to figure out the logic. One version of the driver will work perfectly for everyone that uses DHCP... another version will work fine for people who specify a static IP address... another version will work for people who use Red Hat's network configuration script but not the default PCMCIA script. The best I've been able to figure out, is that whether a call to set_rx_mode() will work or lock up the card depends on the history of what has gone on before (whether the card has had traffic through it), where the rx filter setup frame goes in the transmit ring, the alignment of the frame, and how many times set_rx_mode() has been called. Certain combinations work, other combinations don't. The effect of "ifconfig eth0 -multicast" (which should be a no-op) is that it calls set_rx_mode() with the same set of parameters it was called with before. Doing this one or more times may kick the card so that it starts working. The number of times is constant for a given network configuration, and varies between 0 and 3. I wasted a lot of time trying to figure out the rules for when set_rx_mode() would work and eventually gave up; I'm waiting for Xircom to give me an explanation. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA versioning...
> Is there actually a way to work out what version of userspace > utilities you are using? Right now, no; the user space utilities grab the version number from the header files. I haven't figured out a sane way to straighten this out; this was the best I could come up with for now. In general, the version of the kernel stuff is what matters: the user space tools don't change much, and the API is pretty much static, so you don't need to recompile them all the time. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA versioning...
Is there actually a way to work out what version of userspace utilities you are using? Right now, no; the user space utilities grab the version number from the header files. I haven't figured out a sane way to straighten this out; this was the best I could come up with for now. In general, the version of the kernel stuff is what matters: the user space tools don't change much, and the API is pretty much static, so you don't need to recompile them all the time. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: current snapshots of pcmcia
Incidentally, the i82365 module should work ok (using ISA interrupts) despite the "No IRQ known" messages. The Yenta driver won't work at all if PCI interrupts aren't set up. So I guess another question would be, what card(s) are you using and how are they misbehaving? -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: current snapshots of pcmcia
On Mon, Nov 06, 2000 at 04:45:52PM -0700, Jeff V. Merkey wrote: > > On a related topic, I've pulled down your stuff at sourceforge and we > are using it for our 2.4 build. Is this the baest place or do you have > somewhere more recent and is this the list to report bugs? We have seen > some problems with IBM thinkpads with DSP devices having some issues > (like the volume control doesn't work right on 2.4). Most are just > annoyances and what I would classify as level IV bugs (very > non-critical). The sourceforge site is the most up to date place for PCMCIA. That is the best place to report bugs that are specific to that code. For bugs that are specific to things in the 2.4 tree and/or have to do with how PCMCIA interacts with other subsystems (i.e., the problem that started this thread, where I think the problem is in the PCI subsystem), then linux-kernel is probably a better place. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: current snapshots of pcmcia
On Mon, Nov 06, 2000 at 03:19:41PM -0800, David Ford wrote: > > Undoubtedly :( But it used to work when I used your i82365 module instead of > the kernel's yenta module. The i82365 module now gives the same failure > output as the yenta module. How long ago was this? I would need to know what kernel versions and what PCMCIA driver versions were involved. It has been months since I changed any of the PCI bridge setup code in the PCMCIA modules. > I modprobed the following to get things up and running, (all your pkg) > pcmcia_core, i82365, and ds. Then ran cardmgr. All was well. Now when I > load i82365, it yields the pci irq failure and the irq type is changed. > > 2nd sentc: What changed in the last two-three weeks? I notice that the > current pcmcia (yours) code loads a new module called pci_fixup. There is no module called pci_fixup. There is an object file called pci_fixup that is linked into pcmcia_core. This has been there since PCMCIA release 3.1.11. > Intel PCIC probe: <4>PCI: No IRQ known for interrupt pin A of device 00:03.0. > PCI: No IRQ known for interrupt pin B of device 00:03.1. This is a PCI subsystem issue; the PCMCIA code asks the PCI subsystem to activate the bridge device and isn't working. > Ricoh RL5C478 rev 03 PCI-to-CardBus at slot 00:03, mem 0x1000 > host opts [0]: [isa irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > 168/176] [bus 2/5] > host opts [1]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > 168/176] [bus 6/9] > ISA irqs (default) = 3,4,7,11 polling interval = 1000 ms > > Previous output was: > Ricoh RL5C478 rev 03 PCI-to-CardBus at slot 00:03, mem 0x1000 > host opts [0]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > 168/176] [bus 2/5] > host opts [1]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > 168/176] [bus 6/9] > ISA irqs (default) = 3,4,7,11 polling interval = 1000 ms > > Notice the change from serial irq to isa irq. This is odd. I don't have an explanation for this, especially without knowing what PCMCIA driver releases were involved. Unless you specify otherwise, the i82365 driver just reports the bridge settings that it finds; it won't change the interrupt delivery mode unless told to do so. So something else has caused your two sockets to be set up in different ways; there isn't any way to tell the i82365 module to do that. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Compile error in drivers/ide/osb4.c in 240-t10p6
On Sun, Oct 29, 2000 at 11:12:57PM +0100, Rasmus Andersen wrote: > > Thanks for the pointer. However my test build still barfs in the final > link phase because we (in t10p6) morphed drivers/pcmcia/cs.c::pcmcia_ > request_irq into (the static) cs_request_irq. The rename part > broke the two other places in cs.c where pcmcia_request_irq was > referenced and the static part made its usage in drivers/net/pcmcia/ > ray_cs.c a bit awkward. It should be un-morphed back to the way it was. It was an error that slipped into a patch I was preparing, because I was hand-editing the "diff" output to accommodate some changes between the kernel tree and the separate PCMCIA package. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Compile error in drivers/ide/osb4.c in 240-t10p6
On Sun, Oct 29, 2000 at 11:12:57PM +0100, Rasmus Andersen wrote: Thanks for the pointer. However my test build still barfs in the final link phase because we (in t10p6) morphed drivers/pcmcia/cs.c::pcmcia_ request_irq into (the static) cs_request_irq. The rename part broke the two other places in cs.c where pcmcia_request_irq was referenced and the static part made its usage in drivers/net/pcmcia/ ray_cs.c a bit awkward. It should be un-morphed back to the way it was. It was an error that slipped into a patch I was preparing, because I was hand-editing the "diff" output to accommodate some changes between the kernel tree and the separate PCMCIA package. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List - more on PCI resources...]
On Fri, Oct 13, 2000 at 02:22:32PM -0700, Dunlap, Randy wrote: > I'm not familiar with yenta controllers/devices, > and I'm not trying to throw you a tasty red herring, > but... > > yenta_config_init() does > config_writeb(socket, PCI_CACHE_LINE_SIZE, 32); > > Is this writing to the CardBus bridge or to the device's > CacheLineSize register? It is writing to the bridge. I think it should probably actually be L1_CACHE_BYTES/4. I am not sure about the impact of an incorrect setting. Maybe Linus knows. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List
On Tue, Oct 10, 2000 at 02:08:45PM -0400, [EMAIL PROTECTED] wrote: > > I am one of those people that uses PCMCIA on an SMP machine, I also > use 2.4. Aside from the very occasional problem, I don't see any > locking issues. Is it possible to just leave it as is with a warning? I think the configuration should still permit it; the probability of hitting the locking issue in the ds module is vanishingly small. The problem of non-SMP-tested PCMCIA drivers is more serious, but I'd really call all the 2.4 PCMCIA code "experimental" at this point. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List
On Wed, Oct 11, 2000 at 12:04:22AM +1100, Andrew Morton wrote: > > * Misc locking problems > > + drivers/pcmcia/ds.c: ds_read & ds_write. SMP locks are > > missing, on UP the sleep_on() use is unsafe. > > It is my understanding that hen's teeth easily outnumber SMP PCMCIA > systems. spinlocks in drivers/pcmcia/ and drivers/net/pcmcia/ are > almost nonexistent. > > So I propose that this item be removed simply by stating "Linux 2.4 does > not support PCMCIA on multiprocessors". Comments, David? There are some people who use PCMCIA on SMP desktop boxes; many wireless network cards are only made as PCMCIA cards, and the "desktop version" consists of an ISA or PCI card reader plus a card. It is not a configuration that I currently test. I am told it mostly works, though some client drivers are not SMP safe. It is something that should be fixed eventually, for sure, but given the number of open issues with PCMCIA in 2.4, I don't think it is high on the list. If you want to say that PCMCIA on SMP is unsupported until someone carefully checks it out and fixes these things, I suppose that's fine. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List
On Tue, Oct 10, 2000 at 02:08:45PM -0400, [EMAIL PROTECTED] wrote: I am one of those people that uses PCMCIA on an SMP machine, I also use 2.4. Aside from the very occasional problem, I don't see any locking issues. Is it possible to just leave it as is with a warning? I think the configuration should still permit it; the probability of hitting the locking issue in the ds module is vanishingly small. The problem of non-SMP-tested PCMCIA drivers is more serious, but I'd really call all the 2.4 PCMCIA code "experimental" at this point. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Xircom problems with test9-preX
On Wed, Oct 04, 2000 at 01:56:27AM +1100, Andrew Morton wrote: > > This patchlet was selectively taken from the latest pcmcia-cs > (3.1.21-beta). It made my NIC work correctly - without this patch the > Xircom NIC incorrectly enters half-duplex mode with disastrous > performance consequences. I doubt that the full duplex fix itself caused the problem. I think this is probably another instance of the receive filter issue. When you bring up the Xircom card, if you don't get incoming traffic, try doing things like "ifconfig eth0 promisc" (which should always work); sometimes it is also enough to do "ifconfig eth0 -promisc" a few times (which should do nothing, but...) -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Xircom problems with test9-preX
On Wed, Oct 04, 2000 at 01:56:27AM +1100, Andrew Morton wrote: This patchlet was selectively taken from the latest pcmcia-cs (3.1.21-beta). It made my NIC work correctly - without this patch the Xircom NIC incorrectly enters half-duplex mode with disastrous performance consequences. I doubt that the full duplex fix itself caused the problem. I think this is probably another instance of the receive filter issue. When you bring up the Xircom card, if you don't get incoming traffic, try doing things like "ifconfig eth0 promisc" (which should always work); sometimes it is also enough to do "ifconfig eth0 -promisc" a few times (which should do nothing, but...) -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: ds.o fails to properly enable CardBus card (2.4.0t8)
On Sat, Sep 16, 2000 at 01:02:10AM +0200, Dag B wrote: > > cs: cb_alloc(bus 4): vendor 0x115d, device 0x0003 > PCI: Failed to allocate resource 1 for PCI device 115d:0003 > PCI: Failed to allocate resource 2 for PCI device 115d:0003 > PCI: Failed to allocate resource 6 for PCI device 115d:0003 This part appears to be a PCI bug; it is not allocating the memory resources for the card successfully. The message is not particularly helpful, however. > So: the PCI code says that the last bus is '1', but my CardBus bus #4. > Is this expected? I don't think this is a problem. > I also notice that if I insmod/rmmod ds.o multiple times, I will get > multiple entries for the devices on the card in the 'lspci' output: > > 04:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) > 04:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) This is a PCMCIA bug and appears to not be 2.4 specific; luckily there is an easy workaround: don't insmod/rmmod ds.o ;) I'll fix this. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Card services & yenta driver
On Fri, Sep 15, 2000 at 02:49:35PM -0700, Linus Torvalds wrote: > > The patch looks ok, but the SS_DEBOUNCE thing is horrible. > > Why do it? All of the SS_DETECT logic is inside cs.c anyway. Now you > introduce SS_DEBOUNCE to fix a cs.c bug, and "export" that cs.c logic bug > into the low-level driver. > > An alternative, and probably more logical, fix is much simpler: add a > simple > > socket->events = 0; > > to "yenta_get_status()". Nothing more, nothing less. I think this is a bad idea. Ignoring latched events and relying on the current socket status is unsafe. You can ignore transient card-detect events when the driver hasn't yet started the power up sequence, but you cannot ignore them at other times, because the bridge does stuff (like cutting power, and redetecting card type) on its own. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Card services yenta driver
On Fri, Sep 15, 2000 at 02:49:35PM -0700, Linus Torvalds wrote: The patch looks ok, but the SS_DEBOUNCE thing is horrible. Why do it? All of the SS_DETECT logic is inside cs.c anyway. Now you introduce SS_DEBOUNCE to fix a cs.c bug, and "export" that cs.c logic bug into the low-level driver. An alternative, and probably more logical, fix is much simpler: add a simple socket-events = 0; to "yenta_get_status()". Nothing more, nothing less. I think this is a bad idea. Ignoring latched events and relying on the current socket status is unsafe. You can ignore transient card-detect events when the driver hasn't yet started the power up sequence, but you cannot ignore them at other times, because the bridge does stuff (like cutting power, and redetecting card type) on its own. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA: 3CCFE575CT initialization probem under 2.4.0-test7
On Thu, Sep 07, 2000 at 04:47:42PM -0600, Richard Gooch wrote: > Can someone post why this has broken and why a fix is (I presume) > difficult? I'll have to look at this myself if no-one else fixes it by > the time the other issues are fixed :-( In the old CardBus API, when a new CardBus card was attached to a driver, the driver returned a linked list of structs describing the new devices associated with that card. The structs included device names, and major/minor #'s. These structs were then passed out to cardmgr. In 2.4, this API has mostly gone away; new PCI drivers use the Hot Plug PCI calls so they can support regular PCI cards as well as CardBus cards. These drivers don't interact directly with the PCMCIA stack at all, and the API doesn't have a way of associating device names with cards. To replicate this functionality, I guess the API could be extended so that the "probe" entry point returned device information; then the PCI layer could return this through pci_insert_device and from there the PCMCIA stack could get to it. I have been wary of implementing this because it is not really just a PCMCIA problem; all hot plug devices face the same issue, and I didn't want to slap a quick fix onto the PCI interface that would only be useful for CardBus. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA: 3CCFE575CT initialization probem under 2.4.0-test7
On Thu, Sep 07, 2000 at 12:25:41PM -0400, Claude LeFrancois (LMC) wrote: > > cardmgr[386]: executing: './network start 3c575_cb' > cardmgr[386]: + usage: ifup > cardmgr[386]: start cmd exited with status 1 The new hot plug PCI interface does not provide a method for passing the correct device name to cardmgr. There is no fix at this time. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA: 3CCFE575CT initialization probem under 2.4.0-test7
On Thu, Sep 07, 2000 at 12:25:41PM -0400, Claude LeFrancois (LMC) wrote: cardmgr[386]: executing: './network start 3c575_cb' cardmgr[386]: + usage: ifup device name cardmgr[386]: start cmd exited with status 1 The new hot plug PCI interface does not provide a method for passing the correct device name to cardmgr. There is no fix at this time. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA: 3CCFE575CT initialization probem under 2.4.0-test7
On Thu, Sep 07, 2000 at 04:47:42PM -0600, Richard Gooch wrote: Can someone post why this has broken and why a fix is (I presume) difficult? I'll have to look at this myself if no-one else fixes it by the time the other issues are fixed :-( In the old CardBus API, when a new CardBus card was attached to a driver, the driver returned a linked list of structs describing the new devices associated with that card. The structs included device names, and major/minor #'s. These structs were then passed out to cardmgr. In 2.4, this API has mostly gone away; new PCI drivers use the Hot Plug PCI calls so they can support regular PCI cards as well as CardBus cards. These drivers don't interact directly with the PCMCIA stack at all, and the API doesn't have a way of associating device names with cards. To replicate this functionality, I guess the API could be extended so that the "probe" entry point returned device information; then the PCI layer could return this through pci_insert_device and from there the PCMCIA stack could get to it. I have been wary of implementing this because it is not really just a PCMCIA problem; all hot plug devices face the same issue, and I didn't want to slap a quick fix onto the PCI interface that would only be useful for CardBus. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
