* Re: [Patch v2] net: export TCP send buffer size via netlink
From: David Miller @ 2010-02-01 10:00 UTC (permalink / raw)
To: amwang; +Cc: linux-kernel, netdev, eric.dumazet
In-Reply-To: <20100201092153.4194.91507.sendpatchset@localhost.localdomain>
From: Amerigo Wang <amwang@redhat.com>
Date: Mon, 1 Feb 2010 04:18:28 -0500
> V1 -> V2:
> Keep ABI compatiblity of struct tcp_info.
>
> Currently, we can only get TCP send buffer size by
> getsockopt (SO_SNDBUF or TCP_INFO), this is not enough
> for the tools like netstat or ss to read.
>
> Show TCP send buffer size via netlink NETLINK_INET_DIAG.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
If the user has a "struct tcp_info info" on it's stack,
and it's compiled against the header file before your
changes, guess what the kernel is going to do?
It's going to write past the end of the user's variable
into random stack locations.
You can't change the layout, at all.
^ permalink raw reply
* [BUG]? xfrm: INFO: inconsistent lock state
From: Wei Yongjun @ 2010-02-01 10:01 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: Herbert Xu
I got following lock INFO in my Fedora12 box uner 2.6.33-rc6.
Is this a BUG?
=================================
[ INFO: inconsistent lock state ]
2.6.33-rc6 #120
---------------------------------
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
(&(&x->lock)->rlock){?.-...}, at: [<c072d03f>] xfrm_input+0xdf/0x5c0
{IN-HARDIRQ-W} state was registered at:
[<c04718dc>] __lock_acquire+0xa9c/0x1890
[<c047274f>] lock_acquire+0x7f/0xf0
[<c0762958>] _raw_spin_lock+0x38/0x50
[<c072b5ca>] xfrm_timer_handler+0x3a/0x260
[<c0447d9d>] __hrtimer_tasklet_trampoline+0xd/0x10
[<c04634ce>] hrtimer_run_queues+0x15e/0x2a0
[<c045146d>] run_local_timers+0xd/0x20
[<c04514b4>] update_process_times+0x34/0x70
[<c046ce8a>] tick_periodic+0x2a/0x80
[<c046cefe>] tick_handle_periodic+0x1e/0x90
[<c0768377>] smp_apic_timer_interrupt+0x57/0x8b
[<c076382f>] apic_timer_interrupt+0x2f/0x34
[<c0401d3b>] cpu_idle+0x4b/0x80
[<c074e0d7>] rest_init+0x67/0x70
[<c0956874>] start_kernel+0x30e/0x314
[<c095609e>] i386_start_kernel+0x9e/0xa5
irq event stamp: 1113374
hardirqs last enabled at (1113374): [<c0449288>] local_bh_enable_ip+0x68/0xd0
hardirqs last disabled at (1113373): [<c0449248>] local_bh_enable_ip+0x28/0xd0
softirqs last enabled at (1113338): [<c0449570>] __do_softirq+0x100/0x1c0
softirqs last disabled at (1113343): [<c0404e17>] do_softirq+0x97/0xe0
other info that might help us debug this:
3 locks held by swapper/0:
#0: (rcu_read_lock){.+.+..}, at: [<c06b8426>] net_rx_action+0xd6/0x230
#1: (rcu_read_lock){.+.+..}, at: [<c06b77c8>] netif_receive_skb+0x138/0x570
#2: (rcu_read_lock){.+.+..}, at: [<d1c5d540>] ip6_input_finish+0x0/0x390 [ipv6]
stack backtrace:
Pid: 0, comm: swapper Not tainted 2.6.33-rc6 #120
Call Trace:
[<c075f984>] ? printk+0x1d/0x21
[<c046fb8f>] print_usage_bug+0x15f/0x1a0
[<c046ff8a>] mark_lock+0x3ba/0x5c0
[<c04701f2>] ? mark_held_locks+0x62/0x90
[<c0473540>] ? check_usage_backwards+0x0/0xd0
[<c04717ef>] __lock_acquire+0x9af/0x1890
[<c05a0cac>] ? trace_hardirqs_on_thunk+0xc/0x10
[<c07633fc>] ? restore_all_notrace+0x0/0x18
[<c04701f2>] ? mark_held_locks+0x62/0x90
[<c047274f>] lock_acquire+0x7f/0xf0
[<c072d03f>] ? xfrm_input+0xdf/0x5c0
[<c0762958>] _raw_spin_lock+0x38/0x50
[<c072d03f>] ? xfrm_input+0xdf/0x5c0
[<c072d03f>] xfrm_input+0xdf/0x5c0
[<d1c88929>] xfrm6_rcv_spi+0x29/0x30 [ipv6]
[<d1c8894c>] xfrm6_rcv+0x1c/0x20 [ipv6]
[<d1c5d681>] ip6_input_finish+0x141/0x390 [ipv6]
[<d1c5d540>] ? ip6_input_finish+0x0/0x390 [ipv6]
[<d1c5d92f>] ip6_input+0x5f/0x70 [ipv6]
[<d1c5de78>] ipv6_rcv+0x338/0x440 [ipv6]
[<d1c5db6e>] ? ipv6_rcv+0x2e/0x440 [ipv6]
[<c06b79df>] netif_receive_skb+0x34f/0x570
[<c06b77c8>] ? netif_receive_skb+0x138/0x570
[<c06affde>] ? __alloc_skb+0x4e/0x130
[<c04080b0>] ? nommu_sync_single_for_device+0x0/0x10
[<d087ec5e>] pcnet32_poll+0x27e/0x7a0 [pcnet32]
[<c0450797>] ? run_timer_softirq+0x37/0x2c0
[<c0763067>] ? _raw_spin_unlock_irq+0x27/0x30
[<c06b84a0>] net_rx_action+0x150/0x230
[<c06b8426>] ? net_rx_action+0xd6/0x230
[<c04494c8>] ? __do_softirq+0x58/0x1c0
[<c0449510>] __do_softirq+0xa0/0x1c0
[<c0449470>] ? __do_softirq+0x0/0x1c0
<IRQ> [<c0448ce5>] ? irq_exit+0x45/0x50
[<c076837c>] ? smp_apic_timer_interrupt+0x5c/0x8b
[<c05a0cbc>] ? trace_hardirqs_off_thunk+0xc/0x10
[<c076382f>] ? apic_timer_interrupt+0x2f/0x34
[<c0409de3>] ? default_idle+0x43/0xa0
[<c0401d3b>] ? cpu_idle+0x4b/0x80
[<c074e0d7>] ? rest_init+0x67/0x70
[<c0956874>] ? start_kernel+0x30e/0x314
[<c0956390>] ? unknown_bootoption+0x0/0x1a0
[<c095609e>] ? i386_start_kernel+0x9e/0xa5
^ permalink raw reply
* Re: [Patch] net: export TCP send buffer size via netlink
From: David Miller @ 2010-02-01 9:58 UTC (permalink / raw)
To: amwang; +Cc: linux-kernel, netdev
In-Reply-To: <20100201080256.4084.30962.sendpatchset@localhost.localdomain>
From: Amerigo Wang <amwang@redhat.com>
Date: Mon, 1 Feb 2010 02:59:32 -0500
>
> Currently, we can only get TCP send buffer size by
> getsockopt (SO_SNDBUF or TCP_INFO), this is not enough
> for the tools like netstat or ss to read.
>
> Show TCP send buffer size via netlink NETLINK_INET_DIAG.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
> Cc: David Miller <davem@davemloft.net>
You can't change the layout of struct tcp_info, it's
hard coded into applications.
^ permalink raw reply
* Re: [PATCH ver2] Avoid enqueuing skb for default qdiscs
From: Maxime Bizon @ 2010-02-01 9:52 UTC (permalink / raw)
To: Krishna Kumar; +Cc: davem, Jarek Poplawski, netdev, herbert, kaber
In-Reply-To: <20090806114421.19208.39374.sendpatchset@localhost.localdomain>
On Thu, 2009-08-06 at 17:14 +0530, Krishna Kumar wrote:
Hello,
> From: Krishna Kumar <krkumar2@in.ibm.com>
>
> dev_queue_xmit enqueue's a skb and calls qdisc_run which
> dequeue's the skb and xmits it. In most cases, the skb that
> is enqueue'd is the same one that is dequeue'd (unless the
> queue gets stopped or multiple cpu's write to the same queue
> and ends in a race with qdisc_run). For default qdiscs, we
> can remove the redundant enqueue/dequeue and simply xmit the
> skb since the default qdisc is work-conserving.
Sorry old stuff, but I just noticed this.
One side effect of this patch is that tc now shows a lot of requeue for
slow interfaces (slow dsl link in my case), because sch_direct_xmit is
called even if device stopped its queue.
My first reflex was too investigate for a misbehaving driver (returning
TX_BUSY), but start_xmit is not even called, sch_direct_xmit notices
that queue is stopped, and just does a dequeue/requeue.
Since we're talking about slow interfaces, this has no impact on
performance, the requeue counter incrementing is just a bit scary.
Shouldn't we check for stopped queue earlier to avoid this ?
Regards,
--
Maxime
^ permalink raw reply
* Re: debug: nt_conntrack and KVM crash
From: Alexey Dobriyan @ 2010-02-01 9:36 UTC (permalink / raw)
To: Jon Masters
Cc: Eric Dumazet, linux-kernel, netdev, netfilter-devel,
Patrick McHardy
In-Reply-To: <1265016745.7499.144.camel@tonnant>
On Mon, Feb 1, 2010 at 11:32 AM, Jon Masters <jonathan@jonmasters.org> wrote:
> I hacked up a per-namespace version of hashtables (this needs doing
> anyway, since the global stuff is just waiting to break)
Which ones? Conntrack hashtables are per-netns.
^ permalink raw reply
* Re: debug: nt_conntrack and KVM crash
From: Jon Masters @ 2010-02-01 9:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev, netfilter-devel, Patrick McHardy
In-Reply-To: <1264834704.2919.3.camel@edumazet-laptop>
On Sat, 2010-01-30 at 07:58 +0100, Eric Dumazet wrote:
> Le vendredi 29 janvier 2010 à 20:59 -0500, Jon Masters a écrit :
> > On Fri, 2010-01-29 at 20:57 -0500, Jon Masters wrote:
> >
> > > Ah so I should have realized before but I wasn't looking at valid values
> > > for the range of the hashtable yet, nf_conntrack_htable_size is getting
> > > wildly out of whack. It goes from:
> > >
> > > (gdb) print nf_conntrack_hash_rnd
> > > $1 = 2688505299
> > > (gdb) print nf_conntrack_htable_size
> > > $2 = 16384
> > >
> > > nf_conntrack_events: 1
> > > nf_conntrack_max: 65536
> > >
> > > Shortly after booting, before being NULLed shortly after starting some
> > > virtual machines (the hash isn't reset, whereas it is recomputed if the
> > > hashtable is re-initialized after an intentional resizing operation):
> >
> > I mean the *seed* isn't changed, so I don't think it was resized
> > intentionally. I wonder where else htable_size is fiddled with.
> This rings a bell here, since another crash analysis on another problem
> suggested to me a potential problem with read_mostly and modules, but I
> had no time to confirm the thing yet.
It gets more interesting, and this occurs with the code builtin anyway
(I build in to make it easier to kgdb the result conveniently), so I
don't think that's an issue...but...
I hacked up a per-namespace version of hashtables (this needs doing
anyway, since the global stuff is just waiting to break) but then
noticed that the built kernel always ends up linked roughly (the
nf_conntrack_default_htable_size is a direct rename of the existing
htable_size and is now simply the initial size for new hashtables - they
can then have their own sizes independently of this global):
00000000000074c8 l O .data.read_mostly 0000000000000008
nf_conntrack_cachep
00000000000074d0 g O .data.read_mostly 0000000000000198
nf_conntrack_untracked
0000000000007668 g O .data.read_mostly 0000000000000004
nf_conntrack_default_htable_size
000000000000766c g O .data.read_mostly 0000000000000004
nf_conntrack_default_max
In some of my runs, I've been seeing nf_conntrack_default_htable_size
get corrupted with a value that just happens to be the address of
nf_conntrack_cachep. I looked over the RCU handling and the cache
allocation/de-allocation, but didn't see anything yet. And then I'm not
sure why this address would happen to get written there? It immediately
follows nf_conntrack_untracked so I looked over what happens to that
struct (including the memset, etc.) and didn't see anything either.
Like I said, I dumped the memory with kgdb in a number of runs both
"before" and "after" for the entire page surrounding the corruption and
the only real difference is this change to the value immediately
following nf_conntrack_untracked. There was also a decrement of the
reference count on untracked (I think that's normal? It's like a
catchall for when a connection isn't being tracking anywhere else) so
I'm still looking to weird freeing.
Anyway. It looks like we have a few issues:
1). The conntrack code needs to be looked at for namespaces. I have some
work in progress patches for hashing I can send along later. But that's
just a start really for someone who knows that piece a little better.
2). Some other weird memory corruption of that specific address. Most of
the other people who've had this problem don't have dumps or kgdb.
Jon.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Patch v2] net: export TCP send buffer size via netlink
From: Amerigo Wang @ 2010-02-01 9:18 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, Eric Dumazet, Amerigo Wang, David Miller
V1 -> V2:
Keep ABI compatiblity of struct tcp_info.
Currently, we can only get TCP send buffer size by
getsockopt (SO_SNDBUF or TCP_INFO), this is not enough
for the tools like netstat or ss to read.
Show TCP send buffer size via netlink NETLINK_INET_DIAG.
Signed-off-by: WANG Cong <amwang@redhat.com>
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 7fee8a4..b63f541 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -163,6 +163,8 @@ struct tcp_info {
__u32 tcpi_rcv_space;
__u32 tcpi_total_retrans;
+
+ __u32 tcpi_sndbuf;
};
/* for TCP_MD5SIG socket option */
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index b0a26bb..b3d6a62 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2385,6 +2385,7 @@ void tcp_get_info(struct sock *sk, struct tcp_info *info)
info->tcpi_retransmits = icsk->icsk_retransmits;
info->tcpi_probes = icsk->icsk_probes_out;
info->tcpi_backoff = icsk->icsk_backoff;
+ info->tcpi_sndbuf = sk->sk_sndbuf;
if (tp->rx_opt.tstamp_ok)
info->tcpi_options |= TCPI_OPT_TIMESTAMPS;
^ permalink raw reply related
* [PATCH v2] sky2: Fix transmit dma mapping handling
From: Jarek Poplawski @ 2010-02-01 9:17 UTC (permalink / raw)
To: David Miller
Cc: Michael Breuer, Stephen Hemminger, akpm, flyboy, linux-kernel,
netdev, Michael Chan, Don Fry, Francois Romieu, Matt Carlson
In-Reply-To: <4B661E22.8090907@majjas.com>
On Sun, Jan 31, 2010 at 07:19:46PM -0500, Michael Breuer wrote:
> On 1/31/2010 5:18 PM, Jarek Poplawski wrote:
>> On Sun, Jan 31, 2010 at 04:58:42PM -0500, Michael Breuer wrote:
>>
>>> On 1/31/2010 1:50 PM, Michael Breuer wrote:
>>>> I put a printk as a third else case in sky2_tx_unmap. Looks like
>>>> the issue is that a large number (perhaps all) calls to
>>>> sky2_tx_unmap have re->flags set to neither TX_MAP_SINGLE or
>>>> TX_MAP_PAGE. Thus the elements are never being unmapped.
>>>>
>>>> I suspect that the system collapses when using DMAR sooner than if
>>>> not using DMAR. Probably some hardware limitation on the number of
>>>> mapped elements that is less than the software limitation. I don't
>>>> see at present how a ring element can ever get to this code
>>>> without re->flags being set to one or the other.
>>>>
>>>>
>>>>
>>> Put some more debugging code in... re->flags is always NULL upon
>>> entry to sky2_tx_unmap.
>>>
>>>
>> Yes, good point! Could you try if this patch can fix it. (not compiled)
...
> Ok- solves the dma-debug issue - i.e., elements are now being unmapped.
>
> Will leave up and hit with traffic unless a crash occurs. If I hit
> something unrelated I'll backport to 2.6.32.7 and try that for a while.
> I do think it's plausible that the dma errors after (during) load were
> due to hardware limitations on the number of mapped entries (haven't
> researched what that limit was). I would also assume that the sw map
> would also have failed eventually.
>
> I'd suggest that regardless of whether this patch solves my crash that
> it ought to be backported as it seems unlikely that any machine would be
> able to survive for long without the tx entries being unmapped.
Here is a bit improved version (re->flags = 0 in sky2_tx_unmap()) for
merging, or additional testing if David wishes.
Thanks,
Jarek P.
--------------->
Michael Breuer reported that dma-debug entries added by sky2 driver
weren't unmapped, and found out "re->flags is always NULL upon entry
to sky2_tx_unmap". It is overwritten by get_tx_le() after changes
introduced by commit 6b84dacadbdc3dab6a5b313d20d5a93b0d998641.
This patch reorders initializations in get_tx_le() and tx_init(), and
additionally does re->flags zeroing in sky2_tx_unmap() to prevent
possible double unmapping.
With debugging by: Michael Breuer <mbreuer@majjas.com>
Reported-by: Michael Breuer <mbreuer@majjas.com>
Tested-by: Michael Breuer <mbreuer@majjas.com>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---
drivers/net/sky2.c | 20 +++++++++++++-------
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index d760650..21bb00a 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -1025,9 +1025,10 @@ static void sky2_prefetch_init(struct sky2_hw *hw, u32 qaddr,
static inline struct sky2_tx_le *get_tx_le(struct sky2_port *sky2, u16 *slot)
{
struct sky2_tx_le *le = sky2->tx_le + *slot;
- struct tx_ring_info *re = sky2->tx_ring + *slot;
+ struct tx_ring_info *re;
*slot = RING_NEXT(*slot, sky2->tx_ring_size);
+ re = sky2->tx_ring + *slot;
re->flags = 0;
re->skb = NULL;
le->ctrl = 0;
@@ -1036,13 +1037,16 @@ static inline struct sky2_tx_le *get_tx_le(struct sky2_port *sky2, u16 *slot)
static void tx_init(struct sky2_port *sky2)
{
- struct sky2_tx_le *le;
+ struct sky2_tx_le *le = sky2->tx_le;
+ struct tx_ring_info *re = sky2->tx_ring;
sky2->tx_prod = sky2->tx_cons = 0;
sky2->tx_tcpsum = 0;
sky2->tx_last_mss = 0;
- le = get_tx_le(sky2, &sky2->tx_prod);
+ re->flags = 0;
+ re->skb = NULL;
+ le->ctrl = 0;
le->addr = 0;
le->opcode = OP_ADDR64 | HW_OWNER;
sky2->tx_last_upper = 0;
@@ -1622,17 +1626,19 @@ static unsigned tx_le_req(const struct sk_buff *skb)
return count;
}
-static void sky2_tx_unmap(struct pci_dev *pdev,
- const struct tx_ring_info *re)
+static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re)
{
- if (re->flags & TX_MAP_SINGLE)
+ if (re->flags & TX_MAP_SINGLE) {
pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr),
pci_unmap_len(re, maplen),
PCI_DMA_TODEVICE);
- else if (re->flags & TX_MAP_PAGE)
+ re->flags = 0;
+ } else if (re->flags & TX_MAP_PAGE) {
pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr),
pci_unmap_len(re, maplen),
PCI_DMA_TODEVICE);
+ re->flags = 0;
+ }
}
/*
^ permalink raw reply related
* Re: [Patch] net: export TCP send buffer size via netlink
From: Cong Wang @ 2010-02-01 9:04 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev, David Miller
In-Reply-To: <1265014309.2848.7.camel@edumazet-laptop>
Eric Dumazet wrote:
> Le lundi 01 février 2010 à 02:59 -0500, Amerigo Wang a écrit :
>> Currently, we can only get TCP send buffer size by
>> getsockopt (SO_SNDBUF or TCP_INFO), this is not enough
>> for the tools like netstat or ss to read.
>>
>> Show TCP send buffer size via netlink NETLINK_INET_DIAG.
>>
>> Signed-off-by: WANG Cong <amwang@redhat.com>
>> Cc: David Miller <davem@davemloft.net>
>>
>> ---
>> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
>> index 7fee8a4..46768de 100644
>> --- a/include/linux/tcp.h
>> +++ b/include/linux/tcp.h
>> @@ -136,6 +136,7 @@ struct tcp_info {
>> __u32 tcpi_ato;
>> __u32 tcpi_snd_mss;
>> __u32 tcpi_rcv_mss;
>> + __u32 tcpi_sndbuf;
>>
>> __u32 tcpi_unacked;
>> __u32 tcpi_sacked;
>
> You cannot change tcp_info like this, this structure is used by some
> programs, and they are going to break badly.
>
Oh, right, I forgot the ABI compatibility...
I will append it to this structure.
Thanks!
^ permalink raw reply
* Re: [Patch] net: export TCP send buffer size via netlink
From: Eric Dumazet @ 2010-02-01 8:51 UTC (permalink / raw)
To: Amerigo Wang; +Cc: linux-kernel, netdev, David Miller
In-Reply-To: <20100201080256.4084.30962.sendpatchset@localhost.localdomain>
Le lundi 01 février 2010 à 02:59 -0500, Amerigo Wang a écrit :
> Currently, we can only get TCP send buffer size by
> getsockopt (SO_SNDBUF or TCP_INFO), this is not enough
> for the tools like netstat or ss to read.
>
> Show TCP send buffer size via netlink NETLINK_INET_DIAG.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
> Cc: David Miller <davem@davemloft.net>
>
> ---
> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> index 7fee8a4..46768de 100644
> --- a/include/linux/tcp.h
> +++ b/include/linux/tcp.h
> @@ -136,6 +136,7 @@ struct tcp_info {
> __u32 tcpi_ato;
> __u32 tcpi_snd_mss;
> __u32 tcpi_rcv_mss;
> + __u32 tcpi_sndbuf;
>
> __u32 tcpi_unacked;
> __u32 tcpi_sacked;
You cannot change tcp_info like this, this structure is used by some
programs, and they are going to break badly.
^ permalink raw reply
* [Patch] net: export TCP send buffer size via netlink
From: Amerigo Wang @ 2010-02-01 7:59 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, Amerigo Wang, David Miller
Currently, we can only get TCP send buffer size by
getsockopt (SO_SNDBUF or TCP_INFO), this is not enough
for the tools like netstat or ss to read.
Show TCP send buffer size via netlink NETLINK_INET_DIAG.
Signed-off-by: WANG Cong <amwang@redhat.com>
Cc: David Miller <davem@davemloft.net>
---
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 7fee8a4..46768de 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -136,6 +136,7 @@ struct tcp_info {
__u32 tcpi_ato;
__u32 tcpi_snd_mss;
__u32 tcpi_rcv_mss;
+ __u32 tcpi_sndbuf;
__u32 tcpi_unacked;
__u32 tcpi_sacked;
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index b0a26bb..b3d6a62 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2385,6 +2385,7 @@ void tcp_get_info(struct sock *sk, struct tcp_info *info)
info->tcpi_retransmits = icsk->icsk_retransmits;
info->tcpi_probes = icsk->icsk_probes_out;
info->tcpi_backoff = icsk->icsk_backoff;
+ info->tcpi_sndbuf = sk->sk_sndbuf;
if (tp->rx_opt.tstamp_ok)
info->tcpi_options |= TCPI_OPT_TIMESTAMPS;
^ permalink raw reply related
* Re: Pull request: bluetooth-2.6 2010-01-30
From: David Miller @ 2010-02-01 7:35 UTC (permalink / raw)
To: marcel; +Cc: netdev
In-Reply-To: <cover.1264859950.git.marcel@holtmann.org>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Sat, 30 Jan 2010 06:08:43 -0800
> this includes two L2CAP fixes. One for a memory leak and another one for
> a double free.
>
> For Bluetooth PCMCIA cards a BUG_ON caused a few issues when we have
> shared interrupts. So revert this and put a clear comment in the source
> that this is what we actually want.
>
> The Bluetooth HID fix for raw reports has a big diffstat, but the logical
> change is small. By accident we send the reports on the interrupt channel
> and the original test device seems to cope with that. Devices that follow
> the specification more closer will break. The right thing is to use the
> control channel. This is similar to what is done via USB.
>
> And by request from Luis, include the driver for Atheros Bluetooth chipset
> AR3011. It is a new driver and by itself small and self contained. If you
> feel that it should not be merged, then let me know and I redo this
> patchset.
Pulled, thanks Marcel.
^ permalink raw reply
* Re: [PATCH 0/3][v2] tcp: fix ICMP-RTO war
From: David Miller @ 2010-02-01 7:33 UTC (permalink / raw)
To: damian; +Cc: netdev
In-Reply-To: <4B635E17.406@tvk.rwth-aachen.de>
From: Damian Lukowski <damian@tvk.rwth-aachen.de>
Date: Fri, 29 Jan 2010 23:15:51 +0100
> This patches fix the current RTO calculation routine, when
> srtt and rttvar are zero, yielding an RTO of zero
> Under some circumstances, TCPs srtt and rttvar are zero,
> yielding a calculated RTO of zero.
> This is particularly unfortunate for ICMP based RTO recalculation
> as introduced in f1ecd5d9e736660 (Revert Backoff [v3]: Revert RTO
> on ICMP destination unreachable), as it results in RTO retransmission
> flooding.
>
> Thanks to Ilpo Jarvinen for providing debug patches and to
> Denys Fedoryshchenko for reporting and testing.
>
> Signed-off-by: Damian Lukowski <damian@tvk.rwth-aachen.de>
I still haven't seen a detailed enough analysis of why these
tiny RTOs can come to exist in the first place.
Please show me a list of events, function by function, the value of
relevant variables and per-socket TCP state, in the TCP stack, that
show how this ends up happening.
Thanks for all of your work on this so far.
^ permalink raw reply
* Re: [PATCH 1/3][v2] tcp: fix ICMP-RTO war: Check lower bound
From: David Miller @ 2010-02-01 7:32 UTC (permalink / raw)
To: damian; +Cc: netdev
In-Reply-To: <4B635E1A.7040100@tvk.rwth-aachen.de>
From: Damian Lukowski <damian@tvk.rwth-aachen.de>
Date: Fri, 29 Jan 2010 23:15:54 +0100
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 34f5cc2..ff6cbaa 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -528,9 +528,12 @@ static inline void tcp_bound_rto(const struct sock *sk)
> inet_csk(sk)->icsk_rto = TCP_RTO_MAX;
> }
>
> +static inline u32 tcp_rto_min(struct sock *sk);
> static inline u32 __tcp_set_rto(const struct tcp_sock *tp)
> {
> - return (tp->srtt >> 3) + tp->rttvar;
> + u32 rto = (tp->srtt >> 3) + tp->rttvar;
> + u32 min = tcp_rto_min((struct sock *)tp);
> + return unlikely(rto < min) ? min : rto;
> }
>
> static inline void __tcp_fast_path_on(struct tcp_sock *tp, u32 snd_wnd)
Don't make assumptions about the layout and relationships
between struct sock and struct tcp_sock without using
the interfaces create for this purpose.
For this case, simply add a "struct sock *" first argument to
__tcp_set_rto() and update the callers.
Thanks.
^ permalink raw reply
* Re: [net-next PATCH 00/13] drivers/net/tulip: Cleanups
From: David Miller @ 2010-02-01 7:27 UTC (permalink / raw)
To: joe; +Cc: netdev
In-Reply-To: <cover.1264747118.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 28 Jan 2010 22:59:16 -0800
> Joe Perches (13):
> tulip_core: Use dev_<level> and pr_<level>
> tulip/21142.c: Use dev_<level> and pr_<level>
> tulip/de2104x.c: Use dev_<level> and pr_<level>
> tulip/dmfe.c: Use dev_<level> and pr_<level>
> tulip/eeprom.c: Use dev_<level> and pr_<level>
> tulip/interrupt.c: Use dev_<level> and pr_<level>
> tulip/media.c: Use dev_<level> and pr_<level>
> tulip/pnic.c: Use dev_<level> and pr_<level>
> tulip/pnic2.c: Use dev_<level> and pr_<level>
> tulip/timer.c: Use dev_<level> and pr_<level>
> tulip/uli526x.c: Use dev_<level> and pr_<level>
> tulip/winbond-840.c: Use dev_<level> and pr_<level>
> tulip/xircom_cb.c: Use dev_<level> and pr_<level>
All applied, thanks Joe.
^ permalink raw reply
* Re: [BUG-FIX][PATCH 0/2]: recent dccp fixes
From: David Miller @ 2010-02-01 7:17 UTC (permalink / raw)
To: gerrit; +Cc: dccp, netdev
In-Reply-To: <1265005087-5549-1-git-send-email-gerrit@erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Mon, 1 Feb 2010 07:18:05 +0100
> In January there were two dccp commits introducing bugs. Having
> been guilty of ack-ing them, please find below patches to fix
> them.
>
> Patch #1: fixes a bug resulting from truncating cache name length.
> Patch #2: reverts a commit which introduced a module-loading bug.
>
> This being bugs, would you please consider this for stable too.
>
> The test-tree also has been fixed accordingly,
> http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=dccp_exp.git;a=shortlog;h=ready
Gerrit can you at least CC: the author of the changes
you are reverting?
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: mcp251x: Move to threaded interrupts instead of workqueues.
From: christian pellegrin @ 2010-02-01 7:10 UTC (permalink / raw)
To: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Wolfgang Grandegger
Cc: Christian Pellegrin
In-Reply-To: <1264959793-1797-1-git-send-email-chripell-VaTbYqLCNhc@public.gmane.org>
Please wait a moment for this patch because I had some reports of
possible problems.
On Sun, Jan 31, 2010 at 6:43 PM, Christian Pellegrin <chripell-VaTbYqLCNhc@public.gmane.org> wrote:
> This patch addresses concerns about efficiency of handling incoming
> packets. Handling of interrupts is done in a threaded interrupt handler
> which has a smaller latency than workqueues. This change needed a rework
> of the locking scheme that was much simplified. Some other (more or less
> longstanding) bugs are fixed: utilization of just half of the RX
> buffers, useless wait for interrupt on open, more reliable reset
> sequence. The MERR interrupt is not used anymore: it overloads the CPU
> in bus-off state without any additional information.
>
> Signed-off-by: Christian Pellegrin <chripell-VaTbYqLCNhc@public.gmane.org>
> ---
> drivers/net/can/mcp251x.c | 415 ++++++++++++++++++++++-----------------------
> 1 files changed, 202 insertions(+), 213 deletions(-)
>
> diff --git a/drivers/net/can/mcp251x.c b/drivers/net/can/mcp251x.c
> index bbe186b..884d309 100644
> --- a/drivers/net/can/mcp251x.c
> +++ b/drivers/net/can/mcp251x.c
> @@ -180,6 +180,14 @@
> #define RXBEID0_OFF 4
> #define RXBDLC_OFF 5
> #define RXBDAT_OFF 6
> +#define RXFSIDH(n) ((n) * 4)
> +#define RXFSIDL(n) ((n) * 4 + 1)
> +#define RXFEID8(n) ((n) * 4 + 2)
> +#define RXFEID0(n) ((n) * 4 + 3)
> +#define RXMSIDH(n) ((n) * 4 + 0x20)
> +#define RXMSIDL(n) ((n) * 4 + 0x21)
> +#define RXMEID8(n) ((n) * 4 + 0x22)
> +#define RXMEID0(n) ((n) * 4 + 0x23)
>
> #define GET_BYTE(val, byte) \
> (((val) >> ((byte) * 8)) & 0xff)
> @@ -219,7 +227,8 @@ struct mcp251x_priv {
> struct net_device *net;
> struct spi_device *spi;
>
> - struct mutex spi_lock; /* SPI buffer lock */
> + struct mutex mcp_lock; /* SPI device lock */
> +
> u8 *spi_tx_buf;
> u8 *spi_rx_buf;
> dma_addr_t spi_tx_dma;
> @@ -227,11 +236,11 @@ struct mcp251x_priv {
>
> struct sk_buff *tx_skb;
> int tx_len;
> +
> struct workqueue_struct *wq;
> struct work_struct tx_work;
> - struct work_struct irq_work;
> - struct completion awake;
> - int wake;
> + struct work_struct restart_work;
> +
> int force_quit;
> int after_suspend;
> #define AFTER_SUSPEND_UP 1
> @@ -245,7 +254,8 @@ static void mcp251x_clean(struct net_device *net)
> {
> struct mcp251x_priv *priv = netdev_priv(net);
>
> - net->stats.tx_errors++;
> + if (priv->tx_skb || priv->tx_len)
> + net->stats.tx_errors++;
> if (priv->tx_skb)
> dev_kfree_skb(priv->tx_skb);
> if (priv->tx_len)
> @@ -300,16 +310,12 @@ static u8 mcp251x_read_reg(struct spi_device *spi, uint8_t reg)
> struct mcp251x_priv *priv = dev_get_drvdata(&spi->dev);
> u8 val = 0;
>
> - mutex_lock(&priv->spi_lock);
> -
> priv->spi_tx_buf[0] = INSTRUCTION_READ;
> priv->spi_tx_buf[1] = reg;
>
> mcp251x_spi_trans(spi, 3);
> val = priv->spi_rx_buf[2];
>
> - mutex_unlock(&priv->spi_lock);
> -
> return val;
> }
>
> @@ -317,15 +323,11 @@ static void mcp251x_write_reg(struct spi_device *spi, u8 reg, uint8_t val)
> {
> struct mcp251x_priv *priv = dev_get_drvdata(&spi->dev);
>
> - mutex_lock(&priv->spi_lock);
> -
> priv->spi_tx_buf[0] = INSTRUCTION_WRITE;
> priv->spi_tx_buf[1] = reg;
> priv->spi_tx_buf[2] = val;
>
> mcp251x_spi_trans(spi, 3);
> -
> - mutex_unlock(&priv->spi_lock);
> }
>
> static void mcp251x_write_bits(struct spi_device *spi, u8 reg,
> @@ -333,16 +335,12 @@ static void mcp251x_write_bits(struct spi_device *spi, u8 reg,
> {
> struct mcp251x_priv *priv = dev_get_drvdata(&spi->dev);
>
> - mutex_lock(&priv->spi_lock);
> -
> priv->spi_tx_buf[0] = INSTRUCTION_BIT_MODIFY;
> priv->spi_tx_buf[1] = reg;
> priv->spi_tx_buf[2] = mask;
> priv->spi_tx_buf[3] = val;
>
> mcp251x_spi_trans(spi, 4);
> -
> - mutex_unlock(&priv->spi_lock);
> }
>
> static void mcp251x_hw_tx_frame(struct spi_device *spi, u8 *buf,
> @@ -358,10 +356,8 @@ static void mcp251x_hw_tx_frame(struct spi_device *spi, u8 *buf,
> mcp251x_write_reg(spi, TXBCTRL(tx_buf_idx) + i,
> buf[i]);
> } else {
> - mutex_lock(&priv->spi_lock);
> memcpy(priv->spi_tx_buf, buf, TXBDAT_OFF + len);
> mcp251x_spi_trans(spi, TXBDAT_OFF + len);
> - mutex_unlock(&priv->spi_lock);
> }
> }
>
> @@ -408,13 +404,9 @@ static void mcp251x_hw_rx_frame(struct spi_device *spi, u8 *buf,
> for (; i < (RXBDAT_OFF + len); i++)
> buf[i] = mcp251x_read_reg(spi, RXBCTRL(buf_idx) + i);
> } else {
> - mutex_lock(&priv->spi_lock);
> -
> priv->spi_tx_buf[RXBCTRL_OFF] = INSTRUCTION_READ_RXB(buf_idx);
> mcp251x_spi_trans(spi, SPI_TRANSFER_BUF_LEN);
> memcpy(buf, priv->spi_rx_buf, SPI_TRANSFER_BUF_LEN);
> -
> - mutex_unlock(&priv->spi_lock);
> }
> }
>
> @@ -467,21 +459,6 @@ static void mcp251x_hw_sleep(struct spi_device *spi)
> mcp251x_write_reg(spi, CANCTRL, CANCTRL_REQOP_SLEEP);
> }
>
> -static void mcp251x_hw_wakeup(struct spi_device *spi)
> -{
> - struct mcp251x_priv *priv = dev_get_drvdata(&spi->dev);
> -
> - priv->wake = 1;
> -
> - /* Can only wake up by generating a wake-up interrupt. */
> - mcp251x_write_bits(spi, CANINTE, CANINTE_WAKIE, CANINTE_WAKIE);
> - mcp251x_write_bits(spi, CANINTF, CANINTF_WAKIF, CANINTF_WAKIF);
> -
> - /* Wait until the device is awake */
> - if (!wait_for_completion_timeout(&priv->awake, HZ))
> - dev_err(&spi->dev, "MCP251x didn't wake-up\n");
> -}
> -
> static netdev_tx_t mcp251x_hard_start_xmit(struct sk_buff *skb,
> struct net_device *net)
> {
> @@ -490,7 +467,6 @@ static netdev_tx_t mcp251x_hard_start_xmit(struct sk_buff *skb,
>
> if (priv->tx_skb || priv->tx_len) {
> dev_warn(&spi->dev, "hard_xmit called while tx busy\n");
> - netif_stop_queue(net);
> return NETDEV_TX_BUSY;
> }
>
> @@ -511,12 +487,13 @@ static int mcp251x_do_set_mode(struct net_device *net, enum can_mode mode)
>
> switch (mode) {
> case CAN_MODE_START:
> + mcp251x_clean(net);
> /* We have to delay work since SPI I/O may sleep */
> priv->can.state = CAN_STATE_ERROR_ACTIVE;
> priv->restart_tx = 1;
> if (priv->can.restart_ms == 0)
> priv->after_suspend = AFTER_SUSPEND_RESTART;
> - queue_work(priv->wq, &priv->irq_work);
> + queue_work(priv->wq, &priv->restart_work);
> break;
> default:
> return -EOPNOTSUPP;
> @@ -525,7 +502,7 @@ static int mcp251x_do_set_mode(struct net_device *net, enum can_mode mode)
> return 0;
> }
>
> -static void mcp251x_set_normal_mode(struct spi_device *spi)
> +static int mcp251x_set_normal_mode(struct spi_device *spi)
> {
> struct mcp251x_priv *priv = dev_get_drvdata(&spi->dev);
> unsigned long timeout;
> @@ -533,8 +510,7 @@ static void mcp251x_set_normal_mode(struct spi_device *spi)
> /* Enable interrupts */
> mcp251x_write_reg(spi, CANINTE,
> CANINTE_ERRIE | CANINTE_TX2IE | CANINTE_TX1IE |
> - CANINTE_TX0IE | CANINTE_RX1IE | CANINTE_RX0IE |
> - CANINTF_MERRF);
> + CANINTE_TX0IE | CANINTE_RX1IE | CANINTE_RX0IE);
>
> if (priv->can.ctrlmode & CAN_CTRLMODE_LOOPBACK) {
> /* Put device into loopback mode */
> @@ -555,11 +531,12 @@ static void mcp251x_set_normal_mode(struct spi_device *spi)
> if (time_after(jiffies, timeout)) {
> dev_err(&spi->dev, "MCP251x didn't"
> " enter in normal mode\n");
> - return;
> + return -EBUSY;
> }
> }
> }
> priv->can.state = CAN_STATE_ERROR_ACTIVE;
> + return 0;
> }
>
> static int mcp251x_do_set_bittiming(struct net_device *net)
> @@ -590,33 +567,39 @@ static int mcp251x_setup(struct net_device *net, struct mcp251x_priv *priv,
> {
> mcp251x_do_set_bittiming(net);
>
> - /* Enable RX0->RX1 buffer roll over and disable filters */
> - mcp251x_write_bits(spi, RXBCTRL(0),
> - RXBCTRL_BUKT | RXBCTRL_RXM0 | RXBCTRL_RXM1,
> - RXBCTRL_BUKT | RXBCTRL_RXM0 | RXBCTRL_RXM1);
> - mcp251x_write_bits(spi, RXBCTRL(1),
> - RXBCTRL_RXM0 | RXBCTRL_RXM1,
> - RXBCTRL_RXM0 | RXBCTRL_RXM1);
> + mcp251x_write_reg(spi, RXBCTRL(0),
> + RXBCTRL_BUKT | RXBCTRL_RXM0 | RXBCTRL_RXM1);
> + mcp251x_write_reg(spi, RXBCTRL(1),
> + RXBCTRL_RXM0 | RXBCTRL_RXM1);
> return 0;
> }
>
> -static void mcp251x_hw_reset(struct spi_device *spi)
> +static int mcp251x_hw_reset(struct spi_device *spi)
> {
> struct mcp251x_priv *priv = dev_get_drvdata(&spi->dev);
> int ret;
> -
> - mutex_lock(&priv->spi_lock);
> + unsigned long timeout;
>
> priv->spi_tx_buf[0] = INSTRUCTION_RESET;
> -
> ret = spi_write(spi, priv->spi_tx_buf, 1);
> -
> - mutex_unlock(&priv->spi_lock);
> -
> - if (ret)
> + if (ret) {
> dev_err(&spi->dev, "reset failed: ret = %d\n", ret);
> + return -EIO;
> + }
> +
> /* Wait for reset to finish */
> + timeout = jiffies + HZ;
> mdelay(10);
> + while ((mcp251x_read_reg(spi, CANSTAT) & CANCTRL_REQOP_MASK)
> + != CANCTRL_REQOP_CONF) {
> + schedule();
> + if (time_after(jiffies, timeout)) {
> + dev_err(&spi->dev, "MCP251x didn't"
> + " enter in conf mode after reset\n");
> + return -EBUSY;
> + }
> + }
> + return 0;
> }
>
> static int mcp251x_hw_probe(struct spi_device *spi)
> @@ -640,63 +623,17 @@ static int mcp251x_hw_probe(struct spi_device *spi)
> return (st1 == 0x80 && st2 == 0x07) ? 1 : 0;
> }
>
> -static irqreturn_t mcp251x_can_isr(int irq, void *dev_id)
> -{
> - struct net_device *net = (struct net_device *)dev_id;
> - struct mcp251x_priv *priv = netdev_priv(net);
> -
> - /* Schedule bottom half */
> - if (!work_pending(&priv->irq_work))
> - queue_work(priv->wq, &priv->irq_work);
> -
> - return IRQ_HANDLED;
> -}
> -
> -static int mcp251x_open(struct net_device *net)
> +static void mcp251x_open_clean(struct net_device *net)
> {
> struct mcp251x_priv *priv = netdev_priv(net);
> struct spi_device *spi = priv->spi;
> struct mcp251x_platform_data *pdata = spi->dev.platform_data;
> - int ret;
> -
> - ret = open_candev(net);
> - if (ret) {
> - dev_err(&spi->dev, "unable to set initial baudrate!\n");
> - return ret;
> - }
>
> + free_irq(spi->irq, priv);
> + mcp251x_hw_sleep(spi);
> if (pdata->transceiver_enable)
> - pdata->transceiver_enable(1);
> -
> - priv->force_quit = 0;
> - priv->tx_skb = NULL;
> - priv->tx_len = 0;
> -
> - ret = request_irq(spi->irq, mcp251x_can_isr,
> - IRQF_TRIGGER_FALLING, DEVICE_NAME, net);
> - if (ret) {
> - dev_err(&spi->dev, "failed to acquire irq %d\n", spi->irq);
> - if (pdata->transceiver_enable)
> - pdata->transceiver_enable(0);
> - close_candev(net);
> - return ret;
> - }
> -
> - mcp251x_hw_wakeup(spi);
> - mcp251x_hw_reset(spi);
> - ret = mcp251x_setup(net, priv, spi);
> - if (ret) {
> - free_irq(spi->irq, net);
> - mcp251x_hw_sleep(spi);
> - if (pdata->transceiver_enable)
> - pdata->transceiver_enable(0);
> - close_candev(net);
> - return ret;
> - }
> - mcp251x_set_normal_mode(spi);
> - netif_wake_queue(net);
> -
> - return 0;
> + pdata->transceiver_enable(0);
> + close_candev(net);
> }
>
> static int mcp251x_stop(struct net_device *net)
> @@ -707,17 +644,19 @@ static int mcp251x_stop(struct net_device *net)
>
> close_candev(net);
>
> + priv->force_quit = 1;
> + free_irq(spi->irq, priv);
> + destroy_workqueue(priv->wq);
> + priv->wq = NULL;
> +
> + mutex_lock(&priv->mcp_lock);
> +
> /* Disable and clear pending interrupts */
> mcp251x_write_reg(spi, CANINTE, 0x00);
> mcp251x_write_reg(spi, CANINTF, 0x00);
>
> - priv->force_quit = 1;
> - free_irq(spi->irq, net);
> - flush_workqueue(priv->wq);
> -
> mcp251x_write_reg(spi, TXBCTRL(0), 0);
> - if (priv->tx_skb || priv->tx_len)
> - mcp251x_clean(net);
> + mcp251x_clean(net);
>
> mcp251x_hw_sleep(spi);
>
> @@ -726,9 +665,27 @@ static int mcp251x_stop(struct net_device *net)
>
> priv->can.state = CAN_STATE_STOPPED;
>
> + mutex_unlock(&priv->mcp_lock);
> +
> return 0;
> }
>
> +static void mcp251x_error_skb(struct net_device *net, int can_id, int data1)
> +{
> + struct sk_buff *skb;
> + struct can_frame *frame;
> +
> + skb = alloc_can_err_skb(net, &frame);
> + if (skb) {
> + frame->can_id = can_id;
> + frame->data[1] = data1;
> + netif_rx(skb);
> + } else {
> + dev_err(&net->dev,
> + "cannot allocate error skb\n");
> + }
> +}
> +
> static void mcp251x_tx_work_handler(struct work_struct *ws)
> {
> struct mcp251x_priv *priv = container_of(ws, struct mcp251x_priv,
> @@ -737,33 +694,32 @@ static void mcp251x_tx_work_handler(struct work_struct *ws)
> struct net_device *net = priv->net;
> struct can_frame *frame;
>
> + mutex_lock(&priv->mcp_lock);
> if (priv->tx_skb) {
> - frame = (struct can_frame *)priv->tx_skb->data;
> -
> if (priv->can.state == CAN_STATE_BUS_OFF) {
> mcp251x_clean(net);
> - netif_wake_queue(net);
> - return;
> + } else {
> + frame = (struct can_frame *)priv->tx_skb->data;
> +
> + if (frame->can_dlc > CAN_FRAME_MAX_DATA_LEN)
> + frame->can_dlc = CAN_FRAME_MAX_DATA_LEN;
> + mcp251x_hw_tx(spi, frame, 0);
> + priv->tx_len = 1 + frame->can_dlc;
> + can_put_echo_skb(priv->tx_skb, net, 0);
> + priv->tx_skb = NULL;
> }
> - if (frame->can_dlc > CAN_FRAME_MAX_DATA_LEN)
> - frame->can_dlc = CAN_FRAME_MAX_DATA_LEN;
> - mcp251x_hw_tx(spi, frame, 0);
> - priv->tx_len = 1 + frame->can_dlc;
> - can_put_echo_skb(priv->tx_skb, net, 0);
> - priv->tx_skb = NULL;
> }
> + mutex_unlock(&priv->mcp_lock);
> }
>
> -static void mcp251x_irq_work_handler(struct work_struct *ws)
> +static void mcp251x_restart_work_handler(struct work_struct *ws)
> {
> struct mcp251x_priv *priv = container_of(ws, struct mcp251x_priv,
> - irq_work);
> + restart_work);
> struct spi_device *spi = priv->spi;
> struct net_device *net = priv->net;
> - u8 txbnctrl;
> - u8 intf;
> - enum can_state new_state;
>
> + mutex_lock(&priv->mcp_lock);
> if (priv->after_suspend) {
> mdelay(10);
> mcp251x_hw_reset(spi);
> @@ -772,45 +728,54 @@ static void mcp251x_irq_work_handler(struct work_struct *ws)
> mcp251x_set_normal_mode(spi);
> } else if (priv->after_suspend & AFTER_SUSPEND_UP) {
> netif_device_attach(net);
> - /* Clean since we lost tx buffer */
> - if (priv->tx_skb || priv->tx_len) {
> - mcp251x_clean(net);
> - netif_wake_queue(net);
> - }
> + mcp251x_clean(net);
> mcp251x_set_normal_mode(spi);
> + netif_wake_queue(net);
> } else {
> mcp251x_hw_sleep(spi);
> }
> priv->after_suspend = 0;
> + priv->force_quit = 0;
> }
>
> - if (priv->can.restart_ms == 0 && priv->can.state == CAN_STATE_BUS_OFF)
> - return;
> + if (priv->restart_tx) {
> + priv->restart_tx = 0;
> + mcp251x_write_reg(spi, TXBCTRL(0), 0);
> + mcp251x_clean(net);
> + netif_wake_queue(net);
> + mcp251x_error_skb(net, CAN_ERR_RESTARTED, 0);
> + }
> + mutex_unlock(&priv->mcp_lock);
> +}
>
> - while (!priv->force_quit && !freezing(current)) {
> - u8 eflag = mcp251x_read_reg(spi, EFLG);
> - int can_id = 0, data1 = 0;
> +static irqreturn_t mcp251x_can_ist(int irq, void *dev_id)
> +{
> + struct mcp251x_priv *priv = dev_id;
> + struct spi_device *spi = priv->spi;
> + struct net_device *net = priv->net;
>
> - mcp251x_write_reg(spi, EFLG, 0x00);
> + mutex_lock(&priv->mcp_lock);
> + while (!priv->force_quit) {
> + enum can_state new_state;
> + u8 intf = mcp251x_read_reg(spi, CANINTF);
> + u8 eflag;
> + int can_id = 0, data1 = 0;
>
> - if (priv->restart_tx) {
> - priv->restart_tx = 0;
> - mcp251x_write_reg(spi, TXBCTRL(0), 0);
> - if (priv->tx_skb || priv->tx_len)
> - mcp251x_clean(net);
> - netif_wake_queue(net);
> - can_id |= CAN_ERR_RESTARTED;
> + if (intf & CANINTF_RX0IF) {
> + mcp251x_hw_rx(spi, 0);
> + /* Free one buffer ASAP */
> + mcp251x_write_bits(spi, CANINTF, intf & CANINTF_RX0IF,
> + 0x00);
> }
>
> - if (priv->wake) {
> - /* Wait whilst the device wakes up */
> - mdelay(10);
> - priv->wake = 0;
> - }
> + if (intf & CANINTF_RX1IF)
> + mcp251x_hw_rx(spi, 1);
>
> - intf = mcp251x_read_reg(spi, CANINTF);
> mcp251x_write_bits(spi, CANINTF, intf, 0x00);
>
> + eflag = mcp251x_read_reg(spi, EFLG);
> + mcp251x_write_reg(spi, EFLG, 0x00);
> +
> /* Update can state */
> if (eflag & EFLG_TXBO) {
> new_state = CAN_STATE_BUS_OFF;
> @@ -851,59 +816,31 @@ static void mcp251x_irq_work_handler(struct work_struct *ws)
> }
> priv->can.state = new_state;
>
> - if ((intf & CANINTF_ERRIF) || (can_id & CAN_ERR_RESTARTED)) {
> - struct sk_buff *skb;
> - struct can_frame *frame;
> -
> - /* Create error frame */
> - skb = alloc_can_err_skb(net, &frame);
> - if (skb) {
> - /* Set error frame flags based on bus state */
> - frame->can_id = can_id;
> - frame->data[1] = data1;
> -
> - /* Update net stats for overflows */
> - if (eflag & (EFLG_RX0OVR | EFLG_RX1OVR)) {
> - if (eflag & EFLG_RX0OVR)
> - net->stats.rx_over_errors++;
> - if (eflag & EFLG_RX1OVR)
> - net->stats.rx_over_errors++;
> - frame->can_id |= CAN_ERR_CRTL;
> - frame->data[1] |=
> - CAN_ERR_CRTL_RX_OVERFLOW;
> - }
> -
> - netif_rx(skb);
> - } else {
> - dev_info(&spi->dev,
> - "cannot allocate error skb\n");
> + if (intf & CANINTF_ERRIF) {
> + /* Handle overflow counters */
> + if (eflag & (EFLG_RX0OVR | EFLG_RX1OVR)) {
> + if (eflag & EFLG_RX0OVR)
> + net->stats.rx_over_errors++;
> + if (eflag & EFLG_RX1OVR)
> + net->stats.rx_over_errors++;
> + can_id |= CAN_ERR_CRTL;
> + data1 |= CAN_ERR_CRTL_RX_OVERFLOW;
> }
> + mcp251x_error_skb(net, can_id, data1);
> }
>
> if (priv->can.state == CAN_STATE_BUS_OFF) {
> if (priv->can.restart_ms == 0) {
> + priv->force_quit = 1;
> can_bus_off(net);
> mcp251x_hw_sleep(spi);
> - return;
> + break;
> }
> }
>
> if (intf == 0)
> break;
>
> - if (intf & CANINTF_WAKIF)
> - complete(&priv->awake);
> -
> - if (intf & CANINTF_MERRF) {
> - /* If there are pending Tx buffers, restart queue */
> - txbnctrl = mcp251x_read_reg(spi, TXBCTRL(0));
> - if (!(txbnctrl & TXBCTRL_TXREQ)) {
> - if (priv->tx_skb || priv->tx_len)
> - mcp251x_clean(net);
> - netif_wake_queue(net);
> - }
> - }
> -
> if (intf & (CANINTF_TX2IF | CANINTF_TX1IF | CANINTF_TX0IF)) {
> net->stats.tx_packets++;
> net->stats.tx_bytes += priv->tx_len - 1;
> @@ -914,12 +851,66 @@ static void mcp251x_irq_work_handler(struct work_struct *ws)
> netif_wake_queue(net);
> }
>
> - if (intf & CANINTF_RX0IF)
> - mcp251x_hw_rx(spi, 0);
> + }
> + mutex_unlock(&priv->mcp_lock);
> + return IRQ_HANDLED;
> +}
>
> - if (intf & CANINTF_RX1IF)
> - mcp251x_hw_rx(spi, 1);
> +static int mcp251x_open(struct net_device *net)
> +{
> + struct mcp251x_priv *priv = netdev_priv(net);
> + struct spi_device *spi = priv->spi;
> + struct mcp251x_platform_data *pdata = spi->dev.platform_data;
> + int ret;
> +
> + ret = open_candev(net);
> + if (ret) {
> + dev_err(&spi->dev, "unable to set initial baudrate!\n");
> + return ret;
> + }
> +
> + mutex_lock(&priv->mcp_lock);
> + if (pdata->transceiver_enable)
> + pdata->transceiver_enable(1);
> +
> + priv->force_quit = 0;
> + priv->tx_skb = NULL;
> + priv->tx_len = 0;
> +
> + ret = request_threaded_irq(spi->irq, NULL, mcp251x_can_ist,
> + IRQF_TRIGGER_FALLING, DEVICE_NAME, priv);
> + if (ret) {
> + dev_err(&spi->dev, "failed to acquire irq %d\n", spi->irq);
> + if (pdata->transceiver_enable)
> + pdata->transceiver_enable(0);
> + close_candev(net);
> + goto open_unlock;
> + }
> +
> + priv->wq = create_freezeable_workqueue("mcp251x_wq");
> + INIT_WORK(&priv->tx_work, mcp251x_tx_work_handler);
> + INIT_WORK(&priv->restart_work, mcp251x_restart_work_handler);
> +
> + ret = mcp251x_hw_reset(spi);
> + if (ret) {
> + mcp251x_open_clean(net);
> + goto open_unlock;
> + }
> + ret = mcp251x_setup(net, priv, spi);
> + if (ret) {
> + mcp251x_open_clean(net);
> + goto open_unlock;
> }
> + ret = mcp251x_set_normal_mode(spi);
> + if (ret) {
> + mcp251x_open_clean(net);
> + goto open_unlock;
> + }
> + netif_wake_queue(net);
> +
> +open_unlock:
> + mutex_unlock(&priv->mcp_lock);
> + return ret;
> }
>
> static const struct net_device_ops mcp251x_netdev_ops = {
> @@ -961,7 +952,7 @@ static int __devinit mcp251x_can_probe(struct spi_device *spi)
> dev_set_drvdata(&spi->dev, priv);
>
> priv->spi = spi;
> - mutex_init(&priv->spi_lock);
> + mutex_init(&priv->mcp_lock);
>
> /* If requested, allocate DMA buffers */
> if (mcp251x_enable_dma) {
> @@ -1010,18 +1001,12 @@ static int __devinit mcp251x_can_probe(struct spi_device *spi)
>
> SET_NETDEV_DEV(net, &spi->dev);
>
> - priv->wq = create_freezeable_workqueue("mcp251x_wq");
> -
> - INIT_WORK(&priv->tx_work, mcp251x_tx_work_handler);
> - INIT_WORK(&priv->irq_work, mcp251x_irq_work_handler);
> -
> - init_completion(&priv->awake);
> -
> /* Configure the SPI bus */
> spi->mode = SPI_MODE_0;
> spi->bits_per_word = 8;
> spi_setup(spi);
>
> + /* Here is OK to not lock the MCP, no one knows about it yet */
> if (!mcp251x_hw_probe(spi)) {
> dev_info(&spi->dev, "Probe failed\n");
> goto error_probe;
> @@ -1064,10 +1049,6 @@ static int __devexit mcp251x_can_remove(struct spi_device *spi)
> unregister_candev(net);
> free_candev(net);
>
> - priv->force_quit = 1;
> - flush_workqueue(priv->wq);
> - destroy_workqueue(priv->wq);
> -
> if (mcp251x_enable_dma) {
> dma_free_coherent(&spi->dev, PAGE_SIZE,
> priv->spi_tx_buf, priv->spi_tx_dma);
> @@ -1089,6 +1070,12 @@ static int mcp251x_can_suspend(struct spi_device *spi, pm_message_t state)
> struct mcp251x_priv *priv = dev_get_drvdata(&spi->dev);
> struct net_device *net = priv->net;
>
> + priv->force_quit = 1;
> + disable_irq(spi->irq);
> + /*
> + * Note: at this point neither IST nor workqueues are running.
> + * open/stop cannot be called anyway so locking is not needed
> + */
> if (netif_running(net)) {
> netif_device_detach(net);
>
> @@ -1115,16 +1102,18 @@ static int mcp251x_can_resume(struct spi_device *spi)
>
> if (priv->after_suspend & AFTER_SUSPEND_POWER) {
> pdata->power_enable(1);
> - queue_work(priv->wq, &priv->irq_work);
> + queue_work(priv->wq, &priv->restart_work);
> } else {
> if (priv->after_suspend & AFTER_SUSPEND_UP) {
> if (pdata->transceiver_enable)
> pdata->transceiver_enable(1);
> - queue_work(priv->wq, &priv->irq_work);
> + queue_work(priv->wq, &priv->restart_work);
> } else {
> priv->after_suspend = 0;
> }
> }
> + priv->force_quit = 0;
> + enable_irq(spi->irq);
> return 0;
> }
> #else
> --
> 1.5.6.5
>
>
--
Christian Pellegrin, see http://www.evolware.org/chri/
"Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room."
^ permalink raw reply
* [PATCH 02/86] dccp: revert buggy auto-loading of dccp module
From: Gerrit Renker @ 2010-02-01 6:18 UTC (permalink / raw)
To: davem; +Cc: dccp, netdev, Gerrit Renker
In-Reply-To: <1265005087-5549-2-git-send-email-gerrit@erg.abdn.ac.uk>
This reverts commit (38ff3e6bb987ec583268da8eb22628293095d43b) ("dccp_probe:
Fix module load dependencies between dccp and dccp_probe", from 15 Jan). Not
only does it not work:
% modprobe -v dccp_probe
kernel: [ 1431.442912] sys_init_module: 'dccp_probe'->init suspiciously \
returned 1, it should follow 0/-E convention
kernel: [ 1431.442915] sys_init_module: loading module anyway...
... but it also causes a crash:
% rmmod dccp_probe
kernel: [ 1777.305846] kernel BUG at /usr/src/davem-2.6/mm/slab.c:521!
kernel: [ 1777.305852] invalid opcode: 0000 [#1] SMP
kernel: [ 1777.305861] last sysfs file: /sys/class/power_supply/BAT0/energy_full
kernel: [ 1777.305867] Modules linked in: dccp_probe(-) iwl3945 iwlcore [last unloaded: dccp]
kernel: [ 1777.305883]
kernel: [ 1777.305891] Pid: 12912, comm: rmmod Tainted: G R 2.6.33-rc5 #6 2008URG/2008URG
kernel: [ 1777.305899] EIP: 0060:[<c01d5e43>] EFLAGS: 00010046 CPU: 1
kernel: [ 1777.305910] EIP is at kfree+0x73/0x150
kernel: [ 1777.305916] EAX: c1678c00 EBX: 00000000 ECX: c01d5e15 EDX: 40080000
kernel: [ 1777.305922] ESI: c015cb9a EDI: 080488a0 EBP: f4ffbf34 ESP: f4ffbf10
kernel: [ 1777.305929] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
kernel: [ 1777.305936] Process rmmod (pid: 12912, ti=f4ffb000 task=f61e8620 task.ti=f4ffb000)
==> After reverting the commit:
% modprobe -v dccp_probe
insmod /lib/modules/2.6.33-rc5/kernel/net/dccp/dccp.ko
insmod /lib/modules/2.6.33-rc5/kernel/net/dccp/dccp_probe.ko
% lsmod
Module Size Used by
dccp_probe 2345 0
dccp 120233 1 dccp_probe
Previously (during about 4 years of this module's history) there had never
been a problem with the 'silent dependency' that the commit tried to fix:
this dependency is deliberate and required, since dccp_probe performs probing
of dccp connections and hence needs to know about dccp internals.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/probe.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
--- a/net/dccp/probe.c
+++ b/net/dccp/probe.c
@@ -161,8 +161,7 @@ static __init int dccpprobe_init(void)
if (!proc_net_fops_create(&init_net, procname, S_IRUSR, &dccpprobe_fops))
goto err0;
- ret = try_then_request_module((register_jprobe(&dccp_send_probe) == 0),
- "dccp");
+ ret = register_jprobe(&dccp_send_probe);
if (ret)
goto err1;
^ permalink raw reply
* [PATCH 01/86] dccp: fix bug in cache allocation
From: Gerrit Renker @ 2010-02-01 6:18 UTC (permalink / raw)
To: davem; +Cc: dccp, netdev, Gerrit Renker
In-Reply-To: <1265005087-5549-1-git-send-email-gerrit@erg.abdn.ac.uk>
This fixes a bug introduced in commit de4ef86cfce60d2250111f34f8a084e769f23b16
("dccp: fix dccp rmmod when kernel configured to use slub", 17 Jan): the
vsnprintf used sizeof(slab_name_fmt), which became truncated to 4 bytes, since
slab_name_fmt is now a 4-byte pointer and no longer a 32-character array.
This lead to error messages such as
FATAL: Error inserting dccp: No buffer space available
>> kernel: [ 1456.341501] kmem_cache_create: duplicate cache cci
generated due to the truncation after the 3rrdc character.
Fixed for the moment by introducing a symbolic constant. Tested to fix the bug.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/ccid.c | 2 +-
net/dccp/ccid.h | 8 +++++---
2 files changed, 6 insertions(+), 4 deletions(-)
--- a/net/dccp/ccid.c
+++ b/net/dccp/ccid.c
@@ -83,7 +83,7 @@ static struct kmem_cache *ccid_kmem_cache_create(int obj_size, char *slab_name_f
va_list args;
va_start(args, fmt);
- vsnprintf(slab_name_fmt, sizeof(slab_name_fmt), fmt, args);
+ vsnprintf(slab_name_fmt, CCID_SLAB_NAME_LENGTH, fmt, args);
va_end(args);
slab = kmem_cache_create(slab_name_fmt, sizeof(struct ccid) + obj_size, 0,
--- a/net/dccp/ccid.h
+++ b/net/dccp/ccid.h
@@ -19,7 +19,9 @@
#include <linux/list.h>
#include <linux/module.h>
-#define CCID_MAX 255
+/* maximum value for a CCID (RFC 4340, 19.5) */
+#define CCID_MAX 255
+#define CCID_SLAB_NAME_LENGTH 32
struct tcp_info;
@@ -49,8 +51,8 @@ struct ccid_operations {
const char *ccid_name;
struct kmem_cache *ccid_hc_rx_slab,
*ccid_hc_tx_slab;
- char ccid_hc_rx_slab_name[32];
- char ccid_hc_tx_slab_name[32];
+ char ccid_hc_rx_slab_name[CCID_SLAB_NAME_LENGTH];
+ char ccid_hc_tx_slab_name[CCID_SLAB_NAME_LENGTH];
__u32 ccid_hc_rx_obj_size,
ccid_hc_tx_obj_size;
/* Interface Routines */
^ permalink raw reply
* [BUG-FIX][PATCH 0/2]: recent dccp fixes
From: Gerrit Renker @ 2010-02-01 6:18 UTC (permalink / raw)
To: davem; +Cc: dccp, netdev
In-Reply-To: <recent-dccp-bug-fixes-jan-2010>
In January there were two dccp commits introducing bugs. Having
been guilty of ack-ing them, please find below patches to fix
them.
Patch #1: fixes a bug resulting from truncating cache name length.
Patch #2: reverts a commit which introduced a module-loading bug.
This being bugs, would you please consider this for stable too.
The test-tree also has been fixed accordingly,
http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=dccp_exp.git;a=shortlog;h=ready
^ permalink raw reply
* socket layer incorrectness
From: Lv Zheng @ 2010-02-01 5:05 UTC (permalink / raw)
To: netdev
Hi, all
I'm new to this mailing list. Please forgive me if this mail is
interrupting you.
I read the kernel socket layer implementation recently.
Wondering whether one can kindly make some detailed explaination
for me, I sent this email to the netdev mailing list.
==================================================
I noted BSD had presented socket API as follows:
socket(family, type, protocol)
Which means there should be sth. like:
sock_register_family
sock_register_type
sock_register_protocol
in the world.
As far as these abstractions are concerned, struct sock should be:
struct sock {
struct family_ops *family_ops;
struct sock_type_ops *type_ops;
struct proto_ops *proto_ops;
};
==================================================
A. family abstaction
For family, I think it looks like a protocol factory, and owns
create/release ops might be enough for family_ops just like current
kernel does.
B. type abstaction
For type, we have SOCK_STREAM, SOCK_DGRAM, SOCK_RAW
for INET:
1. SOCK_STREAM: buffer requeued orderly for the upper level
protocol layer without lower level protocol's head/tail.
2. SOCK_DGRAM: buffer defrag/fraged aligning lower level
protocol's content due to lower level's MTU without lower level
protocol's head/tail.
3. SOCK_RAW: buffer is copied directly from lower level queue.
If socket is implemented in this way, defrag/frag/streaming can go
into the socket layer and we can involve hardware as much as it
could to accelarate fragmentation and streaming.
But currently we do not have type abstraction in the Linux kernel.
C. protocol abstaction
For protocol, we have proto_register in the kernel, but it does not
affect sock_create. In the socket layer, only /proc/net/protocols is
affected by such registration, proto_ops is mostly a family specific
implementation.
proto_ops should not related to the socket operations which should
be type_ops' responsibility while current kernel takes proto_ops as
type_ops.
IMO, proto_ops should contain operations as head/tail analysis,
buffer ordering determination and so on.
==================================================
Can someone tell me why current Linux kernel is not implemented in
the way that BSD socket abstraction tells us to do?
Best regards/Lv Zheng
^ permalink raw reply
* Re: [PATCH] sky2: receive dma mapping error handling
From: Michael Breuer @ 2010-02-01 4:26 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Stephen Hemminger, David Miller, akpm, flyboy, linux-kernel,
netdev, Michael Chan, Don Fry, Francois Romieu, Matt Carlson
In-Reply-To: <4B661E22.8090907@majjas.com>
On 1/31/2010 7:19 PM, Michael Breuer wrote:
> On 1/31/2010 5:18 PM, Jarek Poplawski wrote:
> solves the dma-debug issue - i.e., elements are now being unmapped.
>
> Will leave up and hit with traffic unless a crash occurs. If I hit
> something unrelated I'll backport to 2.6.32.7 and try that for a
> while. I do think it's plausible that the dma errors after (during)
> load were due to hardware limitations on the number of mapped entries
> (haven't researched what that limit was). I would also assume that the
> sw map would also have failed eventually.
>
> I'd suggest that regardless of whether this patch solves my crash that
> it ought to be backported as it seems unlikely that any machine would
> be able to survive for long without the tx entries being unmapped.
>
FYI - tried generating lots of extra tx traffic... found a way to
generate the rx status messages on demand:
ping -i .0000001 -s 8000 -t 2 <host> >/dev/null
Yields:
Jan 31 23:08:07 mail kernel: sky2 eth0: rx error, status 0x1f6a0010
length 1518
Jan 31 23:08:07 mail kernel: sky2 eth0: rx error, status 0x1f6a0010
length 1518
Jan 31 23:08:07 mail kernel: sky2 eth0: rx error, status 0x1f6a0010
length 1518
Jan 31 23:08:07 mail kernel: sky2 eth0: rx error, status 0x1f6a0010
length 1518
Jan 31 23:08:07 mail kernel: sky2 eth0: rx error, status 0x1f6a0010
length 1518
Jan 31 23:08:07 mail kernel: sky2 eth0: rx error, status 0x1f6a0010
length 1518
Jan 31 23:08:07 mail kernel: sky2 eth0: rx error, status 0x1f6a0010
length 1518
Jan 31 23:08:07 mail kernel: sky2 eth0: rx error, status 0x1f6a0010
length 1518
Jan 31 23:08:07 mail kernel: sky2 eth0: rx error, status 0x1f6a0010
length 1518
Jan 31 23:08:07 mail kernel: sky2 eth0: rx error, status 0x1f6a0010
length 1518
Jan 31 23:08:12 mail kernel: net_ratelimit: 316 callbacks suppressed
etc.
Looking at the packet trace, it seems that my Windows7 box is under
*some* circumstances not observing the MTU. In this case, the ICMP reply
is going back with the 8000 byte jumbo frame unfragmented. It seems that
the reverse is also true. I don't know why sometimes win7 does this, and
at other times properly fragments.
Oddly, prior to this attempt if I set no fragment on a ping from the
windows box back to the linux box and a size of > mtu (like 8000), the
ping failed. Absent the no-fragment flag, the ping properly fragmented.
I am not sure why Windows now thinks the MTU is > 1500. I'll look into
that when I have some time. It's possible that with 2.6.33-rc5 & the
patches I've got that somehow path mtu discovery is broken as nothing
changed on the windows side.
Understanding that the other side is out of spec, I'd still wonder why
the sky2 driver generates rx errors. Perhaps overruns should be tossed
silently... by the hardware if possible.
^ permalink raw reply
* Re: [PATCH 5/8] percpu: add __percpu sparse annotations to x86
From: H. Peter Anvin @ 2010-02-01 3:30 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-kernel, axboe, rusty, akpm, ebiederm, tytso,
Trond.Myklebust, aelder, hch, viro, davem, netdev, x86, mingo,
fweisbec, dan.j.williams, borislav.petkov, ying.huang, lenb,
neilb, cl, Thomas Gleixner
In-Reply-To: <4B5E50D0.8050705@kernel.org>
On 01/25/2010 06:17 PM, Tejun Heo wrote:
> On 01/26/2010 10:06 AM, H. Peter Anvin wrote:
>> On 01/25/2010 07:22 AM, Tejun Heo wrote:
>>>
>>> In arch/x86/kernel/cpu/common.c, per_cpu(exception_stacks, cpu) is
>>> replaced with &per_cpu(exception_stacks[0], cpu) which is equivalent
>>> except that it allows per_cpu() macro to correctly drop percpu
>>> designation during sparse pass.
>>>
>>
>> Same comment as Frederic's about this... this kind of uglification
>> really is unacceptable and needs to be addressed.
>
> Hmm... I don't think it's too bad but if you don't like it that much,
> probably the right thing to do is just leave it there and let sparse
> whine about it. There are only three in-kernel instances at this
> point, so it's not that big a deal.
>
That would probably be my preference until it can be fixed in a better
way. If we paper it over now, it will be forgotten -- and then someone
will come along and cargo cult it for no good reason.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [PATCH] nodmask.h: remove macro any_online_node
From: Benjamin Herrenschmidt @ 2010-02-01 2:05 UTC (permalink / raw)
To: H Hartley Sweeten
Cc: Linux Kernel, linuxppc-dev-mnsaURCQ41sdnm+yROfE0A,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
rientjes-hpIqsD4AKlfQT0dZR+AlfA,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A,
mel-wPRd99KPJ+uzQB+pC5nmwQ, lee.schermerhorn-VXdhtT5mjnY,
paulus-eUNUBHrolfbYtjvyW6yDsg,
dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8, miltonm-ogEGBHC/i9Y,
nfont-V7BBcbaFuwjMbYB6QlFGEg,
geoffrey.levand-mEdOJwZ7QcZBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ,
bfields-uC3wQj2KruNg9hUCZPvPmw, neilb-l3A5Bk7waGM,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, bhalevy-C4P08NqkoRlBDgjK7y7TUQ,
chuck.lever-QHcLZuEGTsvQT0dZR+AlfA,
Ricardo.Labiaga-HgOvQuBEEgTQT0dZR+AlfA
In-Reply-To: <201001061624.59118.hartleys-3FF4nKcrg1dE2c76skzGb0EOCMrvLtNR@public.gmane.org>
On Wed, 2010-01-06 at 16:24 -0700, H Hartley Sweeten wrote:
> nodmask.h: remove macro any_online_node
>
> The macro any_online_node is prone to producing sparse warnings
> due to the local symbol 'node'. Since all the in-tree users are really
> requesting the first online node (the mask argument is either
> NODE_MASK_ALL or node_online_map) just use the first_online_node
> macro and remove the any_online_node macro since there are no users.
>
> Signed-off-by: H Hartley Sweeten <hsweeten-3FF4nKcrg1dE2c76skzGb0EOCMrvLtNR@public.gmane.org>
> Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
> Cc: David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
> Cc: Mel Gorman <mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org>
> Cc: Lee Schermerhorn <lee.schermerhorn-VXdhtT5mjnY@public.gmane.org>
Acked-by: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> Cc: Paul Mackerras <paulus-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
> Cc: Dave Hansen <dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> Cc: Milton Miller <miltonm-ogEGBHC/i9Y@public.gmane.org>
> Cc: Nathan Fontenot <nfont-V7BBcbaFuwjMbYB6QlFGEg@public.gmane.org>
> Cc: Geoff Levand <geoffrey.levand-mEdOJwZ7QcZBDgjK7y7TUQ@public.gmane.org>
> Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> Cc: J. Bruce Fields <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
> Cc: Neil Brown <neilb-l3A5Bk7waGM@public.gmane.org>
> Cc: Trond Myklebust <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
> Cc: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Cc: Benny Halevy <bhalevy-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org>
> Cc: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Cc: Ricardo Labiaga <Ricardo.Labiaga-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 2.6.33-rc6: Reported regressions 2.6.31 -> 2.6.32
From: Rafael J. Wysocki @ 2010-02-01 0:38 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
[NOTE:
* Still growing faster than we're fixing them.]
This message contains a list of some regressions introduced between 2.6.31 and
2.6.32, for which there are no fixes in the mainline I know of. If any of them
have been fixed already, please let me know.
If you know of any other unresolved regressions introduced between 2.6.31
and 2.6.32, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-02-01 149 50 45
2010-01-24 140 45 43
2010-01-10 130 44 40
2009-12-29 124 60 57
2009-11-21 86 29 25
2009-11-16 84 46 41
2009-10-26 66 42 37
2009-10-12 48 31 27
2009-10-02 22 15 9
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15193
Subject : kswapd continuously active
Submitter : Jan Engelhardt <jengelh@medozas.de>
Date : 2010-01-22 23 (10 days old)
References : http://marc.info/?l=linux-kernel&m=126420434519039&w=4
Handled-By : Jens Axboe <jens.axboe@oracle.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15158
Subject : oops related to i915_gem_object_save_bit_17_swizzle
Submitter : Werner Lemberg <wl@gnu.org>
Date : 2010-01-28 08:26 (4 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15156
Subject : 2.6.32.6 hang at boot with ati x1600
Submitter : Alexey Kuznetsov <ak@axet.ru>
Date : 2010-01-28 05:02 (4 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15127
Subject : Bluetooth: sleeping function called from invalid context
Submitter : David John <davidjon@xenontk.org>
Date : 2010-01-12 9:19 (20 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9e726b17422bade75fba94e625cd35fd1353e682
References : http://marc.info/?l=linux-kernel&m=126328727021949&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15108
Subject : Blank screen with KMS enabled (on clevo M5xN laptop)
Submitter : Jérémy Lal <kapouer@melix.org>
Date : 2010-01-22 20:30 (10 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15100
Subject : X11 is black after resume from s2ram if my T400 was previous in docking station before
Submitter : Toralf Förster <toralf.foerster@gmx.de>
Date : 2010-01-21 08:56 (11 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c1c7af60892070e4b82ad63bbfb95ae745056de0
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15096
Subject : Resume lock up -- bisected, commit 3a1151e3f124fd1a2c54b8153f510f1a7c715369
Submitter : Rafał Miłecki <zajec5@gmail.com>
Date : 2010-01-20 23:15 (12 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3a1151e3f124fd1a2c54b8153f510f1a7c715369
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15071
Subject : IBM/Lenovo Trackpoint speed, sensitivity reset after suspend
Submitter : Marten Vance <kernel@mv.so36.net>
Date : 2010-01-16 16:19 (16 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15042
Subject : socket(PF_INET6 hangs when ipv6 not yet initialized
Submitter : Marc Haber <mh+linux-kernel@zugschlus.de>
Date : 2010-01-10 14:28 (22 days old)
References : http://marc.info/?l=linux-kernel&m=126313553029280&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15021
Subject : agpgart sometimes fails to initialize sometimes
Submitter : Maciej Piechotka <uzytkownik2@gmail.com>
Date : 2010-01-09 23:31 (23 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15015
Subject : blank screen at random times in laptop when sitting idle
Submitter : Jithin Emmanuel <jithin1987@gmail.com>
Date : 2010-01-09 16:48 (23 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15004
Subject : i915: *ERROR* Execbuf while wedged
Submitter : tomas m <tmezzadra@gmail.com>
Date : 2010-01-07 18:53 (25 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15000
Subject : Thinkpad dock button no longer works
Submitter : Paul Martin <pm@debian.org>
Date : 2010-01-07 02:11 (25 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14998
Subject : Caught 32-bit read from uninitialized memory in acpi_system_read_event -- 2.6.31 regression
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2010-01-06 21:40 (26 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=eca6f534e61919b28fb21aafbd1c2983deae75be
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14997
Subject : Closing and re-opening the lid does not reactivate the backlight
Submitter : o. meijer <meijer.o@gmail.com>
Date : 2010-01-06 15:38 (26 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14943
Subject : nfs regression?
Submitter : Nikola Ciprich <extmaillist@linuxbox.cz>
Date : 2009-12-28 12:10 (35 days old)
References : http://marc.info/?l=linux-kernel&m=126200276223524&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14939
Subject : drm: random hang with i915
Submitter : Arnd Bergmann <arnd@arndb.de>
Date : 2009-12-07 17:30 (56 days old)
References : http://marc.info/?l=linux-kernel&m=126020704125723&w=4
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14922
Subject : 2.6.32 seemed to have broken nVidia MCP7A sata controller
Submitter : Mike Cui <cuicui@gmail.com>
Date : 2009-12-19 6:13 (44 days old)
References : http://marc.info/?l=linux-ide&m=126120323407742&w=4
Handled-By : Jeff Garzik <jeff@garzik.org>
Robert Hancock <hancockrwd@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14898
Subject : ksoftirqd problem
Submitter : Nico <segfault2@hotmail.com>
Date : 2009-12-13 19:05 (50 days old)
References : http://marc.info/?l=linux-kernel&m=126073114325690&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14895
Subject : BUG in kernel 2.6.32 when using luks encrypted root and RAID0..
Submitter : r4 <mk_4@centrum.cz>
Date : 2009-12-03 18:24 (60 days old)
References : http://marc.info/?l=linux-kernel&m=125986664904751&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14894
Subject : pohmelfs: NULL pointer dereference
Submitter : Alexander Beregalov <a.beregalov@gmail.com>
Date : 2009-12-02 1:11 (61 days old)
References : http://marc.info/?l=linux-kernel&m=125971633107940&w=4
Handled-By : Evgeniy Polyakov <zbr@ioremap.net>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14891
Subject : Deadlock regression related to NFS root
Submitter : Stephen R. van den Berg <srb@cuci.nl>
Date : 2009-11-24 0:24 (69 days old)
References : http://marc.info/?l=linux-kernel&m=125902279909452&w=4
Handled-By : Trond Myklebust <Trond.Myklebust@netapp.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14886
Subject : Asus P2B-DS not detected as SMP moterboard
Submitter : Lorenzo Buzzi <flinco@libero.it>
Date : 2009-12-27 17:20 (36 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e5b8fc6ac158f65598f58dba2c0d52ba3b412f52
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14868
Subject : flood of "don't try to register things with the same name in the same directory." on upgrade to 2.6.32
Submitter : Rich Ercolani <rercola@acm.jhu.edu>
Date : 2009-12-24 02:44 (39 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14817
Subject : When is system under load, then freeze/HD fail
Submitter : okias <d.okias@gmail.com>
Date : 2009-12-15 11:12 (48 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14783
Subject : Unhandled IRQ on Thinkpad R61i: "irq 16: nobody cared"
Submitter : Stefan Zegenhagen <sz@emlix.com>
Date : 2009-12-10 19:14 (53 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14782
Subject : Suspend hangs Lenovo SL300 after gdm login
Submitter : Gary Trakhman <gary.trakhman@gmail.com>
Date : 2009-12-10 18:53 (53 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=03ba3782e8dcc5b0e1efe440d33084f066e38cae
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14748
Subject : e1000e NIC not working after reboot
Submitter : Maciek Sitarz <macieks@freesco.pl>
Date : 2009-12-06 13:04 (57 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14742
Subject : 2.6.32 new menu idle governor causes very high CPU temp
Submitter : <akwatts@ymail.com>
Date : 2009-12-05 17:24 (58 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14695
Subject : regression in karmic thermal control
Submitter : Bugie <public@bugie.de>
Date : 2009-11-26 08:45 (67 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14670
Subject : i915: playing video via XVideo extension makes the screen flicker
Submitter : Thomas Meyer <thomas@m3y3r.de>
Date : 2009-11-23 13:15 (70 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b42d4c5c6a872815d711e5d51a600f5122c38eee
References : http://lkml.org/lkml/2010/1/11/150
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14668
Subject : Resume from disk hangs in acpi_ex_acquire_global_lock
Submitter : Maxim Levitsky <maximlevitsky@gmail.com>
Date : 2009-11-22 21:25 (71 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14667
Subject : bisected 2.6.32 EC regression - Temperatures not correctly detected after suspend - Dell Studio XPS 16 laptop
Submitter : Federico Chiacchiaretta <federico.chia@gmail.com>
Date : 2009-11-22 20:42 (71 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6a63b06f3c494cc87eade97f081300bda60acec7
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14657
Subject : perf subsystem breakage in 2.6.32-rc7
Submitter : Arjan van de Ven <arjan@infradead.org>
Date : 2009-11-19 19:50 (74 days old)
References : http://marc.info/?l=linux-kernel&m=125866013419738&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14656
Subject : Oops at __rmqueue+0x98 with 2.6.32-rc6
Submitter : Lucas C. Villa Real <lucasvr@gobolinux.org>
Date : 2009-11-19 3:48 (74 days old)
References : http://marc.info/?l=linux-kernel&m=125860255229092&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14624
Subject : ath9k: BUG kmalloc-8192: Poison overwritten
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2009-11-12 4:58 (81 days old)
References : http://marc.info/?l=linux-kernel&m=125800196520396&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14621
Subject : specjbb2005 and aim7 regression with 2.6.32-rc kernels
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2009-11-06 7:38 (87 days old)
References : http://marc.info/?l=linux-kernel&m=125749310413174&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14504
Subject : intermittent hibernation problem again
Submitter : Ferenc Wágner <wferi@niif.hu>
Date : 2009-10-28 23:49 (96 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14487
Subject : PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0
Submitter : Justin P. Mattock <justinmattock@gmail.com>
Date : 2009-10-23 16:45 (101 days old)
References : http://lkml.org/lkml/2009/10/23/252
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14482
Subject : kernel BUG at fs/dcache.c:670 +lvm +md +ext3
Submitter : Alexander Clouter <alex@digriz.org.uk>
Date : 2009-10-23 10:30 (101 days old)
References : http://lkml.org/lkml/2009/10/23/50
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14442
Subject : resume after hibernate: /dev/sdb drops and returns as /dev/sde
Submitter : Duncan <1i5t5.duncan@cox.net>
Date : 2009-10-20 01:52 (104 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14426
Subject : CE: hpet increasing min_delta_ns flood
Submitter : Thibault Mondary <thibm@free.fr>
Date : 2009-10-17 09:29 (107 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14376
Subject : Kernel NULL pointer dereference/ kvm subsystem
Submitter : Don Dupuis <dondster@gmail.com>
Date : 2009-10-06 14:38 (118 days old)
References : http://marc.info/?l=linux-kernel&m=125484025021737&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14298
Subject : warning at manage.c:361 (set_irq_wake), matrix-keypad related?
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2009-09-30 20:07 (124 days old)
References : http://marc.info/?l=linux-kernel&m=125434130703538&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14297
Subject : console resume broken since ba15ab0e8d
Submitter : Sascha Hauer <s.hauer@pengutronix.de>
Date : 2009-09-30 15:11 (124 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ba15ab0e8de0d4439a91342ad52d55ca9e313f3d
References : http://marc.info/?l=linux-kernel&m=125432349404060&w=4
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15197
Subject : padlock_sha1 and hmac broken?
Submitter : Wolfgang Walter <wolfgang.walter@stwm.de>
Date : 2010-01-29 23:44 (3 days old)
References : http://marc.info/?l=linux-kernel&m=126480912924283&w=4
Handled-By : Herbert Xu <herbert@gondor.apana.org.au>
Patch : http://patchwork.kernel.org/patch/75959/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15135
Subject : Kernel 2.6.32.x hangs during boot process
Submitter : François Figarola <francois.figarola@i-consult.fr>
Date : 2010-01-16 9:58 (16 days old)
References : http://marc.info/?l=linux-kernel&m=126363593817261&w=4
Handled-By : Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Patch : http://patchwork.kernel.org/patch/75560/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15134
Subject : gobi_loader hangs after commit 8e8dce065088
Submitter : Matthew Garrett <mjg59@srcf.ucam.org>
Date : 2010-01-17 2:55 (15 days old)
References : http://marc.info/?l=linux-kernel&m=126369696509502&w=4
Handled-By : Oliver Neukum <oliver@neukum.org>
Alan Cox <alan@lxorguk.ukuu.org.uk>
Patch : http://patchwork.kernel.org/patch/73878/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15040
Subject : High cpu temperature with 2.6.32 - bisected to cpuidle menu update
Submitter : Dimitrios Apostolou <jimis@gmx.net>
Date : 2010-01-06 17:39 (26 days old)
References : http://marc.info/?l=linux-kernel&m=126279952723036&w=4
Handled-By : Arjan van de Ven <arjan@infradead.org>
Patch : http://patchwork.kernel.org/patch/71962/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14897
Subject : i915: Commit 0e442c60 causes flickering
Submitter : David John <davidjon@xenontk.org>
Date : 2009-12-09 17:26 (54 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0e442c60dd39ac6924b11a20497734bd2303744c
References : http://marc.info/?l=linux-kernel&m=126037889600769&w=4
Handled-By : David John <davidjon@xenontk.org>
Patch : http://patchwork.kernel.org/patch/75423/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.31 and 2.6.32, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=14230
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox