On Sunday 20 May 2007, Stefan Richter wrote:
> maybe we should change
>
> /* argument to RAW1394_IOC_GET_CYCLE_TIMER ioctl */
> struct raw1394_cycle_timer {
> /* contents of Isochronous Cycle Timer register,
> as in OHCI 1.1 clause 5.13 (also with non-OHCI hosts) */
> __
On Sun, 20 May 2007 the mental interface of
WANG Cong told:
> On Sun, May 20, 2007 at 01:11:13PM +0200, Elimar Riesebieter wrote:
> >Hi,
> >
> >FYI, building the kernel with
> >gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7)
> >on my powerbook (PPC) gives:
> >
> >...
> >fs/partitions/check.
On 5/20/07, Ray Lee <[EMAIL PROTECTED]> wrote:
On 5/19/07, Al Viro <[EMAIL PROTECTED]> wrote:
> On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> > Ken? Ball's in your court. As the patch isn't providing a killer
> > feature for 2.6.22, I'd suggest just reverting it for now until the
> >
Arnd Bergmann wrote:
> On Sunday 20 May 2007, Stefan Richter wrote:
>> maybe we should change
...
>> struct raw1394_cycle_timer {
...
>> before a libraw1394 with get-cycle-timer support is released.
>
> Yes, if you still have the chance to change this without breaking
> users, that would be ideal.
In fact, while it's never worded explicitely in the spec, it's always
been strongly in the "spirit" of the architecture that the timebase and
decrementer have a constant frequency.
The architecture mentions varying time base frequencies,
and how to deal with this, actually. It makes no
recommen
On Sunday 20 May 2007, Kay Sievers wrote:
> On 5/20/07, Ray Lee <[EMAIL PROTECTED]> wrote:
> > On 5/19/07, Al Viro <[EMAIL PROTECTED]> wrote:
> > > On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> > > > Ken? Ball's in your court. As the patch isn't providing a killer
> > > > feature for 2
On Sunday 20 May 2007, Ray Lee wrote:
> On 5/19/07, Al Viro <[EMAIL PROTECTED]> wrote:
> > On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> > > Ken? Ball's in your court. As the patch isn't providing a killer
> > > feature for 2.6.22, I'd suggest just reverting it for now until the
> > >
On Sun, 20 May 2007 13:21:11 +0200
Folkert van Heusden <[EMAIL PROTECTED]> wrote:
> > I do not see such on i386, so why for x86_64?
> > >>>So that you know that one of your programs crashed. That's a feature.
> > >>This feature could be handy for i386 too.
> > >Since 2.6.18.2 I use this patch.
On 5/20/07, Kay Sievers <[EMAIL PROTECTED]> wrote:
On 5/20/07, Ray Lee <[EMAIL PROTECTED]> wrote:
> On 5/19/07, Al Viro <[EMAIL PROTECTED]> wrote:
> > On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> > > Ken? Ball's in your court. As the patch isn't providing a killer
> > > feature for
> > > I do not see such on i386, so why for x86_64?
> > > >>>So that you know that one of your programs crashed. That's a feature.
> > > >>This feature could be handy for i386 too.
> > > >Since 2.6.18.2 I use this patch. With 2.6.21.1 it still applies altough
> > > >with a small offsets. Works
On 5/20/07, Andrey Borzenkov <[EMAIL PROTECTED]> wrote:
On Sunday 20 May 2007, Ray Lee wrote:
> The when part is what looks to make it racy. I'm guessing that we're
> relying on udev to create those loop nodes. If so, I think any scheme
> that creates more on demand would give transient mount err
On Sun, 2007-05-20 at 09:10 -0700, Ray Lee wrote:
> On 5/20/07, Kay Sievers <[EMAIL PROTECTED]> wrote:
> > On 5/20/07, Ray Lee <[EMAIL PROTECTED]> wrote:
> > > On 5/19/07, Al Viro <[EMAIL PROTECTED]> wrote:
> > > > On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> > > > > Ken? Ball's in yo
Andrey Borzenkov <[EMAIL PROTECTED]> writes:
> On Sunday 20 May 2007, Kay Sievers wrote:
>>
>> Until the tools can request dynamic loop device allocation from the
>> kernel before they want to use the device, you can create as many as
>> needed "static" loop* nodes in /lib/udev/devices/, which wil
omparison under
the same conditions.
One odd thing i noticed, with 2.6.21-cfs-v13 the gnome's time applet in
the bar skipped some minutes (e.g. 16:23 -> 16:25) several times.
The data is available on:
http://www.debianPT.org/~elmig/pool/kernel/20070520/
How did you get your data?
Am Sonntag, 20. Mai 2007 18:16 schrieben Sie:
> On Sun, 2007-05-20 at 09:10 -0700, Ray Lee wrote:
> > On 5/20/07, Kay Sievers <[EMAIL PROTECTED]> wrote:
> > > On 5/20/07, Ray Lee <[EMAIL PROTECTED]> wrote:
> > > > On 5/19/07, Al Viro <[EMAIL PROTECTED]> wrote:
> > > > > On Sat, May 19, 2007 at 11:1
On Sun, 20 May 2007, Robert P. J. Day wrote:
> i can do that as long as there's no way that those changes can (even
> theoretically) make a difference in the build. in order to make sure
> this patch didn't break anything, i went with a straight cut-and-paste
> of the content to go into the new m
at the same time. (At minimum: the
scheduler, cpu, and video card.)
One odd thing i noticed, with 2.6.21-cfs-v13 the gnome's time applet in
the bar skipped some minutes (e.g. 16:23 -> 16:25) several times.
The data is available on:
http://www.debianPT.org/~elmig/pool/kernel/20070520/
Ho
On Sat, May 19, 2007 at 16:34 -0700, Andrew Morton wrote:
> On Sun, 20 May 2007 00:30:55 +0200 "Sasa Ostrouska" <[EMAIL PROTECTED]> wrote:
>
> > Hi everybody,
> >
> > I tried today to upgrade the kernel to 2.6.21.1 and i got the same
> > error during the boot time.
> > Here is the dmesg of the 2.
n't compare
absolute values on different test setups.
One odd thing i noticed, with 2.6.21-cfs-v13 the gnome's time applet in
the bar skipped some minutes (e.g. 16:23 -> 16:25) several times.
The data is available on:
http://www.debianPT.org/~elmig/pool/kernel/20070520/
How did yo
On Sun, May 20, 2007 at 01:37:13PM +0300, [EMAIL PROTECTED] wrote:
> Hello Oleg,
>
> I've done some more tests and quite frankly I think this is really related
> to the dreaded ''fglrx.ko'' module. It seems to me that it is much easier
> to reproduce the problem if that damn module is loaded. It
Indan Zupancic wrote:
>> The change was made primarily to make libata spin down disks properly on
>> power down and hibernate. I don't like the added delay either but it's
>> better than shortening the lifespan of harddisks.
>
> Ah, it fixes that "weird noise on shutdown" problem? Fair enough.
Y
On Fri, May 18, 2007 at 06:08:54AM +0200, Nick Piggin wrote:
> If we add 8 bytes to struct page on 64-bit machines, it becomes 64 bytes,
> which is quite a nice number for cache purposes.
We had those hardware alignment for many data structures where they
were only wasting memory (i.e. vmas).
The
On Sun, 20 May 2007, David Rientjes wrote:
> On Sun, 20 May 2007, Robert P. J. Day wrote:
>
> > i can do that as long as there's no way that those changes can
> > (even theoretically) make a difference in the build. in order to
> > make sure this patch didn't break anything, i went with a straigh
Indan Zupancic wrote:
>> Can you try to measure with sd_resume in place?
>
> [2.173366] sd 0:0:0:0: [sda] Starting disk
> [2.475422] ata2: SATA link down (SStatus 0 SControl 310)
> [5.478403] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [5.481928] ata1.00: ata_hpa_resiz
[EMAIL PROTECTED] wrote:
Mybe I am wrong, but if you are detecting 40-wire cable to set them to
DMA/33, why the check includes also 80-wire cables configuring them to
DMA/33 too?
With this patch my nvidia4 IDE controllers detects correctly and
configure correctly DMA/100 for my HD and DMA/3
On 5/20/07, Miguel Figueiredo <[EMAIL PROTECTED]> wrote:
> It doesn't look like you were running his glitch1 script which starts
> several in glxgears parallel. Were you, or were you just running one?
No i'm not, i'm running only one instance of glxgears inside the GNOME's
environment.
Then no
Tjenarvi Tjenarvi wrote:
> When WITHOUT ATA/ATAPi/MFM/RLL support, but I couldn't boot it, I got
> kernel panic. Here is the last 10 lines messages:
>
> VFS : Mounted root (ext2 filesystem)
> No kernel modules found for Linux.2.6.22-rc1
> VFS: Cannot open root device "301" or unknown-block (3,1)
[EMAIL PROTECTED] wrote:
>
> Mybe I am wrong, but if you are detecting 40-wire cable to set them to
> DMA/33, why the check includes also 80-wire cables configuring them to
> DMA/33 too?
>
> With this patch my nvidia4 IDE controllers detects correctly and
> configure correctly DMA/100 for my HD a
On Thu, May 17, 2007 at 07:10:19PM +0200, Jörn Engel ([EMAIL PROTECTED]) wrote:
> On Thu, 17 May 2007 20:03:11 +0400, Evgeniy Polyakov wrote:
> >
> > Is logfs 32bit fs or 674bit, since although you use 64bit values for
> > offsets, area management and strange converstions like described below
> >
On Thu, 17 May 2007 14:23:45 -0700, Jesse Barnes wrote:
> In collaboration with the FB guys, we've been working on enhancing the
> kernel's graphics subsystem in an attempt to bring some sanity to the
> Linux graphics world and avoid the situation we have now where several
> kernel and userspace d
Indan Zupancic wrote:
Everything seems to work fine without sd_resume(), so why is it needed?
Because not all disks spin up without being told to do so and like it or
not spinning disks up on resume is the default behavior. As I wrote in
the other reply, it would be worthwhile to make it config
I did a quick hack so kconfig could scan all Kconfig files
in the kernel tree.
By scanning all Kconfig files we gain the following:
-> kconfig can report when a depends on refer to an undefined symbol
-> kconfig can report when a select refer to an undefined symbol
Later we can push a lot of comm
Björn Steinbrink <[EMAIL PROTECTED]> writes:
>
> Ok, it seems that ipw2200 is just a trigger for the problem here. AFAICT
> the cause of the worse C state usage is that after ipw2200 has woken the
> cpu, acpi_processor_idle() chooses C2 (due to dma? bm? I have no
> idea...) as the prefered sleep s
* Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Add lock contention tracking to lockdep
>
> [EMAIL PROTECTED] ~]# cat /proc/lockdep_contentions | sort -rnk 2 | head
> dcache_lock: 3000 0 [618] [] _atomic_dec_and_lock+0x39/0x58
> [17] [] sysfs_open_file+0x28/0x25a [160]
> [] d_instantiate+0x2a/0x
On Sun, May 20, 2007 at 03:09:10PM +0200, Stefan Richter wrote:
>...
> Since you mention "select": My opinion about the "select" dialect of
> "depends on" is that the UIs should be improved and "select" should be
> removed from the Kconfig language. What do we "select"? Typically we
> "select" a
On Sun, May 20, 2007 at 02:52:14AM -0700, Trent Piepho wrote:
> On Sun, 20 May 2007, Satyam Sharma wrote:
> > On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > On Sun, May 20, 2007 at 05:25:24AM +0530, Satyam Sharma wrote:
> > > > On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > >> O
On 5/20/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
I'm pleased to announce an updated version of the x86_64 highres/dyntick
support patches against 2.6.22-rc2:
http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc2-x86_64-highres-v1.patch
Broken out version is available here:
http
On Sun, May 20, 2007 at 03:52:21PM +0200, Thomas Gleixner wrote:
> On Sun, 2007-05-20 at 12:18 +0200, Heiko Carstens wrote:
> > > I work out a more complex debug patch and pester you to test once I'm
> > > done.
> >
> > I've also tons of 'NOHZ: local_softirq_pending 08' that disappear with
> > noh
On Saturday 19 May 2007, Mattia Dongili wrote:
> On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> > On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <[EMAIL PROTECTED]> wrote:
> >
> > > On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> > > > On Fri, 18 May 2007 16:1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Here's a first little issue with private futex I came across. But a
real bug but a hole.
When we use clone() with CLONE_CHILD_CLEARTID possible waiters are woken
upon termination of the thread. This operation uses FUTEX_WAKE so far.
But it in almos
On Sun, 20 May 2007 11:45:03 -0600 Robert Hancock wrote:
> Indan Zupancic wrote:
> >>> Everything seems to work fine without sd_resume(), so why is it needed?
> >> Because not all disks spin up without being told to do so and like it or
> >> not spinning disks up on resume is the default behavior.
Ulrich Drepper a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Here's a first little issue with private futex I came across. But a
real bug but a hole.
When we use clone() with CLONE_CHILD_CLEARTID possible waiters are woken
upon termination of the thread. This operation uses FUTEX_WA
On 5/20/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
> 1. do nothing, always use the shared futexes. Not very attractive IMO
Why do you find this non attractive ?
How is it performance critical ?
You should know better than any other that the problem is not that the
problem itself is the onl
In order to eventually break the interdependency between the module.h
and moduleparam.h header files, factor out the common MODULE_INFO
content into a new header file.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
this patch doesn't actually start cleaning up the mess related to
mod
On Mon, May 14, 2007 at 09:38:49PM +0200, Pierre Ossman wrote:
> I've reached the point where I've grown tired of trying to figure out
> who has hardware for what. I intend to commit the following in a few
> days so if you care about the quality of the drivers it's time to step
> up to the plate.
Ulrich Drepper a écrit :
On 5/20/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
> 1. do nothing, always use the shared futexes. Not very attractive IMO
Why do you find this non attractive ?
How is it performance critical ?
You should know better than any other that the problem is not that the
On Sun, May 20, 2007 at 03:06:15PM -0400, Robert P. J. Day wrote:
>
> In order to eventually break the interdependency between the module.h
> and moduleparam.h header files, factor out the common MODULE_INFO
> content into a new header file.
The moduleinfo.h file looks redundant at first look.
Wh
Russell King wrote:
> On Mon, May 14, 2007 at 09:38:49PM +0200, Pierre Ossman wrote:
>> I've reached the point where I've grown tired of trying to figure out
>> who has hardware for what. I intend to commit the following in a few
>> days so if you care about the quality of the drivers it's time to
On Sat, 19 May 2007, Davi Arnaut wrote:
> Hi,
>
> Gathering signals in bulk enables server applications to drain a signal
> queue (almost full of realtime signals) more efficiently by reducing the
> syscall and file look-up overhead.
>
> Very similar to the sigtimedwait4() call described by Niel
On Sun, May 20, 2007 at 09:16:44PM +0200, Pierre Ossman wrote:
> Russell King wrote:
> > On Mon, May 14, 2007 at 09:38:49PM +0200, Pierre Ossman wrote:
> >> I've reached the point where I've grown tired of trying to figure out
> >> who has hardware for what. I intend to commit the following in a fe
On 05/20, [EMAIL PROTECTED] wrote:
>
> I've done some more tests and quite frankly I think this is really related
> to the dreaded ''fglrx.ko'' module. It seems to me that it is much easier
> to reproduce the problem if that damn module is loaded. It does uses
> workqueue. Then there is another
From: Stefan Richter <[EMAIL PROTECTED]>
It's not sufficiently documented that CONFIG_HOTPLUG_CPU is required for
suspend/hibernation on SMP.
Point out the non-obvious.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
arch/i386/Kconfig
Hello Tejun,
On Sun, May 20, 2007 19:09, Tejun Heo wrote:
> Indan Zupancic wrote:
>> Don't controllers support spread spin up of disks, to avoid the peak load?
>> I think I saw something about that in the SiI 3512 spec I downloaded. So
>> maybe something like a special spin up method which can be
On Sun, May 20, 2007 19:17, Tejun Heo wrote:
> Indan Zupancic wrote:
>> So over all it takes half a second longer to detect the disk, but
>> because everything waits on it, it takes more than three seconds
>> longer to resume.
>
> Eeeek. Extra three secs doesn't sound too hot. :-(
Hey, without y
On Sun, 20 May 2007, Sam Ravnborg wrote:
> On Sun, May 20, 2007 at 03:06:15PM -0400, Robert P. J. Day wrote:
> >
> > In order to eventually break the interdependency between the module.h
> > and moduleparam.h header files, factor out the common MODULE_INFO
> > content into a new header file.
>
> T
On 05/15, Rafael J. Wysocki wrote:
>
> On Monday, 14 May 2007 23:48, Oleg Nesterov wrote:
> >
> > So, in the long term, should we change this only user, or we think we
> > better fix
> > freezeable wqs again?
>
> Long term, I'd like to have freezable workqueues, so that people don't have to
> us
Uwe Bugla wrote:
> Andrey's path however (i. e. copying his attached version of loop.c into the
> 2.6.22-rc2 kernel tree) led to:
>
> a. an incompilable kernel
> b. endless messages trying to compile loop.c going like this (just a part of
> them - not complete anyway!):
>
> drivers/block/loop.
On Sun, 20 May 2007, Stefan Richter wrote:
>
> >> Iterating upwards and downwards the dependency graph is the duty of
> >> "make snafuconfig", not of the maintainers.
>
> ...multi-level dependencies are no problem for it.
>
> There is nothing wrong with
>
> A... depends on B
>
> B... de
On Sun, 20 May 2007, Sam Ravnborg wrote:
> On Sun, May 20, 2007 at 03:06:15PM -0400, Robert P. J. Day wrote:
> >
> > In order to eventually break the interdependency between the module.h
> > and moduleparam.h header files, factor out the common MODULE_INFO
> > content into a new header file.
>
> T
Why can we still not do this?
It's a stupid restriction. Security isn't a reason;
we have SE Linux policy and auditing to take
care of any issues. Heck, SE Linux policy could
even deny this feature for the truly paranoid.
Writing to /dev/* to update timestamps is surely
a worse security situatio
On Sun, May 20, 2007 at 03:51:18PM -0400, Robert P. J. Day wrote:
> On Sun, 20 May 2007, Sam Ravnborg wrote:
>
> > On Sun, May 20, 2007 at 03:06:15PM -0400, Robert P. J. Day wrote:
> > >
> > > In order to eventually break the interdependency between the module.h
> > > and moduleparam.h header file
Trent Piepho wrote:
> config A
> bool "A"
>
> config B
> bool "B"
> depends on A
>
> config C
> bool "C"
> select B
>
> In this case, it's possible to turn C on and A off. B will be on, even
> though it depends on A and A is off.
>
> The kconfig docs say that "B..
> I wrote on 2007-03-21:
>> On 20 Mar, Greg KH wrote:
>>> On Tue, Mar 20, 2007 at 10:43:22PM +0100, Stefan Richter wrote:
SET_MODULE_OWNER(dev);
+#if 0
+ /* FIXME - Is this the correct parent device anyway? */
SET_NETDEV_DEV(dev, &host->device);
+#endif
...
>>> If so
On Sun, 20 May 2007, Stefan Richter wrote:
> Trent Piepho wrote:
> > config A
> > bool "A"
> >
> > config B
> > bool "B"
> > depends on A
> >
> > config C
> > bool "C"
> > select B
> >
> > In this case, it's possible to turn C on and A off. B will be on, even
> > though it depe
On Sunday, 20 May 2007 21:54, Oleg Nesterov wrote:
> On 05/15, Rafael J. Wysocki wrote:
> >
> > On Monday, 14 May 2007 23:48, Oleg Nesterov wrote:
> > >
> > > So, in the long term, should we change this only user, or we think we
> > > better fix
> > > freezeable wqs again?
> >
> > Long term, I'd
On May 20 2007 18:12, Folkert van Heusden wrote:
>> >
>> > + if (unlikely(sig == SIGQUIT || sig == SIGILL || sig == SIGTRAP ||
>> > + sig == SIGABRT || sig == SIGBUS || sig == SIGFPE ||
>> > + sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
>> > + sig == SIGSYS || sig =
On Sun, May 20, 2007 at 04:06:40PM -0400, Robert P. J. Day wrote:
> On Sun, 20 May 2007, Sam Ravnborg wrote:
>
> > On Sun, May 20, 2007 at 03:06:15PM -0400, Robert P. J. Day wrote:
> > >
> > > In order to eventually break the interdependency between the module.h
> > > and moduleparam.h header file
> >> >
> >> > +if (unlikely(sig == SIGQUIT || sig == SIGILL || sig == SIGTRAP
> >> > ||
> >> > +sig == SIGABRT || sig == SIGBUS || sig == SIGFPE ||
> >> > +sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
> >> > +sig == SIGSYS || sig == SIGSTK
On 05/20, Rafael J. Wysocki wrote:
>
> On Sunday, 20 May 2007 21:54, Oleg Nesterov wrote:
> >
> > I am a bit afraid of too many yes/no options for the freezer, a couple of
> > naive
> > questions.
> >
> > 1. Can't we make all wqs freezable? I still can't see the reason to have
> > both
> >f
First thing mm.h does is including sched.h solely for can_do_mlock() inline
function which has "current" dereference inside. By dealing with can_do_mlock()
mm.h can be detached from sched.h which is good. See below, why.
This patch
a) removes unconditional inclusion of sched.h from mm.h
b) makes c
Thanks for looking into this!
I tried the patches on 2.6.22rc1-git5. The second patch unfortunately
did not resolve the issue, although it seems to get a bit further. Here
are the logs.
** 2.6.22rc1-git5 + timing-debug.patch
May 20 22:40:49 localhost kernel: pccard: PCMCIA card inserted into
On Sun, 20 May 2007, Sam Ravnborg wrote:
> On Sun, May 20, 2007 at 04:06:40PM -0400, Robert P. J. Day wrote:
> > On Sun, 20 May 2007, Sam Ravnborg wrote:
> >
> > > On Sun, May 20, 2007 at 03:06:15PM -0400, Robert P. J. Day wrote:
> > > >
> > > > In order to eventually break the interdependency bet
> + switch(sig) {
> + case SIGQUIT:
> + case SIGILL:
> + case SIGTRAP:
> + case SIGABRT:
> + case SIGBUS:
> + case SIGFPE:
> + case SIGSEGV:
> + case SIGXCPU:
> + case SIGXFSZ:
> + case SIGSYS:
> + case SIGSTKFLT:
Unconditional? That's defini
Christoph Lameter wrote:
Yeah earlier versions did this but then I have to do a patch that changes
all destructors and all kmem_cache_create calls in the kernel.
Yes, please ;-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTEC
> > + switch(sig) {
> > + case SIGQUIT:
> > + case SIGILL:
> > + case SIGTRAP:
> > + case SIGABRT:
> > + case SIGBUS:
> > + case SIGFPE:
> > + case SIGSEGV:
> > + case SIGXCPU:
> > + case SIGXFSZ:
> > + case SIGSYS:
> > + case SIGSTKFLT:
>
> Unconditional? That's def
> > > + switch(sig) {
> > > + case SIGQUIT:
> > > + case SIGILL:
> > > + case SIGTRAP:
> > > + case SIGABRT:
> > > + case SIGBUS:
> > > + case SIGFPE:
> > > + case SIGSEGV:
> > > + case SIGXCPU:
> > > + case SIGXFSZ:
> > > + case SIGSYS:
> > > + case SIGSTKFLT:
> > Unconditional? That's defi
isicom, cleanup locking
don't spin processor when not needed (use sleep instead of delay). Don't
release the lock when needed in next iteration -- this actually fixes a
bug -- missing braces
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit af05316f4ba7503ae531f3afdb5264c10e3b8e2c
tree 2f
isicom, del_timer at exit
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 017f1314b3de8cf20bfff7df0d3d55e6498de104
tree 938fec328f3b24588575540771f65c8fadeaf961
parent af05316f4ba7503ae531f3afdb5264c10e3b8e2c
author Jiri Slaby <[EMAIL PROTECTED]> Sun, 20 May 2007 21:43:42 +0200
committer
isicom, proper variables types
irq is int, base is unsigned long
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 2c1fb6b2f7c17ab752e56220a0b7e84fbe6d3448
tree 1b4ceff6aacaae2ad1548c2efa202d7d0c3d92ba
parent 017f1314b3de8cf20bfff7df0d3d55e6498de104
author Jiri Slaby <[EMAIL PROTECTED]> S
> So.. if we get enough clocksources into the tree, can any of those
> parts of the code be reworked to use clocksources/clockevents and
> hrtimers quickly and easily? I noticed the patch just posted does
> some of it.. but not as much as Ben just mentioned.
Well, some of these are expected to be
On Sun, May 20, 2007 at 11:20:36PM +0200, Folkert van Heusden wrote:
> > > + switch(sig) {
> > > + case SIGQUIT:
> > > + case SIGILL:
> > > + case SIGTRAP:
> > > + case SIGABRT:
> > > + case SIGBUS:
> > > + case SIGFPE:
> > > + case SIGSEGV:
> > > + case SIGXCPU:
> > > + case SIGXFSZ:
> > > +
On Sun, 2007-05-20 at 18:02 +0200, Segher Boessenkool wrote:
> > In fact, while it's never worded explicitely in the spec, it's always
> > been strongly in the "spirit" of the architecture that the timebase and
> > decrementer have a constant frequency.
>
> The architecture mentions varying time b
On Sun, 2007-05-20 at 02:53 +0530, Anant Nitya wrote:
> > 1 == TASK_INTERRUPTIBLE, so we know that ksoftirqd was not woken up. At
> > least it is not a scheduler problem.
> >
> > I work out a more complex debug patch and pester you to test once I'm
> > done.
> No problem :)
You asked for it :)
Pl
On Sunday, 20 May 2007 23:06, Oleg Nesterov wrote:
> On 05/20, Rafael J. Wysocki wrote:
> >
> > On Sunday, 20 May 2007 21:54, Oleg Nesterov wrote:
> > >
> > > I am a bit afraid of too many yes/no options for the freezer, a couple of
> > > naive
> > > questions.
> > >
> > > 1. Can't we make all w
On Sun, 20 May 2007 13:08:15 +0200 Elimar Riesebieter <[EMAIL PROTECTED]> wrote:
> FYI, building 2.6.22-rc2 with
> gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7)
> on my powerbook (PPC) gives:
>
> ...
> kernel/time/ntp.c: In function 'do_adjtimex':
> kernel/time/ntp.c:307: warning: compar
On Fri, 18 May 2007 22:17:14 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger (7):
> [TCP] slow start: Make comments and code logic clearer.
> *** sky2: remove Gigabyte 88e8056 restriction ***
> sky2: PHY register settings
> sky2: keep track of rec
On Sun, 20 May 2007, CIJOML wrote:
> can anybody help me find current usb.ids maintainer? David Brownell is
> not responding and latest official version is 5 mounths old. I could
> take ownership if nobody takes care.
Official maintainer is afaik still Vojtech.
--
Jiri Kosina
-
To unsubscribe
CIJOML wrote:
> Hi guys,
>
> can anybody help me find current usb.ids maintainer? David Brownell is not
> responding and latest official version is 5 mounths old.
>
> I could take ownership if nobody takes care.
>
> Thanks for reply
>
> Michal
farragut.flameeyes.is-a-geek.org/
-
To unsubscri
On Sun, 20 May 2007 23:20:36 +0200, Folkert van Heusden wrote:
> > > + switch(sig) {
> > > + case SIGQUIT:
> > > + case SIGILL:
> > > + case SIGTRAP:
> > > + case SIGABRT:
> > > + case SIGBUS:
> > > + case SIGFPE:
> > > + case SIGSEGV:
> > > + case SIGXCPU:
> > > + case SIGXFSZ:
> > > + case
Randy Dunlap wrote:
On Sun, 20 May 2007 11:45:03 -0600 Robert Hancock wrote:
Indan Zupancic wrote:
Everything seems to work fine without sd_resume(), so why is it needed?
Because not all disks spin up without being told to do so and like it or
not spinning disks up on resume is the default be
On Sun, 2007-05-20 at 23:10 +0100, Christian Kujau wrote:
> hi there,
>
> yet another[0] badness, again from this very iBook running vanilla
> 2.6.22-rc1-git8:
Just another kmalloc(0)... report this one to the DRI folks, it's not
powerpc specific.
Cheers,
Ben.
-
To unsubscribe from this list:
Tejun Heo wrote:
[EMAIL PROTECTED] wrote:
Mybe I am wrong, but if you are detecting 40-wire cable to set them to
DMA/33, why the check includes also 80-wire cables configuring them to
DMA/33 too?
With this patch my nvidia4 IDE controllers detects correctly and
configure correctly DMA/100 for my
On Mon, May 21, 2007 at 12:24:22AM +0200, Andi Kleen wrote:
> > > But I think your list is far too long anyways.
> >
> > So, which ones would you like to have removed then?
>
> SIGFPE at least and the accounting signals are dubious too. SIGQUIT can
> be also relatively common.
And SIGSEGV and SI
hi there,
yet another[0] badness, again from this very iBook running vanilla
2.6.22-rc1-git8:
[41653.487050] Badness at include/linux/slub_def.h:77
[41653.487060] Call Trace:
[41653.487068] [ecafbcb0] [c0008d00] show_stack+0x3c/0x194 (unreliable)
[41653.487097] [ecafbce0] [c01426d4] report_bug
On Sat, May 19, 2007 at 10:53:20AM -0700, William Lee Irwin III wrote:
> On Fri, May 18, 2007 at 04:42:10PM +0100, Hugh Dickins wrote:
> > Sooner rather than later, don't we need those 8 bytes to expand from
> > atomic_t to atomic64_t _count and _mapcount? Not that we really need
> > all 64 bits o
Micah Cowan wrote:
> Alan Cox wrote:
>>> [XSI] [Option Start] If the request would cause the file size to
>>> exceed the soft file size limit for the process and there is no room
>>> for any bytes to be written, the request shall fail and the
>>> implementation shall generate the SIGXFSZ signal for
On Sunday, May 20, 2007, Jon Smirl wrote:
> On Thu, 17 May 2007 14:23:45 -0700, Jesse Barnes wrote:
> > In collaboration with the FB guys, we've been working on enhancing the
> > kernel's graphics subsystem in an attempt to bring some sanity to the
> > Linux graphics world and avoid the situation w
Hi,
On Sat, 19 May 2007, Sam Ravnborg wrote:
> We see a lot of these lately:
> GEN /home/bor/build/linux-2.6.22/Makefile
> scripts/kconfig/conf -s arch/i386/Kconfig
> drivers/macintosh/Kconfig:116:warning: 'select' used by config symbol
> 'PMAC_APM_EMU' refers to undefined symbol 'SYS_SUPP
On Sun, May 20, 2007 at 11:38:04AM -0700, David Brownell wrote:
> On Saturday 19 May 2007, Mattia Dongili wrote:
> > On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> > > On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > On Fri, May 18
On 5/20/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
With the interfaces implemented here, a userspace application can create a
multiseat environment either with a single graphics card with multiple
outputs or multiple cards. It could do this by creating several frame
buffer objects and associati
101 - 200 of 271 matches
Mail list logo
