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
<[email protected]>
o kobject: add kobject_rename() Based on a patch written by Dan Aloni
<[email protected]>
o driver core: added class_device_rename() Based on a patch written
by Dan Aloni <[email protected]>
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 ([email protected]) 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 ([email protected]) 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 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 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, 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
Linus Torvalds <[email protected]> writes:
>
> 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.
No ppc, ppc64, s390?
Current bad issues for x86-64:
- IDE Taskfile IO when enabled corrupts file systems on AMD8111
(on others too?). This is the worst because there is no fix available.
I would propose to completely disable taskfile in Kconfig
until the issue is resolved.
- Reiserfs zeroes every second 4K block in any write >4K on 64bit systems
(patch is in -mm*). Hopefully the patch can be merged before 2.6-pre.
and
- doesn't compile (trivial fixes are already sent)
-Andi
On 11 Jul 2003, Andi Kleen wrote:
>
> Linus Torvalds <[email protected]> writes:
> >
> > 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.
>
> No ppc, ppc64, s390?
Do we have distributions that intend to make releases using those? I
suspect not, but hey, don't get me wrong: I'd love to see them working
out-of-the-box.
It's purely a matter of priorities. The only architecture that really
_has_ to be stable is x86. Others are determined largely by whether they
get their own testing done, and companies and individuals being willing to
put the resources down.
Linus
El 10 Jul 2003 16:40:29 -0700 Robert Love <[email protected]> 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
Linus Torvalds writes:
> On 11 Jul 2003, Andi Kleen wrote:
> >
> > Linus Torvalds <[email protected]> writes:
> > >
> > > 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.
> >
> > No ppc, ppc64, s390?
>
> Do we have distributions that intend to make releases using those? I
> suspect not, but hey, don't get me wrong: I'd love to see them working
> out-of-the-box.
SuSE has a ppc64 version of their enterprise server edition and I
think they include ppc32 kernels too. Terrasoft does a distribution
aimed at powermac users. Mandrake and Gentoo have ppc versions of
their distributions. And of course there is Debian/PPC, which is what
I use. I think ppc and ppc64 have well and truly eclipsed alpha and
sparc, in terms of the size of the market for distributions, by now.
In fact ppc and ppc64 are in pretty good shape in your tree as far as
the desktop and server machines are concerned.
Paul.
Diego Calleja Garc?a wrote:
>El 10 Jul 2003 16:40:29 -0700 Robert Love <[email protected]> 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.
On Thu, Jul 10, 2003 at 05:12:43PM -0700, Linus Torvalds wrote:
> Do we have distributions that intend to make releases using those? I
> suspect not, but hey, don't get me wrong: I'd love to see them working
> out-of-the-box.
RH AS and SLES support s390 and ppc64. OTOH their trees are
patched to death so who cares :)
ppc32 is pretty important as lots of kernel developers love mac
hardware. (Writing this from an ibook..)
On 2003-07-11T09:42:28,
Christoph Hellwig <[email protected]> said:
> > Do we have distributions that intend to make releases using those? I
> > suspect not, but hey, don't get me wrong: I'd love to see them working
> > out-of-the-box.
> RH AS and SLES support s390 and ppc64. OTOH their trees are
> patched to death so who cares :)
We'd like to avoid that nightmare for 2.6 though, so we definetely
care.
Sincerely,
Lars Marowsky-Br?e <[email protected]>
--
SuSE Labs - Research & Development, SuSE Linux AG
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
-- Capt. Edward A. Murphy -- Louis Pasteur
On Fri, Jul 11, 2003 at 12:27:28PM +0200, Lars Marowsky-Bree wrote:
> We'd like to avoid that nightmare for 2.6 though, so we definetely
> care.
I don't know who "we" is, but SuSE/RH managment certainly doesn't
act like that by ACKed every bloody feature request from big blue
and friends..
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 -- [email protected]
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 -- [email protected]
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: http://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
On Fri, 11 Jul 2003, Lars Marowsky-Bree wrote:
>
> We'd like to avoid that nightmare for 2.6 though, so we definetely
> care.
Hey, all the better. However, in that case I'd strongly suggest up the
management chain that people be aware of the fact that if they want 2.6.x
to be stable on anything but x86, it will need testing. Both internally
and externally. By doing things like running all the internal machines on
a pre-2.6 kernel.
The same is true of x86 too, but there at least there will be test
coverage even without vendor support. Vendors making their own internal
distributions with pre-2.6 kernels will help on x86 too, of course. Hint
hint.
(Late 2.3.x got much better coverage through things like this, so I'm not
all that pessimistic. But people need to be aware of the issue).
Linus
On Fri, 2003-07-11 at 18:52, Linus Torvalds wrote:
\
> The same is true of x86 too, but there at least there will be test
> coverage even without vendor support. Vendors making their own internal
> distributions with pre-2.6 kernels will help on x86 too, of course. Hint
> hint.
fwiw there are rpms of 2.5.75 that fit in Red Hat Linux 9 (plus updated
modutils, initscripts and mkinitrd from rawhide) on
http://people.redhat.com/arjanv/2.5
for people to play with.
(the files in this location will gets updated regularly)
[email protected] 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 <[email protected]>
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 <[email protected]> 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
Linus Torvalds wrote:
>>
>> No ppc, ppc64, s390?
>
> Do we have distributions that intend to make releases using those? I
> suspect not, but hey, don't get me wrong: I'd love to see them working
> out-of-the-box.
At the moment, the s390 port is fully merged and functional (~30 known bugs,
more to be found) in the your tree, something that has never been the
case in 2.2 or 2.4.
I expect to see an official debian kernel for s390 2.6.early without any
architecture specific patches. The commercial distributions are likely
to remain some more time on 2.4.{19,21}, actually there are probably more
people still running 2.4.7 than 2.4.19 on s390...
Arnd <><
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.)
Arjan van de Ven <[email protected]> said:
[...]
> fwiw there are rpms of 2.5.75 that fit in Red Hat Linux 9 (plus updated
> modutils, initscripts and mkinitrd from rawhide) on
> http://people.redhat.com/arjanv/2.5
> for people to play with.
Where are the non-kernel files? A kernel RPM on itself is not enough... and
for me at least ((semi-)regular bk-kernel tester) the least useful.
--
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
Horst von Brand wrote:
> Arjan van de Ven <[email protected]> said:
>
> [...]
>
>
>>fwiw there are rpms of 2.5.75 that fit in Red Hat Linux 9 (plus updated
>>modutils, initscripts and mkinitrd from rawhide) on
>>http://people.redhat.com/arjanv/2.5
>>for people to play with.
>
>
> Where are the non-kernel files? A kernel RPM on itself is not enough... and
> for me at least ((semi-)regular bk-kernel tester) the least useful.
rawhide, like arjan said :)
Pick your favorite rawhide mirror.
Jeff