Additional info: libreport version: 2.0.14 abrt_version: 2.0.13 cmdline: BOOT_IMAGE=/vmlinuz-3.5.4-1.fc17.i686 root=/dev/mapper/vg_jimslinux-lv_root ro rd.lvm.lv=vg_jimslinux/lv_swap rd.md=0 rd.dm=0 SYSFONT=True rd.lvm.lv=vg_jimslinux/lv_root KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 rhgb quiet kernel: 3.5.4-1.fc17.i686 backtrace: :WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x1df/0x1f0() :Hardware name: :NETDEV WATCHDOG: em1 (sis900): transmit queue 0 timed out :Modules linked in: fuse bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ppdev snd_usb_audio snd_usbmidi_lib snd_hwdep snd_rawmidi uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media i2c_core usblp snd_intel8x0 snd_ac97_codec ac97_bus microcode snd_seq snd_seq_device snd_pcm serio_raw sis900 mii parport_pc parport snd_page_alloc snd_timer snd soundcore binfmt_misc uinput ata_generic pata_acpi sata_sis pata_sis [last unloaded: scsi_wait_scan] :Pid: 0, comm: swapper/0 Not tainted 3.5.4-1.fc17.i686 #1 :Call Trace: : [<c0438f72>] warn_slowpath_common+0x72/0xa0 : [<c086da0f>] ? dev_watchdog+0x1df/0x1f0 : [<c086da0f>] ? dev_watchdog+0x1df/0x1f0 : [<c0439043>] warn_slowpath_fmt+0x33/0x40 : [<c086da0f>] dev_watchdog+0x1df/0x1f0 : [<c086d830>] ? dev_deactivate_queue.constprop.32+0x60/0x60 : [<c0447d81>] run_timer_softirq+0xf1/0x2a0 : [<c0745f9a>] ? scsi_softirq_done+0x11a/0x140 : [<c086d830>] ? dev_deactivate_queue.constprop.32+0x60/0x60 : [<c0441187>] __do_softirq+0x97/0x190 : [<c04410f0>] ? local_bh_enable_ip+0x90/0x90 : <IRQ> [<c04414dd>] ? irq_exit+0x9d/0xb0 : [<c042138e>] ? smp_apic_timer_interrupt+0x5e/0x90 : [<c045c8c7>] ? hrtimer_start+0x27/0x30 : [<c0944d15>] ? apic_timer_interrupt+0x31/0x38 : [<c08100e0>] ? __cpufreq_governor+0xb0/0x110 : [<c040a3d8>] ? mwait_idle+0x78/0x1b0 : [<c040acc6>] ? cpu_idle+0xb6/0xe0 : [<c0924c55>] ? rest_init+0x5d/0x68 : [<c0be19bc>] ? start_kernel+0x35d/0x363 : [<c0be1494>] ? repair_env_string+0x51/0x51 : [<c0be12c2>] ? i386_start_kernel+0x78/0x7d
1. Boot Linux 2. Connected iPhone by usb line Package: kernel OS Release: Fedora release 17 (Beefy Miracle)
i am connected to the internet via lan cable. it is an old cable with cracks, so it loses connection while i was moving the laptop to another place. then it is impossible to reconnect to the www. Package: kernel OS Release: Fedora release 17 (Beefy Miracle)
Why it Happened? = Someone or some Program issued a crash trigger. Usual assumption when no new processes are being initiated. Or only individual threads not being used or viewed, are the ones causing a halt process in Chrome. There have been a number of different situations, usually Chrome is open, However this is the first time Hootlet was in use. Plus, Double Sandboxed Apps, & not part of OS? I was about to make a Joke about how the Jewish calendar starts on September. And that the conspiracy of World Trade Center, is a Jewish financial conspiracy by the CIA to rob Islamic nations of wealth in order for our economy to service. Unfortunately is is Jewish financial teachings that have ruined our economy. There is an audio CD from 1999, "Train" something or other authored by Three Jews about Internet Commerce. Using Hootlet to post to Facebook, I was about to note the Hebrew Calendar was invented in 300BC , and not 5773 years ago. They are taking credit for the Egyptian Calendar. Moses was born and lead Hebrew slaves out of Egypt in 1600BC. Amen-Hotep 4th dismissed the Hebrew slaves from work, in order to move south and Invent what became Greek and Roman Columns, while Moses watched Amen-"Ra" rise in the East over the Sinai. He then Ordered the death of his people who continued to worship Apis, however God killed all the people who did as Moses had commanded. ~ I.E. God protects the Apis Worshipers beyond the wishes of Jews, and avenges with death those who harm them. And as the Bible or Orthodox Jewish Bible records Moses was far from Perfect embarrassing people with his poor judgment in using the power his place gave him. So basically who is hacking my Computer? Package: kernel OS Release: Fedora release 17 (Beefy Miracle)
Guys, if this error what to do? WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x1df/0x1f0()
Occurs on boot up of the system Package: kernel OS Release: Fedora release 17 (Beefy Miracle)
No idea what causes it. Watching video on mplayer and downloading torrent through transmission at the time. Comes up every boot, sometimes immediately after login and sometimes later Package: kernel OS Release: Fedora release 17 (Beefy Miracle)
Either we find a bug in the driver, or you get new hardware, as the hardware isn't communicating with the driver properly. If you're able to reproduce this, the upstream driver maintanier asks that you get in touch with him: http://www.brownhat.org/sis900.html That said, it sounds like this has been a very long running problem, likely not one thats getting fixed anytime soon
commit 3508ea333ed5414561af4c818b3b80c0acca1845 Author: Denis Kirjanov <kda> Date: Fri Aug 2 13:50:54 2013 +0400 sis900: Fix the tx queue timeout issue [ 198.720048] ------------[ cut here ]------------ [ 198.720108] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:255 dev_watchdog+0x229/0x240() [ 198.720118] NETDEV WATCHDOG: eth0 (sis900): transmit queue 0 timed out [ 198.720125] Modules linked in: bridge stp llc dmfe sundance 3c59x sis900 mii [ 198.720159] CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.0-rc3+ #12 [ 198.720167] Hardware name: System Manufacturer System Name/TUSI-M, BIOS ASUS TUSI-M ACPI BIOS Revision 1013 Beta 001 12/14/2001 [ 198.720175] 000000ff c13fa6b9 c169ddcc c12208d6 c169ddf8 c1031e4d c1664a84 c169de24 [ 198.720197] 00000000 c165f5ea 000000ff c13fa6b9 00000001 000000ff c1664a84 c169de10 [ 198.720217] c1031f13 00000009 c169de08 c1664a84 c169de24 c169de50 c13fa6b9 c165f5ea [ 198.720240] Call Trace: [ 198.720257] [<c13fa6b9>] ? dev_watchdog+0x229/0x240 [ 198.720274] [<c12208d6>] dump_stack+0x16/0x20 [ 198.720306] [<c1031e4d>] warn_slowpath_common+0x7d/0xa0 [ 198.720318] [<c13fa6b9>] ? dev_watchdog+0x229/0x240 [ 198.720330] [<c1031f13>] warn_slowpath_fmt+0x33/0x40 [ 198.720342] [<c13fa6b9>] dev_watchdog+0x229/0x240 [ 198.720357] [<c103f158>] call_timer_fn+0x78/0x150 [ 198.720369] [<c103f0e0>] ? internal_add_timer+0x40/0x40 [ 198.720381] [<c13fa490>] ? dev_init_scheduler+0xa0/0xa0 [ 198.720392] [<c103f33f>] run_timer_softirq+0x10f/0x200 [ 198.720412] [<c103954f>] ? __do_softirq+0x6f/0x210 [ 198.720424] [<c13fa490>] ? dev_init_scheduler+0xa0/0xa0 [ 198.720435] [<c1039598>] __do_softirq+0xb8/0x210 [ 198.720467] [<c14b54d2>] ? _raw_spin_unlock+0x22/0x30 [ 198.720484] [<c1003245>] ? handle_irq+0x25/0xd0 [ 198.720496] [<c1039c0c>] irq_exit+0x9c/0xb0 [ 198.720508] [<c14bc9d7>] do_IRQ+0x47/0x94 [ 198.720534] [<c1056078>] ? hrtimer_start+0x28/0x30 [ 198.720564] [<c14bc8b1>] common_interrupt+0x31/0x38 [ 198.720589] [<c1008692>] ? default_idle+0x22/0xa0 [ 198.720600] [<c10083c7>] arch_cpu_idle+0x17/0x30 [ 198.720631] [<c106d23d>] cpu_startup_entry+0xcd/0x180 [ 198.720643] [<c14ae30a>] rest_init+0xaa/0xb0 [ 198.720654] [<c14ae260>] ? reciprocal_value+0x50/0x50 [ 198.720668] [<c17044e0>] ? repair_env_string+0x60/0x60 [ 198.720679] [<c1704bda>] start_kernel+0x29a/0x350 [ 198.720690] [<c17044e0>] ? repair_env_string+0x60/0x60 [ 198.720721] [<c1704269>] i386_start_kernel+0x39/0xa0 [ 198.720729] ---[ end trace 81e0a6266f5c73a8 ]--- [ 198.720740] eth0: Transmit timeout, status 00000204 00000000 timer routine checks the link status and if it's up calls netif_carrier_on() allowing upper layer to start the tx queue even if the auto-negotiation process is not finished. Also remove ugly auto-negotiation check from the sis900_start_xmit() CC: Duan Fugang <B38611> CC: Ben Hutchings <bhutchings> Signed-off-by: Denis Kirjanov <kda> Signed-off-by: David S. Miller <davem> The above patch made it in 3.11. Can anyone experiencing this issue test a 3.11 kernel on F19 and confirm? Thanks, Michele
Jim, do you still see this issue with kernels 3.11.x or later? Thanks, Michele
(In reply to Michele Baldessari from comment #9) > Jim, > > do you still see this issue with kernels 3.11.x or later? > > Thanks, > Michele Michele, I did a workaround over a year ago and pretty much forgot about this issue. A month or so ago I did have a possibly related problem with slow eth0 transmit/upload speed. That did not clear up with the kernel update to 3.11.x. At that time I switched to Linux Mint since it did not have the slow upload/transmit issue on eth0 with the SIS hardware. So, I can't give you any information to help check out the fix. Jim
Hi Jim, thanks for the feedback. Note that this sis transmit timeout issue is a kernel issue and unless a distro uses a different kernel version (which carries the fix), the issue will still be there. If anyone else is seeing this please let us know if 3.11 fixes it or not. Thanks, Michele
Hi everyone, I'm running Fedora 20 i686 on my laptop, kernel 3.11.5-200. This kernel version is impacted by this issue. If you need some dump, I can help.