Re: Responding to 2 thread <2.6.23.8 - Hang with sata_mv (7042)...> AND <Bug: get EXT3-fs error Allocating block in system zone>

[Mark Lord <liml@rtr.ca>]

Morrison, Tom wrote:
> I am a little confused as to exactly what thread I am to respond to 
> and/or what requests...but lets try this and see if I get close?
> 
> I have the <far> below mentioned hardware/configuration (flat 4Gig 
> of DDR mem (0x0_000_0000 to 0x1_000_0000)...PPC/8548E - 36bit addressing
> 
> As can be seen below - Mark has asked me try patching my sata_mv 
> (and scsi_lib) with some patches from the second thread in subject:
> 
>     1) Disable 64bit DMA in sata_mv (equivalent of the CAP_64 for 
>        AHCI) and disabling the bounce:
> 
>     2) Disable queue bounce limit in drivers/scsi/scsi_lib.c
> 
> +#if 0
>          blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
> +#endif
> 
> Mark had already asked me to try #1 a while back - and that didn't work.
> So, I tried #2 - and now it doesn't hang for me went writing a large 
> File (which was my error condition)...
> 
> So, as Linus suggested in his email, it looks like something 
> is wrong in the bounce buffering? What - somebody will have
> to look into this further...
..

That's a bit strange, actually.. because you said that this system
does not have any RAM at any addresses above 0xffffffff.
The physical RAM in this system is supposedly from 0 - 0xffffffff (4Gbytes).

????

> -----Original Message-----
> From: Mark Lord [mailto:liml@rtr.ca] 
> Sent: Monday, December 10, 2007 11:44 AM
> To: Morrison, Tom
> Cc: Jeff Garzik; linux-ide@vger.kernel.org; Tejun Heo; hp@syntomax.com
> Subject: Re: Revisiting - 2.6.23.8 - Hang with sata_mv (7042) + Flat
> 4Gig (no holes) Memory
> 
> Morrison, Tom wrote:
> ..
>> To re-state the problem....
>>
>> Hardware/Configuration:
>>    MPC8548E with a 7042 (rev 2 - connected internal via a PEX switch) 
>>    2.6.23.8 (using PHYS_64BIT & PTE_64BIT - for 36 bit addressing
>>              & MSI is NOT compiled in)
>>    Flat 4Gig Memory Map (no holes - 0 - 0x0_FFFF_FFFF defined -
> special
>>  	                   low reserve memory is also used)
>>
>>    Local Bus & PCI Express IOMem mapped to unique space in 
>> 		0xC_xxxx_xxxx with extensions to the ioremap routines 
>> 		to create the appropriate requested physical address...
>> 		This is (and should be) transparent to the requesting 
>> 		function that calls ioremap.
>> 		
>>    2 SATA hard drives connected.
>>
>> To recreate:
>>    Write a large file (now greater than >310Mbytes) - hangs
>>    and soft lockup is detected by kernel - no useful info 
>>    in stack trace...
>>
>> Of interest:
>>    a) Replace sata_mv.c - with the 'old' Marvell's reference 
>>       driver and it works perfectly!!
>>
>>    b) Also, sata_mv works perfectly in all conditions - if we boot
> with 
>>       less than the ~3750M from the command line (which I note is
> ~below
>>       where its PEX IOmemory space is located).
> ..
> 
> Tom:  could you please try and follow the recent thread here (linux-ide)
> entitled " Bug: get EXT3-fs error Allocating block in system zone ".
> 
> Somebody there has a similar problem on x86-32 with RAM above 4GB
> using a standard AHCI SATA controller.
> 
> Jens has posted a couple of debugging patches there to try and isolate
> things.
> (patches attached here for convenience, though you'll have to
> modify/hack
>  the first one for sata_mv instead of ahci).
> 
> -ml
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html