- 06 Mar, 2008 15 commits
-
-
David Brownell authored
Prevent oops on enc28j60 packet RX: make sure buffers are aligned. Not all architectures support unaligned accesses in kernel space. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Acked-by:
Claudio Lanconelli <lanconelli.claudio@eptar.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jon Schindler authored
Replace init_module and cleanup_module with static functions and module_init/module_exit. Signed-off-by:
Jon Schindler <jkschind@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Jon Schindler authored
Replaced init_module and cleanup_module with static functions and module_init/module_exit. Signed-off-by:
-
Jon Schindler authored
Replaced init_module and cleanup_module with static functions and module_init/module_exit. Signed-off-by:
-
Jon Schindler authored
Replaced init_module and cleanup_module with static functions and module_init/module_exit. Signed-off-by:
-
Tobias Klauser authored
bnep_sock_cleanup() always returns 0 and its return value isn't used anywhere in the code. Signed-off-by:
Tobias Klauser <tklauser@distanz.ch> Signed-off-by:
-
Tobias Klauser authored
hci_sock_cleanup() always returns 0 and its return value isn't used anywhere in the code. Compile-tested with 'make allyesconfig && make net/bluetooth/bluetooth.ko' Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Dave Young authored
Alon Bar-Lev reports: Feb 16 23:41:33 alon1 usb 3-1: configuration #1 chosen from 1 choice Feb 16 23:41:33 alon1 BUG: unable to handle kernel NULL pointer dereference at virtual address 00000008 Feb 16 23:41:33 alon1 printing eip: c01b2db6 *pde = 00000000 Feb 16 23:41:33 alon1 Oops: 0000 [#1] PREEMPT Feb 16 23:41:33 alon1 Modules linked in: ppp_deflate zlib_deflate zlib_inflate bsd_comp ppp_async rfcomm l2cap hci_usb vmnet(P) vmmon(P) tun radeon drm autofs4 ipv6 aes_generic crypto_algapi ieee80211_crypt_ccmp nf_nat_irc nf_nat_ftp nf_conntrack_irc nf_conntrack_ftp ipt_MASQUERADE iptable_nat nf_nat ipt_REJECT xt_tcpudp ipt_LOG xt_limit xt_state nf_conntrack_ipv4 nf_conntrack iptable_filter ip_tables x_tables snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device bluetooth ppp_generic slhc ioatdma dca cfq_iosched cpufreq_powersave cpufreq_ondemand cpufreq_conservative acpi_cpufreq freq_table uinput fan af_packet nls_cp1255 nls_iso8859_1 nls_utf8 nls_base pcmcia snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm nsc_ircc snd_timer ipw2200 thinkpad_acpi irda snd ehci_hcd yenta_socket uhci_hcd psmouse ieee80211 soundcore intel_agp hwmon rsrc_nonstatic pcspkr e1000 crc_ccitt snd_page_alloc i2c_i801 ieee80211_crypt pcmcia_core agpgart thermal bat! tery nvram rtc sr_mod ac sg firmware_class button processor cdrom unix usbcore evdev ext3 jbd ext2 mbcache loop ata_piix libata sd_mod scsi_mod Feb 16 23:41:33 alon1 Feb 16 23:41:33 alon1 Pid: 4, comm: events/0 Tainted: P (2.6.24-gentoo-r2 #1) Feb 16 23:41:33 alon1 EIP: 0060:[<c01b2db6>] EFLAGS: 00010282 CPU: 0 Feb 16 23:41:33 alon1 EIP is at sysfs_get_dentry+0x26/0x80 Feb 16 23:41:33 alon1 EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: f48a2210 Feb 16 23:41:33 alon1 ESI: f72eb900 EDI: f4803ae0 EBP: f4803ae0 ESP: f7c49efc Feb 16 23:41:33 alon1 hcid[7004]: HCI dev 0 registered Feb 16 23:41:33 alon1 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 Feb 16 23:41:33 alon1 Process events/0 (pid: 4, ti=f7c48000 task=f7c3efc0 task.ti=f7c48000) Feb 16 23:41:33 alon1 Stack: f7cb6140 f4822668 f7e71e10 c01b304d ffffffff ffffffff fffffffe c030ba9c Feb 16 23:41:33 alon1 f7cb6140 f4822668 f6da6720 f7cb6140 f4822668 f6da6720 c030ba8e c01ce20b Feb 16 23:41:33 alon1 f6e9dd00 c030ba8e f6da6720 f6e9dd00 f6e9dd00 00000000 f4822600 00000000 Feb 16 23:41:33 alon1 Call Trace: Feb 16 23:41:33 alon1 [<c01b304d>] sysfs_move_dir+0x3d/0x1f0 Feb 16 23:41:33 alon1 [<c01ce20b>] kobject_move+0x9b/0x120 Feb 16 23:41:33 alon1 [<c0241711>] device_move+0x51/0x110 Feb 16 23:41:33 alon1 [<f9aaed80>] del_conn+0x0/0x70 [bluetooth] Feb 16 23:41:33 alon1 [<f9aaed99>] del_conn+0x19/0x70 [bluetooth] Feb 16 23:41:33 alon1 [<c012c1a1>] run_workqueue+0x81/0x140 Feb 16 23:41:33 alon1 [<c02c0c88>] schedule+0x168/0x2e0 Feb 16 23:41:33 alon1 [<c012fc70>] autoremove_wake_function+0x0/0x50 Feb 16 23:41:33 alon1 [<c012c9cb>] worker_thread+0x9b/0xf0 Feb 16 23:41:33 alon1 [<c012fc70>] autoremove_wake_function+0x0/0x50 Feb 16 23:41:33 alon1 [<c012c930>] worker_thread+0x0/0xf0 Feb 16 23:41:33 alon1 [<c012f962>] kthread+0x42/0x70 Feb 16 23:41:33 alon1 [<c012f920>] kthread+0x0/0x70 Feb 16 23:41:33 alon1 [<c0104c2f>] kernel_thread_helper+0x7/0x18 Feb 16 23:41:33 alon1 ======================= Feb 16 23:41:33 alon1 Code: 26 00 00 00 00 57 89 c7 a1 50 1b 3a c0 56 53 8b 70 38 85 f6 74 08 8b 0e 85 c9 74 58 ff 06 8b 56 50 39 fa 74 47 89 fb eb 02 89 c3 <8b> 43 08 39 c2 75 f7 8b 46 08 83 c0 68 e8 98 e7 10 00 8b 43 10 Feb 16 23:41:33 alon1 EIP: [<c01b2db6>] sysfs_get_dentry+0x26/0x80 SS:ESP 0068:f7c49efc Feb 16 23:41:33 alon1 ---[ end trace aae864e9592acc1d ]--- Defer hci_unregister_sysfs because hci device could be destructed while hci conn devices still there. Signed-off-by:
Dave Young <hidave.darkstar@gmail.com> Tested-by:
Stefan Seyfried <seife@suse.de> Acked-by:
Alon Bar-Lev <alon.barlev@gmail.com> Signed-off-by:
-
SDiZ authored
From: SDiZ <sdiz@sdiz.net> Fix the CONWISE Technology based adapters with buggy SCO support issue (bugzilla #9027) Signed-off-by:
-
James Chapman authored
When walking a session's packet reorder queue, use skb_queue_walk_safe() since the list could be modified inside the loop. Rearrange the unlinking skbs from the reorder queue such that it is done while the queue lock is held in pppol2tp_recv_dequeue() when walking the skb list. A version of this patch was suggested by Jarek Poplawski. Signed-off-by:
James Chapman <jchapman@katalix.com> Signed-off-by:
-
James Chapman authored
Fix locking issues in the pppol2tp driver which can cause a kernel crash on SMP boxes. There were two problems:- 1. The driver was violating read_lock() and write_lock() scheduling rules because it wasn't using softirq-safe locks in softirq contexts. So we now consistently use the _bh variants of the lock functions. 2. The driver was calling sk_dst_get() in pppol2tp_xmit() which was taking sk_dst_lock in softirq context. We now call __sk_dst_get(). Signed-off-by:
-
Harvey Harrison authored
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by:
-
Harvey Harrison authored
Signed-off-by:
-
Harvey Harrison authored
Signed-off-by:
-
Harvey Harrison authored
Signed-off-by:
-
- 05 Mar, 2008 15 commits
-
-
Neil Horman authored
Brings max_burst socket option set/get into line with the latest ietf socket extensions api draft, while maintaining backwards compatibility. Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by:
-
Gui Jianfeng authored
If an address family is not listed in "Supported Address Types" parameter(INIT Chunk), but the packet is sent by that family, this address family should be considered as supported by peer. Otherwise, an error condition will occur. For instance, if kernel receives an IPV6 SCTP INIT chunk with "Support Address Types" parameter which indicates just supporting IPV4 Address family. Kernel will reply an IPV6 SCTP INIT ACK packet, but the source ipv6 address in ipv6 header will be vacant. This is not correct. refer to RFC4460 as following: IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported Address Types' parameter either IPv4 or IPv6, but uses the other family for sending the packet containing the INIT chunk, or if it also lists addresses of the other family in the INIT chunk, then the address family that is not listed in the 'Supported Address Types' parameter SHOULD also be considered as supported by the receiver of the INIT chunk. The receiver of the INIT chunk SHOULD NOT respond with any kind of error indication. Here is a fix to comply to RFC. Signed-off-by:Gui Jianfeng <guijianfeng@cn.fujitsu.com> Acked-by:
-
Adrian Bunk authored
Make the needlessly global init_tti() static. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Acked-by:
"Ramkrishna Vepa" <Ramkrishna.Vepa@neterion.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org>
-
Adrian Bunk authored
This patch fixes the following build error introduced by commit a79d8e93 and reported by Olaf Hering: <-- snip --> ... LD .tmp_vmlinux1 arch/powerpc/sysdev/built-in.o: In function `of_add_fixed_phys': fsl_soc.c:(.init.text+0xd34): undefined reference to `fixed_phy_add' make: *** [.tmp_vmlinux1] Error 1 <-- snip --> Signed-off-by:
Adrian Bunk <adrian.bunk@movial.fi> Signed-off-by:
-
Adrian Bunk authored
This patch fixes the following build error: <-- snip --> ... CC [M] drivers/net/atarilance.o {standard input}: Assembler messages: {standard input}:406: Error: symbol `Lberr' is already defined {standard input}:460: Error: symbol `Lberr' is already defined make[3]: *** [drivers/net/atarilance.o] Error 1 <-- snip --> Signed-off-by: -
Auke Kok authored
Another team member unfortunately left: update MAINTAINERS. Condense the 3 lists down to a single list for all our drivers. Point to our new sourceforge index page which is slightly better navigateable than the sf.net project page. Signed-off-by:
Auke Kok <auke-jan.h.kok@intel.com> Signed-off-by:
-
Emil Tantilov authored
Signed-off-by:
Emil Tantilov <emil.s.tantilov@intel.com> Signed-off-by:
-
Auke Kok authored
This fixes a "trying to free already free IRQ" message and simplifies the shutdown/suspend code by re-using already existing code when going to suspend. The code is now symmetric with e100_resume. Signed-off-by:
-
Thomas Klein authored
Fixed Kconfig: ehea driver requires sparse mem Signed-off-by:
Thomas Klein <tklein@de.ibm.com> Signed-off-by:
-
Komuro authored
This message is frequently displayed even if normal file-transfer. Signed-off-by:
Komuro <komurojun-mbn@nifty.com> Signed-off-by:
-
Martin Michlmayr authored
The mv643xx_eth driver can be loaded as a platform device, as is done by various Orion (ARM) based devices. The driver needs to define a module alias for the platform driver so udev will load it automatically. Tested with Debian on a QNAP TS-209. Signed-off-by:
Martin Michlmayr <tbm@cyrius.com> Signed-off-by:
-
Ondrej Zary authored
When the chip dies (probably because of a bug somewhere in the driver), de_stop_rxtx() fails and changing the media type crashes the whole machine. Replace BUG_ON() in de_set_media() with a warning. Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Signed-off-by:
-
frederic Rodo authored
Signed-off-by:
Frederic Rodo <f.rodo@til-technologies.fr> Signed-off-by:
-
Stephen Hemminger authored
From: Stephen Hemminger <shemminger@linux-foundation.org> Based upon a patch by Marcel Wappler: This patch fixes a DHCP issue of the kernel: some DHCP servers (i.e. in the Linksys WRT54Gv5) are very strict about the contents of the DHCPDISCOVER packet they receive from clients. Table 5 in RFC2131 page 36 requests the fields 'ciaddr' and 'siaddr' MUST be set to '0'. These DHCP servers ignore Linux kernel's DHCP discovery packets with these two fields set to '255.255.255.255' (in contrast to popular DHCP clients, such as 'dhclient' or 'udhcpc'). This leads to a not booting system. Signed-off-by: -
David S. Miller authored
-
- 04 Mar, 2008 10 commits
-
-
Michael Buesch authored
This fixes the module init message to tell that the legacy driver loaded. This makes it less confusing, in case both drivers are loaded. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Jussi Kivilinna authored
Replace broken code that attempted to copy 6 byte array to 64-bit integer. Due to missing cast to 64-bit integer, left shift operation were 32-bit and lead to bytes been copied over each other. New code uses simple memcpy, for greater readability and efficiency. Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by:
-
Sebastian Siewior authored
instead of with itself. Signed-off-by:
Sebastian Siewior <bigeasy@linutronix.de> Signed-off-by:
-
David Woodhouse authored
Slightly more useful if we compare it against the sequence number of the command we have outstanding, rather than comparing the reply with itself. Doh. Pointed out by Sebastian Siewior Signed-off-by:
David Woodhouse <dwmw2@infradead.org> Acked-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Johannes Berg authored
When I called p54_parse_eeprom() on a hand-coded structure I managed to make a small mistake with wrap->len which caused a segfault a few lines down when trying to read entry->len. This patch changes the validation code to avoid such problems. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Tested-by:
Florian Fainelli <florian.fainelli@telecomint.eu> Signed-off-by:
-
Johannes Berg authored
Since the EEPROM structure is read from hardware, it is always little endian, annotate that in the struct and make sure to convert where applicable. Signed-off-by:
-
Yoichi Yuasa authored
This patch has added pcibios_enable_device() return value check. Signed-off-by:
Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by:
-
Stefano Brivio authored
Merge rate_control_pid_shift_adjust() to rate_control_pid_adjust_rate() in order to make the learning algorithm aware of constraints on rates. Also add some comments and rename variables. This fixes a bug which prevented 802.11b/g non-AP STAs from working with 802.11b only AP STAs. This patch was originally destined for 2.6.26, and is being backported to fix a user reported problem in post-2.6.24 kernels. Signed-off-by:
Stefano Brivio <stefano.brivio@polimi.it> Signed-off-by:
-
Herbert Xu authored
Now the ESP uses the AEAD interface even for algorithms which are not combined mode, we need to select CONFIG_CRYPTO_AUTHENC as otherwise only combined mode algorithms will work. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
David S. Miller authored
If all of the entropy is in the local and foreign addresses, but xor'ing together would cancel out that entropy, the current hash performs poorly. Suggested by Cosmin Ratiu: Basically, the situation is as follows: There is a client machine and a server machine. Both create 15000 virtual interfaces, open up a socket for each pair of interfaces and do SIP traffic. By profiling I noticed that there is a lot of time spent walking the established hash chains with this particular setup. The addresses were distributed like this: client interfaces were 198.18.0.1/16 with increments of 1 and server interfaces were 198.18.128.1/16 with increments of 1. As I said, there were 15000 interfaces. Source and destination ports were 5060 for each connection. So in this case, ports don't matter for hashing purposes, and the bits from the address pairs used cancel each other, meaning there are no differences in the whole lot of pairs, so they all end up in the same hash chain. Signed-off-by:
-
