[SOLVED] General Protection Fault on bringing network down

clearloon · 2011-08-21 11:14:23

***Issue resolved on 20111117 by updating to kernel 3.1.1-1***

Apologies if this should be in "Networking" rather than Kernel.

I'm getting a general protection fault every time I take my network down:

Aug 21 12:01:55 localhost kernel: [   42.513387] wlan0: deauthenticating from 00:18:f6:70:64:4e by local choice (reason=3)
Aug 21 12:01:55 localhost kernel: [   42.596692] general protection fault: 0000 [#1] PREEMPT SMP 
Aug 21 12:01:55 localhost kernel: [   42.599996] CPU 1 
Aug 21 12:01:55 localhost kernel: [   42.599996] Modules linked in: nfsd exportfs nfs lockd fscache auth_rpcgss nfs_acl sunrpc cryptd aes_x86_64 aes_generic nouveau ttm drm_kms_helper drm uvcvideo videodev i2c_algo_bit mxm_wmi wmi media video v4l2_compat_ioctl32 nvidia(P) uas usb_storage snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device arc4 snd_hda_codec_realtek rt61pci crc_itu_t rt2x00pci rt2x00lib mac80211 cfg80211 rfkill snd_hda_intel eeprom_93cx6 snd_hda_codec evdev snd_hwdep snd_pcm psmouse snd_timer snd pcspkr serio_raw i2c_piix4 soundcore k10temp snd_page_alloc edac_core edac_mce_amd sp5100_tco sg floppy asus_atk0110 i2c_core button processor fuse usblp ext4 mbcache jbd2 crc16 sr_mod cdrom sd_mod pata_acpi ohci_hcd pata_atiixp ahci ehci_hcd libahci libata scsi_mod usbcore [last unloaded: vboxdrv]
Aug 21 12:01:55 localhost kernel: [   42.599996] 
Aug 21 12:01:55 localhost kernel: [   42.599996] Pid: 1113, comm: wpa_supplicant Tainted: P            3.0-ARCH #1 System manufacturer System Product Name/M3A
Aug 21 12:01:55 localhost kernel: [   42.599996] RIP: 0010:[<ffffffff811f369d>]  [<ffffffff811f369d>] crypto_destroy_tfm+0x1d/0x70
Aug 21 12:01:55 localhost kernel: [   42.599996] RSP: 0018:ffff88021bef17d8  EFLAGS: 00010286
Aug 21 12:01:55 localhost kernel: [   42.599996] RAX: 00000000000fac04 RBX: ffff000000000000 RCX: 0000000000000001
Aug 21 12:01:55 localhost kernel: [   42.599996] RDX: 0000000000000000 RSI: ffff000000000000 RDI: ffff000000000000
Aug 21 12:01:55 localhost kernel: [   42.599996] RBP: ffff88021bef17f8 R08: ffff88022130af9c R09: 0000000000000001
Aug 21 12:01:55 localhost kernel: [   42.599996] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880221a24560
Aug 21 12:01:55 localhost kernel: [   42.599996] R13: ffff88021cd27074 R14: ffff880221ee5740 R15: 0000000000000020
Aug 21 12:01:55 localhost kernel: [   42.599996] FS:  00007f186b94c700(0000) GS:ffff88022fc40000(0000) knlGS:0000000000000000
Aug 21 12:01:55 localhost kernel: [   42.599996] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Aug 21 12:01:55 localhost kernel: [   42.599996] CR2: 00007f186a74270c CR3: 0000000221c10000 CR4: 00000000000006e0
Aug 21 12:01:55 localhost kernel: [   42.599996] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Aug 21 12:01:55 localhost kernel: [   42.599996] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Aug 21 12:01:55 localhost kernel: [   42.599996] Process wpa_supplicant (pid: 1113, threadinfo ffff88021bef0000, task ffff880221b31590)
Aug 21 12:01:55 localhost kernel: [   42.599996] Stack:
Aug 21 12:01:55 localhost kernel: [   42.599996]  ffff880221ee5740 0000000000000020 ffff88022130ae00 ffff880221a24560
Aug 21 12:01:55 localhost kernel: [   42.599996]  ffff88021bef1808 ffffffffa04e07e1 ffff88021bef1828 ffffffffa04eb91c
Aug 21 12:01:55 localhost kernel: [   42.599996]  ffff88022130ae00 ffff88022130ae00 ffff88021bef1848 ffffffffa04ebe32
Aug 21 12:01:55 localhost kernel: [   42.599996] Call Trace:
Aug 21 12:01:55 localhost kernel: [   42.599996]  [<ffffffffa04e07e1>] ieee80211_aes_key_free+0x11/0x20 [mac80211]
Aug 21 12:01:55 localhost kernel: [   42.599996]  [<ffffffffa04eb91c>] __ieee80211_key_destroy+0x5c/0x80 [mac80211]
Aug 21 12:01:55 localhost kernel: [   42.599996]  [<ffffffffa04ebe32>] __ieee80211_key_free+0x42/0x50 [mac80211]
Aug 21 12:01:55 localhost kernel: [   42.599996]  [<ffffffffa04cf708>] __sta_info_destroy+0x128/0x340 [mac80211]
Aug 21 12:01:55 localhost kernel: [   42.599996]  [<ffffffffa04d0371>] sta_info_destroy_addr+0x41/0x70 [mac80211]
Aug 21 12:01:55 localhost kernel: [   42.599996]  [<ffffffffa04dafa7>] ieee80211_mgd_deauth+0x217/0x220 [mac80211]
Aug 21 12:01:55 localhost kernel: [   42.599996]  [<ffffffffa04e173e>] ieee80211_deauth+0x1e/0x20 [mac80211]
Aug 21 12:01:55 localhost kernel: [   42.599996]  [<ffffffffa04bbb1a>] __cfg80211_mlme_deauth+0xea/0x100 [cfg80211]
Aug 21 12:01:55 localhost kernel: [   42.599996]  [<ffffffffa04bbba3>] cfg80211_mlme_deauth+0x73/0xa0 [cfg80211]
Aug 21 12:01:55 localhost kernel: [   42.599996]  [<ffffffffa04b028e>] nl80211_deauthenticate+0xbe/0xf0 [cfg80211]
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff8135cf45>] genl_rcv_msg+0x1d5/0x250
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff8135cd70>] ? genl_rcv+0x40/0x40
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff8135c0f9>] netlink_rcv_skb+0xa9/0xd0
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff813263df>] ? __alloc_skb+0x4f/0x230
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff8135cd55>] genl_rcv+0x25/0x40
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff8135b9d9>] netlink_unicast+0x2d9/0x320
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff8135bdba>] netlink_sendmsg+0x2da/0x370
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff8116a200>] ? __pollwait+0xf0/0xf0
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff8131cc3e>] sock_sendmsg+0x10e/0x130
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff810f78aa>] ? unlock_page+0x2a/0x40
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff8111a619>] ? __do_fault+0x459/0x580
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff8131e321>] ? move_addr_to_kernel+0x51/0x60
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff813299da>] ? verify_iovec+0x4a/0xd0
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff8131e844>] __sys_sendmsg+0x3f4/0x410
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff81082b29>] ? enqueue_hrtimer+0x39/0xf0
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff81221654>] ? timerqueue_del+0x34/0x90
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff810834b6>] ? hrtimer_try_to_cancel+0x96/0x130
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff81061b6e>] ? do_setitimer+0x18e/0x2e0
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff8131f839>] sys_sendmsg+0x49/0x90
Aug 21 12:01:55 localhost kernel: [   42.766675]  [<ffffffff813f4402>] system_call_fastpath+0x16/0x1b
Aug 21 12:01:55 localhost kernel: [   42.766675] Code: df e8 38 f6 ff ff e9 33 ff ff ff 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 5d f0 4c 89 65 f8 66 66 66 66 90 48 85 ff 48 89 fb 74 23 
Aug 21 12:01:55 localhost kernel: [   42.766675] RIP  [<ffffffff811f369d>] crypto_destroy_tfm+0x1d/0x70
Aug 21 12:01:55 localhost kernel: [   42.766675]  RSP <ffff88021bef17d8>
Aug 21 12:01:55 localhost kernel: [   42.767705] ---[ end trace 4cae88dd46c844f1 ]---

This is new behaviour - it started a week or two ago, but it is consistent - I cannot bring down the network without this happening.

I'm really struggling here - I can't find anything on the forum/google that points to a solution.

Any thoughts?

Last edited by clearloon (2011-11-18 10:54:32)

pigiron · 2011-08-24 03:45:50

This part caught my eye:

[last unloaded: vboxdrv]

Disclaimer: I know nothing about VirtualBox... but I did look at the crypto_destroy_tfm() code. It's so simple that something must be trashing the structures that are being passed in.

According to the VirtualBox Arch wiki page, the vboxdrv module needs to be rebuilt on a kernel change. Have you done that?

If the answer is yes, I'd still try an experiment where the vboxdrv module never get's loaded and see what happens.

Last edited by pigiron (2011-08-24 04:06:21)

clearloon · 2011-08-24 16:03:17

Good suggestions pigiron, thanks. No luck though.

Inxsible · 2011-08-24 16:05:37

can you show us your rc.conf ??

clearloon · 2011-08-25 17:11:30

#
# /etc/rc.conf - Main Configuration for Arch Linux
#

# -----------------------------------------------------------------------
# LOCALIZATION
# -----------------------------------------------------------------------
#
# LOCALE: available languages can be listed with the 'locale -a' command
# HARDWARECLOCK: set to "UTC" or "localtime"
# USEDIRECTISA: use direct I/O requests instead of /dev/rtc for hwclock
# TIMEZONE: timezones are found in /usr/share/zoneinfo
# KEYMAP: keymaps are found in /usr/share/kbd/keymaps
# CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US)
# CONSOLEMAP: found in /usr/share/kbd/consoletrans
# USECOLOR: use ANSI color sequences in startup messages
#
LOCALE="en_GB.utf8"
HARDWARECLOCK="UTC"
USEDIRECTISA="no"
TIMEZONE="Europe/London"
KEYMAP="uk"
CONSOLEFONT="default8x16"
CONSOLEMAP=
USECOLOR="yes"

# -----------------------------------------------------------------------
# HARDWARE
# -----------------------------------------------------------------------
#
# MOD_AUTOLOAD: Allow autoloading of modules at boot and when needed
# MOD_BLACKLIST: Prevent udev from loading these modules
# MODULES: Modules to load at boot-up. Prefix with a ! to blacklist.
#
# NOTE: Use of 'MOD_BLACKLIST' is deprecated. Please use ! in the MODULES array.
#
MOD_AUTOLOAD="yes"
MODULES=(usblp fuse)

# Scan for LVM volume groups at startup, required if you use LVM
USELVM="no"

# -----------------------------------------------------------------------
# NETWORKING
# -----------------------------------------------------------------------
#
# HOSTNAME: Hostname of machine. Should also be put in /etc/hosts
#
HOSTNAME="desktop"

# Use 'ifconfig -a' or 'ls /sys/class/net/' to see all available interfaces.
#
# Interfaces to start at boot-up (in this order)
# Declare each interface then list in INTERFACES
#   - prefix an entry in INTERFACES with a ! to disable it
#   - no hyphens in your interface names - Bash doesn't like it
# 
# DHCP:     Set your interface to "dhcp" (eth0="dhcp")
# Wireless: See network profiles below
#

#Static IP example
#eth0="eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255"
wlan0="dhcp"
INTERFACES=(wlan0)

# Routes to start at boot-up (in this order)
# Declare each route then list in ROUTES
#   - prefix an entry in ROUTES with a ! to disable it
#
ROUTES=(!gateway)
 
# Enable these network profiles at boot-up.  These are only useful
# if you happen to need multiple network configurations (ie, laptop users)
#   - set to 'menu' to present a menu during boot-up (dialog package required)
#   - prefix an entry with a ! to disable it
#
# Network profiles are found in /etc/network.d
#
# This now requires the netcfg package
#
NETWORKS=(misonet)

# -----------------------------------------------------------------------
# DAEMONS
# -----------------------------------------------------------------------
#
# Daemons to start at boot-up (in this order)
#   - prefix a daemon with a ! to disable it
#   - prefix a daemon with a @ to start it up in the background
#
DAEMONS=(syslog-ng dbus net-profiles @mysqld @sshd @crond @cupsd @kdm @rtorrent @openntpd rpcbind nfs-common nfs-server @netfs @air-video-server synergys)

clearloon · 2011-09-02 08:10:56

Sorry to bump this but I really could do with some help - I'm at a loss as to what's wrong.

As far as I can tell there's nothing unusual in rc.conf and the right modules are being loaded by udev (rt61pci, which is correct). My system is completely up to date and the network works fine in all other respsects.

Any ideas?

kokoko3k · 2011-09-02 09:37:01

Maybe you can rmmod the wireless network module instead of putting the nic down.
Just a workaround.

Lone_Wolf · 2011-09-02 21:33:18

This may have to do with the recent deprecation of net-tools , check http://www.archlinux.org/news/deprecation-of-net-tools/

you should have a rc.conf.pacnew file, look at it and make the necessary changes.

clearloon · 2011-09-06 08:26:39

@kokoko3k - same problem unfortunately - as soon as I unload the module it hangs.

@Lone_Wolf - an updated rc.conf didn't make any difference unfortunately.

Lone_Wolf · 2011-09-06 14:49:01

could be a problem in the wireless driver.

paste the output of

#lscpi -v

(as root)
that should tell us what wireless chipset and driver you use.

clearloon · 2011-09-06 15:30:10

The relevent bit is:

02:06.0 Network controller: Ralink corp. RT2561/RT61 802.11g PCI
        Subsystem: Ralink corp. EW-7108PCg
        Flags: bus master, slow devsel, latency 64, IRQ 21
        Memory at febf8000 (32-bit, non-prefetchable) [size=32K]
        Capabilities: [40] Power Management version 2
        Kernel driver in use: rt61pci
        Kernel modules: rt61pci

Lone_Wolf · 2011-09-06 15:50:12

https://wiki.archlinux.org/index.php/Wi … bsolete.29

try blacklisting the rt61pci module

clearloon · 2011-09-06 17:35:43

I'd tried that but it doesn't work. udev loads rt2x00pci which seems to include rt61pci - if I blacklist rt61pci then no wireless interface is found. The output of

lsmod | grep rt

when rt2x00pci is loaded is:

exportfs                3663  1 nfsd
rt61pci                21769  0 
crc_itu_t               1297  1 rt61pci
rt2x00pci               4986  1 rt61pci
rt2x00lib              34031  2 rt61pci,rt2x00pci
mac80211              216021  2 rt2x00pci,rt2x00lib
cfg80211              160740  2 rt2x00lib,mac80211
eeprom_93cx6            1344  1 rt61pci

Last edited by clearloon (2011-09-06 17:37:40)

clearloon · 2011-09-11 14:21:14

This is driving me crazy, but I can now replicate it during installation using arch 2011.08.19 - bringing the network up works fine, bringing it down gives me the GPF.

Arch Linux

#1 2011-08-21 11:14:23

[SOLVED] General Protection Fault on bringing network down

#2 2011-08-24 03:45:50

Re: [SOLVED] General Protection Fault on bringing network down

#3 2011-08-24 16:03:17

Re: [SOLVED] General Protection Fault on bringing network down

#4 2011-08-24 16:05:37

Re: [SOLVED] General Protection Fault on bringing network down

#5 2011-08-25 17:11:30

Re: [SOLVED] General Protection Fault on bringing network down

#6 2011-09-02 08:10:56

Re: [SOLVED] General Protection Fault on bringing network down

#7 2011-09-02 09:37:01

Re: [SOLVED] General Protection Fault on bringing network down

#8 2011-09-02 21:33:18

Re: [SOLVED] General Protection Fault on bringing network down

#9 2011-09-06 08:26:39

Re: [SOLVED] General Protection Fault on bringing network down

#10 2011-09-06 14:49:01

Re: [SOLVED] General Protection Fault on bringing network down

#11 2011-09-06 15:30:10

Re: [SOLVED] General Protection Fault on bringing network down

#12 2011-09-06 15:50:12

Re: [SOLVED] General Protection Fault on bringing network down

#13 2011-09-06 17:35:43

Re: [SOLVED] General Protection Fault on bringing network down

#14 2011-09-11 14:21:14

Re: [SOLVED] General Protection Fault on bringing network down

Board footer