probe at 0x220: 00 40
f6 24 34 08
Jan 30 21:26:37 cr753963-a kernel: eth0: NE2000 found at 0x220, using IRQ
5.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
size 8
speed 917 kHz
Oct 24 23:15:31 cr753963-a kernel: input0: Analog 2-axis 4-button joystick
at gameport0.0 [TSC timer, 463 MHz clock, 1193 ns res]
and I can't get any further :[
Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
joydev
Ok, I can get it to work with modules, but it will not work if it's
directly compiled into the kernel, is this a known bug?
Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://w
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/
Test.
-
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://vger.kernel.org/lkml/
, npollfds, 1) until the timeout
really did expire.
-
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/
chunk, algorithm 2 [6/5] [_U]
bitmap: 149/164 pages [596KB], 1024KB chunk
H'm... this means that my alarm scripts aren't working. Well, that's
good to know. The drive is being re-integrated now.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
[8025041e] system_call+0x7e/0x83
Code: 4c 8b ae 98 00 00 00 4c 8b 70 08 e8 63 fe ff ff 8b 43 28 4c
RIP [8031504a] cfq_dispatch_insert+0x18/0x68
RSP 8100789b5af8
CR2: 0098
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
.)
-
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/
it internally (to do async
read-ahead or whatever) from a threadlet function.
-
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/
; these are the cases where
even a user-space longjmp-based thread library would context
switch.
- Context switches between threads in an application. The Linux
kernel already optimizes out the MMU context switch in this case,
and the scheduler already knows that such context
to disk. This caused annoying hiccups before the MS_ASYNC
calls were added.
I agree that msync(MS_ASYNC) has no semantics if time is ignored.
But it's a useful way to tell the OS that the page is not going
to be dirtied again.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Here's some more data.
6x ST3400832AS (Seagate 7200.8) 400 GB drives.
3x SiI3232 PCIe SATA controllers
2.2 GHz Athlon 64, 1024k cache (3700+), 2 GB RAM
Linux 2.6.20.4, 64-bit kernel
Tested able to sustain reads at 60 MB/sec/drive simultaneously.
RAID-10 is across 6 drives, first part of drive
From [EMAIL PROTECTED] Tue Mar 27 16:25:58 2007
Date: Tue, 27 Mar 2007 12:25:52 -0400 (EDT)
From: Justin Piszcz [EMAIL PROTECTED]
X-X-Sender: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED], linux-ide@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re
remember doing anything like that. What micro jumper?
It's been a while, but I just double-checked the drive manual and
it doesn't mention any jumpers.
-
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
Minor point: the chip part numbers are actually IT887x, not ITE887x.
I STFW for a data sheet, but didn't have immediate luck. Does anyone know
where to find
documentation?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
* MS_ASYNC does not start I/O (it used to, up to 2.5.67).
Yes, I noticed. See
http://www.ussg.iu.edu/hypermail/linux/kernel/0602.1/0450.html
for a bug report on the subject February 2006.
That's why this application is still running on 2.4.
As I mentioned at the time, the SUS says:
(http
(2) too often.
This is why we've
been extending these things with linux-specific goodies which permit
applications to actually tell the kernel what they want to be done in a
more finely-grained fashion.
Well, I still think the current Linux behavior is a bug, but there's a
usable (and run-time
Linux _will_ write all modified data to permanent storage locations.
Since 2.6.17 it will do this regardless of msync(). Before 2.6.17 you
do need msync() to enable data to be written back.
But it will not start I/O immediately, which is not a requirement in
the standard, or at least it's
, that seems (to me, at least)
to obviously be the intended purpose of msync(MS_ASYNC). I wonder if
there's any historical documentation describing the original intent
behind creating the call.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
it's a big deal, as 32 (tags) x 128K (largest LBA28 write
size) is 4M, only half of a typical drive's cache RAM. But it's
possible that there's some difference.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
:57:58: disk 3, o:1, dev:sdd4
14:57:58: disk 5, o:1, dev:sdf4
-
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/
.
Here's the kernel config:
$ grep ^CONFIG /usr/src/linux/.config
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
, but that was with X running so I couldn't see a
console oops. But given that I installed 2.6.24-rc6 about 24 hours ago,
that's a disturbing pattern.
It is probably this one:
http://marc.info/?t=11978279403r=1w=2
Thanks! I got the patch from
http://marc.info/?l=linux-netdevm=119756785219214
(Which
Thanks! I got the patch from
http://marc.info/?l=linux-netdevm=119756785219214
(Which didn't make it into -rc7; please fix!)
and am recompiling now.
Jeff is busy so he's asked me to pick up the more important
driver bug fixes that get posted.
I'll push this around, thanks.
Much obliged
, but I'd rather avoid having the
prisoner link /jail/lib/libfoo.so (write returns EROFS) to /jail/usr/log
where it's potentially writeable.
--
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
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/
, please share.)
--
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/
GCC about a non-returning statement.
-
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/
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/
the ambiguity is still useful. I was just saying
that it can be pretty much anything withouyt confusing the casual
reader.
We're in violent agreement, I just didn't say it very well the first
time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
.)
-
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/
Uniprocessor Althlon 64, 64-bit kernel, 2G ECC RAM,
2.6.23-rc8 + linuxpps (5.0.0) + ip1000a driver.
(patch from http://marc.info/?l=linux-netdevm=118980588419882)
After a few hours of operation, ntp loses the ability to send packets.
sendto() returns -EAGAIN to everything, including the 24-byte
/0x74
filp: 442 get_empty_filp+0x44/0xcd
ip_dst_cache: 421 dst_alloc+0x29/0x76
I'm backing out the ip1000a driver and seeing what happens.
-
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
? rc8-mm1? rc8-mm2??
As I wrote originally, I got it from
http://marc.info/?l=linux-netdevm=118980588419882
which was a reuqest for mainline submission.
If there are other patches floating around, I'm happy to try them.
Now that I know what to look for, it's easy to spot the leak before OOM.
I
Today, 26 april, is the *21*'th anniversary of nuclear
explosion at Chernobyl's station (ex USSR).
And linux 2.6.*21* is released. Nice!
-
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
; they's use it! in good conscience.
-
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/
that the
schedule works.
But if the seed samples are correlated, it gets a lot trickier.
-
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
.
-
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/
matter, and can be changed without affecting the subpool structure that
is Fortuna's real novel contribution. That was just what Niels and
Bruce came up with to make the whole thing concrete.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
*, but your
code is going to get some extremely critical examination.
-
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/
changes as you like. (Search debian-legal for desert island
test.)
-
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/
you cited, and has been fixed.
There's probably more discussion of the subject in linux-kernel around
the time that change went in.
Whether the goal is *achieved* is a different issue. random.c tries
pretty hard, but makes some concessions to practicality, relying on
computational security
that understanding the concept is pretty
fundamental to any meaningful discussion of information-theoretic
security.
I stand by my comments above.
Cool! So there's a problem to be solved!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
a little bit weaker than the above, and I have to figure out of
the proof extends.
-
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
.
/dev/random will output once it has as many bits of entropy as you're
asking for. If you do a 20-byte read, it'll output once it has 160
bits. If you do a 1-byte read, it'll output once it has 8 bits.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
it would take to do that kind of analysis.
And given the variety of platforms that Linux runs on, it gets insane.
Yes, it can be proved based on fluid flow computations that hard drive
rotation rates are chaotic and thus disk access timing is a usable
entropy source, but then someone installs a solid
[A discussion on the git list about how to provide a hardlinked file
that *cannot* me modified by an editor, but must be replaced by
a new copy.]
[EMAIL PROTECTED] wrote all of:
perhaps having a new 'immutable hardlink' feature in the Linux VFS
would help? I.e. a hardlink that can only
in ip.h:ip_select_ident()) a workaround
for a Microsoft VJ compression bug. The fix was added in 2.4.4 (via
DaveM's zerocopy-beta-3 patch); before that, Linux 2.4 sent a constant
zero as the IP ID of DF packets. See discussion at
http://www.postel.org/pipermail/end2end-interest/2001-May/thread.html
could you please also react to this feedback:
http://marc.theaimsgroup.com/?l=linux-kernelm=110698371131630w=2
to quote a couple of key points from that very detailed security
analysis:
I'm not sure how the OpenBSD code is better in any way. (Notice that
it uses the same
I really got bored of this thread.Can you all question your self on thing?
If someone starts reading right now the sources of the linux kernel will be
able to understand every aspect and part of the code???
Do you understand every aspect?
Is it still opensource or starts to be a closedsource
[EMAIL PROTECTED] writes:
(The homebrew 15-bit block cipher in this code does show how much the
world needs a small block cipher for some of these applications.)
Doesn't TEA fill this niche? It's certainly used for this in the Linux
kernel, e.g. in reiserfs (although I have my doubts
linux It's easy to make a smaller hash by just thowing bits away,
linux but a block cipher is a permutation, and has to be
linux invertible.
linux For example, if I take a k-bit counter and encrypt it with
linux a k-bit block cipher, the output is guaranteed not to
linux
: 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/
separate.
Works for me (test code below).
The machine we plan to buy is a HP Proliant Xeon machine and I want to run a
32 bit linux kernel on it (the xeon we want doesn't have the 64-bit stuff
yet)
If you're working with 4GB data sets, I would recommend you think VERY hard
before deciding
SMP thread-creation case would be to have a NULL value for
the thread-to-CPU pointer and initialize the thread's CPU pointer to that,
but that then complicates the UP case.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
of it, but then I have to worry about the system page
size (I'm not sure if the kernel will DTRT and not page in half of an
8K page if I writev() two 4K vectors to it), and it prevents me from
using pwrite().
I haven't tracked down the splice() idea that sct mentioned in
http://www.ussg.iu.edu/hypermail/linux
, so if I am inferring incorrectly,
I apologize. (And you can ignore the rest of this missive.)
However, I did look carefully at an earlier patch that claimed to be a
Linux port of some OpenBSD networking randomization code, ostensibly to
make packet-guessing attacks more difficult.
http
It adds support for advanced networking-related randomization, in
concrete it adds support for TCP ISNs randomization
Er... did you read the existing Linux TCP ISN generation code?
Which is quite thoroughly randomized already?
I'm not sure how the OpenBSD code is better in any way. (Notice
).
The Linux kernel is clearly published, and while the second part is
a little fuzzy (and I'm not eager enough to chase it back to original
case law), I think the functional nature of software places it in the
factual category.
3. The Amount and Substantiality of the Portion Taken
Your publisher
possible.)
-
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/
suggestions? Does userland need to fall
back on read()/write() for a byte?
-
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
the total overflow 32 bits.
-
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/
or 89 21 if *not* inverted.)
-
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/
-length messages, it matters.
-
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/
try them both and see which works.
However, if your hardware uses the opposite bit ordering within bytes,
DO NOT ATTEMPT to fix lib/crc-ccitt.c. It will break all of the
existing users of the code.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
I could find on the Web is like the linux kernel ccitt_crc.
Go figure.
Funny, I can find it all over the place:
http://www.nongnu.org/avr-libc/user-manual/group__avr__crc.html
http://www.aerospacesoftware.com/checks.htm
http://www.bsdg.org/SWAG/CRC/0011.PAS.html
http://www.ethereal.com/lists
, for the copy_from_user source, prefetchnta is
probably indicated. If user space hasn't caused it to be cached already
(admittedly, the common case), we *know* the kernel isn't going to look
at that data again.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
to cold-cache code.
-
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/
+
include/asm-xtensa/mmu_context.h|6 ++
kernel/sched.c |9 -
25 files changed, 151 insertions(+), 1 deletion(-)
I think this pretty clearly points out the need for some arch-generic
infrastructure in Linux. An awful lot of arch hooks are for one
or two
. Don't emulate it, or you will be lynched by a mob of angry
kernel developers with torches and pitchforks.
-
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
;
} while ((x += CHAR_BIT * sizeof *b) size);
return size;
}
Do we actually store bitmaps on 64-bit machines with 32 significant bits
per ulong?
-
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
space and the kernel address space must both fit into the 4G
linear virtual address space provided by the x86 architecture.
Normally, Linux divides this into 3G for user virtual memory
and 1G for kernel memory, which holds up to 896M of RAM plus all
memory-mapped
is a fair price
to pay for avoiding another layer of abstraction (a.k.a. obfuscation).
And it lets you optimize them better.
I apologize for not having counted them before.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
better.
I apologize for not having counted them before.
I also disagree that the architectures don't matter. ARM and PPC are
pretty important, and I believe Linux on MIPS is growing too.
Er... I definitely don't see where I said, and I don't even see where
I implied - or even hinted
. (You'll also need to add
a #include stdbool.h, unless you expand the bool, false and
true macros to their values _Bool, 0 and 1 by hand.)
--- linux-2.6/include/linux/fs.h.super 2006-12-12 08:53:34.0 -0500
+++ linux-2.6/include/linux/fs.h2006-12-12 08:54:14.0 -0500
@@ -1879,7
recognize this or similar situations?
Cheers // Matias
--
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/
have an atomic flag that would avoid blocking to preallocate
the additional kernel thread! Then you'd really be guaranteed no
long delays, ever.
-
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
at a time just before each of the 20 round groups.
-
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/
%ecx
pushl %eax
jne 1b
addl$4*86,%esp
ret
.size sha_stackwipe, .-sha_stackwipe
-
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
support. Enabling this also disables the
(expert use only) CONFIG_VMSPLIT_[23]G_OPT options.
Does that seem reasonably user-oriented?
-
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
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/
return 0;
}
-
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/
(), a lovely
example of calling schedule_timeout() without set_current_state() first.)
-
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
] init_transmeta+0x1d5/0x230 SS:ESP 0068:c030fed0
Kernel panic - not syncing: Attempted to kill the idle task!
-
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
VGA compatible controller [0300]: ATI Technologies Inc Rage Mobility
P/M [1002:4c52] (rev 64)
$ grep ^CONFIG /usr/src/linux/.config
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
suspend
(and resume) for me.
-
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/
Responding to various proposed fixes:
Index: linux/arch/i386/kernel/cpu/mtrr/main.c
===
--- linux.orig/arch/i386/kernel/cpu/mtrr/main.c
+++ linux/arch/i386/kernel/cpu/mtrr/main.c
@@ -734,8 +734,11 @@ void mtrr_ap_init(void
ideas, but they're not obviously
bad ones, to me. Is it worth looking for synergy between various
indirect system call ideas?
-
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
Hi:
I am running Redhat Linux Enterprise version 4 update 4 on a dual-core
4G memory machine. There are many references on the web talking about
increasing default user address space to 3.5 G however lacking specific
instructions. My questions:
1. What is the specific steps to be done
Sleeping in an ISR is not fundamentally impossible - I could design
a multitasker that permitted it - but has significant problems, and
most multitaskers, including Linux, forbid it.
The first problem is the scheduler. Sleeping is actually a call
into the scheduler to choose another process
I'm not used to seeing order-0 allocation failures on lightly loaded 2 GB
(amd64, so it's all low memory) machines.
Can anyone tell me what happened? It happened just as I was transferring
a large file to the machine for later crunching (the sgrep program is
a local number-crunching application
---
Total builds: 64 Total build errors: 3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
should be made by Sun Jul 28 20:54:53 UTC 2013.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.88-rc1.gz
and the diffstat can be found below.
We have additional build failures
should be made by Sun Jul 28 20:48:22 UTC 2013.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.55-rc1.gz
and the diffstat can be found below.
Cross platform build looks good
should be made by Sun Jul 28 20:45:08 UTC 2013.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.4-rc1.gz
and the diffstat can be found below.
Cross build is ok: Total builds: 64
with qemu. This is part of
my sanity tests of upcoming -stable kernel versions.
It will have to wait until tonight, though - my home internet
connection is down and I can not connect to the system right
now.
Guenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
.
Guenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoting Wolfram Sang w...@the-dreams.de:
Signed-off-by: Wolfram Sang w...@the-dreams.de
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
Documentation/i2c/instantiating-devices | 34
+++--
1 file changed, 32 insertions(+), 2 deletions
1 - 100 of 10001 matches
Mail list logo
