Re: 2.6.18-rc[67] crashes in TCP ack handling

2006-09-17 Thread bert hubert
On Sun, Sep 17, 2006 at 08:32:14AM +0900, Stephen Hemminger wrote:

 By building all the possiblities into the kernel, ie. not as modules
 you get the last one registered. TCP LP is probably the worst one
 to use, because it is designed for bulk low priority applications.
 It also is one of the newest least tested.  Right now, I would rate

Hehe, this seems to be a bad default configuration policy then. People
generally don't assume that if the kernel offers 10 policies that the most
unstable will be used by default if you compile them all in.

I've attached a patch that reorders the choices per your suggested order, so
people are most likely to get a sane default.

I've tried to make reno the default, no matter what you compiled in, but
it didn't work. The linker probably reorders tcp_cong.o in early.

 Without a back trace, it will be hard to find the bug in TCP LP

Indeed. 

Many thanks for your quick answer Stephen!

-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://netherlabs.nl  Open and Closed source services
--- linux-2.6.18/net/ipv4/Makefile~ 2006-09-17 11:48:33.0 +0200
+++ linux-2.6.18/net/ipv4/Makefile  2006-09-17 11:48:45.0 +0200
@@ -7,7 +7,7 @@
 ip_output.o ip_sockglue.o inet_hashtables.o \
 inet_timewait_sock.o inet_connection_sock.o \
 tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o \
-tcp_minisocks.o tcp_cong.o \
+tcp_minisocks.o \
 datagram.o raw.o udp.o arp.o icmp.o devinet.o af_inet.o igmp.o \
 sysctl_net_ipv4.o fib_frontend.o fib_semantics.o
 
@@ -37,16 +37,20 @@
 obj-$(CONFIG_IP_ROUTE_MULTIPATH_CACHED) += multipath.o
 obj-$(CONFIG_INET_TCP_DIAG) += tcp_diag.o
 obj-$(CONFIG_NET_TCPPROBE) += tcp_probe.o
-obj-$(CONFIG_TCP_CONG_BIC) += tcp_bic.o
-obj-$(CONFIG_TCP_CONG_CUBIC) += tcp_cubic.o
-obj-$(CONFIG_TCP_CONG_WESTWOOD) += tcp_westwood.o
+
+obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o
+obj-$(CONFIG_TCP_CONG_VENO) += tcp_veno.o
+obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o
+obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
 obj-$(CONFIG_TCP_CONG_HSTCP) += tcp_highspeed.o
 obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybla.o
+obj-$(CONFIG_TCP_CONG_CUBIC) += tcp_cubic.o
+obj-$(CONFIG_TCP_CONG_WESTWOOD) += tcp_westwood.o
 obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o
-obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o
-obj-$(CONFIG_TCP_CONG_VENO) += tcp_veno.o
-obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
-obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o
+obj-$(CONFIG_TCP_CONG_BIC) += tcp_bic.o
+
+# make sure the built in congestion scheme is the default
+obj-y += tcp_cong.o
 
 obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
  xfrm4_output.o


Re: 2.6.18-rc[67] crashes in TCP ack handling

2006-09-17 Thread Stephen Hemminger
On Sun, 17 Sep 2006 12:11:01 +0200
bert hubert [EMAIL PROTECTED] wrote:

 On Sun, Sep 17, 2006 at 08:32:14AM +0900, Stephen Hemminger wrote:
 
  By building all the possiblities into the kernel, ie. not as modules
  you get the last one registered. TCP LP is probably the worst one
  to use, because it is designed for bulk low priority applications.
  It also is one of the newest least tested.  Right now, I would rate
 
 Hehe, this seems to be a bad default configuration policy then. People
 generally don't assume that if the kernel offers 10 policies that the most
 unstable will be used by default if you compile them all in.
 
 I've attached a patch that reorders the choices per your suggested order, so
 people are most likely to get a sane default.
 
 I've tried to make reno the default, no matter what you compiled in, but
 it didn't work. The linker probably reorders tcp_cong.o in early.

Reno is always builtin.  To choose it use 
 sysctl -w net.ipv4.tcp_congestion_control=reno
Depending on load order is not good, and not a safe way to configure.
If you want a particular value set it with sysctl!

The more experimental ones are already labeled as EXPERIMENTAL.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Bluetooth] recursive locking in l2cap_sock_accept/bt_accept_dequeue

2006-09-17 Thread Marcel Holtmann
Hi Pekka,

 Got this from a 2.6.18rc7-based fedora-devel kernel:
 
 =
 [ INFO: possible recursive locking detected ]
 2.6.17-1.2647.fc6 #1
 -
 sdpd/4955 is trying to acquire lock:
  (sk_lock-AF_BLUETOOTH){--..}, at: [f0cea241] bt_accept_dequeue+0x26/0xc6 
 [bluetooth]
 
 but task is already holding lock:
  (sk_lock-AF_BLUETOOTH){--..}, at: [f0b90088] l2cap_sock_accept+0x41/0x11e 
 [l2cap]
 
 other info that might help us debug this:
 1 lock held by sdpd/4955:
  #0:  (sk_lock-AF_BLUETOOTH){--..}, at: [f0b90088] 
 l2cap_sock_accept+0x41/0x11e [l2cap]
 
 stack backtrace:
  [c04051ee] show_trace_log_lvl+0x58/0x171
  [c0405802] show_trace+0xd/0x10
  [c040591b] dump_stack+0x19/0x1b
  [c043b9e1] __lock_acquire+0x778/0x99c
  [c043c176] lock_acquire+0x4b/0x6d
  [c05b27e3] lock_sock+0xac/0xbc
  [f0cea241] bt_accept_dequeue+0x26/0xc6 [bluetooth]
  [f0b90129] l2cap_sock_accept+0xe2/0x11e [l2cap]
  [c05b1bd7] sys_accept+0xd8/0x179
  [c05b1d1f] sys_socketcall+0xa7/0x186
  [c0403faf] syscall_call+0x7/0xb
 DWARF2 unwinder stuck at syscall_call+0x7/0xb
 Leftover inexact backtrace:
  [c0405802] show_trace+0xd/0x10
  [c040591b] dump_stack+0x19/0x1b
  [c043b9e1] __lock_acquire+0x778/0x99c
  [c043c176] lock_acquire+0x4b/0x6d
  [c05b27e3] lock_sock+0xac/0xbc
  [f0cea241] bt_accept_dequeue+0x26/0xc6 [bluetooth]
  [f0b90129] l2cap_sock_accept+0xe2/0x11e [l2cap]
  [c05b1bd7] sys_accept+0xd8/0x179
  [c05b1d1f] sys_socketcall+0xa7/0x186
  [c0403faf] syscall_call+0x7/0xb

what where you doing when this happened?

Regards

Marcel


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: tcp congestion policy selection link order fragile

2006-09-17 Thread Stephen Hemminger
On Sun, 17 Sep 2006 14:21:53 +0200
bert hubert [EMAIL PROTECTED] wrote:

 On Sun, Sep 17, 2006 at 08:53:51PM +0900, Stephen Hemminger wrote:
 
  Depending on load order is not good, and not a safe way to configure.
 
 I agree fully.
 
  If you want a particular value set it with sysctl!
 
 Operators, distributors and even people who've been doing kernel stuff for
 more than a decade expect to be able to compile in (experimental) policies,
 and not have a *random* one of them enabled by default!

Any body who builds in random stuff without thinking is being foolish.
But, if you can think of a better configuration method that isn't too
grotty, then go for it.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: tcp congestion policy selection link order fragile

2006-09-17 Thread bert hubert
The original message Stephen reacts to below apparently never made it to the
list, it can be found here: http://ds9a.nl/tmp/module-policy.txt

 Any body who builds in random stuff without thinking is being foolish.
 But, if you can think of a better configuration method that isn't too
 grotty, then go for it.

The method I'm proposing is simple enough:

1) reno is always built-in
2) it is the default tcp congestion policy
3) loading/compiling-in additional tcp congestion policies only make them
   available
4) userspace is free to select a non-default tcp congestion policy at will

The implementation might be as simple as making the *first* registered
congestion policy the default (instead of the last one) which would be reno,
as it is in tcp_cong.o, which is probably always loaded first (as the other
.o's need symbols that are in tcp_cong.o).

Despite what you allege about my foolishness, I maintain that a kernel that
enables a *random policy* from the ones you compiled in, is not a sane
kernel.

The default kernel should be as sane as possible, allowing the userspace
people (ie, me) to mess things up to their heart's desire.

Bert

-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://netherlabs.nl  Open and Closed source services
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Bluetooth] recursive locking in l2cap_sock_accept/bt_accept_dequeue

2006-09-17 Thread Pekka Pietikainen
On Sun, Sep 17, 2006 at 02:18:26PM +0200, Marcel Holtmann wrote:
 Hi Pekka,
 
  Got this from a 2.6.18rc7-based fedora-devel kernel:
  
  =
  [ INFO: possible recursive locking detected ]
  2.6.17-1.2647.fc6 #1

  sdpd/4955 is trying to acquire lock:
   (sk_lock-AF_BLUETOOTH){--..}, at: [f0cea241] bt_accept_dequeue+0x26/0xc6 
  [bluetooth]
 
 what where you doing when this happened?
Hiya

Hmn. Plugged my USB BT dongle in, started gnome-obex-server and sent a few
pictures from my cellphone to the box, nothing fancy.. Bluetooth daemons
running obviously at this time...


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH,RESEND] rtl8150: use default MTU of 1500

2006-09-17 Thread Lennert Buytenhek
The rtl8150 (ethernet) driver uses a default MTU of 1540, which causes
all kinds of problems with for example booting off NFS root.  There isn't
really any reason why we shouldn't use the default of 1500.

Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]

Index: linux-2.6.18-rc2/drivers/usb/net/rtl8150.c
===
--- linux-2.6.18-rc2.orig/drivers/usb/net/rtl8150.c
+++ linux-2.6.18-rc2/drivers/usb/net/rtl8150.c
@@ -867,9 +867,8 @@
netdev-hard_start_xmit = rtl8150_start_xmit;
netdev-set_multicast_list = rtl8150_set_multicast;
netdev-set_mac_address = rtl8150_set_mac_address;
netdev-get_stats = rtl8150_netdev_stats;
-   netdev-mtu = RTL8150_MTU;
SET_ETHTOOL_OPS(netdev, ops);
dev-intr_interval = 100;   /* 100ms */
 
if (!alloc_all_urbs(dev)) {
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Mark frame diverter for future removal.

2006-09-17 Thread Jason Lunz
[EMAIL PROTECTED] said:
 The code for frame diverter is unmaintained and has bitrotted.
 The number of users is very small and the code has lots of problems.
 If anyone is using it, they maybe exposing themselves to bad packet attacks.

I seem to recall looking at frame diverter and thinking that everything
it does can be done with ebtables. All the more reason to remove it.

Jason

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/3][ATM]: [he] he_init_one() is declared __devinit, but calls __init functions

2006-09-17 Thread Roland Dreier
  author chas williams - CONTRACTOR [EMAIL PROTECTED] Sat, 16 Sep 2006 
  15:44:55 -0400

Not really a big deal -- but in general it's probably better to try
and preserve authorship information.

All you need is to add a

From: Roland Dreier [EMAIL PROTECTED]

line at the beginning of the body of the patch.

Thanks,
  Roland
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/4] IP100A: Fix TX Pause bug (reset_tx, intr_handler)

2006-09-17 Thread Jesse Huang
Dear Philippe:

(1) We are not allow to support register TxStartThresh and, RxEarlyThresh,
so
we remove it.

(2) Your consideration is right. But reset_tx is workaround for customer's
embedded system, I don't have this
enviroment now. I can't sure it will work fine if I removed this.

Thanks you very mutch.

Best Regards,
Jesse Huang.

- Original Message - 
From: Philippe De Muyter [EMAIL PROTECTED]
To: Jesse Huang [EMAIL PROTECTED]
Cc: netdev@vger.kernel.org
Sent: Friday, September 15, 2006 7:44 PM
Subject: Re: [PATCH 1/4] IP100A: Fix TX Pause bug (reset_tx, intr_handler)


On Thu, Sep 14, 2006 at 12:58:30AM +, Jesse Huang wrote:
[...]
 @@ -262,8 +262,6 @@ enum alta_offsets {
  ASICCtrl = 0x30,
  EEData = 0x34,
  EECtrl = 0x36,
 - TxStartThresh = 0x3c,
 - RxEarlyThresh = 0x3e,

Why ?

  FlashAddr = 0x40,
  FlashData = 0x44,
  TxStatus = 0x46,
[...]
 @@ -1156,29 +1160,29 @@ static irqreturn_t intr_handler(int irq,
  np-stats.tx_fifo_errors++;
  if (tx_status  0x02)
  np-stats.tx_window_errors++;
 - /*
 - ** This reset has been verified on
 - ** DFE-580TX boards ! [EMAIL PROTECTED]
 - */
 - if (tx_status  0x10) { /* TxUnderrun */
 - unsigned short txthreshold;
 -
 - txthreshold = ioread16 (ioaddr + TxStartThresh);
 - /* Restart Tx FIFO and transmitter */
 - sundance_reset(dev, (NetworkReset|FIFOReset|TxReset)  16);
 - iowrite16 (txthreshold, ioaddr + TxStartThresh);
 - /* No need to reset the Tx pointer here */
 +
 + /* FIFO ERROR need to be reset tx */
 + if (tx_status  0x10) { /* Reset the Tx. */
 + spin_lock(np-lock);
 + reset_tx(dev);
 + spin_unlock(np-lock);
 + }

Just as the comments say, on DFE-580TX 4 port boards, where it is easy to
reproduce TxUnderrun problems, just resetting on the chip the Tx FIFO and
transmitter is enough.
There is no need to call reset_tx, which discards all pending messages and
frees all the skb's.  It is also not necessary to reload the Tx pointer.

Is it different with newer versions of the chip ?

Philippe


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] powerpc: ibmveth: Harden driver initilisation for kexec

2006-09-17 Thread Michael Ellerman
Hi Jeff,

This patch has been floating around for a while now, Santi originally
sent it in March: http://www.spinics.net/lists/netdev/msg00471.html

You replied saying you thought it was bonkers, I think I explained why
it wasn't, perhaps you disagree.

I'm resending it now in the hope you can either give us more info on
your objections, or merge it.


After a kexec the ibmveth driver will fail when trying to register with
the Hypervisor because the previous kernel has not unregistered.

So if the registration fails, we unregister and then try again.

We don't unconditionally unregister, because we don't want to disturb the
regular code path for 99% of users.

Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
Acked-by: Anton Blanchard [EMAIL PROTECTED]
Signed-off-by: Santiago Leon [EMAIL PROTECTED]

---
 ibmveth.c |   31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

Index: to-merge/drivers/net/ibmveth.c
===
--- to-merge.orig/drivers/net/ibmveth.c
+++ to-merge/drivers/net/ibmveth.c
@@ -437,6 +437,31 @@ static void ibmveth_cleanup(struct ibmve
 adapter-rx_buff_pool[i]);
 }
 
+static int ibmveth_register_logical_lan(struct ibmveth_adapter *adapter,
+union ibmveth_buf_desc rxq_desc, u64 mac_address)
+{
+   int rc, try_again = 1;
+
+   /* After a kexec the adapter will still be open, so our attempt to
+   * open it will fail. So if we get a failure we free the adapter and
+   * try again, but only once. */
+retry:
+   rc = h_register_logical_lan(adapter-vdev-unit_address,
+   adapter-buffer_list_dma, rxq_desc.desc,
+   adapter-filter_list_dma, mac_address);
+
+   if (rc != H_SUCCESS  try_again) {
+   do {
+   rc = h_free_logical_lan(adapter-vdev-unit_address);
+   } while (H_IS_LONG_BUSY(rc) || (rc == H_BUSY));
+
+   try_again = 0;
+   goto retry;
+   }
+
+   return rc;
+}
+
 static int ibmveth_open(struct net_device *netdev)
 {
struct ibmveth_adapter *adapter = netdev-priv;
@@ -503,11 +528,7 @@ static int ibmveth_open(struct net_devic
ibmveth_debug_printk(receive q   @ 0x%p\n, 
adapter-rx_queue.queue_addr);
 

-   lpar_rc = h_register_logical_lan(adapter-vdev-unit_address,
-adapter-buffer_list_dma,
-rxq_desc.desc,
-adapter-filter_list_dma,
-mac_address);
+   lpar_rc = ibmveth_register_logical_lan(adapter, rxq_desc, mac_address);
 
if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk(h_register_logical_lan failed with 
%ld\n, lpar_rc);


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[BUG] kernel panic on T60 by e1000 driver

2006-09-17 Thread Joe Jin

while I try to transmit a 8k data by send() on my laptap T60,  kernel
panic occured:
===
kernel Bug at include/linux/skbuff.h:847!
invalid opcode  [#1]
SMP
Modules linked in: rds cisco_ipsec parport_pc lp parport autofs4
pcmcia opw3945 ieee80211 ie80211_crypt ipt_REJECT xt_tcpudp x_tables
vfat fat dm_mirror dm_mod ibm-acpi button battery ac yenta_socket
rsrc_nonstatic pcmcia_core uhci_hcd ehci_hcd i2c_i801 i2c_core e1000
ext3 jbd ahci libata sd_mod scsi_mod
CPU:0
EIP:0060:[f8e02261]   Tainted:PF  VLI
EFLAGS: 00010297(2.6.17.4 #4)
EIP is at rds_tcp_data_recv+0x1f9/0x349 [rds]
eax: 0590   ebx: f6f32d40   ecx: 0008   edx: 000a
esi: 0590   edi: f652ed48   ebp: f670f558   esp: c03eed90
ds: 007bes: 007bss: 0068
Process swapper (pid: 0, threadinfo-c03ee000 task=c032e320)
Stack: 0590 f652de58 c03eee0c 0018 f6e30cc0 c03eee1c 0001 dead4ead
    f6e30cc0 05a8 f6795a80 d853d534 c02a4198 05a8
   f8e02068 c03eee1c  f652ed48 f652de58 0017 f673ab40
Call Trace:
c02a4198 tcp_read_sock+0xd5/0x158 f8e02068
rds_tcp_data_recv+0x0/0x349 [rds]
f8e02427 rds_tcp_read_sock+0x76/0xca [rds] c012059c printk+0xe/0x11
c027e123 sock_def_readable+0x0/0x5e f8e025ac
rds_tcp_data_ready+0x96/0xe8 [rds]
c02a9a45 tcp_data_queue+0x2d4/0x640 c02aabe4
tcp_rcv_established+0x57d/0x5e4
c02b13ba tcp_v4_do_rcv+0x1b/0xae c02b1929 tcp_v4_rcv+0x4dc/0x7fe
c014537d get_page_from_freelist+0x7d/0x96 c029a78a
ip_local_deliver+0x163/0x20e
c029adbc ip_rcv+0x3e6/0x420 c0283f10 netif_receive_skb+0x274/0x294
f8ba835e e1000_clean_rx_irq_ps+0x2a7/0x56e [e1000] f8ba77d9
e1000_clean+0x5e/0x100 [e1000]
c02840bf net_rx_action+0x97/0x147 c0124504 __do_softirq+0x5c/0xc2
c0104b1e do_softirq+0x44/0x4b

c0104a40 do_IRQ+0x74/0x7e c010362e common_interrupt+0x1a/0x20
c0206f05 acpi_processor_idle+0x235/0x341 c010111b cpu_idle+0x9a/0xb3
c03a5778 start_kernel+0x193/0x195
Code: 0c f4 ff ff e9 03 01 00 00 8b 47 18 8b 34 24 0f 47 f0 8b 43 60
39 44 24 0c 77 1e 2b 44 24 0c 77 1e 2b 44 24 0c 3b 43 64 89 43 60 73
08 0f 0b 4f 03 7a 47 e0 f8 8b 44 24 0c 01 83 98 00 00 00 39 73 60
EIP: [f8e02261] rds_tcp_data_recv+0x1f9/0x349 [rds] SS:ESP 0068: c03eed90
0Kernel panic - not syncing: Fatal exception in interrupt


follow is the output of lspci:

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and
945GT Express Memory Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and
945GT Express PCI Express Root Port (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High
Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express
Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express
Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express
Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express
Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB
UHCI #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB
UHCI #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB
UHCI #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB
UHCI #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2
EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface
Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE
Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family)
Serial ATA Storage Controller AHCI (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc M52 [ATI
Mobility Radeon X1300]
02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet
Controller
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG
Network Connection (rev 02)
15:00.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller



From the panic information, I think it maybe caused by nic driver

could others also met this?
Thanks.


--
Regards,
Joe Jin
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html