* disks becoming slow but not explicitly failing anyone?
From: Carlos Carvalho @ 2006-04-22 20:05 UTC (permalink / raw)
To: linux-raid
We've been hit by a strange problem for about 9 months already. Our
main server suddenly becomes very unresponsive, the load skyrockets
and if demand is high enough it collapses. top shows many processes
stuck in D state. There are no raid or disk error messages, either in
the console or logs.
The machine has 4 IDE disks in a software raid5 array, connected to a
3Ware 7506. Only once I saw warnings of scsi resets of the 3Ware due
to timeouts.
This 3Ware card has leds which are on when there's activity in the IDE
channel. As expected, all leds turn on and off almost simultaneously
during normal operation of the raid5, however when the problem appears
one of the leds stays on much longer than the others for each burst of
activity. This shows that the disk is getting much slower than the
others, holding the whole array.
Several times a smart test of the disk shows read failures but not
always. I've changed cables, 3Ware card and even connected the slow
disk in the IDE channel of the motherboard to no avail. Changing the
disk and reconstructing the array restores normal operation.
This has happened with 7 (seven!!) disks already, 80GB and 120GB,
Maxtor and Seagate. Has anyone else seen this?
^ permalink raw reply
* Re: usbkbd not reporting unknown keys
From: Vojtech Pavlik @ 2006-04-22 20:04 UTC (permalink / raw)
To: Matheus Izvekov; +Cc: linux-kernel, dtor_core
In-Reply-To: <305c16960604221259g4ddabca2o6333f7ffcaff8e4f@mail.gmail.com>
On Sat, Apr 22, 2006 at 04:59:48PM -0300, Matheus Izvekov wrote:
> On 4/22/06, Vojtech Pavlik <vojtech@suse.cz> wrote:
> > On Sat, Apr 22, 2006 at 03:11:30PM -0300, Matheus Izvekov wrote:
> > My opinion is that usbkbd serves as:
> >
> > a) an example usb/input driver
> > b) for embedded systems where usbhid is too large
> >
> > For keyboards with extra keys, use usb-hid.
> >
> > --
> > Vojtech Pavlik
> > Director SuSE Labs
> >
> Sorry, weve came to that conclusion, the thread got to somethign else
> entirely different. ill summarize here my problem so that you dont
> need to read it all over again.
>
> 1) I have a microsoft multimedia keyboard, and the hid driver doesnt
> maps all the multimedia keys. The output of the hid debug output was
> posted previously in the thread.
> 2) For some reason, th hid driver register lots of absolute axis and
> joystick buttons that dont seem to work at all, no matter what i
> press. I Asked if it would be possible to blacklist those. Currently
> the device registers a js interface with so many axis and buttons that
> some programs even segfault while reading it. This interface is
> useless as far as i can see.
> If you need more detailed information please ask me.
Just point me to the HID debug logs. (I need DEBUG enabled in both
hid-core.c and hid-input.c.) Make sure you're running an uptodate
kernel. I'll see what is needed to fix the mappings for that keyboard.
> Maybe the thread subject should be changed to something more
> apropriate, do so if it pleases you.
--
Vojtech Pavlik
Director SuSE Labs
^ permalink raw reply
* Re: [PATCH TESTING] bcm43xx PIO mode
From: Michael Buesch @ 2006-04-22 20:07 UTC (permalink / raw)
To: bcm43xx-dev; +Cc: netdev
In-Reply-To: <200604221718.54245.mb@bu3sch.de>
[-- Attachment #1: Type: text/plain, Size: 414 bytes --]
On Saturday 22 April 2006 17:18, you wrote:
> bcm43xx_lock_mmio(bcm, flags);
> +
> + txctl = bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL);
> + if (txctl & BCM43xx_PIO_TXCTL_SUSPEND)
> + return;
Ah, and yes, I see the bug here. :)
But that normally does not trigger anyway. So no problem
for testing.
And I forgot to say that PIO mode is enabled by module
parameter pio=1
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: usbkbd not reporting unknown keys
From: Matheus Izvekov @ 2006-04-22 19:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Vojtech Pavlik, dtor_core
In-Reply-To: <20060422185402.GC10613@suse.cz>
On 4/22/06, Vojtech Pavlik <vojtech@suse.cz> wrote:
> On Sat, Apr 22, 2006 at 03:11:30PM -0300, Matheus Izvekov wrote:
> My opinion is that usbkbd serves as:
>
> a) an example usb/input driver
> b) for embedded systems where usbhid is too large
>
> For keyboards with extra keys, use usb-hid.
>
> --
> Vojtech Pavlik
> Director SuSE Labs
>
Sorry, weve came to that conclusion, the thread got to somethign else
entirely different. ill summarize here my problem so that you dont
need to read it all over again.
1) I have a microsoft multimedia keyboard, and the hid driver doesnt
maps all the multimedia keys. The output of the hid debug output was
posted previously in the thread.
2) For some reason, th hid driver register lots of absolute axis and
joystick buttons that dont seem to work at all, no matter what i
press. I Asked if it would be possible to blacklist those. Currently
the device registers a js interface with so many axis and buttons that
some programs even segfault while reading it. This interface is
useless as far as i can see.
If you need more detailed information please ask me.
Maybe the thread subject should be changed to something more
apropriate, do so if it pleases you.
^ permalink raw reply
* Re: RFC: New diff-delta.c implementation
From: Nicolas Pitre @ 2006-04-22 19:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Geert Bosch, Git Mailing List
In-Reply-To: <7vslo5ikmk.fsf@assigned-by-dhcp.cox.net>
On Sat, 22 Apr 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > Well, actually I was measuring a 10% speed improvement with a quick and
> > naive (not memory efficient) approach for pack-objects with the current
> > algorithm.
> >...
> > The idea to avoid memory pressure is to reverse the window processing
> > such that the object to delta against is constant for the entire window
> > instead of the current logic where the target object is constant. This
> > way there would be only one index in memory at all time.
>
> Your are right. The first led to the latter unexplored idea.
>
> I expect to be offline most of the day today, and have other
> things I can work on for the next few days anyway, so if you or
> somebody else have an inclination and energy to reverse the
> delta window, I would appreciate that.
I'll probably give it a try.
I'm still reviewing Geert's code right now and found minor things
pertaining to the GIT delta encoding here and there which probably
explain why it doesn't pack the Linux kernel archive yet.
Nicolas
^ permalink raw reply
* Re: get_user_pages ?
From: Nick Piggin @ 2006-04-22 4:09 UTC (permalink / raw)
To: markh; +Cc: dmarkh, linux-kernel
In-Reply-To: <4448D047.8070202@compro.net>
Mark Hounschell wrote:
>>OK, I'd suggest either using vm_insert_page, or converting it all over
>>to a ->nopage handler then.
>>
>
>
> I set the bit back on after get_user_pages and now I seem to be OK.
>
> You've looked at the code some obviously. What is in my future WRT these
> changes being made that you referenced above and the depreciation of
> some of the calls in use. Given my situation, do you foresee anything
> that will keep me from being able to get valid bus addresses for my pte?
Well remap_pfn_range / io_remap_pfn_range is a good option, but it
shouldn't really support get_user_pages so I suspect you are just
lucky there (ie. on some platforms you might not have a struct page
for your bus address, and other times the final put_page will try
to free the page).
If you definitely have struct pages, vm_insert_page is an option,
unless the memory is allocated with dma_alloc_* or similar, in
which case you should probably be using remap_pfn_range.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: [linux-lvm] Another XFS + LVM2 snapshots problems
From: Luca Berra @ 2006-04-22 19:56 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <20060422180104.GD4809@agk.surrey.redhat.com>
On Sat, Apr 22, 2006 at 07:01:04PM +0100, Alasdair G Kergon wrote:
>On Sat, Apr 22, 2006 at 04:13:01PM +0200, Gabriel Barazer wrote:
>> Linux kernel 2.6.16.1
>> LVM & mapper version 2.01.15 (library 1.01.15, driver version 4.5.0)
>
>As you discovered, those versions are not compatible.
>You upgraded your kernel to a recent one: you need to upgrade your
>dm & lvm2 packages to correspond with that kernel. (1.02.* & 2.02.*)
>
sorry,
is there a documented compatibility matrix between dm driver version and
device-mapper library version?
Regards,
L.
--
Luca Berra -- bluca@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
^ permalink raw reply
* Re: [PATCH 2.6.17-rc2 1/2] return class device pointer from tty_register_device()
From: Greg KH @ 2006-04-22 4:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tilman Schmidt, linux-kernel, hjlipp
In-Reply-To: <20060421181429.5ea9d777.akpm@osdl.org>
On Fri, Apr 21, 2006 at 06:14:29PM -0700, Andrew Morton wrote:
> Tilman Schmidt <tilman@imap.cc> wrote:
> >
> > + * Returns a pointer to the class device (or NULL on error).
> > + *
> > * This call is required to be made to register an individual tty device if
> > * the tty driver's flags have the TTY_DRIVER_NO_DEVFS bit set. If that
> > * bit is not set, this function should not be called.
> > */
> > -void tty_register_device(struct tty_driver *driver, unsigned index,
> > - struct device *device)
> > +struct class_device *tty_register_device(struct tty_driver *driver,
> > + unsigned index, struct device *device)
> > {
>
> It would be better to make this return ERR_PTR(-Efoo) on error, rather than
> NULL.
>
> That way, tty_register_device() ends with
>
> - class_device_create(tty_class, NULL, dev, device, "%s", name);
> + return class_device_create(tty_class, NULL, dev, device, "%s", name);
> }
>
> which is neat.
I agree, that would be nicer.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] off-by-1 in kernel/power/main.c
From: dean gaudet @ 2006-04-22 4:05 UTC (permalink / raw)
To: linux-kernel; +Cc: len.brown
there's an off-by-1 in 2.6.16.9 (and 2.6.17-rc2)
kernel/power/main.c:state_store() ... if your kernel just happens to have
some non-zero data at pm_states[PM_SUSPEND_MAX] (i.e. one past the end of
the array) then it'll let you write anything you want to /sys/power/state
and in response the box will enter S5.
i randomly discovered this because i really wanted to put my box into S5
(for wake on lan) and tried "echo off >/sys/power/state" and was quite
happy that the box entered S5... happy until i compiled a different kernel
and this S5 trick stopped working :)
anyhow, this begs the question, what is the correct way to get a box to
shutdown into s5? on a fc4 box i have here it does that happily, but
ubuntu boxes don't seem to go into s5... and i couldn't figure out from
fc4 patches if they'd changed anything in this area. pointers
appreciated.
btw i can whip up a patch making "off" a valid value for /sys/power/state
...
-dean
Signed-off-by: dean gaudet <dean@arctic.org>
--- linux/kernel/power/main.c.orig 2006-03-19 21:53:29.000000000 -0800
+++ linux/kernel/power/main.c 2006-04-21 20:54:12.000000000 -0700
@@ -272,7 +272,7 @@
if (*s && !strncmp(buf, *s, len))
break;
}
- if (*s)
+ if (state < PM_SUSPEND_MAX && *s)
error = enter_state(state);
else
error = -EINVAL;
^ permalink raw reply
* Re: [PATCH] 'make headers_install' kbuild target.
From: Adrian Bunk @ 2006-04-22 13:20 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-kernel, sam
In-Reply-To: <1145710123.11909.241.camel@pmac.infradead.org>
On Sat, Apr 22, 2006 at 01:48:43PM +0100, David Woodhouse wrote:
> On Sat, 2006-04-22 at 14:38 +0200, Adrian Bunk wrote:
> > What was the recommended way for getting userspace header at last
> > year's kernel summit?
>
> It was said that we need _incremental_ changes, and this is an attempt
> to satisfy that request.
>
> > > The important thing is that we all get our editors out and clean up the
> > > _contents_ our own headers, and actually start to _think_ about the
> > > visibility of any new header-file content we introduce. Let's not
> > > concentrate too much on the implementation details of how we actually
> > > get those to userspace.
> >
> > Currently, it's said the kernel headers aren't suitable for userspace.
>
> Indeed they aren't.
>
> > After the cleanups you propose, the kernel headers will be suitable for
> > userspace (the copy steps you propose are not required, distributions
> > could equally start to copy the verbatim headers again).
>
> After the _first_ stage of the cleanups I propose, the export step will
> still be necessary. You'll need to pick those headers which are intended
> to be user-visible, and leave behind those which are not.
>
> If we actually go on to abolish __KERNEL__ and move the public headers
> to a separate directory, you're right -- as I said, one day hopefully
> it'll just be 'cp -a'. But that is not the _first_ stage. We need to do
> this incrementally.
>...
Why can't the splitting happen incrementally?
Assume you have a header include/linux/foo.h:
- Add an #include <kabi/linux/foo.h> at the top.
- Move the part of the contents that is part of the userspace ABI to
include/kabi/linux/foo.h.
When this is done for all headers containing parts of the userspace ABI:
- test the kabi/ headers in userspace
- review all headers under kabi/ since what's there will become a fixed
ABI that can never be changed
- test the kabi/ headers in userspace
- make the ABI headers official
For kernel code, this header splitting should be completely transparent
(and nothing outside include/ should directly include headers under
include/kabi/).
For userspace, this will be one switch from the many different header
packages floating around to the new ABI headers, but it should break
nearly none usespace applications (it will break some abuses, but
that's OK).
> dwmw2
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Problem with 5disk RAID5 array - two drives lost
From: David Greaves @ 2006-04-22 19:54 UTC (permalink / raw)
To: Carlos Carvalho; +Cc: linux-raid, tbostrom
In-Reply-To: <17482.34615.908339.197028@fisica.ufpr.br>
Carlos Carvalho wrote:
> Molle Bestefich (molle.bestefich@gmail.com) wrote on 22 April 2006 05:54:
> >Tim Bostrom wrote:
> >> raid5: Disk failure on hdf1, disabling device.
> >
> >MD doesn't like to find errors when it's rebuilding.
> >It will kick that disk off the array, which will cause MD to return
> >crap (instead of stopping the array and removing the device - I
> >wonder), again causing 'mount' etc. to fail.
> >
> >Quite unfortunate for you, since you have absolutely no redundancy
> >with 4/5 drives, and you really can't afford to have the 4th disk
> >kicked just because there's a bad block on it.
>
> Yes...
>
> As Molle says, you have a chance that it's a driver/cable problem.
> What you can also do is dd the disk to another one and try to rebuild
> the array with the new disk so that you won't get errors during the
> reconstruction. If you get errors during the copy you'll have to
> decide what to do with the bad blocks. Some people prefer to use
> ddrescue instead of dd; I've never tried it.
I've used ddrescue and would *highly* recommend it. Use the GNU version,
not the other one (dd_rescue?)
It handles errors very well indeed and has a good display to show what's
happening.
It seems faster than dd (possibly threaded so streams both drives rather
than read a drive, write a drive)
David
^ permalink raw reply
* (no subject)
From: gkzoeelxh @ 2006-04-22 4:01 UTC (permalink / raw)
^ permalink raw reply
* Re: [v4l-dvb-maintainer] [PATCH] cx25840 driver in 2.6.16 -- adds CX25836 support
From: Hans Verkuil @ 2006-04-22 13:33 UTC (permalink / raw)
To: v4l-dvb-maintainer; +Cc: Scott Alfter, linux-kernel
In-Reply-To: <44496BDB.2090503@ssai.us>
Hi Scott,
Thank you for your patch! Nice work. I've integrated it into the cx25840
driver (with some tweaks).
Please check my mercurial tree at
http://www.linuxtv.org/hg/~hverkuil/cx25836 to see if my changes did
not break anything for you. For the most part the changes dealt with
preventing the cx25836/7 from touching cx25840-specific registers.
Please let me know if it is OK (or not) so that I can get it merged into
the main v4l-dvb repository. I also need a Signed-off-by line from you
(see http://www.linuxtv.org/v4lwiki/index.php/How_to_submit_patches)
before I can officially merge the code.
As I am also maintainer of ivtv I'm looking forward to your ivtv
patches. Please contact me when you are seriously starting work on
ivtv: work is in progress to merge ivtv into the kernel, and if you can
let me know in advance what sort of changes you need, then I can warn
you if the changes required for the kernel merge conflict with what you
need.
And for the record, AFAIK there is no driver for the TI TLV320AIC23B.
Regards,
Hans Verkuil
On Saturday 22 April 2006 01:33, Scott Alfter wrote:
> My company is working on a quad CX23416-based MPEG-2 compressor card.
> The hardware guy decided to use CX25836s to capture video, instead
> of the CX25840 that most everybody else uses. The main difference
> between the '836 and '840 is that the '840 captures both audio and
> video, while the '836 captures video only. The video-related
> commands between the two are mostly the same, but the chip needs a
> different initialization sequence and it'd probably be a good idea to
> keep audio-related commands away from it. It also doesn't need to
> have audio firmware loaded.
>
> This is my first attempt at a Linux kernel patch. I've tested it
> with NTSC input at 352x480 and 720x480, and it works well. I'm
> currently using it with a hacked version of ivtv 0.6.1. Those
> changes will eventually need to be released here as well, but the
> hardware design is still in a bit of flux. I also need to put
> together a driver for the audio capture chips used on the card, the
> TI TLV320AIC23B; there appears to be no driver in the kernel for that
> chip.
>
> The patch is attached; a test mailing indicated that Thunderbird
> attaches patches inline instead of encoded. The patch is also
> available from this URL:
>
> http://alfter.us/files/linux-2.6.16-cx25836.patch
>
> Scott Alfter
> salfter@ssai.us
^ permalink raw reply
* Re: unix socket connection tracking
From: Jan Engelhardt @ 2006-04-22 13:34 UTC (permalink / raw)
To: Lukasz Stelmach; +Cc: LKML
In-Reply-To: <444A1B86.1060701@poczta.fm>
>>>>> I feel dumb as never so please enlight me. Is ther a way to find out which
>>>>> process is on the other end of a unix socket pointed by a specified fd in a process.
>>>> getpeer*()
>>> getpeername(2) (that is the only man page I've got)
>>>
>> Exactly. And if you do the same on another socket from another process, you
>> can match up what sockets are connected.
>> You always need to examine more than one process. (Unless the process talks
>> to itself.)
>
>But how can I examine a file-descriptor (socket) from within other process. Like
>this.
>
>A [fd:4]------[fd:6] B -+
>| |
>`---[ptrace] C [ptrace]-'
>
7315 pts/9 S+ 0:00 | \_ ssh jengelh@lo
3698 ? Ss 0:00 /usr/sbin/sshd -o PidFile=/var/run/sshd.init.pid
7316 ? Ss 0:00 \_ sshd: jengelh [priv]
7320 ? S 0:00 \_ sshd: jengelh@pts/10
7321 pts/10 Ss 0:00 \_ -bash
Just look at all processes and logically connect them:
15:32 shanghai:/D/home/jengelh # l /proc/7315/fd
total 7
dr-x------ 2 root root 0 Apr 22 15:32 .
dr-xr-xr-x 5 root root 0 Apr 22 15:32 ..
lrwx------ 1 root root 64 Apr 22 15:32 0 -> /dev/pts/9
lrwx------ 1 root root 64 Apr 22 15:32 1 -> /dev/pts/9
lrwx------ 1 root root 64 Apr 22 15:32 2 -> /dev/pts/9
lrwx------ 1 root root 64 Apr 22 15:32 3 -> socket:[85928]
lrwx------ 1 root root 64 Apr 22 15:32 4 -> /dev/pts/9
lrwx------ 1 root root 64 Apr 22 15:32 5 -> /dev/pts/9
lrwx------ 1 root root 64 Apr 22 15:32 6 -> /dev/pts/9
15:33 shanghai:/D/home/jengelh # l /proc/7316/fd/
total 6
dr-x------ 2 root root 0 Apr 22 15:32 .
dr-xr-xr-x 5 root root 0 Apr 22 15:32 ..
lrwx------ 1 root root 64 Apr 22 15:32 0 -> /dev/null
lrwx------ 1 root root 64 Apr 22 15:33 1 -> /dev/null
lrwx------ 1 root root 64 Apr 22 15:33 2 -> /dev/null
lrwx------ 1 root root 64 Apr 22 15:33 3 -> socket:[85929]
lrwx------ 1 root root 64 Apr 22 15:33 4 -> /dev/ptmx
lrwx------ 1 root root 64 Apr 22 15:33 5 -> socket:[85959]
No need for ptrace. No need for getpeername() either, but it's useful to
get the real addresses of sockets.
Jan Engelhardt
--
^ permalink raw reply
* Re: [PATCH] 'make headers_install' kbuild target.
From: David Woodhouse @ 2006-04-22 13:36 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel, sam
In-Reply-To: <20060422132032.GB5010@stusta.de>
On Sat, 2006-04-22 at 15:20 +0200, Adrian Bunk wrote:
> Why can't the splitting happen incrementally?
It can, and has already started that way. There's no reason why the
'make headers_export' mechanism can't work with that -- it already does,
because it exports the include/mtd directory and nothing from
include/linux/mtd -- as I said, ideally the mechanism ends up being just
'cp -a' on certain directories. And then it can be abolished. We've got
a long way to go before we get there, though.
> Assume you have a header include/linux/foo.h:
> - Add an #include <kabi/linux/foo.h> at the top.
> - Move the part of the contents that is part of the userspace ABI to
> include/kabi/linux/foo.h.
Absolutely. That's what I've done with MTD headers already, although the
directory names are different. The directory names don't _matter_
either, because important part was that the files themselves are cleaned
up.
Linus isn't keen on splitting it into a new directory, and I don't want
to start off by demanding that. As I said, the important part of the
above is the bit where one of us goes to the file with an editor and
identifies the public parts vs. the private parts, then splits them up
-- possibly with #ifdef __KERNEL__, but _preferably_ into separate
files. And it doesn't _matter_ which directories we put those files
into, for now. I don't want to talk about it _yet_ because it's just
taking attention away from the real problem.
The more we screw around with such minutiae, the less likely we are to
get traction with Linus -- despite the fact that almost everyone who's
expressed an opinion is _agreeing_ with you about where we want to end
up.
We need to keep it simple and unintrusive to start with. Concentrate on
the _contents_ and then we can deal with the less important details
later.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] 'make headers_install' kbuild target.
From: David Woodhouse @ 2006-04-22 12:48 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel, sam
In-Reply-To: <20060422123835.GA5010@stusta.de>
On Sat, 2006-04-22 at 14:38 +0200, Adrian Bunk wrote:
> What was the recommended way for getting userspace header at last
> year's kernel summit?
It was said that we need _incremental_ changes, and this is an attempt
to satisfy that request.
> > The important thing is that we all get our editors out and clean up the
> > _contents_ our own headers, and actually start to _think_ about the
> > visibility of any new header-file content we introduce. Let's not
> > concentrate too much on the implementation details of how we actually
> > get those to userspace.
>
> Currently, it's said the kernel headers aren't suitable for userspace.
Indeed they aren't.
> After the cleanups you propose, the kernel headers will be suitable for
> userspace (the copy steps you propose are not required, distributions
> could equally start to copy the verbatim headers again).
After the _first_ stage of the cleanups I propose, the export step will
still be necessary. You'll need to pick those headers which are intended
to be user-visible, and leave behind those which are not.
If we actually go on to abolish __KERNEL__ and move the public headers
to a separate directory, you're right -- as I said, one day hopefully
it'll just be 'cp -a'. But that is not the _first_ stage. We need to do
this incrementally.
> If everyone is working in a different direction, this is only wasting
> work.
The stated plan is to start with a simple export mechanism which lets us
see the mess we have at the moment and work on the _real_ problem -- the
actual contents of the headers. Then to proceed towards the goal you
stated, which is what we wanted all along.
Who would be working in a different direction?
--
dwmw2
^ permalink raw reply
* Re: Problem with 5disk RAID5 array - two drives lost
From: Molle Bestefich @ 2006-04-22 19:52 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <17482.34615.908339.197028@fisica.ufpr.br>
Carlos Carvalho wrote:
> What you can also do is dd the disk to another one and try to rebuild
> the array with the new disk so that you won't get errors during the
> reconstruction.
Right, neat hack.
> Some people prefer to use ddrescue instead of dd; I've never tried it.
I can definitely recommend dd_rescue/dd-rescue/ddrescue.
Much better than dd for this kind of thing.
Very delicious. Yummy yummy.
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: Ingo Oeser @ 2006-04-22 13:29 UTC (permalink / raw)
To: Jörn Engel
Cc: Ingo Oeser, David S. Miller, simlo, linux-kernel, mingo, netdev
In-Reply-To: <20060422114846.GA6629@wohnheim.fh-wedel.de>
Hi Jörn,
On Saturday, 22. April 2006 13:48, Jörn Engel wrote:
> Unless I completely misunderstand something, one of the main points of
> the netchannels if to have *zero* fields written to by both producer
> and consumer.
Hmm, for me the main point was to keep the complete processing
of a single packet within one CPU/Core where this is a non-issue.
> Receiving and sending a lot can be expected to be the
> common case, so taking a performance hit in this case is hardly a good
> idea.
There is no hit. If you receive/send in bursts you can simply aggregate
them until a certain queueing threshold.
The queue design outlined can split the queueing in reserve and commit stages,
where the producer can be told how much in can produce and the consumer is
told how much it can consume.
Within their areas the producer and consumer can freely move around.
So this is not exactly a queue, but a dynamic double buffer :-)
So maybe doing queueing with the classic head/tail variant is better here,
but the other variant might replace it without problems and allows
for some nice improvements.
Regards
Ingo Oeser
^ permalink raw reply
* Re: RFC: New diff-delta.c implementation
From: Geert Bosch @ 2006-04-22 13:39 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0604220846040.2215@localhost.localdomain>
On Apr 22, 2006, at 08:51, Nicolas Pitre wrote:
> First, pack-objects tries to find the best object combinations
> producing the smallest delta. Then there is a second pass
> where the best delta are actually written out. When that
> message appears that means the delta size for the same object
> pair does not match between those two passes.
OK, thanks for that info. There are very few comments in the
code, or specs of either the file format used, or
for function arguments. I'll look a the code again with this
info.
What is the exact role of the max_size parameter that is
passed to diff_delta? I took it to mean return 0 if
the size of the delta would be bigger than max_size and
max_size is nonzero.
I only set *delta_size when returning a nonzero delta.
-Geert
^ permalink raw reply
* Re: Linux 2.6.17-rc2
From: Alistair John Strachan @ 2006-04-22 13:21 UTC (permalink / raw)
To: Andi Kleen; +Cc: Linus Torvalds, Linux Kernel Mailing List, meissner
In-Reply-To: <200604220307.17383.ak@suse.de>
On Saturday 22 April 2006 02:07, Andi Kleen wrote:
[snip]
> They probably forget to set PROT_EXEC in either mprotect or mmap somewhere.
> You can check in /proc/*/maps which mapping contains the address it is
> faulting on and then try to find where it is allocated or mprotect'ed.
Turned out this was exactly what the problem was. Wine attempts to match
Windows as far as read/write/execute mappings go, and war3.exe tried to
execute memory in a section with "MEM_EXECUTE" not set.
I'm surprised the program works on Windows with DEP/NX enabled, but apparently
it does. There's a patch floating around on the Wine mailing list which adds
a workaround for this problem:
http://www.winehq.org/pipermail/wine-devel/2006-April/046935.html
Many thanks to Marcus Meissner for debugging it.
--
Cheers,
Alistair.
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply
* Re: RFC: New diff-delta.c implementation
From: Nicolas Pitre @ 2006-04-22 12:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Geert Bosch, Git Mailing List
In-Reply-To: <7v7j5hkglq.fsf@assigned-by-dhcp.cox.net>
On Sat, 22 Apr 2006, Junio C Hamano wrote:
> Geert Bosch <bosch@adacore.com> writes:
>
> > BTW. It's a shame that we don't reuse the index when comparing one
> > source
> > against multiple targets. Creating the index takes about 70% of
> > the time.
>
> I think we tried that with Nico/Davide's delta already, and IIRC
> we had mixed results.
Well, actually I was measuring a 10% speed improvement with a quick and
naive (not memory efficient) approach for pack-objects with the current
algorithm.
> It really depends on how big an index for a source is. Keep in
> mind that we keep --window (default=10) of the source text
> in-core, and you are suggesting to keep index in-core as well,
> so we need to take memory pressure into account.
The idea to avoid memory pressure is to reverse the window processing
such that the object to delta against is constant for the entire window
instead of the current logic where the target object is constant. This
way there would be only one index in memory at all time.
Nicolas
^ permalink raw reply
* Re: qla2xxx lock ordering question
From: Arjan van de Ven @ 2006-04-22 13:41 UTC (permalink / raw)
To: Andrew Vasquez; +Cc: mingo, linux-scsi
In-Reply-To: <20060420234606.GO8514@andrew-vasquezs-powerbook-g4-15.local>
On Thu, 2006-04-20 at 16:46 -0700, Andrew Vasquez wrote:
> On Wed, 19 Apr 2006, Arjan van de Ven wrote:
>
> > a question about qla2xxx lock ordering since it trips up with Ingo's
> > lock depenceny tool:
> >
> > in qla2x00_mailbox_command() the code first grabs the mbx_reg_lock lock,
> > then the hardware_lock. So far so good. But then...
> > it drops the mbx_reg_lock, does stuff, and regrabs the mbx_reg_lock
> > lock, while keeping the hardware_lock held!
> >
> > This appears to be an AB-BA deadlock risk since for the second part you
> > are taking the locks in the wrong order... or am I missing something
> > here?
>
> Actually the code is a bit convoluted, but I believe we are OK. There
> are two scenarios we need to consider:
I actually don't believe so based on what the lockdep checker sees; it
really really sees a third behavior..
^ permalink raw reply
* Re: RFC: New diff-delta.c implementation
From: Nicolas Pitre @ 2006-04-22 12:51 UTC (permalink / raw)
To: Geert Bosch; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <6794F5B2-A277-4CD9-9BA8-509F86378E68@adacore.com>
On Sat, 22 Apr 2006, Geert Bosch wrote:
> BTW, after applying the obvious fixes, I get the following
> message:
> potomac%./git-pack-objects --no-reuse-delta --stdout <lst
> Generating pack...
> Done counting 16984 objects.
> Deltifying 16984 objects.
> 100% (16984/16984) done
> fatal: delta size changed
>
> Is this expected now I have a different algorithm?
It should not.
First, pack-objects tries to find the best object combinations producing
the smallest delta. Then there is a second pass where the best delta
are actually written out. When that message appears that means the
delta size for the same object pair does not match between those two
passes.
Nicolas
^ permalink raw reply
* Re: [PATCH] Shrink rbtree
From: David Woodhouse @ 2006-04-22 13:38 UTC (permalink / raw)
To: Ingo Oeser; +Cc: Andrew Morton, andrea, linux-kernel
In-Reply-To: <200604221429.27858.ioe-lkml@rameria.de>
On Sat, 2006-04-22 at 14:29 +0200, Ingo Oeser wrote:
> Yes, but please make it a common helper, since there is a real need
> for it and code has to agree on the dirty hacks it uses :-)
Is there a real need for it? It's all just paranoid debugging checks,
isn't it? If there's a _real_ need for marking an object as being
inactive because it can be reached through some means other than the
rbtree, then that arguably lives in the higher-level object itself, not
its rb_node.
I'm reluctant to 'bless' this practice, because we'll then get asked to
set it to 'inactive' every time we take a node off the tree, to have a
BUG_ON() which checks it in certain places, etc.... it's mostly
pointless AFAICT.
--
dwmw2
^ permalink raw reply
* Re: data recovery on raid5
From: Molle Bestefich @ 2006-04-22 19:48 UTC (permalink / raw)
To: Jonathan; +Cc: linux-raid
In-Reply-To: <444A7C99.80006@abhost.net>
Jonathan wrote:
> # mdadm -C /dev/md0 -n 4 -l 5 missing /dev/etherd/e0.[023]
I think you should have tried "mdadm --assemble --force" first, as I
proposed earlier.
By doing the above, you have effectively replaced your version 0.9.0
superblocks with version 0.9.2. I don't know if version 0.9.2
superblocks are larger than 0.9.0, Neil hasn't responded to that yet.
Potentially hazardous, who knows.
Anyway.
This is from your old superblock as described by Sam Hopkins:
> /dev/etherd/<blah>:
> Chunk Size : 32K
This is from what you've just posted:
> /dev/etherd/<blah>:
> Chunk Size : 64K
If I were you, I'd recreate your superblocks now, but with the correct
chunk size (use -c).
> We'll be happy to pay you for your services.
I'll be modest and charge you a penny per byte of data recovered, ho hum.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.