hwd speed can't be beat

phrakture · 2004-12-02 18:55:16

Hey all, just like to report on some progress with hwd and lshwd

Thanks to z4ziggy and rasat (along with some minor input from myself) the archlinux hardware detection provided by hwd/lshwd is now faster than kudzu (redhat) and knoppix... monitor detection in both of these is very sluggish, and now hwd takes less than a second (or about 0.2s on non-DDC setups) whereas knoppix usually takes about 3-10 seconds... and runs about the same on a non-DDC setup.

right now, I seriously doubt the speed/accuracy of this setup can be beaten - but it's going to require some testing.

anyone interested in helping out with this?

dekernel · 2004-12-02 18:58:41

What kind of help are you looking for?
I am only really good for testing for which I volunteer.

phrakture · 2004-12-02 19:07:11

eh, just kinda wondering if people would be willing to maybe throw in knoppix or something (or one of the other new-fangled live CDs like that), and kinda time the hardware detection. during boot it'd be hard, so I would recommend running the detection scripts after boot with the "time" command.

then on the same machine, try the arch version.

it's easy to say it works great with my setup, but this is supposed to be generic and I would like to see how it works on other's machines.

you can go here to grab the CVS packages:
http://www.bliss-solutions.org/archlinu … /index.php
Login with guest/guest

it's not that big of a deal, i just figured if anyone was interested, just go ahead and post some results in this thread...

i3839 · 2004-12-02 19:43:32

And what to do if you get thw following?

» Zugriff verweigert.
Bitte identifizieren Sie sich.

Some link to a downloadable lshwd or the cvs command we can use to get it would be useful... Requiring to sigh up to just download some free software is kinda silly.

phrakture · 2004-12-02 19:45:29

oh sorry, use guest/guest

i3839 · 2004-12-02 21:57:21

The generated tgz package had bad file permissions set so it couldn't extract all files, thanks to an unreadable/writable/executable dir where files needed to be put...

The makefile is broken, so make starts yelling, and when slightly changing the thing so that it at least starts compiling, then gcc spits out way too many errors and gives up...

I wonder how you can even work on the thing with such broken environment/setup...

Good luck...

xerxes2 · 2004-12-02 21:59:51

the binary worked for me, named lshwd,

z4ziggy · 2004-12-02 22:33:10

thats strange. i thought it might be due to the web-cvs zip download, but all permission and compile worked fine for me. this is what i did :
login guest/guest
select lshwd development
select the lshwd checkbox and press download

basicly all files and 1 sub-directories (pcmcia) from lshwd should be extracted properly. the makefile is a very simple hand-made generated - just open it up and edit if u think something is missing - i'd love to fix whatever errors it may have...

[EDIT]
also, in order to compile you must have latest pciutils package and usbutils.

phrakture · 2004-12-02 22:35:04

i3839 wrote:

The generated tgz package had bad file permissions set so it couldn't extract all files, thanks to an unreadable/writable/executable dir where files needed to be put...
The makefile is broken, so make starts yelling, and when slightly changing the thing so that it at least starts compiling, then gcc spits out way too many errors and gives up...
I wonder how you can even work on the thing with such broken environment/setup...
Good luck...

works fine here too

i3839 · 2004-12-03 12:13:40

Thanks to the lack of permission info, the zip version did work, but the tar version didn't because the files have bad permissions and the files that are in the pcmcia dir can't be extracted because the pcmia dir is unwritable and unexecutable.

Installing the pciutils and usbutils packages fixed all compiling problems though, so it would be a good idea to add that to the readme or something. :-)

z4ziggy · 2004-12-03 13:55:33

tnx man.
i will ask rasat on his return to look into tar.gz, maybe its something on the cvs...

regarding the readme - yep, need to add compiling instructions and used-files list. will do it today.

z4ziggy · 2004-12-05 01:31:47

u were right i3839, permissions were wrong on sources... sorry for that. i fixed it - tnx for pointing that out.
i also added dependency packages and used-files to the README.

also, firewire is now supported and full X info is added for generating compatible Xconfig and showing valid gfx card module...

i3839 · 2004-12-05 03:25:38

The permissions are still somewhat wrong: source files don't need execution permission. Other than that it's fine.

The output I get:

lshwd $ time ./lshwd
00:00.0 Host bridge: VIA Technologies|VT82C691 [Apollo PRO] (via-agp)
00:01.0 PCI bridge: VIA Technologies|VT82C598 [Apollo MVP3 AGP] (unknown)
00:07.0 ISA bridge: VIA Technologies|VT82C686 [Apollo Super] (unknown)
00:07.1 IDE interface: VIA Technologies|VT82C586 IDE [Apollo] (via82cxxx)
00:07.2 USB Controller: VIA Technologies|VT82C586B USB (uhci_hcd)
00:07.3 USB Controller: VIA Technologies|VT82C586B USB (uhci_hcd)
00:07.4 SMBus: VIA Technologies|VT82C686 [Apollo Super ACPI] (i2c-viapro)
00:07.5 Multimedia audio controller: VIA Technologies|VT82C686 [Apollo Super AC97/Audio] (snd-via82xx)
00:0e.0 Ethernet controller: Realtek|RTL-8029(AS) (ne2k-pci)
00:0f.0 Ethernet controller: Realtek|RTL-8139 (8139too)
01:00.0 VGA compatible controller: nVidia Corp.|Riva TNT2 Model 64 (vesa)
real 0m0.157s
user 0m0.057s
sys 0m0.017s
cpu 47.06%

I think I should be able to use at least the nv driver instead of the vesa one, so telling me to use vesa is a bit silly, especially if virtually all cards support vesa. And just printing out the videocard info isn't exactly "full X info". ;-)

Compared to hotplug:

etc # time ./rc.d/hotplug start
:: Starting Hotplug Daemon [DONE]
real 0m5.376s
user 0m1.505s
sys 0m0.990s
etc # lsmod
Module Size Used by
pwc 78000 0
videodev 7264 1 pwc
uhci_hcd 27952 0
usbcore 99652 4 pwc,uhci_hcd
via686a 16864 0
i2c_sensor 2816 1 via686a
i2c_isa 1632 0
i2c_core 18672 3 via686a,i2c_sensor,i2c_isa
nvidia 4812180 12
8139too 20992 0
mii 3936 1 8139too

It finds more, but also takes a lot longer.

z4ziggy · 2004-12-05 03:51:02

u r right about it all, so lets take it 1 step at a time.
about the vesa<>nv, can u please execute "hwsetup -v" (u need to have hwd package installed) and see if u get the proper "nv" module? also, if u may, please post me the "lspci -n" & "lspci" outputs so i can see what card is it. we should look if the card's info is in pcitable, and if so, if its the x-info generator which changes to vesa if not found in Cards file.

i839 wrote:

And just printing out the videocard info isn't exactly "full X info". ;-)

true, the code is there, however, i havnt decided yet how to output it - as a tmp file, to /etc/sysconfig, or whatever... need to consult rasat on that when he's back. till then, we can refer to it as - "full x-info implemented but not yet displayed"

regarding the file permissions, i double checked it again, its the damn web-cvs - it tars the files with wrong permissions... i'll ask rasat to fix it asap on his return.

last thing, to REALLY test performance, the "-a" should be used to actually load those modules then booting, and then comparing to hotplug. also, hotplug finds more modules since its obviously superior over lshwd in term of modules supported... im thinking of adding sensors detection, need to look into it a bit more...

tnx again for your input.

[edit]
ps.
i am amazed of the timings though... NICE...

i3839 · 2004-12-05 16:33:35

hwsetup -v output for my videocard:

class: VIDEO
bus: PCI
device: fb0
driver: Card:RIVA TNT2
desc: nVidia Corp.|Riva TNT2 Model 64

So it doesn't say vesa directly, nor nv.

Lspci's output is more or less the same as lshwd's output (surprise ;-):

~ $ lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC Bus Master IDE (rev 10)
00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 10)
00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 10)
00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 20)
00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
01:00.0 VGA compatible controller: nVidia Corporation RIVA TNT2 Model 64 (rev 15)

~ $ lspci -n
00:00.0 Class 0600: 1106:0691 (rev c4)
00:01.0 Class 0604: 1106:8598
00:07.0 Class 0601: 1106:0686 (rev 22)
00:07.1 Class 0101: 1106:0571 (rev 10)
00:07.2 Class 0c03: 1106:3038 (rev 10)
00:07.3 Class 0c03: 1106:3038 (rev 10)
00:07.4 Class 0c05: 1106:3057 (rev 30)
00:07.5 Class 0401: 1106:3058 (rev 20)
00:0e.0 Class 0200: 10ec:8029
00:0f.0 Class 0200: 10ec:8139 (rev 10)
01:00.0 Class 0300: 10de:002d (rev 15)

As you also could have seen with lshwd's output, it's a Nvidia TNT2 card (model 64). If that doesn't ring a bell: TNT2 was the last card before the Geforce 1, so quite enough time to put it in some list.

I use a cutom kernel with most things build in and not as modules. Besides, it's about hardware detection, not module loading. The info from hotplug was more to show all the stuff that's present, and to show how way too long it takes to figure that out (and load the modules, but still). Hotplug is hard to beat in functionality: It basically finds everything, it calls also udev so the device files can be made and allows custom scripts which are called when the device of your choice is detected (useful for things like automatic network connection setup with e.g. usb modems). Weak point of hotplug is that it's only good at finding devices when they're plugged in, so the /sys scanning and shellscript bouncing at startup with /etc/rc.d/hotplug start is way too slow. A lacking feature is automatic X config generation, but that shouldn't be hotplug's task anyway, IMHO that's something that X should have build in, something that's good and fast enough to do at each startup (utopia?). It doesn't help that not all hardware is easily autoconfigured.

I don't see the use of a /etc/sysconfig directory, as the goal seems to be fast autoconfiguration and Arch doesn't use sysconfig anyway. Full x info includes monitor setup stuff, one of the hardest things to reliably autodetect well. If you're lucky the monitor supports autodetection (DCC or whatever), but even if it does it can give unreliable info, thus not using the monitor optimally. Also doing input devices detection when not being able to count on /dev/input/* may be hard (serial mouse/keyboard, usb things, etc).

z4ziggy · 2004-12-05 16:53:26

as always, you are right...

lshwd is not aiming to replace hotplug, only to allow quick hardware detection for live-cds mostly and linux n00bs, ie, mainly hwsetup replacement. as far as modules display and load, as said, it should be used for ppl who using generic kernel and havnt built their custom kernel with their own modules (yet...).

about your RIVA TNT2 card - i checked the pcitable and i have found your card info (as shown on your initial post). i then looked at /usr/share/hwdata/Cards and found the corresponding xinfo there. my guess is you dont have hwd installed or dont have latest /usr/share/hwdata/Cards file (see the README for latest files). please correct me if im wrong on this. i made a quick hack to my sources to detect my gfx card as yours (nVidia Corp.|Riva TNT2 Model 64) and it did return the proper module : nv. this is why im guessing its something with the /usr/share/hwdata/Cards ... also, try to compile with "-DDEBUG", maybe it will show u further info.

please check the card info by hand, lets try to diagnose it... if you DO have all files, then im guessing its a bug report, ea? :

i3839 · 2004-12-05 17:09:53

I found out why it didn't seem to work: I run hwsetup as user, and /usr/share/hwdata/Cards isn't user readable (install bug?). When I run it as root "nv" is given as expected.

z4ziggy · 2004-12-05 18:47:24

as far as /usr/share/hwdata/Cards permissions, yep, i see no reason for having root only. however, as far has hardware detection goes, i think the hwd script (which takes care of executing lshwd, creating full x config, man page, etc) will require root priv, and maybe even lshwd itself for opening devices.

in anyway, im glad we are dealing with those issues before releasing lshwd, and for finally lshwd to work for u

i3839 · 2004-12-05 19:20:58

In general I won't trust any autoconfig stuff to run as root, especially if they're in development. And that shouldn't be required anyway, because you uset he system as user you'll have the access to all devices you may use, thus you shouldn't need to have root privileges to do proper autodetection. You only need root to load modules, but that's independend of the autodetection.

z4ziggy · 2004-12-05 19:25:42

noted.
i will wait for rasat (he is due to return on the 8th or so) to conclude those issues as they reflect more on hwd than lshwd (except for auto-modprobe).
in the meanwhile, i will continue to look into sensor stuff and maybe add this to lshwd - im open to ideas/comments

tnx again for your info.

i3839 · 2004-12-05 19:47:48

I would leave sensors for later, it's rather low priority stuff as it isn't important for a properly functioning system. As for detection, lm_sensors comes with a program "sensors-detect" which does the detection and says which modules must be loaded. It does need root access to do the probing, or at least it requires it. I would concentrate on getting good X config files first, then focus on networking stuff and other more important things to get a livecd functioning properly.

z4ziggy · 2004-12-05 21:44:57

true, but :
networking is part of pci/pcmcia/whatever, and i dont see what else is needed. also, current networking devices which are mapped to modules will be displayed per device.
regarding the x info, we will be able to produce full x config info once i will generate it to a file (as mentioned earlier, need to conclude with rasat how he prefers to output the gfx section) plus the info used from ddcxinfo-arch - this is all part of the hwd script to rap those tools and produce full X config.
regarding the sensors, yes, i was thinking of looking into the sensors-detect sources to look for their enum functions, i just need to find time for that... volunteers?

if u have c coding experience, please feel free to add yourself whatever changes u think are necessary to the web-cvs. i hope user GUEST is sufficient for the time being until rasat's return.

i3839 · 2004-12-05 22:52:35

With networking I mean the whole config until the point you have internet access, with minimal info provided by the user. But I'm aware that that isn't really part of your project (although it would be great for a livecd).

Time is scarce. ;-)

z4ziggy · 2004-12-05 23:09:45

hmm... nice... i didnt think about it, mainly since im a happy dhcp lamer (cant thank enough for being behind a router...)
any ideas/suggestions of what/how this networking wizard should do/operate? i can imagine, it will be highly usefull for first timers...
as i said, i myself am behind a dhcp router, but i know there are many problems with the israeli linux users which are forced to use a specific script even with a dsl network, so any automatic detection will be a perfect solution
one thing which comes to mind however, is several inputs (dns, gw, etc) which should be provided manually since they cant be retrieved automatically, as far as i know. do share your thoughts on the subject

i3839 · 2004-12-05 23:42:26

Internet config is hard to do, because there are so many configs possible. If it was just ethernet with dhcp or static ip then it would be easy. Some other configs possible: serial modem with PPP and dialup, DSL with PPPoA (ppp over ATM, used for instance with usb adsl modems), PPPoE (ppp over ethernet, used with ethernet modems), PPTP may be used too, that's tunneled through ppp and used for authentication (hopefully rare, it's ugly and insecure). Then there are the numerous wireless things I don't know of, but those use most likely dhcp for the IP stuff, so that's probably easier in some ways. And a lot DSL setting depend on which ISP you have, to make things more complicated. And to finish it off it's impossible to test setups you don't have yourself. All in all it's a cute little nightmare.

The tool would should probably figure out/get a list of network devices it needs to configure, then it asks the user for the required info. Or the other way round; the user starts it up and then can configure easily whatever network setup is present. Sort of combining all those seperate tools (like netcardconfig of Knoppix, that pppoe tool some wireless thing, at the least). It then does everything needed to get it working (which is painfully lot when having a Speedtouch USB ADSL modem). DNS is easy because often it's provided by PPP or DHCP, and you can always setup some default ones which are slow but should always work.

I wanted to make a livecd once, until I found out how damn ugly cd's are: Slow, noisy, cd-writers don't follow standards, etc. That said, maybe I had too high expectations.

Stick to your hardware setup for the while being. ;-)

Arch Linux

#1 2004-12-02 18:55:16

hwd speed can't be beat

#2 2004-12-02 18:58:41

Re: hwd speed can't be beat

#3 2004-12-02 19:07:11

Re: hwd speed can't be beat

#4 2004-12-02 19:43:32

Re: hwd speed can't be beat

#5 2004-12-02 19:45:29

Re: hwd speed can't be beat

#6 2004-12-02 21:57:21

Re: hwd speed can't be beat

#7 2004-12-02 21:59:51

Re: hwd speed can't be beat

#8 2004-12-02 22:33:10

Re: hwd speed can't be beat

#9 2004-12-02 22:35:04

Re: hwd speed can't be beat

#10 2004-12-03 12:13:40

Re: hwd speed can't be beat

#11 2004-12-03 13:55:33

Re: hwd speed can't be beat

#12 2004-12-05 01:31:47

Re: hwd speed can't be beat

#13 2004-12-05 03:25:38

Re: hwd speed can't be beat

#14 2004-12-05 03:51:02

Re: hwd speed can't be beat

#15 2004-12-05 16:33:35

Re: hwd speed can't be beat

#16 2004-12-05 16:53:26

Re: hwd speed can't be beat

#17 2004-12-05 17:09:53

Re: hwd speed can't be beat

#18 2004-12-05 18:47:24

Re: hwd speed can't be beat

#19 2004-12-05 19:20:58

Re: hwd speed can't be beat

#20 2004-12-05 19:25:42

Re: hwd speed can't be beat

#21 2004-12-05 19:47:48

Re: hwd speed can't be beat

#22 2004-12-05 21:44:57

Re: hwd speed can't be beat

#23 2004-12-05 22:52:35

Re: hwd speed can't be beat

#24 2004-12-05 23:09:45

Re: hwd speed can't be beat

#25 2004-12-05 23:42:26

Re: hwd speed can't be beat

Board footer