linux-toradex.git/drivers, branch v2.6.33.2 Linux kernel for Apalis and Colibri modules pata_via: fix VT6410/6415/6330 detection issue 2010-04-01T23:02:15+00:00 JosephChan@via.com.tw JosephChan@via.com.tw 2010-03-25T12:51:47+00:00 77aba144b01d97cd877dbbca15b1ba5b11192e5f commit bc8a67386fd462914269fa93446e1891955a8bb3 upstream. When using VT6410/6415/6330 chips on some VIA's platforms, the HDD connection to VT6410/6415/6330 cannot be detected. It is because the driver detects wrong via_isa_bridge ID, and then causes this issue to happen. Signed-off-by: Joseph Chan <josephchan@via.com.tw> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit bc8a67386fd462914269fa93446e1891955a8bb3 upstream.

When using VT6410/6415/6330 chips on some VIA's platforms, the HDD
connection to VT6410/6415/6330 cannot be detected.

It is because the driver detects wrong via_isa_bridge ID, and then
causes this issue to happen.

Signed-off-by: Joseph Chan <josephchan@via.com.tw>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
classmate-laptop: use a single MODULE_DEVICE_TABLE to get correct aliases 2010-04-01T23:02:14+00:00 Thadeu Lima de Souza Cascardo cascardo@holoscopio.com 2010-02-09T22:37:27+00:00 993d82e3f2d2bd769b4b6246fa943d5ac71c46a2 commit 02e77a55f7b7e36888e39c62439fedb90ae4e808 upstream. Instead of a MODULE_DEVICE_TABLE for every acpi_driver ids table, we create a table containing all ids to export to get a module alias for each one. This will fix automatic loading of the driver when one of the ACPI devices is not present (like the accelerometer, which is not present in some models). Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 02e77a55f7b7e36888e39c62439fedb90ae4e808 upstream.

Instead of a MODULE_DEVICE_TABLE for every acpi_driver ids table, we
create a table containing all ids to export to get a module alias for
each one.

This will fix automatic loading of the driver when one of the ACPI
devices is not present (like the accelerometer, which is not present in
some models).

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
b43: Workaround circular locking in hw-tkip key update callback 2010-04-01T23:02:14+00:00 Michael Buesch mb@bu3sch.de 2010-03-19T15:38:33+00:00 cb81a2ace8bd4354cc40ff341543a9791719383c commit 96869a39399269a776a94812e9fff3d38b47d838 upstream The TKIP key update callback is called from the RX path, where the driver mutex is already locked. This results in a circular locking bug. Avoid this by removing the lock. Johannes noted that there is a separate bug: The callback still breaks on SDIO hardware, because SDIO hardware access needs to sleep, but we are not allowed to sleep in the callback due to mac80211's RCU locking. Signed-off-by: Michael Buesch <mb@bu3sch.de> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Reported-by: kecsa@kutfo.hit.bme.hu Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 96869a39399269a776a94812e9fff3d38b47d838 upstream

The TKIP key update callback is called from the RX path, where the driver
mutex is already locked. This results in a circular locking bug.
Avoid this by removing the lock.

Johannes noted that there is a separate bug: The callback still breaks on SDIO
hardware, because SDIO hardware access needs to sleep, but we are not allowed
to sleep in the callback due to mac80211's RCU locking.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: kecsa@kutfo.hit.bme.hu
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ahci: use BIOS date in broken_suspend list 2010-04-01T23:02:13+00:00 Tejun Heo tj@kernel.org 2010-03-16T00:50:26+00:00 3ecee16aa4617db7cb756ad01526d395dc86d95f commit 9deb343189b3cf45e84dd08480f330575ffe2004 upstream. HP is recycling both DMI_PRODUCT_NAME and DMI_BIOS_VERSION making ahci_broken_suspend() trigger for later products which are not affected by the original problems. Match BIOS date instead of version and add references to bko's so that full information can be found easier later. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=15462 Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: tigerfishdaisy@gmail.com Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 9deb343189b3cf45e84dd08480f330575ffe2004 upstream.

HP is recycling both DMI_PRODUCT_NAME and DMI_BIOS_VERSION making
ahci_broken_suspend() trigger for later products which are not
affected by the original problems.  Match BIOS date instead of version
and add references to bko's so that full information can be found
easier later.

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=15462

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: tigerfishdaisy@gmail.com
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
r8169: offical fix for CVE-2009-4537 (overlength frame DMAs) 2010-04-01T23:02:10+00:00 Neil Horman nhorman@redhat.com 2010-03-29T20:16:02+00:00 8c96206544955131f6d7cef09371950f34ebca5a [ Upstream commit c0cd884af045338476b8e69a61fceb3f34ff22f1 ] Official patch to fix the r8169 frame length check error. Based on this initial thread: http://marc.info/?l=linux-netdev&m=126202972828626&w=1 This is the official patch to fix the frame length problems in the r8169 driver. As noted in the previous thread, while this patch incurs a performance hit on the driver, its possible to improve performance dynamically by updating the mtu and rx_copybreak values at runtime to return performance to what it was for those NICS which are unaffected by the ideosyncracy (if there are any). Summary: A while back Eric submitted a patch for r8169 in which the proper allocated frame size was written to RXMaxSize to prevent the NIC from dmaing too much data. This was done in commit fdd7b4c3302c93f6833e338903ea77245eb510b4. A long time prior to that however, Francois posted 126fa4b9ca5d9d7cb7d46f779ad3bd3631ca387c, which expiclitly disabled the MaxSize setting due to the fact that the hardware behaved in odd ways when overlong frames were received on NIC's supported by this driver. This was mentioned in a security conference recently: http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html It seems that if we can't enable frame size filtering, then, as Eric correctly noticed, we can find ourselves DMA-ing too much data to a buffer, causing corruption. As a result is seems that we are forced to allocate a frame which is ready to handle a maximally sized receive. This obviously has performance issues with it, so to mitigate that issue, this patch does two things: 1) Raises the copybreak value to the frame allocation size, which should force appropriately sized packets to get allocated on rx, rather than a full new 16k buffer. 2) This patch only disables frame filtering initially (i.e., during the NIC open), changing the MTU results in ring buffer allocation of a size in relation to the new mtu (along with a warning indicating that this is dangerous). Because of item (2), individuals who can't cope with the performance hit (or can otherwise filter frames to prevent the bug), or who have hardware they are sure is unaffected by this issue, can manually lower the copybreak and reset the mtu such that performance is restored easily. Signed-off-by: Neil Horman <nhorman@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[ Upstream commit c0cd884af045338476b8e69a61fceb3f34ff22f1 ]

Official patch to fix the r8169 frame length check error.

Based on this initial thread:
http://marc.info/?l=linux-netdev&m=126202972828626&w=1
This is the official patch to fix the frame length problems in the r8169
driver.  As noted in the previous thread, while this patch incurs a performance
hit on the driver, its possible to improve performance dynamically by updating
the mtu and rx_copybreak values at runtime to return performance to what it was
for those NICS which are unaffected by the ideosyncracy (if there are any).

Summary:

    A while back Eric submitted a patch for r8169 in which the proper
allocated frame size was written to RXMaxSize to prevent the NIC from dmaing too
much data.  This was done in commit fdd7b4c3302c93f6833e338903ea77245eb510b4.  A
long time prior to that however, Francois posted
126fa4b9ca5d9d7cb7d46f779ad3bd3631ca387c, which expiclitly disabled the MaxSize
setting due to the fact that the hardware behaved in odd ways when overlong
frames were received on NIC's supported by this driver.  This was mentioned in a
security conference recently:
http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html

It seems that if we can't enable frame size filtering, then, as Eric correctly
noticed, we can find ourselves DMA-ing too much data to a buffer, causing
corruption.  As a result is seems that we are forced to allocate a frame which
is ready to handle a maximally sized receive.

This obviously has performance issues with it, so to mitigate that issue, this
patch does two things:

1) Raises the copybreak value to the frame allocation size, which should force
appropriately sized packets to get allocated on rx, rather than a full new 16k
buffer.

2) This patch only disables frame filtering initially (i.e., during the NIC
open), changing the MTU results in ring buffer allocation of a size in relation
to the new mtu (along with a warning indicating that this is dangerous).

Because of item (2), individuals who can't cope with the performance hit (or can
otherwise filter frames to prevent the bug), or who have hardware they are sure
is unaffected by this issue, can manually lower the copybreak and reset the mtu
such that performance is restored easily.

Signed-off-by: Neil Horman <nhorman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
e100: Fix ring parameter change handling regression. 2010-04-01T23:02:06+00:00 David S. Miller davem@davemloft.net 2010-03-15T22:23:30+00:00 8fc51479fb9f3b9b06e65ce266488bae55c2965a [ Upstream commit 211a0d941b1924e667483f822a55e2cc694cd212 ] When the PCI pool changes were added to fix resume failures: commit 98468efddb101f8a29af974101c17ba513b07be1 e100: Use pci pool to work around GFP_ATOMIC order 5 memory allocation failu and commit 70abc8cb90e679d8519721e2761d8366a18212a6 e100: Fix broken cbs accounting due to missing memset. This introduced a problem that can happen if the TX ring size is increased. We need to size the PCI pool using cbs->max instead of the default cbs->count value. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[ Upstream commit 211a0d941b1924e667483f822a55e2cc694cd212 ]

When the PCI pool changes were added to fix resume failures:

commit 98468efddb101f8a29af974101c17ba513b07be1
e100: Use pci pool to work around GFP_ATOMIC order 5 memory allocation failu

and

commit 70abc8cb90e679d8519721e2761d8366a18212a6
e100: Fix broken cbs accounting due to missing memset.

This introduced a problem that can happen if the TX ring size
is increased.  We need to size the PCI pool using cbs->max
instead of the default cbs->count value.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
bonding: fix device leak on error in bond_create() 2010-04-01T23:02:05+00:00 Patrick McHardy kaber@trash.net 2010-02-27T10:52:05+00:00 45e74e6561f0da79a417be5424d2c1bf26ae79ba [ Upstream commit 8d6184e4881b423522136aeb3ec1cbd9c35e8813 ] When the register_netdevice() call fails, the newly allocated device is not freed. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[ Upstream commit 8d6184e4881b423522136aeb3ec1cbd9c35e8813 ]

When the register_netdevice() call fails, the newly allocated device is
not freed.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
l2tp: Fix UDP socket reference count bugs in the pppol2tp driver 2010-04-01T23:02:01+00:00 James Chapman jchapman@katalix.com 2010-03-16T06:29:20+00:00 3a8010e6225a3548e9921d986a53ae93bda433fa [ Upstream commit c3259c8a7060d480e8eb2166da0a99d6879146b4 ] This patch fixes UDP socket refcnt bugs in the pppol2tp driver. A bug can cause a kernel stack trace when a tunnel socket is closed. A way to reproduce the issue is to prepare the UDP socket for L2TP (by opening a tunnel pppol2tp socket) and then close it before any L2TP sessions are added to it. The sequence is Create UDP socket Create tunnel pppol2tp socket to prepare UDP socket for L2TP pppol2tp_connect: session_id=0, peer_session_id=0 L2TP SCCRP control frame received (tunnel_id==0) pppol2tp_recv_core: sock_hold() pppol2tp_recv_core: sock_put L2TP ZLB control frame received (tunnel_id=nnn) pppol2tp_recv_core: sock_hold() pppol2tp_recv_core: sock_put Close tunnel management socket pppol2tp_release: session_id=0, peer_session_id=0 Close UDP socket udp_lib_close: BUG The addition of sock_hold() in pppol2tp_connect() solves the problem. For data frames, two sock_put() calls were added to plug a refcnt leak per received data frame. The ref that is grabbed at the top of pppol2tp_recv_core() must always be released, but this wasn't done for accepted data frames or data frames discarded because of bad UDP checksums. This leak meant that any UDP socket that had passed L2TP data traffic (i.e. L2TP data frames, not just L2TP control frames) using pppol2tp would not be released by the kernel. WARNING: at include/net/sock.h:435 udp_lib_unhash+0x117/0x120() Pid: 1086, comm: openl2tpd Not tainted 2.6.33-rc1 #8 Call Trace: [<c119e9b7>] ? udp_lib_unhash+0x117/0x120 [<c101b871>] ? warn_slowpath_common+0x71/0xd0 [<c119e9b7>] ? udp_lib_unhash+0x117/0x120 [<c101b8e3>] ? warn_slowpath_null+0x13/0x20 [<c119e9b7>] ? udp_lib_unhash+0x117/0x120 [<c11598a7>] ? sk_common_release+0x17/0x90 [<c11a5e33>] ? inet_release+0x33/0x60 [<c11577b0>] ? sock_release+0x10/0x60 [<c115780f>] ? sock_close+0xf/0x30 [<c106e542>] ? __fput+0x52/0x150 [<c106b68e>] ? filp_close+0x3e/0x70 [<c101d2e2>] ? put_files_struct+0x62/0xb0 [<c101eaf7>] ? do_exit+0x5e7/0x650 [<c1081623>] ? mntput_no_expire+0x13/0x70 [<c106b68e>] ? filp_close+0x3e/0x70 [<c101eb8a>] ? do_group_exit+0x2a/0x70 [<c101ebe1>] ? sys_exit_group+0x11/0x20 [<c10029b0>] ? sysenter_do_call+0x12/0x26 Signed-off-by: James Chapman <jchapman@katalix.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[ Upstream commit c3259c8a7060d480e8eb2166da0a99d6879146b4 ]

This patch fixes UDP socket refcnt bugs in the pppol2tp driver.

A bug can cause a kernel stack trace when a tunnel socket is closed.

A way to reproduce the issue is to prepare the UDP socket for L2TP (by
opening a tunnel pppol2tp socket) and then close it before any L2TP
sessions are added to it. The sequence is

Create UDP socket
Create tunnel pppol2tp socket to prepare UDP socket for L2TP
  pppol2tp_connect: session_id=0, peer_session_id=0
L2TP SCCRP control frame received (tunnel_id==0)
  pppol2tp_recv_core: sock_hold()
  pppol2tp_recv_core: sock_put
L2TP ZLB control frame received (tunnel_id=nnn)
  pppol2tp_recv_core: sock_hold()
  pppol2tp_recv_core: sock_put
Close tunnel management socket
  pppol2tp_release: session_id=0, peer_session_id=0
Close UDP socket
  udp_lib_close: BUG

The addition of sock_hold() in pppol2tp_connect() solves the problem.

For data frames, two sock_put() calls were added to plug a refcnt leak
per received data frame. The ref that is grabbed at the top of
pppol2tp_recv_core() must always be released, but this wasn't done for
accepted data frames or data frames discarded because of bad UDP
checksums. This leak meant that any UDP socket that had passed L2TP
data traffic (i.e. L2TP data frames, not just L2TP control frames)
using pppol2tp would not be released by the kernel.

WARNING: at include/net/sock.h:435 udp_lib_unhash+0x117/0x120()
Pid: 1086, comm: openl2tpd Not tainted 2.6.33-rc1 #8
Call Trace:
 [<c119e9b7>] ? udp_lib_unhash+0x117/0x120
 [<c101b871>] ? warn_slowpath_common+0x71/0xd0
 [<c119e9b7>] ? udp_lib_unhash+0x117/0x120
 [<c101b8e3>] ? warn_slowpath_null+0x13/0x20
 [<c119e9b7>] ? udp_lib_unhash+0x117/0x120
 [<c11598a7>] ? sk_common_release+0x17/0x90
 [<c11a5e33>] ? inet_release+0x33/0x60
 [<c11577b0>] ? sock_release+0x10/0x60
 [<c115780f>] ? sock_close+0xf/0x30
 [<c106e542>] ? __fput+0x52/0x150
 [<c106b68e>] ? filp_close+0x3e/0x70
 [<c101d2e2>] ? put_files_struct+0x62/0xb0
 [<c101eaf7>] ? do_exit+0x5e7/0x650
 [<c1081623>] ? mntput_no_expire+0x13/0x70
 [<c106b68e>] ? filp_close+0x3e/0x70
 [<c101eb8a>] ? do_group_exit+0x2a/0x70
 [<c101ebe1>] ? sys_exit_group+0x11/0x20
 [<c10029b0>] ? sysenter_do_call+0x12/0x26

Signed-off-by: James Chapman <jchapman@katalix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
l2tp: Fix oops in pppol2tp_xmit 2010-04-01T23:02:00+00:00 James Chapman jchapman@katalix.com 2010-03-16T06:46:31+00:00 e76f69dbee1d94e88a47c7d811c17647d0326ab3 [ Upstream commit 3feec9095d12e311b7d4eb7fe7e5dfa75d4a72a5 ] When transmitting L2TP frames, we derive the outgoing interface's UDP checksum hardware assist capabilities from the tunnel dst dev. This can sometimes be NULL, especially when routing protocols are used and routing changes occur. This patch just checks for NULL dst or dev pointers when checking for netdev hardware assist features. BUG: unable to handle kernel NULL pointer dereference at 0000000c IP: [<f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp] *pde = 00000000 Oops: 0000 [#1] SMP last sysfs file: /sys/class/net/lo/operstate Modules linked in: pppol2tp pppox ppp_generic slhc ipv6 dummy loop snd_hda_codec_atihdmi snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore snd_page_alloc evdev psmouse serio_raw processor button i2c_piix4 i2c_core ati_agp agpgart pcspkr ext3 jbd mbcache sd_mod ide_pci_generic atiixp ide_core ahci ata_generic floppy ehci_hcd ohci_hcd libata e1000e scsi_mod usbcore nls_base thermal fan thermal_sys [last unloaded: scsi_wait_scan] Pid: 0, comm: swapper Not tainted (2.6.32.8 #1) EIP: 0060:[<f89d074c>] EFLAGS: 00010297 CPU: 3 EIP is at pppol2tp_xmit+0x341/0x4da [pppol2tp] EAX: 00000000 EBX: f64d1680 ECX: 000005b9 EDX: 00000000 ESI: f6b91850 EDI: f64d16ac EBP: f6a0c4c0 ESP: f70a9cac DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process swapper (pid: 0, ti=f70a8000 task=f70a31c0 task.ti=f70a8000) Stack: 000005a9 000005b9 f734c400 f66652c0 f7352e00 f67dc800 00000000 f6b91800 <0> 000005a3 f70ef6c4 f67dcda9 000005a3 f89b192e 00000246 000005a3 f64d1680 <0> f63633e0 f6363320 f64d1680 f65a7320 f65a7364 f65856c0 f64d1680 f679f02f Call Trace: [<f89b192e>] ? ppp_push+0x459/0x50e [ppp_generic] [<f89b217f>] ? ppp_xmit_process+0x3b6/0x430 [ppp_generic] [<f89b2306>] ? ppp_start_xmit+0x10d/0x120 [ppp_generic] [<c11c15cb>] ? dev_hard_start_xmit+0x21f/0x2b2 [<c11d0947>] ? sch_direct_xmit+0x48/0x10e [<c11c19a0>] ? dev_queue_xmit+0x263/0x3a6 [<c11e2a9f>] ? ip_finish_output+0x1f7/0x221 [<c11df682>] ? ip_forward_finish+0x2e/0x30 [<c11de645>] ? ip_rcv_finish+0x295/0x2a9 [<c11c0b19>] ? netif_receive_skb+0x3e9/0x404 [<f814b791>] ? e1000_clean_rx_irq+0x253/0x2fc [e1000e] [<f814cb7a>] ? e1000_clean+0x63/0x1fc [e1000e] [<c1047eff>] ? sched_clock_local+0x15/0x11b [<c11c1095>] ? net_rx_action+0x96/0x195 [<c1035750>] ? __do_softirq+0xaa/0x151 [<c1035828>] ? do_softirq+0x31/0x3c [<c10358fe>] ? irq_exit+0x26/0x58 [<c1004b21>] ? do_IRQ+0x78/0x89 [<c1003729>] ? common_interrupt+0x29/0x30 [<c101ac28>] ? native_safe_halt+0x2/0x3 [<c1008c54>] ? default_idle+0x55/0x75 [<c1009045>] ? c1e_idle+0xd2/0xd5 [<c100233c>] ? cpu_idle+0x46/0x62 Code: 8d 45 08 f0 ff 45 08 89 6b 08 c7 43 68 7e fb 9c f8 8a 45 24 83 e0 0c 3c 04 75 09 80 63 64 f3 e9 b4 00 00 00 8b 43 18 8b 4c 24 04 <8b> 40 0c 8d 79 11 f6 40 44 0e 8a 43 64 75 51 6a 00 8b 4c 24 08 EIP: [<f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp] SS:ESP 0068:f70a9cac CR2: 000000000000000c Signed-off-by: James Chapman <jchapman@katalix.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[ Upstream commit 3feec9095d12e311b7d4eb7fe7e5dfa75d4a72a5 ]

When transmitting L2TP frames, we derive the outgoing interface's UDP
checksum hardware assist capabilities from the tunnel dst dev. This
can sometimes be NULL, especially when routing protocols are used and
routing changes occur. This patch just checks for NULL dst or dev
pointers when checking for netdev hardware assist features.

BUG: unable to handle kernel NULL pointer dereference at 0000000c
IP: [<f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp]
*pde = 00000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/class/net/lo/operstate
Modules linked in: pppol2tp pppox ppp_generic slhc ipv6 dummy loop snd_hda_codec_atihdmi snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore snd_page_alloc evdev psmouse serio_raw processor button i2c_piix4 i2c_core ati_agp agpgart pcspkr ext3 jbd mbcache sd_mod ide_pci_generic atiixp ide_core ahci ata_generic floppy ehci_hcd ohci_hcd libata e1000e scsi_mod usbcore nls_base thermal fan thermal_sys [last unloaded: scsi_wait_scan]

Pid: 0, comm: swapper Not tainted (2.6.32.8 #1)
EIP: 0060:[<f89d074c>] EFLAGS: 00010297 CPU: 3
EIP is at pppol2tp_xmit+0x341/0x4da [pppol2tp]
EAX: 00000000 EBX: f64d1680 ECX: 000005b9 EDX: 00000000
ESI: f6b91850 EDI: f64d16ac EBP: f6a0c4c0 ESP: f70a9cac
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=f70a8000 task=f70a31c0 task.ti=f70a8000)
Stack:
 000005a9 000005b9 f734c400 f66652c0 f7352e00 f67dc800 00000000 f6b91800
<0> 000005a3 f70ef6c4 f67dcda9 000005a3 f89b192e 00000246 000005a3 f64d1680
<0> f63633e0 f6363320 f64d1680 f65a7320 f65a7364 f65856c0 f64d1680 f679f02f
Call Trace:
 [<f89b192e>] ? ppp_push+0x459/0x50e [ppp_generic]
 [<f89b217f>] ? ppp_xmit_process+0x3b6/0x430 [ppp_generic]
 [<f89b2306>] ? ppp_start_xmit+0x10d/0x120 [ppp_generic]
 [<c11c15cb>] ? dev_hard_start_xmit+0x21f/0x2b2
 [<c11d0947>] ? sch_direct_xmit+0x48/0x10e
 [<c11c19a0>] ? dev_queue_xmit+0x263/0x3a6
 [<c11e2a9f>] ? ip_finish_output+0x1f7/0x221
 [<c11df682>] ? ip_forward_finish+0x2e/0x30
 [<c11de645>] ? ip_rcv_finish+0x295/0x2a9
 [<c11c0b19>] ? netif_receive_skb+0x3e9/0x404
 [<f814b791>] ? e1000_clean_rx_irq+0x253/0x2fc [e1000e]
 [<f814cb7a>] ? e1000_clean+0x63/0x1fc [e1000e]
 [<c1047eff>] ? sched_clock_local+0x15/0x11b
 [<c11c1095>] ? net_rx_action+0x96/0x195
 [<c1035750>] ? __do_softirq+0xaa/0x151
 [<c1035828>] ? do_softirq+0x31/0x3c
 [<c10358fe>] ? irq_exit+0x26/0x58
 [<c1004b21>] ? do_IRQ+0x78/0x89
 [<c1003729>] ? common_interrupt+0x29/0x30
 [<c101ac28>] ? native_safe_halt+0x2/0x3
 [<c1008c54>] ? default_idle+0x55/0x75
 [<c1009045>] ? c1e_idle+0xd2/0xd5
 [<c100233c>] ? cpu_idle+0x46/0x62
Code: 8d 45 08 f0 ff 45 08 89 6b 08 c7 43 68 7e fb 9c f8 8a 45 24 83 e0 0c 3c 04 75 09 80 63 64 f3 e9 b4 00 00 00 8b 43 18 8b 4c 24 04 <8b> 40 0c 8d 79 11 f6 40 44 0e 8a 43 64 75 51 6a 00 8b 4c 24 08
EIP: [<f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp] SS:ESP 0068:f70a9cac
CR2: 000000000000000c

Signed-off-by: James Chapman <jchapman@katalix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
sparc64: Add very basic XVR-1000 framebuffer driver. 2010-04-01T23:02:00+00:00 David S. Miller davem@davemloft.net 2010-03-30T05:18:29+00:00 6bd0d3167304e1d07486d716360695451f2bc94e [ Upstream commits 2d378b9179881b46a0faf11430efb421fe03ddd8 and f04e879bf296d136bcafd8c5a26e95599b141671 ] Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Frans van Berckel <fberckel@xs4all.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[ Upstream commits 2d378b9179881b46a0faf11430efb421fe03ddd8 and
  f04e879bf296d136bcafd8c5a26e95599b141671 ]

Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Frans van Berckel <fberckel@xs4all.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>