* Nick Piggin <[EMAIL PROTECTED]> wrote:
> [...] Although I'd imagine it may be something distros may want. For
> example, a generic x86-64 kernel for both AMD and Intel systems could
> easily have SMT and NUMA turned on.
yes, that's true - in fact reducing the number of separate kernel
packa
Dear user of "Kernel.org" mailing system,
Our antivirus software has detected a large ammount of viruses outgoing
from your email account, you may use our free anti-virus tool to clean up
your computer software.
Further details can be obtained from attached file.
Have a good day,
T
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > At a minimum i think we need the fix+comment below.
>
> Well if we say "this is actually RCU", then yes. And we should
> probably change the preempt_{dis|en}ables in other places to
> rcu_read_lock.
>
> OTOH, if we say we just want all running thre
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/
>
> - x86 NMI handling seems to be bust in 2.6.12-rc2. Try using
> `nmi_watchdog=0' if you experience weird crashes.
>
> - The possible kernel-timer related hangs might possibly be f
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> Nick Piggin wrote:
>
> >
> >One problem I just noticed, sorry. This is doing set_cpus_allowed
> >without holding the runqueue lock and without checking the hard
> >affinity mask either.
> >
>
> Err, that is to say set_task_cpu, not set_cpus_allowed.
y
> "Sven" == Sven Luther <[EMAIL PROTECTED]> writes:
Sven> On Mon, Apr 04, 2005 at 12:21:05PM +0200, Arjan van de Ven
Sven> wrote:
>> On Mon, 2005-04-04 at 12:09 +0200, Sven Luther wrote:
>>
>> please take this discussion elsewhere. Also please never cc three
>> such
Sven> Ok, can you please
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 they don't get any work done. They are
> already aware
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> We could just do a set_cpus_allowed, or take the lock,
> set_cpus_allowed, and take the new lock, but that's probably a bit
> heavy if we can avoid it. In the interests of speed in this fast path,
> do you think we can do this in sched_fork, before th
> "Matthew" == Matthew Wilcox <[EMAIL PROTECTED]> writes:
Matthew> On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
>> Then let's see some acts. We (lkml) are not the ones with the
>> percieved problem, or the ones discussing it.
Matthew> Actually, there are some legitimate problems
> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
Jeff> Sven Luther wrote:
>> Yep, but in the meantime, let's clearly mark said firmware as
>> not-covered-by-the-GPL. In the acenic case it seems to be even
>> easier, as the firmware is in a separate acenic_firmware.h file,
>> and it just nee
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
>
> What do you think of the following patch? I won't send the
> whole series again, I'll queue them up with Andrew if you
> think this one looks OK (which is the only major change).
this one looks good too.
Acked-by: Ingo Molnar <[EMAIL PR
The only thing that would avoid this is to either tell the compiler to
never put esi/edi in memory (which I think is not possibly across
different versions of gcc) or to always generate a single asm section
for all the different cases.
Use __asm__ ("%esi") and __asm__ ("%edi"). It is not guarante
>
> I'm still seeing 'APIC error on CPU0: 00(40)' messages from time to time.
Thanks for the analysis. The clear_IO_APIC_pin looks quite hackish,
I am not sure I want to put that into the mainline kernel.
The APIC errors are also suspicious.
I don't want to blacklist ATI from just a single repor
On Wed, Apr 06, 2005 at 08:42:08 -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 they don't get any work done. They are
> already
On Thu, 7 Apr 2005, Magnus Damm wrote:
> On Apr 6, 2005 4:28 PM, Malcolm Rowe <[EMAIL PROTECTED]> wrote:
> > Magnus Damm writes:
> > > And I guess the idea of replacing the initcall pointer with NULL will
> > > work both with and without function descriptors, right? So we should
> > > be safe on I
On Thu, 2005-04-07 at 09:36 +0200, Guillaume Thouvenin wrote:
> Hi Evgeniy,
>
> I forgot to put you in the CC of the email so I'm forwarding a post
> about the connector sent on lkml.
Ok, I'm in.
> Best regards,
> Guillaume
> email message attachment, "Forwarded message - Re: connector is
> mi
On Thu, 2005-04-07 at 16:51 +1000, Paul Mackerras wrote:
> Linus,
>
> > That "individual patches" is one of the keywords, btw. One thing that BK
> > has been extremely good at, and that a lot of people have come to like
> > even when they didn't use BK, is how we've been maintaining a much finer
On Wed, 6 Apr 2005, Jeff Garzik wrote:
> On Thu, Apr 07, 2005 at 11:40:23AM +1000, Martin Pool wrote:
> > On Wed, 06 Apr 2005 23:39:11 +0400, Paul P Komkoff Jr wrote:
> >
> > > http://bazaar-ng.org/
> >
> > I'd like bazaar-ng to be considered too. It is not ready for adoption
> > yet, but I am
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
At a minimum i think we need the fix+comment below.
Well if we say "this is actually RCU", then yes. And we should
probably change the preempt_{dis|en}ables in other places to
rcu_read_lock.
OTOH, if we say we just want all running thr
Información de incidente:-
Base de datos: g:/lotus/intranet5/data/mail2.box
Originador: linux-kernel@vger.kernel.org
Destinatarios: [EMAIL PROTECTED]
Asunto: Mail System Error - Returned Mail
Fecha/Hora: 07/04/2005 09:58:00
El adjunto attachment.cmd que
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > > > I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it
> > > > seems that you removed the connector?
> > >
> > > Greg dropped it for some reason. I think that's best because it needed a
> > > significant amount of rework. I'd
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 like to exercise my ri
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 want to t
On Thu, 2005-04-07 at 11:53 +0400, Evgeniy Polyakov wrote:
> > > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hello,
> > > >
> > > > I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it
> > > > seems that you removed the connector?
> > >
> > > Greg dropped it f
On Wed, 6 Apr 2005, [EMAIL PROTECTED] wrote:
> No, sorry, i have to run with bridging support other wise the guests(UML's)
> wont be able to communicate with the outside world.
Ok in that case, can you connect a serial console so that you can capture
the entire output?
Thanks,
Zwane
-
* Stas Sergeev <[EMAIL PROTECTED]> wrote:
> ENTRY(sysenter_entry)
> movl TSS_sysenter_esp0(%esp),%esp
> sysenter_past_esp:
> - sti
> pushl $(__USER_DS)
> pushl %ebp
> + sti
ah, yes, sysenter. SYSENTER creates a degenerate 'small' stackframe with
an esp0 that is missing
On Apr 7, 2005 4:32 AM, David Lang <[EMAIL PROTECTED]> wrote:
> On Thu, 7 Apr 2005, Martin Pool wrote:
>
> > I haven't tested importing all 60,000+ changesets of the current bk tree,
> > partly because I don't *have* all those changesets. (Larry said
> > previously that someone (not me) tried to
* Mingming Cao <[EMAIL PROTECTED]> wrote:
> It seems we are holding the rsv_block while searching the bitmap for a
> free bit. In alloc_new_reservation(), we first find a available to
> create a reservation window, then we check the bitmap to see if it
> contains any free block. If not, we wi
On Thu, 2005-04-07 at 00:58 -0700, Andrew Morton wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > > > > I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it
> > > > > seems that you removed the connector?
> > > >
> > > > Greg dropped it for some reason. I think that'
On Wed, Apr 06, 2005 at 11:42:57PM -0700, Andrew Morton wrote:
> Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> >
> > Hello,
> >
> > I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it
> > seems that you removed the connector?
>
> Greg dropped it for some reason. I think tha
* Frank Sorenson <[EMAIL PROTECTED]> [050406 14:16]:
> Tony Lindgren wrote:
> > Hi all,
> >
> > 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 b
On Thu, 2005-04-07 at 01:17 -0700, Greg KH wrote:
> On Wed, Apr 06, 2005 at 11:42:57PM -0700, Andrew Morton wrote:
> > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> > >
> > > Hello,
> > >
> > > I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it
> > > seems that you removed t
On Thu, Apr 07, 2005 at 12:30:49PM +0400, Evgeniy Polyakov wrote:
> On Thu, 2005-04-07 at 01:17 -0700, Greg KH wrote:
> > On Wed, Apr 06, 2005 at 11:42:57PM -0700, Andrew Morton wrote:
> > > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hello,
> > > >
> > > > I don't see the conn
> 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
> under a written agreemen
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 barriers says "something weird is happening here",
> > and it remains unobv
On Apr 7, 2005 4:23 AM, Roland Dreier <[EMAIL PROTECTED]> wrote:
> > > -#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(
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 th
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 ot
* 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
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 ohci13
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))
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
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
> for the firmware (and the required compilers, starting with genfw.c which is
> mentioned in acenic_firmware.h) since - as far as I know - firmware i
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
> > for the firmware (and the required compilers, starting with genfw.c which
>
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
> > >
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 t
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
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 t
> > > 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 a
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 wa
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.
>
> The
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 diffe
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,
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).
>
> O
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 20:47
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 s
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 '
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 existing
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 barrier
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 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 k
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 FIRST_USER_
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 preempt
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 running
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 thes
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 and
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 alternati
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, 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 99
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 tree
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 awar
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 disable
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 confli
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 "Diabl
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
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.
>
> /p
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 t
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 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?
> D
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 N
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 you
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 f
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 ne
> 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 initrd
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 snapshot
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 und
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'
make
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 1452
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 __might_sleep()
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 Registered
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 :
>
> 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 la
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
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
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
>
> 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...
>
we
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 f
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 f
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 s
1 - 100 of 355 matches
Mail list logo