Messages in this thread |  | | | Date | Mon, 21 Jun 2004 21:48:50 +0200 | | From | Carl-Daniel Hailfinger <> | | Subject | Re: [PATCH] new device support for forcedeth.c second try |
| |
Kalin KOZHUHAROV wrote: > > # modprobe -r forcedeth; ntp_check; modprobe forcedeth; ntp_check; dmesg > -c; ntp_check; sleep 10; ntp_check > 22 Jun 03:48:56 ntpdate[8310]: adjust time server 192.168.1.100 offset > 0.000057 sec > 22 Jun 03:48:57 ntpdate[8366]: adjust time server 192.168.1.100 offset > 0.000057 sec > eth1: phy init failed to autoneg. > eth1: no link during initialization. > eth1: no IPv6 routers present > forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.28. > PCI: Setting latency timer of device 0000:00:04.0 to 64 > eth1: forcedeth.c: subsystem: 01043:80a7 bound to 0000:00:04.0 > bad: scheduling while atomic! > [<c03222fc>] schedule+0x47c/0x490 > [<c013920f>] __get_free_pages+0x1f/0x40 > [<c03227a3>] schedule_timeout+0x63/0xc0 > [<c0124b10>] process_timeout+0x0/0x10 > [<c0124eef>] msleep+0x1f/0x30 > [<e1f031b4>] phy_reset+0x64/0xc0 [forcedeth] > [<e1f032a8>] phy_init+0x98/0x320 [forcedeth] > [<e1f04b12>] nv_open+0x282/0x5d0 [forcedeth] > [<c02bc4eb>] dev_open+0xcb/0x100 > [<c02c01d4>] dev_mc_upload+0x24/0x50 > [<c02bd9f1>] dev_change_flags+0x51/0x120 > [<c02bc375>] dev_load+0x25/0x70 > [<c02f93c6>] devinet_ioctl+0x246/0x560 > [<c02fb8fe>] inet_ioctl+0x5e/0xa0 > [<c02b4d09>] sock_ioctl+0xf9/0x2b0 > [<c01643fd>] sys_ioctl+0x10d/0x290 > [<c0106087>] syscall_call+0x7/0xb > > eth1: forcedeth.c: subsystem: 01043:80a7 bound to 0000:00:04.0 > 22 Jun 03:48:57 ntpdate[8406]: adjust time server 192.168.1.100 offset > 0.000056 sec > 22 Jun 03:49:07 ntpdate[8436]: adjust time server 192.168.1.100 offset > 0.000067 sec > > This time the trace is reproducible every time. This patch and the > kmsgdump patch are the only ones applied to a stock 2.6.7 > Plugging a proper cable, just hides the three lines /^eth1:/
It seems that msleep is not the way to go here. I have to find a way to move the PHY reset out of line.
> Please tell me if I can do something else to help debugging.
Does the driver work for you when a cable is plugged in? Please test normal network traffic.
Thanks, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |