Jeff Garzik wrote:
On Fri, Nov 09, 2007 at 09:02:35AM +0700, Riki Oktarianto wrote:
Some BIOSen map AHCI ABAR but lock the SATA controller to IDE mode.
This patch add quirk to set AHCI mode on ICH board with such case.
Tested on Macbook2,1 (ICH7M)
Intel will complain but it's awful tempting..
Jeff Garzik wrote:
On Thu, Nov 08, 2007 at 10:29:37PM -0500, Mark Lord wrote:
And I might even privately patch my own kernels to map the ACHI BAR
in the cases where the BIOS didn't...
The inability to do this in the general case is the main reason why
AHCI was not unconditionally en
What happened to ATA Passthru command support for ATAPI?
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkm
Rene Herman wrote:
Tejun Heo wrote:
Everything seems fine in the dmesg. Performance degradation is
probably some other issue in -rc kernel. I'm suspecting recently
fixed block layer bug. If it's still the same in the next -rc,
please report.
In fact, it's CFQ. The PATA thing was a red herr
Jens Axboe wrote:
But surely one of (not sure which) sync+async or async+sync may also be
okay?
Or would it?
Async merge to sync request should be ok. But I wonder what happens with
hdparm, since it seems to trigger one of these tests. Very puzzling.
I'll dive in and take a look.
The code
ave others from trying -- no, doesn't fix any)
As expected. The issue is rq_is_sync(rq) takes the data direction into
account as well, while bio_sync() only checks the sync bit. This should
fix it.
And here a little more relaxed version, as Mark Lord suggested. We allow
merge of async bio into a s
Jens Axboe wrote:
I did have to massage the second patch to get it to apply cleanly
after the first patch. You may want to regenerate it against -rc3.
Hmm odd, I thought I did. Will double check.
Ahh.. I get it now.
I tried to apply the second patch *on top* of the first patch,
whereas it
Tejun Heo wrote:
OT but care to make -i and -I work equivalently? Such that -i reports
more detailed info and user can dump stored id block.
hdparm -I works just fine now.
hdparm -i requires the HDIO_GET_IDENTITY ioctl() from drivers/ide,
to retrieve the "boot time" copy of the identify bloc
Tejun Heo wrote:
Mark Lord wrote:
Support for IDENTIFY PACKET DEVICE would be nice too.
It already does that, using HDIO_DRIVE_CMD to retrieve it
in the same way as for regular IDENTIFY DEVICE commands.
Hmmm... My hdparm doesn't seem to do that.
Sure it does.
Try "strace hdpa
o the kernel panic.
Could somebody fix this please?
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/
Jens Axboe wrote:
Robert Hancock wrote:
..
+/* The following blacklist entries are taken from the Windows
+ driver .inf files for the Silicon Image 3124 and 3132. */
+{ "Maxtor 7B250S0","BANC1B70",ATA_HORKAGE_NONCQ, },
+{ "HTS541060G9SA00","MB3OC60D",ATA_HORKAG
Patrick Ale wrote:
Hi guys,
Me again, sorry.
Is it possible to make hdparm work with libata?
It already works fine with libata.
..
Anyway, I used to be able to force the drive back with using hdparm
-X68 -d 1 /dev/sdk
Userspace PIO mode changes are NOT a good idea,
and I doubt that libata
Robert Hancock wrote:
..
Only some of the hdparm functionality is supported in libata,
That's not true. MOST hdparm functionality is supported in libata.
Only a very few things are not supported, including -d and -X,
for reasons already pointed out.
Nearly everything else works.
-ml
-
To uns
Oleg Verych wrote:
scripts: replace gawk, head, bc with shell, update
Replacing overhead of using some (external) programs
instead of good old `sh'.
...
-t4=`echo $t3 | gawk '{ print $1 }'`
-t5=`echo $t1 | gawk '{ print $1 }'`
-t6=`echo $t4 - $t5 | tr a-f A-F`
-t7=`( echo
I'm with Linus 100% here.
It's really irritating to upgrade to a newer kernel,
using the same old .config file, and then discover that
my MythTV box no longer auto-boots to record programs.
The reason being, that /proc/acpi/alarm no longer exists,
and the kernel option to configure it has myster
Oleg Verych wrote:
..
Without jokes, it even commented:
+# awk style field access
+field() {
+ shift $1 ; echo $1
+}
+
Ack.
-
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/ma
re: hdparm -d
Support for that ioctl could likely be added, but these days I don't
think there's much use for it. I can't see how anybody in their right
mind would want to disable DMA on a modern drive, and if libata turns
it off automatically then there's likely some serious hardware or
driv
Nigel Cunningham wrote:
On Sun, 2007-02-11 at 01:27 +0100, Rafael J. Wysocki wrote:
Plus:
- What if I'm planning to implement the power managemet, but not just right
now?
Why not right now?
LKML is much more receptive to drivers that follow
the "release early, release often" mantra.
Which m
Robert Hancock wrote:
Having a single drive on the channel configured as slave is not really a
legal configuration.
Sure it is. Not ideal, but "legal" in every respect,
and suprisingly common "in the wild" since the early 1990s.
(I believe the ATA standards say that it's
something that a h
Tejun Heo wrote:
[EMAIL PROTECTED] wrote:
..
ata1: command timeout
Feb 19 20:39:31 linux kernel: ata1: no sense translation for status: 0x40
Feb 19 20:39:31 linux kernel: ata1: translated ATA stat/err 0x40/00 to SCSI
SK/ASC/ASCQ 0xb/00/00
Feb 19
(Yeah, mmap() has taught some people about MAP_FAIL, but that's pretty
unusual too.
It's so unusual, that I regularly find buggy code checking for NULL
instead of MAP_FAILED. Just about every program I look at has it wrong
in at least one place.
Ditto for the result value from wait() -- lots o
It's not as if people should be pulling 'raw' IRQ numbers out
of a hat or even module parameters these days, except for ISA drivers..
Err.. in the embedded space, this is exceptionally common today,
on the most modern of chips, too. Lots of magic hard(ware)-coded IRQ numbers.
Cheers
-
To unsub
You guys need to backup in this thread.
Every example of O_DIRECT here could be replaced with
calls to mmap(), msync(), and madvise() (or posix_fadvise).
In addition to being at least as fast as O_DIRECT,
these have the added benefit of using the page cache
(avoiding reads for data already pres
Adrian Bunk wrote:
On Tue, Jan 30, 2007 at 09:13:00AM +1100, Bron Gondwana wrote:
We do a lot of Cyrus which does a lot of MMAP - and we also use the
Areca driver - which are both strong reasons to move to 2.6.19.2, but
if the MMAP fix was ported back to 2.6.16 we might consider staying
there i
Robert Hancock wrote:
Jeff Garzik wrote:
* Include the patch inline rather than as an attachment.
..
I'd love to, but unfortunately nobody seems to have come up with a way
of doing this in Thunderbird that keeps it from mangling whitespace
Yup, major nuisance. I have to fire up Kmail wh
an adjacent directly lookup also
failed.
This patch fixes the behaviour to be similar to what we had originally.
When a bad sector is encounted, SCSI will now work around it again,
failing *only* the bad sector itself.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
diff -u --recursive
sector
is no reason to pretend that (for example) an adjacent directly lookup also
failed.
This patch fixes the behaviour to be similar to what we had originally.
When a bad sector is encounted, SCSI will now work around it again,
failing *only* the bad sector itself.
Signed-off-by: Mark Lo
James Bottomley wrote:
First off, please send SCSI patches to the SCSI list:
Fixed already, thanks!
This patch fixes the behaviour to be similar to what we had originally.
When a bad sector is encounted, SCSI will now work around it again,
failing *only* the bad sector itself.
Erm, but th
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries. With existing ATA error recovery in the drives,
that's about 3 seconds per retry on average, or 12 seconds per failure.
Multiply that by the number of blocks past the error to comple
Randy Dunlap wrote:
On Wed, 31 Jan 2007 18:00:15 -0500 Theodore Tso wrote:
..
More specifically, Dave said that it "seemed rude" to just take the
driver and send updates, but maybe the best way of dealing with
out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
kind of spec r
Tejun Heo wrote:
A much better solution with thunderbird is using external editor
extension.
http://globs.org/articles.php?lng=en&pg=2
Brilliant! Installed, and now tested (the max_cmd_len patch posting).
-ml
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
Ric Wheeler wrote:
Mark Lord wrote:
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries.
(note: libata does *not* generate retries for medium errors;
the looping is driven by the SCSI mid-layer code).
It really beats the altern
James Bottomley wrote:
For the MD case, this is what REQ_FAILFAST is for.
I cannot find where SCSI honours that flag. James?
And for that matter, even when I patch SCSI so that it *does* honour it,
I don't actually see the flag making it into the SCSI layer from above.
And I don't see where
Mark Lord wrote:
James Bottomley wrote:
For the MD case, this is what REQ_FAILFAST is for.
I cannot find where SCSI honours that flag. James?
Scratch that thought.. SCSI honours it in scsi_end_request().
But I'm not certain that the block layer handles it correctly,
at least not i
Douglas Gilbert wrote:
Ric,
Both ATA (ATA8-ACS) and SCSI (SBC-3) have recently added
command support to flag a block as "uncorrectable". There
is no need to send bad "long" data to it and suppress the
disk's automatic re-allocation logic.
That'll be useful in a couple of years, once drives tha
Alan wrote:
When libata reports a MEDIUM_ERROR to us, we *know* it's non-recoverable,
as the drive itself has already done internal retries (libata uses the
"with retry" ATA opcodes for this).
This depends on the firmware. Some of the "raid firmware" drives don't
appear to do retries in firmwar
James Bottomley wrote:
On Wed, 2007-01-31 at 12:57 -0500, Mark Lord wrote:
Alan wrote:
When libata reports a MEDIUM_ERROR to us, we *know* it's non-recoverable,
as the drive itself has already done internal retries (libata uses the
"with retry" ATA opcodes for this).
This
Ingo Molnar wrote:
also, we context-switch kernel threads in 350 nsecs on current hardware
and the -rt kernel is certainly happy with that and runs all hardirqs
Ingo, how relevant is that "350 nsecs on current hardware" claim?
I don't mean that in a bad way, but my own experience suggests t
James Bottomley wrote:
On Tue, 2007-01-30 at 19:47 -0500, Mark Lord wrote:
Kernels since about 2.6.16 or so have been broken in this regard.
They "complete" the good sectors before the error,
and then fail the entire remaining portions of the request.
What was the commit that intr
James Bottomley wrote:
On Thu, 2007-02-01 at 15:02 -0500, Mark Lord wrote:
..
One thing that could be even better than the patch below,
would be to have it perhaps skip the entire bio that includes
the failed sector, rather than only the bad sector itself.
Er ... define "skip over th
Alan wrote:
If this is the right strategy for disk recovery for a given type of
device then this ought to be an automatic strategy. Most end users will
not have the knowledge to frob about in sysfs, and if the bad sector hits
at the wrong moment a sensible automatic recovery strategy is going to
Matt Mackall wrote:
..
Also worth considering is that spending minutes trying to reread
damaged sectors is likely to accelerate your death spiral. More data
may be recoverable if you give up quickly in a first pass, then go
back and manually retry damaged bits with smaller I/Os.
All good input.
Andrew Morton wrote:
On Mon, 04 Dec 2006 23:56:42 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
libata_resume_fix.patch
I thought this was resolved long ago? Are there still open reports that
this solves, where upstream doesn't work?
Heck, I don't know.
You probably
Ed Sweetman wrote:
Not sure what went on between 2.6.19-rc5-mm2 and 2.6.20-rc2-mm2 in
libata land but SMART is no longer available on my hdds.
It's working for me with 2.6.20-rc3, ata_piix libata driver.
-ml
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Hugh Dickins wrote:
On Thu, 4 Jan 2007, Hua Zhong wrote:
So I'd argue that it makes more sense to support O_DIRECT
on tmpfs as the memory IS the backing store.
A few more voices in favour and I'll be persuaded.
I see no reason to restrict it as is currently done.
Policy belongs in userspac
Ed Sweetman wrote:
Mark Lord wrote:
Ed Sweetman wrote:
Not sure what went on between 2.6.19-rc5-mm2 and 2.6.20-rc2-mm2 in
libata land but SMART is no longer available on my hdds.
It's working for me with 2.6.20-rc3, ata_piix libata driver.
Well, not in the sata_nv libata driver.
Ex
longer use the card myself.
But lots of other people do seem to use it, so it might be nice to see it
"in-tree".
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- linux-2.6.11/drivers/ide/Kconfig2005-03-02 10:07:37.0 -0500
+++ linux/drivers/ide/Kconfig
Alberto Alonso wrote:
Sorry for the long delay, I've been called on too
many issues at work this week.
Anyway, the patch basically made the drives not usable.
Mmm.. Okay, thanks for helping track this down.
It appears that this got broken when the ATA_TFLAG_POLLING
got introduced into libata,
Berck E. Nash wrote:
Tejun Heo wrote:
Then, a series of obsolete STANDBY failures. Who's issuing these
commands? It's not libata, libata uses STANDBY (0xe2). Is it some
kind of gentoo thing?
Nope, Debian/Unstable.
Most probably my hdparm utility. It first tries the old STANDBY command,
Linus Torvalds wrote:
For example, if I get a patch for something that is a whole driver, I
generally think that while I *prefer* to see it follow the kernel coding
style, I also expect that the person who sends me the driver is the one
who is going to maintain it in the future, and thus his
Sergei Shtylyov wrote:
Alan Cox wrote:
I can prepare a patch, but only with a lot of guidance. I can test
& debug, I'm highly motivated just right now ...
If you've got a nice repeatable problem please try using the libata
driver. That handles the error paths differently and doesn't try a F
Andrew Morton wrote:
What do we actually want the kernel to *do*? Stated in terms of "when the
dirty memory state is A, do B" and "when userspace does C, the kernel should
do D".
When we have dirty pages awaiting write-out,
and the write-out device is completely idle,
then we should be writin
[EMAIL PROTECTED] wrote:
On Thu, 21 Jun 2007, David Chinner wrote:
On Thu, Jun 21, 2007 at 12:56:44PM +1000, Neil Brown wrote:
I have that - apparently naive - idea that drives use strong checksum,
and will never return bad data, only good data or an error. If this
isn't right, then it would
Robert de Rooy wrote:
I did another try with libata pcmcia support using 2.6.22-rc5 which
already includes the nodata polling fix, in combination with
disable-dev_init_param-and-setxfermode-for-CFA.patch and the
timing-debug.patch
...
Jun 22 13:19:44 localhost kernel: ata3.00: issuing IDENT
Carlo Wood wrote:
The following can be observed:
1) There is hardly any difference between the two schedulers (noop
is a little faster for the bonny test).
2) An NCQ depth of 1 is WAY faster on RAID5 (bonnie; around 125 MB/s),
the NCQ depth of 2 is by far the slowest for the RAID5 (bonnie
Ingo Molnar wrote:
Subject: [patch] sys_time() speedup
From: Ingo Molnar <[EMAIL PROTECTED]>
improve performance of sys_time(). sys_time() returns time in seconds,
but it does so by calling do_gettimeofday() and then returning the
tv_sec portion of the GTOD time. But the data structure "xtime"
Robert de Rooy wrote:
Mark Lord wrote:
Oh crap. I did test it a couple of months ago, but my boot/root drive
is libata not IDE -- so no panic on boot with it. After booting, it
worked
just fine talking to PC-CARD CF devices using the polling.
Ok, no problem. I recompiled the kernel with
Kai Makisara wrote:
The command 'smartctl -a /dev/sdb' fails with 2.6.22-rc4 kernel. The
disk /dev/sdb is a SATA disk. The command does work still with a real SCSI
disk.
Last time I checked, one must supply the "-d ata" parameter to smartctl
for it to work with libata drives. Has this changed
Thomas Gleixner wrote:
The following patch series contains:
- dyntick bugfixes for -mm (caused by the cpuidle changes in ACPI)
- updates and improvements to high resolution timer / dynticks
- high resolution timer / dynticks support for x86_64
The x86_64 support is based on an initial patch
Thomas Gleixner wrote:
Mark,
On Sun, 2007-06-10 at 18:46 -0400, Mark Lord wrote:
Do you know if there's anything specific in there that would fix
the start-up race condition with HRTIMERS on my machine here
(previously discussed, yet unresolved)?
It still happens sporadically on bo
Jan Kara wrote:
Chuck Ebbert wrote:
On 06/07/2007 11:41 AM, Andrew Morton wrote:
mount /var/lib/mythtv -oremount,ro
sync
umount /var/lib/mythtv
Did this succeed? If the application is still truncating that file, the
umount should have failed.
Shouldn't sync should wait for truncate to
Jan Kara wrote:
Andrew Morton wrote:
On Thu, 07 Jun 2007 12:11:58 -0400
Chuck Ebbert <[EMAIL PROTECTED]> wrote:
On 06/07/2007 11:41 AM, Andrew Morton wrote:
mount /var/lib/mythtv -oremount,ro
sync
umount /var/lib/mythtv
Did this succeed? If the application is still truncating that fil
errupt mis-delivery
problem some more. I've lost the history of the original issue,
but we now know that everything except the actual interrupt seems good.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
Albert Lee wrote:
..
It looks like the ATA passthru commands contain more information than
what libata needs to execute a command.
e.g. protocol number:
libata could possibly infer the protocol from the command opcode.
e.g. multi_count:
libata caches dev->multi_count. Passing multi_co
Christoph Pleger wrote:
Hello,
In recent kernels both PATA and SATA (SCSI too) drives are handled by
libata library. It calls all the drives sd* .
If so, what about the use of hdparm then? I could not change parameters
like DMA, MultSectIO and 32-Bit support with hdparm. sdparm also did not
Robert Hancock wrote:
..
Currently the DMA, multi-sector mode, etc. are not controllable with
hdparm with libata. libata is designed to use the fastest settings
possible by default. In a lot of cases this messing with hdparm was only
needed because of stupidity with the old IDE code (like DMA
Adam Spiers wrote:
On Sun, Jul 08, 2007 at 08:14:10PM -0500, Bruce Allen wrote:
On Sun, 8 Jul 2007, Bruce Allen wrote:
..
http://article.gmane.org/gmane.linux.utilities.smartmontools/4704/match=diamondmax
Again, this indicates that SMART is enabled. But it's not clear what the
kernel version
S.Çag(lar Onur wrote:
Hi;
07 Tem 2007 Cts tarihinde, Robert Hancock Åunları yazmıÅtı:
It's not the free space on the drive that matters, it's the number of
free sectors in the spare sector pool on the drive, which is invisible
to software.
Your SMART log shows 309 reallocated sectors. Th
Jeremy Maitin-Shepard wrote:
I'll certainly admit the kexec idea is vaporware currently, but it does
differ in a significant way from freezer-based approaches, such that I
don't think it should be referred to as just another implementation of a
freezer. Specifically, it doesn't require that th
David Sumbler wrote:
My computer (Ubuntu Feisty) would not boot correctly a few days
ago: it seemed to get into a loop with the following printed about
every 7 seconds (all laboriously copied in longhand, since it wasn't
logged!):
ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.01
Rafael J. Wysocki wrote:
On Thursday, 12 July 2007 08:43, [EMAIL PROTECTED] wrote:
On Wed, 11 Jul 2007, Jeremy Fitzhardinge wrote:
Andrew Morton wrote:
..
8. hibernate kernel does syspend-to-ram to put the devices into a known
safe state.
Again, the devices should be quiesced rather then su
[EMAIL PROTECTED] wrote:
actually, I think that while you may be able to get away with only one
kernel, you are probably better off with two. on the hibernate kernel
you can choose many 'embedded' options that don't make sense for the
normal kernel (no high mem, no SMP support, no SELinux, no
Rafael J. Wysocki wrote:
On Thursday, 12 July 2007 15:51, Mark Lord wrote:
..
Currently, TuxOnIce(suspend2) takes about 10 seconds to suspend my notebook.
Switching to this new scheme would double that to 10 seconds to boot/probe,
plus the original 10 seconds to hibernate. Assuming the new
Mark Lord wrote:
Rafael J. Wysocki wrote:
..
How much RAM is there in your machine?
2GB, but It doesn't need to dump that much for good performance.
Hibernate here consists of:
echo "$(( 256 * 1024 * 1024 ))" > /sys/power/image_size
echo -n disk > /sys/power/st
Jeremy Maitin-Shepard wrote:
A typical usage pattern of hibernate on a laptop is to shut the lid,
causing the system to start to hibernate, and to place the machine in
All laptops we have here, and those of all people I have seen
with laptops, do suspend-to-RAM on lid-close, not hibernate.
An
Ingo Freund wrote:
Hi
I've got a RAID5 (driver aacraid for an ICP9047MA) with four
750GB hdds which provides a 2.25TB sized device.
None of the until now used tools will work with that device.
fdisk complains about missing cylinder count.
cfdisk misses the device size.
parted shows the right dev
me to time:
Original Message
Subject: [BUG] 2.6.21: Kernel won't boot with either/both of CONFIG_NO_HZ,
CONFIG_HIGH_RES_TIMERS
Date: Mon, 30 Apr 2007 16:17:00 -0400
From: Mark Lord <[EMAIL PROTECTED]>
To: Linux Kernel , [EMAIL PROTECTED]
CC: Linus Torvalds <[EMAIL P
Alan Cox wrote:
O> >>BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs, and if DMA is
not complete or interrupt pending, it may wait 10 more secs...
I really don't remember... :)
Maybe Mark or Alan could help with figuring this out.
They also have probably forgotten. :-)
Be
Linus Torvalds wrote:
On Fri, 25 May 2007, Nigel Cunningham wrote:
Does that mean you never ever power off your laptop (assuming you have
one), and the battery never runs out? Surely you must power it off
completely sometimes?
So? The bootup isn't that much worse than a disk suspend/resume, a
Nigel Cunningham wrote:
I'm sorry to say it, but dropping process freezing still seems to me
like the better way though. I prefer it because of the reliability
aspect. With the current code, having frozen processes, I can look at
the state of memory, calculate how much I'll need for this or that
Linus Torvalds wrote:
On Tue, 29 May 2007, Mark Lord wrote:
There are a zillion USB patches in 2.6.22-rc*.
Greg: got any good suggestions on which one to revert first?
Any chance of bisecting it?
Ugh. Is there a way to tell bisect to only work around the USB updates?
I suppose so.. just
Mmmm.. is there a way to get the raw patches out of the http://git.kernel.org/
browser windows ?
Clicking on "diff" gives me a fancy HTML coloured diff,
whereas I need just the raw patch so I can revert it.
???
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Nish Aravamudan wrote:
On 5/29/07, Mark Lord <[EMAIL PROTECTED]> wrote:
I just "upgraded" from 2.6.21.3 to 2.6.22-rc3,
but will be rebooting back into 2.6.21.xx shortly.
Suspend/Resume (RAM) works perfectly on this Dell i9400 dual-core
notebook.
Except with 2.6.22-rc3, all
Mark Lord wrote:
I just "upgraded" from 2.6.21.3 to 2.6.22-rc3,
but will be rebooting back into 2.6.21.xx shortly.
Suspend/Resume (RAM) works perfectly on this Dell i9400 dual-core notebook.
Except with 2.6.22-rc3, all USB devices are non-functional on resume.
Most of the time.
On
Mark Lord wrote:
..
7ed92f1a149dddc3cb537ccd7441e98adac12c3e USB: make the autosuspend
workqueue thread freezable
ef7f6c7084b333c7524dcd297e0578d43733a2a2 USB: more autosuspend timer stuff
I yanked them both, as they appeared to be releated based on the titles.
Reverting this pair of commits
Linus Torvalds wrote:
On Tue, 29 May 2007, Mark Lord wrote:
Okay, just to make it trivial,
I've narrowed it down to only this commit from Alan Stern:
7ed92f1a149dddc3cb537ccd7441e98adac12c3e USB: make the autosuspend workqueue
thread freezable
Heh. Have I mentioned how much I *hate*
Mark Lord wrote:
Linus Torvalds wrote:
..
There's a different (but related to all the same freezer problems)
patch by Rafael Wysocki <[EMAIL PROTECTED]>:
Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by
default
Message-Id: <[EMAIL PROTECTED]>
Alan Stern wrote:
On Tue, 29 May 2007, Mark Lord wrote:
Mark Lord wrote:
7ed92f1a149dddc3cb537ccd7441e98adac12c3e USB: make the autosuspend
workqueue thread freezable
ef7f6c7084b333c7524dcd297e0578d43733a2a2 USB: more autosuspend timer stuff
I yanked them both, as they appeared to be
ut even for
root hubs (an oversight in the original code).
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Acked-by: Mark Lord <[EMAIL PROTECTED]>
---
Index: 2.6.22-rc3/drivers/usb/core/hub.c
===
--- 2.6.22-rc3.orig/drive
Linus Torvalds wrote:
And once I looked closer, I just went "aiieee, it wasn't all the email client"
;)
Not long ago, Tejun pointed out the "External Editor" extension for Thunderbird,
which turns out to be the only really sane way to submit patches with that
client.
Download and install it,
Ingo Molnar wrote:
- sendfile(). This API mainly failed on #2. It partly failed on #1 too.
(couldnt be used in certain types of scenarios so was unintuitive.)
splice() fixes this almost completely.
- KAIO. It fails on #2 and #3.
I wonder how useful it would be to reimplement sendfile(
Daniel J Blueman wrote:
I have a SanDisk Extreme IV 4GB CF card, capable of 40MB/s read, but
am seeing 30MB/s read [1], connected directly to the IDE bus on my
ICH8 controller.
How can I find out if this would be a timing or configuration issue?
On 2.6.20.5 [2], the 120nS timing looks to be righ
Daniel J Blueman wrote:
Hi Mark,
Thanks for the reply; here is the raw identification data:
# hdparm --Istdout /dev/sdb
/dev/sdb:
045a 3fff c837 0010 003f
2020 2020 2020 5644 5334 3142
5434 4456 3038 474a 0003 3bf5 0034 5634
344f 4139 3641 4844 5437 3232 3532 3544
4c41
Daniel J Blueman wrote:
Whoops, yes. Here is the expected data:
# hdparm --Istdout /dev/sdb
/dev/sdb:
848a 1f1c 0010 0240 003f 007a
7e40 2020 2020 3131 3638 3032 4432
3830 374a 3335 0002 0002 0004 4844
5820 342e 3034 5361 6e44 6973 6b20 5344
4346 582d 3430 3936 2020 2020 20
Daniel J Blueman wrote:
On 31/05/07, Mark Lord <[EMAIL PROTECTED]> wrote:
Daniel J Blueman wrote:
> Whoops, yes. Here is the expected data:
[snip]
Thanks. I'll use that data to update/validate future versions of hdparm.
At UDMA66, it *should* be capable of the 40MByte/sec rea
Daniel J Blueman wrote:
hdparm in the other identify mode does list the UDMA3/4 modes twice
[1], which looks odd.
That got fixed a few revisions ago. Update your copy of hdparm
from the masters on sourceforge.
Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
Daniel J Blueman wrote:
On 31/05/07, Mark Lord <[EMAIL PROTECTED]> wrote:
Daniel J Blueman wrote:
...
I don't know too much about the specifics, though, but perhaps the
card is only capable of full speed in PIO6, which requires special
cabling
and is currently unsupporte
Jeff Garzik wrote:
Mark Lord wrote:
Some cards may perform better when their "memory" interface is used
instead of the "I/O" interface, or vice-versa. I'm not sure which
of the two methods was selected by libata (probably the "memory"
interface).
I am
Sergei Shtylyov wrote:
Mark Lord wrote:
O> >>BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs,
and if DMA is not complete or interrupt pending, it may wait 10 more secs...
..
I've lost the original question from this thread, but the idea of the
The ori
Sergei Shtylyov wrote:
Mark Lord wrote:
The original question concerned specifically the DMA command
timeout which is twice more than the usual one, WAIT_CMD (10 seconds).
..
When a drive is in standby, we don't send it anything special to wake up.
So even DMA commands have to have a
401 - 500 of 763 matches
Mail list logo
