On 26 November 2010 12:40, Isaku Yamahata wrote:
> On Thu, Nov 25, 2010 at 08:18:45PM +0000, adq wrote:
>> On 25 November 2010 11:28, Isaku Yamahata wrote:
>> > On Wed, Nov 24, 2010 at 02:08:16PM +, adq wrote:
>> >> > Interesting. I was also thinking that
On 25 November 2010 11:46, Jan Kiszka wrote:
> Am 24.11.2010 12:00, Alexander Graf wrote:
> According to to the Intel IA-32 Software Developers Manual Vol 3 page
> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway.
>
> Signed-off-by: Andrew de Quincey
>
> diff --g
On 25 November 2010 11:28, Isaku Yamahata wrote:
> On Wed, Nov 24, 2010 at 02:08:16PM +0000, adq wrote:
>> > Interesting. I was also thinking that maybe we can leverage overriding
>> > mechanisms that are already available. Maybe it's possible to squeeze the
>>
On 24 November 2010 11:00, Alexander Graf wrote:
>
> On 24.11.2010, at 03:40, adq wrote:
>
>> On 23 November 2010 23:41, Alexander Graf wrote:
>>>
>>> On 23.11.2010, at 22:25, adq wrote:
>>>
>>>> This patch ups the APIC version from 0x11 to 0
On 24 November 2010 11:00, Alexander Graf wrote:
>
> On 24.11.2010, at 03:40, adq wrote:
>
>> On 23 November 2010 23:41, Alexander Graf wrote:
>>>
>>> On 23.11.2010, at 22:25, adq wrote:
>>>
>>>> This patch ups the APIC version from 0x11 to 0
On 23 November 2010 23:41, Alexander Graf wrote:
>
> On 23.11.2010, at 22:25, adq wrote:
>
>> This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X
>> loads successfully (with appropriate kexts, applesmc ain't hooked up
>> properly yet I s
This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X
loads successfully (with appropriate kexts, applesmc ain't hooked up
properly yet I see unfortunately).
According to to the Intel IA-32 Software Developers Manual Vol 3 page
290, the version should be 0x14 Pentium 4/Xeon CPUs a
On 20 November 2010 08:23, Nicholas A. Bellinger wrote:
> On Sat, 2010-11-20 at 01:25 +0000, adq wrote:
>> On 20 November 2010 00:41, Nicholas A. Bellinger
>> wrote:
>> > On Fri, 2010-11-19 at 19:39 +0100, Christoph Hellwig wrote:
>> >> On Thu, Nov 18, 2010
On 20 November 2010 00:41, Nicholas A. Bellinger wrote:
> On Fri, 2010-11-19 at 19:39 +0100, Christoph Hellwig wrote:
>> On Thu, Nov 18, 2010 at 03:47:36PM +0100, Hannes Reinecke wrote:
>> >
>> > aio_ioctl is emulated anyway and currently broken.
>>
>> What's broken about it currently?
>
> Mm,
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, s
> 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
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 une
On 8 August 2010 23:13, adq wrote:
> Hi, more information on the command that is (now) killing my
> qemu+scsi-generic in case someone else can help... Its our old friend
> the READ DVD STRUCTURE command:
>
> CMD: 00 ad
> CMD: 01 00
> CMD: 02 00
> CMD: 03 00
> CMD: 04 0
Hi, more information on the command that is (now) killing my
qemu+scsi-generic in case someone else can help... Its our old friend
the READ DVD STRUCTURE command:
CMD: 00 ad
CMD: 01 00
CMD: 02 00
CMD: 03 00
CMD: 04 00
CMD: 05 00
CMD: 06 00
CMD: 07 01
CMD: 08 00
CMD: 09 08
CMD: 0a 00
CMD: 0b 00
Wh
On 8 August 2010 14:11, Kevin Wolf wrote:
> Am 07.08.2010 02:55, schrieb adq:
>> 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-generi
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/execut
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-generi
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() callback is never called.
This is because these ar
18 matches
Mail list logo
