[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#392261: marked as done (pcmciautils: ..i82365 is 'modprobe && modprobed -r'ed in a rah-rah-rah style loop, was first reported on udev as bug#391832)

Your message dated Tue, 28 Jul 2009 19:17:47 +0200
with message-id <20090728171747.GA29433@galadriel.inutil.org>
and subject line Re: Bug#392261: pcmciautils: ..i82365 is 'modprobe && modprobed -r'ed in a rah-rah-rah style loop, was first reported on udev as bug#391832
has caused the Debian Bug report #392261,
regarding pcmciautils: ..i82365 is 'modprobe && modprobed -r'ed in a rah-rah-rah style loop, was first reported on udev as bug#391832
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
392261: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392261
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: pcmciautils
Version: 014-2
Severity: normal


....wee udevmonitor output snippet:
 UDEV  [1160337418.883552] add@/module/i82365
 UDEV  [1160337418.925886] add@/bus/platform/drivers/i82365
 UDEV  [1160337418.952325] add@/devices/platform/i82365.0
 UEVENT[1160337419.012676] add@/module/i82365
 UEVENT[1160337419.012795] add@/bus/platform/drivers/i82365
 UEVENT[1160337419.012859] add@/devices/platform/i82365.0
 UEVENT[1160337419.012919] remove@/devices/platform/i82365.0
 UEVENT[1160337419.012979] remove@/bus/platform/drivers/i82365
 UDEV  [1160337419.033612] remove@/bus/platform/drivers/i82365
 UEVENT[1160337419.037723] remove@/module/i82365
 UDEV  [1160337419.155955] remove@/module/i82365
 UDEV  [1160337419.181726] remove@/devices/platform/i82365.0
....etc loops, eating all the omph.  Desktop, no pcmcia gear.

...so, Marco adviced udev don't do removal and closed Bug#391832,
asking me to instead put blame here on pcmciautils ;o) to help 
track down this. 

...I also have these ref debs, as my 5 aoulde IBM tp 760ED's are a bit over the hill:
arnt@a45:/var/www/dropzone $ dpkg -l |grep pcmcia
ii  kernel-pcmcia-modules-2.4.27-2-k6 2.4.27-12  Mainstream PCMCIA modules 2.4.27 on AMD K6/K
ii  pcmcia-cs                         3.2.8-8    PCMCIA Card Services for Linux (deprecated)
ii  pcmcia-source                     3.2.8-8    Old PCMCIA kernel modules source
ii  pcmciautils                       014-2      PCMCIA utilities for Linux 2.6



-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i586)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-486
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages pcmciautils depends on:
ii  libc6                        2.3.6.ds1-6 GNU C Library: Shared libraries
ii  libsysfs2                    2.0.0-7     interface library to sysfs
ii  lsb-base                     3.1-17      Linux Standard Base 3.1 init scrip
ii  module-init-tools            3.2.2-3     tools for managing Linux kernel mo

Versions of packages pcmciautils recommends:
ii  udev                          0.100-2    /dev/ and hotplug management daemo

-- no debconf information

--- End Message ---
--- Begin Message --- 
On Wed, Oct 11, 2006 at 03:15:42PM +0200, Arnt Karlsen wrote:
> On Wed, 11 Oct 2006 08:50:10 +0100, Colin wrote in message 
> <20061011075010.GG19827@riva.ucam.org>:
> 
> > reassign 392261 linux-2.6 
> 
> ..ok?  This couldn't be a case of stuff "waging war" in my box? 
> I stuff in debs here to read the docs and help spot conflicts and 
> make sure FlightGear still run flyable on this low end box. 
> 
> > thanks
> > 
> > On Wed, Oct 11, 2006 at 12:47:33AM +0200, Arnt Karlsen wrote:
> > > ....wee udevmonitor output snippet:
> > >  UDEV  [1160337418.883552] add@/module/i82365
> > >  UDEV  [1160337418.925886] add@/bus/platform/drivers/i82365
> > >  UDEV  [1160337418.952325] add@/devices/platform/i82365.0
> > >  UEVENT[1160337419.012676] add@/module/i82365
> > >  UEVENT[1160337419.012795] add@/bus/platform/drivers/i82365
> > >  UEVENT[1160337419.012859] add@/devices/platform/i82365.0
> > >  UEVENT[1160337419.012919] remove@/devices/platform/i82365.0
> > >  UEVENT[1160337419.012979] remove@/bus/platform/drivers/i82365
> > >  UDEV  [1160337419.033612] remove@/bus/platform/drivers/i82365
> > >  UEVENT[1160337419.037723] remove@/module/i82365
> > >  UDEV  [1160337419.155955] remove@/module/i82365
> > >  UDEV  [1160337419.181726] remove@/devices/platform/i82365.0
> > > ....etc loops, eating all the omph.  Desktop, no pcmcia gear.
> > > 
> > > ...so, Marco adviced udev don't do removal and closed Bug#391832,
> > > asking me to instead put blame here on pcmciautils ;o) to help 
> > > track down this. 
> > 
> > Well, pcmciautils doesn't remove modules either. It does modprobe
> > i82365 if configured to do so (/etc/default/pcmciautils), but not
> > obviously in a loop. I can only conclude that this is a kernel bug of
> > some kind that happens when the i82365 driver fails to load. Could you
> > provide the output of 'uname -a' and 'dmesg'?
> 
> ..arnt@a45:~ $ uname -a
> Linux a45 2.6.18-1-486 #1 Fri Sep 29 15:40:22 UTC 2006 i586 GNU/Linux
> 
> ..this is an AMD k6-2 cpu, though.  
> arnt@a45:~ $ dmesg 
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> pci_set_power_state(): 0000:00:09.0: state=3, current state=5
> 
> ...etc, arnt@a45:~ $ dmesg |wc -l
> 253
> of it, so there goes my uptime again, will post dmesg after my next
> reboot.

Since this bug is very old, I suppose this is fixed in the mean
time in Lenny or later kernels?

Cheers,
         Moritz

--- End Message ---
Reply to: