- 03 5月, 2010 1 次提交
-
-
由 Jan Engelhardt 提交于
Fix this one: include/net/sock.h: error: two or more data types in declaration specifiers Signed-off-by: NJan Engelhardt <jengelh@medozas.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 02 5月, 2010 1 次提交
-
-
由 Elina Pasheva 提交于
The following patch adds the initiation of the sync sequence to "sierra_net_bind()". If this step is omitted, the modem will never sync up with the host and it will not be possible to establish a data connection. Signed-off-by: NElina Pasheva <epasheva@sierrawireless.com> Signed-off-by: NRory Filer <rfiler@sierrawireless.com> Tested-by: NElina Pasheva <epasheva@sierrawireless.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 01 5月, 2010 4 次提交
-
-
由 Elina Pasheva 提交于
The following patch removes the default from the Kconfig entry for sierra_net driver as recommended. Signed-off-by: NElina Pasheva <epasheva@sierrawireless.com> Signed-off-by: NRory Filer <rfiler@sierrawireless.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eric Dumazet 提交于
In case a reset is performed, rtl8169_rx_interrupt() is called from process context instead of softirq context. Special care must be taken to call appropriate network core services (netif_rx() instead of netif_receive_skb()). VLAN handling also corrected. Reported-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com> Tested-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com> Diagnosed-by: NOleg Nesterov <oleg@redhat.com> Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Anton Blanchard 提交于
Commit 6f461f6c ("e1000e: enable/disable ASPM L0s and L1 and ERT according to hardware errata") oopses on one of my ppc64 boxes with a NULL pointer (0x4a): Unable to handle kernel paging request for data at address 0x0000004a Faulting instruction address: 0xc0000000004d2f1c cpu 0xe: Vector: 300 (Data Access) at [c000000bec1833a0] pc: c0000000004d2f1c: .e1000e_disable_aspm+0xe0/0x150 lr: c0000000004d2f0c: .e1000e_disable_aspm+0xd0/0x150 dar: 4a [c000000bec1836d0] c00000000069b9d8 .e1000_probe+0x84/0xe8c [c000000bec1837b0] c000000000386d90 .local_pci_probe+0x4c/0x68 [c000000bec183840] c0000000003872ac .pci_device_probe+0xfc/0x148 [c000000bec183900] c000000000409e8c .driver_probe_device+0xe4/0x1d0 [c000000bec1839a0] c00000000040a024 .__driver_attach+0xac/0xf4 [c000000bec183a40] c000000000409124 .bus_for_each_dev+0x9c/0x10c [c000000bec183b00] c000000000409c1c .driver_attach+0x40/0x60 [c000000bec183b90] c0000000004085dc .bus_add_driver+0x150/0x328 [c000000bec183c40] c00000000040a58c .driver_register+0x100/0x1c4 [c000000bec183cf0] c00000000038764c .__pci_register_driver+0x78/0x128 Seems like pdev->bus->self == NULL. I haven't touched pci in a long time so I'm trying to remember what this means (no pcie bridge perhaps?) The patch below fixes the oops for me. Signed-off-by: NAnton Blanchard <anton@samba.org> Reviewed-by: NBruce Allan <bruce.w.allan@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 29 4月, 2010 11 次提交
-
-
由 Sebastian Siewior 提交于
"ifconfig eth0 up && ifconfig eth0 down" triggers: | kobject (a8000000cfa5a480): tried to init an initialized object, something is seriously wrong. | Call Trace: | [<ffffffff8010aabc>] dump_stack+0x8/0x34 | [<ffffffff80293128>] kobject_init+0xe8/0xf0 | [<ffffffff802d922c>] device_initialize+0x2c/0x98 | [<ffffffff802d9cfc>] device_register+0x14/0x28 | [<ffffffff80312cd4>] mdiobus_register+0xdc/0x1e0 | [<ffffffff80314cf0>] sbmac_open+0x58/0x220 | [<ffffffff803519bc>] __dev_open+0x11c/0x180 | [<ffffffff8034d578>] __dev_change_flags+0x120/0x180 | [<ffffffff80351848>] dev_change_flags+0x20/0x78 | [<ffffffff803a753c>] devinet_ioctl+0x7cc/0x820 | [<ffffffff80339ac8>] sock_do_ioctl+0x38/0x90 | [<ffffffff8033a258>] compat_sock_ioctl_trans+0x408/0x1030 | [<ffffffff8033af30>] compat_sock_ioctl+0xb0/0xd0 | [<ffffffff80208b08>] compat_sys_ioctl+0xa0/0x18b8 | [<ffffffff80102f94>] handle_sys+0x114/0x130 | | sb1250-mac-mdio: probed mdiobus_register() calls device_register() which initializes the kobj of the device. mdiobus_unregister() calls only device_del() so we have one reference left. That one is leaving with mdiobus_free() which is only called on remove. Since I don't see any reason why mdiobus_register()/mdiobus_unregister() should happen in ->open()/->close() I move them to probe & exit. Signed-off-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Neil Horman 提交于
Ok, version 4 Change Notes: 1) Minor cleanups, from Vlads notes Summary: Hey- Recently, it was reported to me that the kernel could oops in the following way: <5> kernel BUG at net/core/skbuff.c:91! <5> invalid operand: 0000 [#1] <5> Modules linked in: sctp netconsole nls_utf8 autofs4 sunrpc iptable_filter ip_tables cpufreq_powersave parport_pc lp parport vmblock(U) vsock(U) vmci(U) vmxnet(U) vmmemctl(U) vmhgfs(U) acpiphp dm_mirror dm_mod button battery ac md5 ipv6 uhci_hcd ehci_hcd snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_ac97_codec snd soundcore pcnet32 mii floppy ext3 jbd ata_piix libata mptscsih mptsas mptspi mptscsi mptbase sd_mod scsi_mod <5> CPU: 0 <5> EIP: 0060:[<c02bff27>] Not tainted VLI <5> EFLAGS: 00010216 (2.6.9-89.0.25.EL) <5> EIP is at skb_over_panic+0x1f/0x2d <5> eax: 0000002c ebx: c033f461 ecx: c0357d96 edx: c040fd44 <5> esi: c033f461 edi: df653280 ebp: 00000000 esp: c040fd40 <5> ds: 007b es: 007b ss: 0068 <5> Process swapper (pid: 0, threadinfo=c040f000 task=c0370be0) <5> Stack: c0357d96 e0c29478 00000084 00000004 c033f461 df653280 d7883180 e0c2947d <5> 00000000 00000080 df653490 00000004 de4f1ac0 de4f1ac0 00000004 df653490 <5> 00000001 e0c2877a 08000800 de4f1ac0 df653490 00000000 e0c29d2e 00000004 <5> Call Trace: <5> [<e0c29478>] sctp_addto_chunk+0xb0/0x128 [sctp] <5> [<e0c2947d>] sctp_addto_chunk+0xb5/0x128 [sctp] <5> [<e0c2877a>] sctp_init_cause+0x3f/0x47 [sctp] <5> [<e0c29d2e>] sctp_process_unk_param+0xac/0xb8 [sctp] <5> [<e0c29e90>] sctp_verify_init+0xcc/0x134 [sctp] <5> [<e0c20322>] sctp_sf_do_5_1B_init+0x83/0x28e [sctp] <5> [<e0c25333>] sctp_do_sm+0x41/0x77 [sctp] <5> [<c01555a4>] cache_grow+0x140/0x233 <5> [<e0c26ba1>] sctp_endpoint_bh_rcv+0xc5/0x108 [sctp] <5> [<e0c2b863>] sctp_inq_push+0xe/0x10 [sctp] <5> [<e0c34600>] sctp_rcv+0x454/0x509 [sctp] <5> [<e084e017>] ipt_hook+0x17/0x1c [iptable_filter] <5> [<c02d005e>] nf_iterate+0x40/0x81 <5> [<c02e0bb9>] ip_local_deliver_finish+0x0/0x151 <5> [<c02e0c7f>] ip_local_deliver_finish+0xc6/0x151 <5> [<c02d0362>] nf_hook_slow+0x83/0xb5 <5> [<c02e0bb2>] ip_local_deliver+0x1a2/0x1a9 <5> [<c02e0bb9>] ip_local_deliver_finish+0x0/0x151 <5> [<c02e103e>] ip_rcv+0x334/0x3b4 <5> [<c02c66fd>] netif_receive_skb+0x320/0x35b <5> [<e0a0928b>] init_stall_timer+0x67/0x6a [uhci_hcd] <5> [<c02c67a4>] process_backlog+0x6c/0xd9 <5> [<c02c690f>] net_rx_action+0xfe/0x1f8 <5> [<c012a7b1>] __do_softirq+0x35/0x79 <5> [<c0107efb>] handle_IRQ_event+0x0/0x4f <5> [<c01094de>] do_softirq+0x46/0x4d Its an skb_over_panic BUG halt that results from processing an init chunk in which too many of its variable length parameters are in some way malformed. The problem is in sctp_process_unk_param: if (NULL == *errp) *errp = sctp_make_op_error_space(asoc, chunk, ntohs(chunk->chunk_hdr->length)); if (*errp) { sctp_init_cause(*errp, SCTP_ERROR_UNKNOWN_PARAM, WORD_ROUND(ntohs(param.p->length))); sctp_addto_chunk(*errp, WORD_ROUND(ntohs(param.p->length)), param.v); When we allocate an error chunk, we assume that the worst case scenario requires that we have chunk_hdr->length data allocated, which would be correct nominally, given that we call sctp_addto_chunk for the violating parameter. Unfortunately, we also, in sctp_init_cause insert a sctp_errhdr_t structure into the error chunk, so the worst case situation in which all parameters are in violation requires chunk_hdr->length+(sizeof(sctp_errhdr_t)*param_count) bytes of data. The result of this error is that a deliberately malformed packet sent to a listening host can cause a remote DOS, described in CVE-2010-1173: http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-1173 I've tested the below fix and confirmed that it fixes the issue. We move to a strategy whereby we allocate a fixed size error chunk and ignore errors we don't have space to report. Tested by me successfully Signed-off-by: NNeil Horman <nhorman@tuxdriver.com> Acked-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ben Hutchings 提交于
The driver needs specific PHY and board support code for each SFC4000 board; there is no point trying to continue if it is missing. Currently unsupported boards can trigger an 'oops'. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Cc: stable@kernel.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ben Hutchings 提交于
This fixes a regression introduced by commit eb9f6744 "sfc: Implement ethtool reset operation". Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Cc: stable@kernel.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ben Hutchings 提交于
The original code would wait indefinitely if MAC stats DMA failed. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Cc: stable@kernel.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vlad Yasevich 提交于
When we finish processing ASCONF_ACK chunk, we try to send the next queued ASCONF. This action runs the sctp state machine recursively and it's not prepared to do so. kernel BUG at kernel/timer.c:790! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/module/ipv6/initstate Modules linked in: sha256_generic sctp libcrc32c ipv6 dm_multipath uinput 8139too i2c_piix4 8139cp mii i2c_core pcspkr virtio_net joydev floppy virtio_blk virtio_pci [last unloaded: scsi_wait_scan] Pid: 0, comm: swapper Not tainted 2.6.34-rc4 #15 /Bochs EIP: 0060:[<c044a2ef>] EFLAGS: 00010286 CPU: 0 EIP is at add_timer+0xd/0x1b EAX: cecbab14 EBX: 000000f0 ECX: c0957b1c EDX: 03595cf4 ESI: cecba800 EDI: cf276f00 EBP: c0957aa0 ESP: c0957aa0 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process swapper (pid: 0, ti=c0956000 task=c0988ba0 task.ti=c0956000) Stack: c0957ae0 d1851214 c0ab62e4 c0ab5f26 0500ffff 00000004 00000005 00000004 <0> 00000000 d18694fd 00000004 1666b892 cecba800 cecba800 c0957b14 00000004 <0> c0957b94 d1851b11 ceda8b00 cecba800 cf276f00 00000001 c0957b14 000000d0 Call Trace: [<d1851214>] ? sctp_side_effects+0x607/0xdfc [sctp] [<d1851b11>] ? sctp_do_sm+0x108/0x159 [sctp] [<d1863386>] ? sctp_pname+0x0/0x1d [sctp] [<d1861a56>] ? sctp_primitive_ASCONF+0x36/0x3b [sctp] [<d185657c>] ? sctp_process_asconf_ack+0x2a4/0x2d3 [sctp] [<d184e35c>] ? sctp_sf_do_asconf_ack+0x1dd/0x2b4 [sctp] [<d1851ac1>] ? sctp_do_sm+0xb8/0x159 [sctp] [<d1863334>] ? sctp_cname+0x0/0x52 [sctp] [<d1854377>] ? sctp_assoc_bh_rcv+0xac/0xe1 [sctp] [<d1858f0f>] ? sctp_inq_push+0x2d/0x30 [sctp] [<d186329d>] ? sctp_rcv+0x797/0x82e [sctp] Tested-by: NWei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: NYuansong Qiao <ysqiao@research.ait.ie> Signed-off-by: NShuaijun Zhang <szhang@research.ait.ie> Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Wei Yongjun 提交于
When calculating the INIT/INIT-ACK chunk length, we should not only account the length of parameters, but also the parameters zero padding length, such as AUTH HMACS parameter and CHUNKS parameter. Without the parameters zero padding length we may get following oops. skb_over_panic: text:ce2068d2 len:130 put:6 head:cac3fe00 data:cac3fe00 tail:0xcac3fe82 end:0xcac3fe80 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:127! invalid opcode: 0000 [#2] SMP last sysfs file: /sys/module/aes_generic/initstate Modules linked in: authenc ...... Pid: 4102, comm: sctp_darn Tainted: G D 2.6.34-rc2 #6 EIP: 0060:[<c0607630>] EFLAGS: 00010282 CPU: 0 EIP is at skb_over_panic+0x37/0x3e EAX: 00000078 EBX: c07c024b ECX: c07c02b9 EDX: cb607b78 ESI: 00000000 EDI: cac3fe7a EBP: 00000002 ESP: cb607b74 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process sctp_darn (pid: 4102, ti=cb607000 task=cabdc990 task.ti=cb607000) Stack: c07c02b9 ce2068d2 00000082 00000006 cac3fe00 cac3fe00 cac3fe82 cac3fe80 <0> c07c024b cac3fe7c cac3fe7a c0608dec ca986e80 ce2068d2 00000006 0000007a <0> cb8120ca ca986e80 cb812000 00000003 cb8120c4 ce208a25 cb8120ca cadd9400 Call Trace: [<ce2068d2>] ? sctp_addto_chunk+0x45/0x85 [sctp] [<c0608dec>] ? skb_put+0x2e/0x32 [<ce2068d2>] ? sctp_addto_chunk+0x45/0x85 [sctp] [<ce208a25>] ? sctp_make_init+0x279/0x28c [sctp] [<c0686a92>] ? apic_timer_interrupt+0x2a/0x30 [<ce1fdc0b>] ? sctp_sf_do_prm_asoc+0x2b/0x7b [sctp] [<ce202823>] ? sctp_do_sm+0xa0/0x14a [sctp] [<ce2133b9>] ? sctp_pname+0x0/0x14 [sctp] [<ce211d72>] ? sctp_primitive_ASSOCIATE+0x2b/0x31 [sctp] [<ce20f3cf>] ? sctp_sendmsg+0x7a0/0x9eb [sctp] [<c064eb1e>] ? inet_sendmsg+0x3b/0x43 [<c04244b7>] ? task_tick_fair+0x2d/0xd9 [<c06031e1>] ? sock_sendmsg+0xa7/0xc1 [<c0416afe>] ? smp_apic_timer_interrupt+0x6b/0x75 [<c0425123>] ? dequeue_task_fair+0x34/0x19b [<c0446abb>] ? sched_clock_local+0x17/0x11e [<c052ea87>] ? _copy_from_user+0x2b/0x10c [<c060ab3a>] ? verify_iovec+0x3c/0x6a [<c06035ca>] ? sys_sendmsg+0x186/0x1e2 [<c042176b>] ? __wake_up_common+0x34/0x5b [<c04240c2>] ? __wake_up+0x2c/0x3b [<c057e35c>] ? tty_wakeup+0x43/0x47 [<c04430f2>] ? remove_wait_queue+0x16/0x24 [<c0580c94>] ? n_tty_read+0x5b8/0x65e [<c042be02>] ? default_wake_function+0x0/0x8 [<c0604e0e>] ? sys_socketcall+0x17f/0x1cd [<c040264c>] ? sysenter_do_call+0x12/0x22 Code: 0f 45 de 53 ff b0 98 00 00 00 ff b0 94 ...... EIP: [<c0607630>] skb_over_panic+0x37/0x3e SS:ESP 0068:cb607b74 To reproduce: # modprobe sctp # echo 1 > /proc/sys/net/sctp/addip_enable # echo 1 > /proc/sys/net/sctp/auth_enable # sctp_test -H 3ffe:501:ffff:100:20c:29ff:fe4d:f37e -P 800 -l # sctp_darn -H 3ffe:501:ffff:100:20c:29ff:fe4d:f37e -P 900 -h 192.168.0.21 -p 800 -I -s -t sctp_darn ready to send... 3ffe:501:ffff:100:20c:29ff:fe4d:f37e:900-192.168.0.21:800 Interactive mode> bindx-add=192.168.0.21 3ffe:501:ffff:100:20c:29ff:fe4d:f37e:900-192.168.0.21:800 Interactive mode> bindx-add=192.168.1.21 3ffe:501:ffff:100:20c:29ff:fe4d:f37e:900-192.168.0.21:800 Interactive mode> snd=10 ------------------------------------------------------------------ eth0 has addresses: 3ffe:501:ffff:100:20c:29ff:fe4d:f37e and 192.168.0.21 eth1 has addresses: 192.168.1.21 ------------------------------------------------------------------ Reported-by: NGeorge Cheimonidis <gchimon@gmail.com> Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vlad Yasevich 提交于
Since the change of the atomics to percpu variables, we now have to disable BH in process context when touching percpu variables. Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vlad Yasevich 提交于
When sctp attempts to update an assocition, it removes any addresses that were not in the updated INITs. However, the loop may attempt to refrence a transport with address after removing it. Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Wei Yongjun 提交于
sk->sk_data_ready() of sctp socket can be called from both BH and non-BH contexts, but the default sk->sk_data_ready(), sock_def_readable(), can not be used in this case. Therefore, we have to make a new function sctp_data_ready() to grab sk->sk_data_ready() with BH disabling. ========================================================= [ INFO: possible irq lock inversion dependency detected ] 2.6.33-rc6 #129 --------------------------------------------------------- sctp_darn/1517 just changed the state of lock: (clock-AF_INET){++.?..}, at: [<c06aab60>] sock_def_readable+0x20/0x80 but this lock took another, SOFTIRQ-unsafe lock in the past: (slock-AF_INET){+.-...} and interrupts could create inverse lock ordering between them. other info that might help us debug this: 1 lock held by sctp_darn/1517: #0: (sk_lock-AF_INET){+.+.+.}, at: [<cdfe363d>] sctp_sendmsg+0x23d/0xc00 [sctp] Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
This reverts two commits: fda48a0d tcp: bind() fix when many ports are bound and a follow-on fix for it: 6443bb1f ipv6: Fix inet6_csk_bind_conflict() It causes problems with binding listening sockets when time-wait sockets from a previous instance still are alive. It's too late to keep fiddling with this so late in the -rc series, and we'll deal with it in net-next-2.6 instead. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 28 4月, 2010 13 次提交
-
-
由 Elina Pasheva 提交于
Re-submitted based on comments from netdev community. Summary of the changes: 1. Improved error handling. 2. Added the missing timeout arguments to usb_control_msg(). The following is a new Linux driver which exposes certain models of Sierra Wireless modems to the operating system as Network Interface Cards (NICs). This driver requires a version of the sierra.c driver which supports blacklisting to work properly. The blacklist in sierra.c rejects the interfaces claimed by sierra_net.c. Likewise, the sierra_net.c driver only accepts (i.e. whitelists) the interface(s) used for USB-to-WWAN traffic. The version of sierra.c which supports blacklisting is available from the sierra wireless knowledge base page for older kernels. It is also available in Linux kernel starting from version 2.6.31. This driver works with all Sierra Wireless devices configured with PID=68A3 like USB305, USB306 provided the corresponding firmware version is I2.0 (for USB305) or M3.0 (for USB306) and later. This driver will not work with earlier firmware versions than the ones shown above. In this case the driver will issue an error message indicating incompatibility and will not serve the device's USB-to-WWAN interface. Sierra_net.c sits atop a pre-existing Linux driver called usbnet.c. A series of hook functions are provided in sierra_net.c which are called by usbnet.c in response to a particular condition such as receipt or transmission of a data packet. As such, usbnet.c does most of the work of making a modem appear to the system as a network device and for properly exchanging traffic between the USB subsystem and the Network card interface. Sierra_net.c is concerned with managing the data exchanged between the USB-to-WWAN interface and the upper layers of the operating system. Signed-off-by: NElina Pasheva <epasheva@sierrawireless.com> Signed-off-by: NRory Filer <rfiler@sierrawireless.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Torgny Johansson 提交于
Autosuspend works until you bring the wwan interface up, then the device does not enter autosuspend anymore. The following patch fixes the problem by setting the .manage_power field in the mbm_info struct to the same as in the cdc_info struct (cdc_manager_power). Signed-off-by: NTorgny Johansson <torgny.johansson@ericsson.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
l2cap_create_connless_pdu() can sometimes return ERR_PTR(-ENOMEM) or ERR_PTR(-EFAULT). Signed-off-by: NDan Carpenter <error27@gmail.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Andy Fleming 提交于
When gracefully stopping the controller, the driver was continuing if *either* RX or TX had stopped. We need to wait for both, or the controller could get into an invalid state. Signed-off-by: NAndy Fleming <afleming@freescale.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
The calls to usb_free_buffer() dereference rx_urb and tx_urb in the parameter list but those could be NULL. Signed-off-by: NDan Carpenter <error27@gmail.com> Acked-by: NL. Alberto Giménez <agimenez@sysvalve.es> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ken Kawasaki 提交于
smc91c92_cs: * spin_unlock_irqrestore before calling smc_interrupt() in media_check() to avoid lockup. * use spin_lock_irqsave for ethtool function. Signed-off-by: NKen Kawasaki <ken_kawasaki@spring.nifty.jp> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Andreas Hartmann 提交于
akpm: reluctantly typed in from https://bugzilla.kernel.org/show_bug.cgi?id=15599Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
The bonding driver calls ndo_vlan_rx_register() while holding bond->lock. The bnx2 driver calls bnx2_netif_stop() to stop the rx handling while changing the vlgrp. The call also stops the cnic driver which sleeps while the bond->lock is held and cause the warning. This code path only needs to stop the NAPI rx handling while we are changing the vlgrp. Since no reset is going to occur, there is no need to stop cnic in this case. By adding a parameter to bnx2_netif_stop() to skip stopping cnic, we can avoid the warning. Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
It has been reported that under certain heavy traffic conditions in MSI-X mode, the driver can lose an MSI-X vector causing all packets in the associated rx/tx ring pair to be dropped. The problem is caused by the chip dropping the write to unmask the MSI-X vector by the kernel (when migrating the IRQ for example). This can be prevented by increasing the GRC timeout value for these register read and write operations. Thanks to Dell for helping us debug this problem. Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Andre Detsch 提交于
In some Power7 platforms, when using VIOS (Virtual I/O Server), we need to wait longer for control packets to finish transfer during initialization. Without this change, initialization may fail prematurely. Signed-off-by: NWen Xiong <wenxiong@us.ibm.com> Signed-off-by: NAndre Detsch <adetsch@br.ibm.com> Acked-by: NDivy Le Ray <divy@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Bruce Allan 提交于
Prompted by a previous patch submitted by Matthew Garret <mjg@redhat.com>, further digging into errata documentation reveals the current enabling or disabling of ASPM L0s and L1 states for certain parts supported by this driver are incorrect. 82571 and 82572 should always disable L1. For standard frames, 82573/82574/82583 can enable L1 but L0s must be disabled, and for jumbo frames 82573/82574 must disable L1. This allows for some parts to enable L1 in certain configurations leading to better power savings. Also according to the same errata, Early Receive (ERT) should be disabled on 82573 when using jumbo frames. Cc: Matthew Garret <mjg@redhat.com> Signed-off-by: NBruce Allan <bruce.w.allan@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Peter Waskiewicz 提交于
The PHY laser is still on during driver init. It's allowing garbage to hit our FIFO, which eventually can cause the entire device to die. Power down the laser while setting up the device, and re-enable the laser before getting link. Signed-off-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 27 4月, 2010 6 次提交
-
-
由 françois romieu 提交于
78f1cd02 ("fix broken register writes") does not work for Al Viro's r8169 (XID 18000000). Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 françois romieu 提交于
Few (6) network drivers enable mwi explicitly. Fewer worry about a failure. It is not a fix but it should avoid some annoyance like http://bugzilla.kernel.org/show_bug.cgi?id=15454Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Conrad Kostecki <conikost@gmx.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 YOSHIFUJI Hideaki / 吉藤英明 提交于
Even with commit 32dec5dd ("bridge br_multicast: Don't refer to BR_INPUT_SKB_CB(skb)->mrouters_only without IGMP snooping."), BR_INPUT_SKB_CB(skb)->mrouters_only is not appropriately initialized if IGMP snooping support is compiled and disabled, so we can see garbage. Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Stefan Schmidt 提交于
Trying to run izlisten (from lowpan-tools tests) on a device that does not exists I got the oops below. The problem is that we are using get_dev_by_name without checking if we really get a device back. We don't in this case and writing to dev->type generates this oops. [Oops code removed by Dmitry Eremin-Solenikov] If possible this patch should be applied to the current -rc fixes branch. Signed-off-by: NStefan Schmidt <stefan@datenfreihafen.org> Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Hans de Goede 提交于
Hans de Goede identified a bug in p54p_check_tx_ring: there are two ring indices. 1 => tx data and 3 => tx management. But the old code had a constant "1" and this resulted in spurious dma unmapping failures. Cc: stable@kernel.org Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=583623Bug-Identified-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Andre Detsch 提交于
tg3: Fix INTx fallback when MSI fails MSI setup changes the value of irq_vec in struct tg3 *tp. This attribute must be taken into account and restored before we try to do a new request_irq for INTx fallback. In powerpc, the original code was leading to an EINVAL return within request_irq, because the driver was trying to use the disabled MSI virtual irq number instead of tp->pdev->irq. Signed-off-by: NAndre Detsch <adetsch@br.ibm.com> Acked-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 26 4月, 2010 1 次提交
-
-
由 Eric Dumazet 提交于
Commit fda48a0d (tcp: bind() fix when many ports are bound) introduced a bug on IPV6 part. We should not call ipv6_addr_any(inet6_rcv_saddr(sk2)) but ipv6_addr_any(inet6_rcv_saddr(sk)) because sk2 can be IPV4, while sk is IPV6. Reported-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Tested-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 25 4月, 2010 1 次提交
-
-
由 Alan Cox 提交于
Nothing stops the workqueue being left to run in parallel with close or a few other operations. This causes double unmaps and the like. See kerneloops.org #1041230 for an example Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 24 4月, 2010 2 次提交
-
-
由 Anton Vorontsov 提交于
gianfar driver may pass NULL pointer to the of_translate_address(), which may lead to a kernel oops. Fix this by using of_iomap(), which is also much simpler and shorter. Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Anton Vorontsov 提交于
Old P1020RDB device trees were not specifing tbipa address for MDIO nodes, which is now causing this kernel oops: ... eth2: TX BD ring size for Q[6]: 256 eth2: TX BD ring size for Q[7]: 256 Unable to handle kernel paging request for data at address 0x00000000 Faulting instruction address: 0xc0015504 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c0015504] memcpy+0x3c/0x9c LR [c000a9f8] __of_translate_address+0xfc/0x21c Call Trace: [df839e00] [c000a94c] __of_translate_address+0x50/0x21c (unreliable) [df839e50] [c01a33e8] get_gfar_tbipa+0xb0/0xe0 ... The old device trees are buggy, though having a dead ethernet is better than a dead kernel, so fix the issue by using of_iomap(). Also, a somewhat similar issue exist in the probe() routine, though there the oops is only a possibility. Nonetheless, fix it too. Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-