linux-kernel - Re: VIA VT6307 OHCI version?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m3abq2ccb6.fsf@maximus.localdomain>
Date:	Mon, 29 Oct 2007 13:53:01 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	linux1394-user@...ts.sourceforge.net,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: VIA VT6307 OHCI version?

Stefan Richter <stefanr@...6.in-berlin.de> writes:

> This device is a somewhat buggy PCI card which somebody sent me after
> unsuccessful attempts to get it properly working under Linux.  Among
> more serious trouble, ohci1394 reads a bogus maximum async payload (a
> zero value) from the BusOptions register during startup.  This has
> occasionally been reported for some VT6306 in the past.  I haven't
> really tested this card myself yet, it's currently stuck in a PC which I
> don't use anymore.

I see. I think you may be able to cure this problem with my program,
adding corrected values in addition to write to 0x11 should do the
trick. 93c46 is 16-bit, little-endian here. You'd have to divide the
addresses shown by the dump by 2 of course.
I'd make sure the values are ok before rebooting, there is some
possibility a badly corrupted EEPROM may prevent BIOS from starting.

I think I'd leave GUID (16-bit words at 0, 1, 2, 3) and PCI subsystem
IDs (words at 0xA and 0xB) unchanged, and for all other locations I'd
fill in the 6307 values.

Of course I don't know if the program will be able to write to VT6306,
so I'd test the broken card first.

> VT6306 CardBus card in my main PC:
> MMIO=[80000000-800007ff]  Max Packet=[1024]  IR/IT contexts=[4/8]
> ieee1394: Host added: ID:BUS[2-00:1023]  GUID[00110600000041cc]

The difference is of course at 0x0E, not 0x1E. Maybe the byte at 0x0A
is 0x92 for 4 IR contents and 0xA2 for 8 contents. That would also
make sense wrt the broken 6306 as it has 0x00 there.
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/