On Mon, Apr 04, 2005 at 04:17:45PM -0500, James Bottomley wrote:
> OK, I sent the patch off to Andrew. To complete the original problem,
> the attached is the patch that uses it in the parisc lasi driver
> (although, actually, it sets up 53c700 to work everywhere including BE
> on a LE system).
>
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 endiannes
Fix up two drivers that incorrectly were using the old return values for
their new-style EH methods and kill off scsi_obsolete.h that defined the
constants. The initio driver has all these constansts defined locally
and uses them internally, I'll fix that up some time later.
--- 1.95/drivers/scs
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(): n
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 :-(
>
> T
Dear potential Speaker:
On behalf of the organizing committee, I would like to extend a cordial
invitation for you to attend one of the upcoming IPSI BgD multidisciplinary,
interdisciplinary, and transdisciplinary conferences.
The first one will take place in Loreto Aprutino, Italy:
IPSI-2005
On Tue, 2005-04-05 at 08:21 +0100, Christoph Hellwig wrote:
> What I really don't like is that you still need ifdefs and wrappers to
> support BE and LE wired chips in the same driver. Shouldn't you set the
> BE or LE flag at iomap() time and always use the same accessors?
No, if you look how it
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
>
> BE version 1 (word invariant)
> byte access byte 0 byte 1 byte 2 byte
On Tue, 2005-04-05 at 15:19 +0900, Tejun Heo wrote:
> No problem. Do you want me to do that now? Or is it okay to do the
> next take after you review the request_fn rewrite patch?
Just on resubmit ... I think you're currently reworking the request_fn
patch based on Christoph's comments, so re
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 wi
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 c
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...
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 m
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 ave
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)
> > > byt
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, mos
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 co
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
wh
19 matches
Mail list logo
