Mel Gorman wrote:
(To list based on CC's in net-add-ath5k-wireless-driver-fix.patch . If
that is in error, apologies)
On (31/08/07 21:58), Andrew Morton didst pronounce:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/
I thought I would give
Mel Gorman wrote:
(To list based on CC's in net-add-ath5k-wireless-driver-fix.patch . If
that is in error, apologies)
On (31/08/07 21:58), Andrew Morton didst pronounce:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/
I thought I would give
Oops had done a reply instead of a reply to all...
--- Begin Message ---
Albert Lee wrote:
The patch just workarounds the "lost irq" problem by polling; not real
fix. We still need to find out why irq is lost per Mark's comment:
"This proves that the device does work correctly in most
Albert Lee wrote:
Mark Lord wrote:
...
Mmm.. I don't know about the first failure there,
but after that it gets into the "stuck DRQ" state
which libata makes no attempt to handle at present.
It seems the pata_pcmcia driver is using IRQ driven PIO. Maybe Robert
could try the
Albert Lee wrote:
Mark Lord wrote:
...
Mmm.. I don't know about the first failure there,
but after that it gets into the stuck DRQ state
which libata makes no attempt to handle at present.
It seems the pata_pcmcia driver is using IRQ driven PIO. Maybe Robert
could try the following
Oops had done a reply instead of a reply to all...
---BeginMessage---
Albert Lee wrote:
The patch just workarounds the lost irq problem by polling; not real
fix. We still need to find out why irq is lost per Mark's comment:
This proves that the device does work correctly in most respects
Tejun Heo wrote:
Albert Lee wrote:
libata can do most of this too by using ATA_FLAG_PIO_POLLING (doesn't
cover nodata commands tho).
Hi Tejun,
Polling of nodata commands was fixed in:
http://marc.info/?l=linux-ide=116546272916399=2
Right. Thanks for reminding me. :-)
Tejun Heo wrote:
Albert Lee wrote:
libata can do most of this too by using ATA_FLAG_PIO_POLLING (doesn't
cover nodata commands tho).
Hi Tejun,
Polling of nodata commands was fixed in:
http://marc.info/?l=linux-idem=116546272916399w=2
Right. Thanks for reminding me. :-)
Alan Stern wrote:
On Tue, 12 Jun 2007, Robert de Rooy wrote:
Yes that works.
I tried to plug and unplug the device repeatedly and each time it came
up in full-speed mode.
Good! I'm glad that "companion" attribute file has come in handy for
someone. :-)
Alan Stern
Alan Stern wrote:
Okay. It's clear that you've got a hardware problem of some sort.
Hard to say what it is, but evidently the EHCI controller thinks that
the device is repeatedly being unplugged and replugged.
Anyway, this isn't a problem of recognizing that a single device is
having
Mark Lord wrote:
Russell King wrote:
Before you do, it might help to build the ide-disk module and insert
that
as well?
ARrrggghh!! Of course, that would explain the utter lack
of disk partition check messages, now wouldn't it!
Thanks Russell !
Doh! yes that would obviously help.
With
Mark Lord wrote:
Russell King wrote:
Before you do, it might help to build the ide-disk module and insert
that
as well?
ARrrggghh!! Of course, that would explain the utter lack
of disk partition check messages, now wouldn't it!
Thanks Russell !
Doh! yes that would obviously help.
With
Alan Stern wrote:
Okay. It's clear that you've got a hardware problem of some sort.
Hard to say what it is, but evidently the EHCI controller thinks that
the device is repeatedly being unplugged and replugged.
Anyway, this isn't a problem of recognizing that a single device is
having
Alan Stern wrote:
On Tue, 12 Jun 2007, Robert de Rooy wrote:
Yes that works.
I tried to plug and unplug the device repeatedly and each time it came
up in full-speed mode.
Good! I'm glad that companion attribute file has come in handy for
someone. :-)
Alan Stern
Any way
Mark Lord wrote:
Oh crap. I did test it a couple of months ago, but my boot/root drive
is libata not IDE -- so no panic on boot with it. After booting, it
worked
just fine talking to PC-CARD CF devices using the polling.
=ml
Ok, no problem. I recompiled the kernel with libata (but without
Mark Lord wrote:
Oh crap. I did test it a couple of months ago, but my boot/root drive
is libata not IDE -- so no panic on boot with it. After booting, it
worked
just fine talking to PC-CARD CF devices using the polling.
=ml
Ok, no problem. I recompiled the kernel with libata (but without
Alan Stern wrote:
Robert, it would help somewhat if you could build a kernel with
CONFIG_USB_DEBUG turned on and post the dmesg log showing what happens
when you plug in one of those non-working devices.
Sorry, yes I should have done that before...
Yes, in principle Linux can be made to
Mark Lord wrote:
I still don't see much evidence that interrupts are actually
functioning here.
It would be good to see /proc/interrupts before/after libata tries to
talk to it.
Let's assume for the moment that interrupts are b0rken.
The legacy IDE driver can talk to such devices completely
Jiri Kosina wrote:
On Thu, 7 Jun 2007, Robert de Rooy wrote:
Yes I figured it was a hardware problem, but that was not really the
point I was trying to raise ;). I would like, if possible for Linux to
automatically fallback to USB 1.1 like Windows does (preferably with a
suitable warning
Jiri Kosina wrote:
On Thu, 7 Jun 2007, Robert de Rooy wrote:
Yes I figured it was a hardware problem, but that was not really the
point I was trying to raise ;). I would like, if possible for Linux to
automatically fallback to USB 1.1 like Windows does (preferably with a
suitable warning
Mark Lord wrote:
I still don't see much evidence that interrupts are actually
functioning here.
It would be good to see /proc/interrupts before/after libata tries to
talk to it.
Let's assume for the moment that interrupts are b0rken.
The legacy IDE driver can talk to such devices completely
Alan Stern wrote:
Robert, it would help somewhat if you could build a kernel with
CONFIG_USB_DEBUG turned on and post the dmesg log showing what happens
when you plug in one of those non-working devices.
Sorry, yes I should have done that before...
Yes, in principle Linux can be made to
Joel Becker wrote:
On Thu, Jun 07, 2007 at 10:23:19PM +0200, Robert de Rooy wrote:
On my ThinkPad T41 USB 2.0 behaves strange. Most USB 2.0 devices, refuse
to function as such. Under Windows I get a message that I should plug
the device into a USB 2.0 port (but it continues to function
Hi,
On my ThinkPad T41 USB 2.0 behaves strange. Most USB 2.0 devices, refuse
to function as such. Under Windows I get a message that I should plug
the device into a USB 2.0 port (but it continues to function as USB
1.1), while under Linux I need to manually unload ehci-hcd before I can
Tejun Heo wrote:
Can you test the attached patch
Here is what I get on the T41 (TI Cardbus controller) with 2.6.22-rc4 +
timing-debug.patch +
disable-dev_init_param-and-setxfermode-for-CFA.patch +
libata-dont-test-slave-register-readiness-after-srst.patch
Jun 7 21:10:28 localhost kernel:
Tejun Heo wrote:
Can you test the attached patch
Here is what I get on the T41 (TI Cardbus controller) with 2.6.22-rc4 +
timing-debug.patch +
disable-dev_init_param-and-setxfermode-for-CFA.patch +
libata-dont-test-slave-register-readiness-after-srst.patch
Jun 7 21:10:28 localhost kernel:
Hi,
On my ThinkPad T41 USB 2.0 behaves strange. Most USB 2.0 devices, refuse
to function as such. Under Windows I get a message that I should plug
the device into a USB 2.0 port (but it continues to function as USB
1.1), while under Linux I need to manually unload ehci-hcd before I can
Joel Becker wrote:
On Thu, Jun 07, 2007 at 10:23:19PM +0200, Robert de Rooy wrote:
On my ThinkPad T41 USB 2.0 behaves strange. Most USB 2.0 devices, refuse
to function as such. Under Windows I get a message that I should plug
the device into a USB 2.0 port (but it continues to function
Alan Cox wrote:
http://thread.gmane.org/gmane.linux.kernel/530099
It seems we're losing interrupts from the CFA device. Any ideas?
Alan probably knows more, but ISTR some CFA PCMCIA devices that needed
polling...
Not that I know of. Not devices anyway - there are embedded
Alan Cox wrote:
http://thread.gmane.org/gmane.linux.kernel/530099
It seems we're losing interrupts from the CFA device. Any ideas?
Alan probably knows more, but ISTR some CFA PCMCIA devices that needed
polling...
Not that I know of. Not devices anyway - there are embedded
Alan Cox wrote:
http://thread.gmane.org/gmane.linux.kernel/530099
It seems we're losing interrupts from the CFA device. Any ideas?
Alan probably knows more, but ISTR some CFA PCMCIA devices that needed
polling...
Not that I know of. Not devices anyway - there are embedded
Alan Cox wrote:
http://thread.gmane.org/gmane.linux.kernel/530099
It seems we're losing interrupts from the CFA device. Any ideas?
Alan probably knows more, but ISTR some CFA PCMCIA devices that needed
polling...
Not that I know of. Not devices anyway - there are embedded
Jeff Garzik wrote:
Tejun Heo wrote:
Robert de Rooy wrote:
Hmm, good question. I do not have any other PCMCIA device to test.
The only other device I have is a Cardbus Wi-Fi adapter without Linux
support (Marvell). If I insert that adapter lspci seems to list it
properly, but without resorting
Jeff Garzik wrote:
Tejun Heo wrote:
Robert de Rooy wrote:
Hmm, good question. I do not have any other PCMCIA device to test.
The only other device I have is a Cardbus Wi-Fi adapter without Linux
support (Marvell). If I insert that adapter lspci seems to list it
properly, but without resorting
I don't know if linux-pcmcia is members only, so this might not reach
that list.
Here are some log files...
Tejun Heo wrote:
Robert de Rooy wrote:
Hmm, good question. I do not have any other PCMCIA device to test.
The only other device I have is a Cardbus Wi-Fi adapter without Linux
, seeing how Cardbus is PCI based this is probably
pointless to resolving this issue.
Would any other log data from the controller initialization or lspci help?
Tejun Heo wrote:
Robert de Rooy wrote:
This gets a little bit further again, but now I get lots of new errors
Alright
rotect is off
May 21 16:59:41 localhost kernel: sd 3:0:0:0: [sdd] Asking for cache data failed
May 21 16:59:41 localhost kernel: sd 3:0:0:0: [sdd] Assuming drive cache: write
through
and it continues like that until I pull the card.
Tejun Heo wrote:
Robert de Rooy wrote:
Thanks for l
is off
May 21 16:59:41 localhost kernel: sd 3:0:0:0: [sdd] Asking for cache data failed
May 21 16:59:41 localhost kernel: sd 3:0:0:0: [sdd] Assuming drive cache: write
through
and it continues like that until I pull the card.
Tejun Heo wrote:
Robert de Rooy wrote:
Thanks for looking
, seeing how Cardbus is PCI based this is probably
pointless to resolving this issue.
Would any other log data from the controller initialization or lspci help?
Tejun Heo wrote:
Robert de Rooy wrote:
This gets a little bit further again, but now I get lots of new errors
Alright
I don't know if linux-pcmcia is members only, so this might not reach
that list.
Here are some log files...
Tejun Heo wrote:
Robert de Rooy wrote:
Hmm, good question. I do not have any other PCMCIA device to test.
The only other device I have is a Cardbus Wi-Fi adapter without Linux
Thanks for looking into this!
I tried the patches on 2.6.22rc1-git5. The second patch unfortunately
did not resolve the issue, although it seems to get a bit further. Here
are the logs.
** 2.6.22rc1-git5 + timing-debug.patch
May 20 22:40:49 localhost kernel: pccard: PCMCIA card inserted into
Thanks for looking into this!
I tried the patches on 2.6.22rc1-git5. The second patch unfortunately
did not resolve the issue, although it seems to get a bit further. Here
are the logs.
** 2.6.22rc1-git5 + timing-debug.patch
May 20 22:40:49 localhost kernel: pccard: PCMCIA card inserted into
: lost interrupt
May 17 15:31:06 localhost last message repeated 2 times
May 17 15:32:36 localhost last message repeated 3 times
Robert de Rooy wrote:
I installed the LiveCD to a spare HDD, and updated to the latest
kernel available.
The errors stayed the same, but they took much longer (it
: abnormal status 0x82 on port
0x00014107
May 16 23:13:44 localhost kernel: ata3.00: qc timeout (cmd 0x91)
May 16 23:13:44 localhost kernel: ata3.00: failed to IDENTIFY
(INIT_DEV_PARAMS failed, err_mask=0x4)
Robert de Rooy wrote:
Hi,
I tried Fedora 7t4 LiveCD on my ThinkPad T41 with a PCMCIA
: abnormal status 0x82 on port
0x00014107
May 16 23:13:44 localhost kernel: ata3.00: qc timeout (cmd 0x91)
May 16 23:13:44 localhost kernel: ata3.00: failed to IDENTIFY
(INIT_DEV_PARAMS failed, err_mask=0x4)
Robert de Rooy wrote:
Hi,
I tried Fedora 7t4 LiveCD on my ThinkPad T41 with a PCMCIA
interrupt
May 17 15:31:06 localhost last message repeated 2 times
May 17 15:32:36 localhost last message repeated 3 times
Robert de Rooy wrote:
I installed the LiveCD to a spare HDD, and updated to the latest
kernel available.
The errors stayed the same, but they took much longer (it seems the
timeouts
Hi,
I tried Fedora 7t4 LiveCD on my ThinkPad T41 with a PCMCIA "Dazzle 4in1 Card
Adapter", this adapter supports Sony Memorystick, MMC, SD and SmartMedia cards. The
card had a 128MB Lexmark MemoryStick installed.
Under windows the adapter works fine, but under Linux I got a bunch of errors
Hi,
I tried Fedora 7t4 LiveCD on my ThinkPad T41 with a PCMCIA Dazzle 4in1 Card
Adapter, this adapter supports Sony Memorystick, MMC, SD and SmartMedia cards. The
card had a 128MB Lexmark MemoryStick installed.
Under windows the adapter works fine, but under Linux I got a bunch of errors
in
48 matches
Mail list logo
