I started getting these errors after upgrading to 2.6.4 out of the development tree.
ip_tables: (C) 2000-2002 Netfilter core team PCI: Enabling device 0000:00:09.0 (0014 -> 0017) sk98lin: Network Device Driver v6.23 (C)Copyright 1999-2004 Marvell(R). divert: allocating divert_blk for eth0 eth0: 3Com Gigabit LOM (3C940) PrefPort:A RlmtMode:Check Link State ip_tables: (C) 2000-2002 Netfilter core team Debug: sleeping function called from invalid context at mm/slab.c:1943 in_atomic():0, irqs_disabled():1 Call Trace: [<02120144>] __might_sleep+0x80/0x8a [<02149cdf>] kmem_cache_alloc+0x1c/0x143 [<229953a6>] Vpd+0x26/0x801 [sk98lin] [<22993b03>] SkPnmiGetStruct+0x330/0x3de [sk98lin] [<0211e7eb>] __wake_up+0x8a/0xee [<2298d65b>] SkGeStats+0xef/0x29e [sk98lin] [<022800d7>] rtnetlink_fill_ifinfo+0x307/0x3c8 [<02280359>] rtmsg_ifinfo+0x2d/0x78 [<022808e6>] rtnetlink_event+0x35/0x38 [<02131709>] notifier_call_chain+0x17/0x30 [<022789b2>] dev_open+0xc5/0xcc [<02279d33>] dev_change_flags+0x48/0xee [<022b3de8>] devinet_ioctl+0x255/0x4a1 [<022b58b7>] inet_ioctl+0x69/0x9b [<022723c0>] sock_ioctl+0x2d7/0x38d [<02272808>] sys_socket+0x2a/0x3d [<02178662>] sys_ioctl+0x29a/0x33c
eth0: network connection up using port A speed: 100 autonegotiation: yes duplex mode: full flowctrl: symmetric irq moderation: disabled scatter-gather: enabled Debug: sleeping function called from invalid context at mm/slab.c:1943 in_atomic():0, irqs_disabled():1 Call Trace: [<02120144>] __might_sleep+0x80/0x8a [<02149cdf>] kmem_cache_alloc+0x1c/0x143 [<229953a6>] Vpd+0x26/0x801 [sk98lin] [<22993b03>] SkPnmiGetStruct+0x330/0x3de [sk98lin] [<2298d65b>] SkGeStats+0xef/0x29e [sk98lin] [<022800d7>] rtnetlink_fill_ifinfo+0x307/0x3c8 [<022801d3>] rtnetlink_dump_ifinfo+0x3b/0x56 [<0228b21e>] netlink_dump+0x145/0x4c9 [<02149dce>] kmem_cache_alloc+0x10b/0x143 [<0228b7a1>] netlink_dump_start+0x1ff/0x207 [<022804d6>] rtnetlink_rcv+0x12f/0x50a [<02280198>] rtnetlink_dump_ifinfo+0x0/0x56 [<022803a4>] rtnetlink_done+0x0/0x3 [<0228b00f>] netlink_data_ready+0x14/0x41 [<0228a83f>] netlink_unicast+0x31f/0x362 [<0211e6fe>] default_wake_function+0x0/0xc [<0211e6fe>] default_wake_function+0x0/0xc [<0228ae33>] netlink_sendmsg+0x258/0x267 [<02271c7c>] sock_sendmsg+0x88/0xa2 [<02145458>] buffered_rmqueue+0x1ec/0x1f6 [<0216177e>] rw_vm+0x30a/0x3a4 [<02161a71>] get_user_size+0x30/0x57 [<02272d89>] sys_sendto+0xc7/0xe2 [<0211b1e7>] do_page_fault+0x12b/0x442 [<02271a44>] sock_map_file+0x98/0x106 [<021512ea>] follow_page+0xf4/0xff [<0216177e>] rw_vm+0x30a/0x3a4 [<02273480>] sys_socketcall+0xeb/0x179
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] parport0: irq 7 detected lp0: using parport0 (polling). lp0: console ready NET: Registered protocol family 10 Disabled Privacy Extensions on device 0232f700(lo) IPv6 over IPv4 tunneling driver divert: not allocating divert_blk for non-ethernet device sit0 Debug: sleeping function called from invalid context at mm/slab.c:1943 in_atomic():0, irqs_disabled():1 Call Trace: [<02120144>] __might_sleep+0x80/0x8a [<02149cdf>] kmem_cache_alloc+0x1c/0x143 [<229953a6>] Vpd+0x26/0x801 [sk98lin] [<22993b03>] SkPnmiGetStruct+0x330/0x3de [sk98lin] [<2298d65b>] SkGeStats+0xef/0x29e [sk98lin] [<022800d7>] rtnetlink_fill_ifinfo+0x307/0x3c8 [<022801d3>] rtnetlink_dump_ifinfo+0x3b/0x56 [<0228b21e>] netlink_dump+0x145/0x4c9 [<02149dce>] kmem_cache_alloc+0x10b/0x143 [<0228b7a1>] netlink_dump_start+0x1ff/0x207 [<022804d6>] rtnetlink_rcv+0x12f/0x50a [<02280198>] rtnetlink_dump_ifinfo+0x0/0x56 [<022803a4>] rtnetlink_done+0x0/0x3 [<0228b00f>] netlink_data_ready+0x14/0x41 [<0228a83f>] netlink_unicast+0x31f/0x362 [<0211e6fe>] default_wake_function+0x0/0xc [<0211e6fe>] default_wake_function+0x0/0xc [<0228ae33>] netlink_sendmsg+0x258/0x267 [<02271c7c>] sock_sendmsg+0x88/0xa2 [<02145458>] buffered_rmqueue+0x1ec/0x1f6 [<0216177e>] rw_vm+0x30a/0x3a4 [<02161a71>] get_user_size+0x30/0x57 [<02272d89>] sys_sendto+0xc7/0xe2 [<0211b1e7>] do_page_fault+0x12b/0x442 [<02271a44>] sock_map_file+0x98/0x106 [<021512ea>] follow_page+0xf4/0xff [<0216177e>] rw_vm+0x30a/0x3a4 [<02273480>] sys_socketcall+0xeb/0x179
eth0: no IPv6 routers present
On Wed, 2004-03-31 at 20:26, Zach Wilkinson wrote:
I started getting these errors after upgrading to 2.6.4 out of the development tree.
ip_tables: (C) 2000-2002 Netfilter core team PCI: Enabling device 0000:00:09.0 (0014 -> 0017) sk98lin: Network Device Driver v6.23 (C)Copyright 1999-2004 Marvell(R). divert: allocating divert_blk for eth0 eth0: 3Com Gigabit LOM (3C940) PrefPort:A RlmtMode:Check Link State ip_tables: (C) 2000-2002 Netfilter core team Debug: sleeping function called from invalid context at mm/slab.c:1943 in_atomic():0, irqs_disabled():1 Call Trace: [<02120144>] __might_sleep+0x80/0x8a [<02149cdf>] kmem_cache_alloc+0x1c/0x143
Thou shalt not allocate memory with interrupts off.
Please bugzilla this.
Dave
That's OK, it seems to work anyway. No show stopper. Besides, not being a engineer, I doubt I'm eligible to file a bug report. Last thing I want is to get flamed about presuming to be able to file a bug report. Best to leave well enough alone; these lists can be rough territory.
Thanks,
----- Original Message ----- From: "Dave Jones" davej@redhat.com To: "For testers of Fedora Core development releases" fedora-test-list@redhat.com Sent: Thursday, April 01, 2004 5:38 AM Subject: Re: Call Trace on boot
On Wed, 2004-03-31 at 20:26, Zach Wilkinson wrote:
I started getting these errors after upgrading to 2.6.4 out of the development tree.
ip_tables: (C) 2000-2002 Netfilter core team PCI: Enabling device 0000:00:09.0 (0014 -> 0017) sk98lin: Network Device Driver v6.23 (C)Copyright 1999-2004 Marvell(R). divert: allocating divert_blk for eth0 eth0: 3Com Gigabit LOM (3C940) PrefPort:A RlmtMode:Check Link State ip_tables: (C) 2000-2002 Netfilter core team Debug: sleeping function called from invalid context at mm/slab.c:1943 in_atomic():0, irqs_disabled():1 Call Trace: [<02120144>] __might_sleep+0x80/0x8a [<02149cdf>] kmem_cache_alloc+0x1c/0x143
Thou shalt not allocate memory with interrupts off.
Please bugzilla this.
Dave
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
On Thu, Apr 01, 2004 at 04:22:51PM -0500, Zach Wilkinson wrote:
That's OK, it seems to work anyway. No show stopper. Besides, not being a engineer, I doubt I'm eligible to file a bug report.
Anyone can file a bug report.
Last thing I want is to get flamed about presuming to be able to file a bug report. Best to leave well enough alone; these lists can be rough territory.
Please file it.
Alan
----- Original Message ----- From: "Alan Cox" alan@redhat.com To: "For testers of Fedora Core development releases" fedora-test-list@redhat.com Sent: Thursday, April 01, 2004 4:26 PM Subject: Re: Call Trace on boot
On Thu, Apr 01, 2004 at 04:22:51PM -0500, Zach Wilkinson wrote:
That's OK, it seems to work anyway. No show stopper. Besides, not being a engineer, I doubt I'm eligible to file a bug
report.
Anyone can file a bug report.
Uhh, are you sure that's a good policy? Seems like there would be a lot of potential for abuse.
Last thing I want is to get flamed about presuming to be able to file a
bug
report. Best to leave well enough alone; these lists can be rough territory.
Please file it.
Alan
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
On Thu, 2004-04-01 at 16:38, Zach Wilkinson wrote:
----- Original Message ----- From: "Alan Cox" alan@redhat.com To: "For testers of Fedora Core development releases" fedora-test-list@redhat.com Sent: Thursday, April 01, 2004 4:26 PM Subject: Re: Call Trace on boot
On Thu, Apr 01, 2004 at 04:22:51PM -0500, Zach Wilkinson wrote:
That's OK, it seems to work anyway. No show stopper. Besides, not being a engineer, I doubt I'm eligible to file a bug
report.
Anyone can file a bug report.
Uhh, are you sure that's a good policy? Seems like there would be a lot of potential for abuse.
It has been working for years in many projects. I've been amazed at how quickly people respond to good bug reports. Bugzilla is good at requiring a reasonable level of detail to prevent "my computer doesn't work" reports, which are more common in a list like this.
----- Original Message ----- From: "Will Backman" whb@ceimaine.org To: "For testers of Fedora Core development releases" fedora-test-list@redhat.com Sent: Thursday, April 01, 2004 4:43 PM Subject: Re: Call Trace on boot
On Thu, 2004-04-01 at 16:38, Zach Wilkinson wrote:
----- Original Message ----- From: "Alan Cox" alan@redhat.com To: "For testers of Fedora Core development releases" fedora-test-list@redhat.com Sent: Thursday, April 01, 2004 4:26 PM Subject: Re: Call Trace on boot
On Thu, Apr 01, 2004 at 04:22:51PM -0500, Zach Wilkinson wrote:
That's OK, it seems to work anyway. No show stopper. Besides, not being a engineer, I doubt I'm eligible to file a bug
report.
Anyone can file a bug report.
Uhh, are you sure that's a good policy? Seems like there would be a lot
of
potential for abuse.
It has been working for years in many projects. I've been amazed at how quickly people respond to good bug reports. Bugzilla is good at requiring a reasonable level of detail to prevent "my computer doesn't work" reports, which are more common in a list like this.
I think I fall into this category. I don't understand Call Traces well enough to fill out a bug report. Hell, I don't know even know how to use GDB. Definitely over my head.
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
On Thu, 2004-04-01 at 16:52, Zach Wilkinson wrote:
----- Original Message ----- From: "Will Backman" whb@ceimaine.org To: "For testers of Fedora Core development releases" fedora-test-list@redhat.com Sent: Thursday, April 01, 2004 4:43 PM Subject: Re: Call Trace on boot
On Thu, 2004-04-01 at 16:38, Zach Wilkinson wrote:
----- Original Message ----- From: "Alan Cox" alan@redhat.com To: "For testers of Fedora Core development releases" fedora-test-list@redhat.com Sent: Thursday, April 01, 2004 4:26 PM Subject: Re: Call Trace on boot
On Thu, Apr 01, 2004 at 04:22:51PM -0500, Zach Wilkinson wrote:
That's OK, it seems to work anyway. No show stopper. Besides, not being a engineer, I doubt I'm eligible to file a bug
report.
Anyone can file a bug report.
Uhh, are you sure that's a good policy? Seems like there would be a lot
of
potential for abuse.
It has been working for years in many projects. I've been amazed at how quickly people respond to good bug reports. Bugzilla is good at requiring a reasonable level of detail to prevent "my computer doesn't work" reports, which are more common in a list like this.
I think I fall into this category. I don't understand Call Traces well enough to fill out a bug report. Hell, I don't know even know how to use GDB. Definitely over my head.
I've been in over my head also (which is fairly easy), and often someone will respond to the bug with helpful tips on how to produce useful data. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=56011 for an example of how nice these folks are.
On Thu, Apr 01, 2004 at 04:52:48PM -0500, Zach Wilkinson wrote:
I think I fall into this category. I don't understand Call Traces well enough to fill out a bug report. Hell, I don't know even know how to use GDB.
Nor do most people who file bugs.
Quick guidelines: - Include a copy of the call trace (even if you dont know what it means someone else does) - If it is an error with a message include the exact message - And specify what you were doing
As to gdb, the minimal guide to gdb is this. Find app that is crashing, from the command line
gdb [appname] gdb> run [arguments to command] When it breaks gdb> where
and attach the data. Threaded apps are a bit trickier but uncommon,and most bug reports are useful even without that kind of trace data.
If "select this and press that" breaks it, I can break my own copy.
Alan
On Thu, 2004-04-01 at 16:22, Zach Wilkinson wrote:
That's OK, it seems to work anyway. No show stopper. Besides, not being a engineer, I doubt I'm eligible to file a bug report. Last thing I want is to get flamed about presuming to be able to file a bug report. Best to leave well enough alone; these lists can be rough territory.
Thanks,
You really should submit bug reports. Not all developers read this list every day, and it should not be relied upon for communicating errors.
From what I have read "if its not in bugzilla, it doesn't exist".
-
Alan Cox -
Dave Jones -
Will H. Backman -
Zach Wilkinson