Hello,
according to http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html
[1.] One line summary of the problem:
KB->KiB, MB -> MiB, ... (IEC 60027-2 Letter symbols to be used in electrical
technology – Part 2)
[2.] Full description of the problem/report:
kernel: 2.6.19
linux: gentoo
aft
Richard Knutsson wrote:
Comment out unused constants in include/linux/sysctl.h.
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
NAK as all hell.
This file exports an interface to userspace, and thus should be
maintained indefinitely.
-hpa
-
To unsubscribe from this list: send t
Hello,
I did find this dmesg for the kernel 2.6.20-rc5
Linux version 2.6.20-rc5-Typhoon ([EMAIL PROTECTED]) (gcc version 4.1.1
20061011 (Red Hat 4.1.1-30)) #1 SMP Sat Jan 20 15:00:20 IST 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: size
Alex Dubov wrote:
>
> Indeed, I may be out of sync on this. Simply, I have this rather ugly hack in
> the tifm_sd remove
> code which I was forced to add because of the issue in question.
> I'll do some tests with newer kernels then.
>
>
Please do. And if you see a problem, please try to figur
> [1.] One line summary of the problem:
> KB->KiB, MB -> MiB, ... (IEC 60027-2 Letter symbols to be used in
> electrical
> technology – Part 2)
> Should be everywere KiB, MiB, GiB, ... according to IEC 60027-2
Bytes are not an SI unit. A "megabyte" doesn't have to be a million
bytes
Hi there,
We've a kernel (n/w) module, which sits over ethernet. Whenever a pkt
is received (in softirq), after doing some minimal processing,
wake_up() is called to wake up another kernel thread which does rest
(bulk) of the processing.
We notice that this wake_up() call is sometimes taking as
H. Peter Anvin wrote:
Richard Knutsson wrote:
Comment out unused constants in include/linux/sysctl.h.
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
NAK as all hell.
This file exports an interface to userspace, and thus should be
maintained indefinitely.
Oh, then I misunderstood Eric W
My .config is attached, please let me know if any other information is
needed and please CC (lkml) as I am not on the list, thanks!
Running Kernel 2.6.19.2 on a MD RAID5 volume. Copying files over Samba to
the RAID5 running XFS.
Any idea what happened here?
[473795.214705] BUG: unable to hand
On Sat, 20 Jan 2007, Justin Piszcz wrote:
> My .config is attached, please let me know if any other information is
> needed and please CC (lkml) as I am not on the list, thanks!
>
> Running Kernel 2.6.19.2 on a MD RAID5 volume. Copying files over Samba to
> the RAID5 running XFS.
>
> Any id
Function change mem limit to USER_DS before possible modprobe, but never
restore
it again. Why does this happend, is it just forgotten? As i understand currently
this not cause actual problems, but any one may call access_ok() after
search_binary_handler() and will be really surprised.
Signed-
The BINFMT_IRIX code:
- has been marked as BROKEN for more than two years years and
- is still marked as BROKEN.
Code that has been marked as BROKEN for such a long time seem to be
unlikely to be revived in the forseeable future.
But if anyone wants to ever revive this driver, the code is still
On Sat, Jan 20, 2007 at 03:01:35PM +0100, Adrian Bunk wrote:
> The BINFMT_IRIX code:
> - has been marked as BROKEN for more than two years years and
> - is still marked as BROKEN.
>
> Code that has been marked as BROKEN for such a long time seem to be
> unlikely to be revived in the forseeable f
On Sat, 2007-01-20 at 15:54 +0530, kalash nainwal wrote:
> Hi there,
>
> We've a kernel (n/w) module, which sits over ethernet. Whenever a pkt
> is received (in softirq), after doing some minimal processing,
> wake_up() is called to wake up another kernel thread which does rest
> (bulk) of the pro
Hi all,
On Sat, 6 Jan 2007, Chris Wilson wrote:
Forwarded to lkml as suggested by Alan Stern. Please copy any replies to me,
as I'm not on the list (too much traffic, sorry!).
Ping? It's been two weeks.
Cheers, Chris.
On Fri, 5 Jan 2007, Alan Stern wrote:
On Sat, 6 Jan 2007, Chris Wilson
This patch removes the dropping of ADDR_NO_RANDOMIZE upon execution of setuid
binaries.
Why? The answer consists of two parts:
Firstly, there are valid applications which need an unadulterated memory map.
Some of those which do their memory management, like lisp systems (like SBCL).
They try to
Hi,
I went from 2.6.19+sata_nv-adma-ncq-v7.patch, with no problems and adama
enabled, to 2.6.20-rc5, which gave me problems almost instantly.
I just thought that it might be interesting to know that it DID work
nicely.
CC since i'm not on the ml
--
Ian Kumlien -- http://pomac.netswarm.net
s
> "Condor" <[EMAIL PROTECTED]> writes:
>
>>>From debug log:
>> Jan 16 14:56:13 elrond kernel: usb-storage: device found at 4
>> Jan 16 14:56:13 elrond kernel: usb-storage: waiting for device to settle
>> before scanning
>> Jan 16 14:56:18 elrond kernel: sda: Mode Sense: 00 00 00 00
>> Jan 16 14:56
On Fri, 2007-01-19 at 20:13 +0100, Guennadi Liakhovetski wrote:
> > +static u32 clockevent_mode = 0;
> > +
> > +static void pxa_set_next_event(unsigned long evt,
> > + struct clock_event_device *unused)
> > +{
> > + OSMR0 = OSCR + evt;
> > +}
>
> This doesn't work for
Bill Davidsen <[EMAIL PROTECTED]> writes:
Alessandro Di Marco wrote:
> Hi all,
>
> this is a new 2.6.20 module implementing a user inactivity trigger.
Basically
> it acts as an event sniffer, issuing an ACPI event when no user activity is
> detected for more than a certain amoun
I'm forwarding this post by the author of a great little program for
digital amateur radio on Linux, because I'm curious whether or not the
problem he is seeing can be resolved outside the kernel.
All comments welcome on/off list.
Thanks,
Joe Barr
K1GPL
--
It's a strange world when proprieta
On Fri, 19 Jan 2007, Thomas Gleixner wrote:
> On Fri, 2007-01-19 at 20:13 +0100, Guennadi Liakhovetski wrote:
> > > +static u32 clockevent_mode = 0;
> > > +
> > > +static void pxa_set_next_event(unsigned long evt,
> > > + struct clock_event_device *unused)
> > > +{
> > >
the sysfs interface from the rtc framework seems to incorrectly label the add
function with __devinit ... the proc and dev interfaces do not have this
label on their add functions
ive been trying to develop a rtc module and it kept crashing ... after
debugging it, i'm pretty sure ive traced it
At Sat, 20 Jan 2007 17:37:22 +0300,
Samium Gromoff wrote:
[snip]
> So, here we have a buffer-overflow protection technique, which does not
> actually protect against buffer overflows[1], breaking valid applications.
>
> I suggest getting rid of it.
i botched it slightly:
--- linux/include/linux/
On Sat, 2007-01-20 at 17:08 +0100, Guennadi Liakhovetski wrote:
> > static int hpet_next_event(unsigned long delta,
> >struct clock_event_device *evt)
> > {
> > unsigned long cnt;
> >
> > cnt = hpet_readl(HPET_COUNTER);
> > cnt += delta;
> >
On Thursday 11 January 2007 16:50, Linus Torvalds wrote:
>
> On Thu, 11 Jan 2007, Nick Piggin wrote:
> >
> > Speaking of which, why did we obsolete raw devices? And/or why not just
> > go with a minimal O_DIRECT on block device support? Not a rhetorical
> > question -- I wasn't involved in the di
On Thursday 11 January 2007 18:13, Michael Tokarev wrote:
> example, which isn't quite possible now from userspace. But as long as
> O_DIRECT actually writes data before returning from write() call (as it
> seems to be the case at least with a normal filesystem on a real block
> device - I don't t
On Sunday 14 January 2007 10:11, Nate Diller wrote:
> On 1/12/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Most applications don't get the kind of performance analysis that
> Digeo was doing, and even then, it's rather lucky that we caught that.
> So I personally think it'd be best for libc or s
On 1/19/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
Apology surely accepted, it's a confusing area (inevitably: in a driver
for mem, the distinction between addresses and offsets become blurred).
But please note, the worst of it was, that your patch comment gave no
hint that you were knowingly
Hi all,
I own a Sony Vaio VGN-FS285B and disk performance to say at least is very very
slow. Writing 1 GB data makes the laptop unresponsive. Here is some data
identifying the drive. Hope someone can tell me how to debug and find out
whats the problem.
FWIW since 2.6.16 the problem is same and
Hi,
On Fri, Jan 19, 2007 at 03:37:34PM -0600, Joe Barr wrote:
>
> I'm forwarding this post by the author of a great little program for
> digital amateur radio on Linux, because I'm curious whether or not the
> problem he is seeing can be resolved outside the kernel.
At least, I see one wrong cla
Hi,
On Sat, Jan 20, 2007 at 07:20:53PM +0200, Ismail Dönmez wrote:
> Hi all,
>
> I own a Sony Vaio VGN-FS285B and disk performance to say at least is very
> very
> slow. Writing 1 GB data makes the laptop unresponsive. Here is some data
> identifying the drive. Hope someone can tell me how to
20 Oca 2007 Cts 19:45 tarihinde şunları yazmıştınız:
[...]
> > vaio cartman # hdparm -tT /dev/hda
> >
> > /dev/hda:
> > Timing cached reads: 1576 MB in 2.00 seconds = 788.18 MB/sec
> > Timing buffered disk reads: 74 MB in 3.01 seconds = 24.55 MB/sec
> >
> >
> > [~]> time dd if=/dev/zero of
On Sat, Jan 20, 2007 at 07:52:53PM +0200, Ismail Dönmez wrote:
> 20 Oca 2007 Cts 19:45 tarihinde ??unlar?? yazmt??n??z:
> [...]
> > > vaio cartman # hdparm -tT /dev/hda
> > >
> > > /dev/hda:
> > > Timing cached reads: 1576 MB in 2.00 seconds = 788.18 MB/sec
> > > Timing buffered disk reads
20 Oca 2007 Cts 20:03 tarihinde şunları yazmıştınız:
> On Sat, Jan 20, 2007 at 07:52:53PM +0200, Ismail Dönmez wrote:
> > 20 Oca 2007 Cts 19:45 tarihinde ??unlar?? yazmt??n??z:
> > [...]
> >
> > > > vaio cartman # hdparm -tT /dev/hda
> > > >
> > > > /dev/hda:
> > > > Timing cached reads: 157
Hello,
On 1/20/07, David Schwartz <[EMAIL PROTECTED]> wrote:
> [1.] One line summary of the problem:
> KB->KiB, MB -> MiB, ... (IEC 60027-2 Letter symbols to be used in
> electrical
> technology – Part 2)
> Should be everywere KiB, MiB, GiB, ... according to IEC 60027-2
Bytes are not a
hmm, code line too long. please ignore the previous patch. here is the one
with correct length of code line.
Thanks
Nam
This is a patch for ehca_irq.c that fixes an unproper use of spin_unlock
in irq handler.
Signed-off-by Hoang-Nam Nguyen <[EMAIL PROTECTED]>
---
ehca_irq.c |4 +++-
1 fi
Remove the last (and commented out) invocation of the obsolete
smp_commence() call.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/init/main.c b/init/main.c
index 8b4a7d7..4e88bdd 100644
--- a/init/main.c
+++ b/init/main.c
@@ -395,11 +395,6 @@ static void __init smp_init
On Saturday, 20. January 2007 03:41, Robert Hancock wrote:
> Alistair John Strachan wrote:
> > On Tuesday 16 January 2007 01:53, Jeff Garzik wrote:
> >> Robert Hancock wrote:
> >>> I'll try your stress test when I get a chance, but I doubt I'll run
> >>> into the same problem and I haven't seen any
Hello everyone,
I'm writing a driver for an USB device that has one configuration with
several interfacies and one of them is a HID interface. So when I check
this interface whether it's claimed (usb_interface_claimed), I find out
that it is, and it's claimed by the HID driver. So here is the
que
Hello all,
There's still a bug in the new TCP-MD5 feature.
On x86_64, the hash function is fed wrong TCP payload content.
The same kernel, same conf (except arch -> x86) on an Athlon
doesn't have the problem. Kernel is a vanilla 2.6.20-rc5.
I put debugging printk()s into tcp_v4_do_calc_md5_hash(
(cc: list trimmed and thread moved to linux-pci)
I have a PCI-E e1000 card that does not see interrupts on 2.6.20-rc5
unless CONFIG_PCI_MSI is disabled. An e1000 maintainer indicated that
the PHY state is correct, it's just that the interrupt is not getting
thru to the kernel. Interestingly, o
Adam Kropelin wrote:
I've attached the contents dmesg, 'lspci -vvv', and 'cat
/proc/interrupts' from 2.6.20-rc5.
Actually attached this time.
--Adam
proc-irq-2.6.20-rc5
Description: Binary data
dmesg-2.6.20-rc5
Description: Binary data
lspci-2.6.20-rc5
Description: Binary data
On 1/20/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> > >
It is not expected to increase write performance, but it should help
you do something else during that time, or also give more responsiveness
to Ctrl-C. It is possible that you have fast and slow RAM, or that your
video card uses shared
Pls treat this patch as Patch 2/2 where Patch 1/2 is
http://lkml.org/lkml/2007/1/19/159
---
From: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
Explicitly set pgid and sid of init process to 1.
Signed-off-by: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
Cc: Cedric Le Goater <[EMAIL PROTECTED]>
Cc
Sunil Naidu wrote:
On 1/20/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
It is not expected to increase write performance, but it should help
you do something else during that time, or also give more responsiveness
to Ctrl-C. It is possible that you have fast and slow RAM, or that your
video
Ian Kumlien wrote:
Hi,
I went from 2.6.19+sata_nv-adma-ncq-v7.patch, with no problems and adama
enabled, to 2.6.20-rc5, which gave me problems almost instantly.
I just thought that it might be interesting to know that it DID work
nicely.
CC since i'm not on the ml
(I'm ccing more of the peo
On Sun, Jan 21, 2007 at 01:14:41AM +0530, Sunil Naidu wrote:
> On 1/20/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> >> > >
> >
> >It is not expected to increase write performance, but it should help
> >you do something else during that time, or also give more responsiveness
> >to Ctrl-C. It is po
when there is no longer anything to take away.
-- Antoine de Saint-Exupery
Date: Sat, 20 Jan 2007 20:58:17 +0100
In-Reply-To: <[EMAIL PROTECTED]> (Ken Moffat's message of
"Thu, 18 Jan 2007 00:18:38 +")
Message-ID: <[EMAIL PROTECTED]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/
On Sat, Jan 20, 2007 at 02:56:20PM -0500, Stephen Clark wrote:
> Sunil Naidu wrote:
>
> >On 1/20/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> >
> >
> >>It is not expected to increase write performance, but it should help
> >>you do something else during that time, or also give more responsivene
On Sat, 20 Jan 2007, Ismail Dönmez wrote:
> 20 Oca 2007 Cts 19:45 tarihinde şunları yazmıştınız:
> [...]
> > > vaio cartman # hdparm -tT /dev/hda
> > >
> > > /dev/hda:
> > > Timing cached reads: 1576 MB in 2.00 seconds = 788.18 MB/sec
> > > Timing buffered disk reads: 74 MB in 3.01 seconds
20 Oca 2007 Cts 22:05 tarihinde, Willy Tarreau şunları yazmıştı:
> On Sun, Jan 21, 2007 at 01:14:41AM +0530, Sunil Naidu wrote:
> > On 1/20/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
[...]
> It should not have changed the throughput at all if the
> hardware was not a bit strange (well, it's a VA
20 Oca 2007 Cts 22:10 tarihinde, Tim Schmielau şunları yazmıştı:
[...]
>
> Note that these dd "benchmarks" are completely bogus, because the data=20
> doesn't actually get written to disk in that time. For some enlightening=20
> data, try
>
> time dd if=3D/dev/zero of=3D/tmp/1GB bs=3D1M count=3D
On Sat, Jan 20, 2007 at 10:16:15PM +0200, Ismail Dönmez wrote:
> 20 Oca 2007 Cts 22:10 tarihinde, Tim Schmielau ??unlar?? yazmt??:
> [...]
> >
> > Note that these dd "benchmarks" are completely bogus, because the data=20
> > doesn't actually get written to disk in that time. For some enlighten
Hello.
Bartlomiej Zolnierkiewicz wrote:
I've looked thru the code, and found more issues with the PIO fallback
there. Will try to cook up patches for at least some drivers...
Great, if possible please base them on top of the IDE tree...
Erm, I had doubts about it (having in mind that a
Hi,
Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
>
> I've looked thru the code, and found more issues with the PIO fallback
> there. Will try to cook up patches for at least some drivers...
>
Great, if possible please base them on top of the IDE tree...
>
>>> Erm,
Hello.
Bartlomiej Zolnierkiewicz wrote:
The other advantage of doing cleanups is that code becomes cleaner/simpler
which matters a lot for this codebase, i.e. ide-dma-off-void.patch exposed
(yet to be fixed) bug in set_using_dma() (->ide_dma_off_quietly always returns
0 which is passed by ->ide
Paul Menage wrote:
On 1/11/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
to 0. To walk the hierarchy, I have no root now since I do not have
any task context. I was wondering if exporting the rootnode or providing
a function to export the rootnode of the mounter hierarchy will make
programming eas
Perhaps its time to back to a stable (2.6.17.13 kernel)?
Anyway, when I run a cp 18gb_file 18gb_file.2 on a dual raptor sw raid1
partition, the OOM killer goes into effect and kills almost all my
processes.
Completely 100% reproducible.
Does 2.6.19.2 have some of memory allocation bug as well?
The FB_S3TRIO driver:
- has been marked as BROKEN for more than two years and
- is still marked as BROKEN.
Drivers that had been marked as BROKEN for such a long time seem to be
unlikely to be revived in the forseeable future.
But if anyone wants to ever revive this driver, the code is still
pres
On Sat, 20 Jan 2007, Ismail Dönmez wrote:
> 20 Oca 2007 Cts 22:10 tarihinde, Tim Schmielau şunları yazmıştı:
> >
> > Note that these dd "benchmarks" are completely bogus, because the data=20
> > doesn't actually get written to disk in that time. For some enlightening=20
> > data, try
> >
> > ti
Hi Tim,
On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote:
> On Sat, 20 Jan 2007, Ismail Dönmez wrote:
>
> > 20 Oca 2007 Cts 19:45 tarihinde ??unlar?? yazmt??n??z:
> > [...]
> > > > vaio cartman # hdparm -tT /dev/hda
> > > >
> > > > /dev/hda:
> > > > Timing cached reads: 1576 M
On Sat, 20 Jan 2007, Willy Tarreau wrote:
> Anyway, in your situation with a very small buffer, this should not
> change by more than half a second or so.
Well, his buffer is not small. He has half a GB of RAM, so when
writing 1 GB the buffer would roughly double the dd speed, exactly as he
ha
On Sat, Jan 20, 2007 at 09:28:57PM +0100, Tim Schmielau wrote:
> On Sat, 20 Jan 2007, Willy Tarreau wrote:
>
> > Anyway, in your situation with a very small buffer, this should not
> > change by more than half a second or so.
>
> Well, his buffer is not small. He has half a GB of RAM, so when
>
On Sat, 20 Jan 2007, Willy Tarreau wrote:
> On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote:
> >
> > Note that these dd "benchmarks" are completely bogus, because the data
> > doesn't actually get written to disk in that time. For some enlightening
> > data, try
> >
> > time dd
fixes trailing whitespace and spaces before tab indents in 2.6.20-rc5-rt7 as
reported with: git-apply --whitespace=error-all
---
arch/arm/mach-omap1/time.c|2 +-
arch/i386/kernel/entry.S |2 +-
arch/i386/kernel/reboot.c |2 +-
arch/ia64/Kconfig
Denis Vlasenko wrote:
> On Thursday 11 January 2007 18:13, Michael Tokarev wrote:
>> example, which isn't quite possible now from userspace. But as long as
>> O_DIRECT actually writes data before returning from write() call (as it
>> seems to be the case at least with a normal filesystem on a real
On 1/21/07, Tim Schmielau <[EMAIL PROTECTED]> wrote:
Note that these dd "benchmarks" are completely bogus, because the data
doesn't actually get written to disk in that time. For some enlightening
data, try
time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; time sync
The dd returns as soon a
On Sat, Jan 20, 2007 at 09:39:25PM +0100, Tim Schmielau wrote:
> On Sat, 20 Jan 2007, Willy Tarreau wrote:
> > On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote:
> > >
> > > Note that these dd "benchmarks" are completely bogus, because the data
> > > doesn't actually get written to di
On Sat, 20 Jan 2007, Willy Tarreau wrote:
> On Sat, Jan 20, 2007 at 09:39:25PM +0100, Tim Schmielau wrote:
> > On Sat, 20 Jan 2007, Willy Tarreau wrote:
> > > On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote:
> > >
> > > > also explains why you see better results is writeout starts ea
On Saturday 20 January 2007 19:59, Robert Hancock wrote:
> Ian Kumlien wrote:
> > Hi,
> >
> > I went from 2.6.19+sata_nv-adma-ncq-v7.patch, with no problems and adama
> > enabled, to 2.6.20-rc5, which gave me problems almost instantly.
> >
> > I just thought that it might be interesting to know tha
On Sun, 21 Jan 2007, Sunil Naidu wrote:
> On 1/21/07, Tim Schmielau <[EMAIL PROTECTED]> wrote:
> >
> > Note that these dd "benchmarks" are completely bogus, because the data
> > doesn't actually get written to disk in that time. For some enlightening
> > data, try
> >
> > time dd if=/dev/zero of
Hello again. :-)
Bartlomiej Zolnierkiewicz wrote:
[PATCH] ide: add ide_set_dma() helper
* add ide_set_dma() helper and make ide_hwif_t.ide_dma_check return
-1 when DMA needs to be disabled (== need to call ->ide_dma_off_quietly)
0 when DMA needs to be enabled (== need to call ->ide_dma_
On 1/20/07, Justin Piszcz <[EMAIL PROTECTED]> wrote:
Perhaps its time to back to a stable (2.6.17.13 kernel)?
Anyway, when I run a cp 18gb_file 18gb_file.2 on a dual raptor sw raid1
partition, the OOM killer goes into effect and kills almost all my
processes.
Completely 100% reproducible.
Does
Hello again. :-)
Bartlomiej Zolnierkiewicz wrote:
[PATCH] ide: make ide_hwif_t.ide_dma_host_on void
* since ide_hwif_t.ide_dma_host_on is called either when drive->using_dma == 1
or when return value is discarded make it void, also drop "ide_" prefix
* make __ide_dma_host_on() void and dro
Hello again. :-)
Bartlomiej Zolnierkiewicz wrote:
[PATCH] ide: make ide_hwif_t.ide_dma_{host_off,off_quietly} void
Below are my nits on the patch itself, and the code it changes.
Index: b/drivers/ide/pci/atiixp.c
===
--- a/d
On Sat, 20 Jan 2007, Avuton Olrich wrote:
> On 1/20/07, Justin Piszcz <[EMAIL PROTECTED]> wrote:
> > Perhaps its time to back to a stable (2.6.17.13 kernel)?
> >
> > Anyway, when I run a cp 18gb_file 18gb_file.2 on a dual raptor sw raid1
> > partition, the OOM killer goes into effect and kills a
On Sat, 20 Jan 2007, Justin Piszcz wrote:
>
>
> On Sat, 20 Jan 2007, Avuton Olrich wrote:
>
> > On 1/20/07, Justin Piszcz <[EMAIL PROTECTED]> wrote:
> > > Perhaps its time to back to a stable (2.6.17.13 kernel)?
> > >
> > > Anyway, when I run a cp 18gb_file 18gb_file.2 on a dual raptor sw raid
On Thu, Jan 18, 2007 at 10:55:54PM +0100, Adrian Bunk wrote:
> Let's start with a small exercise:
>
> Consider sparse tells you about a global function:
> warning: symbol 'unionfs_d_revalidate_wrap' was not declared. Should
> it be static?
I ran sparse last week, and cleaned up a few things
On lör, 2007-01-20 at 21:43 +, Alistair John Strachan wrote:
> On Saturday 20 January 2007 19:59, Robert Hancock wrote:
> > Ian Kumlien wrote:
> > > Hi,
> > >
> > > I went from 2.6.19+sata_nv-adma-ncq-v7.patch, with no problems and adama
> > > enabled, to 2.6.20-rc5, which gave me problems almo
On Saturday, 20. January 2007 20:59, you wrote:
> Ian Kumlien wrote:
> > Hi,
> >
> > I went from 2.6.19+sata_nv-adma-ncq-v7.patch, with no problems and adama
> > enabled, to 2.6.20-rc5, which gave me problems almost instantly.
> >
> > I just thought that it might be interesting to know that it DID
Hi,
The following code:
[...]
s = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
socket_address.sll_family = PF_PACKET;
socket_address.sll_protocol = htons(ETH_P_IP);
/*
* this happens to be shaper0 on my system
*/
=> socket_address.sll_if
> Nice observation, however, it still leaves quite an amount of internal
> inconsistencies in the kernel output.
I agree with the majority view that using the term 'MB' or 'GB' to mean
a
million or a billion bytes is inaccurate. The way RAM and flash are measured
is correct. The way disk
On Saturday 20 January 2007 21:55, Michael Tokarev wrote:
> Denis Vlasenko wrote:
> > On Thursday 11 January 2007 18:13, Michael Tokarev wrote:
> >> example, which isn't quite possible now from userspace. But as long as
> >> O_DIRECT actually writes data before returning from write() call (as it
>
Samium Gromoff wrote:
>This patch removes the dropping of ADDR_NO_RANDOMIZE upon execution of setuid
>binaries.
>
>Why? The answer consists of two parts:
>
>Firstly, there are valid applications which need an unadulterated memory map.
>Some of those which do their memory management, like lisp syst
On Sat, 20 Jan 2007, Ivan Ukhov wrote:
> I'm writing a driver for an USB device that has one configuration with
> several interfacies and one of them is a HID interface. So when I check
> this interface whether it's claimed (usb_interface_claimed), I find out
> that it is, and it's claimed by t
Evgeniy Polyakov wrote:
On Fri, Jan 19, 2007 at 01:53:15PM +0100, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
Even further development of such idea is to prevent such OOM condition
at all - by starting swapping early (but wisely) and reduce memory
usage.
These just postpone execution but will
Hi,
I have been testing my wireless zd1211rw driver with kismet, but have noticed
my logs filling up
with these messages instead:
BUG: sleeping function called from invalid context at kernel/mutex.c:86
in_atomic():0, irqs_disabled():1
[] mutex_lock+0x12/0x1a
[] netdev_run_todo+0x10/0x1f1
[] d
On 1/21/07, Tim Schmielau <[EMAIL PROTECTED]> wrote:
Yes. You have a faster Disk that writes about 45 MB/s. But I am not sure I
understand what you want to know?
I got these results with a customized 2.6.20-rc5.
[EMAIL PROTECTED] kernel]$ uname -a
Linux Typhoon 2.6.20-rc5-Topol-M #1 SMP Sun Ja
Jiri Kosina wrote:
On Sat, 20 Jan 2007, Ivan Ukhov wrote:
I'm writing a driver for an USB device that has one configuration with
several interfacies and one of them is a HID interface. So when I check
this interface whether it's claimed (usb_interface_claimed), I find out
that it is, and i
On Sun, 21 Jan 2007, Ivan Ukhov wrote:
> No, it won't do. Imagine that I'm not able to modify the kernel with its
> drivers.
Could I ask you what precisely is the driver you are talking about doing?
Why is it not going to be a part of mainline kernel (i.e. being able to be
put on blacklist ea
Hello Thomas, Sascha and Ingo
please can you find some time to review next patch
arm: i.MX/MX1 clock event source
which has been sent to you and to the ALKML at 2007-01-13.
http://thread.gmane.org/gmane.linux.ports.arm.kernel/29510/focus=29533
There seems to be some problems, because this patc
Hi all,
I am using kernel 2.6.19 with the new pata and sata drivers.
First of all, the drivers work great, no crashes nothing.
There is one downside i found by using these drivers, and i am not
sure how i can fix this.
The drivers load correctly but my drives seem to be in a different
order all
Hi;
After switching ext3 to xfs, i realize system starts to _really_ unresponsive
and extracting tarballs, copying or deleting files or checking out svn
repositories are really slow, so i basically try to measure some for both xfs
and ext3 with same computer, same kernel (2.6.18.6), same disk,
> "David" == David Schwartz <[EMAIL PROTECTED]> writes:
David> The way RAM and flash are measured is correct.
In my experience, RAM and flash *drives* are measured differently.
I understand that individual flash chips come in powers of 2, but by
the time they're packaged as a "flash drive"
On Sat, Jan 20, 2007 at 11:42:37PM +, sathesh babu wrote:
> Hi,
> I am trying to run Linux-2.6.18.2 ( with preemption enable) kernel on FPGA
> board which has MIPS24KE processor runs at 12 MHZ. Programmed the timer to
> give interrupt at every 10msec.
> I am seeing some inconsistence beh
This is for a 2.6.18.6 UP-preempt kernel compiled with gcc-4.1.1, BTW.
Cheers,
Chris
___
The all-new Yahoo! Mail goes wherever you go - free your email address from
your Internet provider. http://uk.docs.yahoo.com/nowyou
On Sat, Jan 20, 2007 at 05:36:03PM -0500, Rik van Riel ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >On Fri, Jan 19, 2007 at 01:53:15PM +0100, Peter Zijlstra
> >([EMAIL PROTECTED]) wrote:
>
> >>>Even further development of such idea is to prevent such OOM condition
> >>>at all - by sta
Chr wrote:
Could you (or anyone else) test what happens if you take the 2.6.20-rc5
version of sata_nv.c and try it on 2.6.19? That would tell us whether
it's this change or whether it's something else (i.e. in libata core).
Ok, did that! (got a fresh 2.6.19 tar ball, and used 2.6.20-rc5' sata_n
OnStream Di30 (using ide-scsi and osst drivers), when reading
or writing I regularly get these kernel messages:
<3>ide-scsi: CoD != 0 in idescsi_pc_intr
Let's assume flaky hardware; nothing we can hold the kernel to
blame for (which is 2.6.19.1) -- it's a good thing it's calling
our attention.
On Sat, 2007-01-20 at 17:37 +0300, Samium Gromoff wrote:
> This patch removes the dropping of ADDR_NO_RANDOMIZE upon execution of setuid
> binaries.
>
> Why? The answer consists of two parts:
>
> Firstly, there are valid applications which need an unadulterated memory map.
> Some of those which d
1 - 100 of 119 matches
Mail list logo
