- 01 Aug, 2008 40 commits
-
-
Luotao Fu authored
commit 9a7867e1 upstream The block transfer routine in the mpc52xx psc spi driver misinterpret the datasheet. According to the processor datasheet the chipselect is held as long as the EOF is not written. Theoretically blocks of any sizes can be transferred in this way. The old routine however writes an EOF after every word, which has the size of size_of_word. This makes the transfer slow. Also fixed some duplicate code. Signed-off-by:
Luotao Fu <l.fu@pengutronix.de> Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jesse Brandeburg authored
commit bb5d10ac upstream The ixgbe driver was untested with device ID 8086:10c8 but still advertises support. Currently if this device is present in the system when the driver is loaded, the system will panic. Remove this device ID until full support can be tested with available hardware. This patch is necessary for 2.6.24, 2.6.25 and 2.6.26 Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Jeff Dike authored
commit 7c1fed03 upstream My copying of linux/init.h didn't go far enough. The definition of __used singled out gcc minor version 3, but didn't care what the major version was. This broke when unit-at-a-time was added and gcc started throwing out initcalls. This results in an early boot crash when ptrace tries to initialize a process with an empty, uninitialized register set. Signed-off-by:
Jeff Dike <jdike@linux.intel.com> Signed-off-by:
-
Eric Sandeen authored
commit 7fcba054 upstream Date: Mon, 28 Jul 2008 15:46:39 -0700 Subject: eCryptfs: use page_alloc not kmalloc to get a page of memory With SLUB debugging turned on in 2.6.26, I was getting memory corruption when testing eCryptfs. The root cause turned out to be that eCryptfs was doing kmalloc(PAGE_CACHE_SIZE); virt_to_page() and treating that as a nice page-aligned chunk of memory. But at least with SLUB debugging on, this is not always true, and the page we get from virt_to_page does not necessarily match the PAGE_CACHE_SIZE worth of memory we got from kmalloc. My simple testcase was 2 loops doing "rm -f fileX; cp /tmp/fileX ." for 2 different multi-megabyte files. With this change I no longer see the corruption. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Acked-by:
Michael Halcrow <mhalcrow@us.ibm.com> Acked-by:
Rik van Riel <riel@redhat.com> Signed-off-by:
-
Ingo Molnar authored
based on e22146e6 upstream Fix bug in kernel_physical_mapping_init() that causes kernel page table to be built incorrectly for systems with greater than 512GB of memory. Signed-off-by:
Jack Steiner <steiner@sgi.com> Cc: linux-mm@kvack.org Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Oliver Pinter <oliver.pntr@gmail.com> Signed-off-by:
-
Steven Toth authored
(cherry picked from commit 7e994302) DVB: cx23885: SRAM changes for the 885 and 887 silicon parts In a previous patch I merged both memory maps into a single struct, believing that they could be combined. We've since found problems with streaming multiple channels on the 885. I'm restoring the multiple memory map structs - in line with the windows driver. Signed-off-by:
Steven Toth <stoth@hauppauge.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Steven Toth authored
(cherry picked from commit d8d12b43) DVB: cx23885: Reallocated the sram to avoid concurrent VIDB/C issues This may be cx23885 chip specific and may not work on the cx23887. Analog and mpeg encoder streaming are still to be tested. Signed-off-by:
-
Steven Toth authored
(cherry picked from commit 52ce27bf) DVB: cx23885: DVB Transport cards using DVB port VIDB/TS1 did not stream Certain DVB cards that have demodulators on TS1/VIDB were not streaming packets. This ensure the pin directions on PAD_CTRL are set correctly, solving the issue. Signed-off-by:
-
Steven Toth authored
(cherry picked from commit ecda5966) DVB: cx23885: Ensure PAD_CTRL is always reset to a sensible default PAD_CTRL controls TS1 and TS2 input and output states, if the register became corrupt the driver was never able to recover. Signed-off-by:
-
Steven Toth authored
(cherry picked from commit 28901ab6) V4L: cx23885: Bugfix for concurrent use of /dev/video0 and /dev/video1 With the HVR1800, trying to use video0 and video1 simultaneously caused buffer corruption in the PCIe bridge. This fix reallocates video1 buffer locations to avoid the issue. Signed-off-by:
-
Simon Arlott authored
V4L: saa7134: Copy tuner data earlier to avoid overwriting manual tuner type (cherry picked from commit d53687d1) Copy tuner data earlier in init to avoid overwriting manual tuner type When saa7134_board_init2 runs, it immediately overwrites the current value (set earlier from module parameter) of tuner_type with the static values, and then does autodetection. This patch moves the tuner_addr copy to earlier in saa7134_initdev and removes the tuner_type copy from saa7134_board_init2. Autodetection could still potentially change to the wrong tuner type, but it is now possible to override the default type for the card again. My card's tuner is configured with autodetection from eeprom, so I don't need to manually set the tuner. I've checked that the autodetection still works for my card. Signed-off-by:
Simon Arlott <simon@fire.lp0.eu> Reviewed-by:
Hermann Pitton <hermann-pitton@arcor.de> Cc: Brian Marete <bgmarete@gmail.com> Signed-off-by:
-
Laurent Pinchart authored
(cherry picked from commit bdf2fe4a) V4L: uvcvideo: Add support for Medion Akoya Mini E1210 integrated webcam Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@skynet.be> Signed-off-by:
-
Laurent Pinchart authored
(cherry picked from commit 6833c917) V4L: uvcvideo: Make input device support optional UVC devices can report button events. The uvcvideo driver depends on CONFIG_INPUT to report events to the input layer. This patch removes the hard dependency by introducing a new CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV option. Signed-off-by:
-
Laurent Pinchart authored
(cherry picked from commit e01117c8) V4L: uvcvideo: Don't free URB buffers on suspend. All submitted URBs must be killed at suspend time, but URB buffers don't have to be freed. Avoiding a free on suspend/reallocate on resume lowers the pressure on system memory. Signed-off-by:
-
Laurent Pinchart authored
(cherry picked from commit 29135878) V4L: uvcvideo: Use GFP_NOIO when allocating memory during resume The swap device might still be asleep, so memory allocated in the resume handler must use GFP_NOIO. Thanks to Oliver Neukum for catching and reporting this bug. Signed-off-by:
-
Laurent Pinchart authored
(cherry picked from commit 233548a2) V4L: uvcvideo: Fix a buffer overflow in format descriptor parsing Thanks to Oliver Neukum for catching and reporting this bug. Signed-off-by:
-
Michael Krufky authored
(cherry picked from commit d01eb2dc) DVB: dib0700: add support for Hauppauge Nova-TD Stick 52009 Signed-off-by:
-
Hans Verkuil authored
(cherry picked from commit 1a3932e0) V4L: cx18: Upgrade to newer firmware & update cx18 documentation Conexant graciously gave us permission to redistribute the firmware. Update the documentation where the firmware can be downloaded. Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Pierre Ossman authored
Commit 981bcead upstream. Stop the S/PDIF DMA engine and output when the device is told to pause. It will keep on looping the current buffer contents if this isn't done. Signed-off-by:
Pierre Ossman <drzeus@drzeus.cx> Tested-by:
Rene Herman <rene.herman@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Brice Goglin authored
part of commit 0dcffac1 upstream (the upstream multislice patch contains this fix within a large rework of the code since there is one rx_done ring per slice. The old allocating is replaced by a call to myri10ge_probe_slices()) Allocating the rx_done ring requires mgp->max_intr_slots to be valid, which requires that we already loaded the firmware we are going to use with this ring. So move the allocating after myri10ge_load_firmware() (but keep it before myri10ge_reset() which already needs the rx_done ring). If fixedsa regression where loading the driver would not appear to do anything. Regression introduced in 2.6.26-rc3 by commit 014377a1 Reported and patch tested by Lukas Hejtmanek at http://lkml.org/lkml/2008/7/22/305 Reproduced and patch tested also by me. Signed-off-by:
Brice Goglin <brice@myri.com> Signed-off-by:
-
Brice Goglin authored
part of commit 0dcffac1 upstream (the upstream multislice patch contains the same fix within myri10ge_alloc_slices() which does this for every slice) Even if we don't have multiple slices in myri10ge in 2.6.26, we already use some multislice-aware routines that need the slice state pointers to mgp and dev to be valid. This patch fixes a regression where configuring the interface up would oops in myri10ge_allocate_rings() when using ss->mgp (and later when using ss->dev). Oops reported and patch tested by Lukas Hejtmanek at http://lkml.org/lkml/2008/7/23/101Signed-off-by:
-
Kay Sievers authored
commit ebabe276 Since 43cc71ee, the platform modalias is prefixed with "platform:". Add MODULE_ALIAS() to most of the hotpluggable platform drivers, to re-enable auto loading. Signed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 74988bd8 ] The IOMMU code and the block layer can split things up using different rules, so this can't work reliably. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 7ae93f51 ] Based upon a report by Daniel Smolik. We do it too early, which triggers a BUG in cpufreq_register_notifier(). Signed-off-by:
-
David S. Miller authored
[ Upstream commit b7c2a757 ] We're calling request_irq() with a IRQs disabled. No straightforward fix exists because we want to enable these IRQs and setup state atomically before getting into the IRQ handler the first time. What happens now is that we mark the VIRQ to not be automatically enabled by request_irq(). Then we make explicit enable_irq() calls when we grab the LDC channel. This way we don't need to call request_irq() illegally under the LDC channel lock any more. Bump LDC version and release date. Signed-off-by:
-
David S. Miller authored
[ Upstream commit 4b53fb67 ] This is based upon an excellent bug report from Eric Dumazet. tcp_ack() should clear ->icsk_probes_out even if there are packets outstanding. Otherwise if we get a sequence of ACKs while we do have packets outstanding over and over again, we'll never clear the probes_out value and eventually think the connection is too sick and we'll reset it. This appears to be some "optimization" added to tcp_ack() in the 2.4.x timeframe. In 2.2.x, probes_out is pretty much always cleared by tcp_ack(). Here is Eric's original report: ---------------------------------------- Apparently, we can in some situations reset TCP connections in a couple of seconds when some frames are lost. In order to reproduce the problem, please try the following program on linux-2.6.25.* Setup some iptables rules to allow two frames per second sent on loopback interface to tcp destination port 12000 iptables -N SLOWLO iptables -A SLOWLO -m hashlimit --hashlimit 2 --hashlimit-burst 1 --hashlimit-mode dstip --hashlimit-name slow2 -j ACCEPT iptables -A SLOWLO -j DROP iptables -A OUTPUT -o lo -p tcp --dport 12000 -j SLOWLO Then run the attached program and see the output : # ./loop State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,200ms,1) State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,200ms,3) State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,200ms,5) State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,200ms,7) State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,200ms,9) State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,200ms,11) State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,201ms,13) State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,188ms,15) write(): Connection timed out wrote 890 bytes but was interrupted after 9 seconds ESTAB 0 0 127.0.0.1:12000 127.0.0.1:54455 Exiting read() because no data available (4000 ms timeout). read 860 bytes While this tcp session makes progress (sending frames with 50 bytes of payload, every 500ms), linux tcp stack decides to reset it, when tcp_retries 2 is reached (default value : 15) tcpdump : 15:30:28.856695 IP 127.0.0.1.56554 > 127.0.0.1.12000: S 33788768:33788768(0) win 32792 <mss 16396,nop,nop,sackOK,nop,wscale 7> 15:30:28.856711 IP 127.0.0.1.12000 > 127.0.0.1.56554: S 33899253:33899253(0) ack 33788769 win 32792 <mss 16396,nop,nop,sackOK,nop,wscale 7> 15:30:29.356947 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 1:61(60) ack 1 win 257 15:30:29.356966 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 61 win 257 15:30:29.866415 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 61:111(50) ack 1 win 257 15:30:29.866427 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 111 win 257 15:30:30.366516 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 111:161(50) ack 1 win 257 15:30:30.366527 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 161 win 257 15:30:30.876196 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 161:211(50) ack 1 win 257 15:30:30.876207 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 211 win 257 15:30:31.376282 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 211:261(50) ack 1 win 257 15:30:31.376290 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 261 win 257 15:30:31.885619 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 261:311(50) ack 1 win 257 15:30:31.885631 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 311 win 257 15:30:32.385705 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 311:361(50) ack 1 win 257 15:30:32.385715 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 361 win 257 15:30:32.895249 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 361:411(50) ack 1 win 257 15:30:32.895266 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 411 win 257 15:30:33.395341 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 411:461(50) ack 1 win 257 15:30:33.395351 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 461 win 257 15:30:33.918085 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 461:511(50) ack 1 win 257 15:30:33.918096 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 511 win 257 15:30:34.418163 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 511:561(50) ack 1 win 257 15:30:34.418172 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 561 win 257 15:30:34.927685 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 561:611(50) ack 1 win 257 15:30:34.927698 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 611 win 257 15:30:35.427757 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 611:661(50) ack 1 win 257 15:30:35.427766 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 661 win 257 15:30:35.937359 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 661:711(50) ack 1 win 257 15:30:35.937376 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 711 win 257 15:30:36.437451 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 711:761(50) ack 1 win 257 15:30:36.437464 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 761 win 257 15:30:36.947022 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 761:811(50) ack 1 win 257 15:30:36.947039 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 811 win 257 15:30:37.447135 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 811:861(50) ack 1 win 257 15:30:37.447203 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 861 win 257 15:30:41.448171 IP 127.0.0.1.12000 > 127.0.0.1.56554: F 1:1(0) ack 861 win 257 15:30:41.448189 IP 127.0.0.1.56554 > 127.0.0.1.12000: R 33789629:33789629(0) win 0 Source of program : /* * small producer/consumer program. * setup a listener on 127.0.0.1:12000 * Forks a child * child connect to 127.0.0.1, and sends 10 bytes on this tcp socket every 100 ms * Father accepts connection, and read all data */ #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <unistd.h> #include <stdio.h> #include <time.h> #include <sys/poll.h> int port = 12000; char buffer[4096]; int main(int argc, char *argv[]) { int lfd = socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in socket_address; time_t t0, t1; int on = 1, sfd, res; unsigned long total = 0; socklen_t alen = sizeof(socket_address); pid_t pid; time(&t0); socket_address.sin_family = AF_INET; socket_address.sin_port = htons(port); socket_address.sin_addr.s_addr = htonl(INADDR_LOOPBACK); if (lfd == -1) { perror("socket()"); return 1; } setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(int)); if (bind(lfd, (struct sockaddr *)&socket_address, sizeof(socket_address)) == -1) { perror("bind"); close(lfd); return 1; } if (listen(lfd, 1) == -1) { perror("listen()"); close(lfd); return 1; } pid = fork(); if (pid == 0) { int i, cfd = socket(AF_INET, SOCK_STREAM, 0); close(lfd); if (connect(cfd, (struct sockaddr *)&socket_address, sizeof(socket_address)) == -1) { perror("connect()"); return 1; } for (i = 0 ; ;) { res = write(cfd, "blablabla\n", 10); if (res > 0) total += res; else if (res == -1) { perror("write()"); break; } else break; usleep(100000); if (++i == 10) { system("ss -on dst 127.0.0.1:12000"); i = 0; } } time(&t1); fprintf(stderr, "wrote %lu bytes but was interrupted after %g seconds\n", total, difftime(t1, t0)); system("ss -on | grep 127.0.0.1:12000"); close(cfd); return 0; } sfd = accept(lfd, (struct sockaddr *)&socket_address, &alen); if (sfd == -1) { perror("accept"); return 1; } close(lfd); while (1) { struct pollfd pfd[1]; pfd[0].fd = sfd; pfd[0].events = POLLIN; if (poll(pfd, 1, 4000) == 0) { fprintf(stderr, "Exiting read() because no data available (4000 ms timeout).\n"); break; } res = read(sfd, buffer, sizeof(buffer)); if (res > 0) total += res; else if (res == 0) break; else perror("read()"); } fprintf(stderr, "read %lu bytes\n", total); close(sfd); return 0; } ---------------------------------------- Signed-off-by:
-
Andrew Morton authored
commit 0c65f459 upstream arm's fls() is implemented as a macro, causing it to misbehave when passed 64-bit arguments. Fix. Cc: Nickolay Vinogradov <nickolay@protei.ru> Tested-by:
Krzysztof Halasa <khc@pm.waw.pl> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Jan Beulich authored
commit fb5e2b37 upstream Due to the addition of __attribute__((__cold__)) to a few symbols without adjusting the linker scripts, those symbols currently may end up outside the [_stext,_etext) range, as they get placed in .text.unlikely by (at least) gcc 4.3.0. This may confuse code not only outside of the kernel, symbol_put_addr()'s BUG() could also trigger. Hence we need to add .text.unlikely (and for future uses of __attribute__((__hot__)) also .text.hot) to the TEXT_TEXT() macro. Issue observed by Lukas Lipavsky. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Tested-by:
Lukas Lipavsky <llipavsky@suse.cz> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
David Brownell authored
commit 449321b3 upstream This fixes kernel http://bugzilla.kernel.org/show_bug.cgi?id=11112 (bogus RTC update IRQs reported) for rtc-at91rm9200 by scrubbing old IRQ status before enabling IRQs. It also removes nonfunctional periodic IRQ support from this driver; only update IRQs are reported, or provided by the hardware. I suspect some other RTCs probably have versions of #11112; it's easy to overlook, since most non-RTC drivers don't care about spurious IRQs: they're not reported to userspace. Signed-off-by:
W Unruh <unruh@physics.ubc.ca> Cc: Andrew Victor <avictor.za@gmail.com> Signed-off-by:
-
Jens Axboe authored
commit e8e7b9eb upstream cdrom_read_capacity() will blindly return the capacity from the device without sanity-checking it. This later causes code in fs/buffer.c to oops. Fix this by checking that the device is telling us sensible things. From: Jens Axboe <jens.axboe@oracle.com> Cc: Michael Buesch <mb@bu3sch.de> Cc: Jan Kara <jack@suse.cz> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <petkovbb@googlemail.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> [harvey: blocklen is a big-endian value] Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by:
-
Jan Kratochvil authored
commit d536b1f8 upstream currently if you use PTRACE_SINGLEBLOCK on AMD K6-3 (i586) it will crash. Kernel now wrongly assumes existing DEBUGCTLMSR MSR register there. Removed the assumption also for some other non-K6 CPUs but I am not sure there (but it can only bring small inefficiency there if my assumption is wrong). Based on info from Roland McGrath, Chuck Ebbert and Mikulas Patocka. More info at: https://bugzilla.redhat.com/show_bug.cgi?id=456175Signed-off-by:
Jan Kratochvil <jan.kratochvil@redhat.com> Signed-off-by:
-
Miao Xie authored
commit 91cd4d6e upstream Fix wrong domain attr updates, or we will always update the first sched domain attr. Signed-off-by:
Miao Xie <miaox@cn.fujitsu.com> Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Paul Jackson <pj@sgi.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Alexey Dobriyan authored
commit ee1e6ab6 upstream struct pagemap_walk was placed on stack, some hooks are initialized, the rest (->pgd_entry, ->pud_entry, ->pte_entry) are valid but junk. Reported-by:
Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Cc: "Vegard Nossum" <vegard.nossum@gmail.com> Signed-off-by:
-
Atsushi Nemoto authored
commit 5f17156f upstream Add missing cond_syscall() entry for compat_sys_epoll_pwait. Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Davide Libenzi <davidel@xmailserver.org> Signed-off-by:
-
Mathieu Desnoyers authored
commit: d35cb360 When a kernel was rebuilt, the previous Module.markers was not cleared. It caused markers with different format strings to appear as duplicates when a markers was changed. This problem is present since scripts/mod/modpost.c started to generate Module.markers, commit b2e3e658 It therefore applies to 2.6.25, 2.6.26 and linux-next. I merely merged the patches from Roland, Wenji and Takashi here. Credits to Roland McGrath <roland@redhat.com> Wenji Huang <wenji.huang@oracle.com> and Takashi Nishiie <t-nishiie@np.css.fujitsu.com> for providing the individual fixes. - Changelog : - Integrated Takashi's Makefile modification to clear Module.markers upon make clean. Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Cc: Roland McGrath <roland@redhat.com> Cc: Wenji Huang <wenji.huang@oracle.com> Cc: Takashi Nishiie <t-nishiie@np.css.fujitsu.com> Signed-off-by:
-
H. Peter Anvin authored
Commit 3bf2e774 upstream x86, suspend, acpi: enter Big Real Mode The explanation for recent video BIOS suspend quirk failures is that the VESA BIOS expects to be entered in Big Real Mode (*.limit = 0xffffffff) instead of ordinary Real Mode (*.limit = 0xffff). This patch changes the segment descriptors to Big Real Mode instead. The segment descriptor registers (what Intel calls "segment cache") is always active. The only thing that changes based on CR0.PE is how it is *loaded* and the interpretation of the CS flags. The segment descriptor registers contain of the following sub-registers: selector (the "visible" part), base, limit and flags. In protected mode or long mode, they are loaded from descriptors (or fs.base or gs.base can be manipulated directly in long mode.) In real mode, the only thing changed by a segment register load is the selector and the base, where the base <- selector << 4. In particular, *the limit and the flags are not changed*. As far as the handling of the CS flags: a code segment cannot be writable in protected mode, whereas it is "just another segment" in real mode, so there is some kind of quirk that kicks in for this when CR0.PE <- 0. I'm not sure if this is accomplished by actually changing the cs.flags register or just changing the interpretation; it might be something that is CPU-specific. In particular, the Transmeta CPUs had an explicit "CS is writable if you're in real mode" override, so even if you had loaded CS with an execute-only segment it'd be writable (but not readable!) on return to real mode. I'm not at all sure if that is how other CPUs behave. Signed-off-by:
"H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
-
Oliver Neukum authored
commit 62ad296b upstream usb serial decrements the pm counter even if an interface has been disconnected. If it was a logical disconnect the interface may belong already to another driver. This patch introduces a check for disconnected interfaces. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Ingo Molnar authored
commit fab3b58d upstream as reported in: "reboot=bios is mandatory on Dell T5400 server." http://bugzilla.kernel.org/show_bug.cgi?id=11108 add a DMI reboot quirk. Signed-off-by:
-
Herton Ronaldo Krzesinski authored
commit 723edb50 upstream Fallout from commit 33185c50 ("x86: merge signal_32/64.h") Thanks to Dick Streefland who provided an useful testcase on http://lkml.org/lkml/2008/3/17/205 (only applicable to 2.6.24.x), that helped a lot as a deterministic way to bisect an issue that leaded to this fix. Signed-off-by:
Herton Ronaldo Krzesinski <herton@mandriva.com.br> Signed-off-by:
Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br> Cc: Roland McGrath <roland@redhat.com> Signed-off-by:
-
Paul E. McKenney authored
commit d7c06513 upstream The comment was correct -- need to make the code match the comment. Without this patch, if a CPU goes dynticks idle (and stays there forever) in just the right phase of preemptible-RCU grace-period processing, grace periods stall. The offending sequence of events (courtesy of Promela/spin, at least after I got the liveness criterion coded correctly...) is as follows: o CPU 0 is in dynticks-idle mode. Its dynticks_progress_counter is (say) 10. o CPU 0 takes an interrupt, so rcu_irq_enter() increments CPU 0's dynticks_progress_counter to 11. o CPU 1 is doing RCU grace-period processing in rcu_try_flip_idle(), sees rcu_pending(), so invokes dyntick_save_progress_counter(), which in turn takes a snapshot of CPU 0's dynticks_progress_counter into CPU 0's rcu_dyntick_snapshot -- now set to 11. CPU 1 then updates the RCU grace-period state to rcu_try_flip_waitack(). o CPU 0 returns from its interrupt, so rcu_irq_exit() increments CPU 0's dynticks_progress_counter to 12. o CPU 1 later invokes rcu_try_flip_waitack(), which notices that CPU 0 has not yet responded, and hence in turn invokes rcu_try_flip_waitack_needed(). This function examines the state of CPU 0's dynticks_progress_counter and rcu_dyntick_snapshot variables, which it copies to curr (== 12) and snap (== 11), respectively. Because curr!=snap, the first condition fails. Because curr-snap is only 1 and snap is odd, the second condition fails. rcu_try_flip_waitack_needed() therefore incorrectly concludes that it must wait for CPU 0 to explicitly acknowledge the counter flip. o CPU 0 remains forever in dynticks-idle mode, never taking any more hardware interrupts or any NMIs, and never running any more tasks. (Of course, -something- will usually eventually happen, which might be why we haven't seen this one in the wild. Still should be fixed!) Therefore the grace period never ends. Fix is to make the code match the comment, as shown below. With this fix, the above scenario would be satisfied with curr being even, and allow the grace period to proceed. Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Josh Triplett <josh@kernel.org> Cc: Dipankar Sarma <dipankar@in.ibm.com> Signed-off-by:
-
