On 17 November 2010 23:33, adq wrote:
>> On 12 November 2010 10:00, Paolo Bonzini wrote:
>>> On 08/09/2010 01:51 AM, adq wrote:
Figured out what the problem is - READ DVD STRUCTURE has its xfer
length in an unexpected place, so hw/scsi-bus.c retrieves completely
the wrong valu
> On 12 November 2010 10:00, Paolo Bonzini wrote:
>> On 08/09/2010 01:51 AM, adq wrote:
>>>
>>> Figured out what the problem is - READ DVD STRUCTURE has its xfer
>>> length in an unexpected place, so hw/scsi-bus.c retrieves completely
>>> the wrong value for the transfer length. Attached nasty hac
I'll have a go at resurrecting it; I wasn't sure if there was any
interest before.
On 12 November 2010 10:00, Paolo Bonzini wrote:
> On 08/09/2010 01:51 AM, adq wrote:
>>
>> Figured out what the problem is - READ DVD STRUCTURE has its xfer
>> length in an unexpected place, so hw/scsi-bus.c retrie
On 08/09/2010 01:51 AM, adq wrote:
Figured out what the problem is - READ DVD STRUCTURE has its xfer
length in an unexpected place, so hw/scsi-bus.c retrieves completely
the wrong value for the transfer length. Attached nasty hacky (!)
patch fixes it as a proof of concept, will see what I can do
On 7 August 2010 02:50, adq wrote:
> On 7 August 2010 01:55, adq wrote:
>> Hi, I've been tracking down why scsi generic devices (using SG_IO)
>> don't work any more. After adding debug, I can see that it actually
>> submits the scsi CDB in hw/scsi-generic.c/execute_command(), but that
>> the hw/s
On 7 August 2010 01:55, adq wrote:
> Hi, I've been tracking down why scsi generic devices (using SG_IO)
> don't work any more. After adding debug, I can see that it actually
> submits the scsi CDB in hw/scsi-generic.c/execute_command(), but that
> the hw/scsi-generic.c/scsi_read_complete() callbac
