On 01/07/2007 11:20 AM, Jeremy Fitzhardinge wrote:
Rene Herman wrote:
How is it for efficiency? I thought it was for correctness.
romsignature is using probe_kernel_adress() while all other accesses
to the ROMs there aren't.
If nothing else, anyone reading that code is likely to ask himself
On 01/07/2007 07:07 PM, Jeremy Fitzhardinge wrote:
Rene Herman wrote:
Doing the set_fs() and pagefault_{disable,enable} calls for every
single byte during the checksum seems rather silly.
Why?
Because it makes for dumb code. But oh well, given that it all compiles
to basically nothing I
On 01/08/2007 01:10 PM, Rolf Eike Beer wrote:
Ahmed S. Darwish wrote:
- struct intmem_allocation* alloc =
- (struct intmem_allocation*)kmalloc(sizeof *alloc, GFP_KERNEL);
+ struct intmem_allocation* alloc = kmalloc(sizeof *alloc,
+
On 01/08/2007 02:44 PM, Dimitar G. Katerinski wrote:
After some investigation, I find out that my IDE chipset is being discovered
as SATA, so my hard drive is not /dev/hda, but /dev/sda.
It seems you compiled in support for "PATA", more specifically for:
00:09.0 IDE interface: nVidia
Nick Piggin wrote:
Aucoin wrote:
Ummm, shm_open, ftruncate, mmap ? Is it a trick question ? The process
responsible for initially setting up the shared area doesn't stay
resident.
The issue is that the shm pages should show up in the active and
inactive lists. But they aren't, and you
Aucoin wrote:
From: Rene Herman [mailto:[EMAIL PROTECTED] ftruncate there
and some similarity to a problem I once experienced
I can't honestly say I completely grasp the fundamentals of the issue
you experienced but we are using ext3 with data=journal
Rereading I see ext3 isn't involved
Hi Kai.
Attachment allows st to be autoloaded.
Rene.
--- linux-2.6.11-rc1.orig/drivers/scsi/st.c 2004-12-26 23:33:37.0
+0100
+++ linux-2.6.11-rc1/drivers/scsi/st.c 2005-01-16 17:32:45.0 +0100
@@ -85,6 +85,7 @@
MODULE_AUTHOR("Kai Makisara");
MODULE_DESCRIPTION("SCSI Tape
Chris Wright wrote:
-stable review patch. If anyone has any objections, please let us know.
--
From: Herbert Xu <[EMAIL PROTECTED]>
As CBC is the default chaining method for cryptoloop, we should select
it from cryptoloop to ease the transition.
Signed-off-by: Herbert Xu
On 02/26/2007 07:13 PM, Linus Torvalds wrote:
The floppy is still pretty much the only user of native motherboard
(aka i8237) DMA'ing for most people. Some old ISA sound-cards may do
it, of course.
Other than these two, ECP parallel ports are the other remaining users.
Now, even though on a
On 02/28/2007 02:04 PM, Alan wrote:
PLIP/Laplink runs bidirectional on ordinary parallel ports. The
bidirectional part of parallel ports in "normal" modes is still used
for things like PnP detection of printer and drivers.
And my parallel port Iomega ZIP drive, it seems. I actually checked
On 04/01/2007 12:06 PM, Pekka Enberg wrote:
Looks like mcdx_xfer is sleeping while holding q->queue_lock. The
attached (untested) patch should fix it.
This (including your followup) does indeed avoid the traces in the
kernel log, but unfortunately, the driver seems to need a bit more.
This
On 04/02/2007 02:02 AM, Rene Herman wrote:
On 04/01/2007 12:06 PM, Pekka Enberg wrote:
Looks like mcdx_xfer is sleeping while holding q->queue_lock. The
attached (untested) patch should fix it.
This (including your followup) does indeed avoid the traces in the
kernel log, but unfortunat
On 04/02/2007 10:55 AM, Pekka J Enberg wrote:
On Mon, 2 Apr 2007, Jens Axboe wrote:
But as I wrote earlier, it'll take lots more to make this driver close
to functional.
Heh, looking at the driver, that's quite an understatement =). Rene,
here's an untested attempt to use a mutex instead
On 04/02/2007 09:10 AM, Jens Axboe wrote:
Updated patch attached :-)
diff --git a/Documentation/feature-removal-schedule.txt
b/Documentation/feature-removal-schedule.txt
index 0bc8b0b..cff761a 100644
--- a/Documentation/feature-removal-schedule.txt
+++
On 04/02/2007 05:18 PM, Rene Herman wrote:
Thanks again, spinning!
Oh, forgot to mention. Yes, earlier PREEMPT was on and it's now disabled.
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
On 04/02/2007 11:42 AM, Jens Axboe wrote:
I somehow doubt that the cards are capable of highmem addressing in
the first place :-)
Well, we could pretend we're using 286s and define the 15-16 MB hole as
"highmem". But other than that, these things plug into an ISA bus, so
no. Most of them
On 04/03/2007 08:57 AM, Pekka J Enberg wrote:
[ re-including linux-kernel ]
Does this change the dd case?
diff --git a/drivers/cdrom/mcdx.c b/drivers/cdrom/mcdx.c
index f574962..6c613d0 100644
--- a/drivers/cdrom/mcdx.c
+++ b/drivers/cdrom/mcdx.c
@@ -1248,6 +1248,7 @@ #endif
On 04/03/2007 07:31 PM, Pekka J Enberg wrote:
Oh, well, here goes. Rene, would you be so kind and spin the wheel once
more? =)
Absolutely!
[EMAIL PROTECTED]:~# dd if=/dev/mcdx0 of=/dev/null
Oops: 0002 [#1]
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010082 (2.6.20.4 #11)
EIP is
On 04/03/2007 08:32 PM, Pekka J Enberg wrote:
Please enable CONFIG_DEBUG_SLAB now and reproduce. It should tell us
what's going wrong there.
Taking forever to reproduce in as far as getting the oops. The thing is
now just locking hard each time. Will keep on trying...
Rene.
-
To
Hi Rusty.
Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?
Often a module grows multiple authors over time, but initial authors
aren't around (or too interested) anymore. And sometimes, if someone
maintaining a driver is just doing minor peripheral updates to keep it
compiling,
On 04/04/2007 01:26 PM, Rene Herman wrote:
Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?
And here's the accompanying patch to the module-init-tools-3.3-pre1 as
found on http://kernel.org/pub/linux/utils/kernel/module-init-tools/
Rene.
--- module-init-tools-3.3-pre1
On 04/04/2007 02:33 PM, Christoph Hellwig wrote:
On Wed, Apr 04, 2007 at 01:26:04PM +0200, Rene Herman wrote:
Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?
#define MODULE_MAINTAINER(x) MODULE_AUTHOR(x), please.
MODULE_AUTHOR really has meant maintainer in practice for ages
On 04/04/2007 05:02 PM, Adrian Bunk wrote:
#define MODULE_MAINTAINER(x) MODULE_AUTHOR(x), please.
MODULE_AUTHOR really has meant maintainer in practice for ages,
and it's the only actually relevant for users information we
should store.
I agree. The actual author information belong into the
On 04/04/2007 06:00 PM, Alan Cox wrote:
Given that people seem to agree that authorship information has no place
in the binary, that might actually be best.
Authorship information is very useful in the binary, especially when you
have to get lawyers involved in explaining things to people.
On 04/04/2007 07:48 PM, Adrian Bunk wrote:
On Wed, Apr 04, 2007 at 07:00:18PM +0200, Takashi Iwai wrote:
But in general, it would be nice to have an easy way to find a
maintainer (not author) from a module binary, and I agree
MODULE_MAINTAINER can work well for such a purpose. It's no
On 04/08/2007 12:41 PM, Ingo Molnar wrote:
this is pretty hard to get right, and the most objective way to change
it is to do it testcase-driven. FYI, interactivity tweaking has been
gradual, the last bigger round of interactivity changes were done a year
ago:
commit
On 04/09/2007 06:23 AM, Mike Galbraith wrote:
On Sun, 2007-04-08 at 20:51 +0200, Rene Herman wrote:
On 04/08/2007 12:41 PM, Ingo Molnar wrote:
commit 5ce74abe788a26698876e66b9c9ce7e7acc25413
Author: Mike Galbraith <[EMAIL PROTECTED]>
Date: Mon Apr 10 22:52:44 2006 -0700
On 04/09/2007 03:53 PM, Ingo Molnar wrote:
In any case, it would be very nice if you could try Mike's latest
patch, how does it work on your setup? (i've attached it)
Can do. Note that "my setup" in that case consisted of browsing around
eBay in firefox with ogg123 playing audio directly to
On 04/09/2007 04:15 PM, Ingo Molnar wrote:
* Rene Herman <[EMAIL PROTECTED]> wrote:
To me, the example rather serves as confirmation of what Kolivas
has been saying; endlessly tweaking the tweaks isn't going
anywhere.
but ... SD clearly regresses in some areas, so by that logic S
On 04/09/2007 07:48 PM, Ingo Molnar wrote:
i didnt say that, in fact my first lkml comment about RSDL on lkml
was the exact opposite, but you SD advocates are _still_ bickering
about (and not accepting) fundamental things like Mike's make -j5
workload and flagging it as unrealistic, so until
On 04/09/2007 03:27 PM, Andreas Mohr wrote:
And I really don't see much difference whatsoever to the I/O scheduler
area: some people want predictable latency, while others want maximum
throughput or fastest operation for seek-less flash devices (noop).
Hardware varies similarly greatly has
On 02/15/2007 08:02 PM, Linus Torvalds wrote:
Think of it this way: in science, a theory is proven to be bad by a
single undeniable fact just showing that it's wrong.
The same is largely true of a warning. If the warning sometimes
happens for code that is perfectly fine, the warning is bad.
On 02/12/2007 08:38 AM, Andi Kleen wrote:
From: Rene Herman <[EMAIL PROTECTED]>
[ ... ]
--- linux.orig/arch/i386/Kconfig
+++ linux/arch/i386/Kconfig
@@ -843,7 +843,7 @@ config RELOCATABLE
config PHYSICAL_ALIGN
hex "Alignment value to which kernel should be aligned"
Hi Greg.
On an older Intel 430VX system, 2.6.20.4 complains a bit:
===
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
:00:07.1: cannot adjust
Hi Al.
GIT doesn't remember, it's been too long, but IIRC you were the last one
to do some work on mcdx (the old proprietary mitsumi cd-rom driver). The
thing builds without warnings on 2.6.20.4, unlike most other proprietary
CD-ROM drivers, so someone did...
In any case, I just bet you're
On 03/31/2007 08:47 AM, Jens Axboe wrote:
Try this.
diff --git a/drivers/cdrom/mcdx.c b/drivers/cdrom/mcdx.c
index f574962..7086313 100644
--- a/drivers/cdrom/mcdx.c
+++ b/drivers/cdrom/mcdx.c
@@ -577,6 +577,11 @@ static void do_mcdx_request(request_queue_t * q)
if (!req)
On 01/10/2007 11:44 PM, [EMAIL PROTECTED] wrote:
The patch titled
romsignature/checksum cleanup
has been removed from the -mm tree. Its filename was
romsignature-checksum-cleanup-2.patch
This patch was dropped because x86_64 tree changes trashed it
I was (am) quite unsure why this
top people reading this code from
wondering if they're looking at a bug...
Signed-off-by: Rene Herman <[EMAIL PROTECTED]>
===
Rene.
diff --git a/arch/i386/kernel/e820.c b/arch/i386/kernel/e820.c
index f391abc..8b8741f 100644
--- a/arch/i386/kernel/e820.c
+++ b/arch/i386/kernel/e820.c
@@
-by: Rene Herman <[EMAIL PROTECTED]>
===
Rene
diff --git a/arch/x86_64/kernel/setup.c b/arch/x86_64/kernel/setup.c
index af425a8..0b3d237 100644
--- a/arch/x86_64/kernel/setup.c
+++ b/arch/x86_64/kernel/setup.c
@@ -183,22 +183,31 @@ static struct resource video_ram_resourc
On 01/29/2007 02:46 PM, Rene Herman wrote:
This syncs up the x86_64 probe_roms() with the i386 version as just
submitted.
===
Sync up with i386. Specifically, be careful about touching the
legacy ROMs; in virtualized environments they may not be mapped.
Crosscompiled, but not booted due
On 06/14/2007 06:01 PM, Linus Torvalds wrote:
It's totally pointless to try to "force" people to be good. That's like
"curing" gay people. Not going to happen.
Tangent, but that could in fact quite easily be construed as saying that gay
people aren't good which I hope is not the point you
On 06/14/2007 09:29 PM, Lennart Sorensen wrote:
On Thu, Jun 14, 2007 at 07:48:03PM +0200, Rene Herman wrote:
On 06/14/2007 06:01 PM, Linus Torvalds wrote:
It's totally pointless to try to "force" people to be good. That's like
"curing" gay people. Not going
On 04/19/2007 04:18 PM, Bart Trojanowski wrote:
I need to preserve some state from the bios before entering protected
mode. For now I want to copy it into some ram accessible by real-mode,
say the last megabyte visible in real-mode.
What's the easiest way to have linux ignore the megabyte
On 04/04/2007 06:38 PM, Rene Herman wrote:
Rusty?
On 04/04/2007 06:00 PM, Alan Cox wrote:
Given that people seem to agree that authorship information has no
place in the binary, that might actually be best.
Authorship information is very useful in the binary, especially when you
have
Andrew, mind if I submit this to you?
===
Provide MODULE_MAINTAINER() as a convenient place to stick a name and email
address both for drivers having multiple (current and non-current) authors
and for when someone who wants to maintain a driver isn't so much an author.
Signed-off-by: Rene Herman <[EMA
On 04/26/2007 03:18 AM, Andrew Morton wrote:
On Mon, 23 Apr 2007 14:32:36 +0200 Rene Herman <[EMAIL PROTECTED]>
wrote:
Provide MODULE_MAINTAINER() as a convenient place to stick a name and
email address both for drivers having multiple (current and
non-current) authors and for when s
On 04/26/2007 03:54 PM, Adrian Bunk wrote:
Let me try to summarize the points:
- you think MODULE_AUTHOR without MODULE_MAINTAINER confuses users
Yes, and the frustration of composing lengthy emails to bouncing (or worse
still, silent) email adresses is severe if you just decided to for once
On 04/26/2007 06:00 PM, Alan Cox wrote:
Tie Alan to his chair and take away his keyboard while we submit patches
removing MODULE_AUTHOR? Or just apply a trivial two line, optional, non
mandatory, patch introducing a MODULE_MAINTAINER? You pick... :-)
MODULE_AUTHOR is extremely important for
On 04/26/2007 09:43 PM, Adrian Bunk wrote:
What exactly is missing that the kernel Bugzilla doesn't already offer?
Users?
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On 04/26/2007 05:52 PM, Adrian Bunk wrote:
I don't think we want to expose maintainership information to users at
all:
With the point you make about old installed kernel modules having outdated
information forever you've in fact convinced me that MODULE_MAINTAINER is
not a good idea. If I
On 04/26/2007 10:24 PM, Adrian Bunk wrote:
The problem with such a database would be the same as with the
MAINTAINERS file: The information becomes outdated, and someone has to
maintain it.
Sending a patch against MAINTAINERS is easy - I don't see a
WWW-browseable database being in any
Good day.
Stumbling around with git here. I'd like to use git to efficiently track the
current -stable as well as -current. Say, my local tree is a clone of
Linus current:
git clone \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git local
I then branch off a 2.6.20
On 04/14/2007 08:24 AM, Junio C Hamano wrote:
I think adding these lines to .git/config would do the trick,
after you have done the "checkout -b v2.6.20 v2.6.20" step:
[branch "v2.6.20"]
remote = stable
merge = refs/heads/master
[remote "stable"]
url =
On 04/14/2007 10:34 AM, Chris Wright wrote:
I've already put a tree like this up on kernel.org. The master branch
is Linus' tree, and there's branches for each of the stable releases
called linux-2.6.[12-20].y (I didn't add 2.6.11.y).
On 04/14/2007 10:54 AM, Rene Herman wrote:
On 04/14/2007 10:34 AM, Chris Wright wrote:
I've already put a tree like this up on kernel.org. The master branch
is Linus' tree, and there's branches for each of the stable releases
called linux-2.6.[12-20].y (I didn't add 2.6.11.y).
http
On 04/15/2007 01:30 AM, Robert P. J. Day wrote:
Remove the obsolete code for the traffic shaper.
Why are all your messages getting a "{Spam?}" subject prefix?
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On 04/15/2007 01:38 AM, Robert P. J. Day wrote:
Why are all your messages getting a "{Spam?}" subject prefix?
i have no idea, that's a recent development. is that happening with
anyone else?
Not that I've seen. Your last message/thread were the others:
http://lkml.org/lkml/2007/4/14/89
+= sjcd.o
diff --git a/drivers/cdrom/mitsumi.c b/drivers/cdrom/mitsumi.c
new file mode 100644
index 000..79d95d0
--- /dev/null
+++ b/drivers/cdrom/mitsumi.c
@@ -0,0 +1,1026 @@
+/*
+ * drivers/cdrom/mitsumi.c - Mitsumi legacy CD-ROM Driver for Linux
+ *
+ * Copyright (C) 1995-1996 Heiko Schlit
On 06/04/2007 11:42 AM, Rene Herman wrote:
[ ... ]
Unfortunately, I can make the box oops by just doing enough of those dd
runs in a row (this one with bs=2k count=128, oopsed the seventh time or
something):
===
BUG: unable to handle kernel paging request at virtual address 8c1d2071
On 06/04/2007 05:07 PM, Rene Herman wrote:
Call Trace:
[] __mitsumi_get_frame+0xc/0x16 [mitsumi]
[] mitsumi_get_frame+0x120/0x134 [mitsumi]
[] lock_timer_base+0x15/0x2f
[] cfq_set_request+0x0/0x144
Perhaps interesting (and perhaps not) -- I've been unable to reproduce
the OOPS after
On 06/04/2007 09:08 PM, Andy Whitcroft wrote:
I guess line length and white space checks make sense some degree on
those files. I'll sort that out and I guess we'll have anohter version.
Could you then also post the thing itself, and not just a patch against the
previous version for us
On 06/04/2007 08:41 PM, Pekka Enberg wrote:
[ Jens' email address updated to his oracle address ]
We can see that we're reading 2048 bytes from port 0x300 and storing
the data in memory location 0x8c1d2071 which causes the OOPS. What's
surprising is that EBP is set to 0x8c1d2071 too which
On 06/04/2007 10:38 PM, Rene Herman wrote:
On 06/04/2007 08:41 PM, Pekka Enberg wrote:
[ Jens' email address updated to his oracle address ]
We can see that we're reading 2048 bytes from port 0x300 and storing
the data in memory location 0x8c1d2071 which causes the OOPS. What's
surprising
On 06/05/2007 01:09 AM, Christoph Lameter wrote:
Here a version of the patch that drops the WARN_ONs
And now all that's done, how about yet another random person stepping in and
suggesting NIL or maybe NIL_PTR instead of ZERO_SIZE_PTR?
I understand the idea is that code need not necesarily
On 06/05/2007 04:10 AM, WANG Cong wrote:
On Mon, Jun 04, 2007 at 01:57:51PM -0400, Jeff Garzik wrote:
A matter of opinion :) I tend to think goto is special enough to
warrant column 1 unconditionally. It is special, so it draws additional
attention over and above case labels.
I and others
On 06/05/2007 02:07 PM, John Anthony Kazos Jr. wrote:
The name says exactly what it is. It's not at all dreadful. If we're going
to return a special value in the zero-size case (and in only that case) as
a valid pointer instead of actually allocating one byte and treating it as
zero, what we
On 06/05/2007 03:58 PM, John Anthony Kazos Jr. wrote:
So "ZERO_SIZE_OBJ_PTR" is the most correct form, and "ZERO_SIZE_PTR" is a
convenient shortening. "ZERO_PTR" is too short and also confuses with NULL
because NULL is a zero-value object, rather than a non-zero--value pointer to
a zero-size
On 06/05/2007 04:40 PM, Jeremy Fitzhardinge wrote:
Rene Herman wrote:
No, what we have is a sizeof(pointer) sized pointer pointing to an
object of size zero. ZERO_SIZE_PTR is butt-ugly. With a really ugly butt.
It doesn't matter. It will never, ever, be used by anything except
On 06/06/2007 11:26 PM, Pavel Machek wrote:
Yes, it's internal but given that this is open-source
which, optimistically, is read many more times than it's
written one should still strive for code that reads nice
as far as I'm concerned. It's obviously also not hugely
important but it's just
On 06/08/2007 11:31 AM, Andy Whitcroft wrote:
Ok, the latest version 0.04 is released and I have also put up the
complete script at:
http://www.shadowen.org/~apw/public/checkpatch/checkpatch.pl-0.04
Previous versions are also there.
Thank you. False positive:
do not use
On 06/10/2007 07:52 PM, Sam Ravnborg wrote:
We once discussed about .po files for kconfig and back then
the conclusion was not to keep them in the kernel tree.
I advocated that they should stay out back then.
But on the other hand I do not see it causing much troubles
having
On 06/10/2007 08:58 PM, Rene Herman wrote:
RESIST! UNITE!
Stick a ";-)" on that, by the way...
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
On 06/11/2007 02:56 AM, Paul Mundt wrote:
On Mon, Jun 11, 2007 at 01:59:00AM +0200, Denis Vlasenko wrote:
I agree. i18n efforts won't help one iota because people just have
to know English in order to participate in l-k development.
That's a ridiculous statement. Non-native language
On 06/11/2007 02:14 AM, Adrian Bunk wrote:
On Mon, Jun 11, 2007 at 01:59:00AM +0200, Denis Vlasenko wrote:
I agree. i18n efforts won't help one iota because people just have
to know English in order to participate in l-k development.
They should be able to read _and_ reply_ to lkml posts,
On 06/11/2007 12:46 PM, KAMEZAWA Hiroyuki wrote:
"Qi Yong" <[EMAIL PROTECTED]> wrote:
On 11/06/07, KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
Hi, thank you for your work. I was impressed.
BTW, how about adding following lines (both in Japanese and English) ?
==
This is translated "HOWTO"
On 06/11/2007 01:28 PM, KAMEZAWA Hiroyuki wrote:
Rene Herman <[EMAIL PROTECTED]> wrote:
Please don't say that -- I perfectly understood what you were saying and as
such it was of perfect use. There's a large number of non-native English
speakers around the Linux kernel and noone is ex
On 06/11/2007 07:20 PM, Dave Jones wrote:
FWIW, waay back when (sometime last year if memory serves)
Linus suggested changing the default to 0x100 for all x86.
The reasoning was some performance microoptimisation regarding
4MB aligned TLBs iirc.
Yup. Or rather, he suggested 4M (0x40):
On 06/11/2007 07:58 PM, H. Peter Anvin wrote:
Rene Herman wrote:
Aligning the kernel image on 4M could gain an additional TLB entry if
the kernel image would fit in one (4M aligned) hugepage, but not in the
3M that's left after loading the kernel at 1M physical. And that stuff
about the MTRRs
On 06/11/2007 08:46 PM, Dave Jones wrote:
On Mon, Jun 11, 2007 at 08:19:57PM +0200, Jan Engelhardt wrote:
>
> On Jun 11 2007 10:36, H. Peter Anvin wrote:
> >
> >Picking the 16 MB base is a bit obnoxious on small-memory machines, 4 MB
> >would probably be a more reasonable base. Of
On 06/11/2007 10:07 PM, Rene Herman wrote:
But, it's just a default anyway. Would it be considered beneficial to
more explicitly provide a few options through a config menu, something
like the attached?
Ehm, so now where did that long help actually end up? :-|
If the notion is considered
On 05/22/2007 12:25 PM, Thomas Gleixner wrote:
From: Ingo Molnar <[EMAIL PROTECTED]>
The SJCD driver uses a jiffies busy loop. Replace it with msleep.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Acked-by: Thomas Gleixner <[EMAIL PROTECTED]>
Okay, that's just waiting for a reset to
On 05/23/2007 07:04 PM, Randy Dunlap wrote:
That's a good source of confusion. To me, "notime" means something
like "don't bother calculating time", instead of the proposed
behavior. Can't it be something like 'nologts' (no log timestamps)
or nots or notimestamps or nologtime instead?
On 05/23/2007 09:28 PM, Ingo Molnar wrote:
* Rene Herman <[EMAIL PROTECTED]> wrote:
The trouble there is that unless you poll the bloody thing like mad
too much of the Q subchannels passes below you and you need a huge
number of retries to get anything out of it. I noticed when I s
On 05/23/2007 09:34 PM, Alan Cox wrote:
driver was snappy in that regard. When I replaced our sleeping loop with a
busy-wait same as the original the snappyness returned and moreover, reading
the TOC from the CD went from something close to a minute to approximately a
second. Thought that
On 05/23/2007 10:55 PM, Randy Dunlap wrote:
That's a good source of confusion. To me, "notime" means something
like "don't bother calculating time", instead of the proposed
behavior. Can't it be something like 'nologts' (no log timestamps)
or nots or notimestamps or nologtime instead
On 05/24/2007 07:08 AM, Randy Dunlap wrote:
Rene Herman wrote:
Okay. I would by the way not be against turning the timestamping off by
default and turning it _on_ with a "timestamps" or "logtime" or
whatever option. The information is sometimes handy for seeing the
(
On 05/24/2007 07:11 AM, Rene Herman wrote:
Okay. I would by the way not be against turning the timestamping off
by default and turning it _on_ with a "timestamps" or "logtime" or
whatever option.
Yes I only now looked. Sorry, didn't realise that was how it already worked.
On 05/08/2007 03:49 PM, Jens Axboe wrote:
The key is that you have to have interrupts disabled for the highmem
case, which may complicate your driver (or just make it perform worse,
from the system POV). If you let the block layer bounce, then you can
just use page_address() and don't worry
On 05/08/2007 10:13 PM, Ondrej Zary wrote:
I fixed cdu31a some time ago - so it at least works.
Oh, okay, thanks, I missed that. When I last tested it (which I see is in
fact well over a year ago) it "sort of" worked sometimes but was really flakey.
I also have a Panasonic drive with
On 05/08/2007 11:12 PM, Bob Tracy wrote:
Agreed. I've still got a GUS in one of my museum pieces that runs MS-Win
3.1 by default. The BIOS is too old to support booting from anything
except hda, sda and floppy, but because I enjoy pain I'll be happy to
modify the startup floppy images for a
On 05/09/2007 12:22 PM, Pekka Enberg wrote:
+static void end_entire_request(struct request *req, int uptodate)
+{
+ if (end_that_request_first(req, uptodate, req->hard_nr_sectors))
+ BUG();
+ add_disk_randomness(req->rq_disk);
+ blkdev_dequeue_request(req);
+
outdated.
A bit more than half of the tags in the tree don't include an email address
already and I'll submit patches removing more...
Rene.
commit 3b4fa382d5a6a3d9afdcb5a9232d63c47391fb30
Author: Rene Herman <[EMAIL PROTECTED]>
Date: Fri May 11 02:24:35 2007 +0200
module_author:
On 05/11/2007 12:46 PM, Alan Cox wrote:
The email address is the problem I was trying to fix; with multiple current
and non-current authors and maintainers who might not even be authors the
address(es) available from the tag confuse the issue of whom to contact.
It's moreover also information
On 05/11/2007 04:40 PM, Alan Cox wrote:
But it's not a style issue. It's solving a problem. The adresses from this
tag are the only addresses available from the binary and as such are
mistaken for maintainer/general contact addresses which they often are not.
Which is why you want
On 05/11/2007 01:42 PM, John Anthony Kazos Jr. wrote:
Can't we just subtitle it somehow? Add tags: " (current maintainer)", "
(original author, inactive)", " (bug and defect reports)", or whatever
you like after the names.
Yes, that's close to Rusty's version of the original
command for snd_cs4236
Yup; the conversion of the mixed legacy/pnp ALSA drivers to the isa_bus
framework is not quite right. Wants the attached.
Takashi, this needs to go to Linus. Can you make sure it gets there? This is
against -linus HEAD.
Signed-off-by: Rene Herman <[EMAIL PROTECTED]>
On 05/02/2007 10:59 PM, H. Peter Anvin wrote:
I'm having a framework for multiple drivers (probe and set methods,
basically); the stock distro will have VGA and VESA drivers only.
Dropping new drivers in is trivial if someone wants to.
It sounds like going overboard a bit; 80x25 standard VGA,
On 05/02/2007 11:15 PM, H. Peter Anvin wrote:
However, the pluggable framework is quite trivial and makes the code
look really clean, so I'm keeping it regardless.
Sheesh. Anyways, I know you asked about register writes but in case it's
still useful info: the CL54xx adapters have 132x43 and
On 05/02/2007 11:25 PM, H. Peter Anvin wrote:
Anyways, I know you asked about register writes but in case it's
still useful info: the CL54xx adapters have 132x43 and 132x25 as BIOS
modes 0x54 and 0x55 (ie, just int 0x10 modes) respectively. No idea how
complete the Bochs/Qemu video BIOS is.
On 05/03/2007 12:11 AM, H. Peter Anvin wrote:
The problem is to detect the ones that have it from the ones that don't.
Checking here, and mine also has 132x25 as BIOS mode 0x14 in addition to
0x55. Probably also not universal, and 0x54 (132x43) doesn't seem to be
repeated. Unfortunate that
601 - 700 of 1135 matches
Mail list logo
