Linux v2.5.40 - and a feature freeze reminder

Linux v2.5.40 - and a feature freeze reminder

[Linus Torvalds]

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 <ahaas@neosoft.com>:
  o C99 designated initializers for bfs, minix, efs, openpromfs,
    ramfs, exportfs, devpts, romfs, proc, isofs, ufs, cramfs

Alex Williamson <alex_williamson@attbi.com>:
  o fs/partitions/sun.c: raid autodetect for sun disk labels

<andmike@us.ibm.com>:
  o Error handler general clean up

Bart Schuymer <bart.de.schuymer@pandora.be>:
  o net/bridge/br_input.c: Missing read_unlock

<bzeeb-lists@lists.zabbadoz.net>:
  o fix endless loop walking the MADT

Dave Jones <davej@codemonkey.org.uk>:
  o trivial bits
  o Various trivial module related fixes
  o include fix

Rolf Fokkens <fokkensr@fokkensr.vertis.nl>:
  o sg.c and USER_HZ, kernel 2.5.37

Jeff Dike <jdike@uml.karaya.com>:
  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

<jeffs@accelent.com>:
  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 <jes@trained-monkey.org>:
  o acenic net drvr bug fix: remove '=' typo in intr mask argument to
    writel()

Dominik Brodowski <linux@brodo.de>:
  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 <pwaechtler@mac.com>:
  o oss sound cli cleanup

Randy Dunlap <randy.dunlap@verizon.net>:
  o hc_sl811 build and memory leak

<rscott@attbi.com>:
  o [ARM PATCH] 1243/1: Add support for Ceiva Photoframe, part2:
    machine specifics (fixed) Adds machine specific support for Ceiva
    Photoframe. Affects:

Sam Ravnborg <sam@mars.ravnborg.org>:
  o Remove unused clean: target in various makefiles Simple cleanup,
    kbuild does not use distributed clean target, so bettet get rid of
    them.

<schoenfr@gaaertner.de>:
  o net/ipv4/proc.c: Dont print dummy member of icmp_mib

<yoshfuji@linux-ipv6.org>:
  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 <viro@math.psu.edu>:
  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 <akpm@digeo.com>:
  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 <acme@conectiva.com.br>:
  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 <ch@hpl.hp.com>:
  o [ARM PATCH] 1255/1: [PATCH] SA-1111 PCI support for USB Fixes
    several oopsen in the SA-1111 "fake" PCI support

David Brownell <david-b@pacbell.net>:
  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 <david@gibson.dropbear.id.au>:
  o Fix: Orinoco driver update
  o Squash warning in fs/devfs/base.c

David Mosberger <davidm@napali.hpl.hp.com>:
  o avoid reference to struct page before it's declared

David S. Miller <davem@nuts.ninka.net>:
  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 <gilbertd@treblig.org>:
  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 <edward_peng@dlink.com.tw>:
  o update sundance driver to support building on older kernel

Greg Kroah-Hartman <greg@kroah.com>:
  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 <hirofumi@mail.parknet.co.jp>:
  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 <mingo@elte.hu>:
  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 <perex@suse.cz>:
  o ALSA updates [1-10: 2002/06/24 - 2002/08/05 ]

Javier Achirica <achirica@ttd.net>:
  o airo wireless net drvr: add Cisco MIC support Conditionally enabled
    when out-of-tree, but open source, crypto lib is present.

Jeff Garzik <jgarzik@mandrakesoft.com>:
  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 <axboe@suse.de>:
  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 <kai@tp1.ruhr-uni-bochum.de>:
  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

kai.makisara@kolumbus.fi <Kai.Makisara@kolumbus.fi>:
  o SCSI tape driver locking fixes

Linus Torvalds <torvalds@home.transmeta.com>:
  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 <mdharm-usb@one-eyed-alien.net>:
  o USB-storage: problem clearing halts

Matthew Wilcox <willy@debian.org>:
  o remove GFP_NFS
  o Remove QDIO_BH

Nicolas Pitre <nico@cam.org>:
  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 <zaitcev@redhat.com>:
  o [sparc]: defconfig update
  o [sparc] Stalingrad for kbuild army
  o [sparc] Suppress warnings in srmmu printks

Russell King <rmk@arm.linux.org.uk>:
  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 <urban@teststation.com>:
  o wait_event_interruptible_timeout
  o SMB Unix Extensions
  o might_sleep fixes

Wim Van Sebroeck <wim@iguana.be>:
  o i8xx documentation
  o i8xx: new PCI ids
  o i810-tco update

Re: Linux v2.5.40 - and a feature freeze reminder

[DevilKin]

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

Re: Linux v2.5.40 - and a feature freeze reminder

[jbradford]

> > 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.

Re: Linux v2.5.40 - and a feature freeze reminder

[Linus Torvalds]

In article <200210010939.53707.devilkin-lkml@blindguardian.org>,
DevilKin  <devilkin-lkml@blindguardian.org> 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

Re: Linux v2.5.40 - and a feature freeze reminder

[Thomas Molina]

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.  

Re: Linux v2.5.40 - and a feature freeze reminder

[DevilKin]

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 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.

Re: Linux v2.5.40 - and a feature freeze reminder

[Gregoire Favre]

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:greg@ulima.unil.ch

Re: Linux v2.5.40 - and a feature freeze reminder

[Jens Axboe]

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

Re: Linux v2.5.40 - and a feature freeze reminder

[Alan Cox]

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 ?

Re: Linux v2.5.40 - and a feature freeze reminder

[jlnance]

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

Re: Linux v2.5.40 - and a feature freeze reminder

[Denis Vlasenko]

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

Re: Linux v2.5.40 - and a feature freeze reminder

[Dave Jones]

On Tue, Oct 01, 2002 at 08:25:04AM -0400, jlnance@intrex.net 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 (vojtech@suse.cz) know about it.

The biggest problems (all?) in this area should be long gone now.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

Re: Linux v2.5.40 - and a feature freeze reminder

[Vojtech Pavlik]

On Tue, Oct 01, 2002 at 08:25:04AM -0400, jlnance@intrex.net 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

Re: Linux v2.5.40 - and a feature freeze reminder

[Adrian Bunk]

On Tue, 1 Oct 2002, Linus Torvalds wrote:

>...
> Summary of changes from v2.5.39 to v2.5.40
> ============================================
>...
> Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>:
>...
>   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

Re: Linux v2.5.40 - and a feature freeze reminder

[Kai Germaschewski]

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

Re: Linux v2.5.40 - and a feature freeze reminder

[Christoph Hellwig]

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.

Re: Linux v2.5.40 - and a feature freeze reminder

[Chris Wedgwood]

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)

Re: Linux v2.5.40 - and a feature freeze reminder

[Linus Torvalds]

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

Re: Linux v2.5.40 - and a feature freeze reminder

[Alexander Viro]

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...

Re: Linux v2.5.40 - and a feature freeze reminder

[Linus Torvalds]

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

Re: Linux v2.5.40 - and a feature freeze reminder

[Jens Axboe]

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

Re: Linux v2.5.40 - and a feature freeze reminder

[Andries Brouwer]

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

Re: Linux v2.5.40 - and a feature freeze reminder

[Peter Osterlund]

Linus Torvalds <torvalds@transmeta.com> writes:

> Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>:
>   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 - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: Linux v2.5.40 - and a feature freeze reminder

[Kai Germaschewski]

On 6 Oct 2002, Peter Osterlund wrote:

> Linus Torvalds <torvalds@transmeta.com> writes:
> 
> > Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>:
> >   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

Re: Linux v2.5.40 - and a feature freeze reminder

[Peter Osterlund]

Linus Torvalds <torvalds@transmeta.com> 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 - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: Linux v2.5.40 - and a feature freeze reminder

[Linus Torvalds]

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

Re: Linux v2.5.40 - and a feature freeze reminder

[Hans Reiser]

>  

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 ;]
>
>  
>

Re: Linux v2.5.40 - and a feature freeze reminder

[Chris Wedgwood]

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

Re: Linux v2.5.40 - and a feature freeze reminder

[Peter Chubb]

>>>>> "Christoph" == Christoph Hellwig <hch@infradead.org> 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				    peterc@gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories, all almost the same.

Re: Linux v2.5.40 - and a feature freeze reminder

[James H. Cloos Jr.]

[-- Attachment #1: Type: text/plain, Size: 223 bytes --]

>>>>> "Markus" == Markus Weiss <mweiss38@gmx.net> writes:

Markus> I also would love to test on my laptop (especially because of
Markus> ACPI), but I have / on LVM :-(
 
I got this reply to my recent, similar note:

-JimC


[-- Attachment #2: Type: message/rfc822, Size: 610 bytes --]

From: Daniel Berlin <dberlin@dberlin.org>
To: "James H. Cloos Jr." <cloos@jhcloos.com>
Subject: Re: ide-scsi, 1394-sbp2 and usb-storage scsi host ids
Date: Mon, 30 Sep 2002 00:28:19 -0400 (EDT)

> I can't test 2.5 on this box, as /home, /opt, /tmp, /usr, /var and
> swap are all in LVM1.

Use EVMS CVS with 2.5, and enable the LVM support it includes.

Works great for me under 2.5.38.

You just have to remember to mount (or set up devfsd/whatever to 
create the right symlinks for you) /dev/evms/lvm/<whatever> instead of 
/dev/<whatever>.

--Dan

Re: Linux v2.5.40 - and a feature freeze reminder

[Markus Weiss]

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

Re: Linux v2.5.40 - and a feature freeze reminder

[Nils O. =?ISO-8859-1?Q?Sel=E5sdal=22?= <noselasd@Utel.no>]

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