comes from? or do I need to
specify the BAR using a mask?
Would some one be able to point me to an example code please?
Thanks and Regards,
Sanka
Your question doesn't seem to make much sense. DMA transfers have
nothing to do with BARs at all, they don't come from or to one.
--
Robert
Ignacy Gawedzki wrote:
Hi everyone,
I'm having trouble to determine the cause of the following behavior. I'm not
even sure that I'm supposed to hot plug and unplug a SATA drive from a nForce3
Ultra (apparently CK8S, on a Gigabyte K8NS Ultra 939 mobo) SATA interface, to
begin with. The
Ignacy Gawedzki wrote:
Hi everyone,
I'm having trouble to determine the cause of the following behavior. I'm not
even sure that I'm supposed to hot plug and unplug a SATA drive from a nForce3
Ultra (apparently CK8S, on a Gigabyte K8NS Ultra 939 mobo) SATA interface, to
begin with. The
Jeff Garzik wrote:
Robert Hancock wrote:
Jeff Garzik wrote:
Ping... sata_nv status is still a bit open for 2.6.24, and I would
like to move us forward a bit.
* Kuan's patch... it has been confirmed (and is needed), correct?
can someone work up a good patch for 2.6.24? The only one I
Kuan Luo wrote:
First thank davide to help to send the attachment.
Robert,
The patch is to solve the error message "ata1: CPB flags CMD err,
flags=0x11" when testing HDS7250SASUN500G in rhel4u5.
I tested this hd in 2.6.24-rc7 which needed to remove the mask in
blacklist to run the ncq and the
Jeff Garzik wrote:
Ping... sata_nv status is still a bit open for 2.6.24, and I would like
to move us forward a bit.
* Kuan's patch... it has been confirmed (and is needed), correct? can
someone work up a good patch for 2.6.24? The only one I ever received
was badly word-wrapped, and at
Jeff Garzik wrote:
Ping... sata_nv status is still a bit open for 2.6.24, and I would like
to move us forward a bit.
* Kuan's patch... it has been confirmed (and is needed), correct? can
someone work up a good patch for 2.6.24? The only one I ever received
was badly word-wrapped, and at
Kuan Luo wrote:
First thank davide to help to send the attachment.
Robert,
The patch is to solve the error message ata1: CPB flags CMD err,
flags=0x11 when testing HDS7250SASUN500G in rhel4u5.
I tested this hd in 2.6.24-rc7 which needed to remove the mask in
blacklist to run the ncq and the
Jeff Garzik wrote:
Robert Hancock wrote:
Jeff Garzik wrote:
Ping... sata_nv status is still a bit open for 2.6.24, and I would
like to move us forward a bit.
* Kuan's patch... it has been confirmed (and is needed), correct?
can someone work up a good patch for 2.6.24? The only one I
duty cycle. If the CPU is
already idle this has no effect and won't save any power.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line "unsubscri
ond my ken. The outputs of the
above two are the same.
$./a.out
before vfork
1
Could anyone help me with this? Thanks.
Why do you expect a different result? Also, calling exit from a vforked
child is explicitly not allowed. The only things you can do are execve
or _exit.
--
Robert Hancoc
f your driver
would also be useful. One common problem is not calling
pci_enable_device before requesting the interrupt..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe
be useful. One common problem is not calling
pci_enable_device before requesting the interrupt..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line unsubscribe linux
Could anyone help me with this? Thanks.
Why do you expect a different result? Also, calling exit from a vforked
child is explicitly not allowed. The only things you can do are execve
or _exit.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page
duty cycle. If the CPU is
already idle this has no effect and won't save any power.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
Matt Mackall wrote:
Your usage of "overall power" here is wrong. Power is an instantaneous
quantity (1/s) like velocity, and you are comparing it to energy which
is not an instaneous quantity, more like distance.
If we throttle the velocity of a car from 100km/h to 50km/h, it'll
obviously take
David Newall wrote:
Andi Kleen wrote:
Isn't it the case that an idle machine will use
less power when throttled than when not?
No that is not the case (not even on old CPUs)
Then why would it run cooler? What generates the heat when not
throttled? What stops generating heat when
David Newall wrote:
Andi Kleen wrote:
Isn't it the case that an idle machine will use
less power when throttled than when not?
No that is not the case (not even on old CPUs)
Then why would it run cooler? What generates the heat when not
throttled? What stops generating heat when
Matt Mackall wrote:
Your usage of overall power here is wrong. Power is an instantaneous
quantity (1/s) like velocity, and you are comparing it to energy which
is not an instaneous quantity, more like distance.
If we throttle the velocity of a car from 100km/h to 50km/h, it'll
obviously take
James Bottomley wrote:
On Sun, 2008-01-13 at 16:29 +, Alan Cox wrote:
Yes, I concur for the short term. The other two possible courses of
action either involve long discussions (the different device one) or
you'll never quite be sure you got all the paths (the GFP_DMA32 one).
At least with
no wonder it has not been reliable to try and
use MMCONFIG in the past..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-k
in the past..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
James Bottomley wrote:
On Sun, 2008-01-13 at 16:29 +, Alan Cox wrote:
Yes, I concur for the short term. The other two possible courses of
action either involve long discussions (the different device one) or
you'll never quite be sure you got all the paths (the GFP_DMA32 one).
At least with
Kuan Luo wrote:
Robert hancock wrote:
What problem does this resolve? I tested it against the cache
flush/NCQ
write switching problem we've been trying to solve, and it
doesn't look
like it fixes that one - if I apply this patch and then remove the
udelay(20) in sata_nv.c that I added which
Kuan Luo wrote:
Robert hancock wrote:
What problem does this resolve? I tested it against the cache
flush/NCQ
write switching problem we've been trying to solve, and it
doesn't look
like it fixes that one - if I apply this patch and then remove the
udelay(20) in sata_nv.c that I added which
an's patch or
not, otherwise if a driver does opt in and tries to use extended config
space it will still break. And if they are resolved, the patch seems
quite pointless.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://w
James Bottomley wrote:
On Sat, 2008-01-12 at 17:04 -0600, Robert Hancock wrote:
I don't think the problem is that there's some buffer which is getting
allocated above 4GB and never bounced, since the problem goes away if
ADMA is disabled entirely and the DMA mask remains 32-bit always. My
James Bottomley wrote:
With mem<=4098M or sata_nv.adma=0 it still mounts and works ok.
As I wrote, it would appear that somehow the blk_queue_bounce_limit
setting that the driver has made is not being respected and the block
layer is still trying to feed it addresses over 4GB. Any ideas
Alexander wrote:
Robert Hancock wrote:
There's this patch which was intended to fix it:
http://lkml.org/lkml/2007/11/22/148
I applied this patch to 2.6.24-rc7. Now at boot time my DVD-RW is
normaly detected as:
sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
But I
Alexander wrote:
Robert Hancock wrote:
There's this patch which was intended to fix it:
http://lkml.org/lkml/2007/11/22/148
I applied this patch to 2.6.24-rc7. Now at boot time my DVD-RW is
normaly detected as:
sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
But I
James Bottomley wrote:
With mem=4098M or sata_nv.adma=0 it still mounts and works ok.
As I wrote, it would appear that somehow the blk_queue_bounce_limit
setting that the driver has made is not being respected and the block
layer is still trying to feed it addresses over 4GB. Any ideas anyone?
James Bottomley wrote:
On Sat, 2008-01-12 at 17:04 -0600, Robert Hancock wrote:
I don't think the problem is that there's some buffer which is getting
allocated above 4GB and never bounced, since the problem goes away if
ADMA is disabled entirely and the DMA mask remains 32-bit always. My
or
not, otherwise if a driver does opt in and tries to use extended config
space it will still break. And if they are resolved, the patch seems
quite pointless.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com
Gabor Gombas wrote:
On Mon, Jan 07, 2008 at 06:10:29PM -0600, Robert Hancock wrote:
Gabor, I just noticed you said that it worked OK in 2.6.20, yet 2.6.22
fails. 2.6.20 had ADMA support as well, so I wonder what change started
causing the problem. Would it be possible for you to do a git
Kuan Luo wrote:
hi robert,
I have fixed a bug in rhel4u5 2.6.9-55 when running adma mode
with HDS7250SASUN500G.
Could you check this code and if no problem, then help me to
submit to the newest kernel.
What problem does this resolve? I tested it against the cache flush/NCQ
Kuan Luo wrote:
hi robert,
I have fixed a bug in rhel4u5 2.6.9-55 when running adma mode
with HDS7250SASUN500G.
Could you check this code and if no problem, then help me to
submit to the newest kernel.
What problem does this resolve? I tested it against the cache flush/NCQ
Gabor Gombas wrote:
On Mon, Jan 07, 2008 at 06:10:29PM -0600, Robert Hancock wrote:
Gabor, I just noticed you said that it worked OK in 2.6.20, yet 2.6.22
fails. 2.6.20 had ADMA support as well, so I wonder what change started
causing the problem. Would it be possible for you to do a git
it is limited to 32-bit DMA.. Could that be breaking or
insufficient somehow?
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
it has an APIC
mode setting that needs to be enabled).
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
setting that needs to be enabled).
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
it is limited to 32-bit DMA.. Could that be breaking or
insufficient somehow?
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
ata_scsi_dev_config(sdev, dev);
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
used for our purposes, do not touch it". We should be listening.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
not touch it. We should be listening.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
);
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
Guillaume Laurès wrote:
Le 8 janv. 08 à 01:29, Robert Hancock a écrit :
From your report:
ata5: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl
0x1501000 status 0x400
ata5: CPB 0: ctl_flags 0x1f, resp_flags 0x1
ata5: CPB 1: ctl_flags 0x1f, resp_flags 0x2
ata5: CPB 2: ctl_flags
Guillaume Laurès wrote:
Le 8 janv. 08 à 01:29, Robert Hancock a écrit :
From your report:
ata5: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl
0x1501000 status 0x400
ata5: CPB 0: ctl_flags 0x1f, resp_flags 0x1
ata5: CPB 1: ctl_flags 0x1f, resp_flags 0x2
ata5: CPB 2: ctl_flags
Andi Kleen wrote:
On Mon, Jan 07, 2008 at 05:31:58PM -0600, Robert Hancock wrote:
Jesse Barnes wrote:
Hmm -- I didn't see Jesse's mail?
I believe that such a change is in Greg KH's tree. So -mm (with both
trees) would probably work.
Yes 2.6.24-rc6-mm1 works, but plain git-x86 does
ponse. The timeout is
30 seconds, so that means the drive failed to service those queued
commands for that length of time.
It may be that your drive has a poor NCQ implementation that can starve
some of the pending commands for a long time under heavy load?
--
Robert Hancock Saskatoon,
Allen Martin wrote:
Dunno about the NVidia version.
Theirs works rather differently - the GO bit is there, but there's
another append register which is used to tell the controller
that a new
tag has been added to the CPB list.
The only thing we currently use the GO bit for is to switch
Jesse Barnes wrote:
On Monday, January 07, 2008 2:47 Andi Kleen wrote:
This patch
commit c5182babd1d0706f1294af7b8dbf64e378b066bb
Author: Robert Hancock <[EMAIL PROTECTED]>
Date: Sat Jan 5 13:26:32 2008 +0100
x86: validate against ACPI motherboard resources
...
recently added
Jesse Barnes wrote:
On Monday, January 07, 2008 2:47 Andi Kleen wrote:
This patch
commit c5182babd1d0706f1294af7b8dbf64e378b066bb
Author: Robert Hancock [EMAIL PROTECTED]
Date: Sat Jan 5 13:26:32 2008 +0100
x86: validate against ACPI motherboard resources
...
recently added to git-x86
Allen Martin wrote:
Dunno about the NVidia version.
Theirs works rather differently - the GO bit is there, but there's
another append register which is used to tell the controller
that a new
tag has been added to the CPB list.
The only thing we currently use the GO bit for is to switch
seconds, so that means the drive failed to service those queued
commands for that length of time.
It may be that your drive has a poor NCQ implementation that can starve
some of the pending commands for a long time under heavy load?
--
Robert Hancock Saskatoon, SK, Canada
To email, remove
Andi Kleen wrote:
On Mon, Jan 07, 2008 at 05:31:58PM -0600, Robert Hancock wrote:
Jesse Barnes wrote:
Hmm -- I didn't see Jesse's mail?
I believe that such a change is in Greg KH's tree. So -mm (with both
trees) would probably work.
Yes 2.6.24-rc6-mm1 works, but plain git-x86 does
sks/port.
However, (please correct?) SATA uses a hub type architecture while
SAS uses a switch architecture. My experience with network hubs vs.
switches is that network hubs can be much slower if there is
communication contention. Is the word 'hub' being used in the
"shared-communication
using the term
'hub' as a [sic] replacement for a 'switch'?
I believe that they're essentially the same in that regard, though
someone can correct me if I'm wrong..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http
Linda Walsh wrote:
Robert Hancock wrote:
Looks like the drive reports ERR/ABRT (command aborted), meaning it
likely doesn't support those commands.
---
Except the PATA version of the drive does (same capacity, & other
specs). Seagate would
disable "advanced" fea
Allen Martin wrote:
Dunno about the NVidia version.
Theirs works rather differently - the GO bit is there, but there's
another append register which is used to tell the controller
that a new
tag has been added to the CPB list.
The only thing we currently use the GO bit for is to switch
Linda Walsh wrote:
I seem to remember reading about some problems with Promise SATA & ACPI.
Does this address that or is that a separate issue? (Am using no-acpi for
now, but would like to try acpi again if it may be fixed (last time I tried
it with this card, "sdb" went "offline" (once it
Linda Walsh wrote:
Robert Hancock wrote:
Linda Walsh wrote:
Alan Cox wrote:
rate began falling; at 128k block-reads-at-a-time or larger, it
drops below
20MB/s (only on buffered SATA).
Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.
http://linux-ata.org
Benjamin Herrenschmidt wrote:
Another thing about the PacDigi core: one has to be very careful
to avoid sequential accesses to sequential PCI locations when
programming the chip -- it cannot handle merged register writes.
So for any group of sequentially laid out registers, the code has
to
Benjamin Herrenschmidt wrote:
Another thing about the PacDigi core: one has to be very careful
to avoid sequential accesses to sequential PCI locations when
programming the chip -- it cannot handle merged register writes.
So for any group of sequentially laid out registers, the code has
to
Linda Walsh wrote:
Robert Hancock wrote:
Linda Walsh wrote:
Alan Cox wrote:
rate began falling; at 128k block-reads-at-a-time or larger, it
drops below
20MB/s (only on buffered SATA).
Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.
http://linux-ata.org
Linda Walsh wrote:
I seem to remember reading about some problems with Promise SATA ACPI.
Does this address that or is that a separate issue? (Am using no-acpi for
now, but would like to try acpi again if it may be fixed (last time I tried
it with this card, sdb went offline (once it
Allen Martin wrote:
Dunno about the NVidia version.
Theirs works rather differently - the GO bit is there, but there's
another append register which is used to tell the controller
that a new
tag has been added to the CPB list.
The only thing we currently use the GO bit for is to switch
Mark Lord wrote:
Robert Hancock wrote:
..
From some of the traces I took previously (posted on LKML as "sata_nv
ADMA controller lockup investigation" way back in Feb 07), what seems
to occur is that when the second command is issued very rapidly
(within less than 20 mi
REVISION "\n");
It's been 7.00alpha2 for god knows how long, so clearly this version
number is not useful..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this
Tejun Heo wrote:
Robert Hancock wrote:
Jeff Garzik wrote:
Tejun Heo wrote:
Thanks a lot for the detailed explanation. Nvidia ppl, any ideas?
FLUSH is used regularly. We really need to fix this.
I reiterate my opinion :) ... We should remove ADMA support from
sata_nv. It's only
s, etc, permitted removability)?
I think they were referring to physically hotplugging the drive. This is
more practical if you have a removable drive caddy, or if the drive is
hooked up through eSATA.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from
ly (within
less than 20 microseconds, or potentially longer) after the previous
command's completion, the ADMA status changes from 0x500 (STOPPED and
IDLE) to 0x400 (just IDLE) as it typically does, but then it sticks
there, no interrupt is ever raised, and CPB response flags remain at 0.
less than 20 microseconds, or potentially longer) after the previous
command's completion, the ADMA status changes from 0x500 (STOPPED and
IDLE) to 0x400 (just IDLE) as it typically does, but then it sticks
there, no interrupt is ever raised, and CPB response flags remain at 0.
--
Robert
.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
Tejun Heo wrote:
Robert Hancock wrote:
Jeff Garzik wrote:
Tejun Heo wrote:
Thanks a lot for the detailed explanation. Nvidia ppl, any ideas?
FLUSH is used regularly. We really need to fix this.
I reiterate my opinion :) ... We should remove ADMA support from
sata_nv. It's only
for god knows how long, so clearly this version
number is not useful..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Mark Lord wrote:
Robert Hancock wrote:
..
From some of the traces I took previously (posted on LKML as sata_nv
ADMA controller lockup investigation way back in Feb 07), what seems
to occur is that when the second command is issued very rapidly
(within less than 20 microseconds
Jeff Garzik wrote:
Tejun Heo wrote:
Thanks a lot for the detailed explanation. Nvidia ppl, any ideas?
FLUSH is used regularly. We really need to fix this.
I reiterate my opinion :) ... We should remove ADMA support from
sata_nv. It's only in a few chips, it's not appearing in any new
Robert Hancock wrote:
Tejun Heo wrote:
[cc'ing Robert Hancock and NVidia people]
Whole thread can be read from the following URL.
http://thread.gmane.org/gmane.linux.ide/21710
In a nutshell, with ADMA enabled, FLUSH_EXT occasionally times out. I
first suspected faulty disk (reallocation
Tejun Heo wrote:
[cc'ing Robert Hancock and NVidia people]
Whole thread can be read from the following URL.
http://thread.gmane.org/gmane.linux.ide/21710
In a nutshell, with ADMA enabled, FLUSH_EXT occasionally times out. I
first suspected faulty disk (reallocation failure on flush
ny
ACPI changes very recently in that code.
These lines seem suspicious that the drivers/ide code is doing something
funny to the ACPI layer:
ACPI: Cannot set device to a higher-powered state than parent
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam"
in that code.
These lines seem suspicious that the drivers/ide code is doing something
funny to the ACPI layer:
ACPI: Cannot set device to a higher-powered state than parent
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http
Tejun Heo wrote:
[cc'ing Robert Hancock and NVidia people]
Whole thread can be read from the following URL.
http://thread.gmane.org/gmane.linux.ide/21710
In a nutshell, with ADMA enabled, FLUSH_EXT occasionally times out. I
first suspected faulty disk (reallocation failure on flush
Robert Hancock wrote:
Tejun Heo wrote:
[cc'ing Robert Hancock and NVidia people]
Whole thread can be read from the following URL.
http://thread.gmane.org/gmane.linux.ide/21710
In a nutshell, with ADMA enabled, FLUSH_EXT occasionally times out. I
first suspected faulty disk (reallocation
Jeff Garzik wrote:
Tejun Heo wrote:
Thanks a lot for the detailed explanation. Nvidia ppl, any ideas?
FLUSH is used regularly. We really need to fix this.
I reiterate my opinion :) ... We should remove ADMA support from
sata_nv. It's only in a few chips, it's not appearing in any new
Linda Walsh wrote:
Robert Hancock wrote:
Have you tried using a different block size to see how that effects
the results? There might be some funny interaction there.
There is some interaction with the large block size (but only on the
SATA
disk). Counts were adjusted to keep
ST debug cards would bother to
accurately emulate the ISA timings of normal port 0x80 accesses,
however. Most likely if you plug those in, port 0x80 accesses suddenly
become lots faster now that the writes are completing on the PCI bus
before ever hitting ISA/LPC..
--
Robert Hancock S
to
accurately emulate the ISA timings of normal port 0x80 accesses,
however. Most likely if you plug those in, port 0x80 accesses suddenly
become lots faster now that the writes are completing on the PCI bus
before ever hitting ISA/LPC..
--
Robert Hancock Saskatoon, SK, Canada
To email
Linda Walsh wrote:
Robert Hancock wrote:
Have you tried using a different block size to see how that effects
the results? There might be some funny interaction there.
There is some interaction with the large block size (but only on the
SATA
disk). Counts were adjusted to keep
upper layers will get a failure report,
and I believe at that point the md layer decides to disable the device.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the li
writes. However, I suspect in the majority of implementations
(perhaps all), it indeed does.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line "unsubscri
st tipping
over some internal "flooding" limit which degrades buffered
performance?
Very Confused & TIA,
Linda
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
in the majority of implementations
(perhaps all), it indeed does.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
the md layer decides to disable the device.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Robert Hancock wrote:
Jeff Garzik wrote:
Robert Hancock wrote:
This fixes some problems with ATAPI devices on nForce4 controllers in
ADMA mode
on systems with memory located above 4GB. We need to delay setting
the 64-bit
DMA mask until the PRD table and padding buffer are allocated so
Robert Hancock wrote:
Jeff Garzik wrote:
Robert Hancock wrote:
This fixes some problems with ATAPI devices on nForce4 controllers in
ADMA mode
on systems with memory located above 4GB. We need to delay setting
the 64-bit
DMA mask until the PRD table and padding buffer are allocated so
machine and not the real one..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
uff might be related to this
problem, but if it couldn't be fixed, I think the only sane solution
would be to blacklist MMCONFIG support on that chipset.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
non-global problems I'm aware
of are devices behind host bridges which can't receive/handle MMCONFIG
requests, in which case the problem would be bus-wide.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
oss resume or
something? Anyway, I asked it to please stop doing that, and it
complied without even exploding (unlike crabby APICs).
Are we missing some logic to resync the TSCs after resume, or something?
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EM
201 - 300 of 1555 matches
Mail list logo
