Ok. This is it. We (Andrew and me) are going to start a "pre-2.6" series, where getting patches in is going to be a lot harder. This is the last 2.5.x kernel, so take note. The probably most notable thing here is the anticipatory scheduler, which has been in -mm for a long time, and was the major piece that hadn't been merged. Some architecture updates: cris has been updated for 2.5, ia64 and arm26 updates etc. And various random (smallish) things. Linus ----- Summary of changes from v2.5.74 to v2.5.75 ============================================ Adam Belay: o [PNP] Handle Disabled Resources Properly o [PNP] Allow resource auto config to assign disabled resources o [PNP] Fix manual resource setting API Alex Williamson: o ia64: turn off ALLOW_IOV_BYPASS Alexey Kuznetsov: o [TCP]: Delete obsolete comment Andrew Morton: o move_vma() make_pages_present() fix o page unmapping debug o NUMA memory reporting fix o ramfs: use rgeneric_file_llseek o inode_change_ok(): remove lock_kernel() o nommu vmtruncate: remove lock_kernel() o procfs: remove some unneeded lock_kernel()s o remove lock_kernel() from file_ops.flush() o block_llseek(): remove lock_kernel() o Make CONFIG_TC35815 depend on CONFIG_TOSHIBA_JMR3927 o Report detached thread exit to the debugger o timer renaming and cleanups o fix lost_tick detector for speedstep o fix lost-tick compensation corner-case o cleanup and generalise lowmem_page_address o Security hook for vm_enough_memory o ext2: inode allocation race fix o fix double mmdrop() on exec path o ext3: fix journal_release_buffer() race o Set limits on CONFIG_LOG_BUF_SHIFT o Fix cciss hang o e100 use-after-free fix o PCI domain scanning fix o ipc semaphore optimization o bring back the batch_requests function o Create `kblockd' workqueue o elv_may_queue() API function o elevator completion API o anticipatory I/O scheduler o Use kblockd for running request queues o per queue nr_requests o blk_congestion_wait threshold cleanup o allow the IO scheduler to pass an allocation hint to o handle OOM in get_request_wait() o block batching fairness o generic io contexts o block request batching o get_io_context fixes o block allocation comments o after exec_mmap(), exec cannot fail o bootmem.c cleanups o epoll: microoptimisations o fix current->user->__count leak o MTD build fix for old gcc's o fix rfcomm oops o i2o_scsi build fix o Improve mmap readaround o use task_cpu() not ->thread_info->cpu in sched.c o misc fixes o breadahead() tweaks o proc_attr_lookup() fix o xattr: cleanups o xattr: blockdev inode selection fix o xattr: update-in-place optimisation o xattrr: preparation for fine-grained locking o xattr: fine-grained locking o Module autoloading for quota o display bootserver in /proc/net/pnp o BSD accounting speedup Anton Blanchard: o enable device mapper in compat layer Arun Sharma: o ia64: IA-32 support patch: msgsnd/msgrcv return value off by 4 o ia64: IA-32 support patch: munmap should return EINVAL if size == 0 o ia64: IA-32 support patch: mmap should return ENOMEM Ben Collins: o [SPARC64]: Fix formatting and typos in boot Makefile o [SPARC64]: Enable KALLSYMS, use print_symbol() Benjamin Herrenschmidt: o fix IDE init oops on PowerMac Bernardo Innocenti: o Fix do_div() for all architectures o Fix problem introduced by do_div() patch Bruno Ducrot: o powernow-k7 typo fix Chad Talbott: o ia64: SN2 updates Dagfinn Ilmari Mannsåker: o Allow modular DM Dave Jones: o [AGPGART] SiS 755 support for AMD K8 GART o [CPUFREQ] Fix stupid inverted FID/VID bug o [CPUFREQ] update cpufreq docs to reflect newly merged architecture support From Dominik Brodowski o [AGPGART] Add AGP3 support for all VIA AGP3 chipsets o [AGPGART] Fill out bridge structure with pdev before querying agp version o [CPUFREQ] Misc cleanups o [CPUFREQ] kobj refcount fixes o [CPUFREQ] move cpufreq_restore(), and don't make it dependent on CONFIG_PM o [CPUFREQ] don't care about "rmmod -f". It's expected to break things o [CPUFREQ] More misc cleanups Dave Kleikamp: o JFS: Possible trap/data loss when fixing directory index table o JFS: If unicode conversion fails, operation should fail o JFS: Make error return codes negative o JFS: add nointegrity mount option David Mosberger: o ia64: A couple of additional fixes to sync with 2.5.73+ o ia64: support arch_get_unmapped_area() cache o ia64: Remove UNW_DEBUG again. Adding it was a mistake o ia64: Fix LOAD_OFFSET macro in kernel linker script. Reported by Mika Penttil. o ia64: Sync up with 2.5.74+ o Use ".incbin" for initramfs image build David S. Miller: o [SPARC64]: Move raid xor into library assembler file o [SPARC64]: Kill all irq_cpustat_t except __softirq_pending o [SPARC64]: Use kstat_this_cpu where possible o [TCP]: Initialize socket route on move to established state o [TCP]: Eliminate spurious CWND restart on every new connection o [SUNHME]: Set RXMAX/TXMAX large enough to handle VLAN frames Dmitry Torokhov: o [NET] Attach inner qdiscs to TBF Eric Sandeen: o [XFS] add swsusp support to xfs daemons Gary Hade: o ia64: fix for sys32_sysinfo bug Greg Kroah-Hartman: o PCI: change WARN_ON(irqs_disabled()) to WARN_ON(in_interrupt()) to keep the fusion drivers happy o sysfs: change print() to pr_debug() to not annoy everyone o SYSFS: add module referencing to sysfs attribute files o sysfs: add sysfs_rename_dir() Based on a patch written by Dan Aloni <da-x@gmx.net> o kobject: add kobject_rename() Based on a patch written by Dan Aloni <da-x@gmx.net> o driver core: added class_device_rename() Based on a patch written by Dan Aloni <da-x@gmx.net> o driver core: add my copyright to class.c Greg Ungerer: o selection of boot parameters at configure time for Motorola 5282 targets o conditional ROMfs copy for Motorola M5307C3 board o force PAGE_SIZE to be an unsigned long o remove unused register from clobber list in down_trylock() o simplify access_ok() for all m68knommu targets o shared library support for MMUless binfmt_flat loader o flat loader H8/300 specific support abstracted o flat loader m68knommu specific support abstracted o flat loader v850 specific support abstracted o conditional ROMfs copy for Cleopatra/5307 board o .no .romvec section for DragonEngine/68328 target o define shared lib limits for flat loader o cleanup show_process_blocks() for non-mmu targets o define raw read/write for m68knommu io access o remove 68360 specific trap init call o 68328 DragenEngine configure updates o conditional ROMfs copy for SecureEdgeMP3/5307 board o DragenEngine interrupt handler to use irqreturn_t o conditional ROMfs copy for NETtel/5307 board o fix security_initcall in m68knommu linker script o clean module_exit in m68knommu serial drivers o fix return type of m68knommu timer handler to be irqreturn_t o fix interrupt handler passed as arg to return irqreturn_t o use irqreturn_t in ColdFire interrupt setup code Herbert Xu: o [IPSEC] Add policy expiration o [IPSEC] Fix refcnt leak in xfrm_lookup Hideaki Yoshifuji: o [IPV6] fix a mistake in ipv6_advmss() conversion o [NET] Fix oops with /proc/net/{raw,igmp,mfilter, raw6,igmp6,mfilter6,anycast,ip6_flowlabel}. o [NET] Send only unicast NSs in PROBE state o [IPV6] ignore on-link information without on-link flag set o [IPV6] remove unused variable o [IPV6] fix algorithm for updating lifetime o [ATM] Convert clip neigh table to C99 initializers o [IPV6] Fix BUG when appending destination options headers Hirofumi Ogawa: o FAT maintainership Ian Molton: o ARM26 architecture update Ingo Molnar: o another timer overflow thing o Double unlock in BSD accounting speedup patch James Morris: o [IPSEC]: Do not call request_module() under spinlock in xfrm_get_type() Jason Lunz: o [NET] Fix refcounting of dev->promiscuity for af_packet Jean-Luc Richier: o [IPV6] Fix ipv6_addr_prefix() for prefixlen != 0 (mod 8) Jeff Garzik: o fix via irq routing Via irq routing has a funky PIRQD location. I checked my datasheets and, yep, this is correct all the way back to via686a. o [netdrvr 8139too] fix debug printk John Levon: o OProfile: __exit fixes o OProfile: needed fix to IO-APIC timer o OProfile: fix a comment John Marvin: o ia64: don't let PTRACE_POKEDATA write the NaT bits of syscall args John Stultz: o jiffies include fix This patch fixes a bad declaration of jiffies in timer_tsc.c and timer_cyclone.c, replacing it with the proper usage of jiffies.h. Krzysztof Halasa: o C99 initializers in hdlc_generic.c Linus Torvalds: o The sbp2 driver needs <linux/pci.h>, but didn't include it. It apparently used to work due to some random magic indirect include, but broke lately. o Add an asynchronous buffer read-ahead facility. Nobody uses it for now, but I needed it for some tuning tests, and it is potentially useful for others. o Re-organize "ext3_get_inode_loc()" and make it easier to follow by splitting it into two functions: one that calculates the position, and the other that actually reads the inode block off the disk. o Carl-Daniel Hailfinger suggest adding a paranoid incoming trigger as per the "bk help triggers" suggestion, so that we'll see any new triggers showing up in the tree. o Go back to defaulting to 6-byte commands for MODE SENSE, since some drivers seem to be unhappy about the 10-byte version. o When forcing through a signal for some thread-synchronous event (ie SIGSEGV, SIGFPE etc that happens as a result of a trap as opposed to an external event), if the signal is blocked we will not invoce a signal handler, we will just kill the thread with the signal. o Simplify and speed up mmap read-around handling o Fix several broken macros to get the "private" field of a seq-file in the networking code. o Avoid deadlocking on thread shutdown after a vfork o Fix IDE initialization when we don't probe for interrupts o Make the gcc version checks use the preprocessor symbols consistently. o Update CREDITS file and other documentation about my new email address o Fix up the IDE irq disable to take into account some o Fix mailer-induced corruption in initramfs build rules Lode Leroy: o [IPV4] display bootserver in /proc/net/pnp Marc Zyngier: o EISA: core changes o EISA: Documentation update o EISA: More EISA ids o EISA: PA-RISC changes o EISA: PCI-EISA dma_mask o EISA: avoid unnecessary probing Martin Diehl: o Missing IrDA stuff for 2.5.73-bk8: sir_dev Martin Hicks: o ia64: fix register-backing store initialization for main thread Matthew Wilcox: o PCI: Improve documentation Fix some grammar problems Add a note about Fast Back to Back support Change the slot_name recommendation to pci_name(). o PCI: arch/i386/pci/direct.c can use __init, not __devinit pci_sanity_check() is only called from functions marked __init, so it can be __init too. o PCI: pci_find_bus needs a domain Give pci_find_bus a domain argument and move its declaration to <linux/pci.h> o PCI: Remove pci_bus_exists Convert all callers of pci_bus_exists() to call pci_find_bus() instead. o PCI: arch/i386/pci/irq.c should use pci_find_bus Use pci_find_bus rather than relying on the return value of pci_scan_bus. o PCI: arch/i386/pci/legacy.c: use raw_pci_ops Make pcibios_fixup_peer_bridges() use raw_pci_ops directly instead of faking pci_bus and pci_dev. o PCI config space in sysfs o Driver Core: fix firmware binary files Fixes the sysfs binary file bug. o ia64: Use generic pci_scan_bus() Mikael Starvik: o CRIS architecture update for 2.5.74 Paul Fulghum: o synclink.c update o synclinkmp.c update o synclink_cs.c update Paul Mackerras: o Compile fix and cleanup for macserial driver Pavel Machek: o New maintainter for nbd o suspend SMP-kernel with one CPU o Fix thinko in acpi o Fix swsusp with PREEMPT Randy Dunlap: o [IPV6] use correct mib struct o [NET] Add MODULE_LICENSE (GPL) to wanroutrer so that kernel is not tainted Roger Luethi: o via-rhine 1.18-2.5: Fix Rhine-I regression Russell King: o [SERIAL] Don't return -ERESTARTSYS if signals aren't pending Rusty Russell: o Remove cpu arg from cpu_raise_irq o Per-cpu variable in mm/slab.c o Remove unused __syscall_count o Make ksoftirqd a normal per-cpu variable o Make kstat_this_cpu in terms of __get_cpu_var and use it o switch_mm and enter_lazy_tlb: remove cpu arg Scott Feldman: o [e1000] request_irq() failure resulted in freeing twice o [e1000] fix VLAN support on PPC64 o [e1000] missing Tx cleanup opportunities during intr handling o [e1000] alloc_etherdev failure didn't cleanup regions o [e1000] ethtool diag cleanup o [e1000] h/w workaround for mis-fused parts o [e1000] s/int/unsigned int/ for descriptor ring indexes o [e1000] misc cleanup Stephen Hemminger: o Change OSDL address in CREDITS o [NET]: PPP handling fragmented skbuffs Stephen Lord: o Remove unused xfs_syncd.c file o Cleanup xfs and pagebuf sysctl code, use posix initializers to avoid confusion in the future over which constants apply to which initializers. Steve French: o Fix compiler warning o cifs xattr support part 1 o Signing fixes (1-4) o Update cifs vfs information and readme o Fix statfs failure due to invalid value for ffree Steven Cole: o update Documentation/Changes, scripts/ver_linux Thomas Graf: o [NET]: Make {send,recv}msg return EMSGSIZE when msg_iovelen is too big, as per 1003.1 Tom Rini: o PPC32: Update the OpenPIC code o PPC32: Update the bootloader serial code to have stub functions o PPC32: Remove references to a removed file o PPC32: Minor KGDB updates o PPC32: Add a backend for standard (ns1655x) UARTs for debugers o PPC32: Update the Motorola Sandpoint support o PPC32: Fix CONFIG_NVRAM && !CONFIG_PPC_PMAC o Remove the Zynx 4500 platform code. It was old and unmaintained o PPC32: Remove the MEN F1 platform code. It was old and unmaintained Trond Myklebust: o Add open intent information to the 'struct nameidata' o Pass 'nameidata' to ->create() o Pass 'nameidata' to ->permission() o Use the intents in 'nameidata' to improve NFS close-to-open consistency o make create() follow symlinks again Ulrich Drepper: o wrong pid in siginfo_t o tgkill patch for safe inter-thread signals Ville Nuorvala: o [IPV6] fix a dst leakage and clean-up in tcp_v6_connect() o [NET]: Fix tunnel device bugs added by alloc_netdev() changes o [IPV6]: Fix DST handling bug in ip6ip6_err() o [IPV6]: Convert ip6ip6 tunnel driver to alloc_netdev()
On Thu, Jul 10, 2003 at 02:14:15PM -0700, Linus Torvalds wrote: > Ok. This is it. We (Andrew and me) are going to start a "pre-2.6" series, > where getting patches in is going to be a lot harder. This is the last > 2.5.x kernel, so take note. Well, only two words from me. Oh Shit. The 2.5.70 ARM patch currently looks like this: 343 files changed, 45388 insertions(+), 7341 deletions(-) and I don't see that this will be reducing in size now that 2.6 is around the corner. I _know_ ARM stuff doesn't build and hasn't built in Linus' tree for a fair time now - there are some generic changes to support ARM modules needed in vmalloc.c which I just haven't had the time to sort out, and there's still the issue of whether /proc/kcore actually works or not, and now I see that the time stuff needs re-working for multiple ARM platforms yet again. (yes, all the other architectures got updated, except for ARM.) Maybe I should just forget even attempting to merge upstream, like most of the ARM community doesn't. Frustrated such an understatement. -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
On Thu, 10 Jul 2003, Russell King wrote: > > Well, only two words from me. Oh Shit. Hey, this is already much later than it should have been, so it's not as if this is a huge surprise. > The 2.5.70 ARM patch currently looks like this: We can sort it out later. Obviously, clearly arm-specific patches (ie stuff in arch/arm and include/asm-arm) I wouldn't mind per se, but I'd rather hold back on even those just to make the patches and the changlogs not be mixed up with the "main bugfixes". We've never had a first stable release that has all architectures up-to-date, and I'm not planning on changing that for 2.6.x. This is _not_ the time to try to make my tree build on arm (or other architectures either), considering that my tree hasn't been the main ARM tree for a long time. > Frustrated such an understatement. To be blunt, which part of "we want to release 2.6.x this year" came as a surprise to you? I That means that I'm not willing to hold stuff up any more. Stuff that hasn't followed the development tree doesn't magically just "get fixed". Also, the only real point of a stable release is for distribution makers. That pretty much cuts the list of "needs to be supported" down to x86, ia64, x86-64 and possibly sparc/alpha. So everything else is a bonus, but can equally well just play catch-up later. Embedded people tend to want to stay back anyway, which is obviously why they don't follow the development tree in the first place. Linus
On Thu, Jul 10, 2003 at 03:26:09PM -0700, Linus Torvalds wrote: > On Thu, 10 Jul 2003, Russell King wrote: > > > > Well, only two words from me. Oh Shit. > > Hey, this is already much later than it should have been, so it's not as > if this is a huge surprise. Absolutely no surprise. In any case, the long development cycle isn't what ARM stuff needs. For example, during 2.3, people only started serious merging with myself of the StrongARM SoC code towards the end of 2.3 when it became important to them for 2.4. That caused the serial layer rewrite around 2.4.2 time and later spawned the cpufreq project, both of which has been maintained ever since. Now that StrongARM SoC has been end of life'd by Intel, most of the work which went into 2.5 is wasted because probably no one will ever use it. A fine example of this was what happened with the touchscreen stuff (thank god we got the input layer in 2.5.) I see the same thing happening to the Intel PXA (Xscale stuff.) Virtually the whole of the ARM community is working on 2.4 for Xscale because that's the current stable kernel. They're not interested in 2.6 until 2.6 actually comes out. At this point, everyone will want their drivers to work on that kernel. Of course, 2.8 will be too late. And then yours truely then ends up with loads of crap patches and we start the process again. The major problem is that embedded developers only care about what works for them and what they can provide to their customers. Once that's done, they don't have any interest in cleaning stuff up nor feeding obvious bug fixes back up. > > The 2.5.70 ARM patch currently looks like this: > > We can sort it out later. Obviously, clearly arm-specific patches (ie > stuff in arch/arm and include/asm-arm) I wouldn't mind per se, but I'd > rather hold back on even those just to make the patches and the changlogs > not be mixed up with the "main bugfixes". I've still got to sort out the module space and /proc/kcore - we allocate the module space between TASK_SIZE and PAGE_OFFSET, which needs vmalloc to be aware that entries on the vmlist may cover two allocatable areas. Maybe this has changed, I haven't had time to look into this. This is probably the main reason why stock 2.5 (since Rusty's module changes went in, recent) has never built for ARM. I don't think the kclist stuff really fits this for me - it doesn't allow me to do allocations off it, and I don't want yet another list for modules. I guess I'm going to stick with my current approach of having two memory spaces in the vmlist. (see patch). > We've never had a first stable release that has all architectures > up-to-date, and I'm not planning on changing that for 2.6.x. This is _not_ > the time to try to make my tree build on arm (or other architectures > either), considering that my tree hasn't been the main ARM tree for a long > time. Hasn't ever, I'm afraid. I can't think of any stock kernel which has been usable, let alone been compilable for ARM. Which, IMO, is a pretty sorry statement to make. --- orig/mm/vmalloc.c Tue May 27 10:05:48 2003 +++ linux/mm/vmalloc.c Tue May 27 10:14:45 2003 @@ -178,21 +178,11 @@ return err; } - -/** - * get_vm_area - reserve a contingous kernel virtual area - * - * @size: size of the area - * @flags: %VM_IOREMAP for I/O mappings or VM_ALLOC - * - * Search an area of @size in the kernel virtual mapping area, - * and reserved it for out purposes. Returns the area descriptor - * on success or %NULL on failure. - */ -struct vm_struct *get_vm_area(unsigned long size, unsigned long flags) +struct vm_struct *__get_vm_area(unsigned long size, unsigned long flags, + unsigned long start, unsigned long end) { struct vm_struct **p, *tmp, *area; - unsigned long addr = VMALLOC_START; + unsigned long addr = start; area = kmalloc(sizeof(*area), GFP_KERNEL); if (unlikely(!area)) @@ -209,12 +199,14 @@ write_lock(&vmlist_lock); for (p = &vmlist; (tmp = *p) ;p = &tmp->next) { + if ((unsigned long)tmp->addr < addr) + continue; if ((size + addr) < addr) goto out; if (size + addr <= (unsigned long)tmp->addr) goto found; addr = tmp->size + (unsigned long)tmp->addr; - if (addr > VMALLOC_END-size) + if (addr > end - size) goto out; } @@ -239,6 +231,21 @@ } /** + * get_vm_area - reserve a contingous kernel virtual area + * + * @size: size of the area + * @flags: %VM_IOREMAP for I/O mappings or VM_ALLOC + * + * Search an area of @size in the kernel virtual mapping area, + * and reserved it for out purposes. Returns the area descriptor + * on success or %NULL on failure. + */ +struct vm_struct *get_vm_area(unsigned long size, unsigned long flags) +{ + return __get_vm_area(size, flags, VMALLOC_START, VMALLOC_END); +} + +/** * remove_vm_area - find and remove a contingous kernel virtual area * * @addr: base address -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
On Fri, 11 Jul 2003, Russell King wrote: > > Absolutely no surprise. In any case, the long development cycle isn't > what ARM stuff needs. Well, nothing really _wants_ a long development cycle. I suspect any particular feature taken on its own always wants the shortest possible development cycle, and that what ends up happening is just that there are a lot of interdepencies and just plain "different" development-cycles. Which is not a bad thing per se, and pretty clearly is unavoidable. So I'm not complaining. It's just a fact of life. I think that the best way to "solve" the problem is to partially ignore it, and I don't think it's a bad thing that we have many different trees, and some of them are less strongly coupled to others - exactly to handle the inevitable case of release cycle lag. For example, I absolutely detest the BSD "world" model, which actually makes these problems bigger by tying different projects together into one tree. I think it's much more important to try to have as much freedom as possible, including very much having separate timetables and development environments. > Hasn't ever, I'm afraid. I can't think of any stock kernel which has > been usable, let alone been compilable for ARM. Which, IMO, is a pretty > sorry statement to make. You see that as a sorry statement, but I don't think it's a failure. Why _should_ one tree have to try to make everybody happy? We want to try to make it easier to keep the couplings in place by striving for portable infrastructure etc, but we would only be hampered by a philosophy that says "everything has to work in tree X", since that just means that you can't afford to break things. I'd much rather keep the freedom to break stuff, and have many separate trees that break _different_ things, and let them all co-exist in a friendly rivalry. And my tree is just one tree in that forest. So it's not a bug - it's a FEATURE! Linus
On Thu, 2003-07-10 at 23:14, Linus Torvalds wrote:
> Ok. This is it. We (Andrew and me) are going to start a "pre-2.6" series,
> where getting patches in is going to be a lot harder. This is the last
> 2.5.x kernel, so take note.
Is there any expected or planned timeframe to finalize the pre-2.6
series and end up with a stable 2.6.0 kernel?
I'm worried about the current status of the 2.5 kernel scheduler. I know
that Con is working hard to nail down all the problems that some people
like me are having. I don't still feel comfortable with it, and although
Con patches are several orders of magnitude better than stock scheduler,
there are minor problems.
Sometime ago, I made down a combo patch and, sincerely, it's the one I'm
using the most for my desktop boxes as it's the one that gets better
response times and interactive feeling. For my server boxes, neither my
combo patch, neither Con or stock do feel good when the system is under
heavy load. It suffers from starvation. Simply doing a "tar jxvf" makes
logging into the system a PITA.
Just my 2 cents.
On 11 Jul 2003, Felipe Alfaro Solana wrote: > > Is there any expected or planned timeframe to finalize the pre-2.6 > series and end up with a stable 2.6.0 kernel? It's a bit hard to plan, since it depends on just how well the pre-series ends up working for people. There are now people starting to use the current 2.5.x kernels for production use, and indicators look pretty good in general, but who can tell? So if I were to guess at a couple of months, then that's still just a guess. > I'm worried about the current status of the 2.5 kernel scheduler. I know > that Con is working hard to nail down all the problems that some people > like me are having. I don't still feel comfortable with it, and although > Con patches are several orders of magnitude better than stock scheduler, > there are minor problems. Quite frankly, I worry a lot more about device drivers etc than I do about the scheduler. We'll never have "The Perfect Scheduler" (tm), since I don't think such a thing exists, but more importantly, I could live even with the current one, and I'm sure Con's will be better without having any huge stability issues. > Sometime ago, I made down a combo patch and, sincerely, it's the one I'm > using the most for my desktop boxes as it's the one that gets better > response times and interactive feeling. For my server boxes, neither my > combo patch, neither Con or stock do feel good when the system is under > heavy load. It suffers from starvation. Simply doing a "tar jxvf" makes > logging into the system a PITA. And this one is almost certainly not a process scheduler issue, but an IO scheduler one. 2.5.75 may help that a bit - anticipatory IO scheduling from the -mm tree, and a much simpler (and in my tests, noticeably faster and more robust) executable mmap prefetcher. But as with process scheduling, I don't believe in "perfect". It will just have to be "good enough for a lot of people". Linus
On Thu, 2003-07-10 at 16:30, Felipe Alfaro Solana wrote:
> I'm worried about the current status of the 2.5 kernel scheduler.
I am sure Linus and Andrew will continue to take patches to tune the
scheduler, as long as they are clearly tuning issues.
I do not see it as a _huge_ problem, because we are just worrying about
corner cases now. Worst case we can turn off the interactivity estimator
- which is both the root of the improvement and the problems - and be
back to where we are in 2.4.
Robert Love
On Thu, 10 Jul 2003, Linus Torvalds wrote:
> > Sometime ago, I made down a combo patch and, sincerely, it's the one I'm
> > using the most for my desktop boxes as it's the one that gets better
> > response times and interactive feeling. For my server boxes, neither my
> > combo patch, neither Con or stock do feel good when the system is under
> > heavy load. It suffers from starvation. Simply doing a "tar jxvf" makes
> > logging into the system a PITA.
>
> And this one is almost certainly not a process scheduler issue, but an IO
> scheduler one. 2.5.75 may help that a bit - anticipatory IO scheduling
> from the -mm tree, and a much simpler (and in my tests, noticeably faster
> and more robust) executable mmap prefetcher.
>
> But as with process scheduling, I don't believe in "perfect". It will just
> have to be "good enough for a lot of people".
Indeed. Yesterday while I was doing the SOFTRR hack I had after a quite
long time the opportunity to test the current scheduler interactivity. To
me it looks very good. My usual `make -j 40 bzImage` let my system
completely usable. If all this noise was for the tar thingy maybe we are
responsible to not have well read the thread to stop it soon.
- Davide
El 10 Jul 2003 16:40:29 -0700 Robert Love <rml@tech9.net> escribió:
> I do not see it as a _huge_ problem, because we are just worrying about
> corner cases now. Worst case we can turn off the interactivity estimator
> - which is both the root of the improvement and the problems - and be
> back to where we are in 2.4.
It used to work fine in the past; now as Felipe said, it's a PITA. Con's
patch helps but it's not even near than what it used to be. My make -j 25
without any skip is now -j3 with Con's patch and some mp3 skips. Perhaps
i should start testing when it stopped "working" (i always save the kernel
images)
Diego Calleja
Diego Calleja García wrote: >El 10 Jul 2003 16:40:29 -0700 Robert Love <rml@tech9.net> escribió: > > > >>I do not see it as a _huge_ problem, because we are just worrying about >>corner cases now. Worst case we can turn off the interactivity estimator >>- which is both the root of the improvement and the problems - and be >>back to where we are in 2.4. >> >> > >It used to work fine in the past; now as Felipe said, it's a PITA. Con's >patch helps but it's not even near than what it used to be. My make -j 25 >without any skip is now -j3 with Con's patch and some mp3 skips. Perhaps >i should start testing when it stopped "working" (i always save the kernel >images) > > Please share this information if you find it :-) I would like a nice desktop kernel again too. >Diego Calleja > > >
On Thu, 2003-07-10 at 23:14, Linus Torvalds wrote:
> Ok. This is it. We (Andrew and me) are going to start a "pre-2.6" series,
> where getting patches in is going to be a lot harder. This is the last
> 2.5.x kernel, so take note.
>
> The probably most notable thing here is the anticipatory scheduler,
> which has been in -mm for a long time, and was the major piece that
> hadn't been merged.
>
> Some architecture updates: cris has been updated for 2.5, ia64 and arm26
> updates etc. And various random (smallish) things.
Hi Linus !
I'm quite concerned about Power Management. Patrick haven't yet merged
the new implementation which changes the driver-side semantics to
something sane and your above mail seem to imply this is now too late.
While I agree these should have been merged a lot earlier, I'm also
annoyed by the fact that the existing save_state/suspend semantics
are just plain broken...
What do you plan on this regard ? Patrick, do you still need to hold
your patch until OLS ? They should get in now, that won't prevent
you from doing your paper ;)
Ben.
I'm still getting oops when loading aha152x.. (having it compiled in the kernel gives the same result) PnPBIOS: Scanning system for PnP BIOS support... PnPBIOS: Found PnP BIOS installation structure at 0xc00f9710 PnPBIOS: PnP BIOS version 1.0, entry 0xf2300:0x0, dseg 0xf0000 PnPBIOS: 15 nodes reported by PnP BIOS; 15 recorded by driver ... isapnp: Scanning for PnP cards... isapnp: Card 'CS4237' isapnp: Card 'Adaptec AVA-1505AE' isapnp: 2 Plug & Play cards detected total ... SCSI subsystem initialized pnp: Device 01:02.00 activated. aha152x: found ISAPnP AVA-1505A at io=0x140, irq=10 aha152x: BIOS test: passed, detected 1 controller(s) aha152x: resetting bus... aha152x0: vital data: rev=3, io=0x140 (0x140/0x140), irq=10, scsiid=7, reconnecd aha152x0: trying software interrupt, <1>Unable to handle kernel NULL pointer dec printing eip: c58951ea *pde = 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[<c58951ea>] Not tainted EFLAGS: 00010046 EIP is at swintr+0x4a/0x70 [aha152x] eax: 00000000 ebx: c3db2800 ecx: 0000000a edx: 00000002 esi: 24000001 edi: 00000000 ebp: c3dffecc esp: c3dffec8 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 244, threadinfo=c3dfe000 task=c4d4f300) Stack: 0000000a c3dffeec c010a793 0000000a c3e6b800 c3dfff1c c3dfe000 0000000a c02c8f00 c3dfff14 c010aac9 0000000a c3dfff1c c3db2800 c3db2800 00000500 c3e6b800 c3e6b9b0 00000140 c3dfff5c c01092f8 c3e6b800 c1346680 00000152 Call Trace: [<c010a793>] handle_IRQ_event+0x33/0x60 [<c010aac9>] do_IRQ+0xb9/0x180 [<c01092f8>] common_interrupt+0x18/0x20 [<c589545e>] aha152x_probe_one+0x24e/0x3d0 [aha152x] [<c58959ae>] aha152x_detect+0x3ce/0x810 [aha152x] [<c5895df0>] aha152x_release+0x0/0x80 [aha152x] [<c582703c>] init_this_scsi_driver+0x3c/0xeb [aha152x] [<c012d02b>] sys_init_module+0xfb/0x220 [<c01090d7>] syscall_call+0x7/0xb Code: a1 4c 00 00 00 25 ff ff 00 00 50 68 80 b6 89 c5 e8 e1 39 88 <0>Kernel panic: Fatal exception in interrupt In interrupt handler - not syncing snd-cs4236 module can be loaded with no problem. (pnp soundcard) -- S.
On Thu, 10 Jul 2003, Linus Torvalds wrote:
> David Mosberger:
> o Use ".incbin" for initramfs image build
Why was this change necessary? It requires me to build a new toolchain (yes I
know Documentation/Changes says you need at least 2.12):
| tux$ make usr/
| AS usr/initramfs_data.o
| usr/initramfs_data.S: Assembler messages:
| usr/initramfs_data.S:2: Error: Unknown pseudo-op: `.incbin'
| make[1]: *** [usr/initramfs_data.o] Error 1
| make: *** [usr/] Error 2
| tux$ m68k-linux-ld -v
| GNU ld version 2.9.5 (with BFD 2.9.5.0.37)
| tux$
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, 11 Jul 2003, Geert Uytterhoeven wrote: > On Thu, 10 Jul 2003, Linus Torvalds wrote: > > David Mosberger: > > o Use ".incbin" for initramfs image build > > Why was this change necessary? It requires me to build a new toolchain (yes I > know Documentation/Changes says you need at least 2.12): > > | tux$ make usr/ > | AS usr/initramfs_data.o > | usr/initramfs_data.S: Assembler messages: > | usr/initramfs_data.S:2: Error: Unknown pseudo-op: `.incbin' > | make[1]: *** [usr/initramfs_data.o] Error 1 > | make: *** [usr/] Error 2 > | tux$ m68k-linux-ld -v > | GNU ld version 2.9.5 (with BFD 2.9.5.0.37) > | tux$ Oops, I missed this: On Wed, 9 Jul 2003, David Mosberger wrote: > As I recall, the only objection to this patch came from Russell King, > since it would force ARM to upgrade to a reasonably recent version of > binutils, but he (grudingly) agreed to the change. So yes, m68k is affected too... Gr{oetje,eeting}s, Geert, happily using gcc 2.95.2 -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Linus Torvalds wrote: > Ok. This is it. We (Andrew and me) are going to start a > "pre-2.6" series, where getting patches in is going to be a > lot harder. This is the last 2.5.x kernel, so take note. [ ... ] Thanks a lot to all 'extreme'-kernel-developers and especially to Linus (as ever) and Andrew! I just compiled 2.5.75 on my old Alpha (AS1000A/333, Noritake). It compiled without problems! And it started up without problems (some warnings, but nothing the can't be fixed with 'vi /etc/*'). :-) So thanks a lot, you did a GREAT job! I hope to see 2.6 (or even better 3.0) soon on that machine. I can only recommend 2.5 on Alpha. It was (believe it or not) a performance boost on this machine! Best regards, Oliver -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (MingW32) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj8O29sACgkQEyZKIOgU3Si1ggCgh3QE8+IucC5NBpC/OaUDN+sP U3sAnRLfssfUXlrhXdUcDRECfRbXd1KX =Yyky -----END PGP SIGNATURE-----
Compile statistics: 2.5.75 Compiler: gcc 3.2.2 Script: http://www.osdl.org/archive/cherry/stability/compregress.sh bzImage bzImage modules (defconfig) (allmodconfig) (allmodconfig) 2.5.75 0 warnings 8 warnings 1296 warnings 0 errors 9 errors 39 errors 2.5.74 0 warnings 8 warnings 1338 warnings 0 errors 9 errors 40 errors 2.5.73 2 warnings 11 warnings 1347 warnings 0 errors 9 errors 43 errors 2.5.72 2 warnings 8 warnings 1335 warnings 0 errors 0 errors 48 errors 2.5.71 6 warnings 11 warnings 1347 warnings 0 errors 0 errors 48 errors 2.5.70 7 warnings 10 warnings 1366 warnings 0 errors 0 errors 57 errors Compile statistics have been for kernel releases from 2.5.46 to 2.5.75 at: www.osdl.org/archive/cherry/stability Failure summary: drivers/block: 2 warnings, 1 errors drivers/char: 228 warnings, 4 errors drivers/isdn: 216 warnings, 6 errors drivers/media: 102 warnings, 5 errors drivers/mtd: 42 warnings, 1 errors drivers/net: 29 warnings, 6 errors drivers/net: 302 warnings, 6 errors drivers/scsi/aic7xxx: 0 warnings, 1 errors drivers/scsi: 110 warnings, 10 errors drivers/video: 75 warnings, 3 errors sound/oss: 49 warnings, 3 errors sound: 5 warnings, 3 errors Warning summary: drivers/atm: 36 warnings, 0 errors drivers/cdrom: 25 warnings, 0 errors drivers/i2c: 3 warnings, 0 errors drivers/ide: 28 warnings, 0 errors drivers/md: 2 warnings, 0 errors drivers/message: 1 warnings, 0 errors drivers/pci: 1 warnings, 0 errors drivers/pcmcia: 3 warnings, 0 errors drivers/scsi/aacraid: 1 warnings, 0 errors drivers/scsi/pcmcia: 5 warnings, 0 errors drivers/scsi/sym53c8xx_2: 1 warnings, 0 errors drivers/serial: 1 warnings, 0 errors drivers/telephony: 9 warnings, 0 errors drivers/video/aty: 3 warnings, 0 errors drivers/video/matrox: 5 warnings, 0 errors drivers/video/sis: 2 warnings, 0 errors fs/afs: 1 warnings, 0 errors fs/intermezzo: 1 warnings, 0 errors fs/jffs: 1 warnings, 0 errors fs/lockd: 4 warnings, 0 errors fs/nfsd: 2 warnings, 0 errors fs/smbfs: 2 warnings, 0 errors net: 35 warnings, 0 errors sound/isa: 3 warnings, 0 errors ===== Porting items identified as warnings (2003-07-10) ======== ===================================== Misc porting reminders: 4 reminders ===================================== drivers/char/applicom.c:260:2: warning: #warning "LEAK" drivers/char/applicom.c:524:2: warning: #warning "Je suis stupide. DW. - copy*user in cli" drivers/char/mwave/mwavedd.c:332:2: warning: #warning "Sleeping on spinlock" kernel/suspend.c:294:2: warning: #warning This might be broken. We need to somehow wait for data to reach the disk ======================================================================== DMA mapping conversions using Documnentation/DMA-mapping.txt: 5 files ======================================================================== drivers/net/defxx.c:202:2: #error Please convert me to Documentation/DMA-mapping.txt drivers/scsi/AM53C974.c:1:2: #error Please convert me to Documentation/DMA-mapping.txt drivers/scsi/dpt_i2o.c:32:2: #error Please convert me to Documentation/DMA-mapping.txt drivers/scsi/ini9100u.c:111:2: #error Please convert me to Documentation/DMA-mapping.txt drivers/scsi/scsiiom.c:9:2: #error Please convert me to Documentation/DMA-mapping.txt ===================================== Other #error conversions: 1 files ===================================== drivers/scsi/pci2220i.c:37:2: #error Convert me to understand page+offset based scatterlists =========================================== MOD_INC_USE_COUNT deprecations: 123 files =========================================== drivers/atm/eni.c drivers/atm/idt77252.c drivers/atm/lanai.c drivers/atm/uPD98402.c drivers/atm/zatm.c drivers/char/ftape/compressor/zftape-compress.c drivers/char/genrtc.c drivers/char/ip2.c drivers/char/n_r3964.c drivers/char/watchdog/acquirewdt.c drivers/char/watchdog/ib700wdt.c drivers/char/watchdog/machzwd.c drivers/char/watchdog/pcwd.c drivers/char/watchdog/sbc60xxwdt.c drivers/char/watchdog/sc520_wdt.c drivers/char/watchdog/softdog.c drivers/char/watchdog/wdt_pci.c drivers/ide/ide-probe.c drivers/ide/legacy/ide-cs.c drivers/ide/pci/aec62xx.c drivers/ide/pci/alim15x3.c drivers/ide/pci/amd74xx.c drivers/ide/pci/cmd64x.c drivers/ide/pci/cs5520.c drivers/ide/pci/cy82c693.c drivers/ide/pci/hpt34x.c drivers/ide/pci/hpt366.c drivers/ide/pci/ns87415.c drivers/ide/pci/opti621.c drivers/ide/pci/pdc202xx_new.c drivers/ide/pci/pdc202xx_old.c drivers/ide/pci/piix.c drivers/ide/pci/rz1000.c drivers/ide/pci/sc1200.c drivers/ide/pci/serverworks.c drivers/ide/pci/siimage.c drivers/ide/pci/sis5513.c drivers/ide/pci/slc90e66.c drivers/ide/pci/triflex.c drivers/ide/pci/trm290.c drivers/ide/pci/via82cxxx.c drivers/isdn/capi/capidrv.c drivers/isdn/capi/kcapi.c drivers/isdn/hardware/eicon/capifunc.c drivers/isdn/hardware/eicon/capimain.c drivers/isdn/hardware/eicon/diva_didd.c drivers/isdn/hardware/eicon/divamnt.c drivers/isdn/hardware/eicon/divasi.c drivers/isdn/hardware/eicon/divasmain.c drivers/isdn/hysdn/hysdn_net.c drivers/isdn/i4l/isdn_common.c drivers/isdn/i4l/isdn_tty.c drivers/md/md.c drivers/media/video/bt819.c drivers/media/video/bt856.c drivers/media/video/saa5249.c drivers/media/video/saa7110.c drivers/media/video/saa7111.c drivers/media/video/saa7185.c drivers/media/video/tuner-3036.c drivers/media/video/zr36067.c drivers/mtd/chips/amd_flash.c drivers/mtd/chips/sharp.c drivers/mtd/devices/blkmtd.c drivers/net/arcnet/arc-rimi.c drivers/net/arcnet/com20020-isa.c drivers/net/arcnet/com20020-pci.c drivers/net/arcnet/com20020.c drivers/net/arcnet/com90io.c drivers/net/arcnet/com90xx.c drivers/net/fc/iph5526.c drivers/net/hamradio/baycom_epp.c drivers/net/hamradio/baycom_par.c drivers/net/hamradio/baycom_ser_fdx.c drivers/net/hamradio/baycom_ser_hdx.c drivers/net/hamradio/bpqether.c drivers/net/hamradio/hdlcdrv.c drivers/net/hamradio/mkiss.c drivers/net/irda/act200l.c drivers/net/irda/actisys.c drivers/net/irda/esi.c drivers/net/irda/girbil.c drivers/net/irda/irtty.c drivers/net/irda/litelink.c drivers/net/irda/ma600.c drivers/net/irda/mcp2120.c drivers/net/irda/old_belkin.c drivers/net/irda/tekram.c drivers/net/irda/toshoboe.c drivers/net/pcmcia/com20020_cs.c drivers/net/rrunner.c drivers/net/wan/comx-hw-comx.c drivers/net/wan/comx-hw-locomx.c drivers/net/wan/comx-hw-mixcom.c drivers/net/wan/comx-hw-munich.c drivers/net/wan/comx-proto-fr.c drivers/net/wan/comx-proto-lapb.c drivers/net/wan/comx-proto-ppp.c drivers/net/wan/comx.c drivers/net/wan/cosa.c drivers/net/wan/dlci.c drivers/net/wan/dscc4.c drivers/net/wan/farsync.c drivers/net/wan/hostess_sv11.c drivers/net/wan/lmc/lmc_main.c drivers/net/wan/pc300_drv.c drivers/net/wan/sdla.c drivers/net/wan/sdlamain.c drivers/net/wan/sealevel.c drivers/telephony/ixj.c drivers/telephony/phonedev.c fs/lockd/clntlock.c fs/lockd/svc.c fs/nfsd/nfssvc.c fs/smbfs/smbiod.c net/atm/br2684.c net/atm/pppoatm.c net/irda/ircomm/ircomm_tty.c net/lapb/lapb_iface.c net/wanrouter/wanmain.c sound/oss/cs4281/cs4281m.c sound/oss/cs46xx.c sound/oss/msnd.c =========================================== MOD_DEC_USE_COUNT deprecations: 91 files =========================================== drivers/atm/eni.c drivers/atm/idt77252.c drivers/atm/lanai.c drivers/char/epca.c drivers/char/genrtc.c drivers/char/ip2.c drivers/char/n_r3964.c drivers/ide/ide-probe.c drivers/ide/legacy/ide-cs.c drivers/isdn/capi/capidrv.c drivers/isdn/capi/kcapi.c drivers/isdn/hardware/eicon/capifunc.c drivers/isdn/hardware/eicon/capimain.c drivers/isdn/hardware/eicon/diva_didd.c drivers/isdn/hardware/eicon/divamnt.c drivers/isdn/hardware/eicon/divasi.c drivers/isdn/hardware/eicon/divasmain.c drivers/isdn/hysdn/hysdn_net.c drivers/isdn/i4l/isdn_common.c drivers/isdn/i4l/isdn_tty.c drivers/md/md.c drivers/media/video/bt819.c drivers/media/video/bt856.c drivers/media/video/saa5249.c drivers/media/video/saa7110.c drivers/media/video/saa7111.c drivers/media/video/saa7185.c drivers/media/video/tuner-3036.c drivers/media/video/zr36067.c drivers/message/i2o/i2o_block.c drivers/mtd/devices/blkmtd.c drivers/net/arcnet/arc-rimi.c drivers/net/arcnet/com20020-isa.c drivers/net/arcnet/com20020-pci.c drivers/net/arcnet/com20020.c drivers/net/arcnet/com90io.c drivers/net/arcnet/com90xx.c drivers/net/fc/iph5526.c drivers/net/hamradio/baycom_epp.c drivers/net/hamradio/baycom_par.c drivers/net/hamradio/baycom_ser_fdx.c drivers/net/hamradio/baycom_ser_hdx.c drivers/net/hamradio/bpqether.c drivers/net/hamradio/hdlcdrv.c drivers/net/hamradio/mkiss.c drivers/net/irda/act200l.c drivers/net/irda/actisys.c drivers/net/irda/esi.c drivers/net/irda/girbil.c drivers/net/irda/irtty.c drivers/net/irda/litelink.c drivers/net/irda/ma600.c drivers/net/irda/mcp2120.c drivers/net/irda/old_belkin.c drivers/net/irda/tekram.c drivers/net/irda/toshoboe.c drivers/net/pcmcia/com20020_cs.c drivers/net/rrunner.c drivers/net/wan/comx-hw-comx.c drivers/net/wan/comx-hw-locomx.c drivers/net/wan/comx-hw-mixcom.c drivers/net/wan/comx-hw-munich.c drivers/net/wan/comx-proto-fr.c drivers/net/wan/comx-proto-lapb.c drivers/net/wan/comx-proto-ppp.c drivers/net/wan/comx.c drivers/net/wan/cosa.c drivers/net/wan/dlci.c drivers/net/wan/dscc4.c drivers/net/wan/farsync.c drivers/net/wan/hostess_sv11.c drivers/net/wan/lmc/lmc_main.c drivers/net/wan/pc300_drv.c drivers/net/wan/sdla.c drivers/net/wan/sdlamain.c drivers/net/wan/sealevel.c drivers/telephony/ixj.c drivers/telephony/phonedev.c fs/intermezzo/inode.c fs/lockd/clntlock.c fs/lockd/svc.c fs/nfsd/nfssvc.c fs/smbfs/smbiod.c net/atm/br2684.c net/atm/pppoatm.c net/irda/ircomm/ircomm_tty.c net/lapb/lapb_iface.c net/wanrouter/wanmain.c sound/oss/cs4281/cs4281m.c sound/oss/cs46xx.c sound/oss/msnd.c =========================================== cli, save_flags conversions: 62 files =========================================== drivers/atm/ambassador.c drivers/atm/uPD98402.c drivers/atm/zatm.c drivers/cdrom/cdu31a.c drivers/cdrom/cm206.c drivers/cdrom/sbpcd.c drivers/cdrom/sonycd535.c drivers/char/cyclades.c drivers/char/epca.c drivers/char/esp.c drivers/char/ftape/lowlevel/fdc-io.c drivers/char/ftape/lowlevel/ftape-calibr.c drivers/char/ftape/lowlevel/ftape-format.c drivers/char/generic_serial.c drivers/char/ip2main.c drivers/char/isicom.c drivers/char/istallion.c drivers/char/moxa.c drivers/char/mxser.c drivers/char/stallion.c drivers/i2c/i2c-elektor.c drivers/isdn/act2000/capi.h drivers/isdn/divert/divert_init.c drivers/isdn/divert/divert_procfs.c drivers/isdn/divert/isdn_divert.c drivers/isdn/hardware/avm/b1.c drivers/isdn/hardware/avm/c4.c drivers/isdn/hardware/avm/t1isa.c drivers/isdn/hysdn/boardergo.c drivers/isdn/hysdn/hysdn_proclog.c drivers/isdn/hysdn/hysdn_sched.c drivers/isdn/i4l/isdn_audio.c drivers/isdn/i4l/isdn_tty.c drivers/isdn/i4l/isdn_ttyfax.c drivers/isdn/icn/icn.c drivers/isdn/isdnloop/isdnloop.c drivers/isdn/pcbit/edss1.c drivers/isdn/pcbit/layer2.c drivers/isdn/sc/command.c drivers/isdn/sc/message.c drivers/isdn/sc/shmem.c drivers/isdn/sc/timer.c drivers/net/3c527.c drivers/net/82596.c drivers/net/hamradio/6pack.c drivers/net/hamradio/dmascc.c drivers/net/hamradio/mkiss.c drivers/net/irda/toshoboe.c drivers/net/ni5010.c drivers/net/ni65.c drivers/net/pcmcia/nmclan_cs.c drivers/net/sk_mca.c drivers/net/tulip/xircom_tulip_cb.c drivers/net/wan/comx-hw-comx.c drivers/net/wan/comx-hw-locomx.c drivers/net/wan/comx-hw-mixcom.c drivers/net/wan/comx.c drivers/net/wan/sdla.c drivers/net/wan/sdla_x25.c drivers/net/wan/x25_asy.c drivers/scsi/AM53C974.c drivers/scsi/mca_53c9x.c =========================================== sti conversions: 14 files =========================================== drivers/cdrom/cdu31a.c drivers/cdrom/cm206.c drivers/cdrom/sbpcd.c drivers/cdrom/sonycd535.c drivers/char/esp.c drivers/char/ftape/lowlevel/fdc-isr.c drivers/char/ftape/lowlevel/ftape-io.c drivers/char/generic_serial.c drivers/char/isicom.c drivers/i2c/i2c-elektor.c drivers/isdn/act2000/act2000_isa.c drivers/isdn/hysdn/boardergo.c drivers/isdn/hysdn/hysdn_sched.c drivers/net/wan/cosa.c John
schmurtz@netcourrier.com wrote:
>
> I'm still getting oops when loading aha152x..
Does this fix it?
(This patch is also in the linux-scsi tree. James, is a merge planned
soon?)
From: Martin Diehl <lists@mdiehl.de>
Seems there are two problems:
* interrupt handler expects to find the host in aha152x_host[] array which
is currently set too late after probing irq's
* despite testing for NULL swintr derefences a shpnt==NULL anyway, looks
like a victim of HOSTNO obfuscation ;-)
The patch below fixes the issue for me - succesfully tested to compile,
load and even use my attached scanner.
drivers/scsi/aha152x.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff -puN drivers/scsi/aha152x.c~aha152x-oops-fix drivers/scsi/aha152x.c
--- 25/drivers/scsi/aha152x.c~aha152x-oops-fix 2003-06-26 18:38:55.000000000 -0700
+++ 25-akpm/drivers/scsi/aha152x.c 2003-06-26 18:38:55.000000000 -0700
@@ -941,7 +941,8 @@ static irqreturn_t swintr(int irqno, voi
struct Scsi_Host *shpnt = lookup_irq(irqno);
if (!shpnt) {
- printk(KERN_ERR "aha152x%d: catched software interrupt %d for unknown controller.\n", HOSTNO, irqno);
+ /* no point using HOSTNO here! */
+ printk(KERN_ERR "aha152x: catched software interrupt %d for unknown controller.\n", irqno);
return IRQ_NONE;
}
@@ -1049,6 +1050,10 @@ struct Scsi_Host *aha152x_probe_one(stru
printk(KERN_INFO "aha152x%d: trying software interrupt, ",
shost->host_no);
+
+ /* need to have host registered before triggering any interrupt */
+ aha152x_host[registered_count] = shost;
+ mb();
SETPORT(DMACNTRL0, SWINT|INTEN);
mdelay(1000);
free_irq(shost->irq, shost);
@@ -1064,7 +1069,7 @@ struct Scsi_Host *aha152x_probe_one(stru
printk(KERN_ERR "aha152x%d: IRQ %d possibly wrong. "
"Please verify.\n", shost->host_no, shost->irq);
- goto out_release_region;
+ goto out_unregister_host;
}
printk("ok.\n");
@@ -1077,12 +1082,12 @@ struct Scsi_Host *aha152x_probe_one(stru
"aha152x", shost) < 0) {
printk(KERN_ERR "aha152x%d: failed to reassign interrupt.\n",
shost->host_no);
- goto out_release_region;
+ goto out_unregister_host;
}
-
- aha152x_host[registered_count] = shost;
return shost; /* the pcmcia stub needs the return value; */
+out_unregister_host:
+ aha152x_host[registered_count] = NULL;
out_release_region:
release_region(shost->io_port, IO_RANGE);
out_unregister:
_
On Fri, 2003-07-11 at 12:53, Andrew Morton wrote:
> (This patch is also in the linux-scsi tree. James, is a merge planned
> soon?)
Yes, I'm just testing the scsi-misc tree now.
James
I should have looked in linux-scsi. Yes it does fix it. Thank you. -- S
Russell King <rmk@arm.linux.org.uk> said:
[...]
> The major problem is that embedded developers only care about what
> works for them and what they can provide to their customers. Once
> that's done, they don't have any interest in cleaning stuff up nor
> feeding obvious bug fixes back up.
I think this is rather uncivilized behaviour. Somebody called the work
invested in the general infrastructure or just donating money "watering the
garden". If they don't do that, they have no right to wonder later why it
dried up.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Thu, 10 Jul 2003, Linus Torvalds wrote:
> Ok. This is it. We (Andrew and me) are going to start a "pre-2.6" series,
> where getting patches in is going to be a lot harder. This is the last
> 2.5.x kernel, so take note.
The AMD PCscsiII chip, commonly referred to as AM53C974, and supported
in 2.4 by two drivers, am53c974 and tmscsim, still isn't working with
2.5.75, neither driver compiles (built-in). (This is on akpm's must-fix v6.)