login
Search
Linus Torvalds released the official 2.6.8 kernel noting, "the major patches since -rc4 [story] were some sparc64 and parsic updates, but there's some network driver and SATA updates and a few ARM patches too. And a use-after-free fix in MTD." The latest Linux kernel can always be obtained from a kernel.org mirror.
Shortly after the release, an easily reproducible Oops was reported from accessing a mounted NFS filesystem. Linus acknowledged the bug, and decided to release a quick 2.6.8.1, "to make it usable for people with NFS." When asked why it was named this instead of 2.6.9 using the long-standing three-digit kernel versioning, Linus explained:
"Well, we've been discussing the 2.6.x.y format for a while [story], so I see this as an opportunity to actually do it... Will it break automated scripts? Maybe. But on the other hand, we'll never even find out unless we try it some time."
From: Linus Torvalds [email blocked]
To: Kernel Mailing List [email blocked]
Subject: Linux v2.6.8
Date: Fri, 13 Aug 2004 23:05:43 -0700 (PDT)
The major patches since -rc4 were some sparc64 and parsic updates, but
there's some network driver and SATA updates and a few ARM patches too.
And a use-after-free fix in MTD.
Linus
Summary of changes from v2.6.8-rc4 to v2.6.8
============================================
<jwboyer:infradead.org>:
o Restore physmap configure-time settings according to user requests
<sm0407:nurfuerspam.de>:
o cdrom: MO-drive open write fix
Aaron Grothe:
o [CRYPTO]: Add Khazad algorithm
Andrew Chew:
o [libata sata_nv] support for hardware, bug fixes
o [libata] unmap MMIO region _after_ last possible usage
Andrew Morton:
o bk-netdev-axnet_cs-fix
o bk-netdev-hp-plus-fix
Catalin Marinas:
o [ARM PATCH] 2012/1: Use -malignment-traps instead of
-mshort-load-bytes if gcc supports it
Dave Hansen:
o 4kstacks: fix compile with gcc 2.95
David S. Miller:
o [SPARC64]: Eliminate costly sdivx from gettimeofday
o [SPARC64]: Implement tlb flush batching just like ppc64
o [SPARC64]: Need flush_tlb_pending() in switch_to()
o [SPARC64]: Kill TLB rtrap debug code
o [SPARC64]: Update defconfig
o [SPARC64]: Always record actual PC when kernel profiling
o [SPARC64]: Make clear_user_page more leight weight
o [SPARC64]: Fix up copy_page just like clear_page
o [SPARC64]: Remove memcpy Ultra3 PCACHE patching trick
o [SPARC64]: Use saner local label names in Ultra3 copies
o [SPARC64]: More entropy in add_timer_randomness
o [SPARC64]: Fix spitfire bugs in tlb flush and copy_page changes
o [SPARC64]: Kill swapper_space test in arch/sparc64/mm/tlb.c
o [SPARC64]: Change TIF_BLKCOMMIT into a fault code
o [SPARC64]: Update defconfig
o [SPARC64]: Fix non-SMP build
David Woodhouse:
o Fix use-after-free bug in MTD partitioning code
o Cosmetic MTD changes -- update email address and idents
o M-Systems DiskOnChip driver update
o RedBoot flash partitioning: use vmalloc for buffer
o Export new mtd_erase_callback() function
o Fix MTD partitioning modular build
Eugene Surovegin:
o [IPSEC]: Add missing flow_cache_genid update to
xfrm_policy_delete()
Jens Axboe:
o export kblockd_schedule_work()
o setup queue before elevator_init()
Linus Torvalds:
o Be a bit more anal about allowing SCSI commands to be sent
o Pass done file pointer to block device ioctl's
o Allow non-root users certain raw commands if they are deemed safe
o Linux 2.6.8
Marc Singer:
o [ARM PATCH] 2001/1: lh7a40x IDE cleanup
o [ARM PATCH] 2002/1: lh7a40x Timer fixup
Margit Schubert-While:
o prism54 Clarification to Viro's patch
o prism54 URGENT - Fix IRQ handling
o prism54 Fix memory leaks
o prism54 Fix supported rates reporting
Martin Devera:
o [PKT_SCHED]: Fix borrowing fairness in htb
Mathieu LESNIAK:
o wrong mac address with netgear FA311 ethernet card
Matthew Wilcox:
o Remove fcntl f_op
o PA-RISC update
o lasi_82596 update
Neil Brown:
o Fix unsigned underflow in xdr decoding
Patrick McHardy:
o [PKT_SCHED]: Disable local bh's when grabbing qdisc_tree_lock in
tc_dump_tfilter
Pawel Sikora:
o [NET]: Kill stray NET_FASTROUTE references
Roger Luethi:
o via-rhine: Really call rhine_power_init()
Russell King:
o [PCMCIA] pd6729: add MODULE_DESCRIPTION and MODULE_AUTHOR, fix
comment style
Simon Kelley:
o Atmel wireless bigendian fix
Stephen Hemminger:
o [VLAN]: Propagate ethtool/mii ioctls to the real device
o [VLAN]: Mirror real devices carrier and hotplug state
o [VLAN]: Use RCU for group operations
o [VLAN]: Fix device refcount bug
o [BRIDGE]: Fix problems with filtering and defragmentation
Tom Rini:
o Remove CONFIG_SERIAL_8250_MANY_PORTS from Ebony / Ocotea
o ppc32: Fix warning on CONFIG_PPC32 && CONFIG_6xx
From: Willy Tarreau [email blocked]
Subject: Re: Linux v2.6.8 - Oops on NFSv3
Date: Sat, 14 Aug 2004 12:10:39 +0200
Hi Linus & All,
I've just compiled and booted 2.6.8 on my dual athlon. Everything went
OK before I logged in as a non-root user whose home is mounted from
another linux box over NFSv3/UDP.
I got this oops :
<-----------
Unable to handle kernel NULL pointer dereference at virtual address 00000014
printing eip:
c01f1e76
*pde = 00000000
Oops: 0002 [#1]
PREEMPT SMP
Modules linked in: usbmouse ohci_hcd usbcore e1000 snd_seq_midi snd_emu10k1_synth snd_emux_synth
snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec snd_util_mem snd_hwdep
snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_page_alloc
snd_timer snd_mixer_oss snd soundcore
w83781d i2c_sensor i2c_amd756 i2c_core bsd_comp ppp_generic slhc
CPU: 1
EIP: 0060:[<c01f1e76>] Not tainted
EFLAGS: 00010296 (2.6.8)
EIP is at nfs3_request_init+0x16/0x20
eax: 00000000 ebx: d5496620 ecx: 00000000 edx: df614880
esi: dc262000 edi: dbb4bd68 ebp: 00000000 esp: dc263c44
ds: 007b es: 007b ss: 0068
Process bash (pid: 460, threadinfo=dc262000 task=dfc3d730)
Stack: dff96e00 c01ea7e8 d5496620 df614880 00000174 dbb4bd68 c12bd3c0 dc263cb0
d5496620 c01ed162 df614880 dbb4bd68 c12bd3c0 00000000 00000174 c12bd3d8
c12bd3c0 dc263dd0 dc263cb0 c014170c dc263d20 c12bd3c0 dc263d28 dc263d28
Call Trace:
[<c01ea7e8>] nfs_create_request+0xd8/0xf0
[<c01ed162>] readpage_async_filler+0x52/0x100
[<c014170c>] read_cache_pages+0xac/0x160
[<c011e6b0>] autoremove_wake_function+0x0/0x40
[<c012985e>] recalc_sigpending+0xe/0x10
[<c03e3923>] rpc_call_sync+0x93/0xb0
[<c01ed29c>] nfs_readpages+0x8c/0xc0
[<c01ed110>] readpage_async_filler+0x0/0x100
[<c01417f5>] read_pages+0x35/0x130
[<c013eac4>] __alloc_pages+0xc4/0x320
[<c013ed0f>] __alloc_pages+0x30f/0x320
[<c0141cf2>] do_page_cache_readahead+0x1b2/0x1e0
[<c0141e5b>] page_cache_readahead+0x13b/0x1c0
[<c013ae88>] do_generic_mapping_read+0xb8/0x410
[<c013b488>] __generic_file_aio_read+0x1d8/0x200
[<c013b1e0>] file_read_actor+0x0/0xd0
[<c013b4f5>] generic_file_aio_read+0x45/0x50
[<c01e6128>] nfs_file_read+0xb8/0xd0
[<c0157e6a>] do_sync_read+0x7a/0xb0
[<c0157f55>] vfs_read+0xb5/0xf0
[<c0158170>] sys_read+0x40/0x70
[<c01059e3>] syscall_call+0x7/0xb
Code: f0 ff 40 14 89 43 18 5b c3 90 8b 4c 24 04 8b 51 0c 3b 54 24
>>EIP; c01f1e76 <nfs3_request_init+16/20> <=====
Code; c01f1e76 <nfs3_request_init+16/20>
00000000 <_EIP>:
Code; c01f1e76 <nfs3_request_init+16/20> <=====
0: f0 ff 40 14 lock incl 0x14(%eax) <=====
Code; c01f1e7a <nfs3_request_init+1a/20>
4: 89 43 18 mov %eax,0x18(%ebx)
Code; c01f1e7d <nfs3_request_init+1d/20>
7: 5b pop %ebx
Code; c01f1e7e <nfs3_request_init+1e/20>
8: c3 ret
Code; c01f1e7f <nfs3_request_init+1f/20>
9: 90 nop
Code; c01f1e80 <nfs3_request_compatible+0/60>
a: 8b 4c 24 04 mov 0x4(%esp,1),%ecx
Code; c01f1e84 <nfs3_request_compatible+4/60>
e: 8b 51 0c mov 0xc(%ecx),%edx
Code; c01f1e87 <nfs3_request_compatible+7/60>
11: 3b 54 24 00 cmp 0x0(%esp,1),%edx
----------->
Extracts from the functions where the oops occured :
void
nfs3_request_init(struct nfs_page *req, struct file *filp)
{
req->wb_cred = get_rpccred(nfs_cred(req->wb_inode, filp));
}
static inline
struct rpc_cred * get_rpccred(struct rpc_cred *cred)
{
atomic_inc(&cred->cr_count);
return cred;
}
static struct rpc_cred *
nfs_cred(struct inode *inode, struct file *filp)
{
struct rpc_cred *cred = NULL;
if (filp)
cred = (struct rpc_cred *)filp->private_data;
if (!cred)
cred = NFS_I(inode)->mm_cred;
return cred;
}
static inline struct nfs_inode *NFS_I(struct inode *inode)
{
return container_of(inode, struct nfs_inode, vfs_inode);
}
So it seems to me that both (filp or filp->private_data) and
NFS_I(req->wb_inode)->mm_cred were NULL. I don't know if this
is a permitted situation, but directly calling get_rpccred()
from this leads to this oops.
Last 2.6 kernel I tried on this machine was 2.6.7, and I did
not notice this oops. Unfortunately, I don't have enough time
to dig through the large patch (19MB uncompressed), nor to try
different configurations. But this seems reproducible anytime
I try to access a file over NFSv3. Directory listings seem OK
at the moment. I've not tested other combinations of NFS/config
either (I'm typing this mail from the machine, so I don't want
to risk retyping everything). Since it's reproducible on a
single request, I don't think that PREEMPT/SMP has anything to
do with this.
I can send other informations if needed. If anyone wants to
suggest a patch, I can give it a try, but I won't have much
time to help debugging this, unfortunately.
Cheers,
Willy
.config used :
[config]
From: Jeff Garzik [email blocked]
Subject: Re: Linux v2.6.8 - Oops on NFSv3
Date: Sat, 14 Aug 2004 06:34:42 -0400
Willy Tarreau wrote:
> Hi Linus & All,
>
> I've just compiled and booted 2.6.8 on my dual athlon. Everything went
> OK before I logged in as a non-root user whose home is mounted from
> another linux box over NFSv3/UDP.
>
> I got this oops :
Already solved in another thread...
http://marc.theaimsgroup.com/?l=linux-kernel&m=109247958302409&w=2
From: Linus Torvalds [email blocked]
Subject: Re: Linux v2.6.8 - Oops on NFSv3
Date: Sat, 14 Aug 2004 03:41:58 -0700 (PDT)
On Sat, 14 Aug 2004, Willy Tarreau wrote:
>
> I've just compiled and booted 2.6.8 on my dual athlon. Everything went
> OK before I logged in as a non-root user whose home is mounted from
> another linux box over NFSv3/UDP.
Damn. I think the stupid typo in fs/nfs/file.c from the fcntl f_op removal
patch is the problem.
Andrew, since I'm gone in another hour, how about you try to make a
2.6.8.1 with this, since this is clearly a good reason for one?
Linus
--- 1.40/fs/nfs/file.c 2004-08-09 11:58:00 -07:00
+++ edited/fs/nfs/file.c 2004-08-14 03:35:11 -07:00
@@ -89,7 +89,7 @@
int res;
res = nfs_check_flags(filp->f_flags);
- if (!res)
+ if (res)
return res;
lock_kernel();
From: Linus Torvalds [email blocked]
Subject: Re: Linux v2.6.8 - Oops on NFSv3
Date: Sat, 14 Aug 2004 03:49:00 -0700 (PDT)
On Sat, 14 Aug 2004, Linus Torvalds wrote:
>
> Andrew, since I'm gone in another hour, how about you try to make a
> 2.6.8.1 with this, since this is clearly a good reason for one?
Ahh. Jeff posted the right one, obviously. Pushed to BK.
I'll make a 2.6.8.1 myself, to make it usable for people with NFS.
Linus
From: Christoph Hellwig [email blocked]
Subject: Re: Linux v2.6.8 - Oops on NFSv3
Date: Sat, 14 Aug 2004 11:55:48 +0100
On Sat, Aug 14, 2004 at 03:49:00AM -0700, Linus Torvalds wrote:
>
>
> On Sat, 14 Aug 2004, Linus Torvalds wrote:
> >
> > Andrew, since I'm gone in another hour, how about you try to make a
> > 2.6.8.1 with this, since this is clearly a good reason for one?
>
> Ahh. Jeff posted the right one, obviously. Pushed to BK.
>
> I'll make a 2.6.8.1 myself, to make it usable for people with NFS.
Cane we make this 2.6.9 to avoid breaking all kinds of scripts expecting
three-digit kernel versions?
From: Linus Torvalds [email blocked]
Subject: Re: Linux v2.6.8 - Oops on NFSv3
Date: Sat, 14 Aug 2004 04:05:56 -0700 (PDT)
On Sat, 14 Aug 2004, Christoph Hellwig wrote:
>
> Cane we make this 2.6.9 to avoid breaking all kinds of scripts expecting
> three-digit kernel versions?
Well, we've been discussing the 2.6.x.y format for a while, so I see this
as an opportunity to actually do it... Will it break automated scripts?
Maybe. But on the other hand, we'll never even find out unless we try it
some time.
Linus
From: Arjan van de Ven [email blocked]
Subject: Re: Linux v2.6.8 - Oops on NFSv3
Date: Sat, 14 Aug 2004 13:18:32 +0200
On Sat, 2004-08-14 at 13:05, Linus Torvalds wrote:
> On Sat, 14 Aug 2004, Christoph Hellwig wrote:
> >
> > Cane we make this 2.6.9 to avoid breaking all kinds of scripts expecting
> > three-digit kernel versions?
>
> Well, we've been discussing the 2.6.x.y format for a while, so I see this
> as an opportunity to actually do it... Will it break automated scripts?
> Maybe. But on the other hand, we'll never even find out unless we try it
> some time.
well... I'll volunteer to keep a 2.6.X-postY series.. this fix could be
part of that.
For me the -post series should be
* Only patches that are in later head kernels (maybe lightly touched to
resolve patch conflicts)
* Only patches that fix something critical/important
(where critical is of course a gray area but I'm sure a decent balance
will be found)
From: Al Viro [email blocked]
Subject: Re: Linux v2.6.8 - Oops on NFSv3
Date: Sat, 14 Aug 2004 12:31:38 +0100
On Sat, Aug 14, 2004 at 01:18:32PM +0200, Arjan van de Ven wrote:
> On Sat, 2004-08-14 at 13:05, Linus Torvalds wrote:
> > On Sat, 14 Aug 2004, Christoph Hellwig wrote:
> > >
> > > Cane we make this 2.6.9 to avoid breaking all kinds of scripts expecting
> > > three-digit kernel versions?
> >
> > Well, we've been discussing the 2.6.x.y format for a while, so I see this
> > as an opportunity to actually do it... Will it break automated scripts?
> > Maybe. But on the other hand, we'll never even find out unless we try it
> > some time.
>
> well... I'll volunteer to keep a 2.6.X-postY series.. this fix could be
> part of that.
>
> For me the -post series should be
> * Only patches that are in later head kernels (maybe lightly touched to
> resolve patch conflicts)
> * Only patches that fix something critical/important
> (where critical is of course a gray area but I'm sure a decent balance
> will be found)
2.6.X-paperbagY?
Said that, if you start doing that - count on my help.
:)
Damn you guys are slow....
Funny, that patch-2.6.8.1
There's something funny with the patch. One part of it is this:
- if (flags & (O_APPEND | O_DIRECT))
+ if ((flags & (O_APPEND | O_DIRECT)) == (O_APPEND | O_DIRECT))
(flags & (O_APPEND | O_DIRECT)) == (O_APPEND | O_DIRECT)
simplifies to
(flags & P) == P #Substituted (O_APPEND | O_DIRECT) for P
which, in turn, simplifies to
flags == P #Simple bitwise logic: flags and P must be identical to yield P when AND is applied on them.
Too much coffee for either the kernel developers or me, perhaps?
Too much coffee for you :-)
Too much coffee for you :-)
What you are describing is bool (?) logic not bitwise.
Example:
If O_APPEND bit is set and O_DIRECT is not (and vice versa), first condition will be true, second wont.
My head hurts
Maybe I'm just not too familiar with bitwise logic, but I find the second version very confusing to read. After some thought, I've determined it says "If both O_APPEND and O_DIRECT are set, then ..."
In that case, I'd write:
if ((flags & O_APPEND) && (flags & O_DIRECT)) {In my opinion that says exactly what it means, instead of obfuscating the meaning with unusual coding. However, maybe that is a standard way of doing it and I've just never seen it done that way before.
They're logically equivalent
The two are logically equivalent. The former is idiomatic, and is more "optimized."
You see, the && operator implies "short circuit evaluation." That is, if the left side of && evaluates as false, the right side is not evaluated. This is important if the right half has side effects. For instance, consider:
In this example, if the pointer ptr is NULL, it will not get dereferenced. In other words, it is equivalent to this nested if statement, along with the extra branches it implies:
if (ptr) { if (*ptr == 3) { /*... */ } }Compilers are required to implement the short-circuit semantics. They can optimize them away when it they can prove that there are no unwanted side effects. In this case, the compiler may be able to prove that.
When the compiler can prove there are no side effects due to the right-hand side of a logical operator, it may optimize a sequence such your sequence above to something slightly less pessimistic:
It's less clear whether the compiler would succeed in seeing through this and optimize the expression down to the single test that the original code has.
For grins, I tried this on a couple compilers. I specifically tried this test code:
#define O_APPEND 02000 #define O_DIRECT 040000 extern void bar(); extern void baz(); void foo1(unsigned int flags) { if ((flags & (O_APPEND | O_DIRECT)) == (O_APPEND | O_DIRECT)) bar(); else baz(); } void foo2(unsigned int flags) { if ((flags & O_APPEND) && (flags & O_DIRECT)) bar(); else baz(); }Here's what GCC 3.4.0 for x86 output w/ -O6 -fomit-frame-pointer:
.globl foo1 .type foo1, @function foo1: movl 4(%esp), %eax andl $17408, %eax cmpl $17408, %eax je .L5 jmp baz .L5: jmp bar .size foo1, .-foo1 .globl foo2 .type foo2, @function foo2: movl 4(%esp), %eax testb $4, %ah je .L7 testb $64, %ah jne .L9 .L7: jmp baz .L9: jmp barNotice that for the first one, there's a single test/branch. For the second one, there are two tests, two branches. Ick. Branching sucks on modern CPUs. Like I said, I tried a couple compilers. I tried a TI DSP compiler for the C62x, just to see what it'd do.
_foo1: ;** --------------------------------------------------------------------------* MVK .S1 17408,A3 ; |10| || MVK .S2 17408,B4 ; |10| AND .L1 A3,A4,A3 ; |10| CMPEQ .L2X A3,B4,B0 ; |10| [ B0] B .S1 $C$L2 ; |10| [!B0] CALLRET .S1 _baz ; |13| [ B0] CALLRET .S1 _bar ; |11| NOP 3 ; BRANCHCC OCCURS {$C$L2} ; |10| ;** NOP 1 $C$RL2: ; CALL-RETURN OCCURS {_baz} ; |13| $C$L2: NOP 2 $C$RL3: ; CALL-RETURN OCCURS {_bar} ; |11| _foo2: ;** --------------------------------------------------------------------------* $C$DW$4 SHR .S1 A4,4,A3 ; |18| AND .L1 A4,A3,A3 ; |18| EXTU .S1 A3,21,31,A0 ; |18| [ A0] B .S1 $C$L1 ; |18| [!A0] CALLRET .S1 _baz ; |21| [ A0] CALLRET .S1 _bar ; |19| NOP 3 ; BRANCHCC OCCURS {$C$L1} ; |18| ;** NOP 1 $C$RL0: ; CALL-RETURN OCCURS {_baz} ; |21| ;** $C$L1: NOP 2 $C$RL1: ; CALL-RETURN OCCURS {_bar} ; |19|This one is interesting--if quite a bit harder to follow due to the delayed branches on the C62x architecture. (Quick primer below.) This compiler was able to at least get as far as the && to & conversion, so that there is only one actual "branch" that isn't a function call. They end up being the same speed.
So caveat emptor. Under GCC, this coding strategy actually ends up producing better object code. (At least, on x86.) Under the TI DSP compiler on C62x, it doesn't.
How many programmer cycles does it steal? Unknown. It's a common idiom, but its popularity may be due to the popularity of premature microoptimization.
Incidentally, looking at the TI compiler's output, I see that it can be optimized further.... I'll have to let the compiler guys here know. :-)
Quick primer on reading C62x code:
Jeremy: Ugly style!
Just a side comment for Jeremy: The "indent every paragraph" style's ugly and dated. Just look at what it does to the hanging indents on the bulleted list! Everyone block-formats their paragraphs these days.
Ah, just my 0x02 cents. :-)
Funny, that patch-2.6.8.1
There's something funny with the patch. One part of it is this beauty:
- if (flags & (O_APPEND | O_DIRECT))
+ if ((flags & (O_APPEND | O_DIRECT)) == (O_APPEND | O_DIRECT))
(flags & (O_APPEND | O_DIRECT)) == (O_APPEND | O_DIRECT)
simplifies to
(flags & P) == P #Substituted (O_APPEND | O_DIRECT) for P
which, in turn, simplifies to
flags == P #Simple bitwise logic: flags and P must be identical to yield P when AND is applied on them.
Too much coffee for either the kernel developers or me, perhaps?
wrong
let's talk using an example:
flags = 7
p = 3
(flags & p) == p
translates to
(7 & 3) == 3
3 == 3
yet, 7 != 3. Therefore, your reasoning seems to have a fault.
I stand corrected
Thanks for correcting me. I wonder how on Earth I managed to forget about upper bits. This proves, once again, that one can be wrong while being completely confident on being correct if something fundamental is overlooked.
Funny, that patch-2.6.8.1
This code is correct, I believe if fixes a bug because:
- if (flags & (O_APPEND | O_DIRECT))
means that, if flags has O_APPEND or O_DIRECT is set
while
+ if ((flags & (O_APPEND | O_DIRECT)) == (O_APPEND | O_DIRECT))
means that if flags has O_APPEND and O_DIRECT are set
so they are diffrent...
Previously, if one of these flags are set, the condition will be true, the correction is that both should be set to be true...
Hope it helped
Ibrahim
finally .y
I love it. This makes so much more sense and allows people to measure all of those bk and rc snapshots. I hope this leads to a furthore measurement in version numbering of kernel work so that as much as possible can be documented and tracked.
The new attitude to "stability"
The kernel developers have gone to great pains to prevent interface incompatibility to user space where possible between kernels (ie. system calls). Why the hell can't they do likewise for scripts?
Is this another "stability of production systems matters less now than it used to, as that's a vendor issue", and the attitude implied by the "new" development model? I now remember the days of Alan Cox's *stable* kernels with even more gratitude than I did before.
Re: The new attitude to "stability"
Ditto. Please come back, AC. We need you.
flexible
Scripting languages are created in the sense they should be flexible, scalable and quick tools. I think scripting languages can catch up to this extra .y, if they can't I don't think it would be useful to continue using said language.
Matrox Framebuffer problems
I cannot use 2.6.8 because i get machine freeze sometimes when i switch from X (with mga driver) and mga fb.
Is this problem still annoyng this last release?
I had this problem in 2.6.7.
Thanks
2.6.8.1 only fixes NFS
the only change in 2.6.8.1 from 2.6.8 was the NFS oops.
Matrox Framebuffer problems
I get my screen go completely blank every time I try 3D screensavers for a few seconds. I think this bug surfaced in 2.6.7.