From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3c80dcc2e915815ac5e933e2e9e17bca@quanstro.net> To: 9fans@hamnavoe.com, 9fans@9fans.net From: erik quanstrom Date: Sat, 5 Jul 2008 16:36:45 -0400 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] via vt8237 Topicbox-Message-UUID: dbebd9aa-ead3-11e9-9d60-3106f5b1d025 i think the posted patch might not be appropriate for controllers not having the via controllers' problem as it is quite quick to reset the controller if a command takes a long time. with a properly functioning controller, it is generally a bad idea to do a reset with a command in flight. i haven't seen any other patches so i don't know how they work. i also took a look at the linux driver for the same hardware and didn't find the same reset loop. i did however find some pci setup code specific to this chipset which i posted some time ago http://9fans.net/archive/2008/02/277 this code was translated from the linux. i don't know if this was ever tried. but it tries to attack the root of the problem, missed interrupts, by setting some pcie magic. i can't try this myself as i don't have appropriately buggy hardware. if this doesn't work, it might make sense to have a controller setting to optionally check for missed interrupts. this will allow us to still tell the difference between an interrupt that got lost and a controller that's gone off into the weeds. i've put up a driver that may work if this is the case but it's not tested due to lack of hardware. sources is down, so it can be accessed here: hget http://www.quanstro.net/vtsdata.c - erik