Krzysztof Halasa <[EMAIL PROTECTED]> writes:
> > So, by making the COPYING contain the v2 text, is the author
> > specifying a particular version? If yes, then the sec. 9 provision
> > would be meaningless, since there would be no way to not specify a
> > version number.
>
> Of course the "publis
>> "version 2 or higher"
> That phrase exists outside the license
That's true. But sec. 9 of the GPLv2 says:
If the Program does not specify a version number of this License, you
may choose any version ever published by the Free Software Foundation.
So, by making the COPYING contain the v2
> a previous discussion that said 4 was the default...I don't see
> why. nice uses +10 by default on all linux distro...So I suspect
> that if Mike just used "nice lame" instead of "nice +5 lame", he
> would have got what he wanted.
tcsh, and probably csh, has a builtin 'nice' with default +4. So
>> [GPL acknowledging fair-use rights]
> Pure noise, a license can't take them away in any case.
A bare license probably cannot take them away, since you haven't
agreed to anything. But (1) that may not be true in all legal
systems, and (2) a contract-based license can take it away (e.g. an
NDA)
Linus Torvalds wrote:
> That said, I think they are still pushing the "you don't have any
> rights unless we give you additional rights explicitly" angle a bit
> too hard.
>From section 2 (GPLv3, draft 2):
This License acknowledges your rights of "fair use" or other
equivalent, as provided by c
>> Is there any way to make git tell exactly where between rc4 and rc5
>> each kernel is, so I can name the bzimages accordingly?
>
> You'd have to use the raw commit names, since these things don't have any
> symbolic names. You can get that by just doing
>
> cat .git/HEAD
Also, don't nam
> slow and steady progress
The oscillations are indeed discouraging. For S3 sleep/wake on my TP
600X:
2.6.11.4: works well (the console was hosed with jittering text, but
X restores fine), which hugely improved using my laptop.
2.6.12.3: ditto
But:
2.6.13-rc3
Pavel Machek wrote:
> If you think it is a linux bug, can you produce small test case doing
> just the sigwait, and post it on l-k with big title "sigwait() breaks
> when straced, and on suspend"?
Here it is. I haven't tested the sigwait()+suspend lately, since
suspend isn't working with any kern
>> One other glitch is that pdnsd (a nameserver caching daemon) has crashed
>> when the system wakes up from swsusp. It also happens when waking up
>> from S3, which was working with 2.6.11.4 although not with 2.6.13-rc3.
>> Many people have said mysql also does not suspend well. Is their use of
>Len, Kevin confirms that the below patch fixes the above regression for
>him. Should we merge it now?
It also works for me. Well, I'm not 100% sure it was that patch, but
2.6.13-rc3 on my TP 600X has the C2/C3 regression:
ACPI: CPU0 (power states: C1[C1])
And 2.6.13-rc3-mm2, which includes
> Perhaps the patch from Daniel Ritz to free the yenta IRQ on suspend
> (attached) will help?
Alas, when I went to apply it, patch said it was already there, and
sure enough 2.6.13-rc3-mm2 does have it.
One approach is to find out why PCMCIA cannot remove the socket power
when using cardctl eject
> So, in short, problem is that if you leave prism54 card in, even
> with module removed, swsusp hangs, right?
Right, in some circumstances. To narrow them down I spent many hours
rebooting into combinations of runlevels and loaded modules. It is
reproducible even in single-user mode. The vario
>>If I don't eject the pcmcia card (usually a prism54 wireless card),
>>swsusp begins the process of hibernation, but never gets to the
>>writing pages part.
> Well, it really may be the firmware loading. Add some printks to
> confirm it, then fix it.
I did more tests, this time with 2.6.13-rc3-m
I get the same short freezes with
cat /proc/acpi/battery/*/{state,info}
and also with the 'acpi' command-line tool. I'm about to try the the
suggested kernel profiling with -mm3 and will report the results.
Meanwhile:
>>> readprofile -r
>> do i have to activate something special during kerne
swsusp now mostly works on my TP 600X. If I don't eject the pcmcia card
(usually a prism54 wireless card), swsusp begins the process of
hibernation, but never gets to the writing pages part. The eth0 somehow
tries to reload the firmware (as if it's been woken up), and then
everything hangs. If I
>From my previous message on this subject:
> With 2.6.13-rc3 I now get these errors (2.6.11.4 was fine) on my TP
> 600X (Debian 'etch' system):
>
> localhost kernel: hda: dma_timer_expiry: dma status == 0x21
> localhost kernel: hda: DMA timeout error
> localhost kernel: hda: dma timeout error: s
I just changed kernels from 2.6.11.4 to 2.6.13-rc3 and upon boot I now
see these errors on the console and in the syslog:
localhost kernel: hda: dma_timer_expiry: dma status == 0x21
localhost kernel: hda: DMA timeout error
localhost kernel: hda: dma timeout error: status=0x58 { DriveReady SeekComp
17 matches
Mail list logo
