login
Search
Linux creator Linus Torvalds released the official 2.6.9 kernel today, following what he referred to as "naming confusion" in which a test release named "-final" was first uploaded to kernel.org. Linus went on to add, "excuses aside, not a lot of changes since -rc4 [story] (which was the last announced test-kernel), mainly some UML updates that don't affect anybody else. And a number of one-liners or compiler fixes. Full list appended." Official releases and test kernels can be found at a kernel.org mirror.
Regarding the compiler fixes, a handful of problems were reported on the lkml with some versions of GCC [forum]. Linus replied, "Heh. Clearly there's a gcc bug.. What compiler version? I've got gcc-3.2 and gcc-3.3, and neither seems to have any trouble, but hey, I'm cursed by having fairly up-to-date systems. That said, I know what's up, but it would be good to know what compilers have this problem." Linus provided a fix for older versions of gcc which can be found within.
From: Linus Torvalds [email blocked]
To: Kernel Mailing List [email blocked]
Subject: Linux v2.6.9...
Date: Mon, 18 Oct 2004 15:45:21 -0700 (PDT)
Ok,
despite some naming confusion (expanation: I'm a retard), I did end up
doing the 2.6.9 release today. And it wasn't the same as the "-final" test
release (see explanation above).
Excuses aside, not a lot of changes since -rc4 (which was the last
announced test-kernel), mainly some UML updates that don't affect anybody
else. And a number of one-liners or compiler fixes. Full list appended.
Linus
----
Summary of changes from v2.6.9-rc4 to v2.6.9
============================================
<mgoodman:csua.berkeley.edu>:
o Fix NFS3 krb5 clients on x86-64
Al Borchers:
o USB: corrected digi_acceleport 2.6.9-rc1 fix for hang on disconnect
Andrea Arcangeli:
o ptep_establish smp race x86 PAE >4G
Andrew Morton:
o revert writeback threshold changes
o ext3 direct io assert fix
Anton Blanchard:
o ppc64: fix some issues with mem_reserve
Benjamin Herrenschmidt:
o ppc64: Split iomap implementation & eeh !
o ppc32: Add "native" iomap interfaces
o ppc64: more issues with mem_reserve
Chris Wright:
o uml: fix ubd deadlock on SMP
Christoph Hellwig:
o [XFS] fix a freeze/thaw deadlock
Christoph Lameter:
o time interpolator fixes
David Brownell:
o USB: EHCI SMP fix
o USB: net2280 updates
David Woodhouse:
o ppc64: one more explicit cmp instruction sizing
Dmitry Torokhov:
o Fix oops in parkbd
Greg Kroah-Hartman:
o USB: handle NAK packets in input devices
Herbert Xu:
o USB: Fix hiddev devfs oops
Hirokazu Takata:
o m32r: fix syscall table
o m32r: remove obsolete system calls
Ingo Molnar:
o tailcall prevention in sys_wait4() and sys_waitid()
James Morris:
o SELinux: fix bugs in mprotect hook
John L. Byrne:
o fix oops in fork() cleanup path
John Rose:
o PCI Hotplug: rpaphp safe list traversal
Lars Ellenberg:
o uml: fix critical IP checksum corruption
Linus Torvalds:
o Fix threaded user page write memory ordering
o Take the whole PCI bus range into account when scanning PCI bridges
Nathan Lynch:
o ppc64: fix smp_startup_cpu for cpu hotplug
Nathan Scott:
o [XFS] Fix up write_inode return type to use the right signedness
o [XFS] Fix regression when running in laptop mode, causes hangs on
sync
Nick Piggin:
o ACPI: check parameter for NULL
o kswapd lockup fix
Nicolas Pitre:
o Fix MTD build error for Lubbock map driver
o unbalanced locking in MTD Intel chip driver
o Duh. _Really_ unbalanced locking in MTD Intel chip driver
Olaf Hering:
o joydump needs gameport
Olaf Kirch:
o auth_domain_lookup fix
Oliver Neukum:
o security issue in firmware system
Paolo 'Blaisorblade' Giarrusso:
o uml: don't declare cpu_online - fix compilation error
o uml: fix wrong type for rb_entry call
o uml: fix warning for unused var
o uml: finish update for 2.6.8 API changes
o uml: fix an "unused" warnings
o uml: export more Symbols
o uml: Set cflags before including arch Makefile
o uml: force using /bin/bash for building
o uml: no extraversion in arch/um/Makefile for mainline
o uml: Single Linking Step for vmlinux
o uml: make -j fix
o uml: update makefile to new kbuild API names
o uml: kbuild - add even more cleaning
o uml: mark broken configs
o uml: use always a separate io thread for UBD
Pavel Machek:
o swsusp: fix x86-64 - do not use memory in copy loop
Randy Dunlap:
o cyber2000: fix init/exit section confusion
o intel_agp: dangling devexit reference
Sreenivas Bagalkote:
o megaraid 2.20.4: fix a data corruption bug
Stephen D. Smalley:
o SELinux: retain ptracer SID across fork
Tim Schmielau:
o Fix reporting of process start times
Vojtech Pavlik:
o USB: Fix oops in usblp driver
Yoshinori Sato:
o H8/300 some error/warning fix
From: Jeff Garzik [email blocked]
To: Linux Kernel [email blocked]
Subject: Weird... 2.6.9 kills FC2 gcc
Date: Mon, 18 Oct 2004 21:10:19 -0400
The following appears in 2.6.9 release kernel, building with stock FC2
gcc on x86, but does not appear in 2.6.9-final:
> AS arch/i386/kernel/vsyscall.o
> cc1: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
> make[1]: *** [arch/i386/kernel/vsyscall.o] Error 1
> make: *** [arch/i386/kernel] Error 2
This is 100% reproducible, at the same location (vsyscall), which is
strange because vsyscall didn't change AFAICS.
I'll build a gcc 3.4.2 without Fedora Core patches and see if the
behavior persists.
But in the meantime, if anybody else knows what line of code causes this
segfault, please speak up :)
Jeff
From: Jeff Garzik [email blocked]
Subject: Re: [PATCH] Re: Weird... 2.6.9 kills FC2 gcc
Date: Mon, 18 Oct 2004 23:31:41 -0400
More data points:
No problems at all on x86-64.
No ICE on 32-bit x86 gcc 3.4.2, with 2.6.9 release kernel.
So this ICE appears to be a bug specific to 3.3.x or perhaps Fedora.
Jeff
From: Linus Torvalds [email blocked]
Subject: Re: 2.6.9 BK build broken
Date: Mon, 18 Oct 2004 22:14:00 -0700 (PDT)
On Mon, 18 Oct 2004, Jeff Garzik wrote:
> >
> > I get an ICE here in -BK-latest, which the attached patch fixes (backs
> > out Linus's change).
Heh. Clearly there's a gcc bug.. What compiler version?
I've got gcc-3.2 and gcc-3.3, and neither seems to have any trouble, but
hey, I'm cursed by having fairly up-to-date systems.
That said, I know what's up, but it would be good to know what compilers
have this problem..
> Another data point, I have no problems with 2.6-BK-latest on x86-64,
> with gcc 3.3.3 (FC2)...
Too much C syntax, too little CPP braindamage.
I bet the thing is fixed by changing the
#define __builtin_warning(x, ...) (1)
into
#define __builtin_warning(x, y...) (1)
(ie add the name for the varargs macro argument). Never mind that we don't
use it, and newer gcc's are happy - older gcc's clearly aren't ;)
Linus
From: Matthias Andree <matthias.andree@gmx.de>
Subject: SOLVED: 2.6.9 BK build broken
Date: Tue, 19 Oct 2004 11:23:07 +0200
On Mon, 18 Oct 2004, Linus Torvalds wrote:
> I bet the thing is fixed by changing the
>
> #define __builtin_warning(x, ...) (1)
>
> into
>
> #define __builtin_warning(x, y...) (1)
Indeed it is. I just did bk pull and found that
torvalds@ppc970.osdl.org|ChangeSet|20041019071619|06021
compiles fine on gcc-3.3.4, 3.4.2 and SuSE's gcc-3.3.3-41.
Thank you.
--
Matthias Andree
From: John Cherry [email blocked]
To: Linux Kernel Mailing List [email blocked]
Subject: 2.6.9-final (compile stats)
Date: 17 Oct 2004 15:54:49 -0700
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-final 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
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
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
What's with the jump in #warnings?
I'm not complaining (it's not actually affected me) but I'd be interested to know what change(s) in -rc2 resulted in such a huge number of warnings over 2.6.9-rc1? Some widely used #define or something like that?
Cheers,
jc
KernelTrap had an article abo
KernelTrap had an article about this recently:
Linux: 2.6.9-rc2, Stricter Type Checks ( http://kerneltrap.org/node/view/3827 )
2.6.9 freezes my system
Hi,
when I umount my usb burner and I disconnect it from a uhci_hcd port I get a oops and then the machine freezes.
No problem until kernel 2.6.7.
I use fully preemptible kernels.
sr 1:0:0:0: Illegal state transition cancel->offline
Oct 19 16:04:11 chopin kernel: Badness in scsi_device_set_state at drivers/scsi/scsi_lib.c:1688
Oct 19 16:04:11 chopin kernel: [] scsi_device_set_state+0xc9/0x120 [scsi_mod]
Oct 19 16:04:11 chopin kernel: [] scsi_eh_offline_sdevs+0x6e/0x90 [scsi_mod]
Oct 19 16:04:11 chopin kernel: [] scsi_unjam_host+0xc3/0xd0 [scsi_mod]
Oct 19 16:04:11 chopin kernel: [] scsi_error_handler+0xa8/0xd0 [scsi_mod]
Oct 19 16:04:11 chopin kernel: [] scsi_error_handler+0x0/0xd0 [scsi_mod]
Oct 19 16:04:11 chopin kernel: [] kernel_thread_helper+0x5/0x18
Oct 19 16:04:11 chopin kernel: Badness in kref_get at lib/kref.c:32
Oct 19 16:04:11 chopin kernel: [] kref_get+0x47/0x50
Oct 19 16:04:11 chopin kernel: [] kobject_get+0x1a/0x30
Oct 19 16:04:11 chopin kernel: [] get_device+0x18/0x20
Oct 19 16:04:11 chopin kernel: [] scsi_request_fn+0x25/0x3c0 [scsi_mod]
etc...
This is not the place for bug reports
Please submit your report either to your distribution vendor or the Linux kernel mailing list.
bugzilla
You can also try the kernel bugzilla at http://bugzilla.kernel.org/.
Stanford checker
I wonder what happened with the Stanford checker. Maybe those guys can track what gcc features are used in the code and report what gcc versions should cleanly compile the code.
-c
Did that CD burning issue get fixed?
If i recall correctly, 2.6.8 broke cd writing. Did that get fixed?
depends on cdrecord
the problem was that cdrecord depended on a hack (scsi emulation for ide cdwriters). linus wanted to remove this hack for a long time, but the cdrecord's author refused to change his software to support direct ide writing. so linus simply removed the scsi emulation code because he thought it was ugly. (this might not be a perfect representation of what was wrong, but I think its close... google it if you want to know precisely what was going on)
well, wheter cdrecord's author was 'wrong' or linus or both, I dont know, you can form your own opinion if you want by reading the appropriate mailinglists etc (I'm sure here on kerneltrap you'll find some about this in the archive).
I think he's talking about 2.
I think he's talking about 2.6.8.1 = no buring cd's as user (cdrecord)
Not on kernel.org
Where is it? I don't see it one kernel.org as of 2:46 est today..
And I really don't care what the issue was with cdburning, all I want to know is if it is fixed yet or not.
You should care!
Because I think that now cdrecord must have the setuid-bit set to burn, and AFAIK it won't change in the near future: that's not a bug but a feature :)
Yeah, the problem is, AFAIK,
Yeah, the problem is, AFAIK, that cdrecord drops the privileges. I guess that may limited to determined versions of cdrecord; mine [Cdrecord-Clone 2.01a34 (i686-pc-linux-gnu)] from Debian Testing still fails even when with suid:
cdrecord: Cannot allocate memory. Cannot get SCSI I/O buffer.
This problem in particular is
This problem in particular is solved when running cdrecord with strace (as suggested in Re: Cannot burn without strace on 2.6.8-rc3-mm1).
Problem solved by compiling cdrecord without nptl
Thanks for that link!
It gave me the idea to try
USE="-nptl" emerge cdrtoolsin gentoo. This recompiles cdrecord without nptl.
And it worked! cdrecord works again :)
cdrecord drops priviliges
I bet that this failure to get an I/O buffer is related to changes
in mlockall in 2.6.9.
A solution is to:
struct rlimit my_lim;
my_lim.rlim_cur = RLIM_INFINITY;
my_lim.rlim_max = RLIM_INFINITY;
setrlimit(RLIMIT_MEMLOCK,&my_lim);
*before* dropping privileges.
Well, if we don't know exactl
Well, if we don't know exactly what issue are you talking about it would be hard to know if it is solved or not :P
The SCSI emulation mess is different from the privileges mess.
Re: Well, if we don't know exactl
As I speak I'm writing a CD with nautilus-cdburner under Debian/Unstable
(Gnome 2.8). So it just works again (TM).
Seems so...
I just tested both xcdroast and k3b as myself (not root). They work again. Thus, the problem seems to be fixed.
PATCH APPLY
Hi can anybody tell me if this patch of 2.6.9 has to be applied to
2.6.8 or to 2.6.8.1 ? I tried to apply it to 2.6.8.1 but I get some .rej
files.
Rgds
Saxa
2.6.9 Patch
The 2.6.9 patch has to be applied to the 2.6.8 version, not to the 2.6.8.1 (unfortunately)
Best
Ingo's VP
Has Ingo moved vol_preeempt out of public reach ?
Even ~ingo/voluntary_preempt is wiped clean.
It worked wonders for my 32MB AMD-K6 m/c ...
moved
It appears to have been renamed to realtime-preempt, and can be found at
http://people.redhat.com/mingo/realtime-preempt/
Linux-wlan-ng (slightly) broken in 2.6.9
2.6.9 breaks latest linux-wlan-ng-0.2.1pre22 (support for prism2-3 wlan cards, linux-wlan.com). Seems like a trivial issue, after commenting out some (probably noncritical) lines, the driver compiled cleanly.
Kernel 2.6
It seems that linux 2.6 it's still EXPERIMENTAL, my ethernet realtek 8139 doesn't work since 2.6.7. Why not start a 2.7 branch where to try new code like Reiser4 (excellent)
Maro Melo
8139 works... for me atleast...
Well, I've also a 8139, but it run flawlessy from 2.6.0 till now 2.6.9... maybe
eth1: RealTek RTL8139 at 0xe8816000, 00:e0:7d:dd:68:86, IRQ 18
eth1: Identified 8139 chip type 'RTL-8100B/8139D'
what have you?
the card is recognised, and a
the card is recognised, and also i can navigate, but sometimes it get freezes
card freeze or system freeze?
hmm, do you mean something the card freezes BUT the system is still running or the system also freeze?
if the first is right, add "noirqdebug" in your kernel command line and check it again, but anyway please contact the maintainer, or you had to learn to live with it.
Realtek 8139
the card is recognised, and also i can navigate, but sometimes it get freezes
RTL8139 works fine for me
My RTL8139 works too.
eth0: RealTek RTL8139 at 0xf89d6000, 00:e0:7d:db:7a:f0, IRQ 10
eth0: Identified 8139 chip type 'RTL-8100B/8139D'
I've got tons of these
I am running a 2.6.7, 2.6.8.1, and a 2.6.9 on different machines, each with a realtek card in it. Works fine in all of them.
Intel or 3com nics however, will perform better :)
Typo?
"Regarding the compler fixes,"
s/compler/compiler
how about the nvidia driver with the 2.6.9?
It's said the source path incorrect.and I don't want use unoffical patch
get and patch this one liner
get and patch this one liner :
http://ck.kolivas.org/patches/2.6/2.6.9/2.6.9-ck1/patches/nvidia_compat....
and it should work, atleast it worked for me...
less not functioning?
Anybody else having trouble using the 'less' command after upgrading?
scott@amdg:~/tmp$ less test scott@amdg:~/tmp$ cat test this is a test yep scott@amdg:~/tmp$ scott@amdg:~/tmp$ strace less test execve("/usr/bin/less", ["less", "test"], [/* 49 vars */]) = 0 brk(0) = 0x8063000 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 ... open("/dev/tty", O_RDONLY|O_LARGEFILE) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbffff290) = -1 ENOTTY (Inappropriate ioctl for device) fsync(3) = -1 EINVAL (Invalid argument) ioctl(3, SNDCTL_TMR_STOP or TCSETSW, {B4800 opost isig -icanon -echo ...}) = -1 ENOTTY (Inappropriate ioctl for device) rt_sigaction(SIGINT, {0x8058a70, [INT], SA_RESTORER|SA_RESTART, 0x400970a8}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTSTP, {0x8058ab0, [TSTP], SA_RESTORER|SA_RESTART, 0x400970a8}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGWINCH, {0x8058af0, [WINCH], SA_RESTORER|SA_RESTART, 0x400970a8}, {SIG_DFL}, 8) = 0 brk(0) = 0x8066000 brk(0x8067000) = 0x8067000 pipe([4, 5]) = 0 vfork() = 6268 close(5) = 0 read(4, "", 1) = 0 close(4) = 0 wait4(6268, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 6268 --- SIGCHLD (Child exited) @ 0 (0) --- stat64("test", {st_mode=S_IFREG|0644, st_size=19, ...}) = 0 stat64("test", {st_mode=S_IFREG|0644, st_size=19, ...}) = 0 open("test", O_RDONLY|O_LARGEFILE) = 4 _llseek(4, 1, [1], SEEK_SET) = 0 _llseek(4, 0, [0], SEEK_SET) = 0 read(4, "this is a test\nyep\n", 64) = 19 _llseek(4, 1, [1], SEEK_SET) = 0 fstat64(4, {st_mode=S_IFREG|0644, st_size=19, ...}) = 0 _llseek(4, 0, [0], SEEK_SET) = 0 brk(0) = 0x8067000 brk(0x8069000) = 0x8069000 write(1, "\33[?1049h\33[?1h\33=\33[24;1H\33[K", 25) = 25 fsync(3) = -1 EINVAL (Invalid argument) ioctl(3, SNDCTL_TMR_STOP or TCSETSW, {B4800 -opost isig icanon -echo ...}) = -1 ENOTTY (Inappropriate ioctl for device) exit_group(1) = ?Yes
It's Legacy BSD ptys that are broken (or incompatibly changed).
Deactivates them and less (as well as patch) works.
I made up a bug report for that (do not remember the bug #, sorry).
Thanks! Disabled Legacy BSD a
Thanks! Disabled Legacy BSD and less now works.
Less and pty
I had the same problem using the Slackware 10.0. The problem was fixed not disabling the Legacy BSD, bu simply changing one (bad) line in
/etc/udev/rules.d/udev.rules
the bad string was:
KERNEL="tty[p-za-e][0-9a-f]*", NAME="tty/s%n", SYMLINK="%k"
in that string substitute
tty/s%n
with
pty/s%n
and all will be ok again.
Roberto
What kind of problems do you
What kind of problems do you get with patch? I had some problems patching a linux kernel, 2.6.8.1 to 2.6.8.1-mm4 on a slackware box, maybe this is the reason.
Problem with less
I run Slackware 10.0 and I had to downgrade to 2.6.8.1 because of the same issue you are having with less. 2.6.9 also appears to break mplayer. Recompiling less from source wouldn't fix it either.
Less and Slack 10
This is a known issue with Slack 10.
The problem is a bad line in
/etc/udev/rules.d/udev.rules
You have two choices:
1: download the new udev.rules from slackware_current, and use it
2: change one line in you udev.rules file:
in the line
KERNEL="tty[p-za-e][0-9a-f]*", NAME="tty/s%n", SYMLINK="%k"
substitute
tty/s%n
with
pty/s%n
And will be ok (for sure).
Roberto
Less and Slack 10
and follow that with a
/etc/rc.d/rc.udev restart
and no reboot required 8-)
old udev problem
This is the third time I debugged this since I always forget what's wrong. Hopefully next time I'll google and get here.
It's an old udev bug which created /dev/tty/ .
In /etc/udev/rules.d/udev.rules change this
-KERNEL="tty[p-za-e][0-9a-f]*", NAME="tty/s%n", SYMLINK="%k"
+KERNEL="tty[p-za-e][0-9a-f]*", NAME="pty/s%n", SYMLINK="%k"
or just upgrade to newer udev.
-----
Gah, google pointed me to adding comments to "less not functioning?", no replies seen, damn.