James, can you please send this on ASAP? Sitting for oever a week
on a boot regression that comes with a patch isn't reasonable.
On Sun, Aug 10, 2014 at 05:54:25AM -0700, Guenter Roeck wrote:
> The latest kernel fails to boot qemu arm images when using scsi
> for disk access. Boot gets stuck afte
On 08/15/2014 12:22 PM, Christoph Hellwig wrote:
On Fri, Aug 15, 2014 at 12:34:22PM -0600, Jens Axboe wrote:
On 2014-08-15 12:22, Guenter Roeck wrote:
ping ... the problem fixed by this patch still affects the upstream kernel
(v3.16-11383-gc9d2642) as well as -next (20140815).
James, could yo
On Fri, Aug 15, 2014 at 12:34:22PM -0600, Jens Axboe wrote:
> On 2014-08-15 12:22, Guenter Roeck wrote:
>> ping ... the problem fixed by this patch still affects the upstream kernel
>> (v3.16-11383-gc9d2642) as well as -next (20140815).
>
> James, could you upstream this one in time for -rc1?
It's
On 8/10/14 8:54 AM, Guenter Roeck wrote:
The latest kernel fails to boot qemu arm images when using scsi
for disk access. Boot gets stuck after the following messages.
brd: module loaded
sym53c8xx :00:0c.0: enabling device (0100 -> 0103)
sym0: <895a> rev 0x0 at pci :00:0c.0 irq 93
sym0:
On 2014-08-15 12:22, Guenter Roeck wrote:
ping ... the problem fixed by this patch still affects the upstream kernel
(v3.16-11383-gc9d2642) as well as -next (20140815).
James, could you upstream this one in time for -rc1?
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscr
ping ... the problem fixed by this patch still affects the upstream kernel
(v3.16-11383-gc9d2642) as well as -next (20140815).
Guenter
On 08/10/2014 05:54 AM, Guenter Roeck wrote:
The latest kernel fails to boot qemu arm images when using scsi
for disk access. Boot gets stuck after the followin
On 08/11/2014 08:33 AM, Venkatesh Srinivas wrote:
Should we wrap the sdev->device_busy read and test in a new
scsi_device_busy(), so as to preserve the old polarity?
I don't see a difference in polarity, or at least replacing '== 0' with '!'
is not a reverse in polarity for me. Anyway, I don't
Should we wrap the sdev->device_busy read and test in a new
scsi_device_busy(), so as to preserve the old polarity?
Reviewed-by: Venkatesh Srinivas
On 8/11/14, Jens Axboe wrote:
> On 2014-08-10 06:54, Guenter Roeck wrote:
>> The latest kernel fails to boot qemu arm images when using scsi
>> for
On 2014-08-10 06:54, Guenter Roeck wrote:
The latest kernel fails to boot qemu arm images when using scsi
for disk access. Boot gets stuck after the following messages.
brd: module loaded
sym53c8xx :00:0c.0: enabling device (0100 -> 0103)
sym0: <895a> rev 0x0 at pci :00:0c.0 irq 93
sym0:
On 08/10/2014 02:54 PM, Guenter Roeck wrote:
The latest kernel fails to boot qemu arm images when using scsi
for disk access. Boot gets stuck after the following messages.
brd: module loaded
sym53c8xx :00:0c.0: enabling device (0100 -> 0103)
sym0: <895a> rev 0x0 at pci :00:0c.0 irq 93
sy
The latest kernel fails to boot qemu arm images when using scsi
for disk access. Boot gets stuck after the following messages.
brd: module loaded
sym53c8xx :00:0c.0: enabling device (0100 -> 0103)
sym0: <895a> rev 0x0 at pci :00:0c.0 irq 93
sym0: No NVRAM, ID 7, Fast-40, LVD, parity checki
11 matches
Mail list logo
