4 days ago I had Ubuntu Lucid running on this computer. Suspend and
resume worked flawlessly every time.
Then I upgraded to Ubuntu Precise. Suspend seems to work, but resume
fails every time. The video never initializes. By the flashing
keyboard lights, I guess it's a kernel panic. It fails from
12:03:13 PM Tim Hockin wrote:
>> 4 days ago I had Ubuntu Lucid running on this computer. Suspend and
>> resume worked flawlessly every time.
>>
>> Then I upgraded to Ubuntu Precise.
>
> Well, do you use a distro kernel or a kernel.org kernel?
>
>> Suspend see
it was
worth sending this new info along, anyway.
It did not require 'noapic' on the Lucid (2.6.32?) kernel
On Sat, Dec 29, 2012 at 9:34 PM, Tim Hockin wrote:
> Running a suspend with pm_trace set, I get:
>
> aer :00:03.0:pcie02: hash matches
>
> I don't know wha
;ll try a vanilla kernel next, maybe hack on AER a bit, to see if I
can make it progress.
On Sat, Dec 29, 2012 at 10:19 PM, Tim Hockin wrote:
> Quick update: booting with 'noapic' on the commandline seems to make
> it resume successfully.
>
> The main dmesg diffs, ot
On Sun, Dec 30, 2012 at 2:55 PM, Rafael J. Wysocki wrote:
> On Saturday, December 29, 2012 11:17:11 PM Tim Hockin wrote:
>> Best guess:
>>
>> With 'noapic', I see the "irq 5: nobody cared" message on resume,
>> along with 1 IRQ5 counts in /proc/i
Hi Tejun,
This email worries me. A lot. It sounds very much like retrograde
motion from our (Google's) point of view.
We absolutely depend on the ability to split cgroup hierarchies. It
pretty much saved our fleet from imploding, in a way that a unified
hierarchy just could not do. A mandated
On Mon, Apr 22, 2013 at 11:41 PM, Tejun Heo wrote:
> Hello, Tim.
>
> On Mon, Apr 22, 2013 at 11:26:48PM +0200, Tim Hockin wrote:
>> We absolutely depend on the ability to split cgroup hierarchies. It
>> pretty much saved our fleet from imploding, in a way that a unified
&g
ied hierarchies goes
against everything that we're doing here, and will cause us REAL pain.
On Mon, Apr 22, 2013 at 3:33 PM, Tim Hockin wrote:
> On Mon, Apr 22, 2013 at 11:41 PM, Tejun Heo wrote:
>> Hello, Tim.
>>
>> On Mon, Apr 22, 2013 at 11:26:48PM +0200, Tim Hocki
On Mon, Jun 24, 2013 at 5:01 PM, Tejun Heo wrote:
> Hello, Tim.
>
> On Sat, Jun 22, 2013 at 04:13:41PM -0700, Tim Hockin wrote:
>> I'm very sorry I let this fall off my plate. I was pointed at a
>> systemd-devel message indicating that this is done. Is it so? It
&
On Wed, Jun 26, 2013 at 2:20 PM, Tejun Heo wrote:
> Hello, Tim.
>
> On Mon, Jun 24, 2013 at 09:07:47PM -0700, Tim Hockin wrote:
>> I really want to understand why this is SO IMPORTANT that you have to
>> break userspace compatibility? I mean, isn't Linux supposed to be
On Wed, Jun 26, 2013 at 6:04 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Jun 26, 2013 at 05:06:02PM -0700, Tim Hockin wrote:
>> The first assertion, as I understood, was that (eventually) cgroupfs
>> will not allow split hierarchies - that unified hierarchy would be the
>&
On Thu, Jun 27, 2013 at 6:22 AM, Serge Hallyn wrote:
> Quoting Mike Galbraith (bitbuc...@online.de):
>> On Wed, 2013-06-26 at 14:20 -0700, Tejun Heo wrote:
>> > Hello, Tim.
>> >
>> > On Mon, Jun 24, 2013 at 09:07:47PM -0700, Tim Hockin wrote:
>> >
Changing the subject, so as not to mix two discussions
On Thu, Jun 27, 2013 at 9:18 AM, Serge Hallyn wrote:
>
>> > FWIW, the code is too embarassing yet to see daylight, but I'm playing
>> > with a very lowlevel cgroup manager which supports nesting itself.
>> > Access in this POC is low-level ("
On Thu, Jun 27, 2013 at 11:11 AM, Serge Hallyn wrote:
> Quoting Tim Hockin (thoc...@hockin.org):
>
>> For our use case this is a huge problem. We have people who access
>> cgroup files in a fairly tight loops, polling for information. We
>> have literally hundeds of jo
On Thu, Jun 27, 2013 at 10:38 AM, Tejun Heo wrote:
> Hello, Tim.
>
> On Wed, Jun 26, 2013 at 08:42:21PM -0700, Tim Hockin wrote:
>> OK, then what I don't know is what is the new interface? A new cgroupfs?
>
> It's gonna be a new mount option for cgroupfs.
>
On Thu, Jun 27, 2013 at 11:14 AM, Serge Hallyn wrote:
> Quoting Tejun Heo (t...@kernel.org):
>> Hello, Serge.
>>
>> On Thu, Jun 27, 2013 at 08:22:06AM -0500, Serge Hallyn wrote:
>> > At some point (probably soon) we might want to talk about a standard API
>> > for these things. However I think it
On Fri, Jun 28, 2013 at 9:31 AM, Serge Hallyn wrote:
> Quoting Tim Hockin (thoc...@hockin.org):
>> On Thu, Jun 27, 2013 at 11:11 AM, Serge Hallyn
>> wrote:
>> > Quoting Tim Hockin (thoc...@hockin.org):
>> >
>> >> For our use case this is a huge pro
On Thu, Jun 27, 2013 at 2:04 PM, Tejun Heo wrote:
> Hello,
>
> On Thu, Jun 27, 2013 at 01:46:18PM -0700, Tim Hockin wrote:
>> So what you're saying is that you don't care that this new thing is
>> less capable than the old thing, despite it having real impact.
>
On Fri, Jun 28, 2013 at 8:53 AM, Serge Hallyn wrote:
> Quoting Daniel P. Berrange (berra...@redhat.com):
>> Are you also planning to actually write a new cgroup parent manager
>> daemon too ? Currently my plan for libvirt is to just talk directly
>
> I'm toying with the idea, yes. (Right now my
On Fri, Jun 28, 2013 at 8:05 AM, Michal Hocko wrote:
> On Thu 27-06-13 22:01:38, Tejun Heo wrote:
>> Oh, that in itself is not bad. I mean, if you're root, it's pretty
>> easy to play with and that part is fine. But combined with the
>> hierarchical nature of cgroup and file permissions, it enc
On Fri, Jun 28, 2013 at 12:21 PM, Serge Hallyn wrote:
> Quoting Tim Hockin (thoc...@hockin.org):
>> On Fri, Jun 28, 2013 at 9:31 AM, Serge Hallyn
>> wrote:
>> > Quoting Tim Hockin (thoc...@hockin.org):
>> >> On Thu, Jun 27, 2013 at 11:11 AM, Serge Hally
Come on, now, Lennart. You put a lot of words in my mouth.
On Fri, Jun 28, 2013 at 6:48 PM, Lennart Poettering wrote:
> On 28.06.2013 20:53, Tim Hockin wrote:
>
>> a single-agent, we should make a kick-ass implementation that is
>> flexible and scalable, and full-featured eno
On Sun, Jun 30, 2013 at 12:39 PM, Lennart Poettering
wrote:
> Heya,
>
>
> On 29.06.2013 05:05, Tim Hockin wrote:
>>
>> Come on, now, Lennart. You put a lot of words in my mouth.
>
>
>>> I for sure am not going to make the PID 1 a client of another daemon.
&
A year later - what ever happened with this? I want it more than ever
for Google's use.
On Tue, Jan 31, 2012 at 7:37 PM, Frederic Weisbecker wrote:
> Hi,
>
> Changes In this version:
>
> - Split 32/64 bits version of res_counter_write_u64() [1/10]
> Courtesy of Kirill A. Shutemov
>
> - Added K
On Mon, Apr 1, 2013 at 11:46 AM, Tejun Heo wrote:
> On Mon, Apr 01, 2013 at 11:43:03AM -0700, Tim Hockin wrote:
>> A year later - what ever happened with this? I want it more than ever
>> for Google's use.
>
> I think the conclusion was "use kmemcg instead"
On Mon, Apr 1, 2013 at 1:29 PM, Tejun Heo wrote:
> On Mon, Apr 01, 2013 at 01:09:09PM -0700, Tim Hockin wrote:
>> Pardon my ignorance, but... what? Use kernel memory limits as a proxy
>> for process/thread counts? That sounds terrible - I hope I am
>
> Well, the argu
On Mon, Apr 1, 2013 at 3:03 PM, Tejun Heo wrote:
> Hello, Tim.
>
> On Mon, Apr 01, 2013 at 02:02:06PM -0700, Tim Hockin wrote:
>> We run dozens of jobs from dozens users on a single machine. We
>> regularly experience users who leak threads, running into the tens of
>>
On Mon, Apr 1, 2013 at 3:35 PM, Tejun Heo wrote:
> Hey,
>
> On Mon, Apr 01, 2013 at 03:20:47PM -0700, Tim Hockin wrote:
>> > U so that's why you guys can't use kernel memory limit? :(
>>
>> Because it is completely non-obvious how to map between
On Mon, Apr 1, 2013 at 4:18 PM, Tejun Heo wrote:
> Hello,
>
> On Mon, Apr 01, 2013 at 03:57:46PM -0700, Tim Hockin wrote:
>> I am not limited by kernel memory, I am limited by PIDs, and I need to
>> be able to manage them. memory.kmem.usage_in_bytes seems to be far
>>
All,
is it possible to detect whether a device is running at 66MHz (as opposed
to 33)? PCI defines a 66MHz capable bit, but not a 66MHz enabled bit. We
have a silly device that seems to need to know what it's bus speed is, but
have no way to tell from software (that I know of).
So, pray tell -
> disallowed CPU on which it is already running. And even a non-RT
> process will stick on its disallowed CPU as long as nothing else runs
> there.
are we going to keep the cpus_allowed API? If we want the (IMHO) more
flexible sysmp() API - I'll finish the 2.4 port. If we are going to keep
cpu
> > use vanilla 2.4.x, you can simply copy drivers/net/starfire.c from the -ac
> > tree.
>
> I can't use 2.4 kernels ATM because they don't boot (at all) on Cobalt
> hardware for some reason - when I've got chance I'll look into it and try
> and fix the 2.4 kernels so they work on Cobalt kit, but
> Is it possible to bind a process to a specific
> cpu on this SMP machine (process affinity) ?
>
> I there something like pset ?
http://isunix.it.ilstu.edu/~thockin/pset - pset for linux-2.2 (not ported
to 2.4 yet)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
I'm noticing these messages:
mtrr: base(0xd400) is not aligned on a size(0x180) boundary
:many times in dmesg. System is a dual P3-933 on a MSI 694D board (Apollo
Pro 133).
Is it worrisome?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
> On Mon, 15 Jan 2001, Tim Hockin wrote:
>
> > Motherboard (MSI 694D-AR) has Via Apollo Pro chipset, those IDE drives seem
> > fine. Board also has a promise PDC20265 RAID/ATA100 controller. On each
> > channel of this controller I have an IBM 45 GB ATA100 drive as
I haven't received messages in a few days at least...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Just built a new system with Linux-2.4.0.
Motherboard (MSI 694D-AR) has Via Apollo Pro chipset, those IDE drives seem
fine. Board also has a promise PDC20265 RAID/ATA100 controller. On each
channel of this controller I have an IBM 45 GB ATA100 drive as master.
(hde and hdg?). BIOS sees these
> And if anybody else understands pirq routing, speak up. It's a black art.
>
I have some experience with PIRQ and Serverworks, but I missed the first
bit of this discussion - can someone catch me up?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
> > patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
> > 0x44 and 0x45 are probably ID's of two primary buses and the code should scan
> > both of them, but not the space between them.
>
0x44 is the primary bus number of the host bridge, and 0x45 is the
subordinat
> "THIS CHANGE CAUSED PROBLEMS FOR SOME APPLICATION CODE."
>
> _Which_ applications?
>
> _Why_ did they have a problem? Was this due to a bug or were they
> designed to do stuff this way?
I, for one, have an app that relies on syscalls not being restarted:
app g
> >From searching Google, I know some sort of driver exists. In July, Adam J.
> Richter ([EMAIL PROTECTED]) posted a 2.2.16 driver he obtained from Dave
> Gotwisner at Wyse Technologies. And Tim Hockin mentioned that he was using
> an NSC driver, but had made some minor modifi
> Without syncing, Linux writes whenever it thinks it's appropriate, e.g.
> when pages have to be freed (I think also when the bdflush writes back
> data, i.e. every 30 seconds by default).
what about mmap() on non-filesystem files (/dev/mem, /proc/bus/pci...) ?
-
To unsubscribe from this list:
> > Device 00:01.0 (slot 0): ISA bridge
> > INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> > INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> > INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> > INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
>
> Your "link" v
On 4/13/05, Dave Jones <[EMAIL PROTECTED]> wrote:
> If we have a situation where we screw a subset of users with the
> config option =y and a different subset with =n, how is this improving
> the situation any over what we have today ?
Dave,
What's a good alternative? Do we need to keep a white
lcome this option, but otherwise I'd rather like to use the measuring
> code in IDE driver as it requires no user intervention to get the right
> timing.
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/drivers/p
Attached is a patch for cleaning up some PCI ids and adding a few that were
missing. Please let me know of any problems with this.
(diff against 2.4.5)
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/drivers/pci
inclusion.
This patch also includes support for a configurable 'max failures'
parameter, and one change for better DMA error reporting.
Tim
Andre Hedrick wrote:
>
> Bring it on! ;-)
>
> On Tue, 27 Mar 2001, Tim Hockin wrote:
>
> > Andre,
> >
> > I'm
All,
Attached is a patch for sym53c8xx.c to handle the error timer better, and
be more proper for SMP. The changes are very simple, and have been beaten
on by us. Please let me know if there are any problems accepting this
patch for general inclusion.
Tim
--
Tim Hockin
Systems Software
earlier).
Please let me know if you have any problems with this for general
inclusion.
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
earlier).
Please let me know if you have any problems with this for general
inclusion.
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/drivers/ide/hpt366.c cobalt-2.4.5/drivers/ide/hpt366.c
--- dist-2.4.5/drivers/ide
Alan,
Aattached is a (large, but self contained) patch for Cobalt Networks suport
for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there
is anything that would prevent this from general inclusion in the next
release.
(patch against 2.4.5)
Thanks
Tim
--
Tim Hockin
Systems
Add a rwproc entry to the ide structure, for recalling what happened last
time!
Please let me knwo if there are any problems with this patch (some of the
patches I sent earlier depend on this).
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL
know if there
is anything that would prevent this from general inclusion in the next
release.
(patch against 2.4.5)
Thanks
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/drivers/cobalt/README cobalt-2.4.5/driver
know if there
is anything that would prevent this from general inclusion in the next
release.
(patch against 2.4.5)
Thanks
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/drivers/cobalt/acpi.c cobalt-2.4.5/driver
> Looks interesting. Seemingly literate use of spinlocks.
thanks - I gave it lots of thought.
> Off-hand I see old style initialization. Is it right for new driver?
the old-style init is because it is an old driver. I want to do a full-on
rework, but haven't had the time.
> i2c framework is n
Thanks for all the comments, so far. I'm going to incorporate all the
changes mentioned, and resubmit the questioned patches.
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "u
crew to get at
LEAST the adapters/algorithms submitted for general inclusion. Once that
is in, I will make cobalt_i2c go away.
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe l
All,
attached is a (small) patch which saves the src address on tcp_accept().
Please let me know if there are any problems taking this for general
inclusion.
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/net
ed to 2.4.x yet - should be easy, and is a more
complete implementation of sysmp() than the others..
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
On Sun, Aug 07, 2005 at 01:36:01PM +0200, Andi Kleen wrote:
> Erick Turnquist <[EMAIL PROTECTED]> writes:
>
> > Hi, I'm running an Athlon64 X2 4400+ (a dual core model) with an
> > nVidia GeForce 6800 Ultra on a Gigabyte GA-K8NXP-SLI motherboard and
> > getting nasty messages like these in my dmes
On Sun, Aug 07, 2005 at 02:46:50PM -0400, Erick Turnquist wrote:
> > Some BIOSes do not lock SMM, and you *could* turn it off at the chipset
> > level.
>
> I don't see anything about SMM in my BIOS configuration even with the
> advanced options enabled... Turning it off at the chipset level sounds
On Sun, Aug 07, 2005 at 02:51:19PM -0400, Lee Revell wrote:
> > It's most likely bad SMM code in the BIOS that blocks the CPU too long
> > and is triggered in idle. You can verify that by using idle=poll
> > (not recommended for production, just for testing) and see if it goes away.
> >
>
> WTF,
On Mon, Aug 08, 2005 at 02:01:25PM +0200, Andi Kleen wrote:
> > Some BIOSes do not lock SMM, and you *could* turn it off at the chipset
> > level.
>
> Doing so would be wasteful though. Both AMD and Intel CPUs need SMM code
> for the deeper C* sleep states.
Really? I'm not too familiar with the
On Mon, Jan 31, 2005 at 08:22:11AM +0100, Emmanuel Fleury wrote:
> Jan 30 00:58:21 hermes vmunix: alim7101_wdt: ALi 1543 South-Bridge does
> not have the correct revision number (???1001?) - WDT
> not set
>
> What did I do wrong ?
You used the wrong South Bridge revision. Seriously, older revisi
On Mon, Jan 31, 2005 at 01:55:59PM -0500, Mike Waychison wrote:
> FWIW, some of the old cobalt boxes had the old south bridge revision
> with a WDT. It managed to do resets/wdt off gpio pin 5 though, and
> there is a patch in Alan's 2.6.10-ac tree that handles it.
The old Cobalts also had a PIC a
Hey all,
I just had an eepro/100 S delivered to me. I haven't dug through specs
yet, but has anyone looke at this? Supposedly has a 3DES ASIC built in to
the core.
Any way we can use it?
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
aking nvram_open_cnt SMP
safe, or should it just go away all together. I vote for the latter
option, unless something depends on this behavior (in which case, other
fixes are needed, because it is broken :).
comments?
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[
> /usr/src/linux-2.4.6/include/linux/mtd/cfi.h: In function `cfi_spin_unlock':
> /usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: `do_softirq' undeclared
> (first use in this function)
> /usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: (Each undeclared identifier
> is reported only once
> /usr
ng
obvious bug in. If you read the spec carefuly, it is obviously correct.
You have to set DMA up for read vs. write. Does this make your problems go
away? DIff against 2.4.3
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -u dist-2
The attached patch fixes the MOXA driver properly. Indexing is 0 based, so
rather than adjust the enum, don't subtract 1 from each index. Also use a
for loop for the PCI devices, and up the version number.
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appli
It seems OK to me.
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
--- /home/users/admin/C26/III/linux-2.2/drivers/scsi/sym53c8xx.cTue May 15
19:14:48 2001
+++ /usr/src/linux/drivers/scsi/sym53c8xx.c Wed May 16 22:
s distros is not easy. Add to that it requires
YACC, when most people have bison (yes, a shell script is easy to make, but
not always an option).
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
On 7/12/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> -- there may be other edge cases other than
> this one. I'm actually surprised that this wasn't a ring buffer to start
> with -- it certainly seems like it wanted to be one.
The problem with a ring buffer is that it would lose old entries; but
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
The MCE handler has several paths that it can take, depending on various
conditions of the MCE status and the value of the 'tolerant' knob. The
exact semantics are not well defined and the code is a bit twisty.
Description:
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
The MCE handler already has an idle-task handler which checks for the
TIF_MCE_NOTIFY flag. Given that the system is idle at that point, we can
get even better granularity of MCE logging by polling for MCEs whenever
we enter the idl
There were other patches which added more COBALT support, but they
were dropped or lost or whatever.
I would not balk at having that code yanked. I never got around to
doing proper Cobalt support for modern kernels. :(
On 6/3/07, Roland Dreier <[EMAIL PROTECTED]> wrote:
> > > there is no Kc
I think the nvram is the only place left that uses CONFIG_COBALT
On 6/3/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
On Sun, 3 Jun 2007, Tim Hockin wrote:
> There were other patches which added more COBALT support, but they
> were dropped or lost or whatever.
>
> I would
That sounds correct.
On 6/3/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
On Sun, 3 Jun 2007, Tim Hockin wrote:
> I think the nvram is the only place left that uses CONFIG_COBALT
sure, but once you remove this snippet near the top of
drivers/char/nvram.c:
...
# if defined(CONF
On 5/18/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> * If RIPV is set it is not safe to restart, so set the 'no way out'
>flag rather than the 'kill it' flag.
Why? It is not PCC. We cannot return of course, but killing isn't returning.
My understanding is that the absence of RIPV
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
/dev/mcelog is a clear-on-read interface. It is currently possible for
multiple users to open and read() the device. Users are protected from
each other during any one read, but not across reads.
Description:
This patch adds suppo
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especially when we are trying really hard to stress the system out. The
current MCE poller uses a static interval which does not care whether it
has or has not
On 27 Apr 2007 11:09:17 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Thu, Apr 26, 2007 at 06:02:52PM -0700, Tim Hockin wrote:
> Description:
> This patch makes the MCE poller adjust the polling interval dynamically.
> If we find an MCE, poll 2x faster (down to 10 ms). When
On 27 Apr 2007 19:02:30 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Fri, Apr 27, 2007 at 09:58:14AM -0700, Tim Hockin wrote:
> On 27 Apr 2007 11:09:17 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >On Thu, Apr 26, 2007 at 06:02:52PM -0700, Tim Hockin wrote:
> &g
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especially when we are trying really hard to stress the system out. The
current MCE poller uses a static interval which does not care whether it
has or has not
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especially when we are trying really hard to stress the system out. The
current MCE poller uses a static interval which does not care whether it
has or has not
Sorry, Gmail mangles whitespace unless you do just the right thing.
Let me work around it. Proper patch coming.
On 4/27/07, Tim Hockin <[EMAIL PROTECTED]> wrote:
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
We've found that MCEs (specifically DRAM SBEs) tend t
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especially when we are trying really hard to stress the system out. The
current MCE poller uses a static interval which does not care whether it
has or has not
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
some situations. Calling poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup o
[] smp_apic_timer_interrupt+0x4e/0x70
[] apic_timer_interrupt+0x66/0x70
On 4/29/07, Tim Hockin <[EMAIL PROTECTED]> wrote:
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
some situations. Calling poll() on /dev/mcelog d
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
/dev/mcelog is a clear-on-read interface. It is currently possible for
multiple users to open and read() the device. Users are protected from
each other during any one read, but not across reads.
Description:
This patch adds suppo
On 5/1/07, Rafal Bilski <[EMAIL PROTECTED]> wrote:
2.6.21.1 is first kernel which I'm using at this device. Earlier it was
WindowsCE terminal. It is hardware fault. Commenting out the code is my
way to avoid "wakeup" messages in log, but I don't want to change anything
in vanilla kernel. I'm luc
On 5/2/07, Rafal Bilski <[EMAIL PROTECTED]> wrote:
What about module option?
Looks ok to me, if this is the preferred route.
---
drivers/net/natsemi.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index 349b96a
Newer version coming in a while. Testing.
On 4/30/07, Tim Hockin <[EMAIL PROTECTED]> wrote:
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. C
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/
In some sense a cgroup is a pgrp that mere mortals can't escape. Why
not just do something like that? root can set this "container id" or
"job id" on your process when it first starts (e.g. docker sets it on
your container process) or even make a cgroup that sets this for all
processes in that cg
I don't buy that it is not practical. Not convenient, maybe. Not
clean, sure. But it is practical - it uses mechanisms that exist on
all kernels today. That is a win, to me.
On Thu, Mar 13, 2014 at 10:58 AM, Simo Sorce wrote:
> On Thu, 2014-03-13 at 10:55 -0700, Andy Lutomirski wrote:
>>
>> S
wait till you can
> unless it's urgent.
Yeah sorry. Replying from my phone is awkward at best. I know better :)
> On Wed, Dec 11, 2013 at 09:37:46PM -0800, Tim Hockin wrote:
>> The immediate problem I see with setting aside reserves "off the top"
>> is that we don
On Thu, Dec 12, 2013 at 11:23 AM, Tejun Heo wrote:
> Hello, Tim.
>
> On Thu, Dec 12, 2013 at 10:42:20AM -0800, Tim Hockin wrote:
>> Yeah sorry. Replying from my phone is awkward at best. I know better :)
>
> Heh, sorry about being bitchy. :)
>
>> In my mind, the ON
1 - 100 of 112 matches
Mail list logo
