Recent changes to bugs

Firewire Device Not Being Detected by Card

Chris — Wed, 21 May 2025 21:43:13 -0000

Hello,
I am attempting to use dvgrab to capture footage from my Sony HDR FX1 camera via firewire on a Raspberry pi 5. I am currently on linux kernel version 6.12.28-v8-16k+ on Raspian OS.

The output of 'lspci' is as follows:

0001:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 21)
0001:01:00.0 PCI bridge: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI Bridge [Cheetah Express] (rev 01)
0001:02:00.0 FireWire (IEEE 1394): Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express] (rev 01)
0002:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 21)
0002:01:00.0 Ethernet controller: Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge

I know my firewire card works as I have tested it on a different linux computer with my Sony camera and it works perfectly. I have also tried using a different firewire card -
FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 80) - which yields the same result as the other card on the Raspberry pi.

The output of 'dmesg | grep firewire' is :

[ 2.461857] firewire_ohci 0001:02:00.0: enabling device (0000 -> 0002)
[ 2.461902] firewire_ohci 0001:02:00.0: probe with driver firewire_ohci failed with error -12
[ 2.621208] Modules linked in: brcmfmac snd_soc_hdmi_codec hci_uart brcmutil btbcm drm_display_helper bluetooth cfg80211 cec aes_ce_blk drm_dma_helper aes_ce_cipher rpi_hevc_dec pisp_be ghash_ce gf128mul snd_soc_core sha2_ce ecdh_generic sha256_arm64 ecc v4l2_mem2mem snd_compress sha1_ce videobuf2_dma_contig snd_pcm_dmaengine snd_pcm firewire_ohci(+) rfkill videobuf2_memops videobuf2_v4l2 libaes firewire_core v3d snd_timer videodev sha1_generic snd gpu_sched raspberrypi_hwmon videobuf2_common mc drm_shmem_helper spi_bcm2835 gpio_keys drm_kms_helper i2c_brcmstb raspberrypi_gpiomem rp1_mailbox rp1_adc nvmem_rmem uio_pdrv_genirq uio drm i2c_dev ledtrig_pattern fuse drm_panel_orientation_quirks backlight dm_mod ip_tables x_tables ipv6
[ 2.706995] pc : ar_context_release+0x24/0x80 [firewire_ohci]
[ 2.712766] lr : release_ohci+0x28/0x58 [firewire_ohci]
[ 2.795396] ar_context_release+0x24/0x80 [firewire_ohci]
[ 2.800813] release_ohci+0x28/0x58 [firewire_ohci]
[ 2.853075] fw_ohci_init+0x54/0x3ff8 [firewire_ohci]

Thanks

iMX6 / XIO2213BZAY / Drive Connection

Jason Alden — Mon, 31 Oct 2016 22:41:06 -0000

I am currently trying to find a solution to the below setup

Setup:
The setup consists of a connection from a iMX6 to a XIOO2213BZAY chip via PCI then connected to removable memory modules via firewire

Reference:
I have used the nitrogen6x to model the behavior. Though it is not a complete reprsentation of the actual board we are using for, the Nitrogen6x doesn not have a reset. The same behavior is still seen.

Kernel Version:
I have tested a variety of versions.
3.10.17, 3.10.53, 3.14.52, & 4.1.15

Behavior:
The expected behavior is that the drives would connect every time. Right now the behavior changes depending on the Linux kernel version. We have had the best luck with 3.10.17.

The PCI, firewire_core, firewire_ohci, and firewire_sbp2 drivers all load; however, the sbp2 driver fails at login when sbp2_agent_reset is performed. 'orb->response' from sbp2_send_management_orb is used as the buffer passed into dma_map_single which seems to have mixed up results. Half of the array is always has consistent results, element 0 & 1; meanwhile, element 2 & 3 return as 0x00's more times than not.

In sbp2_login: command_block_agent_address is 281470681743360 (FFFF00000000), I hardcoded the command_block_agent_address to be 0xFFFFF0100000 which allowed the driver to connect to the drive & created the SCSI device. Everything works as expected if I just hardcode that value.
I also modified the driver to do a repeat the DMA read, continuously, if a failure occurs. I have also included a variety of command like 'smp_mb()', 'sync', "echo 3 > /proc/sys/vm/drop_cache" that in some cases would help establish a connection. Once a connection was established I was able to connect to the drives just fine.

There is more information at this link:
https://sourceforge.net/p/linux1394/mailman/message/34243589/

Do you have any ideas what would cause incomplete reading from DMA?
Please see logging below.

Any help is appreciated,
Jason

****** Successful Run *****
sbp2_login: size of response: 16
sbp2_send_management_orb: dma_map_single: DMA_FROM_DEVICE
sbp2_send_management_orb: dev id: 0xD219E868
sbp2_send_management_orb: orb->response_bus: 0x223752B8 ;function: 0x0
sbp2_send_management_orb: lu->tgt->management_agent_address = 0xFFFFF0030000
sbp2_send_management_orb: dma_map_single: DMA_TO_DEVICE
sbp2_send_management_orb: orb->base.request_bus: 0x22375298
sbp2_send_orb 0x22375298
complete_transaction 0x22375298
sbp2_status_write: spin_lock_irqsave
sbp2_status_write: sync
sbp2_status_write: spin_unlock_irqrestore
complete_managment_orb 0x223752B8
sbp2_send_management_orb:wait_for_completion_timeout: 2997 , orb->done = 0 ; timeout = 196611
sbp2_cancel_orbs:
sbp2_send_management_orb: dma_unmap_single: DMA_TO_DEVICE
sbp2_send_management_orb: dma_unmap_single: DMA_FROM_DEVICE
sbp2_send_management_orb: memcpy size = 16
sbp2_send_management_orb: orb->response[0] = 0x1000
sbp2_send_management_orb: orb->response[1] = 0xFFFFC0FF
sbp2_send_management_orb: orb->response[2] = 0x10F0
sbp2_send_management_orb: orb->response[3] = 0x3000000

****** Failed Run *****
sbp2_login: size of response: 16
sbp2_send_management_orb: dma_map_single: DMA_FROM_DEVICE
sbp2_send_management_orb: dev id: 0xD219E868
sbp2_send_management_orb: orb->response_bus: 0x224C4FB8 ;function: 0x0
sbp2_send_management_orb: lu->tgt->management_agent_address = 0xFFFFF0030000
sbp2_send_management_orb: dma_map_single: DMA_TO_DEVICE
sbp2_send_management_orb: orb->base.request_bus: 0x224C4F98
sbp2_send_orb 0x224C4F98
complete_transaction 0x224C4F98
sbp2_status_write: spin_lock_irqsave
sbp2_status_write: sync
sbp2_status_write: spin_unlock_irqrestore
complete_managment_orb 0x224C4FB8
sbp2_send_management_orb:wait_for_completion_timeout: 2997 , orb->done = 0 ; timeout = 196611
sbp2_cancel_orbs:
sbp2_send_management_orb: dma_unmap_single: DMA_TO_DEVICE
sbp2_send_management_orb: dma_unmap_single: DMA_FROM_DEVICE
sbp2_send_management_orb: memcpy size = 16
sbp2_send_management_orb: orb->response[0] = 0x1000
sbp2_send_management_orb: orb->response[1] = 0xFFFFC0FF
sbp2_send_management_orb: orb->response[2] = 0x0
sbp2_send_management_orb: orb->response[3] = 0x0

free_orb 0x224C4F98
firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries)
sbp2_login: command_block_agent_address is 281470681743360 (FFFF00000000), generation is 4
sbp2_set_busy_timeout returned rcode 0x0 (no error)
sbp2_agent_reset: command_block_agent_address is FFFF00000000, generation is 4
sbp2_agent_reset returned rcode 0x7 (address error)

Bug in dc1394_external_trigger_set_source

Anonymous — Tue, 08 Jan 2008 18:03:34 -0000

The routine
dc1394_external_trigger_set_source in control.c of the library lib1394

dc1394error_t
dc1394_external_trigger_set_source(dc1394camera_t *camera, dc1394trigger_source_t source)
{
dc1394error_t err;
uint32_t curval;

if ( (source < DC1394_TRIGGER_SOURCE_MIN) || (source > DC1394_TRIGGER_SOURCE_MAX) ) {
return DC1394_INVALID_TRIGGER_SOURCE;
}

err=GetCameraControlRegister(camera, REG_CAMERA_TRIGGER_MODE, &curval);
DC1394_ERR_RTN(err, "Could not get trigger source");

source-= DC1394_TRIGGER_MODE_MIN;
curval= (curval & 0xFF1FFFFFUL) | ((source & 0x8UL) << 21);
err=SetCameraControlRegister(camera, REG_CAMERA_TRIGGER_MODE, curval);
DC1394_ERR_RTN(err, "Could not set trigger source");
return err;
}

has a check at the beginning to see if the souce value is in the range DC1394_TRIGGER_SOURCE_MIN and DC1394_TRIGGER_SOURCE_MAX and later the souce is normalize by subtracting DC1394_TRIGGER_SOURCE_MIN.
so the normalize rang of source is 0-7.
then source is anded wit 0x8 giveing the result 0.

So dc1394_external_trigger_set_source will omly set the source in REG_CAMERA_TRIGGER_MODE to 0.

2.4.32-System Crash after plugging in FireWire Device

Anonymous — Thu, 23 Nov 2006 11:50:04 -0000

1) I have two stand alone systems, P1 and P2,having Red Hat Linux with kernel version of 2.4.32.
2) I start pinging P2 from P1 system which is but obvious unconnected.
3) Now as soon as I connect P2 system, i.e. bus reset occurs, P1 system crashes.

please revert back.

Umax Powerlook 1000 scanner is recognized but fail to scan

Anonymous — Mon, 13 Nov 2006 15:11:56 -0000

Umax Powerlook 1000 scanner is fully supported in
kernel-2.4.20-8 by Vuescan scanning software. When I
tried use FC3 I discovered that firewire drivers was
broken and the scanner wasn´t recognized. In fedora
core 5 (kernel-2.6.18-1.2200.FC5) the scanner is
recognized but fail to scan due to a bug in sbp2 modile
(SCSI over Firewire).

"The problem is that the driver isn't returning the
full length of the sense data. VueScan is requesting 32
bytes of sense data, but the driver isn't returning all
of the sense data.This works fine for most scanners,
but not for UMAX scanners(Ed Hamrick - Vuescan software)."

Any help would be very much appreciated.

Renan from Brazil

libiec61883: problem into pkg-config version test

marcio_tex — Tue, 30 May 2006 02:43:11 -0000

These vars

pkgconfig_major=`pkg-config --version | sed
's/\([0-9]*\).\([0-9]*\).\([0-9]*\)/\1/'`

pkgconfig_minor=`pkg-config --version | sed
's/\([0-9]*\).\([0-9]*\).\([0-9]*\)/\2/'`

don't works for numbers > 9. Patch attached for fix it.

Regards,

Kernel lockup when plugging device

Anonymous — Sun, 13 Feb 2005 22:26:34 -0000

I just plugged the firewire wire, then I got error
messages :

Feb 13 11:01:01 xxx CROND[27569]: (root) CMD (nice -n
19 run-parts /etc/cron.hourly)
Feb 13 11:40:43 xxx kernel: ohci1394_0: Unrecoverable
error!
Feb 13 11:40:43 xxx kernel: ohci1394_0: Async Req Tx
Context died: ctrl[ffffffff] cmdptr[ffffffff]
Feb 13 11:40:43 xxx kernel: ohci1394_0: Async Rsp Tx
Context died: ctrl[ffffffff] cmdptr[ffffffff]
Feb 13 11:40:43 xxx kernel: ohci1394_0: Async Req Rcv
Context died: ctrl[ffffffff] cmdptr[ffffffff]
Feb 13 11:40:43 xxx kernel: ohci1394_0: Async Rsp Rcv
Context died: ctrl[ffffffff] cmdptr[ffffffff]
Feb 13 11:40:43 xxx kernel: ohci1394_0: Iso Xmit 0
Context died: ctrl[ffffffff] cmdptr[ffffffff]
Feb 13 11:40:43 xxx kernel: ohci1394_0: Iso Xmit 1
Context died: ctrl[ffffffff] cmdptr[ffffffff]
Feb 13 11:40:43 xxx kernel: ohci1394_0: Iso Xmit 2
Context died: ctrl[ffffffff] cmdptr[ffffffff]
Feb 13 11:40:43 xxx kernel: ohci1394_0: Iso Xmit 3
Context died: ctrl[ffffffff] cmdptr[ffffffff]
Feb 13 11:40:43 xxx kernel: ohci1394_0: Iso Recv 0
Context died: ctrl[ffffffff] cmdptr[ffffffff]
match[ffffffff]
Feb 13 11:40:43 xxx kernel: ohci1394_0: Iso Recv 1
Context died: ctrl[ffffffff] cmdptr[ffffffff]
match[ffffffff]
Feb 13 11:40:43 xxx kernel: ohci1394_0: Iso Recv 2
Context died: ctrl[ffffffff] cmdptr[ffffffff]
match[ffffffff]
Feb 13 11:40:43 xxx kernel: ohci1394_0: Iso Recv 3
Context died: ctrl[ffffffff] cmdptr[ffffffff]
match[ffffffff]
Feb 13 11:40:43 xxx kernel: ohci1394_0: Runaway loop
while stopping context: ...
Feb 13 11:40:43 xxx kernel: ohci1394_0: Runaway loop
while stopping context: ...
Feb 13 11:40:43 xxx kernel: ohci1394_0: Runaway loop
while stopping context: reqTxComplete...
Feb 13 11:40:43 xxx kernel: ohci1394_0: Runaway loop
while stopping context: respTxComplete...
Feb 13 11:40:43 xxx kernel: ohci1394_0: Runaway loop
while stopping context: RQPkt...
Feb 13 11:40:43 xxx kernel: ohci1394_0: Runaway loop
while stopping context: RSPkt...
Feb 13 11:40:43 xxx kernel: ohci1394_0: Error in
reception of SelfID packets [0xffffffff/0x00010019]
(count: 0)
Feb 13 11:40:43 xxx kernel: ohci1394_0: Set PHY Reg
timeout [0xffffffff/0x00004000/100]
Feb 13 11:40:43 xxx kernel: ohci1394_0: Unhandled
interrupt(s) 0xfe7cff0c
Feb 13 11:40:43 xxx kernel: ieee1394: Node removed:
ID:BUS[0-00:1023] GUID[00004c0107002ad7]

Later, when plugging/switching on device, the kernel
locked up.

- - Don't post here - -

Stefan Richter — Mon, 23 Aug 2004 20:13:42 -0000

This bug tracker is practically ignored. Please submit
bug reports to the mailinglist linux1394-devel -at-
lists.sourceforge.net. This list is also the correct
place for discussion about FireWire related application
development under Linux.

On installation trouble and other Linux & FireWire
related topics post at linux1394-user -at-
lists.sourceforge.net. Technically you don't need to be
subscribed in order to submit posts to any of the two
mailinglists, but you should do so anyway if you wish
to post.

occasional sbp2 lockup when powering down device

Anonymous — Fri, 13 Aug 2004 00:48:42 -0000

Kernel: 2.6.6, using in-kernel 1394 drivers
Disk: Acom data external 160GB

Sometimes when I'm done with the device and umount it,
then power it off, the sbp2 subsystem will freeze, not
allowing me to mount the device again until I reboot.

Whenever the freeze ocurrs, this is at the end of my dmesg:

ieee1394: Node changed: 0-01:1023 -> 0-00:1023
ieee1394: Node suspended: ID:BUS[0-00:1023]
GUID[00063a27d40510d2]
Synchronizing SCSI cache for disk sde:

When I umount and shut down device successfully, I see
the two messages from ieee1394, but NOT the
"Synchronizing SCSI cache for disk sde:" message.

I checked in the kernel code and found that there are
two situations when sd_shutdown won't try to
synchronize the cache:

1) Get drive data returns null, or

2) The SCSI device is no longer online.

Could there be a race condition in the code where the
sbp2 instance is destroyed AFTER these checks, causing
the cache sync attempt to lock up?

I'm no kernel hacker, this just my uneducated guess.

-Zorin <lynx at zorin.org>

SBP2 issues in newer 2.6 kernels

Alzheimer — Tue, 20 Apr 2004 12:05:32 -0000

Hi,

I have an external case (Oxford911 chip) which holds
two IDE devices: a Seagate hard disk (Master) and a NEC
1300 DVD writer (Slave). The case has a single power
button, this means both devices get power at the same
time, they cannot be run seperately.

The device is connected via a firewire port provided by
my PCI Creative Audigy Player soundcard (OHCI).

In kernel 2.6.2, both devices are detected and working
seemingly without error. However, in kernel 2.6.5 and
newer versions (I even downloaded the current SVN/CVS
trunk of the drivers) it is broken partially - only the
NEC DVD writer is detected, not the hard disk. This has
happened before (if I recall correctly, it worked in
2.4.20, but not in 2.4.21).

Here's the kernel output in 2.6.2:

---- 8< ----
Apr 20 13:22:43 [kernel] ieee1394: Node added:
ID:BUS[0-01:1023] GUID[00027a07e5002132]
Apr 20 13:22:43 [kernel] ieee1394: The root node is not
cycle master capable; selecting a new root node and
resetting...
Apr 20 13:22:43 [kernel] ieee1394: Node changed:
0-01:1023 -> 0-00:1023
Apr 20 13:22:43 [kernel] scsi0 : SCSI emulation for
IEEE-1394 SBP-2 Devices
Apr 20 13:22:43 [ieee1394.agent] ... no drivers for
IEEE1394 product 0x000000/0x00609e/0x010483
Apr 20 13:22:44 [kernel] ieee1394: sbp2: Logged into
SBP-2 device
Apr 20 13:22:44 [kernel] ieee1394: sbp2: Node
0-00:1023: Max speed [S400] - Max
payload [2048]
Apr 20 13:22:44 [kernel] SCSI device sda: 156301488
512-byte hdwr sectors (80026 MB)
Apr 20 13:22:44 [kernel] sda: asking for cache data failed
Apr 20 13:22:45 [scsi.agent] disk at
/devices/platform/host0/0:0:0:0
Apr 20 13:22:45 [kernel] ieee1394: sbp2: Logged into
SBP-2 device
Apr 20 13:22:45 [kernel] ieee1394: sbp2: Node
0-00:1023: Max speed [S400] - Max
payload [2048]
Apr 20 13:22:45 [kernel] Vendor: _NEC Model:
DVD_RW ND-1300A Rev: 1.09
Apr 20 13:22:45 [kernel] sr0: scsi3-mmc drive: 40x/40x
writer cd/rw xa/form2 cdda tray
Apr 20 13:22:46 [scsi.agent] cdrom at
/devices/platform/host0/0:0:1:0
---- 8< ----

The devices then work flawlessy despite the error messages.

In Kernel 2.6.6-r1 (before you complain, it's about the
same in 2.6.3, 2.6.4 and 2.6.5) it looks like this:

---- 8< ----
Apr 20 13:11:35 [kernel] ieee1394: Node added:
ID:BUS[0-01:1023] GUID[00027a07e5002132]
Apr 20 13:11:35 [kernel] ieee1394: The root node is not
cycle master capable; selecting a new root node and
resetting...
Apr 20 13:11:35 [ieee1394.agent] ... no drivers for
IEEE1394 product 0x/0x/0x
Apr 20 13:11:36 [kernel] ieee1394: Node changed:
0-01:1023 -> 0-00:1023
Apr 20 13:11:36 [kernel] ieee1394: Node changed:
0-00:1023 -> 0-01:1023
Apr 20 13:11:36 [ieee1394.agent] ... no drivers for
IEEE1394 product 0x/0x/0x
Apr 20 13:11:36 [kernel] scsi0 : SCSI emulation for
IEEE-1394 SBP-2 Devices
Apr 20 13:11:37 [kernel] ieee1394: sbp2: Logged into
SBP-2 device
Apr 20 13:11:37 [kernel] ieee1394: Node 0-00:1023: Max
speed [S400] - Max payload [2048]
Apr 20 13:11:37 [kernel] Vendor: _NEC Model:
DVD_RW ND-1300A Rev: 1.09
Apr 20 13:11:37 [ieee1394.agent] ... no drivers for
IEEE1394 product 0x000000/0x00609e/0x010483
Apr 20 13:11:37 [kernel] sr0: scsi3-mmc drive: 40x/40x
writer cd/rw xa/form2 cdda tray
Apr 20 13:11:38 [scsi.agent] cdrom at
/devices/pci0000:00/0000:00:0d.2/fw-host0/00027a07e5002132/00027a07e5002132-0/host0/0:0:0:0
---- 8< ----

As you can see, only the NEC 1300 is detected this
time. There's no hint whatsoever that my disk is there
at all.

I tried to get a log with excessive debugging output,
however my kernel logger (metalog) didn't like that idea.

Please let me know which further information you want
me to provide in order to help you identify the
problem. In case this problem is already known, is
there a workaround for it?

Thanks for all your efforts to support IEEE1394 in Linux!

*** ADDITIONAL INFORMATION: ***
System: i686 AMD Athlon(tm) XP 2000+ AuthenticAMD
GNU/Linux (Gentoo)
Kernel: 2.6.2 (OK) and 2.6.6-r1 (FAIL)
IEEE1394: Original (2.6.2) and Trunk 1206 (2.6.6-r1)
libraw: not installed
Driver: OHCI
/proc/bus/ieee1394/devices: file does not exist
Card: Creative Audigy Player
Chipset: unknown
lspci:
00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7
[Apollo KT266/A/333]
Subsystem: VIA Technologies, Inc. VT8366/A/7
[Apollo KT266/A/333]
Flags: bus master, 66Mhz, medium devsel, latency 0
Memory at c0000000 (32-bit, prefetchable)
Capabilities: [a0] AGP version 2.0
Capabilities: [c0] Power Management version 2

00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7
[Apollo KT266/A/333 AGP] (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01,
sec-latency=0
Memory behind bridge: e0000000-e1ffffff
Prefetchable memory behind bridge:
d0000000-dfffffff
Capabilities: [80] Power Management version 2

00:0d.0 Multimedia audio controller: Creative Labs SB
Audigy (rev 03)
Subsystem: Creative Labs SB0090 Audigy Player
Flags: bus master, medium devsel, latency 32,
IRQ 11
I/O ports at <ignored>
Capabilities: [dc] Power Management version 2

00:0d.1 Input device controller: Creative Labs SB
Audigy MIDI/Game port (rev 03)
Subsystem: Creative Labs SB Audigy MIDI/Game Port
Flags: bus master, medium devsel, latency 32
I/O ports at <ignored>
Capabilities: [dc] Power Management version 2

00:0d.2 FireWire (IEEE 1394): Creative Labs SB Audigy
FireWire Port (prog-if 10 [OHCI])
Subsystem: Creative Labs SB Audigy FireWire Port
Flags: bus master, medium devsel, latency 32, IRQ 7
Memory at <ignored> (32-bit, non-prefetchable)
Memory at <ignored> (32-bit, non-prefetchable)
Capabilities: [44] Power Management version 2

00:10.0 USB Controller: VIA Technologies, Inc. USB (rev
80) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. USB
Flags: bus master, medium devsel, latency 32, IRQ 5
I/O ports at <ignored>
Capabilities: [80] Power Management version 2

00:10.1 USB Controller: VIA Technologies, Inc. USB (rev
80) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. USB
Flags: bus master, medium devsel, latency 32, IRQ 5
I/O ports at <ignored>
Capabilities: [80] Power Management version 2

00:10.2 USB Controller: VIA Technologies, Inc. USB (rev
80) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. USB
Flags: bus master, medium devsel, latency 32, IRQ 5
I/O ports at <ignored>
Capabilities: [80] Power Management version 2

00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0
(rev 82) (prog-if 20 [EHCI])
Subsystem: VIA Technologies, Inc. USB 2.0
Flags: bus master, medium devsel, latency 32,
IRQ 10
Memory at e2005000 (32-bit, non-prefetchable)
Capabilities: [80] Power Management version 2

00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA
Bridge
Subsystem: VIA Technologies, Inc. VT8235 ISA Bridge
Flags: bus master, stepping, medium devsel,
latency 0
Capabilities: [c0] Power Management version 2

00:11.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus
Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
Subsystem: VIA Technologies, Inc.
VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus
Master IDE
Flags: bus master, medium devsel, latency 32,
IRQ 255
I/O ports at e400
Capabilities: [c0] Power Management version 2

00:12.0 Ethernet controller: VIA Technologies, Inc.
VT6102 [Rhine-II] (rev 74)
Subsystem: VIA Technologies, Inc. VT6102 [Rhine
II] Embeded Ethernet Controller on VT8235
Flags: bus master, medium devsel, latency 32,
IRQ 11
I/O ports at e800
Memory at e2006000 (32-bit, non-prefetchable)
Capabilities: [40] Power Management version 2

00:13.0 Multimedia audio controller: C-Media
Electronics Inc CM8738 (rev 10)
Subsystem: Chaintech Computer Co. Ltd: Unknown
device 1100
Flags: bus master, medium devsel, latency 32,
IRQ 10
I/O ports at ec00
Capabilities: [c0] Power Management version 2

01:00.0 VGA compatible controller: nVidia Corporation
NV25 [GeForce4 Ti 4200] (rev a3) (prog-if 00 [VGA])
Flags: bus master, 66Mhz, medium devsel,
latency 248, IRQ 11
Memory at e0000000 (32-bit, non-prefetchable)
Memory at d0000000 (32-bit, prefetchable)
Memory at d8000000 (32-bit, prefetchable)
Capabilities: [60] Power Management version 2
Capabilities: [44] AGP version 2.0