Re: 2.6.18-rc[67] crashes in TCP ack handling
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
[Bluetooth] recursive locking in l2cap_sock_accept/bt_accept_dequeue
Hiya!
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: [] bt_accept_dequeue+0x26/0xc6
[bluetooth]
but task is already holding lock:
(sk_lock-AF_BLUETOOTH){--..}, at: [] 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: []
l2cap_sock_accept+0x41/0x11e [l2cap]
stack backtrace:
[] show_trace_log_lvl+0x58/0x171
[] show_trace+0xd/0x10
[] dump_stack+0x19/0x1b
[] __lock_acquire+0x778/0x99c
[] lock_acquire+0x4b/0x6d
[] lock_sock+0xac/0xbc
[] bt_accept_dequeue+0x26/0xc6 [bluetooth]
[] l2cap_sock_accept+0xe2/0x11e [l2cap]
[] sys_accept+0xd8/0x179
[] sys_socketcall+0xa7/0x186
[] syscall_call+0x7/0xb
DWARF2 unwinder stuck at syscall_call+0x7/0xb
Leftover inexact backtrace:
[] show_trace+0xd/0x10
[] dump_stack+0x19/0x1b
[] __lock_acquire+0x778/0x99c
[] lock_acquire+0x4b/0x6d
[] lock_sock+0xac/0xbc
[] bt_accept_dequeue+0x26/0xc6 [bluetooth]
[] l2cap_sock_accept+0xe2/0x11e [l2cap]
[] sys_accept+0xd8/0x179
[] sys_socketcall+0xa7/0x186
[] syscall_call+0x7/0xb
-
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: 2.6.18-rc[67] crashes in TCP ack handling
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
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: [] bt_accept_dequeue+0x26/0xc6
> [bluetooth]
>
> but task is already holding lock:
> (sk_lock-AF_BLUETOOTH){--..}, at: [] 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: []
> l2cap_sock_accept+0x41/0x11e [l2cap]
>
> stack backtrace:
> [] show_trace_log_lvl+0x58/0x171
> [] show_trace+0xd/0x10
> [] dump_stack+0x19/0x1b
> [] __lock_acquire+0x778/0x99c
> [] lock_acquire+0x4b/0x6d
> [] lock_sock+0xac/0xbc
> [] bt_accept_dequeue+0x26/0xc6 [bluetooth]
> [] l2cap_sock_accept+0xe2/0x11e [l2cap]
> [] sys_accept+0xd8/0x179
> [] sys_socketcall+0xa7/0x186
> [] syscall_call+0x7/0xb
> DWARF2 unwinder stuck at syscall_call+0x7/0xb
> Leftover inexact backtrace:
> [] show_trace+0xd/0x10
> [] dump_stack+0x19/0x1b
> [] __lock_acquire+0x778/0x99c
> [] lock_acquire+0x4b/0x6d
> [] lock_sock+0xac/0xbc
> [] bt_accept_dequeue+0x26/0xc6 [bluetooth]
> [] l2cap_sock_accept+0xe2/0x11e [l2cap]
> [] sys_accept+0xd8/0x179
> [] sys_socketcall+0xa7/0x186
> [] 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
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
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
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: [] 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
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.
[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
> 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)
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:
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
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
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:[] 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:
tcp_read_sock+0xd5/0x158
rds_tcp_data_recv+0x0/0x349 [rds]
rds_tcp_read_sock+0x76/0xca [rds] printk+0xe/0x11
sock_def_readable+0x0/0x5e
rds_tcp_data_ready+0x96/0xe8 [rds]
tcp_data_queue+0x2d4/0x640
tcp_rcv_established+0x57d/0x5e4
tcp_v4_do_rcv+0x1b/0xae tcp_v4_rcv+0x4dc/0x7fe
get_page_from_freelist+0x7d/0x96
ip_local_deliver+0x163/0x20e
ip_rcv+0x3e6/0x420 netif_receive_skb+0x274/0x294
e1000_clean_rx_irq_ps+0x2a7/0x56e [e1000]
e1000_clean+0x5e/0x100 [e1000]
net_rx_action+0x97/0x147 __do_softirq+0x5c/0xc2
do_softirq+0x44/0x4b
do_IRQ+0x74/0x7e common_interrupt+0x1a/0x20
acpi_processor_idle+0x235/0x341 cpu_idle+0x9a/0xb3
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: [] rds_tcp_data_recv+0x1f9/0x349 [rds] SS:ESP 0068: c03eed90
<0>Kernel 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
Kernel panic occurs with ucdsnmp
Hi all, I am trying to compile the Linux's distribution with enabling the 'compounds'. It will successfully compiled, image and romfs.img is created. But when i am trying to boot with this image I am getting the following error message . Other stuff added by David S. Miller VFS: Mounted root (romfs filesystem) readonly. Freeing init memory: 44K Warning: unable to open an initial console. Kernel panic: Attempted to kill init! Panic reset After this it will halts. If i am not enable the 'ucdsnmp' package it works fine. What is the resean of this . WORNING: UNABLE TO OPEN AN INITIAL CONSOLE. KERNEL PANIC: ATTEMPTED TO KILL INIT! PANIC RESET Please tell me where is the mistake ? Tahnks in advance. Chinmaya - 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
Kernel panic occurs with ucdsnmp
Hi all, I am trying to compile the uCLinux's distribution with enabling the 'ucdsnmp'. It will successfully compiled, image and romfs.img is created. But when i am trying to boot with this image I am getting the following error message . Other stuff added by David S. Miller VFS: Mounted root (romfs filesystem) readonly. Freeing init memory: 44K Warning: unable to open an initial console. Kernel panic: Attempted to kill init! Panic reset After this it will halts. If i am not enable the 'ucdsnmp' package it works fine. What is the resean of this . WORNING: UNABLE TO OPEN AN INITIAL CONSOLE. KERNEL PANIC: ATTEMPTED TO KILL INIT! PANIC RESET Please tell me where is the mistake ? Tahnks in advance. Chinmaya - 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
