ChangeSet@1.1546, 2005-01-06 10:51:33-02:00, mbellon@mvista.com [PATCH] 32 bit ltrace oops when tracing 64 bit executable [X86_64] Didn't see a fix for this so here it is. Tried using "ltrace -i" on a 64 bit executable when ltrace was a 32 bit executable. The kernel threw an oops. The find_target routine (arch/x86/ia32/ptrace32.c) doesn't deal with a NULL return from find_task_by_pid properly - if NULL is returned put_task_struct() is still called. ChangeSet@1.1545, 2005-01-06 08:57:01-02:00, solar@openwall.com [PATCH] Check for zero program header on load_elf_interp() ChangeSet@1.1544, 2005-01-06 06:16:31-02:00, penguin@muskoka.com [PATCH] 8390 Tx fix for non i386 Recently spotted on bugzilla for 2.6. A missing E8390_CMD constant has no effect on i386 since it is zero, but some other arch. use Alan's register mapping (mac8390, etc) which may have non-zero E8390_CMD. Paul. ChangeSet@1.1543, 2005-01-05 07:06:02-02:00, zaitcev@redhat.com [PATCH] USB: Add user defined IDs to ftdi This should be self-evident. Patch by Rogier Wolff. ChangeSet@1.1542, 2005-01-04 19:02:18-02:00, khali@linux-fr.org [PATCH] I2C: Cleanup a couple media/video drivers Hi Marcelo, hi all, Two media/video drivers in 2.4 have a compatibility trick to make them work when the kernel tree is patched with i2c 2.8.x. The trick also allowed to share the same code between Linux 2.4 and 2.5/2.6. Unfortunately, the trick relies on one define (I2C_PEC) to define (or not) structure members that are not related with that define at all. That define was picked just because it happened to be present in i2c 2.8.x and the 2.5/2.6 kernel trees, but not in the (unpatched) 2.4 kernel tree. Basically, the trick was to switch to the new structure members (found in i2c 2.8.x and the 2.5/2.6 kernels) if I2C_PEC was defined. The problem now is that i2c 2.9.0, which was just released, has stepped back on the changes that had made i2c 2.8.x uncompatible with the 2.4 kernels, to the great joy of i2c/lm_sensors distro packagers and i2c patch maintainer (i.e. me). Because i2c 2.9.0 still defines I2C_PEC but uses the old structure members, the trick doesn't work anymore. (No surprise, that's what happens when you rely on something to take an unrelated decision just because it seems to work at some point.) Since the 2.8.x series of i2c is now considered deprecated and unsupported, the easiest way to get things back in order is to get rid of the trick altogether. This will make i2c 2.9.0 work while breaking i2c 2.8.x, which is OK. The affected drivers are bttv-if and tvmixer. I asked Gerd and he told me he had no objection to the cleanups I propose. Note that both the trick and its removal only have an effect when patching the kernel tree with i2c 2.8.0 or later. This means that the proposed change is necessarily safe for vanilla kernel users. Patch follows, please apply. The patch is also available online at: http://khali.linux-fr.org/devel/i2c/linux-2.4.28/linux-2.4.28-i2c-2.9.0-drivers-media-video.diff Thanks. Signed-off-by: Jean Delvare ChangeSet@1.1527.3.6, 2004-12-27 15:51:46-05:00, stkn@gentoo.org [libata] add #include (fixes 2.4 alpha build) ChangeSet@1.1527.3.5, 2004-12-27 15:51:34-05:00, albertcc@tw.ibm.com [libata] verify ATAPI DMA for a given request is OK After some testing, it seems that some PATA host adapter (ex. pdc20275) cannot work reliably with specific request buffer sizes under ATAPI DMA mode. Detailed test result: 4096, 2048, 1024, 512, 256: OK 384, 257, 255, 128, 96, 64, 32: failed (irq lost) It seems multiple of 256 bytes are the safe ATAPI DMA buffer sizes to use. Attached please find the patch to fix the pdc2027x ATAPI DMA problem. Changes: 1. Add a callback function "check_atapi_dma()" to ata_port_operations such that libata core can ask the driver: "Can this command be processed in ATAPI DMA mode safely? " when the the command is received. 2. ATAPI DMA is off by default if the callback function is not provided by the driver If the callback function is not provided by the driver, the ATAPI DMA should be as is. The ATAPI DMA is already controlled by dev->flags. BTW, the patch isolates the ATAPI DMA workaround to the pdc20275 driver itself, not impacting libata core . Signed-off-by: Albert Lee ChangeSet@1.1527.3.4, 2004-12-27 15:51:04-05:00, albertcc@tw.ibm.com [libata] PIO error handling improvement Tested burning CD-RW with libata-dev-2.6 and cdrecord: 1. ATAPI DMA mode - tested OK 2. ATAPI PIO mode - test failed when cdrecord finishes burning and issues MODE_SELECT to the device. After checking the log, it showed that MODE_SELECT caused ata_pio_complete() to return error. However, the error is not handled by ata_pio_task(). Attached please find the patch for ata_pio_task() error handling for your review. Changes in the patch: 1. End the PIO task when PIO_ST_IDLE state is entered 2. End the PIO task after PIO_ST_TMOUT and PIO_ST_ERR state handled by ata_pio_error() 3. Remove the first "if" statement to handle the error condition returned from ata_pio_block(), ata_pio_complete() and ata_pio_poll(). Change #2 is not so necessary since ata_pio_error() will put the cmd to PIO_ST_IDLE state after the error condition is handled. The change just saves a function call to queue_work(). Tested OK on on my machine with pdc20275 and ASUS CD-RW drive. Signed-off-by: Albert Lee ChangeSet@1.1527.3.3, 2004-12-27 15:46:51-05:00, albertcc@tw.ibm.com [libata] use PIO mode for request sense Signed-off-by: Albert Lee ChangeSet@1.1527.3.2, 2004-12-27 15:45:49-05:00, jgarzik@pobox.com [libata sata_uli] add 5281 support, fix SATA phy setup for others Contributed by Peer Chen @ ULi and tested by a user. ChangeSet@1.1527.3.1, 2004-12-27 15:43:33-05:00, jgarzik@pobox.com [libata sata_nv] fix dev detect by removing sata-reset flag Remove ATA_FLAG_SATA_RESET. See comment in code and http://bugme.osdl.org/show_bug.cgi?id=3352 for more details. This problem needs more investigation. Removing the flag appears to fix the problems in the field, so it's the best temporary solution. ChangeSet@1.1540, 2004-12-27 13:02:06-02:00, a.pugachev@pcs-net.net [PATCH] drivers/net/appletalk/Config.in depends on CONFIG_ATALK This patch makes "Appletalk devices" subscreen menu dependant on CONFIG_ATALK ChangeSet@1.1539, 2004-12-27 13:00:25-02:00, mhw@wittsend.com [PATCH] Computone driver update Fixed jiffies math in ii2DelayTimer... Dumped some groady tracing code that hasn't been used (or tested) in years and was only a source of warning messages. PCI fixes submitted by Bjorn Helgaas Added calls to Add pci_enable_device()/pci_disable_device() per submitted patches. My thanks to Bjorn Helgaas . Yet another shot at the busy board timing window (use the poll timer). Because of this, the poll timer is always enabled... Cleaned up some comments on immediate interrupt mode (ppp code elsewhere has been fixed and the new busy board logic won't throw a hairball). ChangeSet@1.1538, 2004-12-23 21:33:57-02:00, paulus@samba.org [PATCH] PPC64 signal code cleanup This patch cleans up the signal handling for PPC64 in 2.4. There was some old code in there that was never used, and also the signal delivery code was saving some state in the thread_struct (in the saved_msr and saved_softe fields). That is of course bogus because the kernel doesn't actually know when the process exits the signal handler, and because signal handlers can be nested. This patch dispenses with the use of those thread_struct fields. It also fixes a possible race by using set_current_state (which has a barrier) rather than setting current->state directly, removes some unused code, removes some debug cruft, and fixes some compile warnings. Please apply. Signed-off-by: Paul Mackerras ChangeSet@1.1537, 2004-12-22 14:00:27-02:00, ak@suse.de [PATCH] [CAN-2004-1144] Fix int 0x80 hole in 2.4 x86-64 linux kernels Petr Vandrovec discovered an exploitable root hole on all 2.4 x86-64 kernels. The problem occurs because the eax register on the 32bit int 0x80 syscall handler is not properly 64bit zero extended, which can be used to overflow the system call table. The problem only occurs on 2.4 x86-64 kernels, 2.6 doesn't have this hole because some unrelated changes in 2.5 fixed it as a side effect. Marcelo should be releasing a new pre* kernel with this fix shortly, there should be also update kernel from the various linux distributions. It is recommended that everybody who runs a 2.4 x86-64 kernel with shell user access updates to a kernel which has this patch applied. Patch is for 2.4.29pre2, but should apply to pretty much any 2.4.x x86-64 kernel. -Andi TAG: v2.4.29-pre3