Greg KH wrote: > On Fri, Mar 13, 2009 at 03:10:51PM -0700, Andrew Morton wrote: >> >> I fired up this kernel up on my FC8 laptop and I see >> http://userweb.kernel.org/~akpm/p3130212.jpg >> >> On the next two boot attempts, the kernel came up OK. >>
root issue: seems that something with the 2.6.newer doesn't like some of the stuff with the fedora nash stuff. mkinitrd and friends were updated multiple times to work with these newer kernels in the fedora 10 I was using. I worked around by changing root=LABEL to use root=/dev/foo in grub.conf >> >> ------------[ cut here ]------------ >> WARNING: at drivers/net/e1000e/ich8lan.c:408 >> e1000_acquire_swflag_ich8lan+0x51/0xf2() e1000e mutex contention. >> Owned by pid 10 >> Modules linked in: >> Pid: 9, comm: events/0 Not tainted 2.6.28.7 #1 >> Call Trace: >> [<ffffffff8103a810>] warn_slowpath+0xae/0xcd >> [<ffffffff8104394b>] ? lock_timer_base+0x26/0x4a >> [<ffffffff8104394b>] ? lock_timer_base+0x26/0x4a >> [<ffffffff8105d63f>] ? __lock_acquire+0x702/0x760 >> [<ffffffff8105bfc6>] ? mark_held_locks+0x50/0x6d >> [<ffffffff812dd950>] ? mutex_trylock+0x104/0x118 >> [<ffffffff8105c170>] ? trace_hardirqs_on_caller+0xf8/0x123 >> [<ffffffff8105c1a8>] ? trace_hardirqs_on+0xd/0xf >> [<ffffffff811ed838>] e1000_acquire_swflag_ich8lan+0x51/0xf2 >> [<ffffffff811f2fe9>] e1000e_read_kmrn_reg+0x1b/0x69 >> [<ffffffff811f63c5>] ? e1000e_downshift_workaround+0x0/0x12 >> [<ffffffff811ed1e9>] >> e1000e_gig_downshift_workaround_ich8lan+0x2c/0x71 >> [<ffffffff811f63d5>] e1000e_downshift_workaround+0x10/0x12 >> [<ffffffff8104a6ed>] run_workqueue+0xf5/0x1fd [<ffffffff8104a697>] >> ? run_workqueue+0x9f/0x1fd [<ffffffff8104a8f6>] ? >> worker_thread+0x0/0xe8 [<ffffffff8104a9d1>] worker_thread+0xdb/0xe8 >> [<ffffffff8104de14>] ? autoremove_wake_function+0x0/0x36 >> [<ffffffff8104a8f6>] ? worker_thread+0x0/0xe8 >> [<ffffffff8104db1a>] kthread+0x44/0x6b >> [<ffffffff8100cf59>] child_rip+0xa/0x11 >> [<ffffffff8100c474>] ? restore_args+0x0/0x30 >> [<ffffffff8104dad6>] ? kthread+0x0/0x6b >> [<ffffffff8100cf4f>] ? child_rip+0x0/0x11 newer kernels have this fixed. This really is a warning as this is only telling you that it had to wait (but that the mutex worked!) we've isolated all these warnings down to known SMP safe paths (and fixed the relevant issues) and have posted a patch to current net-next that removes the warning. don't have the commit handy but could probably chase it down. so, WARNING is noisy but okay. The tx hang you see is bad (as it appears to be a false hang since status is set correctly and you don't get a NETDEV_WATCHDOG) Jesse PS please include netdev on network related issues. :-) ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel