- 10 Oct, 2007 5 commits
-
-
Chuck Ebbert authored
Update the libata drive blacklists to the latest in 2.6.23-rc8. Signed-off-by:
Chuck Ebbert <cebbert@redhat.com> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Stephen Hemminger authored
Already upstream. After resume, driver has reset the chip so the current state of transmit checksum offload state machine and DMA state machine will be undefined. The fix is to set the state so that first Tx will set MSS and offset values. Signed-off-by:
Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by:
-
Stephen Hemminger authored
Already upstream. The length check for truncated frames was not correctly handling the case where VLAN acceleration had already read the tag. Also, the Yukon EX has some features that use high bit of status as security tag. Signed-off-by:
Pierre-Yves Ritschard <pyr@spootnik.org> Signed-off-by:
-
Stephen Hemminger authored
This is the 2.6.22 version of a regression fix that is already in 2.6.23. Change the watchdog timer form 10 per second all the time, to 1 per second and only if interface is up. Signed-off-by:
-
James Bottomley authored
commit 2302827c from upstream Domain Validation in the SPI transport class is failing on boxes with damaged cables (and failing to the extent that the box hangs). The problem is that the first test it does is a cable integrity test for wide transfers and if this fails, it turns the wide bit off. The problem is that the next set of tests it does turns wide back on again, with the result that it runs through the entirety of DV with a known bad setting and then hangs the system. The attached patch fixes the problem by physically nailing the wide setting to what it deduces it should be for the whole of Domain Validation. Signed-off-by:
James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by:
-
- 26 Sep, 2007 35 commits
-
-
Greg Kroah-Hartman authored
-
Larry Finger authored
port of 3f708697 from mainline. A crash upon booting that is caused by bcm43xx has been reported [1] and found to be due to a work queue being reinitialized while work on that queue is still pending. This fix modifies the shutdown of work queues and prevents periodic work from being requeued during shutdown. With this patch, no more crashes on reboot were observed by the original reporter. I do not get that particular failure on my system; however, when running a large number of ifdown/ifup sequences, my system would kernel panic with the 'caps lock' light blinking at roughly a 1 Hz rate. In addition, there were infrequent failures in the firmware that resulted in 'IRQ READY TIMEOUT' errors. With this patch, no more of the first type of failure occur, and incidence of the second type is greatly reduced. [1] http://bugzilla.kernel.org/show_bug.cgi?id=8937Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Acked-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
David Miller authored
commit 2cc7345f in mainline Subject: [PATCH] [SPARC64]: Fix booting on V100 systems. On the root PCI bus, the OBP device tree lists device 3 twice. Once as 'pm' and once as 'lomp'. Everything goes downhill from there. Ignore the second instance to workaround this. Thanks to Kövedi_Krisztián for the bug report and testing the fix. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Adit Ranadive authored
commit ce5d0b47 in mainline Subject: [PATCH] [PKTGEN]: srcmac fix Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Herbert Xu authored
commit ef8aef55 in mainline Subject: [PATCH] [NET]: Do not dereference iov if length is zero When msg_iovlen is zero we shouldn't try to dereference msg_iov. Right now the only thing that tries to do so is skb_copy_and_csum_datagram_iovec. Since the total length should also be zero if msg_iovlen is zero, it's sufficient to check the total length there and simply return if it's zero. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Ilpo Järvinen authored
commit 49ff4bb4 in mainline. [TCP]: DSACK signals data receival, be conservative In case a DSACK is received, it's better to lower cwnd as it's a sign of data receival. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
-
Ilpo Järvinen authored
commit 6ee8009e38006da81d2a53da1aaa27365552553e in mainline Subject: [PATCH 1/1] [TCP]: Also handle snd_una changes in tcp_cwnd_down tcp_cwnd_down must check for it too as it should be conservative in case of collapse stuff and also when receiver is trying to lie (though it wouldn't be successful anyway). Note: - Separated also is_dupack and do_lost in fast_retransalert * Much cleaner look-and-feel now * This time it really fixes cumulative ACK + many new SACK blocks recovery entry (I claimed this fixes with last patch but it wasn't). TCP will now call tcp_update_scoreboard regardless of is_dupack when in recovery as long as there is enough fackets_out. - Introduce FLAG_SND_UNA_ADVANCED * Some prior_snd_una arguments are unnecessary after it - Added helper FLAG_ANY_PROGRESS to avoid long FLAG...|FLAG... constructs This is a reduced version of a mainline patch. Signed-off-by:
-
Stephen Hemminger authored
commit 09d74cdd88a59a18f2ad7cfa0b6045ed1817b632 in mainline. Subject: [PATCH] [KBUILD]: Sanitize tc_ematch headers. The headers in tc_ematch are used by iproute2, so these headers should be processed. Signed-off-by:
-
Evgeniy Polyakov authored
commit 8c7b43a2e58baa24002fa2b266d9a5007bc52a40 in mainline I tried to preserve bridging code as it was before, but logic is quite strange - I think we should free skb on error, since it is already unshared and thus will just leak. Herbert Xu states: > + if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL) > + goto out; If this happens it'll be a double-free on skb since we'll return NF_DROP which makes the caller free it too. We could return NF_STOLEN to prevent that but I'm not sure whether that's correct netfilter semantics. Patrick, could you please make a call on this? Patrick McHardy states: NF_STOLEN should work fine here. Signed-off-by:
Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by:
-
Jiri Kosina authored
commit 6ae5f983 in mainline The commit 95c385 broke proper source address selection for cases in which there is a address which is makred 'deprecated'. The commit mistakenly changed ifa->flags to ifa_result->flags (probably copy/paste error from a few lines above) in the 'Rule 3' address selection code. The patch restores the previous RFC-compliant behavior. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Denis V. Lunev authored
commit 9e3be4b3 in mainline addrconf_dad_failure calls addrconf_dad_stop which takes referenced address and drops the count. So, in6_ifa_put perrformed at out: is extra. This results in message: "Freeing alive inet6 address" and not released dst entries. Signed-off-by:
Denis V. Lunev <den@openvz.org> Signed-off-by:
Alexey Dobriyan <adobriyan@openvz.org> Signed-off-by:
-
YOSHIFUJI Hideaki authored
commit 3ef9d943 in mainline Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
-
Nick Bowler authored
commit 8ee4f391831cb96916a8e8a05f04b1c1d7dd30d8 in mainline. In testing our ESP/AH offload hardware, I discovered an issue with how AH handles mutable fields in IPv4. RFC 4302 (AH) states the following on the subject: For IPv4, the entire option is viewed as a unit; so even though the type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes. The current implementation does not zero the type and length fields, resulting in authentication failures when communicating with hosts that do (i.e. FreeBSD). I have tested record route and timestamp options (ping -R and ping -T) on a small network involving Windows XP, FreeBSD 6.2, and Linux hosts, with one router. In the presence of these options, the FreeBSD and Linux hosts (with the patch or with the hardware) can communicate. The Windows XP host simply fails to accept these packets with or without the patch. I have also been trying to test source routing options (using traceroute -g), but haven't had much luck getting this option to work *without* AH, let alone with. Signed-off-by:Nick Bowler <nbowler@ellipticsemi.com> Signed-off-by:
-
YOSHIFUJI Hideaki authored
commit e1f52208 in mainline. [IPv6]: Fix NULL pointer dereference in ip6_flush_pending_frames Some of skbs in sk->write_queue do not have skb->dst because we do not fill skb->dst when we allocate new skb in append_data(). BTW, I think we may not need to (or we should not) increment some stats when using corking; if 100 sendmsg() (with MSG_MORE) result in 2 packets, how many should we increment? If 100, we should set skb->dst for every queued skbs. If 1 (or 2 (*)), we increment the stats for the first queued skb and we should just skip incrementing OutDiscards for the rest of queued skbs, adn we should also impelement this semantics in other places; e.g., we should increment other stats just once, not 100 times. *: depends on the place we are discarding the datagram. I guess should just increment by 1 (or 2). Signed-off-by:
-
Patrick McHardy authored
commit 0a9c7301 in mainline [INET_DIAG]: Fix oops in netlink_rcv_skb netlink_run_queue() doesn't handle multiple processes processing the queue concurrently. Serialize queue processing in inet_diag to fix a oops in netlink_rcv_skb caused by netlink_run_queue passing a NULL for the skb. BUG: unable to handle kernel NULL pointer dereference at virtual address 00000054 [349587.500454] printing eip: [349587.500457] c03318ae [349587.500459] *pde = 00000000 [349587.500464] Oops: 0000 [#1] [349587.500466] PREEMPT SMP [349587.500474] Modules linked in: w83627hf hwmon_vid i2c_isa [349587.500483] CPU: 0 [349587.500485] EIP: 0060:[<c03318ae>] Not tainted VLI [349587.500487] EFLAGS: 00010246 (2.6.22.3 #1) [349587.500499] EIP is at netlink_rcv_skb+0xa/0x7e [349587.500506] eax: 00000000 ebx: 00000000 ecx: c148d2a0 edx: c0398819 [349587.500510] esi: 00000000 edi: c0398819 ebp: c7a21c8c esp: c7a21c80 [349587.500517] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [349587.500521] Process oidentd (pid: 17943, ti=c7a20000 task=cee231c0 task.ti=c7a20000) [349587.500527] Stack: 00000000 c7a21cac f7c8ba78 c7a21ca4 c0331962 c0398819 f7c8ba00 0000004c [349587.500542] f736f000 c7a21cb4 c03988e3 00000001 f7c8ba00 c7a21cc4 c03312a5 0000004c [349587.500558] f7c8ba00 c7a21cd4 c0330681 f7c8ba00 e4695280 c7a21d00 c03307c6 7fffffff [349587.500578] Call Trace: [349587.500581] [<c010361a>] show_trace_log_lvl+0x1c/0x33 [349587.500591] [<c01036d4>] show_stack_log_lvl+0x8d/0xaa [349587.500595] [<c010390e>] show_registers+0x1cb/0x321 [349587.500604] [<c0103bff>] die+0x112/0x1e1 [349587.500607] [<c01132d2>] do_page_fault+0x229/0x565 [349587.500618] [<c03c8d3a>] error_code+0x72/0x78 [349587.500625] [<c0331962>] netlink_run_queue+0x40/0x76 [349587.500632] [<c03988e3>] inet_diag_rcv+0x1f/0x2c [349587.500639] [<c03312a5>] netlink_data_ready+0x57/0x59 [349587.500643] [<c0330681>] netlink_sendskb+0x24/0x45 [349587.500651] [<c03307c6>] netlink_unicast+0x100/0x116 [349587.500656] [<c0330f83>] netlink_sendmsg+0x1c2/0x280 [349587.500664] [<c02fcce9>] sock_sendmsg+0xba/0xd5 [349587.500671] [<c02fe4d1>] sys_sendmsg+0x17b/0x1e8 [349587.500676] [<c02fe92d>] sys_socketcall+0x230/0x24d [349587.500684] [<c01028d2>] syscall_call+0x7/0xb [349587.500691] ======================= [349587.500693] Code: f0 ff 4e 18 0f 94 c0 84 c0 0f 84 66 ff ff ff 89 f0 e8 86 e2 fc ff e9 5a ff ff ff f0 ff 40 10 eb be 55 89 e5 57 89 d7 56 89 c6 53 <8b> 50 54 83 fa 10 72 55 8b 9e 9c 00 00 00 31 c9 8b 03 83 f8 0f Reported by Athanasius <link@miggy.org> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Stephen Hemminger authored
commit 596e4150 in mainline Bug: http://bugzilla.kernel.org/show_bug.cgi?id=8876 Not all ips are shown by "ip addr show" command when IPs number assigned to an interface is more than 60-80 (in fact it depends on broadcast/label etc presence on each address). Steps to reproduce: It's terribly simple to reproduce: # for i in $(seq 1 100); do ip ad add 10.0.$i.1/24 dev eth10 ; done # ip addr show this will _not_ show all IPs. Looks like the problem is in netlink/ipv4 message processing. This is fix from bug submitter, it looks correct. Signed-off-by:
-
Patrick McHardy authored
commit a2221f30 in mainline. Not all are listed, same as the IPV4 devinet bug. Signed-off-by:
-
Willy Tarreau authored
commit ba685fb2 in mainline. As noticed by Chuck Ebbert, commit c5e3ae88 introduced a copy-paste typo, as realtek phy is 0x732 and not 0x1c1. Obvious fix below suggested by Ayaz Abdulla. Signed-off-by:
Willy Tarreau <w@1wt.eu> Cc: Ayaz Abdulla <aabdulla@nvidia.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Herbert Xu authored
This corresponds to upstream changesets e4630f9f and 32528d0f. [CRYPTO] blkcipher: Fix handling of kmalloc page straddling The function blkcipher_get_spot tries to return a buffer of the specified length that does not straddle a page. It has an off-by-one bug so it may advance a page unnecessarily. What's worse, one of its callers doesn't provide a buffer that's sufficiently long for this operation. This patch fixes both problems. Thanks to Bob Gilligan for diagnosing this problem and providing a fix. Signed-off-by:
-
Jens Axboe authored
The commit in Linus upstream git tree is f3da54ba. Fix race with shared tag queue maps There's a race condition in blk_queue_end_tag() for shared tag maps, users include stex (promise supertrak thingy) and qla2xxx. The former at least has reported bugs in this area, not sure why we haven't seen any for the latter. It could be because the window is narrow and that other conditions in the qla2xxx code hide this. It's a real bug, though, as the stex smp users can attest. We need to ensure two things - the tag bit clearing needs to happen AFTER we cleared the tag pointer, as the tag bit clearing/setting is what protects this map. Secondly, we need to ensure that the visibility of the tag pointer and tag bit clear are ordered properly. [ I removed the SMP barriers - "test_and_clear_bit()" already implies all the required barriers. -- Linus ] Also see http://bugzilla.kernel.org/show_bug.cgi?id=7842Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Neil Brown authored
commit 7a1fa065 in mainline. Commit aaf68cfb added a bias to sk_inuse, so this test for an unused socket now fails. So no sockets get closed because they are old (they might get closed if the client closed them). This bug has existed since 2.6.21-rc1. Thanks to Wolfgang Walter for finding and reporting the bug. Cc: Wolfgang Walter <wolfgang.walter@studentenwerk.mhn.de> Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by:
-
Stefan Richter authored
Initialization of ohci1394 was broken according to one reporter if the driver was statically linked, i.e. not built as loadable module. Dmesg: PCI: Device 0000:02:07.0 not available because of resource collisions ohci1394: Failed to enable OHCI hardware. This was reported for a Toshiba Satellite 5100-503. The cause is commit 8df4083c in Linux 2.6.19-rc1 which only served purposes of early remote debugging via FireWire. This functionality is better provided by the currently out-of-tree driver ohci1394_earlyinit. Reversal of the commit was OK'd by Andi Kleen. Same as pre-2.6.23 commit be7963b7. Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Eric Sandeen authored
commit 3d82abae in mainline. Convert asserts (BUGs) in dx_probe from bad on-disk data to recoverable errors with helpful warnings. With help catching other asserts from Duane Griffin <duaneg@dghda.com> Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Acked-by:
Duane Griffin <duaneg@dghda.com> Acked-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Alexey Dobriyan authored
commit 49af7ee1 in mainline. NFS unregisters sysctls only if V4 support is compiled in. However, sysctl table is not V4 specific, so unregister it always. Steps to reproduce: [build nfs.ko with CONFIG_NFS_V4=n] modrobe nfs rmmod nfs ls /proc/sys Unable to handle kernel paging request at ffffffff880661c0 RIP: [<ffffffff802af8e3>] proc_sys_readdir+0xd3/0x350 PGD 203067 PUD 207063 PMD 7e216067 PTE 0 Oops: 0000 [1] SMP CPU 1 Modules linked in: lockd nfs_acl sunrpc Pid: 3335, comm: ls Not tainted 2.6.23-rc3-bloat #2 RIP: 0010:[<ffffffff802af8e3>] [<ffffffff802af8e3>] proc_sys_readdir+0xd3/0x350 RSP: 0018:ffff81007fd93e78 EFLAGS: 00010286 RAX: ffffffff880661c0 RBX: ffffffff80466370 RCX: ffffffff880661c0 RDX: 00000000000014c0 RSI: ffff81007f3ad020 RDI: ffff81007efd8b40 RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffffffff802a8570 R12: ffffffff880661c0 R13: ffff81007e219640 R14: ffff81007efd8b40 R15: ffff81007ded7280 FS: 00002ba25ef03060(0000) GS:ffff81007ff81258(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffffffff880661c0 CR3: 000000007dfaf000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ls (pid: 3335, threadinfo ffff81007fd92000, task ffff81007d8a0000) Stack: ffff81007f3ad150 ffffffff80283f30 ffff81007fd93f48 ffff81007efd8b40 ffff81007ee00440 0000000422222222 0000000200035593 ffffffff88037e9a 2222222222222222 ffffffff80466500 ffff81007e416400 ffff81007e219640 Call Trace: [<ffffffff80283f30>] filldir+0x0/0xf0 [<ffffffff80283f30>] filldir+0x0/0xf0 [<ffffffff802840c7>] vfs_readdir+0xa7/0xc0 [<ffffffff80284376>] sys_getdents+0x96/0xe0 [<ffffffff8020bb3e>] system_call+0x7e/0x83 Code: 41 8b 14 24 85 d2 74 dc 49 8b 44 24 08 48 85 c0 74 e7 49 3b RIP [<ffffffff802af8e3>] proc_sys_readdir+0xd3/0x350 RSP <ffff81007fd93e78> CR2: ffffffff880661c0 Kernel panic - not syncing: Fatal exception Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Acked-by:
Trond Myklebust <trond.myklebust@fys.uio.no> Cc: "J. Bruce Fields" <bfields@fieldses.org> Signed-off-by:
-
Eric Sandeen authored
commit ef2b02d3 in mainline. The do_split() function for htree dir blocks is intended to split a leaf block to make room for a new entry. It sorts the entries in the original block by hash value, then moves the last half of the entries to the new block - without accounting for how much space this actually moves. (IOW, it moves half of the entry *count* not half of the entry *space*). If by chance we have both large & small entries, and we move only the smallest entries, and we have a large new entry to insert, we may not have created enough space for it. The patch below stores each record size when calculating the dx_map, and then walks the hash-sorted dx_map, calculating how many entries must be moved to more evenly split the existing entries between the old block and the new block, guaranteeing enough space for the new entry. The dx_map "offs" member is reduced to u16 so that the overall map size does not change - it is temporarily stored at the end of the new block, and if it grows too large it may be overwritten. By making offs and size both u16, we won't grow the map size. Also add a few comments to the functions involved. This fixes the testcase reported by hooanon05@yahoo.co.jp on the linux-ext4 list, "ext3 dir_index causes an error" Thanks to Andreas Dilger for discussing the problem & solution with me. Signed-off-by:
Andreas Dilger <adilger@clusterfs.com> Tested-by:
Junjiro Okajima <hooanon05@yahoo.co.jp> Cc: Theodore Ts'o <tytso@mit.edu> Cc: ext4 <linux-ext4@vger.kernel.org> Signed-off-by:
-
Pavel Emelyanov authored
commit 0e2f6db8 in mainline. The inode->i_flock list contains the leases, flocks and posix locks in the specified order. However, the flocks are added in the head of this list thus hiding the leases from F_GETLEASE command, from time_out_leases() and other code that expects the leases to come first. The following example will demonstrate this: #define _GNU_SOURCE #include <unistd.h> #include <fcntl.h> #include <stdio.h> #include <sys/file.h> static void show_lease(int fd) { int res; res = fcntl(fd, F_GETLEASE); switch (res) { case F_RDLCK: printf("Read lease\n"); break; case F_WRLCK: printf("Write lease\n"); break; case F_UNLCK: printf("No leases\n"); break; default: printf("Some shit\n"); break; } } int main(int argc, char **argv) { int fd, res; fd = open(argv[1], O_RDONLY); if (fd == -1) { perror("Can't open file"); return 1; } res = fcntl(fd, F_SETLEASE, F_WRLCK); if (res == -1) { perror("Can't set lease"); return 1; } show_lease(fd); if (flock(fd, LOCK_SH) == -1) { perror("Can't flock shared"); return 1; } show_lease(fd); return 0; } The first call to show_lease() will show the write lease set, but the second will show no leases. Fix the flock adding so that the leases always stay in the head of this list. Found during making the flocks pid-namespaces aware. Signed-off-by:
Pavel Emelyanov <xemul@openvz.org> Acked-by:
"J. Bruce Fields" <bfields@fieldses.org> Cc: Trond Myklebust <trond.myklebust@fys.uio.no> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Arnd Bergmann authored
commit 179c85ea in mainline. The futex list traversal on the compat side appears to have a bug. It's loop termination condition compares: while (compat_ptr(uentry) != &head->list) But that can't be right because "uentry" has the special "pi" indicator bit still potentially set at bit 0. This is cleared by fetch_robust_entry() into the "entry" return value. What this seems to mean is that the list won't terminate when list iteration gets back to the the head. And we'll also process the list head like a normal entry, which could cause all kinds of problems. So we should check for equality with "entry". That pointer is of the non-compat type so we have to do a little casting to keep the compiler and sparse happy. The same problem can in theory occur with the 'pending' variable, although that has not been reported from users so far. Based on the original patch from David Miller. Acked-by:
Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: David Miller <davem@davemloft.net> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Stefan Richter authored
Minor regression since 2.6.22-rc1: If the experimental firewire-ohci driver instead of ohci1394 was loaded, iBook G3 and older PowerBooks refused to suspend. Same as commit 55111428 plus format string touch-ups from 8a8cea27, "firewire: missing newline in printk". Original patch description: Fixes (papers over) "Sleep problems with kernels >= 2.6.21 on powerpc", http://lkml.org/lkml/2007/8/25/155. The issue is that the FireWire controller's pci_dev.current_state of iBook G3 and presumably older PowerBooks is still in PCI_UNKNOWN instead of PCI_D0 when the firewire driver's .suspend method is called. Like it was suggested earlier in http://lkml.org/lkml/2006/10/24/13, we do not fail .suspend anymore if pci_set_power_state failed. Signed-off-by:
-
Andrew Morton authored
commit 3558c9b3 in mainline. sparc32: drivers/block/DAC960.c: In function 'DAC960_V1_EnableMemoryMailboxInterface': drivers/block/DAC960.c:1168: error: 'DMA_32BIT_MASK' undeclared (first use in this function) drivers/block/DAC960.c:1168: error: (Each undeclared identifier is reported only Cc: <dac@conglom-o.org> Cc: Alessandro Polverini <alex@nibbles.it> Cc: Jeff Garzik <jeff@garzik.org> Cc: Matthew Wilcox <matthew@wil.cx> Signed-off-by:
-
Matthew Wilcox authored
commit 868047fc in mainline. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=8942 Use PCI_DMA_* constants instead of own private definitions Fall back to 32-bit DMA mask if a 64-bit one fails Signed-off-by:
Matthew Wilcox <matthew@wil.cx> Acked-by:
Lars <polynomial-c@gmx.de> Cc: Alessandro Polverini <alex@nibbles.it> Cc: <dac@conglom-o.org> Signed-off-by:
-
Andreas Gruenbacher authored
commit 1a1a1a75 in mainline. dput must be called before mntput here. Signed-off-by:
Andreas Gruenbacher <agruen@suse.de> Acked-By:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Andrew Morton authored
commit e4260197 in mainline. There is still some confusion and disagreement over what this interface should actually do. So it is best that we disable it in 2.6.23 until we get that fully sorted out. (sys_timerfd() was present in 2.6.22 but it was apparently broken, so here we assume that nobody is using it yet). Cc: Michael Kerrisk <mtk-manpages@gmx.net> Cc: Davide Libenzi <davidel@xmailserver.org> Acked-by:
-
Wolfgang Walter authored
commit 9db619e6 in mainline. we upgraded the kernel of a nfs-server from 2.6.17.11 to 2.6.22.6. Since then we get the message lockd: too many open TCP sockets, consider increasing the number of nfsd threads lockd: last TCP connect from ^\\236^\É^D These random characters in the second line are caused by a bug in svc_tcp_accept. (Note: there are two previous __svc_print_addr(sin, buf, sizeof(buf)) calls in this function, either of which would initialize buf correctly; but both are inside "if"'s and are not necessarily executed. This is less obvious in the second case, which is inside a dprintk(), which is a macro which expands to an if statement.) Signed-off-by:
Wolfgang Walter <wolfgang.walter@studentenwerk.mhn.de> Signed-off-by:
-
Jens Axboe authored
This is a splice patch for 2.6.22 and 2.6.21 (and earlier, I did not check. Let me know if you still maintain older stable trees!). It fixes an infinite loop in do_splice_direct(), when there's either nothing to read or nothing to write and blocking doesn't help. It could be things like running out of disk space. We need to exit both for failure and zero return, or we could be going around forever. This got fixed in 2.6.23-git with commit 51a92c0f Herbert Poetzl <herbert@13thfloor.at> noticed this bug in 2.6.22, and has verified that this minimal fix works. Signed-off-by:
-
Jean Delvare authored
Commit 85237f20 introduced the following warning: drivers/media/video/pwc/pwc-if.c: In function "pwc_video_close": drivers/media/video/pwc/pwc-if.c:1211: warning: "i" may be used uninitialized in this function This is true, and can cause a broken debug message to be logged. Here's a fix. Fix is already in Linus' tree for 2.6.23: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7b9fbc3e30f785412a26819aa4daf0b6c27f6c53Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
