of the embedded call
to pci_set_master().
This isn't good, and these may not be the only devices affected in this way.
Can we perhaps not do that, or provide some other way to return control of
bus-mastering
to the device driver ?
--
ml...@pobox.com
Mark Lord
--
To unsubscribe from this list: send the line
On 14-04-08 02:27 PM, Bjorn Helgaas wrote:
[+cc Ben, linux-pci]
On Tue, Apr 8, 2014 at 10:34 AM, Mark Lord ml...@pobox.com wrote:
I am working a couple of drivers for chips that perform extensive
bus-mastering ops.
These including full SRIOV support, and allow assigning virtual functions
On 14-04-03 05:28 PM, J. Bruce Fields wrote:
> On Thu, Apr 03, 2014 at 04:48:11PM -0400, Mark Lord wrote:
>> On 14-04-03 03:30 PM, J. Bruce Fields wrote:
>>> On Thu, Apr 03, 2014 at 01:51:06PM -0400, Mark Lord wrote:
>>>> On 14-04-03 01:16 PM, J. Bruce Fields wro
On 14-04-03 03:30 PM, J. Bruce Fields wrote:
> On Thu, Apr 03, 2014 at 01:51:06PM -0400, Mark Lord wrote:
>> On 14-04-03 01:16 PM, J. Bruce Fields wrote:
>>> On Thu, Apr 03, 2014 at 12:33:55PM -0400, Mark Lord wrote:
>>>> This commit from linux-3.14 br
On 14-04-03 04:15 PM, J. Bruce Fields wrote:
> On Thu, Apr 03, 2014 at 01:51:06PM -0400, Mark Lord wrote:
>> On 14-04-03 01:16 PM, J. Bruce Fields wrote:
>>> The original behavior was in practice harmless and changing it broke
>>> something, so I think we should defini
On 14-04-03 01:16 PM, J. Bruce Fields wrote:
> On Thu, Apr 03, 2014 at 12:33:55PM -0400, Mark Lord wrote:
>> This commit from linux-3.14 breaks our NFS-root clients here:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6e14b46b91fee8a049b
Mark Lord wrote:
> On 14-04-03 12:33 PM, Mark Lord wrote:
>> This commit from linux-3.14 breaks our NFS-root clients here:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6e14b46b91fee8a049b0940333ce13a820beaaa5
>>
>>
>> -
On 14-04-03 12:33 PM, Mark Lord wrote:
> This commit from linux-3.14 breaks our NFS-root clients here:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6e14b46b91fee8a049b0940333ce13a820beaaa5
>
>
> - *p++ = htonl((u32) stat->mode);
> +
On 14-04-03 12:33 PM, Mark Lord wrote:
This commit from linux-3.14 breaks our NFS-root clients here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6e14b46b91fee8a049b0940333ce13a820beaaa5
- *p++ = htonl((u32) stat-mode);
+ *p++ = htonl((u32) (stat-mode
Mark Lord wrote:
On 14-04-03 12:33 PM, Mark Lord wrote:
This commit from linux-3.14 breaks our NFS-root clients here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6e14b46b91fee8a049b0940333ce13a820beaaa5
- *p++ = htonl((u32) stat-mode);
+ *p++ = htonl((u32
On 14-04-03 01:16 PM, J. Bruce Fields wrote:
On Thu, Apr 03, 2014 at 12:33:55PM -0400, Mark Lord wrote:
This commit from linux-3.14 breaks our NFS-root clients here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6e14b46b91fee8a049b0940333ce13a820beaaa5
- *p
On 14-04-03 04:15 PM, J. Bruce Fields wrote:
On Thu, Apr 03, 2014 at 01:51:06PM -0400, Mark Lord wrote:
On 14-04-03 01:16 PM, J. Bruce Fields wrote:
The original behavior was in practice harmless and changing it broke
something, so I think we should definitely just revert this patch.
Yup
On 14-04-03 03:30 PM, J. Bruce Fields wrote:
On Thu, Apr 03, 2014 at 01:51:06PM -0400, Mark Lord wrote:
On 14-04-03 01:16 PM, J. Bruce Fields wrote:
On Thu, Apr 03, 2014 at 12:33:55PM -0400, Mark Lord wrote:
This commit from linux-3.14 breaks our NFS-root clients here:
https://git.kernel.org
On 14-04-03 05:28 PM, J. Bruce Fields wrote:
On Thu, Apr 03, 2014 at 04:48:11PM -0400, Mark Lord wrote:
On 14-04-03 03:30 PM, J. Bruce Fields wrote:
On Thu, Apr 03, 2014 at 01:51:06PM -0400, Mark Lord wrote:
On 14-04-03 01:16 PM, J. Bruce Fields wrote:
On Thu, Apr 03, 2014 at 12:33:55PM -0400
New install: Haswell i7-4770 CPU, Q87 chipset.
When I enable intel_iommu=on at boot, it clutters the log with this WARN_ONCE():
...
[0.313282] Freeing initrd memory: 5092K (880037af7000 - 880037ff)
[0.313603] DMAR: No ATSR found
[0.313774] IOMMU 0 0xfed9: using Queued
New install: Haswell i7-4770 CPU, Q87 chipset.
When I enable intel_iommu=on at boot, it clutters the log with this WARN_ONCE():
...
[0.313282] Freeing initrd memory: 5092K (880037af7000 - 880037ff)
[0.313603] DMAR: No ATSR found
[0.313774] IOMMU 0 0xfed9: using Queued
rbitrarily long scatter-gather lists */
> - hcd->self.sg_tablesize = ~0;
> + hcd->self.sg_tablesize = 31;
>
> /* support to build packet from discontinuous buffers */
> hcd->self.no_sg_constraint = 1;
>
> Sadly it didn't fix t
-self.no_sg_constraint = 1;
Sadly it didn't fix the problem. Did I get the patch right?
That sounds almost as if the old version is still being loaded/run,
possibly from the initramfs image?
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line
CSI command.
Is there not a block layer / scheduler tunable for max sg entries or something?
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More ma
or something?
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
akey in the most recent 3.12.* kernels, as well as the 3.13-rc* ones.
So I have gone back to running older kernels and patching them.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
USB3 mass-storage issues with kernels since this patch.
Dunno if the patch itself is the problem, but just too much to do with USB3
is very flakey in the most recent 3.12.* kernels, as well as the 3.13-rc* ones.
So I have gone back to running older kernels and patching them.
Cheers
--
Mark Lord
Real
On 13-11-19 09:15 AM, Eric Dumazet wrote:
> On Tue, 2013-11-19 at 09:02 -0500, Mark Lord wrote:
>> On 13-11-19 05:04 AM, David Laight wrote:
>>>> From: Mark Lord
>> ..
>>>> except the ax88179_178a driver still does not work in linux-3.12,
>>&g
On 13-11-19 05:04 AM, David Laight wrote:
>> From: Mark Lord
..
>> except the ax88179_178a driver still does not work in linux-3.12,
>> whereas it works fine in all earlier kernels.
>>
>> That's a regression.
>> And a simple revert (earlier in this thread) fixes
On 13-11-19 05:04 AM, David Laight wrote:
From: Mark Lord
..
except the ax88179_178a driver still does not work in linux-3.12,
whereas it works fine in all earlier kernels.
That's a regression.
And a simple revert (earlier in this thread) fixes it.
So.. let's revert it for now, until
On 13-11-19 09:15 AM, Eric Dumazet wrote:
On Tue, 2013-11-19 at 09:02 -0500, Mark Lord wrote:
On 13-11-19 05:04 AM, David Laight wrote:
From: Mark Lord
..
except the ax88179_178a driver still does not work in linux-3.12,
whereas it works fine in all earlier kernels.
That's a regression
On 13-10-25 06:01 AM, Alexander Gordeev wrote:
>
> If this problem really exists anywhere besides pSeries?
>
> I can imagine x86 hitting lack of vectors in interrupt table when
> number of CPUs exceeds hundreds, but do we have this problem now?
An awful lot of x86 hardware has a 256 (255?)
On 13-10-25 06:01 AM, Alexander Gordeev wrote:
If this problem really exists anywhere besides pSeries?
I can imagine x86 hitting lack of vectors in interrupt table when
number of CPUs exceeds hundreds, but do we have this problem now?
An awful lot of x86 hardware has a 256 (255?) vector
On 13-10-24 10:31 AM, Alexander Gordeev wrote:
> On Thu, Oct 24, 2013 at 11:51:58AM +0100, Tejun Heo wrote:
>> I haven't looked into any details but, if the above works for most use
>> cases, it looks really good to me.
>
> Well, if we reuse Michael's statistics:
>
> - 58 drivers call
On 13-10-24 07:41 AM, Alexander Gordeev wrote:
> On Thu, Oct 24, 2013 at 11:57:40AM +0100, David Laight wrote:
>> The one case it doesn't work is where the driver either
>> wants the full number or the minimum number - but not
>> a value in between.
>>
>> Might be worth adding an extra parameter
On 13-10-24 07:41 AM, Alexander Gordeev wrote:
On Thu, Oct 24, 2013 at 11:57:40AM +0100, David Laight wrote:
The one case it doesn't work is where the driver either
wants the full number or the minimum number - but not
a value in between.
Might be worth adding an extra parameter so that this
On 13-10-24 10:31 AM, Alexander Gordeev wrote:
On Thu, Oct 24, 2013 at 11:51:58AM +0100, Tejun Heo wrote:
I haven't looked into any details but, if the above works for most use
cases, it looks really good to me.
Well, if we reuse Michael's statistics:
- 58 drivers call pci_enable_msix()
On 13-10-11 04:41 AM, Alexander Gordeev wrote:
> On Thu, Oct 10, 2013 at 07:17:18PM -0400, Mark Lord wrote:
>> Just to help us all understand "the loop" issue..
>>
>> Here's an example of driver code which uses the existing MSI-X interfaces,
>> for a device w
On 13-10-11 04:41 AM, Alexander Gordeev wrote:
On Thu, Oct 10, 2013 at 07:17:18PM -0400, Mark Lord wrote:
Just to help us all understand the loop issue..
Here's an example of driver code which uses the existing MSI-X interfaces,
for a device which can work with either 16, 8, 4, 2, or 1 MSI-X
Just to help us all understand "the loop" issue..
Here's an example of driver code which uses the existing MSI-X interfaces,
for a device which can work with either 16, 8, 4, 2, or 1 MSI-X interrupt.
This is from a new driver I'm working on right now:
static int xx_alloc_msix_irqs (struct
Just to help us all understand the loop issue..
Here's an example of driver code which uses the existing MSI-X interfaces,
for a device which can work with either 16, 8, 4, 2, or 1 MSI-X interrupt.
This is from a new driver I'm working on right now:
static int xx_alloc_msix_irqs (struct xx_dev
On 13-10-02 06:29 AM, Alexander Gordeev wrote:
..
> This update converts pci_enable_msix() and pci_enable_msi_block()
> interfaces to canonical kernel functions and makes them return a
> error code in case of failure or 0 in case of success.
Rather than silently break dozens of drivers in
On 13-10-02 06:29 AM, Alexander Gordeev wrote:
..
This update converts pci_enable_msix() and pci_enable_msi_block()
interfaces to canonical kernel functions and makes them return a
error code in case of failure or 0 in case of success.
Rather than silently break dozens of drivers in mysterious
On 13-09-26 09:03 AM, Alexander Gordeev wrote:
> On Thu, Sep 26, 2013 at 08:32:53AM -0400, Mark Lord wrote:
>> On 13-09-18 05:48 AM, Alexander Gordeev wrote:
>>> The last pattern makes most of sense to me and could be updated with a more
>>> clear sequenc
On 13-09-26 09:03 AM, Alexander Gordeev wrote:
On Thu, Sep 26, 2013 at 08:32:53AM -0400, Mark Lord wrote:
On 13-09-18 05:48 AM, Alexander Gordeev wrote:
The last pattern makes most of sense to me and could be updated with a more
clear sequence - a call to (bit modified) pci_msix_table_size
On 13-09-18 05:48 AM, Alexander Gordeev wrote:
>
> The last pattern makes most of sense to me and could be updated with a more
> clear sequence - a call to (bit modified) pci_msix_table_size() followed
> by a call to pci_enable_msix(). I think this pattern can effectively
> supersede the currently
On 13-09-18 05:48 AM, Alexander Gordeev wrote:
The last pattern makes most of sense to me and could be updated with a more
clear sequence - a call to (bit modified) pci_msix_table_size() followed
by a call to pci_enable_msix(). I think this pattern can effectively
supersede the currently
On 13-06-29 02:47 PM, Henrique de Moraes Holschuh wrote:
> You know, either the "long" or the "offline" SMART test routines do exactly
> that on any spinning rust device with a firmware that is not utterly broken.
>
> The HDD's firmware will rewrite, and even reallocate any "weak" sectors
> found
On 13-06-29 02:47 PM, Henrique de Moraes Holschuh wrote:
You know, either the long or the offline SMART test routines do exactly
that on any spinning rust device with a firmware that is not utterly broken.
The HDD's firmware will rewrite, and even reallocate any weak sectors
found by the
in PAGE_SIZE multiples.
And the SCSI stack in Linux has rather atrocious error handling.
It lumps multiple requests together, and can fail the entire lot even
if only a single sector is bad.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "
.
And the SCSI stack in Linux has rather atrocious error handling.
It lumps multiple requests together, and can fail the entire lot even
if only a single sector is bad.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line unsubscribe linux
On 13-06-23 05:51 PM, Pavel Machek wrote:
> On Sun 2013-06-23 17:27:52, Mark Lord wrote:
>
>> For all existing drives out there, that's a 512 byte unit.
>
> I guessed so. (It would be good to actually document it, as well as
> documenting exactly why it is dangerous. Is it
ok at the error
logs to see what sector the drive is choking on.
Or just low-level format it all with "hdparm --security-erase".
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
-level format it all with hdparm --security-erase.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
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.kernel.org/majordomo
On 13-06-23 05:51 PM, Pavel Machek wrote:
On Sun 2013-06-23 17:27:52, Mark Lord wrote:
For all existing drives out there, that's a 512 byte unit.
I guessed so. (It would be good to actually document it, as well as
documenting exactly why it is dangerous. Is it okay to send patches
On 13-01-17 08:53 AM, J. Bruce Fields wrote:
> On Thu, Jan 17, 2013 at 08:11:52AM -0500, Mark Lord wrote:
>> On 13-01-14 11:17 AM, Mark Lord wrote:
>>>
>>> Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
>>>
>>> /*
>>&
On 13-01-17 08:53 AM, J. Bruce Fields wrote:
On Thu, Jan 17, 2013 at 08:11:52AM -0500, Mark Lord wrote:
On 13-01-14 11:17 AM, Mark Lord wrote:
Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
/*
* Remove a dead transport
*/
static void svc_delete_xprt(struct svc_xprt
On 13-02-21 09:26 PM, Paul Gortmaker wrote:
> On Thu, Feb 21, 2013 at 9:37 AM, Mark Lord wrote:
>> On 13-02-20 10:05 PM, Linus Torvalds wrote:
>>> On Wed, Feb 20, 2013 at 2:09 PM, David Miller wrote:
..
>>> Nooo You killed the 3c501 and 3c503 drivers! Snif.
>
On 13-02-20 10:05 PM, Linus Torvalds wrote:
> On Wed, Feb 20, 2013 at 2:09 PM, David Miller wrote:
>>
>> 15) Orphan and delete a bunch of pre-historic networking drivers from
>> Paul Gortmaker.
>
> Nooo You killed the 3c501 and 3c503 drivers! Snif.
>
> I wonder if they still worked..
I
On 13-02-20 10:05 PM, Linus Torvalds wrote:
On Wed, Feb 20, 2013 at 2:09 PM, David Miller da...@davemloft.net wrote:
15) Orphan and delete a bunch of pre-historic networking drivers from
Paul Gortmaker.
Nooo You killed the 3c501 and 3c503 drivers! Snif.
I wonder if they still
On 13-02-21 09:26 PM, Paul Gortmaker wrote:
On Thu, Feb 21, 2013 at 9:37 AM, Mark Lord ker...@start.ca wrote:
On 13-02-20 10:05 PM, Linus Torvalds wrote:
On Wed, Feb 20, 2013 at 2:09 PM, David Miller da...@davemloft.net wrote:
..
Nooo You killed the 3c501 and 3c503 drivers! Snif.
I
On 13-02-12 03:52 PM, J. Bruce Fields wrote:
> On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote:
>> Got it again, this time on a different system
>> running mostly the same software.
>
> Mark, Paweł, Tom, could any of you confirm whether this helps?
..
No, I c
On 13-02-12 03:52 PM, J. Bruce Fields wrote:
On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote:
Got it again, this time on a different system
running mostly the same software.
Mark, Paweł, Tom, could any of you confirm whether this helps?
..
No, I cannot confirm one way or the other
Got it again, this time on a different system
running mostly the same software.
This time, I noticed when it happened: on mounting another system's storage
over NFS.
I was doing a "mount" command when suddenly this happened. Linux-3.7.3.
[ 3342.841487] [ cut here ]
[
Got it again, this time on a different system
running mostly the same software.
This time, I noticed when it happened: on mounting another system's storage
over NFS.
I was doing a mount command when suddenly this happened. Linux-3.7.3.
[ 3342.841487] [ cut here ]
[
On 13-01-18 12:37 AM, Stanislav Kinsbursky wrote:
>
> You have more than one NFS mount in different network namespaces, haven't you?
>
No, I don't (knowingly) use (multiple) namespaces at all.
Usually I disable them in the kernel .config,
though it appears the currently running kernel has this:
On 13-01-18 12:37 AM, Stanislav Kinsbursky wrote:
You have more than one NFS mount in different network namespaces, haven't you?
No, I don't (knowingly) use (multiple) namespaces at all.
Usually I disable them in the kernel .config,
though it appears the currently running kernel has this:
On 13-01-17 08:24 AM, Stanislav Kinsbursky wrote:
..
> This looks like the old issue I was trying to fix with "SUNRPC: protect
> service sockets lists during
> per-net shutdown".
> So, here is the problem as I see it: there is a transport, which is processed
> by service thread and
> it's
On 13-01-17 08:53 AM, J. Bruce Fields wrote:
> On Thu, Jan 17, 2013 at 08:11:52AM -0500, Mark Lord wrote:
>> On 13-01-14 11:17 AM, Mark Lord wrote:
>>>
>>> Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
>>>
>>> /*
>>&
On 13-01-14 11:17 AM, Mark Lord wrote:
>
> Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
>
> /*
> * Remove a dead transport
> */
> static void svc_delete_xprt(struct svc_xprt *xprt)
> {
> struct svc_serv *serv = xprt->xpt_server;
>
On 13-01-14 11:17 AM, Mark Lord wrote:
Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
/*
* Remove a dead transport
*/
static void svc_delete_xprt(struct svc_xprt *xprt)
{
struct svc_serv *serv = xprt-xpt_server;
struct svc_deferred_req *dr
On 13-01-17 08:53 AM, J. Bruce Fields wrote:
On Thu, Jan 17, 2013 at 08:11:52AM -0500, Mark Lord wrote:
On 13-01-14 11:17 AM, Mark Lord wrote:
Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
/*
* Remove a dead transport
*/
static void svc_delete_xprt(struct svc_xprt
On 13-01-17 08:24 AM, Stanislav Kinsbursky wrote:
..
This looks like the old issue I was trying to fix with SUNRPC: protect
service sockets lists during
per-net shutdown.
So, here is the problem as I see it: there is a transport, which is processed
by service thread and
it's processing is
On 13-01-16 05:51 PM, Mark Lord wrote:
> On 13-01-16 12:20 AM, Stanislav Kinsbursky wrote:
>>
>> Mark, could you provide any call traces?
>
> Call traces from where/what?
> There's this one, posted earlier in the BUG report:
>
> kernel BUG at net/sunrp
On 13-01-16 12:20 AM, Stanislav Kinsbursky wrote:
>
> Mark, could you provide any call traces?
Call traces from where/what?
There's this one, posted earlier in the BUG report:
kernel BUG at net/sunrpc/svc_xprt.c:921!
Call Trace:
[] ? svc_recv+0xcc/0x338 [sunrpc]
[] ?
On 13-01-16 12:20 AM, Stanislav Kinsbursky wrote:
Mark, could you provide any call traces?
Call traces from where/what?
There's this one, posted earlier in the BUG report:
kernel BUG at net/sunrpc/svc_xprt.c:921!
Call Trace:
[a016a56a] ? svc_recv+0xcc/0x338 [sunrpc]
On 13-01-16 05:51 PM, Mark Lord wrote:
On 13-01-16 12:20 AM, Stanislav Kinsbursky wrote:
Mark, could you provide any call traces?
Call traces from where/what?
There's this one, posted earlier in the BUG report:
kernel BUG at net/sunrpc/svc_xprt.c:921!
Call Trace:
[a016a56a
On 13-01-14 03:37 PM, J. Bruce Fields wrote:
> Thanks for the report.
>
> On Mon, Jan 14, 2013 at 11:17:09AM -0500, Mark Lord wrote:
>> Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server
>
> It's acting as an NFS client, right?
Client and server, with other Li
Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server
is getting these BUG complaints. The .config file is gzip'd/attached.
[ cut here ]
kernel BUG at net/sunrpc/svc_xprt.c:921!
invalid opcode: [#1] SMP
Modules linked in: nfsv4 xt_state xt_tcpudp xt_recent
Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server
is getting these BUG complaints. The .config file is gzip'd/attached.
[ cut here ]
kernel BUG at net/sunrpc/svc_xprt.c:921!
invalid opcode: [#1] SMP
Modules linked in: nfsv4 xt_state xt_tcpudp xt_recent
On 13-01-14 03:37 PM, J. Bruce Fields wrote:
Thanks for the report.
On Mon, Jan 14, 2013 at 11:17:09AM -0500, Mark Lord wrote:
Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server
It's acting as an NFS client, right?
Client and server, with other Linux boxes all running 3
On 12-10-29 07:03 PM, Greg Kroah-Hartman wrote:
> On Mon, Oct 29, 2012 at 07:00:54PM -0400, Mark Lord wrote:
>> There's something else very wrong when going from 3.4.9 to 3.4.16.
>> I've done it on two machines here, one the AMD-450 server (64-bit),
>> and the other my main
There's something else very wrong when going from 3.4.9 to 3.4.16.
I've done it on two machines here, one the AMD-450 server (64-bit),
and the other my main notebook (Core2duo 32-bit-PAE).
Both systems feel much more sluggish than usual with 3.4.16 running.
Reverted them both back to earlier
On 12-10-29 10:22 AM, Mark Lord wrote:
> On 12-10-29 02:46 AM, Willy Tarreau wrote:
>> On Mon, Oct 29, 2012 at 12:03:55AM -0400, Mark Lord wrote:
>>> My server here runs the 3.4.xx series of "stable" kernels.
>>> Until today, it was running 3.4.9.
>
On 12-10-29 02:46 AM, Willy Tarreau wrote:
> On Mon, Oct 29, 2012 at 12:03:55AM -0400, Mark Lord wrote:
>> My server here runs the 3.4.xx series of "stable" kernels.
>> Until today, it was running 3.4.9.
>> Today I tried to upgrade it to 3.4.16.
>> It
There's something else very wrong when going from 3.4.9 to 3.4.16.
I've done it on two machines here, one the AMD-450 server (64-bit),
and the other my main notebook (Core2duo 32-bit-PAE).
Both systems feel much more sluggish than usual with 3.4.16 running.
Reverted them both back to earlier
On 12-10-29 07:03 PM, Greg Kroah-Hartman wrote:
On Mon, Oct 29, 2012 at 07:00:54PM -0400, Mark Lord wrote:
There's something else very wrong when going from 3.4.9 to 3.4.16.
I've done it on two machines here, one the AMD-450 server (64-bit),
and the other my main notebook (Core2duo 32-bit-PAE
On 12-10-29 02:46 AM, Willy Tarreau wrote:
On Mon, Oct 29, 2012 at 12:03:55AM -0400, Mark Lord wrote:
My server here runs the 3.4.xx series of stable kernels.
Until today, it was running 3.4.9.
Today I tried to upgrade it to 3.4.16.
It hangs in setup.c.
I've isolated the fault down
On 12-10-29 10:22 AM, Mark Lord wrote:
On 12-10-29 02:46 AM, Willy Tarreau wrote:
On Mon, Oct 29, 2012 at 12:03:55AM -0400, Mark Lord wrote:
My server here runs the 3.4.xx series of stable kernels.
Until today, it was running 3.4.9.
Today I tried to upgrade it to 3.4.16.
It hangs in setup.c
My server here runs the 3.4.xx series of "stable" kernels.
Until today, it was running 3.4.9.
Today I tried to upgrade it to 3.4.16.
It hangs in setup.c.
I've isolated the fault down to this specific change
that was made between 3.4.9 and 3.4.16.
Reverting this change allows the system to
My server here runs the 3.4.xx series of stable kernels.
Until today, it was running 3.4.9.
Today I tried to upgrade it to 3.4.16.
It hangs in setup.c.
I've isolated the fault down to this specific change
that was made between 3.4.9 and 3.4.16.
Reverting this change allows the system to boot/run
On 12-08-26 10:15 AM, wbrana wrote:
> On 8/26/12, Mark Lord wrote:
>> Here are a couple of real scenarios you don't seem to have thought about.
>> A 32-bit kernel on a legacy (or even new) system in 2017 will still need
>> regular kernel updates (not "long term" un0
On 12-08-26 10:15 AM, wbrana wrote:
On 8/26/12, Mark Lord ker...@teksavvy.com wrote:
Here are a couple of real scenarios you don't seem to have thought about.
A 32-bit kernel on a legacy (or even new) system in 2017 will still need
regular kernel updates (not long term un0maintained kernels
On 12-08-24 12:45 PM, wbrana wrote:
> On 8/24/12, Alan Cox wrote:
>> That doesn't work for a variety of reasons x86 hardware is still
>> changing, devices are still changing. So please exit cloud cuckoo land
>> and go do something useful.
> Hardware will be discontinued if no software will
On 12-08-24 12:45 PM, wbrana wrote:
On 8/24/12, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
That doesn't work for a variety of reasons x86 hardware is still
changing, devices are still changing. So please exit cloud cuckoo land
and go do something useful.
Hardware will be discontinued if no
saeed wrote:
On Mon, 25 Feb 2008, Jeff Garzik wrote:
...
Saeed: isn't this what your SOC patches already implemented for us?
As near as I can tell, sata_mv now already has support for the 60x1C0.
Saeed's stuff didn't support PCI though, and Jon Li is definitely talking
about PCI...
yes, my
Pavel Machek wrote:
Hi!
This is a patch (very ugly, assumes you have just one disk) to bring
powersaving to AHCI. You need Alan's SCSI autosuspend (attached) patch
as a base.
It saves .5W compared to config with disk spinning, and even .15W
compared to hdparm -y... on my thinkpad x60 anyway.
Pavel Machek wrote:
Hi!
This is a patch (very ugly, assumes you have just one disk) to bring
powersaving to AHCI. You need Alan's SCSI autosuspend (attached) patch
as a base.
It saves .5W compared to config with disk spinning, and even .15W
compared to hdparm -y... on my thinkpad x60 anyway.
saeed wrote:
On Mon, 25 Feb 2008, Jeff Garzik wrote:
...
Saeed: isn't this what your SOC patches already implemented for us?
As near as I can tell, sata_mv now already has support for the 60x1C0.
Saeed's stuff didn't support PCI though, and Jon Li is definitely talking
about PCI...
yes, my
Jeff Garzik wrote:
Jon Li wrote:
Hello,
I am curious as to whether there are plans to add support for integrated
sata devices. I personally want to add support for a 60x1C0 based
device (pci:id = 0x5182). I think adding support should be relatively
simple, except for a few issues outlined
Pavel Machek wrote:
Hi!
This is a patch (very ugly, assumes you have just one disk) to bring
powersaving to AHCI. You need Alan's SCSI autosuspend (attached) patch
as a base.
It saves .5W compared to config with disk spinning, and even .15W
compared to hdparm -y... on my thinkpad x60 anyway.
Pavel Machek wrote:
Hi!
This is a patch (very ugly, assumes you have just one disk) to bring
powersaving to AHCI. You need Alan's SCSI autosuspend (attached) patch
as a base.
It saves .5W compared to config with disk spinning, and even .15W
compared to hdparm -y... on my thinkpad x60 anyway.
Jeff Garzik wrote:
Jon Li wrote:
Hello,
I am curious as to whether there are plans to add support for integrated
sata devices. I personally want to add support for a 60x1C0 based
device (pci:id = 0x5182). I think adding support should be relatively
simple, except for a few issues outlined
Bartlomiej Zolnierkiewicz wrote:
- ide-dma.c is not a separate module
- ide-dma.c is not PCI specific anymore
- DMA is enabled by default nowadays
- link for Intel Zappa BIOS is dead
etc.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-dma.c | 48
Matthew Wilcox wrote:
I've ported the scsi_ram driver [1] to libata. It could use a lot more
work -- there's a lot of stuff in the identify page that I haven't
filled in, and there's a lot of commands it doesn't even try to execute.
For example, when you unload the driver, you get the mildly
101 - 200 of 1516 matches
Mail list logo
