Use the parallel port!
the parallel port is broken (physically)
Do your PC's have Via chipsets? I've never had any success with USB and VIA.
Yes, but it all worked ok in Redhat, Mandrake and Windows.
hmmmmm
On Sun, Sep 08, 2002 at 11:07:09AM +0000, Ricardo Campos wrote:
Use the parallel port!
the parallel port is broken (physically)
Do your PC's have Via chipsets? I've never had any success with USB and VIA.
Yes, but it all worked ok in Redhat, Mandrake and Windows.
hmmmmm
have you got the correct USB chipset support in your kernel? you will have a choice of 2 drivers for the via chipset you may need to try the other one....
I had a similar problem getting my adsl working, there is no indication of which driver will work except by trying them both, and both of them may appear to work.....
Adam
On Sunday 08 Sep 2002 12:33 pm, Adam Bower wrote:
On Sun, Sep 08, 2002 at 11:07:09AM +0000, Ricardo Campos wrote:
Use the parallel port!
the parallel port is broken (physically)
Do your PC's have Via chipsets? I've never had any success with USB and VIA.
Yes, but it all worked ok in Redhat, Mandrake and Windows.
hmmmmm
have you got the correct USB chipset support in your kernel? you will have a choice of 2 drivers for the via chipset you may need to try the other one....
You don't need it in your kernel. Al you need is USB support then load the module appropriate to your chipset, and there are only two to choose from.
Ian
On Sun, Sep 08, 2002 at 06:13:16PM +0100, Ian Thompson-bell wrote:
You don't need it in your kernel. Al you need is USB support then load the module appropriate to your chipset, and there are only two to choose from.
well there are 4 USB chipsets now, but you have a choice of OHCI, UHCI and EHCI.. but you have a choice of 2 modules/drivers for the UHCI chipset which is what i would wager Ricardo has, so he will have to try both of them and see which works better (or at all)
Sorry to be pedantic about this but it can be confusing as when you select building the driver into the kernel support for one of the UHCI chipsets the option for the other one disappears! which really confused me for a while when i was trying to get my ADSL modem working...
clear as mud (or windows) Adam
On Sunday 08 Sep 2002 6:25 pm, Adam Bower wrote:
On Sun, Sep 08, 2002 at 06:13:16PM +0100, Ian Thompson-bell wrote:
You don't need it in your kernel. Al you need is USB support then load the module appropriate to your chipset, and there are only two to choose from.
well there are 4 USB chipsets now, but you have a choice of OHCI, UHCI and EHCI.. but you have a choice of 2 modules/drivers for the UHCI chipset which is what i would wager Ricardo has, so he will have to try both of them and see which works better (or at all)
You live an learn. I was not aware of the EHCI chipset. I am running RH7.3 on a Dell 2650 laptop. RH Detected the USB and lsmod shows usb-uhci is loaded but I can see no way of determing which of the two UHCI drivers this is. lspci says the chip is USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02).
Sorry to be pedantic about this but it can be confusing as when you select building the driver into the kernel support for one of the UHCI chipsets the option for the other one disappears! which really confused me for a while when i was trying to get my ADSL modem working...
I have never understood why people want to build monolithic kernels. Modules were introduced just so this could be avoided. I can understand rebuilding to get rid of unused stuff but surely modules are more flexible and resource efficient?
ian
On Sun, Sep 08, 2002 at 06:46:07PM +0100, Ian Thompson-bell wrote:
I have never understood why people want to build monolithic kernels. Modules were introduced just so this could be avoided. I can understand rebuilding to get rid of unused stuff but surely modules are more flexible and resource efficient?
It depends, i tend to build modules for things that i don't often use or require but if it something is in use 24/7 (like the usb for my modem) then it gets built in statically. Also the reason my USB support got built in was in the early days of 2.4 series kernel the modules did not load reliably and as i had a USB mouse I found i had to built it into the kernel. The real issue with the 2 drivers for the UHCI chipsets imho is a bug, as I am 99% sure that when i originally built the kernels there was only 1 driver, the bit where the kernel configurator hides the option that is still relevant and applicable is wrong. They could have at least changed the option to show it is there but not selectable in this case.
Adam
On Sunday 08 Sep 2002 7:20 pm, Adam Bower wrote:
On Sun, Sep 08, 2002 at 06:46:07PM +0100, Ian Thompson-bell wrote:
I have never understood why people want to build monolithic kernels. Modules were introduced just so this could be avoided. I can understand rebuilding to get rid of unused stuff but surely modules are more flexible and resource efficient?
It depends, i tend to build modules for things that i don't often use or require but if it something is in use 24/7 (like the usb for my modem) then it gets built in statically.
Why? What is the advantage?
Also the reason my USB support got built in
was in the early days of 2.4 series kernel the modules did not load reliably and as i had a USB mouse I found i had to built it into the kernel. The real issue with the 2 drivers for the UHCI chipsets imho is a bug, as I am 99% sure that when i originally built the kernels there was only 1 driver, the bit where the kernel configurator hides the option that is still relevant and applicable is wrong. They could have at least changed the option to show it is there but not selectable in this case.
If you build these two different USB modules, how are they differentiated?
ian
On Sun, Sep 08, 2002 at 09:21:32PM +0100, Ian Thompson-bell wrote:
It depends, i tend to build modules for things that i don't often use or require but if it something is in use 24/7 (like the usb for my modem) then it gets built in statically.
Why? What is the advantage?
like i said when the kernel refused to load the modules it made sense to build things in, I have had this problem many times when using modular kernels and got really annoyed with building a kernel and then finding out i had to rebuild it with something compiled in. Anyhow what is the disadvantage?
If you build these two different USB modules, how are they differentiated?
I just read the kernel docs and one is called usb-uhci and the other is called just uhci.
Adam
On Sunday 08 Sep 2002 9:35 pm, Adam Bower wrote:
On Sun, Sep 08, 2002 at 09:21:32PM +0100, Ian Thompson-bell wrote:
It depends, i tend to build modules for things that i don't often use or require but if it something is in use 24/7 (like the usb for my modem) then it gets built in statically.
Why? What is the advantage?
like i said when the kernel refused to load the modules it made sense to build things in, I have had this problem many times when using modular kernels and got really annoyed with building a kernel and then finding out i had to rebuild it with something compiled in. Anyhow what is the disadvantage?
Assuming modules load OK then the advantage is not having to recompile a kernel every time a better module becomes available or your hardware changes and you need additional modules.
If you build these two different USB modules, how are they differentiated?
I just read the kernel docs and one is called usb-uhci and the other is called just uhci.
Thanks.
Ian
On Mon, Sep 09, 2002 at 08:11:53PM +0100, Ian Thompson-bell wrote:
Assuming modules load OK then the advantage is not having to recompile a kernel every time a better module becomes available or your hardware changes and you need additional modules.
I usually find its far quicker to just build a new kernel and not have to muck around with modules that don't load and dependancy lists that don't work etc. etc. in all modules would be a nice system if they were reliable and dependable which in my experience of linux (kernel trees 2.0 2.2 and 2.4) they are not it is not really worth any effort trying to make something work which doesn't and you may as well build things statically.
2p Adam
Assuming modules load OK then the advantage is not having to recompile a kernel every time a better module becomes available or your hardware
changes
and you need additional modules.
I usually find its far quicker to just build a new kernel and not have to
muck
around with modules that don't load and dependency lists that don't work
etc.
etc. in all modules would be a nice system if they were reliable and
dependable
which in my experience of linux (kernel trees 2.0 2.2 and 2.4) they are
not it
is not really worth any effort trying to make something work which doesn't
and
you may as well build things statically.
2p Adam
I go along with Adam on this. I started off generating modules all over the place with my first kernel builds (2.4.18) and got into all sorts of trouble (mainly because I didn't understand what I was doing at the time, so not really an valid argument). So I switched to a fully static build just to get things working.
Now I understand what's going on a bit more, I've found building a modularized kernel and building a static kernel makes very little real difference to the sort of system I have (single user home system) either in performance or kernel size. It takes me less than 1/2 hour to build another kernel and get it installed and working. Over the past couple of months the kernel has grown by a _whole_ 200k as the functionality has been increased. Performance is exemplary (as always).
At a theoretical level I think Ian is correct and I think that the logic and rationale behind the module concept is very powerful but in practice the actual advantages are negligible. I suspect it's horses for courses and a scenario can be constructed where having a modular kernel would be really advantageous (I'll leave that as a exercise for the reader! :o) ).
2d
Keith ____________ In theory there should be no difference between theory and practice. In practice there's always a difference between practice and theory.
On Tuesday 10 Sep 2002 9:07 am, Adam Bower wrote:
On Mon, Sep 09, 2002 at 08:11:53PM +0100, Ian Thompson-bell wrote:
Assuming modules load OK then the advantage is not having to recompile a kernel every time a better module becomes available or your hardware changes and you need additional modules.
I usually find its far quicker to just build a new kernel and not have to muck around with modules that don't load and dependancy lists that don't work etc. etc. in all modules would be a nice system if they were reliable and dependable which in my experience of linux (kernel trees 2.0 2.2 and 2.4) they are not it is not really worth any effort trying to make something work which doesn't and you may as well build things statically.
2p Adam
I guess it boils down to personal experience. I spent absoluitely ages just getting my first kernel to run (compiling was no problem) and I have great difficulty in understand what i should do with each option in config in order to support the hardware I have. With modules I start with a kernel i know works, I can insmod a module and if it works keep it in modules.conf
ian
-
Adam Bower -
Ian Thompson-bell -
Keith Watson -
Ricardo Campos