Merges with all the regular suspects - Al's partitioning, Andrew on VM,
USB, networking, sparc, net drivers. And Ingo has been working on fixing
up the inevitable details in the thread signal stuff, as well as updating
the smp-scalable timer code.
And ISDN, kbuild, ARM, uml...
And a small reminder that we're now officially in the last month of
features, and since I'm going to be away basically the last week of
October, so I actually personally consider Oct 20th to be the drop-date,
unless you've got a really good and scary costume.. So don't try to leave
it to the last day.
[ And if that didn't worry you, the following should: I'm perfectly happy
with the kernel, and as such whatever features _you_ think are missing
might just not weigh too much with me if you then also make the mistake
of trying to leave them for the last crunch. I might just take the last
day off too ;]
And if it wasn't clear to the non-2.5-development people out there, yes
you _should_ also test this code out even before the freeze. The IDE layer
shouldn't be all that scary any more, and while there are still silly
things like trivially non-compiling setups etc, it's generally a good idea
to try things out as widely as possible before it's getting too late to
complain about things..
Linus
----
Summary of changes from v2.5.39 to v2.5.40
============================================
Art Haas <[email protected]>:
o C99 designated initializers for bfs, minix, efs, openpromfs,
ramfs, exportfs, devpts, romfs, proc, isofs, ufs, cramfs
Alex Williamson <[email protected]>:
o fs/partitions/sun.c: raid autodetect for sun disk labels
<[email protected]>:
o Error handler general clean up
Bart Schuymer <[email protected]>:
o net/bridge/br_input.c: Missing read_unlock
<[email protected]>:
o fix endless loop walking the MADT
Dave Jones <[email protected]>:
o trivial bits
o Various trivial module related fixes
o include fix
Rolf Fokkens <[email protected]>:
o sg.c and USER_HZ, kernel 2.5.37
Jeff Dike <[email protected]>:
o UML updates to allow it to build and run as 2.5.38
o Cleaned up arch/um/Makefile and updated the ubd driver
o Trivial fix to the ubd driver
o One last fix to the ubd driver, allowing UML to boot
o Bumped EXTRAVERSION for the 2.4 fixes and highmem support
o Added highmem support to uml
o Fixed highmem support for 2.5
o Missed a change to fixmap.h in the highmem update
o Updated to build with the 2.5.39 kbuild
o One last fix to make the non-highmem build work
o Added CONFIG_HIGHMEM to defconfig
o Moved the linker script from vmlinux.lds.S, which will be empty, to
uml.ld.S.
o main.o needed to be added to the vmlinux dependencies so it would
build
<[email protected]>:
o [ARM PATCH] 1238/1: Accelent PXA IDP config cleanups This patch
brings support for the PXA-IDP up to 2.5.30, plus adds support in
head.S for low level serial debugging support.
James Bottomley <jejb@mulgrave.(none)>:
o [SCSI 53c700] flag as able to do I/O from highmem
Jes Sorensen <[email protected]>:
o acenic net drvr bug fix: remove '=' typo in intr mask argument to
writel()
Dominik Brodowski <[email protected]>:
o (1/5) CPUfreq core
o (2/5) CPUfreq i386 core
o (3/5) CPUfreq i386 drivers
o (4/5) CPUfreq Documentation
o (5/5) CPUfreq /proc/sys/cpu/ add-on patch
o CPUfreq i386 drivers update
o cpufreq bugfixes
o cpufreq crashes on P4
Peter W?chtler <[email protected]>:
o oss sound cli cleanup
Randy Dunlap <[email protected]>:
o hc_sl811 build and memory leak
<[email protected]>:
o [ARM PATCH] 1243/1: Add support for Ceiva Photoframe, part2:
machine specifics (fixed) Adds machine specific support for Ceiva
Photoframe. Affects:
Sam Ravnborg <[email protected]>:
o Remove unused clean: target in various makefiles Simple cleanup,
kbuild does not use distributed clean target, so bettet get rid of
them.
<[email protected]>:
o net/ipv4/proc.c: Dont print dummy member of icmp_mib
<[email protected]>:
o net/ipv6/addrconf.c: Refine IPv6 Address Validation Timer
o net/ipv6/ndisc.c: Add missing credits
o net/ipv6/ip6_fib.c: Default route support on router
Alexander Viro <[email protected]>:
o gendisks list switched to list_head
o get_gendisk() prototype change
o floppy fixes
o ubd fixes
o register_disk() unexported
o >major_name inlined
o alloc_disk/put_disk
Andrew Morton <[email protected]>:
o Fix uninitialized swapper_space lists
o additional might_sleep checks
o kmem_cache_destroy fix
o Documentation/vm/hugetlbpage.txt
o get_user_pages PageReserved fix
o move_one_page kmap atomicity fix
o fix uninitialised vma list_head
o add /proc/buddyinfo
o remove free_area_t typedef
o per-node kswapd instances
o in-kernel topology API
o topology API updates
o scsi_initialise_merge_fn() will only set highio if ->type ==
TYPE_DISK
Arnaldo Carvalho de Melo <[email protected]>:
o [X25] simplify facility negotiation
o [X25] fix thinko in x25_facilities
o LLC: remove unused list_head from llc_opt & use rw_lock_init for
rwlocks
o X25: Simplify ioctl code, CodingStyle cleanups
o X25: use refcounts and protect x25_route list
o LLC: rename llc_sock.c to af_llc.c
o X25: use refcnts and protect x25_neigh structs and list
o X25: protect x25 sockets and list with refcnt and rwlock
o X25: x25_wait_for_{data,connection_establishemnt} and the death
of the last cli/sti pair in X.25
o LAPB: use refcounts and rwlock to protect lapb_cb and list
o lapbether: get rid of cli/sti, use refcnts for devs, etc
o LLC: CONFIG_LLC_UI is really a bool, not a tristate
o LLC: make it clear that Appletalk and IPX needs LLC
o LLC: make sure llc.o is linked before the datalink protos when
!module
o LLC: kill mac_send_pdu, use plain dev_queue_xmit
Christopher Hoover <[email protected]>:
o [ARM PATCH] 1255/1: [PATCH] SA-1111 PCI support for USB Fixes
several oopsen in the SA-1111 "fake" PCI support
David Brownell <[email protected]>:
o Sleeping function called from illegal context
o usbcore misc cleanup
o ehci-hcd, urb queuing
o ohci-hcd, paranoia
o usb_sg_{init,wait,cancel}()
David Gibson <[email protected]>:
o Fix: Orinoco driver update
o Squash warning in fs/devfs/base.c
David Mosberger <[email protected]>:
o avoid reference to struct page before it's declared
David S. Miller <[email protected]>:
o [ALSA]: Add some missing includes
o [ALSA]: Fix ioctl32 build on sparc64
o [ALSA]: Add SBUS dma support
o [ALSA]: Add AMD7930 and CS4231 Sparc drivers
o [SPARC]: Blow away old sbus audio layer
o sound/i2c/i2c.c: Include linux/errno.h
o sound/core/seq/seq_midi_emul.c: Include linux/string.h
o sound/i2c/i2c.c: Include linux/string.h
o sound/synth/util_mem.c: Include asm/semaphore.h
o sound/synth/util_mem.c: Revert previous change
o include/sound/core.h: Always include linux/sched.h and
asm/semaphore.h
o sound/pci/emu10k1/emufx.c: Pass bitops pointer correctly
o [SPARC]: Comment out DBRI option/rules until driver is converted
o arch/sparc64/defconfig: Update
o sound/sparc/cs4231.c: Fix probing bugs
o [SPARC]: OOPS, ffs return value is off by one :-)
o sound/sparc/cs4231.c: Fix register offsets
o sound/core/oss/mixer_oss.c: Use SIOC_{IN,OUT}
o [SPARC64]: Rework all EBUS DMA support
o arch/sparc64/kernel/pci_schizo.c: Enable error interrupts in
correct PBM
o [SPARC]: sigmask_lock --> sig->siglock
o [SPARC]: Rename private init_timers to sparc{,64}_init_timers
o drivers/input/keyboard/sunkbd.c: queue_task --> schedule_task
o drivers/net/ethertap.c: Use C99 initializers
o sound/sparc/cs4231.c: Include sound/pcm_params.h
o sound/pci/cs46xx/dsp_spos.c: Include linux/vmalloc.h
Dr. David Alan Gilbert <[email protected]>:
o [ARM PATCH] 1257/1: Helpful comment in stat.h Hi, For reasons of
great complexity I found out the hard way that the kernel must (and
does) zero the pad sections in the stat structures.
o [ARM PATCH] 1260/1: Fix comment in nwfpe Hi, I believe the comment
in the nwfpe fpopcodes is slightly wrong - although a 2nd pair of
eyes on this would be a good idea.
Edward Peng <[email protected]>:
o update sundance driver to support building on older kernel
Greg Kroah-Hartman <[email protected]>:
o USB: queue_task() fixups
o USB: added Palm Zire id to the visor driver, thanks to Martin
Brachtl
o driver core: added location of device in driverfs tree to
/sbin/hotplug call
o USB: add a lot more driverfs files for all usb devices
o USB: Fix the name of usb hubs in driverfs
o USB: allow /sbin/hotplug to be called for the main USB device
o USB: fix typo from previous schedule_task() patch
Hirofumi Ogawa <[email protected]>:
o use fff/ffff/fffffff instead of ff8/fff8/ffffff8 for EOF of FAT
o remove fat_search_long() in vfat_add_entry()
Ingo Molnar <[email protected]>:
o sigfix-2.5.39-A1
o futex-fix-2.5.39-A1
o signal delivery to thread groups bugfix
o thread-group SIGSTOP handling
o atomic-thread-signals
o smptimers, old BH removal, tq-cleanup
o tq-cleanup module compile
o tq_struct removal fixups
o sigfix-2.5.39-D0, BK-curr
Jaroslav Kysela <[email protected]>:
o ALSA updates [1-10: 2002/06/24 - 2002/08/05 ]
Javier Achirica <[email protected]>:
o airo wireless net drvr: add Cisco MIC support Conditionally enabled
when out-of-tree, but open source, crypto lib is present.
Jeff Garzik <[email protected]>:
o sundance net drvr: fix reset_tx logic (contributed by Edward Peng @
D-Link, cleaned up by me)
o sundance net drvr: fix DFE-580TX packet drop issue, further
reset_tx fixes (contributed by Edward Peng @ D-Link)
o sundance net drvr: bump version to LK1.05
o [net drivers] fix MII lib force-media ethtool path (contributed by
Edward Peng @ D-Link)
o sis900 net driver update
o [net drivers] MII lib update
o [net drivers] Rename MII lib API member,
s/duplex_lock/force_media/, and update all drivers that reference
this struct member.
o Add helper function generic_mii_ioctl to MII lib, use it in 8139cp
net drvr
o Use new MII lib helper generic_mii_ioctl in several net drivers
o [net drivers] Remove 'dev' argument from generic_mii_ioctl helper
o [net drivers] add optional duplex-changed arg to generic_mii_ioctl
helper
o [net drivers] update hamachi.c and starfire.c to use MII lib
o Use schedule_task() in tlan net driver, fixing build
o Include linux/tqueue.h in orinoco[_cs] net drvrs, fixing build
(contributed by James Blackwell)
o Use do_gettimeofday() in ATM drivers (contributed by Francois
Romieu)
o Replace local var in 8139cp net driver that was accidentally
removed, due to synchronize_irq() becoming a no-op when
!CONFIG_SMP.
Jens Axboe <[email protected]>:
o request_irq() use GFP_ATOMIC
o add function to set q->merge_bvec_fn
o don't BUG() on too big a bio
o make loop set right queue restrictions
o raid5 BIO_UPTODATE set
o loop clear q->queuedata on exit
o set ide pci dma mask
Kai Germaschewski <[email protected]>:
o ISDN: cleanup ISDN net / ioctl code
o ISDN: Move CISCO HDLCK protocol into separate file
o ISDN: More cleanup to isdn_net.c (X.25 / PPP)
o ISDN: Move net_device setup to a type-specific method
o ISDN: 'ethernet over ISDN' cleanups
o ISDN: net_device->header for CISCO HDLC
o ISDN: net_device->header for syncPPP and UI HDLC
o ISDN: net_device->header for IPTYP
o ISDN: separate out 'ethernet over ISDN' receive function
o ISDN: separate out IPTYP receive function
o ISDN: separate out RAWIP receive function
o ISDN: separate out CISCO HDLC receive function
o ISDN: separate out IPTYP receive function
o ISDN: finish separating out receive functions
o ISDN: Use a function pointer for type-specific receive
o ISDN: Use a function pointer for type-specific connected() callback
o ISDN: Use a function pointer for type-specific disconnected()
callback
o ISDN: inline function for testing if interface is bound
o ISDN: Put slot index of reserved channel into ->exclusive
o ISDN: exclusive handling in isdn_net_force_dial_lp()
o ISDN: Share code for initiating dial out
o ISDN: Use net/ethernet/eth.c eth_rebuild_header()
o ISDN: Remove ISDN_NET_CONNECTED flags
o ISDN: unclutter isdn_net_find_icall()
o ISDN: Introduce generic bind/unbind callbacks
o kbuild: Make scripts/Configure follow the definition of 'int'
o kbuild: Fix typo for 'tags' target
o kbuild: Make KBUILD_VERBOSE=0 work better under emacs
o ISDN: Use a struct to describe types of ISDN net interfaces
o ISDN: Introduce generic init/cleanup callbacks
o ISDN: Use ether_setup() for ethernet over ISDN only
o ISDN: Add close()/open() callbacks to ISDN net interface
implementation
o ISDN: Move "name" member from isdn_net_local to isdn_net_dev
o ISDN: Move dial/channel related members to isdn_net_dev
o ISDN: Move ppp-specifics to isdn_net_dev
o ISDN: Move dial/hangup related stuff to isdn_net_dev
[email protected] <[email protected]>:
o SCSI tape driver locking fixes
Linus Torvalds <[email protected]>:
o Remove more tmp-file on clean (introduced with kallsyms)
o Fix "make mrproper" that broke when the files pattern matched a
directory pattern. Clean directories _first_, then files.
o Fix broken whitespacing in PPC Makefile
o Make sure the "devices" list is initialized in isapnp_device_driver
o All .tmp* files are auto-generated
Matthew Dharm <[email protected]>:
o USB-storage: problem clearing halts
Matthew Wilcox <[email protected]>:
o remove GFP_NFS
o Remove QDIO_BH
Nicolas Pitre <[email protected]>:
o [ARM PATCH] 1302/1: ARMv5 optimized findbit Question: is there any
reason to do all this with byte access rather than word access
besides alignment issues? Word access would be much faster.
o [ARM PATCH] 1293/1: fix to the ARM optimized strchr() Two bugs
here:
Pete Zaitcev <[email protected]>:
o [sparc]: defconfig update
o [sparc] Stalingrad for kbuild army
o [sparc] Suppress warnings in srmmu printks
Russell King <[email protected]>:
o free_irq docs
o [ARM] Add Thumb syscall stubs and drop gcc asm workarounds
o [ARM] Move PHYS_TO_NID() to asm/memory.h When
CONFIG_DISCONTIGMEM=n, we define PHYS_TO_NID(x) to zero in each
architecture specific file. This cset moves it into the generic
ARM code.
o [ARM] Put back the CPU MM context switch avoidence test
o [ARM] Thumb fixes This cset fixes a set of problems discovered
while developing KLIBC with Thumb support. We now allow pure Thumb
executables, and prevent such executables from being run on
non-Thumb code aware CPUs.
o [ARM] Always decend into compressed and bootp subdirectories
o [ARM] Make "bootp" Image generation know that the zImage is now PIC
o [ARM] Fix XScale "feature" XScale does not guarantee that CPU
control register writes complete their side effects immediately.
In fact, Intel give sample code to demonstrate a way to ensure that
the effect of the write has occurred.
o Since irq_exit() now deals with softirqs, irq_enter and irq_exit
must be located at the top level of the interrupt handler.
o [ARM] Remove old AMBA KMI driver information
o [ARM] Fix up initcall ordering ARM machine support gets initialised
too late in the initialisation
o [ARM] Provide hook for FP emulators to know when a new thread is
created This allows FP emulators to take their FP initialisation
out of the hot path.
o [ARM] Move machine config questions into machine class subdirs This
cset moves a fair amount of per-machine questions into their
relevant machine class subdirectory, making arch/arm/config.in
easier on the eyes.
o [ARM] Update nwfpe to use new fp_init hook
o [ARM] Don't continue to process pending interrupts after
disable_irq() This solves a problem whereby the generic interrupt
code repeatedly called an interrupt handler, even though the
interrupt handler had called disable_irq().
o [ARM] Parse initrd information early We need the initrd location
before the normal command line parsing
o [ARM] Add DC21285 decompressor debug support
o [ARM] 2.5.34 update Update for changes in mainline 2.5.3[01234].
o [ARM] Unify integer register usage passed into FP module
o [ARM] NWFPE updates for new entry conditions
o [ARM] Remove keyboard.h includes and some generic ARM keyboard bits
o [ARM] Bring asm/setup.h and asm/unistd.h into line with main ARM
tree This removes some minor differences between Linus' tree and
the main ARM tree; comment clarification and some weird formatting.
o [ARM] Correct the usage of __FUNCTION__ to make gcc happy
o [ARM] Update PCI host bridge drivers for GregKH PCI cleanups
o [ARM] Don't return a value from ptrace_set_bpt() The return value
from ptrace_set_bit() is never used. This cset makes it a void
function.
o [ARM] Fix up export-objs for clps711x, integrator and sa1100 (From
Thunder)
o [ARM] Cleanup Ceiva merge
o [ARM] Add kmap_types.h and percpu.h
o [ARM] Fix clps711x and ftvpci LEDs initialisation
o [ARM] Fix assabet backlight and power supply settings
o [ARM] Update SA1111 core and related drivers for LDM
o [ARM] Add LDM suspend/resume support to SA1100 suspend code
o [ARM] Remove "struct device" from sa1111_init() callers This didn't
follow the LDM model correctly. The SA1111 is always a device on
the root bus.
o [ARM] sa1100fb updates Update sa1100fb for recent fbcon changes,
and move stork LCD power handling into machine specific file.
o [ARM] Update cpufreq related sa1100 related drivers and CPU code
This cset updates sa1100 code for the now merged cpufreq next-gen.
o [ARM] Fix sa1111 IRQ handling We must clear down all currently
pending IRQs before servicing any IRQ on the chip. This prevents
immediate recursion into the interrupt handling paths when we
service the first IRQ.
o [ARM] Prevent namespace clash with IRq numbering Add "IRQ_" prefix
to these sa1111 irq numbers.
o [ARM] General cleanups/missed bits in previous csets This corrects
spelling mistakes, adds missed configuration for cpufreq, corrects
free_irq comment, etc.
o [ARM] iPAQ updates from Jamey Hicks
Urban Widmark <[email protected]>:
o wait_event_interruptible_timeout
o SMB Unix Extensions
o might_sleep fixes
Wim Van Sebroeck <[email protected]>:
o i8xx documentation
o i8xx: new PCI ids
o i810-tco update
On Tuesday 01 October 2002 09:32, Linus Torvalds wrote:
<snip>
> And if it wasn't clear to the non-2.5-development people out there, yes
> you _should_ also test this code out even before the freeze. The IDE layer
> shouldn't be all that scary any more, and while there are still silly
> things like trivially non-compiling setups etc, it's generally a good idea
> to try things out as widely as possible before it's getting too late to
> complain about things..
Basically: I would _love_ to test this kernel on my laptop here, but -
unfortunately - i need the laptop for my work. Which means i need it to work.
So how much chance IS there to trash the filesystems? I guess a lot of ppl
like me are just waiting to test it out, but aren't willing to screw their
systems over it...
DK
--
There's no easy quick way out, we're gonna have to live through our
whole lives, win, lose, or draw.
-- Walt Kelly
> > And if it wasn't clear to the non-2.5-development people out there, yes
> > you _should_ also test this code out even before the freeze. The IDE layer
> > shouldn't be all that scary any more, and while there are still silly
> > things like trivially non-compiling setups etc, it's generally a good idea
> > to try things out as widely as possible before it's getting too late to
> > complain about things..
>
> Basically: I would _love_ to test this kernel on my laptop here, but -
> unfortunately - i need the laptop for my work. Which means i need it to work.
>
> So how much chance IS there to trash the filesystems? I guess a lot of ppl
> like me are just waiting to test it out, but aren't willing to screw their
> systems over it...
There is not much chance.
The only thing that can be guaranteed is that if nobody tests 2.5.x out, then 2.6.x will definitely have trivial bugs in it.
John.
In article <[email protected]>,
DevilKin <[email protected]> wrote:
>
>Basically: I would _love_ to test this kernel on my laptop here, but -
>unfortunately - i need the laptop for my work. Which means i need it to work.
>
>So how much chance IS there to trash the filesystems? I guess a lot of ppl
>like me are just waiting to test it out, but aren't willing to screw their
>systems over it...
Personal opinion (and only that): not much chance for a filesystem
trashing.
There's more chance of something just not _working_ than of disk
corruption. Ie you may find that some driver you need doesn't compile
because it hasn't been updated to the new world order yet, for example.
And people still report problems booting, for example, whatever the
reason. So make sure you have a working choice in your lilo
configuration or whatever.
But from what we've seen lately, there really aren't reports of
corrupted disks or anything like that that I've seen. Which is
obviously not to say that it couldn't happen, but it's not a very likely
occurrence.
That said, I can't set other peoples risk bars for them.
Linus
On Tue, 1 Oct 2002, Linus Torvalds wrote:
> But from what we've seen lately, there really aren't reports of
> corrupted disks or anything like that that I've seen. Which is
> obviously not to say that it couldn't happen, but it's not a very likely
> occurrence.
I'll echo what Linus says, FWIW. I'm carrying several ide-related
problems on my problem report status page
(http://members.cox.net/tmolina/kernprobs/status.html)
but they are all related to different bits loading/unloading incorrectly.
I've not seen a single report of data corruption on the 2.4-ac forward ported ide
code.
On Tuesday 01 October 2002 10:23, Thomas Molina wrote:
> On Tue, 1 Oct 2002, Linus Torvalds wrote:
> > But from what we've seen lately, there really aren't reports of
> > corrupted disks or anything like that that I've seen. Which is
> > obviously not to say that it couldn't happen, but it's not a very likely
> > occurrence.
>
> I'll echo what Linus says, FWIW. I'm carrying several ide-related
> problems on my problem report status page
> (http://members.cox.net/tmolina/kernprobs/status.html)
> but they are all related to different bits loading/unloading incorrectly.
> I've not seen a single report of data corruption on the 2.4-ac forward
> ported ide code.
OK Neato, i'll give it a spin. Well, as soon as I can get my hands on a 2.5.40
kernel, which seem to be quite unavailable as http://www.kernel.org seems to be
down, and it ain't synced towards the mirrors yet.
DK
--
The Abrams' Principle:
The shortest distance between two points is off the wall.
On Tue, Oct 01, 2002 at 12:32:47AM -0700, Linus Torvalds wrote:
> And if it wasn't clear to the non-2.5-development people out there, yes
> you _should_ also test this code out even before the freeze.
I haven't tested 40, but 39 works pretty well at home, just two minor
more or less related problems:
where could I learn how to adapt Makefile for the post (more or less)
2.5.21 kernels?
And is xawtv or other TV programm supposed to work (I have a DVB-s and
didn't manage using TV prog with it...)?
As soon as I found a 40 anywhere, I'll give a try ;-)
Have a great day,
Gr?goire
________________________________________________________________
http://ulima.unil.ch/greg ICQ:16624071 mailto:[email protected]
In fa.linux.kernel, you wrote:
>> > And if it wasn't clear to the non-2.5-development people out there, yes
>> > you _should_ also test this code out even before the freeze. The IDE layer
>> > shouldn't be all that scary any more, and while there are still silly
>> > things like trivially non-compiling setups etc, it's generally a good idea
>> > to try things out as widely as possible before it's getting too late to
>> > complain about things..
>>
>> Basically: I would _love_ to test this kernel on my laptop here, but -
>> unfortunately - i need the laptop for my work. Which means i need it to work.
>>
>> So how much chance IS there to trash the filesystems? I guess a lot of ppl
>> like me are just waiting to test it out, but aren't willing to screw their
>> systems over it...
>
> There is not much chance.
>
> The only thing that can be guaranteed is that if nobody tests 2.5.x out, then 2.6.x
> will definitely have trivial bugs in it.
Which reminds me, I was testing 2.5.39 yesterday on a 433MHz x86, 224Mb ram.
I felt this was abit like some of the 2.4.7-2.4.9 kernels i once ran:
too happy swapping things out. Having mozilla and evolution in the background
while compiling some large projects, or doing lots of file copying
caused most of mozilla and evolution to be swapped out, and thus the desktop felt
alot slower than e.g. 2.4.19.
Other issue, it took me about 2 hours to figure out that it was enabling preemtion
that caused the kernel not to boot.
--
Vennlig hilsen/Best Regards
Nils Olav Sel?sdal
System Engineer
UtelSystems a/s
Tlf: +47 370 45 431
w w w . u t e l s y s t e m s . c o m
On 1 October 2002 05:32, Linus Torvalds wrote:
> Merges with all the regular suspects - Al's partitioning, Andrew on VM,
> USB, networking, sparc, net drivers. And Ingo has been working on fixing
> up the inevitable details in the thread signal stuff, as well as updating
> the smp-scalable timer code.
>
> And ISDN, kbuild, ARM, uml...
>
> And a small reminder that we're now officially in the last month of
> features, and since I'm going to be away basically the last week of
> October, so I actually personally consider Oct 20th to be the drop-date,
> unless you've got a really good and scary costume.. So don't try to leave
> it to the last day.
>
> [ And if that didn't worry you, the following should: I'm perfectly happy
> with the kernel, and as such whatever features _you_ think are missing
> might just not weigh too much with me if you then also make the mistake
> of trying to leave them for the last crunch. I might just take the last
> day off too ;]
>
> And if it wasn't clear to the non-2.5-development people out there, yes
> you _should_ also test this code out even before the freeze. The IDE layer
> shouldn't be all that scary any more, and while there are still silly
> things like trivially non-compiling setups etc, it's generally a good idea
> to try things out as widely as possible before it's getting too late to
> complain about things..
I think those people who has two boxes and an eth link can test 2.5 on NFS
root mode since 2.5 does not contain big changes to NFS code and it's harder
to corrupt filesystems over NFS ;-). Problems? Just use that Big Red Switch!
(don't forget to write down oops first though ;-)
I personally would do that too, once it would compile for me.
BTW, where's netconsole patches for 2.5, just in case?
--
vda
On Tue, Oct 01 2002, Thomas Molina wrote:
> On Tue, 1 Oct 2002, Linus Torvalds wrote:
>
> > But from what we've seen lately, there really aren't reports of
> > corrupted disks or anything like that that I've seen. Which is
> > obviously not to say that it couldn't happen, but it's not a very likely
> > occurrence.
>
> I'll echo what Linus says, FWIW. I'm carrying several ide-related
> problems on my problem report status page
> (http://members.cox.net/tmolina/kernprobs/status.html)
broken floppy driver
should be fixed in 2.5.40
ide double init
fixed (2.5.39, I think)
oops in ide_toggle_bounce
fixed in 2.5.40
--
Jens Axboe
On Tue, 2002-10-01 at 08:32, Linus Torvalds wrote:
> And a small reminder that we're now officially in the last month of
> features, and since I'm going to be away basically the last week of
> October, so I actually personally consider Oct 20th to be the drop-date,
> unless you've got a really good and scary costume.. So don't try to leave
> it to the last day.
Are we going to 32bit dev_t for 2.6 - thats one decision someone does
have to make the call on still I believe ?
On Tuesday 01 October 2002 09:32, Linus Torvalds wrote:
<snip>
> And if it wasn't clear to the non-2.5-development people out there, yes
> you _should_ also test this code out even before the freeze. The IDE layer
> shouldn't be all that scary any more, and while there are still silly
> things like trivially non-compiling setups etc, it's generally a good idea
> to try things out as widely as possible before it's getting too late to
> complain about things..
I also would love to test on my laptop (especially because of ACPI),
but I have / on LVM :-(
Any info, when I might be able to get a 2.5 kernel running ?
Thanks,
Markus
--
Werden Sie mit uns zum "OnlineStar 2002"! Jetzt GMX w?hlen -
und tolle Preise absahnen! http://www.onlinestar.de
On Tue, Oct 01, 2002 at 12:32:47AM -0700, Linus Torvalds wrote:
> And if it wasn't clear to the non-2.5-development people out there, yes
> you _should_ also test this code out even before the freeze. The IDE layer
> shouldn't be all that scary any more, and while there are still silly
> things like trivially non-compiling setups etc, it's generally a good idea
> to try things out as widely as possible before it's getting too late to
> complain about things..
Do the ps/2 mouse and the keyboard work like they did in 2.4 (same /dev
major/minor)? I tried 2.5 early on but quit because I couldnt see my
input devices. At the time I posted a note and got some responses, but
it appeared that I would have to change things around such that they
wouldnt work with 2.4 anymore, which I was not willing to do.
Thanks,
Jim
On Tue, Oct 01, 2002 at 08:25:04AM -0400, [email protected] wrote:
> Do the ps/2 mouse and the keyboard work like they did in 2.4 (same /dev
> major/minor)? I tried 2.5 early on but quit because I couldnt see my
> input devices. At the time I posted a note and got some responses, but
> it appeared that I would have to change things around such that they
> wouldnt work with 2.4 anymore, which I was not willing to do.
There are several new CONFIG_ options you need to configure to get
keyboard/mouse working in 2.5. Asides from this, everything has
'just worked' for me. There are some keyboards out there that are
still having slight problems, but Vojtech is working his way through
these.
If anyone is still having "keyboard/mouse doesn't work" problems in 2.5
after enabling the relevant CONFIG_ options, enable the DEBUG defines
in i8042.c, and let Vojtech ([email protected]) know about it.
The biggest problems (all?) in this area should be long gone now.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
On Tue, Oct 01, 2002 at 08:25:04AM -0400, [email protected] wrote:
> On Tue, Oct 01, 2002 at 12:32:47AM -0700, Linus Torvalds wrote:
>
> > And if it wasn't clear to the non-2.5-development people out there, yes
> > you _should_ also test this code out even before the freeze. The IDE layer
> > shouldn't be all that scary any more, and while there are still silly
> > things like trivially non-compiling setups etc, it's generally a good idea
> > to try things out as widely as possible before it's getting too late to
> > complain about things..
>
> Do the ps/2 mouse and the keyboard work like they did in 2.4 (same /dev
> major/minor)? I tried 2.5 early on but quit because I couldnt see my
> input devices. At the time I posted a note and got some responses, but
> it appeared that I would have to change things around such that they
> wouldnt work with 2.4 anymore, which I was not willing to do.
If you enable enough options they work interchangeably with 2.4, yes.
--
Vojtech Pavlik
SuSE Labs
On Tue, 1 Oct 2002, Linus Torvalds wrote:
>...
> Summary of changes from v2.5.39 to v2.5.40
> ============================================
>...
> Kai Germaschewski <[email protected]>:
>...
> o kbuild: Make KBUILD_VERBOSE=0 work better under emacs
>...
This change is broken, it has the effect that compilation no longer stops
when the compilation of a .c file fails, kbuild doesn't stop the
compilation until it misses the .o when linking, e.g. (the directory is
still called "2.5.39" because I forgot to change the name after applying
patch-2.5.40 but this is 2.5.40):
<-- snip -->
...
gcc -Wp,-MD,./.idt77252.o.d -D__KERNEL__
-I/home/bunk/linux/kernel-2.5/linux-2
.5.39-full/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2
-fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=k6 -I/home/bunk/linux/kernel-2.5/linux-2.5.39-full/arch/i386/mach-generic
-nostdinc -iwithprefix include -g -DKBUILD_BASENAME=idt77252 -c -o
idt77252.o idt77252.c
drivers/atm/idt77252.c: In function `alloc_scq':
drivers/atm/idt77252.c:669: warning: unsigned int format, different type arg (arg 5)
drivers/atm/idt77252.c: In function `idt77252_interrupt':
drivers/atm/idt77252.c:2899: warning: implicit declaration of function `queue_task'
drivers/atm/idt77252.c:2899: `tq_immediate' undeclared (first use in this function)
drivers/atm/idt77252.c:2899: (Each undeclared identifier is reported only once
drivers/atm/idt77252.c:2899: for each function it appears in.)
drivers/atm/idt77252.c:2900: warning: implicit declaration of function `mark_bh'
drivers/atm/idt77252.c:2900: `IMMEDIATE_BH' undeclared (first use in this function)
gcc -Wp,-MD,./.idt77105.o.d -D__KERNEL__ -I/home/bunk/linux/kernel-2.5/linux-2
.5.39-full/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2
-fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe
-mpreferred-stack-boundary=2 -march=k6
-I/home/bunk/linux/kernel-2.5/linux-2.5.39-full/arch/i386/mach-generic
-nostdinc -iwithprefix include -g -DKBUILD_BASENAME=idt77105 -c -o
idt77105.o idt77105.c
...
gcc -Wp,-MD,./.fore200e_pca_fw.o.d -D__KERNEL__
-I/home/bunk/linux/kernel-2.5/
linux-2.5.39-full/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2
-fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe
-mpreferred-stack-boundary=2 -march=k6
-I/home/bunk/linux/kernel-2.5/linux-2.5.39-full/arch/i386/mach-generic
-nostdinc -iwithprefix include -g -DKBUILD_BASENAME=fore200e_pca_fw
-c -o fore200e_pca_fw.o fore200e_pca_fw.c
ld -m elf_i386 -r -o fore_200e.o fore200e.o fore200e_pca_fw.o
ld -m elf_i386 -r -o built-in.o atmdev_init.o eni.o suni.o zatm.o
uPD98402.o
nicstar.o idt77252.o idt77105.o horizon.o ambassador.o atmtcp.o iphase.o
firestream.o lanai.o fore_200e.o
ld: cannot open idt77252.o: No such file or directory
make[2]: *** [built-in.o] Error 1
make[2]: Leaving directory `/home/bunk/linux/kernel-2.5/linux-2.5.39-full/drivers/atm'
<-- snip -->
cu
Adrian
--
You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
Alan Cox
On Tue, 1 Oct 2002, Adrian Bunk wrote:
> This change is broken, it has the effect that compilation no longer stops
> when the compilation of a .c file fails, kbuild doesn't stop the
> compilation until it misses the .o when linking, e.g. (the directory is
> still called "2.5.39" because I forgot to change the name after applying
> patch-2.5.40 but this is 2.5.40):
Grrr, you're right, I keep forgetting about this annoying property of
piping the output. BTW, the patch also has another bug, it shouldn't
affect the (default) KBUILD_VERBOSE=1 case at all, but it does.
Have to think of a sensible fix.
--Kai
On Tue, Oct 01, 2002 at 12:32:47AM -0700, Linus Torvalds wrote:
> you _should_ also test this code out even before the freeze. The IDE layer
> shouldn't be all that scary any more, and while there are still silly
> things like trivially non-compiling setups etc, it's generally a good idea
> to try things out as widely as possible before it's getting too late to
> complain about things..
What about the 64bit sector_t (aka >2TB blockdevice) patches. IMHO they're
a must-have for 2.6 (people already ask for backporting them to 2.4..) and
last time I check Peter had a BK tree with nicely split changesets.
On Tue, Oct 01, 2002 at 10:14:21PM +0100, Christoph Hellwig wrote:
> What about the 64bit sector_t (aka >2TB blockdevice) patches. IMHO
> they're a must-have for 2.6 (people already ask for backporting them
> to 2.4..) and last time I check Peter had a BK tree with nicely
> split changesets.
Indeed. I *really* would like to see this.
Consider a super-cheap IDE raid setup, 8x320GB drives for a single
filesystem. This means the files-system starts are 2.1TB (raid5, more
with raid0) and if you want to grow it...
--cw (who has lots of DVDs to stream about the house)
>>>>> "Christoph" == Christoph Hellwig <[email protected]> writes:
Christoph> On Tue, Oct 01, 2002 at 12:32:47AM -0700, Linus Torvalds
Christoph> wrote:
>> you _should_ also test this code out even before the freeze. The
>> IDE layer shouldn't be all that scary any more, and while there are
>> still silly things like trivially non-compiling setups etc, it's
>> generally a good idea to try things out as widely as possible
>> before it's getting too late to complain about things..
Christoph> What about the 64bit sector_t (aka >2TB blockdevice)
Christoph> patches. IMHO they're a must-have for 2.6 (people already
Christoph> ask for backporting them to 2.4..) and last time I check
Christoph> Peter had a BK tree with nicely split changesets.
Indeed... And I'm trying to merge it all now into 2.5.40. Sorry I've
been a bit slow --- testing, especially error testing when disks fill
up, takes a long time (How long does it take to write 4 TB to a disk?
About a day with the machines I have here. Multiply that by three
(now four with XFS) filesystems to test...)
--
Dr Peter Chubb [email protected]
You are lost in a maze of BitKeeper repositories, all almost the same.
On Wed, Oct 02, 2002 at 09:06:07AM +1000, Peter Chubb wrote:
> Indeed... And I'm trying to merge it all now into 2.5.40. Sorry
> I've been a bit slow --- testing, especially error testing when
> disks fill up, takes a long time (How long does it take to write 4
> TB to a disk? About a day with the machines I have here. Multiply
> that by three (now four with XFS) filesystems to test...)
With XFS, if you don't care about the file contents, you can create
very larges (multi-TB) non-sparse files more or less instantly.
If you want code for this, let me know and I'll hack something
together.
--cw
On Tue, 1 Oct 2002, Christoph Hellwig wrote:
>
> What about the 64bit sector_t (aka >2TB blockdevice) patches.
I think we should do both 64-bit sector_t and 32-bit dev_t, although both
of them depend on how horrible the code ends up being. Example patches?
Linus
On Tue, 1 Oct 2002, Linus Torvalds wrote:
>
> On Tue, 1 Oct 2002, Christoph Hellwig wrote:
> >
> > What about the 64bit sector_t (aka >2TB blockdevice) patches.
>
> I think we should do both 64-bit sector_t and 32-bit dev_t, although both
> of them depend on how horrible the code ends up being. Example patches?
Umm... Speaking of 32bit dev_t, I'd rather do it right way. We _do_ have
a very real chance to kill all per-major arrays in a couple of weeks.
Both for block and character devices.
Basically, we can get rid of the notions of major and minor. With the stuff
already in place we can easily do CIDR equivalent - I have such patches and
they work nicely. Probable sequence:
* switch to dynamic allocation of gendisks (large part will go
in a couple of hours, the rest - later tonight).
* refcounting for gendisks [~3Kb patch]
* caching of pointer to gendisk in bdev->bd_disk
* killing majority of get_gendisk() calls [~20Kb]
* introduction of blk_register_area() and removal of kludge in genhd.c;
switching blk_set_probe() users to final mechanism ([~15Kb patch])
* using it to deal with remaining deadlocks in modular ide, etc.
* addition of gendisk->queue poitner, setting it for all gendisks.
* defining QUEUE to local variable in all drivers that still use it.
* killing blk_dev[] array.
* switching set_device_ro() to gendisk *.
* moving read-only/read-write state into gendisk.
* killing the last remaining array.
At that point block devices are OK. Moreover, blk_register_area() can be
easily abstracted into mechanism common for block and character devices,
but in any case character devices are much easier...
On Tue, 1 Oct 2002, Alexander Viro wrote:
>
> Umm... Speaking of 32bit dev_t, I'd rather do it right way.
Hey, if you drive that part, I'll be very happy.
I don't doubt you can fix up the block device handling quite nicely by
now, but I worry about all the other crud, including how to make the
interfaces be backwards-compatible etc, and making sure we convert
correctly in all the right places.
The explicit dev_t<->kdev_t conversion has fixed only a subset of the
problems, and we still use dev_t as keys into things (ie we have this
notion that two different dev_t never map to the same "bdev *", for
example - which totally breaks aliases etc).
There's also all the user-level interfaces for dev_t, and the disk layout
interfaces used by various filesystems.
We can easily make kdev_t be 32-bit, but without a 32-bit dev_t that
doesn't help much.
Linus
On Tue, Oct 01 2002, Linus Torvalds wrote:
>
> On Tue, 1 Oct 2002, Christoph Hellwig wrote:
> >
> > What about the 64bit sector_t (aka >2TB blockdevice) patches.
>
> I think we should do both 64-bit sector_t and 32-bit dev_t, although both
> of them depend on how horrible the code ends up being. Example patches?
Peter had patches for 64-bit sector_t, and they looked pretty nice.
Definitely mergeable. Peter, do you have a recent version?
--
Jens Axboe
On Tue, Oct 01, 2002 at 08:12:28PM -0700, Linus Torvalds wrote:
> There's also all the user-level interfaces for dev_t, and the disk layout
> interfaces used by various filesystems.
>
> We can easily make kdev_t be 32-bit, but without a 32-bit dev_t that
> doesn't help much.
There is no real problem. You know I did this several times
and also sent patches at various points in time. Asking Google yields
http://www.uwsg.iu.edu/hypermail/linux/kernel/0103.3/0038.html
as the first reference, and it has all relevant details and an example patch.
(There was a discussion about 32 vs 64 bits. Of course 64 is better
in all respects, but it is no longer feasible so today it must be 32.
Too bad.)
Andries
Linus Torvalds <[email protected]> writes:
> Kai Germaschewski <[email protected]>:
> o kbuild: Make KBUILD_VERBOSE=0 work better under emacs
This change has the unfortunate side effect that compilation doesn't
stop after a compile error if I run make without arguments. I observed
this when enabling debugging in yenta.c. Building with "make
KBUILD_VERBOSE=1" does stop after the error.
I'm using make 3.79.1 on a RH73 system.
p4:~/kernel/linus/main/linux$ make drivers/pcmcia/yenta.o
make[1]: Entering directory `/home/petero/kernel/linus/main/linux/drivers/pcmcia'
gcc -Wp,-MD,./.yenta.o.d -D__KERNEL__ -I/home/petero/kernel/linus/main/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i586 -I/home/petero/kernel/linus/main/linux/arch/i386/mach-generic -nostdinc -iwithprefix include -DKBUILD_BASENAME=yenta -DEXPORT_SYMTAB -c -o yenta.o yenta.c
drivers/pcmcia/yenta.c: In function `cb_readl':
drivers/pcmcia/yenta.c:42: parse error before string constant
[cut]
drivers/pcmcia/yenta.c:118: parse error before string constant
make[1]: Leaving directory `/home/petero/kernel/linus/main/linux/drivers/pcmcia'
p4:~/kernel/linus/main/linux$ echo $?
0
p4:~/kernel/linus/main/linux$ make KBUILD_VERBOSE=1 drivers/pcmcia/yenta.o
make[1]: Entering directory `/home/petero/kernel/linus/main/linux/drivers/pcmcia'
gcc -Wp,-MD,./.yenta.o.d -D__KERNEL__ -I/home/petero/kernel/linus/main/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i586 -I/home/petero/kernel/linus/main/linux/arch/i386/mach-generic -nostdinc -iwithprefix include -DKBUILD_BASENAME=yenta -DEXPORT_SYMTAB -c -o yenta.o yenta.c
yenta.c: In function `cb_readl':
yenta.c:42: parse error before string constant
[cut]
yenta.c:118: parse error before string constant
make[1]: *** [yenta.o] Error 1
make[1]: Leaving directory `/home/petero/kernel/linus/main/linux/drivers/pcmcia'
make: *** [drivers/pcmcia/yenta.o] Error 2
p4:~/kernel/linus/main/linux$ echo $?
2
p4:~/kernel/linus/main/linux$
--
Peter Osterlund - [email protected]
http://w1.894.telia.com/~u89404340
On 6 Oct 2002, Peter Osterlund wrote:
> Linus Torvalds <[email protected]> writes:
>
> > Kai Germaschewski <[email protected]>:
> > o kbuild: Make KBUILD_VERBOSE=0 work better under emacs
>
> This change has the unfortunate side effect that compilation doesn't
> stop after a compile error if I run make without arguments. I observed
> this when enabling debugging in yenta.c. Building with "make
> KBUILD_VERBOSE=1" does stop after the error.
Right. Fixed in Linus' bk tree.
--Kai
Linus Torvalds <[email protected]> writes:
> Merges with all the regular suspects - Al's partitioning, Andrew on VM,
> USB, networking, sparc, net drivers.
My PCMCIA network card no longer works. During boot, I see this
message:
ds: no socket drivers loaded
It worked in 2.5.39. Also this patch helps, although I don't
understand why it is now needed:
--- linux/drivers/pcmcia/ds.c.old Sun Oct 6 01:00:38 2002
+++ linux/drivers/pcmcia/ds.c Sun Oct 6 00:53:23 2002
@@ -894,9 +894,9 @@
* Ugly. But we want to wait for the socket threads to have started up.
* We really should let the drivers themselves drive some of this..
*/
current->state = TASK_INTERRUPTIBLE;
- schedule_timeout(HZ/10);
+ schedule_timeout(HZ/4);
pcmcia_get_card_services_info(&serv);
if (serv.Revision != CS_RELEASE_CODE) {
printk(KERN_NOTICE "ds: Card Services release does not match!\n");
--
Peter Osterlund - [email protected]
http://w1.894.telia.com/~u89404340
On 6 Oct 2002, Peter Osterlund wrote:
>
> My PCMCIA network card no longer works. During boot, I see this
> message:
>
> ds: no socket drivers loaded
>
> It worked in 2.5.39. Also this patch helps, although I don't
> understand why it is now needed:
The PCMCIA code does initializations in the wrong order, and
asynchronously (ie from multiple different threads). And init_pcmcia_ds()
really depends on the actual low-level drivers having had time to
register, since the PCMCIA code never had any sane way to inform the DS
layer that a new client driver had registered.
Thus the delay by init_pcmcia_ds() - to give time for drivers to
initialize. And the yenta driver needs some time.. That time apparently
went up a bit, probably due to the tq/work changes.
The _right_ thing to do is to not have init_pcmcia_ds() depend on
low-level drivers being initialized, but instead do that DS thing
_early_, and then when each driver initializes it would tell the DS layer.
But that's not how the PCMCIA code was organized..
Linus
>
Wouldn't it make more sense, or at least be more fair, to move the
deadline in the other direction if you are going on vacation/away?
We're going to have trouble getting reiser4 ready before the Halloween
date you announced, and we are working long hours as it is. reiser4 is
dramatically better and dramatically faster than reiserfs.
Hans
Linus Torvalds wrote:
>
>And a small reminder that we're now officially in the last month of
>features, and since I'm going to be away basically the last week of
>October, so I actually personally consider Oct 20th to be the drop-date,
>unless you've got a really good and scary costume.. So don't try to leave
>it to the last day.
>
>[ And if that didn't worry you, the following should: I'm perfectly happy
> with the kernel, and as such whatever features _you_ think are missing
> might just not weigh too much with me if you then also make the mistake
> of trying to leave them for the last crunch. I might just take the last
> day off too ;]
>
>
>
Hi
> Wouldn't it make more sense, or at least be more fair, to move the
> deadline in the other direction if you are going on vacation/away?
> We're going to have trouble getting reiser4 ready before the Halloween
> date you announced, and we are working long hours as it is. reiser4 is
> dramatically better and dramatically faster than reiserfs.
Well, that only means you need your scary costume :-). PS:try to write your message after text you quote.