Recently I debugged something that was spinning in the for(;;) in
__getblk_slow(). It turned out it was calling __getblk() with a size
argument that didn't match the bdev's inode's i_blkbits.
grow_buffers() would add a page at the index calculated from the 4k size
argument but when
* [EMAIL PROTECTED] [EMAIL PROTECTED]:
Whenever I modprobe parport_pc, I get this message:
Jan 27 10:55:47 hummus kernel: pnp: Device 00:0b activated.
Jan 27 10:55:47 hummus kernel: parport: PnPBIOS parport detected.
Jan 27 10:55:47 hummus kernel: pnp: Device 00:0b disabled.
and
Viktor Horvath wrote:
Hello everybody,
today I patched myself up from 2.6.7 vanilla to 2.6.10 vanilla, but
after all patches succeeded, make menuconfig shows v2.6.8.1
Configuration. Even worse, a compiled kernel calls in his bootlog
himself 2.6.8.1.
I guess you did somthing like this:
2.6.7
* Tony Lindgren [EMAIL PROTECTED] [050127 13:34]:
Hi all,
Thanks for all the comments, here's an updated version of the dynamic
tick patch.
Oops, I guess I should test before posting :)
Looks like CONFIG_X86_LOCAL_APIC=y is currenly needed on uniprocessor
machines to compile. Also
Jason Gaston wrote:
This patch adds the Intel ICH7R DID's to the ahci.c SATA AHCI driver for ICH7R
SATA support.
If acceptable, please apply.
applied
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
I feel the need to point something out here.
[TEXT][BRK][MMAP---][STACK]
Here's a normal layout.
[TEXT][BRK][MMAP---][STACK][MMAP--]
Is this one any worse?
yes.
oracle, db2 and similar like to mmap 2Gb or more *in one chunk*.
moving the stack in the middle means the
Hi,
I'm getting a kernel Oops while booting 2.6.11-rc2-mm1
on a diskless (nfsroot based) embedded ppc system.
Vanilla 2.6.11-rc2 works Ok.
[...]
VFS: Mounted root (nfs filesystem) readonly.
Freeing unused kernel memory: 112k init
INIT: version 2.86 booting
Oops: kernel access of bad area, sig:
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
(b) sys_mremap() isn't covered.
On Thu, Jan 27, 2005 at 03:58:12PM -0500, Rik van Riel wrote:
AFAICS it is covered.
--- mm1-2.6.11-rc2.orig/mm/mremap.c 2005-01-26 00:26:43.0 -0800
+++
On Thu, 27 Jan 2005, Marcelo Tosatti wrote:
On Thu, Jan 27, 2005 at 07:38:49AM +0100, Ake wrote:
On Wed, Jan 26, 2005 at 12:49:04PM -0200, Marcelo Tosatti wrote:
--- a/mm/filemap.c.orig 2004-11-17 09:54:22.0 -0200
+++ b/mm/filemap.c2005-01-26 15:21:10.614842296 -0200
applied
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linus Torvalds wrote:
On Thu, 27 Jan 2005, Jaco Kroon wrote:
Hmm, just an idea, shouldn't the i8042_write_command be waiting until
the device has asserted the pin to indicate that the buffer is busy?
No. Because then you might end up waiting forever for the _opposite_
reason, namely that the
On Thu, Jan 27, 2005 at 02:54:13PM -0400, Mauricio Lin wrote:
Hi Andrea,
On Wed, 26 Jan 2005 01:49:01 +0100, Andrea Arcangeli [EMAIL PROTECTED]
wrote:
On Tue, Jan 25, 2005 at 08:11:19PM -0400, Mauricio Lin wrote:
Sometimes the first application to be killed is XFree. AFAIK the
This
Albert Herranz [EMAIL PROTECTED] wrote:
Hi,
I'm getting a kernel Oops while booting 2.6.11-rc2-mm1
on a diskless (nfsroot based) embedded ppc system.
Vanilla 2.6.11-rc2 works Ok.
[...]
VFS: Mounted root (nfs filesystem) readonly.
Freeing unused kernel memory: 112k init
INIT: version
Andrea Arcangeli [EMAIL PROTECTED] wrote:
Can you replace this:
if (cap_t(p-cap_effective) CAP_TO_MASK(CAP_SYS_RAWIO)) {
force_sig(SIGTERM, p);
} else {
force_sig(SIGKILL, p);
}
with this?
On Thu, Jan 27, 2005, DervishD [EMAIL PROTECTED] wrote:
Didn't knew about that... Thanks a lot for the info!. Is there
any documentation available for the ioctl USB interface to the
kernel? Any API guide or something like that?
You can use the kernel sources to see how to use it.
JE
-
To
On Thu, 27 Jan 2005, John Richard Moser wrote:
Your patch 5/6 for mmap rand is also small. 1M is trivial, though I'd
imagine mmap() rand would pose a bit more confusion in some cases at
least, even for small ranges.
Still, this is a joke, like OpenBSD's stackgap.
Also, besides security
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
I feel the need to point something out here.
[TEXT][BRK][MMAP---][STACK]
Here's a normal layout.
[TEXT][BRK][MMAP---][STACK][MMAP--]
Is this one any worse?
yes.
oracle, db2 and similar like to mmap
On Fri, 28 Jan 2005, Jaco Kroon wrote:
ok, how would I try this? Where can I find an example to code it from?
Sorry, I should probably be grepping ...
If the udelay() didn't work, then this one isn't worth worryign about
either. Back to the drawing board.
Yea. But for interrests
--- Andrew Morton [EMAIL PROTECTED] escribió:
Can you tell us which filesystem is being bad? Add
this:
if (!inode-i_op)
printk(%s is naughty\n, inode-i_sb-s_id);
It's probably NFS - there has been some work done in
there in -mm.
0:a is naughty
Cheers,
Albert
On Thursday 27 January 2005 11:18, Zan Lynx wrote:
On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
Unfortunately, there will ALWAYS be a path, either direct, or
indirect between the secure net and the internet.
Other than letting people use secure computers after they
On Sun, 2005-01-23 at 09:51 -0800, Linus Torvalds wrote:
with this patch the oops is gone(also tested with PREEMPT and no oops)
--- 1.32/drivers/char/pty.c 2005-01-10 17:29:36 -08:00
+++ edited/drivers/char/pty.c 2005-01-23 09:49:16 -08:00
@@ -149,13 +149,15 @@
static int
Hello,
here is a fix for a NULL pointer access problem with NFSv2 that isn't in
2.6.11-rc2-mm1, but it can't explain this NULL inode-i_op.
-- Andreas.
---BeginMessage---
Hello,
this patch has an NFSv2 problem that I haven't tripped over until today. The
fix is this:
--- 8 ---
Fix
On Fri, Jan 28, 2005 at 03:09:40PM +, Hugh Dickins wrote:
On Thu, 27 Jan 2005, Marcelo Tosatti wrote:
On Thu, Jan 27, 2005 at 07:38:49AM +0100, Ake wrote:
On Wed, Jan 26, 2005 at 12:49:04PM -0200, Marcelo Tosatti wrote:
--- a/mm/filemap.c.orig 2004-11-17 09:54:22.0 -0200
On Thu, 27 Jan 2005 13:02:48 +0100, Jens Axboe wrote:
Hi,
For the longest time, only the old PATA drivers supported barrier writes
with journalled file systems. This patch adds support for the same type
of cache flushing barriers that PATA uses for SCSI, to be utilized with
libata.
What, if
On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
3) eepro100
Unmaintained; users should use e100.
When I last mentioned eepro100 was going away, I got a few private
emails saying complaining about issues not yet taken care of in e100.
eepro100 will not be removed until these
Hi.
On Fri, 2005-01-28 at 05:43, Pavel Machek wrote:
Unfortunately I do not know how to reproduce it. I tried
parallel-building kernels for few hours and that worked okay. Swsusp
is not involved (but usb, bluetooth, acpi and sound may be).
I take it you're sure suspending is not involved
--- Andreas Gruenbacher [EMAIL PROTECTED] escribió:
Hello,
here is a fix for a NULL pointer access problem with
NFSv2 that isn't in
2.6.11-rc2-mm1, but it can't explain this NULL
inode-i_op.
-- Andreas.
Hi,
Yes, that patch seems unrelated.
Same Oops with or without it.
Thanks,
On Thu, Jan 27, 2005 at 02:29:43PM -0800, Andrew Morton wrote:
I've already queued a patch for this:
--- 25/mm/oom_kill.c~mm-fix-several-oom-killer-bugs-fix Thu Jan 27
13:56:58 2005
+++ 25-akpm/mm/oom_kill.c Thu Jan 27 13:57:19 2005
@@ -198,12 +198,7 @@ static void
Jens Axboe wrote:
Hi,
A few changes:
- Cleanup up the driver additions even more, blk_complete_barrier_rq()
does all the work now.
- Fixed up the exports
- Comment functions
- Fixed a bug with SCSI and write back caching disabled
- Rename blk_queue_flush() to blk_queue_flushing() to indicate
Doug Maxey wrote:
On Thu, 27 Jan 2005 13:02:48 +0100, Jens Axboe wrote:
Hi,
For the longest time, only the old PATA drivers supported barrier writes
with journalled file systems. This patch adds support for the same type
of cache flushing barriers that PATA uses for SCSI, to be utilized with
Hi!
Unfortunately I do not know how to reproduce it. I tried
parallel-building kernels for few hours and that worked okay. Swsusp
is not involved (but usb, bluetooth, acpi and sound may be).
I take it you're sure suspending is not involved because it happens
before you've ever
Hello again,
this looks like a good candidate. Could you please try if it fixes the
problem?
Thanks,
--
Andreas Gruenbacher [EMAIL PROTECTED]
SUSE Labs, SUSE LINUX GMBH
---BeginMessage---
This pattern from 2.4 times doesn't work very well anymore :(
Signed-off-by: Andreas Gruenbacher [EMAIL
On Thu, 2005-01-27 at 06:01, Adrian Bunk wrote:
Before I'm getting flamed to death:
This patch isn't meant for being immediately applied.
This patch makes all needlessly global code under drivers/acpi/
static.
Please review this patch.
Thanks for the patch Adrian.
I agree that this is the
I just got an interesting I see these problems too report. It
may provide a useful clue. According to Art Haas [EMAIL PROTECTED]:
I'm running the current BK kernel now, and I'm not seeing the problems
right now because, I found, I do not have some of the IP masquerading
modules installed on
On Thu, 27 Jan 2005, Viktor Horvath wrote:
Hello everybody,
today I patched myself up from 2.6.7 vanilla to 2.6.10 vanilla, but
after all patches succeeded, make menuconfig shows v2.6.8.1
Configuration. Even worse, a compiled kernel calls in his bootlog
himself 2.6.8.1. When installing the
--- Andreas Gruenbacher [EMAIL PROTECTED] escribió:
Hello again,
this looks like a good candidate. Could you please
try if it fixes the
problem?
The Oops went away with this one.
Thanks,
Your welcome.
Cheers,
Albert
__
On Thu, 2005-01-27 at 15:53 +, Alan Cox wrote:
On Mer, 2005-01-26 at 22:10, Benjamin Herrenschmidt wrote:
On Wed, 2005-01-26 at 10:34 -0600, Brian King wrote:
Well, I honestly think that this is unnecessary burden. I think that
just dropping writes returning data from the cache on
Applied.
thanks,
-Len
On Thu, 2005-01-27 at 06:04, Adrian Bunk wrote:
The prototype of the unused global function
acpi_ut_create_pkg_state_and_push was already #ifdef
ACPI_FUTURE_USAGE'd, but the actual function wasn't.
Most likely this was a bug in my patch that added
ACPI_FUTURE_USAGE.
The receiver of my Logitech Cordeless Desktop fails to report the
keyboard's class descriptor most times I insert the usb-hid module
since I changed to linux 2.6. The modell of the receiver is C-BD9-DUAL
REV C.
The request seems not to fail but the count of received characters is zero.
As I
Hi.
On Fri, 2005-01-28 at 10:01, Pavel Machek wrote:
Yes, it happened even in cases when machine was not ever suspended. I
guess I should also add that kernel is tainted: pavel, (that means I
have my own patches in; but I really believe that my changes are not
responsible).
I often believe
Pierre Ossman wrote:
I recently tried out adding PNP support to my driver to remove the
hassle of finding the correct parameters for it. This, however, causes
it to show up under the pnp bus, where as it previously was located
under the platform bus.
Is the idea that PNP devices should only
Only the ready flag was lost.
No, note that if there was valid data we would see 0xa5 instead of
0x5a that was in the buffer - because in i8042_command we invert data
coming from AUX port.
We misunderstand each other.
Let me repeat. The following happens:
We wait, then write d3, wait, then
This patch removes references to the pcxx driver drivers/char/Makefile
It depends on the previous patches.
Signed-off-by: James Nelson [EMAIL PROTECTED]
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/Makefile
linux-2.6.11-rc2-mm1/drivers/char/Makefile
---
This patch removes references to the pcxx driver in drivers/char/Kconfig
It depends on the previous patch.
Signed-off-by: James Nelson [EMAIL PROTECTED]
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/Kconfig
linux-2.6.11-rc2-mm1/drivers/char/Kconfig
---
This patch removes drivers/char/pcxx.c
It depends on the previous patches.
Signed-off-by: James Nelson [EMAIL PROTECTED]
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/pcxx.c
linux-2.6.11-rc2-mm1/drivers/char/pcxx.c
--- linux-2.6.11-rc2-mm1-original/drivers/char/pcxx.c
This patch removes drivers/char/pcxx.h
It depends on the previous patches.
Signed-off-by: James Nelson [EMAIL PROTECTED]
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/pcxx.h
linux-2.6.11-rc2-mm1/drivers/char/pcxx.h
--- linux-2.6.11-rc2-mm1-original/drivers/char/pcxx.h
This patch removes drivers/char/digi_fep.h
It depends on the previous patches.
Signed-off-by: James Nelson [EMAIL PROTECTED]
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/digi_fep.h
linux-2.6.11-rc2-mm1/drivers/char/digi_fep.h
---
This patch removes drivers/char/fep.h
It depends on the previous patches.
Signed-off-by: James Nelson [EMAIL PROTECTED]
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/fep.h
linux-2.6.11-rc2-mm1/drivers/char/fep.h
--- linux-2.6.11-rc2-mm1-original/drivers/char/fep.h
This patch removes drivers/char/digi_bios.h
It depends on the previous patches.
Signed-off-by: James Nelson [EMAIL PROTECTED]
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/digi_bios.h
linux-2.6.11-rc2-mm1/drivers/char/digi_bios.h
---
From strace output which Trever sent, OO.o seems to be getting many
-EINTRs (Interrupted System Call) which are attempted to be restarted
but again recieve EINTR when restarted. (futex, accept and poll are the
ones which get EINTR).
Whereas, when OO.o successfully starts up on my machine, I
On Thursday 27 January 2005 17:36, Linus Torvalds wrote:
I also tried increasing the total timeout value to about 5 seconds
(versus the default half second), still no success, so the device is
simply not sending back the requested values.
If it was the other way around (that it works
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill Davidsen wrote:
On Thu, 27 Jan 2005, Zan Lynx wrote:
On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
On Wednesday 26 January 2005 13:56, Bill Davidsen wrote:
On Wed, 26 Jan 2005, Jesse Pollard wrote:
On Tuesday 25 January 2005
On Thu, 2005-01-27 at 22:45 +0100, Timo Kamph wrote:
I guess you did somthing like this:
2.6.7 -patch- 2.6.8 -patch- 2.6.8.1 -patch- 2.6.9 -patch- 2.6.10.
And you didn't noticed that the 2.6.9 patch failed, because it is diffed
against 2.6.8 and not 2.6.8.1!
You're perfectly right. I
I've forwarded this to netfilter-devel for inspection.
Thanks for collecting all the data points so well.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
On Thu, 27 Jan 2005, Zan Lynx wrote:
On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
On Wednesday 26 January 2005 13:56, Bill Davidsen wrote:
On Wed, 26 Jan 2005, Jesse Pollard wrote:
On Tuesday 25 January 2005 15:05, linux-os wrote:
This isn't relevant at all. The Navy
On Thu, 27 Jan 2005 22:57:25 +
Russell King [EMAIL PROTECTED] wrote:
Has e100 actually been fixed to use the PCI DMA API correctly yet?
It seems to be doing the right thing. I see the DMA sync calls
(properly using cpu vs. device syncing variants) at the right
spots, and the only thing the
On Fri, 28 Jan 2005, ierdnah wrote:
is this patch better? should i test this too?
You probably should. The patch you've tested is really ugly, and not a fix
at all - it's really just depending on the compiler generating a specific
code sequence that will hide the race. As such, it's a
Followup to: [EMAIL PROTECTED]
By author:Julien TINNES [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Not very important but ((get_random_int() % 4096) 4) could be
optimized into get_random_int() 0xFFF0. Because 4096 is a power of 2
you won't loose any entropy by doing 0xFFF
On Thu, 27 Jan 2005, Evgeniy Polyakov wrote:
On Thu, 27 Jan 2005 10:19:51 -0500
Bill Davidsen [EMAIL PROTECTED] wrote:
Evgeniy Polyakov wrote:
On Mon, 24 Jan 2005 18:54:49 +0100
Adrian Bunk [EMAIL PROTECTED] wrote:
It seems noone who reviewed the SuperIO patches noticed that
Hi List,
When booting I see this in dmesg:
testing tea ECB encryption
test 1 (128 bit key):
0a3aea4140a9ba94
fail
test 2 (128 bit key):
775d2a6af6ce9209
fail
test 3 (128 bit key):
be7abb81952d1f1edd89a1250421df95
fail
test 4 (128 bit key):
Zan Lynx [EMAIL PROTECTED] writes:
In the reality I'm familiar with, the defense contractor's secure
projects building had one entrance, guarded by security guards who were
not cheap $10/hr guys, with strict instructions. No computers or
computer media were allowed to leave the building
The attached changelog describes what I just pushed out to BitKeeper
(and what should be appearing in the next -mm release from Andrew).
Note to BK users: please re-clone netdev-2.6, don't just 'bk pull'.
Most of this is simply stuff that is hanging out for a while in
netdev-2.6 while it --
On Thu, Jan 27, 2005 at 03:31:14PM -0800, David S. Miller wrote:
Therefore the only missing sync would be of the new RX descriptor
when linking things in like that, ie. at the end of e100_rx_alloc_skb()
if rx-prev-skb is non-NULL.
And that is inherently unsafe, since the chip may be modifying
is there a way to do this solely in i2c-core without having to
add support to all the drivers?
Corey Minyard wrote:
I have an IPMI interface driver that sits on top of the I2C code. I'd
like to get it into the mainstream kernel, but I have a few problems
to solve first before I can do that. The
On Thu, Jan 27, 2005 at 12:33:26PM -0800, David S. Miller wrote:
So they won't be listed in /proc/net/rt_cache (since they've been
removed from the lookup table) but they will be accounted for in
/proc/net/stat/rt_cache until the final release is done on the
routing cache object and it can be
Julien Not very important but ((get_random_int() % 4096) 4)
Julien could be optimized into get_random_int() 0xFFF0.
HPA .. and gcc knows that.
HPA8: 25 ff 0f 00 00 and$0xfff,%eax
HPAd: 83 c4 0cadd$0xc,%esp
HPA 10: c1 e0
On Thu, 27 Jan 2005, John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill Davidsen wrote:
On Thu, 27 Jan 2005, Zan Lynx wrote:
On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
On Wednesday 26 January 2005 13:56, Bill Davidsen wrote:
On Wed, 26 Jan 2005, Jesse
This patch fixes a memory leak in the FLASH_Burn ioctl for the Cobalt LCD
interface driver.
Signed-off-by: James Nelson [EMAIL PROTECTED]
diff -purN --exclude='*~' linux-2.4.29-original/drivers/char/lcd.c
linux-2.4.29/drivers/char/lcd.c
--- linux-2.4.29-original/drivers/char/lcd.c
This patch adds CAP_SYS_ADMIN checks to the potentially dangerous ioctls
FLASH_Erase and FLASH_Burn
in the Cobalt LCD interface driver.
Signed-off-by: James Nelson [EMAIL PROTECTED]
diff -purN --exclude='*~' linux-2.4.29-original/drivers/char/lcd.c
linux-2.4.29/drivers/char/lcd.c
---
Hi,
some thoughts and observations.
I'm running -RT + a port of UTIME (the grandfather of HRT, IIRC) on a
couple of machines (x86,ppc,arm - all UP) here.
One part of the problem is the gettimeofday() issue, which seems to be
already addressed by John Stulz's patches.
The more interresting
On Thu, Jan 27, 2005 at 03:35:35PM -0800, Andrew Morton wrote:
On x86 we could perhaps test for non-nullness of tsk-thread-io_bitmap_ptr?
yes for ioports. But I'm afraid I was too optimistic about eflags for
iopl, that's not in the per-task tss, it's only stored at the very top
of the kernel
On Thursday 27 January 2005 18:04, Len Brown wrote:
Thanks for the patch Adrian.
I agree that this is the right direction to go -- enforcing APIs with
the use of static reduces the possibility of programming errors --
particularly with many cooks in the kitchen. Indeed, just on Monday we
Andrea Arcangeli [EMAIL PROTECTED] wrote:
And they had not necessairly hardware access. They might have hardware
access.
On x86 we could perhaps test for non-nullness of tsk-thread-io_bitmap_ptr?
I thought I could wait the other patches
to be merged to avoid confusion before making more
This series of patches is to remove the pcxx driver. It is obsoleted by the
epca
driver.
These patches go together.
Diffstat:
MAINTAINERS |7
drivers/char/Kconfig | 17
drivers/char/Makefile|1
drivers/char/digi_bios.h | 177 ---
drivers/char/digi_fep.h | 517
On Fri, 28 Jan 2005, Jasper Spaans wrote:
Is this supposed to happen?
No. What is your kernel version?
- James
--
James Morris
[EMAIL PROTECTED]
-
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 Fri, 28 Jan 2005 00:17:01 +
Russell King [EMAIL PROTECTED] wrote:
Yes. Someone suggested this evening that there may have been a recent
change to do with some IPv6 refcounting which may have caused this
problem. Is that something you can confirm?
Yep, it would be this change below.
Hi,
On Thu, 27 Jan 2005, Andries Brouwer wrote:
In short - raw mode in 2.6 is badly broken.
I think not just that. The whole keyboard input layer needs some serious
review. Just the complete lack of any locking is frightening, I'd really
like to know how the input layer could become the
This patch removes references to the pcxx driver in MAINTAINERS.
Signed-off-by: James Nelson [EMAIL PROTECTED]
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/MAINTAINERS
linux-2.6.11-rc2-mm1/MAINTAINERS
--- linux-2.6.11-rc2-mm1-original/MAINTAINERS 2005-01-24 17:16:10.0
-0500
On Fri, Jan 28, 2005 at 12:14:30AM +, Russell King wrote:
The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
Hmmm, I recall e100 working fine on a Radisys ENP-2611, which has a
IXP2400 (xscale) in big-endian mode, running 2.6. This particular
board had its root fs
A long time ago, Linus wrote:
An atomic op is pretty much as expensive as a spinlock/unlock pair on x86.
Not _quite_, but it's pretty close.
Are both read and modify atomic ops relatively expensive on some CPUs,
or is it just modify atomic ops?
(Ignoring for this question the possibility
On Thu, Jan 27, 2005 at 07:38:43PM -0500, James Morris wrote:
Is this supposed to happen?
No. What is your kernel version?
Current bitkeeper + latest swsusp2 patches and hostap driver, however, those
two don't come near touching the crypto stuff[1] so they're not really on my
suspect
On Fri, 28 Jan 2005 00:14:30 +
Russell King [EMAIL PROTECTED] wrote:
The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
There's a message from me back on 30th June 2004 at about 10:30 BST on
this very list which generated almost no interest from anyone...
I see.
Anton Altaparmakov [EMAIL PROTECTED] wrote:
What would you propose can I do to perform the required zeroing in a
deadlock safe manner whilst also ensuring that it cannot happen that a
concurrent -readpage() will cause me to miss a page and thus end up
with non-initialized/random data on disk
On Thu, 27 Jan 2005, Paul Jackson wrote:
A long time ago, Linus wrote:
An atomic op is pretty much as expensive as a spinlock/unlock pair on x86.
Not _quite_, but it's pretty close.
Are both read and modify atomic ops relatively expensive on some CPUs,
or is it just modify atomic
Roland Dreier wrote:
Julien Not very important but ((get_random_int() % 4096) 4)
Julien could be optimized into get_random_int() 0xFFF0.
HPA .. and gcc knows that.
HPA8: 25 ff 0f 00 00 and$0xfff,%eax
HPAd: 83 c4 0cadd$0xc,%esp
On Thu, 2005-01-27 at 14:08 +, David Howells wrote:
Signed-Off-By: David Howells [EMAIL PROTECTED]
Excellent. Thanks David!
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
David S. Miller wrote:
I've forwarded this to netfilter-devel for inspection.
Thanks for collecting all the data points so well.
Here is the fix for everyone. Please report back if it doesn't
solve the problem. Thanks.
= net/ipv4/netfilter/ip_nat_proto_tcp.c 1.10 vs edited =
---
On Fri, Jan 28, 2005 at 12:17:01AM +, Russell King wrote:
On Thu, Jan 27, 2005 at 12:33:26PM -0800, David S. Miller wrote:
So they won't be listed in /proc/net/rt_cache (since they've been
removed from the lookup table) but they will be accounted for in
/proc/net/stat/rt_cache until the
Hi,
I have posted a couple of times in the past to no avail... I have an
Intel 31244 SATA controller that is supposed to work with the sata_vsc
driver module... It does in fact, almost
You can insert the module in a running kernel and after barking as
follows (once for each disk
On Fri, 28 Jan 2005, Jasper Spaans wrote:
On Thu, Jan 27, 2005 at 07:38:43PM -0500, James Morris wrote:
Is this supposed to happen?
No. What is your kernel version?
Current bitkeeper + latest swsusp2 patches and hostap driver, however, those
two don't come near touching the crypto
Hi.
You normally test cryptoapi functionality while booting?
Anyway, I can confirm that if suspend2 touches anything remotely related
to this, it's unintentional and I'll fix it :
Nigel
On Fri, 2005-01-28 at 10:30, Jasper Spaans wrote:
Hi List,
When booting I see this in dmesg:
testing
David Sims wrote:
Hi,
I have posted a couple of times in the past to no avail... I have an
Intel 31244 SATA controller that is supposed to work with the sata_vsc
driver module... It does in fact, almost
You can insert the module in a running kernel and after barking as
follows (once for
On Thu, 2005-01-27 at 16:48, David S. Miller wrote:
On Fri, 28 Jan 2005 00:14:30 +
Russell King [EMAIL PROTECTED] wrote:
The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
There's a message from me back on 30th June 2004 at about 10:30 BST on
this very list which
Noticed this oops today when setting up a box with a i865G chipset:
I'm using Xorg 6.8.0.
I also experience virtual terminal corruption when I switch to any of
them after X starts up.
Thanks.
-- James Lamanna
drm:i830_dma_initialize] *ERROR* can not find dma buffer map!
[drm:i830_irq_emit]
True - thanks - including the part about the cost of locking bugs.
My question was poorly phrased - the code speaks the answer to the
real question I had:
$ grep define.atomic_ include/asm-ia64/atomic.h | head -2
#define atomic_read(v) ((v)-counter)
#define atomic_set(v,i)
On Thu, Jan 27, 2005 at 07:00:32PM -0500, Jeff Garzik wrote:
The attached changelog describes what I just pushed out to BitKeeper
(and what should be appearing in the next -mm release from Andrew).
Note to BK users: please re-clone netdev-2.6, don't just 'bk pull'.
It's much more efficient
On Fri, 28 Jan 2005, Nigel Cunningham wrote:
You normally test cryptoapi functionality while booting?
This happens if you link tcrypt statically into the kernel.
- James
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
Andy Isaacson wrote:
On Thu, Jan 27, 2005 at 07:00:32PM -0500, Jeff Garzik wrote:
The attached changelog describes what I just pushed out to BitKeeper
(and what should be appearing in the next -mm release from Andrew).
Note to BK users: please re-clone netdev-2.6, don't just 'bk pull'.
It's
I didn't look at the trace. My only problem is in saving new files. I
can copy an old one, rename it and start, empty it and save fine. I just
can't save new ones.
Anyway, I hope this gets fixed. I am running pure rawhide Fedora Core,
just so you know... latest of everything.
Trever
On Thu,
On Thu, Jan 27, 2005 at 07:43:34PM +0100, Pavel Machek wrote:
Hi!
It happened for 3rd in a week now...
When problem happens, processes start to segfault, usually right
during startup. Programs that were loaded prior to problem usualy
works, and can be restarted. I also seen sendmail exec
601 - 700 of 729 matches
Mail list logo
