headers
Bongani Hlope | 1 Aug 2007 01:35
Picon
Favicon

[OOPS] 2.6.23-rc1 Seems to be network related

Hi

I got this partial Oops on my work laptop (DELL D800), while using the linux 
2.6.23-rc1 kernel. I've been using this kernel ever since it was released and 
this is the first and only time it did not boot. It was around the time it 
should have been trying to connect to my linksys wireless router (which has 
been working fine everyday since the 2.6.23-rc1 kernel was released).

I copied what was on screen by hand, so some info is missing. I don't know how 
to reproduce it.

Call Trace:
[<c0104cbc>] show_trace_log_lvl+0x1a/0x2f
[<c0104d6c>] show_stack_log_lvl+0x9b/0xa3
[<c0104f36>] show_registers+0x1c2/0x2db
[<c0105151>] die+0x02/0x1de
[<c01052b6>] do_trap+0x89/0xa2
[<c010558e>] do_invalid_op+0x88/0x92
[<c035a162>] error_code+0x6a/0x70
[<c0114efa>] kmap_atomic+0xe/0x10
[<c014a29c>] get_page_from_freelist+0x24c/0x3...
[<c015dd06>] __alloc_pages+0x53/0x27d
[<c015da60>] kmem_cache_alloc+0x32/0x68
[<c02e5065>] dst_alloc+0x28/0x60
[<c02f45fe>] ip_route_input+0x9b9/0xbba
[<c0314835>] arp_process+0x155/0x4e1
[<c0314caa>] arp_rcv+0xe9/0xfd
[<c02e1660>] netif_receive_skb+0x16e/0x1eb
[<c02e2efa>] process_backlog+0x71/0xda
[<c02e2fb9>] net_rx_action+0x56/0xee
(Continue reading)

Permalink | Reply | 0 comments |
headers
Divy Le Ray | 1 Aug 2007 01:43
Favicon

Re: [2.6 patch] drivers/net/cxgb3/xgmac.c: remove dead code

Adrian Bunk wrote:
>
> This patch removes dead code ("tx_xcnt" can never be != 0 at this place)
> spotted by the Coverity checker.
>
> Signed-off-by: Adrian Bunk <bunk <at> stusta.de>
>
Acked-by: Divy Le Ray <divy <at> chelsio.com>
>
>
> ---
>
>  drivers/net/cxgb3/xgmac.c |    5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> --- linux-2.6.22-rc6-mm1/drivers/net/cxgb3/xgmac.c.old  2007-07-24 
> 13:55:33.000000000 +0200
> +++ linux-2.6.22-rc6-mm1/drivers/net/cxgb3/xgmac.c      2007-07-24 
> 13:57:06.000000000 +0200
>  <at>  <at>  -510,38 +510,35  <at>  <at>  int t3b2_mac_watchdog_task(struct cmac *
>         if (tx_mcnt == mac->tx_mcnt) {
>                 tx_xcnt = (G_TXSPI4SOPCNT(t3_read_reg(adap,
>                                                 
> A_XGM_TX_SPI4_SOP_EOP_CNT +
>                                                 mac->offset)));
>                 if (tx_xcnt == 0) {
>                         t3_write_reg(adap, A_TP_PIO_ADDR,
>                                      A_TP_TX_DROP_CNT_CH0 + macidx(mac));
>                         tx_tcnt = (G_TXDROPCNTCH0RCVD(t3_read_reg(adap,
>                                                       A_TP_PIO_DATA)));
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Aug 2007 01:43

Re: [OOPS] 2.6.23-rc1 Seems to be network related

On Wed, 1 Aug 2007 01:35:23 +0200
Bongani Hlope <bonganilinux <at> mweb.co.za> wrote:

> I got this partial Oops on my work laptop (DELL D800), while using the linux 
> 2.6.23-rc1 kernel. I've been using this kernel ever since it was released and 
> this is the first and only time it did not boot. It was around the time it 
> should have been trying to connect to my linksys wireless router (which has 
> been working fine everyday since the 2.6.23-rc1 kernel was released).
> 
> I copied what was on screen by hand, so some info is missing. I don't know how 
> to reproduce it.
> 
> Call Trace:
> [<c0104cbc>] show_trace_log_lvl+0x1a/0x2f
> [<c0104d6c>] show_stack_log_lvl+0x9b/0xa3
> [<c0104f36>] show_registers+0x1c2/0x2db
> [<c0105151>] die+0x02/0x1de
> [<c01052b6>] do_trap+0x89/0xa2
> [<c010558e>] do_invalid_op+0x88/0x92
> [<c035a162>] error_code+0x6a/0x70
> [<c0114efa>] kmap_atomic+0xe/0x10
> [<c014a29c>] get_page_from_freelist+0x24c/0x3...
> [<c015dd06>] __alloc_pages+0x53/0x27d
> [<c015da60>] kmem_cache_alloc+0x32/0x68
> [<c02e5065>] dst_alloc+0x28/0x60
> [<c02f45fe>] ip_route_input+0x9b9/0xbba
> [<c0314835>] arp_process+0x155/0x4e1
> [<c0314caa>] arp_rcv+0xe9/0xfd
> [<c02e1660>] netif_receive_skb+0x16e/0x1eb
> [<c02e2efa>] process_backlog+0x71/0xda
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Perches | 1 Aug 2007 01:48

Re: [PATCH] pktgen - define and use pktgen_dbg,err,warn,info

On Mon, 2007-07-30 at 16:05 -0700, David Miller wrote:
> I still don't know about this patch.  Instead of the simple
> transformation:
> 
> -	printk(foo);
> +	printk(KERN_INFO foo);
> 
> we get this new macro, and the lines changes to use that macro.

Actually, I agree.

Many local macros could be eliminated that define
printk(<level> prefix)

I'd like to see macros added to kernel.h for:

	pr_err
	pr_notice
	pr_warn
	pr_alert
	pr_crit
	pr_emerge

and convert tree-wide all the single-line

	printk(KERN_<level> [prefix] fmt "\n", args...)

calls to the equivalent pr_<level> calls.

That would leave the multi-line printk(<level>...) calls
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jay Cliburn | 1 Aug 2007 02:07

[PATCH] atl1: use spin_trylock_irqsave()

From: Ingo Molnar <mingo <at> elte.hu>

use the simpler spin_trylock_irqsave() API to get the adapter lock.

[ this is also a fix for -rt where adapter->lock is a sleeping lock. ]

Signed-off-by: Ingo Molnar <mingo <at> elte.hu>
Signed-off-by: Jay Cliburn <jacliburn <at> bellsouth.net>
---
 drivers/net/atl1/atl1_main.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index 56f6389..3c1984e 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
 <at>  <at>  -1704,10 +1704,8  <at>  <at>  static int atl1_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
 		}
 	}

-	local_irq_save(flags);
-	if (!spin_trylock(&adapter->lock)) {
+	if (!spin_trylock_irqsave(&adapter->lock, flags)) {
 		/* Can't get lock - tell upper layer to requeue */
-		local_irq_restore(flags);
 		dev_printk(KERN_DEBUG, &adapter->pdev->dev, "tx locked\n");
 		return NETDEV_TX_LOCKED;
 	}
--

-- 
1.5.2.2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Aug 2007 02:45

Re: [REGRESSION] tg3 dead after s2ram

On Tue, 31 Jul 2007 11:28:32 +0200 "Joachim Deguara" <joachim.deguara <at> amd.com> wrote:

> On my Acer Ferrari 1000 the tg3 ethernet no longer is available after a 
> suspend to ram with the latet 2.6.23-rc1-git9.

Thanks. cc's added, body retained..

>  The tg3 works fine with s2ram 
> in 2.6.22.1.  The tell tail signs that is dead is this message from the 
> kernel log:
> 
> [    6.754133] tg3: eth0: No firmware running.
> [    6.816140] tg3: tg3_load_tso_firmware fails for eth0 to set CPU PC, is 
> ffffffff should be 00010000
> [    7.285797] ACPI: EC: Handler for query 0x80 is not found!
> [    8.016223] tg3: tg3_abort_hw timed out for eth0, TX_MODE_ENABLE will not 
> clear MAC_TX_MODE=ffffffff
> 
> and trying to bring the link up resuls in:
> 
> # ifconfig eth0 up
> SIOCSIFFLAGS: No such device
> 
> Full kernel log follows.
> 
> -Joachim
> 
> [    0.000000] Linux version 2.6.23-rc1-git9 (joachim <at> avanti) (gcc version 
> 4.2.1 20070705 (prerelease) (SUSE Linux)) #13 SMP PREEMPT Tue Jul 31 11:15:02 
> CEST 2007
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bongani Hlope | 1 Aug 2007 02:57
Picon
Favicon

[OOPS] 2.6.23-rc1 Seems to be network related

Hi

I'm not sure if the first email went through, resending without .config 
attachment.

I got this partial Oops on my work laptop (DELL D800), while using the linux 
2.6.23-rc1 kernel. I've been using this kernel ever since it was released and 
this is the first and only time it did not boot. It was around the time it 
should have been trying to connect to my linksys wireless router (which has 
been working fine everyday since the 2.6.23-rc1 kernel was released).

I copied what was on screen by hand, so some info is missing. I don't know how 
to reproduce it.

Call Trace:
[<c0104cbc>] show_trace_log_lvl+0x1a/0x2f
[<c0104d6c>] show_stack_log_lvl+0x9b/0xa3
[<c0104f36>] show_registers+0x1c2/0x2db
[<c0105151>] die+0x02/0x1de
[<c01052b6>] do_trap+0x89/0xa2
[<c010558e>] do_invalid_op+0x88/0x92
[<c035a162>] error_code+0x6a/0x70
[<c0114efa>] kmap_atomic+0xe/0x10
[<c014a29c>] get_page_from_freelist+0x24c/0x3...
[<c015dd06>] __alloc_pages+0x53/0x27d
[<c015da60>] kmem_cache_alloc+0x32/0x68
[<c02e5065>] dst_alloc+0x28/0x60
[<c02f45fe>] ip_route_input+0x9b9/0xbba
[<c0314835>] arp_process+0x155/0x4e1
[<c0314caa>] arp_rcv+0xe9/0xfd
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Aug 2007 03:04

Re: [OOPS] 2.6.23-rc1 Seems to be network related

On Wed, 1 Aug 2007 02:57:48 +0200 Bongani Hlope <bonganilinux <at> mweb.co.za> wrote:

> I'm not sure if the first email went through, resending without .config 
> attachment.

It did come through, and I replied ;)

The below post-2.6.23-rc1 patch should fix it.

commit b8c1c5da1520977cb55a358f20fc09567d40cad9
Author: Andrew Morton <akpm <at> linux-foundation.org>
Date:   Tue Jul 24 12:02:40 2007 -0700

    slab: correctly handle __GFP_ZERO

    Use the correct local variable when calling into the page allocator.  Local
    `flags' can have __GFP_ZERO set, which causes us to pass __GFP_ZERO into the
    page allocator, possibly from illegal contexts.  The page allocator will later
    do prep_zero_page()->kmap_atomic(..., KM_USER0) from irq contexts and will
    then go BUG.

    Cc: Mike Galbraith <efault <at> gmx.de>
    Acked-by: Christoph Lameter <clameter <at> sgi.com>
    Signed-off-by: Andrew Morton <akpm <at> linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds <at> linux-foundation.org>

diff --git a/mm/slab.c b/mm/slab.c
index bde271c..a684778 100644
--- a/mm/slab.c
+++ b/mm/slab.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wei Yongjun | 1 Aug 2007 03:06
Favicon

Re: [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc


> On Tue, 2007-07-31 at 07:37 -0400, Neil Horman wrote:
>   
>> On Tue, Jul 31, 2007 at 12:44:27PM +0800, Wei Yongjun wrote:
>>     
>>> If SCTP data sender received a SACK which contains Cumulative TSN Ack is 
>>> not less than the Cumulative TSN Ack Point, and if this Cumulative TSN 
>>> Ack is not used by the data sender, SCTP data sender still accept this 
>>> SACK , and next SACK which send correctly to DATA sender be dropped, 
>>> because it is less than the new Cumulative TSN Ack Point.
>>> After received this SACK, data will be retrans again and again even if 
>>> correct SACK is received.
>>> So I think this SACK must be dropped to let data transmit  correctly.
>>>
>>> Following is the tcpdump of my test. And patch in this mail can avoid 
>>> this problem.
>>>
>>> 02:19:38.233278 sctp (1) [INIT] [init tag: 1250461886] [rwnd: 54784] [OS: 10] [MIS: 65535] [init TSN:
217114040] 
>>> 02:19:39.782160 sctp (1) [INIT ACK] [init tag: 1] [rwnd: 54784] [OS: 100] [MIS: 65535] [init TSN: 100] 
>>> 02:19:39.798583 sctp (1) [COOKIE ECHO] 
>>> 02:19:40.082125 sctp (1) [COOKIE ACK] 
>>> 02:19:40.097859 sctp (1) [DATA] (B)(E) [TSN: 217114040] [SID: 0] [SSEQ 0] [PPID 0xf192090b] 
>>> 02:19:40.100162 sctp (1) [DATA] (B)(E) [TSN: 217114041] [SID: 0] [SSEQ 1] [PPID 0x3e467007] 
>>> 02:19:40.100779 sctp (1) [DATA] (B)(E) [TSN: 217114042] [SID: 0] [SSEQ 2] [PPID 0x11b12a0a] 
>>> 02:19:40.101200 sctp (1) [DATA] (B)(E) [TSN: 217114043] [SID: 0] [SSEQ 3] [PPID 0x30e7d979] 
>>> 02:19:40.561147 sctp (1) [SACK] [cum ack 217114040] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 
>>> 02:19:40.568498 sctp (1) [DATA] (B)(E) [TSN: 217114044] [SID: 0] [SSEQ 4] [PPID 0x251ff86f] 
>>> 02:19:40.569308 sctp (1) [DATA] (B)(E) [TSN: 217114045] [SID: 0] [SSEQ 5] [PPID 0xe5d5da5d] 
>>> 02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
(Continue reading)

Permalink | Reply | 7 comments |
headers
Luis R. Rodriguez | 1 Aug 2007 03:20
Picon
Gravatar

Re: Removing the prism54 module

On 7/28/07, Edward Ando <edwardando@...> wrote:
> Dear All,
> I am trying to set up software suspend 2 (TuxOnIce now it seems). This
> has decided it wants to remove the prism54 module before starting the
> hibernate process.
>
> When it tries to do this, (or when I manually do: "ifconfig eth1
> down"), I start getting these messages on all terminals, ad infinitum:
>
> kernel: unregister_netdevice: waiting for eth1 to become free. Usage
> count = 4

Hmm... can you show lsmod output please?

  Luis
Permalink | Reply | 0 comments |

Gmane