On Sat, 2005-07-16 at 19:35 -0700, Nish Aravamudan wrote:
> As you've seen, I think it depends on the timesource: for the PIT, it
> would be arch/i386/kernel/timers/timer_pit.c::setup_pit_timer().
That one looks pretty straightforward.
arch/i386/kernel/timers/timer_tsc.c really looks like fun. S
On Sun, 2005-07-17 at 04:38 +0200, Adrian Bunk wrote:
> SCSI_QLA2XXX is automatically enabled for (SCSI && PCI).
This has bugged me for a while. Why does this one SCSI driver default
to Y in the first place?
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
On Sun, 2005-07-17 at 04:13 +0200, Jesper Juhl wrote:
> Where do we actually program the tick rate we want?
>
In arch/i386/kernel/timers/timer_pit.c:
166 void setup_pit_timer(void)
167 {
168 unsigned long flags;
169
170 spin_lock_irqsave(&i8253_lock, flags);
On Thu, 2005-07-14 at 09:57 +1000, Con Kolivas wrote:
> On Thu, 14 Jul 2005 03:34, Lee Revell wrote:
> > On Wed, 2005-07-13 at 13:27 +0200, szonyi calin wrote:
> > > I have the following problem with audio:
> > > Xmms is running with threads for audio and spectrum
> &
On Fri, 2005-07-15 at 14:01 +1000, Con Kolivas wrote:
> Interbech is a an application is designed to benchmark interactivity in Linux.
>
> Version 0.21 update
>
> http://ck.kolivas.org/apps/interbench/interbench-0.21.tar.bz2
>
I would suggest using microseconds for both the RT and non RT tests.
On Fri, 2005-07-15 at 14:01 +1000, Con Kolivas wrote:
> his makes a large difference to the latencies measured under mem_load
> particularly when running real time benchmarks on a RT-PREEMPT kernel
Here are some results from my 600MHz C3. In realtime mode, the
PREEMPT_RT kernel performs as expect
On Fri, 2005-07-15 at 14:24 -0500, Lee wrote:
> Hi,
>
> > > [20975.978911] PREEMPT SMP DEBUG_PAGEALLOC
> > > [20976.029194] Modules linked in: vmnet vmmon nvidia
> > > [20976.090907] CPU:695757158
> > > [20976.090909] EIP:0060:[]Tainted: P VLI
> >
> > Please reproduce the bug with
On Fri, 2005-07-15 at 14:04 -0500, Lee wrote:
> [20975.978911] PREEMPT SMP DEBUG_PAGEALLOC
> [20976.029194] Modules linked in: vmnet vmmon nvidia
> [20976.090907] CPU:695757158
> [20976.090909] EIP:0060:[]Tainted: P VLI
Please reproduce the bug without these proprietary modules lo
On Thu, 2005-07-14 at 22:54 -0600, Zwane Mwaikambo wrote:
> On Fri, 15 Jul 2005, Lee Revell wrote:
>
> > On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
> > > Audio did show slightly larger max latencies but nothing that would be of
> > > significance.
On Fri, 2005-07-15 at 08:57 -0700, Christoph Lameter wrote:
> Try HPET which is pretty standard these days.
>
Really? None of my machines have it. I suspect lots of "embeddable"
systems don't either.
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
> Audio did show slightly larger max latencies but nothing that would be of
> significance.
>
> On video, maximum latencies are only slightly larger at HZ 250, all the
> desired cpu was achieved, but the average latency and number of missed
On Fri, 2005-07-15 at 03:55 +0300, Zvi Rackover wrote:
> hello all,
>
> i wish to write a module for i386 that can hook interrupts. the module
> loads its own interrupt descriptor table instead of the default
> system's table. after executing my own handler(s), the old appropriate
> handler will b
On Fri, 2005-07-15 at 02:04 +0200, Jesper Juhl wrote:
> While reading this thread it occoured to me that perhaps what we
> really want (besides sub HZ timers) might be for the kernel to
> auto-tune HZ?
>
> Would it make sense to introduce a new config option (say
> CONFIG_HZ_AUTO) that when select
On Thu, 2005-07-14 at 16:49 -0700, Linus Torvalds wrote:
>
> On Thu, 14 Jul 2005, Lee Revell wrote:
> >
> > And I'm incredibly frustrated by this insistence on hard data when it's
> > completely obvious to anyone who knows the first thing about MIDI that
> &
On Thu, 2005-07-14 at 16:49 -0700, Linus Torvalds wrote:
> YOUR argument is "nobody else matters, only I do".
>
> MY argument is that this is a case of give and take.
I wouldn't say that. I do agree with you that HZ=1000 for everyone is
problematic, I just feel that a reasonable compromise is C
On Thu, 2005-07-14 at 16:25 -0700, Linus Torvalds wrote:
> On Thu, 14 Jul 2005, Lee Revell wrote:
> > This thread has really gone OT, but to revisit the original issue for a
> > bit, are you still unwilling to consider leaving the default HZ at 1000
> > for 2.6.13?
>
&g
On Thu, 2005-07-14 at 16:25 -0700, Linus Torvalds wrote:
> Yes. I see absolutely no point to it until I actually hear people who have
> actually tried some real load that doesn't work. Dammit, I want a real
> user who says that he can noticeable see his DVD stuttering, not some
> theory.
>
> I'
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> I have to say, this whole thread has been pretty damn worthless in
> general in my not-so-humble opinion.
>
This thread has really gone OT, but to revisit the original issue for a
bit, are you still unwilling to consider leaving the defau
On Thu, 2005-07-14 at 20:58 +0100, Alistair John Strachan wrote:
> the responsiveness of our instrument to 300us which is low enough
> for the real-time PCR industry
PCR, as in polymerase chain reaction? They can do that in realtime?
Impressive.
Lee
-
To unsubscribe from this list: send the li
On Thu, 2005-07-14 at 08:02 -0700, Christoph Lameter wrote:
> I doubt that increasing the timer frequency is the way to go to solve
> these issues. HZ should be as low as possible and we should strive for
> a tickless system.
Agreed. Most of those applications are driven by their own interrupt
s
On Thu, 2005-07-14 at 10:38 +0200, Ingo Molnar wrote:
> - there are real-time applications (robotic environments: fast rotating
>tools, media and mobile/phone applications, etc.) that want 10
>usecs precision. If such users increased HZ to 100,000 or even
>1000,000, the current timer i
On Thu, 2005-07-14 at 11:24 +0200, Jan Engelhardt wrote:
> "My expectation is if we want to beat the competition, we'll want
> the ability to go *under* 100Hz."
> >>>
> >>> What does Windows do here?
> >>
> >> windows xp base rate is 100Hz... but multimedia apps can ask for almost
> >
>
On Wed, 2005-07-13 at 18:13 -0700, dean gaudet wrote:
> http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx
Did anyone else find this strange:
"The RTC is used in periodic mode to provide the system profiling
interrupt on uni-processor systems and the clock interrupt on
multi-processor systems
On Wed, 2005-07-13 at 18:13 -0700, dean gaudet wrote:
> On Wed, 13 Jul 2005, Chris Wedgwood wrote:
>
> > On Wed, Jul 13, 2005 at 04:41:41PM -0700, dean gaudet wrote:
> >
> > > windows xp base rate is 100Hz... but multimedia apps can ask for
> > > almost any rate they want (depends on the hw capab
On Tue, 2005-07-12 at 23:58 -0700, Paul Jackson wrote:
> Dick Johnson wrote:
> > Or just disallow tabs altogether. At Analogic we ...
>
> This is the Linux kernel, not Analogic.
>
> We use tabs for indentation. You can set the number
> of physical spaces per tab however you want in your
> editor
On Tue, 2005-07-12 at 22:05 -0700, Linus Torvalds wrote:
> I think the shortlog speaks for itself.
HZ still defaults to 250. As was explained in another thread, this will
break apps like MIDI sequencers and won't really save much battery
power.
The default should remain 1000 until these issues a
On Wed, 2005-07-13 at 14:16 -0700, Chris Wedgwood wrote:
>(1) ACPI/SMM suckage in laptops
Anything that loses ticks at 1000HZ is unsuitable for serious multimedia
use anyway, so I think this part of the argument isn't as important.
Also, I don't know that anyone has a list of machines with the
On Wed, 2005-07-13 at 14:16 -0700, Chris Wedgwood wrote:
> Both can be detected from you .config and we could see HZ as needed
> there and everyone else could avoid this surely?
Does anyone object to setting HZ at boot? I suspect nothing else will
make everyone happy.
Lee
-
To unsubscribe from
On Wed, 2005-07-13 at 14:32 -0500, Dmitry Torokhov wrote:
> Hi,
>
> On 7/13/05, Lee Revell <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-07-13 at 12:10 -0700, Linus Torvalds wrote:
> > > So we should aim for a HZ value that makes it easy to convert to and from
On Wed, 2005-07-13 at 12:33 -0700, Martin J. Bligh wrote:
>
> --On Wednesday, July 13, 2005 14:32:02 -0500 Dmitry Torokhov <[EMAIL
> PROTECTED]> wrote:
>
> > Hi,
> >
> > On 7/13/05, Lee Revell <[EMAIL PROTECTED]> wrote:
> >> On Wed, 2005-07-13
On Wed, 2005-07-13 at 15:11 -0400, Bill Davidsen wrote:
> Paul Slootman wrote:
> > Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> >
> >>What's the gain in parking the head manually if it's done anyway when the
> >>disk
> >>spins down (for whatever reason)?
> >
> >
> > It seems you're completely
On Wed, 2005-07-13 at 12:10 -0700, Linus Torvalds wrote:
> So we should aim for a HZ value that makes it easy to convert to and from
> the standard user-space interface formats. 100Hz, 250Hz and 1000Hz are all
> good values for that reason. 864 is not.
How about 500? This might be good enough to
On Wed, 2005-07-13 at 10:51 -0700, Linus Torvalds wrote:
>
> On Wed, 13 Jul 2005, Lee Revell wrote:
>
> > On Tue, 2005-07-12 at 22:05 -0700, Linus Torvalds wrote:
> > > I think the shortlog speaks for itself.
> >
> > HZ still defaults to 250. As was ex
On Wed, 2005-07-13 at 13:27 +0200, szonyi calin wrote:
> I have the following problem with audio:
> Xmms is running with threads for audio and spectrum
> analyzer(OpenGL).
> The audio eats 5% cpu, the spectrum analyzer about 80 %. The
> problem is that sometimes the spectrum analyzer is eating all
On Wed, 2005-07-13 at 08:35 +0200, Ingo Molnar wrote:
> * Lee Revell <[EMAIL PROTECTED]> wrote:
>
> > > I have found that heavy network traffic really kills the interactive
> > > performance. In the top excerpt below, gtk-gnutella is generating ab
On Wed, 2005-07-13 at 11:59 -0400, Bill Davidsen wrote:
> Theodore Ts'o wrote:
> > The real answer here is for the tickless patches to cleaned up to the
> > point where they can be merged, and then we won't waste battery power
> > entering the timer interrupt in the first place. :-)
>
> And that
On Wed, 2005-07-13 at 12:26 -0400, Bill Davidsen wrote:
> >
> > Going to HZ=864 would fix this problem. It would likely cause other
> > problems in places that expect 1/HZ to be a sane number, though.
> >
> But if you are going to an "odd" value, would 1381 would be a better
> choice, given the
On Tue, 2005-07-12 at 15:22 -0700, Martin J. Bligh wrote:
>
> --On Tuesday, July 12, 2005 16:58:44 -0400 Lee Revell <[EMAIL PROTECTED]>
> wrote:
>
> > On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
> >> Some sort of comprimise has to be struck for now
On Tue, 2005-07-12 at 21:18 -0400, Lee Revell wrote:
> On Mon, 2005-07-04 at 13:16 +0200, Ingo Molnar wrote:
> > i'd first suggest to try the latest kernel, before changing your X
> > config - i think the bug might have been fixed meanwhile.
>
> I have found that he
On Mon, 2005-07-04 at 13:16 +0200, Ingo Molnar wrote:
> i'd first suggest to try the latest kernel, before changing your X
> config - i think the bug might have been fixed meanwhile.
I have found that heavy network traffic really kills the interactive
performance. In the top excerpt below, gtk-g
On Tue, 2005-07-12 at 19:37 -0400, Keenan Pepper wrote:
> but I'm not sure if that's right. I guess I'll see when I try to boot it!
>
The standard fix is to make it a compat_semaphore. See the list
archives for details.
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
/300 seems like a reasonable comprimise to me. Exactly what problems
> *does* it cause (in visible effect, not "timers are less granular").
> Jittery audio/video? How much worse is it?
OK, here's a real world example, taken straight from the linux-audio-dev
list today.
Lee
On Mon, 2005-07-11 at 17:07 +0200, Ingo Molnar wrote:
> I've uploaded -27 with the fix - but it should
> only confirm that it's not a stack overflow.
V0.7.51-28 does not compile:
CC [M] sound/oss/emu10k1/midi.o
sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__'
sound/oss/
On Tue, 2005-07-12 at 15:55 -0400, Keenan Pepper wrote:
> Ingo Molnar's realtime-preempt patches used to be based on the -mm
> kernels, but now they appear to be based on the mainline kernels, so
> they don't support reiser4 (at least until reiser4 is merged into
> mainline, which is looking unc
On Tue, 2005-07-12 at 08:08 -0700, Martin J. Bligh wrote:
> Well, looking forward, you'll have sub-HZ timers, so none of this will
> matter. Actually, looking at the above, 150 seems perfectly reasonable
> to me, but 300 seems to be close enough. I'll run some numbers on
> both.
>
> From your abov
On Tue, 2005-07-12 at 10:55 -0700, David Lang wrote:
> On Tue, 12 Jul 2005, Lee Revell wrote:
>
> > On Tue, 2005-07-12 at 05:17 -0700, David Lang wrote:
> >> for example a series 1 DirectTv tivo manages to write two program
> >> streams to disk while reading and vi
On Tue, 2005-07-12 at 05:17 -0700, David Lang wrote:
> for example a series 1 DirectTv tivo manages to write two program
> streams to disk while reading and viewing a third
Actually it writes two streams to disk while reading and viewing one of
them, unless they released a model with three tuners.
On Tue, 2005-07-12 at 08:08 -0700, Martin J. Bligh wrote:
> Well, looking forward, you'll have sub-HZ timers, so none of this will
> matter. Actually, looking at the above, 150 seems perfectly reasonable
> to me, but 300 seems to be close enough. I'll run some numbers on both.
>
> >From your above
On Tue, 2005-07-12 at 21:52 +1000, Con Kolivas wrote:
> > Well, it's just the default settings of the kernel which has changed. If
> > you want the old behaviour, you can use (with your admin hat):
> > echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice
> > IMHO it seems quite fair,
On Tue, 2005-07-12 at 07:56 -0700, Martin J. Bligh wrote:
> --Lee Revell <[EMAIL PROTECTED]> wrote (on Tuesday, July 12, 2005 10:24:59
> -0400):
>
> > On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
> >> Exactly what problems
> >> *does* it ca
On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
> Exactly what problems
> *does* it cause (in visible effect, not "timers are less granular").
> Jittery audio/video? How much worse is it?
Yes, exactly. Say you need to deliver a frame of audio or video every
5ms. You have a rendering th
On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
> Look back in the thread. It made kernel compiles about 5% faster on a
> fairly large box. I think the SGI people did it originally because it
> caused them even larger problems.
>
Right, I saw those, but you don't expect to change the de
On Mon, 2005-07-11 at 21:07 -0700, Martin J. Bligh wrote:
>
> --Lee Revell <[EMAIL PROTECTED]> wrote (on Monday, July 11, 2005 20:30:59
> -0400):
>
> > On Mon, 2005-07-11 at 14:39 -0600, Chris Friesen wrote:
> >> Lee Revell wrote:
> >>
> >> &g
On Mon, 2005-07-11 at 15:38 +0100, Alistair John Strachan wrote:
> I realise 4KSTACKS is a considerable rework of the IRQ handler, etc. and
> probably even more heavily modified by rt-preempt, but is there nothing else
> that can be tested before a serial console run?
>
Well, netconsole is a lo
On Mon, 2005-07-11 at 11:38 -0700, Martin J. Bligh wrote:
> >> Lots of people have switched from 2.4 to 2.6 (100 Hz to 1000 Hz) with no
> >> impact in
> >> stability, AFAIK. (I only remember some weird warning about HZ with debian
> >> woody's
> >> ps).
> >>
> >
> > Yes, that's called "progress
On Mon, 2005-07-11 at 14:39 -0600, Chris Friesen wrote:
> Lee Revell wrote:
>
> > Tickless + sub HZ timers is a win for everyone, the multimedia people
> > get better latency, and the laptop people get to run longer.
>
> IIRC it's not a win for many systems. Thro
On Tue, 2005-06-21 at 19:03 +0100, James Courtier-Dutton wrote:
> linux-2.6.12-rc6-mm1 fails to even boot on my system. See previous
> email for details.
>
> I have the same problem with 2 different laptops, and those laptops
> had different pcmcia chips, so that is why I suspect the pcmcia-core.
On Mon, 2005-07-11 at 13:04 +0200, Stelian Pop wrote:
> Oops, bad Evolution (even if I did use insert->text file for the patch).
>
> Going back to mutt. Sorry about this.
There's no need to go back to mutt, Evolution is not broken. Before
doing 'Insert->Text File', you just have to change the te
On Mon, 2005-07-11 at 11:38 -0700, Martin J. Bligh wrote:
> That's a very subjective viewpoint. Realize that this is a balancing
> act between latency and overhead ... and you're firmly only looking
> at one side of the argument, instead of taking a comprimise in the
> middle ...
>
> If I start ar
On Sat, 2005-07-09 at 13:30 -0700, randy_dunlap wrote:
> | Then the owners of such machines can use HZ=250 and leave the default
> | alone. Why should everyone have to bear the cost?
>
> indeed, why should everyone have to have 1000 timer interrupts per second?
So why waste everyone's time with
On Sat, 2005-07-09 at 12:12 -0700, Andrew Morton wrote:
> Lee Revell <[EMAIL PROTECTED]> wrote:
> >
> > > This is not a userspace visible thing really with few exceptions, and
> > > well people can select the one they want, right?
> >
> > Then wh
On Sat, 2005-07-09 at 14:41 -0400, Lee Revell wrote:
> Yes, that's called "progress" so no one complained. Going back is
> called a "regression". People don't like those as much.
Sorry for the tone of this message, I really sound like a jerk.
Anyway, I&
On Sat, 2005-07-09 at 20:39 +0200, Diego Calleja wrote:
> El Sat, 09 Jul 2005 14:16:31 -0400,
> Lee Revell <[EMAIL PROTECTED]> escribió:
>
> > I still think you're absolutely insane to change the default in the
> > middle of a stable kernel series. People WILL co
On Sat, 2005-07-09 at 20:31 +0200, Arjan van de Ven wrote:
> why?
Because the minimum poll/select timeout is now 4ms rather than 1ms. An
app that has a soft RT constraint somewhere in the middle that worked on
2.6.12 will break on 2.6.13.
> it's a config option. Some distros ship 100 already, ot
On Sat, 2005-07-09 at 20:22 +0200, Peter Zijlstra wrote:
> I once made a patch so that the front and back channels were inverted
> but I lost it somewhere. And since I'm a lazy ass I kept using the OSS
> driver. It's not as if I actually use my sblive for anything else but
> the occasional mp3. But
On Sat, 2005-07-09 at 19:08 +0200, Martin Schlemmer wrote:
> On Fri, 2005-07-08 at 14:59 -0700, Andrew Morton wrote:
> > Chris Wedgwood <[EMAIL PROTECTED]> wrote:
>
> > > WHAT?
> > >
> > > The previous value here i386 is 1000 --- so why is the default 250.
> >
> > Because 1000 is too high.
> >
On Sat, 2005-07-09 at 16:29 +0200, Peter Zijlstra wrote:
> [] emu10k1_audio_release+0x114/0x210 [emu10k1] (40)
Kind of OT, but any particular reason you're using this old OSS driver?
It's likely to be deprecated soon, and the ALSA driver is much more
actively maintained...
Lee
-
To unsubscribe
On Fri, 2005-07-08 at 16:29 -0700, David S. Miller wrote:
> From: "Martin J. Bligh" <[EMAIL PROTECTED]>
> Date: Fri, 08 Jul 2005 16:14:59 -0700
>
> > I'm not saying there isn't data supporting higher HZ ... I just haven't
> > seen it published. I get the feeling what people really want is high-res
On Fri, 2005-07-08 at 15:03 -0700, Phil Oester wrote:
> On Fri, Jul 08, 2005 at 11:25:08PM +0200, Alexander Nyberg wrote:
> > fre 2005-07-08 klockan 23:12 +0200 skrev Rudo Thomas:
> > > Hello, guys.
> > >
> > > Time started to pass faster with 2.6.12.2 (actually, it was 2.6.12-ck3
> > > which is b
On Fri, 2005-07-08 at 14:59 -0700, Andrew Morton wrote:
> Chris Wedgwood <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
> ^^
>
> It's been over two weeks and nobody has complained about anything.
Wrong, I complained loud
On Thu, 2005-07-07 at 10:38 -0700, Dave Hansen wrote:
> On Thu, 2005-07-07 at 19:27 +0200, Jens Axboe wrote:
> > On Thu, Jul 07 2005, Clemens Koller wrote:
> > > Well, sure, it's not a notebook HDD, but maybe it's possible
> > > to give headpark a more generic way to get the heads parked?
> >
> >
On Wed, 2005-07-06 at 10:44 -0400, Michael Krufky wrote:
> bttv is now maintained by Mauro Carvalho Chehab
> <[EMAIL PROTECTED]>, as part of the video4linux project. I am
> forwarding this to Mauro and the video4linux list. Linux and Kernel
> Video
Where's the MAINTAINERS patch?
Lee
-
To un
On Wed, 2005-07-06 at 11:02 -0400, Piszcz, Justin wrote:
> You probably aren't going to get any help with this until you reproduce
> the problem without the vm* binary-only drivers.
>
Also without nvidia.
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Tue, 2005-07-05 at 18:13 -0700, William Weston wrote:
> Audio without xruns is an RT requirement, IMHO ;-}
>
This isn't even an opinion, it's a fact. If you are capturing data and
your audio handling thread does not get scheduled in (periods_per_buffer
- 1) * period_time time units, you lose
On Tue, 2005-07-05 at 16:54 +0100, Alan Cox wrote:
> On Gwe, 2005-07-01 at 20:42, Sean Bruno wrote:
> > This is pretty much the reaction that I am getting from calling ASUS
> > tech support. They have told me on several occasions that they will
> > "call me back" and never do.
>
> Ditto with pro
On Tue, 2005-07-05 at 06:29 -0600, Alejandro Bonilla wrote:
> .Alejandro
> (removing some people so they don't get triplicated emails)
Please don't trim cc: lists! We *want* the duplicate emails, so that
one goes in the Inbox and one in the LKML folder.
See the list archives for more reasons why
On Mon, 2005-07-04 at 11:36 -0700, dean gaudet wrote:
> as for other details it's trivial to lock the daemon in memory and run
> it at nice -4 to get a head start on parking even when at 100% cpu and
> under memory load.
>
Negative nice values are not the correct solution when dealing with RT
con
On Wed, 2005-04-20 at 18:05 +, Francesco Oppedisano wrote:
> Hi,
> i'd like to know how much time does linux kernel run with disabled
> interrupts. So i would like to remap the instructions capable of
> disabling interrupt to other ones which count how much this time is...
> Does already exist
On Tue, 2005-04-19 at 22:00 +0200, Nico Schottelius wrote:
> Can you tell me which ones?
>
Multimedia apps like JACK and mplayer that use the TSC for high res
timing need to know the CPU speed, and /proc/cpuinfo is the fast way to
get it.
Why don't you create sysfs entries instead? It would be
On Tue, 2005-04-19 at 09:24 -0400, Lennart Sorensen wrote:
> On Tue, Apr 19, 2005 at 02:15:30PM +0200, Nico Schottelius wrote:
> > When I wrote schwanz3(*) for fun, I noticed /proc/cpuinfo
> > varies very much on different architectures.
> >
> > Is it possible to make it look more identical (as fa
On Thu, 2005-04-14 at 19:34 -0400, Lee Revell wrote:
> Here's the patch from that thread against 2.6.12-rc2. It also fixes an
> unrelated typo in nearby code. Obviously untested, as I don't have the
> hardware ;-)
>
> Summary: Enable write combining for server wo
On Fri, 2005-04-15 at 11:40 -0700, Daniel Souza wrote:
> A way to "protect" system calls is, after boot a trusted kernel image,
> take a MD5 of the syscalls functions implementations (the opcodes that
> are part of sys_read for example) and store it in a secure place.
That's the problem, once the
On Fri, 2005-04-15 at 18:15 +, Allison wrote:
> Once these are loaded into the kernel, is there no way the kernel
> functions can be protected ?
No. If the attacker can load arbitrary code into the kernel, game over.
Think about it.
Lee
-
To unsubscribe from this list: send the line "unsubs
On Fri, 2005-04-15 at 13:33 -0400, Malita, Florin wrote:
> On Fri, 2005-04-15 at 13:16 -0400, Richard B. Johnson wrote:
> > I'm not sure there really are any "kernel" rootkits. You need to be
> > root to install a module and you need to be root to replace a kernel
> > with a new (possibly altered
On Thu, 2005-04-14 at 21:18 -0400, Patrick McFarland wrote:
> On Thursday 07 April 2005 07:17 am, Patrick McFarland wrote:
> > Nope, 2.6.7 is also fubar. Now to 2.6.6.
>
> I haven't tested 2.6.6 yet, but 2.6.12-rc2-mm3 is broken too.
>
There's no point in testing newer kernels if you have yet to
On Fri, 2005-04-15 at 02:16 +0200, Christian Kujau wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Lee Revell wrote:
> >
> > Fixed in 2.6.11.7.
> >
>
> thank you & sorry for the noise.
No need to apologize, this is not noise. Always err
On Fri, 2005-04-15 at 01:22 +0200, Christian Kujau wrote:
> maybe some guru can shed some light on what's going on in xmms-oops.txt
> and tell me who's to bug here :->
Fixed in 2.6.11.7.
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EM
/www.ussg.iu.edu/hypermail/linux/kernel/0104.3/1007.html
Signed-Off-By: Lee Revell <[EMAIL PROTECTED]>
--- linux-2.6.12-rc2-k7/arch/i386/kernel/cpu/mtrr/main.c~ 2005-04-14
19:29:31.0 -0400
+++ linux-2.6.12-rc2-k7/arch/i386/kernel/cpu/mtrr/main.c2005-04-14
19:29:16.0
On Thu, 2005-04-14 at 18:46 -0400, abonilla wrote:
> On Thu, 14 Apr 2005 17:15:16 -0400, Lee Revell wrote
> > On Thu, 2005-04-14 at 16:58 -0400, Shawn Starr wrote:
> > > We just need to figure
> > > out to get the specs from IBM
> >
> > Best bet is proba
On Thu, 2005-04-14 at 16:58 -0400, Shawn Starr wrote:
> We just need to figure
> out to get the specs from IBM
Best bet is probably reverse engineering it...
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
On Thu, 2005-04-14 at 14:43 -0600, Bjorn Helgaas wrote:
> On Thu, 2005-04-14 at 13:11 -0400, Lee Revell wrote:
> > I get this message occasionally on both my machines. I googled and saw
> > some references to this message on 2.4 but nothing for 2.6. Some of the
> > reference
I get this message occasionally on both my machines. I googled and saw
some references to this message on 2.4 but nothing for 2.6. Some of the
references were to APIC, which I don't have enabled.
Both machines are using VIA chipsets and display the "VIA IRQ fixup"
message on boot. I think this
On Thu, 2005-04-14 at 18:19 +0200, Christoph Hellwig wrote:
> On Thu, Apr 14, 2005 at 09:18:32AM -0700, Dmitry Yusupov wrote:
> > Consider linux-iscsi-5.x CVS branch as a "mainline". Current open-iscsi
> > SVN repository is the place where all hard-core development will happen
> > at least for the
On Thu, 2005-04-14 at 13:48 +0200, Geert Uytterhoeven wrote:
> On Tue, 12 Apr 2005, Andrew Morton wrote:
> > As the commits list probably isn't working at present I'll cc linux-kernel
> > on this lot. Fairly cruel, sorry, but I don't like the idea of people not
> > knowing what's hitting the main
I am having a problem with the RT preempt kernels where xscreensaver
will cause the X server to consume excessive CPU, starving other
processes. This should not happen as xscreensaver runs at the highest
nice value. It seems that there's some kind of priority inversion
happening between the high
On Sun, 2005-04-10 at 19:47 +0200, Ingo Molnar wrote:
> yeah, that's what i did in -45-01.
>
Ingo,
This build failure was reported with 45-01 by an AMD64 user. Do you
need the .config?
HOSTCC scripts/bin2c
CC arch/x86_64/kernel/asm-offsets.s
CHK include/asm-x86_64/offset.h
UP
On Tue, 2005-04-12 at 15:26 -0700, Trond Myklebust wrote:
> ty den 12.04.2005 Klokka 15:22 (-0400) skreiv Xin Zhao:
> > I have very very fast network and is testing NFS2 over this kind of
> > network. I noticed that for standard work like read/write a large
> > file, compile kernels, the performan
On Tue, 2005-04-12 at 11:49 -0700, Linus Torvalds wrote:
>
> On Tue, 12 Apr 2005, Lee Revell wrote:
> >
> > Um... why in the heck are you posting this here instead of alsa-devel?
>
> Which list do you think has more people interested? ppc64 or alsa?
>
OK, makes
On Tue, 2005-04-12 at 15:07 +1000, Benjamin Herrenschmidt wrote:
> Hi !
>
> (Andrew: This is an update of the previous patch, it fixes a problem
> with headphone beeing incorrectly muted on some models).
>
> This patch hacks the current PowerMac Alsa driver to add some basic
> support of analog s
On Mon, 2005-04-11 at 15:12 -0400, Lee Revell wrote:
> On Mon, 2005-04-11 at 11:38 -0700, Mingming Cao wrote:
> > I will work on a patch for Lee to try sometime tonight.
> >
>
> Just FYI, this will take a while to test, because this latency seems
> quite rare. I haven&
301 - 400 of 631 matches
Mail list logo
