* [PATCH] tulip : fix 21142 with 10Mbps without negotiation
@ 2009-01-27 16:57 Philippe De Muyter
2009-01-30 21:49 ` David Miller
[not found] ` <20090129210701.GA8092@frolo.macqel>
0 siblings, 2 replies; 10+ messages in thread
From: Philippe De Muyter @ 2009-01-27 16:57 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 3237 bytes --]
Hello list
with current kernels, tulip 21142 ethernet controllers fail to connect
to a 10Mbps only (i.e. without negotiation-partner) network. It used
to work in 2.4 kernels. Fix that. Tested on a 21142 Rev 0x11.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
diff -r 4e8869c1d518 drivers/net/tulip/21142.c
--- a/drivers/net/tulip/21142.c Sat Jan 17 23:00:27 2009 +0000
+++ b/drivers/net/tulip/21142.c Tue Jan 27 16:44:04 2009 +0100
@@ -9,6 +9,11 @@
Please refer to Documentation/DocBook/tulip-user.{pdf,ps,html}
for more information on this driver.
+
+ DC21143 manual "21143 PCI/CardBus 10/100Mb/s Ethernet LAN Controller
+ Hardware Reference Manual" is currently available at
+ http://developer.intel.com/design/network/manuals/278074.htm
+
Please submit bugs to http://bugzilla.kernel.org/ .
*/
@@ -32,7 +37,11 @@ void t21142_media_task(struct work_struc
int csr12 = ioread32(ioaddr + CSR12);
int next_tick = 60*HZ;
int new_csr6 = 0;
-
+ int csr14 = ioread32(ioaddr + CSR14);
+
+ /* CSR12[LS10,LS100] are not reliable during autonegotiation */
+ if ((csr14 & 0x80) && (csr12 & 0x7000) != 0x5000)
+ csr12 |= 6;
if (tulip_debug > 2)
printk(KERN_INFO"%s: 21143 negotiation status %8.8x, %s.\n",
dev->name, csr12, medianame[dev->if_port]);
@@ -76,7 +85,7 @@ void t21142_media_task(struct work_struc
new_csr6 = 0x83860000;
dev->if_port = 3;
iowrite32(0, ioaddr + CSR13);
- iowrite32(0x0003FF7F, ioaddr + CSR14);
+ iowrite32(0x0003FFFF, ioaddr + CSR14);
iowrite16(8, ioaddr + CSR15);
iowrite32(1, ioaddr + CSR13);
}
@@ -132,10 +141,14 @@ void t21142_lnk_change(struct net_device
struct tulip_private *tp = netdev_priv(dev);
void __iomem *ioaddr = tp->base_addr;
int csr12 = ioread32(ioaddr + CSR12);
-
+ int csr14 = ioread32(ioaddr + CSR14);
+
+ /* CSR12[LS10,LS100] are not reliable during autonegotiation */
+ if ((csr14 & 0x80) && (csr12 & 0x7000) != 0x5000)
+ csr12 |= 6;
if (tulip_debug > 1)
printk(KERN_INFO"%s: 21143 link status interrupt %8.8x, CSR5 %x, "
- "%8.8x.\n", dev->name, csr12, csr5, ioread32(ioaddr + CSR14));
+ "%8.8x.\n", dev->name, csr12, csr5, csr14);
/* If NWay finished and we have a negotiated partner capability. */
if (tp->nway && !tp->nwayset && (csr12 & 0x7000) == 0x5000) {
@@ -143,7 +156,9 @@ void t21142_lnk_change(struct net_device
int negotiated = tp->sym_advertise & (csr12 >> 16);
tp->lpar = csr12 >> 16;
tp->nwayset = 1;
- if (negotiated & 0x0100) dev->if_port = 5;
+ /* If partner cannot negotiate, it is 10Mbps Half Duplex */
+ if (!(csr12 & 0x8000)) dev->if_port = 0;
+ else if (negotiated & 0x0100) dev->if_port = 5;
else if (negotiated & 0x0080) dev->if_port = 3;
else if (negotiated & 0x0040) dev->if_port = 4;
else if (negotiated & 0x0020) dev->if_port = 0;
@@ -214,7 +229,7 @@ void t21142_lnk_change(struct net_device
tp->timer.expires = RUN_AT(3*HZ);
add_timer(&tp->timer);
} else if (dev->if_port == 5)
- iowrite32(ioread32(ioaddr + CSR14) & ~0x080, ioaddr + CSR14);
+ iowrite32(csr14 & ~0x080, ioaddr + CSR14);
} else if (dev->if_port == 0 || dev->if_port == 4) {
if ((csr12 & 4) == 0)
printk(KERN_INFO"%s: 21143 10baseT link beat good.\n",
[-- Attachment #2: dc21143-nonegotiation.diff --]
[-- Type: text/x-patch, Size: 2969 bytes --]
diff -r 4e8869c1d518 drivers/net/tulip/21142.c
--- a/drivers/net/tulip/21142.c Sat Jan 17 23:00:27 2009 +0000
+++ b/drivers/net/tulip/21142.c Tue Jan 27 16:44:04 2009 +0100
@@ -9,6 +9,11 @@
Please refer to Documentation/DocBook/tulip-user.{pdf,ps,html}
for more information on this driver.
+
+ DC21143 manual "21143 PCI/CardBus 10/100Mb/s Ethernet LAN Controller
+ Hardware Reference Manual" is currently available at :
+ http://developer.intel.com/design/network/manuals/278074.htm
+
Please submit bugs to http://bugzilla.kernel.org/ .
*/
@@ -32,7 +37,11 @@ void t21142_media_task(struct work_struc
int csr12 = ioread32(ioaddr + CSR12);
int next_tick = 60*HZ;
int new_csr6 = 0;
-
+ int csr14 = ioread32(ioaddr + CSR14);
+
+ /* CSR12[LS10,LS100] are not reliable during autonegotiation */
+ if ((csr14 & 0x80) && (csr12 & 0x7000) != 0x5000)
+ csr12 |= 6;
if (tulip_debug > 2)
printk(KERN_INFO"%s: 21143 negotiation status %8.8x, %s.\n",
dev->name, csr12, medianame[dev->if_port]);
@@ -76,7 +85,7 @@ void t21142_media_task(struct work_struc
new_csr6 = 0x83860000;
dev->if_port = 3;
iowrite32(0, ioaddr + CSR13);
- iowrite32(0x0003FF7F, ioaddr + CSR14);
+ iowrite32(0x0003FFFF, ioaddr + CSR14);
iowrite16(8, ioaddr + CSR15);
iowrite32(1, ioaddr + CSR13);
}
@@ -132,10 +141,14 @@ void t21142_lnk_change(struct net_device
struct tulip_private *tp = netdev_priv(dev);
void __iomem *ioaddr = tp->base_addr;
int csr12 = ioread32(ioaddr + CSR12);
-
+ int csr14 = ioread32(ioaddr + CSR14);
+
+ /* CSR12[LS10,LS100] are not reliable during autonegotiation */
+ if ((csr14 & 0x80) && (csr12 & 0x7000) != 0x5000)
+ csr12 |= 6;
if (tulip_debug > 1)
printk(KERN_INFO"%s: 21143 link status interrupt %8.8x, CSR5 %x, "
- "%8.8x.\n", dev->name, csr12, csr5, ioread32(ioaddr + CSR14));
+ "%8.8x.\n", dev->name, csr12, csr5, csr14);
/* If NWay finished and we have a negotiated partner capability. */
if (tp->nway && !tp->nwayset && (csr12 & 0x7000) == 0x5000) {
@@ -143,7 +156,9 @@ void t21142_lnk_change(struct net_device
int negotiated = tp->sym_advertise & (csr12 >> 16);
tp->lpar = csr12 >> 16;
tp->nwayset = 1;
- if (negotiated & 0x0100) dev->if_port = 5;
+ /* If partner cannot negotiate, it is 10Mbps Half Duplex */
+ if (!(csr12 & 0x8000)) dev->if_port = 0;
+ else if (negotiated & 0x0100) dev->if_port = 5;
else if (negotiated & 0x0080) dev->if_port = 3;
else if (negotiated & 0x0040) dev->if_port = 4;
else if (negotiated & 0x0020) dev->if_port = 0;
@@ -214,7 +229,7 @@ void t21142_lnk_change(struct net_device
tp->timer.expires = RUN_AT(3*HZ);
add_timer(&tp->timer);
} else if (dev->if_port == 5)
- iowrite32(ioread32(ioaddr + CSR14) & ~0x080, ioaddr + CSR14);
+ iowrite32(csr14 & ~0x080, ioaddr + CSR14);
} else if (dev->if_port == 0 || dev->if_port == 4) {
if ((csr12 & 4) == 0)
printk(KERN_INFO"%s: 21143 10baseT link beat good.\n",
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] tulip : fix 21142 with 10Mbps without negotiation
2009-01-27 16:57 [PATCH] tulip : fix 21142 with 10Mbps without negotiation Philippe De Muyter
@ 2009-01-30 21:49 ` David Miller
[not found] ` <20090129210701.GA8092@frolo.macqel>
1 sibling, 0 replies; 10+ messages in thread
From: David Miller @ 2009-01-30 21:49 UTC (permalink / raw)
To: phdm; +Cc: netdev
From: Philippe De Muyter <phdm@macqel.be>
Date: Tue, 27 Jan 2009 17:57:27 +0100
> with current kernels, tulip 21142 ethernet controllers fail to connect
> to a 10Mbps only (i.e. without negotiation-partner) network. It used
> to work in 2.4 kernels. Fix that. Tested on a 21142 Rev 0x11.
>
> Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Applied, thanks Philippe.
^ permalink raw reply [flat|nested] 10+ messages in thread
* tulip : kernel BUG in tulip_up/tulip_resume
[not found] ` <20090129210701.GA8092@frolo.macqel>
@ 2009-11-08 22:33 ` Philippe De Muyter
2009-11-21 19:10 ` David Miller
2009-11-29 0:17 ` Jarek Poplawski
0 siblings, 2 replies; 10+ messages in thread
From: Philippe De Muyter @ 2009-11-08 22:33 UTC (permalink / raw)
To: grundler, kyle, netdev, linux-kernel
Hello,
I have just installed 2.6.31 (from opensuse 11.2) one a tulip-equipped
computer and I get the following error message from the kernel :
[ 2495.526390] ------------[ cut here ]------------
[ 2495.526390] kernel BUG at /usr/src/packages/BUILD/kernel-default-2.6.31.5/linux-2.6.31/include/linux/netdevice.h:439!
[ 2495.526390] invalid opcode: 0000 [#1] SMP
[ 2495.526390] last sysfs file: /sys/devices/pci0000:00/0000:00:07.1/host0/target0:0:0/0:0:0:0/block/sda/uevent
[ 2495.526390] Modules linked in: ohci_hcd raw1394 ohci1394 ieee1394 acpi_cpufreq speedstep_lib processor thermal_sys hwmon edd ipv6 af_packet fuse loop dm_mod rtc_cmos rtc_core rtc_lib apm pcspkr sg tulip uhci_hcd ehci_hcd reiserfs ata_piix ahci libata
[ 2495.526390]
[ 2495.526390] Pid: 339, comm: kapmd Not tainted (2.6.31.5-0.1-default #1)
[ 2495.526390] EIP: 0060:[<c3d6045d>] EFLAGS: 00010246 CPU: 0
[ 2495.526390] EIP is at tulip_up+0xa2d/0xa80 [tulip]
[ 2495.526390] EAX: 00000000 EBX: c1cd7000 ECX: c022af50 EDX: 0001ec00
[ 2495.526390] ESI: c1cd7340 EDI: 00000000 EBP: c20bde44 ESP: c20bddfc
[ 2495.526390] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 2495.526390] Process kapmd (pid: 339, ti=c20bc000 task=c25a32c0 task.ti=c20bc000)
[ 2495.526390] Stack:
[ 2495.526390] 0000000b c20bde44 c02acf76 2caa9a94 c2481800 c20bde38 c043ca4a c20bde27
[ 2495.526390] <0> 069ee44b c20ec120 c087c020 0001ec00 c1cd7000 c3d5c720 2caa9a94 c1cd7000
[ 2495.526390] <0> c2480000 00000000 c20bde68 c3d60555 00000080 c1cd7000 c1cd7000 2caa9a94
[ 2495.526390] Call Trace:
[ 2495.526390] [<c3d60555>] tulip_resume+0xa5/0xd0 [tulip]
[ 2495.526390] [<c043dd65>] pci_legacy_resume+0x35/0x60
[ 2495.526390] [<c043df2f>] pci_pm_resume+0x7f/0xb0
[ 2495.526390] [<c04d82f2>] pm_op+0xd2/0x180
[ 2495.526390] [<c04d91ee>] device_resume+0x5e/0x1a0
[ 2495.526390] [<c04d93dd>] dpm_resume+0xad/0x140
[ 2495.526390] [<c04d948b>] dpm_resume_end+0x1b/0x40
[ 2495.526390] [<c3db1978>] check_events+0x148/0x240 [apm]
[ 2495.526390] [<c3db23a2>] apm_mainloop+0x82/0x130 [apm]
[ 2495.526390] [<c3db28fe>] apm+0x10e/0x3d0 [apm]
[ 2495.526390] [<c026bef4>] kthread+0x84/0x90
[ 2495.526390] [<c0204db7>] kernel_thread_helper+0x7/0x10
[ 2495.526390] Code: 45 e4 e8 37 ce 6c fc 8b 4d e8 89 5c 24 10 89 7c 24 0c 89 4c 24 04 89 44 24 08 c7 04 24 4c 4e d6 c3 e8 86 f7 89 fc e9 f4 f8 ff ff <0f> 0b eb fe 0f be 96 16 09 00 00 b9 01 00 00 00 8b 45 e8 e8 fb
[ 2495.526390] EIP: [<c3d6045d>] tulip_up+0xa2d/0xa80 [tulip] SS:ESP 0068:c20bddfc
[ 2495.534162] ---[ end trace 609ed25c95a75fa1 ]---
This comes from a BUG_ON in napi_enable in netdevice.h.
napi_enable itself is called by tulip_up as such :
#ifdef CONFIG_TULIP_NAPI
napi_enable(&tp->napi);
#endif
At first reading, a matching napi_disable is called in tulip_down.
Does someone know what could be wrong and have a fix or should I look myself ?
Thanks in advance
Philippe
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: tulip : kernel BUG in tulip_up/tulip_resume
2009-11-08 22:33 ` tulip : kernel BUG in tulip_up/tulip_resume Philippe De Muyter
@ 2009-11-21 19:10 ` David Miller
2009-11-29 0:17 ` Jarek Poplawski
1 sibling, 0 replies; 10+ messages in thread
From: David Miller @ 2009-11-21 19:10 UTC (permalink / raw)
To: phdm; +Cc: grundler, kyle, netdev, linux-kernel
From: Philippe De Muyter <phdm@macqel.be>
Date: Sun, 8 Nov 2009 23:33:05 +0100
> I have just installed 2.6.31 (from opensuse 11.2) one a tulip-equipped
> computer and I get the following error message from the kernel :
I took some looks at this bug.
I simply can't figure out how this is possible. As both suspend
and resume make sure to make the necessary napi_disable() and
napi_enable() calls, and therefore they should match up and not
trigger this BUG().
I'll try to study the code some more when I get a chance.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: tulip : kernel BUG in tulip_up/tulip_resume
2009-11-08 22:33 ` tulip : kernel BUG in tulip_up/tulip_resume Philippe De Muyter
2009-11-21 19:10 ` David Miller
@ 2009-11-29 0:17 ` Jarek Poplawski
2009-11-29 11:36 ` Jarek Poplawski
1 sibling, 1 reply; 10+ messages in thread
From: Jarek Poplawski @ 2009-11-29 0:17 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: grundler, kyle, netdev, linux-kernel
Philippe De Muyter wrote, On 11/08/2009 11:33 PM:
> Hello,
>
> I have just installed 2.6.31 (from opensuse 11.2) one a tulip-equipped
> computer and I get the following error message from the kernel :
>
> [ 2495.526390] ------------[ cut here ]------------
> [ 2495.526390] kernel BUG at /usr/src/packages/BUILD/kernel-default-2.6.31.5/linux-2.6.31/include/linux/netdevice.h:439!
> [ 2495.526390] invalid opcode: 0000 [#1] SMP
...
> This comes from a BUG_ON in napi_enable in netdevice.h.
>
> napi_enable itself is called by tulip_up as such :
>
> #ifdef CONFIG_TULIP_NAPI
> napi_enable(&tp->napi);
> #endif
>
> At first reading, a matching napi_disable is called in tulip_down.
>
> Does someone know what could be wrong and have a fix or should I look myself ?
Don't know, guess only...
Jarek P.
---
drivers/net/tulip/tulip_core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
index 0df983b..6b1456c 100644
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -1787,11 +1787,11 @@ static int tulip_resume(struct pci_dev *pdev)
return retval;
}
- netif_device_attach(dev);
-
if (netif_running(dev))
tulip_up(dev);
+ netif_device_attach(dev);
+
return 0;
}
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: tulip : kernel BUG in tulip_up/tulip_resume
2009-11-29 0:17 ` Jarek Poplawski
@ 2009-11-29 11:36 ` Jarek Poplawski
2009-12-03 6:25 ` David Miller
0 siblings, 1 reply; 10+ messages in thread
From: Jarek Poplawski @ 2009-11-29 11:36 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: grundler, kyle, netdev, linux-kernel
On Sun, Nov 29, 2009 at 01:17:10AM +0100, Jarek Poplawski wrote:
> Philippe De Muyter wrote, On 11/08/2009 11:33 PM:
> > Does someone know what could be wrong and have a fix or should I look myself ?
>
> Don't know, guess only...
...And maybe a second guess btw. (to try together or separate).
Jarek P.
---
diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
index 6b2330e..fd32601 100644
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -1749,9 +1749,9 @@ static int tulip_suspend (struct pci_dev *pdev, pm_message_t state)
if (!netif_running(dev))
goto save_state;
+ netif_device_detach(dev);
tulip_down(dev);
- netif_device_detach(dev);
free_irq(dev->irq, dev);
save_state:
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: tulip : kernel BUG in tulip_up/tulip_resume
2009-11-29 11:36 ` Jarek Poplawski
@ 2009-12-03 6:25 ` David Miller
2009-12-03 8:47 ` Philippe De Muyter
0 siblings, 1 reply; 10+ messages in thread
From: David Miller @ 2009-12-03 6:25 UTC (permalink / raw)
To: jarkao2; +Cc: phdm, grundler, kyle, netdev, linux-kernel
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Sun, 29 Nov 2009 12:36:59 +0100
> On Sun, Nov 29, 2009 at 01:17:10AM +0100, Jarek Poplawski wrote:
>> Philippe De Muyter wrote, On 11/08/2009 11:33 PM:
>> > Does someone know what could be wrong and have a fix or should I look myself ?
>>
>> Don't know, guess only...
>
> ...And maybe a second guess btw. (to try together or separate).
Philippe please test Jarek's patches.
Thank you.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: tulip : kernel BUG in tulip_up/tulip_resume
2009-12-03 6:25 ` David Miller
@ 2009-12-03 8:47 ` Philippe De Muyter
2009-12-06 17:10 ` apm/pm bug [was Re: tulip : kernel BUG in tulip_up/tulip_resume] Philippe De Muyter
2009-12-06 17:10 ` Philippe De Muyter
0 siblings, 2 replies; 10+ messages in thread
From: Philippe De Muyter @ 2009-12-03 8:47 UTC (permalink / raw)
To: David Miller; +Cc: jarkao2, grundler, kyle, netdev, linux-kernel
Hi Jarek and David,
On Wed, Dec 02, 2009 at 10:25:26PM -0800, David Miller wrote:
> From: Jarek Poplawski <jarkao2@gmail.com>
> Date: Sun, 29 Nov 2009 12:36:59 +0100
>
> > On Sun, Nov 29, 2009 at 01:17:10AM +0100, Jarek Poplawski wrote:
> >> Philippe De Muyter wrote, On 11/08/2009 11:33 PM:
> >> > Does someone know what could be wrong and have a fix or should I look myself ?
> >>
> >> Don't know, guess only...
> >
> > ...And maybe a second guess btw. (to try together or separate).
>
> Philippe please test Jarek's patches.
Busy doing that. I had some problems trying to activate apm's debug.
Will report later.
Best regards
Philippe
^ permalink raw reply [flat|nested] 10+ messages in thread
* apm/pm bug [was Re: tulip : kernel BUG in tulip_up/tulip_resume]
2009-12-03 8:47 ` Philippe De Muyter
2009-12-06 17:10 ` apm/pm bug [was Re: tulip : kernel BUG in tulip_up/tulip_resume] Philippe De Muyter
@ 2009-12-06 17:10 ` Philippe De Muyter
1 sibling, 0 replies; 10+ messages in thread
From: Philippe De Muyter @ 2009-12-06 17:10 UTC (permalink / raw)
To: David Miller; +Cc: kyle, linux-pm, linux-laptop, grundler, jarkao2
[CCing linux-laptop@vger.kernel.org and linux-pm@lists.linux-foundation.org]
On Thu, Dec 03, 2009 at 09:47:42AM +0100, Philippe De Muyter wrote:
> Hi Jarek and David,
> On Wed, Dec 02, 2009 at 10:25:26PM -0800, David Miller wrote:
> > From: Jarek Poplawski <jarkao2@gmail.com>
> > Date: Sun, 29 Nov 2009 12:36:59 +0100
> >
> > > On Sun, Nov 29, 2009 at 01:17:10AM +0100, Jarek Poplawski wrote:
> > >> Philippe De Muyter wrote, On 11/08/2009 11:33 PM:
> > >> > Does someone know what could be wrong and have a fix or should I look myself ?
> > >>
> > >> Don't know, guess only...
> > >
> > > ...And maybe a second guess btw. (to try together or separate).
> >
> > Philippe please test Jarek's patches.
>
> Busy doing that. I had some problems trying to activate apm's debug.
> Will report later.
The problem seems not to be in tulip driver, but in apm or power management.
I see, with some debugging added by me :
[ 488.585707] eth0: Digital DS21142/43 Tulip rev 17 at Port 0xec00, 00:00:f8:02:cf:08, IRQ 11.
[ 508.888374] eth0: 21143 10baseT link beat good.
[ 530.754453] apm: BIOS version 1.1 Flags 0x03 (Driver version 1.16ac)
[ 530.754723] apm: entry f690:7ca cseg16 f690 dseg 40 cseg len ffff, dseg len ffff
[ 531.016684] apm: Connection version 1.1
[ 531.018853] apm: AC on line, battery status unknown, battery life unknown
[ 531.028277] apm: battery flag 0x80, battery life unknown
[ 864.060751] apm: received system standby notify
[ 864.063111] check_events : calling standby()
[ 1141.088550] apm: received system standby resume notify
[ 1141.090195] check_events : calling dpm_resume_end(PMSG_RESUME)
[ 1141.096173] tulip_resume
I do not see there a call to tulip_suspend after the call to standby(),
but I think there should be one.
Philippe
^ permalink raw reply [flat|nested] 10+ messages in thread
* apm/pm bug [was Re: tulip : kernel BUG in tulip_up/tulip_resume]
2009-12-03 8:47 ` Philippe De Muyter
@ 2009-12-06 17:10 ` Philippe De Muyter
2009-12-06 17:10 ` Philippe De Muyter
1 sibling, 0 replies; 10+ messages in thread
From: Philippe De Muyter @ 2009-12-06 17:10 UTC (permalink / raw)
To: David Miller; +Cc: jarkao2, grundler, kyle, linux-pm, linux-laptop
[CCing linux-laptop@vger.kernel.org and linux-pm@lists.linux-foundation.org]
On Thu, Dec 03, 2009 at 09:47:42AM +0100, Philippe De Muyter wrote:
> Hi Jarek and David,
> On Wed, Dec 02, 2009 at 10:25:26PM -0800, David Miller wrote:
> > From: Jarek Poplawski <jarkao2@gmail.com>
> > Date: Sun, 29 Nov 2009 12:36:59 +0100
> >
> > > On Sun, Nov 29, 2009 at 01:17:10AM +0100, Jarek Poplawski wrote:
> > >> Philippe De Muyter wrote, On 11/08/2009 11:33 PM:
> > >> > Does someone know what could be wrong and have a fix or should I look myself ?
> > >>
> > >> Don't know, guess only...
> > >
> > > ...And maybe a second guess btw. (to try together or separate).
> >
> > Philippe please test Jarek's patches.
>
> Busy doing that. I had some problems trying to activate apm's debug.
> Will report later.
The problem seems not to be in tulip driver, but in apm or power management.
I see, with some debugging added by me :
[ 488.585707] eth0: Digital DS21142/43 Tulip rev 17 at Port 0xec00, 00:00:f8:02:cf:08, IRQ 11.
[ 508.888374] eth0: 21143 10baseT link beat good.
[ 530.754453] apm: BIOS version 1.1 Flags 0x03 (Driver version 1.16ac)
[ 530.754723] apm: entry f690:7ca cseg16 f690 dseg 40 cseg len ffff, dseg len ffff
[ 531.016684] apm: Connection version 1.1
[ 531.018853] apm: AC on line, battery status unknown, battery life unknown
[ 531.028277] apm: battery flag 0x80, battery life unknown
[ 864.060751] apm: received system standby notify
[ 864.063111] check_events : calling standby()
[ 1141.088550] apm: received system standby resume notify
[ 1141.090195] check_events : calling dpm_resume_end(PMSG_RESUME)
[ 1141.096173] tulip_resume
I do not see there a call to tulip_suspend after the call to standby(),
but I think there should be one.
Philippe
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2009-12-06 17:10 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-01-27 16:57 [PATCH] tulip : fix 21142 with 10Mbps without negotiation Philippe De Muyter
2009-01-30 21:49 ` David Miller
[not found] ` <20090129210701.GA8092@frolo.macqel>
2009-11-08 22:33 ` tulip : kernel BUG in tulip_up/tulip_resume Philippe De Muyter
2009-11-21 19:10 ` David Miller
2009-11-29 0:17 ` Jarek Poplawski
2009-11-29 11:36 ` Jarek Poplawski
2009-12-03 6:25 ` David Miller
2009-12-03 8:47 ` Philippe De Muyter
2009-12-06 17:10 ` apm/pm bug [was Re: tulip : kernel BUG in tulip_up/tulip_resume] Philippe De Muyter
2009-12-06 17:10 ` Philippe De Muyter
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.