Re: Random crashes that won't allow rebooting easily
On Fri, Apr 19, 2013 at 02:32:08PM +0100, Bill Harris wrote:
> Bill Harris <email@example.com> writes:
> > Thanks for your quick response. The laptop is currently crashed, and so
> > I'll check logs and more later. I discovered uprecords a while back, and
> I booted into W7 and launched IE last night, and then I shut down again.
> Then I booted Debian. This time it worked, but I have no reason to
> believe that following those steps is anything more than superstition.
If you have no reason to believe it, then you shouldn't :-)
> Before that, I had tried a reboot into Debian recovery mode, and I
> continued on rather than entering a root password for maintenance.
> Somewhere in there it crashed with a log file on the screen. I don't
> know for sure what log file that was nor whether it wrote it to disk,
> but I found similar messages in 'messages' from the day before when I
> was trying to boot when I rebooted last night.
> Here is a section from 'messages' (one of several) where it said "cut
> here" (I presume that's important :-) ):
> Apr 17 20:08:13 marbach kernel: [76743.293881] ------------[ cut here ]------------
> Apr 17 20:08:13 marbach kernel: [76743.293916] WARNING: at /build/buildd-linux-2.6_2.6.32-48squeeze1-amd64-qu4MIV/linux-2.6-2.6.32/debian/build/source_amd64_none/net/mac80211/tx.c:1330 ieee80211_tx+0x1ad/0x1d3 [mac80211]()
> Apr 17 20:08:13 marbach kernel: [76743.293922] Hardware name: HP Pavilion dv7 Notebook PC
> Apr 17 20:08:13 marbach kernel: [76743.293924] tx refused but queue active
> Apr 17 20:08:13 marbach kernel: [76743.293927] Modules linked in: nls_utf8 nls_cp437 vfat fat usb_storage xt_limit xt_tcpudp ipt_LOG ipt_MASQUERADE xt_DSCP ipt_REJECT nf_conntrack_irc nf_conntrack_ftp xt_state aes_x86_64 aes_generic usbhid hid parport_pc ppdev lp parport sco bridge stp bnep l2cap bluetooth acpi_cpufreq cpufreq_userspace cpufreq_stats cpufreq_conservative cpufreq_powersave nfsd lockd nfs_acl auth_rpcgss binfmt_misc sunrpc exportfs uinput fuse iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables x_tables ext4 jbd2 crc16 loop snd_hda_codec_atihdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq arc4 ecb uvcvideo snd_timer radeon snd_seq_device i915 joydev videodev ttm brcm80211(C) snd v4l1_compat drm_kms_helper mac80211 v4l2_compat_ioctl32 hp_accel psmouse soundcore drm lis3lv02d i2c_i801 cfg80211 i2c_algo_bit input_polldev i2c_core video snd_page_alloc wmi output rfkill pcspkr evdev led_class serio_raw battery ac processor
> Apr 17 20:08:13 marbach kernel: button ext3 jbd mbcache sg sr_mod sd_mod crc_t10dif cdrom ahci ehci_hcd libata usbcore nls_base scsi_mod r8169 mii thermal thermal_sys [last unloaded: scsi_wait_scan]
> Apr 17 20:08:13 marbach kernel: [76743.294040] Pid: 0, comm: swapper Tainted: G C 2.6.32-5-amd64 #1
> Apr 17 20:08:13 marbach kernel: [76743.294044] Call Trace:
> Apr 17 20:08:13 marbach kernel: [76743.294046] <IRQ> [<ffffffffa021771d>] ? ieee80211_tx+0x1ad/0x1d3 [mac80211]
This looks related to wireless.... Fun with the wireless driver perhaps?
Perhaps a sensible experiment is to run it with the wireless radio
disabled? (most laptops have a physical switch).
> Does that mean anything related to an inability to boot?
That is quite plausible - things crashing in the kernel is usually bad .
Karl E. Jorgensen