[H. Peter Anvin - Sun, Dec 30, 2007 at 12:27:15PM -0800]
> Cyrill Gorcunov wrote:
>>
>> Thanks Ingo, you're quite right! Next time i'll appear in list with real
>> (and hope usefull) patch ;)
>>
>
> Wonderful! I also *really* have to apologize for my short fuse earlier, it
> was uncalled for.
>
Hi all,
new versions of Qt4 based qgit-2.1 and stable Qt3 based qgit-1.5.8
have been released.
Download tarballs from
http://sourceforge.net/project/showfiles.php?group_id=139897
Or directly from git repositories
git://git.kernel.org/pub/scm/qgit/qgit.git (qgit-1.5.8)
on 12/31/2007 12:42 AM Jose de la Mancha wrote the following:
>
> Of course there are "RAID edition" hard drives with a feature called TLER
> (Time Limited Error Recovery) which stops the hard drive from entering into
> a deep recovery cycle. The hard drive will only spend 7 seconds to attempt
>
Hello,
I get MAC address from ioctl. However, ifconfig can change this MAC
address. Can I get a real physical MAC address of the NIC?
Thanks,
Theewara
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
This patch converts the tracing mechanism of Preempt RCU boosting into
markers. The handler functions for these markers are included inside
rcupreempt_trace.c and will be included only when PREEMPT_RCU_BOOST is
chosen.
Signed-off-by: K.Prasad <[EMAIL PROTECTED]>
---
This patch converts Preempt RCU Tracing code infrastructure to implement
markers.
- The rcupreempt_trace structure has been moved to the tracing
infrastructure and de-linked from the rcupreempt.c code. A per-cpu
instance of rcupreempt_trace structure will be maintained in
Hi Ingo,
Please accept these patches into the rt tree which convert the
existing RCU tracing mechanism for Preempt RCU and RCU Boost into
markers.
These patches are based upon the 2.6.24-rc5-rt1 kernel tree.
Along with marker transition, the RCU Tracing infrastructure has also
been
Mike Frysinger wrote:
The current asm-x86/msr.h does not actually define anything for (!__KERNEL__
&& __i386__). For x86_64, it fails to build due to u32/u64 types being used.
Simply not installing the header seems easiest to me. Otherwise, x86_64 will
need sanitizing and i386 should have
The current asm-x86/msr.h does not actually define anything for (!__KERNEL__
&& __i386__). For x86_64, it fails to build due to u32/u64 types being used.
Simply not installing the header seems easiest to me. Otherwise, x86_64 will
need sanitizing and i386 should have things added back, otherwise
On Sun, Dec 30, 2007 at 03:34:45PM -0500, Alan Stern wrote:
> On Sun, 30 Dec 2007, Ingo Molnar wrote:
>
> > * Andreas Mohr <[EMAIL PROTECTED]> wrote:
> >
> > > (yes, that's all there is, despite CONFIG_USB_DEBUG being set)
> > >
> > > The LED of a usb stick isn't active either, for obvious
On Sun, Dec 30, 2007 at 01:38:24PM +, Adrian McMenamin wrote:
> On Thu, 2007-12-27 at 14:58 -0800, Joe Perches wrote:
> > On Thu, 2007-12-27 at 16:52 +, Adrian McMenamin wrote:
> > > This patch adds support for the CD-Rom drive on the SEGA Dreamcast.
> >
> > Because it was already so
--- Carlos Corbacho <[EMAIL PROTECTED]> wrote:
>
> So do we require changes to the userspace udev rules here, or just some use
> of
> modalias in the drivers?
>
It was handled by whoever manages the distro's udev rules until now. Here's the
example:
On Sun, 30 Dec 2007 14:20:20 +0100 Oliver Pinter (Pintér Olivér) wrote:
> -- [patch is attachment]
Please send SCSI patches to [EMAIL PROTECTED] and
cc the appropriate (LPFC) maintainer, as listed in the
MAINTAINERS file.
---
~Randy
desserts: http://www.xenotime.net/linux/recipes/
--
To
On Dec 23 2007 06:13, Jeff Garzik wrote:
> Another year, another update! :)
>
> The kernel hacker's guide to git has received some updates:
>
> http://linux.yyz.us/git-howto.html
>
It says
"""Don't forget to download tags from time to time.
git pull only downloads sha1-indexed object
"Yinghai Lu" <[EMAIL PROTECTED]> writes:
> it seems in numa_default_policy()
>
> are called two times:
>
> one is in rest_init(), and another is init_post()
>
> another reason for that?
They run in different threads.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe
> As far as I can see, the kernel doesn't behave as it would be, IMO,
> normal. I do have HPETs and Linux detects them without any
> need for hpet=force (HPET is registered for clockevents), but keeps
> LAPIC as the only option for dynticks. It looks like timing devices are
> rated and then only
it seems in numa_default_policy()
are called two times:
one is in rest_init(), and another is init_post()
another reason for that?
YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
David P. Reed wrote:
H. Peter Anvin wrote:
Now, I think there is a specific reason to believe that EGA/VGA (but
perhaps not CGA/MDA) didn't need these kinds of hacks: the video cards
of the day was touched, directly, by an interminable number of DOS
applications. CGA/MDA generally *were
On Dec 30, 2007 12:46 PM, Xiaofan Chen <[EMAIL PROTECTED]> wrote:
> If you do not like the existing fsusb application, you can rewrite
> it in python with pyusb (which is based on libusb) but you do not
> need a kernel driver.
>
> pyusb: http://pyusb.berlios.de/
>
> Hex file parsing in pyk by
On Monday 31 December 2007 01:01:08 Alex Dubov wrote:
> This is exactly the same as with tifm_sd module if you noticed.
Unfortunately not, I've really never used tifm_sd as I don't have any MMC/ SD
cards.
> Second, it is impossible to guess in advance, which type of card is put
> into slot
On Dec 30, 2007 4:28 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> On Sun, Dec 30, 2007 at 04:01:39PM -0800, Yinghai Lu wrote:
> > On Dec 30, 2007 3:23 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > >
> > > On Sun, Dec 30, 2007 at 02:42:41PM -0800, Yinghai Lu wrote:
> > > > On Dec 30, 2007 2:06
H. Peter Anvin wrote:
Now, I think there is a specific reason to believe that EGA/VGA (but
perhaps not CGA/MDA) didn't need these kinds of hacks: the video cards
of the day was touched, directly, by an interminable number of DOS
applications. CGA/MDA generally *were not*, due to the
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Dec 31 2007 00:01, Carlos Corbacho wrote:
> >On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote:
> >> From: Alex Dubov <[EMAIL PROTECTED]>
> >>
> >> Sony MemoryStick cards are used in many products manufactured by Sony. They
> >> are
> However, my only concerns are that:
>
> 1) tifm_ms was not autoloaded
> 2) On loading tifm_ms, only memstick was autoloaded - mspro_block was not.
>
> Although, whether this is an issue with userspace (ie. udev) not dealing with
> the modules properly, I don't know.
>
This is exactly the
On Monday 31 December 2007 00:31:12 Jan Engelhardt wrote:
> On Dec 31 2007 00:01, Carlos Corbacho wrote:
> >On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote:
> >> From: Alex Dubov <[EMAIL PROTECTED]>
> >>
> >> Sony MemoryStick cards are used in many products manufactured by Sony.
> >>
On Dec 30, 2007 4:28 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> On Sun, Dec 30, 2007 at 04:01:39PM -0800, Yinghai Lu wrote:
> > On Dec 30, 2007 3:23 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > >
> > > On Sun, Dec 30, 2007 at 02:42:41PM -0800, Yinghai Lu wrote:
> > > > On Dec 30, 2007 2:06
Use HR-timers (when available) to deliver an accurate preemption tick.
The regular scheduler tick that runs at 1/HZ can be too coarse when nice
level are used. The fairness system will still keep the cpu utilisation 'fair'
by then delaying the task that got an excessive amount of CPU time but try
Extend group scheduling to also cover the realtime classes. It uses the time
limiting introduced by the previous patch to allow multiple realtime groups.
The hard time limit is required to keep behaviour deterministic.
The algorithms used make the realtime scheduler O(tg), linear scaling wrt the
Very simple time limit on the realtime scheduling classes.
Allow the rq's realtime class to consume sched_rt_ratio of every
sched_rt_period slice. If the class exceeds this quota the fair class
will preempt the realtime class.
TODO:
- rt limit vs load-balance
- proper interface
Signed-off-by:
I spend xmas implementing group scheduling for the realtime scheduling classes.
Its a tad raw, but seems to work for the trivial test cases I threw at it.
The hrtick stuff is unrelated but was still stuck in my sched queue.
Patches against .26-rc6-mm1
--
--
To unsubscribe from this list: send
On Dec 31 2007 00:01, Carlos Corbacho wrote:
>On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote:
>> From: Alex Dubov <[EMAIL PROTECTED]>
>>
>> Sony MemoryStick cards are used in many products manufactured by Sony. They
>> are available both as storage and as IO expansion cards.
Richard Harman wrote:
I think I may have a monkey wrench to throw into this, I finally got
around to testing the C1E patch, and the port80 patch. End result:
port80 patch has zero effect on this laptop, and the C1E patch makes
it stable.
Stating that your system is "stable" is not very
On Sun, Dec 30, 2007 at 04:01:39PM -0800, Yinghai Lu wrote:
> On Dec 30, 2007 3:23 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > On Sun, Dec 30, 2007 at 02:42:41PM -0800, Yinghai Lu wrote:
> > > On Dec 30, 2007 2:06 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > > On Sun, Dec 30, 2007 at
David P. Reed wrote:
Alan Cox wrote:
Now what's interesting is that the outb to port 80 is *faster* than
an outb to an unused port, on my machine. So there's something there
- actually accepting the bus transaction. In the ancient 5150 PC,
80 was
Yes and I even told you a while back
> In fs/cifs/cifssmb.c, in CIFSSMBSetEA (...) function wrong counting of
> var exists.
>
> EXISTING CODE:
> pSMB->DataCount = sizeof(*parm_data) + ea_value_len + name_len + 1;
>
> MUST BE:
> pSMB->DataCount = sizeof(*parm_data) + ea_value_len + name_len;
>
> REASON:
> "sizeof(*parm_data)" counts
On Sun, 2007-12-30 at 23:00 +0100, Sam Ravnborg wrote:
> Can you please remind me what problem you are actually trying to solve here.
> Your current approach it not good - we do not want .c code in include/*
> And what is wrong with the current include path?
It's not a bit deal.
inflate.c is
Mostly just stylistic comments from me here.
On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote:
> From: Alex Dubov <[EMAIL PROTECTED]>
>
> Sony MemoryStick cards are used in many products manufactured by Sony. They
> are available both as storage and as IO expansion cards. Currently,
On Dec 30, 2007 3:23 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> On Sun, Dec 30, 2007 at 02:42:41PM -0800, Yinghai Lu wrote:
> > On Dec 30, 2007 2:06 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > On Sun, Dec 30, 2007 at 12:48:48PM -0800, Yinghai Lu wrote:
> > > > On Dec 30, 2007 6:51 AM,
On Sun, 30 Dec 2007 08:36:26 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
> The C1E patch, which permits the lapic to function *does* make my
> system stable. My previous method of testing (using USB peripherals)
> and checking /proc/interrupts for ERRor interrupts so far hasn't
> caused the
On Sun, Dec 30, 2007 at 02:42:41PM -0800, Yinghai Lu wrote:
> On Dec 30, 2007 2:06 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > On Sun, Dec 30, 2007 at 12:48:48PM -0800, Yinghai Lu wrote:
> > > On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > > >
> > > > * Yinghai Lu <[EMAIL
On Dec 30 2007 23:42, Jose de la Mancha wrote:
>SHORT QUESTION :
>In a Debian-controlled RAID array, is there a parameter that handles the
>timeout before a non-responding drive is dropped from the array ? Can this
>timeout become user-adjustable in a future build ?
Not sure about Debian,
but
Alan Cox wrote:
Now what's interesting is that the outb to port 80 is *faster* than an
outb to an unused port, on my machine. So there's something there -
actually accepting the bus transaction. In the ancient 5150 PC, 80 was
Yes and I even told you a while back how to verify where
Jose de la Mancha wrote:
Hi everyone. I'm sorry but I'm not currently subscribed to this list (I've
been sent here by the listmaster), so please CC me all your
answers/comments. Thanks in advance.
SHORT QUESTION :
In a Debian-controlled RAID array, is there a parameter that handles the
timeout
Hi everyone. I'm sorry but I'm not currently subscribed to this list (I've
been sent here by the listmaster), so please CC me all your
answers/comments. Thanks in advance.
SHORT QUESTION :
In a Debian-controlled RAID array, is there a parameter that handles the
timeout before a non-responding
On Dec 30, 2007 2:06 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 30, 2007 at 12:48:48PM -0800, Yinghai Lu wrote:
> > On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > >
> > > * Yinghai Lu <[EMAIL PROTECTED]> wrote:
> > >
> > > > please check if you can replace the
Hi Kim,
On Fri, Aug 17, 2007 at 11:34:37AM -0700, K Naru wrote:
> From: Kim Naru ([EMAIL PROTECTED])
>
> Added support to offload TCP/UDP/IP checksum to the
> VIA Technologies VT6105M chip.
> Firstly, let the stack know this chip is capable of
> doing its own checksum(IPV4 only).
> Secondly
On Sunday, 30 of December 2007, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > what's exactly in the hibernation image? Dirty data i suppose
> >
> > No, everything, including the kernel code, page tables etc. :-)
> >
> > > - but what about kernel-internal pages.
rmmod capidrv never returns
this is 2.6.24-rc6 with allmodconfig
gcc version 4.2.1 (SUSE Linux)
also see https://bugzilla.novell.com/show_bug.cgi?id=350850
[ 1807.666763] capidrv: Rev 1.1.2.2: loaded
[ 1810.803450] capidrv: Rev 1.1.2.2 : unloaded
[ 1810.808417] BUG: unable to handle kernel
* Alan Cox <[EMAIL PROTECTED]> wrote:
> > ok. Like the patch below?
>
> Not quite - you still need the loop in case you NMI and then run off
> into oblivion
yes indeed. Updated patch below.
Ingo
-->
Subject: x86: hlt on early crash
From: Ingo Molnar <[EMAIL PROTECTED]>
On Sun, Dec 30, 2007 at 12:48:48PM -0800, Yinghai Lu wrote:
> On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > * Yinghai Lu <[EMAIL PROTECTED]> wrote:
> >
> > > please check if you can replace the one in the x86-mm
> > >
> > >
* Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> Teach git to ignore generated files in
> arch/x86/vdso/*
thanks Sam, applied.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Greetings!
Some of the keys on my USB-HID keyboard generate scancodes which are
bound to big keycodes in `drivers/hid/hid-input.c` and
`include/linux/input.h`, like 418, 419 or 432. Is there any possibility
to change it (in runtime, without editing `input.h` and recompiling the
kernel)? Should
* Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sun, 30 Dec 2007 21:46:50 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > well, using io_delay=udelay is not 'blindly disabling'. io_delay=none
> > would be the end goal, once all _p() API uses are eliminated by
> > transformation.
>
>
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > what's exactly in the hibernation image? Dirty data i suppose
>
> No, everything, including the kernel code, page tables etc. :-)
>
> > - but what about kernel-internal pages. What if we go from SLAB to
> > SLUB? What if the size of a
* Alan Cox <[EMAIL PROTECTED]> wrote:
> You won't bisect obscure timing triggered problems, and the _p users
> are almost all for hardware where performance doesn't matter one iota
> (eg CMOS).
actually, people have, and i have too. But i agree that io_delay=none
would be stupid now, and
On 30-12-07 22:44, H. Peter Anvin wrote:
Ingo Molnar wrote:
It probably should actually HLT, to avoid sucking power, and
stressing the thermal system. We're dead at this point, and the
early 486's which had problems with HLT will lock up - we don't care.
ok. Like the patch below?
Don't
On Sat, Dec 22, 2007 at 11:28:11AM -0800, Joe Perches wrote:
> On Sat, 2007-12-22 at 15:31 +0100, Sam Ravnborg wrote:
> > I looked at how inflate was used:
> >
> > $ grep inflate */boot/Makefile
> > alpha/boot/Makefile:$(obj)/misc.o: lib/inflate.c
> > => redundandt dependency, can be deleted
> >
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Document the fact that __save_processor_state() has to save all CPU
registers referred to by the kernel in case a different kernel is
used to load and restore a hibernation image containing it.
Sigend-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
On Dec 30, 2007 1:29 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
> > [PATCH] x86_64: fix section warning about enable_IO_APIC and
> > setup_local_APIC
> >
> > clear IO_APIC before enabing apic error vector cause link warning
> >
> > use function call
On Sunday, 30 of December 2007, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > how different can it be, for resume to work? I mean, we'll have
> > > deeply kernel version dependent variables in RAM. Am i missing
> > > something obvious?
> >
> > On x86-64 it can
On Sun, Dec 30, 2007 at 07:18:25PM +, Christoph Hellwig wrote:
> On Sun, Dec 30, 2007 at 08:06:34PM +0100, Marcin Slusarz wrote:
> > There are many places where these functions would be useful.
> > (just look at: grep -r 'cpu_to_[ble12346]*([ble12346]*_to_cpu.*[-+]'
> > linux-src/)
> > What
Ingo Molnar wrote:
It probably should actually HLT, to avoid sucking power, and stressing
the thermal system. We're dead at this point, and the early 486's
which had problems with HLT will lock up - we don't care.
ok. Like the patch below?
Don't need the cli; we're already running with
> Now what's interesting is that the outb to port 80 is *faster* than an
> outb to an unused port, on my machine. So there's something there -
> actually accepting the bus transaction. In the ancient 5150 PC, 80 was
Yes and I even told you a while back how to verify where it is. From the
Teach git to ignore generated files in
arch/x86/vdso/*
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Roland McGrath <[EMAIL PROTECTED]>
Cc: "H. Peter Anvin" <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
---
arch/x86/vdso/.gitignore|
> ok. Like the patch below?
Not quite - you still need the loop in case you NMI and then run off into
oblivion
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Cyrill Gorcunov wrote:
Thanks Ingo, you're quite right! Next time i'll appear in list with real
(and hope usefull) patch ;)
Wonderful! I also *really* have to apologize for my short fuse earlier,
it was uncalled for.
-hpa
--
To unsubscribe from this list: send the line
On Sun, 30 Dec 2007 12:53:02 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Bodo Eggert wrote:
> >
> > I've never seen code which would do that, and it was not suggested by any
> > tutorial I ever saw. I'd expect any machine to break on all kinds of
> > software
> > if it required this.
On Sun, 30 Dec 2007 21:46:50 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> well, using io_delay=udelay is not 'blindly disabling'. io_delay=none
> would be the end goal, once all _p() API uses are eliminated by
> transformation.
io_delay = none is not the end goal. Correctness is the end
> fact even io_delay=udelay would be wrong because any problem will be
> less clearly triggerable and thus less bisectable/debuggable.
And if this eats someones disk because you drive the hardware out of spec
you are going to sit there and tell them to bisect it ? Lovely.
Ingo - put the
On Dec 30, 2007 10:24 PM, J. Bruce Fields <[EMAIL PROTECTED]> wrote:
>
> On Fri, Dec 28, 2007 at 03:07:46PM -0800, Andrew Morton wrote:
> > On Fri, 28 Dec 2007 23:53:49 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Dec 23, 2007 5:27 PM, Torsten Kaiser <[EMAIL PROTECTED]>
Eduard-Gabriel Munteanu wrote:
On Sun, 30 Dec 2007 15:57:59 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
I think I may have a monkey wrench to throw into this, I finally got
around to testing the C1E patch, and the port80 patch. End result:
port80 patch has zero effect on this laptop,
On Sun, 30 Dec 2007, Ingo Molnar wrote:
> * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> > Ingo Molnar wrote:
> >> * Bodo Eggert <[EMAIL PROTECTED]> wrote:
> >>> BTW: The error function in linux-2.6.23/arch/i386/boot/compressed/misc.c
> >>> uses while(1) without cpu_relax() in order to halt the
* Rene Herman <[EMAIL PROTECTED]> wrote:
> On 30-12-07 21:46, Ingo Molnar wrote:
>> * Alan Cox <[EMAIL PROTECTED]> wrote:
>>
So the current plan is to go with an io_delay=udelay default in v2.6.25,
to give this a migration window, and io_delay=none in v2.6.26 [and a
complete
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > how different can it be, for resume to work? I mean, we'll have
> > deeply kernel version dependent variables in RAM. Am i missing
> > something obvious?
>
> On x86-64 it can be almost totally different (by restoring a
> hibernation image we
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> [PATCH] x86_64: fix section warning about enable_IO_APIC and setup_local_APIC
>
> clear IO_APIC before enabing apic error vector cause link warning
>
> use function call in setup_local_APIC to avoid that.
as i said, this just works around the link
On Sunday, 30 of December 2007, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > But i'm wondering - are we really ever resuming to a different
> > > kernel version, for this to be an issue?
> >
> > The boot kernel may be different from the kernel within the image,
[PATCH] x86_64: fix section warning about enable_IO_APIC and setup_local_APIC
clear IO_APIC before enabing apic error vector cause link warning
use function call in setup_local_APIC to avoid that.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Index: linux-2.6/arch/x86/kernel/smpboot_64.c
On Fri, Dec 28, 2007 at 03:07:46PM -0800, Andrew Morton wrote:
> On Fri, 28 Dec 2007 23:53:49 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
>
> > On Dec 23, 2007 5:27 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> > > On Dec 23, 2007 8:30 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > >
I am so happy that there will be a way for people who don't build their
own kernels to run Linux on their HP and Compaq laptops that have
problems with gazillions of writes to port 80, and I'm also happy that
some of the strange driver code will be cleaned up over time. Thank you
all. Some
> But that does't mean that other ports won't have the same timings. Also,
> it doesn't mean that we really need to have exactly *those* timings.
For ISA bus you want "at least" those timings. That is an easy case
anyway - ISA bus boxes, old processors and generally no TSC so we can
fall back to
On Sun, 30 Dec 2007 15:57:59 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
> I think I may have a monkey wrench to throw into this, I finally got
> around to testing the C1E patch, and the port80 patch. End result:
> port80 patch has zero effect on this laptop, and the C1E patch makes
> it
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>> * Bodo Eggert <[EMAIL PROTECTED]> wrote:
>>
>>> BTW: The error function in linux-2.6.23/arch/i386/boot/compressed/misc.c
>>> uses while(1) without cpu_relax() in order to halt the machine. Is this
>>> fixed? Should it be
On Sun, Dec 30, 2007 at 05:10:41PM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > i've added your full patch meanwhile - maybe we can get away with it.
>
> i needed the trivial fix below. You did not test-build it on 32-bit it
> appears :-)
Had
On Sun, 30 Dec 2007 15:42:17 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> Eduard-Gabriel Munteanu <[EMAIL PROTECTED]> writes:
> >
> > Other kernel developers, as discussed previously in this thread, are
> > working on a HPET-driven dynticks (as opposed to the current
> > LAPIC-driven one), but
* Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> This patch eliminates checkpatch.pl complains on bootflag.c
thanks, applied this to x86.git, to the v2.6.25 queue. See the finalized
patch below. (I added two more small cleanups that checkpatch did not
warn about but which were obvious)
On Sun, Dec 30, 2007 at 04:06:02PM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > Combine the 32 and 64 bit specific Makefiles in one file. While
> > > doing so link order was (almost) preserved on 32 bit but on 64 bit
> > > link order changed a lot.
> > >
> >
On 30-12-07 21:46, Ingo Molnar wrote:
* Alan Cox <[EMAIL PROTECTED]> wrote:
So the current plan is to go with an io_delay=udelay default in v2.6.25,
to give this a migration window, and io_delay=none in v2.6.26 [and a
complete removal of arch/x86/kernel/io_delay.c], once the _p() uses are
Eduard-Gabriel Munteanu wrote:
On Sun, 30 Dec 2007 03:49:21 +0200
Note that this problem is only related to AMD64 multi-core laptops. As
far as I can see, devs might not invest much coding effort into this
and instead say "Go buy an Intel laptop!", as this really is a hardware
quirk. And if
[Ingo Molnar - Sun, Dec 30, 2007 at 06:22:50PM +0100]
|
| * Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
|
| > orig:
| > mbr_base = (buf_base+sector_size-1) & ~(sector_size-1);
| > new (could be):
| > mbr_base = (buf_base + sector_size - 1) & ~(sector_size - 1);
| >
| > Is a new version that bad?
Ingo Molnar wrote:
* Bodo Eggert <[EMAIL PROTECTED]> wrote:
BTW: The error function in
linux-2.6.23/arch/i386/boot/compressed/misc.c uses while(1) without
cpu_relax() in order to halt the machine. Is this fixed? Should it be
fixed?
this is early bootup so there's no need to be "nice" to
Juergen Beisert wrote:
On Sunday 30 December 2007 16:38, Alan Cox wrote:
do you have any memories about the outb_p() use of misc_32.c:
pos = (x + cols * y) * 2; /* Update cursor position */
outb_p(14, vidport);
outb_p(0xff & (pos >> 9), vidport+1);
Bodo Eggert wrote:
I've never seen code which would do that, and it was not suggested by any
tutorial I ever saw. I'd expect any machine to break on all kinds of software
if it required this. The only thing I remember being warned about is writing
the index and the data register at the same
* Alan Cox <[EMAIL PROTECTED]> wrote:
> > So the current plan is to go with an io_delay=udelay default in v2.6.25,
> > to give this a migration window, and io_delay=none in v2.6.26 [and a
> > complete removal of arch/x86/kernel/io_delay.c], once the _p() uses are
> > fixed up. This is gradual
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > But i'm wondering - are we really ever resuming to a different
> > kernel version, for this to be an issue?
>
> The boot kernel may be different from the kernel within the image, if
> that's what you're asking for.
how different can it be,
On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
> > please check if you can replace the one in the x86-mm
> >
> > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ffcbdc220a1520d006a837f33589c7c19ffbeb76
>
On 29-12-07 10:09, Richard Harman wrote:
Anyway, I'm extremely open to getting to the bottom of working around
the quirks on this hardware. If I havn't mentioned it previously, this
laptop is an HP dv6408nr, with an amd turion tl-56 cpu and nVidia MCP51
chipset.
What can I do to help? It
On Sunday, 30 of December 2007, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Document the fact that __save_processor_state() has to save all CPU
> > registers referred to by the kernel in case a different kernel
On Sun, Dec 30, 2007 at 09:18:38PM +0100, Jan Engelhardt wrote:
>
> On Dec 30 2007 21:11, [EMAIL PROTECTED] wrote:
> >
> >i build a kernel with allmodconfig and didn`t get my system to boot with
> >that.
> >
> >after some investigation i found that it was due to udev:
> >
> >udevd[1226]:
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> So even if that "port 80" access will also cause PCI postings to be
> flushed, so would the actual IO access that accompanies it, so I don't
> think that is a very strong argument.
>
> With all that said: it is certainly possible that the 1us
On Sun, 30 Dec 2007, Ingo Molnar wrote:
> * Andreas Mohr <[EMAIL PROTECTED]> wrote:
>
> > (yes, that's all there is, despite CONFIG_USB_DEBUG being set)
> >
> > The LED of a usb stick isn't active either, for obvious reasons.
> >
> > And keep in mind that this is a (relatively old) OHCI-only
1 - 100 of 442 matches
Mail list logo
