| 1 |
Corbin Bird <corbinbird <at> charter.net> writes: |
| 2 |
|
| 3 |
> The hardware ID's database may need to be updated ( or supplemented ). |
| 4 |
> The package "sys-apps/pciutils" has the hardware database included in it. |
| 5 |
|
| 6 |
looking at the ebuild for 'pci-utils' we see:: |
| 7 |
|
| 8 |
RDEPEND="${DEPEND} |
| 9 |
sys-apps/hwids |
| 10 |
|
| 11 |
So if you want the latest data on hwids, install:: |
| 12 |
'sys-apps/hwids-99999999' |
| 13 |
|
| 14 |
> I have a 990FX chipset MB that is constantly ID as a 880 chipset board. |
| 15 |
> No info on 990FX chipsets found in the hardware ID's database. |
| 16 |
> The kernel keeps applying a 880 chipset workaround for the PCI bus, |
| 17 |
> every boot. |
| 18 |
> |
| 19 |
> Same problem I think, different hardware. |
| 20 |
|
| 21 |
OK, so both of you guys should use serial sniffers and usb sniffers and log |
| 22 |
those sessions on a separate machine for rigorous analysis. Commercial |
| 23 |
sniffers are very user friendly. Some cheap embedded boards can sniff usb |
| 24 |
readily (but you'll have to search them out yourself). |
| 25 |
|
| 26 |
For a usb sniffer, you may need special hardware to intercept those singnals |
| 27 |
from the actual communications link. sniffing from inside |
| 28 |
of a host is sometime problematic on catching every charcter, timings, |
| 29 |
and other such critical signal information. sniffing RS-232 is well |
| 30 |
documented around the net. When I sniff usb, I try to first use usb-1.0 |
| 31 |
or 1.1, as the slower speeds are easier to watch and collect critical data. |
| 32 |
|
| 33 |
good-hunting. |
| 34 |
|
| 35 |
hth, |
| 36 |
James |
Archives