- 24 12月, 2005 1 次提交
-
-
由 Pavel Roskin 提交于
orinoco_nortel was broken during conversion to iomem API. Wrong PCI BAR is used for chipset registers. Reported by Tomas Novak <tap@post.cz> Signed-off-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
-
- 23 12月, 2005 5 次提交
-
-
由 Linus Torvalds 提交于
-
由 Linus Torvalds 提交于
-
由 ASANO Masahiro 提交于
NFS client prevents mandatory lock, but there is a flaw on it; Locks are possibly left if the mode is changed while locking. This permits unlocking even if the mandatory lock bits are set. Signed-off-by: NASANO Masahiro <masano@tnes.nec.co.jp> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Nicolas Pitre 提交于
Currently a simple void foo(void) { preempt_enable(); } produces the following code on ARM: foo: bic r3, sp, #8128 bic r3, r3, #63 ldr r2, [r3, #4] ldr r1, [r3, #0] sub r2, r2, #1 tst r1, #4 str r2, [r3, #4] blne preempt_schedule mov pc, lr The problem is that the TIF_NEED_RESCHED flag is loaded _before_ the preemption count is stored back, hence any interrupt coming within that 3 instruction window causing TIF_NEED_RESCHED to be set won't be seen and scheduling won't happen as it should. Nothing currently prevents gcc from performing that reordering. There is already a barrier() before the decrement of the preemption count, but another one is needed between this and the TIF_NEED_RESCHED flag test for proper code ordering. Signed-off-by: NNicolas Pitre <nico@cam.org> Acked-by: NNick Piggin <nickpiggin@yahoo.com.au> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 22 12月, 2005 15 次提交
-
-
由 David S. Miller 提交于
The problem is that when new policies are inserted, sockets do not see the update (but all new route lookups do). This bug is related to the SA insertion stale route issue solved recently, and this policy visibility problem can be fixed in a similar way. The fix is to flush out the bundles of all policies deeper than the policy being inserted. Consider beginning state of "outgoing" direction policy list: policy A --> policy B --> policy C --> policy D First, realize that inserting a policy into a list only potentially changes IPSEC routes for that direction. Therefore we need not bother considering the policies for other directions. We need only consider the existing policies in the list we are doing the inserting. Consider new policy "B'", inserted after B. policy A --> policy B --> policy B' --> policy C --> policy D Two rules: 1) If policy A or policy B matched before the insertion, they appear before B' and thus would still match after inserting B' 2) Policy C and D, now "shadowed" and after policy B', potentially contain stale routes because policy B' might be selected instead of them. Therefore we only need flush routes assosciated with policies appearing after a newly inserted policy, if any. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Paul Mackerras 提交于
It turns out that commit f9bd170a broke the cascade from XICS to i8259 on pSeries machines; specifically we ended up not ever doing the EOI on the XICS for the cascade. The result was that interrupts from the serial ports (and presumably any other devices using ISA interrupts) didn't get through. This fixes it and also simplifies the code, by doing the EOI on the XICS in the xics_get_irq routine after reading and acking the interrupt on the i8259. Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Hans Verkuil 提交于
- CC data was swapped the wrong way around. - Enabling CC disabled XDS and vice versa: these two should be independent from one another. Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl> Signed-off-by: NMauro Carvalho Chehab <mchehab@brturbo.com.br>
-
由 Ricardo Cerqueira 提交于
- When ALSA or OSS are loaded, check if the other is present Fixed hotplug notifiers cleanup on module removal - The saa7134 DMA sound modules now have their own Kconfig entries, and if built statically enforce exclusivity - SND_PCM_OSS isn't necessary for the OSS driver Signed-off-by: NRicardo Cerqueira <v4l@cerqueira.org> Signed-off-by: NMauro Carvalho Chehab <mchehab@brturbo.com.br>
-
由 Ian McDonald 提交于
I hope to actually change this behaviour shortly but this will help anybody grepping code at present. Signed-off-by: NIan McDonald <imcdnzl@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Kristian Slavov 提交于
If you add more than one IPv6 address belonging to the same prefix and delete the address that was last added, routing table entry for that prefix is also deleted. Tested on 2.6.14.4 To reproduce: ip addr add 3ffe::1/64 dev eth0 ip addr add 3ffe::2/64 dev eth0 /* wait DAD */ sleep 1 ip addr del 3ffe::2/64 dev eth0 ip -6 route (route to 3ffe::/64 should be gone) In ipv6_del_addr(), if ifa == ifp, we set ifa->if_next to NULL, and later assign ifap = &ifa->if_next, effectively terminating the for-loop. This prevents us from checking if there are other addresses using the same prefix that are valid, and thus resulting in deletion of the prefix. This applies only if the first entry in idev->addr_list is the address to be deleted. Signed-off-by: NKristian Slavov <kristian.slavov@nomadiclab.com> Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Mika Kukkonen 提交于
In vlan_ioctl_handler() the code misses couple checks for error return values. Signed-off-by: NMika Kukkonen <mikukkon@iki.fi> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Mika Kukkonen 提交于
I found these while compiling with extra gcc warnings; considering the indenting surely they are not intentional? Signed-off-by: NMika Kukkonen <mikukkon@iki.fi> Signed-off-by: NRalf Baechle <ralf@linux-mips.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Linus Torvalds 提交于
-
由 Linus Torvalds 提交于
When compiled-in, make sure the sound system has initialized before these drivers do. Reported by Adrian Bunk <bunk@stusta.de> (The right fix would be to make the sound core use "subsys_initcall()" and thus initialize before all normal drivers, but this is the quick and limited safe fix for 2.6.15). Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Alan Stern 提交于
This patch (as618) changes usbcore to prevent derailing the suspend/resume sequence when a USB driver doesn't include support for it. This is a workaround rather than a true fix; the core needs to be changed so that URB submissions from suspended drivers can be refused and outstanding URBs cancelled. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Paul Walmsley 提交于
When the usb-storage module forces sdev->scsi_level to SCSI_2, it should also force starget->scsi_level to the same value. Otherwise, the SCSI layer may attempt to issue SCSI-3 commands to the device, such as REPORT LUNS, which it cannot handle. This can prevent the device from working with Linux. The AMS Venus DS3 DS2316SU2S SATA-to-SATA+USB enclosure, based on the Oxford Semiconductor OXU921S chip, requires this patch to function correctly on Linux. The enclosure reports a SCSI-3 SPC-2 command set level, but does not correctly handle the REPORT LUNS SCSI command - probably due to a bug in its firmware. It seems likely that other USB storage enclosures with similar bugs will also benefit from this patch. Tony Lindgren <tony@atomide.com> collaborated in the development of this patch. Signed-off-by: NPaul Walmsley <paul@booyaka.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Adrian Bunk 提交于
Jan's crosscompile page [1] shows, that one regression in 2.6.15-rc is that the v850 defconfig does no longer compile. The compile error is: <-- snip --> ... CC arch/v850/kernel/setup.o In file included from /usr/src/ctest/rc/kernel/arch/v850/kernel/setup.c:17: /usr/src/ctest/rc/kernel/include/linux/irq.h:13:43: asm/smp.h: No such file or directory make[2]: *** [arch/v850/kernel/setup.o] Error 1 <-- snip --> The #include <asm/smp.h> in irq.h was intruduced in 2.6.15-rc. Since include/linux/irq.h needs code from asm/smp.h only in the CONFIG_SMP=y case and linux/smp.h #include's asm/smp.h only in the CONFIG_SMP=y case, I'm suggesting this patch to #include <linux/smp.h> in irq.h. I've tested the compilation with both CONFIG_SMP=y and CONFIG_SMP=n on i386. Signed-off-by: NAdrian Bunk <bunk@stusta.de> Acked-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
- 21 12月, 2005 19 次提交
-
-
由 YOSHIFUJI Hideaki 提交于
A tentative address is not considered "assigned to an interface" in the traditional sense (RFC2462 Section 4). Don't try to select such an address for the source address. Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
-
由 YOSHIFUJI Hideaki 提交于
If the link was not available when the interface was created, run DAD for pending tentative addresses when the link becomes ready. Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
-
由 YOSHIFUJI Hideaki 提交于
NETDEV_UP might be sent even if the link attached to the interface was not ready. DAD does not make sense in such case, so we won't do so. After interface Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
-
由 YOSHIFUJI Hideaki 提交于
Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
-
由 YOSHIFUJI Hideaki 提交于
Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
-
由 Linus Torvalds 提交于
-
由 Tom Zanussi 提交于
There's currently a diagnostic printk in relay_switch_subbuf() meant as a warning if you accidentally try to log an event larger than the sub-buffer size. The problem is if this happens while logging from somewhere it's not safe to be doing printks, such as in the scheduler, you can end up with a deadlock. This patch removes the warning from relay_switch_subbuf() and instead prints some diagnostic info when the channel is closed. Thanks to Mathieu Desnoyers for pointing out the problem and suggesting a fix. Signed-off-by: NTom Zanussi <zanussi@us.ibm.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 David S. Miller 提交于
It was a stupid workaround for the "static inline" vs. "extern inline" issues of long ago, and it is what causes schedule() to be inlined like crazy into kernel/sched.c when -Os is specified. MIPS and S390 should probably do the same. Now CC_OPTIMIZE_FOR_SIZE can be safely used on sparc64 once more. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ingo Molnar 提交于
When a spinlock debugging check hits, we print the CPU number as an informational thing - but there is no guarantee that preemption is off at that point - hence we should use raw_smp_processor_id(). Otherwise DEBUG_PREEMPT will print a warning. With this fix the warning goes away and only the spinlock-debugging info is printed. Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andi Kleen 提交于
Now needs to include the type 1 functions ("direct") too. Reported by Pavel Roskin <proski@gnu.org> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andreas Gruenbacher 提交于
We must check for MAY_SATTR before setting acls, which includes checking for read-only exports: the lower-level setxattr operation that eventually sets the acl cannot check export-level restrictions. Bug reported by Martin Walter <mawa@uni-freiburg.de>. Signed-off-by: NAndreas Gruenbacher <agruen@suse.de> Acked-by: NTrond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Jason Wessel 提交于
All the work was done to setup the file and maintain the file handles but the access functions were zeroed out due to the #ifdef. Removing the #ifdef allows full access to all the parameters when CONFIG_MODULES=n. akpm: put it back again, but use CONFIG_SYSFS instead. Signed-off-by: NJason Wessel <jason.wessel@windriver.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NAdrian Bunk <bunk@stusta.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andi Kleen 提交于
The overflow checking condition in lib/swiotlb.c was wrong. It would first run a NULL pointer through virt_to_phys before testing it. Since pci_map_sg overflow is not that uncommon and causes data corruption (including broken file systems) when not properly detected I think it's better to fix it in 2.6.15. This affects x86-64 and IA64. Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Knut Petersen 提交于
Whenever ywrap scrolling is selected together with 180 degree screen rotation, 2.6.15-rc6 and earlier versions are broken. fb_pan_display() expects non-negative yoffsets, but ud_update_start() calls it with yoffsets down to -(yres - font height). This patch transforms yoffset to the correct range 0 ... vyres-1. Some obviously unneeded parentheses are removed, too. Verified with cyblafb, should be applied before 2.6.15-final because it does fix the framebuffer rotation code introduced early in the 2.6.15 release cycle. Signed-off-by: NKnut Petersen <Knut_Petersen@t-online.de> Acked-by: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
-
由 Antonino A. Daplas 提交于
Reported by: janis huang (Bugzilla Bug 5747) Fix on oops in intelfb. Not sure what's happening, looks like dinfo->name pointer is invalidated after initialization. Remove intelfb_get_fix, it's not needed and move the majority of the code to the initialization routine. Signed-off-by: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Antonino A. Daplas 提交于
Fix intelfb trying to free a non-existent resource in its error path. Signed-off-by: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Benjamin Herrenschmidt 提交于
The g5 thermal control for liquid cooled machines has a small bug, when the temperatures gets too high, it boosts all fans to the max, but incorrectly sets the liquids pump to the min instead of the max speed, thus causing the overtemp condition not to clear and the machine to shut down after a while. This fixes it to set the pumps to max speed instead. This problem might explain some of the reports of random shutdowns that some g5 users have been reporting in the past. Many thanks to Marcus Rothe for spending a lot of time trying various patches & sending log logs before I found out that typo. Note that overtemp handling is still not perfect and the machine might still shutdown, that patch should reduce if not eliminate such occcurences in "normal" conditions with high load. I'll implement a better handling with proper slowing down of the CPUs later. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-