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-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-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 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"
Arjan van de Ven wrote:
On Mon, 04 Feb 2008 12:29:03 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
re: http://bugzilla.kernel.org/show_bug.cgi?id=9489
This just happened here again. Or at least I finally noticed that
the fan on my notebook seemed to be running hard for much longer
than
Gene Heskett wrote:
On Sunday 03 February 2008, Ingo Molnar wrote:
* Gene Heskett <[EMAIL PROTECTED]> wrote:
I believe its the same, but lemme paste it for sure, yes:
[ 26.339926] ENABLING IO-APIC IRQs
[ 26.340119] ..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1
[ 26.350129] ..MP-BIO
re: http://bugzilla.kernel.org/show_bug.cgi?id=9489
This just happened here again. Or at least I finally noticed that
the fan on my notebook seemed to be running hard for much longer
than usual. :)
Powertop showed 2.6.24-final running with 1-36000 wakeups/sec,
with *nothing* significant r
Andi Kleen wrote:
..
You should probably use simple_strtoul() instead of inventing an
own hex parser in kgdb.c. And sprintf instead of an own hex writer.
In general more use sprintf would probably shorten a lot of the parser
code.
..
Speaking of which.. the kernel implementation of snprintf() s
Andrew Morton wrote:
On Mon, 11 Feb 2008 17:57:54 +0200 Alon Bar-Lev <[EMAIL PROTECTED]> wrote:
On Tuesday 06 November 2007, Alon Bar-Lev wrote:
On 11/6/07, Dave Young <[EMAIL PROTECTED]> wrote:
Hi,
sorry for reply again, this seems a diffrent issue ...
All that I do is running pppd over the
Tejun Heo wrote:
..
* For timeouts, result TF isn't available and thus res printout is
misleading. res shouldn't be printed after timeouts. This would
require allocating yest another temp buf and separating out res printing
into separate snprintf.
..
And snprintf() is buggy, by the way. It d
Hugo Mills wrote:
I'm getting these on my Dell Latitude D830:
Feb 15 13:06:00 willow kernel: ata1.00: exception Emask 0x2 SAct 0x4 SErr 0x0
action 0x2 frozen
Feb 15 13:06:00 willow kernel: ata1.00: spurious completions during NCQ
issue=0x0 SAct=0x4 FIS=004040a1:0002
Feb 15 13:06:00 will
Tejun Heo wrote:
Andrew Morton wrote:
So, I guess it's NACK w/o suggested alternatives, right?
I wouldn't nack without good reasons, and I have none here. I don't have
very strong opinions either way.
I was just wondering whether I should just go with snprintf dancing in
eh_link_report, whic
WRITE_UNC_EXT command.
Cheers
Mark Lord
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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-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 hang
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.
>>>
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 kerne
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 othe
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-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 mysterio
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-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
look 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&quo
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.
to do I/O 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 l
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 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 support
Andreas Schwab wrote:
Jeff Garzik <[EMAIL PROTECTED]> writes:
Andreas Schwab wrote:
Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
following error from wodim:
Errno: 0 (Success), write_g1 scsi se
Hans J. Koch wrote:
Am Sun, 17 Feb 2008 07:29:27 -0800
schrieb Arjan van de Ven <[EMAIL PROTECTED]>:
On Sun, 17 Feb 2008 13:37:53 +0100
"Hans J. Koch" <[EMAIL PROTECTED]> wrote:
Of course there's no driver for the wlan, but that's a different
story ;)
I replaced that unsupported Atheros 5007
Mark Lord wrote:
Hans J. Koch wrote:
..
Really? Unbelievable what these guys do to make my live harder...
So, they might use some undocumented GPIO to turn the power on, and
...
GPIO lines are not usually very difficult to trace,
and programming them is pretty easy, too ...
If I had an
devices were unaffected, but drivers/ide devices could
misbehave or even be corrupted by some operations.
hdparm-8.2 is available at http://sourceforge.net/projects/hdparm/
Upgrading from any earlier 7.x or 8.x version
is strongly recommended for all users.
Cheers
--
Mark Lord
Real-Time Remedies
Mark Lord wrote:
Theodore Tso wrote:
..
The following ld_preload can help in some cases. Mutt has this hack
encoded in for maildir directories, which helps.
..
Oddly enough, that same spd_readdir() preload craps out here too
when used with "rm -r" on largish directories.
I added
Theodore Tso wrote:
..
The following ld_preload can help in some cases. Mutt has this hack
encoded in for maildir directories, which helps.
..
Oddly enough, that same spd_readdir() preload craps out here too
when used with "rm -r" on largish directories.
I added a bit more debugging to it, an
Paulo Marques wrote:
Mark Lord wrote:
Theodore Tso wrote:
..
The following ld_preload can help in some cases. Mutt has this hack
encoded in for maildir directories, which helps.
..
Oddly enough, that same spd_readdir() preload craps out here too
when used with "rm -r" on largish d
don't see it
in there, then the kernel would have to get rebuilt with
that config option to enable the feature.
Or just switch to the modern libata drivers for IDE/SATA drives.
Note also that hdparm has now been updated to version 8.4,
with some unrelated bug fixes.
Cheers
--
Mark Lord
Rea
Jeff Chua wrote:
On Feb 20, 2008 2:19 PM, Jeff Chua
I'll try the "idle=poll" to see if that works and will try some printk
I don't know what exactly the i915_suspend() and i915_resume() are
supposed to do because it works better without them.
After inserting "return 0;" right at the top o
base.
this patch change use last_port directly, and move pp assignment later.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
..
Yup, obvious bug fixes, thanks.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
Index: lin
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 ]
[ 33
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 cann
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 x
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 oth
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]
[] ? nfs_callback_authenticate+
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/
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;
&g
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: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 process
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:
C
Rafael J. Wysocki wrote:
No. Again, if there are devices that wake us up from S4, but not from S5,
they need to be handled differently in the *enter S4* case (hibernation) and
in the *enter S5* case (powering off the system).
..
Something I've never understood, is why we would ever want to bo
[EMAIL PROTECTED] wrote:
..
I've been watching for kexec hibernate for a little while now, and the
last I saw was that acpi was incompatible with the kexec hibernate (but
the suspend folks were still claiming that devices needed to be put in
the 'right mode' not just powered off. I've been wait
Rafael J. Wysocki wrote:
On Friday, 22 of February 2008, Mark Lord wrote:
[EMAIL PROTECTED] wrote:
..
I've been watching for kexec hibernate for a little while now, and the
last I saw was that acpi was incompatible with the kexec hibernate (but
the suspend folks were still claiming
Anders Eriksson wrote:
[EMAIL PROTECTED] said:
The sysrq-e output is probably just standard ext3 journalling unrelated to
the problem... what does dmesg say? lspci? What's your hardware setup?
dmesg ; smartd ; dmesg yields no new entries in dmesg. It seems on disk
accesses are dead. it
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 di
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 -
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 bel
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
the fall-back,
which queries the BIOS (from kernel startup code) for translation
info on ALL drives.
--
Mark Lord
Real-Time Remedies Inc.
[EMAIL PROTECTED]
Rupa Schomaker wrote:
>
> Andre Hedrick <[EMAIL PROTECTED]> writes:
>
> > > But there is no indication of what the pr
hdparm-6.0 is currently winding through release channels,
and includes support for freezing/managing the security status.
Cheers
-
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/maj
Ahh.. that might explain some weirdness observed here, as well.
Thanks!
Dmitry Torokhov wrote:
Please try the following patch:
http://www.ucw.cz/~vojtech/input/alps-suspend-typo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
Note:
hdparm can also use O_DIRECT for the -t timing test.
Eg. hdparm --direct -t /dev/hda
-
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/majordomo-info.html
Please read the F
Linus Torvalds wrote:
Btw, things like this:
+#define IDEFLOPPY_TICKS_DELAY HZ/20 /* default delay for ZIP 100
(50ms) */
are just bugs waiting to happen.
Needs parenthesis: ((HZ)/20)
Or one could just use the msecs_to_jiffies() macro.
Cheers
-
To unsubscribe from this list: sen
Jeff Garzik wrote:
-#ifndef ATA_ENABLE_ATAPI
- if (unlikely(dev->class == ATA_DEV_ATAPI))
- return NULL;
-#endif
+ if (atapi_enabled) {
+ if (unlikely(dev->class == ATA_DEV_ATAPI))
+ return NULL;
+ }
..
Is that if-stmt the rig
have here, and see (1) if it runs as-is,
and (2) what the disassembly shows.
I'd certainly like to get source for my 730AP here,
as it seems to be a bit buggy on the WEP implementation.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
[EMAIL PROTECTED]
-
To unsubscribe from this list: sen
>Each of the first three large parts starts with this sequence of bytes
Actually, the byte structure of the first 0x100 bytes
of each section seems to be very similar.
Some kind of header.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAI
DervishD wrote:
..
the new implementation seems to rewrite the fat on every single write
(that's the reason of the slowdown, probably), and since I'm not sure
about the quality of the flash memory present in the device, it is
very probable that it would wear the first sectors :( So I have to
moun
Oh, you *should* be able to get the results you
are looking for (hdparm -I) by trying it this way:
hdparm --Istdin http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Oliver Tennert wrote:
"hdparm -I /dev/dvdrecorder" leads to the output:
/dev/dvdrecorder:
HDIO_DRIVE_CMD(identify) failed: Input/output error
The kernel tells me:
[4296893.262000] hdd: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
[4296893.262000] hdd: drive_cmd: error=0x04 { Abor
Alan Cox wrote:
On Llu, 2005-09-05 at 12:24 -0400, Mark Lord wrote:
I'm not sure why the "failed: Input/output error" (-EIO) result is
being returned from the ATA layer in this case. Driver bug, most likely.
Because the command failed an error was reported back instead of
Daniel Phillips wrote:
There are only two stacks involved, the normal kernel stack and your new ndis
stack. You save ESP of the kernel stack at the base of the ndis stack. When
the Windows code calls your api, you get the ndis ESP, load the kernel ESP
from the base of the ndis stack, push the
Is someone actively working on USB Suspend/Resume support yet?
I ask because this is becoming more and more important as people
shift more to portable notebook computers with Linux.
Enabling CONFIG_USB_SUSPEND is currently a surefire way to
guarantee crashing my own notebook on suspend/resume,
w
Robert Hancock wrote:
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 le
Mark Lord wrote:
Robert Hancock wrote:
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 ve
Venki Pallipadi wrote:
Reintroduce run time configurable max_cstate for !CPU_IDLE case.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.24-rc/drivers/acpi/processor_idle.c
===
--- linux-2.6.24-rc.orig/driver
Mark Lord wrote:
Venki Pallipadi wrote:
Reintroduce run time configurable max_cstate for !CPU_IDLE case.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.24-rc/drivers/acpi/processor_idle.c
===
---
Pallipadi, Venkatesh wrote:
-Original Message-
From: Mark Lord [mailto:[EMAIL PROTECTED]
..
Okay, with !CONFIG_CPU_IDLE, this works fine -- same as 2.6.23
and earlier.
Good to know. Atleast we do not have a regression for 2.6.24 now.
..
Agreed. We're happy here, fo
2.6.24
Submitter : Mark Lord <[EMAIL PROTECTED]>
Date: 2007-12-02 04:23
References : http://lkml.org/lkml/2007/12/1/141
http://bugzilla.kernel.org/show_bug.cgi?id=9489
Handled-By : Arjan van de Ven <[EMAIL PROTECTED]>
..
I have only seen t
Venki Pallipadi wrote:
Reintroduce run time configurable max_cstate for !CPU_IDLE case.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.24-rc/drivers/acpi/processor_idle.c
===
--- linux-2.6.24-rc.orig/driver
Linus Torvalds wrote:
..
Both git trees and tar-balls/patches pushed out, should be mirroring out
within minutes. So there are no excuses to not try it out, and see if your
favorite regression has been fixed.
..
We're still missing the sata_qstor regression fix from Tejun,
and the patch from V
Andrew Morton wrote:
..
umm, OK, I queued it for 2.6.24. I'll give people a day or so to comment
on this.
I had to invent some silly changlelog for it. Please review it for
accuracy and completeness?
..
From: Venki Pallipadi <[EMAIL PROTECTED]>
This was writeable in 2.6.23 but the cpuidle m
Arjan van de Ven wrote:
..
if we take a step back; Mark afaics only wants to put 1 in there...
And that makes sense; either you want the "no latency" C1, or you want the lot
(esp given that C2 and deeper are at the whim of the bios, what they mean varies
over time. Actually even C1 does that on s
Len Brown wrote:
1. Why does VMware need max_cstate=1 to load quickly?
..
Eh? Nothing to do with "loading" anything,
but rather it's simple responsiveness to guest keyboard
input that we're experiencing trouble with.
The guest OS is probably "broken" in that regard,
but setting max_cstate=1 ma
Tejun Heo wrote:
[cc'ing linux-ide]
Jonathan Woithe wrote:
Hi guys
I was wondering whether anyone can shed any light on the status of SATA tape
drives. There's very little info on the net about this at least in the
places I've checked; the only thing of any significance I've found thus far
is
Francois Romieu wrote:
Holger Hoffstaette <[EMAIL PROTECTED]> :
[...]
Maybe turning off sendfile or NAPI just lead to random success - so far it
really looks like tso on the r8169 is the common cause.
TSO on the r8169 is the magic switch but the regression makes imvho more
sense from a VM pov:
Zhu Yi wrote:
On Thu, 2007-12-06 at 12:39 +0300, Cyrill Gorcunov wrote:
From: Cyrill Gorcunov <[EMAIL PROTECTED]>
Subject: [PATCH] iwlwifi3945/4965 - fix rate control algo reference leak
..
Any chance of getting LEDs support re-added to this driver,
perhaps in the 2.6.25 timeframe?
With that
Ingo Molnar wrote:
...
thanks. I do get the impression that most of this can/should wait until
2.6.25. The patches look quite dangerous.
..
I confess to not really trying hard to understand everything in this thread,
but the implication seems to be that this bug might affect udelay()
and possi
trash can wrote:
..
Robert Hancock wrote:
That is rather curious. There's no sign of any libata error handling
going on.. Maybe the drive is actually returning that error code in the
ATAPI CDB, or at least we think it is?
You are sure that this drive still works with older kernels using
drivers
Mark Lord wrote:
I missed the early part of this thread,
but here is a data point that may or may not be useful.
I have an ASUS mobo here with an onboard JM363 SATA/PATA controller
(verified by looking at the actual chip).
It works fine when in AHCI mode with a PATA ATAPI ZIP100 drive
all by
Improve the existing boot/load time warnings from sata_mv
for Highpoint RocketRAID 23xx cards, based on new knowledge
about where the BIOS likes to overwrite sectors with metadata.
Harmless to us, but very useful for end users.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
This
trash can wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks for the note. Zip drive as only device on the bus did not work
for me. kernel is correctly identifying the Jmicron chip.
..
So have you tried 2.6.24-rc* on that system yet, using only libata ?
Mark Lord wrote:
Mark Lord
like I got the system to
probe and re-add the first drive by doing a "mount -a", but haven't
been able (no idea how) to re-add the second.
hotplug made great strides with the introduction of the new-EH code, but
it still needs a bit of work. Mark Lord was looking into that, s
Anas Nashif wrote:
Actually no TCP/IP is needed here. Basically the MEI driver writes and reads the
messages to/from the firmware. When communicating in-band using LMS, TCP/IP
terminates at LMS and the messages are copied using MEI driver.
To have a feel for all of this, with many examples, sa
Jens,
I'm experimenting here with trying to generate large I/O through libata,
and not having much luck.
The limit seems to be the number of hardware PRD (SG) entries permitted
by the driver (libata:ata_piix), which is 128 by default.
The problem is, the block layer *never* sends an SG entry la
(resending with corrected email address for Jens)
Jens,
I'm experimenting here with trying to generate large I/O through libata,
and not having much luck.
The limit seems to be the number of hardware PRD (SG) entries permitted
by the driver (libata:ata_piix), which is 128 by default.
The probl
Mark Lord wrote:
(resending with corrected email address for Jens)
Jens,
I'm experimenting here with trying to generate large I/O through libata,
and not having much luck.
The limit seems to be the number of hardware PRD (SG) entries permitted
by the driver (libata:ata_piix), which is 1
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB for
libata,
but 2.6.24 uses only 4KB segments and a *few* 8KB segments.
Just a suspicion ... could this be slab vs slub? ie check your
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB for
libata,
but 2.6.24 uses only 4KB segments and a *few* 8KB segments.
Just a
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to
64KB for libata,
but 2.6.24 uses only 4KB segments and a *few* 8KB
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to
64KB for libata
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB for
libata,
but 2.6.24 uses only 4KB segments and a *few* 8KB segments.
Just a
1 - 100 of 763 matches
Mail list logo
