You are not logged in [login] | [register]
RSS MAD is both an RSS feed archive and online feed reader.
You can browse our categories, search for a feed, or if you already have a URL, use our online feed reader.
Simply start browsing the site, and if you find some feeds you like, register to view them on your own personalized page!
you are here: home » computers & internet » software
Searching 189654 articles in 8938 feeds.
Do you like RSS MAD? Why not spread the news and tell a friend about it - it's as easy as filling out this form!
added: Sun, 16th October 2005 | 2067 views | 0x in favourites
feed url: http://lkml.org/rss.php
lkml [Viewed: 128]
Oliver Neukum writes: (Summary) Not a problem, if the
firmware issue is fixed as it needs to be.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Tino Keitel writes: (Summary) All disks spun down at suspend, and spun up again at
resume.
Regards,
Tino
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
"Justin Mattock" writes: Hello; I'm noticing this with the latest git
dmesg:[ 0.943919] ACPI: EC: GPE = 0x17, I/O: command/status =
0x66, data = 0x62
dmesg:[ 11.486870] ACPI: EC: GPE storm detected, disabling EC GPE
dmesg.0:[ 0.943919] ACPI: EC: GPE = 0x17, I/O: command/status =
0x66, data = 0x62
I will see this on various boot's.
regards;
Harvey Harrison writes: (Summary) 55 +++++++++++++++++++++---------------------------- 1 files changed, 24 insertions(+), 31 deletions(-) diff --git a/crypto/michael_mic.c b/crypto/michael_mic.c index 9e917b8..792dbf9 100644 --- a/crypto/michael_mic.c +++ b/crypto/michael_mic.c @@ -31,19 +31,18 @@ static inline u32 xswap(u32 val) return ((val & } - -#define michael_block(l, r) \ -do { \ - r ^= rol32(l, 17); \ - r ^= xswap(l); \ - r ^= rol32(l, 3); \ - r ^= ror32(l, 2); \ -} while (0) - +static void michael_block(struct michael_mic_ctx *ctx, u32 val) +{ + ctx->l ^= val; while (len >= 4) { - mctx->l ^= le32_to_cpup(src++); switch (mctx->pending_len) { - case 0: - mctx->l ^= 0x5a; - case 1: - mctx->l ^= data[0] | - case 2: - mctx->l ^= data[0] |
"Kingsley Foreman" writes: (Summary) ok after some playing a bit if i use
tc qdisc change dev bond0 parent 1: pfifo limit 30
the dropped packets go away, im not sure if that is considered normal or
not, however any number under 30 gives me issues.
Kingsley
----- Original Message -----
From: "Jarek Poplawski" <jarkao2@gmail.com>
Kevin Hao writes: (Summary) + if (irq) { + if (request_irq(irq, hpet_interrupt, irq_flags, + devp->hd_name, (void *)devp)) { + printk(KERN_ERR "hpet: IRQ %d is not free\n", irq); + } + + cap =3D (readq(&timer->hpet_config) & + irq =3D find_next_bit(&cap, HPET_MAX_IRQ, 1 + irq)) { + if (request_irq(irq, hpet_interrupt, irq_flags, + devp->hd_name, (void *)devp)) { + printk(KERN_WARNING "hpet: IRQ %d is not free\n", irq); + } + + if (irq >=3D HPET_MAX_IRQ) + irq =3D 0; - } - } - + irq =3D hpet_timer_get_irq(devp); diff --git a/include/linux/hpet.h b/include/linux/hpet.h index 2dc29ce..440ca72 100644 --- a/include/linux/hpet.h +++ b/include/linux/hpet.h @@ -37,6 +37,7 @@ struct hpet { #define hpet_compare _u1._hpet_compare =20 #define HPET_MAX_TIMERS (32) +#define HPET_MAX_IRQ (32) =20 /* * HPET general capabilities register @@ -64,7 +65,7 @@ struct hpet { */ =20 #define Tn_INT_ROUTE_CAP_MASK (0xffffffff00000000ULL) -#define Tn_INI_ROUTE_CAP_SHIFT (32UL) +#define Tn_INT_ROUTE_CAP_SHIFT (32
Jarek Poplawski writes: (Summary)
Thanks,
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Tino Keitel writes: (Summary) On Thu, May 15, 2008 at 19:32:36 -0700, Greg KH wrote:
[...]
Maybe this email came from a person who uses a distro kernel that
already included the appleir driver? This was done
in 2.6.23-rc2.
Regards,
Tino
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Rusty Russell writes: (Summary) i++) + if (iov[i].iov_len) + return false; The usual case is that the Guest doesn't want random numbers + * and so has no buffers although /dev/urandom is still readable, whereas + * console is the reverse. */ + if (head == dev->vq->vring.num) + return false; + + /* This is why we convert to iovecs: the readv() call uses them, and so + * it reads straight into the Guest's buffer. */ + while (!iov_empty(iov, in_num)) { + len = readv(dev->fd, iov, in_num); + } + + /* Tell the Guest about the new input. */ @@ -1683,6 +1769,7 @@ static struct option opts[] = { { "verbose", 0, NULL, 'v' }, { "tunnet", 1, NULL, 't' }, { "block", 1, NULL, 'b' }, + { "rng", 0, NULL, 'r' }, { "initrd", 1, NULL, 'i' }, { NULL }, };
Mariusz Kozlowski writes: (Summary)
I'll just start from scratch then.
Thanks,
Mariusz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Rusty Russell writes: (Summary) VIRTIO + ---help--- + This driver provides kernel-side support for the virtual Random Number + Generator hardware. + diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile --- a/drivers/char/hw_random/Makefile +++ b/drivers/char/hw_random/Makefile @@ -11,3 +11,4 @@ obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx-rng.o obj-$(CONFIG_HW_RANDOM_OMAP) += omap-rng.o obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o +obj-$(CONFIG_HW_RANDOM_VIRTIO) += virtio-rng.o diff --git a/drivers/char/hw_random/virtio-rng.c b/drivers/char/hw_random/virtio-rng.c new file mode 100644 --- /dev/null +++ b/drivers/char/hw_random/virtio-rng.c @@ -0,0 +1,143 @@ +/* + * Randomness driver for virtio + * Copyright (C) 2007, 2008 Rusty Russell IBM Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; +} + +static struct hwrng virtio_h
Eric Dumazet writes: (Summary) (1Kb per module)
Instead of having all refcounters in the same memory node - with TLB misses
because of vmalloc() - this new implementation permits to have better
NUMA properties, since each CPU will use storage on its preferred node,
thanks to percpu storage.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> 40 +++++++++++++++++++++++++++++----------
2 files changed, 46 insertions(+), 19 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 3e03b1a..dfd36ed 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -217,11 +217,6 @@ void *__symbol_get_gpl(const char *symbol);
-
enum module_state
{
MODULE_STATE_LIVE,
@@ -307,8 +302,11 @@ struct module
#ifdef CONFIG_MODULE_UNLOAD
/* Reference counts */
- struct module_ref ref[NR_CPUS]; */
static inline void __module_get(struct module *module)
{
if (module) {
BUG_ON(module_refcount(module) == 0);
}
}
@@ -396,7 +403,7 @@ static inline int try_module_get(struct modu
Andi Kleen writes: (Summary) Also there
are livetime issues when to wrap.
It's certainly possible, but likely complicated
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Paul Mundt writes: (Summary) Commit 95b570c9cef3b12356454c7112571b7e406b4b51 introduced a
TAINT_WARN that was implemented for all architectures using the
generic warn_on_slowpath(), which excluded any architecture that
set HAVE_ARCH_WARN_ON.
As all of the architectures that implement their own WARN_ON()
all go through the report_bug() path (specifically handling
BUG_TRAP_TYPE_WARN), taint the kernel there as well for consistency.
Greg KH writes: (Summary) On Thu, May 15, 2008 at 03:05:10PM -0700, Arthur Jones wrote:
Thanks again.
I've audited the whole tree and only found one other place with this
problem, the display driver class.
"Zhang, Yanmin" writes: (Summary)
On Thu, 2008-05-15 at 10:05 -0700, Christoph Lameter wrote:
reed=20
ench=20
ab sizes.
freeing.
on becomes 97% (the bad
the=20
le it=20
urred=20
l=20
I forgot that.
Mariusz Kozlowski writes: (Summary) What you should do is basically
# Set this up just once..
git remote add linux-next git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
and then after that, you keep on just doing
git fetch linux-next
git checkout linux-next/master
"
This is from today:
$ git fetch linux-next
remote: Counting objects: 3749, done.
remote: Compressing objects: 100% (748/748), done.
Indexing 2309 objects...
remote: Total 2309 (delta 1918), reused 1951 (delta 1560)
100% (2309/2309) done
Resolving 1918 deltas...
100% (1918/1918) done
496 objects were added to complete this thin pack.
* refs/remotes/linux-next/history: fast forward to branch 'history' of git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next
old..new: b26fb88..75f1411
* refs/remotes/linux-next/master: forcing update to non-fast forward branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/sfr/lin
Paul Mundt writes: (Summary) And it's at least been verified on avr32 and
sh.
Either Havaard or I can resubmit this with a proper changelog if that
will help move things along, obviously it's not a very pressing patch one
way or the other, but consistency is good, and we're all likely to forget
about this again otherwise.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH writes: (Summary) On Thu, May 15, 2008 at 03:05:10PM -0700, Arthur Jones wrote:
Great!
Thanks for testing this, I'll clean it up a bit more and send it to
Linus later this evening.
Eric Dumazet writes: (Summary) (!!=
!)
Well, I should have stated that this saving also takes place in the=20
module disk file.
(The "struct module" is included in it, in the=20
".gnu.linkonce.this_module" section)
Here on my distro, around 2000 modules are shiped.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
"Huang, Ying" writes: (Summary)
Jump from kernel A to kernel B
Jump to entry of purgatory (purgatory_entry)
purgatory save the return address (kexec_jump_back_entry_A)
Purgatory set kexec_jump_back_entry for kernel B to a code
segment in purgatory, say kexec_jump_back_entry_A_for_B
Purgatory jump to entry point of kernel B
Jump from kernel B to kernel A
Jump to purgatory (kexec_jump_back_entry_A_for_B)
Purgatory save the return address (kexec_jump_back_entry_B)
Purgatory return to kernel A (kexec_jump_back_entry_A)
Jump from kernel A to kernel B again
Jump to entry of purgatory (purgatory_entry)
Purgatory save the return address (kexec_jump_back_entry_A)
Purgatory jump to kexec_jump_back_entry_B
The disadvantage of this solution is that some information is saved in
purgatory (kexec_jump_back_entry_A, kexec_jump_back_entry_B).
"Cyrill Gorcunov" writes: (Summary) wrote:
[...]
And sorry about top-posting (gmail mobile client is really screwed up,
trying to force top-post all the time)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Stephen Rothwell writes: Hi Marius,
On Thu, 15 May 2008 23:31:21 +0300 Adrian Bunk <bunk@kernel.org> wrote:
This would indicate something wrong with your clone of linux-next. How
did you create the repository?
Any day's linux-next tree is a git tree like any other ...
[unhandled content-type:application/pgp-signature]
FUJITA Tomonori writes: (Summary) These people need per-device dma_ops and we can do stack
per-device dma_ops?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Balbir Singh writes: Mark Seger wrote:
I looked through the code and your argument seems to be correct. The behaviour
is inconsistent w.r.t. other statistics like utime and stime. We currently
accumulate tgid information in signal_struct, we need to do something similar
for io as well. If nobody gets to it by the time I finish my backlog, I'll try
and get to it.
FUJITA Tomonori writes: (Summary) It enables IOMMUs
to set up an appropriate dma_mapping_ops per device:
http://lkml.org/lkml/2008/5/14/519
But I wanted to make sure whether per-device dma_ops is useful for
everyone.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
(Eric W. Biederman) writes: (Summary) writes:
I'm not opposed.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
"Cyrill Gorcunov" writes: (Summary) wrote:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Vivek Goyal writes: (Summary) Re-entry point has not changed
Do nothing.
- Continue to resume kernel A
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton writes: (Summary) 2008-02-05 09:44:09
Parent: 149b36eae2ab6aa6056664f4bc461f3d3affc9c1 (serial: stop passing NULL to functions that expect data)
Child: 9d778a69370cc1b643b13648df971c83ff5654ef (serial: avoid waking up closed serial ports on resume)
Branches: many (89)
Follows: v2.6.24
Precedes: v2.6.25-rc1
serial: keep the DTR setting for serial console.
But I don't recall seeing any other reports of this and there's not
really anyone who is actively working on the serial drivers.
(Eric W. Biederman) writes: (Summary) writes:
I don't know what the case is for keeping two kernels in memory and switching
between them.
I suspect a small piece of trampoline code between the two kernels could
handle the case.
Mauro Carvalho Chehab writes: (Summary) Also, as it is common on several devices, the userspace handlers
are more tested.
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Mauro Carvalho Chehab writes: (Summary) wrote:
It seems a little dangerous to use just DIR_IN/DIR_OUT, since a future change
on a kernel header could cause namespace conflict.
I saw another discussion about this.
I like the idea of loading firmware asynchronously, provided that you block at
open() or at ioctl(), if the user requested to open before having the firmware
loaded.
This is probably obsolete. The current code, at vivi and em28xx already prevents such issues (at
least, it went fine at the tests we did).
Also, the timeout is obsolete
No. Why to release the firmware?
In this case, it should return -EBUSY.
Instead of incrementing the usage, printing the open message just to discover
that you don't have enough memory, I would move the users increment and the
dprintk to happen after the allocation of fh.
"Huang, Ying" writes: (Summary) And the stack state is different depend on where
come from, from relocate_new_kernel() or return.
Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton writes: (Summary) wrote:
comment seems wrong.
Is it really safe to walk this list locklessly?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton writes: (Summary) wrote:
We still have this silliness in acct_file_reopen():
spin_unlock(&acct_lock);
do_acct_process(acct, old_ns, old_acct);
filp_close(old_acct, NULL);
spin_lock(&acct_lock);
Was this lock-dropping safe before?
Is it safe now?
To work this out, we'd need to know what acct_lock protects.
Hiroshi Shimamoto writes: (Summary) 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c index f1525ad..c42a03a 100644 --- a/kernel/posix-cpu-timers.c +++ b/kernel/posix-cpu-timers.c @@ -1037,6 +1037,9 @@ static void check_thread_timers(struct task_struct *tsk, sig->rlim[RLIMIT_RTTIME].rlim_cur += USEC_PER_SEC;
YOSHIFUJI Hideaki / åè¤è±æ writes: (Summary)
(Commit-ID: bf0b48dfc368c07c42b5a3a5658c8ee81b4283ac)
to fix this specific issue.
--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH writes: (Summary)
Now why that hid quirk line hadn't been added for the year or so that
the person knew about it, sure is odd to me...
I'll test it out and probably reduce this whole thing to a one-line
hid-quirk patch...
ugh, why do people not send stuff upstream, it just wastes everyone's
time in the end :(
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
(Eric W. Biederman) writes: (Summary) writes:
What I was thinking was:
In kernel A()
relocate_new_kernel:
...
call *%eax
kexec_jump_back_entry:
/* This code should be PIC so figure out where we are */
call 1f
1:
popl %edi
subl $(1b - relocate_kernel), %edi
/* Setup a safe stack */
leal PAGE_SIZE(%edi), %esp
...
Then in purgatory we can read the address of kexec_jump_back_entry
by examining 0(%esp) and export it in whatever fashion is sane.
Peng Haitao writes: (Summary) 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/audit.c b/kernel/audit.c index b782b04..48fa3d0 100644 --- a/kernel/audit.c +++ b/kernel/audit.c @@ -686,7 +686,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh) } /* fallthrough */ case AUDIT_LIST: - err = audit_receive_filter(nlh->nlmsg_type, NETLINK_CB(skb).pid, + err = audit_receive_filter(msg_type, NETLINK_CB(skb).pid, uid, seq, data, nlmsg_len(nlh), loginuid, sid);
"Huang, Ying" writes: (Summary) On Thu, 2008-05-15 at 22:00 -0400, Vivek Goyal wrote:
[...]
The disadvantage of this solution is that kernel B must know it is
original kernel (A) or kexeced kernel (B).
(Tony Breeds) writes: (Summary) Thoughts?.
From: Tony Breeds <tony@bakeyournoodle.com>
Subject: [PATCH] Fix various 8390 builds
The commit 3f8cb098859bbea29d7b3765a3102e4a6bf81b85
(drivers/net/lib8390: fix warning, trim trailing whitespace) removed
ei_local from ei_tx_err() and ei_rx_overrun() resulting in the following
build errors on m68k and sh:
Using /scratch1/tony/next as source for kernel
GEN /scratch1/tony/next_out/Makefile
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL /scratch1/tony/next/scripts/checksyscalls.sh
CHK include/linux/compile.h
CC [M] drivers/net/zorro8390.o
In file included from /scratch1/tony/next/drivers/net/zorro8390.c:47:
drivers/net/lib8390.c: In function 'ei_tx_err':
drivers/net/lib8390.c:556: error: 'ei_local' undeclared (first use in this function)
drivers/net/lib8390.c:556: error: (Each undeclared identifier is reported only once
drivers/net/lib8390.c:556: error: for each function
"Huang, Ying" writes: (Summary)
Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Fernando Luis Vázquez Cao writes: (Summary)
extern int reserve_perfctr_nmi(unsigned int);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Vivek Goyal writes: (Summary) On Thu, May 15, 2008 at 12:57:53PM +0800, Huang, Ying wrote:
IMHO, this kind of make more sense to me when keeping C function like
semantics in mind.
Both the cases can be treated like calls to functions (calling BIOS function
and jumping to kernel B).
Hiroshi Shimamoto writes: (Summary) 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c index f1525ad..c42a03a 100644 --- a/kernel/posix-cpu-timers.c +++ b/kernel/posix-cpu-timers.c @@ -1037,6 +1037,9 @@ static void check_thread_timers(struct task_struct *tsk, sig->rlim[RLIMIT_RTTIME].rlim_cur += USEC_PER_SEC;
Vivek Goyal writes: (Summary)
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Mauro Carvalho Chehab writes: (Summary) This need to be mandatory for
a few drivers like saa7134, where some exported symbols at kbd-ir-i2c are used
there.
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
"Huang, Ying" writes: (Summary) Biederman wrote:
As far as I know, in suspend to ram, interrupt is used as waking up
event, such as, keyboard interrupt.
Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linus Torvalds writes: (Summary) Or we should say "ok, I can write even _better_ source
code, and fix the bug, make the source look nicer _and_ not piss off the
script too".
So I did that too.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
"Huang, Ying" writes: (Summary) But I think if the
effort is small, why not support general 32-bit physical mode code call
at same time.
Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
(Eric W. Biederman) writes: (Summary)
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Herbert Xu writes: On Thu, May 15, 2008 at 05:33:54PM -0500, Randy Dunlap wrote:
Thanks, I've merged this into the original change.
"Huang, Ying" writes: (Summary)
Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Vivek Goyal writes: (Summary) On Thu, May 15, 2008 at 01:41:50PM +0800, Huang, Ying wrote:
ioapic_suspend() is not putting APICs in Legacy mode and that's why
we are seeing the issue.
Paul Mackerras writes: (Summary) 4 -
20 files changed, 508 insertions(+), 39 deletions(-)
Andy Fleming (2):
[POWERPC] 85xx: Add 8568 PHY workarounds to board code
[POWERPC] 85xx: Fix some sparse warnings for 85xx MDS
Anton Vorontsov (3):
[POWERPC] 86xx: mpc8610_hpcd: use ULI526X driver for on-board ethernet
[POWERPC] 86xx: mpc8610_hpcd: add support for NOR and NAND flashes
[POWERPC] 86xx: mpc8610_hpcd: fix second serial port
Benjamin Herrenschmidt (1):
[POWERPC] vmemmap fixes to use smaller pages
FUJITA Tomonori (1):
[POWERPC] spufs: Fix compile error
Ishizaki Kou (1):
[POWERPC] cell: Fix section mismatches in io-workarounds code
Jeremy McNicoll (1):
[POWERPC] 85xx: SBC8548 - Add flash support and HW Rev reporting
Luke Browning (1):
[POWERPC] spufs: Fix pointer reference in find_victim
Nate Case (1):
[POWERPC] Fix uninitialized variable bug in copy_{to|from}_user
R
Harvey Harrison writes: (Summary) } - -/*-------------------------------------------------------------------------*/ - -/* Routines for unaligned data access */ - -static u16 get_be16(u8 *buf) -{ - return ((u16) buf[0] << -} - - /*-------------------------------------------------------------------------*/ /* @@ -1551,9 +1522,9 @@ static int do_read(struct fsg_dev *fsg) /* Get the starting Logical Block Address and check that it's * not too big */ if (fsg->cmnd[0] == SC_READ_6) - lba = (fsg->cmnd[1] << /* We allow DPO (Disable Page Out = don't save data in the * cache) and FUA (Force Unit Access = don't read from the @@ -1684,9 +1655,9 @@ static int do_write(struct fsg_dev *fsg) /* Get the starting Logical Block Address and check that it's * not too big */ if (fsg->cmnd[0] == SC_WRITE_6) - lba = (fsg->cmnd[1] << /* We allow DPO (Disable Page Out = don't save data in the * cache) and FUA (Force Unit Access = write directly to the @@ -1920,7 +1891,7 @@ static int do_verify(s
Andi Kleen writes: (Summary) Otherwise it'll be useless
for most people.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Adrian Bunk writes: (Summary) PCI - ---help--- - Say Y or M if you have a PCI sound card utilizing the Trident - 4DWave-DX/NX chipset or your mother board chipset has SiS 7018 - or ALi 5451 built-in. you can enable them by saying Y to "/proc file - system support" and "Sysctl support", and after the /proc file - system has been mounted, executing the command - - command what is enabled - - echo 0>/proc/ALi5451 pcm out is also set to S/PDIF out. !STANDALONE) diff --git a/sound/oss/Makefile b/sound/oss/Makefile index 1f86299..3a14147 100644 --- a/sound/oss/Makefile +++ b/sound/oss/Makefile @@ -29,7 +29,6 @@ obj-$(CONFIG_SOUND_MSNDCLAS) +=3D msnd.o msnd_classic= =2Eo obj-$(CONFIG_SOUND_MSNDPIN) +=3D msnd.o msnd_pinnacle.o obj-$(CONFIG_SOUND_VWSND) +=3D vwsnd.o obj-$(CONFIG_SOUND_AU1550_AC97) +=3D au1550_ac97.o ac97_codec.o -obj-$(CONFIG_SOUND_TRIDENT) +=3D trident.o ac97_codec.o obj-$(CONFIG_SOUND_BCM_CS4297A) +=3D swarm_cs4297a.o =20 obj-$(CONFIG_SOUND_WM97XX) +=3D ac97_plugin_wm97xx.o diff --git a/sound/oss/trident.
KOSAKI Motohiro writes:
Agreed.
I like your approach :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Adrian Bunk writes: (Summary) 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
e6a639a06854b75ca90e49e00dfd858cb4c8dd02 diff --git a/drivers/media/common/tuners/mxl5005s.c b/drivers/media/common/tuners/mxl5005s.c
index 5d05b53..0dc2bef 100644
--- a/drivers/media/common/tuners/mxl5005s.c
+++ b/drivers/media/common/tuners/mxl5005s.c
@@ -101,7 +101,7 @@ enum {
MXL_QAM,
MXL_ANALOG_CABLE,
MXL_ANALOG_OTA
-} tuner_modu_type;
Rusty Russell writes: (Summary) The problem of allocating memory which is laid out precisely
as the original per-cpu alloc is vexing on NUMA, and probably requires
reserving virtual address space and remapping into it, but the rewards
would be maximally-efficient per-cpu accessors, and getting rid of that
boutique allocator in module.c.
Only minor commentry on the patch itself:
void * would seem more natural here (love those gcc'isms)
Looks like you can skip this if you assign to mod->refptr directly below:
And finally:
This if (refptr) seems redundant.
Thanks!
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.t
Henrique de Moraes Holschuh writes: On Fri, 16 May 2008, Rusty Russell wrote:
It would be easy to implement rng-tools as a kernel driver, as long as
proper in-kernel interfaces exist for it to work in an event-driven way.
I don't see what we would win over rng-tools in userspace, however.
Andrew Morton writes: (Summary)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Paul Jackson writes: (Summary) Peter Anvin, Andi Kleen, Ingo Molnar (and anyone else
interested):
I invite your review of these patches, especially 7, 9 and 10 of the
set of 10, that I posted yesterday.
In combination, I believe that they allow passing more than E820MAX
(128) memory map entries from EFI firmware to a booting kernel, beyond
the E820 constraints of non-EFI legacy BIOS's, without changing the
EFI interface interface.
Henrique de Moraes Holschuh writes: (Summary) On Thu, 15 May 2008, Theodore Tso wrote:
The TPM has some sort of idea of restricted operations. even when it is disabled(!),
so I would not be too surprised to find out that, as long as it is
enabled, it will return random numbers to anyone.
But access to the TPM requires a control layer which must have excusive
access to the chip.
Andrew Morton writes: (Summary) Regularly :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nick Piggin writes: (Summary) But
you catch that refault in your driver , which can prevent the page from
being faulted back in.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Abhijit Menon-Sen writes: (Summary) 9 +++------ 5 files changed, 16 insertions(+), 11 deletions(-) diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h index 82de2fb..ed8ab42 100644 --- a/include/linux/kallsyms.h +++ b/include/linux/kallsyms.h @@ -101,6 +101,16 @@ static inline void print_symbol(const char *fmt, unsigned long addr) __builtin_extract_return_addr((void *)addr)); +#endif +} + #ifndef CONFIG_64BIT #define print_ip_sym(ip) \ do { \ diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index 7b76fd3..9625317 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -418,7 +418,7 @@ void __suspend_report_result(const char *function, void *fn, int ret) { if (ret) { printk(KERN_ERR "%s(): ", function); } if (msgbuf[0]) { - print_fn_descriptor_symbol(KERN_WARNING "initcall %s()", - (unsigned long) *call);
Henrique de Moraes Holschuh writes: (Summary) The PUBEK is there, the kernel
exports it nicely through sysfs, but trousers gets crap instead of the
PUBEK if I ask it to get the PUBEK (and therefore, nothing useful in
trousers works).
Jesse Barnes writes: (Summary)
I think the approach is fairly sound (using a notifier to let mode setting
drivers switch the front buffer), but there are some details to be worked out
still:
- the console needs to be switched earlier on, probably in panic(), so we
don't lose messages (the current code will print stuff to VT8 until the
notifier gets called, so we lose the early stuff), but that should be easy
- abusing KD_TEXT for this purpose probably isn't right, I think we'll want
some smarts under KD_KERNEL_GRAPHICS for this (console layer hacking for
the above could be under a KD_KERNEL_GRAPHICS test)
- we definitely don't wait to wait on VT switch in the notifier, this means
more exporting of stuff from the console core and smarter handling
- the switch in the notifier should be more robust;
+
#include "xf86.h"
#include "xf86_OSproc.h"
#include "xf86Resources.h"
#include "xf86RAC.h"
+#include "xf86Priv.h"
#include "xf86cmap.h"
#include "compiler.h"
#include "mibstore.h"
@@ -1068,6 +1071
Rusty Russell writes: (Summary) I was a little surprised to see that hwrng
drivers don't contribute in any way to the entropy pool though, but now
reading the thread I find out about rngd (not installed on my Ubuntu system,
but available at least).
One could argue that virtual rng should try to feed the kernel rng directly,
with or without entropy credit.
Anyway, since there's interest, I'll drag virtio_rng from the bottom of the
queue, apply Christian's fix (which I somehow missed before, sorry
Christian), and re-post.
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Theodore Tso writes: (Summary) I tried for a bit to try to get it to
work a while ago, but the few things I tried didn't work, and I
eventually lost interest.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton writes: (Summary) chip->slv_addr_shift) - 1)) {
I think?
It's a neat-looking driver.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Theodore Tso writes: (Summary) Normally that key is stored in a file, and of
course we can have a userspace helper pull that key into the kernel,
but given the extensive Trousers infrastructure that can do this
already, it seemed to make more sense to do it all in userspace, and
not require any more kernel code.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Tino Keitel writes: (Summary) On Thu, May 15, 2008 at 14:11:17 -0700, Greg KH wrote:
[...]
Yes, I'm using it for months.
When the appleir kernel driver is used, the IR device acts as in input
device, not as a HID device.
Rusty Russell writes: (Summary) On Friday 16 May 2008 01:32:47 Avi Kivity wrote:
But performance is going to suck in the meantime, as currently our host
doesn't do this.
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
"Rafael J. Wysocki" writes: (Summary)
With BenH in particular (CCed).
I don't agree with that.
Ditto.
Please be more specific.
The names have been discussed either and I don't intend to change them now. :-)
Still, having more specialized callbacks is not generally bad IMO, they
can reuse the code just fine.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
"Dave Airlie" writes: (Summary) the
radeon drm hasn't seen any changes that should affect this sorta
thing, do you run radeonfb or vesafb?
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Chinner writes: On Thu, May 15, 2008 at 10:42:15AM -0700, Christoph Lameter wrote:
We're out of memory. I'd suggest write backing as much as you can
without blocking. e.g. treat it like pdflush and say 1024 pages, or
like balance_dirty_pages() and write a 'write_chunk' back from the
mapping (i.e. sync_writeback_pages()).
Any of these are better from an I/O perspective than single page
writeback....
Cheers,
Dave.
Henrique de Moraes Holschuh writes: (Summary) make it work here too), I will write the rng-tools trousers
interface code (at least for the Debian version) :-)
The kernel TPM driver works, the BIOS works, and I have the PCRs updated
properly during boot, but trousers get the tpm pubek key wrong for some
reason (the kernel driver can read it just fine).
Bjorn Helgaas writes: (Summary) if (!pnp_res) { - if (!warned) { - dev_err(&dev->dev, "can't add resource for IRQ %d\n", - irq); if (!pnp_res) { - if (!warned) { - dev_err(&dev->dev, "can't add resource for IO " - "%#llx-%#llx\n",(unsigned long long) start, - (unsigned long long) end); if (!pnp_res) { - if (!warned) { - dev_err(&dev->dev, "can't add resource for MEM " - "%#llx-%#llx\n",(unsigned long long) start, - (unsigned long long) end);
Bjorn Helgaas writes: (Summary) IORESOURCE_DISABLED) - pnp_printf(buffer, " disabled\n"); - else - pnp_printf(buffer, " 0x%llx-0x%llx\n", - (unsigned long long) res->start, - (unsigned long long) res->end); IORESOURCE_DISABLED) { pnp_printf(buffer, " disabled\n"); + } + + switch (pnp_resource_type(res)) { + case IORESOURCE_IO: + case IORESOURCE_MEM: + pnp_printf(buffer, " %#llx-%#llx\n", (unsigned long long) res->start, (unsigned long long) res->end); - else - pnp_printf(buffer, " %lld\n", - (unsigned long long) res->start); + } } + ret = (buffer->curr - buf);
Bjorn Helgaas writes: (Summary)
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. i++) {
- if (pnp_resource_valid(res)) {
- pnp_printf(buffer, "io");
- else
- pnp_printf(buffer, " 0x%llx-0x%llx\n",
- (unsigned long long) res->start,
- (unsigned long long) res->end); i++) {
- if (pnp_resource_valid(res)) {
- pnp_printf(buffer, "mem");
- else
- pnp_printf(buffer, " 0x%llx-0x%llx\n",
- (unsigned long long) res->start,
- (unsigned long long) res->end); i++) {
- if (pnp_resource_valid(res)) {
- pnp_printf(buffer, "irq");
- else
- pnp_printf(buffer, " %lld\n",
- (unsigned long long) res->start); i++) {
- if (pnp_resource_valid(res)) {
-
"Jesper Juhl" writes: (Summary) 2008/5/16 Theodore Tso <tytso@mit.edu>:
Hmm, I would like to know how you'd do that.
Even if you a) know the exact distro installed (and the configuration,
b) know the exact hardware in the machine, c) know the exact time it
was booted and know that there have been no ssh logins or similar that
might have generated syscalls, d) know exactely how many requests (and
of what type) have been made to the server and the exact times they
were made.
How would you go about brute force guessing the contents of the entropy pool?
Bjorn Helgaas writes: (Summary) + + if (pnp_resource_valid(res)) + return res->start; + + if (pnp_resource_valid(res)) + return res->flags; } static inline int pnp_port_valid(struct pnp_dev *dev, unsigned int bar) @@ -63,25 +75,41 @@ static inline int pnp_port_valid(struct static inline resource_size_t pnp_port_len(struct pnp_dev *dev, unsigned int bar) { - return pnp_resource_len(pnp_get_resource(dev, IORESOURCE_IO, bar)); } static inline int pnp_mem_valid(struct pnp_dev *dev, unsigned int bar) @@ -92,18 +120,30 @@ static inline int pnp_mem_valid(struct p static inline resource_size_t pnp_mem_len(struct pnp_dev *dev, unsigned int bar) { - return pnp_resource_len(pnp_get_resource(dev, IORESOURCE_MEM, bar)); } static inline int pnp_irq_valid(struct pnp_dev *dev, unsigned int bar) @@ -114,12 +154,20 @@ static inline int pnp_irq_valid(struct p static inline resource_size_t pnp_dma(struct pnp_dev *dev, unsigned int bar) { - return pnp_get_resource(dev, IORESOURCE_DMA, bar)->start;
Bjorn Helgaas writes: (Summary) This series replaces the fixed-size pnp_resource_table with a
linked list of resources.
This iteration fixes a null pointer dereference Andrew found
on a PNPBIOS machine.
Because of that problem, Andrew dropped the following patches
from the -mm tree (these were patches 6-8 of the v1 series):
pnp-replace-pnp_resource_table-with-dynamically-allocated-resources.patch
pnp-remove-ratelimit-on-add-resource-failures.patch
pnp-dont-sort-by-type-in-sys-resources.patch
This posting doesn't repeat patches 1-5 from the original v1 series;
Adrian Bunk writes: On Mon, May 12, 2008 at 03:43:45PM +0530, debian developer wrote:
Works here.
Please send your .config
cu
Adrian
"Carlos R. Mafra" writes: (Summary)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik writes: (Summary) It should be quite doable to support TPM
RNG entirely via userspace, at any rate.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Rene Herman writes: (Summary) ]
And while that person is at it, could he or she please remove the silly
() from the "foo+0x0/0x1234()" (or the "foo+0x0/0x1234 [bar]()" or the
"0x12345678()").
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik writes: (Summary) Brandeburg, Jesse wrote:
So I guess a good message for customers might be:
Don't depend on an entropy source whose volume decreases as workload and
network traffic increase.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Randy Dunlap writes:
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Theodore Tso writes: (Summary) If the attacker knows the machine type,
distribution OS loaded, etc., it might not be that hard to brute force
guess many of the factors you have listed above.
Basically the question has always been one of the overhead to collect
and boil down any input data (which after all, any user space process
can send arbitrary data into the entropy pool via "cat my_secret_data
is estimating how much "entropy" should be ascribed to data which is
sent into the entropy pool, and this is where you have to be very
careful.
If you screw the entropy credit information then security of
/dev/random will be impacted.
Henrique de Moraes Holschuh writes: (Summary) But at least valgrind tells me I fixed the worst bugs, and FIPS 140-2 (the old version of it that still had criteria for non-deterministic RNGs) and DIEHARD couldn't find any issues with its output after several runs on gigabyte-sized files produced both from an Intel FWH RNG, and from a VIA PadLock RNG.
David Chinner writes: On Thu, May 15, 2008 at 09:45:55PM +0400, Alexander Beregalov wrote:
[snip]
That hang is just memory reclaim running, I think you'll find.
It can take some time for reclaim to find pages to use, and meanwhile
everything in the machine will back up behind it....
Cheers,
Dave.
Theodore Tso writes: (Summary) That has the net result of potentially
improving the entropy found in /dev/random and /dev/urandom, but not
necessarily compromising /dev/random, since /dev/random's output is
throttled by the entropy estimate.
The only cost of doing this would be the overhead in sending the
information into the entropy pool.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
"Theodore Ts'o" writes: (Summary) Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git for_linus
These are all cleanups and bug fixes for 2.6.26.
Many thanks,
- Ted
fs/ext4/balloc.c | journaled)
Mingming Cao (1):
jbd2: update transaction t_state to T_COMMIT fix
Valerie Clement (1):
ext4: mballoc fix mb_normalize_request algorithm for 1KB block size filesystems
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
» more
» more
Is RSS MAD missing something? Tell us about new feeds here.