I looked at my "include/asm-i386/param.h" and the HZ value is 1000.So, I
suppose the timer interrupt frequency is 1000 times per sec. or once every 1
millisec.
So, is scheduler_tick() ( for resceduling) called only once every 1 ms?? I
am measuring the time when 2 of my processes are scheduled
I disabled the FIFO resetting code and am running tests. See what
happens. I am on 2.6 not
2.4 so it could be a problem there. At any rate, I will see if the
problem goes away.
Jeff
Willy Tarreau wrote:
On Sat, Apr 02, 2005 at 11:58:44PM -0700, jmerkey wrote:
It works fine with the Intel
David Lang wrote:
On Sat, 2 Apr 2005, Andreas Dilger wrote:
given that this would let you get the same storage with about 1200
fewer
drives (with corresponding savings in raid controllers, fiberchannel
controllers and rack frames) it would be interesting to know how
close it
would be (for a lot
On Sat, Apr 02, 2005 at 11:58:44PM -0700, jmerkey wrote:
>
> It works fine with the Intel Dual Port Pro-1000 MT adapters without
> these problems.
but unless I'm mistaken, there's no PCI bridge on this board, and it is
possible that the two ports share the same IRQ, that's why I suggested
Jeff Garzik wrote:
jmerkey wrote:
With linux 2.6.9 running at 192 MB/S network loading and protocol
splitting drivers routing packets out of
a 2.6.9 device at full 100 mb/s (12.5 MB/S) simultaneously over 4
ports, the adaptec starfire driver goes into
constant Tx FIFO reconfiguration mode and
It works fine with the Intel Dual Port Pro-1000 MT adapters without
these problems. I am using testing scenarios
with Jumbo Frames as well. I am guessing the PCI bus contention is high
due to the disk I/O bandwidth and
this is causing conditions the adapter does not normally see.
Documentation
jmerkey wrote:
With linux 2.6.9 running at 192 MB/S network loading and protocol
splitting drivers routing packets out of
a 2.6.9 device at full 100 mb/s (12.5 MB/S) simultaneously over 4 ports,
the adaptec starfire driver goes into
constant Tx FIFO reconfiguration mode and after 3-4 days of
On Sat, 2 Apr 2005, Andreas Dilger wrote:
given that this would let you get the same storage with about 1200 fewer
drives (with corresponding savings in raid controllers, fiberchannel
controllers and rack frames) it would be interesting to know how close it
would be (for a lot of people the
* Paul Jackson <[EMAIL PROTECTED]> wrote:
> Just so as no else wastes time repeating the little bit I've done so
> far, and so I don't waste time figuring out what is already known,
> here's what I have so far, trying out Ingo's "sched: auto-tune
> migration costs" on ia64 SN2:
>
> To get it
Steven Rostedt wrote:
Have you benchmarked your own memory manager?
kmalloc(1024, GFP_KERNEL) is something like 17 instructions on i386
uniprocessor.
Where did you get that? I'm looking at the assembly of it right now and
it's much larger than 17 instructions. Not to mention that it calls
On Apr 02, 2005 22:36 -0800, David Lang wrote:
> On Fri, 1 Apr 2005, Chen, Kenneth W wrote:
> >To run this "industry db benchmark", assuming you have a 32-way numa box,
> >I recommend buying the following:
> >
> >512 GB memory
> >1500 73 GB 15k-rpm fiber channel disks
> >50 hardware raid
The hlist_for_each_entry_rcu() comment block refers to a nonexistent
hlist_add_rcu() API, needs to change to hlist_add_head_rcu().
Signed-off-by: <[EMAIL PROTECTED]>
---
diff -urpN -X dontdiff linux-2.6.12-rc1/include/linux/list.h
linux-2.6.12-rc1-bettersk/include/linux/list.h
---
Update the RCU documentation to allow for the new synchronize_rcu() and
synchronize_sched() primitives. Fix a few other nits as well.
Signed-off-by: <[EMAIL PROTECTED]>
---
Depends on the earlier "Deprecate synchronize_kernel, GPL replacement" patch.
RTFP.txt | 29
On Fri, 1 Apr 2005, Chen, Kenneth W wrote:
To run this "industry db benchmark", assuming you have a 32-way numa box,
I recommend buying the following:
512 GB memory
1500 73 GB 15k-rpm fiber channel disks
50 hardware raid controllers, make sure you get the top of the line model
(the one has 1GB
On Sun, Apr 03, 2005 at 08:18:11AM +0200, Arjan van de Ven wrote:
> On Sat, 2005-04-02 at 22:11 -0800, Paul E. McKenney wrote:
> > Add a deprecated_for_modules macro that allows symbols to be
>
>
> > +#ifdef MODULE
> > +#define deprecated_for_modules __deprecated
> > +#else
> > +#define
This patch changes calls to synchronize_kernel(), deprecated in the
earlier "Deprecate synchronize_kernel, GPL replacement" patch to
instead call the new synchronize_rcu() and synchronize_sched() APIs.
Signed-off-by: <[EMAIL PROTECTED]>
---
arch/i386/oprofile/nmi_timer_int.c |2 +-
The synchronize_kernel() primitive is used for quite a few different
purposes: waiting for RCU readers, waiting for NMIs, waiting for interrupts,
and so on. This makes RCU code harder to read, since synchronize_kernel()
might or might not have matching rcu_read_lock()s. This patch creates
a new
On Sat, 2005-04-02 at 22:11 -0800, Paul E. McKenney wrote:
> Add a deprecated_for_modules macro that allows symbols to be
> +#ifdef MODULE
> +#define deprecated_for_modules __deprecated
> +#else
> +#define deprecated_for_modules
> +#endif
> +
how about also starting it with __ like __deprecated
Add a deprecated_for_modules macro that allows symbols to be
deprecated only when used by modules, as suggested by Andrew
Morton some months back.
Signed-off-by: <[EMAIL PROTECTED]>
---
diff -urpN -X dontdiff linux-2.6.12-rc1/include/linux/module.h
On Sun, Mar 27, 2005 at 04:34:54PM +0200, Adrian Bunk wrote:
> Due to the patent situation at least in the USA, the exports of
> kernel/rcupdate.c should be EXPORT_SYMBOL_GPL.
Based on -what- line of reasoning??? The obvious ones do not apply
to this situation.
These need to be put back.
Hi Ingo,
I need the following two patches to keep my system alive and avoid
the BUGs in the log send to you earlier (private mail).
--- example BUG
BUG: using smp_processor_id() in preemptible [0001] code: java/16460
caller is icmp_send+0x9b/0x3d0
Just so as no else wastes time repeating the little bit I've done so
far, and so I don't waste time figuring out what is already known,
here's what I have so far, trying out Ingo's "sched: auto-tune migration
costs" on ia64 SN2:
To get it to compile against 2.6.12-rc1-mm4, I did thus:
1.
Hi Jeff,
I've also experienced those messages under 2.4, but they were harmless,
and I never had a machine hang even after weeks of full load (the adapter
was mounted on a stress test machine before being used in firewalls for
months).
So I wonder how you can be sure that it is this driver which
Jeff Garzik wrote:
David Liontooth wrote:
:02:0b.0 Ethernet controller: Marvell Technology Group Ltd. Yukon
Gigabit Ethernet 10/100/1000Base-T Adapter (rev 13)
You want the sk98lin or skge drivers.
Correct -- that one worked already in Debian-Installer. What was
confusing is that the
With linux 2.6.9 running at 192 MB/S network loading and protocol
splitting drivers routing packets out of
a 2.6.9 device at full 100 mb/s (12.5 MB/S) simultaneously over 4 ports,
the adaptec starfire driver goes into
constant Tx FIFO reconfiguration mode and after 3-4 days of constantly
With linux 2.6.9 running at 192 MB/S network loading and protocol
splitting drivers routing packets out of
a 2.6.9 device at full 100 mb/s (12.5 MB/S) simultaneously over 4 ports,
the adaptec starfire driver goes into
constant Tx FIFO reconfiguration mode and after 3-4 days of constantly
On Sun, Apr 03, 2005 at 10:56:44AM +0900, Tomita, Haruo wrote:
> Isn't there race issue during fput() and the dentry_open()?
> When booting kernel, the following deadlocks are experienced.
> Stack traceback for pid 2130
> 0xf717f1b021301 1 0 R 0xf717f400
Manfred Spraul wrote:
Gigabyte's K8NS Ultra-939 mobo has a 100/10 LAN PHY chip, ICS1883, which
isn't detected by the 2.6.12-rc1 kernel (and likely not previous
kernels).
The board is a nVidia nForce board, correct? Then please try the
forcedeth network driver ("Reverse Engineered nForce Ethernet
Hello!
I believe that the synchronize_kernel() needs a matching
rcu_read_lock() and rcu_read_unlock() pair as shown below,
along with an rcu_dereference(). Without these, I believe
that the following sequence of events could occur:
o CPU 0 in ItLpQueue_process() tests the lpEventHandler
$B%"%J%?$N$?$a$K=PMh>e$,$j$^$7$?(B
$B%^%8%a$J=P2q$$7O%5%$%H$G$9!#(B
http://com.deai-pc.com/?num=20010
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Sat, 2005-04-02 at 20:08 -0800, David S. Miller wrote:
> > Did anyone have a preference for the API? I was thinking
> > ioread32_native, but ioread32be is fine too.
>
> I think doing foo{be,le}{8,16,32}() would be consistent with
> our byteorder.h interface names.
Thinking about this some
On Sun, 2005-04-03 at 07:46 +0530, Arun Srinivas wrote:
> I attached the 'dmesg' output because there it shows that my kernel
> recogonized 2 cpu's.As said earlier , are they treated as 2 physical cpu's
> or logical cpu's?
>
As I said, they are logical
[snip]
> > > available
> > > Apr 2
On Sat, 02 Apr 2005 21:40:39 -0600
James Bottomley <[EMAIL PROTECTED]> wrote:
> After all, the driver must know the card is BE, so the routines that
> make use of the feature are easily coded into the card, so there's no
> real need to add it to the iomem cookie.
Yes, I don't believe it needs to
At 3:13 AM -0500 4/2/05, Lee Revell wrote:
On Fri, 2005-04-01 at 23:05 -0800, Pallipadi, Venkatesh wrote:
It can be SMI happening in the platform. Typically BIOS uses some SMI
> polling to handle some devices during early boot. Though 500
microseconds > sounds a bit too high.
Nope, that sounds
On Sun, 2005-04-03 at 04:10 +0100, Matthew Wilcox wrote:
> > SPARC64 can do it in the PTEs, but we just use raw physical
> > addresses in our I/O accessors, and in those load/store instructions
> > we can specify the endianness.
>
> Ah right. So you'd prefer an ioread8be() interface?
Actually,
hi
can someone show me an example usage of sched_setaffinity().I do not know
how to set the affinity mask for a process.please.
thanks
arun
_
Marriages at Bharatmatriony.com
http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?74
On Sat, Apr 02, 2005 at 06:38:05PM -0800, David S. Miller wrote:
> > My thought on this is that we should encode the endianness of the
> > registers in the ioremap cookie. Some architectures (sparc, I think?) can
> > do this in their PTEs. The rest of us can do it in our ioread/writeN
> >
Geachte dames en heren,
Ergert u zich ook altijd over de hoge prijzen die voor software gevraagd
worden?
Daar komt nu een einde aan. Wij leveren u alle mogelijke software voor een
fractie van de normale prijs.
De software wordt vanuit het buitenland direct naar uw adres verzonden,
omdat het
On Sun, 3 Apr 2005 02:37:57 +0100
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> My thought on this is that we should encode the endianness of the
> registers in the ioremap cookie. Some architectures (sparc, I think?) can
> do this in their PTEs. The rest of us can do it in our ioread/writeN
>
I attached the 'dmesg' output because there it shows that my kernel
recogonized 2 cpu's.As said earlier , are they treated as 2 physical cpu's
or logical cpu's?
From: Steven Rostedt <[EMAIL PROTECTED]>
To: Arun Srinivas <[EMAIL PROTECTED]>
CC: LKML
Subject: Re: sched /HT processor
Date: Sat,
Isn't there race issue during fput() and the dentry_open()?
(BWhen booting kernel, the following deadlocks are experienced.
(B
(BStack traceback for pid 2130
(B0xf717f1b0 21301 1 0 R 0xf717f400 *irqbalance
(BESP EIP Function (args)
(B0xf75bfe38
On Sat, Apr 02, 2005 at 02:52:14PM -0600, James Bottomley wrote:
> This driver has had it's own different infrastructure for doing this for
> ages, but it's time it used the common one.
Thanks. I'd been looking at this for a while but hadn't got round tuit yet.
> #ifdef CONFIG_53C700_LE_ON_BE
David Liontooth wrote:
:02:0b.0 Ethernet controller: Marvell Technology Group Ltd. Yukon
Gigabit Ethernet 10/100/1000Base-T Adapter (rev 13)
You want the sk98lin or skge drivers.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Sun, 2005-04-03 at 06:07 +0530, Arun Srinivas wrote:
> HI
>
> I have pentium4 hyperthreaded processor.I am using kernel 2.6.5 and i
> rebuilt my kernel with CONFIG_SMP enabled (in this kernel source there is
> nothing such as CONFIG_SMT...i noticed this only in recent 2.6.11).
>
I don't
On Saturday 02 April 2005 19:38, Joseph E. Sacco, Ph.D. wrote:
>prepatch 2.6.12-rc1 [2005-03-18 02:52 UTC] does not apply cleanly to
>linux-2.6.11.6:
Its not supposed to, its against the bare 2.6.11.tar.gz output.
[...]
Its also the smoothest, snappiest kernel to come around in quite a
while.
On Sat, 2 Apr 2005, Joseph E. Sacco, Ph.D. wrote:
> prepatch 2.6.12-rc1 [2005-03-18 02:52 UTC] does not apply cleanly to
> linux-2.6.11.6:
>
No, it does not, it applies to the base 2.6.11, *not* to 2.6.11.6 - first
back out the 2.6.11.6 patch, then apply the 2.6.12-rc1 patch.
--
Jesper Juhl
prepatch 2.6.12-rc1 [2005-03-18 02:52 UTC] does not apply cleanly to
linux-2.6.11.6:
./net/ipv4/fib_hash.c.rej
./net/ipv4/tcp_timer.c.rej
./net/netrom/nr_in.c.rej
./net/xfrm/xfrm_state.c.rej
./sound/pci/ac97/ac97_codec.c.rej
./drivers/pci/hotplug/pciehp_ctrl.c.rej
./drivers/net/wan/hd6457x.c.rej
HI
I have pentium4 hyperthreaded processor.I am using kernel 2.6.5 and i
rebuilt my kernel with CONFIG_SMP enabled (in this kernel source there is
nothing such as CONFIG_SMT...i noticed this only in recent 2.6.11).
1) So, after I rebulit it with CONFIG_SMP enabled does linux recogonize my
On Sat, 2 Apr 2005, Andrew Morton wrote:
> Jesper Juhl <[EMAIL PROTECTED]> wrote:
> >
> > However, it seems you did *not* roll
> > figure-out-who-is-inserting-bogus-modules-warning-fix.patch into
> > figure-out-who-is-inserting-bogus-modules.patch but instead just dropped
> > the patch.
>
On Sun, 3 Apr 2005, Jesper Juhl wrote:
>
> Hi Andrew,
>
> Reading your 2.6.12-rc1-mm4 announce text I see
>
> ...
> -figure-out-who-is-inserting-bogus-modules-warning-fix.patch
>
> Folded into figure-out-who-is-inserting-bogus-modules.patch
> ...
>
Jesper Juhl <[EMAIL PROTECTED]> wrote:
>
> However, it seems you did *not* roll
> figure-out-who-is-inserting-bogus-modules-warning-fix.patch into
> figure-out-who-is-inserting-bogus-modules.patch but instead just dropped
> the patch.
I meant to drop it - it was just a debug thing, and we
On Mar 26, 2005 7:32 PM, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
>
> On 2005-03-26, at 16:19, Arjan van de Ven wrote:
>
> > `
> >> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> >> hda: dma_intr: error=0x84 { DriveStatusError BadCRC
> >
> > BadCRC is 99% sure a cabling issue;
Hi Andrew,
Reading your 2.6.12-rc1-mm4 announce text I see
...
-figure-out-who-is-inserting-bogus-modules-warning-fix.patch
Folded into figure-out-who-is-inserting-bogus-modules.patch
...
figure-out-who-is-inserting-bogus-modules.patch
Figure out who is inserting bogus modules
...
However,
Jeremy Nickurak <[EMAIL PROTECTED]> writes:
> I'm playing with this under 2.6.11.4
I got 2.6.12-rc1
> The vertical cruise control buttons work properly, with the
> exception of the extra button press.
Yup, nice, I see the same
> But the horizontal buttons are mapping to 6/7 as non-repeat
Hi, i got a new ahtec laptop and i get null pointer oops everytime i
load i810_audio on 2.4 and 2.6 (including 2.6.11.6) kernels.
*** These are init messages & oops:
i810_audio: Unknown symbol ac97_set_dac_rate
i810_audio: Unknown symbol ac97_release_codec
i810_audio: Unknown symbol
On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote:
> > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
> > Grub option), and the system just locked up hard. I just was curious
> > if this was from a different change. But at least in the latest it
> > shows output, and
Sam, my patch to automatically include a random value based upon the
BitKeeper or CVS version in the kernel version had one, rather minor,
bug related to building in seperate object and source trees.
This patch fixes that up.
Signed-Off-By: Ryan Anderson <[EMAIL PROTECTED]>
Index:
On Sun, 3 Apr 2005, Jose Luis Domingo Lopez wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all:
>
> I am getting the following stack dump in the logs when I try to unload the
> "bttv" kernel module ("rmmod bttv" ends with SIGSEGV). I have tried with
> other kernel versions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all:
I am getting the following stack dump in the logs when I try to unload the
"bttv" kernel module ("rmmod bttv" ends with SIGSEGV). I have tried with
other kernel versions keeping "module-init-tools" version the same (Debian
3.1-rel-2), and
Jesper Juhl schrieb:
Cleanup spacing and trailing whitespace in fs/cifs/dir.c
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch1 2005-04-02
23:31:27.0 +0200
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-02 23:47:39.0 +0200
@@ -37,7
On Sun, 3 Apr 2005, Matthias-Christian Ott wrote:
> Jesper Juhl schrieb:
>
> > Cleanup spacing and trailing whitespace in fs/cifs/dir.c
> >
[snip]
> >
> The Subject is wrong it must be: "[PATCH][2/7] cifs: dir.c cleanup - spaces"
>
Yup, it is. Unfortunately I only saw that milliseconds
Labeled this one [1/7] initially, by mistake, it is of course [2/7] -
whoops.
Cleanup spacing and trailing whitespace in fs/cifs/dir.c
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch1 2005-04-02
23:31:27.0 +0200
+++
Don't cast the pointer returned from kmalloc()
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch4 2005-04-03
00:03:33.0 +0200
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-03 00:04:58.0 +0200
@@ -280,8 +280,8 @@ int
Lines should be <80 chars in length.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch5 2005-04-03
00:06:17.0 +0200
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-03 00:07:59.0 +0200
@@ -193,9 +193,9 @@ int cifs_create(struct
Beautify comments in fs/cifs/dir.c and make them style-wise consistent with
the other files.
Signed-of-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch2 2005-04-02
23:51:24.0 +0200
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-02
Lines should be less than 80chars, rework cifs_create() a bit to fit more
easily.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch6 2005-04-03
00:17:50.0 +0200
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-03 00:21:00.0
Remove redundant NULL pointer checks before kfree() in fs/cifs/dir.c
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch3 2005-04-03
00:02:22.0 +0200
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-03 00:02:24.0 +0200
@@ -321,12
Cleanup spacing and trailing whitespace in fs/cifs/dir.c
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch1 2005-04-02
23:31:27.0 +0200
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-02 23:47:39.0 +0200
@@ -37,7 +37,7 @@ void
Whitespace cleanups of function definitions in fs/cifs/dir.c
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4-orig/fs/cifs/dir.c 2005-03-02 08:38:12.0
+0100
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-02 23:28:28.0 +0200
@@ -31,8 +31,7 @@
Can someone please explain why I get this every time I switch in and out
of X? And better yet how do I turn this off?
debug atyfb: Mach64 non-shadow register values:
debug atyfb: 0x2000: 004F0063 000C0052 01DF020C 000201EA
debug atyfb: 0x2010: 016F 1400 0020 0B002200
debug atyfb:
Hi Steve,
Here's yet another round of cleanups for fs/cifs/ - this time it's for
dir.c.
I believe this marks the end of the files you wanted done in a specific
order, so now I'll be going through the remaining ones in arbitrary order.
Just like for the previous files I've split the cleanups
On Saturday 02 April 2005 15:34, Ingo Molnar wrote:
>* Lee Revell <[EMAIL PROTECTED]> wrote:
>> It wasn't clear from your last mail whether you were using NFS.
>> If so I would be suspicious given the NFS changes in the new RT
>> patches. I'll try to reproduce the problem on a local fs.
>
>also,
On Sat, 2 Apr 2005, Maciej Soltysiak wrote:
> Hi,
>
> out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments.
> I found one:
>
> # grep -nr "memset.*\,\(\ \|\)0\(\ \|\));" *
> net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct
> ieee80211_txb), 0);
>
And here's
On Sat, 2005-04-02 at 22:14 +0200, Manfred Spraul wrote:
> Steven Rostedt wrote:
>
> >I admit you really need to know what you're doing to use this method. If
> >I believe that a kmalloc would be too expensive, then I use the locking
> >of static variables. But each situation is different and I
Hi!
This fixes remaining u32s in drivers/ net. [These patches are
independend].
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
--- clean-cvs/drivers/net/8139cp.c 2005-01-16 22:27:04.0 +0100
+++
On Fri, Apr 01, 2005 at 07:18:52PM +0200, Uwe Zybell wrote:
> There is a line in fs/partitions/msdos.c that lets extended partitions
> be max 1k (..."==1 ? 1 : 2"...). The comment explains it to protect
> sysadmins from themselves. But now I have found a legitimate use
> for extended partitions
Hi!
This fixes drivers/pci (mostly pcie stuff). [These patches are
independend and change no object code; therefore not numbered].
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
---
Hi!
> > This is last of the series. I tried to submit patches through their
> > mainainers (when they were easy to determine, our MAINTAINERS file
> > sucks).
>
> You mean that there are patches in addition to these seven?
Yes, there are 7 more. They were sent to l-k and maintainers. I'll
On Sat, 2005-04-02 at 15:44 -0500, Steven Rostedt wrote:
> On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote:
> > >
> > > FYI
> > >
> > > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
> > > Grub option), and the system just locked up hard. I just was curious
> > >
On Sat, 2 Apr 2005, |TEcHNO| wrote:
> Hi,
>
>
> First of all, I don't have my X configured to work w/o that module, and I
> don't think I can do it now.
You should be able to just use the "nv" driver instead of the "nvidia"
driver - that should be the only change you need to make in xorg.conf
Hi!
I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately
that turned out not to be the case as Russel King pointed out. Here
are fixes for drivers/macintosh. [These patches are independend and
change no object code; therefore not numbered].
Please apply,
Signed-off-by: Pavel
Hi,
out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments.
I found one:
# grep -nr "memset.*\,\(\ \|\)0\(\ \|\));" *
net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct
ieee80211_txb), 0);
I found none in Linus' bk.
Regards,
Maciej
-
To unsubscribe from this
Hi!
This fixes u32 vs. pm_message_t in drivers/message. [These patches are
independend and change no object code; therefore not numbered].
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
---
Ingo wrote:
> in theory the code should work fine on ia64 as well,
Nice. I'll try it on our SN2 Altix IA64 as well.
Though I am being delayed a day or two in this
by irrelevant problems.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Hi!
This fixes u32 vs. pm_message_t in drivers/mmc, drivers/mtd and
drivers/scsi. [These patches are independend and change no object
code; therefore not numbered].
This is last of the series. I tried to submit patches through their
mainainers (when they were easy to determine, our MAINTAINERS
Hi!
Here are fixes for drivers/media. [These patches are independend and
change no object code; therefore not numbered].
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
---
Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> This is last of the series. I tried to submit patches through their
> mainainers (when they were easy to determine, our MAINTAINERS file
> sucks).
You mean that there are patches in addition to these seven?
> Unfortunately that probably means some
On Saturday 02 April 2005 20:10, Andrew Walrond wrote:
>
> In the meantime, I'm going to remove this driver from the .config
>
Boots fine without this driver compiled in (SCSI_FUTURE_DOMAIN=n)
Andrew Walrond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Hi!
This fixes u32 vs. pm_message_t in pcmcia. [These patches are
independend and change no object code; therefore not numbered]. Please
apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
---
On Sat, 2005-04-02 23:03:14 +0200, Geert Uytterhoeven <[EMAIL PROTECTED]>
wrote in message <[EMAIL PROTECTED]>:
> On Fri, 1 Apr 2005, Jan-Benedict Glaw wrote:
> > Well, the patch looks fine, but you forgot to also do the VAX-specific
> > part. Withoug the BUGs, maybe the VAX kernel would be even
Hi!
I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately
that turned out not to be the case as Russel King pointed out. Here
are remaining fixes for USB. [These patches are independend and change
no object code; therefore not numbered].
Please apply,
Signed-off-by: Pavel Machek
Hi,
First of all, I don't have my X configured to work w/o that module, and
I don't think I can do it now.
Second of all, the 2.4.x kernel had this module too, and worked flawlessly.
Non the less, I'll try to do it.
--
pozdrawiam |"Help me master, I felt the burning twilight behind
[EMAIL
Hi!
I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately
that turned out not to be the case... Here are fixes x86-64. [These
patches are independend and change no object code; therefore not
numbered].
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Hi!
Here are fixes for drivers/char. [These patches are independend and
change no object code; therefore not numbered].
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
--- clean-cvs/drivers/char/agp/efficeon-agp.c
Hi!
I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately
that turned out not to be the case as Russel King pointed out. Here
are fixes for Documentation and common code (mainly system
devices). [These patches are independend and change no object code;
therefore not numbered].
On Sat, 2 Apr 2005, |TEcHNO| wrote:
> Hi,
>
> I've recently switched form 2.4.x kernel series to 2.6.x, and I've encourted a
> problem with my old scanner card,
> Apr 1 17:29:41 techno kernel: Modules linked in: nvidia
^^^ Very first thing to do is try it without the nvidia module loaded and
Hi,
If you'r asking:
$ uname -r
2.6.11.3
--
pozdrawiam |"Help me master, I felt the burning twilight behind
[EMAIL PROTECTED]|those gates of stell..." --Perihelion, Prophecy Sequence
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Fri, 1 Apr 2005, Jan-Benedict Glaw wrote:
> On Fri, 2005-04-01 01:07:44 -0800, Matt Mackall <[EMAIL PROTECTED]>
> wrote in message <[EMAIL PROTECTED]>:
> > I've been sitting on this patch for a while, figured it's high time I
> > shared it with the world. This patch eliminates all kernel bugs,
On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
> >
> > > Here's the bug I get:
> > >
> >
> > FYI
> >
> > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
>
Jacek Luczak napisaÅ(a):
Matan Peled napisaÅ(a):
Jacek Luczak wrote:
Hi
Early morning i made a 2.6.12-rc1 with RT-V0.7.43-05 and this is what I
sow in dmesg after 6 hours of computers work:
Hmm... A lot of that seems to involve ndiswrapper. Is there any way
you could
reproduce this without
1 - 100 of 323 matches
Mail list logo
