Re: [FIX] Re: 2.5.66 new fbcon oops while loading X

Re: [FIX] Re: 2.5.66 new fbcon oops while loading X

[Petr Vandrovec]

On 27 Mar 03 at 10:56, Wichert Akkerman wrote:
> Previously James Simmons wrote:
> > Only if they have more than one video card which is pretty small number.
> 
> Since when is that a relevant factor in breaking backwards
> compatibility?

All G400 and newer matroxfb users have dualhead system, so number is
not that small. Definitely not from my point of view ;-)

Problem is that Debian unstable still supports 2.2.x kernels
(kernel-image-2.2.20... & 2.2.22) and this version supports only 0/32/64/...
minors. 

So if you filled bug against makedev, you have to fill bug against 2.2.x
kernels too - either remove them or patch them, as otherwise updated
makedev has to conflict with kernels << 2.4.0.
                                                            Petr Vandrovec
                                                            

Re: [FIX] Re: 2.5.66 new fbcon oops while loading X

[Wichert Akkerman]

Previously Riley Williams wrote:
> Surely the correct fix is to have the updated MAKEDEV do something
> along the lines of...

That's fine for new installs, but people never run MAKEDEV when
upgrading their kernel.

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>           http://www.wiggy.net/
A random hacker

2.5.66 new fbcon oops while loading X / possible gcc bug?

[bert hubert]

While loading X, I get this oops. The weird thing is that I don't use
framebuffer. I compiled with gcc 3.2.2 but the code generated looks weird.
Virgin gcc 3.2.2 on a pentium III.

Oops, followed by my unskilled ruminations:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
c0275a13
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[fb_open+51/208]    Not tainted
EFLAGS: 00013282
EIP is at fb_open+0x33/0xd0
eax: 00000000   ebx: 000000e0   ecx: 00000001   edx: 00000001
esi: cbd436e0   edi: 00000000   ebp: 00000000   esp: c9589f24
ds: 007b   es: 007b   ss: 0068
Process XFree86 (pid: 497, threadinfo=c9588000 task=c96b27e0)
Stack: c9554720 cbfea4e0 00000000 c9554720 c89b0604 c0150bde c89b0604 c9554720 
       c9554720 c89b0604 cbfea4e0 c01481ca c89b0604 c9554720 00000002 bffffb78 
       cbfe2000 c9588000 c0148008 c937e940 cbfea4e0 00000002 c9589f80 c937e940 
Call Trace:
 [chrdev_open+94/112] chrdev_open+0x5e/0x70
 [dentry_open+442/480] dentry_open+0x1ba/0x1e0
 [filp_open+104/112] filp_open+0x68/0x70
 [sys_open+91/144] sys_open+0x5b/0x90
 [syscall_call+7/11] syscall_call+0x7/0xb

Code: 8b 00 85 c0 74 0b 83 38 02 74 6a ff 80 c0 00 00 00 85 d2 b8 

gdb traces fb_open+0x33 to:

(gdb)  l *(fb_open+0x33)
0xe23 is in fb_open (include/linux/module.h:286).
281	#define local_inc(x) atomic_inc(x)
282	#define local_dec(x) atomic_dec(x)
283	#endif
284	
285	static inline int try_module_get(struct module *module)
286	{
287		int ret = 1;
288	
289		if (module) {
290			unsigned int cpu = get_cpu();

>From the oops: Code: 8b 00 85 c0 74 0b 83 38 02 74 6a ff 80 c0 00 00 00 85
d2 b8

This output looks somewhat bogus to me as it appears to try to dereference
'module' before it has been tested for zero or not:

static inline int try_module_get(struct module *module)
{
c0275a08:	8b 86 94 01 00 00	mov	0x194(%esi),%eax
        int ret = 1;
c0275a0e:	ba 01 00 00 00		mov	$0x1,%edx
c0275a13:       8b 00			mov	(%eax),%eax

        if (module) {
c0275a15:	85 c0			test	%eax,%eax 
c0275a17:	74 0b			je	c0275a24 <fb_open+0x44>
c0275a19:	83 38 02		cmpl   $0x2,(%eax)
c0275a1c:	74 6a			je 	c0275a88 <fb_open+0xa8>

which is called from fb_open:

static int
fb_open(struct inode *inode, struct file *file)
{
 	int fbidx = minor(inode->i_rdev);
 	struct fb_info *info;
 	int res = 0;

#ifdef CONFIG_KMOD
        if (!(info = registered_fb[fbidx]))
                try_to_load(fbidx);
#endif /* CONFIG_KMOD */
        if (!(info = registered_fb[fbidx]))
                return -ENODEV;
        if (!try_module_get(info->fbops->owner))
                return -ENODEV;
        if (info->fbops->fb_open) {
                res = info->fbops->fb_open(info,1);
                if (res)
                        module_put(info->fbops->owner);
        }
        return res;
}

This suddenly appeared in 2.5.66, 2.5.65 works flawlessly with the same
compiler.

Regards,

bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting

Re: 2.5.66 new fbcon oops while loading X / possible gcc bug?

[James Simmons]

> While loading X, I get this oops. The weird thing is that I don't use
> framebuffer. I compiled with gcc 3.2.2 but the code generated looks weird.
> Virgin gcc 3.2.2 on a pentium III.

You don't use framebuffer? Can you send me your config. 

[FIX] Re: 2.5.66 new fbcon oops while loading X

[bert hubert]

On Tue, Mar 25, 2003 at 05:23:07PM +0000, James Simmons wrote:
> > While loading X, I get this oops. The weird thing is that I don't use
> > framebuffer. I compiled with gcc 3.2.2 but the code generated looks weird.
> > Virgin gcc 3.2.2 on a pentium III.
> 
> You don't use framebuffer? Can you send me your config. 

Ok, I've found the bug, it is in fb_open() in drivers/video/fbmem.c, it
needs this addition:

        if(fbidx >= FB_MAX)
                return -ENODEV;

Without it, large minor numbers result in access beyond the end of
registered_fb.

On Debian, ls /dev/fb[67] results in:
crw--w--w-    1 root     tty       29, 192 Nov 30  2000 /dev/fb6
crw--w--w-    1 root     tty       29, 224 Nov 30  2000 /dev/fb7

On Red Hat this is: 
crw-------    1 root     root      29,   7 Apr 11  2002 /dev/fb7
crw-------    1 root     root      29,   8 Apr 11  2002 /dev/fb8

Which explains why many don't see this bug.

Regards,

bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting

Re: [FIX] Re: 2.5.66 new fbcon oops while loading X

[Wichert Akkerman]

Previously bert hubert wrote:
> On Debian, ls /dev/fb[67] results in:
> crw--w--w-    1 root     tty       29, 192 Nov 30  2000 /dev/fb6
> crw--w--w-    1 root     tty       29, 224 Nov 30  2000 /dev/fb7

Documentation/devices.txt (at least in 2.5.64) states that those
devices should be fully supported:

                For backwards compatibility {2.6} the following
                progression is also handled by current kernels:
                  0 = /dev/fb0
                 32 = /dev/fb1
                    ...
                224 = /dev/fb7

So perhaps the patch should look something like:

if (fbidx >= FB_MAX) {
	/* Support older device minor numbering */
	if (fbidx%32!=0)
		return -ENODEV;
	else
		fbidx/=32;

	/* Check if it is still too large */
	if (fbidx >= FB_MAX)
		return -ENODEV;
}

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>           http://www.wiggy.net/
A random hacker

Re: [FIX] Re: 2.5.66 new fbcon oops while loading X

[James Simmons]

> Previously bert hubert wrote:
> > On Debian, ls /dev/fb[67] results in:
> > crw--w--w-    1 root     tty       29, 192 Nov 30  2000 /dev/fb6
> > crw--w--w-    1 root     tty       29, 224 Nov 30  2000 /dev/fb7
> 
> Documentation/devices.txt (at least in 2.5.64) states that those
> devices should be fully supported:
> 
>                 For backwards compatibility {2.6} the following
>                 progression is also handled by current kernels:
>                   0 = /dev/fb0
>                  32 = /dev/fb1
>                     ...
>                 224 = /dev/fb7

That is no longer true. The fb nodes should be recreated. I fixed the docs 
in devices.txt

Re: [FIX] Re: 2.5.66 new fbcon oops while loading X

[Wichert Akkerman]

Previously James Simmons wrote:
> That is no longer true. The fb nodes should be recreated. I fixed the docs 
> in devices.txt

Fine with me, however someone might want to look at the device numbering
that the various Linux distros are using at this moment. I know Debian
is using the old numbering and I just filed a bugreport to get that
updated. I do expect a fair amount of people will run into this when
they upgrade to 2.5/2.6 kernels.

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>           http://www.wiggy.net/
A random hacker

Re: [FIX] Re: 2.5.66 new fbcon oops while loading X

[James Simmons]

> Previously James Simmons wrote:
> > That is no longer true. The fb nodes should be recreated. I fixed the docs 
> > in devices.txt
> 
> Fine with me, however someone might want to look at the device numbering
> that the various Linux distros are using at this moment. I know Debian
> is using the old numbering and I just filed a bugreport to get that
> updated. I do expect a fair amount of people will run into this when
> they upgrade to 2.5/2.6 kernels.

Only if they have more than one video card which is pretty small number.

Re: [FIX] Re: 2.5.66 new fbcon oops while loading X

[Wichert Akkerman]

Previously James Simmons wrote:
> Only if they have more than one video card which is pretty small number.

Since when is that a relevant factor in breaking backwards
compatibility?

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>           http://www.wiggy.net/
A random hacker

Re: [FIX] Re: 2.5.66 new fbcon oops while loading X

[James Simmons]

> On Tue, Mar 25, 2003 at 05:23:07PM +0000, James Simmons wrote:
> > > While loading X, I get this oops. The weird thing is that I don't use
> > > framebuffer. I compiled with gcc 3.2.2 but the code generated looks weird.
> > > Virgin gcc 3.2.2 on a pentium III.
> > 
> > You don't use framebuffer? Can you send me your config. 
> 
> Ok, I've found the bug, it is in fb_open() in drivers/video/fbmem.c, it
> needs this addition:
> 
>         if(fbidx >= FB_MAX)
>                 return -ENODEV;
> 
> Without it, large minor numbers result in access beyond the end of
> registered_fb.
> 
> On Debian, ls /dev/fb[67] results in:
> crw--w--w-    1 root     tty       29, 192 Nov 30  2000 /dev/fb6
> crw--w--w-    1 root     tty       29, 224 Nov 30  2000 /dev/fb7
> 
> On Red Hat this is: 
> crw-------    1 root     root      29,   7 Apr 11  2002 /dev/fb7
> crw-------    1 root     root      29,   8 Apr 11  2002 /dev/fb8
> 
> Which explains why many don't see this bug.

Ah. That explains it. I will apply the fix.