Stefan Richter wrote:
> My guess is that there won't be conflicts of this with linux1394-2.6.git
> anytime soon, so taking it into any other tree should be fine.
Wrong, there should already be a (trivial) conflict due to a patch from
December. Another (trivially) conflicting patch was sent to
lin
James Bottomley wrote:
>> I'm just a bit reluctant to touch these drivers, since they're all
>> incredibly ancient. We don't have good luck with simple transformation
>> patches on the older drivers ... and it seems to take months before
>> anyone notices there's a problem.
>
> This is the patch
On Fri, 2008-01-18 at 17:32 -0600, James Bottomley wrote:
> On Sat, 2008-01-19 at 08:27 +0900, Tejun Heo wrote:
> > James Bottomley wrote:
> > > On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
> > >> aha152x.c and fdomain are built twice - once for the isa driver and
> > >> once for the PCMCIA
James Bottomley wrote:
>> I personally think it's a bit odd to disallow building into kernel
>> because of the peculiarity of the implementation (including c files and
>> compiling them slightly differently) and also no one reporting doesn't
>> necessarily mean no one has attempted it and failed.
>
On Sat, 2008-01-19 at 08:27 +0900, Tejun Heo wrote:
> James Bottomley wrote:
> > On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
> >> aha152x.c and fdomain are built twice - once for the isa driver and
> >> once for the PCMCIA one. Through #ifdefs, the compiled codes are
> >> slightly differe
Tejun Heo wrote:
> James Bottomley wrote:
>> On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
>>> aha152x.c and fdomain are built twice - once for the isa driver and
>>> once for the PCMCIA one. Through #ifdefs, the compiled codes are
>>> slightly different; thus, global symbols need to be give
James Bottomley wrote:
> On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
>> aha152x.c and fdomain are built twice - once for the isa driver and
>> once for the PCMCIA one. Through #ifdefs, the compiled codes are
>> slightly different; thus, global symbols need to be given different
>> names de
ATA requires that all DMA transfers begin and end on word boundaries.
Because of this, a large amount of machinery grew up in ide to adjust
scatterlists on this basis. However, as of 2.5, the block layer has a
dma_alignment variable which ensures both the beginning and length of a
DMA transfer are
http://bugzilla.kernel.org/show_bug.cgi?id=9775
--- Comment #7 from [EMAIL PROTECTED] 2008-01-18 14:36 ---
Duh! I mean boot with it off, power it up and rescan.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
http://bugzilla.kernel.org/show_bug.cgi?id=9775
--- Comment #6 from [EMAIL PROTECTED] 2008-01-18 14:35 ---
Thanks, I've just done some more testing.
There are no tapes in the drives.
Normally, there is the L80 and a DLT8000 on channel B
and a DLT8000 on channel A
Both busses have ext
http://bugzilla.kernel.org/show_bug.cgi?id=9775
--- Comment #5 from [EMAIL PROTECTED] 2008-01-18 14:27 ---
Reply-To: [EMAIL PROTECTED]
> Latest working kernel version:
> Earliest failing kernel version:
> Distribution: Gentoo
> Hardware Environment: ML150G3, (2Core cpu, 64Bit) AHA
> Latest working kernel version:
> Earliest failing kernel version:
> Distribution: Gentoo
> Hardware Environment: ML150G3, (2Core cpu, 64Bit) AHA3944AUWD card,
> Storagetek
> L80 +2x DLT8000
> Software Environment: gentoo
> Problem Description: kernel panic
>
> Steps to reproduce:
> Panic if
Martin J. Bligh <[EMAIL PROTECTED]> has used the 'sudo' feature to access
Kernel Bug Tracker using your account.
Martin J. Bligh <[EMAIL PROTECTED]> did not provide a reason for doing this.
If you feel that this action was inappropiate, please contact
[EMAIL PROTECTED] For more inf
On Fri, Jan 18, 2008 at 01:32:12PM -0700, Yang, Bo wrote:
> Alan,
>
> The in/outb_p in MegaRAID scsi driver is used for our old io mapped
> megaraid controller. There are still some customers are using those old
> controller. Please keep them.
Hi Bo,
I think you've misunderstood the question.
On Fri, 18 Jan 2008 13:32:12 -0700
"Yang, Bo" <[EMAIL PROTECTED]> wrote:
> Alan,
>
> The in/outb_p in MegaRAID scsi driver is used for our old io mapped
> megaraid controller. There are still some customers are using those old
> controller. Please keep them.
Do they need the I/O delays. If th
Alan,
The in/outb_p in MegaRAID scsi driver is used for our old io mapped
megaraid controller. There are still some customers are using those old
controller. Please keep them.
Thanks.
Bo Yang
-Original Message-
From: Alan Cox [mailto:[EMAIL PROTECTED]
Sent: Friday, January 18, 20
On Thu, 2008-01-10 at 14:53 +0800, Ke Wei wrote:
> The 88SE6440 driver :
>
> The driver is based on bare code from Jeff Garzik. And it can work
> under linux kernel 2.6.23.
> By far, Can discover and find SAS HDD, but SATA is currently
> unsupported. Command queue depth can be above 1.
> Most erro
On Thu, 2008-01-10 at 02:21 -0500, Jeff Garzik wrote:
> Jeff Garzik wrote:
> > 1) To make it easier for people to review and test the driver, I would
> > suggest posting a diff against 2.6.24-rc7 (or 2.6.23), ignoring my
> > original code. Thus, it would result in a patch
>
> Er, that sentence
On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
> aha152x.c and fdomain are built twice - once for the isa driver and
> once for the PCMCIA one. Through #ifdefs, the compiled codes are
> slightly different; thus, global symbols need to be given different
> names depending on which flavor is b
I notice the MegaRAID driver uses outb_p. Can someone at LSI confirm that
the delays between each I/O are required, and if so how long they must be.
I'm trying to sort out the use of in/outb_p and where it is unneccessary
or used for non ISA devices.
(Please cc me on the reply)
Alan
-
To unsubs
Pete Wyckoff wrote:
I have performed a test to compare the performance of SCST and STGT.
Apparently the SCST target implementation performed far better than
the STGT target implementation. This makes me wonder whether this is
due to the design of SCST or whether STGT's performance can be
improved
On Jan 17, 2008 6:45 PM, Pete Wyckoff <[EMAIL PROTECTED]> wrote:
> There's nothing particularly stunning here. Suspect Bart has
> configuration issues if not even IPoIB will do > 100 MB/s.
Regarding configuration issues: the systems I ran the test on probably
communicate via PCI-e x4 with the Inf
22 matches
Mail list logo
