|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
|
December 2006 | LG #133
USB generally tends to be a trouble-free area of Linux: most modern distros handle it very well, and the degree to which it's become automated is very impressive (kudos to all the people involved - especially from those of us who remember the early days!) However, when it does break, troubleshooting can be rather difficult: there are a number of pieces that all have to work together. Even more problematic, which pieces have to work in what situation varies... and not all of these have 'usb' in the name.
With that in mind, let's take a look at what happens in some USB-related situations - including how the individual pieces break, and what can be done about them in the rare case when they do.
Inserting a USB pen-drive
So, what actually happens when we grab one of those ubiquitous pen-drive gadgets and insert it into a USB port? Let's watch the log (by running 'tail -f /var/log/messages') as we plug in and find out.
Sep 17 19:58:47 Fenrir kernel: usb 4-1: new high speed USB device using ehci_hcd and address 3 Sep 17 19:58:47 Fenrir kernel: usb 4-1: Product: Geek Squad Sep 17 19:58:47 Fenrir kernel: usb 4-1: Manufacturer: SanDisk Corporation Sep 17 19:58:47 Fenrir kernel: usb 4-1: SerialNumber: SNDK14050503CBF08502 Sep 17 19:58:47 Fenrir kernel: usb 4-1: configuration #1 chosen from 1 choice Sep 17 19:58:47 Fenrir kernel: scsi1 : SCSI emulation for USB Mass Storage devices Sep 17 19:58:47 Fenrir usb.agent[4021]: usb-storage: already loaded Sep 17 19:58:52 Fenrir kernel: Vendor: Model: Geek Squad Rev: 0.2 Sep 17 19:58:52 Fenrir kernel: Type: Direct-Access ANSI SCSI revision: 02 Sep 17 19:58:52 Fenrir kernel: SCSI device sda: 2001888 512-byte hdwr sectors (1025 MB) Sep 17 19:58:52 Fenrir kernel: sda: Write Protect is off Sep 17 19:58:52 Fenrir kernel: SCSI device sda: 2001888 512-byte hdwr sectors (1025 MB) Sep 17 19:58:52 Fenrir kernel: sda: Write Protect is off Sep 17 19:58:52 Fenrir kernel: sda:<7>usb-storage: queuecommand called Sep 17 19:58:52 Fenrir kernel: sda1 Sep 17 19:58:52 Fenrir kernel: sd 1:0:0:0: Attached scsi removable disk sda Sep 17 19:58:53 Fenrir scsi.agent[4058]: sd_mod: loaded successfully (for disk)That's a lot of info... fortunately, it's mostly self-explanatory.
The fact may not be all that clearly visible here, since it's all lumped under "kernel:" messages, but - the 'hotplug' system detected a change on one of the ports that it was watching. After the initial handshake, which gave it a bunch of data, it assigned address '3' to the device (these device numbers are sequential: the last USB device I used, which just happened to be the same pen-drive, got a '2'.) It then logged a bunch of human-readable data telling me what the device reported itself to be, loaded any required modules that had not yet been loaded, and attached the device via the appropriate driver (i.e., created an access point for it in the file system) to a "special" file in the "/dev" directory, at "/dev/sda1". This, in turn, allows us to mount the device on a directory in our file system in the usual way.
Famous Last Words ("What Could Possibly Go Wrong?")
If the "hotplug" system doesn't work, the game is over before it even starts: no detection means no device identification means no module loading means no driver installation means no mounting. End of game, thank you for playing. So, what can we do if there are no messages whatsoever in the log no matter how frantically we fiddle and frob the USB dongle?
First, check to see that "hotplug" is installed on your system. In Debian, for example, the package system is easily queried:
ben@Fenrir:~$ dpkg -l hotplug Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==========================-==========================-===================== ii hotplug 0.0.20040329-25 Linux Hotplug ScriptsIn this case, "hotplug" is fully installed. The next question is, has hotplug support been compiled into the kernel?
ben@Fenrir:~$ ls -l /proc/sys/kernel/hotplug -rw-r--r-- 1 root root 0 2006-09-17 20:32 /proc/sys/kernel/hotplugYep, the entry for it exists in "/proc". Next, is it running? Well... the problem is that 'hotplug' doesn't really have a daemon in the classic sense - it's integrated into the driver core in the kernel - so there's nothing to check for in the process table. What to do, what to do... oh, it's simple - we'll just start the system manually, no harm in that.
ben@Fenrir:~$ su -c '/etc/init.d/hotplug start' Password: Starting hotplug subsystem: pci intel-agp: already loaded uhci-hcd: loaded successfully uhci-hcd: already loaded uhci-hcd: already loaded ehci-hcd: loaded successfully snd-intel8x0: already loaded ignoring pci display device 01:00.0 b44: already loaded ipw2200: already loaded yenta_socket: already loaded ohci-hcd: loaded successfully ohci-hcd: already loaded pci [success] usb usb-storage: already loaded cdc-acm: already loaded usb [success] isapnp isapnp [success] ide ide [success] input input [success] scsi sd_mod: loaded successfully (for disk) scsi [success] done.Your list of modules will almost certainly be different; the important thing is that you see a list of modules loading under the 'pci', 'usb', and [possibly, depending on what you've compiled in your kernel] 'scsi' subheadings.At this point, your basic hotplug system should be OK.
USBFS
Something that comes in very useful when troubleshooting USB is the 'usbfs' virtual file system. To get access to it, compile this option into the kernel (CONFIG_USB_DEVICEFS=y) and list it in '/etc/fstab' (the relevant line reads "none /proc/bus/usb usbfs noauto 0 0", and it is loaded by the kernel when the USB subsystem is detected.) The result is a series of entries (directories) in "/proc/bus/usb", one for each detected device plus a "devices" file containing human-readable descriptions. With this, it's very easy to tell if your system recognizes a given USB device or not - and if you end up with some truly strange USB device that isn't listed in the hotplug system's device database, you can even create your own usermap for it in "/etc/hotplug/usb/" (the necessary 'match_flags', 'idVendor', and 'idProduct' information is shown in the "devices" file.) What more could you possibly want?
Modules
So, we've detected the device and identified it... but let's say that there's still no joy in Mudville. In the most common scenario, the log would look something like this:
Sep 17 19:43:08 Fenrir kernel: usb 4-1: new high speed USB device using ehci_hcd and address 2 Sep 17 19:43:08 Fenrir kernel: usb 4-1: Product: Geek Squad Sep 17 19:43:08 Fenrir kernel: usb 4-1: Manufacturer: SanDisk Corporation Sep 17 19:43:08 Fenrir kernel: usb 4-1: SerialNumber: SNDK14050503CBF08502 Sep 17 19:43:08 Fenrir kernel: usb 4-1: configuration #1 chosen from 1 choice Sep 17 19:43:08 Fenrir kernel: scsi0 : SCSI emulation for USB Mass Storage devices Sep 17 19:43:09 Fenrir usb.agent[3687]: usb-storage: already loaded Sep 17 19:43:13 Fenrir kernel: Vendor: Model: Geek Squad Rev: 0.2 Sep 17 19:43:13 Fenrir kernel: Type: Direct-Access ANSI SCSI revision: 02 Sep 17 19:43:13 Fenrir scsi.agent[3730]: sd_mod: can't be loaded (for disk)Whoops! What do you mean, "can't be loaded"? Oh, right, right... there's still the small matter of having the appropriate module. USB is only the interface method; at the end of all that connecting, the important bit is what device we're connecting TO. In the case of the pen-drive, it's fairly common to have it show up as "/dev/sda1" or "/dev/sdb1" (or, less commonly, "/dev/sda") - in any case, it looks like a SCSI device, which means that we need to have SCSI support (and specifically SCSI disk support) in the kernel. It's preferable to have the latter compiled as a module, so the relevant kernel options look like this:
# SCSI device support # CONFIG_SCSI=y ... # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=mThe above is, of course, highly variable and dependent on the device you're inserting.
And Then What?
Assuming that you have your "/etc/fstab" properly configured - i.e., you have entries that look something like this:
ben@Fenrir:~$ grep sd /etc/fstab /dev/sda /mnt/sda vfat user,noauto,gid=103,rw,fmask=113 0 0 /dev/sda1 /mnt/sda1 vfat user,noauto,gid=103,rw,fmask=113 0 0 /dev/sdb /mnt/sdb vfat user,noauto,gid=103,rw,fmask=113 0 0 /dev/sdb1 /mnt/sdb1 vfat user,noauto,gid=103,rw,fmask=113 0 0 /dev/sdc /mnt/sdc vfat user,noauto,gid=103,rw,fmask=113 0 0- the rest is very simple:
ben@Fenrir:~$ mount /mnt/sda1 ben@Fenrir:~$ mount|grep sda1 /dev/sda1 on /mnt/sda1 type vfat (rw,noexec,nosuid,nodev,gid=103,fmask=113,user=ben)Wrap-up
As I mentioned originally, the USB subsystem in Linux is well-configured and as automatic as anything related to computers can hope to be; usually, it's no trouble at all. However, for those few times when it doesn't behave quite right, I hope I've given you some good tools for getting it back in shape. Good luck!
--
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
[Kapil Hari Paranjape] Hello,
On Sun, 17 Sep 2006, Benjamin A. Okopnik wrote: > > The Monthly Troubleshooter: The USB SubsystemIn this context you might find the following post interesting.
http://www.infodrom.org/~joey/log/?200609102259
The rest is out-of-band for the USB subsystem.Of course, the question does arise: How will people learn about GNU and Linux once everything starts working smoothly? I can certainly vouch for the fact that many of the things I learnt about computers, I learnt because the computer was not doing things the way I wanted it to.
From Personal Experience: There are two types of mathematics books. There are those where the author has taken great pains to construct the most illuminating exercises for the student to solve at the end of each chapter. ... And then there are the books where there are mistakes in the text.[Thomas Adam]
Kapil Hari Paranjape <kapil at imsc.res.in> wrote: > > Of course, the question does arise: How will people learn about > GNU and Linux once everything starts working smoothly? I can > certainly vouch for the fact that many of the things I learnt about > computers, I learnt because the computer was not doing things the > way I wanted it to.They don't need to worry about that anymore. With the use of GNOME and KDE, all of those worries are hidden behind flashy buttons and dialogue windows.
[Ben Okopnik]
Kapil Hari Paranjape wrote: > > Of course, the question does arise: How will people learn about > GNU and Linux once everything starts working smoothly?Well... as reliable and tough as Linux software tends to be (after it's had all the bugs beaten out of it by insane^Whyper-focused^Wdetermined users, it doesn't dare do anything else), there are still hardware failures, new or odd peripherals [1], strange USB configurations, and experimentation. The thing that I appreciate about the 'hotplug' system in this regard is how open (whodathunk it?) the system is to hacking in new bits - that's a good piece of design, especially considering how byzantine the ins and outs of that system used to be. A kernel-based driver with a shell-script "interface" is a very cool idea.
[1] The first portable MP3 player I had was a Samsung Yepp - an odd gadget that looked like a flattened egg and could store something like 32MB. Someone had written a piece of software that would perform the necessary functions for it, but getting it connected to my machine so that the software could read it was quite the fraught process. I ended up studying the 'hotplug' system (mostly by reading the scripts in '/etc/hotplug'), and writing a usermap and a connector script for it, both of which went into '/etc/hotplug/usb':
(yepp.usermap)
# usb module match_flags idVendor idProduct bcdDevice_lo bcdDevice_hi bDeviceClass bDeviceSubClass bDeviceProtocol bInterfaceClass bInterfaceSubClass bInterfaceProtocol driver_info yepp 0x0003 0x04e8 0x5a03 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000(yepp)
#!/bin/sh . /etc/hotplug/hotplug.functions mesg setting permissions of $DEVICE chgrp staff $DEVICE chmod g+w $DEVICEThe info for the usermap came from the USBFS device descriptions, as I mentioned in the article. From then on, all I ever had to do was plug the Yepp's cable into a USB port and fire up the software.
> I can > certainly vouch for the fact that many of the things I learnt about > computers, I learnt because the computer was not doing things the > way I wanted it to.[nod] That's exactly what I'm trying to replicate in the Monthly Troubleshooter series - the (fortunately) rare bits of experience that I hope our readers will never run into, but will now have some clues on handling if they ever do.
I'm also hoping that our readers who have successfully dealt with problems in the various Linux subsystems, especially if it's happened more than once (I am, of course, including everyone on this list) will write us at [email protected] and tell us about their solutions - preferably including the words "Monthly Troubleshooter:" in the subject. I really liked the discussion that happened around the printer topic because other people had included their experiences; as a result, I think that a lot of people will benefit from that one.
> From Personal Experience: > > There are two types of mathematics books. > > There are those where the author has taken great pains to > construct the most illuminating exercises for the student > to solve at the end of each chapter. > > ... And then there are the books where there are mistakes > in the text.
[chuckle] Both types can be very educational, although in somewhat different ways; the second type may require a brick wall and a strong forehead. On the other hand, it does have the benefit (which the first type lacks) of instilling the idea of checking everything - and that even the reference material could be wrong, which is a lesson that can come at a high cost if not learned early on.
http://www.readbookonline.net/readOnLine/2437/[Martin Hooper]
On 20/09/2006 Benjamin A. Okopnik wrote: > > http://www.readbookonline.net/readOnLine/2437/I don't know if anyone else is using Firefox to view that page but it doesn't work.
I'm guessing that if I use IE then it would...
[Ben Okopnik]
Martin Hooper wrote: > On 20/09/2006 Benjamin A. Okopnik wrote: > > > http://www.readbookonline.net/readOnLine/2437/ > > I don't know if anyone else is using Firefox to view that page > but it doesn't work.Works fine in Mozilla, Firefox, dillo, w3m, and Lynx.
ben@Fenrir:~$ mozilla-suite -v Mozilla 1.7.13, Copyright (c) 2003-2004 mozilla.org, build 2006080919 ben@Fenrir:~$ firefox -v Mozilla Firefox 1.5.0.6, Copyright (c) 1998 - 2006 mozilla.org ben@Fenrir:~$ dillo -v Dillo 0.8.5-i18n-misc> I'm guessing that if I use IE then it would...Have you tried scrolling down? The text doesn't start until well down the page.
[Martin Hooper]
Benjamin A. Okopnik wrote: > Have you tried scrolling down? The text doesn't start until well down > the page.Ah yes - Got there now!! Just that there's a lot of white space between the top of the page and the content.. ;)
[Ben Okopnik]
On Wed, Sep 20, 2006 at 01:41:27PM +0100, Thomas Adam wrote: > Kapil Hari Paranjape <kapil at imsc.res.in> wrote: > > > > Of course, the question does arise: How will people learn about > > GNU and Linux once everything starts working smoothly? I can > > certainly vouch for the fact that many of the things I learnt about > > computers, I learnt because the computer was not doing things the > > way I wanted it to. > > They don't need to worry about that anymore. With the use of GNOME and > KDE, all of those worries are hidden behind flashy buttons and dialogue > windows.Wind0ws? Did somebody just mention Wind0ws?
In my opinion, KDE and Gnome are very nice tools... but the intended use for those tools has nothing to do with administering or maintaining Linux. It has to do with easing people from the Wind0ws world past the oh-so-terrifying idea that another OS will slit their throats, rape their Chihuahuas, and run away to Monaco with their money - and into using the same applications in pretty much the same way as they always have, marketing hype to the contrary notwithstanding.
It's possible to debate the long-term usefulness of this approach. I, for example, have strong reservations about it maintaining the irresponsible mindset that is trained into many Wind0ws users by the shiny, glitzy interface ("just put gas into it, and leave Complicated Stuff like checking the oil to the professional mechanics!") - this is what allows viruses, etc. to propagate - but there are many people whose only reason for switching to Linux was the ability to "keep doing the same thing as before". Perhaps the question is, would it be better to have a huge slew of ignorant users on vulnerability-riddled platforms, or to have them using an OS which is well-designed and stable? The concerns and the answers regarding the uses of KDE, etc. are not mutually exclusive, but rather orthogonal.
[Thomas Adam]
"Benjamin A. Okopnik" <ben at linuxgazette.net> wrote: > In my opinion, KDE and Gnome are very nice tools... but the intended > use for those tools has nothing to do with administering or > maintaining Linux. It has to do with easing people from the Wind0ws > world past the oh-so-terrifying idea that another OS will slit their > throats, rape their Chihuahuas, and run away to Monaco with their > money - and into using the same applications in pretty much the same > way as they always have, marketing hype to the contrary > notwithstanding.That is as maybe -- and whether or not KDE and GNOME are out on a mission to wean people using Windows to Linux, the fact remains that with GNOME (especially in Ubuntu, for example), the de facto functionality is to automount and run Nautilus for any device that you can shove into one of the many orifices your computer comes with nowadays; USB included. :P
Whilst that could be deemed appropriate for someone new to Linux, it could also be considered one of convenience for the more experienced user. Of course, what it doesn't do is allow you to easily see what is happening behind the scenes. Maybe in some instances this is a good thing; I am not sure whether it is or not at the moment.
But the whole USB subsystem is getting much better than it used to be. By that, I really mean hotplug. It used to be an abomination a few years ago; using some form of black magic (tm) to somehow select the devices, etc. But it is by no means perfect. I think one of the biggest issues that throws people is the lack of consistency between the device mappings between unplugging and replugging the devices -- especially if it is a mass-storage device (c.f. /dev/sda1, /dev/sda2, etc.) This gets slightly better if you're one of these people who subscribes to the whole "udev" experience. But as I am known for making my views all too clear about why I hate udev, I do not use it. :P
> It's possible to debate the long-term usefulness of this approach. I, > for example, have strong reservations about it maintaining the > irresponsible mindset that is trained into many Wind0ws users by the > shiny, glitzy interface ("just put gas into it, and leave Complicated > Stuff like checking the oil to the professional mechanics!") - this is > what allows viruses, etc. to propagate - but there are many people > whose only reason for switching to Linux was the ability to "keep > doing the same thing as before". Perhaps the question is, would it beI'm not going to rehash this one -- around issue #96 onwards I published several exchanges like the one here for 'Windows Defectors'. So I'll point any readers to those. Plus it saves me typing.
[Pedro Fraile Pérez] I am running Ubuntu Dapper here, and the USB subsystem works as is to be expected, only the package 'hotplug' does not exist any more. In fact, it is not to be found among the repositories. I remember I was confused for quite some time when I upgraded from Breezy, and found out that most of my /etc/hotplug* was gone, there was no /sbin/hotplug, and some things were not working any more ... until I (correctly) installed udev. Your message has finally impulsed me to try to find out for sure what happened, and the answer seems to lie withing these threads (please correct me if I am wrong)
http://lists.debian.org/debian-devel/2005/08/msg01454.html
http://lists.debian.org/debian-devel/2005/09/msg00732.htmlOne thing I am still missing is the knowledge on how to troubleshoot the combination udev / hal / sysfs (Does hal has something to do with the other two?). I have minor glitches with a couple of things: an USB stick that is automounted on a back slot of a Dell box, but not on a front one - and no hardware problem here, for sure -, or a DVD writer that takes all the /dev/{cdr*,dvd*} symlinks, instead of leaving the /dev/cdrom to the other CD reader. In the all days, I would have modified some script under /etc/hotplug.d/ to log some information on a temporary file, but I do not know of a similar strategy with udev. I have to admit that I have not invested tons of time on it though ...
> Something that comes in very useful when troubleshooting USB is the > 'usbfs' virtual file system. To get access to it, compile this option > into the kernel (CONFIG_USB_DEVICEFS=y) and list it in > '/etc/fstab' (the relevant line reads "none /proc/bus/usb usbfs > noauto 0 0", and it is loaded by the kernel when the USB subsystem is > detected.)No usbfs entry in my /etc/fstab either, but procbususb gets mounted on /proc/bus/usb at boot anyway ...
> Assuming that you have your "/etc/fstab" properly configured - i.e., > you have entries that look something like this: > > `` > ben@Fenrir:~$ grep sd /etc/fstab > /dev/sda /mnt/sda vfat user,noauto,gid=103,rw,fmask=113 0 0 > /dev/sda1 /mnt/sda1 vfat user,noauto,gid=103,rw,fmask=113 0 0 > /dev/sdb /mnt/sdb vfat user,noauto,gid=103,rw,fmask=113 0 0 > /dev/sdb1 /mnt/sdb1 vfat user,noauto,gid=103,rw,fmask=113 0 0 > /dev/sdc /mnt/sdc vfat user,noauto,gid=103,rw,fmask=113 0 0Another difference here is the use of 'pmount'. From 'aptitude show pmount':
Description: mount removable devices as normal userThe net result being that (under gnome, at least) any removable media gets mounted on an ad-hoc created /media/whatever with the right user permissions, without any entry in fstab. Cannot say I dislike it ...
[Ben Okopnik]
On Thu, Sep 21, 2006 at 08:58:33AM +0100, Thomas Adam wrote: > "Benjamin A. Okopnik" <ben at linuxgazette.net> wrote: > > In my opinion, KDE and Gnome are very nice tools... but the intended > > use for those tools has nothing to do with administering or > > maintaining Linux. It has to do with easing people from the Wind0ws > > world past the oh-so-terrifying idea that another OS will slit their > > throats, rape their Chihuahuas, and run away to Monaco with their > > money - and into using the same applications in pretty much the same > > way as they always have, marketing hype to the contrary > > notwithstanding. > > That is as maybe -- and whether or not KDE and GNOME are out on a > mission to wean people using Windows to Linux, the fact remains that > with GNOME (especially in Ubuntu, for example), the de facto > functionality is to automount and run Nautilus for any device that > you can shove into one of the many orifices your computer comes with > nowadays; USB included. :PI'll have to install Gnome and try shoving a screwdriver into the fan vent. The mounting procedure ought to be interesting, to say the least.
> I think one of the > biggest issues that throws people is the lack of consistency between > the device mappings between unplugging and replugging the devices -- > especially if it is a mass-storage device (c.f. /dev/sda1, /dev/sda2, > etc.)Really? I actually have symlinks in my '/mnt' that are hard-wired to specific devices:
r!ls -FAlS /mnt total 36 drwxrwxr-x 2 root staff 4096 2005-11-22 16:19 hda1/ drwxr-xr-x 2 root root 4096 2005-11-22 16:09 hdc/ drwxr-xr-x 2 root root 4096 2005-11-22 16:09 sda/ drwxr-xr-x 2 root root 4096 2005-11-22 16:09 sda1/ drwxr-xr-x 2 root root 4096 2005-11-22 16:09 sdb/ drwxr-xr-x 2 root root 4096 2005-11-22 16:09 sdb1/ drwxr-xr-x 2 root root 4096 2006-04-26 13:28 sdc/ drwxr-xr-x 2 root root 4096 2005-11-22 16:09 sr0/ drwxr-xr-x 2 root root 4096 2004-05-10 20:26 test/ lrwxrwxrwx 1 root root 4 2005-11-22 16:10 olympus -> sda1/ lrwxrwxrwx 1 root root 4 2005-11-22 16:19 puppy -> hda1/ lrwxrwxrwx 1 root root 4 2005-11-22 16:12 sdcard -> sdb1/ lrwxr-xr-x 1 root root 3 2005-12-08 12:31 dvd -> sr0/ lrwxrwxrwx 1 root root 3 2005-11-22 16:11 dvd-scsi -> sr0/ lrwxrwxrwx 1 root root 3 2005-11-22 16:11 flash -> sdb/'olympus' (my digital camera), 'sdcard' (the SD card from my Palm Pilot), and 'flash' (my USB thumb drive) are absolutely consistent in the device names that they get assigned to.
> This gets slightly better if you're one of these people who > subscribes to the whole "udev" experience. But as I am known for > making my views all too clear about why I hate udev, I do not use > it. :PI've tried 'udev' at one point, and gave up on it - I don't recall why. Perhaps I caught something from you via email.
[Kapil Hari Paranjape]
On Thu, 21 Sep 2006, Pedro Fraile Pérez wrote: > El Sun, 17 Sep 2006 21:47:54 -0400 > "Benjamin A. Okopnik" <ben at linuxgazette.net> wrote: > > > > The Monthly Troubleshooter: The USB Subsystem > > ============================================= > > > ... until I (correctly) > installed udev. Your message has finally impulsed me to try to find out > for sure what happened, and the answer seems to lie withing these > threads (please correct me if I am wrong) > > http://lists.debian.org/debian-devel/2005/08/msg01454.html > http://lists.debian.org/debian-devel/2005/09/msg00732.htmlIndeed. This is a problem for all those udev-haters out there
> One thing I am still missing is the knowledge on how to troubleshoot > the combination udev / hal / sysfs (Does hal has something to do with > the other two?).Absolutely. HAL is the AI in the system
Q: Can I use udev to automount a USB device when I connect it? A: Technically, yes, but udev is not intended for this. All major distributions use HAL (http://freedesktop.org/wiki/Software_2fhal) for this, which also watches devices with removable media and integrates the Desktop environment.Alternatively, it is easy to add the following to fstab:
/dev/disk/by-label/PENDRIVE /media/PENDRIVE vfat user,noauto 0 0This means that users can access the device with:
$mount /media/PENDRIVE
and doen't have to be root, but will get full permissions on the device. Using the persistent disk links (label, uuid) will always catch the same device regardless of the actual kernel name.> I have minor glitches with a couple of things: an USB > stick that is automounted on a back slot of a Dell box, but not on a > front one - and no hardware problem here, for sure -,Actually this is probably a hardware problem as I discovered.
The problem is that there are two types of USB ports. Those that supply suficient power and those that do not. If you have a device which requires power to be supplied through the USB socket and you connect to a USB port that does not supply power (or does not supply enough of it) then the device will not work.
I found this out when I was trying to connect an external USB disk to a Mac PowerBook (inappropriately named!). It turns out that the PowerBook only has low/no power USB sockets and so the disk needs external power in order to work (the disk happily had a socket for such an adapter). In the process I also discovered why this disk had ben behaving exactly as you described with another Intel-based machine that had Front and Back USB ports.
> In the all days, I would have > modified some script under /etc/hotplug.d/ to log some information on a > temporary file, but I do not know of a similar strategy with udev. I > have to admit that I have not invested tons of time on it though ...Again quoting from the udev NEWS.Debian:
Scripts in /etc/dev.d/ and /etc/hotplug.d/ are not supported anymore unless the hotplugd.rules rules file is manually enabled. -- Marco d'Itri <md at linux.it> Thu, 17 Aug 2006 14:40:34 +0200So if you have a recent sid/etch then you can enable the scripts but its going to take some work.
> The net result being that (under gnome, at least) any removable media > gets mounted on an ad-hoc created /media/whatever with the right > user permissions, without any entry in fstab. Cannot say I dislike > it ...I think the problem is what-if. What if there is a device that I do not want automounted? There is perhaps not an easy way to prevent that from happening.
[Rick Moen]
Quoting Kapil Hari Paranjape (kapil at imsc.res.in): > Absolutely. HAL is the AI in the systemUgh. That's repulsive -- if only because of the dependency on glib (about which it's said "this dep will be dropped soon"). Something with the smell of GNOME about it has no business getting anywhere near my kernels.
[Kapil Hari Paranjape]
On Thu, 21 Sep 2006, Rick Moen wrote: > > Ugh. That's repulsive -- if only because of the dependency on glib > (about which it's said "this dep will be dropped soon"). Something with > the smell of GNOME about it has no business getting anywhere near my > kernels.
One alternative is "usbmount" which specifically indicates:
USBmount is intended as a lightweight solution which is independent of a desktop environment. Users which would like an icon to appear when an USB device is plugged in should use the pmount and hal packages instead.There is also the more general purpose "am-utils" but using this when one only wants to mounts USB sticks is perhaps excessive.
[Pedro Fraile Pérez]
Kapil Hari Paranjape <kapil at imsc.res.in> escribi?: > > On Thu, 21 Sep 2006, Pedro Fraile P?rez wrote: > > > I have minor glitches with a couple of things: an USB > > stick that is automounted on a back slot of a Dell box, but not on a > > front one - and no hardware problem here, for sure -, > > Actually this is probably a hardware problem as I discovered. > > The problem is that there are two types of USB ports. Those that > supply suficient power and those that do not. If you have a device > which requires power to be supplied through the USB socket and you > connect to a USB port that does not supply power (or does not supply > enough of it) then the device will not work.Hello Kapil,
That's a good piece of info, but I am afraid it is not my case. Under several versions of Windows, the memory stick is mounted both in the front and back slots, so there must be some kind of driver issue here.
> > The net result being that (under gnome, at least) any removable > > media gets mounted on an ad-hoc created /media/whatever with the > > right user permissions, without any entry in fstab. Cannot say I > > dislike it ... > > I think the problem is what-if. What if there is a device that I do > not want automounted? There is perhaps not an easy way to prevent > that from happening.Yes, I agree. You can disable the automounting process for all removable devices, but I have not yet found out how you can do it on a per-device basis.
[Kapil Hari Paranjape]
On Fri, 22 Sep 2006, Kapil Hari Paranjape wrote: (quoting from the udev FAQ) > Alternatively, it is easy to add the following to fstab: > /dev/disk/by-label/PENDRIVE /media/PENDRIVE vfat user,noauto 0 0 > > This means that users can access the device with: > $mount /media/PENDRIVE > and doen't have to be root, but will get full permissions on the device. > Using the persistent disk links (label, uuid) will always catch the > same device regardless of the actual kernel name.These instructions seem to work ... but you don't need udev to make this work!
When you make the file system give it a "label". Most filesystem types (even DOS and Windows types like FAT and VFAT) allow you to set a label. You can then mount the system by
mount -L <your label> <mount point>Alternatively your fstab could contain entries like:
LABEL=DOST /media/DOST vfat rw,user,noauto 0 0 LABEL=LEAN /media/LEAN ext2 rw,user,noauto 0 0You can then mount the disks (as a user) with a command like:
mount /media/DOSTThis doesn't work for those cameras that appear as USB memory devices to your computer unless the manufacturer is kind enough to give the device a label when it is formatted.
[Martin Hooper]
On 29/09/2006 Kapil Hari Paranjape wrote: > mount -L <your label> <mount point> > > Alternatively your fstab could contain entries like: > LABEL=DOST /media/DOST vfat rw,user,noauto 0 0 > LABEL=LEAN /media/LEAN ext2 rw,user,noauto 0 0How do you create labels then?? I guess its an option to mkfs...
[Ben Okopnik]
On Thu, Sep 21, 2006 at 09:16:57PM +0200, Pedro Fraile P?rez wrote: > > One thing I am still missing is the knowledge on how to troubleshoot > the combination udev / hal / sysfs (Does hal has something to do with > the other two?).Hmmm, you've got me; I'm still using hotplug. Anybody else care to comment?
> > Something that comes in very useful when troubleshooting USB is the > > 'usbfs' virtual file system. To get access to it, compile this option > > into the kernel (CONFIG_USB_DEVICEFS=y) and list it in > > '/etc/fstab' (the relevant line reads "none /proc/bus/usb usbfs > > noauto 0 0", and it is loaded by the kernel when the USB subsystem is > > detected.) > > No usbfs entry in my /etc/fstab either, but procbususb > gets mounted on /proc/bus/usb at boot anyway ...Actually, given that the entry in my '/etc/fstab' says "noauto", I was wondering about that. I used to mount it manually, but looking at it now, it's clearly being mounted by the kernel - perhaps when USB support gets loaded? It would have made sense to automate it, since it's such a useful gadget. Looking at 'dmesg' output, there's nothing noting it... I suspect that '/etc/fstab' line is no longer necessary.
[Thomas Adam]
Benjamin A. Okopnik <ben at linuxgazette.net> wrote: > On Thu, Sep 21, 2006 at 09:16:57PM +0200, Pedro Fraile P?rez wrote: > > > > One thing I am still missing is the knowledge on how to troubleshoot > > the combination udev / hal / sysfs (Does hal has something to do > > with the other two?). > > Hmmm, you've got me; I'm still using hotplug. Anybody else care to > comment?HAL works by abstraction. Essentially by the time HAL kicks in, it will have already realised what the interface is that $DEVICE is using. So of course before that can happen, hotplug must have been working to recognise the device. It has to load the driver, manage what's in /dev, and provide some mechanism of accessing it.
It's mounted, which of course means that applications such as GNOME can then shunt a nice icon on its desktop for users to use.
[Kapil Hari Paranjape]
On Fri, 29 Sep 2006, Martin Hooper wrote: > On Fri, 29 Sep 2006, Kapil Hari Paranjape wrote: > > When you make the file system give it a "label". Most filesystem > > types (even DOS and Windows types like FAT and VFAT) allow you to > > set a label. > How do you create labels then?? I guess its an option to mkfs...
To make this more clear:
mkdosfs -n <your label> <other options> mke2fs -L <your label> <other options>Perhaps those who use other file systems can pitch in with what is required for xfs, jfs, reiserfs, ...
[John Karns]
On Sat, 30 Sep 2006, Kapil Hari Paranjape wrote: > On Fri, 29 Sep 2006, Kapil Hari Paranjape wrote: >> When you make the file system give it a "label". Most filesystem >> types (even DOS and Windows types like FAT and VFAT) allow you to >> set a label. > > To make this more clear: > mkdosfs -n <your label> <other options> > mke2fs -L <your label> <other options> > Perhaps those who use other file systems can pitch in with > what is required for xfs, jfs, reiserfs, ...A quick check of the man pages for the filesystems mentioned above shows that the convention is mkfs.<type> "-L <label>" (for xfs, jfs and reiserfs4). The older reiserfs (pre-version 4) is an exception and calls for the flag as lowercase "-l <label>".
Replacing Tin Soldiers© Jan-Paul Herr, pixelio.de
Author(s): Michael Schilli
Although a USB toy such as a polystyrene rocket launcher only includes a Windows CD, it works fine on Linux with a spot of reverse engineering. With libusb, this doesn't even require compiling a device driver – Perl controls the device from userspace.
Trouble at the office? It doesn't necessarily need to lead to a battle, such as in the video The Great Office War [2] by toy manufacturer Hasbro. Even if you don't have an attack plan, the USB-controlled Rocket Baby rocket launcher (Figure 1), by Chinese manufacturer Cheeky Dream, is a bargain at less than US$ 20. Not only did it cheer up my colleagues at work, it also gave me an opportunity to study the Linux kernel's fairly complex USB subsystem [3].
Figure 1: The USB rocket launcher Rocket Baby, by Cheeky Dream.
Opening the box reveals a CD for Windows XP, but no trace of a Linux driver. This seems to have provoked a number of gadget fans in the developer community to investigate the USB protocol the toy uses on Windows with USB sniffers such as USBsniff, to reverse engineer the interfaces, and create bindings for languages such as Python, or even for completely different operating systems [4].
When the toy is plugged into an empty USB slot, the Ubuntu Hardy Heron distribution autodetects it. The kernel messages, which can be read in the /var/log/messages logfile (Figure 2), tell you that the toy rocket launcher is now connected to the Intel-based PC's UHCI controller.
Figure 2: After you plug in the rocket launcher, the kernel detects the device and assigns a USB entry to it.
According to the logfile, the kernel's USB subsystem has mapped the rocket launcher to usb 5-1. The sysfs tree below /sys/bus/usb/devices/5-1 gives you the details. The USB filesystem, usbfs, projects the kernel's internal USB data to userspace this way. Figure 3 shows that the idVendor value for the launcher is 0x0a81, and the idProduct is 0x0701, as can be determined easily by looking up the content of the respective files in the sysfs tree. According to the order in which you plug in the USB devices, the kernel assigns varying USB numbers for them; instead of usb 5-1, it could be usb 3-1 next time.
Figure 3: Linux shows details of hotplugged devices in the /sys tree.
This said, there is only one device with the idVendor and idProduct values we just discovered plugged into the PC; thus, a program can find the USB address of the device reliably and fairly quickly by parsing the USB tree until it finds the right combination.Linux normally uses kernel device drivers to talk to USB devices. A driver is difficult to program because there is no safety net, as taken for granted in user space; the slightest pointer error will torpedo the whole Linux system and force a reboot. On top of this, users would need to recompile the device driver for each new kernel and load the module as root by running modprobe. Data structures tend to change rapidly in the kernel, and it is possible that the source code you write for kernel 2.6.22 goes out the window with version 2.6.24.
But if you do not need high data throughput or realtime responses, there is no need to leave the control logic with the kernel. Instead, the kernel has the usbfs that lets you talk to USB devices at the hardware level, and this means that you can implement the driver in userspace.
The Open Source libusb project [5] provides a convenient library for C programs, and the Perl Device::USB module from CPAN wraps Perl functions around it.
Listing 3 shows you how to raise the rocket launcher's barrels by about half an inch with just a couple of lines of Perl code. First, the find_device() function uses the Device::USB module to locate the device with the idVendor and idProduct values discovered beforehand in the USB tree. If this succeeds, the open() method opens a connection to the device.
The kernel's USB subsystem supports four different communication modes for USB controllers: Control Transfers for short messages, Bulk Transfers for larger volumes of data, Interrupt Transfers for time-critical data, and Isosynchronous Transfers for realtime data. Reverse engineering helped the developers discover that the rocket launcher uses one-byte control messages to move the tower and fire the polystyrene rockets. Listing 1 shows the codes for various actions.
Listing 1
Control Codes
01 down 0x01, 02 up 0x02, 03 left 0x04, 04 right 0x08, 05 fire 0x10, 06 stop 0x20, 07 start 0x40,One code moves the launcher until another code either changes the direction or a stop command cancels the movement, which is important because if a program starts a movement and then fails, the rocket launcher's motor will annoyingly keep on running. The hex values passed into the control_msg() method in Lines 14 and 22 define how the USB interface passes the control byte on to the controller: 0x21 stands for the request type, 0x09 for USB_REQ_SET_CONFIGURATION, 0x02 for USB_RECIP_ENDPOINT, and the value 0 for an unused index. Then comes the control code (0x02 for moving the barrels up in line 15) for driving the launcher. Perl's chr() function transforms an integer value, such as 0x02, into a single byte containing the same value.
The last two parameters specify the length of the string, 1, or exactly one byte in our case, and the response wait time in milliseconds (1000) before the program times out.
After this, the test program takes a short break of a tenth of a second (10,000 microseconds) thanks to the CPAN Time::HiRes module and its usleep() function, before going on to send the 0x20 control byte, which the receiving end interprets as a stop command, thus switching the rocket launcher tower motor off. In Listing 3, the two calls to control_msg() thus move the launcher tower up for a tenth of a second. If the tower is not at its maximum elevation already, this means that you hear the motor for a fraction of the second and the polystyrene rockets are elevated by about 20 degrees.
Listing 2
Parameters for control_msg()
01 $requesttype => 0x21 02 $request => 0x09 03 $value => 0x02 04 $index => 0 05 $bytes => chr(...) 06 $size => 1 07 $timeout => 1000Listing 3
rocket-test
01 #!/usr/local/bin/perl -w 02 use strict; 03 04 use Time::HiRes qw(usleep); 05 use Device::USB; 06 my $usb = Device::USB->new; 07 my $dev = 08 $usb->find_device( 0xA81, 09 0x701 ); 10 $dev->open; 11 12 # Move Up 13 my $val = 0x02; 14 $dev->control_msg( 0x21, 15 0x09, 0x02, 0, chr($val), 16 1, 1000 ); 17 18 usleep(150_000); 19 20 # Stop 21 $val = 0x20; 22 $dev->control_msg( 0x21, 23 0x09, 0x02, 0, chr($val), 24 1, 1000 ); 25 26 # Read status 27 $val = 0x40; 28 my $buf; 29 $dev->control_msg( 0x21, 30 0x09, 0x02, 0, chr($val), 31 1, 1000 ); 32 $dev->bulk_read( 1, 33 $buf = "", 1, 1000 ); 34 printf "Status %08b\n", 35 ord($buf);Fire!
When you fire the rockets, note that the motor needs to pump for about two seconds to build up the pressure needed to fire the projectiles. So that the program can discover when to switch off the motor, because the rocket has been released, it must access the USB interface and read the rocket launcher controller data. The controller reports which actions are available now, and which are not. If the tower is swiveled as far right as it will turn, the controller returns a status string with a value of 0x08 (binary 0000_1000) to show that all actions apart from 0x08 are now available; as you will see in box 1, 0x08 represents the direction right. If the tower is swiveled as far left and to the bottom as it will turn, the controller returns a status message of 0x05 (binary 0000_0101), because both 0x01 (down) and 0x04 (left) are now blocked. In a similar fashion, the USB device sets a 0x10 flag (binary 0001_0000) shortly after firing to tell the controller that it can now issue a 0x20 to switch off the motor, unless you want to fire the next in line of the total of three rockets.
To check the launcher status, the controller first sends a control code of 0x40 via control_msg() to the USB device, which is immediately followed by a bulk transfer using the bulk_read() method to pick up the data string returned by the device. Line 34 in Listing 3 writes the result, which is 00000000 in most cases, unless the tower is swiveled to one of the limits, or at minimum or maximum elevation, or a rocket has just been fired.
The Device::USB::MissileLauncher::RocketBaby module from CPAN provides a neat interface abstraction; a newly constructed object offers the do() and cando() methods, which expect actions as strings such as left, up, fire, or stop. The do() method executes these actions, whereas cando() just issues a status request and a bulk read to check whether an action is currently available.
Listing 4 shows you how to use this. To start, it rotates the tower down and to the left to the limits to ascertain the precise position, then it measures the time required to elevate the tower completely and to swivel it fully to the right. Then it divides the two times by half and centers the tower using the calculated values before firing all three rockets one after another.
Listing 4
center-fire
01 #!/usr/local/bin/perl -w 02 use strict; 03 04 use 05 Device::USB::MissileLauncher::RocketBaby; 06 use Time::HiRes 07 qw(usleep gettimeofday 08 tv_interval); 09 10 my $rb = 11 Device::USB::MissileLauncher::RocketBaby 12 ->new(); 13 14 do_until("left"); 15 do_until("down"); 16 17 my $right_start = 18 [gettimeofday]; 19 do_until("right"); 20 my $right_elapsed = 21 tv_interval( 22 $right_start, 23 [gettimeofday] 24 ); 25 26 my $up_start = 27 [gettimeofday]; 28 do_until("up"); 29 my $up_elapsed = 30 tv_interval( $up_start, 31 [gettimeofday] ); 32 33 do_until( "left", 34 $right_elapsed / 2 ); 35 do_until( "down", 36 $up_elapsed / 2 ); 37 38 for ( 1 .. 3 ) { 39 do_until("fire"); 40 usleep(100_000); 41 } 42 43 ############################# 44 sub do_until { 45 ############################# 46 my ( $what, $max_time ) = 47 @_; 48 49 my $start = [gettimeofday]; 50 51 while ( $rb->cando($what) ) 52 { 53 $rb->do($what); 54 usleep(100_000); 55 last 56 if defined $max_time 57 and 58 tv_interval( $start, 59 [gettimeofday] ) > 60 $max_time; 61 } 62 $rb->do("stop"); 63 }Installation
Linux needs the libusb-dev package in userspace to access USB devices. Any fairly recent distribution will have this. The Device::USB and Device::USB::MissileLauncher::RocketBaby modules are best installed using a CPAN shell. Various types of rocket launchers use different code combinations; when in doubt, you can search for the right combination on the Internet and then wrap it up in an abstraction such as the CPAN RocketBaby module.
A Youtube video [6] shows you how the rocket launcher responds to the center-fire script. And now a message from the Homeland Security Department: please avoid exporting this script to untrusted countries.
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March, 12, 2019
