I'll have to.
But we still face the initial problem that requeued requests will be
stuck in the queue forever (ie until the timeout catches it), causing
failover to be painfully slow.
Anyway, I'll think it over.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Stor
Hannes Reinecke wrote:
> Laurent Riffard wrote:
>> Le 21.11.2007 23:41, Andrew Morton a écrit :
>>> On Wed, 21 Nov 2007 22:45:22 +0100
>>> Laurent Riffard <[EMAIL PROTECTED]> wrote:
>>>
>>>> Le 21.11.2007 05:45, Andrew Morton a écrit :
&
a_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch
>> touch pata_via.c.
>
> None of the above...
>
> I did a bisection, it spotted git-scsi-misc.patch.
> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine.
>
> I g
oo busy, sorry). If someone
else confirms it does it's job then
Acked-by: Hannes Reinecke <[EMAIL PROTECTED]>
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
[EMAIL PROTECTED] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfe
from userland
anyway after doing a device_del(). And the implication is that it's
going to be remove soon entirely. So we're just moving the timing
of the eventual call to the ->release() function; the events will
be triggered by device_del() and won't be changed.
And if some dev
_segments by using an 'io_restrictions' structure
> that keeps the most restrictive values from all component devices.
>
> So it should not allow more than max_hw_segments.
>
> However I just notices that it does not preserve bounce_pfn as a restriction.
> So when the
t;>
>>>> 1-debloat.patchdeinlines a lot of functions
>>>> 2-addstatic.patch adds statics, #ifdefs out huge amount of unused code,
>>>> adds consts
>>>> 3-addconst.patch adds more consts
Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]>
Cheer
t huge amount of unused code,
>>> adds consts
>>> 3-addconst.patch adds more consts
Have you checked the sequence assembler, too? It doesn't help much to edit the
*.shipped files;
someone might just run the assembler again and we're back to square one ...
;> linux-2.6.23-rc1.aic2.t/drivers/scsi/aic7xxx/built-in.o
>>
>> 1-debloat.patchdeinlines a lot of functions
>> 2-addstatic.patch adds statics, #ifdefs out huge amount of unused code,
>> adds consts
>> 3-addconst.patch adds more consts
> --
> vda
&g
Am Sat 01 Sep 2007 12:43:57 AM CEST schrieb Kiyoshi Ueda
<[EMAIL PROTECTED]>:
This patch moves the rq->end_io() calling point to the top of
blk_end_request() from the last of end_that_request_last().
This means that whole request completion can be hooked by rq->end_io()
because all device driv
ot; approach so to speak ;-)
>> The problem is that we don't really have a maintainer for the aic7xyz
>> drivers any more. Volunteers welcome. NOT IT!
>
> Take it before someone else does!
>
Well, the semi-official maintainers are James B. and me.
So I might as well do i
onder why this one is not implemented as a SCSI driver in the
first place.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
[EMAIL PROTECTED] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB
ery
single possible device nodes (and defeat the purpose of udev to create
device nodes for existing devices only).
Please apply.
Cheers,
Hannes
--
Dr. Hannes Reinecke [EMAIL PROTECTED]
SuSE Linux Products GmbHS390 & zSeries
Maxfeldstraße 5
Dr. Hannes Reinecke [EMAIL PROTECTED]
SuSE Linux AG S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg http://www.suse.de
Subject: ata_piix does not find any devices on ACER laptop
From: H
Christoph Hellwig wrote:
> On Thu, Apr 07, 2005 at 11:46:27AM +0200, Hannes Reinecke wrote:
>>Hi all,
>>
>>/proc/scsi/scsi currently has a very dumb implementation of the seq_file
>>api which causes 'cat /proc/scsi/scsi' to return with -ENOMEM when a
&g
imes for
no appearent reason.
But I'm all ears for a better solution.
Cheers,
Hannes
--
Dr. Hannes Reinecke [EMAIL PROTECTED]
SuSE Linux AG S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg
Andreas Schwab wrote:
Hannes Reinecke <[EMAIL PROTECTED]> writes:
--- linux-2.6.10/kernel/power/disk.c.orig 2005-01-31
13:54:17.0 +0100
+++ linux-2.6.10/kernel/power/disk.c2005-01-31 14:55:14.0 +0100
@@ -9,6 +9,8 @@
*
*/
+#define DEBUG
+
#include
#i
Matthew Garrett wrote:
On Mon, 2005-01-31 at 15:09 +0100, Hannes Reinecke wrote:
swsusp_check is used by both entry points, and is itself not a init
function.
I simply found it bad style to reference a __init function from there.
And name_to_dev_t is evil in itself. I'd gladly be rid of
ce in 'major:minor'
format.
When written to it expects a device in 'major:minor' format.
This device is then checked for a suspended image and resume is started
if a valid image is found.
The original functionality is left in place.
It should only be used from initramfs; ot
.
Cheers,
Hannes
--
Dr. Hannes Reinecke [EMAIL PROTECTED]
SuSE Linux AG S390 & zSeries
MaxfeldstraÃe 5+49 911 74053 688
90409 NÃrnberg http://www.suse.de
-
To unsubscribe from this list: send the
principle :-).
Oh, and the usual applies: works for me, might eat your disk, beware of
nasal demons.
Cheers,
Hannes
--
Dr. Hannes Reinecke [EMAIL PROTECTED]
SuSE Linux AG S390 & zSeries
Maxfeldstraße 5 +49 9
Greg KH wrote:
On Wed, Jan 19, 2005 at 02:48:14PM +0100, Hannes Reinecke wrote:
Hi Dmitry,
attached is the reworked patch for removing the call to
call_usermodehelper from input.c
I've used the 'phys' attribute to generate the device names, this way we
don't need to touch
Vojtech Pavlik wrote:
On Wed, Jan 19, 2005 at 03:56:33PM +0100, Hannes Reinecke wrote:
oops. hadn't thought of that. But of course, you are correct.
So better be using monotonically increasing numbers.
New patch attached.
This one looks quite OK to me.
Will you put it into your bk-input tr
Dmitry Torokhov wrote:
On Wed, 19 Jan 2005 15:16:08 +0100, Hannes Reinecke <[EMAIL PROTECTED]> wrote:
[ ... ]
I'm not too happy about this 'inputX' thing (as this doesn't carry any
information, whereas 'phys' gives you at least a rough guess what this
device
Dmitry Torokhov wrote:
Hi Hannes,
On Wed, 19 Jan 2005 10:59:30 +0100, Hannes Reinecke <[EMAIL PROTECTED]> wrote:
Dmitry Torokhov wrote:
But the real question is whether we really need class devices have
unique names or we could do with inputX thus leaving individual
drivers intact an
come.
Cheers,
Hannes
--
Dr. Hannes Reinecke [EMAIL PROTECTED]
SuSE Linux AG S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg http://www.suse.de
# This is a BitKeeper generated diff -Nru st
On Tue, Jan 18, 2005 at 03:56:35PM +0100, Hannes Reinecke wrote:
Hi all,
the input subsystem is using call_usermodehelper directly, which breaks
all sorts of assertions especially when using udev.
And it's definitely going to fail once someone is trying to use netlink
messages for hotplug e
Dmitry Torokhov wrote:
Hi,
On Tue, 18 Jan 2005 15:59:35 +0100, Hannes Reinecke <[EMAIL PROTECTED]> wrote:
Implement proper class names for input drivers.
This patch probably should probably use atomic_inc in case we ever
have non-serialized probe functions.
True.
But the real question is w
Implement proper class names for input drivers.
Cheers,
Hannes
--
Dr. Hannes Reinecke [EMAIL PROTECTED]
SuSE Linux AG S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg http://www.sus
This patch implements the core changes in drivers/input/input.c.
A new sysfs class 'input_device' is added as a representation of
struct input_dev.
Cheers,
Hannes
--
Dr. Hannes Reinecke [EMAIL PROTECTED]
SuSE Linux AG S390 & zSeries
M
s
not very informative.
Patch 1/2 implements the core changes to drivers/input/input.c
Patch 2/2 provides proper device names for input drivers.
Patches are relative to bk://kernel.bkbits.net/vojtech/input
Comments are welcome.
Please CC me directly as I'm not on this list.
Cheers,
Hannes
--
Dr
1001 - 1031 of 1031 matches
Mail list logo
