[ANNOUNCE] Hardware detection tool 0.2

[ANNOUNCE] Hardware detection tool 0.2

[Carlos E Gorges]

Hardware detection tool 0.2

The main idea is keep a unified database of modules and 
create a good tool for hardware configurators.

This version supports detection of PCI, ISA PnP and USB (hotplug) devices.

ftp://ftp.techlinux.com.br/pub/people/carlos/kernel/hwd/hwd-0.2.tar.bz2
ftp://ftp.techlinux.com.br/pub/people/carlos/kernel/hwd/hwd-0.2-linux248-ac11.patch.bz2


cya;
-- 
	 _________________________
	 Carlos E Gorges          
	 (carlos@techlinux.com.br)
	 Tech informática LTDA
	 Brazil                   
	 _________________________

Re: [ANNOUNCE] Hardware detection tool 0.2

[Greg KH]

On Thu, Aug 30, 2001 at 07:40:25PM -0300, Carlos E Gorges wrote:
> Hardware detection tool 0.2
> 
> The main idea is keep a unified database of modules and 
> create a good tool for hardware configurators.

Why don't you just pull the PCI and USB module information out of the
drivers themselves?  All the information you need it in the
MODULE_DEVICE_TABLE() macro.  You don't get a pretty vendor string for
most all of the USB devices that use a USB class spec, but that isn't
necessary.

All you are caring about is what device is supported by what module,
right?  That can be easily determined by the info in the modules.usbmap
and modules.pcimap files in the /lib/modules/<kernel_version>/
directory.

Keeping tables like these will be a tough thing to do, that's why the
linux-hotplug project relies on the drivers themselves to do the work.

thanks,

greg k-h

Re: [ANNOUNCE] Hardware detection tool 0.2

[jeff millar]

----- Original Message -----
From: "Greg KH" <greg@kroah.com>
To: "Carlos E Gorges" <carlos@techlinux.com.br>
Cc: <linux-kernel@vger.kernel.org>
Sent: Thursday, August 30, 2001 7:18 PM
Subject: Re: [ANNOUNCE] Hardware detection tool 0.2


> On Thu, Aug 30, 2001 at 07:40:25PM -0300, Carlos E Gorges wrote:
> > Hardware detection tool 0.2
> >
> > The main idea is keep a unified database of modules and
> > create a good tool for hardware configurators.
>
> Why don't you just pull the PCI and USB module information out of the
> drivers themselves?  All the information you need it in the
> MODULE_DEVICE_TABLE() macro.  You don't get a pretty vendor string for
> most all of the USB devices that use a USB class spec, but that isn't
> necessary.

One reason: Not all hardware has the signals needed to detect when a card
gets plugged or unplugged.  Consider legacy cPCI systems.  The don't have
the Hot Swap extensions or backplane hot swap control.  The only way to find
the cards is to periodically scan the bus for new cards, cards that
disappeared, or requests for Hot Swap.

SMP, APIC and networking issues...

[java programmer]

Hi all:

There have been some recent posts regarding some
SMP/register corruption bugs.

Searching the archives, there have also been some
reports with both 3com and intel ethernet cards
hanging after an N amount of time, where N = a couple
of days to 2 weeks. That is, the nic's will behave
nicely for some time and then totally hang - are not 
even pingable. This happens on SMP machines and is
believed to be caused by some APIC/interrupt issues.

I have seen the exact same behavior on 2.4.7 with
a intel pro/100 ethernet 64 bit PCI nic on a SMP
intel chipset. Stress testing and transferrring 
Gbytes of data thru the nic works fine after the 
machine is rebooted but after say 3 days, the 
card just hangs. (this happens with both intel 
supplied and kernel supplied drivers, e100, eepro100)

After the hang, logging in via the console and
saying ifconfig (for eth1, I have also blacked
out the IP address) shows the following:

eth1      Link encap:Ethernet  HWaddr
00:50:8B:E3:AA:B5
inet addr:x.x.x.x  
Bcast:66.37.140.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500 
Metric:1
          RX packets:6232292 errors:0 dropped:0
overruns:0 frame:0
          TX packets:7098591 errors:0 dropped:0
overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:2693585563 (2568.8 Mb)  TX
bytes:2786888257 (2657.7 Mb)
          Interrupt:15 Base address:0x4000

The supposed trick is to boot with a  "noapic" 
option, since this is believed to be a APIC issue, 
not a driver issue (as mentioned, this problem 
has been seen for both 3com and intel cards).

Is "noapic" still the recommended approach for SMP
kernels or is it advisable to use 2.4.9 to solve 
this specific issue ?

Best regards,

javadesigner



__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

Re: [ANNOUNCE] Hardware detection tool 0.2

[Greg KH]

On Fri, Aug 31, 2001 at 06:58:59PM -0400, jeff millar wrote:
> 
> One reason: Not all hardware has the signals needed to detect when a card
> gets plugged or unplugged.  Consider legacy cPCI systems.  The don't have
> the Hot Swap extensions or backplane hot swap control.  The only way to find
> the cards is to periodically scan the bus for new cards, cards that
> disappeared, or requests for Hot Swap.

But the driver for those devices have a struct pci_driver object that
they use to register themselves with the PCI subsystem, right?  The
MODULE_DEVICE_TABLE uses the id_table structure in the struct pci_driver
object.  That's all, it isn't necessarily a hotplug specific thing.

And having that MODULE_DEVICE_TABLE for those drivers will allow the
kernel to load those modules when the bus is scanned for new cards, like
on boot :)

thanks,

greg k-h

Re: SMP, APIC and networking issues...

[Alan Cox]

> The supposed trick is to boot with a  "noapic" 
> option, since this is believed to be a APIC issue, 
> not a driver issue (as mentioned, this problem 
> has been seen for both 3com and intel cards).
> 
> Is "noapic" still the recommended approach for SMP
> kernels or is it advisable to use 2.4.9 to solve 
> this specific issue ?

If you are still seeing the problem then yes try noapic, but also let
me know if its happening with current kernels. The apic has multiple effects
and not all of them are necessarily hardware issues at all

The big one is that interrupts can get delayed and become much more 
asynchronous which can obviously have impacts on driver races

Re: [ANNOUNCE] Hardware detection tool 0.2

[jeff millar]

What bus and slot number does the driver use to register itself before the
plugging the card?

----- Original Message -----
From: "Greg KH" <greg@kroah.com>
To: "jeff millar" <jeff@wa1hco.mv.com>
Cc: "Carlos E Gorges" <carlos@techlinux.com.br>;
<linux-kernel@vger.kernel.org>
Sent: Friday, August 31, 2001 7:23 PM
Subject: Re: [ANNOUNCE] Hardware detection tool 0.2


> On Fri, Aug 31, 2001 at 06:58:59PM -0400, jeff millar wrote:
> >
> > One reason: Not all hardware has the signals needed to detect when a
card
> > gets plugged or unplugged.  Consider legacy cPCI systems.  The don't
have
> > the Hot Swap extensions or backplane hot swap control.  The only way to
find
> > the cards is to periodically scan the bus for new cards, cards that
> > disappeared, or requests for Hot Swap.
>
> But the driver for those devices have a struct pci_driver object that
> they use to register themselves with the PCI subsystem, right?  The
> MODULE_DEVICE_TABLE uses the id_table structure in the struct pci_driver
> object.  That's all, it isn't necessarily a hotplug specific thing.
>
> And having that MODULE_DEVICE_TABLE for those drivers will allow the
> kernel to load those modules when the bus is scanned for new cards, like
> on boot :)
>
> thanks,
>
> greg k-h
>

Re: [ANNOUNCE] Hardware detection tool 0.2

[Greg KH]

On Fri, Aug 31, 2001 at 07:46:38PM -0400, jeff millar wrote:
> What bus and slot number does the driver use to register itself before the
> plugging the card?

I don't understand what you are asking here.
In pci_module_init you pass a pointer to your struct pci_driver object
that describes to the pci subsystem what kind of pci devices that your
driver works for.  It does this with the id_table pointer which is a
struct pci_device_id.

MODULE_DEVICE_TABLE takes that struct pci_device_id table and exports it
to an area in the module object table that allows it to be extracted by
depmod.  depmod takes that info and creates
/lib/modules/<kernel_version/modules.pcimap from it.  So any userspace
code can then look at the modules.pcimap file and determine what kind of
pci devices each module is claiming it supports.

Using that table, combined with tools like lspci, a userspace program
can build a table of kernel modules that a given hardware platform
needs.  And if it wants to, from the kernel module list, it can generate
a .config file, which is what I think Carlos is trying to do.  And what
I thought this thread was talking about.

This whole process did not involve any hotplug stuff at all.

But if you want to use it for hotplug you can :)
See my OLS 2001 paper and presentation at http://www.kroah.com/linux/
and http://linux-hotplug.sf.net/ which contains lots of good
documentation if you want to know more on how the linux-hotplug
subsystem currently works.

Did that help?

thanks,

greg k-h

Re: [ANNOUNCE] Hardware detection tool 0.2

[Tim Jansen]

On Friday 31 August 2001 00:40, Carlos E Gorges wrote:
> Hardware detection tool 0.2
> The main idea is keep a unified database of modules and
> create a good tool for hardware configurators.

The next version of the device registry patch (http://www.tjansen.de/devreg) 
will contain a similar feature. 
In the current release bus drivers (like PCI, USB..) register their devices 
in the registry and the devices are then displayed in a generic, 
bus-independent form in the /proc/devreg directory.
In the upcoming version those drivers with devreg support register themselves 
on initialization and also register each driver instance (an instance handles 
a single physical device) that they create. The instance will then be 
connected to the device, devfs nodes will be connected to the driver instance 
and you can get a pretty good graph of the relations between drivers, driver 
instances, devfs nodes/minor numbers and the physical devices.

bye...

Re: SMP, APIC and networking issues...

[Jorge Nerin]

Alan Cox wrote:
>>The supposed trick is to boot with a  "noapic" 
>>option, since this is believed to be a APIC issue, 
>>not a driver issue (as mentioned, this problem 
>>has been seen for both 3com and intel cards).
>>
>>Is "noapic" still the recommended approach for SMP
>>kernels or is it advisable to use 2.4.9 to solve 
>>this specific issue ?
>>
> 
> If you are still seeing the problem then yes try noapic, but also let
> me know if its happening with current kernels. The apic has multiple effects
> and not all of them are necessarily hardware issues at all
> 
> The big one is that interrupts can get delayed and become much more 
> asynchronous which can obviously have impacts on driver races

I'm having nic hangs with recent kernels, the last one in wich I saw 
this is with 2.4.9-ac3, and I'm currently running 2.4.9-ac5, the nic is 
a 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 64) linked with a 
twisted cable to another computer.

I have a dual 200mmx, motherboard is a gigabyte 586dx, lots of apic 
errors, but so far not a lot of hangs, is home machine, no server.

Aug 27 15:50:26 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 27 15:50:26 quartz kernel: eth0: transmit timed out, tx_status 00 
status e601.
Aug 27 15:50:26 quartz kernel:   diagnostics: net 0cf2 media 8880 dma 
0000003a.
Aug 27 15:50:26 quartz kernel: eth0: Interrupt posted but not delivered 
-- IRQ blocked by another device?
Aug 27 15:50:26 quartz kernel:   Flags; bus-master 1, dirty 149028(4) 
current 149028(4)
Aug 27 15:50:26 quartz kernel:   Transmit list 00000000 vs. c51cf300.
Aug 27 15:50:26 quartz kernel:   0: @c51cf200  length 80000062 status 
00010062
Aug 27 15:50:26 quartz kernel:   1: @c51cf240  length 80000062 status 
00010062
Aug 27 15:50:26 quartz kernel:   2: @c51cf280  length 80000062 status 
80010062
Aug 27 15:50:26 quartz kernel:   3: @c51cf2c0  length 80000062 status 
80010062
Aug 27 15:50:26 quartz kernel:   4: @c51cf300  length 8000006e status 
0001006e
Aug 27 15:50:26 quartz kernel:   5: @c51cf340  length 8000006e status 
0001006e
Aug 27 15:50:26 quartz kernel:   6: @c51cf380  length 8000006e status 
0001006e
Aug 27 15:50:26 quartz kernel:   7: @c51cf3c0  length 80000062 status 
00010062
Aug 27 15:50:26 quartz kernel:   8: @c51cf400  length 80000062 status 
00010062
Aug 27 15:50:26 quartz kernel:   9: @c51cf440  length 80000062 status 
00010062
Aug 27 15:50:26 quartz kernel:   10: @c51cf480  length 80000062 status 
00010062
Aug 27 15:50:26 quartz kernel:   11: @c51cf4c0  length 80000062 status 
00010062
Aug 27 15:50:26 quartz kernel:   12: @c51cf500  length 80000062 status 
00010062
Aug 27 15:50:26 quartz kernel:   13: @c51cf540  length 80000062 status 
00010062
Aug 27 15:50:26 quartz kernel:   14: @c51cf580  length 80000062 status 
00010062
Aug 27 15:50:26 quartz kernel:   15: @c51cf5c0  length 80000062 status 
00010062

BTW I switched to a rtl8139 from a rtl8029 for speed upgrade, but it was 
slow as a dog in my system, due to (as someone said) bad motherboard 
chipset for busmaster transfer, and nic hangs, so switched to a 3com 
905, with the same results, speed is somewhat better, but it also hangs.

-- 
Jorge Nerin
<comandante@zaralinux.com>