Now, most of you are probably going to be totally bored out of your minds
on Christmas day, and here's the perfect distraction. Test 2.6.15-rc7. All
the stores will be closed, and there's really nothing better to do in
between meals.
A number of mostly one-liners. The biggest ones are probably some s390
qeth updates and some ipv6 fixes, the rest is just a number of small
fixes. The shortlog gives a pretty good picture of what's going on. I
suspect the forcedeth fix is the one most likely to affect any reasonable
number of people, although the more relaxed usb suspend probably makes
a big difference.
Please do give it a try, and if you have any issues/regressions, send out
a note (even if you sent one earlier) so that we don't forget about it.
Thanks,
Linus
---
Adrian Bunk:
[SPARC]: Fix RTC build failure.
include/linux/irq.h: #include <linux/smp.h>
[SUNGEM]: Fix link error with CONFIG_HOTPLUG disabled.
[SPARC]: introduce a SPARC Kconfig symbol
Alan Stern:
usbcore: allow suspend/resume even if drivers don't support it
Alex Williamson:
[ACPI] increase owner_id limit to 64 from 32
Andi Kleen:
Fix swiotlb pci_map_sg error handling
Fix build with CONFIG_PCI_MMCONFIG
Andreas Gruenbacher:
nfsd: check for read-only exports before setting acls
Andrew Morton:
Fix memory ordering problem in wake_futex()
Antonino A. Daplas:
intelfb: Fix freeing of nonexistent resource
intelfb: Fix oops when changing video mode
ASANO Masahiro:
fix posix lock on NFS
Bart De Schuymer:
[BRIDGE-NF]: Fix bridge-nf ipv6 length check
Ben Collins:
block: Cleanup CDROMEJECT ioctl
Fix typo in x86_64 __build_write_lock_const assembly
Benjamin Herrenschmidt:
powerpc: g5 thermal overtemp bug
David S. Miller:
[IPSEC]: Perform SA switchover immediately.
[SPARC64]: Stop putting -finline-limit=XXX into CFLAGS
[IPSEC]: Fix policy updates missed by sockets
[SPARC]: Kill CHILD_MAX.
[VIDEO] sbuslib: Disallow private mmaps.
David Shaohua Li:
[ACPI] correct earlier SMP deep C-states on HT patch
Edson Seabra:
powerpc: CPM2 interrupt handler failure after 100,000 interrupts
Frank Pavlic:
s390: some minor qeth driver fixes
s390: minor qeth network driver fixes
s390: remove redundant and useless code in qeth
Hans Verkuil:
V4L/DVB (3191): Fix CC output
Hiroyuki YAMAMORI:
[IPV6]: Fix Temporary Address Generation
Ian McDonald:
[DCCP]: Comment typo
Ingo Molnar:
fix spinlock-debugging smp_processor_id() usage
James Bottomley:
[SCSI] fix scsi_reap_target() device_del from atomic context
[email protected]:
[SCSI] fix for fc transport recursion problem.
Jason Wessel:
kernel/params.c: fix sysfs access with CONFIG_MODULES=n
Jean Delvare:
V4L/DVB (3188): Fix compilation failure with gcc 2.95.3.
Knut Petersen:
Fix framebuffer console upside-down ywrap scrolling
Kristian Slavov:
[RTNETLINK]: Fix RTNLGRP definitions in rtnetlink.h
[IPV6]: Fix address deletion
Kurt Huwig:
n_r3964: fixed usage of HZ; removed bad include
Len Brown:
[ACPI] fix build warning from owner_id patch
Linus Torvalds:
Initialize drivers/media/video/saa7134 late
Fix silly typo ("smb" vs "smp")
Linux v2.6.15-rc7
Manfred Spraul:
forcedeth: fix random memory scribbling bug
add missing memory barriers to ipc/sem.c
Mauro Carvalho Chehab:
V4L/DVB (3189): Fix a broken logic that didn't cover all standards.
V4L/DVB SCM Maintainers Update
Michael Chan:
[TG3]: Fix peer device handling
[TG3]: Some low power fixes
[TG3]: Add tw32_wait_f() for some sensitive registers
[TG3]: Fix ethtool memory test
Mika Kukkonen:
[NETROM]: Fix three if-statements in nr_state1_machine()
[VLAN]: Add two missing checks to vlan_ioctl_handler()
Neil Brown:
md: Change case of raid level reported in sys/mdX/md/level
Neil Horman:
[SCTP]: Fix sctp to not return erroneous POLLOUT events.
Nicolas Pitre:
[ARM] 3210/1: add missing memory barrier helper for NPTL support
fix race with preempt_enable()
Olaf Hering:
missing license for libphy.ko
Oliver Endriss:
V4L/DVB (3181): Enable SPDIF output for DVB-S rev 2.3
Patrick McHardy:
[NETFILTER]: Fix NAT init order
[NETFILTER]: Fix incorrect dependency for IP6_NF_TARGET_NFQUEUE
[XFRM]: Handle DCCP in xfrm{4,6}_decode_session
Paul Mackerras:
powerpc: correct register usage in 64-bit syscall exit path
powerpc: update defconfigs
powerpc: Fix i8259 cascade on pSeries with XICS interrupt controller
Paul Walmsley:
USB Storage: Force starget->scsi_level in usb-storage scsiglue.c
Pavel Roskin:
orinoco_nortel: Fix incorrect PCI resource use
orinoco_nortel: Add Symbol LA-4123 ID
Ravikiran G Thirumalai:
x86_64/ia64 : Fix compilation error for node_to_first_cpu
Ricardo Cerqueira:
V4L/DVB (3180): Fix tuner 100 definition for hauppauge eeprom
V4L/DVB (3200): Fix saa7134 ALSA/OSS collisions
Russell King:
[ARM] Fix sys_sendto and sys_recvfrom 6-arg syscalls
Thomas Renninger:
[ACPI] fix passive cooling regression
Tom Zanussi:
relayfs: remove warning printk() in relay_switch_subbuf()
Tony Battersby:
fix libata inquiry VPD for ATAPI devices
Trond Myklebust:
RPC: Do not block on skb allocation
NFS: Fix another O_DIRECT race
SUNRPC: Fix "EPIPE" error on mount of rpcsec_gss-protected partitions
NLM: Fix Oops in nlmclnt_mark_reclaim()
YOSHIFUJI Hideaki:
[IPV6]: Fix route lifetime.
[IPV6]: Flag RTF_ANYCAST for anycast routes.
[IPV6]: Try not to send icmp to anycast address.
[IPV6]: Defer IPv6 device initialization until the link becomes ready.
[IPV6]: Run DAD when the link becomes ready.
[IPV6]: Don't select a tentative address as a source address.
[IPV6]: Fix dead lock.
On Sat, 24 Dec 2005 19:39:23 -0800 (PST),
Linus Torvalds <[email protected]> wrote:
>
>Now, most of you are probably going to be totally bored out of your minds
>on Christmas day, and here's the perfect distraction. Test 2.6.15-rc7.
The Linux Kernel Debugger (KDB) has been upgraded to 2.6.15-rc7. Fetch
it from
ftp://oss.sgi.com/projects/kdb/download/v4.4/
ftp://ftp.ocs.com.au/pub/mirrors/oss.sgi.com/projects/kdb/download/v4.4/
Bah, Hum(de)bug!
On Sat, 24 Dec 2005 19:39:23 -0800 (PST), Linus Torvalds <[email protected]> wrote:
>
>Please do give it a try, and if you have any issues/regressions, send out
>a note (even if you sent one earlier) so that we don't forget about it.
For first time I tried running firewall box on 2.6 series with 15-rc7,
worked first time: http://bugsplatter.mine.nu/test/boxen/deltree/, an
old pentium/mmx with f00f bug.
Only copied /etc/modules.conf to /etc/modprobe.conf, iptables and
all else (NFS, ADSL, Samba) working without change to .conf files.
Thanks,
Grant.
Grant Coady wrote:
> On Sat, 24 Dec 2005 19:39:23 -0800 (PST), Linus Torvalds <[email protected]> wrote:
>
>
>>Please do give it a try, and if you have any issues/regressions, send out
>>a note (even if you sent one earlier) so that we don't forget about it.
>
>
> For first time I tried running firewall box on 2.6 series with 15-rc7,
> worked first time: http://bugsplatter.mine.nu/test/boxen/deltree/, an
> old pentium/mmx with f00f bug.
Hey that is a good ASCII site! Very useful for debugging one's issues.
http://bugsplatter.mine.nu/test/linux-2.6/
/me will bocome a copycat if only /me had a bit more time.
Good idea, thank you. I love the simplicity of it.
> Only copied /etc/modules.conf to /etc/modprobe.conf, iptables and
> all else (NFS, ADSL, Samba) working without change to .conf files.
Kalin.
--
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
On 12/24/05, Linus Torvalds <[email protected]> wrote:
>
> Please do give it a try, and if you have any issues/regressions, send out
> a note (even if you sent one earlier) so that we don't forget about it.
>
> Thanks,
>
> Linus
Hi Linus,
I've visiting at my parents house and gave 2.6.15-rc7 a try on my
dad's machine. This machine is his normal desktop box which I
administer remotely, as well as a MythTV server. The new kernel built
and booted fine. I then built the NVidia stuff. However when I tried
to build the ivtv driver from portage it failed:
* Determining the location of the kernel source code
* Found kernel source directory:
* /usr/src/linux
* Found sources for kernel version:
* 2.6.15-rc7
* Checking for suitable kernel configuration options:
>>> Unpacking source...
>>> Unpacking ivtv-0.4.0.tar.gz to /var/tmp/portage/ivtv-0.4.0-r2/work
>>> Unpacking pvr_2.0.24.23035.zip to /var/tmp/portage/ivtv-0.4.0-r2/work
>>> Source unpacked.
* Preparing ivtv module
created ivtv-svnversion.h
make CONFIG_VIDEO_IVTV=m -C /usr/src/linux
M=/var/tmp/portage/ivtv-0.4.0-r2/work /ivtv-0.4.0/driver modules
make[1]: Entering directory `/usr/src/linux-2.6.15-rc7'
CC [M] /var/tmp/portage/ivtv-0.4.0-r2/work/ivtv-0.4.0/driver/msp3400.o
In file included from
/var/tmp/portage/ivtv-0.4.0-r2/work/ivtv-0.4.0/driver/comp at.h:77,
from
/var/tmp/portage/ivtv-0.4.0-r2/work/ivtv-0.4.0/driver/msp3 400.c:52:
include/linux/videodev.h: In function `video_device_create_file':
include/linux/videodev.h:21: error: dereferencing pointer to incomplete type
include/linux/videodev.h: In function `video_device_remove_file':
include/linux/videodev.h:27: error: dereferencing pointer to incomplete type
In file included from
/var/tmp/portage/ivtv-0.4.0-r2/work/ivtv-0.4.0/driver/comp at.h:77,
from
/var/tmp/portage/ivtv-0.4.0-r2/work/ivtv-0.4.0/driver/msp3 400.c:52:
include/linux/videodev.h:30:5: warning: "OBSOLETE_OWNER" is not defined
include/linux/videodev.h: At top level:
include/linux/videodev.h:204: error: `VIDEO_MAX_FRAME' undeclared here
(not in a function)
make[2]: *** [/var/tmp/portage/ivtv-0.4.0-r2/work/ivtv-0.4.0/driver/msp3400.o]
E rror 1
make[1]: *** [_module_/var/tmp/portage/ivtv-0.4.0-r2/work/ivtv-0.4.0/driver]
Err or 2
make[1]: Leaving directory `/usr/src/linux-2.6.15-rc7'
make: *** [all] Error 2
!!! ERROR: media-tv/ivtv-0.4.0-r2 failed.
!!! Function linux-mod_src_compile, Line 505, Exitcode 2
!!! Unable to make KDIR=/usr/src/linux all.
!!! If you need support, post the topmost build error, NOT this status message.
gandalf src #
Most probably this is stuff the Gentoo devs will clean up when the
real kernel comes out but I *think* you were asking for this sort of
info so I'm posting it back.
Cheers to all,
Mark
On Mon, 2005-12-26 at 10:02 -0800, Mark Knecht wrote:
> Hi Linus,
> I've visiting at my parents house and gave 2.6.15-rc7 a try on my
> dad's machine. This machine is his normal desktop box which I
> administer remotely, as well as a MythTV server. The new kernel built
> and booted fine. I then built the NVidia stuff. However when I tried
> to build the ivtv driver from portage it failed:
There's nothing the kernel developers can do about regressions in out of
tree modules - there is no stable kernel module API so the authors of
that module will have to fix it.
Any idea why the IVTV module has not been submitted for mainline?
Lee
Am Montag, 26. Dezember 2005 19:02 schrieb Mark Knecht:
[ivtv-0.4.0 not compiling on 2.6.15rc]
>
> Most probably this is stuff the Gentoo devs will clean up when the
> real kernel comes out but I *think* you were asking for this sort of
> info so I'm posting it back.
Hi Mark,
the ChangeLog of ivtv-0.4.1 says:
[...]
- support 2.6.15 kernel changes.
[...]
Em Seg, 2005-12-26 ?s 10:02 -0800, Mark Knecht escreveu:
> On 12/24/05, Linus Torvalds <[email protected]> wrote:
> >>> Unpacking ivtv-0.4.0.tar.gz to /var/tmp/portage/ivtv-0.4.0-r2/work
IVTV is not part of kernel. You should try instead ivtv-0.5 stuff
(there are several duplicated modules between kernel and ivtv-0.4 that
were removed on 0.5 as part of a strategy of having it included on some
newer kernel version - maybe 2.6.17 or 2.6.18).
Cheers,
Mauro
On 12/26/05, Lee Revell <[email protected]> wrote:
> On Mon, 2005-12-26 at 10:02 -0800, Mark Knecht wrote:
> > Hi Linus,
> > I've visiting at my parents house and gave 2.6.15-rc7 a try on my
> > dad's machine. This machine is his normal desktop box which I
> > administer remotely, as well as a MythTV server. The new kernel built
> > and booted fine. I then built the NVidia stuff. However when I tried
> > to build the ivtv driver from portage it failed:
>
> There's nothing the kernel developers can do about regressions in out of
> tree modules - there is no stable kernel module API so the authors of
> that module will have to fix it.
>
> Any idea why the IVTV module has not been submitted for mainline?
>
> Lee
Lee, et all,
Yes, I understood ivtv wasn't part of the kernel, and I did
consider trying something newer, but that meant testing that this new
ivtv didn't cause other problems which I didn't have time for as I'm
leaving tomorrow morning for home. Testing ivtv within MythTV is a
long involved process (literally hours and hours really) and I didn't
want to leave my folks without their beloved TV recording system if
something went wrong. I'll test the new kernel on my machines at home,
including with ivtv, and then I'll update them when I know it works
for me.
None the less, and maybe as a non-developer I'm seeing this wrong,
but when a new kernel causes some drive to say a symbol isn't
available, as a user type I have no way of knowing if the symbol was
dropped on purpose or something got left out.
I'm glad it's considered a non-issue.
Best regards and Happy upcoming New Years,
Mark
Lee Revell wrote:
>On Mon, 2005-12-26 at 10:02 -0800, Mark Knecht wrote:
>
>
>>Hi Linus,
>> I've visiting at my parents house and gave 2.6.15-rc7 a try on my
>>dad's machine. This machine is his normal desktop box which I
>>administer remotely, as well as a MythTV server. The new kernel built
>>and booted fine. I then built the NVidia stuff. However when I tried
>>to build the ivtv driver from portage it failed:
>>
>>
>There's nothing the kernel developers can do about regressions in out of
>tree modules - there is no stable kernel module API so the authors of
>that module will have to fix it.
>
>Any idea why the IVTV module has not been submitted for mainline?
>
Little by little, ivtv is being merged into V4L. There is a lot of
reorganization that is taking place, and it is not a very fast process.
As of 2.6.15-rc1, many of the modules from ivtv were merged into the
kernel through V4L. Recently, there was another ivtv fork discovered,
called paken. (for better details, see ivtv mailing list archives) The
ivtv guys are currently working on cleaning up the main ivtv module, and
merging in the code from the paken repo. When all is ready, it will all
be merged into v4l, and eventually the kernel.
Cheers,
Michael Krufky
Mark Knecht wrote:
>On 12/24/05, Linus Torvalds <[email protected]> wrote:
>
>
>>Please do give it a try, and if you have any issues/regressions, send out
>>a note (even if you sent one earlier) so that we don't forget about it.
>>
>>
>I've visiting at my parents house and gave 2.6.15-rc7 a try on my
>dad's machine. This machine is his normal desktop box which I
>administer remotely, as well as a MythTV server. The new kernel built
>and booted fine. I then built the NVidia stuff. However when I tried
>to build the ivtv driver from portage it failed:
>
>
>>>>Unpacking ivtv-0.4.0.tar.gz to /var/tmp/portage/ivtv-0.4.0-r2/work
>>>>Unpacking pvr_2.0.24.23035.zip to /var/tmp/portage/ivtv-0.4.0-r2/work
>>>>Source unpacked.
>>>>
>>>>
> * Preparing ivtv module
>created ivtv-svnversion.h
>make CONFIG_VIDEO_IVTV=m -C /usr/src/linux
>M=/var/tmp/portage/ivtv-0.4.0-r2/work /ivtv-0.4.0/driver modules
>make[1]: Entering directory `/usr/src/linux-2.6.15-rc7'
> CC [M] /var/tmp/portage/ivtv-0.4.0-r2/work/ivtv-0.4.0/driver/msp3400.o
>In file included from
>/var/tmp/portage/ivtv-0.4.0-r2/work/ivtv-0.4.0/driver/comp at.h:77,
> from
>/var/tmp/portage/ivtv-0.4.0-r2/work/ivtv-0.4.0/driver/msp3 400.c:52:
>include/linux/videodev.h: In function `video_device_create_file':
>include/linux/videodev.h:21: error: dereferencing pointer to incomplete type
>include/linux/videodev.h: In function `video_device_remove_file':
>include/linux/videodev.h:27: error: dereferencing pointer to incomplete type
>In file included from
>/var/tmp/portage/ivtv-0.4.0-r2/work/ivtv-0.4.0/driver/comp at.h:77,
> from
>/var/tmp/portage/ivtv-0.4.0-r2/work/ivtv-0.4.0/driver/msp3 400.c:52:
>include/linux/videodev.h:30:5: warning: "OBSOLETE_OWNER" is not defined
>include/linux/videodev.h: At top level:
>include/linux/videodev.h:204: error: `VIDEO_MAX_FRAME' undeclared here
>(not in a function)
>make[2]: *** [/var/tmp/portage/ivtv-0.4.0-r2/work/ivtv-0.4.0/driver/msp3400.o]
>E rror 1
>make[1]: *** [_module_/var/tmp/portage/ivtv-0.4.0-r2/work/ivtv-0.4.0/driver]
>Err or 2
>make[1]: Leaving directory `/usr/src/linux-2.6.15-rc7'
>make: *** [all] Error 2
>
>!!! ERROR: media-tv/ivtv-0.4.0-r2 failed.
>!!! Function linux-mod_src_compile, Line 505, Exitcode 2
>!!! Unable to make KDIR=/usr/src/linux all.
>!!! If you need support, post the topmost build error, NOT this status message.
>
>gandalf src #
>
> Most probably this is stuff the Gentoo devs will clean up when the
>real kernel comes out but I *think* you were asking for this sort of
>info so I'm posting it back.
>
>
Mark-
You don't have to worry about this... Since ivtv is an out-of-tree
kernel module, and 2.6.15 is not released to mainline yet, so you cant
expect the distros to make their external driver packages compatable.
Anyhow, I believe that ivtv 0.5.x is meant to be built against 2.6.15
... We have been merging some of the modules from ivtv into v4l, and
some of those modules have already made it into 2.6.15. I think you
will run into module collisions using ivtv 0.4.x with kernel 2.6.15, but
i'm not sure about that. Please see the ivtv mailing list / web site
for more information about this, and how to get it to work with your kernel.
Eventually, the ivtv driver will entirely be merged into v4l (and the
kernel), and things will be much easier. Until then, you should try the
new 0.5.x version of ivtv with Kernel 2.6.15
Cheers,
-Michael
I too have been bored during Christmas and ran 2.6.15-rc7 as Linus asked.
Furthermore I patched it with 'adaptive read-ahead', Ingo's mutex,
Balbirs/Stevens 'slab-cache estimate optimization' and Cons 'swap
prefetch'.
I've enable 4k stacks and kernel preemption and up till now I've yet
to see one glitch.
Usage: Watching movies, using git, compiling kernel, ftp, bittorrent..
Nothing special...
Machine is a Athlon 1.3 GHz, 512 MB Ram, 46xx sound ALSA ..
Luuk van der Duim
On 12/25/05, Linus Torvalds <[email protected]> wrote:
> Please do give it a try, and if you have any issues/regressions, send out
> a note (even if you sent one earlier) so that we don't forget about it.
Hmm. Somebody broke UML compile for my config again...
CC arch/um/sys-i386/stub_segv.o
In file included from arch/um/sys-i386/stub_segv.c:10:
arch/um/include/sysdep/stub.h:12:23: stub-data.h: No such file or directory
In file included from arch/um/sys-i386/stub_segv.c:10:
arch/um/include/sysdep/stub.h: In function `remap_stack':
arch/um/include/sysdep/stub.h:97: error: dereferencing pointer to
incomplete type
make[1]: *** [arch/um/sys-i386/stub_segv.o] Error 1
make: *** [arch/um/sys-i386] Error 2
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.15-rc7
# Tue Dec 27 14:28:35 2005
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_UML=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_IRQ_RELEASE_METHOD=y
#
# UML-specific options
#
CONFIG_MODE_TT=y
# CONFIG_HOST_2G_2G is not set
CONFIG_KERNEL_HALF_GIGS=1
# CONFIG_MODE_SKAS is not set
#
# Host processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_UML_X86=y
# CONFIG_64BIT is not set
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_TOP_ADDR=0xc0000000
# CONFIG_3_LEVEL_PGTABLES is not set
CONFIG_STUB_CODE=0xbfffe000
CONFIG_STUB_DATA=0xbffff000
CONFIG_STUB_START=0xbfffe000
CONFIG_ARCH_HAS_SC_SIGNALS=y
CONFIG_ARCH_REUSE_HOST_VSYSCALL_AREA=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_LD_SCRIPT_STATIC=y
CONFIG_NET=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
# CONFIG_HOSTFS is not set
# CONFIG_HPPFS is not set
CONFIG_MCONSOLE=y
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_SMP is not set
CONFIG_NEST_LEVEL=0
# CONFIG_HIGHMEM is not set
CONFIG_KERNEL_STACK_ORDER=2
CONFIG_UML_REAL_TIME_CLOCK=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
# CONFIG_LBD is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
#
# Networking
#
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
# CONFIG_IPV6 is not set
# CONFIG_NETFILTER is not set
#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set
#
# Character Devices
#
CONFIG_STDERR_CONSOLE=y
CONFIG_STDIO_CONSOLE=y
CONFIG_SSL=y
CONFIG_NULL_CHAN=y
CONFIG_PORT_CHAN=y
CONFIG_PTY_CHAN=y
CONFIG_TTY_CHAN=y
CONFIG_XTERM_CHAN=y
# CONFIG_NOCONFIG_CHAN is not set
CONFIG_CON_ZERO_CHAN="fd:0,fd:1"
CONFIG_CON_CHAN="xterm"
CONFIG_SSL_CHAN="pty"
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_WATCHDOG is not set
CONFIG_UML_SOUND=m
CONFIG_SOUND=m
CONFIG_HOSTAUDIO=m
CONFIG_UML_RANDOM=y
# CONFIG_MMAPPER is not set
#
# Block devices
#
CONFIG_BLK_DEV_UBD=y
CONFIG_BLK_DEV_UBD_SYNC=y
CONFIG_BLK_DEV_COW_COMMON=y
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_RAM is not set
CONFIG_BLK_DEV_RAM_COUNT=16
# CONFIG_ATA_OVER_ETH is not set
CONFIG_NETDEVICES=y
#
# UML Network Devices
#
CONFIG_UML_NET=y
CONFIG_UML_NET_ETHERTAP=y
CONFIG_UML_NET_TUNTAP=y
CONFIG_UML_NET_SLIP=y
CONFIG_UML_NET_DAEMON=y
CONFIG_UML_NET_MCAST=y
# CONFIG_UML_NET_PCAP is not set
CONFIG_UML_NET_SLIRP=y
#
# Network device support
#
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
#
# PHY device support
#
#
# Wan interfaces
#
# CONFIG_WAN is not set
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPP_FILTER is not set
# CONFIG_PPP_ASYNC is not set
# CONFIG_PPP_SYNC_TTY is not set
# CONFIG_PPP_DEFLATE is not set
# CONFIG_PPP_BSDCOMP is not set
# CONFIG_PPP_MPPE is not set
# CONFIG_PPPOE is not set
CONFIG_SLIP=m
# CONFIG_SLIP_COMPRESSED is not set
# CONFIG_SLIP_SMART is not set
# CONFIG_SLIP_MODE_SLIP6 is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
# CONFIG_QFMT_V2 is not set
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_RELAYFS_FS is not set
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
# CONFIG_CRYPTO is not set
#
# Hardware crypto devices
#
#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=m
# CONFIG_LIBCRC32C is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_INPUT is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
CONFIG_DEBUG_SLAB=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
CONFIG_FRAME_POINTER=y
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_CMDLINE_ON_HOST is not set
CONFIG_PT_PROXY=y
# CONFIG_SYSCALL_DEBUG is not set
Lee Revell wrote:
> On Mon, 2005-12-26 at 10:02 -0800, Mark Knecht wrote:
>
>>Hi Linus,
>> I've visiting at my parents house and gave 2.6.15-rc7 a try on my
>>dad's machine. This machine is his normal desktop box which I
>>administer remotely, as well as a MythTV server. The new kernel built
>>and booted fine. I then built the NVidia stuff. However when I tried
>>to build the ivtv driver from portage it failed:
>
>
> There's nothing the kernel developers can do about regressions in out of
> tree modules - there is no stable kernel module API so the authors of
> that module will have to fix it.
>
> Any idea why the IVTV module has not been submitted for mainline?
>
> Lee
>
No idea. I even asked the IVTV developers mailing list some time ago
trying to get them to include it in mainline, but they did not want to
for some odd reason I could not work out.
Maybe someone else can kick them a little harder. :-)
James
On 12/27/05, James Courtier-Dutton <[email protected]> wrote:
> Lee Revell wrote:
> > On Mon, 2005-12-26 at 10:02 -0800, Mark Knecht wrote:
> >
> >>Hi Linus,
> >> I've visiting at my parents house and gave 2.6.15-rc7 a try on my
> >>dad's machine. This machine is his normal desktop box which I
> >>administer remotely, as well as a MythTV server. The new kernel built
> >>and booted fine. I then built the NVidia stuff. However when I tried
> >>to build the ivtv driver from portage it failed:
> >
> >
> > There's nothing the kernel developers can do about regressions in out of
> > tree modules - there is no stable kernel module API so the authors of
> > that module will have to fix it.
> >
> > Any idea why the IVTV module has not been submitted for mainline?
> >
> > Lee
> >
>
> No idea. I even asked the IVTV developers mailing list some time ago
> trying to get them to include it in mainline, but they did not want to
> for some odd reason I could not work out.
>
> Maybe someone else can kick them a little harder. :-)
Hehe... Please see the earlier messages in this thread... It is a
plan-in-motion. Maybe for 2.6.17 or 2.6.18. ...depending on some
other factors...
-Mike
Hello,
On Sat, 24 Dec 2005 19:39:23 -0800 (PST), Linus Torvalds
<[email protected]> wrote:
>
>
> Please do give it a try, and if you have any issues/regressions, send
> out a note (even if you sent one earlier) so that we don't
> forget about it.
Just booted my own 2.6.15-rc7 on a machine based on ASUS A8V-Deluxe
with AMD Athlon 3800+, and it is really working fine ! I also now have
smartd working using -d ata for the SATA disk...
Still have to check ATI proprietary driver for X.org, but vanilla is great !
Thx,
Paul
Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator
--
Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur
"Some people dream of success... while others wake up and work hard at it"
"I worry about my child and the Internet all the time, even though she's
too young to have logged on yet. Here's what I worry about. I worry that
10 or 15 years from now, she will come to me and say 'Daddy, where were
you when they took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation
1. the latest and greatest ivtv is 0.5.x svn trunk
2. a week ago it still depended on some v4l cvs changes not merged
upstream (ie could not build without a private v4l tree dump)
3. and it had firmware loading problems with the latest 2.6.15-rc git
dumps
4. the merging process stalled considerably when the paken fork was
discovered
The root of the problem of course is ivtv developpers still haven't
understood the "release early, release often" part and are aiming for
a perfect (cleaned-up and feature-complete) driver before submitting
it. Instead of merging everything now (experimental) and finishing the
paken merge cleanup / inside the kernel.
ivtv 0.5 is not even available as a kernel patchset, so you get the
idea. ivtv writers would get a boatload of feedback if it behaved like
any other kernel patchset.
Now don't get me wrong, the ivtv people did and are doing a wonderful
job driver-side, but they seriously need to learn to integrate in the
kernel ecosystem. Someone wrote in the thread about the need to "kick"
them a bit to make them understand this. I'm afraid this feeling is
shared by a lot of other people. The low priority given to merging is
real frustrating.
Regards,
--
Nicolas Mailhot
Nicolas Mailhot wrote:
>1. the latest and greatest ivtv is 0.5.x svn trunk
>2. a week ago it still depended on some v4l cvs changes not merged
>upstream (ie could not build without a private v4l tree dump)
>3. and it had firmware loading problems with the latest 2.6.15-rc git
>dumps
>4. the merging process stalled considerably when the paken fork was
>discovered
>
>The root of the problem of course is ivtv developpers still haven't
>understood the "release early, release often" part and are aiming for
>a perfect (cleaned-up and feature-complete) driver before submitting
>it. Instead of merging everything now (experimental) and finishing the
>paken merge cleanup / inside the kernel.
>
>ivtv 0.5 is not even available as a kernel patchset, so you get the
>idea. ivtv writers would get a boatload of feedback if it behaved like
>any other kernel patchset.
>
>Now don't get me wrong, the ivtv people did and are doing a wonderful
>job driver-side, but they seriously need to learn to integrate in the
>kernel ecosystem. Someone wrote in the thread about the need to "kick"
>them a bit to make them understand this. I'm afraid this feeling is
>shared by a lot of other people. The low priority given to merging is
>real frustrating.
>
>
Please, give them a break, and let's end this conversation right now.
IVTV has come a long way in a path of merging into V4L, especially
during 2.6.15 development. This is not simply a matter of getting the
ivtv code into the kernel to let it compile correctly.... This is also
an issue of changing the ivtv modules to conform with the V4L2 API, and
to make all of these modules behave in the same style as the other v4l
kernel modules, so that other devices can use the ivtv modules, etc.
We are trying to encourage proper codingstyle, so that things are
correct from the start... This is not simply a matter of merging in a
new module -- When ready, the ivtv modules will become part of the v4l
subsystem, and card drivers will make use of them. These modules must
conform to a standard API as the rest of V4L does... Otherwise, we would
be creating more work for ourselves later on.
I can go on and on explaining why there needs to be work done before
this is all merged in... but simply enough, it isn't ready. (although
it seems to be getting there soon) There are people working on it, and
significant headway has been made in the past few months. We want this
to be done correctly -- not quickly for a deadline. Remember, the
people working on this code are doing it because they want it to work --
NOT because they have a deadline in order to receive a paycheck. Please
have some patience, and things will be better in the longrun.
About the dependency on the v4l cvs tree, this is part of the transition
-- When the ivtv guys are finished with a module, it goes to the v4l-dvb
cvs, where we will make additional cleanups, and set up Kconfig, etc...
Now that there is this "upstream merge window" policy, that explains why
there are some ivtv dependencies in v4l-dvb cvs, that are not yet in the
kernel. If you read the ivtv mailing list, or the web site
instructions, you will understand that there is a 0.4.x series, for use
as standalone, and a 0.5.x series, which depends ont the v4l-dvb tree.
I'm done rambling.... Just have patience.... Merges will happen soon
enough. Please dont try to rush things.
Cheers,
Michael Krufky
P.S.: Hans, Taylor, and all the other ivtv developers - You're doing a
great job, and keep up the good work. This just goes to show how much
the community appreciates the work of the ivtv project. :-D
Below is a patch by Andi Kleen from kernel Bugzilla #5758 fixing a
post-2.6.14 regression.
cu
Adrian
<-- snip -->
Reject SRAT tables that don't cover all memory
Broken BIOS on Iwill reports these and it causes the bootmem
allocator to crash. Add a sanity check if all the PXMs in the
SRAT table cover all memory as reported by e820.
This patch fixes kernel Bugzilla #5758.
From: Andi Kleen <[email protected]>
Signed-off-by: Adrian Bunk <[email protected]>
--- linux.orig/arch/x86_64/mm/srat.c
+++ linux/arch/x86_64/mm/srat.c
@@ -17,6 +17,7 @@
#include <linux/topology.h>
#include <asm/proto.h>
#include <asm/numa.h>
+#include <asm/e820.h>
static struct acpi_table_slit *acpi_slit;
@@ -196,12 +197,39 @@ acpi_numa_memory_affinity_init(struct ac
nd->start, nd->end);
}
+/* Sanity check to catch more bad SRATs (they are amazingly common).
+ Make sure the PXMs cover all memory. */
+static int nodes_cover_memory(void)
+{
+ int i;
+ unsigned long pxmram, e820ram;
+
+ pxmram = 0;
+ for_each_node_mask(i, nodes_parsed) {
+ unsigned long s = nodes[i].start >> PAGE_SHIFT;
+ unsigned long e = nodes[i].end >> PAGE_SHIFT;
+ pxmram += e - s;
+ pxmram -= e820_hole_size(s, e);
+ }
+
+ e820ram = end_pfn - e820_hole_size(0, end_pfn);
+ if (pxmram < e820ram) {
+ printk(KERN_ERR
+ "SRAT: PXMs only cover %luMB of your %luMB e820 RAM. Not used.\n",
+ (pxmram << PAGE_SHIFT) >> 20,
+ (e820ram << PAGE_SHIFT) >> 20);
+ return 0;
+ }
+ return 1;
+}
+
void __init acpi_numa_arch_fixup(void) {}
/* Use the information discovered above to actually set up the nodes. */
int __init acpi_scan_nodes(unsigned long start, unsigned long end)
{
int i;
+
if (acpi_numa <= 0)
return -1;
@@ -212,6 +240,11 @@ int __init acpi_scan_nodes(unsigned long
node_clear(i, nodes_parsed);
}
+ if (!nodes_cover_memory()) {
+ bad_srat();
+ return -1;
+ }
+
memnode_shift = compute_hash_shift(nodes, nodes_weight(nodes_parsed));
if (memnode_shift < 0) {
printk(KERN_ERR
On Thu, Dec 29, 2005 at 02:39:02PM +0100, Adrian Bunk wrote:
> Below is a patch by Andi Kleen from kernel Bugzilla #5758 fixing a
> post-2.6.14 regression.
WTF are you submitting my patches? Please don't do this - I am perfectly
capable to do this on my own when the time is ripe for them. For this
patch that's post 2.6.15 and after more testing.
-Andi
On Thu, Dec 29, 2005 at 05:07:41PM +0100, Andi Kleen wrote:
> On Thu, Dec 29, 2005 at 02:39:02PM +0100, Adrian Bunk wrote:
> > Below is a patch by Andi Kleen from kernel Bugzilla #5758 fixing a
> > post-2.6.14 regression.
>
> WTF are you submitting my patches? Please don't do this - I am perfectly
> capable to do this on my own when the time is ripe for them. For this
> patch that's post 2.6.15 and after more testing.
According to the bug logs this is a regression in 2.6.15-rc, and it's
not good if 2.6.15 will not boot on some machines where 2.6.14 did.
> -Andi
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 Thu, Dec 29, 2005 at 05:20:20PM +0100, Adrian Bunk wrote:
> On Thu, Dec 29, 2005 at 05:07:41PM +0100, Andi Kleen wrote:
> > On Thu, Dec 29, 2005 at 02:39:02PM +0100, Adrian Bunk wrote:
> > > Below is a patch by Andi Kleen from kernel Bugzilla #5758 fixing a
> > > post-2.6.14 regression.
> >
> > WTF are you submitting my patches? Please don't do this - I am perfectly
> > capable to do this on my own when the time is ripe for them. For this
> > patch that's post 2.6.15 and after more testing.
>
> According to the bug logs this is a regression in 2.6.15-rc, and it's
> not good if 2.6.15 will not boot on some machines where 2.6.14 did.
The risk at this stage of breaking more than fixing is too high.
Especially since it's only one relatively obscure machine with totally
broken BIOS. And a workaround exists.
Please leave the decision of what patches are release critical and what
not for x86-64 to me. Thanks.
-Andi
This email lists some known regressions in 2.6.15-rc7 compared to 2.6.14.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you was declared guilty for a breakage or in any other way involved
with one or more of these issues.
Subject : cpuset_excl_nodes_overlap() may sleep under tasklist_lock
References : http://lkml.org/lkml/2005/12/28/63
Submitter : Kirill Korotaev <[email protected]>
Status : unknown
Subject : /sys/class/net/<device name>/wireless directory is gone
References : http://bugzilla.kernel.org/show_bug.cgi?id=5800
http://marc.theaimsgroup.com/?l=linux-netdev&m=113619905529636&w=2
Submitter : Ismail Donmez <[email protected]>
Handled-By : Andrey Borzenkov <[email protected]>
Status : patch available
Subject : USB handoff, irq 193: nobody cared!
References : http://lkml.org/lkml/2005/11/14/274
Submitter : Michael Madore <[email protected]>
Status : unknown, caused by a patch by David Brownell
Subject : BUG: spinlock recursion on 2.6.14-mm2 when oprofiling
References : http://lkml.org/lkml/2005/11/18/95
Submitter : Wu Fengguang <[email protected]>
Handled-By : "Paul E. McKenney" <[email protected]>
Status : unknown, reported against -mm, already fixed in -mm
(make-rcu-task_struct-safe-for-oprofile.patch)
Is this bug present in Linus' tree?
Subject : oops in kernel 2.6.15-rc{6,7}
References : http://lkml.org/lkml/2005/12/28/75
http://lkml.org/lkml/2005/12/30/119
Submitter : Mathias Klein <[email protected]>
Status : unknown
Subject : No sound with snd_intel8x0 & ALi M5455 chipset
(kobject_register failed)
References : http://bugzilla.kernel.org/show_bug.cgi?id=5760
Submitter : Christian Casteyde <[email protected]>
Status : submitter was asked to do a binary search for
the guilty patch
Subject : No sound from CX23880 tuner w. 2.6.15-rc5
References : http://lkml.org/lkml/2005/12/12/190
http://www.spinics.net/lists/vfl/msg22791.html
Submitter : "P. Christeas" <[email protected]>
Handled-By : Mauro Carvalho Chehab <[email protected]>
Torsten Seeboth <[email protected]>
Status : regression in cx88-tvaudio.c, no patch known
Subject : x86_64: PANIC: early exception
References : http://bugzilla.kernel.org/show_bug.cgi?id=5758
Status : Andi considers his patch too risky for 2.6.15,
workaround available, should be noted in the
final 2.6.15 announcement
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 Monday 02 January 2006 17:46, Adrian Bunk wrote:
> Subject : x86_64: PANIC: early exception
> References : http://bugzilla.kernel.org/show_bug.cgi?id=5758
> Status : Andi considers his patch too risky for 2.6.15,
> workaround available, should be noted in the
> final 2.6.15 announcement
If it worked in 2.6.14 then only by extreme luck and probably
also ran into problems later. The BIOS in this case is terminally broken.
So I wouldn't consider this a real regression.
-Andi
On Mon, Jan 02, 2006 at 06:07:52PM +0100, Andi Kleen wrote:
> On Monday 02 January 2006 17:46, Adrian Bunk wrote:
>
> > Subject : x86_64: PANIC: early exception
> > References : http://bugzilla.kernel.org/show_bug.cgi?id=5758
> > Status : Andi considers his patch too risky for 2.6.15,
> > workaround available, should be noted in the
> > final 2.6.15 announcement
>
> If it worked in 2.6.14 then only by extreme luck and probably
> also ran into problems later. The BIOS in this case is terminally broken.
>
> So I wouldn't consider this a real regression.
Unless I misread the Bugzilla bug, the submitter was extremely lucky
in 2.6.14 making it a regression for him.
But discussing this point won't buy us much.
Would you veto against a section "known regressions" in the final 2.6.15
announcement listing this issue with a link to the Bugzilla bug?
> -Andi
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 Monday 02 January 2006 18:23, Adrian Bunk wrote:
> Would you veto against a section "known regressions" in the final 2.6.15
> announcement listing this issue with a link to the Bugzilla bug?
Yes for this case. The original was likely so fragile that it might
break only with minor changes in the hardware configuration.
In general listing known regressions is a good idea though.
It might be a good idea to give them different priorities though - e.g.
a broken BIOS with a missing workaround is less priority than
a pure Linux bug.
-Andi
On Mon, 2006-01-02 at 18:38 +0100, Andi Kleen wrote:
> On Monday 02 January 2006 18:23, Adrian Bunk wrote:
>
> > Would you veto against a section "known regressions" in the final 2.6.15
> > announcement listing this issue with a link to the Bugzilla bug?
>
> Yes for this case. The original was likely so fragile that it might
> break only with minor changes in the hardware configuration.
>
> In general listing known regressions is a good idea though.
>
> It might be a good idea to give them different priorities though - e.g.
> a broken BIOS with a missing workaround is less priority than
> a pure Linux bug.
I'm currently struggling with a probable case of broken BIOS without
workaround, is there a central repository of known simular problems? Is
there a way to pinpoint such problems to prevent people from tossing
these into bugzilla?
On Mon, Jan 02, 2006 at 05:46:36PM +0100, Adrian Bunk wrote:
> This email lists some known regressions in 2.6.15-rc7 compared to 2.6.14.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you was declared guilty for a breakage or in any other way involved
> with one or more of these issues.
[ . . . ]
> Subject : BUG: spinlock recursion on 2.6.14-mm2 when oprofiling
> References : http://lkml.org/lkml/2005/11/18/95
> Submitter : Wu Fengguang <[email protected]>
> Handled-By : "Paul E. McKenney" <[email protected]>
> Status : unknown, reported against -mm, already fixed in -mm
> (make-rcu-task_struct-safe-for-oprofile.patch)
> Is this bug present in Linus' tree?
No, this bug is not present in Linus's tree.
Thanx, Paul