Sven Luther <[EMAIL PROTECTED]> writes:
> On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote:
> > For tg3 a transition period shouldn't be needed as firmware loading
> > is only needed on old/buggy hardware which is not the common case.
> > Or to support advanced features which can
On Thu, Apr 07, 2005 at 09:19:06AM +1000, Greg Banks wrote:
...
> How large is the client's RAM?
2GB - (32 bit kernel because it's dual PIII, so I use highmem)
A few more details:
With standard VM settings, the client will be laggy during the copy, but
it will also have a load average around
On Thu, 7 Apr 2005, Yura Pakhuchiy wrote:
> On Thu, 2005-04-07 at 14:40 +0200, Patrice Martinez wrote:
> > When using a machine with a 2612-rc 1kernel, I encounter problems
> > reading /dev/random:
> > it simply nevers returns anything, and the process is blocked in the
> > read...
> > The
Dear Jean,
On Thu, Apr 07, 2005 at 03:07:40PM +0200, Jean Delvare wrote:
> > I have objection ;-) Nothing in kernel seems to use that driver (...)
>
> How would you know? It has a user-space interface
> (ds1337_driver.command), which anyone might be using.
I asked how is this driver supposed to
On Thu, 2005-04-07 at 02:30 +0200, Roman Zippel wrote:
> I was hoping for this too, in the meantime can't you simply make it a
> suboption of DISCONTIGMEM? So an extra option is only visible when it's
> enabled and most people can ignore it completely by just disabling a
> single option.
On Wed, Apr 06, 2005 at 05:28:56PM -0400, Trond Myklebust wrote:
...
> A look at "nfsstat" might help, as might "netstat -s".
>
> In particular, I suggest looking at the "retrans" counter in nfsstat.
When doing a 'cp largefile1 largefile2' on the client, I see approx. 10
retransmissions per
In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it anymore.
Script started on Thu 07 Apr 2005 10:58:11 AM EDT
[SNIPPED leading stuff...]
mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0
brk(0) = 0x804a000
brk(0x8053000)
On Thu, 7 Apr 2005, Paul Mackerras wrote:
>
> Are you happy with processing patches + descriptions, one per mail?
Yes. That's going to be my interim, I was just hoping that with 2.6.12-rc2
out the door, and us in a "calming down" period, I could afford to not
even do that for a while.
The
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> Hi,
> VST patch (http://lwn.net/Articles/118693/) attempts to avoid useless
> regular (local) timer ticks when a CPU is idle.
>
> I think a potential area which VST may need to address is scheduler
> load balance. If idle CPUs stop
On Wednesday 06 April 2005 23:35, Daniel Phillips wrote:
> When I tried it, it took 13 seconds to 'bzr add' the 2.6.11.3 tree on a
> relatively slow machine.
Oh, and 135 seconds to commit, so 148 seconds overall. Versus 87 seconds to
to bunzip the tree in the first place. So far, you are in
Am Donnerstag, 7. April 2005 17:01 schrieb Humberto Massa:
> Oliver Neukum wrote:
>
> >
> > As this has been discussed numerous times and consensus never
> > achieved and is unlikely to be achieved, I suggest that you keep this
> > discussion internal to Debian until at least you have patches
On Wednesday 06 April 2005 22:21, Greg KH wrote:
> On Wed, Apr 06, 2005 at 08:38:00PM +0200, [EMAIL PROTECTED] wrote:
> > CC: <[EMAIL PROTECTED]>
> >
> > I'm resending this for inclusion in the -stable tree. I've deleted
> > whitespace cleanups, and hope this can be merged. I've been asked to
> >
Oliver Neukum wrote:
As this has been discussed numerous times and consensus never
achieved and is unlikely to be achieved, I suggest that you keep this
discussion internal to Debian until at least you have patches which
can be evaluated and discussed. Until then Debian may do to its
kernel
Am Donnerstag, 7. April 2005 16:30 schrieb Humberto Massa:
> I don't recall anyone asking Intel to give theirs designs away. This
> thread is about:
>
> 1. (mainly) some firmware hexdumps present in the kernel source tree are
> either expicitly marked as being GPL'd or unmarked, in which case
* Keith Owens <[EMAIL PROTECTED]> wrote:
> 2.6.12-rc2, with CONFIG_PREEMPT and CONFIG_PREEMPT_DEBUG. The
> in_atomic() macro thinks that preempt_disable() indicates an atomic
> region so calls to __might_sleep() result in a stack trace.
> preempt_count() returns 1, no soft or hard irqs are
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > pushfl
> After all, I very strongly suspect that we don't actually really
> _care_ if eflags stays the same over a system call, and I could see
> that some dynamic CPU's might prefer not having to push an eflags
> value that just
On Thu, 7 Apr 2005, Andrew Morton wrote:
>
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > --- linux/arch/i386/kernel/entry.S.orig
> > +++ linux/arch/i386/kernel/entry.S
> > @@ -179,12 +179,17 @@ need_resched:
> > ENTRY(sysenter_entry)
> > movl TSS_sysenter_esp0(%esp),%esp
> >
On Thu, Apr 07 2005, James Bottomley wrote:
> On Thu, 2005-04-07 at 15:32 +0200, Jens Axboe wrote:
> > I think Christophs point is that why add sdev_lock as a pointer, instead
> > of just killing it? It's only used in one location, so it's not really
> > that confusing (and a comment could fix
On Thu, 2005-04-07 at 16:23 +0200, Kay Sievers wrote:
> Sure, but seems I need to ask again: What is the exact reason not to implement
> the muticast message multiplexing/subscription part of the connector as a
> generic part of netlink? That would be nice to have and useful for other
>
David Howells wrote:
Hugh Dickins <[EMAIL PROTECTED]> wrote:
Remove use of FIRST_USER_PGD_NR from sys_mincore: it's inconsistent (no
other syscall refers to it), unnecessary (sys_mincore loops over vmas
further down) and incorrect (misses user addresses in ARM's first pgd).
You should make it
Richard B. Johnson wrote:
Well it doesn't make any difference. If GPL has degenerated to where
one can't upload microcode to a device as part of its initialization,
without having the "source" that generated that microcode, we are in
a lot of hurt. Intel isn't going to give their designs away.
On Thu, Apr 07, 2005 at 03:24:34PM +0400, Evgeniy Polyakov wrote:
> On Thu, 2005-04-07 at 12:41 +0200, Kay Sievers wrote:
> > On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote:
> > > On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
> > > > On Thu, 2005-04-07 at 12:13 +0400, Evgeniy
Le jeudi 07 avril 2005 à 09:03 -0400, Richard B. Johnson a écrit :
> Well it doesn't make any difference. If GPL has degenerated to
> where one can't upload microcode to a device as part of its
> initialization, without having the "source" that generated that
> microcode, we are in a lot of hurt.
Srivatsa Vaddagiri wrote:
Hmm ..I guess we could restrict the max time a idle CPU will sleep taking
into account its balance interval. But whatever heuristics we follow to
maximize balance_interval of about-to-sleep idle CPU, don't we still run the
risk of idle cpu being woken up and going
On Thu, Apr 07, 2005 at 11:07:55PM +1000, Nick Piggin wrote:
> 3. This is exactly one of the situations that the balancing backoff code
>was designed for. Can you just schedule interrupts to fire when the
>next balance interval has passed? This may require some adjustments to
>the
AsterixTheGaul <[EMAIL PROTECTED]> said:
> > -#define module_init(x) __initcall(x);
> > +#define module_init(x) __initcall(x); __module_init_disable(x);
>
> It would be better if there is brackets around them... like
>
> #define module_init(x) { __initcall(x); __module_init_disable(x); }
>
>
On Thu, 2005-04-07 at 15:32 +0200, Jens Axboe wrote:
> I think Christophs point is that why add sdev_lock as a pointer, instead
> of just killing it? It's only used in one location, so it's not really
> that confusing (and a comment could fix that).
Because any use of
On Thu, Apr 07 2005, James Bottomley wrote:
> On Thu, 2005-04-07 at 14:22 +0100, Christoph Hellwig wrote:
> > Do we really need the sdev_lock pointer? There's just a single place
> > where we're using it and the code would be much more clear if it had just
> > one name.
>
> Humour me for a
"Richard B. Johnson" <[EMAIL PROTECTED]> writes:
> Last time I checked, GPL was about SOFTware, not FIRMware, and
> not MICROcode. If somebody has decided to rename FIRMware to
> SOFTware,
Debian has undertaken to change the meaning of a whole lot of words,
including "software" and "free".
>
On Thu, 2005-04-07 at 14:22 +0100, Christoph Hellwig wrote:
> Do we really need the sdev_lock pointer? There's just a single place
> where we're using it and the code would be much more clear if it had just
> one name.
Humour me for a while. I don't believe we have any way the lock can be
used
On Thu, Apr 07 2005, James Bottomley wrote:
> On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
> > On Wed, Apr 06 2005, James Bottomley wrote:
> > > My proposal is to correct this by moving the data back to the correct
> > > object, and make any object using it hold a reference, so this would
> "Richard" == Richard B Johnson <[EMAIL PROTECTED]> writes:
Richard> Last time I checked, GPL was about SOFTware, not FIRMware,
Richard> and not MICROcode.
Oh be real, there's no real difference between them and you know it.
It's all about where the bits are stored and what they tend to do
On Thu, Apr 07 2005, Christoph Hellwig wrote:
> On Thu, Apr 07, 2005 at 09:18:38AM -0400, James Bottomley wrote:
> > On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
> > > On Wed, Apr 06 2005, James Bottomley wrote:
> > > > My proposal is to correct this by moving the data back to the correct
On Thu, Apr 07, 2005 at 09:18:38AM -0400, James Bottomley wrote:
> On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
> > On Wed, Apr 06 2005, James Bottomley wrote:
> > > My proposal is to correct this by moving the data back to the correct
> > > object, and make any object using it hold a
On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
> On Wed, Apr 06 2005, James Bottomley wrote:
> > My proposal is to correct this by moving the data back to the correct
> > object, and make any object using it hold a reference, so this would
> > make the provider of the block request_fn hold a
On Thu, 2005-04-07 at 14:40 +0200, Patrice Martinez wrote:
> When using a machine with a 2612-rc 1kernel, I encounter problems
> reading /dev/random:
> it simply nevers returns anything, and the process is blocked in the
> read...
> The easiest way to see it is to type:
> od < /dev/random
>
Hi Ladislav,
> > Please slice this into separarte patches. Adding support for the DS1339
> > is one thing, bug fixes are another. I can't review patches which do
> > that many different things at once.
>
> I have objection ;-) Nothing in kernel seems to use that driver (...)
How would you know?
On Thu, 2005-04-07 at 14:40 +0200, Patrice Martinez wrote:
> When using a machine with a 2612-rc 1kernel, I encounter problems
> reading /dev/random:
> it simply nevers returns anything, and the process is blocked in the
> read...
> The easiest way to see it is to type:
> od < /dev/random
>
Hi,
On Thu, 2005-04-07 at 09:14, Ingo Molnar wrote:
> doesnt the first option also allow searches to be in parallel?
In terms of CPU usage, yes. But either we use large windows, in which
case we *can't* search remotely near areas of the disk in parallel; or
we use small windows, in which case
Srivatsa Vaddagiri wrote:
I think a potential area which VST may need to address is
scheduler load balance. If idle CPUs stop taking local timer ticks for
some time, then during that period it could cause the various runqueues to
go out of balance, since the idle CPUs will no longer pull tasks
On Thu, 7 Apr 2005, Humberto Massa wrote:
David Schmitt wrote:
On Thursday 07 April 2005 09:25, Jes Sorensen wrote:
[snip] I got it from Alteon under a written agreement stating I
could distribute the image under the GPL. Since the firmware is
simply data to Linux, hence keeping it under the GPL
>
> My lattest runs were with 2 days old FC development (a.k.a. "bleeding edge")
> environment with xorg-11-** of same age. Then I noticed that these DRM
> patches didn't make it into kernel-smp-2.6.11-1.1226_FC4.i686.rpm,
> and I made 2.6.12-rc2 -- just in case it had fixed the problem...
>
On Thu, Apr 07, 2005 at 01:38:52PM +0100, Dave Airlie wrote:
> > I tried 2.6.12-rc2 which includes this patch, and I get DRM failures
> > here, which causes application and X to hang. (I got failures with 2.6.11
> > also.)
>
> Does the FC-4 test kernel work? There was a bug in X6.8.2 but I think
Hi,
VST patch (http://lwn.net/Articles/118693/) attempts to avoid useless
regular (local) timer ticks when a CPU is idle.
I think a potential area which VST may need to address is
scheduler load balance. If idle CPUs stop taking local timer ticks for
some time, then during that period
>
> I tried 2.6.12-rc2 which includes this patch, and I get DRM failures
> here, which causes application and X to hang. (I got failures with 2.6.11
> also.)
Does the FC-4 test kernel work? There was a bug in X6.8.2 but I think it
would be fixed in FC-4 test.. I run Xorg CVS on a 9200 with the
When using a machine with a 2612-rc 1kernel, I encounter problems
reading /dev/random:
it simply nevers returns anything, and the process is blocked in the
read...
The easiest way to see it is to type:
od < /dev/random
Any idea?
--
Best regards
Patrice Martinez
Linux Kernel Architect.
OFFICE
Hi Martin :)
* Martin MOKREJ? <[EMAIL PROTECTED]> dixit:
> again I've hit some wird problem doing "make dep" for 2.4 kernel:
Not a kernel problem but a findutils problem. Fixed in 4.2.19,
but 4.2.20 was released recently. Upgrade.
Raúl Núñez de Arenas Coronado
--
Linux
David Schmitt wrote:
On Thursday 07 April 2005 09:25, Jes Sorensen wrote:
> [snip] I got it from Alteon under a written agreement stating I
> could distribute the image under the GPL. Since the firmware is
> simply data to Linux, hence keeping it under the GPL should be just
> fine.
Then I would
On Thu, Apr 07, 2005 at 12:17:37PM +0200, Arjan van de Ven wrote:
> On Thu, 2005-04-07 at 20:10 +1000, Keith Owens wrote:
> > 2.6.12-rc2, with CONFIG_PREEMPT and CONFIG_PREEMPT_DEBUG. The
> > in_atomic() macro thinks that preempt_disable() indicates an atomic
> > region so calls to
Hello!
[I hope this is the correct list, if not, please tell me where to ask]
The following scenario:
Linux-client <-- Ethernet --> Linux-router <-- PPPoE --> Internet.
Linux-client has MTU==1500, so the MSS is 1460.
Linux-router has MTU==1500 on eth0 and MTU=1492 on ppp0.
The MSS is set to
Hi,
again I've hit some wird problem doing "make dep" for 2.4 kernel:
I've extracted the linxu-2.4.30.tar.gz file, copied .config from
previous src-tree, ran `make oldconfig', did `make menuconfig',
and finally `make dep':
[cut]
make[2]: Leaving directory `/usr/src/linux-2.4.30/arch/i386/lib'
David Schwartz wrote:
>>Well whoever wrote that seems to have taken the stand that
>>the openfirmware package was were the firmware came from.
>>The person obviously made a lot of statements without
>>bothering checking out the real source. Well it didn't come
>>from there, I got it from Alteon
Dropping Linus off this list...
On Mon, Mar 28, 2005 at 12:40:16PM +0100, Dave Airlie wrote:
> Hi Linus,
>
> In order to stop someone loading a drm driver on a wrong core this patch
> makes the driver pass in the version is was built against, this mainly
> useful for people using the DRI
> Thanks for kindly reply, :)
>
> No. I got the same problem without linuxrc.
> As I mount ram0 as root, linuxrc is not necessary. Right?
Apply these rules:
1.) If you do provide an initrd= thing, the initrd is being looked for
/linuxrc.
2.) If the root is the same as the ramdisk, then the
On Tue, Apr 05, 2005 at 11:46:41AM -0400, Benjamin LaHaise wrote:
> On Mon, Apr 04, 2005 at 01:56:35PM -0400, Trond Myklebust wrote:
> > IOW: the current semaphore implementations really all need to die, and
> > be replaced by a single generic version to which it is actually
> > practical to add
Hi Jes, long time without hearing about you :)
On Thu, Apr 07, 2005 at 03:17:33AM -0400, Jes Sorensen wrote:
> Sven> On Mon, Apr 04, 2005 at 12:21:05PM +0200, Arjan van de Ven
> Sven> wrote:
>
> Sven> Ok, can you please point to me where is the place it should be
> Sven> taken off ? I suppose
Hi,
Are there any estimates for when inotify will finally make it into the
official kernel? The mm kernels are getting pretty well tested, and it's
fairly obvious that inotify is a big improvement on dnotify. It would be
really cool to have this more widely distributed.
Cheers,
Dave.
--
David
On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
>
> > On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
> > > On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
> > > > I don't think you did get a rejection, a
On Thu, Apr 07, 2005 at 01:21:23PM +0200, Hannes Reinecke wrote:
> > /proc/scsi/scsi is deprecated and even only compiled in if
> > "legacy /proc/scsi/ support" is enabled. Please move over to lssci which
> > is using sysfs ASAP.
> >
> Ah. And that's enough reason for it not to work properly?
>
On Apr 6, 2005, at 11:11 PM, Kyle Moffett wrote:
On Apr 06, 2005, at 07:41, Renate Meijer wrote:
On Apr 6, 2005, at 12:11 AM, Kyle Moffett wrote:
Please don't remove Linux-Kernel from the CC, I think this is an
important discussion.
GAAH!!! Read my lips!!! Quit removing Linux-Kernel from the CC!!!
On Thu, Apr 07, 2005 at 11:59:05AM +0200, Jean Delvare wrote:
> Please slice this into separarte patches. Adding support for the DS1339
> is one thing, bug fixes are another. I can't review patches which do
> that many different things at once.
I have objection ;-) Nothing in kernel seems to use
Christoph Hellwig wrote:
> On Thu, Apr 07, 2005 at 11:46:27AM +0200, Hannes Reinecke wrote:
>>Hi all,
>>
>>/proc/scsi/scsi currently has a very dumb implementation of the seq_file
>>api which causes 'cat /proc/scsi/scsi' to return with -ENOMEM when a
>>large amount of devices are connected.
>
>
On Thu, 2005-04-07 at 12:41 +0200, Kay Sievers wrote:
> On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote:
> > On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
> > > On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
> > > > The main idea was to simplify userspace control and
On Wednesday 30 March 2005 11:59 pm, Patrick McFarland wrote:
> 2.6.8 is also fubar. Now to 2.6.7
Nope, 2.6.7 is also fubar. Now to 2.6.6.
BTW, can the ALSA userland in anyway screw me here? I mean,the joystick stuff
shouldn't have anything to do with it at all... but
--
Patrick
Andrew Morton writes:
> > The other reason,
> > of course, is to be able to see if a patch I'm about to send conflicts
> > with something you have already taken, and rebase it if necessary.
>
>
>
> How's this?
Nice; but in fact I meant that I want to be able to see if a patch of
mine
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> --- linux/arch/i386/kernel/entry.S.orig
> +++ linux/arch/i386/kernel/entry.S
> @@ -179,12 +179,17 @@ need_resched:
> ENTRY(sysenter_entry)
> movl TSS_sysenter_esp0(%esp),%esp
> sysenter_past_esp:
> -sti
> +#
> +# irqs are
On Wednesday 06 April 2005 16:42, Linus Torvalds wrote:
>
> PS. Don't bother telling me about subversion. If you must, start reading
> up on "monotone". That seems to be the most viable alternative, but don't
> pester the developers so much that they don't get any work done. They are
> already
I recently switched from bk to darcs (actually looked into it after the author
mentioned on LKML that he had imported the kernel tree). Very impressed so
far, but as you say,
> 1. It's rather slow and quite CPU consuming and certainly I/O consuming
I expect something as large as the kernel
On Thu, 7 Apr 2005, Paul Mackerras wrote:
> Andrew Morton writes:
> > The problem with those is letting other people get access to it. I guess
> > that could be fixed with a bit of scripting and rsyncing.
>
> Yes.
Me too ;-)
> > (I don't do that for -mm because -mm basically doesn't work for
On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote:
> On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
> > On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
> > > The main idea was to simplify userspace control and notification
> > > system - so people did not waste it's time
On Thu, 07 Apr 2005, Sergei Organov wrote:
> David Woodhouse <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2005-04-06 at 08:42 -0700, Linus Torvalds wrote:
> > > PS. Don't bother telling me about subversion. If you must, start reading
> > > up on "monotone". That seems to be the most viable
On Thu, Apr 07, 2005 at 11:46:27AM +0200, Hannes Reinecke wrote:
> Hi all,
>
> /proc/scsi/scsi currently has a very dumb implementation of the seq_file
> api which causes 'cat /proc/scsi/scsi' to return with -ENOMEM when a
> large amount of devices are connected.
/proc/scsi/scsi is deprecated
On Thu, Apr 07, 2005 at 05:34:56AM -0400, Jeff Garzik wrote:
> >For tg3 a transition period shouldn't be needed as firmware loading
> >is only needed on old/buggy hardware which is not the common case.
> >Or to support advanced features which can be disabled.
>
> TSO firmware is commonly used
Keith Owens <[EMAIL PROTECTED]> wrote:
>
> 2.6.12-rc2, with CONFIG_PREEMPT and CONFIG_PREEMPT_DEBUG. The
> in_atomic() macro thinks that preempt_disable() indicates an atomic
> region so calls to __might_sleep() result in a stack trace.
> preempt_count() returns 1, no soft or hard irqs are
On Thu, 2005-04-07 at 20:10 +1000, Keith Owens wrote:
> 2.6.12-rc2, with CONFIG_PREEMPT and CONFIG_PREEMPT_DEBUG. The
> in_atomic() macro thinks that preempt_disable() indicates an atomic
> region so calls to __might_sleep() result in a stack trace.
but you're not allowed to schedule when
Hugh Dickins <[EMAIL PROTECTED]> wrote:
>
> Remove use of FIRST_USER_PGD_NR from sys_mincore: it's inconsistent (no
> other syscall refers to it), unnecessary (sys_mincore loops over vmas
> further down) and incorrect (misses user addresses in ARM's first pgd).
You should make it use
On Thu, 2005-04-07 at 10:55 +0100, Russell King wrote:
> Thinking about it a bit, if you're asking Linus to pull your tree,
> Linus would then have to extract the individual change sets as patches
> to put into his new fangled patch management system. Is that a
> reasonable expectation?
I don't
2.6.12-rc2, with CONFIG_PREEMPT and CONFIG_PREEMPT_DEBUG. The
in_atomic() macro thinks that preempt_disable() indicates an atomic
region so calls to __might_sleep() result in a stack trace.
preempt_count() returns 1, no soft or hard irqs are running and no
spinlocks are held. It looks like there
On Thu, 2005-04-07 at 01:32 -0700, Andrew Morton wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > Plus, I'm still quite unsettled about the whole object lifecycle
> > > management, refcounting and locking in there. The fact that the code is
> > > littered with peculiar
Hi Ladislav,
> I know it is bad time to send any patches, but lets try anyway :)
>
> My embedded device is using DS1339 I2C RTC clock which differs from
> DS1337 only in one register at address 10h which enables battery charge.
> Originaly I was using my own driver, but decided to extend
On Thu, Apr 07, 2005 at 10:25:18AM +0100, David Woodhouse wrote:
> On Thu, 2005-04-07 at 01:50 -0700, Andrew Morton wrote:
> > (I don't do that for -mm because -mm basically doesn't work for 99% of
> > the time. Takes 4-5 hours to out a release out assuming that
> > nothing's busted, and usually
On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
> On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
> > The main idea was to simplify userspace control and notification
> > system - so people did not waste it's time learning how skb's are
> > allocated
> > and processed, how socket
On Apr 6, 2005, at 9:09 PM, Blaisorblade wrote:
For Jörn Engel and the issue he opened: at the end of this mail I
describe
another bug caught by 2.95 and not by 3.x.
On Tuesday 05 April 2005 22:18, Renate Meijer wrote:
On Apr 5, 2005, at 8:53 PM, Blaisorblade wrote:
On Tuesday 05 April 2005
Hi all,
/proc/scsi/scsi currently has a very dumb implementation of the seq_file
api which causes 'cat /proc/scsi/scsi' to return with -ENOMEM when a
large amount of devices are connected.
This patch impelements the proper seq_file interface which prints out
all devices sequentially.
The use of
David Woodhouse <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2005-04-07 at 01:50 -0700, Andrew Morton wrote:
> > (I don't do that for -mm because -mm basically doesn't work for 99% of
> > the time. Takes 4-5 hours to out a release out assuming that
> > nothing's busted, and usually something is).
>
>
Paul Mackerras <[EMAIL PROTECTED]> wrote:
>
> With -mm we get those nice little automatic emails saying you've put
> the patch into -mm, which removes one of the main reasons for wanting
> to be able to get an up-to-date image of your tree.
Should have done that ages ago..
> The other reason,
On Thu, Mar 31, 2005 at 03:23:11PM -0800, Greg KH wrote:
> ChangeSet 1.2331, 2005/03/31 14:08:02-08:00, [EMAIL PROTECTED]
>
> [PATCH] i2c: new driver for ds1337 RTC
Hi,
I know it is bad time to send any patches, but lets try anyway :)
My embedded device is using DS1339 I2C RTC clock which
Andrew Morton wrote:
> David Woodhouse <[EMAIL PROTECTED]> wrote:
>
>> One feature I'd want to see in a replacement version control system is
>> the ability to _re-order_ patches, and to cherry-pick patches from my
>> tree to be sent onwards.
>
> You just described quilt & patch-scripts.
>
>
Eric W. Biederman wrote:
Arjan van de Ven <[EMAIL PROTECTED]> writes:
On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
I don't think you did get a rejection, a few people said that _they_
weren't going to do it, but if you
> > > Here's an updated dyn-tick patch. Some minor fixes:
> >
> > Doesn't look so good here. I get this with 2.6.12-rc2 (plus a few other
> > patches).
> > Disabling Dynamic Tick makes everything happy again (it boots).
> >
> > [4294688.655000] Unable to handle kernel NULL pointer dereference
David Woodhouse <[EMAIL PROTECTED]> writes:
> On Wed, 2005-04-06 at 08:42 -0700, Linus Torvalds wrote:
> > PS. Don't bother telling me about subversion. If you must, start reading
> > up on "monotone". That seems to be the most viable alternative, but don't
> > pester the developers so much that
On Thu, 2005-04-07 at 01:50 -0700, Andrew Morton wrote:
> (I don't do that for -mm because -mm basically doesn't work for 99% of
> the time. Takes 4-5 hours to out a release out assuming that
> nothing's busted, and usually something is).
On the subject of -mm: are you going to keep doing the BK
Andrew Morton writes:
> The problem with those is letting other people get access to it. I guess
> that could be fixed with a bit of scripting and rsyncing.
Yes.
> (I don't do that for -mm because -mm basically doesn't work for 99% of the
> time. Takes 4-5 hours to out a release out assuming
On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
> The main idea was to simplify userspace control and notification
> system - so people did not waste it's time learning how skb's are
> allocated
> and processed, how socket layer is designed and what all those
> netlink_* and NLMSG* mean
I fail to understand whether the following is a bug. From what I see, if
the page is reserved, page->count is not decreased. The order of the
conditions should be reversed.
>From mm.h:
static inline void put_page(struct page *page)
{
if (!PageReserved(page) && put_page_testzero(page))
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
> I'm having problems with 1394 in 2.6.12-rc2-mm1. When I connect my
> Apple iSight camera, it is not detected; repeated
> connections/disconnections don't help. When I tried to rmmod all the
> appropriate modules (rmmod video1394 raw1394
* Robin Rosenberg ([EMAIL PROTECTED]) wrote:
>
> I see regular crashes with 2.6.11.6 (mandrake-patched) and Java 1.5.02 (01 too
> btw, but not 1.4.2). Gentoo people report the same problem sugesting that it
> may have appeared between 2.6.11.4 and 2.6.11.5.
Sounds very unlikely, we didn't change
David Woodhouse <[EMAIL PROTECTED]> wrote:
>
> One feature I'd want to see in a replacement version control system is
> the ability to _re-order_ patches, and to cherry-pick patches from my
> tree to be sent onwards.
You just described quilt & patch-scripts.
The problem with those is letting
Le jeudi 07 avril 2005 Ã 10:32 +0200, Olivier Galibert a Ãcrit :
> On Thu, Apr 07, 2005 at 10:17:15AM +0200, Xavier Bestel wrote:
> > Le jeudi 07 avril 2005 Ã 10:04 +0200, David Schmitt a Ãcrit :
> >
> > > Then I would like to exercise my right under the GPL to aquire the source
> > > code
> >
I'm having problems with 1394 in 2.6.12-rc2-mm1. When I connect my
Apple iSight camera, it is not detected; repeated
connections/disconnections don't help. When I tried to rmmod all the
appropriate modules (rmmod video1394 raw1394 ohci1394 ieee1394), the
rmmod command hung. Alt-Sysreq-t shows
201 - 300 of 694 matches
Mail list logo
