On Sat, Apr 02, 2005 at 09:40:39PM -0600, James Bottomley wrote:
On Sun, 2005-04-03 at 04:10 +0100, Matthew Wilcox wrote:
SPARC64 can do it in the PTEs, but we just use raw physical
addresses in our I/O accessors, and in those load/store instructions
we can specify the endianness.
Hi Seokmann,
I thought about the race issue of megaraid_isr() and
megaraid_queue_command().
fuinction : lock name
--
megaraid_mbox_runpendq () : pending_list_lock
megaraid_isr() : no lock
wait_till_fw_ready(): host_lock
megaraid_mbox_mm_done():
On Fri, Apr 01, 2005 at 12:20:50PM +0200, Markus Lidel wrote:
Hello,
Christoph Hellwig wrote:
Markus, is this patch actually okay? I just talked to Andi about the
ioctl32 issues and he told me about this patch.
OK, i don't own a 64-bit system, so i couldn't test it out :-(
The only
Hi,
This is my second attemp to make anyone notice the bug that is in the
2.6.x tree. While many people tried to put blame on nvidia, here's a log
that shows that it's purely kernel fault not to work.
At the end of this mail you can find some logs which show how 2.4.x and
2.6.x kernels work
On Tue, 2005-04-05 at 19:25 +0200, |TEcHNO| wrote:
This is my second attemp to make anyone notice the bug that is in the
2.6.x tree. While many people tried to put blame on nvidia, here's a log
that shows that it's purely kernel fault not to work.
At the end of this mail you can
On Tue, Apr 05, 2005 at 09:05:15AM -0500, James Bottomley wrote:
On Tue, 2005-04-05 at 08:42 +0100, Russell King wrote:
Not so. There are two different styles of big endian. (Lets just face
it, BE is fucked in the head anyway...)
physical bus: 31...24 23...16 15...8 7...0
Forgot to mention, I've tried the sg_dd program with
different bpt values. Like 30,40,60,400,401,257,267.
seems like whenever it's even the speeds is faster.
--- Ying Li [EMAIL PROTECTED] wrote:
hi,
I recently got a seagate cheetah (ST336753FC, 15k.3
RPM 37GB) harddrive that sits in my JMR
hi,
I recently got a seagate cheetah (ST336753FC, 15k.3
RPM 37GB) harddrive that sits in my JMR Fortra 2G6
array.
I'm running Linux 2.6, using sg3_util.1.13
My seagate is mapped to /dev/sdb
I run the following:
1.)time sg_dd if=/dev/zero of=/dev/sdb bpt=256
count=120
a.) it finishes on
Convert obsolete MODULE_PARM() to module_param(). This also fixes mpt_factor
that currently is a short parameter (h) but the actual variable is an int.
Signed-off-by: Magnus Damm [EMAIL PROTECTED]
--- linux-2.6.12-rc2/drivers/message/fusion/mptscsih.c 2005-04-05
16:59:53.0 +0200
+++
On Tue, 5 Apr 2005, Russell King wrote:
physical bus: 31...24 23...16 15...8 7...0
BE version 1 (word invariant)
byte access byte 0 byte 1 byte 2 byte 3
word access 31-24 23-16 15-87-0
BE version 2 (byte invariant)
byte access byte 3
Hi,
I don't think anyone has the actual hardware, without which it's quite
difficult to fix the problem.
What was the last 2.6 kernel version that this worked with?
I guess I made a jump from 2.4.26 directly to 2.6.9 or maybe even
higher, but I can't remember if I used the scanner since then,
Ok fine - This fix is already there in the series of patches
I provided a week ago for splitting the mpt fusion drivers
into seperate bus type drivers.
James any word on whether those series of patches will get
approved?
In addition, Steve Ralston is no longer working in this group.
No need to
On Apr 5, 2005 10:30 PM, Moore, Eric Dean [EMAIL PROTECTED] wrote:
Ok fine - This fix is already there in the series of patches
I provided a week ago for splitting the mpt fusion drivers
into seperate bus type drivers.
Ah. I guess that makes this patch pretty useless, except in the case
where
13 matches
Mail list logo