Bug 35972 - vt6656_stage - bringing network interface up results in kernel panic on x86_64
Summary: vt6656_stage - bringing network interface up results in kernel panic on x86_64
Status: RESOLVED OBSOLETE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Staging (show other bugs)
Hardware: All Linux
: P1 high
Assignee: drivers_staging@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-27 10:10 UTC by chakay
Modified: 2012-08-24 12:42 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.38
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description chakay 2011-05-27 10:10:40 UTC
Description:
A kernel panic occurs if I try to bring the wlan interface up. This problem only exits on x86_64.

Steps to reproduce:
modprobe vt6656_stage
ifconfig eth1 up

Additional info:
$ dmesg
vt6656_stage: module is from the staging directory, the quality is unknown, you have been warned.
VIA Networking Wireless LAN USB Driver 1.19_12
VIA Networking Wireless LAN USB Driver Ver. 1.19_12
Copyright (c) 2004 VIA Networking Technologies, Inc.
usb 2-3: reset high speed USB device using ehci_hcd and address 3
usbcore: registered new interface driver vt6656
Config_FileOperation file Not exist
Zone=[2][E][U]!!
BUG: unable to handle kernel paging request at ffff88017ce9d3f1
IP: [<ffffffffa03c3586>] RFbSetPower+0x46/0xa0 [vt6656_stage]
PGD 1694063 PUD 0
Oops: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/platform/coretemp.1/temp1_crit
CPU 1
Modules linked in: [<ffffffff810683c9>] ? run_timer_softirq+0x129/0x440
[<ffffffffa03abdb0>] ? vRunCommand+0x0/0x11a0 [vt6656_stage]
[<ffffffff810898d8>] ? tick_dev_program_event+0x48/0x110
[<ffffffff8105ff88>] ? __do_softirq+0xa8/0x280
[<ffffffff8100bd1c>] ? call_softirq+0x1c/0x30
<EOI> [<ffffffff8100df45>] ? do_softirq+0x65/0xa0
[<ffffffff8105ec77>] ? local_bh_enable_ip+0xa7/0xb0
[<ffffffff813b3b0f>] ? _raw_spin_unlock_bh+0x1f/0x30
[<ffffffff813023f2>] ? dev_set_rx_mode+0x32/0x40
[<ffffffff8130249f>] ? __dev_open+0x9f/0xd0
[<ffffffff8130271c>] ? __dev_change_flags+0x9c/0x180
[<ffffffff813028b3>] ? dev_change_flags+0x23/0x70
[<ffffffff8135f7bb>] ? devinet_ioctl+0x60b/0x710
[<ffffffff81360675>] ? inet_ioctl+0x75/0x90
[<ffffffff812e8e2b>] ? sock_do_ioctl+0x2b/0x70
[<ffffffff812e9108>] ? sock_ioctl+0x68/0x2b0
[<ffffffff81150d7d>] ? do_vfs_ioctl+0x8d/0x520
[<ffffffff810bbdd0>] ? call_rcu+0x10/0x20
[<ffffffff81080d37>] ? __put_cred+0x37/0x40
[<ffffffff811512a1>] ? sys_ioctl+0x91/0xa0
[<ffffffff8100ae12>] ? system_call_fastpath+0x16/0x1b
Comment 1 guelleheiner 2011-06-27 22:41:21 UTC
I can confirm the very same panic.
Comment 2 Alan 2012-08-24 12:42:23 UTC
If this is still seen with modern kernels please re-open/update

Note You need to log in before you can comment on or make changes to this bug.