transport is IB without a link-layer callback,
> > which means it doesn't support IBoE...
> >
> > And there is no method to change the port link-layer type as mlx4 did.
>
> Hal, is that correct?
The mlx5 Ethernet driver has not yet been submitted to the linux kernel.
On Wed, 2015-04-22 at 14:46 -0600, Jason Gunthorpe wrote:
> On Wed, Apr 22, 2015 at 02:53:11PM -0400, Doug Ledford wrote:
>
> > To be precise, the split is that ipath powers the old HTX bus cards that
> > only work in AMD systems, qib is all PCI-e cards. I still have a few
&g
t is that ipath powers the old HTX bus cards that
> > only work in AMD systems,
>
> Do those systems have PAT support? CAn anyone check if PAT is enabled
> if booted on a recent kernel?
I don't have one of these systems any more. The *only* one I ever had
was a monster I
se are all old SDR cards, where the performance numbers were 800MB/s
with WC enabled, 50MB/s without it.
> Mike?
>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: This is a digitally signed message part
On Wed, 2015-04-22 at 19:37 +0200, Luis R. Rodriguez wrote:
> On Wed, Apr 22, 2015 at 12:57:18PM -0400, Doug Ledford wrote:
> > On Wed, 2015-04-22 at 17:33 +0200, Luis R. Rodriguez wrote:
> > > On Wed, Apr 22, 2015 at 09:54:38AM -0400, Doug Ledford wrote:
> > > > On
On Wed, 2015-04-22 at 17:33 +0200, Luis R. Rodriguez wrote:
> On Wed, Apr 22, 2015 at 09:54:38AM -0400, Doug Ledford wrote:
> > On Tue, 2015-04-21 at 14:50 -0700, Luis R. Rodriguez wrote:
> >
> > This:
> > > + /* MTRR was used if this is non-zero */
> > > +
On Wed, 2015-04-22 at 15:21 +, Devesh Sharma wrote:
> > -Original Message-
> > From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
> > ow...@vger.kernel.org] On Behalf Of Doug Ledford
> > Sent: Wednesday, April 22, 2015 8:33 PM
> > To: Michael Wa
IB
>
> Cc: Hal Rosenstock
> Cc: Steve Wise
> Cc: Tom Talpey
> Cc: Jason Gunthorpe
> Cc: Doug Ledford
> Cc: Ira Weiny
> Cc: Sean Hefty
> Signed-off-by: Michael Wang
> ---
> drivers/infiniband/core/device.c | 1 +
> drivers/infiniband/co
2/27.
> This back-and-forth between rdma_ib_or_iboe() and cap_* is confusing and
> increases the number of patches in the patch-set.
> Do this and remove patches 16-24.
>
> 2)The name rdma_tech_* is lame.
> rdma_transport_*(), adhering to the above (*) remark, is much better.
s_wc_add(pioaddr, piolen);
> + if (dd->wc_cookie < 0)
> + ret = -EINVAL;
don't agree on what wc_cookie will be on error.
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: This is a digitally signed message part
Skip this patch please. You remove this line entirely in your next
patch, so this becomes a single kernel out of all possible bisectable
kernels with this accounting enabled, and then the very next kernel does
away with it. It makes no sense to have a single outlying bisectable
kernel like that.
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: This is a digitally signed message part
On Thu, 2015-04-09 at 10:01 -0600, Jason Gunthorpe wrote:
> On Thu, Apr 09, 2015 at 10:34:30AM -0400, Doug Ledford wrote:
>
> > These are exactly the tests I proposed Jason. I'm not sure I see your
> > point here. I guess my point is that although the scenario of all
On Wed, 2015-04-08 at 14:10 -0600, Jason Gunthorpe wrote:
> On Wed, Apr 08, 2015 at 02:29:46PM -0400, Doug Ledford wrote:
>
> > To straighten all this out, lets break management out into the two
> > distinct types:
> >
> > rdma_port_ib_fabric_mgmt() <- fabric s
IB IB
> mthca IB_CA IB IB IB
> qib IB_CA IB IB IB
>
> Cc: Jason Gunthorpe
> Cc: Doug Ledford
> Cc: Ira Weiny
> Cc: Sean Hefty
> Signed-off-by: Michael Wang
> ---
On Mon, 2015-03-30 at 18:42 +0200, Michael Wang wrote:
> On 03/30/2015 06:16 PM, Doug Ledford wrote:
> > On Fri, 2015-03-27 at 16:46 +0100, Michael Wang wrote:
> >> Introduce helper has_sa() and cap_sa() to help us check if an IB device
> >> or it's port support S
On Mon, 2015-03-30 at 18:14 +0200, Michael Wang wrote:
> Hi, Doug
>
> Thanks for the comments :-)
>
> On 03/30/2015 05:56 PM, Doug Ledford wrote:
> > On Fri, 2015-03-27 at 16:40 +0100, Michael Wang wrote:
> >> We have so much places to check transport type and l
On Fri, 2015-03-27 at 16:42 +0100, Michael Wang wrote:
> Introduce helper tech_iboe() to help us check if the port of an IB
> device is using RoCE/IBoE technology.
Just use rdma_transport_is_roce() instead.
> Cc: Jason Gunthorpe
> Cc: Doug Ledford
> Cc: Ira Weiny
> Cc: Se
there is also no reason for both
has_sa and cap_sa. Just use one.
> Cc: Jason Gunthorpe
> Cc: Doug Ledford
> Cc: Ira Weiny
> Cc: Sean Hefty
> Signed-off-by: Michael Wang
> ---
> drivers/infiniband/core/sa_query.c | 12 ++--
> include/rdma/ib_verbs.h
On Fri, 2015-03-27 at 16:47 +0100, Michael Wang wrote:
> Introduce helper has_iwarp() to help us check if an IB device
> support IWARP protocol.
This is a needless redirection. Just stick with the original
rdma_transport_is_iwarp().
> Cc: Jason Gunthorpe
> Cc: Doug Ledford
>
unthorpe
> Cc: Doug Ledford
> Cc: Ira Weiny
> Cc: Sean Hefty
> Signed-off-by: Michael Wang
> ---
> drivers/infiniband/core/cma.c | 2 +-
> drivers/infiniband/core/multicast.c | 8
> include/rdma/ib_verbs.h | 28
&
ords, if our end goal is to have
rdma_transport_is_ib()
rdma_transport_is_iwarp()
rdma_transport_is_roce()
rdma_transport_is_opa()
Then we should skip doing rdma_port_ll_is_*() as the answers to these
items would be implied by rdma_transport_is_roce() and such.
> Cc: Jason Gunthorpe
> Cc: Doug Ledf
lid: 0
port_lid: 0
port_lmc: 0x00
link_layer: Ethernet
> Regardless I think we should define the SA access on a per port basis.
Yes.
> >
> > Cc: Jason Gunthorpe
&
On Thu, 2015-03-26 at 17:04 +0100, Michael Wang wrote:
> Hi, Doug
>
> Thanks for the excellent comments :-)
>
> On 03/26/2015 03:09 PM, Doug Ledford wrote:
> > On Wed, 2015-03-25 at 16:09 +0100, Michael Wang wrote:
> >> [snip]
> >>
> > [snip]
>
t we hide the information we
need to know what sort of device we are working on in two different
fields: the transport and the link layer. Instead, just use one field
with enough variants that we can store all of the relevant information
we need in that one field. This has the benef
m this list. The set can be found here in
case you've lost them:
https://patchwork.kernel.org/bundle/dledford/IPoIB%20Locking%20Fixes/
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: This is a digitally signed message part
On Tue, 2014-09-30 at 12:12 +0200, Michael Kerrisk (man-pages) wrote:
> Hi Doug,
>
> On Mon, Sep 29, 2014 at 7:28 PM, Doug Ledford wrote:
> > On Mon, 2014-09-29 at 11:10 +0200, Michael Kerrisk (man-pages) wrote:
> >> Hello Doug, David,
> >>
> >>
, but privileged pro‐
> cesses (CAP_SYS_RESOURCE) can exceed the limit.
>
> * Since Linux 3.5, there is a ceiling for this limit of
> 1024 (HARD_QUEUESMAX). Privilegedprocesses
> (CAP_SYS_RESOURCE) can exceed the queues_
fallback to the
> original way of dealing queue limits -- where once a user's resource limit
> is reached, and all memory is used, new queues cannot be created.
>
> Reported-by: m...@silodev.com
> Cc: Doug Ledford
Acked-by: Doug Ledford
> Cc: Manfred Spraul
On 02/08/2014 11:17 PM, Davidlohr Bueso wrote:
On Fri, 2014-02-07 at 16:24 -0500, Doug Ledford wrote:
On 2/7/2014 3:11 PM, Davidlohr Bueso wrote:
On Thu, 2014-02-06 at 12:21 +0200, m...@silodev.com wrote:
Hi Folks,
I have recently ported my multi-process application (like a classical open
On 2/7/2014 3:11 PM, Davidlohr Bueso wrote:
> On Thu, 2014-02-06 at 12:21 +0200, m...@silodev.com wrote:
>> Hi Folks,
>>
>> I have recently ported my multi-process application (like a classical open
>> system) which uses POSIX Queues as IPC to one of the latest Linux kernels,
>> and I have faced is
On 11/08/2013 11:04 AM, Paul Gortmaker wrote:
Paul Gortmaker (1):
scsi: delete decade+ obsolete aic7xxx_old driver
Documentation/scsi/00-INDEX | 2 -
Documentation/scsi/aic7xxx_old.txt | 511 --
MAINTAINERS | 1 -
drivers/scsi/K
On 10/30/2013 07:02 AM, Neil Horman wrote:
That does makes sense, but it then begs the question, whats the advantage of
having multiple alu's at all?
There's lots of ALU operations that don't operate on the flags or other
entities that can be run in parallel.
If they're just going to seria
On 10/30/2013 08:18 AM, David Laight wrote:
/me wonders if rearranging the instructions into this order:
adcq 0*8(src), res1
adcq 1*8(src), res2
adcq 2*8(src), res1
Those have to be sequenced.
Using a 64bit lea to add 32bit quantities should avoid the
dependencies on the flags register.
Howeve
* Neil Horman wrote:
> 3) The run times are proportionally larger, but still indicate that Parallel
> ALU
> execution is hurting rather than helping, which is counter-intuitive. I'm
> looking into it, but thought you might want to see these results in case
> something jumped out at you
So here'
On 10/26/2013 07:55 AM, Ingo Molnar wrote:
>
> * Doug Ledford wrote:
>
>>> What I was objecting to strongly here was to measure the _wrong_
>>> thing, i.e. the cache-hot case. The cache-cold case should be
>>> measured in a low noise fashion, so that results ar
On 10/19/2013 04:23 AM, Ingo Molnar wrote:
>
> * Doug Ledford wrote:
>> All prefetch operations get sent to an access queue in the memory
>> controller where they compete with both other reads and writes for the
>> available memory bandwidth. The optimal prefetch windo
On Mon, 2013-10-14 at 22:49 -0700, Joe Perches wrote:
> On Mon, 2013-10-14 at 15:44 -0700, Eric Dumazet wrote:
>> On Mon, 2013-10-14 at 15:37 -0700, Joe Perches wrote:
>> > On Mon, 2013-10-14 at 15:18 -0700, Eric Dumazet wrote:
>> > > attached patch brings much better results
>> > >
>> > > lpq83:~
On 2013-10-17, Ingo wrote:
> * Neil Horman wrote:
>
>> On Mon, Oct 14, 2013 at 03:18:47PM -0700, Eric Dumazet wrote:
>> > On Mon, 2013-10-14 at 14:19 -0700, Eric Dumazet wrote:
>> > > On Mon, 2013-10-14 at 16:28 -0400, Neil Horman wrote:
>> > >
>> > > > So, early testing results today. I wrote
t Linux 7.0 days).
--
Doug Ledford
GPG KeyID: 0E572FDD
http://people.redhat.com/dledford
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kern
Yes, this driver is well past ready to be removed.
Acked-by: Doug Ledford
Sent from my ASUS Pad
Paul Gortmaker wrote:
>After getting warnings in an allyesconfig build[1] from this
>driver, I decided to remind myself just how old it was, and
>whether it warranted fixing. In the Kco
On 08/12/2013 11:09 AM, Sasikantha Babu wrote:
> In the first patch since we removed calling mq_attr_ok to validate
> mqueue attributes default/ceil values, So removing the unused def_attr
>
> Signed-off-by: Sasikantha Babu
> ---
> ipc/mqueue.c |7 ---
> 1 files changed, 0 insertions(+),
On 08/12/2013 11:09 AM, Sasikantha Babu wrote:
> Kernel should not validate queue attributes default/ceiling value while
> creating a mqueue, if user pass attr as NULL. Otherwise In worst case
> If the validation fails then sys_mq_open returns -EINVAL/-EOVERFLOW
> which will make user clueless abou
?
>
> Given that, with user namespaces, it'll soon be possible for users who
> are unprivileged toward the host to be able to create and destroy
> namespaces, if the patch ends up making it easy for a user to consume a
> bunch of system time and not have it accounted at
s and variables via case.
> So I don't agree with (or understand) your objections. But I can certainly
> understand reluctance to merge a large-but-minor, do-nothing-much patch into
> a large and not-very-maintained driver.
Hehehe...and here I was thinking of factoring that t
if (bdev) {
> mutex_lock(&bdev->bd_inode->i_mutex);
> i_size_write(bdev->bd_inode, (loff_t)mddev->array_size
> << 10);
> mutex_unlock(&bdev->bd_inode->i_mutex);
> bdput(bdev);
> }
> }
> return rv;
> }
--
Doug Ledford <[EMAIL PROTECTED]>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed message part
atters." I
don't know why nVidia keeps their specs secret. All I know is what they
tell the world. But what I do know is that it's *possible* they could
be telling the truth, and I have no proof otherwise, regardless of any
suspicions.
--
Doug Ledford <[EMAIL PROTECTED]>
http:
7;s a big part
of what makes it very fast, lots of room for driver optimizations and
enhanced feature support).
--
Doug Ledford <[EMAIL PROTECTED]>
http://people.redhat.com/dledford
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
e
benefits in terms of inter-processor bus pressure.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
-
To unsubscribe from this list: send the line "u
an strace of amp seems to halt on writing to the /dev/dsp
>
> I have an Intel Celeron on an Asus-MEW motherboard which has this soundcard
> integrated.
>
> Any ideas?
Can you try xmms with the oss output module and tell me if that works?
--
Doug Ledford <[EMAIL PROTECTED]>
"Adam J. Richter" wrote:
>
> Doug Ledford wrote:
> >"Adam J. Richter" wrote:
>
> >> On the question of whether this is nothing more than
> >> aggregation,
>
> >Yes, on that very question, I would argue it is a mere aggr
San Jose, California 95129-1034
> +1 408 261-6630 | g g d r a s i l United States of America
> fax +1 408 261-6631 "Free Software For The Rest Of Us."
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the
ly unlikely that there exists a
motherboard BIOS that *doesn't* at least assign the I/O space area and the IRQ
for all bootable devices on the system, regardless of PnPOS settings. Name
one concrete example of a motherboard BIOS that doesn't and I'll recant.
--
Doug Ledford <[EMA
vulnerable to BIOS table bugs like this likely exposes, where as if you
didn't touch boot devices, then buggy BIOSes wouldn't bring your kernel to a
halt as easily.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx u
worry about new PCI cards getting thrown
in, and yet we are remapping the IRQs. Why?
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
-
To un
now coming in on IRQ 10 and as a result,
things don't work.
Now, I'm all for blaming Intel BIOS bugs if they are the cause of the problem,
but I'm having a hard time seeing that here...
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please chec
Max TenEyck Woodbury wrote:
>
> Doug Ledford wrote:
> >
> > Max TenEyck Woodbury wrote:
> >>
> >> Umm. Reboot? What do you think this is? Windoze?
> >
> > It's the *only* way to guarantee that the drive is never touched by more
> > than
failed writes on the primary path, I think this is of
dubious value. Right now, as I see it, multipath and failover simply don't
mix well. There is more work needed to make it work well.
> If this not any clearer than my last mail I will just wait to see the code
> :-).
>
&
capability could be plugged into this service so
> that users could reduce recoding depending on which fencing support they
> selected.
I wouldn't know about that.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx u
Max TenEyck Woodbury wrote:
>
> Doug Ledford wrote:
> >
> > ...
> >
> > If told to hold a reservation, then resend your reservation request once every
> > 2 seconds (this actually has very minimal CPU/BUS usage and isn't as big a
> > deal as reque
"Eric Z. Ayers" wrote:
>
> Doug Ledford writes:
> (James Bottomley commented about the need for SCSI reservation kernel patches)
> >
> > I agree. It's something that needs fixed in general, your software needs it
> > as well, and I've written
tware geared towards getting/holding reservations that also requires the
same kernel patches (plus one more to be fully functional, an ioctl to allow a
SCSI reservation to do a forced reboot of a machine). I'll be releasing that
package in the short term (once I get back from my vacation an
he active path has already failed, which it doesn't currently
attempt to do when writing superblocks or reading partition tables).
> Is there any documentation about the changes in the SCSI-driver interfaces
> from 2.2 -> 2.4 (eg. in sd.c) ?
--
Doug Ledford <[EMAIL PROTECTED]&
he code, so it
will take me a little bit to figure out where it is screwing up at.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
-
To unsubscribe
scribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please chec
on my dell
> workstation (which has a need to have set explictely to a clocking of
> 41194 via ftsodell option), compiling without esd seems fix the prob
> for me.
The latest i810 driver does away with the ftsodell option entirely and should
work on your laptop without having to do any
in the ac
series kernels, but I don't know what happened to make it into 2.4.3. I'm
fixing one last known bug in the driver tonight, and when I'm done I'll put a
patch against 2.4.3 on my web site and drop a note here.
--
Doug Ledford <[EMAIL PROTECTED]> http://p
t CEOs actually pay attention
to how much distress IS is causing the rest of the company and give them a
swift kick in the ass to straighten things out (assuming you have a CEO worth
a damn, that assumption could be totally wrong).
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dled
Rik van Riel wrote:
>
> On Tue, 27 Mar 2001, Doug Ledford wrote:
>
> > I've been using our internal tree for my testing, and I'm reluctant to
> > let my experiences there cause me to draw conclusions about other
> > trees. So, will you please tell me whic
tuations so I can test it here to see
if you are right?
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
-
To unsubscribe from this list: send the line
Mike Galbraith wrote:
>
> On Sat, 24 Mar 2001, Doug Ledford wrote:
> > To those people that would suggest I send in code I only have this to say.
> > Fine, I'll send in a patch to fix this bug. It will make the oom killer call
> > the cache reclaim functions and nev
really an oom killer, it's more like an "I'm Too Lazy To Free Up
Some More Pages So Now You Die" (ITLTFUSMPSNYD) killer.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
sn't need to.
To those people that would suggest I send in code I only have this to say.
Fine, I'll send in a patch to fix this bug. It will make the oom killer call
the cache reclaim functions and never kill anything. That would at least fix
the bug you see above.
--
Alan Cox wrote:
> o Next incarnation of the i810 audio driver (Doug Ledford)
Is this the i810 that's in Red Hat's CVS or the last copy of the big file that
I sent you? If it's the last copy of the big file I sent you, then it has a
memory leak that needs fixed. I
al easy to reproduce too.
Take your favorite machine with lots of RAM, run just a handful of startup
process and system daemons, then log in on a few terminals and do:
while true; do bonnie -s (1/2 ram); done
Pretty soon, system daemons will start to die.
--
Doug Ledford <[EMAIL PROTECTED]&
is in need of killing sshd, I'll claim you are smoking some nice stuff ;-)
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
-
To unsubscribe fro
n
a decent sound driver though, it shouldn't have to.
> -d
>
> Doug Ledford wrote:
>
> > David Ford wrote:
> > >
> > > Actually you probably upgraded to a non-broken version of esd. Stock esd -still-
> > > writes to the socket without regard to re
c.patch.
Why would esd get a short write() unless it is opening the file in non
blocking mode (which I didn't see when I was working on the i810 sound
driver)? If esd is writing to a file in blocking mode and that write is
returning short, then that sounds like a driver bug to me.
--
the problem you are referring to only
happens when a driver module is loaded prior to sd_mod.o, and that reversing
the order will solve the problem (but, I haven't looked so I could easily be
wrong ;-)
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Plea
ilities and
starts to confirm my position.
> Maybe someone can explain the meaning of the illegal
> requests at the end. Nevertheless, I can use the drive fine.
As to the illegal request messages, I'm not sure what those are about ;-)
--
Doug Ledford <[EMAIL PROTECTED]> http:/
d simply wait for the 2.5 development and debugging cycle?)
It would still be helpful because this problem has to be fixed before 2.5.
The only question is whether to fix it with a simple patch such as I just
submitted, or a more complex patch that uses REPORT LUNs. Part of that answer
is h
that when I worked
> Why wait for a check condition? There's an INQUIRY field bit that
> indicates whether REPORT LUNs is supported.
And I'm all for using it in the 2.5 kernel SCSI stack ;-)
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please
Doug Ledford wrote:
> Patches welcomed. The one I sent already works on a fiber channel setup (the
> qla2x00 in question is fc and so is the Clariion array it's connected to, no
> detrimental side effects from scanning the box) and so I'm not inclined to add
> a REPORT LU
Pete Zaitcev wrote:
>
> > Date: Wed, 14 Mar 2001 21:28:14 -0500
> > From: Doug Ledford <[EMAIL PROTECTED]>
>
> > A bug report I was charged with fixing (qla2x00 driver doesn't see all luns or
> > sees multiple identical luns in different scenarios
ist. If that's not the case, and they list their
luns as all being connected, then this patch needs to go into the mainstream
kernel.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
Alan Cox wrote:
> 2.4.2-ac14
> o Updated i810_audio.c (Doug Ledford)
I wanted to let people know that there is a lot of new code in this particular
update that needs testing. The nice thing is that quake3 should now play with
this sound driver so the testi
B/C SEEPROM
entry as needed. That should solve the problem anyway. Of course, it could
simply be something else that is wrong and I could be smoking crack ;-)
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updat
.
Sounds like an IRQ routing problem. Have you tried a UP kernel with IO-APIC
on UP support disabled or an SMP kernel both with and without the noapic
options to see if they make a difference?
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web
e correct test. However, the memory location in the fxsr structure was
reserved by the time the fxsr was put together, so the worst this does is give
an undefined mxcsr value on machines where mxcsr doesn't exist, which is why I
didn't yell too loudly when Linus dropped that line out
h your compiler, your fix in place, and then try to run
it on a PIII or later CPU and it will Oops all over the place. Run it on any
CPU that supports FXSAVE and it will likely blow chunks (all the Intel CPUs
will, but I don't know for sure about the AMD CPUs that support FXSAVE).
--
Doug
Ville Herva wrote:
>
> On Thu, Feb 08, 2001 at 06:16:01PM +0200, you [Ville Herva] claimed:
> > On Thu, Feb 08, 2001 at 07:53:55AM -0500, you [Doug Ledford] claimed:
> > > Ville Herva wrote:
> > > >
> > > > It looks like ac6 (which I believe include
Carlos Carvalho wrote:
>
> Doug Ledford ([EMAIL PROTECTED]) wrote on 9 February 2001 16:41:
> >The latest patch I sent Alan had both the hosts.c fix and some other fixes, so
> >I'm thinking it hasn't made it into his 2.2.19pre9 kernel. The next one
> >sho
Manfred Spraul wrote:
>
> Doug Ledford wrote:
> >
> > > I have this strong suspicion that your kernel will lock up in a bad way
> > > of you have somebody do something like divide by zero without actually
> > > touching a single FP instruction
s,
they make an aggregate performance difference to the typical running of the
kernel (and this was without copy_page or zero_page being optimized, instead I
had done memset, memcpy, copy_*_user as optimized routines) and they make a
huge difference to benchmarks that target the areas they help the mos
-
>
> The machine waits "ad infinitum".
>
The latest patch I sent Alan had both the hosts.c fix and some other fixes, so
I'm thinking it hasn't made it into his 2.2.19pre9 kernel. The next one
should work fine as far as aic7xxx is concerned.
--
> >
> > I confirm that ac7 fixed all the aic7xxx problems on my machine.
Thanks, I hoped it would ;-) It's amazing what happens when you have a bcopy
in assembly that's missing the source address initialization :-(
--
Doug Ledford <[EMAIL PROTECTED]> http://peopl
.2.1 driver because it limits your Quantum drive to 80MByte/s and that
particular speed doesn't include CRC checking. On this driver you have to be
running at 160MByte/s before CRC checking is enabled.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Plea
So, what this driver really needs is someone with a 7895 and someone with a
VLB/EISA controller to test it out. All the other controllers should be
working reliably at this point.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for ai
t; > The Linux 2.4.2-pre1 works fine. Next thing I was thinking was to try ac4
> > and also to try on a different machine which has a different revision of
> > the same type of aic7xxx HBA.
> >
>
> I am running ac5 on a AHA-2940U2/W, no problem.
>
> I patch
equencer code). It resulting in invalid instructions getting
downloaded to every controller prior to a 7895. The attached patch should
solve people's problems with this. (Note, this patch wasn't made against a
full linux tree, so cd into driver/scsi and use patch -p1 in order to a
Andrea Arcangeli wrote:
>
> On Wed, Oct 25, 2000 at 02:46:19PM -0400, Doug Ledford wrote:
> > @@ -214,8 +215,8 @@
> > movb ready,%al # First CPU if 0
> > orb %al,%al
> > jz 4f # First CPU skip this stuff
> > - m
401 - 500 of 502 matches
Mail list logo
