Ok so the PS/2 bug is real and the megaraid mystery continues
Anything which isnt a strict bug fix or previously agreed is now 2.2.19
material.
Alan
2.2.18pre21
o Environment controller update for sparc (Eric Brower)
o No italian translation for config.help (Andrea Ferraris)
o Fix type error in buz driver (Pete Zaitcev)
o Resnchronize Apple PowerMac codebase (Paul Mackerras & co)
o Merge powermac tree fixes into usb
o Powermac input device handling changes
o Fix console switch fonts
o S/390 merge (IBM S/390 folks)
(Merge grunt work done by Kurt Roeckx)
o Make knfsd TCP an option (me)
o Drop cisco info packets (0x2000) (Ivan Passos)
o Add belkin USB serial cable (William Greathouse)
2.2.18pre20
o Fix ide-probe SMP build error (Ian Morgan)
o Fix appletalk physical layer ioctl handling (Andi Kleen)
o Sparc update (Dave Miller)
o Update Stephen Tweedie's contact info (Stephen Tweedie)
o Fix typo in esp and scsi_obsolete code (Dave Miller)
o Bonding ioctl check fix (Willy Tarreau)
o Fix ipv6 procfs bug (Al Viro)
o Report PIV in proc as family 15 and uname as (me)
model 6 as discussed
o Redo Intel cache decodes as code not tables (me)
and add new ones (based on updates by
Asit Mallick & Andrew Ip)
o Fix CMOS locking in machine_power_off paths (me)
o Create build tree symlinks only if insmod is
new enough not to be confused by it (Keith Owens)
o Fix cmsg handling (Philippe Troin)
o Tiny xpds driver changes (Dan Hollis)
o Fix vmalloc sign bug (Ben LaHaise)
o SMBFS fixes/changes for find_next problems and (Urban Widmark)
to avoid truncate bug in netapps
o Fix ntfs translation bug (Anton Altaparmakov)
o Fix sparc problem with some soundcards and the (Jeff Garzik)
_IOC magic
o Update ppa driver to v2.05 (Tim Waugh)
2.2.18pre19
o Fix transproxy socket lookup (Val Henson)
o Add ICS1893 PHY to the SiS900 driver (Lei-Chun Chang)
o Fix documentation error in matroxfb (Vsevolod Sipakov)
o Update IDE floppy maintainer (Paul Bristow)
o Fix remaining cmos locking (Paul Gortmaker)
o Fix sparc bitfield/compiler bits on sound (Dave Miller)
o Update Pegasus USB driver (Petko Manolov)
o Networking updates - move divert header (Andi Kleen)
o Add ETH_P_ATM* defines (Matti Aarnio)
o Fix one more missing GFP_KERNEL/sk->allocation (Dave Miller)
o Fix ISDN multilink handler bug (Kai Germaschewski)
o Fix ymfpci unload cases (Kai Germaschewski)
2.2.18pre18
o Fix off by one in net/ipv4/proc (Dave Miller)
o Move the fpu emu patch that got away (Dave Miller)
o K6 update for MTRR ability (Dave Jones)
o Fix raid1/vm deadlock (Marcelo Tosatti)
o Fix usb mouse userspace memory accesses (David Woodhouse)
o Fix xpdsl if compiled in (typo) (Arjan van de Ven)
o Rio fixes for modem handling. Fix a small (Patrick van de Lageweg)
generic serial bug
o IBMtr driver fixes for cable pulls, pcmcia (Burt Silverman,
behaviour etc Mike Sullivan)
o Tidy up /dev/microcode messages (Daniel Roesen)
o Add arpfilter (Andi Kleen)
o IDE floppy updates for clik support, cleanups (Paul Bristow)
o Fix irongate handling on Alpha (Soohoon Lee)
o Fix HZ=100 assumption in aha152x.c (me)
o Fix power management handling in i810 audio (me)
(From an ALSA fix by Godmar Back)
o Put the NFS block default back to 4K (Trond Myklebust)
o Fix misleading comment in printk code (Riley Williams)
o Fix fbcon scroll back/paste bug (Herbert Xu)
o Fix rtc_lock for ide-probe, and hd.c (Richard Johnson)
o Backport of 2.4 PR_GET/SET_KEEPCAPS (Brian Brunswick)
(from Chris Evans 2.4 code)
o LRU list corruption fix (Andrea Arcangeli)
o Initial gcc 2.96+ support for kernel building (H J Lu)
| Not a recommended compiler for production kernels...
o ALI silence clearing fix (Ching-Ling Lee)
o Fix remaining old-style use of copy_strings (Solar Designer)
o Better pci_resource_start macro for 2.2 (Jeff Garzik)
o Fix nbd deadlock (Marcelo Tosatti)
2.2.18pre17
o Move a few escaped m68k headers into the right (me)
directory
o Backport 2.4 AF_UNIX garbage collect speedups (Dave Miller)
o TCP fixes for NFS (Saadia Khan)
o Fix USB audio hangs (David Woodhouse)
o Sparc64 dcache and exec fixes (Dave Miller)
o Fix typing crap in divert.h (Jeff Garzik)
o Use pkt_type in diverter, add maintainer info (Dave Miller)
o Fix obscure NAT problem in FIB code (Dave Miller)
o Fix sk->allocation in TCP sendmsg (Marcelo Tossati)
o Elevator fixes (Andrea Arcangeli)
o Allow broken_suid on NFS root (Trond Myklebust)
o Fix net/ipv6/proc off by one bug (Dave Miller)
o Fix AGP oops on Alpha (Michal Jaegermann)
o MSR/CPUID init call fixes (Arjan van de Ven)
o CS4281 sound hang fixes (Thomas Woller)
o AX.25 comment updates, Joerg has moved email (Joerg Reuter)
2.2.18pre16
o Finally get the m68k tree merged (Andrew McPherson
and a cast of many)
o Bring the sparc back in line, make it build (Anton Blanchard)
o USB Bluetooth fixes/docs (Greg Kroah-Hartman)
o Fix auth_null credentials bug (Hai-Pao Fan)
o Update cpu flag names (Dave Jones)
o Console 'quiet' boot option as in 2.4 (Rusty Russell)
o Make the sx serial driver work again (Patrick van de Lageweg)
o Fix negotation on the SYM53C1010 (Gerard Roudier)
o Fix alpha loops per jiffy (Jay Estabrook)
o Fix pegasus to work with 2.2 kernels (Greg Kroah-Hartman)
o Update plusb driver for 2.2.x (Eric Ayers,
Deti Fliegl)
o Fix ohci to use __init (Greg Kroah-Hartman)
o /sbin/hotplug support for USB as in 2.4 (Greg Kroah-Hartman)
o Update ksymoops url (Keith Owens)
o Update the changes doc about gcc (Petri Kaukasoina)
o Fix AMD flag naming (Ulrich Windl)
o Restore old block size on devices after a
partition scan (needed for powermac for one) (Michael Schmitz)
o Fix GPL naming in SubmittingDrivers (Mike Harris)
o NFSv3 server patches merge (Dave Higgen)
o CS46xx changes (Nils Faerber)
o Fix sys_nanosleep for >4GHz CPU changes (me)
(Spotted by Ben Herrenschmidt)
o Fix pas rev D mixer (??)
o Fix multiple spelling errors (Andr? Dahlqvist)
o ISDN updates (Kai Germaschewski)
o XSpeed DSL driver (Timothy Lee,
Dan Hollis)
o IDE multi-lun/single-lun handling (Jens Axboe)
o Fix alpha generic trident sound support (Rich Payne)
o Fix PPC for loops per jiffy (Cort Dougan)
2.2.18pre15
o Default msdos behaviour to old (small) letters (me)
| An option 'big' goes with 'small'
o Fix define collision in cpqfc (Arjan van de Ven)
o Fix case where scripts/kwhich isnt executable (me)
o Alpha FPU divide fix (Richard Henderson)
o Add ADMtek985 to the tulip list (J Katz)
o Lose excess ymfpci debugging (Rob Landley)
o Fix i2c bus id clash (Russell King)
o Update the ARM vidc driver (Russell King)
o Update the ARM am79c961a driver (Russell King)
o Fix parport_pc build with no PCI (Russell King)
o Fix ARM memzero (Russell King)
o Update ARM for __init and __setup (Russell King)
o Update ARM to loops_per_jiffy (Russell King)
o Remove arm ecard debug messages (Russell King)
o Fix ARM makefiles (Russell King)
o Fix iph5526 driver to use mdelay (Arjan van de Ven)
o Fix epca, dtlk, aha152x loops_per_sec bits (Philipp Rumpf)
o Fix smp tlb invalidate and bogomip printing (Philipp Rumpf)
o Fix NLS warnings (Arjan van de Ven)
o Fix wavfront conversion to loops_per_jiffies (me)
o Fix an audio problem and a sanyo changer (Jens Axboe)
problem
o Fix include bug with divert (me)
| Alternate fix to Willy Tarreau's
o Fix Alpha for loops_per_jiffy (Willy Tarreau)
2.2.18pre14
o Reorder attributes in drm to work with gcc272 (me)
o GNU cross compilers are foo-bar-gcc (Russell King)
o Add extra strange pcnet32 ident (Willy Tarreau)
o Since no vendor can get which right.. use a (Miquel van Smoorenburg)
shell script instead
| Please nobody tell me this fails in some bash version!
o Should be using bash not bash2 (escaped debug) (Petri Kaukasoina)
o spin_unlock_irq wrong debug mode printk (Willy Tarreau)
o Fix pcxx for the loops changes (Arjan van de Ven)
o Fix ov511/via-rhine name clash (Arjan van de Ven)
o Fix bridge compile with loops_per_sec change (Mitch Adair)
o 8139too driver added (Jeff Garzik)
2.2.18pre13
o Change udelay to use loops_per tick (Philipp Rumpf)
| Otherwise we bomb out at 2GHz which isnt far enough
| away with 1.4/1.6GHz stuff due out RSN
o Fix drivers using big delays to use mdelay (me)
o Fix drivers that used loops_per_sec (Philipp Rumpf, me)
o Fix yamaha PCI sound SMP bug (Arjan van de Ven)
o Change to preferred USB init fix (David Rees)
o Fix rio fix (Arjan van de Ven)
o Catch the VT but no mouse case in init/main.c (Arjan van de Ven)
o Fix the 'which' compiler stuff (Horst von Brand,
Peter Samuelson)
| Can someone verify for me this works on Slackware and
| on Caldera ?
o Add devfs include. Devfs wont be going into 2.2 (Richard Gooch)
but this again makes it easier to do 2.2/2.4
drivers.
2.2.18pre12
o Fix cyrix MTRR handling bug (IIZUKA Daisuke)
o Fix ymfpci poll (me, Arjan)
o Update radio-maestro, add Configure.help (Adam Tla/lka>
o Fix rio/generic serial build bug (Marcelo Tossati)
o USB build bug fix (Arjan van de Ven)
o Fix missing ac97_codec.c return value (Arjan van de Ven)
o Fix several warnings (Arjan van de Ven)
o Made the PS/2 reconnect behaviour optional (me)
| Its now 'psaux-reconnect' on the boot line
o Allow for newer Hauppauge with 4 ports (Krischan Jodies)
o Switch sound drivers from library to object (Arjan van de Ven)
o Kill the not working ac97 lock on the 810 (me)
o Automatically select older compilers for kernel
builds on Debian and RH (Arjan van de Ven)
o Start volumes higher on ac97, teach the driver (Rui Sousa)
about 5bit and 6bit codec precision and use
the mute bit.
2.2.18pre11
o Kill bogus codec_id assignment (Linus Torvalds)
o Update codec init code to handle id right (me)
o Fix dead/clashing define for NFS (Trond Myklebust)
o Remove the find_vga crap from bttv (me)
o Fix return on probe failure for cadet (Arjan van de Ven)
o Add missing configure.help stuff from 2.4test (Alan Ford)
o Fix inia100/megaraid define clash (Arjan van de Ven)
o __xchg marked as taking volatiles (Arjan van de Ven)
o Fix vwsnd warning in sound core (Arjan van de Ven)
o wdt_pci driver should return -EIO on error (Arjan van de Ven)
o Fix init_adfs_fs warning (Arjan van de Ven)
o Fix the joystick driver option parsing (Arjan van de Ven)
o Update mkdep to handle // commenting (Mike Klar)
o Thunderlan driver typo fixes (Torben Mathiasen)
o Add KX133/KT133 stuff to the AGP/DRM (Jeff Nguyen)
o FIx multiple card bug in eepro driver (Aristeu Filho)
o Initial YMF PCI native driver (Pete Zaitcev)
| Based on Jaroslav's ALSA driver and I've tweaked it
| a bit and maybe broken it 8)
o Fix procfs unlink bugs (Willy Tarreau)
o X.25 bugfix backport (Henner Eisen)
o Fix incorrect free_dma on DMAless boxes (Boria)
o Fix via audio driver merge (Nick Lamb)
o Update plusb driver to 2.4 one (Greg Kroah-Hartman)
o Put description info in wacom driver (Greg Kroah-Hartman)
o Update both UHCI drivers to match 2.4test (Greg Kroah-Hartman)
o Masquerade cleanup/warning fixes (Horst von Brand)
2.2.18pre10
o Add printk level to partition printk messages (me)
o Fix bluesmoke address report/serialize (Andrea Arcangeli)
o Add 2.4pre CPUID/MSR docs to 2.2.18pre (Adrian Bunk)
o Update to the 2.4pre via audio driver (Jeff Garzik)
o Fix small SMP race in set_current_state (Andrea Arcangeli)
o Fix __KERNEL__ checks in sparc headers (Dave Miller)
o Fix ADFS root directory bug added in pre9 (Russell King)
o Trap incorrect swap partition sizes (Andries Brouwer)
o Fix nfsroot bootp/dhcp on sparc64 (Dave Miller)
o Tidy up tcp opt parsing (Dave Miller)
o Check range on port range sysctl (Dave Miller)
o Back out erroneous i2c.h change (Arjan van de Ven)
o Fix trident hangs due to over zealous addition (Eric Brombaugh)
of midi support
o Fix big endian/macro bug in ext2fs (Andi Kleen)
o Bring dabusb driver into line with 2.4 (Greg Kroah-Hartman)
o Bring event drivers into line with 2.4 (Franz Sirl,
Greg Kroah-Hartman)
o Fix usb help texts (Greg Kroah-Hartman)
o Generic frame diverter (Benoit Locher)
o Bring USB serial back into line with 2.4 (Greg Kroah-Hartman)
o Fix DVD driver rpc state bug (Jens Axboe)
o Fix extra sunrpc printk (Tim Mann)
o USB init tidy up (Greg Kroah-Hartman)
o Allow PlanB video on generic PPC (Michel Lanners)
o Doc fixes/trim cvs logs on isdn drivers (Kai Germaschewski)
o USB hid, hub, ibmcam, dsbr100 devices updates (Greg Kroah-Hartman)
o Return EAFNOSUPPORT for out of range families
o Fix SMP locking on floppy driver (Jonathan Corbet)
o Add module author info to acm.c (Greg Kroah-Hartman)
o Update CREDITS to reflect all the USB guys (Greg Kroah-Hartman)
o ipfw wrong allocation flag fix (Rusty Russell)
o Implement Sun style lockf/nfs cache barriers (Trond Myklebust)
o Updated ISI serial driver (Multitech)
| You may well need their newer firmware set/loader for the
| later cards too
2.2.18pre9
o Fix usb module load oops (Thomas Sailer)
o Bring USB boot drivers in line with 2.4t8 (Greg Kroah-Hartman)
o And USB print drivers (Greg Kroah-Hartman)
o And USB Rio driver (Greg Kroah-Hartman)
o And USB dc2xx driver (Greg Kroah-Hartman)
o And USB mdc800 driver (Greg Kroah-Hartman)
o NFSv3 support and NFS updates (Trond Myklebust and co)
o Compaq 64bit/66Mhz PCI Fibrechannel driver (Amy Vanzant-Hodge)
o Disable microtouch driver (doesnt work in 2.2 (Greg Kroah-Hartman)
currently)
o Update ADFS support (Russell King)
o Update ARM arch specific code and includes (Russell King)
o Update ARM specific drivers (Russell King)
o Use both fast and slow A20 gating on boot (Kira Brown)
| if your box doesnt boot I want to know about it...
| Needed for stuff like the AMD Elan
2.2.18pre8
o Fix mtrr compile bug (Peter Blomgren)
o Alpha PCI boot up fix (Michal Jaegermann)
o Fix vt/keyboard dependancy in USB config (Arjan van de Ven)
o Fix sound hangs on cs4281 (Tom Woller)
o Fix Alpha vmlinuz.lds (Andrea Arcangeli)
o Fix CDROMPLAYTRKIND bug, allow root to open (Jens Axboe)
the cd door whenver.
o Update ov511 to match 2.4 (Greg Kroah-Hartman)
o Further devio.c fix (Greg Kroah-Hartman)
o Update NR_TASKS comment (Jarkko Kovala)
o Further sparc64 ioctl translator fixes (Andi Kleen)
2.2.18pre7
o Fix the AGP compile in bug (Arjan van de Ven)
o Revert old incorrect syncppp state change (Ivan Passos)
o Fix i810 rng to actually get built in (Arjan van de Ven)
o Megaraid compile fix, joystick, mkiss fixes (Arjan van de Ven)
o Kawasaki USB ethernet depends on net (Arjan van de Ven)
o Compaq cpqarray update (Charles White)
o Fix usb problem with no USB unit found (Oleg Drokin)
o Driver for the radio on some maestro cards (Adam Tlalka)
o Additional shared map support needed for sparc64(Dave Miller)
o Fix wdt_pci when compiled in (me, Arjan van de Ven)
o Fix usb missing symbol when non modular (Arjan van de Ven)
o Identify chip and also handle MTRR for the (me)
Cyrix III
o Allow binding to all ports multicast (Andi Kleen)
o Bring USB docs up to date (Greg Kroah-Hartman)
o Bring USB devio up to date (Greg Kroah-Hartman)
o pci_resource_len null function for non PCI case (Arjan van de Ven)
o Fix synchronous write off end of disk bug (Jari Ruusu)
2.2.18pre6
o Fix the IDE PCI not compiling bug (Dag Wieers)
o Kill an escaped reference to vger.rutgers (Dave Miller)
o Small rtl8139 fixups (Jeff Garzik)
o Add USB bluetooth driver (Greg Kroah-Hartman)
o Fix oops in visor driver (Greg Kroah-Hartman)
o Remove some unneeded ext2 includes,fix a bug (Andreas Dilger)
in the UFS code
o Fix rtc race between timer and rtc irq (Andrea Arcangeli)
o Fix slow gettimeofday SMP race (Andrea Arcangeli)
o Check lost_ticks in settimeofday to be more (Andrea Arcangeli)
precise
2.2.18pre5
o Added older VIA ide chipsets to the not to be (me)
autotuned list
o Fix crash on boot problem with __setup stuff (me)
o Small acenic fix (Matt Domsch)
o Fix hfc_pci isdn driver (Jens David)
o Fix smbfs configuration problem (Urban Widmark)
o Emu10K wrapper/build fixes (Rui Sousa)
o Small cleanups (Arjan van de Ven)
o Fix sparc32 build bug (Horst von Brand)
o Fix quota oops (Martin Diehl)
o Add i810 random number driver (Jeff Garzik)
o Clear suid bits on ext2 truncate as per SuS (Andi Kleen)
o Fix illegal use of section attributes (Arjan van de Ven)
o Documentation for nmi watchdog (Marcelo Tosatti)
o Fix uninitialised variable warnings (Arjan van de Ven)
o Save DR6 condition into the TSS (Ryan Wallach)
o Add additional __init's to the kernel (Andrzej M. Krzysztofowicz)
o Backport 2.4 wdt_pci driver (JP Nollman, me)
o AGP i810 fixes (Chip Salzenberg)
o UDMA support for ALI1543 & 1543C IDE devices (ALI)
o 2.4 MSR/CPUID driver backport (Dave Jones,
H Peter Anvin)
o Fix incorrect use of kernel v user ptr in NCPfs (Petr Vandrovec)
o Updated scsi tape driver (Kai Makisara)
2.2.18pre4
o Remove the aacraid driver again, having looked (me)
at what is needed to make it acceptable and
debug it - Im dumping it back on Adaptec
o DAC960 update (Leonard Zubkoff)
o Add setup vmlinuz.lds changes for Sparc (Arjan van den Ven)
o Sparc updates for drm, ioctl and other (Dave Miller)
o Megaraid driver update (Peter Jarrett)
o Add cd volume 0 to the amp power off on the
crystal cs46xx (Bill Nottingham)
o Fix IPV6 fragment and kfree bugs (Alexey Kuznetsov)
o Fix emu10k build bug (me)
o Emu10K driver upgrade. Adds emu-aps support (Rui Sousa)
o Updated IBM serveraid driver to 4.20 (IBM)
o Ext2 block handling cleanup from 2.4 (Al Viro)
o Make the ATI128 driver modular (Marcelo Tosatti)
o Fix megaraid build bug with gcc 2.7.2 (Arjan van de Ven)
o Fix some of the dquot races (Jan Kara)
o x86 setup code cleanup (Dave Jones)
o Implement 2.4 compatible __setup and __initcall (Arjan van de Ven)
o Tidy up smp_call_function stuff (Keitaro Yosimura)
o Remove 2.4 compat glue from cs4281 driver (Marcelo Tosatti)
o Fix minor bugs in bluesmoke now someone actually
has a faulty CPU and logs (me)
o Fix definition of IPV6_TLV_ROUTERALERT (Dave Miller)
o Fix in6_addr, ip_decrease_ttl, other (Dave Miller)
minor bits
o cp932 fixes (Kazuki Yasumatsu)
o Updated gdth driver (Andreas Koepf)
o Acenic update (Jes Sorensen)
o Update USB serial drivers (Greg Kroah-Hartman)
o Move pci_resource_len into pci compat (Marcelo Tosatti)
2.2.18pre3 (versus 2.2.17pre20)
o Clean up most of the compatibility macros (me)
that various people use. I've systematically
moved the 100% correct ones to the headers
used in 2.4
o Fix newly introduced bug in kmem_cache_shrink (Daniel Roesen)
o Further updates to symbios drivers (Gerhard Roudier)
o Remove emu10K warning and mtrr warning (Daniel Roesen)
o Fix symbol clash between cs4281 and esssolo1 (Arjan van de Ven)
o Fix acenic non modular/module build issues (Arjan van de Ven)
o Fix bug in alpha csum_partial_copy that could (Herbert Xu)
cause spurious EFAULTs
o Yet another eepro100 variant sighted (Torben Mathiasen)
o Minor microcode.c final tweak (Daniel Roesen)
o Document that ATIFB is now modular (Marcelo Tosatti)
o Parport update (Tim Waugh)
o First set of ext2 updates/fixes (Al Viro)
o Bring smbfs back into line with 2.2 (Urban Widmark)
| This should make OS/2 work again
o Fix S/390 _stext (still doesnt build dasd) (Kurt Roeckx)
o Remove unused vars in arch/i386/kernel/bios32.c (Daniel Roesen)
o Update the DHCP initrd support (Chip Salzenberg)
o Allow opening empty scsi removables like IDE
with O_NONBLOCK (needed for some ioctls) (Chip Salzenberg)
o Back out vibra mixer change
o Fix error returns in sbni driver (Dawson Engler)
o Initial merge of the aacraid driver (Adaptec)
| Much deuglification left to be done here
o Report megaraid: on obscure megaraid error (Daniel Deimert)
strings
o Add another CS4299 id string (Mulder Tjeerd)
2.2.18pre2 (versus 2.2.17pre20)
o Fix the compile problems with microcode.c (Dave Jones,
Daniel Roesen)
o GDTH driver update (Achim Leubner)
o Fix mathsemu miuse of casting with asm (??)
o Make msnd_pinnacle driver build on Alpha
o Acenic 0.45 fixes (Chip Salzenberg)
o Compaq CISS driver (SA 5300) (Charles White,
+ cleanups me)
+ gcc 2.95 fixup
o Modularise pm2fb and atyfb
o Upgrade AMI Megaraid driver to 1.09 (AMI)
o Add DEC HSG80 and COMPAQ 'logical volume' to
scsi multilun list
o SK PCI FDDI driver support (Schneider & Koch)
o Linux 2.2 USB backport (Vojtech Pavlik)
backport 3 + further fixes from the USB list
+ mm/slab.c fix for cache destroy
o AGP driver backport (XFree86, Precision
DRM driver backport Insight, XiG, HJ Lu,
VA Linux,
and others)
2.2.18pre1 (versus 2.2.17pre20)
o Update symbios/ncr driver to 1.7.0/3.4.0 (Gerhard Roudier)
o Updated ATP870U driver (ACard)
o Avoid running tq_scheduler stuff sometimes with (Andrea Arcangeli)
interrupts off
o Futher cpu setup updates (me)
o IBM MCA scsi driver updates (Michael Lang)
o Fix incorrect out of memory handling in bttv (Dawson Engler)
o Fix incorrect out of memory handling in buz (Dawson Engler)
o Fix incorrect out of memory handling in qpmouse (Dawson Engler)
o Fix error handling memory leak in ipddp (Dawson Engler)
o Fix error handling memory leak in sdla (Dawson Engler)
o Fix error handling memory leak in softoss (Dawson Engler)
o Fix error handling memory leak in ixj (Dawson Engler)
o Fix error handling memory leak in ax25 (Dawson Engler)
o Merge the microcode driver from 2.4 into 2.2 (Tigran Aivazian)
o Fix skbuff handling bug in the smc9194 driver (Arnaldo Melo)
o Make vfat use the same generation rules as (H. Kawaguchi,
in windows 9x Chip Salzenberg)
o Fix oops in the CPQ array driver (Arnaldo Melo)
o Fix ac97 codec not setting the id field (Bill Nottingham)
o Further work on the cs46xx/CD power bits (me)
o Synclink updates (Paul Fulgham)
o Synclink init bug fix (Arnaldo Melo)
o Handle odd interrupts from toshiba floppies (Alain Knaff)
o Fix trident driver build on nautilus Alpha (Peter Petrakis)
o Add later sb16 imix support tot he sb driver (Massimo Dal Zotto)
o Ignore luns that report can be connected, but (Matt Domsch)
not currently
o Fix dereference after kfree in uart401.c (Dawson Engler)
o Return correct SuS error code for an unknown (Herbert Xu)
socket family
o Add sub window clipping to the bttv driver (Thomas Jacob)
o Fix nfs cache locked messages (Trond Myklebust)
o Fix the modutils misdocumentation (Martin Douda)
o Remove bogus biosparm code from seagate.c (Andries Brouwer)
o Return correct error code on failed fasync set (Chip Salzenberg)
o Handle dcc resume with newer irc clients when (Scottie Shore)
doing an irq masq
--
Alan Cox <[email protected]>
Red Hat Kernel Hacker
& Linux 2.2 Maintainer Brainbench MVP for TCP/IP
http://www.linux.org.uk/diary http://www.brainbench.com
Date: Fri, 10 Nov 2000 03:07:21 +0000 (GMT)
From: Alan Cox <[email protected]>
o Resnchronize Apple PowerMac codebase (Paul Mackerras & co)
BUUUG, new DEV_MAC_HID sysctl number conflicts with DEV_MD
in Ingo's raid patches.
Later,
David S. Miller
[email protected]
> Anything which isnt a strict bug fix or previously
> agreed is now 2.2.19 material.
Alan, do you consider it as a bugfix if I tell you
that
we can't get anymore oops with the new bonding code,
even in SMP ?
I've had reports of it working very well, and faster,
for a long time now and the link detection seems
completely OK now. I'd like to specially thank
Constantine Gavrilov for all the tests he has done and
the time he spent in enhancing the documentation.
Please find the patch against 2.2.18pre20 in
attachment, in case you agree.
Regards,
Willy
___________________________________________________________
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis,
Yahoo! Messenger : http://fr.messenger.yahoo.com
On Fri, Nov 10, 2000 at 10:28:46AM +0100, willy tarreau wrote:
From the patch source:
+CONFIG_BONDING
+ Say 'Y' or 'M' if you wish to be able to 'bond' multiple Ethernet
+ Channels together. This is called 'Etherchannel' by Cisco,
+ 'Trunking' by Sun, and 'Bonding' in Linux.
I think "bonding" is term used in one particular type
of ISDN multilink calls.
Cisco Trademark is EtherChannel -- there the capitalization
is important. We could call it ETHERNETCHANNEL (and even
"Etherchannel" or "ETHERCHANNEL") get away with it clean.
...
> Regards,
> Willy
/Matti Aarnio
Matti Aarnio wrote:
>
> On Fri, Nov 10, 2000 at 10:28:46AM +0100, willy tarreau wrote:
>
> From the patch source:
>
> +CONFIG_BONDING
> + Say 'Y' or 'M' if you wish to be able to 'bond' multiple Ethernet
> + Channels together. This is called 'Etherchannel' by Cisco,
> + 'Trunking' by Sun, and 'Bonding' in Linux.
>
> I think "bonding" is term used in one particular type
> of ISDN multilink calls.
>
> Cisco Trademark is EtherChannel -- there the capitalization
> is important. We could call it ETHERNETCHANNEL (and even
> "Etherchannel" or "ETHERCHANNEL") get away with it clean.
>
> ...
> > Regards,
> > Willy
>
> /Matti Aarnio
ISDN uses "channel bonding", not bonding. As for "Etherchannel", let us change
it to "EtherChannel" is this is how it is called.
--
----------------------------------------
Constantine Gavrilov
Unix System Administrator and Programmer
Xpert Integrated Systems
1 Shenkar St, Herzliya 46725, Israel
Phone: (972-8)-952-2361
Fax: (972-9)-952-2366
----------------------------------------
On Fri, Nov 10, 2000 at 11:57:45AM +0200, Constantine Gavrilov wrote:
> > Cisco Trademark is EtherChannel -- there the capitalization
> > is important. We could call it ETHERNETCHANNEL (and even
> > "Etherchannel" or "ETHERCHANNEL") get away with it clean.
> > ...
> > > Regards,
> > > Willy
> >
> > /Matti Aarnio
>
> ISDN uses "channel bonding", not bonding. As for "Etherchannel", let us
> change it to "EtherChannel" is this is how it is called.
Anything but "EtherChannel" -- trademark people are sometimes
unpleasant when they consider something being infringed.
(And nowhere as much as in USA..)
We dont' have cisco approval of using their trademark in Linux
kernel feature name, or do we ?
> --
> Constantine Gavrilov
> Xpert Integrated Systems
> 1 Shenkar St, Herzliya 46725, Israel
/Matti Aarnio
willy tarreau wrote:
>
> > Anything which isnt a strict bug fix or previously
> > agreed is now 2.2.19 material.
>
> Alan, do you consider it as a bugfix if I tell you
> that
> we can't get anymore oops with the new bonding code,
> even in SMP ?
>
> I've had reports of it working very well, and faster,
> for a long time now and the link detection seems
> completely OK now. I'd like to specially thank
> Constantine Gavrilov for all the tests he has done and
> the time he spent in enhancing the documentation.
>
> Please find the patch against 2.2.18pre20 in
> attachment, in case you agree.
>
> Regards,
> Willy
I do think the new code is much better. Anyone who is considering using trunking
for their projects should use the new code since it has link monitoring and
active backup mode. However, I am a maniac when it comes to kernel testing. If I
say it really works, it usually works. This code has been tested much and bugs
were fixed. However, it has not been tested enough that I may bet by head on
saying there are no known issues. This is because I did not have access to all
hardware that was needed to complete the tests in time.
The code is not worse than the old code. However, a clear note must be made that
this is experimental code and probably has small issues. So if it is included,
it must me marked as experimental.
----------------------------------------
Constantine Gavrilov
Unix System Administrator and Programmer
Xpert Integrated Systems
1 Shenkar St, Herzliya 46725, Israel
Phone: (972-8)-952-2361
Fax: (972-9)-952-2366
----------------------------------------
Matti Aarnio wrote:
>
> On Fri, Nov 10, 2000 at 11:57:45AM +0200, Constantine Gavrilov wrote:
> > > Cisco Trademark is EtherChannel -- there the capitalization
> > > is important. We could call it ETHERNETCHANNEL (and even
> > > "Etherchannel" or "ETHERCHANNEL") get away with it clean.
> > > ...
> > > > Regards,
> > > > Willy
> > >
> > > /Matti Aarnio
> >
> > ISDN uses "channel bonding", not bonding. As for "Etherchannel", let us
> > change it to "EtherChannel" is this is how it is called.
>
> Anything but "EtherChannel" -- trademark people are sometimes
> unpleasant when they consider something being infringed.
> (And nowhere as much as in USA..)
>
> We dont' have cisco approval of using their trademark in Linux
> kernel feature name, or do we ?
>
Gee, we do not call it EtherChannel, we say CISCO calls it EtherChannel. Where
is the infringment here? Are people that paranoid or it is just me who is not
getting it?
--
----------------------------------------
Constantine Gavrilov
Unix System Administrator and Programmer
Xpert Integrated Systems
1 Shenkar St, Herzliya 46725, Israel
Phone: (972-8)-952-2361
Fax: (972-9)-952-2366
----------------------------------------
> However, it has not been tested enough that I may
bet
> by head on saying there are no known issues.
I won't say there are no issues, but I'd say there are
no KNOWN issues.
> This is because I did not have access to all
> hardware that was needed to complete the tests in
> time.
I know that, Constantine. But I know a few people at
work who used it (me included), and I also had a
report
from a guy in germany using it with success.
I know this is really not much, but we used to read
about problems by the past, and I haven't received
even one complaint about the new one, so I bet it's a
bit better than it was.
> The code is not worse than the old code. However, a
> clear note must be made that this is experimental
> code and probably has small issues.
as always, and just like any other driver (eg: I'll
try
to take some time to make the megaraid work again on
my server).
> So if it is included, it must me marked as
experimental.
agreed.
Regards,
Willy
___________________________________________________________
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis,
Yahoo! Messenger : http://fr.messenger.yahoo.com
> > > is important. We could call it
ETHERNETCHANNEL (and even
> > > "Etherchannel" or "ETHERCHANNEL") get
away with it clean.
> > > ...
> > > /Matti Aarnio
> Anything but "EtherChannel" -- trademark people
Ok, Matti. Let's keep "Etherchannel" as you proposed
and as it was documented in the Configure.help. This
patch fixes it (I won't resend the complete patch
on the LKML because 20kB is generally to big for
unconcerned people).
Willy
___________________________________________________________
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis,
Yahoo! Messenger : http://fr.messenger.yahoo.com
On Fri, Nov 10, 2000 at 12:22:04PM +0200, Constantine Gavrilov wrote:
> Gee, we do not call it EtherChannel, we say CISCO calls it
> EtherChannel. Where is the infringment here? Are people that paranoid
> or it is just me who is not getting it?
You missed my original point.
I don't like to call it BONDING.
"Bonding" is something where two (or more) channels carry data
in between two participating systems. Like Multilink-PPP, and
ISDN Channel Bonding. Often indeed data goes out somehow inter-
leaved on the physical links. (Like ISDN Channel Bonding supplies
a transparent 128 kbps link instead of two 64 kbps links to the
upper layers.)
EtherChannel does select the link (out of the group) by forming
XOR of source and destination MAC addresses (their lowest bytes),
and then doing MODULO number-of-links on the result.
So between systems A and B the flow goes via link 0, in between
A and C it goes via link 1. Add there client system D, and it
may end up into either of the links.
|-----------| |------|
| A |-----link-0-----| SW |---[B]
| |-----link-1-----| with |---[C]
|-----------| |EthChn|---[D]
|------|
This gives improved throughput on congested links in between
two switches, or major server and core switches, while preserving
data order over the links.
Blind bonding-type "throw packets on links 0 and 1" MAY end up
sending ethernet frames out of sequence, which for a few LAN
based protocols is a great source of upset.
Beowulf systems have "bonding" in use for parallel Ethernet
links in between two machines, however THAT is not EtherChannel
compatible thing!
> --
> Constantine Gavrilov
/Matti Aarnio
Le Fri, Nov 10, 2000 at 03:07:21AM +0000, Alan Cox a ?crit:
> Anything which isnt a strict bug fix or previously agreed is now 2.2.19
> material.
Compiling 2.2.18pre21 without sysctl gives an error at linkage:
kernel/kernel.o(__ksymtab+0x608): undefined reference to `sysctl_jiffies'
trivial patch included, not sure it's the right one.
Arnaud.
Date: Fri, 10 Nov 2000 11:59:25 +0100
From: "Arnaud S . Launay" <[email protected]>
trivial patch included, not sure it's the right one.
This one is better:
--- kernel/sysctl.c.~1~ Thu Nov 9 19:41:52 2000
+++ kernel/sysctl.c Fri Nov 10 02:52:30 2000
@@ -1173,6 +1173,13 @@
return -ENOSYS;
}
+int sysctl_jiffies(ctl_table *table, int *name, int nlen,
+ void *oldval, size_t *oldlenp,
+ void *newval, size_t newlen, void **context)
+{
+ return -ENOSYS;
+}
+
int proc_dostring(ctl_table *table, int write, struct file *filp,
void *buffer, size_t *lenp)
{
> I don't like to call it BONDING.
> "Bonding" is something where two (or more) channels
> carry data in between two participating systems.
> Like Multilink-PPP, and ISDN Channel Bonding. Often
> indeed data goes out somehow inter-leaved on the
> physical links. (Like ISDN Channel Bonding supplies
> a transparent 128 kbps link instead of two 64
> kbps links to the upper layers.)
this is *EXACTLY* what the old bonding driver does,
and what the new one does by default.
> EtherChannel does select the link (out of the group)
> by forming XOR of source and destination MAC
> addresses (their lowest bytes),
.../...
> This gives improved throughput on congested links
> in between two switches, or major server and core
> switches, while preserving data order over the
links.
OK, I've read about it because Thomas Davis asked me
if I would implement it. I didn't find it usefull for
the case of a Linux server directly connected to a
router or a level X switch (x>2) because in this case
only one link is getting used. Perhaps I'm wrong, but
I think this is the major use of the current Linux
bonding driver. However, the new driver is now ready
for such an implementation.
> Blind bonding-type "throw packets on links 0 and 1"
> MAY end up sending ethernet frames out of sequence,
> which for a few LAN based protocols is a great
source
> of upset.
probably, but do you have examples in mind ? if so, I
would add XOR to a next release, but I don't want to
add too much at a time. I consider this release
primarily as a bugfix (smp, security, oopses...), and
as an improvement which now supports link fail-over,
which is also a primary concern when implementing
multilinks.
> Beowulf systems have "bonding" in use for parallel
> Ethernet links in between two machines, however THAT
> is not EtherChannel compatible thing!
yes it is compatible ! compatible doesn't mean it does
not work the same way, but it works with. Both the
cisco and linux drivers agree to receive on each of
their trunk ports, so the difference only resides in
link optimization when sending frames.
> /Matti Aarnio
Willy
___________________________________________________________
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis,
Yahoo! Messenger : http://fr.messenger.yahoo.com
> o Resnchronize Apple PowerMac codebase (Paul Mackerras & co)
>
>BUUUG, new DEV_MAC_HID sysctl number conflicts with DEV_MD
>in Ingo's raid patches.
Well, I beleive DEV_MAC_HID can safely be changed to something else as
userland only use the /proc entry name./
Ben.
hi,
i'm currently running RH7, with 2.2.16-22 kernel, gcc 2.96 on a Sharp Actius
250 notebook.
i've manged to successfully compile 2.4.0-test10 kernel. however, upon
startup there are some failed/error messages:
1. finding module dependencies: depmod *** Unresolved symbols in
/lib/modules/2.4.0-test10/kernel/arch/i386/kernel/apm.o
2. Starting NFS lockd: lockdsvc: Invalid argument [FAILED]
during shutdown, the following failed messages was noticed:
1. Turning off accounting: aacton: Function not implemented
2. Shutting down NFS lockd [FAILED]
the system is also not able to shutdown/power off completely after
"shutdown -h now". however, using RH7 2.2.16 kernel, the notebook was able
to power off. how can i configure it to turn off automatically?
pls kindly advise where i have gone wrong and how to rectify the above
errors.
pls pardon my ignorance as i'm quite new to linux and this is my first
kernel compilation attempt.
thank you very much.
ps: i've tried the kernel compilation on a HP Vectra PII PC and the error
messages are similar.
On Fri, Nov 10, 2000 at 12:35:27PM +0100, Benjamin Herrenschmidt wrote:
> > o Resnchronize Apple PowerMac codebase (Paul Mackerras & co)
> >
> >BUUUG, new DEV_MAC_HID sysctl number conflicts with DEV_MD
> >in Ingo's raid patches.
>
> Well, I beleive DEV_MAC_HID can safely be changed to something else as
> userland only use the /proc entry name./
One question here. Is it important here that the # be consistant? I mean
since to change a sysctl isn't the name the important bit? ie:
dev.md.speed_limit would work regardless of if DEV_MD is 3 or 4?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
Date: Fri, 10 Nov 2000 08:42:11 -0700
From: Tom Rini <[email protected]>
One question here. Is it important here that the # be consistant?
I mean since to change a sysctl isn't the name the important bit?
ie: dev.md.speed_limit would work regardless of if DEV_MD is 3 or
4?
These nodes are accessible via both /proc/sys/* and the
sys_sysctl(...) system call, the latter uses the numbers
so they are hard coded into application binaries.
Later,
David S. Miller
[email protected]
>>>>> "C" == Corisen <[email protected]> writes:
C> hi, i'm currently running RH7, with 2.2.16-22 kernel, gcc 2.96 on
C> a Sharp Actius 250 notebook.
C> i've manged to successfully compile 2.4.0-test10 kernel. however,
C> upon startup there are some failed/error messages:
C> 1. finding module dependencies: depmod *** Unresolved symbols in
C> /lib/modules/2.4.0-test10/kernel/arch/i386/kernel/apm.o
There are two things you can do about this:
1. Disable module versioning.
2. Copy the System.map file that's made during the kernel build to
/boot/System.map-2.4.0-test10.
Personally, I do 2. Though, now I'm attempting to get the maestro
driver working again and this is getting in my way. So my question to
those that know more is what is the correct way to build a module such
that it'll insmod in the face of module versioning. Is this something
for the FAQ?
C> 2. Starting NFS lockd: lockdsvc: Invalid argument [FAILED]
I've been ignoring this (I'm sure at my peril).
C> during shutdown, the following failed messages was noticed:
C> 1. Turning off accounting: aacton: Function not implemented
You can try enabling BSD process accounting in your configuration. I
have not and also get this message (and don't care).
C> 2. Shutting down NFS lockd [FAILED]
As above.
C> the system is also not able to shutdown/power off completely after
C> "shutdown -h now". however, using RH7 2.2.16 kernel, the notebook
C> was able to power off. how can i configure it to turn off
C> automatically?
My laptop (a Fujitsu E6520 stop powering off with RH7 regardless of
whether I used the supplied kernel or the test10 that I built), so
consider yourself lucky ;-)
Also, the default compiler on RH7 is not correct. Use kgcc instead
(ie. make CC=kgcc bzImage). The gcc2.96 is said/known not to work for
kernel work.
On Fri, 10 Nov 2000 11:23:29 -0500 (EST),
"Georg Nikodym" <[email protected]> wrote:
> C> i've manged to successfully compile 2.4.0-test10 kernel. however,
> C> upon startup there are some failed/error messages:
> C> 1. finding module dependencies: depmod *** Unresolved symbols in
> C> /lib/modules/2.4.0-test10/kernel/arch/i386/kernel/apm.o
>
>There are two things you can do about this:
>
> 1. Disable module versioning.
> 2. Copy the System.map file that's made during the kernel build to
> /boot/System.map-2.4.0-test10.
System.map has nothing, repeat nothing to do with depmod at startup.
Yes, you can run depmod reading from a System.map but that only makes
sense before you boot the new kernel. Once you have booted your
new kernel, depmod -a reads from kernel memory, not System.map.
>those that know more is what is the correct way to build a module such
>that it'll insmod in the face of module versioning. Is this something
>for the FAQ?
Current Makefiles sometimes break with module versioning, the design is
inherently wrong but rewriting the entire Makefile system just before
the release of Linux 2.4 is not an option. This should be in the FAQ,
Richard, please add.
Q. Why do I get unresolved symbols like foo__ver_foo in modules?
A. If /proc/ksyms or the output from depmod -ae contains symbols like
"foo__ver_foo" then you have been bitten by the broken Makefile
code for symbol versioning. The only safe way to recover is save
your config, delete everything, restore the config and recompile.
mv .config ..
make mrproper
mv ../.config .
make oldconfig
make dep clean bzImage modules
install, boot
>>>>> "KO" == Keith Owens <[email protected]> writes:
KO> On Fri, 10 Nov 2000 11:23:29 -0500 (EST), "Georg Nikodym"
KO> <[email protected]> wrote:
C> i've manged to successfully compile 2.4.0-test10 kernel. however,
C> upon startup there are some failed/error messages:
C> 1. finding module dependencies: depmod *** Unresolved symbols in
C> /lib/modules/2.4.0-test10/kernel/arch/i386/kernel/apm.o
>>
>> There are two things you can do about this:
>>
>> 1. Disable module versioning.
>> 2. Copy the System.map file that's made during the kernel build to
>> /boot/System.map-2.4.0-test10.
KO> System.map has nothing, repeat nothing to do with depmod at
KO> startup. Yes, you can run depmod reading from a System.map but
KO> that only makes sense before you boot the new kernel. Once you
KO> have booted your new kernel, depmod -a reads from kernel memory,
KO> not System.map.
OK. Makes sense. My first kicks at building and running a kernel had
these problems (with module loading) until I added the copying of
System.map to my installation procedure. I was led to this by
messages in /var/log/messages... Thanks for the additional pointers.
KO> Q. Why do I get unresolved symbols like foo__ver_foo in modules?
KO> A. If /proc/ksyms or the output from depmod -ae contains symbols
KO> like
KO> "foo__ver_foo" then you have been bitten by the broken Makefile
KO> code for symbol versioning. The only safe way to recover is save
KO> your config, delete everything, restore the config and recompile.
KO> mv .config .. make mrproper mv ../.config . make oldconfig make
KO> dep clean bzImage modules install, boot
OK, but I guess my question wasn't very clear. I have a kernel tree,
I add a printk to maestro.c and make modules. I cannot load the
module until I rebuild and reinstall everything. Is there a way to
avoid this headache, or, stated differently: What's the prescribed
way to be able to load, unload, build, test modules?
At 18:25 10/11/2000, Georg Nikodym wrote:
>OK, but I guess my question wasn't very clear. I have a kernel tree,
>I add a printk to maestro.c and make modules. I cannot load the
>module until I rebuild and reinstall everything. Is there a way to
>avoid this headache, or, stated differently: What's the prescribed
>way to be able to load, unload, build, test modules?
I do the following when I am working on the NTFS driver:
1st: make mrproper && make menuconfig && make dep && make bzImage && make
modules && make modules_install
2nd: install new kernel, lilo, reboot into new kernel
3rd: edit the <mymodule>'s source.
4th: make modules && make modules_install && depmod -a && rmmod <mymodule>
&& modprobe <mymodule>
5th: do testing I wanted to do.
6th go to 3rd step and repeat until satisfied with result.
[NB. Obviously replacing <mymodule> with the module name of whatever I am
looking at.
NB. I have put this in a few convenience scripts...]
This procedure works fine, or at least it does so for all modules I have
tried it with (which isn't many, since I only keep NTFS, md and linear as
modules...).
HTH,
Anton
--
"Education is what remains after one has forgotten everything he
learned in school." - Albert Einstein
--
Anton Altaparmakov Voice: +44-(0)1223-333541(lab) / +44-(0)7712-632205(mobile)
Christ's College eMail: [email protected] / [email protected]
Cambridge CB2 3BU ICQ: 8561279
United Kingdom WWW: http://www-stu.christs.cam.ac.uk/~aia21/
Matti Aarnio wrote:
> Beowulf systems have "bonding" in use for parallel Ethernet
> links in between two machines, however THAT is not EtherChannel
> compatible thing!
>
Maybe we should adopt's sun naming then, and call it 'Trunking'.
This is the same driver that Beowulf uses, and it is Etherchannel
compatible.
The only part of Etherchannel we don't support is the XOR channel
selection (yuck!) and the automatic configuration of the links (it's a
MII thing, that's undocumented.)
Leave it as Ethernet Bonding.
--
------------------------+--------------------------------------------------
Thomas Davis | PDSF Project Leader
[email protected] |
(510) 486-4524 | "Only a petabyte of data this year?"
I think it is great that there is continued valuable developement on the
bonding driver. Have you guys taken a look at the source code for Intel's
new ANS driver? For any Intel network card, it will do 8-way Fast
EtherChannel. Supposedly, it also supports failover (though even
"bonding" driver docs used to say that was impossible because the linux
networking subsystem didn't handle card failures gracefully enough).
You can check it out at:
http://support.intel.com/support/network/adapter/pro100/100Linux.htm
Maybe some of the code will help in the "bonding" driver development. I
much prefer bonding over Intel's ANS, because bonding is GPL and works
with any net card. Etc. etc.
-Dan
On Fri, 10 Nov 2000, willy tarreau wrote:
> > Anything which isnt a strict bug fix or previously
> > agreed is now 2.2.19 material.
>
> Alan, do you consider it as a bugfix if I tell you
> that
> we can't get anymore oops with the new bonding code,
> even in SMP ?
>
> I've had reports of it working very well, and faster,
> for a long time now and the link detection seems
> completely OK now. I'd like to specially thank
> Constantine Gavrilov for all the tests he has done and
> the time he spent in enhancing the documentation.
>
> Please find the patch against 2.2.18pre20 in
> attachment, in case you agree.
>
> Regards,
> Willy
>
>
> ___________________________________________________________
> Do You Yahoo!? -- Pour dialoguer en direct avec vos amis,
> Yahoo! Messenger : http://fr.messenger.yahoo.com
Dan Browning wrote:
>
> I think it is great that there is continued valuable developement on the
> bonding driver. Have you guys taken a look at the source code for Intel's
> new ANS driver? For any Intel network card, it will do 8-way Fast
> EtherChannel. Supposedly, it also supports failover (though even
> "bonding" driver docs used to say that was impossible because the linux
> networking subsystem didn't handle card failures gracefully enough).
>
> You can check it out at:
>
> http://support.intel.com/support/network/adapter/pro100/100Linux.htm
>
> Maybe some of the code will help in the "bonding" driver development. I
> much prefer bonding over Intel's ANS, because bonding is GPL and works
> with any net card. Etc. etc.
Alas, the license has the BSD documentation requirement, and thus is
incompatible with the GPL...
Jeff
--
Jeff Garzik |
Building 1024 | Would you like a Twinkie?
MandrakeSoft |
> EtherChannel. Supposedly, it also supports failover
> (though even "bonding" driver docs used to say that
> was impossible because the linux networking
subsystem
> didn't handle card failures gracefully enough).
the new bonding code supports failover. It probes the
cards itself. Although this is a recommended mode of
operation, it is not the default one because I want it
to keep fully compatible with any implementation based
on the old one.
>
http://support.intel.com/support/network/adapter/pro100/100Linux.htm
I'll take a look, but except for the XOR sending algo,
I don't think much features are missing.
Willy
___________________________________________________________
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis,
Yahoo! Messenger : http://fr.messenger.yahoo.com
Ok, Matti,
here's a final patch against the bonding patch I
posted
on Friday. Could you tell me if it fits your needs ?
If so, I would repost (offline) the complete one
against 2.2.18pre21. Anyway, for those curious here,
it's available at the following URL:
http://www-miaif.lip6.fr/willy/pub/linux-patches/bonding/patch-2.2.18p21-bonding-20001113.gz
Regards,
Willy
___________________________________________________________
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis,
Yahoo! Messenger : http://fr.messenger.yahoo.com
Oops !
better with the patch :-)
Willy
> Ok, Matti,
> here's a final patch against the bonding patch I
> posted on Friday.
___________________________________________________________
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis,
Yahoo! Messenger : http://fr.messenger.yahoo.com
On Fri, 10 Nov 2000, Alan Cox wrote:
> Ok so the PS/2 bug is real and the megaraid mystery continues
>
> Anything which isnt a strict bug fix or previously agreed is now 2.2.19
> material.
Torsten Hilbrich posted a chroot "bug" that works on 2.2.17 and
2.2.18pre21, it's in de.comp.os.unix.networking, Subject containing
"chroot-Bug in Linux", dated 2000-11-15 20:38:38 local time (+0100).
Its Message-ID: <[email protected]>
It shows a program that saves the cwd -- open(".",...) in an open file,
then chroots to a newly made directory below that, fchdirs back to the
original open file (that is now outside the chroot) and calls upon
chdir("..").
Note that it's NOT related to the current working directory, but to an
open file outside the chroot.
Please comment.
--
Matthias Andree
On Thu, Nov 16, 2000 at 03:07:04PM +0100, Matthias Andree wrote:
> It shows a program that saves the cwd -- open(".",...) in an open file,
> then chroots [..]
This is known behaviour (I know Alan knows about it too), solution is to close
open directories filedescriptors before chrooting.
Everything that happens before chroot(2) is trusted, so it's secure to rely
on it to close directories first.
If this is not well documented and people doesn't know about it and so they
writes unsafe code that's another issue...
Andrea
On Thu, Nov 16, 2000 at 05:16:18PM +0100, Andrea Arcangeli wrote:
> On Thu, Nov 16, 2000 at 03:07:04PM +0100, Matthias Andree wrote:
> > It shows a program that saves the cwd -- open(".",...) in an open file,
> > then chroots [..]
>
> This is known behaviour (I know Alan knows about it too), solution is to close
> open directories filedescriptors before chrooting.
>
> Everything that happens before chroot(2) is trusted, so it's secure to rely
> on it to close directories first.
>
> If this is not well documented and people doesn't know about it and so they
> writes unsafe code that's another issue...
But the problem is because you can call chroot when you're already chrooted.
So what happens is--
1. Your server closes all open directory file descriptors and chroots.
2. Someone manages to run some exploit code in your process space which--
1. Makes a directory inside the current chroot jail.
2. Acquires a file descriptor for the root of the current chroot jail.
3. Chroots to the directory that was just created.
4. Uses this exploit to pull itself out of the second chroot jail, which
also breaks it out of the original chroot jail as well.
It's simply not good enough to close all directory file descriptors before chrooting.
If calling chroot once you're already in a chroot jail was disallowed, it would stop
this attack.
-Jesse
On Thu, Nov 16, 2000 at 11:52:49AM -0800, jesse wrote:
> On Thu, Nov 16, 2000 at 05:16:18PM +0100, Andrea Arcangeli wrote:
> > On Thu, Nov 16, 2000 at 03:07:04PM +0100, Matthias Andree wrote:
> > > It shows a program that saves the cwd -- open(".",...) in an open file,
> > > then chroots [..]
> >
> > This is known behaviour (I know Alan knows about it too), solution is to close
> > open directories filedescriptors before chrooting.
> >
> > Everything that happens before chroot(2) is trusted, so it's secure to rely
> > on it to close directories first.
> >
> > If this is not well documented and people doesn't know about it and so they
> > writes unsafe code that's another issue...
>
> But the problem is because you can call chroot when you're already chrooted.
Only if you're root. There are other ways to break out of a
chroot() if you're root too.
Kurt
> It's simply not good enough to close all directory file descriptors before chrooting.
>
> If calling chroot once you're already in a chroot jail was disallowed, it would stop
> this attack.
I think the problem here is that some people have the idea that chroot is
some kind of magical security device. Thats not true at all. You can build an
environment like that if you wish by closing other directory handles and having
no suitably priviledged code in the chroot area and stuff.
Alan
On Thu, 16 Nov 2000, jesse wrote:
> But the problem is because you can call chroot when you're already chrooted.
It's a non-problem. chroot()ing again may also be used to de-escalate
privileges, and if you want to prevent breaking out of a chroot, drop
root privileges, since chroot is a privileged call. And DO USE setuid,
not seteuid or something (otherwise the saved set-uid will bite you).
--
Matthias Andree
[jesse]
> 1. Your server closes all open directory file descriptors and chroots.
> 2. Someone manages to run some exploit code in your process space which--
mkdir("foo")
chroot("foo")
chdir("../../../../../../../../../..")
chroot(".")
mkdir proc
mount -t proc none proc
cd proc/1/cwd
Two easy "get out of jail free" cards. There are other, more complex
exploits. You have added one more. They all require root privileges.
Bottom line: once you are in the chroot jail, you must drop root
privileges, or you defeat the purpose. Security-conscious coders know
this; it's not Linux-specific behavior or anything.
Peter
Followup to: <[email protected]>
By author: Peter Samuelson <[email protected]>
In newsgroup: linux.dev.kernel
>
>
> [jesse]
> > 1. Your server closes all open directory file descriptors and chroots.
> > 2. Someone manages to run some exploit code in your process space which--
>
> mkdir("foo")
> chroot("foo")
BUG: you *MUST* chdir() into the chroot jail before it does you any
good at all!
I usually recommend:
mkdir("foo");
chdir("foo");
chroot(".");
> Bottom line: once you are in the chroot jail, you must drop root
> privileges, or you defeat the purpose. Security-conscious coders know
> this; it's not Linux-specific behavior or anything.
Indeed. They also know the above.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
[I wrote]
> > mkdir("foo")
> > chroot("foo")
[H. Peter Anvin]
> BUG: you *MUST* chdir() into the chroot jail before it does you any
> good at all!
No, it wasn't a bug! It was a demonstration. The above code is
executed not by the application but by the *attacker* who has managed
to 0wn the existing jail.
Doing the additional chroot("foo") without already being in "foo"
basically replaces the chroot jail you *were* in, so you are now out.
The sequence I posted is just the simplest un-chroot procedure I know,
to explain why chroot cannot sandbox the superuser.
Peter
On Thu, 16 Nov 2000, H. Peter Anvin wrote:
> BUG: you *MUST* chdir() into the chroot jail before it does you any
> good at all!
>
> I usually recommend:
#include <sysexits.h>
/* for EX_NOUSER */
> mkdir("foo");
> chdir("foo");
> chroot(".");
add this:
/* DO REPLACE 500 BY AN EXISTING USER ID */
/* DO NOT REPLACE IT BY 0! */
/* DO NOT USE OTHER FUNCTIONS THAN setuid() */
if(setuid(500)) { _exit(EX_NOUSER); }
(For the records and search engines, most people should know that, but
to have it all in one mail.)
Peter Samuelson wrote:
>
> [I wrote]
> > > mkdir("foo")
> > > chroot("foo")
>
> [H. Peter Anvin]
> > BUG: you *MUST* chdir() into the chroot jail before it does you any
> > good at all!
>
> No, it wasn't a bug! It was a demonstration. The above code is
> executed not by the application but by the *attacker* who has managed
> to 0wn the existing jail.
>
> Doing the additional chroot("foo") without already being in "foo"
> basically replaces the chroot jail you *were* in, so you are now out.
>
> The sequence I posted is just the simplest un-chroot procedure I know,
> to explain why chroot cannot sandbox the superuser.
>
Right. Gotcha.
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On Fri, Nov 17, 2000 at 12:30:00AM -0600, Peter Samuelson wrote:
> Two easy "get out of jail free" cards. There are other, more complex
> exploits. You have added one more. They all require root privileges.
Actually, I've heard that a chrooted _non-root_ process can find another
process with the same uid that's not chrooted and can ptrace() to pull
itself out of the jail.
I'd imagine dropping CAP_SYS_PTRACE would avoid this, though.
> Bottom line: once you are in the chroot jail, you must drop root
> privileges, or you defeat the purpose. Security-conscious coders know
> this; it's not Linux-specific behavior or anything.
It appears that even dropping root privileges might not be enough.
And I realize that there are a number of ways that a root process can
escape, I was mostly objecting to the assertion that chroot() was secure
because everything before the chroot call is assumed to be trusted.
-Jesse
Peter Samuelson <[email protected]> writes:
> Two easy "get out of jail free" cards. There are other, more complex
> exploits. You have added one more. They all require root privileges.
Unless I'm missing something, not all of them do. I haven't checked this
or anything, but it seems to me that all you need is a cooperating
process outside the jail, that opens some world-readable directory and
sends it to the exploit process inside the jail, which fchdir()s to
it. Of course you *do* need an AF_UNIX socket inside the jail for this,
too, so it is probably a quite unlikely attack; but if, for instance,
you reused an outside-the-jail uid *inside* the jail, and the jail had
places writable by this user... bing, no root necessary.
--
`The phrase `causes storage to be reserved', doesn't mean that it causes
storage to be reserved. This is a fundamental misunderstanding of
Standardeze.' --- Mike Stump on the GCC list
Alan Cox wrote:
> > It's simply not good enough to close all directory file descriptors before chrooting.
> >
> > If calling chroot once you're already in a chroot jail was disallowed, it would stop
> > this attack.
> I think the problem here is that some people have the idea that
> chroot is some kind of magical security device. Thats not true at
> all. You can build an environment like that if you wish by closing
> other directory handles and having no suitably priviledged code in
> the chroot area and stuff.
I read about the BSD Jail stuff a while ago.
It's a nice "operating system class lab project". Estimated time
needed: 40 hours.
This IS the magical security device.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* Common sense is the collection of *
****** prejudices acquired by age eighteen. -- Albert Einstein ********
Hello!
> This IS the magical security device.
Jail maybe is. Chroot is not. It is even not clear, why you remembered
about jail here. Chroot does not imprison anyone.
Alexey
[email protected] wrote:
> Hello!
>
> > This IS the magical security device.
>
> Jail maybe is. Chroot is not. It is even not clear, why you remembered
> about jail here. Chroot does not imprison anyone.
Well, because lots of people seem to THINK that chroot imprisons
someone. And "jail" actually does....
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
Hello!
> Well, because lots of people seem to THINK that chroot imprisons
> someone. And "jail" actually does....
Also many of people work to add to linux jail-like functionality,
which is expected to be real security tool unlike bsd jail.
I think from the same source where you read about jail
you know that jail is full of holes like colander. 8)
Alexey
[email protected] wrote:
> Hello!
>
> > Well, because lots of people seem to THINK that chroot imprisons
> > someone. And "jail" actually does....
>
> Also many of people work to add to linux jail-like functionality,
> which is expected to be real security tool unlike bsd jail.
>
> I think from the same source where you read about jail
> you know that jail is full of holes like colander. 8)
Nope I didn't read that.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
Hi!
> > Two easy "get out of jail free" cards. There are other, more complex
> > exploits. You have added one more. They all require root privileges.
>
> Actually, I've heard that a chrooted _non-root_ process can find another
> process with the same uid that's not chrooted and can ptrace() to pull
> itself out of the jail.
Right. Once you have same uid as someone else, you have basically his
priviledges if you chooseto.
> I'd imagine dropping CAP_SYS_PTRACE would avoid this, though.
Pardon me, but CAP_SYS_PTRACE is not required for tracing processes of
same UID.
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
[Nix <[email protected]>]
> I haven't checked this or anything, but it seems to me that all you
> need is a cooperating process outside the jail, that opens some
> world-readable directory
In that case, you are already outside. (: Why bother with the chroot
process at all?
Peter