- 26 Oct, 2003 11 commits
-
-
Andi Kleen authored
-
John Levon authored
-
David S. Miller authored
into nuts.ninka.net:/disk1/davem/BK/net-2.5
-
Linus Torvalds authored
Use this to simplify 'finish_task_switch', but perhaps more importantly we can use this to track down why some processes seem to sometimes not die properly even after having been marked as ZOMBIE. The "task->state" flags are too fluid to allow that well.
-
Randolph Chung authored
This fixes the generic __div64_32() to correctly handle divisions by large 32-bit values (as used by nanosleep() and friends, for example). It's a simple bit-at-a-time implementation with a reduction of the high 32-bits handled manually. Architectures that can do 64/32-bit divisions in hardware should implement their own more efficient versions.
-
Yoshinori Sato authored
- add 'sched_clock' - delete smplock.h
-
Andi Kleen authored
The most important part is that it makes x86-64 compile again. Without that 2.6 users won't be very happy. It also works around a bug that allowed every user program to reboot the system on B stepping K8. Also update to match some recent i386 fixes. Full ChangeLog: - Add acpi_pic_set_level_irq to make ACPI compile again - Work around compat mode K8 bug in IRET exception handling - Increase exception stack. The old 1k stack was too easy to overflow (from Jim Paradis, changed by me) - Replace safe_smp_processor_id with cpuid (needed for above) - When there is only one node always enable fake_node mode - Merge with i386 (NTP gettimeofday monoticity fix, irq nr_vectors change) - Fix compile problem for UP kernels in time/cpufreq - Set all nodes online at bootup - Define node_to_cpumask correctly
-
Stelian Pop authored
This documents the existence of a forth 'motioneye' camera plugged into the USB bus, of course unsupported by the meye driver.
-
Stelian Pop authored
This corrects the Zoom and Thumbphrase button events.
-
Andries E. Brouwer authored
The first FAT entry should have the media byte (0xf0,0xf8,...,0xff) extended with all 1 bits in the first FAT entry. Checking this is a good idea, it prevents us from mounting garbage as FAT - there is no good magic for FAT. Unfortunately, Windows does not enforce this, and 2.4 doesn't either. It turns out that there are filesystems around (two reports so far) that have a zero first FAT entry, and work under Windows and 2.4 but fail to mount under 2.6. So, this weakens the test.
-
Andries E. Brouwer authored
The 0xfa code can be a key scancode or it can be a protocol scancode. Only few keyboards use it as a key scancode, and if we always interpret it as a protocol scancode then these rare keyboards will have a dead key. If we interpret it as a key scancode then we have a dead keyboard in case it was protocol. Clearly it is safer to prefer to interpret it as a protocol scancode. This moves the test for ACK and NAK up, so that they are always seen as protocol. This is just a minimal patch. What I did in 1.1.54 was to keep track of commands sent with a flag reply_expected, so that 0xfa could be taken as ACK when a reply is expected and as key scancode otherwise. That is the better solution, but requires larger surgery.
-
- 25 Oct, 2003 2 commits
-
-
Linus Torvalds authored
-
http://lia64.bkbits.net/to-linus-2.5Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
- 24 Oct, 2003 6 commits
-
-
David S. Miller authored
-
David Mosberger authored
-
David S. Miller authored
into nuts.ninka.net:/disk1/davem/BK/net-2.5
-
David S. Miller authored
-
Andi Kleen authored
-
bk://bk.arm.linux.org.uk/linux-2.6-rmkLinus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
- 25 Oct, 2003 1 commit
-
-
Russell King authored
-
- 24 Oct, 2003 5 commits
-
-
Knut Petersen authored
This is a bugfix for setkeycode() in /drivers/char/keyboard.c. If we change a keycode the corresponding bit should be cleared if and only if this keycode is not defined any longer. I believe that this also was intended with the original code, but the implementation is faulty. First off all the first three changed lines are obviously erroneus: oldkey == truekey is false or true, you do not need to inclose this in a for(). I believe the author intended INPUT_KEYCODE(dev,i) == oldkey. But fixing this alone is not enough. If somebody wants to interchange the definition of two keys A and B, the normal way is to use two setkeycode calls: setkeycode (scancode A, keycode B); setkeycode (scancode B, keycode A); The old code does a clearbit(oldkey ..) call even in situations where two keys have the same definition, and this situation arises commonly in the situation mentioned above. Both errors are fixed with this patch.
-
Knut Petersen authored
If somebody uses keyboard scancode set 3 it is necessary to explicitly program the keyboard to send make/break codes for all keys and to set autorepeat for all keys. This is critical for some people. One example is the LK461/46W series of keyboards from Digital Equipment Corporations. These are VMS keyboards that are also usable on a normal PC. These keyboards support Scancode Set 2, but for some keys this support is screwed up -- some function keys (e.g. F18/F20) report the same scancode sequence combined with both alt and shift keys. Scancode Set 3 works perfectly if all keys are programmed to give make/break codes. A lot of keyboards manufactured by Cherry only make/break for some (not all!) modifyer keys in scancode set 3 without this fix.
-
bk://kernel.bkbits.net/gregkh/linux/usb-2.6Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
bk://kernel.bkbits.net/davem/sparc-2.5Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
Linus Torvalds authored
This fixes resource conflicts due to IO decode that doesn't show up with a normal PCI probe (we do similar quirks for most other chipsets). Without it, the kernel doesn't know about some magic IO decodes for the chips.
-
- 23 Oct, 2003 15 commits
-
-
Kazunori Miyazawa authored
-
Herbert Xu authored
-
Hideaki Yoshifuji authored
-
Stephen Hemminger authored
-
Alexey Kuznetsov authored
-
David S. Miller authored
into nuts.ninka.net:/disk1/davem/BK/sparc-2.5
-
David S. Miller authored
-
David Brownell authored
This resolves a bug that was recently reported to me by someone enumerating a USB 1.1 modem through a high speed hub. I'm a bit surprised we never saw it before; I think cache/dma timings must usually be strongly in our favor. The problem was that the HC was still using the old ep0 maxpacket value, so when it received an 18 byte device descriptor it would report a packet overrun and enumeration would fail. The fix is straightforward: invalidate the HC's old endpoint state when we change the full speed maxpacket size. (And eventually, we can remove EHCI and OHCI code coping with usbcore not doing this.)
-
Stéphane Eranian authored
This patch fixes the following issues: - fix a nasty corner case by which a task could inherit psr.pp/psr.up that could be stale by the time it runs. psr.pp/psr.up bits must be cleared on fork and inherited on execve(). Test case provided by John Levon. - mask interrupts when locking the pfm stat structure. We don't want to take PMU interrupts in the middle of this kind of critical section. - fix a bug in pfm_close() for context which use asynchronous notifications. You cannot call fasync_helper() with interrupts disabled because it reenables them. There was no real danger of moving the call outside our critical section. - fix a bug in in pfm_flush_pmds() where you can leave the freeze bit set in the pmc saved state. - updated dump_pmu_state() - cleanup the BUG_ON() usage
-
Arun Sharma authored
his seems to be broken for ia32 on ia64 and possibly other emulation architectures as well. The problem comes from fs/namei.c:set_fs_altroot() using path_lookup() instead of a path_walk() relative to "/" (which is the case for 2.4).
-
Greg Kroah-Hartman authored
into kroah.com:/home/greg/linux/BK/usb-2.6
-
David Brownell authored
This fixes a problem that showed in usb-storage (osdl bugme 1310) and could have shown in other drivers that used usb_reset_device() when they already held dev->serialize: a self-deadlock with some devices. There are some drivers that should likely change so that they grab this lock themselves, since they don't call this during probe() when the lock is already held. The lock protects against config changes by other tasks, which is currently quite rate.
-
Alan Stern authored
An earlier patch caused trouble because it effectively removed the US_FL_FIX_INQUIRY flag for devices with release number higher than 0x5009. This one might cause problems because it explicitly goes against the immediately preceding comment in unusual_devs.h. That comment says that these Casio digital cameras claim to use the CBI transport when in fact they only use CB. However, there have been two reports in the last few weeks from people getting the "unneeded SubClass and Protocol" log messages. One of them was using a device with release number 0x1000, right at the start of the range. The other had a device with release number 0x5010, just beyond the end of the current range. Maybe Casio is marketing two different devices with different behaviors but having the same Vendor, Product, and Release values -- I don't know.
-
Carsten Busse authored
its for the Jenoptik JD 5200 z3 Digicam, to enable it to work as a simple storage device more or less i took the values for the 0x0d96 vendor in the 2.6.0-test7 usb-storage and mixed them with my device id, which seems to work quite well tested with 2.4.22 kernel
-
Ian Abbott authored
Patch by me (Ian Abbott). Removed aliases of FTDI_VID define for consistency. Renamed FTDI_PERLE_PID to FTDI_PERLE_ULTRAPORT_PID. Removed Matrix Orbital and Perle Systems devices from the 8U232AM device table (but left them in the FT232BM device table) as they are known to be FT232BM devices.
-