Ok,
trying to make ready for the real 2.6.9 in a week or so, so please give
this a beating, and if you have pending patches, please hold on to them
for a bit longer, until after the 2.6.9 release. It would be good to have
a 2.6.9 that doesn't need a dot-release immediately ;)
The appended shortlog gives a pretty good idea of what has been going on.
Mostly small stuff, with some architecture updates and an ACPI update
thrown in for good measure.
(The ACPI update fixes broken AML with implied returns, and in particular
the Compaq Evo notebook fan control. Yay! Guess who has one..)
Linus
---
Summary of changes from v2.6.9-rc3 to v2.6.9-rc4
============================================
Adrian Bunk:
o TMS380TR must select FW_LOADER
o Fix Neomagic configuration dependency
Alan Cox:
o fix typo in capi driver
o Fix typo in final changes to old i4l tty code
o 3c59x: add invalid MAC address check
o Update termios to use per tty semaphore
o scsi docs fix
o Fix Kconfig for EDD
o Fix up tty patch problem with pc300 and clean up braces
o usb: hcd locking fix
Alexander Stohr:
o [SPARC64]: Fix solaris emul __set_utsfield offset calculation
Alexander Viro:
o Race with iput and umount
o DAC960 iomem annotations
o sx8 iomem and endianness annotations + endianness bugfix
o more new struct initializers
o more NULL noise removal in drivers/scsi
o arcnet iomem annotations
o romfs endianness annotations
o hton* and ntoh* endianness annotations
o udf endianness annotation fix
o fs/partitions endianness annotations
o quota endianness annotations
o ncpfs (1/7): constants sanitized
o ncpfs (2/7): date handling cleanup
o ncpfs (3/7): be32 handling in marshalling
o ncpfs (4/7): be16 handling in marshalling
o ncpfs (5/7): le16 handling in marshalling
o ncpfs (6/7): trivial endianness annotations
o ncpfs (7/7): misc fixes and cleanups
o isofs endianness annotations
o ufs endianness annotations
o ufs endianness bugfixes
o i2o_config __user annotations
o cciss endianness and iomem annotations
o cpqarray iomem annotations
o umem iomem and (partial) endianness annotations
o hfs endianness annotations
o hfsplus endianness annotations
o hfsplus endianness bugfix
o ohci bugfix for big-endian 64bit boxen
o isd200 bugfix for 64bit boxen
o trivial usb endianness annotations
o amd64 iomem initial annotations
o i2o.h fix
Ali Saidi:
o alpha: cpu mask fix-ups broke SMP DP264 machines in 2.6.8
Andi Kleen:
o x86_64: Lindenhurst MSI build fix
o x86_64: fix oops with multiple MCEs
o x86_64: fix profile_pc
o x86_64: remove CONFIG_FRAME_POINTER
o x86_64: fix circular dependency with UNORDERED_IO
o x86_64: avoid a deadlock during panic
o x86_64: don't corrupt interrupt flag on timer resume
o x86_64: make in_gate_vma() safer
o x86_64: add newline before MCE
Andreas Schwab:
o Properly recognize PowerMac7,3
Andrew Morton:
o sparc64: time interpolator build fix
o remove get_cpu_ptr()
o vmscan: handle empty zones
Andries E. Brouwer:
o overcommit symbolic constants
Anton Altaparmakov:
o NTFS: Fix stupid bug in
fs/ntfs/attrib.c::ntfs_attr_reinit_search_ctx() where we did not
clear ctx->al_entry but it was still set due to changes in
ntfs_attr_lookup() and ntfs_external_attr_find() in particular.
o NTFS: Fix another stupid bug in
fs/ntfs/attrib.c::ntfs_external_attr_find() where we forgot to
unmap the extent mft record when we had finished enumerating an
attribute which caused a bug check to trigger when the VFS calls
->clear_inode.
Arkadiusz Miskiewicz:
o [AGPGART] via-agp.c resume/suspend support
Arnaldo Carvalho de Melo:
o [TCP] don't use sk_zapped
o [SKBUFF] introduce eth_hdr(skb)
o [BRIDGE] convert __constant_htons(constant) to htons
o [SKBUFF] use eth_hdr(skb), skb->mac.raw cases
o [SKBUFF] introduce tr_hdr(skb)
o [LLC] set mac.raw if tr_source_route is called
Arun Sharma:
o [IA64] sparse annotations and cleanups for ia32 subsystem
o [IA64] Added support for the new syscall sys_waitid()
Bartlomiej Zolnierkiewicz:
o [ide] triflex: kill /proc/ide/triflex
o [ide] remove dead CMD640 debugging from ide-probe.c
o [ide] remove dead debugging code from ide-taskfile.c
o [ide] remove stale comment from ide-proc.c
o [ide] aec62xx: remove dead DEBUG_AEC_REGS code
o [ide] Simtec BAST (EB2410ITX) / Thorcom VR1000 driver
o [ide] cmd64x: kill dead DEBUG_CMD_REGS code
o [ide] kill dead TASKFILE_IN_OUT code
o [ide] pdc202xx_old: kill PDC202XX_DECODE_REGISTER_INFO
Bastian Blank:
o s390: sclp compile fix
Ben Dooks:
o [ARM PATCH] 2107/1: BAST - additional serial port fixes
o [ARM PATCH] 2102/1: BAST - incorrect IRQ for USB overcurrent
o [ARM PATCH] 2116/1: S3C2410 - s3c2410_gpio_cfgpin() mask bug
o [ARM PATCH] 2101/1: S3C2410 - usb port management
o [ARM PATCH] 2103/1: BAST - USB power control
o [ARM PATCH] 2118/1: S3C2410 - gpio updates and header file fix
o [ARM PATCH] 2119/1: S3C2410 -
include/asm-arm/arch-s3c2410/regs-mem.h
o [ARM PATCH] 2120/1: S3C2410 -
include/asm-arm/arch-s3c2410/regs-iic.h
o [ARM PATCH] 2121/1: S3C2410 - add S3C2410_MISCCR definitions for
power down config
o [ARM PATCH] 2122/1: S3C2410 - Documentation updates
o [ARM PATCH] 2124/1: S3C2410 -
include/asm-arm/arch-s3c2410/regs-spi.h
o [ARM PATCH] 2123/4: S3C2410 - GPIO IRQ IRQ Filtering and pin number
patch
o [ARM PATCH] 2127/1: S3C2410 - fix compile error in serial driver
o [ARM PATCH] 2129/1: S3C2410 - fix set_irq_type() for EINT0..EINT3
o [ARM PATCH] 2130/1: PXA255 Errata #31 fix for sleep.S
Benjamin Herrenschmidt:
o ppc64: Fix incorrect initialization of hash table on some pSeries
o Fix booting on some recent G5s
o ppc64: Fix find_udbg_vterm()
o ppc64: update g5_defconfig
o ppc64: Fix module exports for G5
Carsten Haustein:
o [ide] piix: fix wrong DMA mode selected
Catalin Marinas:
o [ARM PATCH] 2106/1: Remove the "write" assumption for Jazelle in
the early_abort handler
Chris Wright:
o mlockall(MCL_FUTURE) unlocks currently locked mappings
o mlockall() check rlimit only when MCL_CURRENT is set
o make can_do_mlock useful for mlock/mlockall
o mlockall() take mmap_sem a bit later
Christian Borntr?ger:
o s390: core changes
Christoph Hellwig:
o m32r: remove arch/m32r/drivers/m5.[ch]
o m32r: remove arch/m32r/drivers/cs_internal.h
Christoph Lameter:
o ppc: time interpolator build fix
Clemens Buchacher:
o sparc32: fix warning for changed section attributes
Colin Leroy:
o therm_adt746x: don't change loadavg
o use kthread_stop in therm_adt746x
o fix ans-lcd compilation
o fix warning in arch/ppc/pmac/simple/misc.c
o therm_adt746x: various fixes
Cornelia Huck:
o s390: common i/o layer
Dave Airlie:
o drm: Stop i830 and i915 both being build at same time
o drm: remove unused dma support remnants
Dave Craig:
o [IPV6]: Set skb->dev in ip6_pkt_discard_out
Dave Jiang:
o [ARM PATCH] 2117/1: Fix ATU config on IQ80331 to prevent master
aborts, replace 2099/1
Dave Jones:
o [AGPGART] Fix up sparse iomem warnings for amd-k7 driver
o [AGPGART] Fix up sparse iomem warnings of amd64 driver
o [AGPGART] Fix up sparse iomem warnings in ati driver
o [AGPGART] Fix up sparse iomem warnings in generic agp code
o [AGPGART] Fix up sparse iomem warning in Intel driver
o [AGPGART] Fix sparse iomem warnings in Intel MCH driver
o [AGPGART] Fix up sparse iomem warnings in NVidia driver
o [AGPGART] Fix up sparse iomem warnings in Serverworks driver
o [AGPGART] Fix sign extension bug in amd64 gart driver
o [AGPGART] Really add Intel i915 AGPGART Support
o PCI Hotplug: Use before NULL check in shpchp_ctrl
o find_isa_irq_pin can't be __init
David Gibson:
o ppc64: change bad choice of VSID_MULTIPLIER
o ppc64: squash childregs warnings
o ppc64: EEH checks mistakenly became no-ops
o ppc64: squash EEH warnings
o ppc64: remove redundant #ifdef CONFIG_ALTIVEC
o ppc64: Kconfig cleanups
David Mosberger:
o [IA64] signal.c: fix wrong argument order in __copy_to_user() call
o [IA64] ptrace.c: Fix unchecked user-memory accesses due to
ptrace_{get,set}regs()
o [IA64] fix argument-order in access_ok() call from
csum_partial_copy_from_user
o [IA64] Don't directly deref user pointers
o [IA64] sparse 0 vs. NULL cleanup patch
o [IA64] sparse "long" constant cleanup patch
o [IA64] minimal sparse-enablement; add __user annotations
o [IA64] sparse __iomem annotations
o [IA64] minor sparse cleanups
o [IA64] fix UP build
David S. Miller:
o [TCP]: Smooth out TSO ack clocking
o [SUNGEM]: Do not need two implementations of poll_controller, hehe
o [TCP]: Check correct sequence number for URG in tcp_tso_acked()
o [SUNGEM]: Fix build
o [TCP]: Add tcp_tso_win_divisor sysctl
o [TCP]: Kill tso_{factor,mss}
o [ATM]: Use neigh_table_{init,clear}() in clip.c
o [SPARC64]: Fix SI_TIMER conversion as ppc64 has
o [SPARC64]: Update defconfig
o [TCP]: Rename tcp_skb_psize() to tcp_skb_mss()
o [PKT_ACT]: Fixup tcf_result updating wrt. tcf_action_exec() calls
o [NET]: Kill typo in neighbour.c
o [NET]: Generic network statistics/estimator
o [SPARC64]: Make kprobe implementation more robust
o [SPARC64]: Kill sparse warning in power.c
o [SPARC64]: Use __iomem in chmc.c
o [SPARC64]: Add missing __user annotation to sys_sparc32.c
o [SPARC64]: Add __user annontation to ELF_CORE_COPY_REGS()
o [SPARC64]: Missing __user annotations for asm/checksum.h
o [SUNGEM]: Use NETDEV_TX_foo instead of magic constants
David Woodhouse:
o JFFS2 mount options discarded
o PPC64 Replace cmp instructions with cmpw/cmpd
Davide Libenzi:
o Avoid unnecessary copy for EPOLL_CTL_DEL
Deepak Saxena:
o Updated IXP4xx MTD driver from CVS (v1.6)
Ed L. Cashin:
o fix block layer ioctl bug
Eugene Surovegin:
o ppc32: export "indirect" DCR helpers
Fran?ois Romieu:
o via-velocity: properly manage the count of adapters
o via-velocity: removal of unused velocity_info.xmit_lock
o via-velocity: velocity_give_rx_desc() removal
o via-velocity: received ring wrong index and missing barriers
o via-velocity: early invocation of init_cam_filter()
o via-velocity: removal of incomplete endianness handling
o via-velocity: wrong buffer offset in velocity_init_td_ring()
o via-velocity: comment fixes
Geert Uytterhoeven:
o fix up tty fall-out
Gerald Schaefer:
o s390: z/VM monitor stream
o s390: dcss changes
Gerhard Jaeger:
o ppc32: fix PFC1_EPS and PFC1_EPS_SHIFT for IBM440GX
Greg Banks:
o [NET]: Fix race between neigh-timer_handler and neigh_event_send
Greg Kroah-Hartman:
o USB: fix error in bluetty.c driver caused by tty core changes
o USB: remove FIXME created from tty core changes in empeg driver
Harald Welte:
o [NETFILTER]: Fix NAT helper handling of TCP window tracking info
Herbert Xu:
o [NET]: Remove neigh hash expansion into already locked section
o [TCP]: Show all SYN_RECV sockets in /proc/net/tcp
o [TCP]: Fix bug that hid sockets in tcp_diag
Hideaki Yoshifuji:
o [IPV6]: NEIGHBOUR: hold refcnt of net_device from proxy neighbor
entries
o [IPV6]: Missing ip_rt_put() in SIT error path
o [INET]: Fix ECN encapsulation
Hidetoshi Seto:
o [IA64] Recovery from user-mode memory error
Hirokazu Takata:
o m32r: update comments for Renesas
o m32r: architecture upgrade on 20040928
o m32r: change to use temporary register variables
o m32r: update ioremap routine
o m32r: remove unused arch/m32r/kernel/io_m32102.c
o m32r: remove unused arch/m32r/m32700ut/m32r-flash.c
o m32r: remove arch/m32r/drivers
Horst Hummel:
o s390: dasd driver
Hugh Dickins:
o overcommit documentation fix
Ian Campbell:
o [ARM PATCH] 2113/1: include asm/arch/pxa-regs.h where necessary
o [ARM PATCH] 2114/1: fix drivers/char/watchdog/sa1100-wdt.c on
SA1100
o [ARM PATCH] 2133/1: params_phys is not available on PXA and apears
to be ARCH_RPM specific anyway
o pm: console driver fixes
Ingo Molnar:
o [IA64] Makefile: Fix to make ccache/distcc happy
o random driver preempt robustness
o Fix task_hot() balancing
o NX: fix read_implies_exec() related noexec-fs breakage
o Use cache_decay_ticks instead of a constant
James Morris:
o [CRYPTO]: Add __init and __initdata to aes.c
Jens Axboe:
o cdrom generic_packet oops fix
o [ide] ide-dma blacklist behaviour broken
Jesse Barnes:
o [IA64-SGI] sn2: serialize access to PROM chips
o [IA64] defconfig for Intel bigsur
Jon Smirl:
o document DRM ioctl use
o drm: cleanup header includes into one drm_core.h include
Jonathan Corbet:
o Remove get_cpu_ptr() comment reference
Josef 'Jeff' Sipek:
o Use proper sysfs mount-point in documentation
o Add DEVPATH env variable to hotplug helper call
Len Brown:
o [ACPI] fix __initdata bug in acpi_irq_penalty[]
o [ACPI] ACPICA 20040816 update from Bob Moore
o [ACPI] Enable ACPICA workarounds for 'RELAXED_AML' and 'implicit
return' These workarounds are disabled if "acpi=strict"
o [ACPI] quiet ACPI NUMA boot messages
o [ACPI] fix numa build warnings (Keith Owens)
o [ACPI] Export acpi_strict for use in modular drivers
o [ACPI] cleanup: use ioapic_register_intr()
o [ACPI] allow config to specify custom DSDT (Ulf Dambacher)
o [ACPI] debugging enhancements (Yi Zhu)
o [ACPI] move acpi_bios_year() to blacklist.c from dmi_scan.c (Pavel
Machek)
o [ACPI] delete ACPI DMI/BIOS cutoff year by default
o add GPL to mmconfig.c
o [ACPI] fix allmodconfig build
o [ACPI] x86_64 build fix
o [ACPI] fix double quoted params such as acpi_os_string="a b c" by
Christian Lupien http://bugzilla.kernel.org/show_bug.cgi?id=3242
o [ACPI] thermal module race condition/memory leak (David Shaohua Li)
http://bugzilla.kernel.org/show_bug.cgi?id=3231
o [ACPI] acpi4asus update: support W1N, v0.29
o [ACPI4ASUS] acpi_bus_register_driver() return code
o [ACPI4ASUS] support M6700R laptops
o [ACPI4ASUS] globalize hotk structure
o Cset exclude: [email protected]|ChangeSet|20041010081245|01886
o [ACPI] If BIOS disabled the LAPIC, believe it by default
Li Shaohua:
o pc110pad.c request_region() fix
o PCI resource allocation re-ordering
Linus Torvalds:
o Fix up natsemi network driver IO accessor types
o Wisdom passed down the ages on clay tablets
o The hpet acpi driver is not __initdata
o Fix cyclades driver types, and add __iomem annotations
o Remove casts and add __iomem annotations to gdth driver
o Fix up MMIO pointer types and add __iomem annotations to radeonfb.c
o Do trivial __iomem annotations for tridentfb.c
o Fix up and type-annotate sis fb driver
o Partially undo Alan's recent tty locking fixes: the termios lock
must not be held across the driver/ldisc downcalls.
o Fix close() vs posix lock race
o tty locking fixups: remove unused "flags" variable
o ppc64: fix non-C99 named initializers
o Remove test for __linux__ in auth_gss.h
o Fix up CHECKFLAGS definitions
o pcmcia: add iomem sparse annotations
o prism54: iomem annotations
o i386: mark do_test_wp_bit() noinline
o Remove rest of legacy arch/m32r/drivers directory
o Fix up signed one-bit bitfields in core sound code
o Update ray_cs Raylink/WebGear wireless driver
o Use "request_resource()" to properly fix up PCI resource clashes
o Linux 2.6.9-rc4
Maciej W. Rozycki:
o [NET]: Fix fddi_statistics for 64-bit
o [IPV4]: Set ARP hw type correctly for BOOTP over FDDI
o [IPV4]: Permit the official ARP hw type in SIOCSARP for FDDI
o APIC physical broadcast for i82489DX
Manfred Spraul:
o [NET]: Fix secure tcp sequence number generation
Matt Porter:
o ppc32: sync ppcboot.h with U-Boot
o ppc32: add U-Boot support to Ocotea/440GX port
o ppc32: fix several warnings
o ppc32: move some common PPC44x code to ibm44x_common.c
Maximilian Attems:
o [PCMCIA] replace schedule_timeout() with msleep()
o msleep_interruptible(): fix whitespace
Michael Hunold:
o Fix error path in Video4Linux dpc7146 driver
Nathan Scott:
o [XFS] Remove crufty old cap/mac code - never used, never compiled,
gone
o [XFS] Fix merge botch affecting xfs_setattr for realtime files
o [XFS] Fix sync issues - use correct writepage page re-dirty
interface, and do not clear dirty flag if page only partially
written.
Neil Horman:
o olympic driver: fix kernel oops on lobe fault
Nick Piggin:
o document isolcpus= boot option
o vm: prevent kswapd pageout priority windup
Paolo 'Blaisorblade' Giarrusso:
o uml: makefile fix for .lds scripts
o uml: makefile whitespace fix
o uml: add generic ptrace requests
o uml: fix get_user warning
o uml: remove wrong declaration
o uml: fix fd leak with HostFs
o uml: fix major & minor handling in hostfs
Patrick Caulfield:
o [DECNET]: Mark myself as maintainer
Patrick McHardy:
o [NET_SCHED]: Fix module leak in tc_ctl_tfilter error path
o [NET_SCHED]: Remove useless variable in tc_ctl_tfilter
o [IPV4]: Fix free_netdev after failed alloc_netdev in ipgre_init
o [IPV4]: Fix free_netdev after failed alloc_netdev in ipip_init
o [IPV4]: Fix ipip_fb_tunnel_dev leak in ipip_fini
o [IPV6]: Fix free_netdev after failed alloc_netdev in sit_init
o [VLAN]: Missing rtnl_unlock in register_vlan_device error path
Paul Mackerras:
o PPC64: Remove degree symbol from rtas-proc.c
o PPC64 Replace cmp instructions with cmpw/cmpd
Pavel Machek:
o swsusp: fix highmem
o Fix random crashes in x86-64 swsusp
Prasanna S. Panchamukhi:
o kprobes exception notifier fix
o kprobes exception notifier fix 2
Randy Dunlap:
o pc300: remove extra paren
o doc: remove lingering PC-9800 param
Roger Blofeld:
o [SERIAL] Pick nearest baud rate divider
Roland Dreier:
o ppc64: fix cross-compilation
Russell King:
o [ARM] ecard.c locking and wait_event_interruptible() fix
o [ARM] Add "noirqdebug" option to match x86 option
o [ARM] Fix consistent.c for DMA allocations
o [ARM] Check access permissions for whole of signal stack frame
o [ARM] Remove "%?" from within macros containing assembly
o [ARM] mach-types update
o [ARM] Add POSIX message queue and waitid syscalls
o [ARM] clk_* functions take frequencies in Hz not kHz
o [ARM] Fix params_phys with PIC decompressor builds
o [SERIAL] Fix warning and remove mach-types.h include
o [ARM] Add save_time_delta()/restore_time_delta()
o [ARM] Fix missing definition for OVERCOMMIT_ALWAYS
o Fix ide-cs resource management
o [ARM] Add decompressor support for ARMv6 caches
o [ARM] Remove cache type check before flushing ARMv6 cache
o [ARM] Mark source for copy_page const
o [ARM] Ecard initialisation tweaks
o [ARM] ecard.c: Make the ecard task completion per request
o [ARM] ecard.c: pass a function pointer for kecardd
o [ARM] ecard.c: Remove unnecessary context checks
o [PCMCIA] Improve locking for memory resource probing
o [PCMCIA] Remove two unused variables
Sascha Hauer:
o [ARM PATCH] 2095/1: i.MX time keeping
o [ARM PATCH] 2073/3: Hynix h720x architecture support
Stephen Hemminger:
o limit max jiffy of msecs_to_jiffies
St?phane Eranian:
o [IA64] perfmon2 fix for TASK_TRACED
o [IA64] minor fix to perfmon
o [IA64] perfmon2 fasync fix
Suresh B. Siddha:
o Disable SW irqbalance/irqaffinity for E7520/E7320/E7525 - change
TARGET_CPUS on x86_64
o x86_64: fix tss off by one
Sylvain Munaut:
o ppc: Name update/coherency and white space corrections for
Freescale MPC52xx
o ppc: Freescale MPC52xx hardware definitions misc updates/fix
o ppc: Fix missing include in Freescale MPC52xx syslib
o ppc: Fix spurious iounmap in Freescale MPC52xx syslib
o ppc: Use interactive console for Freescale MPC52xx when using
boot/simple
o ppc: Fix output of low-level serial debug on Freescale MPC52xx
o ppc: Update Freescale MPC52xx documentation / maintainer
o ppc: Add Freescale MPC52xx I2C Support using i2c-mpc.c
o ppc: Freescale MPC52xx interrupt controller init code update
o ppc: Disable the CAN_DOZE & CAN_NAP CPU features when a BDI is used
o ppc: Allow the Freescale MPC52xx to NAP when idle on LITE5200
platform
Thomas Graf:
o [PKT_SCHED]: Remove useless line in cbq_dump_class
o [PKT_SCHED]: Make rate estimator work on all platforms
Thomas Spatzier:
o s390: qeth network driver
Tom Rini:
o ppc32: Update the MVME5100 defconfig so it works out of the box
Tony Luck:
o [IA64] SMP systems may not have SRAT, still need to mark node0
online
o [IA64] mca.h, mca_drv.c: cleanup extern declarations
o [IA64] Don't hardcode offsets in thread_info
Venkatesh Pallipadi:
o cpufreq: ondemand: prevent various divide underflows
o cpufreq: ondemand: account iowait as idle time
Wensong Zhang:
o [IPVS]: Fix endian problem on sync message size
William Lee Irwin III:
o hugetlb: initialize sb->s_maxbytes
Yasuyuki Kozakai:
o [IPV6]: Fix ntohs() --> htons() typo in reassembly.c
Yoichi Yuasa:
o mips: added CPU type checking to interrupt control routines
o mips: added interrupt control routines for vrc4173
On Sunday 10 October 2004 23:22, Linus Torvalds wrote:
>Ok,
> trying to make ready for the real 2.6.9 in a week or so, so please
> give this a beating, and if you have pending patches, please hold
> on to them for a bit longer, until after the 2.6.9 release. It
> would be good to have a 2.6.9 that doesn't need a dot-release
> immediately ;)
>
>The appended shortlog gives a pretty good idea of what has been
> going on. Mostly small stuff, with some architecture updates and an
> ACPI update thrown in for good measure.
>
>(The ACPI update fixes broken AML with implied returns, and in
> particular the Compaq Evo notebook fan control. Yay! Guess who has
> one..)
>
> Linus
>
I'm running it, and dl'ing the suse livecd-9.1 to test the burning
sometime tomorrow. About the only unusual thing I see in dmesg is:
-----------------
EXT3 FS on hda8, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
EXT3-fs warning: maximal mount count reached, running e2fsck is
recommended
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdd2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
EXT3-fs warning: maximal mount count reached, running e2fsck is
recommended
kjournald starting. Commit interval 5 seconds
-----------------
but it *didn't* ask me to hit y for the check while it was booting.
Also, the last couple of -rc's seem to be keeping a lock on /usr when
shutting down, so the 3 attempts at a clean umount during the
shutdown phase all fail. I made sure that everything was stopped
except some screen backgrounds that come from /usr, and gkrellm,
which sits on every window here. That hasn't bothered the reboots
until maybe -rc2 but -rc3 for sure is doing it 100% of the time in
the shutdown phase.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Linus Torvalds <[email protected]> :
[...]
> Summary of changes from v2.6.9-rc3 to v2.6.9-rc4
> ============================================
[...]
> Fran?ois Romieu:
> o via-velocity: properly manage the count of adapters
> o via-velocity: removal of unused velocity_info.xmit_lock
> o via-velocity: velocity_give_rx_desc() removal
> o via-velocity: received ring wrong index and missing barriers
> o via-velocity: early invocation of init_cam_filter()
> o via-velocity: removal of incomplete endianness handling
> o via-velocity: wrong buffer offset in velocity_init_td_ring()
> o via-velocity: comment fixes
The attribution is a bit misleading as Tejun Heo <[email protected]>
did the real work (he appears in the logs though).
People should really, really, test this code if they have been
experiencing issues with the driver lately.
Test reports welcome here or on [email protected].
--
Ueimor
Hi,
> (The ACPI update fixes broken AML with implied returns, and in particular
> the Compaq Evo notebook fan control. Yay! Guess who has one..)
Well, I have one (N600c).
What am I supposed to see ? Is there anything special to do ?
I don't know exactly how fan control is supposed to be fixed.
Automatic wakeup/stop of these fans depending on the temperature
was already working.
Manual stopping of any fan (by writing into /proc/acpi/fan/*/state)
still doesn't work (don't know whether it's supposed to work or not).
By the way, I still see these errors during the boot, don't know if it's
supposed to be fixed :
psparse-1133: *** Error: Method execution failed
[\_SB_.C03E.C053.C0D1.C12E] (Node e7f9a3a8), AE_AML_UNINITIALIZED_LOCAL
psparse-1133: *** Error: Method execution failed
[\_SB_.C03E.C053.C0D1.C13D] (Node e7f9bd68), AE_AML_UNINITIALIZED_LOCAL
psparse-1133: *** Error: Method execution failed [\_SB_.C19F._BTP]
(Node e7fa3348), AE_AML_UNINITIALIZED_LOCAL
Regards,
Brice Goglin
Linus Torvalds wrote:
> Ok,
> trying to make ready for the real 2.6.9 in a week or so, so please give
> this a beating, and if you have pending patches, please hold on to them
> for a bit longer, until after the 2.6.9 release. It would be good to have
> a 2.6.9 that doesn't need a dot-release immediately ;)
The data corruption bug in the new megaraid driver version seems still
not to be fixed. LSI posted a fix some weeks ago, not sure how that went..
"[PATCH]: megaraid 2.20.4: Fixes a data corruption bug"
Linus Torvalds wrote:
> Ok,
> trying to make ready for the real 2.6.9 in a week or so, so please give
> this a beating, and if you have pending patches, please hold on to them
> for a bit longer, until after the 2.6.9 release. It would be good to have
> a 2.6.9 that doesn't need a dot-release immediately ;)
>
> The appended shortlog gives a pretty good idea of what has been going on.
> Mostly small stuff, with some architecture updates and an ACPI update
> thrown in for good measure.
>
> (The ACPI update fixes broken AML with implied returns, and in particular
> the Compaq Evo notebook fan control. Yay! Guess who has one..)
>
> Linus
>
ACPI still explodes on my old PII and stops it booting. (I've reported it
to Len a few times but he seems to be ignoring me).
Anyway, it is oopsing in drivers/acpi/scan.c line 207 where element
(which is NULL) gets dereferenced.
Adding a WARN_ON and return AE_BAD_PARAMETER for the element==NULL case
gives the following:
Badness in acpi_bus_extract_wakeup_device_power_package at drivers/acpi/scan.c:208
[<c021f8bf>] acpi_bus_extract_wakeup_device_power_package+0xfe/0x14b
[<c021f941>] acpi_bus_get_wakeup_device_flags+0x35/0x89
[<c021ff83>] acpi_bus_add+0xd4/0x152
[<c0220105>] acpi_bus_scan+0x104/0x156
[<c03d7742>] acpi_scan_init+0x48/0x5e
[<c03c57f4>] do_initcalls+0x54/0xc0
[<c0100410>] init+0x0/0x100
[<c0100410>] init+0x0/0x100
[<c010043a>] init+0x2a/0x100
[<c0102078>] kernel_thread_helper+0x0/0x18
[<c010207d>] kernel_thread_helper+0x5/0x18
[<c0100410>] init+0x0/0x100
[<c010043a>] init+0x2a/0x100
[<c0102078>] kernel_thread_helper+0x0/0x18
[<c010207d>] kernel_thread_helper+0x5/0x18
The ACPI bios on this thing has always seemed to be pretty broken, but
this at least allows the 'power' button to continue to work (the only
reason why I want ACPI).
Hmm... I don't want to hold up the release for this isolated problem.
Maybe if you're forced to do another -rc I could send in a trivial two
liner? (what's the policy with such a situation?)
Francois Romieu wrote:
> Linus Torvalds <[email protected]> :
> [...]
>
>>Summary of changes from v2.6.9-rc3 to v2.6.9-rc4
>>============================================
>
> [...]
>
>>Fran?ois Romieu:
>> o via-velocity: properly manage the count of adapters
>> o via-velocity: removal of unused velocity_info.xmit_lock
>> o via-velocity: velocity_give_rx_desc() removal
>> o via-velocity: received ring wrong index and missing barriers
>> o via-velocity: early invocation of init_cam_filter()
>> o via-velocity: removal of incomplete endianness handling
>> o via-velocity: wrong buffer offset in velocity_init_td_ring()
>> o via-velocity: comment fixes
>
>
> The attribution is a bit misleading as Tejun Heo <[email protected]>
> did the real work (he appears in the logs though).
>
> People should really, really, test this code if they have been
> experiencing issues with the driver lately.
>
> Test reports welcome here or on [email protected].
>
I'm finally able to successfully use my On board VT6122 10/100/1000 Mb
PCI Ethernet Controller on my Abit KV8-Pro. I have not found any
problems with the via-velocity driver yet. Great work! :)
Daniel Andersen
--
On Mon, 11 Oct 2004, Brice Goglin wrote:
>
> Well, I have one (N600c).
> What am I supposed to see ? Is there anything special to do ?
Different Evo, different BIOS, different AML bug. You might try to update
your BIOS, it might be fixed.
> I don't know exactly how fan control is supposed to be fixed.
> Automatic wakeup/stop of these fans depending on the temperature
> was already working.
It wasn't on the N620c.. That one had errors like
ACPI-1133: *** Error: Method execution failed [\_TZ_.C202] (Node c1926af0), AE_AML_NO_RETURN_VA
ACPI-1133: *** Error: Method execution failed [\_TZ_.C20C._STA] (Node c1926cd4), AE_AML_NO_RETU
but yours are different:
> By the way, I still see these errors during the boot, don't know if it's
> supposed to be fixed :
>
> psparse-1133: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C12E] (Node e7f9a3a8), AE_AML_UNINITIALIZED_LOCAL
> psparse-1133: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C13D] (Node e7f9bd68), AE_AML_UNINITIALIZED_LOCAL
> psparse-1133: *** Error: Method execution failed [\_SB_.C19F._BTP] (Node e7fa3348), AE_AML_UNINITIALIZED_LOCAL
Have you made a acpi bugzilla entry for this?
Linus
On Mon, 11 Oct 2004, Andre Tomt wrote:
>
> The data corruption bug in the new megaraid driver version seems still
> not to be fixed. LSI posted a fix some weeks ago, not sure how that went..
>
> "[PATCH]: megaraid 2.20.4: Fixes a data corruption bug"
I think that one is already in the SCSI BK tree, just not pushed to me.
Perhaps because the tree contains other less important patches that James
doesn't think are worthy yet.. James? Should I just take the small
megaraid patch directly (and leave the compat ioctl cleanups etc to you)?
Linus
On Mon, 11 Oct 2004, Linus Torvalds wrote:
>
> That said, your patch is small and simple, so..
Btw, out of interest, make it print out the "package->type" for the
failure case. It should be ACPI_TYPE_PACKAGE (4), I think, but..
Linus
No, we didn't have two rc3 releases. See updated stats...
> 2.6.9-rc3 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
> 2.6.9-rc3 0w/0e 0w/0e 2752w/17e 41w/0e 11w/0e 2782w/5e
> 2.6.9-rc2 0w/0e 0w/0e 3036w/0e 41w/0e 11w/0e 3655w/0e
> 2.6.9-rc1 0w/0e 0w/0e 77w/10e 4w/0e 3w/0e 68w/0e
Linux 2.6 Compile Statistics (gcc 3.2.2)
Web page with links to complete details:
http://developer.osdl.org/cherry/compile/
Kernel bzImage bzImage bzImage modules bzImage modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
----------- ----------- -------- -------- -------- -------- ---------
2.6.9-rc4 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
2.6.9-rc3 0w/0e 0w/0e 2752w/17e 41w/0e 11w/0e 2782w/5e
2.6.9-rc2 0w/0e 0w/0e 3036w/0e 41w/0e 11w/0e 3655w/0e
2.6.9-rc1 0w/0e 0w/0e 77w/10e 4w/0e 3w/0e 68w/0e
2.6.8.1 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
--
John Cherry
[email protected]
503-626-2455x29
Open Source Development Labs
>
>but yours are different:
>
>> By the way, I still see these errors during the boot, don't
>know if it's
>> supposed to be fixed :
>>
>> psparse-1133: *** Error: Method execution failed
>[\_SB_.C03E.C053.C0D1.C12E] (Node e7f9a3a8), AE_AML_UNINITIALIZED_LOCAL
>> psparse-1133: *** Error: Method execution failed
>[\_SB_.C03E.C053.C0D1.C13D] (Node e7f9bd68), AE_AML_UNINITIALIZED_LOCAL
>> psparse-1133: *** Error: Method execution failed
>[\_SB_.C19F._BTP] (Node e7fa3348), AE_AML_UNINITIALIZED_LOCAL
>
..snippets from ASL language spec.(defined in ACPI spec).
17.5.69 Localx (Method Local Data Objects)
...
On entry to a control method, these objects are uninitialized
and cannot be used until some value or reference is stored
into the object....
I guess AML interpreter successfully catch a bug violating
the rule above. Please attach /proc/acpi/dsdt in bug report.
Thanks,
Luming
On Mon, 11 Oct 2004, Nick Piggin wrote:
>
> ACPI still explodes on my old PII and stops it booting. (I've reported it
> to Len a few times but he seems to be ignoring me).
I suspect the "CONFIG_ACPI_BLACKLIST_YEAR" might be the solution they came
up with. Old ACPI stuff tends to be broken.
That said, your patch is small and simple, so..
Linus
Compiling with gcc 3.4 results in the following compile errors:
<-- snip -->
CC drivers/scsi/qla2xxx/qla_os.o
drivers/scsi/qla2xxx/qla_os.c: In function `qla2x00_queuecommand':
drivers/scsi/qla2xxx/qla_os.c:315: sorry, unimplemented: inlining failed
in call to 'qla2x00_callback': function not considered for inlining
drivers/scsi/qla2xxx/qla_os.c:269: sorry, unimplemented: called from here
drivers/scsi/qla2xxx/qla_os.c:315: sorry, unimplemented: inlining failed
in call to 'qla2x00_callback': function not considered for inlining
drivers/scsi/qla2xxx/qla_os.c:269: sorry, unimplemented: called from here
make[3]: *** [drivers/scsi/qla2xxx/qla_os.o] Error 1
...
CC drivers/scsi/qla2xxx/qla_rscn.o
drivers/scsi/qla2xxx/qla_rscn.c: In function `qla2x00_cancel_io_descriptors':
drivers/scsi/qla2xxx/qla_rscn.c:320: sorry, unimplemented: inlining
failed in call to 'qla2x00_remove_iodesc_timer': function not considered for inlining
drivers/scsi/qla2xxx/qla_rscn.c:257: sorry, unimplemented: called from here
make[3]: *** [drivers/scsi/qla2xxx/qla_rscn.o] Error 1
<-- snip -->
Please apply my patch below which is already for some time in James'
SCSI tree.
diffstat output:
drivers/scsi/qla2xxx/qla_os.c | 122 ++++++++++++++++----------------
drivers/scsi/qla2xxx/qla_rscn.c | 28 +++----
2 files changed, 75 insertions(+), 75 deletions(-)
Signed-off-by: Adrian Bunk <[email protected]>
--- a/drivers/scsi/qla2xxx/qla_os.c 2004-10-10 22:27:31 -07:00
+++ b/drivers/scsi/qla2xxx/qla_os.c 2004-10-10 22:27:31 -07:00
@@ -235,67 +236,6 @@
static __inline__ void
qla2x00_delete_from_done_queue(scsi_qla_host_t *, srb_t *);
-/**************************************************************************
-* sp_put
-*
-* Description:
-* Decrement reference count and call the callback if we're the last
-* owner of the specified sp. Will get the host_lock before calling
-* the callback.
-*
-* Input:
-* ha - pointer to the scsi_qla_host_t where the callback is to occur.
-* sp - pointer to srb_t structure to use.
-*
-* Returns:
-*
-**************************************************************************/
-static inline void
-sp_put(struct scsi_qla_host * ha, srb_t *sp)
-{
- if (atomic_read(&sp->ref_count) == 0) {
- qla_printk(KERN_INFO, ha,
- "%s(): **** SP->ref_count not zero\n",
- __func__);
- DEBUG2(BUG();)
-
- return;
- }
-
- if (!atomic_dec_and_test(&sp->ref_count)) {
- return;
- }
-
- qla2x00_callback(ha, sp->cmd);
-}
-
-/**************************************************************************
-* sp_get
-*
-* Description:
-* Increment reference count of the specified sp.
-*
-* Input:
-* sp - pointer to srb_t structure to use.
-*
-* Returns:
-*
-**************************************************************************/
-static inline void
-sp_get(struct scsi_qla_host * ha, srb_t *sp)
-{
- atomic_inc(&sp->ref_count);
-
- if (atomic_read(&sp->ref_count) > 2) {
- qla_printk(KERN_INFO, ha,
- "%s(): **** SP->ref_count greater than two\n",
- __func__);
- DEBUG2(BUG();)
-
- return;
- }
-}
-
/*
* qla2x00_callback
* Returns the completed SCSI command to LINUX.
@@ -366,6 +306,67 @@
(*(cmd)->scsi_done)(cmd);
}
+/**************************************************************************
+* sp_put
+*
+* Description:
+* Decrement reference count and call the callback if we're the last
+* owner of the specified sp. Will get the host_lock before calling
+* the callback.
+*
+* Input:
+* ha - pointer to the scsi_qla_host_t where the callback is to occur.
+* sp - pointer to srb_t structure to use.
+*
+* Returns:
+*
+**************************************************************************/
+static inline void
+sp_put(struct scsi_qla_host * ha, srb_t *sp)
+{
+ if (atomic_read(&sp->ref_count) == 0) {
+ qla_printk(KERN_INFO, ha,
+ "%s(): **** SP->ref_count not zero\n",
+ __func__);
+ DEBUG2(BUG();)
+
+ return;
+ }
+
+ if (!atomic_dec_and_test(&sp->ref_count)) {
+ return;
+ }
+
+ qla2x00_callback(ha, sp->cmd);
+}
+
+/**************************************************************************
+* sp_get
+*
+* Description:
+* Increment reference count of the specified sp.
+*
+* Input:
+* sp - pointer to srb_t structure to use.
+*
+* Returns:
+*
+**************************************************************************/
+static inline void
+sp_get(struct scsi_qla_host * ha, srb_t *sp)
+{
+ atomic_inc(&sp->ref_count);
+
+ if (atomic_read(&sp->ref_count) > 2) {
+ qla_printk(KERN_INFO, ha,
+ "%s(): **** SP->ref_count greater than two\n",
+ __func__);
+ DEBUG2(BUG();)
+
+ return;
+ }
+}
+
static inline void
qla2x00_delete_from_done_queue(scsi_qla_host_t *dest_ha, srb_t *sp)
{
--- a/drivers/scsi/qla2xxx/qla_rscn.c 2004-10-10 22:27:29 -07:00
+++ b/drivers/scsi/qla2xxx/qla_rscn.c 2004-10-10 22:27:29 -07:00
@@ -242,6 +242,20 @@
}
/**
+ * qla2x00_remove_iodesc_timer() - Remove an active timer from an IO descriptor.
+ * @iodesc: io descriptor
+ */
+static inline void
+qla2x00_remove_iodesc_timer(struct io_descriptor *iodesc)
+{
+ if (iodesc->timer.function != NULL) {
+ del_timer_sync(&iodesc->timer);
+ iodesc->timer.data = (unsigned long) NULL;
+ iodesc->timer.function = NULL;
+ }
+}
+
+/**
* qla2x00_init_io_descriptors() - Initialize the pool of IO descriptors.
* @ha: HA context
*/
@@ -309,20 +323,6 @@
iodesc->timer.function =
(void (*) (unsigned long)) qla2x00_iodesc_timeout;
add_timer(&iodesc->timer);
-}
-
-/**
- * qla2x00_remove_iodesc_timer() - Remove an active timer from an IO descriptor.
- * @iodesc: io descriptor
- */
-static inline void
-qla2x00_remove_iodesc_timer(struct io_descriptor *iodesc)
-{
- if (iodesc->timer.function != NULL) {
- del_timer_sync(&iodesc->timer);
- iodesc->timer.data = (unsigned long) NULL;
- iodesc->timer.function = NULL;
- }
}
/**
Linux 2.6 Compile Statistics (gcc 3.2.2)
Web page with links to complete details:
http://developer.osdl.org/cherry/compile/
Kernel bzImage bzImage bzImage modules bzImage modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
----------- ----------- -------- -------- -------- -------- ---------
2.6.9-rc3 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
2.6.9-rc3 0w/0e 0w/0e 2752w/17e 41w/0e 11w/0e 2782w/5e
2.6.9-rc2 0w/0e 0w/0e 3036w/0e 41w/0e 11w/0e 3655w/0e
2.6.9-rc1 0w/0e 0w/0e 77w/10e 4w/0e 3w/0e 68w/0e
2.6.8.1 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8-rc4 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8-rc3 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8-rc2 0w/0e 0w/0e 85w/ 0e 5w/0e 1w/0e 79w/0e
2.6.8-rc1 0w/0e 0w/0e 87w/ 0e 5w/0e 1w/0e 82w/0e
2.6.7 0w/0e 0w/0e 108w/ 0e 5w/0e 2w/0e 102w/0e
2.6.7-rc3 0w/0e 0w/0e 108w/ 0e 5w/0e 2w/0e 104w/0e
2.6.7-rc2 0w/0e 0w/0e 110w/ 0e 5w/0e 2w/0e 106w/0e
2.6.7-rc1 0w/0e 0w/0e 111w/ 0e 6w/0e 2w/0e 107w/0e
2.6.6 0w/0e 0w/0e 123w/ 0e 7w/0e 4w/0e 121w/0e
2.6.6-rc3 0w/0e 0w/0e 124w/ 0e 7w/0e 5w/0e 121w/0e
2.6.6-rc2 0w/0e 0w/0e 122w/ 0e 7w/0e 4w/0e 121w/0e
2.6.6-rc1 0w/0e 0w/0e 125w/ 0e 7w/0e 4w/0e 123w/0e
2.6.5 0w/0e 0w/0e 134w/ 0e 8w/0e 4w/0e 132w/0e
2.6.5-rc3 0w/0e 0w/0e 135w/ 0e 8w/0e 4w/0e 132w/0e
2.6.5-rc2 0w/0e 0w/0e 135w/ 0e 8w/0e 3w/0e 132w/0e
2.6.5-rc1 0w/0e 0w/0e 138w/ 0e 8w/0e 3w/0e 135w/0e
2.6.4 1w/0e 0w/0e 145w/ 0e 7w/0e 3w/0e 142w/0e
2.6.4-rc2 1w/0e 0w/0e 148w/ 0e 7w/0e 3w/0e 145w/0e
2.6.4-rc1 1w/0e 0w/0e 148w/ 0e 7w/0e 3w/0e 145w/0e
2.6.3 1w/0e 0w/0e 142w/ 0e 9w/0e 3w/0e 142w/0e
2.6.3-rc4 1w/0e 0w/0e 142w/ 0e 9w/0e 3w/0e 142w/0e
2.6.3-rc3 1w/0e 0w/0e 145w/ 7e 9w/0e 3w/0e 148w/0e
2.6.3-rc2 1w/0e 0w/0e 141w/ 0e 9w/0e 3w/0e 144w/0e
2.6.3-rc1 1w/0e 0w/0e 145w/ 0e 9w/0e 3w/0e 177w/0e
2.6.2 1w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
2.6.2-rc3 0w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
2.6.2-rc2 0w/0e 0w/0e 153w/ 8e 12w/0e 3w/0e 188w/0e
2.6.2-rc1 0w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
2.6.1 0w/0e 0w/0e 158w/ 0e 12w/0e 3w/0e 197w/0e
2.6.1-rc3 0w/0e 0w/0e 158w/ 0e 12w/0e 3w/0e 197w/0e
2.6.1-rc2 0w/0e 0w/0e 166w/ 0e 12w/0e 3w/0e 205w/0e
2.6.1-rc1 0w/0e 0w/0e 167w/ 0e 12w/0e 3w/0e 206w/0e
2.6.0 0w/0e 0w/0e 170w/ 0e 12w/0e 3w/0e 209w/0e
Daily compiles (ia32):
http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt
Latest changes in Linus' bitkeeper tree:
http://linux.bkbits.net:8080/linux-2.5
--
John Cherry
[email protected]
503-626-2455x29
Open Source Development Labs
On Mon, Oct 11, 2004 at 11:28:42AM -0500, James Bottomley wrote:
> On Mon, 2004-10-11 at 11:24, Adrian Bunk wrote:
> > Please apply my patch below which is already for some time in James'
> > SCSI tree.
>
> It's waiting in my tree until 2.6.9 goes final because gcc-3.4 fixes are
> hardly showstoppers. If you want to compile the kernel with gcc-3.4 use
> -mm
It's the only compile error with gcc 3.4 I found in 2.6.9-rc4, and the
fix is pretty low-risk.
> James
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, 2004-10-11 at 10:02, Linus Torvalds wrote:
>
>
> On Mon, 11 Oct 2004, Andre Tomt wrote:
> >
> > The data corruption bug in the new megaraid driver version seems still
> > not to be fixed. LSI posted a fix some weeks ago, not sure how that went..
> >
> > "[PATCH]: megaraid 2.20.4: Fixes a data corruption bug"
>
> I think that one is already in the SCSI BK tree, just not pushed to me.
> Perhaps because the tree contains other less important patches that James
> doesn't think are worthy yet.. James? Should I just take the small
> megaraid patch directly (and leave the compat ioctl cleanups etc to you)?
I have no objections. However, I was planning on pushing it through the
SCSI tree because it's in the new megaraid driver which is experimental
at the moment (the old megaraid driver is still in and still
selectable). It's been in -mm for a few days now with no ill effects, I
think, but I'm not sure how many megaraid owners have actually tested
it.
James
On Mon, 2004-10-11 at 11:24, Adrian Bunk wrote:
> Please apply my patch below which is already for some time in James'
> SCSI tree.
It's waiting in my tree until 2.6.9 goes final because gcc-3.4 fixes are
hardly showstoppers. If you want to compile the kernel with gcc-3.4 use
-mm
James
Yes, I also am able to finally use the via-velocity card without it
taking down my router! The patches resolve issues with the card. I
have been heavily using it now without a problem on X86_64 Linux. I
have an Abit A8V with integrated Via Velocity card
On Mon, 11 Oct 2004 09:23:07 +0200, Francois Romieu
<[email protected]> wrote:
> Linus Torvalds <[email protected]> :
> [...]
> > Summary of changes from v2.6.9-rc3 to v2.6.9-rc4
> > ============================================
> [...]
> > Fran?ois Romieu:
> > o via-velocity: properly manage the count of adapters
> > o via-velocity: removal of unused velocity_info.xmit_lock
> > o via-velocity: velocity_give_rx_desc() removal
> > o via-velocity: received ring wrong index and missing barriers
> > o via-velocity: early invocation of init_cam_filter()
> > o via-velocity: removal of incomplete endianness handling
> > o via-velocity: wrong buffer offset in velocity_init_td_ring()
> > o via-velocity: comment fixes
>
> The attribution is a bit misleading as Tejun Heo <[email protected]>
> did the real work (he appears in the logs though).
>
> People should really, really, test this code if they have been
> experiencing issues with the driver lately.
>
> Test reports welcome here or on [email protected].
>
> --
> Ueimor
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Mon, 2004-10-11 at 11:35, Adrian Bunk wrote:
> It's the only compile error with gcc 3.4 I found in 2.6.9-rc4, and the
> fix is pretty low-risk.
But also not essential. If we apply lots of inessential but low risk
fixes, all we end up with is merge problems in the various BK trees and
no real benefit. The fix is queued, it will be in early 2.6.9, just be
patient.
James
James Bottomley wrote:
> On Mon, 2004-10-11 at 10:02, Linus Torvalds wrote:
>>On Mon, 11 Oct 2004, Andre Tomt wrote:
>>>"[PATCH]: megaraid 2.20.4: Fixes a data corruption bug"
>>
>>I think that one is already in the SCSI BK tree, just not pushed to me.
>>Perhaps because the tree contains other less important patches that James
>>doesn't think are worthy yet.. James? Should I just take the small
>>megaraid patch directly (and leave the compat ioctl cleanups etc to you)?
>
> I have no objections. However, I was planning on pushing it through the
> SCSI tree because it's in the new megaraid driver which is experimental
> at the moment (the old megaraid driver is still in and still
> selectable). It's been in -mm for a few days now with no ill effects, I
> think, but I'm not sure how many megaraid owners have actually tested
> it.
I've been running 2.20.3.1 + the data corruption bug fix on megaraids
ranging from low-end SATA adapters to the u320scsi ones for a while on a
2.6.8 based kernel, nothing have blown up yet. The old 2.20.3.1 without
the fix have been holding up too though - however having a known data
corruption bug lingering doesn't feel so good :-)
On Mon, 2004-10-11 at 13:22, Andre Tomt wrote:
> I've been running 2.20.3.1 + the data corruption bug fix on megaraids
> ranging from low-end SATA adapters to the u320scsi ones for a while on a
> 2.6.8 based kernel, nothing have blown up yet. The old 2.20.3.1 without
> the fix have been holding up too though - however having a known data
> corruption bug lingering doesn't feel so good :-)
Yes, well, that's one of the things that worries me slightly ... no-one
has reported the data corruption that the patch claims to fix. That's
one of the reasons I was planning to take it through the normal cycle.
James
man, 11,.10.2004 kl. 07.57 -0700, skrev Linus Torvalds:
>
> On Mon, 11 Oct 2004, Brice Goglin wrote:
> >
> > Well, I have one (N600c).
> > What am I supposed to see ? Is there anything special to do ?
>
> Different Evo, different BIOS, different AML bug. You might try to update
> your BIOS, it might be fixed.
>
The latest BIOS didn't make a difference for me at least.
> > I don't know exactly how fan control is supposed to be fixed.
> > Automatic wakeup/stop of these fans depending on the temperature
> > was already working.
>
> It wasn't on the N620c.. That one had errors like
>
> ACPI-1133: *** Error: Method execution failed [\_TZ_.C202] (Node c1926af0), AE_AML_NO_RETURN_VA
> ACPI-1133: *** Error: Method execution failed [\_TZ_.C20C._STA] (Node c1926cd4), AE_AML_NO_RETU
>
> but yours are different:
>
> > By the way, I still see these errors during the boot, don't know if it's
> > supposed to be fixed :
> >
> > psparse-1133: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C12E] (Node e7f9a3a8), AE_AML_UNINITIALIZED_LOCAL
> > psparse-1133: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C13D] (Node e7f9bd68), AE_AML_UNINITIALIZED_LOCAL
> > psparse-1133: *** Error: Method execution failed [\_SB_.C19F._BTP] (Node e7fa3348), AE_AML_UNINITIALIZED_LOCAL
>
> Have you made a acpi bugzilla entry for this?
>
I made one a while ago:
http://bugzilla.kernel.org/show_bug.cgi?id=1404
Cheers
Kjartan
On Mon, 11 Oct 2004, James Bottomley wrote:
> On Mon, 2004-10-11 at 10:02, Linus Torvalds wrote:
> >
> >
> > On Mon, 11 Oct 2004, Andre Tomt wrote:
> > >
> > > The data corruption bug in the new megaraid driver version seems still
> > > not to be fixed. LSI posted a fix some weeks ago, not sure how that went..
> > >
> > > "[PATCH]: megaraid 2.20.4: Fixes a data corruption bug"
> >
> > I think that one is already in the SCSI BK tree, just not pushed to me.
> > Perhaps because the tree contains other less important patches that James
> > doesn't think are worthy yet.. James? Should I just take the small
> > megaraid patch directly (and leave the compat ioctl cleanups etc to you)?
>
> I have no objections. However, I was planning on pushing it through the
> SCSI tree because it's in the new megaraid driver which is experimental
> at the moment (the old megaraid driver is still in and still
> selectable). It's been in -mm for a few days now with no ill effects, I
> think, but I'm not sure how many megaraid owners have actually tested
> it.
No problems here with the 2.20.4....
later,
chris
On Sun, Oct 10, 2004 at 08:22:54PM -0700, Linus Torvalds wrote:
> trying to make ready for the real 2.6.9 in a week or so, so please give
> this a beating, and if you have pending patches, please hold on to them
> for a bit longer, until after the 2.6.9 release. It would be good to have
> a 2.6.9 that doesn't need a dot-release immediately ;)
With 2.6.9-rc4, using matroxfb, I can no longer pass
video=1280x1024-8@85. This worked on 2.6.8.1, and I'm trying kernels
inbetween now.
$ cat /proc/cmdline
root=/dev/hda1 ro video=1280x1024-8@85 elevator=cfq
$ zgrep -E CONFIG_\(FB\|VIDEO\).*= /proc/config.gz
CONFIG_FB=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_G450=y
CONFIG_FB_MATROX_G100=y
CONFIG_FB_MATROX_I2C=y
$ dmesg | grep matrox
matroxfb: Matrox G450 detected
matroxfb: MTRR's turned on
matroxfb: 640x480x8bpp (virtual: 640x26214)
matroxfb: framebuffer at 0xCC000000, mapped to 0xe0880000, size 33554432
matroxfb_crtc2: secondary head of fb0 was registered as fb1
--
Tom Rini
http://gate.crashing.org/~trini/
On Mon, Oct 11, 2004 at 03:04:49PM -0700, Tom Rini wrote:
> On Sun, Oct 10, 2004 at 08:22:54PM -0700, Linus Torvalds wrote:
>
> > trying to make ready for the real 2.6.9 in a week or so, so please give
> > this a beating, and if you have pending patches, please hold on to them
> > for a bit longer, until after the 2.6.9 release. It would be good to have
> > a 2.6.9 that doesn't need a dot-release immediately ;)
>
> With 2.6.9-rc4, using matroxfb, I can no longer pass
> video=1280x1024-8@85. This worked on 2.6.8.1, and I'm trying kernels
> inbetween now.
The problem happened inbetween -rc1 and -rc2.
--
Tom Rini
http://gate.crashing.org/~trini/
On Mon, 11 Oct 2004, James Bottomley wrote:
>
> Yes, well, that's one of the things that worries me slightly ... no-one
> has reported the data corruption that the patch claims to fix. That's
> one of the reasons I was planning to take it through the normal cycle.
Well, as far as I can tell from the patch, the only way to get data
corruption from the bug is when you use the SCSI ioctl's at the same time
as the disk is busy.
In other words, I think you'd have to do some special disk management, or
possibly try to burn a CD on a SCSI CD-ROM (or other special device that
uses the SCSI ioctl's) on the same controller. And nobody uses SCSI
CD-burners any more, I'd think.
Linus
Linus Torvalds wrote:
>
> On Mon, 11 Oct 2004, Nick Piggin wrote:
>
>>ACPI still explodes on my old PII and stops it booting. (I've reported it
>>to Len a few times but he seems to be ignoring me).
>
>
> I suspect the "CONFIG_ACPI_BLACKLIST_YEAR" might be the solution they came
> up with. Old ACPI stuff tends to be broken.
>
True. I am using acpi=force afterall.
> That said, your patch is small and simple, so..
>
OK you've merged it... well thanks. I guess considering I'm the only
one seeing this, it isn't going to impact anyone but me. Probably
avoiding an oops is a good thing even if it is due to broken hardware.
Linus Torvalds wrote:
>
> On Mon, 11 Oct 2004, Linus Torvalds wrote:
>
>>That said, your patch is small and simple, so..
>
>
> Btw, out of interest, make it print out the "package->type" for the
> failure case. It should be ACPI_TYPE_PACKAGE (4), I think, but..
>
ACPI: element was NULL! package = 1
On Mon, 2004-10-11 at 19:35, Linus Torvalds wrote:
> Well, as far as I can tell from the patch, the only way to get data
> corruption from the bug is when you use the SCSI ioctl's at the same time
> as the disk is busy.
>
> In other words, I think you'd have to do some special disk management, or
> possibly try to burn a CD on a SCSI CD-ROM (or other special device that
> uses the SCSI ioctl's) on the same controller. And nobody uses SCSI
> CD-burners any more, I'd think.
This is not some far-out scenario. For a long time Plextor SCSI burners
were the best on the market, there are 1000's of them out there.
Lee
On Mon, 11 Oct 2004, James Bottomley wrote:
>> Yes, well, that's one of the things that worries me slightly ... no-one
>> has reported the data corruption that the patch claims to fix. That's
>> one of the reasons I was planning to take it through the normal cycle.
On Mon, Oct 11, 2004 at 04:35:50PM -0700, Linus Torvalds wrote:
> Well, as far as I can tell from the patch, the only way to get data
> corruption from the bug is when you use the SCSI ioctl's at the same time
> as the disk is busy.
> In other words, I think you'd have to do some special disk management, or
> possibly try to burn a CD on a SCSI CD-ROM (or other special device that
> uses the SCSI ioctl's) on the same controller. And nobody uses SCSI
> CD-burners any more, I'd think.
Hey! I do. For some reason I've not hit this data corruption. I guess
it's a good question as to why; maybe I trail mainline by long enough
on my "desktop" to have missed where it was introduced.
-- wli
On Tue, Oct 12, 2004 at 09:48:08AM +1000, Nick Piggin wrote:
> OK you've merged it... well thanks. I guess considering I'm the only
> one seeing this, it isn't going to impact anyone but me. Probably
> avoiding an oops is a good thing even if it is due to broken hardware.
FWIW I think at one point I saw this oops, or a similar one -- but I
just didn't bother reporting it. So, I'm glad that this check has been
added.
-Barry K. Nathan <[email protected]>
On Mon, 11 Oct 2004, Linus Torvalds wrote:
>
> In other words, I think you'd have to do some special disk management, or
> possibly try to burn a CD on a SCSI CD-ROM (or other special device that
> uses the SCSI ioctl's) on the same controller. And nobody uses SCSI
> CD-burners any more, I'd think.
>
Not so, I personally have a SCSI Plextor burner, and at work we have
several different other brands of SCSI burners, I also have a few friends
who have SCSI burners (the majority have IDE burners, but there are a few
with SCSI).
And personally I'm buying a new SCSI burner if this one dies, I've never
had a burner as troublefree as this one. IDE burners are no longer for me.
--
Jesper Juhl
On Sun, 10 Oct 2004, Linus Torvalds wrote:
> trying to make ready for the real 2.6.9 in a week or so, so please give
> this a beating, and if you have pending patches, please hold on to them
> for a bit longer, until after the 2.6.9 release. It would be good to have
> a 2.6.9 that doesn't need a dot-release immediately ;)
How about Marcelo's policy that the -final version should differ from
the last -rc only in the Makefile VERSION and nothing else (well,
documentation perhaps if someone else has proofread it).
Would you be ready to have the last -rc out for, say, five days, before
releasing the official, final, blessed, however 2.6.9, in order to catch
the showstoppers?
--
Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)
On Tue, Oct 12, 2004 at 10:05:37AM +0200, Matthias Andree wrote:
> On Sun, 10 Oct 2004, Linus Torvalds wrote:
>
> > trying to make ready for the real 2.6.9 in a week or so, so please give
> > this a beating, and if you have pending patches, please hold on to them
> > for a bit longer, until after the 2.6.9 release. It would be good to have
> > a 2.6.9 that doesn't need a dot-release immediately ;)
>
> How about Marcelo's policy that the -final version should differ from
> the last -rc only in the Makefile VERSION and nothing else (well,
> documentation perhaps if someone else has proofread it).
>
> Would you be ready to have the last -rc out for, say, five days, before
> releasing the official, final, blessed, however 2.6.9, in order to catch
> the showstoppers?
Like this one? 2.6.9-rc4 does not build with
gcc-2.95.3 + binutils-2.15.92.0.2.
Signed-Off-By: Sami Farin <[email protected]>
--- linux/net/ipv4/tcp_output.c.bak 2004-10-11 18:24:06.000000000 +0300
+++ linux/net/ipv4/tcp_output.c 2004-10-11 22:12:32.000000000 +0300
@@ -445,7 +445,7 @@ void tcp_set_skb_tso_segs(struct sk_buff
skb_shinfo(skb)->tso_size = mss_std;
}
}
-EXPORT_SYMBOL_GPL(tcp_set_skb_tso_factor);
+EXPORT_SYMBOL_GPL(tcp_set_skb_tso_segs);
/* Function to create two new TCP segments. Shrinks the given segment
* to the specified size and appends a new segment with the rest of the
--