Michael Chan [Fri, 19 Aug 2005 19:54:29 +0000 (12:54 -0700)]
[TG3]: Fix SerDes detection
A problem was reported by Grant Grundler on an HP rx8620 using IOX
Core LAN partno(A7109-6) 5701 copper NIC. The tg3 driver mistakenly
detects this NIC as having a SerDes PHY and link does not come up as a
result.
The problem was caused by an incorrectly programmed eeprom that set the
NIC_SRAM_DATA_CFG_PHY_TYPE_FIBER bit in the NIC_SRAM_DATA_CFG location.
This patch will override the NIC_SRAM_DATA_CFG_PHY_TYPE_FIBER bit if a
valid PHY ID is read from the MII registers on older 570x chips where
the MII interface is not used on SerDes chips. On newer chips such as
the 5780 that use MII for both copper and SerDes, SerDes detection must
rely on the eeprom.
This patch will make the SerDes detection identical to versions 3.25 and
older.
Signed-off-by: Michael Chan <mchan@broadcom.com> Acked-by: Grant Grundler <iod00d@hp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Herbert Xu [Thu, 18 Aug 2005 21:36:59 +0000 (14:36 -0700)]
[IPCOMP]: Fix false smp_processor_id warning
This patch fixes a false-positive from debug_smp_processor_id().
The processor ID is only used to look up crypto_tfm objects.
Any processor ID is acceptable here as long as it is one that is
iterated on by for_each_cpu().
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Jay Vosburgh [Thu, 18 Aug 2005 21:04:51 +0000 (14:04 -0700)]
[TOKENRING]: Use interrupt-safe locking with rif_lock.
Change operations on rif_lock from spin_{un}lock_bh to
spin_{un}lock_irq{save,restore} equivalents. Some of the
rif_lock critical sections are called from interrupt context via
tr_type_trans->tr_add_rif_info. The TR NIC drivers call tr_type_trans
from their packet receive handlers.
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ben Dooks [Sat, 23 Jul 2005 16:29:38 +0000 (17:29 +0100)]
[PATCH] DM9000 - incorrect ioctl() handling
The DM9000 driver is responding to ioctl() calls it should not be. This
can cause problems with the wireless tools incorrectly indentifying the
device as wireless capable, and crashing under certain operations.
This patch also moves the version printk() to the init call, so that
you only get it once for multiple devices, and to show it is loaded
if there are no defined dm9000s
Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Ralf Baechle [Tue, 2 Aug 2005 10:01:27 +0000 (11:01 +0100)]
[PATCH] IOC3 fixes
- Using the right register clearly improves chances of getting the MII
code and thus the driver working at all.
- On startup check the media type before setting up duplex or we might
spend the first 1.2s with a wrong duplex setting.
- Get rid of whitespace lines. Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Narendra Sankar [Thu, 18 Aug 2005 20:30:35 +0000 (22:30 +0200)]
[PATCH] serverworks: add support for new southbridge IDE
BCM5785 (HT1000) is a Opteron Southbridge from Serverworks/Broadcom that
incorporates a single channel ATA100 IDE controller that is functionally
identical to the Serverworks CSB6 IDE controller. This patch adds support
for the new PCI device ID and also the support for this controller.
Matt Gillette [Thu, 18 Aug 2005 20:27:07 +0000 (22:27 +0200)]
[PATCH] ide: add support for Netcell Revolution to pci-ide generic driver
Adds support for Netcell Revolution to pci-ide generic driver by including
it in the list of devices matched. Includes the Revolution in the list of
simplex devices forced into DMA mode.
Signed-off-by: Matt Gillette <matt.gillette@netcell.com> Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Cc: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Juha-Matti Tapio [Thu, 18 Aug 2005 20:13:44 +0000 (22:13 +0200)]
[PATCH] ide: fix the BLK_DEV_IDEDMA_PCI dependency for drivers/ide/ppc/pmac.c
drivers/ide/ppc/pmac.c uses symbols ide_build_sglist,
__ide_dma_off_quietly, __ide_dma_on and __ide_dma_timeout when
CONFIG_BLK_DEV_IDEDMA_PMAC is defined. The declarations for these
symbols (in ide.h) depend on CONFIG_BLK_DEV_IDEDMA_PCI. There is a
missing dependency for this in drivers/ide/Kconfig which causes
drivers/ide/ppc/pmac.c to fail to build if CONFIG_BLK_DEV_IDEDMA_PMAC
is selected but CONFIG_BLK_DEV_IDEDMA_PCI is not.
Signed-off-by: Juha-Matti Tapio <jmtapio@verkkotelakka.net> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Jan Kara [Thu, 18 Aug 2005 18:24:17 +0000 (11:24 -0700)]
[PATCH] reiserfs+acl+quota deadlock fix
When i_acl_default is set to some error we do not hold the lock (hence we
are not allowed to drop it and reacquire later).
Signed-off-by: Jan Kara <jack@suse.cz> Cc: Jeff Mahoney <jeffm@suse.com> Cc: Chris Mason <mason@suse.com> Cc: <reiserfs-dev@namesys.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NeilBrown [Thu, 18 Aug 2005 18:24:16 +0000 (11:24 -0700)]
[PATCH] md: make sure mddev->bitmap_offset gets cleared between array instantiations.
... otherwise we might try to load a bitmap from an array which hasn't one.
The bug is that if you create an array with an internal bitmap, shut it down,
and then create an array with the same md device, the md drive will assume it
should have a bitmap too. As the array can be created with a different md
device, it is mostly an inconvenience. I'm pretty sure there is no risk of
data corruption.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Robert Love [Thu, 18 Aug 2005 18:24:14 +0000 (11:24 -0700)]
[PATCH] SH64: inotify and ioprio syscalls
Add inotify and ioprio syscall stubs to SH64.
Signed-off-by: Robert Love <rml@novell.com> Acked-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Robert Love [Thu, 18 Aug 2005 18:24:13 +0000 (11:24 -0700)]
[PATCH] SH: inotify and ioprio syscalls
Add inotify and ioprio syscall stubs to SH.
Signed-off-by: Robert Love <rml@novell.com> Acked-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Chuck Lever [Thu, 18 Aug 2005 18:24:12 +0000 (11:24 -0700)]
[PATCH] NFS: Introduce the use of inode->i_lock to protect fields in nfsi
Down the road we want to eliminate the use of the global kernel lock entirely
from the NFS client. To do this, we need to protect the fields in the
nfs_inode structure adequately. Start by serializing updates to the
"cache_validity" field.
Note this change addresses an SMP hang found by njw@osdl.org, where processes
deadlock because nfs_end_data_update and nfs_revalidate_mapping update the
"cache_validity" field without proper serialization.
Test plan:
Millions of fsx ops on SMP clients. Run Nick Wilson's breaknfs program on
large SMP clients.
Signed-off-by: Chuck Lever <cel@netapp.com> Cc: Trond Myklebust <trond.myklebust@fys.uio.no> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Chuck Lever [Thu, 18 Aug 2005 18:24:11 +0000 (11:24 -0700)]
[PATCH] NFS: use atomic bitops to manipulate flags in nfsi->flags
Introduce atomic bitops to manipulate the bits in the nfs_inode structure's
"flags" field.
Using bitops means we can use a generic wait_on_bit call instead of an ad hoc
locking scheme in fs/nfs/inode.c, so we can remove the "nfs_i_wait" field from
nfs_inode at the same time.
The other new flags field will continue to use bitmask and logic AND and OR.
This permits several flags to be set at the same time efficiently. The
following patch adds a spin lock to protect these flags, and this spin lock
will later cover other fields in the nfs_inode structure, amortizing the cost
of using this type of serialization.
Test plan:
Millions of fsx ops on SMP clients.
Signed-off-by: Chuck Lever <cel@netapp.com> Cc: Trond Myklebust <trond.myklebust@fys.uio.no> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Greg KH [Thu, 18 Aug 2005 00:33:11 +0000 (17:33 -0700)]
[PATCH] Fix manual binding infinite loop
Fix for manual binding of drivers to devices. Problem is if you pass in
a valid device id, but the driver refuses to bind. Infinite loop as
write() tries to resubmit the data it just sent.
Thanks to Michal Ostrowski <mostrows@watson.ibm.com> for pointing the
problem out.
Brian King [Wed, 17 Aug 2005 21:32:18 +0000 (07:32 +1000)]
[PATCH] ppc64: iommu vmerge fix
This fixes a bug in the PPC64 iommu vmerge code which results in the
potential for iommu_unmap_sg to go off unmapping more than it should.
This was found on a test system which resulted in PCI bus errors due to
PCI memory being unmapped while DMAs were still in progress.
Signed-off-by: Brian King <brking@us.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Linus Torvalds [Wed, 17 Aug 2005 20:07:28 +0000 (13:07 -0700)]
Revert unnecessary zlib_inflate/inftrees.c fix
It turns out that empty distance code tables are not an error, and that
a compressed block with only literals can validly have an empty table
and should not be flagged as a data error.
Some old versions of gzip had problems with this case, but it does not
affect the zlib code in the kernel.
Analysis and explanations thanks to Sergey Vlasov <vsu@altlinux.ru>
Steven Rostedt [Wed, 17 Aug 2005 18:25:23 +0000 (14:25 -0400)]
[PATCH] nfsd to unlock kernel before exiting
The nfsd holds the big kernel lock upon exit, when it really shouldn't.
Not to mention that this breaks Ingo's RT patch. This is a trivial fix
to release the lock.
Ingo, this patch also works with your kernel, and stops the problem with
nfsd.
Note, there's a "goto out;" where "out:" is right above svc_exit_thread.
The point of the goto also holds the kernel_lock, so I don't see any
problem here in releasing it.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Bhavesh P. Davda [Wed, 17 Aug 2005 18:26:33 +0000 (12:26 -0600)]
[PATCH] NPTL signal delivery deadlock fix
This bug is quite subtle and only happens in a very interesting
situation where a real-time threaded process is in the middle of a
coredump when someone whacks it with a SIGKILL. However, this deadlock
leaves the system pretty hosed and you have to reboot to recover.
Not good for real-time priority-preemption applications like our
telephony application, with 90+ real-time (SCHED_FIFO and SCHED_RR)
processes, many of them multi-threaded, interacting with each other for
high volume call processing.
Acked-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Herbert Xu [Wed, 17 Aug 2005 19:03:59 +0000 (12:03 -0700)]
[TCP]: Fix bug #5070: kernel BUG at net/ipv4/tcp_output.c:864
1) We send out a normal sized packet with TSO on to start off.
2) ICMP is received indicating a smaller MTU.
3) We send the current sk_send_head which needs to be fragmented
since it was created before the ICMP event. The first fragment
is then sent out.
At this point the remaining fragment is allocated by tcp_fragment.
However, its size is padded to fit the L1 cache-line size therefore
creating tail-room up to 124 bytes long.
This fragment will also be sitting at sk_send_head.
4) tcp_sendmsg is called again and it stores data in the tail-room of
of the fragment.
5) tcp_push_one is called by tcp_sendmsg which then calls tso_fragment
since the packet as a whole exceeds the MTU.
At this point we have a packet that has data in the head area being
fed to tso_fragment which bombs out.
My take on this is that we shouldn't ever call tcp_fragment on a TSO
socket for a packet that is yet to be transmitted since this creates
a packet on sk_send_head that cannot be extended.
So here is a patch to change it so that tso_fragment is always used
in this case.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Patrick McHardy [Wed, 17 Aug 2005 19:03:32 +0000 (12:03 -0700)]
[IPV6]: Fix raw socket hardware checksum failures
When packets hit raw sockets the csum update isn't done yet, do it manually.
Packets can also reach rawv6_rcv on the output path through
ip6_call_ra_chain, in this case skb->ip_summed is CHECKSUM_NONE and this
codepath isn't executed.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Dimitry Andric [Wed, 17 Aug 2005 12:01:19 +0000 (13:01 +0100)]
[ARM] 2850/1: Remove duplicate UART I/O mapping from s3c2410_iodesc
Patch from Dimitry Andric
This patch removes the initial UART I/O mapping from s3c2410_iodesc,
since the same mapping is already done in the function s3c24xx_init_io
in the file arch/arm/mach-s3c2410/cpu.c, through the s3c_iodesc array.
I'm not sure if duplicate mappings do any harm, but it's simply
redundant. Also, in s3c2440.c the UART I/O mapping is NOT done.
Additionally, I put a comma behind the last mapping, to ease
copy/pasting stuff around, and make the style consistent with
s3c2440.c and other files.
Signed-off-by: Dimitry Andric <dimitry@andric.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Sean Lee [Wed, 17 Aug 2005 08:28:26 +0000 (09:28 +0100)]
[ARM] 2852/1: Correct the mistake in arch/arm/mm/Kconfig file
Patch from Sean Lee
In the arch/arm/mm/Kconfig file, the CPU_DCACHE_WRITETHROUGH
option is depend on the CPU_DISABLE_DCACHE, but the "Disable
D-Cache" option is configured as CPU_DCACHE_DISABLE.
The CPU_DISABLE_DCACHE should be CPU_DCACHE_DISABLE
Signed-off-by: Sean Lee <beginner2arm@eyou.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Stephen Rothwell [Wed, 17 Aug 2005 03:01:50 +0000 (13:01 +1000)]
[PATCH] iSeries build with newer assemblers and compilers
Paulus suggested that we put xLparMap in its own .c file so that we can
generate a .s file to be included into head.S. This doesn't get around
the problem of having it at a fixed address, but it makes it more
palatable.
It would be good if this could be included in 2.6.13 as it solves our
build problems with various versions of binutils and gcc. In
particular, it allows us to build an iSeries kernel on Debian unstable
using their biarch compiler.
This has been built and booted on iSeries and built for pSeries and g5.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Maneesh Soni [Tue, 16 Aug 2005 22:15:48 +0000 (15:15 -0700)]
[PATCH] Driver core: potentially fix use after free in class_device_attr_show
This moves the code to free devt_attr from class_device_del() to
class_dev_release() which is called after the last reference to the
corresponding kobject() is gone.
This allows us to keep the devt_attr alive while the corresponding
sysfs file is open.
Herbert Xu [Wed, 17 Aug 2005 03:43:40 +0000 (20:43 -0700)]
[TCP]: Fix bug #5070: kernel BUG at net/ipv4/tcp_output.c:864
1) We send out a normal sized packet with TSO on to start off.
2) ICMP is received indicating a smaller MTU.
3) We send the current sk_send_head which needs to be fragmented
since it was created before the ICMP event. The first fragment
is then sent out.
At this point the remaining fragment is allocated by tcp_fragment.
However, its size is padded to fit the L1 cache-line size therefore
creating tail-room up to 124 bytes long.
This fragment will also be sitting at sk_send_head.
4) tcp_sendmsg is called again and it stores data in the tail-room of
of the fragment.
5) tcp_push_one is called by tcp_sendmsg which then calls tso_fragment
since the packet as a whole exceeds the MTU.
At this point we have a packet that has data in the head area being
fed to tso_fragment which bombs out.
My take on this is that we shouldn't ever call tcp_fragment on a TSO
socket for a packet that is yet to be transmitted since this creates
a packet on sk_send_head that cannot be extended.
So here is a patch to change it so that tso_fragment is always used
in this case.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Patrick McHardy [Wed, 17 Aug 2005 03:39:38 +0000 (20:39 -0700)]
[IPV6]: Fix raw socket hardware checksum failures
When packets hit raw sockets the csum update isn't done yet, do it manually.
Packets can also reach rawv6_rcv on the output path through
ip6_call_ra_chain, in this case skb->ip_summed is CHECKSUM_NONE and this
codepath isn't executed.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Peter Chubb [Wed, 17 Aug 2005 00:27:00 +0000 (17:27 -0700)]
[IA64] Updated zx1 defconfig
Just `make oldconfig' doesn't help for the zx1 defconfig ---
because we need the MPT Fusion drivers, which are picked up as not
selected.
Tested on HP ZX2000 and ZX2600.
Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
Zachary Amsden [Tue, 16 Aug 2005 19:05:09 +0000 (12:05 -0700)]
[PATCH] i386 / desc_empty macro is incorrect
Chuck Ebbert noticed that the desc_empty macro is incorrect. Fix it.
Thankfully, this is not used as a security check, but it can falsely
overwrite TLS segments with carefully chosen base / limits. I do not
believe this is an issue in practice, but it is a kernel bug.
Signed-off-by: Zachary Amsden <zach@vmware.com> Signed-off-by: Chris Wright <chrisw@osdl.org>
[ x86-64 had the same problem, and the same fix. Linus ]
NTFS: Complete the previous fix for the unset device when mapping buffers
for mft record writing. I had missed the writepage based mft record
write code path.
Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
Trond Myklebust [Tue, 16 Aug 2005 15:49:44 +0000 (11:49 -0400)]
[PATCH] NFS: Ensure we always update inode->i_mode when doing O_EXCL creates
When the client performs an exclusive create and opens the file for writing,
a Netapp filer will first create the file using the mode 01777. It does this
since an NFSv3/v4 exclusive create cannot immediately set the mode bits.
The 01777 mode then gets put into the inode->i_mode. After the file creation
is successful, we then do a setattr to change the mode to the correct value
(as per the NFS spec).
The problem is that nfs_refresh_inode() no longer updates inode->i_mode, so
the latter retains the 01777 mode. A bit later, the VFS notices this, and calls
remove_suid(). This of course now resets the file mode to inode->i_mode & 0777.
Hey presto, the file mode on the server is now magically changed to 0777. Duh...
NTFS: Fix bug in mft record writing where we forgot to set the device in
the buffers when mapping them after the VM had discarded them.
Thanks to Martin MOKREJŠ for the bug report.
Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
The exception handling code fails to compile if the extended
precision mode is enabled. This patch fixes those compile errors and
also stops _quiet functions from incorrectly raising exceptions. Reported-by: Ralph Siemsen <ralphs@netwinder.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[PATCH] intelfb/fbdev: Save info->flags in a local variable
Reported by: Pavel Kysilka (Bugzilla Bug 5059)
The intelfb driver does not keep resolution set with fbset after
switching to anot console and back.
Steps to reproduce:
initial options: tty1,tty2 - 1024x768-60
1) tty1 - fbset after booting (1024x768-60)
2) tty1 - fbset 800x600-100
tty1: 800x600-100
3) swith to tty2, swith to tty1
tty1: 1024x768-60 (the same resolution as default from kernel booting)
This bug is caused by intelfb unintentionally destroying info->flags in
set_par(). Therefore the flag, FBINFO_MISC_USEREVENT used to notify
fbcon of a mode change was cleared causing the above problem. This bug
though is not intelfb specific, as other drivers may also be affected.
The fix is to save info->flags in a local variable before calling any
of the driver hooks. A more definitive fix (for post 2.6.13) is to
separate info->flags into one that is set by the driver and another that
is set by core fbdev/fbcon.
Sylvain Meyer [Mon, 15 Aug 2005 13:27:13 +0000 (21:27 +0800)]
[PATCH] intelfb: Do not ioremap entire graphics aperture
Reported by: Pavel Kysilka (Bugzilla Bug 4738)
modprobe of intelfb results in the following error message:
intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G chi
intelfb: Version 0.9.2
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
allocation failed: out of vmalloc space - use vmalloc=<size> to increase siz
intelfb: Cannot remap FB region.
This will fail if the graphics aperture size is greater than 128 MB.
Fix is to ioremap only from the beginning of graphics aperture to the
end of the used framebuffer memory.
John McCutchan [Mon, 15 Aug 2005 16:13:28 +0000 (12:13 -0400)]
[PATCH] inotify: add MOVE_SELF event
This adds a MOVE_SELF event to inotify. It is sent whenever the inode
you are watching is moved. We need this event so that we can catch
something like this:
Paul Mundt [Sat, 13 Aug 2005 17:28:06 +0000 (20:28 +0300)]
[PATCH] sh: Make _syscall6() do the right thing.
There was a rather silly and embarrassing typo in the sh _syscall6().
For the syscall ABI we have the trapa value specified as 0x10 + number
of arguments, this was being set incorrectly in the _syscall6() case
which ended up causing some problems for users.
Signed-off-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Linus Torvalds [Sat, 13 Aug 2005 21:22:59 +0000 (14:22 -0700)]
Fix up mmap of /dev/kmem
This leaves the issue of whether we should deprecate the whole thing (or
if we should check the whole mmap range, for that matter) open. Just do
the minimal fix for now.
Oops. I knew I didn't have the physical versus logical cpu identifiers right
when I generated that patch. It's not nearly as bad as I feared at the time
though.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
projects / linux-2.6 / log