On Fri, Jan 12, 2007 at 02:45:23PM -0500, Dailey, Nate wrote:
> Hoping someone on this list might shed some light on this...
>
> I was investigating a problem of poor sequential write performance
> (IOmeter, various size sequential writes) with an embedded Vitesse 7174,
> maxing out (with disk wri
On Thu, 2007-01-11 at 22:26 -0800, Andrew Morton wrote:
> - Merged the "filesystem AIO patches".
Hotfixes alreday applied.
BUG: at
/home/tglx/work/kernel/vanilla/linux-2.6.20-rc4-mm1/arch/i386/mm/highmem.c:60
kmap_atomic()
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack
On Sun, 2007-01-14 at 10:48 +0100, Thomas Gleixner wrote:
> ata_scsi_rbuf_get requests KM_IRQ0 type memory and calls kmap_atomic
> with interrupts enabled.
>
> Boot proceeds, but gets stuck hard at:
> "Remounting root filesystem in read-write mode:"
>
> No SysRq-T, nothing.
>
> The above BUG see
> So I suppose the driver should be modified to set it to 0x80 only
> if it's 0. I believe that most PCI implementations will set it in
> the BIOS or whatever.
pci_set_master should handle this automtically on most platforms.
On x86-32 you also need to check "pcibios_max_latency" if you write th
I changed my bios setting for SATA from IDE to AHCI.
This resulted in some "interesting" read throughput.
plots can be found at http://kenjo.org/~ken/sata/
The plots was done on a live disk so some noise is expected but in the
ahci mode the throughput get stuck at 17 MB way to much.
The read wa
On Sun, 2007-01-14 at 11:46 +0100, Thomas Gleixner wrote:
> > Boot proceeds, but gets stuck hard at:
> > "Remounting root filesystem in read-write mode:"
> >
> > No SysRq-T, nothing.
> >
> > The above BUG seems unrelated to that. Investigating further.
>
> Bisect identified: git-block.patch
Doe
Alan wrote:
So I suppose the driver should be modified to set it to 0x80 only
if it's 0. I believe that most PCI implementations will set it in
the BIOS or whatever.
pci_set_master should handle this automtically on most platforms.
pci_set_master() sets the latency timer not cacheline size
Hello,
I tested libata-dev#promise-sata-pata branch, then I saw Mikael
Pettersson's patch, which kind of obsoleted the testing.
So I did libata-dev#upstream too.
Nothig bad happened yet, after about 1h30 of test for each kernel.
bonnie++, dd, untar, mke[23]fs.
dm striped + linear from sda(20GB)
On Mon, 2007-01-15 at 09:05 +1100, Jens Axboe wrote:
> raid seems to have severe problems with the plugging change. I'll try
> and find Neil and have a chat with him, hopefully we can work it out.
Some hints:
mount(1899): WRITE block 16424 on md3
call md_write_start
md3_raid1(438): WRITE block 40
On Sun, Jan 14 2007, Thomas Gleixner wrote:
> On Mon, 2007-01-15 at 09:05 +1100, Jens Axboe wrote:
> > raid seems to have severe problems with the plugging change. I'll try
> > and find Neil and have a chat with him, hopefully we can work it out.
>
> Some hints:
>
> mount(1899): WRITE block 16424
On Sun, Jan 14 2007, Thomas Gleixner wrote:
> On Sun, 2007-01-14 at 11:46 +0100, Thomas Gleixner wrote:
> > > Boot proceeds, but gets stuck hard at:
> > > "Remounting root filesystem in read-write mode:"
> > >
> > > No SysRq-T, nothing.
> > >
> > > The above BUG seems unrelated to that. Investiga
Should apply to -mm tree or current libata-dev git tree. Sorry for
attaching, but I seem to have misplaced the magic incantations to make
Thunderbird not destroy inline patches..
---
This cleans up a few issues with the error handling in sata_nv in ADMA
mode to make it more consistent with ot
Alan wrote:
> O> Wouldn't it be better to have ->determine_xfer_mask() and
>> ->set_specific_mode() than having two somewhat overlapping callbacks?
>> Or is there some problem that can't be handled that way?
>
> I'm not sure I follow what you are suggesting - can you explain further.
>
> Right no
Brad Fitzpatrick wrote:
> On Sat, 13 Jan 2007, Brad Fitzpatrick wrote:
>
>> I tried another disk (but of the same type), and got the same results both
>> direct and via PMP.
>>
>> Are these disks too old to be hot-plugged? (but I recall the
>> identical errors happening on boot after I power-cycl
Matthew Stapleton wrote:
> Tejun Heo wrote:
>> Can you try the attached patch over 2.6.19 and report full dmesg? Thanks.
>>
>> --
>> tejun
>>
>
> Attached is my full dmesg.
Does the problem still persist?
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the b
Vincent Legoll writes:
> Hello,
>
> I tested libata-dev#promise-sata-pata branch, then I saw Mikael
> Pettersson's patch, which kind of obsoleted the testing.
> So I did libata-dev#upstream too.
>
> Nothig bad happened yet, after about 1h30 of test for each kernel.
> bonnie++, dd, untar,
16 matches
Mail list logo
