- 10 Jun, 2003 5 commits
-
-
Alan Stern authored
This patch makes the hub status irq DMA-aware, by pre-allocating the transfer buffer in consistent memory. Unfortunately, there doesn't seem to be an easy way to do the same for the status report buffers.
-
Matthew Dharm authored
This patch removes the code that faked the EVPD INQUIRY. The SCSI core no longer does that, so there is no need to filter it.
-
Matthew Dharm authored
This patch re-organizes probe and disconnect into smaller functions (which are all functionally equivalent to the current code). This allows easier verification that the code is correct, and will make for easier implementation of the proper SCSI shutdown code.
-
Matthew Dharm authored
This patch introduces some handling for babble conditions. Basically, once a babble is detected, we return sense data saying the command was invalid. We also go on to transfer the CSW (for BBB transport) so we stay in phase with the device. This isn't guaranteed to work with every device that babbles, but it can't hurt compared to the current behavior. Properly operating devices are unaffected by this patch.
-
Olaf Hering authored
-
- 06 Jun, 2003 29 commits
-
-
Petko Manolov authored
better error handling and ethtool ioctl() cleanup. HOME_PNA now should work (at least for the pegasus II based devices). one more vendor and device IDs.
-
Alan Stern authored
As requested by David Brownell, this patch removes the usb_ prefix from the static functions in hub.c. It also multiplies the timeouts for GET_STATUS and GET_DESCRIPTOR control transfers by USB_CTRL_GET_TIMEOUT.
-
Alan Stern authored
Allocate hub status input buffers separately and not on the stack.
-
Oliver Neukum authored
- kill useless variable
-
Joe Burks authored
I noticed a version of vicam.c a few revisions ago had all the /proc fs writing removed because I was incorrectly using potentially tainted user space pointers. Here's a patch which I think fixes the pointer issue and restores the /proc fs interface to vicam. If this fix is still problematic, please let me know and I'll fix whatever comes up.
-
http://linux-sound.bkbits.net/linux-soundLinus Torvalds authored
into home.transmeta.com:/home/torvalds/v2.5/linux
-
Jaroslav Kysela authored
- added AZT3328 driver - added Terratec Aureon support to ICE1724 driver - fixed possible PCI posting problems - ENS1370, ENS1371, FM801, ICE1712, ICE1724, VIA82xx - AC'97 code - added new IDs - fixed typo in S/PDIF code - C-Media related fixes - USB driver - added nrpacks module option - added hack for AudioTrak Optoplay - removed OLD_USB stuff
-
Linus Torvalds authored
-
Andrew Morton authored
The loop thread is getting permanently stuck in balance_dirty_pages() (nr_writeback is exceeded) because the loop thread itself is responsible for completing writeback on behalf of higher layers. So we need to take that out: don't throttle the loop thread. Throttle the tasks which are generating all the dirty data instead.
-
Andrew Morton authored
From: Matthew Dobson <colpatch@us.ibm.com> This resurrects the old /proc/sys/vm/free_pages functionality: the ability to tell page reclaim how much free memory to maintain. This may be needed for specialised networking applications, and it provides an interesting way to stress the kernel: set it very low so atomic allocations can easily fail. Also, a 16G ppc64 box currently cruises along at 1M free memory, which is surely too little to supporthigh-speed networking. We have not changed that setting here, but it is now possible to do so. The patch also reduces the amount of free memory which the VM will maintain in ZONE_HIGHMEM, as it is almost always wasted memory.
-
Andrew Morton authored
From: Dave Olien <dmo@osdl.org> The change makes the transfer rate numbers come out right for the fibre channel version of this controller. For 1G FC, the NegotiatedSynchronousMegaTransfers is 1000, and the NegotiatedDataWidthBIts is 1. The old code assumed NegotiatedDataWidthBits was always either 8 or 16. The new code is simpler, and does the calculation correctly for all cases.
-
Andrew Morton authored
From: Matthew Dobson <colpatch@us.ibm.com> This patch implements a generic version of the nr_cpus_node(node) macro implemented for ppc64 by the previous patch. The generic version simply computes an hweight of the bitmask returned by node_to_cpumask(node) topology macro. This patch also adds a generic_hweight64() function and an hweight_long() function which are used as helpers for the generic nr_cpus_node() macro. This patch also adds a for_each_node_with_cpus() macro, which is used in sched_best_cpu() in kernel/sched.c to fix the original problem of scheduling processes on CPU-less nodes. This macro should also be used in the future to avoid similar problems. Test compiled and booted by Andrew Theurer (habanero@us.ibm.com) on both x440 and ppc64.
-
Andrew Morton authored
From: Matthew Dobson <colpatch@us.ibm.com> This patch defines a topology macro for ppc64, nr_cpus_node(node) which returns the number of CPUs on 'node'. This patch also adds code to compute and store these values in an array for quick lookup. Test compiled and booted by Andrew Theurer (habanero@us.ibm.com) on both x440 and ppc64.
-
Andrew Morton authored
From: Matthew Dobson <colpatch@us.ibm.com> sched_best_cpu schedules processes on nodes based on node_nr_running. For CPU-less nodes, this is always 0, and thus sched_best_cpu tends to migrate tasks to these nodes, which eventually get remigrated elsewhere. This patch adds include/linux/topology.h, and modifies all includes of asm/topology.h to linux/topology.h. A subsequent patch in this series adds helper functions to linux/topology.h to ensure processes are only migrated to nodes with CPUs. Test compiled and booted by Andrew Theurer (habanero@us.ibm.com) on both x440 and ppc64.
-
Andrew Morton authored
From: Ingo Molnar <mingo@elte.hu> Apparently this BUG is triggerable due to correct and expected events.
-
Andrew Morton authored
As "Dmitry A. Fedorov" <D.A.Fedorov@inp.nsk.su> points out, get_current_user() has a local variable __user which conflicts with the sparse tagging. But get_current_user() has no callers.
-
Andrew Morton authored
From: Adam Belay <ambx1@neo.rr.com> - cs4236 doesn't check if the memory for the resource table was successfully allocated.
-
Andrew Morton authored
- Add comment about slab ctor behaviour (Ingo Oeser) - mm/slab.c:fprob() shows up in profiles a lot. Rename it to something more meaningful. - fatfs printk warning fix (Randy Dunlap) - give the the time interpolator list and lock file-static scope (hch)
-
Andrew Morton authored
From: Christoph Hellwig <hch@lst.de> Currently the tty code abuses tty_driver.name as the prefix for the devfs names of the ttys. This is a very bad idea because it means the tty name changes depending on whether devfs is enabled or not, leading to different names in /proc/tty/ depending on whether we have devfs or not (and not whether it actually is mounted!) and a huge amount of ifdefs. The patch below adds a .devfs_name member instead, similar to the block device changes a few weeks ago.
-
Andrew Morton authored
From: Samuel Thibault <Samuel.Thibault@ens-lyon.fr> Still working on kernel facilities for braille devices, the need for being able to force blanking and unblanking raised: even when a key is pressed, the screen must remain blank, for privacy of the blind user who is typing on the keyboard and reading on its braille terminal. I merely added an ignore_poke variable which is set, and the screen blanked. Then, poke_blanked_console returns immediatly. Upon real unblank (because of an Oops or an explicit tioclinux), ignore_poke is reset to get back to normal operation mode. I had to remove the (unnecessary ?) call to unblank_screen from set_selection to prevent mouse selection unblanking the screen. I also added a way for processes to know whether the screen is blanked (the blind user might hence know whether people can read the screen).
-
Andrew Morton authored
From: Samuel Thibault <Samuel.Thibault@ens-lyon.fr> Some fixes for console blanking: on some laptops, doing VESA blanking after the bios did an apm blanking because of a screen closure thrashes the recovery (the video board doesn't seem to have synchronisation registers correctly initialized, since the LCD panel progressively turns white, maybe damaging it ?). I hence moved the schedule for vesa powerdown after the apm blank hook call, so that if it succeeds, it won't be called. I also moved the apm unblank & palette restoration after the vesa unblank, to have a more lifo scheme (also required, or the screen remains black). Btw, why del_timer_sync was called twice in timer_do_blank_screen when vesa_off_interval==0 ?
-
Andrew Morton authored
From: john stultz <johnstul@us.ibm.com> Since jiffies didn't necessarily start incrementing at a second boundary, jiffies/HZ doesn't increment at the same moment as xtime.tv_sec. This causes one second wobbles in the calculation of btime (xtime.tv_sec - jiffies/HZ). This fix increases the precision of the calculation so the usec component of xtime is used as well. Additionally it fixes some of the non-atomic reading of time values.
-
Andrew Morton authored
From: David Mosberger <davidm@napali.hpl.hp.com>, Christoph Hellwig I believe this is the last outstanding piece that prevents ia64 from being fully in sync with Linus' tree (yes, there are some minor ACPI changes outstanding and a toolchain bug that's left to fix, but other than that, I think we're clean). Many architectures (alpha, ia64, ppc, ppc64, sparc, and sparc64 at least) use a syscall convention which provides for a return value and a separate error flag. On those architectures, it can be beneficial if the kernel provides a mechanism to signal that a syscall call has completed successfully, even when the returned value is potentially a (small) negative number. The patch below provides a hook for such a mechanism via a macro called force_successful_syscall_return(). On x86, this would be simply a no-op (because on x86, user-level has to be hacked to handle such cases). On Alpha, it would be something along the lines of: #define force_successful_syscall_return() ptregs->r0 = 0 where "ptregs" is a pointer to the user's ptregs structure of the current task. On ia64, we have been using this for a long time: static inline void force_successful_syscall_return (void) { ia64_task_regs(current)->r8 = 0; } The other architectures (ppc, ppc64, sparc, and sparc64) currently have no mechanism to force a syscall return to be successful. But since the syscall convention already provide for a separate error flag, the arch maintainers could change this if they wanted to. There are only 3 places in the platform-independent portion of the kernel that need this macro: - memory_lseek() in drivers/char/mem.c - fs/fcntl.c for F_GETOWN - lseek for /proc/mem in fs/proc/array.c Ideally, there are a couple of other places that could benefit from this macro: - sys_getpriority() - sys_shmat() - sys_brk() - do_mmap2() - do_mremap() but these are not so critical, because the can be worked around in platform-specific code (e.g., see arch/ia64/kernel/sys_ia64.c). Note that for the above 3 cases, handling them in user level is rather suboptimal: - it would affect all lseek() syscalls, even though only /proc/mem and /dev/mem need the special treatment (at least until there are filesystems that can handle files >= 2^63 bytes) - all fcntl() calls would be affected, even though only F_GETOWN needs the special treatment so I think handling these in the kernel for the platforms that can makes tons of sense. The only limitation of force_successful_syscall_return() is that it doesn't help with system calls performed by the kernel. But the kernel does that so rarely and for such a limited set of syscalls that this is not a real problem.
-
Andrew Morton authored
The addition of more fields to irq_desc_t may have broken compilation of other architectures. Go through and C99ify them (was needed anyway).
-
Andrew Morton authored
Attempt to do something intelligent with IRQ handlers which don't return IRQ_HANDLED. - If they return neither IRQ_HANDLED nor IRQ_NONE, complain. - If they return IRQ_NONE more than 99900 times in 100000 interrupts, complain and disable the IRQ. I did have it at 750-in-1000, but someone had an otherwise-functioning system which triggered it. The 99.9% ratio is designed to address the problem wherein the babbling device shares an IRQ with a good device. We don't want the good device's trickle of IRQ_HANDLED callouts to defeat the lockup detector. (fat chance os this working right). - Add a kernel boot parameter `noirqdebug' to turn the whole thing off.
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> OK, this does the *minimum* required to support DEFINE_PER_CPU inside modules. If we decide to change kmalloc_percpu later, great, we can turf this out. Basically, overallocates the amount of per-cpu data at boot to at least PERCPU_ENOUGH_ROOM if CONFIG_MODULES=y (arch-specific by default 32k: I have only 7744 bytes of percpu data in my kernel here, so makes sense), and a special allocator in module.c dishes it out.
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> Several tweaks to the kmalloc_percpu()/kfree_percpu() interface, to allow future implementations to be more flexible, and make easier to use now we can see how it's actually being used. 1) No flags argument: GFP_ATOMIC doesn't make much sense, 2) Explicit alignment argument, so we don't have to give SMP_CACHE_BYTES alignment always, 3) Zeros memory, since most callers want that and it's not entirely trivial, 4) Convenient type-safe wrapper which takes a typename, and 5) Rename to alloc_percpu/__alloc_percpu, since usage no longer matches kmalloc.
-
Roman Zippel authored
This fixes a problem which can show up with the new select facility, e.g. a symbol is forced to 'y', so we should never even try to change such symbols.
-
Roman Zippel authored
This is an important fix to allow changing boolean symbols, whose dependency is 'm'. All internal symbol states must be converted from the tristate into boolean the state. I missed this change while adding expression support for defaults, please apply.
-
- 05 Jun, 2003 6 commits
-
-
Jeff Garzik authored
into redhat.com:/garz/repo/net-drivers-2.5
-
Hideaki Yoshifuji authored
-
Scott Feldman authored
dev_ioctl already checks capable(CAP_NET_ADMIN) for SOICETHTOOL, so privileged reference are not necessary.
-
Scott Feldman authored
Add 10GbE support for ethtool.
-
Zwane Mwaikambo authored
This one should be safe as we're protected by the xmit_lock in all instances
-
Jeff Garzik authored
-