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
> +++
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
+++
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
> t
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,
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,
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
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
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
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
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
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
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
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
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;
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
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
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
+++
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
+++
> 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
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
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
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
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
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
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.
>
>
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?
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
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
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
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
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
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
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
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?
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
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
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
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 @@
>
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 @@
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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?
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
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
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
> >
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
> 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 =
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
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
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
> 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
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
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
> 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
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,
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
91 matches
Mail list logo
