Bugs item #2482759, was opened at 2009-01-02 13:03 Message generated for change (Comment added) made by ryan_harper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2482759&group_id=180599
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bair (ryandbair) Assigned to: Nobody/Anonymous (nobody) Summary: Windows SCSI errors Initial Comment: When starting up a fresh install of Windows Server 2003 R2 x64, I get errors similar to the following... scsi-disk: Command: lun=0 tag=0x0 data=0x12 0x01 0x00 0x00 0xff 0x00 scsi-disk: Inquiry (len 255) scsi-disk: Inquiry EVPD[Supported pages] buffer size 255 scsi-disk: Read buf_len=7 scsi-disk: Read sector_count=0 scsi-disk: Command complete tag=0x0 status=0 sense=0 lsi_scsi: error: Unhandled writeb 0xff = 0x0 lsi_scsi: error: Unhandled writeb 0x100 = 0x0 lsi_scsi: error: Unhandled writeb 0x101 = 0x0 lsi_scsi: error: Unhandled writeb 0x102 = 0x0 While these errors are happening on boot, the animated bar continues to scroll. The errors continue for about a minute and then everything suddenly kicks into gear and the machine continues to boot. This also happens while trying to get partition information through the device properties in the device manager and through the disk management mmc snapin. I'm running kvm-82 on Debian Lenny AMD64. The disk is a 20GB virtual SCSI, raw format. Here's the command I'm using to run KVM. kvm -m 1024 -smp 2 -drive file=system.img,if=scsi,boot=on -localtime --vnc 127.0.0.1:0 &> ../win2k3x64.log ---------------------------------------------------------------------- Comment By: Ryan Harper (ryan_harper) Date: 2009-01-05 17:16 Message: Yeah, that's a fair point, I haven't figured out exactly what those writes are for. It could be some other bug throwing off the SCRIPTS and causing the write to reserved offsets, however, 64-bit windows does enabled 64-bit Direct Block moves which require a 3rd Dword fetch, hence the ->dsp+=4. ---------------------------------------------------------------------- Comment By: Anssi Kolehmainen (aketzu) Date: 2009-01-05 17:00 Message: Why write to checksum and user data and never read anything? I didn't spot any remarks what writing the checksum might accomplish. This time I made (bad) assumption that if the 3rd dword contains anything else than 0 it must be next opcode and we shouldn't dsp=+4... Now it formats the drive properly and install succeeds (writing about 8-15mb/s with logging on and 10-20mb/s with logging off). Although after install Windows Boot Manager barfs that boot configuration couldn't be read and refuses to boot (but that might be caused by some other incompatibility). ---------------------------------------------------------------------- Comment By: Ryan Harper (ryan_harper) Date: 2009-01-05 15:24 Message: As for serial eeprom, you can look at the tech manual[1], section 2.4 if you want to read why it's poking at those offsets. 1. http://www.lsi.com/DistributionSystem/AssetDocument/files/docs/techdocs/storage_stand_prod/SCSIControllers/lsi53c895a_tech_manual.pdf ---------------------------------------------------------------------- Comment By: Ryan Harper (ryan_harper) Date: 2009-01-05 15:18 Message: It does start quicker, but formatting fails on 64-bit windows if you don't use 64-bit DMA mode. ---------------------------------------------------------------------- Comment By: Anssi Kolehmainen (aketzu) Date: 2009-01-05 15:12 Message: What a better way to spend the night than debug SCSI problems :) kvm-82, win2k8-64 install dvd and some hacking... The startup freezes for a while (log below). Why would driver want to write to eeprom memory? Maybe because that scripts pointer goes wrong? [1231186859.686061] lsi_scsi: SCRIPTS dsp=f00221e0 opcode 878b0000 arg 0000007c [1231186859.686064] lsi_scsi: Compare phase 7 == 7 [1231186859.686066] lsi_scsi: Jump to 0xf0022264 [1231186859.686069] lsi_scsi: SCRIPTS dsp=f0022264 opcode 0f000001 arg 3fc56890 [1231186859.686072] lsi_scsi: Message in len=1/1 [1231186859.686074] lsi_scsi: SCRIPTS dsp=f0022270 opcode fffffdb4 arg 808c0004 [1231186859.686079] lsi_scsi: Load reg 0xff size 4 addr 0x3f518044 = 00000000 [1231186859.686083] lsi_scsi: Write reg ff = 00 [1231186859.686085] lsi_scsi: Write reg 100 = 00 [1231186859.686087] lsi_scsi: Write reg 101 = 00 [1231186859.686089] lsi_scsi: Write reg 102 = 00 [1231186859.686092] lsi_scsi: SCRIPTS dsp=f0022278 opcode 00000068 arg 808c0002 [1231186859.686094] lsi_scsi: DMA no data available [1231186859.686097] lsi_scsi: SCRIPTS execution stopped [1231186870.546702] lsi_scsi: Write reg 40 = 00 Well, that seems to be the case... lsi_dma_64bit() returns true, s->dsp is incremented extra 0x4 and we skip one half instruction... Commenting out s->dsp+=4 (and other instructions around line 973) and the installer starts in a flash as seen below. [1231188815.759843] lsi_scsi: SCRIPTS dsp=f00221e0 opcode 878b0000 arg 0000007c [1231188815.759846] lsi_scsi: Compare phase 7 == 7 [1231188815.759849] lsi_scsi: Jump to 0xf0022264 [1231188815.759852] lsi_scsi: SCRIPTS dsp=f0022264 opcode 0f000001 arg 3fc6f890 [1231188815.759855] lsi_scsi: Message in len=1/1 [1231188815.759858] lsi_scsi: SCRIPTS dsp=f002226c opcode 808c0000 arg fffffdb4 [1231188815.759861] lsi_scsi: Compare data 0x0 & 0xff == 0x0 [1231188815.759864] lsi_scsi: Jump to 0xf0022028 ---------------------------------------------------------------------- Comment By: Ryan Harper (ryan_harper) Date: 2009-01-05 10:03 Message: Fair enough. In my testing, I've not seen such long timeouts. A couple minutes during installation, and a handful of seconds on boot. ---------------------------------------------------------------------- Comment By: Ryan Bair (ryandbair) Date: 2009-01-05 09:34 Message: While everything still works it certainly does affect the usability of Windows guests on SCSI. Freezing all SCSI disk I/O for 20 minutes (new record!) when opening the disk management snap-in and adding up to 5 minutes to the Windows boot time really makes it unusable. I can understand it might not be the highest priority at the moment, but I wouldn't put it too far down the list either. ---------------------------------------------------------------------- Comment By: Ryan Harper (ryan_harper) Date: 2009-01-04 20:11 Message: Yeah, it's worth keeping open so we at least track that it is an open issue. It is harmless AFAICT, so no plans to implement the eeprom interface unless it prevents functionality. We've got lots of other issues to fix in the scsi layer. ---------------------------------------------------------------------- Comment By: Ryan Bair (ryandbair) Date: 2009-01-04 20:05 Message: Thanks, as far as I can see this is the first time the bug has been reported on the tracker so I will keep this bug open. Are there any workarounds or a planned fixes for this issue? ---------------------------------------------------------------------- Comment By: Ryan Harper (ryan_harper) Date: 2009-01-04 19:44 Message: lsi_scsi: error: Unhandled writeb 0xff = 0x0 lsi_scsi: error: Unhandled writeb 0x100 = 0x0 lsi_scsi: error: Unhandled writeb 0x101 = 0x0 lsi_scsi: error: Unhandled writeb 0x102 = 0x0 These are known error messages. Looks like the windows driver is poking at the serial eeprom interface for loading SSVID/SSID but that's not implemented, hence the error message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2482759&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
