- 05 Oct, 2009 40 commits
-
-
Lee Schermerhorn authored
Not upstream as it is fixed differently in .32 I noticed that alloc_bootmem_huge_page() will only advance to the next node on failure to allocate a huge page. I asked about this on linux-mm and linux-numa, cc'ing the usual huge page suspects. Mel Gorman responded: I strongly suspect that the same node being used until allocation failure instead of round-robin is an oversight and not deliberate at all. It appears to be a side-effect of a fix made way back in commit 63b4613c ["hugetlb: fix hugepage allocation with memoryless nodes"]. Prior to that patch it looked like allocations would always round-robin even when allocation was successful. Andy Whitcroft countered that the existing behavior looked like Andi Kleen's original implementation and suggested that we ask him. We did and Andy replied that his intention was to interleave the allocations. So, ... This patch moves the advance of the hstate next node from which to allocate up before the test for success of the attempted allocation. This will unconditionally advance the next node from which to alloc, interleaving successful allocations over the nodes with sufficient contiguous memory, and skipping over nodes that fail the huge page allocation attempt. Note that alloc_bootmem_huge_page() will only be called for huge pages of order > MAX_ORDER. Signed-off-by:
Lee Schermerhorn <lee.schermerhorn@hp.com> Reviewed-by:
Andi Kleen <ak@linux.intel.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: David Rientjes <rientjes@google.com> Cc: Adam Litke <agl@us.ibm.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: Eric Whitney <eric.whitney@hp.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
KAMEZAWA Hiroyuki authored
Not upstream due to other fixes in .32 Works around a BUG() which is triggered when the kernel accesses holes in vmalloc regions. BUG: unable to handle kernel paging request at fa54c000 IP: [<c04f687a>] read_kcore+0x260/0x31a *pde = 3540b067 *pte = 00000000 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/ieee80211/phy0/rfkill0/state Modules linked in: fuse sco bridge stp llc bnep l2cap bluetooth sunrpc nf_conntrack_ftp ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath uinput usb_storage arc4 ecb snd_hda_codec_realtek snd_hda_intel ath5k snd_hda_codec snd_hwdep iTCO_wdt snd_pcm iTCO_vendor_support pcspkr i2c_i801 mac80211 joydev snd_timer serio_raw r8169 snd soundcore mii snd_page_alloc ath cfg80211 ata_generic i915 drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] Sep 4 12:45:16 tuxedu kernel: Pid: 2266, comm: cat Not tainted (2.6.31-rc8 #2) Joybook Lite U101 EIP: 0060:[<c04f687a>] EFLAGS: 00010286 CPU: 0 EIP is at read_kcore+0x260/0x31a EAX: f5e5ea00 EBX: fa54d000 ECX: 00000400 EDX: 00001000 ESI: fa54c000 EDI: f44ad000 EBP: e4533f4c ESP: e4533f24 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process cat (pid: 2266, ti=e4532000 task=f09d19a0 task.ti=e4532000) Stack: 00005000 00000000 f44ad000 09d9c000 00003000 fa54c000 00001000 f6d16f60 e4520b80 fffffffb e4533f70 c04ef8eb e4533f98 00008000 09d97000 c04f661a e4520b80 09d97000 c04ef88c e4533f8c c04ba531 e4533f98 c04c0930 e4520b80 Call Trace: [<c04ef8eb>] ? proc_reg_read+0x5f/0x73 [<c04f661a>] ? read_kcore+0x0/0x31a [<c04ef88c>] ? proc_reg_read+0x0/0x73 [<c04ba531>] ? vfs_read+0x82/0xe1 [<c04c0930>] ? path_put+0x1a/0x1d [<c04ba62e>] ? sys_read+0x40/0x62 [<c0403298>] ? sysenter_do_call+0x12/0x2d Code: 39 f3 89 ca 0f 43 f3 89 fb 29 f2 29 f3 39 cf 0f 46 d3 29 55 dc 8d 1c 32 f6 40 0c 01 75 18 89 d1 89 f7 c1 e9 02 2b 7d ec 03 7d e0 <f3> a5 89 d1 83 e1 03 74 02 f3 a4 8b 00 83 7d dc 00 74 04 85 c0 EIP: [<c04f687a>] read_kcore+0x260/0x31a SS:ESP 0068:e4533f24 CR2: 00000000fa54c000 To access vmalloc area which may have memory holes, copy_from_user is useful. So this: # cat /proc/kcore > /dev/null will not panic. This is a minimal fix, suitable for 2.6.30.x and 2.6.31. More extensive /proc/kcore changes are planned for 2.6.32. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Tested-by:
Nick Craig-Wood <nick@craig-wood.com> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Reported-by: <kbowa@tuxedu.org> Signed-off-by:
-
Sarah Sharp authored
commit 6682bb39 upstream. When there's a descriptor after the SuperSpeed endpoint companion descriptor, the previous code would have skipped over twice the length it was supposed to. This code fixes crashes seen with UASP devices (which have a UASP descriptor after the SS endpoint companion descriptor). Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Sarah Sharp authored
commit 624defa1 upstream. Interrupt transfers are submitted to the xHCI hardware using the same TRB type as bulk transfers. Re-use the bulk transfer enqueueing code to enqueue interrupt transfers. Interrupt transfers are a bit different than bulk transfers. When the interrupt endpoint is to be serviced, the xHC will consume (at most) one TD. A TD (comprised of sg list entries) can take several service intervals to transmit. The important thing for device drivers to note is that if they use the scatter gather interface to submit interrupt requests, they will not get data sent from two different scatter gather lists in the same service interval. For now, the xHCI driver will use the service interval from the endpoint's descriptor (bInterval). Drivers will need a hook to poll at a more frequent interval. Set urb->interval to the interval that the xHCI hardware will use. Signed-off-by:
-
Sarah Sharp authored
commit 2f697f6c upstream. The xHCI hardware reports the number of bytes untransferred for a given transfer buffer. If the hardware reports a bytes untransferred value greater than the submitted buffer size, we want to play it safe and say no data was transferred. If the driver considers a short packet to be an error, remember to set -EREMOTEIO. Signed-off-by:
-
Sarah Sharp authored
commit 204970a4 upstream. Make sure that the driver that submitted the URB considers a short packet an error before setting -EREMOTEIO during a short control transfer. Signed-off-by:
-
Sarah Sharp authored
commit 99eb32db upstream. Make sure that the amount of data the xHC says was transmitted is less than or equal to the size of the requested transfer buffer. Before, if the host controller erroneously reported that the number of bytes untransferred was bigger than the buffer in the URB, urb->actual_length could be set to a very large size. Make sure urb->actual_length <= urb->transfer_buffer_length. Signed-off-by:
-
Sarah Sharp authored
commit 9191eee7 upstream. On a successful transfer, urb->td is freed before the URB is ready to be given back to the driver. Don't touch urb->td after it's freed. This bug would have only shown up when xHCI debugging was turned on, and the freed memory was quickly reused for something else. Signed-off-by:
-
Sarah Sharp authored
commit 83fbcdcc upstream. The 0.95 xHCI spec says that non-control endpoints will be halted if a babble is detected on a transfer. The 0.96 xHCI spec says all types of endpoints will be halted when a babble is detected. Some hardware that claims to be 0.95 compliant halts the control endpoint anyway. When a babble is detected on a control endpoint, check the hardware's output endpoint context to see if the endpoint is marked as halted. If the control endpoint is halted, a reset endpoint command must be issued and the transfer ring dequeue pointer needs to be moved past the stopped transfer. Basically, we treat it as if the control endpoint had stalled. Handle bulk babbling endpoints as if we got a completion event with a stall completion code. Signed-off-by:
-
Sarah Sharp authored
commit 66d1eebc upstream. Use trb_comp_code instead of getting the completion code from the transfer event every time. Signed-off-by:
-
Sarah Sharp authored
commit ac9d8fe7 upstream. This Fresco Logic xHCI host controller chip revision puts bad data into the output endpoint context after a Reset Endpoint command. It needs a Configure Endpoint command (instead of a Set TR Dequeue Pointer command) after the reset endpoint command. Set up the input context before issuing the Reset Endpoint command so we don't copy bad data from the output endpoint context. The HW also can't handle two commands queued at once, so submit the TRB for the Configure Endpoint command in the event handler for the Reset Endpoint command. Devices that stall on control endpoints before a configuration is selected will not work under this Fresco Logic xHCI host controller revision. This patch is for prototype hardware that will be given to other companies for evaluation purposes only, and should not reach consumer hands. Fresco Logic's next chip rev should have this bug fixed. Signed-off-by:
-
Sarah Sharp authored
commit 82d1009f upstream. When a control endpoint stalls, the next control transfer will clear the stall. The USB core doesn't call down to the host controller driver's endpoint_reset() method when control endpoints stall, so the xHCI driver has to do all its stall handling for internal state in its interrupt handler. When the host stalls on a control endpoint, it may stop on the data phase or status phase of the control transfer. Like other stalled endpoints, the xHCI driver needs to queue a Reset Endpoint command and move the hardware's control endpoint ring dequeue pointer past the failed control transfer (with a Set TR Dequeue Pointer or a Configure Endpoint command). Since the USB core doesn't call usb_hcd_reset_endpoint() for control endpoints, we need to do this in interrupt context when we get notified of the stalled transfer. URBs may be queued to the hardware before these two commands complete. The endpoint queue will be restarted once both commands complete. Signed-off-by:
-
Sarah Sharp authored
commit 2d3f1fac upstream. Full speed devices have varying max packet sizes (8, 16, 32, or 64) for endpoint 0. The xHCI hardware needs to know the real max packet size that the USB core discovers after it fetches the first 8 bytes of the device descriptor. In order to fix this without adding a new hook to host controller drivers, the xHCI driver looks for an updated max packet size for control endpoints. If it finds an updated size, it issues an evaluate context command and waits for that command to finish. This should only happen in the initialization and device descriptor fetching steps in the khubd thread, so blocking should be fine. Signed-off-by:
-
Sarah Sharp authored
commit 47aded8a upstream. Set the max packet size for the default control endpoint on high speed devices to be 64 bytes. High speed devices always have a max packet size of 64 bytes. There's no use setting it to eight for the initial 8 byte descriptor fetch and then issuing (and waiting for) an evaluate context command to update it to 64 bytes for the subsequent control transfers. The USB core guesses that the max packet size on a full speed control endpoint is 64 bytes, and then updates it after the first 8-byte descriptor fetch. Change the initial setup for the xHCI internal representation of the full speed device to have a 64 byte max packet size. Signed-off-by:
-
Sarah Sharp authored
commit f2217e8e upstream. Refactor out the code issue, wait for, and parse the event completion code for a configure endpoint command. Modify it to support the evaluate context command, which has a very similar submission process. Add functions to copy parts of the output context into the input context (which will be used in the evaluate context command). Signed-off-by:
-
Sarah Sharp authored
commit 018218d1 upstream. Use the virtual address of the memory hardware uses, not the address for the container of that memory. Signed-off-by:
-
Sarah Sharp authored
commit b0567b3f upstream. Different sections of the xHCI 0.95 specification had opposing requirements for the chain bit in a link transaction request buffer (TRB). The chain bit is used to designate that adjacent TRBs are all part of the same scatter gather list that should be sent to the device. Link TRBs can be in the middle, or at the beginning or end of these chained TRBs. Sections 4.11.5.1 and 6.4.4.1 both stated the link TRB "shall have the chain bit set to 1", meaning it is always chained to the next TRB. However, section 4.6.9 on the stop endpoint command has specific cases for what the hardware must do for a link TRB with the chain bit set to 0. The 0.96 specification errata later cleared up this issue by fixing the 4.11.5.1 and 6.4.4.1 sections to state that a link TRB can have the chain bit set to 1 or 0. The problem is that the xHCI cancellation code depends on the chain bit of the link TRB being cleared when it's at the end of a TD, and some 0.95 xHCI hardware simply stops processing the ring when it encounters a link TRB with the chain bit cleared. Allow users who are testing 0.95 xHCI prototypes to set a module parameter (link_quirk) to turn on this link TRB work around. Cancellation may not work if the ring is stopped exactly on a link TRB with chain bit set, but cancellation should be a relatively uncommon case. Signed-off-by:
-
Alan Stern authored
commit 7bd032dc upstream. This patch (as1292) modifies the USB serial console driver, to make it compatible with the recent changes to the USB serial core. The most important change is that serial->disc_mutex now has to be unlocked following a successful call to usb_serial_get_by_index(). Other less notable changes include: Use the requested port number instead of port 0 always. Prevent the serial device from being autosuspended. Use the ASYNCB_INITIALIZED flag bit to indicate when the port hardware has been initialized. In spite of these changes, there's no question that the USB serial console code is still a big hack. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
commit 320348c8 upstream. This patch (as1291) removes a bunch of code from serial_open(), things that were rendered unnecessary by earlier patches. A missing spinlock is added to protect port->port.count, which needs to be incremented even if the open fails but not if the tty has gotten a hangup. The test for whether the hardware has been initialized, based on the use count, is replaced by a more transparent test of the ASYNCB_INITIALIZED bit in the port flags. Signed-off-by:
-
Alan Stern authored
commit ff8324df upstream. This patch (as1290) adds some missing tests. serial_down() isn't supposed to do anything if the hardware hasn't been initialized, and serial_close() isn't supposed to do anything if the tty has gotten a hangup (because serial_hangup() takes care of shutting down the hardware). The patch also updates and adds a few debugging lines. Signed-off-by:
-
Alan Stern authored
commit 74556123 upstream. This patch (as1289) renames serial_do_down() to serial_down() and serial_do_free() to serial_release(). It also adds a missing call to tty_shutdown() in serial_release(). Signed-off-by:
-
Alan Stern authored
commit 7e29bb4b upstream. This patch (as1288) fixes the initialization logic in serial_install(). A new tty always needs to have a termios initialized no matter what, not just in the case where the lower driver will override the termios settings. Signed-off-by:
-
Alan Stern authored
commit cc56cd01 upstream. This patch (as1287) makes serial_install() be reponsible for acquiring references to the usb_serial structure and the driver module when a tty is first used. This is more sensible than having serial_open() do it, because a tty can be opened many times whereas it is installed only once, when it is created. (Not to mention that these actions are reversed when the tty is released, not when it is closed.) Finally, it is at install time that the TTY core takes its own reference to the usb_serial module, so it is only fitting that we should act the same way in regard to the lower-level serial driver. Signed-off-by:
-
Alan Stern authored
commit 8bc2c1b2 upstream. This patch (as1286) changes usb_serial_get_by_index(). Now the routine will check whether the serial device has been disconnected; if it has then the return value will be NULL. If the device hasn't been disconnected then the routine will return with serial->disc_mutex held, so that the caller can use the structure without fear of racing against driver unloads. This permits the scope of table_mutex in destroy_serial() to be reduced. Instead of protecting the entire function, it suffices to protect the part that actually uses serial_table[], i.e., the call to return_serial(). There's no longer any danger of the refcount being incremented after it reaches 0 (which was the reason for having the large scope previously), because it can't reach 0 until the serial device has been disconnected. Also, the patch makes serial_install() check that serial is non-NULL before attempting to use it. Signed-off-by:
-
Alan Stern authored
commit f5b0953a upstream. This patch (as1285) rearranges the subroutines in usb-serial.c concerned with tty lifetimes into a more logical order: install, open, hangup, close, release. It also updates the formatting of the kerneldoc comments. Signed-off-by:
-
Alan Stern authored
commit 41bd34dd upstream. This patch (as1284) changes the referencing of the usb_serial and usb_serial_port structures in usb-serial.c. It's not feasible to make the port structures keep a reference to the serial structure, because the ports need to remain in existence when serial is released -- quite a few of the drivers expect this. Consequently taking a reference to the port when the device file is open is insufficient; such a reference would not pin serial. To fix this, we now take a reference to serial when the device file is opened. The final put_device() for the ports occurs in destroy_serial(), so that the ports will last as long as they are needed. The patch initializes all the port devices, including those in the unused "fake" ports. This makes the code more uniform because they can all be released in the same way. The error handling code in usb_serial_probe() is much simplified by this approach; instead of freeing everything by hand we can use a single usb_serial_put() call. Also simplified is the port-release mechanism. Instead of being two separate routines, port_release() and port_free() can be combined into one. Signed-off-by:
-
Alan Cox authored
commit fe1ae7fd upstream. Various drivers have hacks to mangle termios structures. This stems from the fact there is no nice setup hook for configuring the termios settings when the port is created Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Luca Tettamanti authored
commit 2c2a6172 upstream. Add myself as asus_atk0110 maintainer. Signed-off-by:
Luca Tettamanti <kronos.it@gmail.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Alan Cox authored
commit 4455e344 upstream. Signed-off-by:
-
Alan Cox authored
commit d2b39182 upstream. The USB layer uses tty_hangup to deal with unplugs of the physical hardware (analogous to loss of carrier) and then frees the resources. However the tty_hangup is asynchronous. As the hangup can sleep we can use tty_vhangup which is the non async version to avoid freeing resources too early. Signed-off-by:
-
Alan Cox authored
commit 7ca0ff9a upstream. Now we are extracting out methods for shutdown and the like we can add a proper tty_port_close method that knows all the innards of the tty closing process and hides the lot from the caller. At some point in the future this will be paired with a similar open() helper and the drivers can stick to hardware management. Signed-off-by:
-
Alan Stern authored
commit 2023c610 upstream. This patch (as1271) affects when new devices get linked into their bus's list of devices. Currently this happens after probing, and it doesn't happen at all if probing fails. Clearly this is wrong, because at that point quite a few symbolic links have already been created in sysfs. We are committed to adding the device, so it should be linked into the bus's list regardless. In addition, this needs to happen before the uevent announcing the new device gets issued. Otherwise user programs might try to access the device before it has been added to the bus. To fix both these problems, the patch moves the call to klist_add_tail() forward from bus_attach_device() to bus_add_device(). Since bus_attach_device() now does nothing but probe for drivers, it has been renamed to bus_probe_device(). And lastly, the kerneldoc is updated. Signed-off-by:
-
Bob Copeland authored
commit 0d0cd72f upstream. Paraphrasing Rafael J. Wysocki: "drivers should not release PCI IRQs in suspend." Doing so causes a warning during suspend/resume on some platforms. Cc: Rafael J. Wysocki <rjw@sisk.pl> Reported-by:
Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Nick Kossifidis authored
commit edd7fc70 upstream. * Don't put chip to full sleep because there are problems during wakeup. Instead hold MAC/Baseband on warm reset state via a new function ath5k_hw_on_hold. * Minor cleanups Signed-off-by:
Nick Kossifidis <mickflemm@gmail.com> Tested-by:
Ben Greear <greearb@candelatech.com> Tested-by:
Johannes Stezenbach <js@sig21.net> Signed-off-by:
-
Patrick McHardy authored
netfilter: ebt_ulog: fix checkentry return value Upstream commit 8a56df0a: Commit 19eda879 (netfilter: change return types of check functions for Ebtables extensions) broke the ebtables ulog module by missing a return value conversion. Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Patrick McHardy authored
netfilter: bridge: refcount fix Upstream commit f3abc9b9: commit f216f082 ([NETFILTER]: bridge netfilter: deal with martians correctly) added a refcount leak on in_dev. Instead of using in_dev_get(), we can use __in_dev_get_rcu(), as netfilter hooks are running under rcu_read_lock(), as pointed by Patrick. Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Patrick McHardy authored
netfilter: nf_conntrack: netns fix re reliable conntrack event delivery Upstream commit ee254fa4: Conntracks in netns other than init_net dying list were never killed. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Acked-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Patrick McHardy authored
netfilter: nf_nat: fix inverted logic for persistent NAT mappings Upstream commit cce5a5c3: Kernel 2.6.30 introduced a patch [1] for the persistent option in the netfilter SNAT target. This is exactly what we need here so I had a quick look at the code and noticed that the patch is wrong. The logic is simply inverted. The patch below fixes this. Also note that because of this the default behavior of the SNAT target has changed since kernel 2.6.30 as it now ignores the destination IP in choosing the source IP for nating (which should only be the case if the persistent option is set). [1] http://git.eu.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98d500d66cb7940747b424b245fc6a51ecfbf005Signed-off-by:
Maximilian Engelhardt <maxi@daemonizer.de> Signed-off-by:
-
Pierre Habouzit authored
commit 119e7a22 upstream. This improves patch fa6963b2 so that perf.data stuff that has been dumped as root can be read (annotate/report) by a user without the use of the --force. Rationale is that root has plenty of ways to screw us (usually) that do not require twisted schemes involving specially crafting a perf.data. Signed-off-by:
Pierre Habouzit <pierre.habouzit@intersec.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <20090827075902.GF19653@laphroaig.corp> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Kurt Roeckx authored
commit f0adb134 upstream. Fixes bugzilla #13780 From: Kurt Roeckx <kurt@roeckx.be> Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
