- Nov 18, 2005
-
-
Matthew Wilcox authored
These drivers do not compile on big endian systems, and parisc is big endian. Also mark some as broken on m68k as well. Signed-off-by:
Matthew Wilcox <willy@parisc-linux.org> Signed-off-by:
Kyle McMartin <kyle@parisc-linux.org>
-
Matthew Wilcox authored
Mention PA-RISC in NS87415 help. PA-RISC [BCJ]xxx0 workstations come with NS87415 integrated for their CD-ROM drives. Signed-off-by:
-
Matthew Wilcox authored
Depend on GSC, not PARISC. Machines without GSC don't have a MUX. Signed-off-by:
-
Matthew Wilcox authored
Fix compile warning caused by conflicting types of expand_upwards. IA64 requires it to not be static inline, as it's used outside mm/mmap.c Signed-off-by:
-
- Nov 17, 2005
-
-
Kyle McMartin authored
Convert superio_init to use PCI_FIXUP_FINAL as ohci_pci being called before superio_probe really makes a mess. superio_init will then fail to register irq 20 (the "SuperIO" irq) and BUG() because ohci_pci has stolen it before superio_fixup_irq can be moved USB to irq 1. Signed-off-by: -
Matthew Wilcox authored
Since taking a spinlock disables preempt, and we need to spinlock tlb flush on SMP for N class, we might as well just spinlock on uniprocessor machines too. Signed-off-by:
-
Grant Grundler authored
Remove unused variable "struct siginfo si" in signal.c Signed-off-by:
Grant Grundler <grundler@parisc-linux.org> Signed-off-by:
-
Christoph Hellwig authored
Remove drm compat_ioctl handlers. The drm drivers have proper compat_ioctl methods these days. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Christoph Hellwig authored
Move PA perf driver over to ->compat_ioctl. Signed-off-by:
Randolph Chung <tausq@parisc-linux.org> Signed-off-by:
-
Ryan Bradetich authored
This commit is in response to a bug reported by Vesa on the irc channel a couple of weeks ago. The bug was that the console would apparently hang (not return) while using the mux console. The root cause of this bug is that bash (with readline support) makes a call to the tcsetattr() glibc function with the argument TCSADRAIN. This causes the serial core in the kernel use the uart_wait_until_sent() to be called. This function verifies the mux transmit queue is empty or calls the msleep_interruptable() with a calculated timeout value that is dependant upon the port->timeout variable. The real problem here is that the port->timeout was not defined so it was defaulted to 0 and the timeout calculation performs the following calculation: char_time = (port->timeout - HZ/50) / port->fifosize; where char_time is an unsigned long. Since the serial Mux does not use interrupts, the msleep_interruptable() function waits until the timeout has been reached ... and when the port->timeout < HZ/50 this timeout will be a long time. (I have validated that the console will eventually return ... but it takes quite a while for this to happen). This patch simply sets the port->timeout on the Mux to HZ/50 to avoid this long timeout period. Signed-off-by:
Ryan Bradetich <rbrad@parisc-linux.org> Signed-off-by:
-
Matthew Wilcox authored
Fix some compile problems: - ret wasn't being initialised in all code paths - I'm pretty sure 'goto out' should have been 'goto out_tsk' Signed-off-by:
-
Ryan Bradetich authored
This patch does the following: * Fixes compiler warnings. * Replaces a __raw_readl call with the existing macro. Signed-off-by:
-
James Bottomley authored
We actually have two separate bad bugs 1. The read_lock implementation spins with disabled interrupts. This is completely wrong 2. Our spin_lock_irqsave should check to see if interrupts were enabled before the call and re-enable interrupts around the inner spin loop. The problem is that if we spin with interrupts off, we can't receive IPIs. This has resulted in a bug where SMP machines suddenly spit smp_call_function timeout messages and hang. The scenario I've caught is CPU0 does a flush_tlb_all holding the vmlist_lock for write. CPU1 tries a cat of /proc/meminfo which tries to acquire vmlist_lock for read CPU1 is now spinning with interrupts disabled CPU0 tries to execute a smp_call_function to flush the local tlb caches This is now a deadlock because CPU1 is spinning with interrupts disabled and can never receive the IPI Signed-off-by:James Bottomley <jejb@parisc-linux.org> Signed-off-by:
-
Matthew Wilcox authored
Improve the error message when we get a clashing mod path, and actually display the IODC data and path for the conflicting device. Signed-off-by:
-
Matthew Wilcox authored
Return PDC_OK when device registration fails so that we enumerate all subsequent devices, even when we get two devices with the same hardware path (which should never happen, but does with at least one revision of rp8400 firmware). Signed-off-by:
-
Carlos O'Donell authored
Document clobbers and args in entry.S and syscall.S. entry.S: Add comment to indicate that cr27 may recycle and EDEADLOCK detection is not 100% correct. Since this is only enabled when using ENABLE_LWS_DEBUG, the user is warned by the comment. Signed-off-by:
Carlos O'Donell <carlos@parisc-linux.org> Signed-off-by:
-
Ryan Bradetich authored
Make the "redirecting irq" message to not display on the console by setting the severity to KERN_DEBUG. The console was basically unusable. Signed-off-by:
-
Grant Grundler authored
irq_affinityp[] only available for SMP builds, make code that uses it conditional on CONFIG_SMP. Signed-off-by:
-
James Bottomley authored
This really only adds them for the machines I can check SMP on, which is CPU interrupts and IOSAPIC (so not any of the GSC based machines). With this patch, irqbalanced can be used to maintain irq balancing. Unfortunately, irqbalanced is a bit x86 centric, so it doesn't do an incredibly good job, but it does work. Signed-off-by:
-
Kyle McMartin authored
Since irq.c uses smp_send_all_nop, we must define it for UP builds as well. Make it a static inline so it gets optimized away. This forces irq.c to include <asm/smp.h> though. Signed-off-by: -
James Bottomley authored
Fix our interrupts not to use smp_call_function On K and D class smp, the generic code calls this under an irq spinlock, which causes the WARN_ON() message in smp_call_function() (and is also illegal because it could deadlock). The fix is to use a new scheme based on the IPI_NOP. Signed-off-by:
-
Grant Grundler authored
Disable nesting of interrupts - still has holes The offending sequence starts out like this: 1) take external interrupt 2) set_eiem() to only allow TIMER_IRQ; local interrupts still disabled 3) read the EIRR to get a "list" of pending interrupts 4) clear EIRR of pending interrupts we intend to handle 5) call __do_IRQ() to handle IRQ. 6) handle_IRQ_event() enables local interrupts (I-Bit) 7) take a timer interrupt 8) read EIRR to get a new list of pending interrupts 9) clear EIRR of pending interrupts we just read 10) handle pending interrupts found in (8) 11) set_eiem(cpu_eiem) and return [ TROUBLE! all enabled CPU IRQs are unmasked. } 12) handle remaining interrupts pending from (3) e.g. call __do_IRQ() -> handle_IRQ_event()..etc [ TROUBLE! call to handle_IRQ_event() can now enable *any* IRQ. } 13) set_eiem(cpu_eiem) and return The problem is we now get into ugly race conditions with Timer and IPI interrupts at this point. I'm not exactly sure what happens when things go wrong (perhaps nest calls to IPI or timer interrupt?). But I'm certain it's not good. This sequence will break sooner if (10) would accidentally leave interrupts enabled. I'm pretty sure the right answer is now to make cpu_eiem a per CPU variable since all external interrupts on parisc are per CPU. This means we will NOT need to send an IPI to every CPU in the system when enabling or disabling an IRQ since only one CPU needs to change it's EIEM. Thanks to James Bottomley for (once again) pointing out the problem. Signed-off-by: -
James Bottomley authored
Fix a longstanding smp bug The problem is that both the timer and ipi interrupts are being called with interrupts enabled, which isn't what anyone is expecting. The IPI issue has just started to show up by causing a BUG_ON in the slab debugging code. The timer issue never shows up because there's an eiem work around in our irq.c The fix is to label both these as SA_INTERRUPT which causes the generic irq code not to enable interrupts. I also suspect the smp_call_function timeouts we're seeing might be connected with the fact that we disable IPIs when handling any other type of interrupt. I've put a WARN_ON in the code for executing smp_call_function() with IPIs disabled. Signed-off-by:
-
Jens Axboe authored
We must reassign z before looping through the zones kicking kswapd, since it will be NULL if we hit an OOM condition and jump back to the beginning again. 'z' is initially assigned before the restart: label. So move the restart label up a little. Signed-off-by:Jens Axboe <axboe@suse.de>
-
Greg Kroah-Hartman authored
Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Greg Kroah-Hartman authored
It was causing too many problems, and this is not the proper type of driver for this device. Signed-off-by:
-
Greg Kroah-Hartman authored
This lets us remove a lot of code in the drivers that were all checking the same thing. It also found some bugs in a few of the drivers, which has been fixed up. Signed-off-by:
-
Richard Purdie authored
Fix an error in the OHCI lh7a404 driver after the platform device conversion. Signed-off-by:
Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Antti Andreimann authored
This small patch adds a device ID used by older Maxtor OneTouch drives (the ones with blue face-plate instead of the fancy silver one used in newer models). The button on those drives works well with the current driver. From: Antti Andreimann <Antti.Andreimann@mail.ee> Signed-off-by:
-
Andrew Morton authored
drivers/usb/core/devio.c: In function `proc_ioctl_compat': drivers/usb/core/devio.c:1401: warning: passing arg 1 of `compat_ptr' makes integer from pointer without a cast Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Herbert Xu authored
this patch from Herbert Xu fixes a race by moving termination of the URBs into close() exclusively. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Oliver Neukum <oliver@neukum.name> Signed-off-by:
-
Daniel Drake authored
Peter Favrholdt reported that his Kodak flash device was getting detected as a CDROM, and he helped me track this down to the fact that the device takes a long time (approx 440ms!) to reset. This patch increases the delay to 500ms, which solves the problem. Signed-off-by:
Daniel Drake <dsd@gentoo.org> Signed-off-by:
-
Oliver Neukum authored
the scsi layer now uses very short sg lists. This breaks the microtek driver. Here is a patch fixes this and some other issues. Signed-off-by:
-
Luiz Fernando Capitulino authored
Updates pl2303_update_line_status() to handle X75 and SX1 Siemens mobiles Signed-off-by:
Luiz Capitulino <lcapitulino@mandriva.com.br> Signed-off-by:
-
Luiz Fernando Capitulino authored
This patch adds two new Siemens mobiles IDs for the pl2303 driver. Signed-off-by:
-
David Brownell authored
The onetouch support doesn't suspend correctly (leaves an interrupt URB posted, instead of unlinking it) so for now just disable it when PM is in the air. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Josef Balatka authored
Jablotron usb serial interface identification Signed-off-by:
Josef Balatka <balatka@email.cz> Signed-off-by:
-
Pavel Machek authored
I actually have this device, and kernel reports blacklist entry is no longer neccessary. Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
-
Andrew Morton authored
drivers/usb/core/devio.c: In function `proc_ioctl_compat': drivers/usb/core/devio.c:1401: warning: passing arg 1 of `compat_ptr' makes integer from pointer without a cast NFI if this is correct... Cc: Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
OGAWA Hirofumi authored
Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
