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
() 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 [EMAIL PROTECTED]
===
Rene.
diff --git a/include/linux/module.h b
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
default
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 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
[PATCH
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 SD isnt
going
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
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
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
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 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 unfortunately
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 majordomo info
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 are
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:[c1047787]Not tainted VLI
EFLAGS: 00010082 (2.6.20.4
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 07-01-08 23:27, Bodo Eggert wrote:
On Mon, 7 Jan 2008, H. Peter Anvin wrote:
There might have been a few 386/20's clocking the ISA bus at ÷3 (6.67
MHz) rather than ÷2 (10 MHz) or ÷2.5 (8 MHz).
Yes, and the remaining users should set the kernel option. Both of them.
The question is:
On 08-01-08 00:24, H. Peter Anvin wrote:
Rene Herman wrote:
Is this only about the ones then left for things like legacy PIC and
PIT? Does anyone care about just sticking in a udelay(2) (or 1) there
as a replacement and call it a day?
PIT is problematic because the PIT may be necessary
On 08-01-08 13:51, Bodo Eggert wrote:
On Tue, 8 Jan 2008, Rene Herman wrote:
Is this only about the ones then left for things like legacy PIC and PIT?
Does anyone care about just sticking in a udelay(2) (or 1) there as a
replacement and call it a day?
PIT is problematic because the PIT may
On 09-01-08 10:34, Frans Pop wrote:
Bjorn:
Len Brown wrote:
Well, yes, the warning is actually new as well. Previously your kernel
just silently ignored 8 more mem resources than it does now it seems.
Given that people are hitting these limits, it might make sense to just
do away with the
On 09-01-08 06:30, Christer Weinigel wrote:
On Tue, 08 Jan 2008 18:52:42 -0800
Zachary Amsden [EMAIL PROTECTED] wrote:
What is the outcome of this thread? Are we going to use timing based
port delays, or can we finally drop these things entirely on 64-bit
architectures?
I a have a doubly
On 10-01-08 01:37, Robert Hancock wrote:
David P. Reed wrote:
I have a small suggestion in mind that might be helpful in the future:
the motherboard resources discovered as PNP0C02 devices in their _CRS
settings in ACPI during ACPI PnP startup should be reserved (or
checked), and any
On 09-01-08 23:43, Ondrej Zary wrote:
Jaroslav -- in your role as ISA-PnP maintainer and Bjorn, in yours as having
been foollish enough to touch PnP recently:
as hibernation (swsusp) started to work with my CPU, I found that my Turtle
Beach Malibu stops working after resume from hibernation.
On 10-01-08 08:58, Jaroslav Kysela wrote:
On Thu, 10 Jan 2008, Rene Herman wrote:
On 09-01-08 23:43, Ondrej Zary wrote:
Jaroslav -- in your role as ISA-PnP maintainer and Bjorn, in yours as
having been foollish enough to touch PnP recently:
as hibernation (swsusp) started to work with my
On 11-01-08 02:36, Zachary Amsden wrote:
FWIW, I fixed the problem locally by recompiling, changing port 80 to
port 84 in io.h; works great, and doesn't conflict with any occupied
ports.
Might not give you a proper delay though. 0xed should be a better choice...
Rene.
--
To unsubscribe from
On 11-01-08 15:35, David P. Reed wrote:
Rene Herman wrote:
On 11-01-08 02:36, Zachary Amsden wrote:
FWIW, I fixed the problem locally by recompiling, changing port 80 to
port 84 in io.h; works great, and doesn't conflict with any occupied
ports.
Might not give you a proper delay though
On 11-01-08 08:01, Pierre Ossman wrote:
On Fri, 11 Jan 2008 02:19:07 +0100
Rene Herman [EMAIL PROTECTED] wrote:
I see a PnP resume _consists_ of setting the resources so I can see the test
implementation wise, but yes, conceptually it seems this test shouldn't be
present. So just like
On 11-01-08 19:40, Ondrej Zary wrote:
On Friday 11 January 2008 15:21:55 Rene Herman wrote:
Hrmpf. Well, okay. Ondrej -- I assume this patch fixes things?
Yes, it works fine. 3c509 card still does not work after resume, but that
looks like another problem.
Okay. Would now only still like
On 12-01-08 12:12, Pierre Ossman wrote:
On Sat, 12 Jan 2008 02:23:27 +0100
Rene Herman [EMAIL PROTECTED] wrote:
Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for
Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test
triggering in pnp_bus_resume
On 12-01-08 16:21, Pierre Ossman wrote:
Ah, sorry. It was a different thread. Look for a mail with the subject
PNP: do not stop/start devices in suspend/resume path in the LKML och
linux-pm archives.
Right, and I see that the removal of start/stop is already in -mm. That's
not going to
-PnP cards from hibernation due to the
RES_DO_NOT_CHANGE test triggering for ALSA drivers and the pnp_start_dev()
still not happening. More in the changelog...
On 12-01-08 20:08, Rafael J. Wysocki wrote:
On Saturday, 12 of January 2008, Rene Herman wrote:
It seems all PnP drivers would need
On 13-01-08 06:50, Bjorn Helgaas wrote:
On Saturday 12 January 2008 1:08:01 pm Rene Herman wrote:
pnp-do-not-stop-start-devices-in-suspend-resume-path.patch in current -mm
breaks resuming isapnp cards from hibernation. They need the pnp_start_dev
to enable the device again after hibernation
On 14-01-08 23:26, Bjorn Helgaas wrote:
On Saturday 12 January 2008 11:13:35 pm Rene Herman wrote:
I find DISABLE including DO_NOT_CHANGE rather unexpected...
I don't know the history of those flags, but I wish they didn't exist.
They really look like warts in the PNP core code. They're
Hi Kai, Sam.
I have a single file foo.c that I want to generate two (ALSA) modules from,
snd-foo2000.ko and snd-foo2001.ko, by compiling with either FOO2000 or
FOO2001 defined.
I can do this, and ALSA does this a few times, by providing dummy foo2000.c
and foo2001.c files, like:
===
On 09/15/2007 01:13 AM, H. Peter Anvin wrote:
Rene Herman wrote:
I have a single file foo.c that I want to generate two (ALSA) modules
from, snd-foo2000.ko and snd-foo2001.ko, by compiling with either
FOO2000 or FOO2001 defined.
I can do this, and ALSA does this a few times, by providing
On 09/15/2007 10:47 AM, Adrian Bunk wrote:
On Sat, Sep 15, 2007 at 01:30:21AM +0200, Rene Herman wrote:
On 09/15/2007 01:13 AM, H. Peter Anvin wrote:
Rene Herman wrote:
I have a single file foo.c that I want to generate two (ALSA) modules
from, snd-foo2000.ko and snd-foo2001.ko
On 09/15/2007 05:53 PM, Denys Vlasenko wrote:
Can you give a bit more info what the dirrefences between devices are
in this particular cases?
It's ISA. Thanks, but never mind guys, I only wanted to know something about
kbuild.
Rene.
-
To unsubscribe from this list: send the line
Hi Andrew.
Trivial -- be explicit about printing hex.
Rene
diff --git a/lib/iomap.c b/lib/iomap.c
index a57d262..5dfcbde 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -40,7 +40,7 @@ static void bad_io_access(unsigned long port, const char
*access)
static int count = 10;
if
On 09/16/2007 10:12 AM, Jeff Garzik wrote:
So let's everybody calm down, ok?
Or rather, can everybody please just shitcan those perverted dipshits you
are replying to and get on with it? These people are here for one reason
only and that's to cause a stir -- however righteous they may feel
Hi Nicolas.
Given that it's not checking for signals, I believe this one should be an
uninterruptible sleep instead?
Signed-off-by: Rene Herman [EMAIL PROTECTED]
Rene.
diff --git a/drivers/input/touchscreen/ucb1400_ts.c
b/drivers/input/touchscreen/ucb1400_ts.c
index f0cbcdb..670dd49 100644
On 09/18/2007 06:03 PM, Nicolas Pitre wrote:
On Tue, 18 Sep 2007, Rene Herman wrote:
Hi Nicolas.
Given that it's not checking for signals, I believe this one should be an
uninterruptible sleep instead?
Probably.
Thanks. Should I send it somewhere or will you or Dmitry grab it?
Rene
On 09/18/2007 09:44 PM, Linus Torvalds wrote:
Nobody sane would *ever* argue for 16kB+ blocksizes in general.
Well, not so sure about that. What if one of your expected uses for example
is video data storage -- lots of data, especially for multiple streams, and
needs still relatively fast
On 09/19/2007 05:50 AM, Linus Torvalds wrote:
On Wed, 19 Sep 2007, Rene Herman wrote:
Well, not so sure about that. What if one of your expected uses for example is
video data storage -- lots of data, especially for multiple streams, and needs
still relatively fast machinery. Why would you
On 09/19/2007 06:33 AM, Linus Torvalds wrote:
On Wed, 19 Sep 2007, Rene Herman wrote:
I do feel larger blocksizes continue to make sense in general though. Packet
writing on CD/DVD is a problem already today since the hardware needs 32K or
64K blocks and I'd expect to see more
On 14-11-07 11:07, David Miller wrote:
Added Jaroslav and Takashi to the already extensive CC
From: Russell King [EMAIL PROTECTED]
So, when are you creating a replacement alsa-devel mailing list on
vger? That's also subscribers-only.
The operative term is alternative rather than
On 14-11-07 09:25, Takashi Iwai wrote:
At Wed, 14 Nov 2007 04:01:31 -0800 (PST),
David Miller wrote:
From: David Miller [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST)
The fact that it farts at me every time I post to this thread.
See? I got another one and I have received at
On 14-11-07 12:56, David Miller wrote:
From: Rene Herman [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 12:46:24 +0100
[EMAIL PROTECTED] is not subscriber-only. Same as that arm list,
it's _moderated_ for non-subscribers and given that I and other moderators
have been doing our best to moderate
On 14-11-07 13:01, David Miller wrote:
From: David Miller [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST)
The fact that it farts at me every time I post to this thread.
See? I got another one and I have received at least 10 of the
following over the past 2 days.
Nah, in
On 15-11-07 05:16, Bron Gondwana wrote:
Totally unrelated - I sent something to the kolab mailing list a couple
[ ... ]
I'm sure if I had something that I considered worth informing the ALSA
project of, I'd be wary of spending the same effort writing a good post
knowing it may be dropped in
On 15-11-07 00:23, David Miller wrote:
From: Takashi Iwai [EMAIL PROTECTED]
BTW, I also prefer keeping the name [EMAIL PROTECTED] It's been so.
That's fine with me, I've changed it [EMAIL PROTECTED]
Great, thanks. Jaroslav -- given that this list won't need moderation I'd
consider it
On 15-11-07 13:02, Bron Gondwana wrote:
I get the same information from both project websites: moderated for
non-members, public archives - no way of knowing that ALSA will accept
me informing them of something they would be interested without
committing to reading or bit-bucketing their list.
On 15-11-07 14:00, Jörn Engel wrote:
And even without mails being held hostage for weeks, every single
moderation mail is annoying. Like the one I'm sure to receive after
sending this out.
Certainly. Upto this thread I wasn't actually aware the list was doing that.
While it might be
On 16-11-07 08:39, Zhao Yakui wrote:
Subject: PNP: Increase the value of PNP constant
From: Zhao Yakui [EMAIL PROTECTED]
On some systems the number of resources(IO,MEM) returnedy by PNP
device is greater than the PNP constant, for example motherboard devices.
It brings that some resources
On 18-11-07 13:44, Pavel Machek wrote:
On Tue 2007-11-13 12:50:08, Mark Lord wrote:
It's a 540MByte download over a slow link for everyone
else.
Hmmm, clean-cg is 7.7G on my machine, and yes I tried
git-prune-packed. What am I doing wrong?
clean-cg? But failure to run git repack -a -d
On 18-11-07 15:35, James Bottomley wrote:
clean-cg? But failure to run git repack -a -d every once in a while?
Actually, the best command is
git gc
which does a repack (into a single pack file rather than an incremenal),
and then removes all the objects now in the pack. If, like me, you
arch/x86/kernel/setup_64.c |2
include/asm-x86/io_32.h |6 --
include/asm-x86/io_64.h | 27 +
11 files changed, 152 insertions(+), 25 deletions(-)
Rene.
commit 5001121e449040aa9cc021f69bfb191662c13004
Author: Rene Herman [EMAIL PROTECTED]
Date
On 16-12-07 22:42, H. Peter Anvin wrote:
It probably comes down to which version is bigger (you probably also
want to try uninlining.)
slow_down_io() sort of needs to stay inline due to the REALLY_SLOW_IO thing.
That stuff could use a cleanup, but that would be a diferent patch.
Thanks for
On 16-12-07 22:43, H. Peter Anvin wrote:
Again, 24 is right out. 25 is a maybe, IMO. Rene's fix could be an
exception, since it is a DMI-keyed workaround for a specific machine and
doesn't change behaviour in general.
I've not much opinion on the schedule as I've not the problem but yes,
On 17-12-07 00:12, David P. Reed wrote:
Rene Herman wrote:
David: I've plugged in your DMI values in this. Could you perhaps test
this to confirm that it works for you?
Will test it by tomorrow morning.
Might as well test the new version then. Ingo Molnar requested a few changes
On 17-12-07 03:04, H. Peter Anvin wrote:
Rene Herman wrote:
On 17-12-07 00:12, David P. Reed wrote:
Rene Herman wrote:
David: I've plugged in your DMI values in this. Could you perhaps
test this to confirm that it works for you?
Will test it by tomorrow morning.
Might as well test
On 17-12-07 03:05, H. Peter Anvin wrote:
Incidentally, I had the thought earlier today that port 0xf0 might be a
suitable delay port. It is used only by the 387-emulating-a-287 hack
for IRQ 13, which Linux doesn't use on 486+.
[EMAIL PROTECTED]:~/src/port80$ su -c ./port80
cycles: out 2400,
On 17-12-07 11:57, Ingo Molnar wrote:
thanks Rene! I've added your patch to x86.git. I changed a few things
ontop of it, see the additional changelog and delta patch below.
appropriated it, more. Definitely not going to forgive you for deleting
that comment.
void native_io_delay(void)
{
On 17-12-07 04:35, H. Peter Anvin wrote:
Well, we probably should leave the possibility in to use 0x80 -- for one
thing, we need to use 0x80 on 386, and there is always the possibility
that the switch will have different timing properties on some or all
machines.
Note that this doesn't
On 17-12-07 14:09, Ingo Molnar wrote:
-#ifndef CONFIG_UDELAY_IO_DELAY
-static int __init dmi_alternate_io_delay_port(const struct dmi_system_id *id)
+static int __init dmi_io_delay_0xed_port(const struct dmi_system_id *id)
{
- printk(KERN_NOTICE %s: using alternate I/O delay port\n,
On 17-12-07 14:31, Pavel Machek wrote:
On Mon 2007-12-17 14:22:26, Rene Herman wrote:
On 17-12-07 14:09, Ingo Molnar wrote:
-#ifndef CONFIG_UDELAY_IO_DELAY
-static int __init dmi_alternate_io_delay_port(const struct
dmi_system_id *id)
+static int __init dmi_io_delay_0xed_port(const struct
On 17-12-07 14:32, David P. Reed wrote:
Rene Herman wrote:
No, most definitely not. Having the user select udelay or none through
the kernel config and then the kernel deciding ah, you know what,
I'll know better and use port access anyway is _utterly_ broken
behaviour. Software needs
On 17-12-07 19:14, linux-os (Dick Johnson) wrote:
Attached is a patch that changes the outs to ins on port 0x80.
No, that isn't useful. Only a write is guaranteed to make ISA/LPC meaning
the timing for a read varies wildly. See the in/out cycles results posted
earlier. Was also reading the
the dv6000z DMI strings as well).
Ingo?
Signed-off-by: Rene Herman [EMAIL PROTECTED]
commit e5f4d11c2470550500e8d8b798d902f2fe07b5c4
Author: Rene Herman [EMAIL PROTECTED]
Date: Mon Dec 17 21:23:55 2007 +0100
x86: provide a DMI based port 0x80 I/O delay override.
Certain (HP) laptops
On 15-12-07 00:29, Alan Cox wrote:
?? Just initialize bogomips to 6GHz equivalent... and we are fine
until 6GHz cpus come out.
How long will that take to boot on a 386?
Well the dumb approach to fix that would seem to be to initialise it to
cpu-family 3 - 50MHz 4 - 300Mhz 5-
On 17-12-07 21:57, H. Peter Anvin wrote:
Rene Herman wrote:
On 17-12-07 17:12, Alan Cox wrote:
I don't think we should be offering udelay based delays at this point.
There are a lot of drivers to fix first. This is just one trivial
example
I agree. This thread's too full of people calling
On 17-12-07 22:41, Ingo Molnar wrote:
* Rene Herman [EMAIL PROTECTED] wrote:
On 17-12-07 17:12, Alan Cox wrote:
I don't think we should be offering udelay based delays at this point.
There are a lot of drivers to fix first. This is just one trivial example
I agree. This thread's too full
On 17-12-07 22:40, H. Peter Anvin wrote:
Rene Herman wrote:
Well, yes, I guess that does make sense. It's back again. Named the
choices standard and alternate again as I feel 0x80 and 0xed
suggest they're free values a bit too much but if anyone feels
strongly about it, so
On 17-12-07 22:56, Ingo Molnar wrote:
* Rene Herman [EMAIL PROTECTED] wrote:
Signed-off-by: Rene Herman [EMAIL PROTECTED]
hm, i see this as a step backwards from the pretty flexible patch
that David already tested. (and which also passed a few hundred
bootup tests on my x86 test-grid
On 29-11-07 18:09, Vitaliy Ivanov wrote:
Can anyone advice whether there is something similar to inotify in 2.4
kernel?
inotify is 2.6 (dnotify 2.4).
Rene
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On 29-11-07 10:11, Dave Young wrote:
The pnpacpi rsparser.c report warnings of:
exceeded the max number of IO resources: 24
dmesg|grep exceeded|wc
66 5943564
Heavens... (added CCs of people who just upped it from 8 -- I suppose the
problem is not new then?)
Rene.
-
To
On 01-12-07 00:52, Bjorn Helgaas wrote:
On Friday 30 November 2007 04:37:26 pm Rene Herman wrote:
On 30-11-07 18:04, Thomas Renninger wrote:
If I have not overseen something, it should be rather obvious that those
can all be declared __init...
---
Declare PNP option parsing
On 30-11-07 14:14, Chris Holvenstot wrote:
For what it is worth I too have seen this problem this morning and it
DOES appear to be new (in contrast to a previous comment)
The message: pnpacpi: exceeded the max number of mem resources: 12
is displayed each time the system is booted with the
On 30-11-07 11:14, Thomas Renninger wrote:
This should be 2.6.24 material:
Mark pnp_init_resource_table, pnp_resource_change, pnp_manual_config_dev
deprecated
Thanks to Rene Herman, the remaining calls to those functions got eliminated
in the sound/isa layer recently.
Those functions
On 30-11-07 18:39, Thomas Renninger wrote:
On Fri, 2007-11-30 at 18:19 +0100, Rene Herman wrote:
Thomas Renninger is making some haste with the deprecation of the removed
functions by the way -- I just saw a patch of his entering my mailbox where
he says he'd in fact like them deprecated
1 - 100 of 1135 matches
Mail list logo
