: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.
Total builds: 54 Total
: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:
Total builds: 58 Total
: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 Total build errors: 3
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/
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/
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/
A at 0x200 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 bo
C timer, 463 MHz clock, 1193 ns res]
> >
> > and I can't get any further :[
> >
> > Dave
>
> insmod 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 f
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/
hat's
an entropy measurement problem!
Until this cloud is dissipated by further analysis, it's not possible to
say "this is shiny and new and better; 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/
.
If the attacker's uncertainty about the state of some of the subpools
increases to the catastrophic reseeding level, then the Fortuna design
goal is achieved.
If the seed samples are independent, then it's easy to see that the
schedule works.
But if the seed samples are correlated, it
n has to hold back entropy for some
time.
And I think that, even in the absence of special-purpose RNG hardware,
synchronization jitter on modern GHz+ CPUs is a fruitful source of
entropy.
-
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/
s is long enough, and you have the same
0.1 second maximum reseed rate, then 21 pools will have pool 20 added
every 29:07:37.6.
As I keep saying, the small size of the Fortuna pools is a separate
matter, and can be changed without affecting the subpool structure that
is Fortuna's real novel con
s the technical goals?
I don't think anyone wants to draw and quarter *you*, 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 major
ng is discussing it with someone who doesn't
even seem to *see* the issues.
> Not to sound like a "I'm taking my ball and going home" - just explaining
> that I like the Fortuna design, I think it's elegant, I want it for my
> systems. GPL require
utput from subsequent /dev/urandom output. That's
discussed in section 5.3 of the paper 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 tr
ou're intimately familiar with the concept,
and any discussion can go straight on to more detailed issues.
I just hope you'll grant me that understanding the concept is pretty
fundamental to any meaningful discussion of information-theoretic
security.
> I stand by my comments above.
elp an attacker).
Remiander modulo a uniformly chosen random irreducible polynomial is a
well-known ("division hash") family of universal hash functions, but
it's a little bit weaker than the above, and I have to figure out of
the proof extends.
-
To unsubscribe from this list: sen
rophic reseeder and output function don't waste entropy).
>
> It's a lot of "ifs" for my taste.
/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 to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
* &) in both unary and binary forms, so it's
not always unambiguous.
In such cases, I'll usually move the brace onto its own line to make the
end of the condition clearer:
if (foobar(.) +
barbar * foobar(bar + foo * oof))
{
at offsets 0, 4 GB, 8 GB, and 12 GB
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 d
a, or f5 a3 when inverted and converted to bytes.
CRC-CCITT of "123456789" is 0x6f91, or 63 90.
(When preset to zero, the values are 0x538d and 0x2189, respectively.
That would be 8d 53 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/
on a modern machine, it's faster to try all 32768 possible polynomials
than to write and debug the GCD code.)
After that, you can figure out the preset and final inversion, if any.
For fixed-length messages, you can merge them into a single 16-bit
constant that you can include at the beginni
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 to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
abbing everything on the Web that
> could help decipher the CCITT CRC and they all show this
> same kind of code and same kind of organization. Nothing
> 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.non
r 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
ivides up the seed
material round-robin among the various subpools. The current /dev/random
doesn't do anything like that. (Of course, non-independence affects
us by limiting us to the conditional entropy of any given piece of
seed material.)
> I also don't know whether this is a
[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
nter to current CPU.
The UP case just omits the per-thread CPU pointer. (Well, stores
it in zero bits.)
An alternative 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
instruction decode limits
that apply 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/
de/asm-v850/mmu_context.h |6 ++
> include/asm-x86_64/mmu_context.h|5 +
> 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
short-sighted design of the NFS
protocol. 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
if (v)
return __ffs(v) + x;
} 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
ng NUM_FRACTION_BITS to 16 or so would give enough room for
reasonable-sized weights and not have 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/
a while ago to get tagged VLANs working on it,
which was a notable failure. Still, this oops is in core network code.
As you might guess, it makes people somewhat grumpy when the main
firewall/router takes a dive, but I can experiment after hours.
Here's the kernel config:
$ grep ^CONFIG /u
a black-screen lockup with
>> keyboard LEDs blinking, 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=11978279
>> Thanks! I got the patch from
>> http://marc.info/?l=linux-netdev&m=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 g
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/
.6.21.
Anybody who 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/
t to abuse these
free services by doing it too often. Also, the latter two actually
return whole HTML pages with the numbers included in ASCII. If anyone
knows how to just download raw binary, 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/
be enough, 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
> could you please also react to this feedback:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=110698371131630&w=2
>
> to quote a couple of key points from that very detailed security
> analysis:
>
> " I'm not sure how the OpenBSD code is better
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 &qu
> [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 r
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
> 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 wa
may be
able to get away with a smaller user virtual address space, which could
allow you to work with more RAM without needing to slow the kernel with
highmem code.
You'll find another discussion of the issues at
http://kerneltrap.org/node/2450
http://lwn.net/Articles/75174/
Finally, could I s
o it takes more quoting
to include a threshold amount of copyrightable "expression").
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 softw
sequence.
This is in fact (see the comment 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.post
citly, 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.
me other source of information? I'd be
much obliged.
-
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/
there are more intricate hierarchies of mutual accessibility?
(A similar case is a copy from a process' address space. Normally,
simgle-copy pipes require a kmap in one of the processes. But if
the copying code can notice that source and dest both have the same
mm structure, a direct copy becomes 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/
ltiple copies 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:/
to think. If there's a -EIO problem on one of the file
descriptors, how does the caller know which one? That's an argument for
separate pull and push (although the splice() library routine still
has the problem). Any suggestions? Does userland need to fall
back on read()/write() for
ion returning, because
there's no way to tell 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/
e to call libraries that use 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/majordo
to a few categories:
- Mandatory switches because the entire application is blocked.
I don't see how this can be avoided; these are the cases where
even a user-space longjmp-based thread library would context
switch.
- Context switches between threads in an application.
can do for real-time tasks is, in addition to the
non-blocking flag (return EAGAIN from asys_submit rather than blocking),
you could 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
There are important efficiency reasons why the user address
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
ot
worth it. If there were five, it would probably be a savings, but 3x
code duplication of some small, well-defined primitives 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
savings, but 3x
> code duplication of some small, well-defined primitives 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.
> I also disagree
the following. (You'll also need to add
a "#include ", 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.000
An intermediate one is to keep a 20-word buffer, and compute 20 words
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/
[]
sha_stackwipe:
xorl%eax,%eax
movl$86,%ecx
# Damn, I had hoped that loop; pushl %eax would work..
1:
decl%ecx
pushl %eax
jne 1b
addl$4*86,%esp
ret
.size sha_stackwipe, .-sha_stackwipe
-
To unsubscribe from this
or
without PAE 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]
cribe 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/
for (i = 0; i < TEST_SIZE; i += 64)
sha_transform5(out, buf+i);
gettimeofday(&stop, 0);
printf(" Five: %08x %08x %08x %08x %08x -- %lu us\n",
out[0], out[1], out[2], out[3], out[4],
100*(stop.tv_sec-start.tv_sec)+stop.tv_usec-start.tv_usec);
sha_stackwipe();
#endif
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/
4l.c:cpia2_exit(), 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.htm
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
f ff
bd 04 00 86 80 89 e9 0f 32 89 c6 93 c8 ff 89 d7 89 c2 <0f> 30 31 c9 b8 01 00 00
00 0f a2 8b 44 24 28 89 e9 89 50 0c b8
EIP: [] 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 &
8026]
00:14.0 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_S
everted successfully does APM 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 mt
27;m not at all sure that these are good 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
imeout had expired using gettimeofday()
and would keep re-invoking poll(pollfds, 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/
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
> 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
5, 64k 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 linu
098
-
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/
ted sectors jumped from 26 to 39.
Something is up with that drive.)
-
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/
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 maj
here's an msync(MS_SYNC) call to be sure the data
is synced 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 aga
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
>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.or
e back as well right?
Um... no, I don't 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 bo
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 [
> * 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 say
orage. If an application calls it too often, that's
the application's fault just as if it called sync(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
> 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 sta
operations.
Reading between the lines of the standard, 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
to read nearby requested sectors are worth keeping.
I'm not sure 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
58: RAID5 conf printout:
14:57:58: --- rd:6 wd:5
14:57:58: disk 0, o:1, dev:sda4
14:57:58: disk 1, o:1, dev:sdb4
14:57:58: disk 2, o:1, dev:sdc4
14: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" i
Quoting Nicolin Chen :
The new hdev is a child device related to the original parent
hwmon driver and its device. However, it doesn't support the
power features, typically being defined in the parent driver.
So this patch inherits three necessary power properties from
the parent dev to hdev:
led)
Signed-off-by: Dr. David Alan Gilbert
---
include/linux/ftrace.h | 1 -
kernel/trace/ftrace.c | 8
2 files changed, 9 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 54d53f345d149..b01cca36147ff 100644
--- a/include/linux/ftrace.h
+++ b/include
From: "Dr. David Alan Gilbert"
It doesn't look like this was ever used.
Build tested only.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/virt/acrn/irqfd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/virt/acrn/irqfd.c b/drivers/virt/acrn/irqfd.c
index d4ad211dce7a3..346cf0
From: "Dr. David Alan Gilbert"
Commit 8788ca164eb4b ("ftrace: Remove the legacy _ftrace_direct API")
stopped setting the 'ftrace_direct_func_count' variable, but left
it around. Clean it up.
Signed-off-by: Dr. David Alan Gilbert
---
include/linux/ftrace.h | 2 -
er reason to keep it short is just that it's going to get typed a LOT.
Anyway, just MHO.
-
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/
oint), but rather saying that no
prefix is necessary for human understanding.
Something to avoid 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 f
t;.
(Or you can split it into KPRINT_BEGIN() and KPRINT_END() macros,
if that works out to be cleaner.)
-
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-netdev&m=118980588419882)
After a few hours of operation, ntp loses the ability to send packets.
sendto() returns -EAGAIN to everything, including the 24-
1 - 100 of 2239 matches
Mail list logo
