Udo van den Heuvel wrote:
Actually, what it looks like is even simpler. The extension cable
contains a four-port hub chip (which is the most common commodity chip)
and haven't bothered changing the descriptor to tell the computer only
one port is actually active. So only one port can be
Hello Sunil and Ingo,
Date: 2007-01-20 02:56:40 GMT (20 hours and 26 minutes ago)
> 2007-01-20, Sunil Naidu <[EMAIL PROTECTED]> wrote:
> I did refer the same. Is it necessary to use only base kernel, say
> 2.6.19? Or, can I go ahead with 2.6.19 + 2.6.19.2 patch + 2.6.19-rt
> patch?
>
> If yes,
H. Peter Anvin wrote:
> Greg KH wrote:
>> On Fri, Jan 19, 2007 at 04:40:34PM +0100, Udo van den Heuvel wrote:
>>>
>>> I just tried my shiny new usb extension cable (repeater):
>>>
>>> Jan 19 16:01:17 epia kernel: usb 5-1: new high speed USB device using
>>> ehci_hcd and address 60
>>> Jan 19
Greg KH wrote:
On Fri, Jan 19, 2007 at 04:40:34PM +0100, Udo van den Heuvel wrote:
Hello,
I just tried my shiny new usb extension cable (repeater):
Jan 19 16:01:17 epia kernel: usb 5-1: new high speed USB device using
ehci_hcd and address 60
Jan 19 16:01:17 epia kernel: usb 5-1: configuration
David Schwartz wrote:
Talk about a cure worse than the disease! So you're saying that 256MB
flash
cards could be advertised as having 268.4MB? A 512MB RAM stick is
mislabelled and could correctly say 536.8MB? That's just plain craziness.
Adopting IEC 60027-2 just replaces a
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.
All comments welcome on/off list.
Thanks,
Joe Barr
K1GPL
[...]
I've spent
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.
All comments welcome on/off list.
Thanks,
Joe Barr
K1GPL
[...]
I've spent
On Sun, Jan 21, 2007 at 12:54:56AM -0500, Theodore Tso wrote:
> On Sat, Jan 20, 2007 at 06:36:44PM +0100, Willy Tarreau wrote:
> > 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
Björn Steinbrink wrote:
On 2007.01.20 22:34:27 -0500, Jeff Garzik wrote:
Robert Hancock wrote:
change in 2.6.20-rc is either causing or triggering this problem. It
would be useful if you could try git bisect between 2.6.19 and
2.6.20-rc5, keeping the latest sata_nv.c each time, and see if
On Sat, Jan 20, 2007 at 06:36:44PM +0100, Willy Tarreau wrote:
> 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
From: On Behalf Of Joe Barr
> 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.
From: w1hkj [mailto:[EMAIL PROTECTED]
> I am now convinced that
On 2007.01.20 22:34:27 -0500, Jeff Garzik wrote:
> Robert Hancock wrote:
> >change in 2.6.20-rc is either causing or triggering this problem. It
> >would be useful if you could try git bisect between 2.6.19 and
> >2.6.20-rc5, keeping the latest sata_nv.c each time, and see if that
>
>
> Yes,
On Fri, Jan 19 2007, dann frazier wrote:
> On Wed, Dec 13, 2006 at 01:52:36PM +0100, Jens Axboe wrote:
> > On Tue, Dec 12 2006, Mike Miller (OS Dev) wrote:
> > > On Mon, Nov 06, 2006 at 09:32:00PM +0100, Jens Axboe wrote:
> > > > On Mon, Nov 06 2006, Mike Miller (OS Dev) wrote:
> > > > > PATCH 9
On Saturday 20 January 2007 22:41, Stephen Clark wrote:
>Willy Tarreau wrote:
>>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
On Thu, Jan 18 2007, Robert Hancock wrote:
> Ricardo Correia wrote:
> >On Tuesday 16 January 2007 00:38, you wrote:
> >>As always with these things, the devil is in the details. It requires
> >>the device to support a ->prepare_flush() queue hook, and not all
> >>devices do that. It will work for
Willy Tarreau wrote:
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
Robert Hancock wrote:
change in 2.6.20-rc is either causing or triggering this problem. It
would be useful if you could try git bisect between 2.6.19 and
2.6.20-rc5, keeping the latest sata_nv.c each time, and see if that
Yes, 'git bisect' would be the next step in figuring out this puzzle.
Hi,
This patch writes the USB vendor and product IDs into the
/sys/class/input/inputX/id/ files, so
that udev can find them. A rule like this does the trick for me:
KERNEL="event*", SYSFS{../id/vendor}=="2040", SYSFS{../id/product}=="9301",
SYMLINK+="input/dvb-remote"
---
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
> On Sat, Jan 20, 2007 at 05:36:03PM -0500, Rik van Riel ([EMAIL PROTECTED])
> wrote:
> > Due to the way everything in the kernel works, you cannot
> > prevent the memory allocator from allocating everything and
> > running out, except maybe by setting aside reserves to deal
> > with special
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.
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'
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
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.
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
> "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
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,
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
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
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
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
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
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
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
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
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
[]
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
> 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
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
*/
=>
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
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
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
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
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
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
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
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
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
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
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
===
---
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
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
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.
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
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
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:
> 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
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
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
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
> >
> >
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
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
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
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
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
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
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)
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
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
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
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
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]>
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
(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,
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
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
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
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
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
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,
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
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:
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
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
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
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
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
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
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
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
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
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
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
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;
> >
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:
---
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)
> > > +{
> > >
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
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
1 - 100 of 238 matches
Mail list logo
