headers
Andrey Borzenkov | 1 May 2005 18:15
Picon

[PATCH] usb.rc stop - remove xpad module too

My 2.6.11-8mdk kernel has xpad module that prevents usbcore from being 
unloaded:

{pts/2}% modinfo xpad
filename:       /lib/modules/2.6.11-8mdk/kernel/drivers/usb/input/xpad.ko.gz
author:         Marko Friedemann <mfr <at> bmx-chemnitz.de>, Oliver Schwartz 
<Oliver.Schwartz <at> gmx.de>, Georg Lukas <georg <at> op-co.de>
description:    driver for Xbox controllers with mouse emulation
license:        GPL

here is trivial patch that adds it to module list to remove.

regards

-andrey

--- /home/bor/tmp/usb.rc.xpad   2004-09-21 02:30:35.000000000 +0400
+++ /home/bor/tmp/usb.rc        2005-05-01 20:11:53.000000000 +0400
 <at>  <at>  -305,6 +305,7  <at>  <at>  maybe_stop_usb ()
     rmmod visor            >/dev/null 2>&1
     rmmod wacom            >/dev/null 2>&1
     rmmod whiteheat        >/dev/null 2>&1
+    rmmod xpad             >/dev/null 2>&1

     if [ "$STATIC_MODULE_LIST" != "" ]; then
        rmmod $STATIC_MODULE_LIST >/dev/null 2>&1
Permalink | Reply | 0 comments |
headers
E. Oltmanns | 2 May 2005 15:45
Picon

Re: Once more udev/hotplug and usb-storage devices

Elias Oltmanns <oltmanns <at> uni-bonn.de> wrote:
[...]
> On linux-2.6.11.7 with udev, hotplug, dbus-1 and hald but no X running,
> I plug in my usb stick. If I'm lucky, nothing unexpected happens and I
> can mount /dev/sda1 afterwards. Otherwise, a whole bunch of error
> messages is generated and there is no way to access the media. In
> fact, udev removes the freshly created device nodes even before I
> remove the usb stick. In the latter case, removing and reinserting the
> usb stick resolves the problem. However, a stale scsi_eh_0 process
> remains and cannot be killed but apparently doesn't affect the
> system's stability either. The relevant part of /var/log/syslog is
> attached below.
>
> As the explicit mentioning of scsi_eh_0 suggests, I haven't managed to
> reproduce this problem if the usb stick has been inserted before. In
> fact, I did achieve this but it involved unloading usb_storage, sd_mod
> and scsi_mod so I ended up with a stale scsi_eh_0 again. So far, it
> only appeared when hald wsa running at the time but I didn't try very
> thoroughly without dbus-1 and hald and, as I said before, I can't
> reproduce this problem reliably.

Just for the record:
While I managed to reproduce the described problem on reinsertion of
the usb stick (without unloading the kernel modules first), the whole
problem never appeared when hald wasn't running at the time.
Naturally, I thought that hal was the problem. However, after an
upgrade of udev from 0.050 to 0.056 the problem didn't occur anymore -
even with hald running! Sorry that I didn't think about upgrading
earlier. Hopefully, this really is the reason.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander harsch | 3 May 2005 13:47
Picon
Picon

problem with 3com 3CRWE62092B wlan card (atmel chipset)

Hello developers,

when I plug in my 3com 3CRWE62092B wlan card, I find the logs appended 
in /var/log/messages. Sometimes, the card does not get recognized at all. 
Sometimes, I can work with it without problems. If the card does not get 
recognized during start, it can be used by simpy re-plugging it in. The logs 
say, that you might be interested in this debug messages, so this is why I 
send it to you. If you have any further questions, I will certainly answer 
them if I can.

May  3 13:12:30 nb-harsch cardmgr[7301]: watching 2 sockets
May  3 13:12:30 nb-harsch cs: IO port probe 0xc00-0xcff: clean.
May  3 13:12:30 nb-harsch cs: IO port probe 0xc00-0xcff: clean.
May  3 13:12:30 nb-harsch cs: IO port probe 0x800-0x8ff: clean.
May  3 13:12:30 nb-harsch cs: IO port probe 0x800-0x8ff: clean.
May  3 13:12:30 nb-harsch cs: IO port probe 0x100-0x4ff: excluding 0x158-0x15f 
0x360-0x367 0x4d0-0x4d7
May  3 13:12:30 nb-harsch cs: IO port probe 0x100-0x4ff: excluding 0x158-0x15f 
0x360-0x367 0x4d0-0x4d7
May  3 13:12:30 nb-harsch cs: IO port probe 0xa00-0xaff: clean.
May  3 13:12:30 nb-harsch cs: IO port probe 0xa00-0xaff: clean.
May  3 13:12:30 nb-harsch cardmgr[7301]: starting, version is 3.2.5
May  3 13:12:30 nb-harsch cardmgr[7301]: socket 0: 3Com 3CRWE62092B 11Mbps 
WLAN PC Card
May  3 13:12:31 nb-harsch eth1: MAC address 00:04:75:cc:6a:46
May  3 13:12:31 nb-harsch eth1: Atmel at76c50x wireless. Version 0.96 
simon <at> thekelleys.org.uk
May  3 13:12:31 nb-harsch eth1: 3com 3CRWE62092B index 0x01: Vcc 3.3, irq 3, 
io 0x0100-0x011f
May  3 13:12:31 nb-harsch wait_for_sysfs[7303]: error: unknown bus, please
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kay Sievers | 3 May 2005 20:13

Re: problem with 3com 3CRWE62092B wlan card (atmel chipset)

On Tue, 2005-05-03 at 13:47 +0200, Alexander harsch wrote:
> Hello developers,
> 
> when I plug in my 3com 3CRWE62092B wlan card, I find the logs appended 
> in /var/log/messages. Sometimes, the card does not get recognized at all. 
> Sometimes, I can work with it without problems. If the card does not get 
> recognized during start, it can be used by simpy re-plugging it in. The logs 
> say, that you might be interested in this debug messages, so this is why I 
> send it to you. If you have any further questions, I will certainly answer 
> them if I can.

> May  3 13:12:31 nb-harsch wait_for_sysfs[7303]: error: unknown bus, please 
> report to <linux-hotplug-devel <at> lists.sourceforge.
> net> 'pcmcia'

That must be an ancient version of udev. You may upgrade it to get rid
of this message. But updating udev will not make your card working
better, cause it's more a driver- and not a hotplug issue.

Thanks,
Kay

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
Permalink | Reply | 0 comments |
headers
Erik van Konijnenburg | 4 May 2005 00:32
Picon
Picon
Favicon

[ANNOUNCE] yaird 0.0.6, a mkinitrd based on hotplug concepts

Version 0.0.6 of yaird is now available at:
	http://www.xs4all.nl/~ekonijn/yaird/yaird-0.0.6.tar.gz

Yaird is a proof of concept perl rewrite of mkinitrd.  It aims to
reliably identify the necessary modules by using the same algorithms
as hotplug, and comes with a template system to to tune the tool for
different distributions and experiment with different image layouts.
It requires a 2.6 kernel with hotplug.  There is a paper discussing it at:

	http://www.xs4all.nl/~ekonijn/yaird/yaird.html

Summary of user visible changes for version 0.0.6
     * Support cryptsetup.  See the README file, see HTML documentation.
     * Support aliases and options in modprobe.conf,
       simply by using modprobe rather than doing a reimplementation in perl.
     * tested with ulibc
     * Bugfixes:
       - failure to generate image on systems without LVM
       - overcrowded /dev under Debian with udev
       - failure to generate image if multiple links to same raid device exist
       - uninitialised value in verbose output

On top of the todo list are now:
     * support NFS devices
     * support cryptsetup-luks
     * support loopback devices

Regards,
Erik
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Castellotti | 4 May 2005 06:43

Simple Newbie question

hey all-

    I recently came across a USB touchscreen I'm trying to get to work
under linux. If I plug it in under windows it registers as an HID-
compliant device, and starts working with no additional drivers, so I
don't believe this should be very difficult. (I'm running Fedora Core 3
with linux kernel2.6.10-1.770_14.rhfc3.at incidentally)

    By diffing changes to /proc/bus/usb/devices, I've gotten a the info:

P:  Vendor=0000 ProdID=ffff Rev= 1.00

    which I've confirmed is the correct device.

I've then edited /etc/hotplug/usb.usermap and added the following lines:

usbhid             0x0000 0x0000   0xffff    0x0000       0x0000
0x00   0x00            0x00            0x00            0x00
0x00       0x00000000
keybdev            0x0000 0x0000   0xffff    0x0000       0x0000
0x00   0x00            0x00            0x00            0x00
0x00       0x00000000
mousedev           0x0000 0x0000   0xffff    0x0000       0x0000
0x00   0x00            0x00            0x00            0x00
0x00       0x00000000

    (The device appears three times in /var/log/messages, as a "USB HID
v1.00 Mouse" a "USB HID v1.00 Device" and a "USB HID v1.00 Keyboard" but
of course I'm only interested in the mouse functionality)
(Continue reading)

Permalink | Reply | 5 comments |
headers
Greg KH | 4 May 2005 07:16
Gravatar

Re: Simple Newbie question

On Wed, May 04, 2005 at 04:43:42PM +1200, Steve Castellotti wrote:
> hey all-
> 
>     I recently came across a USB touchscreen I'm trying to get to work
> under linux. If I plug it in under windows it registers as an HID-
> compliant device, and starts working with no additional drivers, so I
> don't believe this should be very difficult. (I'm running Fedora Core 3
> with linux kernel2.6.10-1.770_14.rhfc3.at incidentally)
> 
> 
>     By diffing changes to /proc/bus/usb/devices, I've gotten a the info:
> 
> P:  Vendor=0000 ProdID=ffff Rev= 1.00
> 
>     which I've confirmed is the correct device.
> 
> 
> 
> I've then edited /etc/hotplug/usb.usermap and added the following lines:
> 
> usbhid             0x0000 0x0000   0xffff    0x0000       0x0000
> 0x00   0x00            0x00            0x00            0x00
> 0x00       0x00000000
> keybdev            0x0000 0x0000   0xffff    0x0000       0x0000
> 0x00   0x00            0x00            0x00            0x00
> 0x00       0x00000000
> mousedev           0x0000 0x0000   0xffff    0x0000       0x0000
> 0x00   0x00            0x00            0x00            0x00
> 0x00       0x00000000
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Roman Kagan | 4 May 2005 09:05
Picon

Re: usb-storage bug in 2.6.12-rc3

On Fri, Apr 29, 2005 at 12:28:30PM -0700, David Brownell wrote:
> On Friday 29 April 2005 11:23 am, Roman Kagan wrote:
> > 
> > ... instead of trying to make sure the attributes are available via
> > sysfs at hotplug time, we can use another means to pass them to hotplug:
> > we can add a routine, which, when called from the .hotplug function
> > and given pointers to struct attribute and struct device, would add
> > environment variable
> > 
> > SYSFS_attrName=attrValue
> 
> Color me amused.  That was the original way to pass information
> to hotplug agents ... back then (2.4.0.test10 or so), there was
> usually no other way to export the relevant data.
> 
> I'd rather just guarantee that the sysfs device were fully
> constructed (attributes and all) before the driver binding and
> hotplug stages of enumeration started.

I must have been unclear in what I was proposing.

I don't suggest to use the technique of 2.4 age to create a set of
environment variables in each .hotplug method, not related to the sysfs
attributes, like usb $PRODUCT, $TYPE, $INTERFACE which are quite
different from the names in sysfs, although they are supposed to convey
the same information.

Rather, _in_addition_ to exporting the attribute values in
sysfs_dir/attrName, one can export (a subset of) them as SYSFS_attrName
environment variables, using _sysfs_ facilities - .show methods - to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christoph Pleger | 4 May 2005 09:46
Picon
Picon

Problems with udev

Hello,

I have two problems with udev:

1. When I use /dev as the root directory for udev, udev does not create
the device nodes for my serial interfaces (/dev/ttyS0 etc.) although the
necessary modules for serial device support are loaded. That prevented a
program that I use to autodetect connected mouse devices from
autodetecting a serial mouse.

2. To solve the problem mentioned above, I now use /udev as the root
directory for udev. When I now connect a USB stick to the computer, udev
does not create the device nodes for the stick (/udev/uba etc.)

Does anybody know how to solve these problems?

I am using Debian sarge with Kernel 2.6.11.8 and udev 056.

Kind regards
  Christoph

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
Permalink | Reply | 0 comments |
headers
Layne Garrett Pedersen | 4 May 2005 19:30

(no subject)

Can you give me more information on the following error?

"
io wait_for_sysfs[5797]: either wait_for_sysfs (udev 039) needs
an update to handle the device '/class/scsi_device' properly (no device 
symlink) or the sysfs-support of your device's driver needs to be fixed, 
please report to <linux-hotplug-devel <at> lists.sourceforge.net>
"

best regards,

Layne Pedersen

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
Permalink | Reply | 1 comment |

Gmane