- 05 May, 2007 3 commits
-
-
Russell King authored
Add cached device type for ioremap_cached(). Group all device memory types together, and ensure that they all have a "MT_DEVICE" prefix. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Change the memory types table to define the L1 descriptor bit 4 to be in terms of the ARMv6 definition - execute never. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
- 21 Apr, 2007 11 commits
-
-
Russell King authored
Add prot_pte_ext to the mem_types table to allow the extended pte attributes to be passed to set_pte_ext(), thereby permitting us to specify memory type information for the hardware PTE entries. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
We really want to be using the memory type table in ioremap, so we only have to do the CPU type fixups in one place. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Rather than our three separate loops to setup mappings (by page mappings up to a section boundary, then section mappings, and the remainder by page mappings) convert this to a more conventional Linux style of a loop over each page table level. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Catalin Marinas at ARM Ltd says: > The CPU architects in ARM intended supersections only as a way to map > addresses >= 4GB. Supersections are not mandated by the architecture > and there is no easy way to detect their hardware support at run-time > (other than checking for a specific core). From the analysis done in > ARM, there wasn't a clear performance gain by using supersections > rather than sections (no significant improvement in the TLB misses). Therefore, we should avoid using supersections unless there's a real need (iow, we're mapping addresses >= 4GB). This means that we can simplify create_mapping() a bit since we will only use supersection mappings for addresses >= 4GB, which means that the physical, virtual and length must be multiples of the supersection mapping size. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
There's now no need to carry around each protection separately. Instead, pass around the pointer to the entry in the mem_types array which we're interested in. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Rather than combining the domain for a particular memory type with the protection information each time we want to use it, do so when we fix up the mem_type array at initialisation time. Rename struct mem_types to be mem_type - each structure is one memory type description, not several. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Lots of places in arch/arm were needlessly including linux/ptrace.h, resumably because we used to pass a struct pt_regs to interrupt handlers. Now that we don't, all these ptrace.h includes are redundant. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
- 20 Apr, 2007 2 commits
-
-
Linus Torvalds authored
This reverts commit 60cba200. It's been linked to lockups of the e1000 hardware, see for example https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 but it's likely that the commit itself is not really introducing the bug, but just allowing an unrelated problem to rear its ugly head (ie one current working theory is that the code exposes us to a hardware race condition by decreasing the amount of time we spend in each NAPI poll cycle). We'll revert it until root cause is known. Intel has a repeatable reproduction on two different machines and bus traces of the hardware doing something bad. Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Cc: Jeff Garzik <jeff@garzik.org> Cc: David S. Miller <davem@davemloft.net> Cc: Greg KH <gregkh@suse.de> Cc: Dave Jones <davej@redhat.com> Cc: Auke Kok <auke-jan.h.kok@intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev: pata_sis: Fix oops on boot
-
- 19 Apr, 2007 14 commits
-
-
Alan Cox authored
A small number of SiS setups require special handling (not many judging by how long this dumb bug survived). A couple of Fedora 7 devel testers hit an Oops on pata_sis loading which is caused by terminal confusion between chipset as 'the chipset we have found' and chipset as 'array iterator' Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Stephen Hemminger authored
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Stephen Hemminger authored
The Yukon FE (100mbit only) chips do not support large packets. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Stephen Hemminger authored
The Yukon EC Ultra chips have transmit settings for store and forward and PCI buffering. By setting these appropriately, normal performance goes from 750Mbytes/sec to 940Mbytes/sec (non-jumbo). It is also possible to do Jumbo mode, but it means turning off TSO and checksum offload so the performance gets worse. There isn't enough buffering for checksum offload to work. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Stephen Hemminger authored
Need to make sure and disable ASF on all chip types. Otherwise, there may be random reboots. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Stephen Hemminger authored
There should never be descriptor error unless hardware or driver is buggy. But if an error occurs, print useful information, clear irq, and recover. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Stephen Hemminger authored
This device is having all sorts of problems that lead to data corruption and system instability. It gets receive status and data out of order, it generates descriptor and TSO errors, etc. Until the problems are resolved, it should not be used by anyone who cares about there system. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Dave Jiang authored
Gianfar needs crc32 to be selected to compile. Signed-off-by: Dave Jiang <djiang@mvista.com> -- drivers/net/Kconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) -- Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Linas Vepstas authored
The basic structure of "normal" UDP/IP/Ethernet frames (that actually work): - It starts with the Ethernet header (dest MAC, src MAC, etc.) - The next part is occupied by the IP header (version info, length of packet, id=0, fragment offset=0, checksum, from / to address, etc.) - Then comes the UDP header (src / dest port, length, checksum) - Actual payload - Ethernet checksum Now what's different for IP fragment: - The IP header has id set to some value (same for all fragments), offset is set appropriately (i.e. 0 for first fragment, following according to size of other fragments), size is the length of the frame. - UDP header is unchanged. I.e. length is according to full UDP datagram, not just the part within the actual frame! But this is only true within the first frame: all following frames don't have a valid UDP-header at all. The spidernet silicon seems to be quite intelligent: It's able to compute (IP / UDP / Ethernet) checksums on the fly and tests if frames are conforming to RFC -- at least conforming to RFC on complete frames. But IP fragments are different as explained above: I.e. for IP fragments containing part of a UDP datagram it sees incompatible length in the headers for IP and UDP in the first frame and, thus, skips this frame. But the content *is* correct for IP fragments. For all following frames it finds (most probably) no valid UDP header at all. But this *is* also correct for IP fragments. The Linux IP-stack seems to be clever in this point. It expects the spidernet to calculate the checksum (since the module claims to be able to do so) and marks the skb's for "normal" frames accordingly (ip_summed set to CHECKSUM_HW). But for the IP fragments it does not expect the driver to be capable to handle the frames appropriately. Thus all checksums are allready computed. This is also flaged within the skb (ip_summed set to CHECKSUM_NONE). Unfortunately the spidernet driver ignores that hints. It tries to send the IP fragments of UDP datagrams as normal UDP/IP frames. Since they have different structure the silicon detects them the be not "well-formed" and skips them. The following one-liner against 2.6.21-rc2 changes this behavior. If the IP-stack claims to have done the checksumming, the driver should not try to checksum (and analyze) the frame but send it as is. Signed-off-by: Norbert Eicker <n.eicker@fz-juelich.de> Signed-off-by: Linas Vepstas <linas@austin.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Divy Le Ray authored
Remove assumption that PHY interrupts use GPIOs 3 and 5. Deal with PHY interrupts connected to any GPIO pins. Signed-off-by: Divy Le Ray <divy@chelsio.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Divy Le Ray authored
Reuse the incoming skb when a clientless abort req is recieved. The release of RDMA connections HW resources might be deferred in low memory situations. Ensure that no further activity is passed up to the RDMA driver for these connections. Signed-off-by: Divy Le Ray <divy@chelsio.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvmLinus Torvalds authored
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm: KVM: Fix off-by-one when writing to a nonpae guest pde
-
Avi Kivity authored
Nonpae guest pdes are shadowed by two pae ptes, so we double the offset twice: once to account for the pte size difference, and once because we need to shadow pdes for a single guest pde. But when writing to the upper guest pde we also need to truncate the lower bits, otherwise the multiply shifts these bits into the pde index and causes an access to the wrong shadow pde. If we're at the end of the page (accessing the very last guest pde) we can even overflow into the next host page and oops. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Denis Lunev authored
There is a race between netlink_dump_start() and netlink_release() that can lead to the situation when a netlink socket with non-zero callback is freed. Here it is: CPU1: CPU2 netlink_release(): netlink_dump_start(): sk = netlink_lookup(); /* OK */ netlink_remove(); spin_lock(&nlk->cb_lock); if (nlk->cb) { /* false */ ... } spin_unlock(&nlk->cb_lock); spin_lock(&nlk->cb_lock); if (nlk->cb) { /* false */ ... } nlk->cb = cb; spin_unlock(&nlk->cb_lock); ... sock_orphan(sk); /* * proceed with releasing * the socket */ The proposal it to make sock_orphan before detaching the callback in netlink_release() and to check for the sock to be SOCK_DEAD in netlink_dump_start() before setting a new callback. Signed-off-by: Denis Lunev <den@openvz.org> Signed-off-by: Kirill Korotaev <dev@openvz.org> Signed-off-by: Pavel Emelianov <xemul@openvz.org> Acked-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 18 Apr, 2007 3 commits
-
-
Olaf Kirch authored
This patch fixes an oops first reported in mid 2006 - see http://lkml.org/lkml/2006/8/29/358 The cause of this bug report is that when an error is signalled on the socket, irda_recvmsg_stream returns without removing a local wait_queue variable from the socket's sk_sleep queue. This causes havoc further down the road. In response to this problem, a patch was made that invoked sock_orphan on the socket when receiving a disconnect indication. This is not a good fix, as this sets sk_sleep to NULL, causing applications sleeping in recvmsg (and other places) to oops. This is against the latest net-2.6 and should be considered for -stable inclusion. Signed-off-by: Olaf Kirch <olaf.kirch@oracle.com> Signed-off-by: Samuel Ortiz <samuel@sortiz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vlad Yasevich authored
The way partial delivery is currently implemnted, it is possible to intereleave a message (either from another steram, or unordered) that is not part of partial delivery process. The only way to this is for a message to not be a fragment and be 'in order' or unorderd for a given stream. This will result in bypassing the reassembly/ordering queues where things live duing partial delivery, and the message will be delivered to the socket in the middle of partial delivery. This is a two-fold problem, in that: 1. the app now must check the stream-id and flags which it may not be doing. 2. this clearing partial delivery state from the association and results in ulp hanging. This patch is a band-aid over a much bigger problem in that we don't do stream interleave. Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Make sure to actually assign the determined mode to rq->sadb_x_ipsecrequest_mode. Noticed by Joe Perches. Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 17 Apr, 2007 7 commits
-
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: [BRIDGE]: Unaligned access when comparing ethernet addresses [SCTP]: Unmap v4mapped addresses during SCTP_BINDX_REM_ADDR operation. [SCTP]: Fix assertion (!atomic_read(&sk->sk_rmem_alloc)) failed message [NET]: Set a separate lockdep class for neighbour table's proxy_queue [NET]: Fix UDP checksum issue in net poll mode. [KEY]: Fix conversion between IPSEC_MODE_xxx and XFRM_MODE_xxx. [NET]: Get rid of alloc_skb_from_cache
-
Linus Torvalds authored
* 'for-linus' of master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband: IB/mthca: Fix data corruption after FMR unmap on Sinai
-
git://one.firstfloor.org/home/andi/git/linux-2.6Linus Torvalds authored
* 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6: [PATCH] x86: Fix potential overflow in perfctr reservation [PATCH] x86: Fix gcc 4.2 _proxy_pda workaround
-
Olof Johansson authored
* Last write during i2c_xfer is of the wrong byte (off-by-1). * Read length is wrong for some of the reads (mistakenly used the PEC version) Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Jean Delvare authored
Looks like a local change I made to be able to test-compile the i2c-pasemi driver leaked upstream. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Jean Delvare authored
Users have been complaining about the w83627ehf driver flooding their logs with debug messages like: w83627ehf 9191-0a10: Increasing fan 4 clock divider from 64 to 128 or: w83627ehf 9191-0290: Increasing fan 4 clock divider from 4 to 8 The reason is that we failed to actually write the LSB of the encoded clock divider value for that fan, causing the next read to report the same old value again and again. Additionally, the fan number was improperly reported, making the bug harder to find. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Russell King authored
Provide an dummy implementation of devm_ioport_map() and devm_ioport_unmap() to allow drivers (eg, pata_platform) to build for platforms where CONFIG_NO_IOPORT is selected. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-