- 24 Feb, 2006 28 commits
-
-
Anton Altaparmakov authored
supported by NTFS which is 4096 bytes).
-
Anton Altaparmakov authored
-
Anton Altaparmakov authored
Windows copes with this and even chkdsk does not detect or fix this so we have to cope with it, too. Thanks to Pawel Kot for reporting the problem. - Miscellaneous updates to layout.h. Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
-
Anton Altaparmakov authored
-
Linus Torvalds authored
-
Adrian Bunk authored
drivers/net/tlan.c compiles with CONFIG_PCI=n only with a warning and due to the dead code elimination of gcc. Additionally, this fixes the only compile error I found with CONFIG_PCI=n and the gcc -Werror-implicit-function-declaration flag on i386. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Linus Torvalds authored
-
-
Michal Ostrowski authored
tty_schedule_flip() would schedule a thread that would call flush_to_ldisc(). If tty_buffer_request_room() gets called prior to that thread running -- which is likely in this loop in hvc_poll(), it would set the active flag in the tty buffer and consequently flush_to_ldisc() would ignore it. The result is that input on the hvc console is not processed. This fix calls tty_flip_buffer_push (and flags the tty as "low_latency"). The push to the ldisc thus happens synchronously. Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Segher Boessenkool authored
Maple firmware does not need PCI resource allocation, and in fact, it can cause problems in some strange cases. Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Segher Boessenkool authored
Do disable, not enable, the HT APIC IRQ in the function that is supposed to. Enable the MPIC IRQ before enabling the downstream APIC IRQ, avoids potentially losing an interrupt. Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Olof Johansson authored
Update defconfigs for g5, pseries and generic ppc64. Default choices for everything, with the following exceptions: * Enable WINDFARM_PM112 on g5 and ppc64. * Increase CONFIG_NR_CPUS to 4 in g5_defconfig * CONFIG_TIGON3=y instead of =m in g5_defconfig Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Anton Blanchard authored
HMT support is currently broken and needs to be reworked to play nicely with the SMT scheduler. Remove the bit rotten bits for the time being. I also updated an incorrect comment, we enter __secondary_hold with the physical cpu id in r3. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Anton Blanchard authored
The runlatch SPR can take a lot of time to write. My original runlatch code would set it on every exception entry even though most of the time this was not required. It would also continually set it in the idle loop, which is an issue on an SMT capable processor. Now we cache the runlatch value in a threadinfo bit, and only check for it in decrementer and hardware interrupt exceptions as well as the idle loop. Boot on POWER3, POWER5 and iseries, and compile tested on pmac32. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
R Sharada authored
native_hpte_clear has a spinlock recursion problem with the native_tlbie_lock being called twice, once in native_hpte_clear() and once within tlbie(). Fix the problem by changing the call to tlbie() in native_hpte_clear() to __tlbie(). It still supports only 4k pages for now. Signed-off-by: R Sharada <sharada@in.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Kelly Daly authored
Disable OProfile in Kconfig for iSeries to prevent hangs. OProfile was not originally intended to work with legacy iSeries. Signed-off-by: Kelly Daly <kelly@au.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Kumar Gala authored
On the 83xx platform to ensure the PCI inbound memory is handled properly we have to turn on coherency for all pages in the MMU. Otherwise we see corruption if inbound "prefetching/streaming" is enabled on the PCI controller. Signed-off-by: Randy Vinson <rvinson@mvista.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Alan Curry authored
altivec_unavailable_exception is called without setting r3... it looks like the r3 that actually gets passed in as struct pt_regs *regs is the undisturbed value of r3 at the time the altivec instruction was encountered. The user actually gets to choose the pt_regs printed in the Oops! This fixes the oops by passing the correct pt_regs pointer to altivec_unavailable_exception. Signed-off-by: Alan Curry <pacman@TheWorld.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Haren Myneni authored
The panic CPU is waiting forever due to some large timeout value if some CPU is not responding to an IPI. This patch fixes the problem - the maximum waiting period will be 10 seconds and then the kdump boot will go ahead. Signed-off-by: Haren Myneni <haren@us.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Olaf Hering authored
Fix up xmon compilation after the last change. Remove lots of dead code, all the pmac and chrp support is in arch/powerpc Signed-off-by: Olaf Hering <olh@suse.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Michael Ellerman authored
For kexec we need to know the size of the MMU hash table. Currently we calculate the size once in the htab code, and then twice more in the kexec code, once using htab_hash_mask and once using ppc64_pft_size. On some machines the ppc64_pft_size calculation is broken because ppc64_pft_size is not set. So we need to fix the second calculation, but better still we should just calculate the size once and use it everywhere else. Tested on Power5 LPAR, Power4 non-LPAR and Power3. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Richard Lucassen authored
The most usable number of ifb devices is 2. Change the default to 2. Signed-off-by: Richard Lucassen <spamtrap@lucassen.org> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Herbert Xu authored
We should use the TOS because it's one of the routing keys. It also means that we update the correct routing cache entry when PMTU occurs. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jamal Hadi Salim authored
When you turn off ARP on a netdevice then the first packet always goes out with a dstMAC of all zeroes. This is because the first packet is used to resolve ARP entries. Even though the ARP entry may be resolved (I tried by setting a static ARP entry for a host i was pinging from), it gets overwritten by virtue of having the netdevice disabling ARP. Subsequent packets go out fine with correct dstMAC address (which may be why people have ignored reporting this issue). To cut the story short: the culprit code is in net/ethernet/eth.c::eth_header() ---- /* * Anyway, the loopback-device should never use this function... */ if (dev->flags & (IFF_LOOPBACK|IFF_NOARP)) { memset(eth->h_dest, 0, dev->addr_len); return ETH_HLEN; } if(daddr) { memcpy(eth->h_dest,daddr,dev->addr_len); return ETH_HLEN; } ---- Note how the h_dest is being reset when device has IFF_NOARP. As a note: All devices including loopback pass a daddr. loopback in fact passes a 0 all the time ;-> This means i can delete the check totaly or i can remove the IFF_NOARP Alexey says: -------------------- I think, it was me who did this crap. It was so long ago I do not remember why it was made. I remember some troubles with dummy device. It tried to resolve addresses, apparently, without success and generated errors instead of blackholing. I think the problem was eventually solved at neighbour level. After some thinking I suspect the deletion of this chunk could change behaviour of some parts which do not use neighbour cache f.e. packet socket. I think safer approach would be to move this chunk after if (daddr). And the possibility to remove this completely could be analyzed later. -------------------- Patch updated with Alexey's safer suggestions. Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca> Acked-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Herbert Xu authored
We often just do an atomic_dec(&x->refcnt) on an xfrm_state object because we know there is more than 1 reference remaining and thus we can elide the heavier xfrm_state_put() call. Do this behind an inline function called __xfrm_state_put() so that is more obvious and also to allow us to more cleanly add refcount debugging later. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Suresh Bhogavilli authored
When garbage collecting route cache entries of multipath routes in rt_garbage_collect(), entries were deleted from the hash bucket 'i' while holding a spin lock on bucket 'k' resulting in a system hang. Delete entries, if any, from bucket 'k' instead. Signed-off-by: Suresh Bhogavilli <sbhogavilli@verisign.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Patrick McHardy authored
The bridge-netfilter code attaches a fake dst_entry with dst->ops == NULL to purely bridged packets. When these packets are SNATed and a policy lookup is done, xfrm_lookup crashes because it tries to dereference dst->ops. Change xfrm_lookup not to dereference dst->ops before checking for the DST_NOXFRM flag and set this flag in the fake dst_entry. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 23 Feb, 2006 12 commits
-
-
Stephen Hemminger authored
There is a race between updating the irq mask and setting it which can be triggered on SMP with a bad cable. Similar patch from Ingo Molnar and Thomas Gleixner Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
-
Stephen Hemminger authored
The SysKonnect Genesis based board would fail on initialization with phy_read errors caused by not waiting for last phy write. Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
-
Stephen Hemminger authored
Fix a race in the receive NAPI, irq handling. The interrupt clear and the start need to be separated. Otherwise there is a window between the last frame received and the NAPI done level handling. Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
-
Francois Romieu authored
Similar to 8139cp code but more inspired/lucky. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
-
Francois Romieu authored
rtl8169_hw_start() requires that the descriptor ring indexes be set to zero. Let a deferred invocation of rtl8169_reset_task() handle it. Enabling a few power management bits will not hurt either. suspend/resume is issued with irq on: the spinlock do not need to save the irq flag. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
-
Michael Ellerman authored
When I changed the hvlpevent_queue code to use a spinlock instead of a custom atomic (719d1cd8) I didn't initialise the lock anywhere, oops. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Stefan Richter authored
Since about Linux 2.6.14, sbp2's inquiry workaround did not work anymore due to changes in the SCSI layer. Update it to become effective again. Testing one of the two known affected bridges has shown that skip_ms_page_8 is required as well. Also, make force_inquiry_hack tunable via /sys/module/sbp2/parameters. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jody McIntyre <scjody@modernduck.com> (cherry picked from 99496037c6744fd938ffb8ccfc8fc91762322ff8 commit)
-
Stefan Richter authored
Let the ieee1394 core select a suitable 1394 address range for sbp2's status FIFO instead of using a fixed range. Since the core only selects addresses which are guaranteed to be out of the "physical range" as per OHCI 1.1, this patch also fixes an old bug: OHCI controllers which implement a writeable PhysicalUpperBound register included sbp2's status FIFO in the physical range. That way sbp2 was never notified of a succesful login and always failed after timeout. Affected OHCI host adapters include ALi and Fujitsu controllers. As another side effect of this patch, the status FIFO is no longer located in a range for which OHCI chips perform "posted writes". Each status write now requires a response subaction. But since large data transfers involve only few status writes, there is no measurable decrease of I/O throughput. What's more, the status FIFO is now safe from potential host bus errors. Nevertheless, posted writes could be re-enabled by extensions to the ARM features of the 1394 stack. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jody McIntyre <scjody@modernduck.com> (cherry picked from b2d38cccad4ef80d6b672b8f89aae5fe2907b113 commit)
-
Stefan Richter authored
If there were commands enqueued but not completed before an SBP-2 unit was unplugged (or an attempt to reconnect failed), knodemgrd or any process which tried to remove the device would sleep uninterruptibly in blk_execute_rq(). Therefore make sure that all commands are completed when sbp2 retreats. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jody McIntyre <scjody@modernduck.com> (cherry picked from 61daa34c132c5d4ed8630e2c46e9bf2f0c7b3428 commit)
-
Stephen Hemminger authored
Need to avoid race in updating IRQ mask. This can probably be replaced smarter use of the interrupt control registers (if/when chipset docs are available). Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
-
Stephen Hemminger authored
To avoid problems with PCI config access without ACPI (or busted ACPI tables), use the device's window into PCI config space. I know this probably will upset the purists, but I would rather have users than ACPI testers. It also generates less code. Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
-
Stephen Hemminger authored
Need to force a transmit coalesce timer restart after processing transmit packets. Otherwise, can get transmit status after last update and chip doesn't send the next one. Can go with the chip defaults for coalescing timers, except for Tx timer which needs to be bigger. Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
-