LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 05-03-2013, 12:36 PM   #1
Skaperen
Senior Member
 
Registered: May 2009
Location: center of singularity
Distribution: Xubuntu, Ubuntu, Slackware, Amazon Linux, OpenBSD, LFS (on Sparc_32 and i386)
Posts: 2,678
Blog Entries: 31

Rep: Reputation: 176Reputation: 176
troubles with -current seem to be USB related


I'm having some troubles with -current (from 2013-04-29) that seem to be related to USB. This is on a new computer, and it involves a PS/2 to USB converter. The computer only has one PS/2 connector. My keyboard and mouse are both PS/2. So I plug the keyboard into the PS/2 connector and plug the mouse into a PS/2 to USB converter, and that converter plugs into a USB port.

The BIOS does not like it when there is no keyboard plugged into the PS/2 port. So I am using the split where keyboard goes direct to PS/2 and mouse give via PS/2 to USB conversion.

Xubuntu works OK with this. Keyboard works. Mouse works. Xubuntu does not have support for mouse in text mode (gpm repeater). But in Slackware64-current, the mouse is simply not working, either in text mode, or in Xfce (KDE was unselected during install). The strace command shows gpm gets NO mouse events ... ever.

I tried blacklisting the "psmouse" module (suggested on IRC). That succeeded to prevent that module from loading, but there is still no mouse activity (gpm still gets NO mouse events). So it appears that module is not the culprit causing the problem. Maybe another is? Maybe the lack of one is? Is a specific module needed for mouse on USB support? FYI, another test with both keyboard and mouse on USB also caused the keyboard to no longer work ... suggesting a USB issue.

I thought the hardware interface for common things like mice, within USB, were standard. Storage devices emulating hard drives, and my USB DVD drive have always worked. But previously keyboard and mouse have always been on PS/2 so I've no experience with how reliable they are on USB.

Here are some diagnostic files for this: http://phil.ipal.net/planck-diagnosis/
 
Old 05-03-2013, 01:11 PM   #2
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, Slarm64 & Android
Posts: 16,149

Rep: Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308
As long as you continue with ps/2, you are going to be saddled with two problems

1. One is connected as only one can be, and your system simply doesn't see the other.
2. ps2 ports blow - especially with adapters on them

My suggestion - buy a usb mouse. It's cheaper than that adapter (probably) and saves all the hassle. Continue with your ps2 keyboard as long as it and the port last.
 
Old 05-03-2013, 01:51 PM   #3
Skaperen
Senior Member
 
Registered: May 2009
Location: center of singularity
Distribution: Xubuntu, Ubuntu, Slackware, Amazon Linux, OpenBSD, LFS (on Sparc_32 and i386)
Posts: 2,678

Original Poster
Blog Entries: 31

Rep: Reputation: 176Reputation: 176
Quote:
Originally Posted by business_kid View Post
As long as you continue with ps/2, you are going to be saddled with two problems

1. One is connected as only one can be, and your system simply doesn't see the other.
2. ps2 ports blow - especially with adapters on them

My suggestion - buy a usb mouse. It's cheaper than that adapter (probably) and saves all the hassle. Continue with your ps2 keyboard as long as it and the port last.
1. The "system" sees the other just fine when I run Xubuntu. What is it about Xubuntu that allows it to do that and can we do that same thing in Slackware ... especially with gpm (that Xubuntu was not using). Note that this is not gpm's fault since the mouse actions were never sent to gpm by the kernel.

2. The failure is for things plugged into USB ports. Things plugged into PS/2 ports work in both systems. If this motherboard had two PS/2 ports, I bet things would be working fine.

Remember, the problem is that Slackware is not working with USB (but maybe because it needs a hand made configuration change to support USB). PS/2 works all around so there is no need to drop PS/2, buy new KVM switches (mine do PS/2), and risk all the other systems failing for the very same reason.

PS/2 works where it is used. On every system I have worked with since PS/2 was around, except for 2 motherboards manufactured by Intel, PS/2 itself has never failed. In the case of the Intel boards, if they boot up with nothing connected, and things are connected while the system is up, they reverse their roles (the keyboard port signals give mouse actions, and the mouse port signals give keyboard actions ... likely a design error by Intel since I heard a number of reports of the same failure mode on a number of their boards). But at least the worked when one did a workaround by reversing the connections (plug keyboard into mouse port and plug mouse into keyboard port).

So, let's see if we can extract some actual help from YOU. Are you running Slackware, particularly -current, on a system where you plug in keyboard and mouse to USB? What changes did YOU do to make USB mouse work on -current?

Last edited by Skaperen; 05-03-2013 at 02:13 PM.
 
Old 05-03-2013, 02:49 PM   #4
Skaperen
Senior Member
 
Registered: May 2009
Location: center of singularity
Distribution: Xubuntu, Ubuntu, Slackware, Amazon Linux, OpenBSD, LFS (on Sparc_32 and i386)
Posts: 2,678

Original Poster
Blog Entries: 31

Rep: Reputation: 176Reputation: 176
Additional info ...

Almost every page found via Google for help with getting USB mouse working has an answer that involves configuring X to use "/dev/input/mice" to read the mouse actions.

The issue I have does not entirely involve X. It involves gpm, too. An by default gpm is reading "/dev/input/mice" already, via the "/dev/mouse" symlink. But is failing as no mouse actions come through from the "/dev/input/mice" device node file.

It seems no driver is supporting the USB mouse, or isn't providing the mouse events to "/dev/input/mouse". So this problem is beyond the vast majority of "solutions" out there.
 
Old 05-03-2013, 04:26 PM   #5
dreamwalking
Member
 
Registered: Dec 2005
Distribution: Slackware 14
Posts: 106

Rep: Reputation: 31
Quote:
Originally Posted by Skaperen View Post
Remember, the problem is that Slackware is not working with USB (but maybe because it needs a hand made configuration change to support USB).
Just to make sure I understand correctly what you mean with this: Your PS2 mouse is not working through the USB adapter, or you have tried to plug a USB mouse as well and it didn't work either?

At least here, USB mouse works out of the box in both Slackware 14.0 and --current, with stock kernel, and gpm is working out of the box as well (and so does USB keyboard for the record). Are you maybe using a custom kernel?

Regarding the ps2-USB mouse, I have no idea, but here's an observation: however I noticed in your /proc/modules that there's no USB_HID and HID module, that you do have loaded on Ubuntu (and I do have on my computer as well). Maybe try load this?
 
Old 05-03-2013, 07:13 PM   #6
Skaperen
Senior Member
 
Registered: May 2009
Location: center of singularity
Distribution: Xubuntu, Ubuntu, Slackware, Amazon Linux, OpenBSD, LFS (on Sparc_32 and i386)
Posts: 2,678

Original Poster
Blog Entries: 31

Rep: Reputation: 176Reputation: 176
Quote:
Originally Posted by dreamwalking View Post
Just to make sure I understand correctly what you mean with this: Your PS2 mouse is not working through the USB adapter, or you have tried to plug a USB mouse as well and it didn't work either?
It did not work in Slackware64-current. I did work in Xubuntu 13.04 amd64.

Quote:
Originally Posted by dreamwalking View Post
At least here, USB mouse works out of the box in both Slackware 14.0 and --current, with stock kernel, and gpm is working out of the box as well (and so does USB keyboard for the record). Are you maybe using a custom kernel?
I am using the kernel installed by the installer. No changes. The problem was first seen on first boot of the installed system

Quote:
Originally Posted by dreamwalking View Post
Regarding the ps2-USB mouse, I have no idea, but here's an observation: however I noticed in your /proc/modules that there's no USB_HID and HID module, that you do have loaded on Ubuntu (and I do have on my computer as well). Maybe try load this?
I loaded this one:
/lib/modules/3.8.8/kernel/drivers/hid/usbhid/usbhid.ko

and it has some symbols missing. So I loaded this one:
/lib/modules/3.8.8/kernel/drivers/hid/hid.ko

which loaded OK and tried the usbhid again, and that loaded OK. But no joy (moving mouse got nothing from gpm). I killed and restarted gpm and still no joy.

I am getting these messages:
Code:
[ 1066.494992] hub 8-1:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
[ 1070.340978] hub 8-1:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
[ 1074.186959] hub 8-1:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
[ 1078.032920] hub 8-1:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
[ 1078.033051] hub 8-1:1.0: unable to enumerate USB device on port 1
So out of curiosity, I moved the USB port where the mouse adapter is plugged in to another port. Now I get these messages:
Code:
[ 1119.915385] hub 8-1:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
[ 1123.761356] hub 8-1:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
[ 1127.607348] hub 8-1:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
[ 1131.453319] hub 8-1:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
[ 1131.453439] hub 8-1:1.0: unable to enumerate USB device on port 2
I've seen these before, but thought it was an internal port. Looks like this the mouse. I just brought up Xubuntu, again, and these messages do not happen at all. Maybe something broken in the 3.8.8 hub driver that is not broken in 3.8.0 ?

I wonder if it will work if I steal modules from Xubuntu (for 3.8.0) and try them on Slackware64-current's 3.8.8.

I'm also going to hunt down a real USB mouse, even though the adapter is working in Xubuntu. Maybe it's something weird in the hardware that is the regression in the software (if it is a regression).
 
Old 05-04-2013, 03:16 AM   #7
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, Slarm64 & Android
Posts: 16,149

Rep: Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308
For my sins (Which must have been many) I was rebuilding kernel 3.8.8 last night.

make menuconfig / device drivers/ input device support/ hardware i/o ports/

Has a number of options for PS2 Multiplexers. You came to mind. You'd never find it or conceive of it otherwise. Maybe rebuild, or at least grep the various kernel configs in that area?
 
Old 05-04-2013, 11:52 AM   #8
Skaperen
Senior Member
 
Registered: May 2009
Location: center of singularity
Distribution: Xubuntu, Ubuntu, Slackware, Amazon Linux, OpenBSD, LFS (on Sparc_32 and i386)
Posts: 2,678

Original Poster
Blog Entries: 31

Rep: Reputation: 176Reputation: 176
Quote:
Originally Posted by business_kid View Post
For my sins (Which must have been many) I was rebuilding kernel 3.8.8 last night.

make menuconfig / device drivers/ input device support/ hardware i/o ports/

Has a number of options for PS2 Multiplexers. You came to mind. You'd never find it or conceive of it otherwise. Maybe rebuild, or at least grep the various kernel configs in that area?
If I had PS/2 multiplexer hardware, this would be interesting. As described in the drivers, apparently some motherboards of an apparent brand called "TQC" have these. One thing I do NOT see is an external PS/2 multiplexer. In theory, this could be done since PS/2 is basically an input-only serial port in which you could send any data you want and get it as-is in the OS driver level.

But I've no plans to change the motherboard and I didn't see an external PS/2 multiplexer at Amazon or Newegg (if it exists, surely one of those two would have it). Google finds driver info but no products.

Personally, I think a new connector or protocol design should be made to add keyboard and mouse to the video monitor connector. Then put the keyboard and mouse connections on the monitor.

USB is bad because it is a messy and complicated design that has been made more complicated by multiple versions of changes. Often devices just won't get connected on USB. Sometimes I see plug in events in the logs, and failure of the device to be ready fast enough. I suspect it might be triggering events too quickly by detecting the device using power. I've also seen an entire bus of devices "go down" because of a plug-in of another device (maybe a hub crash).

Firewire is somewhat better/cleaner than USB, but not by all that much. If you are going to design a new universal peripheral connection system, I can give some good advice on how to do it, including data modulation designs and simpler addressing schemes (no assigned address like USB which can get them goofed up at times).

So show me what set of modules you use in Slackware64-current (future 14.1) on a USB 3.0 controller (xhci, etc) that makes at least mouse, and maybe even keyboard, work.
 
Old 05-04-2013, 02:55 PM   #9
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, Slarm64 & Android
Posts: 16,149

Rep: Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308Reputation: 2308
Firewire has it's versions of that spec too, believe me. I have a brother working in that patch.

I have Intel Panther Point here atm, using xhci_hcd, ehci_hcd uhci_hcd and zero issues. usblp for the pronter, ath9k for the wifi, uvcvideo for a webcam. NO issues once the thing sees the device.
keyboards and mice(mouses? Meece?) are seen instantly. There's some rts5139 Realtek card reader that's a bit more fussy.

Other box in house has an all amd RS690/SB600 chipset, same modules (except ohci_hcd instead of uhci_hcd, no xhci_hcd) and NO issues. b43 for the wifi, usblp for the printer, etc. I ran an SiS chipset here too, with similar results

I do believe xhci_hcd is a bit buggy yet (it has hysterics in the logs) but stuff works. What chipset have you got?
 
Old 05-04-2013, 03:48 PM   #10
Skaperen
Senior Member
 
Registered: May 2009
Location: center of singularity
Distribution: Xubuntu, Ubuntu, Slackware, Amazon Linux, OpenBSD, LFS (on Sparc_32 and i386)
Posts: 2,678

Original Poster
Blog Entries: 31

Rep: Reputation: 176Reputation: 176
This is the motherboard: http://www.supermicro.com/products/m...C600/X9SRA.cfm

Intel C602 chipset
 
Old 05-04-2013, 05:08 PM   #11
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,727

Rep: Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247
One interesting thing about the kernel 3.8.x USB support is that now, the EHCI-HCD driver is now split in EHCI-HCD and EHCI-PCI.

Now, is well known that EHCI-HCD and OHCI-HCD are problematic drivers, which require an strict loading order rule for their right working.

In my opinion, the best way to load that damned drivers is using the initrd and manual loading via that thing, not to rely in the UDEV rules...

Most likely, using an pre-3.8.x kernel, you should have something like that in your mkinitrd configuration for kernel modules loading:

Code:
usb-storage:xhci-hcd:ehci-hcd:ohci-hcd:usbhid
The problem is that now, with 3.8.x, the EHCI-HCD module is just an core usb module. The real thing will do the EHCI-PCI.

UDEV and (probably your initrd) will load the modules in that order:

Code:
usb-storage
xhci-hcd
ehci-hcd
ohci-hcd
usbhid
ehci-pci
That's just very wrong, because will make an serious conflict over EHCI/OHCI

N.B. XHCI(-HCD) is the driver for USB 3.0, EHCI(-PCI) is the driver for USB 2.0 and OHCI(-HCD) is the driver for USB 1.1


What happen when you have loaded that USB modules drivers, in that order?

Well, if you look in your dmesg, you will see glorious disconnection and resets of USB devices, and, most probably, you USB devices will react badly. Mouses disapear, keyboards are kicked out, storage devices which use (strict) the 2.0 protocol will be disconnected or strangelly shutdown.

Solution?

Yep, I believe you catch it: you should load the USB drivers in the RIGHT order, and the RIGHT devices, most probably, using initrd.

Code:
usb-storage:xhci-hcd:ehci-pci:ohci-hcd:usbhid
Example of an real mkinitrd command line:

Code:
mkinitrd -c -k 3.8.8-smp -f ext4 -r /dev/sda2 -h /dev/sda3 -m usb-storage:xhci-hcd:ehci-pci:ohci-hcd:usbhid:mbcache:jbd2:ext4 -u -M -o /boot/initrd-3.8.8-smp.gz
Also, if you have an USB 3.0 device, XHCI-HCD is your friend and it should be load first.

Finally, I believe that, if Our Beloved Leader will rely for future in to 3.8.x (or newer) kernels, he have to apply an simple but (almost) critical patch to the UDEV rules:

Code:
diff -up /lib/modprobe.d/usb-controller.conf.orig /lib/modprobe.d/usb-controller.conf
--- /lib/modprobe.d/usb-controller.conf.orig    2011-08-21 06:54:08.000000000 +0200
+++ /lib/modprobe.d/usb-controller.conf 2013-05-05 00:12:54.590124664 +0200
@@ -4,6 +4,6 @@

 # The EHCI driver should be loaded before the ones for low speed controllers
 # or some devices may be confused when they are disconnected and reconnected.
-softdep uhci-hcd pre: ehci-hcd
-softdep ohci-hcd pre: ehci-hcd
+softdep uhci-hcd pre: ehci-pci
+softdep ohci-hcd pre: ehci-pci

Last edited by Darth Vader; 05-04-2013 at 05:43 PM.
 
Old 05-04-2013, 05:27 PM   #12
Skaperen
Senior Member
 
Registered: May 2009
Location: center of singularity
Distribution: Xubuntu, Ubuntu, Slackware, Amazon Linux, OpenBSD, LFS (on Sparc_32 and i386)
Posts: 2,678

Original Poster
Blog Entries: 31

Rep: Reputation: 176Reputation: 176
Modules SHOULD be load-order agnostic. What if these drivers were not modules and statically compiled into the kernel. Then there would be no order of loading. I think this gets back to the whole concept of modules in the first place. By having to load them, you do end up with transitions in time where the earlier ones are there and the latter ones are not. Now at that time if these drivers are trying to do things, then THAT is what is wrong. Maybe if there was a way to load ALL the modules "atomically", as in, none are allowed to actually do anything until ALL have been loaded (and if the atomic set fails in any way, the whole set is unloaded).

And udev is something I serious think we need to get rid of. It is so very often a big trouble maker. It rewrites it own rules and does it wrong so much. What is needed is a minimalist handler for hot-plugging and static device nodes (yeah, that was always stable) for the defaults. If the kernel knows a name and major/minor code for a device, it should be able to just have a device filesystem that presents that. Among the troubles I've had with udevd are incorrect disk partition numbers (they did not match what /proc/partitions has, and when I made a script to convert /proc/partitions to correct device nodes, and ran it, things worked as they should) and incorrect juggling of network interfaces (move the hard drive to a new box because the old one dies, and it remaps the interfaces to all new names which the configurations do not match ... here we need a smart tool that figures out what is connected and configures accordingly ... and udev can't do it).

I'll rant more in my blog when I get time.

So what is the exact order I should load drivers? I'll hack the rc scripts to do this forced loading BEFORE udevd gets started (and hoping that udevd won't try to unload anything).
 
Old 05-04-2013, 05:37 PM   #13
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,727

Rep: Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247
Quote:
Originally Posted by Skaperen View Post
Modules SHOULD be load-order agnostic. What if these drivers were not modules and statically compiled into the kernel. Then there would be no order of loading. I think this gets back to the whole concept of modules in the first place. By having to load them, you do end up with transitions in time where the earlier ones are there and the latter ones are not. Now at that time if these drivers are trying to do things, then THAT is what is wrong. Maybe if there was a way to load ALL the modules "atomically", as in, none are allowed to actually do anything until ALL have been loaded (and if the atomic set fails in any way, the whole set is unloaded).

And udev is something I serious think we need to get rid of. It is so very often a big trouble maker. It rewrites it own rules and does it wrong so much. What is needed is a minimalist handler for hot-plugging and static device nodes (yeah, that was always stable) for the defaults. If the kernel knows a name and major/minor code for a device, it should be able to just have a device filesystem that presents that. Among the troubles I've had with udevd are incorrect disk partition numbers (they did not match what /proc/partitions has, and when I made a script to convert /proc/partitions to correct device nodes, and ran it, things worked as they should) and incorrect juggling of network interfaces (move the hard drive to a new box because the old one dies, and it remaps the interfaces to all new names which the configurations do not match ... here we need a smart tool that figures out what is connected and configures accordingly ... and udev can't do it).

I'll rant more in my blog when I get time.
The kernel modules have, of course, their dependencies, and loading order. Most times, the UDEV do the right thing, but XHCI/EHCI/OHCI is an special case, because the USB devices are multifunctional, for backward compatibility. So, in theory, an USB 3.0 device will probably work as USB 1.1 device. And there are the confusions, helped by an oldie UDEV rule.

Quote:
Originally Posted by Skaperen View Post
So what is the exact order I should load drivers? I'll hack the rc scripts to do this forced loading BEFORE udevd gets started (and hoping that udevd won't try to unload anything).
Like I said:

Code:
usb-storage
xhci-hcd
ehci-pci
ohci-hcd
usbhid
But, you do not need to hack the rc.d scripts, just use an right INITRD and an GENERIC kernel. You believe or not, that generic kernel behave better than HUGE, in some cases...

Last edited by Darth Vader; 05-04-2013 at 05:41 PM.
 
Old 05-04-2013, 06:22 PM   #14
Skaperen
Senior Member
 
Registered: May 2009
Location: center of singularity
Distribution: Xubuntu, Ubuntu, Slackware, Amazon Linux, OpenBSD, LFS (on Sparc_32 and i386)
Posts: 2,678

Original Poster
Blog Entries: 31

Rep: Reputation: 176Reputation: 176
Please explain to me what you mean by "just use an right INITRD and an GENERIC kernel". It's more trouble to build an initrd image than to just hack a quick script. or is there an initrd image ready made for this?

I am using the generic kernel. The huge one, as far as I know, offers me no advantage ... unless it has these needed drivers compiled in ... but the emphasis on huge is to have lots more disk device drivers (stuff essential short of the initrd).
 
Old 05-04-2013, 06:24 PM   #15
Skaperen
Senior Member
 
Registered: May 2009
Location: center of singularity
Distribution: Xubuntu, Ubuntu, Slackware, Amazon Linux, OpenBSD, LFS (on Sparc_32 and i386)
Posts: 2,678

Original Poster
Blog Entries: 31

Rep: Reputation: 176Reputation: 176
Update: I got the really-USB mouse from my dad's computer and tried it. It's actually WORSE than with the adapter thingy. The really-USB mouse causes udev to completely hang ... init scripts won't finish.

Another evidence for "udev bad". udev should never allow itself to hang for anything.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Slackware current x64 dbus related issue kkmic Slackware 2 12-15-2010 03:37 AM
FC10 nvidia troubles and other related issues bocochoco Fedora 6 12-15-2008 05:58 PM
Second Life Troubles - libexpat related Ariata Linux - Games 2 10-14-2006 09:01 PM
Xauthority timeout problem and hard drive partition troubles (related) W0bbles Linux - General 1 12-31-2005 08:56 PM
current Slack-Current giving troubles? r_jensen11 Slackware 5 02-02-2004 05:08 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 10:35 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration