On Wednesday 31 January 2007 2:47 pm, Daniel Walker wrote:
> On Wed, 2007-01-31 at 11:43 -0800, David Brownell wrote:
> > > As a note, arm and mips both register their clocksources during
> > > time_init() instead of using initcalls.
> >
> > That's actually platform-specific. ...
> >
> > So don'
On Wed, 31 Jan 2007 16:14:10 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Mon, 29 Jan 2007, Andrew Morton wrote:
>
> > - Restored git-block.patch: mainly the block unplugging rework. The
> > problematic CFQ updates have been taken out.
>
> MD hung again as before so I compile
On Wed, 31 Jan 2007, Andrew Morton wrote:
> ow. Please don't make me drop git-block-and-lots-of-other-things again.
> Was 2.6.20-rc6-mm2 OK? It didn't have git-block.
Yes, 2.6.20-rc6-mm2 was okay. Sorry.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Wed, 31 Jan 2007 16:19:06 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I should either revert that commit or just check for "free_pages" being
> negative. The latter, in many ways, is probably better, because generally
> we simply should never work with negative numbers in the kern
On Wed, 2007-01-31 at 16:15 -0800, Daniel Walker wrote:
> > clocksource_initcall is simply superfluid.
>
> My position has always been that clocksources should be registered as
> early as possible .. The fs_initcall() usage is a compromise stemming
> from early resistance that John, and you gave t
Hi Len,
On 2.6.20-rc6-mm2 my rx2600 wouldn't boot unless I reverted all changes
to drivers/acpi/tables.c. Nearly all major early boot detected ACPI tables
weren't discovered. I never had time to resolve because 2.6.20-rc6-mm3
showed up. The -mm2 problem appears corrected but the machine now crash
On Tue, 2007-01-30 at 13:08 -0500, Alan Stern wrote:
> On Sat, 27 Jan 2007, Soeren Sonnenburg wrote:
[P990 mass storage trouble]
> > Now I am clueless what could have gone wrong (as I *think* this was all
> > working at some point at least before firmware updates) and what the
> > difference betwe
It's been a week and a half, and here comes the -rc3
http://www.kernel.org/pub/software/scm/git/
git-1.5.0-rc3.tar.{gz,bz2}(tarball)
git-htmldocs-1.5.0-rc3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.0-rc3.tar.{gz,bz2} (preformatted docs)
te
On Wed, 31 Jan 2007 16:27:16 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Wed, 31 Jan 2007, Andrew Morton wrote:
>
> > ow. Please don't make me drop git-block-and-lots-of-other-things again.
> > Was 2.6.20-rc6-mm2 OK? It didn't have git-block.
>
> Yes, 2.6.20-rc6-mm2 was okay.
On Wed, 31 Jan 2007, Andrew Morton wrote:
> Actually, we might not have lost an IO: it could be that we're simply
> missing an unplug. Are you able to unblock things by forcing some other IO
> against that queue? Say, do a read from /dev/sda?
The system does not come up to a prompt. The traces
On Wed, 2007-01-31 at 18:14 -0600, Robert Hancock wrote:
> > So either #1 or #2 should have failed in the first place. Failing in #3
> > is definitely a BUG in #1 or #2.
> >
> > How does your advise help to fix that BUG ? Ignoring it by using
> > something else ?
>
> Yes, there is likely a bug he
On Wed, 31 Jan 2007, Andrew Morton wrote:
>
> It would be cleaner to check for negativity, but note that we keep
> subtracting stuff from free_pages in the later loop, so we'd need to check
> there as well.
Yeah, not worth it. I'll just revert it.
If we really want to do the micro-optimization
Linus Torvalds wrote:
if (free_pages <= min + z->lowmem_reserve[classzone_idx])
return 0;
gets broken, because the negative 'free_pages' will look like a huge
unsigned positive number (and we'll make it unsigned becaue 'min' got
turned unsigned). There was a reason tha
On Thu, Feb 01, 2007 at 01:03:09AM +0100, Peter Zijlstra wrote:
> On Wed, 2007-01-31 at 15:32 -0800, Paul E. McKenney wrote:
>
> > The wakeup in barrier_sync() would mean that the counter was zero
> > at some point in the past. The counter would then be rechecked, and
> > if it were still zero, b
Guillaume Chazarain <[EMAIL PROTECTED]> writes:
> Hi,
>
> I think this is 2.6.20 material, if it gets appropriately reviewed ;-)
Look good to me.
Lookup doesn't have this problem because it only tests for tgid.
I'm not certain at the moment if we need the rcu_read_lock,
and pid_alive checks, but
On Thu, 1 Feb 2007, Nick Piggin wrote:
>
> We could make them both unsigned, and _add_ everything to min rather than
> subtracting from free_pages?
Yeah, that's the right thing to do, probably. However, since we do that
"min >>=1" thing, we'd have to do that to a separate "correction" factor
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
Hello!
This is yet another update of the RCU priority-boosting patch
(see http://lkml.org/lkml/2007/1/24/294 for the previous version).
This series contains the RCU-boost patch itself and rcutorture
modifications to test it more thoroughly. This version incorporates
feedback from Josh Triplett an
Here is the RCU priority-boosting patch. Pretty close to the
http://lkml.org/lkml/2007/1/24/295 version. This patch prevents
preempted or blocked low-priority RCU readers from indefinitely
stalling RCU grace periods.
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
include/linux/init_ta
This patch adds an optional preemption kernel thread to the rcutorture
tests. This thread sets itself to a low RT priority and chews up CPU
in 10-second bursts, verifying that grace periods progress during this
10-second interval. Passes RCU torture testing on a 4-CPU (a pair of
2-CPU dies) 64-bi
On 1/31/07, Mark Lord <[EMAIL PROTECTED]> wrote:
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 li
From: TJ <[EMAIL PROTECTED]>
Applies to: up-to and including 2.6.20-rc7
Update to previous patch.
Fixed logical error in if() statements for conditional printk(). Replaced
bit-wise OR with AND.
Signed-off-by: TJ <[EMAIL PROTECTED]>
--- fs/partitions/msdos.tj.c2007-02-01 00:41:57.
On Thu, Feb 01, 2007 at 10:07:53AM +1000, Trent Waddington wrote:
> On 2/1/07, Greg KH <[EMAIL PROTECTED]> wrote:
> >No, I'm going by Linus's rule here, if a person doesn't want their code
> >in the kernel tree, then I'm not going to forcefully put it there.
> >That's just being rude.
>
> Makes se
Hi Paul.
On Wed, 2007-01-31 at 17:26 -0800, Paul E. McKenney wrote:
> This patch adds an optional preemption kernel thread to the rcutorture
> tests. This thread sets itself to a low RT priority and chews up CPU
> in 10-second bursts, verifying that grace periods progress during this
> 10-second
Hi;
31 Oca 2007 Çar tarihinde şunları yazmıştınız:
> In other words, please do give it a good testing. We should have fixed the
> nasty stuff on Adrian's list (and here's another thanks to Adrian for
> keeping me on my toes!) and it's all good. But please give it a quick
> shake-down to make sure
On Wed, Jan 31, 2007 at 03:56:51PM -0800, Andrew Morton wrote:
> On Wed, 31 Jan 2007 07:11:04 +
> Oleg Verych <[EMAIL PROTECTED]> wrote:
>
> > kbuild: correctly skip tilded backups in localversion files
>
> Does this patch replace Bastian's patch, below?
Along with "Message-ID: <[EMAIL PROTE
On Thu, Feb 01, 2007 at 01:12:16PM +1100, Nigel Cunningham wrote:
> Hi Paul.
>
> On Wed, 2007-01-31 at 17:26 -0800, Paul E. McKenney wrote:
> > This patch adds an optional preemption kernel thread to the rcutorture
> > tests. This thread sets itself to a low RT priority and chews up CPU
> > in 10
Frédéric Riss wrote:
Le mardi 30 janvier 2007 à 12:17 -0700, Bjorn Helgaas a écrit :
On Tuesday 30 January 2007 12:01, Frédéric Riss wrote:
When calling into an EFI firmware, the parameters need to be passed on
the stack. The recent change to use -mregparm=3 breaks x86 EFI support.
This pat
On Thu, 1 Feb 2007, S.ÃaÄlar Onur wrote:
>
> For me, both 2.6.20-rc6 and 2.6.20-rc7 fails while booting with initramfs
> (initramfs that uses busybox) with "request_module: runaway loop modprobe
> binfmt-" error.
That _usually_ just means that /sbin/modprobe is corrupt, or compiled with
Hi Paul.
On Wed, 2007-01-31 at 18:31 -0800, Paul E. McKenney wrote:
> Good to hear from you, Nigel!
Thanks :)
> Should indeed be OK to freeze during suspend/hibernate. Will my
> schedule_timeout_interruptible() be sufficient to allow the freeze
> to happen, or do I need to add an explicit try_t
On Thu, 1 Feb 2007 03:37:17 +0100 Oleg Verych <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 31, 2007 at 03:56:51PM -0800, Andrew Morton wrote:
> > On Wed, 31 Jan 2007 07:11:04 +
> > Oleg Verych <[EMAIL PROTECTED]> wrote:
> >
> > > kbuild: correctly skip tilded backups in localversion files
> >
>
On Tuesday 30 January 2007 06:52, Sunil Naidu wrote:
> Hi Andrew,
>
> I did compile the same, it's a trouble free boot. I did observe
> interesting changes in the dmesg between 2.6.20-rc6 & 2.6.20-rc6-mm3
> (wondering why there are so many changes in the output). Anyway, the
> changes in brief:-
>
01 Şub 2007 Per tarihinde, Linus Torvalds şunları yazmıştı:
> That _usually_ just means that /sbin/modprobe is corrupt, or compiled with
> a binfmt that itself needs a module to load.
>
> Are you 100% certain that you didn't just happen to put an /sbin/modprobe
> into your initramfs that happens t
On Thu, 1 Feb 2007, S.ÃaÄlar Onur wrote:
>
> I think i found the cause of the problem, initramfs can't handle hardlinks
> anymore (which works with 2.6.18), copying same /sbin/busybox binary with
> different names into initramfs (which ends ups with 50 MB image) or using
> symbolic ones inste
On 2/1/07, Alan <[EMAIL PROTECTED]> wrote:
> When I telnet my board and run the following command:
> root:~> stty -F /dev/ttyS0 -crtscts
>
> I got the following result from the console of my board:
> root:~>new_termios flag: 0x1cb1, old_termios flag: 0x80001cb1
>
> That's correct. CRTSC
[ This is -mm only until Andi acks it ]
The 32-bit sysenter entry point mangles the sixth system call argument
for both 32-bit and 64-bit ptrace. In both cases, strace shows the
frame pointer (ebp) as the sixth argument.
Here's a snippet of a 64-bit strace of a 32-bit test program which
calls mm
From: Jay Cliburn <[EMAIL PROTECTED]>
pci_module_init is deprecated. Use pci_register_driver instead.
Discovered by and modification suggested by Alan Cox.
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1_main.c |5 +
1 files changed, 1 insertions(+), 4 deletion
From: Jay Cliburn <[EMAIL PROTECTED]>
Fix up some constants relating to max and min ring descriptor counts.
Also add functionality to enable ethtool to set tx and rx ring parameters.
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1.h |4 +-
drivers/net/atl1/a
Jeff Garzik wrote:
Divy Le Ray wrote:
From: Divy Le Ray <[EMAIL PROTECTED]>
Offload packets may be DMAed long after their SGE Tx descriptors are
done
so they must remain mapped until they are freed rather than until their
descriptors are freed. Unmap such packets through an skb destructor.
Hi Jeff,
Please see my replies in line.
You need to submit a patch to remove the following ioctls:
CHELSIO_SETREG:
CHELSIO_GETREG:
These will get removed.
CHELSIO_SET_QSET_PARAMS: (use ethtool instead)
CHELSIO_GET_QSET_PARAMS: (use ethtool instead)
The T3 adapter supports multiple Tx/Rx q
On Wed, Jan 31, 2007 at 03:54:55PM -0500, [EMAIL PROTECTED] wrote:
> Only gotcha I know of: Sometimes one of the ipw3945d kernel threads will
> hang in a loop if the RFKill switch is set to "kill" when the system comes
> up. I also don't know how it handles suspend, I don't use that on my D820.
TJ wrote:
From: TJ <[EMAIL PROTECTED]>
Applies to: up-to and including 2.6.20-rc7
This rare but critical bug has the potential to cause a hardware failure on
disk drives by
allowing the system to repeatedly attempt to seek to sectors beyond the end of
the physical
disk, causing sustained 'h
On Tuesday 30 January 2007 04:26, Andrew Morton wrote:
> On Tue, 30 Jan 2007 10:06:45 +0100
> Olivier Galibert <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Jan 29, 2007 at 08:45:28PM -0800, Andrew Morton wrote:
> > > -x86_64-mm-share-whats-shareable.patch
> > > -x86_64-mm-only-call-unreachable_devices
On 1/29/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
1. Scheduling fairness.
Since kernel does not know about multiple threads behind given process,
it can not add it appropriate number of timeslices for execution.
Can be solved either by more tight collaboarion of the userspace and
kernelspac
On Mon, Jan 29, 2007 at 09:09:14AM +1100, Benjamin Herrenschmidt wrote:
>
> If we followed that "only do incrementental changes" rule all the time,
> imagine in what state would be our USB stack today since we couldn't
> have dropped in Linus replacement one ...
Bad example, that is not what happ
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix kernel-doc warning in mtd/nand.h.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
include/linux/mtd/nand.h |1 +
1 file changed, 1 insertion(+)
--- linux-2620-rc7.orig/include/linux/mtd/nand.h
+++ linux-2620-rc7/include/linux/mtd/nand.h
@@ -343
On Thu, 2007-02-01 at 08:42 +1100, Nigel Cunningham wrote:
> Hi.
>
> On Wed, 2007-01-31 at 11:56 +0100, Mike Galbraith wrote:
> > Greetings,
> >
> > I received the below upon first poke of firefox icon after a resume.
>
> Are you able to reproduce it reliably? Failing that, could you try
> ena
Hi.
On Thu, 2007-02-01 at 06:30 +0100, Mike Galbraith wrote:
> Rebuilding this particular kernel with slab debugging would probably be
> a waste of time since stable kernels get very little runtime here, but
> I'll re-add it to my config for test kernels just in case a survivable
> event should ha
On 1/31/07 3:30 PM, "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Gerrit Huizenga wrote:
>> Don't confused KS with a conference;
>> it is a workshop for a very, very large, very very active project.
>
> ... and *growing*, which is the real issue I think.
>
> Something that might make sense for K
Linus Torvalds wrote:
On Thu, 1 Feb 2007, S.ÃaÄlar Onur wrote:
I think i found the cause of the problem, initramfs can't handle hardlinks
anymore (which works with 2.6.18), copying same /sbin/busybox binary with
different names into initramfs (which ends ups with 50 MB image) or using
symboli
On Wed, Jan 31, 2007 at 08:41:03PM +0300, Sergei Organov wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
> [...]
> >> And there are plenty of documented devices that no one cares enough
> >> about to submit a driver for.
> >
> > Any specific examples? I have a long list of people who wish to write
>
On Wed, Jan 31, 2007 at 10:15:20PM +0100, Nicolas Mailhot wrote:
> Le mercredi 31 janvier 2007 ?? 12:12 -0800, Greg KH a ??crit :
> > On Wed, Jan 31, 2007 at 02:06:32PM +0100, Nicolas Mailhot wrote:
>
> [Reordering for the sake of argument]
>
> > > There are many out-of-tree drivers (ivtv, lirc,
On Wed, Jan 31, 2007 at 01:37:58PM -0500, Bob Copeland wrote:
> >Putting the "codingstyle" control aside, often it's because things look
> >too hackish.
>
> Also sometimes the authors know it's hackish, or just don't expect it
> to be generally useful to the world. I happen to own an out-of-tree
Occasionally the kernel has bugs that result in no irq being found for
a given cpu vector. If we acknowledge the irq the system has a good
chance of continuing even though we dropped an irq message. If we
continue to simply print a message and not acknowledge the irq the
system is likely to beco
"Luigi Genoni" <[EMAIL PROTECTED]> writes:
> OK,
> willing to test any patch.
Sure. After I get things working on this end I will copy you,
on any fixes so you can confirm they work for you.
I am still root causing this but I have found a small fix that should
keep the system from going down wh
On Wed, 31 Jan 2007, H. Peter Anvin wrote:
>
> It would be interesting to know what the inode numbers are in the image; also,
> what is the exact behaviour -- do you end up with a missing link, or do both
> entries end up getting hard-linked to an empty file?
Judging by the
request_mod
Linus Torvalds wrote:
On Wed, 31 Jan 2007, H. Peter Anvin wrote:
It would be interesting to know what the inode numbers are in the image; also,
what is the exact behaviour -- do you end up with a missing link, or do both
entries end up getting hard-linked to an empty file?
Judging by the
Sebastian Kemper wrote:
But now /proc/mtrr shows 256MB of video ram, same as lspci, whereas the
real amount of video ram (as properly detected by X) is only 128MB.
The size of the aperture doesn't have to match the actual amount of
memory. For many cards it doesn't.
-hpa
-
To un
While repeatedly running 'aiostress -O -o 2' test I've got in
/var/log/messages:
BUG: warning at mm/truncate.c:398/invalidate_inode_pages2_range()
Call Trace:
[] invalidate_inode_pages2_range+0x236/0x26b
[] ext3_direct_IO+0x16c/0x19e
[] ext3_get_block+0x0/0xe2
[] generic_file_direct_IO+0xb9/0x
On Wed, Jan 31, 2007 at 04:36:38PM -0800, Andrew Morton wrote:
> On Wed, 31 Jan 2007 16:27:16 -0800 (PST)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 31 Jan 2007, Andrew Morton wrote:
> >
> > > ow. Please don't make me drop git-block-and-lots-of-other-things again.
> > > Was 2.6
On Thursday 01 February 2007 07:13, you wrote:
> Sebastian Kemper wrote:
> > But now /proc/mtrr shows 256MB of video ram, same as lspci, whereas
> > the real amount of video ram (as properly detected by X) is only
> > 128MB.
>
> The size of the aperture doesn't have to match the actual amount of
>
H. Peter Anvin wrote:
Linus Torvalds wrote:
On Wed, 31 Jan 2007, H. Peter Anvin wrote:
It would be interesting to know what the inode numbers are in the
image; also,
what is the exact behaviour -- do you end up with a missing link, or
do both
entries end up getting hard-linked to an empty fi
On 1/31/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
When do_tune_cpucache() is called at bootup, I'm not sure how safe it is
to do the kzalloc() thing.
The kzalloc thing is safe as we have already successfully boostrapped
all kmalloc caches at that point. The per-CPU caches that are replaced
Sebastian Kemper wrote:
On Thursday 01 February 2007 07:13, you wrote:
Sebastian Kemper wrote:
But now /proc/mtrr shows 256MB of video ram, same as lspci, whereas
the real amount of video ram (as properly detected by X) is only
128MB.
The size of the aperture doesn't have to match the actual a
Yo,
I took over upstream maintainership of the module-init-tools package
from Rusty at the end of last year. At this point, there's a public
wiki, new pre-release, bugzilla and all that jazz up and running:
http://www.kerneltools.org/ has links to the latest release.
There's a mailing list,
Alexander E. Patrakov wrote:
What's the proper way to make sure that the fix, when it appears, ends
up in my inbox?
Say "please", and give prompt feedback on any test patches that we send you.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
Quoting Pekka J Enberg ([EMAIL PROTECTED]):
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> The revokeat(2) and frevoke(2) system calls invalidate open file
> descriptors and shared mappings of an inode. After an successful
> revocation, operations on file descriptors fail with the EBADF or
> ENXIO e
Jeff Garzik wrote:
Robert Hancock wrote:
Jeff Garzik wrote:
* Include the patch inline rather than as an attachment. Even a
text/plain attachment is very difficult to review and quote in
popular email programs.
Jeff
I'd love to, but unfortunately nobody seems to have come up with a wa
Luca Tettamanti wrote:
Hi Jeff, linux-ide,
I'm having troubles with libata and UDF on RW media. See below.
Il Tue, Jan 30, 2007 at 09:42:34PM +0100, Jan Engelhardt ha scritto:
On Jan 30 2007 21:36, Luca Tettamanti wrote:
Il Tue, Jan 30, 2007 at 09:02:20PM +0100, Jan Engelhardt ha scritto:
On
Tejun Heo wrote:
Implement device resource management, in short, devres. A device
ACK patches 1-7. Applied patches 1-6 (with some remaining pata_platform
damage) to #upstream.
Please examine the resulting damage, and resend patch #7, plus any
missing bits
Jeff
-
To unsubscrib
Two fixes in this test patch. One of them allows old CF cards to refuse
pio mode setting, and one to wait for the drive to settle after a set
features changes the speed settings, which is based upon the workarounds
used by drivers/ide.
Please test and report back if you have an afflicted system. T
Alan wrote:
@@ -5142,6 +5174,20 @@
status = ata_chk_status(ap);
if (unlikely(status & ATA_BUSY))
goto idle_irq;
+
+ if (unlikely(qc->tf.command == ATA_CMD_SET_FEATURES &&
+ qc->tf.feature == SETFEATURES_XFER)) {
+ /* Let the timings
> Looks like you should use ata_busy_wait() here, rather than reproducing
> the same code again.
It waits in 10uS chunks while 1uS chunks were used in the workaround.
Could indeed do that once I know the fix is right. While I'm at it the
ata_busy_wait kerneldoc is borked so here's a fix
Signed-o
Hi all.
I don't know if this report can be useful, but this problem does not
show up in my setup.
I tried multiple times to copy 10MB files (unmounting and remounting
every time) and verified with md5sum the results and everything is
correct.
Details:
* kernel version: 2.6.20-rc6-g93544047
* dr
On 1/31/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
Luca Tettamanti wrote:
> Hi Jeff, linux-ide,
> I'm having troubles with libata and UDF on RW media. See below.
>
> Il Tue, Jan 30, 2007 at 09:42:34PM +0100, Jan Engelhardt ha scritto:
>> On Jan 30 2007 21:36, Luca Tettamanti wrote:
>>> Il Tue, Ja
Hello.
Alan wrote:
Ugh, I'm not seeing any *actual* support for MW/SW DMA in this driver...
Thats long been broken. Should be correct in the libata driver
I've looked thru the specs and it seemed to me that ULi hardware is much
broken PIO wise: their max active time is 8 cycles even
On Wed, Jan 31, 2007 at 05:58:19AM -0500, Jeff Garzik wrote:
> Luca Tettamanti wrote:
> >Hi Jeff, linux-ide,
> >I'm having troubles with libata and UDF on RW media. See below.
> >
> >Il Tue, Jan 30, 2007 at 09:42:34PM +0100, Jan Engelhardt ha scritto:
> >>On Jan 30 2007 21:36, Luca Tettamanti wrot
> should be slightly overclocking PIO modes 0/1 (ULi docs don't shed much light
> on how it should be calculated)... Well, this seems fixed in libata drivers.
The libata code for tuning is based upon the BIOS programmers guide. That
seemed to be the best coverage of a minimal selection. It's also
On Fri, 17 Nov 2006 13:04:30 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Peer Chen wrote:
> > I didn't get any comment from you guys for new patch, does someone take
> > care this patch, do we still need some modification upon it? Or do we
> > need re-submit it in other thread?
>
> For my part
Hi Adrian,
Il Thu, Feb 01, 2007 at 12:10:13AM +0100, Adrian Bunk ha scritto:
> On Wed, Jan 31, 2007 at 05:58:19AM -0500, Jeff Garzik wrote:
> > Luca Tettamanti wrote:
> > >Hi Jeff, linux-ide,
> > >I'm having troubles with libata and UDF on RW media. See below.
> > >
> > >Il Tue, Jan 30, 2007 at 0
Mark Lord wrote:
> Robert Hancock wrote:
>> 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 whenever I'm posting patches,
> and then go back to Thunderbi
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
The patch is specific to kdump scenario.
What I see in the log is cmd timeout(s) and is not related to the patch.
--Sumant
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthias Urlichs
Sent: Wednesday, January 31, 2007 9:50 AM
To: linux-scsi@vger.ke
Mark Lord wrote:
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 t
Jeff Garzik wrote:
Mark Lord wrote:
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 n
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 alternative o
> 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 firmware.
> But
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 in the 2.
On Wed, 2007-01-31 at 10:13 -0500, 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?
Er, it's in scsi_error.c:scsi_decide_disposition():
maybe_retry:
/* we requeue for retry be
Ric Wheeler wrote:
>
>
> Jeff Garzik wrote:
>> Mark Lord wrote:
>>> 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
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 firmw
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
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 depends on the firmware
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 depends on the firmwa
Robert Hancock wrote:
>> http://marc.theaimsgroup.com/?t=11692262122
>
> It looks like Tejun's patch essentially does the same thing as mine with
> the addition of the control from userspace. There is one exception
> though, my patch also does the stop on removal of the SCSI disk (i.e.
> writi
Stefan Richter wrote:
Robert Hancock wrote:
http://marc.theaimsgroup.com/?t=11692262122
It looks like Tejun's patch essentially does the same thing as mine with
the addition of the control from userspace. There is one exception
though, my patch also does the stop on removal of the SCSI disk
On Wednesday 31 January 2007 06:54, Maciej Rutecki wrote:
> Andrew Morton napisał(a):
>
> > OK, thanks. That might be due to the time-management updates as well.
> > I'll see if I can reproduce this.
> >
> > If you're keen, you could test just 2.6.19-rc6+origin.patch+git-acpi.patch
> > from
> >
On Wed, 31 Jan 2007 23:10:32 -0500 Len Brown <[EMAIL PROTECTED]> wrote:
> > CC arch/i386/kernel/traps.o
> > CC arch/i386/kernel/irq.o
> > CC arch/i386/kernel/ptrace.o
> > CC arch/i386/kernel/time.o
> > CC arch/i386/kernel/ioport.o
> > CC arch/i386/kernel/l
301 - 400 of 413 matches
Mail list logo
