* Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Daniel Mack @ 2012-10-21 12:12 UTC (permalink / raw)
To: Artem S. Tashkinov
Cc: bp, pavel, linux-kernel, netdev, security, linux-media, linux-usb
In-Reply-To: <121566322.100103.1350820776893.JavaMail.mail@webmail20>
On 21.10.2012 13:59, Artem S. Tashkinov wrote:
> On Oct 21, 2012, Borislav Petkov wrote:
>>
>> On Sun, Oct 21, 2012 at 01:57:21AM +0000, Artem S. Tashkinov wrote:
>>> The freeze happens on my *host* Linux PC. For an experiment I decided
>>> to check if I could reproduce the freeze under a virtual machine - it
>>> turns out the Linux kernel running under it also freezes.
>>
>> I know that - but a freeze != oops - at least not necessarily. Which
>> means it could very well be a different issue now that vbox is gone.
>>
>> Or, it could be the same issue with different incarnations: with vbox
>> you get the corruptions and without it, you get the freezes. I'm
>> assuming you do the same flash player thing in both cases?
>>
>> Here's a crazy idea: can you try to reproduce it in KVM?
>
> OK, dismiss VBox altogether - it has a very buggy USB implementation, thus
> it just hangs when trying to access my webcam.
>
> What I've found out is that my system crashes *only* when I try to enable
> usb-audio (from the same webcam)
It would also be interesting to know whether you have problems with
*only* the video capture, with some tool like "cheese". It might be
you're hitting a host controller issue here, and then isochronous input
packets on the video interface would most likely also trigger such am
effect. Actually, knowing whether that's the case would be crucial for
further debugging.
Daniel
^ permalink raw reply
* Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Artem S. Tashkinov @ 2012-10-21 12:30 UTC (permalink / raw)
To: zonque-Re5JQEeQqe8AvxtiuMwx3w
Cc: bp-Gina5bIWoIWzQB+pC5nmwQ, pavel-+ZI9xUNit7I,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, security-DgEjT+Ai2ygdnm+yROfE0A,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5083E4AA.3060807@gmail.com>
On Oct 21, 2012, Daniel Mack wrote:
> A hint at least. How did you enable the audio record exactly? Can you
> reproduce this with arecord?
>
> What chipset are you on? Please provide both "lspci -v" and "lsusb -v"
> dumps. As I said, I fail to reproduce that issue on any of my machines.
All other applications can read from the USB audio without problems, it's
just something in the way Adobe Flash polls my audio input which causes
a crash.
Just video capture (without audio) works just fine in Adobe Flash.
Only and only when I choose to use
USB Device 0x46d:0x81d my system crashes in Adobe Flash.
See the screenshot:
https://bugzilla.kernel.org/attachment.cgi?id=84151
My hardware information can be fetched from here:
https://bugzilla.kernel.org/show_bug.cgi?id=49181
On a second thought that can be even an ALSA crash or pretty much
anything else.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* Re: [PATCH for-3.7] vhost: fix mergeable bufs on BE hosts
From: Michael S. Tsirkin @ 2012-10-21 12:49 UTC (permalink / raw)
To: Alexander Graf; +Cc: netdev, stable, kvm, virtualization
In-Reply-To: <20121015175534.GA19489@redhat.com>
On Mon, Oct 15, 2012 at 07:55:34PM +0200, Michael S. Tsirkin wrote:
> We copy head count to a 16 bit field,
> this works by chance on LE but on BE
> guest gets 0. Fix it up.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Tested-by: Alexander Graf <agraf@suse.de>
> Cc: stable@kernel.org
Ping. Dave, could you apply this to -net please?
> ---
> drivers/vhost/net.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 9ab6d47..2bb463c 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -448,7 +448,8 @@ static void handle_rx(struct vhost_net *net)
> .hdr.gso_type = VIRTIO_NET_HDR_GSO_NONE
> };
> size_t total_len = 0;
> - int err, headcount, mergeable;
> + int err, mergeable;
> + s16 headcount;
> size_t vhost_hlen, sock_hlen;
> size_t vhost_len, sock_len;
> /* TODO: check that we are running from vhost_worker? */
> --
> MST
^ permalink raw reply
* Re: [BUG] Kernel recieves DNS reply, but doesn't deliver it to a waiting application
From: Eric Dumazet @ 2012-10-21 12:52 UTC (permalink / raw)
To: Andrew Savchenko; +Cc: netdev
In-Reply-To: <20121021032543.09d1844f.bircoph@gmail.com>
On Sun, 2012-10-21 at 03:25 +0400, Andrew Savchenko wrote:
> Hello,
>
> On Sun, 14 Oct 2012 03:11:19 +0400 Andrew Savchenko wrote:
> > On Sat, 13 Oct 2012 15:44:20 +0200 Eric Dumazet wrote:
> > > On Sat, 2012-10-13 at 16:36 +0400, Andrew Savchenko wrote:
> > > > On Wed, 3 Oct 2012 23:25:48 +0400 Andrew Savchenko wrote:
> > > > > I encountered a very weird bug: after a while of uptime kernel stops to deliver
> > > > > DNS reply to applications. Tcpdump shows that correct reply is recieved, but
> > > > > strace shows inquiring application never recieves it and ends with timeout,
> > > > > epoll_wait() always returns 0:
> > > > > a slice from: $ host kernel.org 8.8.8.8:
> > [...]
> > > > > In a few days I'll try 3.4.12 (I need to rebuild kernel anyway due to unrelated
> > > > > issue) and will report if this bug will occur again. But please note it may
> > > > > take several weeks to check this.
> > > >
> > > > I got this problem again with 3.4.12 kernel. System lasted less than
> > > > a week and reboot was the only option...
> > >
> > > You should investigate and check where the incoming packet is lost
> > >
> > > Tools :
> > >
> > > netstat -s
> > >
> > > drop_monitor module and dropwatch command
> > >
> > > cat /proc/net/udp
> >
> > Thank you for you reply; I updated my kernel to 3.4.14, enabled
> > CONFIG_NET_DROP_MONITOR, and installed dropwatch utility.
> >
> > I will report back when the bug will struck again.
> > This may take a weak or two, however.
>
> This bug is back again on kernel 3.4.14, but this time I was able to
> get debug data and to recover running kernel without reboot.
>
> Drowpatch showed that DNS UDP replies are always dropped here:
> 1 drops at __udp_queue_rcv_skb+61 (0xffffffff813bd670)
>
> Another observations:
> - only UDP replies are lost, TCP works fine;
> - if network load is dropped dramatically (ip_forward disabled, most
> network daemons are stopped) UDP DNS queries work again; but with
> gradual load increase replies became first slow and than cease at all.
> - CPU load is very low (uptime is below 0.05), so this shouldn't be
> an insufficient computing power issue.
>
> I found __udp_queue_rcv_skb function in net/ipv4/udp.c. From the code
> and observations above it follows that this is likely to be a ENOMEM
> condition leading to a packet loss.
>
> This is a memory data after bug happened:
> # cat /proc/meminfo
> MemTotal: 1021576 kB
> MemFree: 32056 kB
> Buffers: 105204 kB
> Cached: 646716 kB
> SwapCached: 236 kB
> Active: 205932 kB
> Inactive: 587156 kB
> Active(anon): 20636 kB
> Inactive(anon): 22488 kB
> Active(file): 185296 kB
> Inactive(file): 564668 kB
> Unevictable: 2152 kB
> Mlocked: 2152 kB
> SwapTotal: 995992 kB
> SwapFree: 995020 kB
> Dirty: 0 kB
> Writeback: 0 kB
> AnonPages: 43120 kB
> Mapped: 7504 kB
> Shmem: 148 kB
> Slab: 176004 kB
> SReclaimable: 118636 kB
> SUnreclaim: 57368 kB
> KernelStack: 688 kB
> PageTables: 2948 kB
> NFS_Unstable: 0 kB
> Bounce: 0 kB
> WritebackTmp: 0 kB
> CommitLimit: 1506780 kB
> Committed_AS: 62708 kB
> VmallocTotal: 34359738367 kB
> VmallocUsed: 262732 kB
> VmallocChunk: 34359474615 kB
> AnonHugePages: 0 kB
> DirectMap4k: 33536 kB
> DirectMap2M: 1013760 kB
>
> # sysctl -a | grep mem
> net.core.optmem_max = 20480
> net.core.rmem_default = 229376
> net.core.rmem_max = 131071
> net.core.wmem_default = 229376
> net.core.wmem_max = 131071
> net.ipv4.igmp_max_memberships = 20
> net.ipv4.tcp_mem = 22350 29801 44700
> net.ipv4.tcp_rmem = 4096 87380 6291456
> net.ipv4.tcp_wmem = 4096 16384 4194304
> net.ipv4.udp_mem = 24150 32202 48300
> net.ipv4.udp_rmem_min = 4096
> net.ipv4.udp_wmem_min = 4096
> vm.lowmem_reserve_ratio = 256 256 32
> vm.overcommit_memory = 0
>
> Sysctl memory parameters are system defaults, I haven't changed them
> via sysctl or /proc interfaces.
>
> I tried to increase udm_mem values to the following:
> net.ipv4.udp_mem = 100000 150000 200000
>
> This solved my issue, at least for a while: DNS queries are working
> fine now.
>
> But I suspect that there is some memory loss in the kernel UDP stack,
> because this issue never happens after reboot and always after about
> a week of network operation. So this memory increase should help only
> for a month or so, if memory loss is linear.
>
> If you need some memory debug information, let me know which one and
> what tools will be needed.
If drop is in __udp_queue_rcv_skb(), its not because you dont have
enough memory. Frame was already received and handled by IP stack.
Thats because sock_queue_rcv_skb() said : there are already enough
frames in socket receive buffer, I dont want to add another frame.
You forgot to attach :
cat /proc/net/udp
netstat -s
By the way, I suspect you are hit by skb recycling.
(skb truesize is too big after few iterations)
We removed skb recycling in linux-3.7-rc1
If so, linux-3.7-rc1 or linux-3.7-rc2 should be fine.
What NIC are you using ?
^ permalink raw reply
* Re: 3.5 bridging regression
From: Willy Tarreau @ 2012-10-21 13:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Eric Dumazet, netdev
In-Reply-To: <1350820413.13333.2042.camel@edumazet-glaptop>
On Sun, Oct 21, 2012 at 01:53:33PM +0200, Eric Dumazet wrote:
> Hello Willy
>
> This is most probably the needed fix.
Good catch, as usual ! It works flawlessly here on top of 3.6.2.
> I guess David planned to send it to stable teams if not already done.
Indeed, I've not seen it there yet.
David, are you OK with sending this patch for -stable ? It fixes
a 3.5 regression causing bridge to panic.
> commit acb600def2110b1310466c0e485c0d26299898ae
> Author: Eric Dumazet <edumazet@google.com>
> Date: Fri Oct 5 06:23:55 2012 +0000
>
> net: remove skb recycling
>
> Over time, skb recycling infrastructure got litle interest and
> many bugs. Generic rx path skb allocation is now using page
> fragments for efficient GRO / TCP coalescing, and recyling
> a tx skb for rx path is not worth the pain.
Thanks and have a nice week-end !
Willy
^ permalink raw reply
* Re: PROBLEM: Memory leak (at least with SLUB) from "secpath_dup" (xfrm) in 3.5+ kernels
From: Eric Dumazet @ 2012-10-21 13:29 UTC (permalink / raw)
To: Mike Kazantsev; +Cc: Paul Moore, netdev, linux-mm
In-Reply-To: <20121021062402.7c4c4cb8@sacrilege>
On Sun, 2012-10-21 at 06:24 +0600, Mike Kazantsev wrote:
> On Sun, 21 Oct 2012 04:45:40 +0600
> Mike Kazantsev <mk.fraggod@gmail.com> wrote:
>
> >
> > kmemleak mechanism seem to provide stack traces and interesting calls
> > for debugging of whatever is allocating the non-freed objects, so guess
> > I'll see if I can get more definitive (to my ignorant eye) "look here"
> > hint from it, and might drop one more mail with data from there.
> >
>
> kmemleak finds a lot (dozens megabytes of stack traces) of identical
> paths leading to a leaks:
>
> (for IPv6 packets)
> unreferenced object 0xffff88002fa25b00 (size 56):
> comm "softirq", pid 0, jiffies 4295009073 (age 295.620s)
> hex dump (first 32 bytes):
> 01 00 00 00 01 00 00 00 00 fc 6e 30 00 88 ff ff ..........n0....
> 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> backtrace:
> [<ffffffff814cfa2b>] kmemleak_alloc+0x21/0x3e
> [<ffffffff810d9445>] kmem_cache_alloc+0xa5/0xb1
> [<ffffffff8147dd35>] secpath_dup+0x1b/0x5a
> [<ffffffff8147df39>] xfrm_input+0x64/0x484
> [<ffffffff814b1d2c>] xfrm6_rcv_spi+0x19/0x1b
> [<ffffffff814b1d4e>] xfrm6_rcv+0x20/0x22
> [<ffffffff8148c19f>] ip6_input_finish+0x203/0x31b
> [<ffffffff8148c622>] ip6_input+0x1e/0x50
> [<ffffffff8148c31c>] ip6_rcv_finish+0x65/0x69
> [<ffffffff8148c5a3>] ipv6_rcv+0x283/0x2e4
> [<ffffffff813ff8ba>] __netif_receive_skb+0x599/0x64c
> [<ffffffff813ffb08>] netif_receive_skb+0x47/0x78
> [<ffffffff81400644>] napi_skb_finish+0x21/0x53
> [<ffffffff81400778>] napi_gro_receive+0x102/0x10e
> [<ffffffff8136978b>] rtl8169_poll+0x326/0x4f9
> [<ffffffff813ffcda>] net_rx_action+0x9f/0x175
>
> (for IPv4 packets)
> unreferenced object 0xffff88003387e000 (size 56):
> comm "softirq", pid 0, jiffies 4294915803 (age 563.583s)
> hex dump (first 32 bytes):
> 01 00 00 00 01 00 00 00 00 48 be 30 00 88 ff ff .........H.0....
> 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> backtrace:
> [<ffffffff814cfa2b>] kmemleak_alloc+0x21/0x3e
> [<ffffffff810d9445>] kmem_cache_alloc+0xa5/0xb1
> [<ffffffff8147dd35>] secpath_dup+0x1b/0x5a
> [<ffffffff8147df39>] xfrm_input+0x64/0x484
> [<ffffffff81474f7b>] xfrm4_rcv_encap+0x17/0x19
> [<ffffffff81474f9c>] xfrm4_rcv+0x1f/0x21
> [<ffffffff81430514>] ip_local_deliver_finish+0x170/0x22a
> [<ffffffff81430706>] ip_local_deliver+0x46/0x78
> [<ffffffff8143038d>] ip_rcv_finish+0x2bd/0x2d4
> [<ffffffff81430969>] ip_rcv+0x231/0x28c
> [<ffffffff813ff8ba>] __netif_receive_skb+0x599/0x64c
> [<ffffffff813ffb08>] netif_receive_skb+0x47/0x78
> [<ffffffff81400644>] napi_skb_finish+0x21/0x53
> [<ffffffff81400778>] napi_gro_receive+0x102/0x10e
> [<ffffffff8136978b>] rtl8169_poll+0x326/0x4f9
> [<ffffffff813ffcda>] net_rx_action+0x9f/0x175
>
> Object at the top and trace seem to be the same (between same
> IP-family) everywhere, just ages and addresses are different.
>
> IPv6 usage seem to be one important detail which I failed to mention.
> IPv4 traces seem to be really rare (only several of them), but that
> might be understandable because rsync was ran over IPv6.
>
> Still wasn't able to figure out what might cause the get's/put's
> disbalance with that commit, but was able to revert it, without
> anything bad happening (so far), using the patch below (in case
> issue might bite someone else before proper fix is found).
>
>
> --
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 6e04b1f..52a9d40 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -427,26 +427,8 @@ struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
> unsigned int length, gfp_t gfp_mask)
> {
> struct sk_buff *skb = NULL;
> - unsigned int fragsz = SKB_DATA_ALIGN(length + NET_SKB_PAD) +
> - SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> -
> - if (fragsz <= PAGE_SIZE && !(gfp_mask & (__GFP_WAIT | GFP_DMA))) {
> - void *data;
> -
> - if (sk_memalloc_socks())
> - gfp_mask |= __GFP_MEMALLOC;
> -
> - data = __netdev_alloc_frag(fragsz, gfp_mask);
> -
> - if (likely(data)) {
> - skb = build_skb(data, fragsz);
> - if (unlikely(!skb))
> - put_page(virt_to_head_page(data));
> - }
> - } else {
> - skb = __alloc_skb(length + NET_SKB_PAD, gfp_mask,
> + skb = __alloc_skb(length + NET_SKB_PAD, gfp_mask,
> SKB_ALLOC_RX, NUMA_NO_NODE);
> - }
> if (likely(skb)) {
> skb_reserve(skb, NET_SKB_PAD);
> skb->dev = dev;
>
>
Did you try linux-3.7-rc2 (or linux-3.7-rc1) ?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: 3.5 bridging regression
From: Eric Dumazet @ 2012-10-21 13:46 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Eric Dumazet, netdev
In-Reply-To: <20121021132610.GG21937@1wt.eu>
On Sun, 2012-10-21 at 15:26 +0200, Willy Tarreau wrote:
> On Sun, Oct 21, 2012 at 01:53:33PM +0200, Eric Dumazet wrote:
> > Hello Willy
> >
> > This is most probably the needed fix.
>
> Good catch, as usual ! It works flawlessly here on top of 3.6.2.
>
> > I guess David planned to send it to stable teams if not already done.
>
> Indeed, I've not seen it there yet.
>
> David, are you OK with sending this patch for -stable ? It fixes
> a 3.5 regression causing bridge to panic.
>
> > commit acb600def2110b1310466c0e485c0d26299898ae
> > Author: Eric Dumazet <edumazet@google.com>
> > Date: Fri Oct 5 06:23:55 2012 +0000
> >
> > net: remove skb recycling
> >
> > Over time, skb recycling infrastructure got litle interest and
> > many bugs. Generic rx path skb allocation is now using page
> > fragments for efficient GRO / TCP coalescing, and recyling
> > a tx skb for rx path is not worth the pain.
>
> Thanks and have a nice week-end !
> Willy
>
Thanks for testing, sorry for adding a bug.
skb_recycle() was losing skb->head_frag status.
(we could have added some logic in skb_is_recycleable(), but this
function was becoming really too complex)
^ permalink raw reply
* Re: PROBLEM: Memory leak (at least with SLUB) from "secpath_dup" (xfrm) in 3.5+ kernels
From: Mike Kazantsev @ 2012-10-21 13:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Paul Moore, netdev, linux-mm
In-Reply-To: <1350826183.13333.2243.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 244 bytes --]
On Sun, 21 Oct 2012 15:29:43 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> Did you try linux-3.7-rc2 (or linux-3.7-rc1) ?
>
I did not, will do in a few hours, thanks for the pointer.
--
Mike Kazantsev // fraggod.net
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: was: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Daniel Mack @ 2012-10-21 14:21 UTC (permalink / raw)
To: Artem S. Tashkinov
Cc: bp, pavel, linux-kernel, netdev@vger.kernel.org, security,
linux-media, linux-usb, alsa-devel
In-Reply-To: <317435358.100327.1350822615555.JavaMail.mail@webmail20>
[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]
[Cc: alsa-devel]
On 21.10.2012 14:30, Artem S. Tashkinov wrote:
> On Oct 21, 2012, Daniel Mack wrote:
>
>> A hint at least. How did you enable the audio record exactly? Can you
>> reproduce this with arecord?
>>
>> What chipset are you on? Please provide both "lspci -v" and "lsusb -v"
>> dumps. As I said, I fail to reproduce that issue on any of my machines.
>
> All other applications can read from the USB audio without problems, it's
> just something in the way Adobe Flash polls my audio input which causes
> a crash.
>
> Just video capture (without audio) works just fine in Adobe Flash.
Ok, so that pretty much rules out the host controller. I just wonder why
I still don't see it here, and I haven't heard of any such problem from
anyone else.
Some more questions:
- Which version of Flash are you running?
- Does this also happen with Firefox?
- Does flash access the device directly or via PulseAudio?
- Could you please apply the attached patch and see what it spits out to
dmesg once Flash opens the device? It returns -EINVAL in the hw_params
callback to prevent the actual streaming. On my machine with Flash
11.4.31.110, I get values of 2/44800/1/32768/2048/0, which seems sane.
Or does your machine still crash before anything is written to the logs?
> Only and only when I choose to use
>
> USB Device 0x46d:0x81d my system crashes in Adobe Flash.
>
> See the screenshot:
>
> https://bugzilla.kernel.org/attachment.cgi?id=84151
When exactly does the crash happen? Right after you selected that entry
from the list? There's a little recording level meter in that dialog.
Does that show any input from the microphone?
> My hardware information can be fetched from here:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=49181
>
> On a second thought that can be even an ALSA crash or pretty much
> anything else.
We'll see. Thanks for your help to sort this out!
Daniel
[-- Attachment #2: snd-usb-hwparams.diff --]
[-- Type: text/x-patch, Size: 778 bytes --]
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index f782ce1..5664b45 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -453,6 +453,18 @@ static int snd_usb_hw_params(struct snd_pcm_substream *substream,
unsigned int channels, rate, format;
int ret, changed;
+
+ printk(">>> %s()\n", __func__);
+
+ printk("format: %d\n", params_format(hw_params));
+ printk("rate: %d\n", params_rate(hw_params));
+ printk("channels: %d\n", params_channels(hw_params));
+ printk("buffer bytes: %d\n", params_buffer_bytes(hw_params));
+ printk("period bytes: %d\n", params_period_bytes(hw_params));
+ printk("access: %d\n", params_access(hw_params));
+
+ return -EINVAL;
+
ret = snd_pcm_lib_alloc_vmalloc_buffer(substream,
params_buffer_bytes(hw_params));
if (ret < 0)
^ permalink raw reply related
* [PATCH 0/5] make cadence ethernet drivers build on any architecture
From: Joachim Eastwood @ 2012-10-21 14:23 UTC (permalink / raw)
To: nicolas.ferre, davem, hskinnemoen, egtvedt, plagnioj, bgat
Cc: netdev, linux-arm-kernel, Joachim Eastwood
This series makes the at91_ether and macb driver build-able on any architecture.
Patch 1 removes the HAVE_NET_MACB from the cadence Kconfig and this allow macb to be built on any architecture. The macb driver requires no other modifications.
Patch 3 moves a bootloader quirk for CSB337 from at91_ether into CSB337 board setup. This allow us to remove the last mach include and build this driver on any architecture. It also make it easier to share the address setup between at91_ether and macb.
Patch 4-5 removes the now unused HAVE_NET_MACB config symbol from AT91/AVR32 Kconfig.
Note that patch 3 is not tested on a real CSB337 board. I only tested it on an other AT91RM9200 board to verify the logic that reverses the address byte order works.
The next series will make the at91_ether driver use address setting and statistics from macb. There is also a clean up of print outs plus some comment/style fixes.
Joachim Eastwood (5):
net/cadence: get rid of HAVE_NET_MACB
net/at91_ether: select MACB in Kconfig
net/at91_ether: move eth addr quirk into csb337 board setup
ARM: AT91: Remove HAVE_NET_MACB
AVR32: Remove HAVE_NET_MACB
arch/arm/mach-at91/Kconfig | 4 ----
arch/arm/mach-at91/board-csb337.c | 35 +++++++++++++++++++++++++++++++
arch/avr32/Kconfig | 1 -
drivers/net/ethernet/cadence/Kconfig | 8 +------
drivers/net/ethernet/cadence/Makefile | 2 +-
drivers/net/ethernet/cadence/at91_ether.c | 26 ++++++-----------------
6 files changed, 43 insertions(+), 33 deletions(-)
--
1.7.12.4
^ permalink raw reply
* [PATCH 1/5] net/cadence: get rid of HAVE_NET_MACB
From: Joachim Eastwood @ 2012-10-21 14:23 UTC (permalink / raw)
To: nicolas.ferre, davem, hskinnemoen, egtvedt, plagnioj, bgat
Cc: netdev, linux-arm-kernel, Joachim Eastwood
In-Reply-To: <1350829392-3812-1-git-send-email-manabian@gmail.com>
macb is a platform driver and there is nothing that prevents
this driver from being built on non-ARM/AVR32 platforms.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
drivers/net/ethernet/cadence/Kconfig | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index 57f78abe..5d1ea30 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -2,13 +2,9 @@
# Atmel device configuration
#
-config HAVE_NET_MACB
- bool
-
config NET_CADENCE
bool "Cadence devices"
default y
- depends on HAVE_NET_MACB || (ARM && ARCH_AT91RM9200)
---help---
If you have a network (Ethernet) card belonging to this class, say Y.
Make sure you know the name of your card. Read the Ethernet-HOWTO,
@@ -34,7 +30,6 @@ config ARM_AT91_ETHER
config MACB
tristate "Cadence MACB/GEM support"
- depends on HAVE_NET_MACB
select PHYLIB
---help---
The Cadence MACB ethernet interface is found on many Atmel AT32 and
--
1.7.12.4
^ permalink raw reply related
* [PATCH 3/5] net/at91_ether: move eth addr quirk into csb337 board setup
From: Joachim Eastwood @ 2012-10-21 14:23 UTC (permalink / raw)
To: nicolas.ferre, davem, hskinnemoen, egtvedt, plagnioj, bgat
Cc: netdev, linux-arm-kernel, Joachim Eastwood
In-Reply-To: <1350829392-3812-1-git-send-email-manabian@gmail.com>
Move Ethernet address byte order fix for csb337 into it's board
setup.
This will allow us to remove the last mach include from at91_ether
and also to share the address setup with the macb driver.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
arch/arm/mach-at91/board-csb337.c | 35 +++++++++++++++++++++++++++++++
drivers/net/ethernet/cadence/Kconfig | 1 -
drivers/net/ethernet/cadence/at91_ether.c | 26 ++++++-----------------
3 files changed, 41 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-at91/board-csb337.c b/arch/arm/mach-at91/board-csb337.c
index 3e37437..5522132 100644
--- a/arch/arm/mach-at91/board-csb337.c
+++ b/arch/arm/mach-at91/board-csb337.c
@@ -217,6 +217,40 @@ static struct gpio_led csb_leds[] = {
}
};
+/*
+ * MicroMonitor (uMon) on the CSB337 store the ethernet address in the
+ * wrong byte order (and continues to do so, for bug-compatibility).
+ */
+#define MACB_SA1B 0x0098
+#define MACB_SA1T 0x009c
+static void __init csb337_fix_eth_addr(void)
+{
+ void __iomem *emac;
+ u32 lo, hi, tmp;
+ int i;
+
+ emac = ioremap(AT91RM9200_BASE_EMAC, SZ_16K);
+ if (!emac) {
+ printk(KERN_ERR "csb337: unable to fixup Ethernet address\n");
+ return;
+ }
+
+ /* Fix byte order on all 4 address registers */
+ for (i = 0; i < 4; i++) {
+ lo = readl(emac + MACB_SA1B + i * 8);
+ hi = readl(emac + MACB_SA1T + i * 8);
+
+ tmp = (lo & 0xff) << 8 | (lo & 0xff00) >> 8;
+ writel(tmp, emac + MACB_SA1T + i * 8);
+
+ tmp = (hi & 0xff) << 8 | (hi & 0xff00) >> 8
+ | (lo & 0xff0000) << 8
+ | (lo & 0xff000000) >> 8;
+ writel(tmp, emac + MACB_SA1B + i * 8);
+ }
+
+ iounmap(emac);
+}
static void __init csb337_board_init(void)
{
@@ -225,6 +259,7 @@ static void __init csb337_board_init(void)
at91_register_uart(0, 0, 0);
at91_add_device_serial();
/* Ethernet */
+ csb337_fix_eth_addr();
at91_add_device_eth(&csb337_eth_data);
/* USB Host */
at91_add_device_usbh(&csb337_usbh_data);
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index f6d0956..40172d1 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -21,7 +21,6 @@ if NET_CADENCE
config ARM_AT91_ETHER
tristate "AT91RM9200 Ethernet support"
- depends on ARM && ARCH_AT91RM9200
select NET_CORE
select MACB
---help---
diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
index 375d272..5ed1a63 100644
--- a/drivers/net/ethernet/cadence/at91_ether.c
+++ b/drivers/net/ethernet/cadence/at91_ether.c
@@ -32,8 +32,6 @@
#include <linux/phy.h>
#include <linux/io.h>
-#include <asm/mach-types.h>
-
#include "macb.h"
#define DRV_NAME "at91_ether"
@@ -55,30 +53,18 @@
* U-Boot on the AT91RM9200-DK do not do this.
*
* - Likewise it must store the addresses in the correct byte order.
- * MicroMonitor (uMon) on the CSB337 does this incorrectly (and
- * continues to do so, for bug-compatibility).
*/
static short __init unpack_mac_address(struct net_device *dev, unsigned int hi, unsigned int lo)
{
char addr[6];
- if (machine_is_csb337()) {
- addr[5] = (lo & 0xff); /* The CSB337 bootloader stores the MAC the wrong-way around */
- addr[4] = (lo & 0xff00) >> 8;
- addr[3] = (lo & 0xff0000) >> 16;
- addr[2] = (lo & 0xff000000) >> 24;
- addr[1] = (hi & 0xff);
- addr[0] = (hi & 0xff00) >> 8;
- }
- else {
- addr[0] = (lo & 0xff);
- addr[1] = (lo & 0xff00) >> 8;
- addr[2] = (lo & 0xff0000) >> 16;
- addr[3] = (lo & 0xff000000) >> 24;
- addr[4] = (hi & 0xff);
- addr[5] = (hi & 0xff00) >> 8;
- }
+ addr[0] = (lo & 0xff);
+ addr[1] = (lo & 0xff00) >> 8;
+ addr[2] = (lo & 0xff0000) >> 16;
+ addr[3] = (lo & 0xff000000) >> 24;
+ addr[4] = (hi & 0xff);
+ addr[5] = (hi & 0xff00) >> 8;
if (is_valid_ether_addr(addr)) {
memcpy(dev->dev_addr, &addr, 6);
--
1.7.12.4
^ permalink raw reply related
* [PATCH 2/5] net/at91_ether: select MACB in Kconfig
From: Joachim Eastwood @ 2012-10-21 14:23 UTC (permalink / raw)
To: nicolas.ferre, davem, hskinnemoen, egtvedt, plagnioj, bgat
Cc: netdev, linux-arm-kernel, Joachim Eastwood
In-Reply-To: <1350829392-3812-1-git-send-email-manabian@gmail.com>
Now that HAVE_NET_MACB is gone let's just select MACB to
satisfy the dependecies in at91_ether.
PHYLIB will then by selected by MACB.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
drivers/net/ethernet/cadence/Kconfig | 2 +-
drivers/net/ethernet/cadence/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index 5d1ea30..f6d0956 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -23,7 +23,7 @@ config ARM_AT91_ETHER
tristate "AT91RM9200 Ethernet support"
depends on ARM && ARCH_AT91RM9200
select NET_CORE
- select PHYLIB
+ select MACB
---help---
If you wish to compile a kernel for the AT91RM9200 and enable
ethernet support, then you should always answer Y to this.
diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
index 798b1e0..9068b83 100644
--- a/drivers/net/ethernet/cadence/Makefile
+++ b/drivers/net/ethernet/cadence/Makefile
@@ -2,5 +2,5 @@
# Makefile for the Atmel network device drivers.
#
-obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o macb.o
+obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
obj-$(CONFIG_MACB) += macb.o
--
1.7.12.4
^ permalink raw reply related
* [PATCH 4/5] ARM: AT91: Remove HAVE_NET_MACB
From: Joachim Eastwood @ 2012-10-21 14:23 UTC (permalink / raw)
To: nicolas.ferre, davem, hskinnemoen, egtvedt, plagnioj, bgat
Cc: netdev, linux-arm-kernel, Joachim Eastwood
In-Reply-To: <1350829392-3812-1-git-send-email-manabian@gmail.com>
HAVE_NET_MACB has already been removed from the driver itself
so removed it from mach Kconfig as well.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
arch/arm/mach-at91/Kconfig | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index d846b6e..72020fb 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -45,7 +45,6 @@ config SOC_AT91RM9200
config SOC_AT91SAM9260
bool "AT91SAM9260, AT91SAM9XE or AT91SAM9G20"
select HAVE_AT91_DBGU0
- select HAVE_NET_MACB
select SOC_AT91SAM9
help
Select this if you are using one of Atmel's AT91SAM9260, AT91SAM9XE
@@ -63,7 +62,6 @@ config SOC_AT91SAM9263
bool "AT91SAM9263"
select HAVE_AT91_DBGU1
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
select SOC_AT91SAM9
config SOC_AT91SAM9RL
@@ -76,7 +74,6 @@ config SOC_AT91SAM9G45
bool "AT91SAM9G45 or AT91SAM9M10 families"
select HAVE_AT91_DBGU1
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
select SOC_AT91SAM9
help
Select this if you are using one of Atmel's AT91SAM9G45 family SoC.
@@ -86,7 +83,6 @@ config SOC_AT91SAM9X5
bool "AT91SAM9x5 family"
select HAVE_AT91_DBGU0
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
select SOC_AT91SAM9
help
Select this if you are using one of Atmel's AT91SAM9x5 family SoC.
--
1.7.12.4
^ permalink raw reply related
* [PATCH 5/5] AVR32: Remove HAVE_NET_MACB
From: Joachim Eastwood @ 2012-10-21 14:23 UTC (permalink / raw)
To: nicolas.ferre, davem, hskinnemoen, egtvedt, plagnioj, bgat
Cc: netdev, linux-arm-kernel, Joachim Eastwood
In-Reply-To: <1350829392-3812-1-git-send-email-manabian@gmail.com>
HAVE_NET_MACB has already been removed from the driver itself
so removed it from arch Kconfig as well.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
arch/avr32/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index 06e73bf..09f9fa8 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -80,7 +80,6 @@ config PLATFORM_AT32AP
select ARCH_REQUIRE_GPIOLIB
select GENERIC_ALLOCATOR
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
#
# CPU types
--
1.7.12.4
^ permalink raw reply related
* Re: Re: was: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Artem S. Tashkinov @ 2012-10-21 14:57 UTC (permalink / raw)
To: zonque
Cc: bp, pavel, linux-kernel, netdev, security, linux-media, linux-usb,
alsa-devel
In-Reply-To: <508404F5.2010502@gmail.com>
> On Oct 21, 2012, Daniel Mack wrote:
>
> [Cc: alsa-devel]
>
> On 21.10.2012 14:30, Artem S. Tashkinov wrote:
> > On Oct 21, 2012, Daniel Mack wrote:
> >
> >> A hint at least. How did you enable the audio record exactly? Can you
> >> reproduce this with arecord?
> >>
> >> What chipset are you on? Please provide both "lspci -v" and "lsusb -v"
> >> dumps. As I said, I fail to reproduce that issue on any of my machines.
> >
> > All other applications can read from the USB audio without problems, it's
> > just something in the way Adobe Flash polls my audio input which causes
> > a crash.
> >
> > Just video capture (without audio) works just fine in Adobe Flash.
>
> Ok, so that pretty much rules out the host controller. I just wonder why
> I still don't see it here, and I haven't heard of any such problem from
> anyone else.
>
> Some more questions:
>
> - Which version of Flash are you running?
Google Chrome has its own version of Adobe Flash:
Name: Shockwave Flash
Description: Shockwave Flash 11.4 r31
Version: 11.4.31.110
> - Does this also happen with Firefox?
No, Adobe Flash in Firefox is an older version (Shockwave Flash 11.1 r102), it shows
just two input devices instead of three which the newer Flash players sees.
* HDA Intel PCH
* USB Device 0x46d:0x81d
> - Does flash access the device directly or via PulseAudio?
PA is not installed on my computer, so Flash accesses it directly via ALSA calls.
> - Could you please apply the attached patch and see what it spits out to
> dmesg once Flash opens the device? It returns -EINVAL in the hw_params
> callback to prevent the actual streaming. On my machine with Flash
> 11.4.31.110, I get values of 2/44800/1/32768/2048/0, which seems sane.
> Or does your machine still crash before anything is written to the logs?
I will try it a bit later.
> > Only and only when I choose to use
> >
> > USB Device 0x46d:0x81d my system crashes in Adobe Flash.
> >
> > See the screenshot:
> >
> > https://bugzilla.kernel.org/attachment.cgi?id=84151
>
> When exactly does the crash happen? Right after you selected that entry
> from the list? There's a little recording level meter in that dialog.
> Does that show any input from the microphone?
Yes, right after I select it and move the mouse cursor away from this combobox
so that this selection becomes active.
> > My hardware information can be fetched from here:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=49181
> >
> > On a second thought that can be even an ALSA crash or pretty much
> > anything else.
>
> We'll see. Thanks for your help to sort this out!
Thank you for your assistance!
^ permalink raw reply
* [NetRom] possible circular locking dependency detected
From: Bernard f6bvp @ 2012-10-21 15:18 UTC (permalink / raw)
Cc: Ralf Baechle, linux-kernel, Linux Netdev List, linux-hams,
Bernard Pidoux
In-Reply-To: <4E06040B.7040309@free.fr>
[-- Attachment #1: Type: text/plain, Size: 191 bytes --]
Hi,
When shutting down my dual core system, there was a possible circular
locking dependency detected that is related to NetRom.
Here is the syslog report.
Regards,
Bernard, f6bvp
[-- Attachment #2: ax25ipd_not_tainted.txt --]
[-- Type: text/plain, Size: 13574 bytes --]
Oct 21 12:10:35 f6bvp-8 aprslist[1773]: terminating on SIGTERM
Oct 21 12:10:35 f6bvp-8 fpacstat: terminating on SIGTERM
Oct 21 12:10:35 f6bvp-8 netromd[1653]: terminating on SIGTERM
Oct 21 12:10:35 f6bvp-8 ax25ipd:
Oct 21 12:10:35 f6bvp-8 ax25ipd: socket udp on port 10094
Oct 21 12:10:35 f6bvp-8 ax25ipd: mode tnc
Oct 21 12:10:35 f6bvp-8 ax25ipd: device /dev/ptmx
Oct 21 12:10:35 f6bvp-8 ax25ipd: speed 115200
Oct 21 12:10:35 f6bvp-8 ax25ipd: loglevel 1
Oct 21 12:10:35 f6bvp-8 ax25ipd:
Oct 21 12:10:35 f6bvp-8 ax25ipd: K4GBB 184.4.148.122 udp 10094 1
Oct 21 12:10:35 f6bvp-8 ax25ipd: F8COJ 0.0.0.0 udp 10093 1
Oct 21 12:10:35 f6bvp-8 ax25ipd: F3KT 62.147.189.164 udp 10093 1
Oct 21 12:10:35 f6bvp-8 ax25ipd: F6BVP-12 192.168.0.68 udp 10093 4
Oct 21 12:10:35 f6bvp-8 ax25ipd: F6BVP-11 192.168.0.115 udp 10093 4
Oct 21 12:10:35 f6bvp-8 ax25ipd: F6BVP-10 192.168.0.115 udp 10093 5
Oct 21 12:10:35 f6bvp-8 ax25ipd: VA2BBS 24.212.252.110 udp 10093 1
Oct 21 12:10:35 f6bvp-8 ax25ipd: ON4HU 81.243.88.115 udp 10093 1
Oct 21 12:10:35 f6bvp-8 ax25ipd: IZ3LSV 88.149.155.158 udp 10094 5
Oct 21 12:10:35 f6bvp-8 ax25ipd:
Oct 21 12:10:35 f6bvp-8 nfs-server[27474]: Arrêt de NFS kernel daemon
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150299]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150313] ======================================================
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150317] [ INFO: possible circular locking dependency detected ]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150321] 3.6.1 #1 Not tainted
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150325] -------------------------------------------------------
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150329] ax25ipd/1580 is trying to acquire lock:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150333] (nr_node_list_lock){+.....}, at: [<ffffffffa06775ec>] nr_rt_device_down+0x7c/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150352]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150352] but task is already holding lock:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150356] (nr_neigh_list_lock){+.-.-.}, at: [<ffffffffa0677596>] nr_rt_device_down+0x26/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150373]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150373] which lock already depends on the new lock.
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150373]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150378]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150378] the existing dependency chain (in reverse order) is:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150382]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150382] -> #2 (nr_neigh_list_lock){+.-.-.}:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150396] [<ffffffff810b6452>] lock_acquire+0x92/0x120
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150409] [<ffffffff81482b76>] _raw_spin_lock_bh+0x36/0x50
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150418] [<ffffffffa06769eb>] nr_remove_neigh+0x1b/0xb0 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150429] [<ffffffffa0677c20>] nr_rt_ioctl+0x2b0/0xa60 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150438] [<ffffffffa0673fa1>] nr_ioctl+0x51/0x1d0 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150445] [<ffffffff813973e0>] sock_do_ioctl+0x30/0x70
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150454] [<ffffffff813976f9>] sock_ioctl+0x79/0x2f0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150460] [<ffffffff8118dd08>] do_vfs_ioctl+0x98/0x560
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150468] [<ffffffff8118e261>] sys_ioctl+0x91/0xa0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150477] [<ffffffff8148b6b9>] system_call_fastpath+0x16/0x1b
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150486]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150486] -> #1 (&(&nr_node->node_lock)->rlock){+.....}:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150498] [<ffffffff810b6452>] lock_acquire+0x92/0x120
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150505] [<ffffffff81482b76>] _raw_spin_lock_bh+0x36/0x50
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150512] [<ffffffffa0676acc>] nr_node_show+0x4c/0x150 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150522] [<ffffffff8119da5c>] seq_read+0x26c/0x420
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150529] [<ffffffff811e1046>] proc_reg_read+0x86/0xc0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150537] [<ffffffff8117b01c>] vfs_read+0xac/0x180
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150546] [<ffffffff8117b13a>] sys_read+0x4a/0x90
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150552] [<ffffffff8148b6b9>] system_call_fastpath+0x16/0x1b
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150559]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150559] -> #0 (nr_node_list_lock){+.....}:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150571] [<ffffffff810b5c41>] __lock_acquire+0x1a91/0x1ce0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150578] [<ffffffff810b6452>] lock_acquire+0x92/0x120
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150586] [<ffffffff81482b76>] _raw_spin_lock_bh+0x36/0x50
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150592] [<ffffffffa06775ec>] nr_rt_device_down+0x7c/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150601] [<ffffffffa0674b4d>] nr_device_event+0x7d/0xa0 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150608] [<ffffffff81487388>] notifier_call_chain+0x58/0xb0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150617] [<ffffffff810810c6>] raw_notifier_call_chain+0x16/0x20
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150625] [<ffffffff813ae526>] call_netdevice_notifiers+0x36/0x60
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150633] [<ffffffff813ae71f>] dev_close_many+0xbf/0x100
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150639] [<ffffffff813ae838>] rollback_registered_many+0xd8/0x250
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150645] [<ffffffff813aea4d>] rollback_registered+0x2d/0x40
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150653] [<ffffffff813b17a8>] unregister_netdevice_queue+0x68/0xc0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150659] [<ffffffff813b1820>] unregister_netdev+0x20/0x30
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150666] [<ffffffffa05df4e7>] mkiss_close+0x57/0x90 [mkiss]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150674] [<ffffffff81309ed1>] tty_ldisc_close.isra.2+0x41/0x60
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150683] [<ffffffff8130a0d0>] tty_ldisc_reinit+0x40/0x80
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150689] [<ffffffff8130a850>] tty_ldisc_hangup+0x190/0x340
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150695] [<ffffffff81301f8a>] __tty_hangup+0x10a/0x3c0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150703] [<ffffffff8130226e>] tty_vhangup+0xe/0x10
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150709] [<ffffffff8130c66e>] pty_close+0x10e/0x180
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150716] [<ffffffff81303212>] tty_release+0x182/0x5c0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150724] [<ffffffff8117bf9e>] __fput+0xae/0x230
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150734] [<ffffffff8117c12e>] ____fput+0xe/0x10
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150740] [<ffffffff81076fb9>] task_work_run+0x69/0x90
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150748] [<ffffffff8105abef>] do_exit+0x87f/0x900
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150756] [<ffffffff8105afce>] do_group_exit+0x4e/0xc0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150763] [<ffffffff8105b057>] sys_exit_group+0x17/0x20
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150770] [<ffffffff8148b6b9>] system_call_fastpath+0x16/0x1b
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150778]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150778] other info that might help us debug this:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150778]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150782] Chain exists of:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150782] nr_node_list_lock --> &(&nr_node->node_lock)->rlock --> nr_neigh_list_lock
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150782]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150799] Possible unsafe locking scenario:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150799]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150803] CPU0 CPU1
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150806] ---- ----
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150809] lock(nr_neigh_list_lock);
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150819] lock(&(&nr_node->node_lock)->rlock);
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150826] lock(nr_neigh_list_lock);
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150834] lock(nr_node_list_lock);
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150842]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150842] *** DEADLOCK ***
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150842]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150847] 4 locks held by ax25ipd/1580:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150851] #0: (big_tty_mutex){+.+.+.}, at: [<ffffffff814832d7>] tty_lock+0x17/0x19
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150867] #1: (&tty->ldisc_mutex){+.+.+.}, at: [<ffffffff8130a7d7>] tty_ldisc_hangup+0x117/0x340
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150885] #2: (rtnl_mutex){+.+.+.}, at: [<ffffffff813c11c7>] rtnl_lock+0x17/0x20
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150901] #3: (nr_neigh_list_lock){+.-.-.}, at: [<ffffffffa0677596>] nr_rt_device_down+0x26/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150921]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150921] stack backtrace:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150927] Pid: 1580, comm: ax25ipd Not tainted 3.6.1 #1
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150930] Call Trace:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150938] [<ffffffff81479b5a>] print_circular_bug+0x289/0x29a
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150945] [<ffffffff810b5c41>] __lock_acquire+0x1a91/0x1ce0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150954] [<ffffffffa06775ec>] ? nr_rt_device_down+0x7c/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150960] [<ffffffff810b6452>] lock_acquire+0x92/0x120
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150969] [<ffffffffa06775ec>] ? nr_rt_device_down+0x7c/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150976] [<ffffffff81482b76>] _raw_spin_lock_bh+0x36/0x50
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150984] [<ffffffffa06775ec>] ? nr_rt_device_down+0x7c/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150990] [<ffffffff810b6ec5>] ? trace_hardirqs_on_caller+0x105/0x190
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150997] [<ffffffffa0674b41>] ? nr_device_event+0x71/0xa0 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151005] [<ffffffffa06775ec>] nr_rt_device_down+0x7c/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151011] [<ffffffff8105d1a7>] ? local_bh_enable_ip+0x97/0x100
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151019] [<ffffffffa0674b4d>] nr_device_event+0x7d/0xa0 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151026] [<ffffffff81487388>] notifier_call_chain+0x58/0xb0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151033] [<ffffffff810810c6>] raw_notifier_call_chain+0x16/0x20
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151038] [<ffffffff813ae526>] call_netdevice_notifiers+0x36/0x60
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151044] [<ffffffff813ae71f>] dev_close_many+0xbf/0x100
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151050] [<ffffffff813ae838>] rollback_registered_many+0xd8/0x250
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151055] [<ffffffff813aea4d>] rollback_registered+0x2d/0x40
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151061] [<ffffffff813b17a8>] unregister_netdevice_queue+0x68/0xc0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151068] [<ffffffff813b1820>] unregister_netdev+0x20/0x30
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151077] [<ffffffffa05df4e7>] mkiss_close+0x57/0x90 [mkiss]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151083] [<ffffffff81309ed1>] tty_ldisc_close.isra.2+0x41/0x60
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151089] [<ffffffff8130a0d0>] tty_ldisc_reinit+0x40/0x80
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151094] [<ffffffff8130a850>] tty_ldisc_hangup+0x190/0x340
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151101] [<ffffffff81301f8a>] __tty_hangup+0x10a/0x3c0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151107] [<ffffffff810b6f5d>] ? trace_hardirqs_on+0xd/0x10
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151114] [<ffffffff8130226e>] tty_vhangup+0xe/0x10
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151120] [<ffffffff8130c66e>] pty_close+0x10e/0x180
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151126] [<ffffffff81303212>] tty_release+0x182/0x5c0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151132] [<ffffffff81192d92>] ? dput+0x62/0x1b0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151138] [<ffffffff8117bf9e>] __fput+0xae/0x230
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151144] [<ffffffff8117c12e>] ____fput+0xe/0x10
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff81076fb9>] task_work_run+0x69/0x90
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff8105abef>] do_exit+0x87f/0x900
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff81483495>] ? retint_swapgs+0x13/0x1b
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff8105afce>] do_group_exit+0x4e/0xc0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff8105b057>] sys_exit_group+0x17/0x20
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff8148b6b9>] system_call_fastpath+0x16/0x1b
^ permalink raw reply
* Re: was: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Daniel Mack @ 2012-10-21 15:22 UTC (permalink / raw)
To: Artem S. Tashkinov
Cc: bp, pavel, linux-kernel, netdev, security, linux-media, linux-usb,
alsa-devel
In-Reply-To: <901486978.101922.1350831476734.JavaMail.mail@webmail20>
On 21.10.2012 16:57, Artem S. Tashkinov wrote:
>> On Oct 21, 2012, Daniel Mack wrote:
>>
>> [Cc: alsa-devel]
>>
>> On 21.10.2012 14:30, Artem S. Tashkinov wrote:
>>> On Oct 21, 2012, Daniel Mack wrote:
>>>
>>>> A hint at least. How did you enable the audio record exactly? Can you
>>>> reproduce this with arecord?
>>>>
>>>> What chipset are you on? Please provide both "lspci -v" and "lsusb -v"
>>>> dumps. As I said, I fail to reproduce that issue on any of my machines.
>>>
>>> All other applications can read from the USB audio without problems, it's
>>> just something in the way Adobe Flash polls my audio input which causes
>>> a crash.
>>>
>>> Just video capture (without audio) works just fine in Adobe Flash.
>>
>> Ok, so that pretty much rules out the host controller. I just wonder why
>> I still don't see it here, and I haven't heard of any such problem from
>> anyone else.
>>
>> Some more questions:
>>
>> - Which version of Flash are you running?
>
> Google Chrome has its own version of Adobe Flash:
>
> Name: Shockwave Flash
> Description: Shockwave Flash 11.4 r31
> Version: 11.4.31.110
So that's the same that I'm using.
>> - Does this also happen with Firefox?
>
> No, Adobe Flash in Firefox is an older version (Shockwave Flash 11.1 r102), it shows
> just two input devices instead of three which the newer Flash players sees.
>
> * HDA Intel PCH
> * USB Device 0x46d:0x81d
And that works, I assume? Does the second choice in the newer Flash
version work maybe?
>> - Does flash access the device directly or via PulseAudio?
>
> PA is not installed on my computer, so Flash accesses it directly via ALSA calls.
Ok, Same here.
>> - Could you please apply the attached patch and see what it spits out to
>> dmesg once Flash opens the device? It returns -EINVAL in the hw_params
>> callback to prevent the actual streaming. On my machine with Flash
>> 11.4.31.110, I get values of 2/44800/1/32768/2048/0, which seems sane.
>> Or does your machine still crash before anything is written to the logs?
>
> I will try it a bit later.
Yes, we need to trace the call chain and see at which point the trouble
starts. What could help is tracing the google-chrome binary with strace
maybe. At least we would see the ioctl command sequence, if the log file
survives the crash.
As the usb list is still in Cc: - Artem's lcpci dump shows that his
machine features XHCI controllers. Can anyone think of a relation to
this problem?
And Artem, is there any way you boot your system on an older machine
that only has EHCI ports? Thinking about it, I wonder whether the freeze
in VBox and the crashes on native hardware have the same root cause. In
that case, would it be possible to share that VBox image?
Daniel
^ permalink raw reply
* Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Alan Stern @ 2012-10-21 15:23 UTC (permalink / raw)
To: Artem S. Tashkinov
Cc: bp, pavel, linux-kernel, netdev, security, linux-media, linux-usb
In-Reply-To: <121566322.100103.1350820776893.JavaMail.mail@webmail20>
On Sun, 21 Oct 2012, Artem S. Tashkinov wrote:
> What I've found out is that my system crashes *only* when I try to enable
> usb-audio (from the same webcam) - I still have no idea how to capture a
> panic message, but I ran
>
> "while :; do dmesg -c; done" in xterm, then I got like thousands of messages
> and I photographed my monitor:
>
> http://imageshack.us/a/img685/9452/panicz.jpg
>
> list_del corruption. prev->next should be ... but was ...
>
> I cannot show you more as I have no serial console to use :( and the kernel
> doesn't have enough time to push error messages to rsyslog and fsync
> /var/log/messages
Is it possible to use netconsole? The screenshot above appears to be
the end of a long series of error messages, which isn't too useful.
The most important information is in the first error.
Alan Stern
^ permalink raw reply
* Re: [PATCH net-next V2] htb: improved accuracy at high rates
From: Vimal @ 2012-10-21 15:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, Jamal Hadi Salim, netdev
In-Reply-To: <1350818245.13333.1967.camel@edumazet-glaptop>
On 21 October 2012 04:17, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> I meant 'dont lose their time', oh well ;)
>
I think I just pasted the patch onto net-next. Fixing both errors,
and resubmitting.
thanks :-)
--
Vimal
^ permalink raw reply
* Re: was: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Alan Stern @ 2012-10-21 15:28 UTC (permalink / raw)
To: Daniel Mack
Cc: Artem S. Tashkinov, bp, pavel, linux-kernel, netdev, security,
linux-media, linux-usb, alsa-devel
In-Reply-To: <5084132B.8080609@gmail.com>
On Sun, 21 Oct 2012, Daniel Mack wrote:
> As the usb list is still in Cc: - Artem's lcpci dump shows that his
> machine features XHCI controllers. Can anyone think of a relation to
> this problem?
>
> And Artem, is there any way you boot your system on an older machine
> that only has EHCI ports? Thinking about it, I wonder whether the freeze
> in VBox and the crashes on native hardware have the same root cause. In
> that case, would it be possible to share that VBox image?
Don't grasp at straws. All of the kernel logs Artem has posted show
ehci-hcd; none of them show xhci-hcd. Therefore the xHCI controller is
highly unlikely to be involved.
Alan Stern
^ permalink raw reply
* Re: was: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Daniel Mack @ 2012-10-21 15:36 UTC (permalink / raw)
To: Alan Stern
Cc: security, alsa-devel, netdev, linux-usb, linux-kernel, bp, pavel,
Artem S. Tashkinov, linux-media
In-Reply-To: <Pine.LNX.4.44L0.1210211126570.14867-100000@netrider.rowland.org>
On Oct 21, 2012 5:28 PM, "Alan Stern" <stern@rowland.harvard.edu> wrote:
>
> On Sun, 21 Oct 2012, Daniel Mack wrote:
>
> > As the usb list is still in Cc: - Artem's lcpci dump shows that his
> > machine features XHCI controllers. Can anyone think of a relation to
> > this problem?
> >
> > And Artem, is there any way you boot your system on an older machine
> > that only has EHCI ports? Thinking about it, I wonder whether the freeze
> > in VBox and the crashes on native hardware have the same root cause. In
> > that case, would it be possible to share that VBox image?
>
> Don't grasp at straws. All of the kernel logs Artem has posted show
> ehci-hcd; none of them show xhci-hcd. Therefore the xHCI controller is
> highly unlikely to be involved.
You might be right - I'm just looking for differences between his setup and
mine that would explain why nobody else sees a severe bug that is 100%
reproducible for him.
^ permalink raw reply
* Re: 3.5 bridging regression
From: Willy Tarreau @ 2012-10-21 15:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Eric Dumazet, netdev
In-Reply-To: <1350827202.13333.2284.camel@edumazet-glaptop>
On Sun, Oct 21, 2012 at 03:46:42PM +0200, Eric Dumazet wrote:
> Thanks for testing, sorry for adding a bug.
No problem, thanks to you for the quick fix.
> skb_recycle() was losing skb->head_frag status.
>
> (we could have added some logic in skb_is_recycleable(), but this
> function was becoming really too complex)
OK. I remember you did this in order to permit zero-copy splice() with
all network drivers. I'll recheck to see if there is a performance impact
with the fix.
Cheers,
Willy
^ permalink raw reply
* Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Borislav Petkov @ 2012-10-21 17:03 UTC (permalink / raw)
To: Artem S. Tashkinov
Cc: pavel, linux-kernel, netdev, security, linux-media, linux-usb
In-Reply-To: <121566322.100103.1350820776893.JavaMail.mail@webmail20>
On Sun, Oct 21, 2012 at 11:59:36AM +0000, Artem S. Tashkinov wrote:
> http://imageshack.us/a/img685/9452/panicz.jpg
>
> list_del corruption. prev->next should be ... but was ...
Btw, this is one of the debug options I told you to enable.
> I cannot show you more as I have no serial console to use :( and the kernel
> doesn't have enough time to push error messages to rsyslog and fsync
> /var/log/messages
I already told you how to catch that oops: boot with "pause_on_oops=600"
on the kernel command line and photograph the screen when the first oops
happens. This'll show us where the problem begins.
--
Regards/Gruss,
Boris.
^ permalink raw reply
* Re: [PATCH 6/6] drivers: net: ethernet: cpsw: implement timestamping capabilities in cpsw
From: Richard Cochran @ 2012-10-21 18:11 UTC (permalink / raw)
To: Mugunthan V N; +Cc: netdev, davem
In-Reply-To: <1350427518-7230-7-git-send-email-mugunthanvnm@ti.com>
On Wed, Oct 17, 2012 at 04:15:18AM +0530, Mugunthan V N wrote:
> This patch implements timestamping capabilities in cpsw through IOCTL interface
> to enable and disable PTP time stamping and adds hardware time stamps to the
> packet's skb buffer using cpts api
Just out of curiosity, I compiled and booted this patch series, but it
does not work. The CPTS driver fails with
[ 1.901459] Missing cpts_reg_ofs property in the DT.
[ 1.906835] cpsw: platform data missing
so I think you forgot to patch the dts files.
Thanks,
Richard
^ 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