Hey,
I got this lovely mess when trying to run ppp under 2.5.69-bk14
using devfs
all ppp is modular
thanks,
/ Brett
PPP generic driver version 2.4.2
devfs_mk_cdev: could not append to parent for ppp
failed to register PPP device (-17)
Unable to handle kernel paging request at virtual address c38755c0
printing eip:
c0150743
*pde = 01092067
*pte = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c0150743>] Not tainted
EFLAGS: 00010286
EIP is at lookup_chrfops+0x83/0xd0
eax: c38755c0 ebx: c129c600 ecx: c1e4c000 edx: 00000000
esi: 00000000 edi: 00000000 ebp: 0000006c esp: c1e4def0
ds: 007b es: 007b ss: 0068
Process pppd (pid: 402, threadinfo=c1e4c000 task=c145d380)
Stack: c1e4c000 00000000 0000006c 00000000 c01507da 0000006c 00000000 c2048b20
c2048b20 ffffffed c21adea0 c0150a42 0000006c 00000000 c2048b20 c21adea0
ffffffed c107b220 c01986c9 c21adea0 c2048b20 c2048b20 c21adea0 c10c6084
Call Trace:
[<c01507da>] get_chrfops+0x4a/0x70
[<c0150a42>] chrdev_open+0x22/0xa0
[<c01986c9>] devfs_open+0xd9/0x110
[<c0147b8a>] dentry_open+0x1da/0x210
[<c01479a0>] filp_open+0x50/0x60
[<c0147e2b>] sys_open+0x3b/0x70
[<c0108df7>] syscall_call+0x7/0xb
Code: 8b 00 be 01 00 00 00 85 c0 74 24 8b 69 14 45 89 69 14 83 38
<6>note: pppd[402] exited with preempt_count 2
bad: scheduling while atomic!
Call Trace:
[<c0114fc7>] schedule+0x3b7/0x3c0
[<c0139ddd>] unmap_vmas+0x1ed/0x260
[<c013de66>] exit_mmap+0x66/0x180
[<c0116763>] mmput+0x53/0xa0
[<c011a19a>] do_exit+0x10a/0x420
[<c0109654>] die+0xc4/0xd0
[<c0112d51>] do_page_fault+0x111/0x469
[<c0125247>] queue_work+0x97/0xb0
[<c012516e>] call_usermodehelper+0xbe/0xd0
[<c0125060>] __call_usermodehelper+0x0/0x50
[<c0112c40>] do_page_fault+0x0/0x469
[<c010905d>] error_code+0x2d/0x40
[<c0150743>] lookup_chrfops+0x83/0xd0
[<c01507da>] get_chrfops+0x4a/0x70
[<c0150a42>] chrdev_open+0x22/0xa0
[<c01986c9>] devfs_open+0xd9/0x110
[<c0147b8a>] dentry_open+0x1da/0x210
[<c01479a0>] filp_open+0x50/0x60
[<c0147e2b>] sys_open+0x3b/0x70
[<c0108df7>] syscall_call+0x7/0xb
PPP generic driver version 2.4.2
failed to register PPP device (-16)
ppp_async: Unknown symbol ppp_channel_index
ppp_async: Unknown symbol ppp_register_channel
ppp_async: Unknown symbol ppp_input
ppp_async: Unknown symbol ppp_input_error
ppp_async: Unknown symbol ppp_output_wakeup
ppp_async: Unknown symbol ppp_unregister_channel
ppp_async: Unknown symbol ppp_unit_number
Same issue under 2.5.70-bk1
> Hey,
>
> I got this lovely mess when trying to run ppp under 2.5.69-bk14
>
> using devfs
> all ppp is modular
>
> thanks,
>
> / Brett
>
> PPP generic driver version 2.4.2
> devfs_mk_cdev: could not append to parent for ppp
> failed to register PPP device (-17)
> Unable to handle kernel paging request at virtual address c38755c0
> printing eip:
> c0150743
> *pde = 01092067
> *pte = 00000000
> Oops: 0000 [#1]
> CPU: 0
> EIP: 0060:[<c0150743>] Not tainted
> EFLAGS: 00010286
> EIP is at lookup_chrfops+0x83/0xd0
> eax: c38755c0 ebx: c129c600 ecx: c1e4c000 edx: 00000000
> esi: 00000000 edi: 00000000 ebp: 0000006c esp: c1e4def0
> ds: 007b es: 007b ss: 0068
> Process pppd (pid: 402, threadinfo=c1e4c000 task=c145d380)
> Stack: c1e4c000 00000000 0000006c 00000000 c01507da 0000006c 00000000 c2048b20
> c2048b20 ffffffed c21adea0 c0150a42 0000006c 00000000 c2048b20 c21adea0
> ffffffed c107b220 c01986c9 c21adea0 c2048b20 c2048b20 c21adea0 c10c6084
> Call Trace:
> [<c01507da>] get_chrfops+0x4a/0x70
> [<c0150a42>] chrdev_open+0x22/0xa0
> [<c01986c9>] devfs_open+0xd9/0x110
> [<c0147b8a>] dentry_open+0x1da/0x210
> [<c01479a0>] filp_open+0x50/0x60
> [<c0147e2b>] sys_open+0x3b/0x70
> [<c0108df7>] syscall_call+0x7/0xb
>
> Code: 8b 00 be 01 00 00 00 85 c0 74 24 8b 69 14 45 89 69 14 83 38
> <6>note: pppd[402] exited with preempt_count 2
> bad: scheduling while atomic!
> Call Trace:
> [<c0114fc7>] schedule+0x3b7/0x3c0
> [<c0139ddd>] unmap_vmas+0x1ed/0x260
> [<c013de66>] exit_mmap+0x66/0x180
> [<c0116763>] mmput+0x53/0xa0
> [<c011a19a>] do_exit+0x10a/0x420
> [<c0109654>] die+0xc4/0xd0
> [<c0112d51>] do_page_fault+0x111/0x469
> [<c0125247>] queue_work+0x97/0xb0
> [<c012516e>] call_usermodehelper+0xbe/0xd0
> [<c0125060>] __call_usermodehelper+0x0/0x50
> [<c0112c40>] do_page_fault+0x0/0x469
> [<c010905d>] error_code+0x2d/0x40
> [<c0150743>] lookup_chrfops+0x83/0xd0
> [<c01507da>] get_chrfops+0x4a/0x70
> [<c0150a42>] chrdev_open+0x22/0xa0
> [<c01986c9>] devfs_open+0xd9/0x110
> [<c0147b8a>] dentry_open+0x1da/0x210
> [<c01479a0>] filp_open+0x50/0x60
> [<c0147e2b>] sys_open+0x3b/0x70
> [<c0108df7>] syscall_call+0x7/0xb
>
> PPP generic driver version 2.4.2
> failed to register PPP device (-16)
> ppp_async: Unknown symbol ppp_channel_index
> ppp_async: Unknown symbol ppp_register_channel
> ppp_async: Unknown symbol ppp_input
> ppp_async: Unknown symbol ppp_input_error
> ppp_async: Unknown symbol ppp_output_wakeup
> ppp_async: Unknown symbol ppp_unregister_channel
> ppp_async: Unknown symbol ppp_unit_number
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Matthew Harrell May the bluebird of happiness
Bit Twiddlers, Inc. twiddle your bits.
[email protected]
My oops output is just marginally different under 2.5.70-bk2.
Unfortunately, I don't seem to have a /proc/ksyms so I don't know what
to point ksymoops to. I can make this one happen over and over by
just running pppd. It does not kill the system but it does make it
rather unuseable.
CSLIP: code copyright 1989 Regents of the University of California
PPP generic driver version 2.4.2
devfs_mk_cdev: could not append to parent for ppp
failed to register PPP device (-17)
Unable to handle kernel paging request at virtual address e0927c80
c015a226
*pde = 0162e067
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c015a226>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: dcdb7a00 ebx: e0927c80 ecx: 0000006c edx: da17df24
esi: 00000000 edi: 00006c00 ebp: dcdb7a00 esp: da17ded8
ds: 007b es: 007b ss: 0068
Stack: c015e070 ddc2f940 00000000 c015a12f dcdb7a00 c022ee80 00006c00 dcdb7a00
00000000 c015a110 000000ff 00000000 00000000 00000000 defde200 c0159fb2
defe3400 00006c00 da17df24 00000000 defde200 ffffffed db6cb500 defe1f00
Call Trace:
[<c015e070>] do_lookup+0x30/0xb0
[<c015a12f>] exact_lock+0xf/0x20
[<c022ee80>] kobj_lookup+0xe0/0x170
[<c015a110>] exact_match+0x0/0x10
[<c0159fb2>] chrdev_open+0xe2/0x150
[<c019e3d0>] devfs_open+0xb0/0xd0
[<c0150a20>] dentry_open+0x110/0x1a0
[<c0150908>] filp_open+0x68/0x70
[<c0150cdb>] sys_open+0x5b/0x90
[<c010b14f>] syscall_call+0x7/0xb
Code: 83 3b 02 74 41 ff 83 00 01 00 00 89 04 24 e8 57 c4 06 00 85
>>EIP; c015a226 <cdev_get+16/60> <=====
>>eax; dcdb7a00 <__crc_scsi_get_command+e98e4/386137>
>>ebx; e0927c80 <__crc_elv_queue_empty+7279d/135f59>
>>edx; da17df24 <__crc_sock_rfree+2f6ef9/3b231c>
>>ebp; dcdb7a00 <__crc_scsi_get_command+e98e4/386137>
>>esp; da17ded8 <__crc_sock_rfree+2f6ead/3b231c>
Trace; c015e070 <do_lookup+30/b0>
Trace; c015a12f <exact_lock+f/20>
Trace; c022ee80 <kobj_lookup+e0/170>
Trace; c015a110 <exact_match+0/10>
Trace; c0159fb2 <chrdev_open+e2/150>
Trace; c019e3d0 <devfs_open+b0/d0>
Trace; c0150a20 <dentry_open+110/1a0>
Trace; c0150908 <filp_open+68/70>
Trace; c0150cdb <sys_open+5b/90>
Trace; c010b14f <syscall_call+7/b>
Code; c015a226 <cdev_get+16/60>
00000000 <_EIP>:
Code; c015a226 <cdev_get+16/60> <=====
0: 83 3b 02 cmpl $0x2,(%ebx) <=====
Code; c015a229 <cdev_get+19/60>
3: 74 41 je 46 <_EIP+0x46>
Code; c015a22b <cdev_get+1b/60>
5: ff 83 00 01 00 00 incl 0x100(%ebx)
Code; c015a231 <cdev_get+21/60>
b: 89 04 24 mov %eax,(%esp,1)
Code; c015a234 <cdev_get+24/60>
e: e8 57 c4 06 00 call 6c46a <_EIP+0x6c46a>
Code; c015a239 <cdev_get+29/60>
13: 85 00 test %eax,(%eax)
1 warning and 1 error issued. Results may not be reliable.
--
Matthew Harrell Artificial Intelligence is no
Bit Twiddlers, Inc. match for natural stupidity
[email protected]
On Wed, May 28, 2003 at 05:27:08PM -0400, Matthew Harrell wrote:
>
> My oops output is just marginally different under 2.5.70-bk2.
> Unfortunately, I don't seem to have a /proc/ksyms so I don't know what
> to point ksymoops to. I can make this one happen over and over by
> just running pppd. It does not kill the system but it does make it
> rather unuseable.
Fsck knows why devfs_mk_cdev() fails, but what follows that is obvious -
int __init ppp_init(void)
{
int err;
printk(KERN_INFO "PPP generic driver version " PPP_VERSION "\n");
err = register_chrdev(PPP_MAJOR, "ppp", &ppp_device_fops);
if (!err) {
err = devfs_mk_cdev(MKDEV(PPP_MAJOR, 0),
S_IFCHR|S_IRUSR|S_IWUSR, "ppp");
}
if (err)
printk(KERN_ERR "failed to register PPP device (%d)\n", err);
return err;
}
clearly leaves device registered after failed insmod. open() afterwards
happily finds the device and dies on attempt to do anything with it
(the module is not there, pointers go to hell knows where).
I'd suggest to change that to
err = devfs_mk_cdev(...)
if (!err) {
err = register_chrdev(...)
if (!err)
return 0;
devfs_remove(...)
}
printk(...)
return err;
That will _not_ solve the devfs problem, whatever it is, but it will make sure
that any errors are handled correctly.
Well, this does stop the oops but it also prevents ppp from working. I now get
this when I execute pppd
pppd: This system lacks kernel support for PPP. This could be because
the PPP kernel module could not be loaded, or because PPP was not
included in the kernel configuration. If PPP was included as a
module, try `/sbin/modprobe -v ppp'. If that fails, check that
ppp.o exists in /lib/modules/`uname -r`/net.
See README.linux file in the ppp distribution for more details.
and the kernel logs show this
CSLIP: code copyright 1989 Regents of the University of California
PPP generic driver version 2.4.2
devfs_mk_cdev: could not append to parent for ppp
: Fsck knows why devfs_mk_cdev() fails, but what follows that is obvious -
: int __init ppp_init(void)
: {
: int err;
:
: printk(KERN_INFO "PPP generic driver version " PPP_VERSION "\n");
: err = register_chrdev(PPP_MAJOR, "ppp", &ppp_device_fops);
: if (!err) {
: err = devfs_mk_cdev(MKDEV(PPP_MAJOR, 0),
: S_IFCHR|S_IRUSR|S_IWUSR, "ppp");
: }
:
: if (err)
: printk(KERN_ERR "failed to register PPP device (%d)\n", err);
: return err;
: }
: clearly leaves device registered after failed insmod. open() afterwards
: happily finds the device and dies on attempt to do anything with it
: (the module is not there, pointers go to hell knows where).
--
Matthew Harrell Life is like a diaper -
Bit Twiddlers, Inc. short and loaded.
[email protected]
And just FYI this problem still exists in the latest 2.5.70-bk9. If someone
would like to give an idea how to fix it and yet still maintain ppp capability
then I would be happy to experiment and try to get something working
--
Matthew Harrell I love defenseless animals,
Bit Twiddlers, Inc. especially in a good gravy.
[email protected]