* [Qemu-devel] Patch for minor qemu heap corruption bug when the console is zero width
From: Kenneth Duda @ 2006-04-07 18:08 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <6fe044190604060153i6b43333dlec41c663f2229cd3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
Hi everyone, here is another patch for a much less significant bug. If
your "vc" console width is 0, qemu corrupts the heap (because it
writes one character into a screen buffer that's been malloc'ed as
size 0). I don't know if this bug ever causes problems in practice
--- I picked it up using mcheck() when debugging heap corruption due
to various slirp bugs. Anyway, this trivial patch fixes the trivial
bug. Feedback on what I can do to get patches like this applied most
appreciated!
Thanks,
-Ken
[-- Attachment #2: qemu-zero-width-console.patch --]
[-- Type: text/plain, Size: 664 bytes --]
diff -burN qemu-snapshot-2006-03-27_23.orig/console.c qemu-snapshot-2006-03-27_23/console.c
--- qemu-snapshot-2006-03-27_23.orig/console.c 2006-03-11 07:35:30.000000000 -0800
+++ qemu-snapshot-2006-03-27_23/console.c 2006-04-06 00:25:41.000000000 -0700
@@ -407,7 +407,8 @@
if (s->width < w1)
w1 = s->width;
- cells = qemu_malloc(s->width * s->total_height * sizeof(TextCell));
+ cells = qemu_malloc((s->width * s->total_height + 1) * sizeof(TextCell));
+ /* Add one extra in case s->width is 0, so we can still store one character. */
for(y = 0; y < s->total_height; y++) {
c = &cells[y * s->width];
if (w1 > 0) {
^ permalink raw reply
* [Bluez-devel] Discoverabe Mode - GIAC or LIAC
From: Renan @ 2006-04-07 18:07 UTC (permalink / raw)
To: bluez-devel
[-- Attachment #1: Type: text/plain, Size: 212 bytes --]
Hello everyone!!!
Does anybody know how to set the discoverable mode for a device under
Linux?
How to set the LIAC/GIAC mode for a device?
Thanks in advance.
Renan Martins
renan@atlantico.com.br
[-- Attachment #2: Type: text/html, Size: 5366 bytes --]
^ permalink raw reply
* Re: Trying again with cross compile
From: Adrian McMenamin @ 2006-04-07 18:07 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5hmzextpl7.wl%tiwai@suse.de>
On Fri, 2006-04-07 at 16:41 +0200, Takashi Iwai wrote:
> Maybe not yet? The fix is simple as below.
>
>
> Takashi
>
>
> diff -r fd751f7a6395 -r 6cddb34dad21 include/core.h
> --- a/include/core.h Thu Apr 6 15:23:55 2006 +0200
> +++ b/include/core.h Thu Apr 6 15:26:05 2006 +0200
> @@ -176,7 +176,7 @@ int snd_power_wait(struct snd_card *card
>
> #define snd_power_lock(card) do { (void)(card); } while (0)
> #define snd_power_unlock(card) do { (void)(card); } while (0)
> -static inline int snd_power_wait(struct snd_card *card, unsigned int state, struct file *file) { return 0; }
> +static inline int snd_power_wait(struct snd_card *card, unsigned int state) { return 0; }
> #define snd_power_get_state(card) SNDRV_CTL_POWER_D0
> #define snd_power_change_state(card, state) do { (void)(card); } while (0)
>
>
I've patched and everything seems to be fine expect that the build gets
wedged on hpi6000
I've even tried leaving if for over an hour - to no avail
Here's what make reports with debugging on if that helps anyone...
Successfully remade target file
`/home/adrian/alsa-driver/pci/asihpi/hpi4000.o'.
Considering target file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.o'.
File `/home/adrian/alsa-driver/pci/asihpi/hpi6000.o' does not
exist.
Looking for an implicit rule for
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.o'.
Trying pattern rule with stem `hpi6000.o'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.o_shipped'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
Trying rule prerequisite `FORCE'.
Found an implicit rule for
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.o'.
Considering target file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
Looking for an implicit rule for
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c_shipped'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.y'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.l'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c,v'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.c,v'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.c'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/s.hpi6000.c'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/SCCS/s.hpi6000.c'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.y'.
Looking for a rule with intermediate file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.y'.
Avoiding implicit rule recursion.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.y_shipped'.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.y,v'.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.y,v'.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.y'.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/s.hpi6000.y'.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/SCCS/s.hpi6000.y'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.l'.
Looking for a rule with intermediate file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.l'.
Avoiding implicit rule recursion.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.l_shipped'.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.l,v'.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.l,v'.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.l'.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/s.hpi6000.l'.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/SCCS/s.hpi6000.l'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w'.
Looking for a rule with intermediate file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w'.
Avoiding implicit rule recursion.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w_shipped'.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w,v'.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.w,v'.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.w'.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/s.hpi6000.w'.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/SCCS/s.hpi6000.w'.
Trying pattern rule with stem `hpi6000'.
Rejecting impossible implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w'.
No implicit rule found for
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
Finished prerequisites of target file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
No need to remake target
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
Pruning file `FORCE'.
Finished prerequisites of target file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.o'.
Must remake target `/home/adrian/alsa-driver/pci/asihpi/hpi6000.o'.
Putting child 0x080e9bd8 (/home/adrian/alsa-driver/pci/asihpi/hpi6000.o)
PID 19527 on the chain.
Live child 0x080e9bd8 (/home/adrian/alsa-driver/pci/asihpi/hpi6000.o)
PID 19527
CC [M] /home/adrian/alsa-driver/pci/asihpi/hpi6000.o
It sticks here for ever - though top reports cc1 is still active
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: chmod u+s confusion
From: Chris Largret @ 2006-04-07 18:06 UTC (permalink / raw)
To: David Fierbaugh; +Cc: linux-newbie
In-Reply-To: <200604070842.19837.david@fierbaugh.org>
On Fri, 2006-04-07 at 08:42 +0000, David Fierbaugh wrote:
> I'd have to actually do a little playing around to make sure, but I believe
> that whoami is specifically written to NOT take SUID into account. It figures
> out exactly who ran the process which called it.
>
> This prevents faking out whoami into saying everyone is root.
I probably should have mentioned that this was just a PoC for what I was
trying to do. I'm actually trying to have the script create a file
someplace like /etc/cron.hourly. It has limited uses (and only my user
and root will be able to run it -- root group), but the script is
refusing to create the file.
> Why?
> Let's say you have a script that runs whoami to determine what
> access/control/etc a user should be given. If an attacker could manage to
> fake whoami into always saying the user was root by using suid, then they now
> have administrative access to whatever that script does.
>
> This would be a bad thing.
>
> You might also want to take a look at /bin/id
/usr/bin/id (where my id program is placed) still returns my username.
Thanks for the reply, but I'm still stumped :)
> > $ echo -e '#!/bin/sh\n\nwhoami'>whoami.sh
> > # chown root:root whoami.sh
> > # chmod 4755 whoami.sh
> > $ ./whoami.sh
> > chris
> > # chmod u+s `which whoami`
> > $ whoami
> > root
--
Chris Largret <http://daga.dyndns.org>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* wierd failures from -mm1
From: Martin Bligh @ 2006-04-07 18:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Andy Whitcroft
I hadn't mailed this out for a while, cause we weren't sure if it was
-mm or a testing glitch, but there's been no -git releases, so Andy
reran -mm to double check, and it still seems to be there. a subsequent
test of rc1 + cons patches didn't hit this ... I think -mm has issues ;-)
Look at the 2.6.17-rc1-mm1 column from: http://test.kernel.org/
Drilling down into the console logs:
http://test.kernel.org/abat/27597/debug/console.log
Hangs after testing NMI watchdog.
http://test.kernel.org/abat/27596/debug/console.log
Hangs after bringing up cpus.
http://test.kernel.org/abat/27598/debug/console.log
http://test.kernel.org/abat/27593/debug/console.log
Both fail with reiserfs fsck errors; at first sight look like just dirty
root partitions, but I don't think they are.
Filesystem is clean
Failed to lock the process to fsck the mounted ro partition. Bad address.
fsck.reiserfs /dev/sda3 failed (status 0x8). Run manually!
Note that it's actually saying it's clean.
^ permalink raw reply
* [Qemu-devel] Patch for sending large (>4k) packets through qemu/slirp
From: Kenneth Duda @ 2006-04-07 18:05 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <6fe044190604060153g1e642409p9682c21a774a21df@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
Hi everyone,
I have patches for a few bugs in qemu, and am new to the list --- if
anyone could clue me in on the best way to get patches applied to the
qemu mainline, that would be great.
This patch fixes three problems (actually all in slirp) with sending
large packets from guest to host in qemu-0.8.0.20060327:
(1) the code in slirp's ip_reass() reads a next pointer out an mbuf
after freeing it via m_cat().
(2) the code in slirp's m_inc() calls realloc() on a large mbuf, but
fails to adjust m_data to point to the new allocation (see
http://lists.gnu.org/archive/html/qemu-devel/2005-05/msg00228.html).
(3) there are many places within ip_input(), ip_reass(), udp_input(),
etc., that treat ip_len and ip_off as though they were declared
unsigned, when in fact they have been declared signed.
Thanks,
-Ken
[-- Attachment #2: qemu-slirp-reassembly-bug.patch --]
[-- Type: text/plain, Size: 466 bytes --]
diff -BurN qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c qemu-snapshot-2006-03-27_23/slirp/ip_input.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c 2004-04-22 00:10:47.000000000 +0000
+++ qemu-snapshot-2006-03-27_23/slirp/ip_input.c 2006-04-06 06:02:52.000000000 +0000
@@ -344,8 +344,8 @@
while (q != (struct ipasfrag *)fp) {
struct mbuf *t;
t = dtom(q);
- m_cat(m, t);
q = (struct ipasfrag *) q->ipf_next;
+ m_cat(m, t);
}
/*
[-- Attachment #3: qemu-slirp-mbuf-bug.patch --]
[-- Type: text/plain, Size: 887 bytes --]
diff -BurN qemu-snapshot-2006-03-27_23.orig/slirp/mbuf.c qemu-snapshot-2006-03-27_23/slirp/mbuf.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/mbuf.c 2004-04-22 00:10:47.000000000 +0000
+++ qemu-snapshot-2006-03-27_23/slirp/mbuf.c 2006-04-05 13:03:03.000000000 +0000
@@ -146,18 +146,19 @@
struct mbuf *m;
int size;
{
+ int datasize;
+
/* some compiles throw up on gotos. This one we can fake. */
if(m->m_size>size) return;
if (m->m_flags & M_EXT) {
- /* datasize = m->m_data - m->m_ext; */
+ datasize = m->m_data - m->m_ext;
m->m_ext = (char *)realloc(m->m_ext,size);
/* if (m->m_ext == NULL)
* return (struct mbuf *)NULL;
*/
- /* m->m_data = m->m_ext + datasize; */
+ m->m_data = m->m_ext + datasize;
} else {
- int datasize;
char *dat;
datasize = m->m_data - m->m_dat;
dat = (char *)malloc(size);
[-- Attachment #4: qemu-slirp-32k-packets.patch --]
[-- Type: text/plain, Size: 4433 bytes --]
diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/ip.h qemu-snapshot-2006-03-27_23/slirp/ip.h
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip.h 2004-04-21 17:10:47.000000000 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/ip.h 2006-04-06 00:28:49.000000000 -0700
@@ -79,6 +79,11 @@
* We declare ip_len and ip_off to be short, rather than u_short
* pragmatically since otherwise unsigned comparisons can result
* against negative integers quite easily, and fail in subtle ways.
+ *
+ * The only problem with the above theory is that these quantities
+ * are in fact unsigned, and sorting fragments by a signed version
+ * of ip_off doesn't work very well, nor does length checks on
+ * ip packets with a signed version of their length!
*/
struct ip {
#ifdef WORDS_BIGENDIAN
@@ -101,6 +106,9 @@
struct in_addr ip_src,ip_dst; /* source and dest address */
};
+#define IP_OFF(ip) (*(u_int16_t *)&((ip)->ip_off))
+#define IP_LEN(ip) (*(u_int16_t *)&((ip)->ip_len))
+
#define IP_MAXPACKET 65535 /* maximum packet size */
/*
diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c qemu-snapshot-2006-03-27_23/slirp/ip_input.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c 2004-04-21 17:10:47.000000000 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/ip_input.c 2006-04-06 00:32:19.000000000 -0700
@@ -111,7 +111,7 @@
* Convert fields to host representation.
*/
NTOHS(ip->ip_len);
- if (ip->ip_len < hlen) {
+ if (IP_LEN(ip) < hlen) {
ipstat.ips_badlen++;
goto bad;
}
@@ -124,13 +124,13 @@
* Trim mbufs if longer than we expect.
* Drop packet if shorter than we expect.
*/
- if (m->m_len < ip->ip_len) {
+ if (m->m_len < IP_LEN(ip)) {
ipstat.ips_tooshort++;
goto bad;
}
/* Should drop packet if mbuf too long? hmmm... */
- if (m->m_len > ip->ip_len)
- m_adj(m, ip->ip_len - m->m_len);
+ if (m->m_len > IP_LEN(ip))
+ m_adj(m, IP_LEN(ip) - m->m_len);
/* check ip_ttl for a correct ICMP reply */
if(ip->ip_ttl==0 || ip->ip_ttl==1) {
@@ -191,7 +191,7 @@
* or if this is not the first fragment,
* attempt reassembly; if it succeeds, proceed.
*/
- if (((struct ipasfrag *)ip)->ipf_mff & 1 || ip->ip_off) {
+ if (((struct ipasfrag *)ip)->ipf_mff & 1 || IP_OFF(ip)) {
ipstat.ips_fragments++;
ip = ip_reass((struct ipasfrag *)ip, fp);
if (ip == 0)
@@ -281,7 +281,7 @@
*/
for (q = (struct ipasfrag *)fp->ipq_next; q != (struct ipasfrag *)fp;
q = (struct ipasfrag *)q->ipf_next)
- if (q->ip_off > ip->ip_off)
+ if (IP_OFF(q) > IP_OFF(ip))
break;
/*
@@ -290,10 +290,10 @@
* segment. If it provides all of our data, drop us.
*/
if (q->ipf_prev != (ipasfragp_32)fp) {
- i = ((struct ipasfrag *)(q->ipf_prev))->ip_off +
- ((struct ipasfrag *)(q->ipf_prev))->ip_len - ip->ip_off;
+ i = IP_OFF((struct ipasfrag *)(q->ipf_prev)) +
+ IP_LEN((struct ipasfrag *)(q->ipf_prev)) - IP_OFF(ip);
if (i > 0) {
- if (i >= ip->ip_len)
+ if (i >= IP_LEN(ip))
goto dropfrag;
m_adj(dtom(ip), i);
ip->ip_off += i;
@@ -305,9 +305,9 @@
* While we overlap succeeding segments trim them or,
* if they are completely covered, dequeue them.
*/
- while (q != (struct ipasfrag *)fp && ip->ip_off + ip->ip_len > q->ip_off) {
- i = (ip->ip_off + ip->ip_len) - q->ip_off;
- if (i < q->ip_len) {
+ while (q != (struct ipasfrag *)fp && IP_OFF(ip) + IP_LEN(ip) > IP_OFF(q)) {
+ i = (IP_OFF(ip) + IP_LEN(ip)) - IP_OFF(q);
+ if (i < IP_LEN(q)) {
q->ip_len -= i;
q->ip_off += i;
m_adj(dtom(q), i);
@@ -327,9 +327,9 @@
next = 0;
for (q = (struct ipasfrag *) fp->ipq_next; q != (struct ipasfrag *)fp;
q = (struct ipasfrag *) q->ipf_next) {
- if (q->ip_off != next)
+ if (IP_OFF(q) != next)
return (0);
- next += q->ip_len;
+ next += IP_LEN(q);
}
if (((struct ipasfrag *)(q->ipf_prev))->ipf_mff & 1)
return (0);
diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/udp.c qemu-snapshot-2006-03-27_23/slirp/udp.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/udp.c 2006-04-06 00:24:30.000000000 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/udp.c 2006-04-06 00:32:55.000000000 -0700
@@ -111,12 +111,12 @@
*/
len = ntohs((u_int16_t)uh->uh_ulen);
- if (ip->ip_len != len) {
- if (len > ip->ip_len) {
+ if (IP_LEN(ip) != len) {
+ if (len > IP_LEN(ip)) {
udpstat.udps_badlen++;
goto bad;
}
- m_adj(m, len - ip->ip_len);
+ m_adj(m, len - IP_LEN(ip));
ip->ip_len = len;
}
^ permalink raw reply
* Re: fs/binfmt_elf.c:maydump()
From: Daniel Jacobowitz @ 2006-04-07 18:02 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel
In-Reply-To: <20060406.221807.114721185.davem@davemloft.net>
On Thu, Apr 06, 2006 at 10:18:07PM -0700, David S. Miller wrote:
> How about something like the following patch? If it's executable
> and not written to, skip it. This would skip the main executable
> image and all text segments of the shared libraries mapped in.
Will this dump text segments that have been COW'd for the purposes of
inserting a breakpoint?
It's just a question of goals, I guess. We could dump code, but it's
rarely useful, so historically we didn't. Similarly, we could dump
mapped data from shared memory, but it can be huge and is rarely
useful, so generally we don't.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply
* Re: [PATCH 2.6.17-rc1-mm1] sched_domain-handle-kmalloc-failure-fix
From: Dave Hansen @ 2006-04-07 18:01 UTC (permalink / raw)
To: Lee Schermerhorn; +Cc: linux-kernel, Andrew Morton, Eric Whitney
In-Reply-To: <1144353528.5162.190.camel@localhost.localdomain>
On Thu, 2006-04-06 at 15:58 -0400, Lee Schermerhorn wrote:
> 2.6.17-rc1-mm1 hangs during boot on HP rx8620 and dl585 -- both 4 node
> NUMA platforms. Problem is in build_sched_domains() setting up the
> sched_group_nodes[] lists, resulting from patch:
> sched_domain-handle-kmalloc-failure.patch
>
> The referenced patch does not propagate the "next" pointer from the head
> of the list, resulting in a loop between the last 2 groups in the list.
> This causes a tight loop/hang in init_numa_sched_groups_power() because
> 'sg->next' never == 'group_head' when you have > 2 nodes.
Wow. I'm incredibly impressed that you tracked that down. I can't
believe how horribly unintelligible that code is.
I ran into the same freeze on a 4-node NUMA-Q. Your patch fixed it.
Is there any good reason that sched domains has to roll its own linked
lists? Why not use list_heads? Seems like it would avoid crappy
problems like this.
-- Dave
^ permalink raw reply
* Re: [Xenomai-core] Frozen timer IRQ - now traced with kgdb :)
From: Jan Kiszka @ 2006-04-07 18:00 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-core
In-Reply-To: <443695BB.6030502@domain.hid>
[-- Attachment #1.1: Type: text/plain, Size: 2000 bytes --]
Philippe Gerum wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>
>>>
>>> BTW, that trace hacking reminds me that we should really think about
>>> making a kernel debugger run. I recently noticed that latest kgdb
>>> applied with a single failing hunk on top of ipipe (2.6.15, x86). Maybe
>>> it is just about making kgdb's irq-locks ipipe-aware and bypassing the
>>> ipipe for int3 and the serial IRQ (so that ipipe can be debugged as
>>> well) and catching the relevant exceptions. Hmm, the debugger seems to
>>> get initialised in the "early" stage. Is this before or after ipipe
>>> setup?
>>>
>>
>> It depends. If "kgdbwait" is set in the bootargs to halt the kernel
>> waiting for the remote GDB to connect to the target, kgdb starts
>> before the ipipe. Otherwise, it's a late init, and kgdb starts after
>> the ipipe is fully initialized.
>>
>
> Basically, kgdb could start before the i-pipe as soon as a breakpoint is
> hit before the latter is enabled in init/main.c.
>
Yep, I dug deeper meanwhile and also came across this.
I already have a trivial hack running here. The most tricky part for me
was to learn quilt, but now I start to love it :). Here is a snapshot
series for 2.6.15.5:
<kgdb series from CVS>
prepare-ipipe-x86.patch
adeos-ipipe-2.6.15-i386-1.2-01.patch
kgdb-ipipe-x86.patch
I'm currently wondering if it makes sense to register a kgdb domain and
"officially" capture all involved IRQs and events. So far the serial
line IRQ is hard-coded (should be retrieved from some internal kgdb
structure later). Anyway, it seems to work quite well, I'm currently
stepping through a network IRQ at ipipe-level.
While playing with this tool a bit, displaying the the ipipe structures,
and thinking about the original problem again, I wondered what could
cause a temporary (as I think to found out now) stalled xeno domain
without locking up the system? Some irq-lock leaks at driver level (i.e.
inside our own code)?
Jan
[-- Attachment #1.2: kgdb-ipipe-x86.patch --]
[-- Type: text/plain, Size: 3997 bytes --]
Index: linux-2.6.15.5/arch/i386/kernel/entry.S
===================================================================
--- linux-2.6.15.5.orig/arch/i386/kernel/entry.S 2006-04-07 16:53:39.000000000 +0200
+++ linux-2.6.15.5/arch/i386/kernel/entry.S 2006-04-07 16:53:40.000000000 +0200
@@ -194,7 +194,7 @@
.previous
-ENTRY(ret_from_fork)
+KPROBE_ENTRY(ret_from_fork)
STI_COND_HW
pushl %eax
call schedule_tail
@@ -582,7 +582,7 @@
PUSH_XCODE(do_simd_coprocessor_error)
jmp error_code
-ENTRY(device_not_available)
+KPROBE_ENTRY(device_not_available)
pushl $-1 # mark this as an int
SAVE_ALL
DIVERT_EXCEPTION(device_not_available)
@@ -767,7 +767,7 @@
jmp error_code
#endif
-ENTRY(spurious_interrupt_bug)
+KPROBE_ENTRY(spurious_interrupt_bug)
pushl $0
PUSH_XCODE(do_spurious_interrupt_bug)
jmp error_code
Index: linux-2.6.15.5/kernel/kgdb.c
===================================================================
--- linux-2.6.15.5.orig/kernel/kgdb.c 2006-04-07 16:30:51.000000000 +0200
+++ linux-2.6.15.5/kernel/kgdb.c 2006-04-07 16:57:35.000000000 +0200
@@ -740,7 +740,7 @@
unsigned long flags;
int processor;
- local_irq_save(flags);
+ local_irq_save_hw(flags);
processor = smp_processor_id();
kgdb_info[processor].debuggerinfo = regs;
kgdb_info[processor].task = current;
@@ -770,7 +770,7 @@
/* Signal the master processor that we are done */
atomic_set(&procindebug[processor], 0);
spin_unlock(&slavecpulocks[processor]);
- local_irq_restore(flags);
+ local_irq_restore_hw(flags);
}
#endif
@@ -1033,7 +1033,7 @@
* Interrupts will be restored by the 'trap return' code, except when
* single stepping.
*/
- local_irq_save(flags);
+ local_irq_save_hw(flags);
/* Hold debugger_active */
procid = smp_processor_id();
@@ -1056,7 +1056,7 @@
if (atomic_read(&cpu_doing_single_step) != -1 &&
atomic_read(&cpu_doing_single_step) != procid) {
atomic_set(&debugger_active, 0);
- local_irq_restore(flags);
+ local_irq_restore_hw(flags);
goto acquirelock;
}
@@ -1556,7 +1556,7 @@
kgdb_restore:
/* Free debugger_active */
atomic_set(&debugger_active, 0);
- local_irq_restore(flags);
+ local_irq_restore_hw(flags);
return error;
}
@@ -1925,9 +1925,9 @@
if (!kgdb_connected || atomic_read(&debugger_active) != 0)
return 0;
if ((code == SYS_RESTART) || (code == SYS_HALT) || (code == SYS_POWER_OFF)){
- local_irq_save(flags);
+ local_irq_save_hw(flags);
put_packet("X00");
- local_irq_restore(flags);
+ local_irq_restore_hw(flags);
}
return NOTIFY_DONE;
}
@@ -1942,9 +1942,9 @@
if (!kgdb_connected || atomic_read(&debugger_active) != 0)
return;
- local_irq_save(flags);
+ local_irq_save_hw(flags);
kgdb_msg_write(s, count);
- local_irq_restore(flags);
+ local_irq_restore_hw(flags);
}
static struct console kgdbcons = {
Index: linux-2.6.15.5/arch/i386/kernel/ipipe-root.c
===================================================================
--- linux-2.6.15.5.orig/arch/i386/kernel/ipipe-root.c 2006-04-07 16:53:39.000000000 +0200
+++ linux-2.6.15.5/arch/i386/kernel/ipipe-root.c 2006-04-07 17:48:00.000000000 +0200
@@ -111,6 +111,15 @@
#endif /* CONFIG_X86_LOCAL_APIC */
+#ifdef CONFIG_KGDB
+static struct ipipe_domain kgdb_domain;
+
+static void kgdb_domain_entry(void)
+{
+
+}
+#endif /* CONFIG_KGDB */
+
/* __ipipe_enable_pipeline() -- We are running on the boot CPU, hw
interrupts are off, and secondary CPUs are still lost in space. */
@@ -248,6 +257,10 @@
ipipe_root_domain->irqs[IPIPE_SERVICE_IPI2].control &= ~IPIPE_SYSTEM_MASK;
ipipe_root_domain->irqs[IPIPE_SERVICE_IPI3].control &= ~IPIPE_SYSTEM_MASK;
#endif /* CONFIG_X86_LOCAL_APIC */
+
+#ifdef CONFIG_KGDB
+ ipipe_control_irq(4, 0, IPIPE_HANDLE_MASK|IPIPE_STICKY_MASK|IPIPE_SYSTEM_MASK);
+#endif /* CONFIG_KGDB */
}
static inline void __fixup_if(struct pt_regs *regs)
[-- Attachment #1.3: prepare-ipipe-x86.patch --]
[-- Type: text/plain, Size: 838 bytes --]
Index: linux-2.6.15.5/arch/i386/kernel/entry.S
===================================================================
--- linux-2.6.15.5.orig/arch/i386/kernel/entry.S 2006-04-07 16:42:54.000000000 +0200
+++ linux-2.6.15.5/arch/i386/kernel/entry.S 2006-04-07 16:47:23.000000000 +0200
@@ -123,7 +123,7 @@
.previous
-KPROBE_ENTRY(ret_from_fork)
+ENTRY(ret_from_fork)
pushl %eax
call schedule_tail
GET_THREAD_INFO(%ebp)
@@ -470,7 +470,7 @@
pushl $do_simd_coprocessor_error
jmp error_code
-KPROBE_ENTRY(device_not_available)
+ENTRY(device_not_available)
pushl $-1 # mark this as an int
SAVE_ALL
movl %cr0, %eax
@@ -652,7 +652,7 @@
jmp error_code
#endif
-KPROBE_ENTRY(spurious_interrupt_bug)
+ENTRY(spurious_interrupt_bug)
pushl $0
pushl $do_spurious_interrupt_bug
jmp error_code
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply
* checking write_cached_data return status inside _release and _flush?
From: Massimiliano Galanti @ 2006-04-07 18:03 UTC (permalink / raw)
To: linux-mtd
hi!
i experienced some corruption of data on flash memories i am using, and
discovered that this is related to these functions in mtdblock.c:
static int mtdblock_release(struct mtd_blktrans_dev *mbd)
static int mtdblock_flush(struct mtd_blktrans_dev *dev)
not checking the return value of the function:
write_cached_data(mtdblk)
i fixed that by checking the return value inside a while cycle but is
there any particular reason the original code is written that way?
Thank you.
--
Massimiliano Galanti
-IM-----------------------
MSN: viperzed@hotmail.com
Yahoo: massimilianogalanti
ICQ: 227544335
Skype: massimilianogalanti
--------------------------
^ permalink raw reply
* Re: [PATCH 0/5] clocksource patches
From: john stultz @ 2006-04-07 17:57 UTC (permalink / raw)
To: Roman Zippel; +Cc: linux-kernel, Andrew Morton
In-Reply-To: <Pine.LNX.4.64.0604031431220.25825@scrub.home>
On Mon, 2006-04-03 at 21:54 +0200, Roman Zippel wrote:
> Some more notes about the patches:
Hey Roman,
I'll reply to more specifics to the patches themselves, but I'll try to
get some general clarifications here.
> 1. generic clocksource updates:
> The most important change is probably clocksource_get_nsec_offset(), it
> returns the nsec part of the realtime clock and is adjusted once a second.
> Other time services can be built on top of this and also only have to be
> updated once a second via second_overflow(). I changed the return value to
> an unsigned long which gives us a 3 second window, which should be more
> than enough (anyone not allowing the timer interrupt for that long gets
> what he is asking for). This function should become clocksource specific
> so arch/clocks can optimize this function themselves (e.g. changing
> resolution, making some parameters constant). The generic clocksource
> currently still deals a bit too much with cycles, more of this should be
> moved into the clocksource drivers (using library functions).
I'm still not convinced for the need of clocksource specific
get_nsec_offset() functions. I really want to limit the clocksource
structure to be as stateless as possible and to only provide an
abstraction to the hardware counter below.
But clearly you are pretty concerned about it, so maybe could you share
the case you have in mind where it would be necessary?
> I'm also still interested in opinions about different possibilities to
> organize the clocksource infrastructure (although I'd more appreciate
> pro/con arguments than outright rejections). One possibility here would be
> to also shorten the function names a bit (clocksource_ is a lot to type :)
> ), cs_... or clock_... would IMO work too.
I *much* prefer the clarity of clocksource over the wear and tear typing
it might take on my fingers.
> 2. periodic clocksource update
> I updated the error adjustment algorithm to be more robust and optimized
> it a bit for the more common cases. It does everything in 64bit right now,
> which is fine for 64bit archs and it allows resolutions of less then
> 1nsec, but as long as e.g. gettimeofday() takes longer than 1nsec that's
> a little wasteful and nobody will see a difference if we "restrict" the
> resolution to 1nsec, which would allow to keep parts of it in 32bit.
>
> I also kept it separate from the do_timer() callback and simply created a
> new callback function, which archs can use. This makes it less likely to
> break any existing setup and even allows to coexists both methods until
> archs have been completely converted.
One of the reasons I did the significant rework of the TOD patches was
so that we could generically introduce the clocksource abstraction first
(using jiffies) for all arches. I feel this provides a much smoother
transition to the generic timekeeping code (and greatly reduces the
amount of CONFIG_GENERIC_TIME specific code), so I'm not sure I
understand why you want to go back to separate do_timer() functions.
I guess what I'm asking for is what was wrong with the way my code did
it? What breakage are you concerned about?
> Another general comment from an arch/driver specific perspective: right
> now everything is rather concentrated on getting the time, but AFAICT it's
> more common that the subsystem which is used to read the time is also used
> as timer (i.e. for the scheduler tick), this means the clocksource driver
> should also include the interrupt setup. Consequently this means the
> update callback isn't sufficient anymore and we need at least something
> like start/stop callbacks. This also means the jiffie clocksource becomes
> basically obsolete, since every arch already needs at least a basic
> clocksource to provide the scheduler tick (which is setup via
> time_init()).
> i386 is currently rather hardcoded to use the i8253 timer, but AFAIK it
> would be desirable to e.g. use HPET for that (especially for hrtimer).
> Something like TSC should internally use another clocksource to provide
> the timer interrupt. Anyway, i386 is quite a mess here right now and I can
> understand that you wanted to stay away from it with the generic
> gettimeofday infrastructure. :-)
> This is not important right now, but I wanted to mention it, it's IMO
> something to keep in mind for the next steps and what at least I'll
> look out for.
Thomas has already commented on this, and maybe we both misunderstand
what your suggesting here, but I am pretty hesitant to bind the clock
source / hardware interrupt timer code together. The reason for that is
in my experience w/ i386 (and I'll take my lumps for my part in the i386
timekeeping mess) the number of combinations of clock/timers is
something like: PIT/PIT, TSC/PIT, CYCLONE/PIT, ACPIPM/PIT, HPET/PIT,
TSC/HPET, HPET/HPET. And with some of Andi's patches x86-64 patches you
can do them all over /APIC.
My goal with the clocksources is to take just the counter aspect of any
hardware and export it generically so we can use that inside generic
code. I also would support a similar timer interrupt source abstraction,
like what Thomas has started in his clockevent patches in his hrt
patchset. The hope being we can later freely mix and match
clocksources/clockevents, allowing for some of the features needed for
dynamic ticks and virtualization.
Do these concerns make sense to you? Or was it something else you were
suggesting?
thanks
-john
^ permalink raw reply
* [PATCH] kdump: enable CONFIG_PROC_VMCORE by default
From: Vivek Goyal @ 2006-04-07 17:59 UTC (permalink / raw)
To: linux kernel mailing list, Fastboot mailing list
Cc: Morton Andrew Morton, Theodore Y Tso
o Everybody seems to be using /proc/vmcore as a method to access the kernel
crash dump. Hence probably it makes sense to enable CONFIG_PROC_VMCORE by
default if CONFIG_CRASH_DUMP is selected. This makes kdump configuration
further easier for a user.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
---
fs/Kconfig | 1 +
1 files changed, 1 insertion(+)
diff -puN fs/Kconfig~kdump-enable-config-proc-vmcore-by-default fs/Kconfig
--- linux-2.6.17-rc1-1M/fs/Kconfig~kdump-enable-config-proc-vmcore-by-default 2006-04-07 12:44:29.000000000 -0400
+++ linux-2.6.17-rc1-1M-root/fs/Kconfig 2006-04-07 12:44:29.000000000 -0400
@@ -799,6 +799,7 @@ config PROC_KCORE
config PROC_VMCORE
bool "/proc/vmcore support (EXPERIMENTAL)"
depends on PROC_FS && EXPERIMENTAL && CRASH_DUMP
+ default y
help
Exports the dump image of crashed kernel in ELF format.
_
^ permalink raw reply
* RE: [RFC] Hypercalls from HVM guests
From: Petersson, Mats @ 2006-04-07 17:56 UTC (permalink / raw)
To: Keir Fraser; +Cc: Steve Ofsthun, xen-devel
> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
> Sent: 07 April 2006 18:40
> To: Petersson, Mats
> Cc: Steve Ofsthun; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [RFC] Hypercalls from HVM guests
>
>
> On 7 Apr 2006, at 18:24, Petersson, Mats wrote:
>
> > Good question - the way I'd say is to look at CPUID to see if it's
> > "GeunineIntel" or "AuthenticAMD", but I'm not sure if
> that's the BEST.
> > Of course, this assumes the code is already aware that it's
> in a HVM
> > environment, which I'm not sure if you know that or not at
> the point
> > you need to know if it's AMD or Intel... Of course, if CPUID is
> > intercepted, it may return other things (but it's against
> the "rules"
> > to lie about the brand of the CPU!)
>
> I like the idea of stealing some MSR space for this, and
> doing some initial interaction with the underlying hypervisor
> platform via RDMSR/WRMSR to known MSRs. We could 'read' an
> 'MSR' that would tell us the correct instruction sequence to
> do a hypercall (either directly, or maybe tell us a 'physical
> address' to read the hypercall transport information from --
> then we could have a hypercall transfer page just as we
> already do for paravirtualised guests).
>
> We just need to pick some MSRs that won't get used by Intel
> or AMD in the future. There's quite a lot of addressing space
> to carve up though.
> :-)
I like this idea, it's quirky and neat at the same time...
But isn't this going to be a catch-22 situation? We don't know if we're
virtualized or not, so we can't make hypercalls, and to find out, we
read an unimplemented MSR, which on REAL hardware causes a GP fault (and
probably also in SVM, since the map for SVM capturing MSR read/write
operations is very specific - at least if we use a MSR like 0xb0000000
or such).
Actually, maybe using an unused index for CPUID (e.g. 0xb0000000) would
be better? As that's defined to return all zero's, and not cause any
traps whatever value you use (unless the CPU is so old that it doesn't
support CPUID, of course).
--
Mats
>
> -- Keir
>
>
>
^ permalink raw reply
* Re: How to know when file data has been flushed into disk?
From: Zach Brown @ 2006-04-07 17:54 UTC (permalink / raw)
To: Xin Zhao; +Cc: linux-kernel, linux-fsdevel
In-Reply-To: <4ae3c140604070842x537353c4s9a60706c2a2d25d9@mail.gmail.com>
> If a program access data like this:
>
> 1. open the file
> 2. write a lot of data into this file
You don't say if this is an extending write or overwriting existing file
data. I'm going to assume extending writes so that data=ordered kicks in.
> 3. close the file
> So my questions are:
> 1. How will the file system be notified after all data has been
> flushed into disk?
Look at phase 2 in journal_commit_transaction(). The kjournald thread
issues the writeback of the file data by walking t_sync_datalist and
then waits for the writeback to complete by using wait_on_buffer()
before committing the transaction.
> 2. Unlike data=journal mode, in data=order mode, the data could be
> lost if system crashes when data is being flushed to disk. When system
> reboots, does journal contains the old meta data for undo?
No, ext3 isn't roll-backward. It doesn't store the *old* data in the
journal and undo the change if it fails halfway through. It's
roll-forward. It stores the *new* data in the journal and replays
complete transactions in the journal that weren't moved out to their
final place on disk at the time of the crash.
So if the machine reboots during the writeback phase then the
transaction won't be committed yet and recovery won't replay that
transaction from the journal. From the metadata's point of view the
file extension will never have happened.
> 3. Does sys_close() have to be blocked until all data and metadata
> are committed?
No, and neither does sys_getpid() :)
> to take subsequent operation. However, data flush could be failed. In
> this case, file system seems to mislead the application. Is this true?
No. The application has no grounds for assuming that a successful
close() has synced previous operations to disk. It's simply not part of
the API.
> If so, any solutions?
The application should rely on tools like fsync(), fdatasync(), O_SYNC,
mount -o sync, etc. Whatever suits it best.
- z
^ permalink raw reply
* Re: [PATCH/RFC] libata: turn on the ATAPI DMADIR support per word 62 (revised)
From: Jeff Garzik @ 2006-04-07 17:54 UTC (permalink / raw)
To: albertl; +Cc: linux-ide, Jonathan Benson, Tejun Heo, Carlos Pardo, Doug Maxey
In-Reply-To: <4436431C.8070800@tw.ibm.com>
Albert Lee wrote:
> Turn on the ATAPI DMADIR support if word 62 indicates it.
>
> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
> ---
> (Revised to add mwdma/udma mask of word 62 per Jeff's comments.
> Need more testing once I get the SiI 3811, etc.)
>
> ATAPI DMADIR follow-up patch to turn on the DMADIR support automatically
> by checking identify device word 62. (Thanks for Jeff and Tejun's pointer.)
>
> According to Jonathan's test result, SiI 3611 (the current known bridge that
> requires the ATAPI DMADIR support) doesn't implement word 62. So, the
> atapi_dmadir parameter is preserved to enable the DMA DIR support manually as
> work around.
>
> Patch against upstream (c2a6585296009379e0f4eff39cdcb108b457ebf2).
> For your review, thanks.
I ACK the patch, though like I said, I would like to see this tested
first with some compliant devices.
Jeff
^ permalink raw reply
* Re: Serial console problem with Xen 3.0
From: Stephen C. Tweedie @ 2006-04-07 17:54 UTC (permalink / raw)
To: Michael Paesold; +Cc: Amitayu Das, xen-devel
In-Reply-To: <02de01c65a4b$6d03a400$d801a8c0@zaphod>
Hi,
On Fri, 2006-04-07 at 15:59 +0200, Michael Paesold wrote:
> Me too. Adding "sync_console" at least repaired the console *output*. I
> still have the problem that keyboard input does not reach linux
Serial input seems to have a bad interaction with ACPI plug-n-play.
Appending "pnpacpi=off" to the "module vmlinuz..." grub.conf line should
turn that off, and restore serial input.
--Stephen
^ permalink raw reply
* nice device running linux
From: Harald Dunkel @ 2006-04-07 17:52 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 223 bytes --]
Hi folks,
Have you seen this one?
http://www.iamm.co.kr/eng/product/ntd25/ntd25.php
It seems to be Linux-powered (derived from 2.4.17). ESR is
explicitly mentioned in the firmware :-).
Regards
Harri
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* DRM via bugs?
From: John Richard Moser @ 2006-04-07 17:49 UTC (permalink / raw)
To: linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm not sure if this is mainline or ubuntu kernel and can't seem to find
any info on this (i.e. if it's known, fixed in 2.6.16, etc), so here's
some massive oopsen from my Athlon 64..
Feb 23 07:52:06 localhost kernel: [33790.181014] Oops: 0000 [1] PREEMPT SMP
Feb 23 07:52:06 localhost kernel: [33790.181017] CPU 0
Feb 23 07:52:06 localhost kernel: [33790.181020] Modules linked in:
af_packet nls_utf8 usb_storage rfcomm l2cap bluetooth powernow_k8
cpufreq_userspace cpufreq_stats freq_table cpufreq_powersave
cpufreq_ondemand cpufreq_conservative via drm video tc1100_wmi sony_acpi
pcc_acpi hotkey dev_acpi container button acpi_sbs battery i2c_acpi_ec
ac nls_iso8859_1 nls_cp437 vfat fat ext2 dm_mod md_mod sr_mod sbp2
parport_pc lp parport ipv6 psmouse serio_raw snd_emu10k1_synth
snd_emux_synth snd_seq_virmidi snd_seq_midi_emul tsdev snd_seq_dummy
snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq i2c_viapro
snd_emu10k1 snd_rawmidi snd_ac97_codec
snd_ac97_bus usblp snd_pcm_oss snd_mixer_oss i2c_core pcspkr rtc
ohci1394 ieee1394 snd_pcm snd_seq_device snd_timer snd_page_alloc
snd_util_mem snd_hwdep snd 8139cp 8139too mii soundcore shpchp usbhid
pci_hotplug sg evdev xfs exportfs ehci_hcd uhci_hcd usbcore ide_generic
ide_cd cdrom generic via82cxxx sd_mod sata_via
libata scsi_mod thermal processor fan capability commoncap vga16fb cf
Feb 23 07:52:06 localhost kernel: copyarea vgastate cfbimgblt
cfbfillrect fbcon
tileblit font bitblit softcursor
Feb 23 07:52:06 localhost kernel: [33790.181069] Pid: 4204, comm: Xorg
Not tainted 2.6.15-15-amd64-k8 #1
Feb 23 07:52:06 localhost kernel: [33790.181072] RIP:
0010:[_end+134037098/2132357120] <ffffffff88440e6a>{:via:via_mmFreeMem+10}
Feb 23 07:52:06 localhost kernel: [33790.181081] RSP:
0018:ffff8100348fddf8 EFLAGS: 00010202
Feb 23 07:52:06 localhost kernel: [33790.181085] RAX: 0000000000000001
RBX: ffff8100382e0000 RCX: 0000000000000000
Feb 23 07:52:06 localhost kernel: [33790.181088] RDX: 0000000000000001
RSI: ffff8100348fde18 RDI: 0000000005fdc280
Feb 23 07:52:06 localhost kernel: [33790.181091] RBP: 0000000000000002
R08: 0000000000000001 R09: 0000000000000001
Feb 23 07:52:06 localhost kernel: [33790.181094] R10: 0000000000000000
R11: 0000000000000000 R12: 0000000000000001
Feb 23 07:52:06 localhost kernel: [33790.181099] R13: ffff8100348fde18
R14: ffff810035238800 R15: ffff810031bc0000
Feb 23 07:52:06 localhost kernel: [33790.181103] FS:
00002aaaab7acce0(0000) GS:ffffffff80426800(0000) knlGS:0000000000000000
Feb 23 07:52:06 localhost kernel: [33790.181107] CS: 0010 DS: 0000 ES:
0000 CR0: 000000008005003b
Feb 23 07:52:06 localhost kernel: [33790.181110] CR2: 0000000005fdc288
CR3: 0000000035625000 CR4: 00000000000006e0
Feb 23 07:52:06 localhost kernel: [33790.181115] Process Xorg (pid:
4204, threadinfo ffff8100348fc000, task ffff81003ab688e0)
Feb 23 07:52:06 localhost kernel: [33790.181117] Stack: ffff8100382e0000
ffffffff8844151a 0000000100000000 ffff81002b346688
Feb 23 07:52:06 localhost kernel: [33790.181126] 0000000005fdc280
ffff81003bcdb4c0 ffff810035238800 0000000000000021
Feb 23 07:52:06 localhost kernel: [33790.181132] ffff81003bcdb4c0
ffff81003523884c
Feb 23 07:52:06 localhost kernel: [33790.181136] Call
Trace:<ffffffff8844151a>{:via:via_final_context+202}
<ffffffff8842a5a0>{:drm:drm_rmctx+128}
Feb 23 07:52:06 localhost kernel: [33790.181191]
<ffffffff801ab64c>{mntput_no_expire+28} <ffffffff8842a520>{:drm:drm_rmctx+0}
Feb 23 07:52:06 localhost kernel: [33790.181215]
<ffffffff8842b365>{:drm:drm_ioctl+405} <ffffffff801a1a09>{do_ioctl+105}
Feb 23 07:52:06 localhost kernel: [33790.181240]
<ffffffff801a1ceb>{vfs_ioctl+683} <ffffffff801ab64c>{mntput_no_expire+28}
Feb 23 07:52:06 localhost kernel: [33790.181251]
<ffffffff801a1d8c>{sys_ioctl+108} <ffffffff8010fede>{system_call+126}
Feb 23 07:52:06 localhost kernel: [33790.181268]
Feb 23 07:52:06 localhost kernel: [33790.181281]
Feb 23 07:52:06 localhost kernel: [33790.181282] Code: 48 8b 4f 08 48 85
c9 0f 84 99 00 00 00 e9 9b 00 00 00 66 66
Feb 23 07:52:06 localhost kernel: [33790.181291] RIP
<ffffffff88440e6a>{:via:via_mmFreeMem+10} RSP <ffff8100348fddf8>
Feb 23 07:52:06 localhost kernel: [33790.181300] CR2: 0000000005fdc288
Feb 23 07:52:06 localhost kernel: [33790.181303] <1>Unable to handle
kernel paging request at 0000000005fdc288 RIP:
Feb 23 07:52:06 localhost kernel: [33790.187430]
<ffffffff88440e6a>{:via:via_mmFreeMem+10}
Feb 23 07:52:06 localhost kernel: [33790.187444] PGD 39181067 PUD
39182067 PMD 0
Something else that happened as well:
[ 1378.035582] agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
[ 1378.035596] agpgart: Xorg tried to set rate=x12. Setting to AGP3 x8 mode.
[ 1378.035601] agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
[ 1378.035640] agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
[ 1378.252992] irq 201: nobody cared (try booting with the "irqpoll" option)
[ 1378.252998]
[ 1378.252999] Call Trace: <IRQ> <ffffffff80165aa5>{__report_bad_irq+53}
<ffffffff80165d1a>{note_interrupt+538}
[ 1378.253030] <ffffffff80165407>{__do_IRQ+215}
<ffffffff8011300f>{do_IRQ+47}
[ 1378.253052] <ffffffff80142af0>{ksoftirqd+0}
<ffffffff80110480>{ret_from_intr+0}
[ 1378.253061] <EOI> <ffffffff8030fd62>{thread_return+82}
<ffffffff8010e720>{default_idle+0}
[ 1378.253078] <ffffffff8010e758>{default_idle+56}
<ffffffff8010e846>{cpu_idle+150}
[ 1378.253090] <ffffffff80439895>{start_kernel+485}
<ffffffff80439286>{_sinittext+646}
[ 1378.253102]
[ 1378.253107] handlers:
[ 1378.253109] [<ffffffff8846c430>] (via_driver_irq_handler+0x0/0x170 [via])
[ 1378.253120] Disabling IRQ #201
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Evil alien overlord from Blasto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRDamCws1xW0HCTEFAQJI4BAAk8TcxM0WDcT0MD/tcz5X9mH/dRIYykeA
tu/fM4dHFVKE+URLw5kjlokP7B7GRK7qvvmmJhV0EbbBSU2eEMIxbEpbaqmuQOa0
fRMOdegc+uWmUDxqOBLp7Iz4G9rC/PxkEoo2uwBiEUEw3aq/nNylHx4kDANkmTQj
0nDUWXgwefmippnsoUiRXpAP/3ttaRSpnaxfdKi0VAeXRw4t632EP6RI2RV57d4Y
CobyujHzMtaZfO5S3WtnAJzCH9UWR+YJ1VUgjG01ndzy3KYC82irvXDQ2R9bnue6
LNwAxJH3Nm1SMdO8d21muo8P3ND6DlCtZiHe0YQzMTxaRjAvhJKDXePdJa8XQT73
ogyJ2cZhnJGLvWlNc/zvqnk/3KwH+6GIv15TmDHyEIounYRXDoYiutxBFWqVfUE7
MJ3oIVUbyZTNaSvYaw9ailewMBQS44bP8j5e53Ulh6a3TLKIcmpmLSfTG2oKSILd
T6KzGP3RDPd69vYZk9Jzyt4KWHaI786edDaNva0FrzxBQ53+a6atyEgdugP3zZEn
3Uq9eFPReDrslawODOJRgDr/9IKSNxLebRcPExxrS/PZPIDmVDVcfk9sUeSmHfq7
JqDi6tHyhw1ULh902sW86783sl/migRbxYc/qi1l7RKJ7hdtAtxfT7aS2d8dKIaJ
YJptBx7ONJM=
=cC5h
-----END PGP SIGNATURE-----
^ permalink raw reply
* [ALSA - driver 0001995]: Master and PCM control missing
From: bugtrack @ 2006-04-07 17:47 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1995>
======================================================================
Reported By: baja
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1995
Category: CORE - control
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution:
Kernel Version:
======================================================================
Date Submitted: 04-03-2006 06:13 CEST
Last Modified: 04-07-2006 19:47 CEST
======================================================================
Summary: Master and PCM control missing
Description:
1.0.11rc3 had the PCM control but the Master control was missing. rc4 now
has both the PCM and the Master volume control missing.
Drivers loaded:
$ lsmod | grep snd
snd_seq_dummy 3396 0
snd_seq_oss 34240 0
snd_seq_midi_event 7232 1 snd_seq_oss
snd_seq 54528 5
snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device 7952 3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss 42016 0
snd_mixer_oss 16320 1 snd_pcm_oss
snd_hda_intel 16028 1
snd_hda_codec 166536 1 snd_hda_intel
snd_pcm 88396 3 snd_pcm_oss,snd_hda_intel,snd_hda_codec
snd_timer 22600 2 snd_seq,snd_pcm
snd 59072 12
snd_seq_dummy,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer
snd_page_alloc 9360 2 snd_hda_intel,snd_pcm
Controls reported by alsa
$ amixer controls
numid=11,iface=MIXER,name='Headphone Playback Switch'
numid=4,iface=MIXER,name='Surround Playback Switch'
numid=3,iface=MIXER,name='Surround Playback Volume'
numid=7,iface=MIXER,name='Center Playback Switch'
numid=5,iface=MIXER,name='Center Playback Volume'
numid=8,iface=MIXER,name='LFE Playback Switch'
numid=6,iface=MIXER,name='LFE Playback Volume'
numid=17,iface=MIXER,name='Line Playback Switch'
numid=16,iface=MIXER,name='Line Playback Volume'
numid=19,iface=MIXER,name='CD Playback Switch'
numid=18,iface=MIXER,name='CD Playback Volume'
numid=13,iface=MIXER,name='Mic Playback Switch'
numid=12,iface=MIXER,name='Mic Playback Volume'
numid=21,iface=MIXER,name='Capture Switch'
numid=23,iface=MIXER,name='Capture Switch',index=1
numid=25,iface=MIXER,name='Capture Switch',index=2
numid=20,iface=MIXER,name='Capture Volume'
numid=22,iface=MIXER,name='Capture Volume',index=1
numid=24,iface=MIXER,name='Capture Volume',index=2
numid=29,iface=MIXER,name='IEC958 Playback Con Mask'
numid=30,iface=MIXER,name='IEC958 Playback Pro Mask'
numid=31,iface=MIXER,name='IEC958 Playback Default'
numid=32,iface=MIXER,name='IEC958 Playback Switch'
numid=34,iface=MIXER,name='IEC958 Capture Default'
numid=33,iface=MIXER,name='IEC958 Capture Switch'
numid=15,iface=MIXER,name='Front Mic Playback Switch'
numid=14,iface=MIXER,name='Front Mic Playback Volume'
numid=2,iface=MIXER,name='Front Playback Switch'
numid=1,iface=MIXER,name='Front Playback Volume'
numid=26,iface=MIXER,name='Input Source'
numid=27,iface=MIXER,name='Input Source',index=1
numid=28,iface=MIXER,name='Input Source',index=2
numid=10,iface=MIXER,name='Side Playback Switch'
numid=9,iface=MIXER,name='Side Playback Volume'
Assuming that that this is an issue since applications look for this
"generic" volume controls.
Thanks
Baja
======================================================================
----------------------------------------------------------------------
baja - 04-03-06 06:17
----------------------------------------------------------------------
By the way... I am using a MSi mother board:
MSI K8NGM2-FID Socket 939 NVIDIA GeForce 6150
ls pci reports:
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev
a2)
with snd_hda_intel...
----------------------------------------------------------------------
tiwai - 04-07-06 19:47
----------------------------------------------------------------------
The most important information is missing: Please upload
/proc/asound/card0/codec#* files.
Possibly there is no master volume or PCM control on your chip indeed, but
only volume for each output jack, Front, Surround, CLFE.
Issue History
Date Modified Username Field Change
======================================================================
04-03-06 06:13 baja New Issue
04-03-06 06:17 baja Note Added: 0009084
04-07-06 19:47 tiwai Note Added: 0009154
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: Detecting deadlocks with hypervisor..
From: Anthony Liguori @ 2006-04-07 17:45 UTC (permalink / raw)
To: Keir Fraser; +Cc: rthelen, T S, Xen-devel, ewan, edwin.zhai
In-Reply-To: <10ef69c2c2859e3da371d0495a08625f@cl.cam.ac.uk>
Keir Fraser wrote:
>
> On 7 Apr 2006, at 18:11, T S wrote:
>
>> We took a look at the xc_linux_save() function ... and what we see is
>> that
>> the canonicalize action is actually done by the Dom-0 (and not by the
>> Dom-U);
>> Dom-0 is able to do this because it is able to access the page tables
>> of Dom-U
>> as well as the pfn2mfn list of the Dom-U. Based on this, we think the
>> Dom-0 can
>> actually save the 'context' of the deadlocked Dom-U. Please correct
>> me if this
>> claim is wrong.
>>
>> Also, given that Dom-0 can access the page tables and other
>> structures of the deadlocked guest,
>> can one of you be able to tell me what changes I need to do to
>> xm_linux_save( ) (and other related functions) to save the state of
>> the deadlocked guest without doing any handshake with the guest OS ?
>
> You can get at the consistent state of a guest by pausing it and then
> reading its state. However, the reason for the handshake is to ensure
> that the guest is not currently accessing pagetables or doing other
> critical operations. If it were then we could not safely translate its
> memory page addresses as it could have those addresses in places like
> its kernel stacks or register contexts, where they would not get
> translated and would cause a crash on restore.
I should add that this is a problem specific to writable page tables as
the guest must be aware of the actual physical pages that it is using.
With a VT/SVM guest or on an architecture that doesn't use writable page
tables, this isn't an issue.
Regards,
Anthony Liguoi
> -- Keir
>
^ permalink raw reply
* [ALSA - driver 0001495]: nForce2 IEC958 output is working when IEC958 control is muted.
From: bugtrack @ 2006-04-07 17:45 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1495>
======================================================================
Reported By: damscot
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1495
Category: PCI - intel8x0
Reproducibility: always
Severity: minor
Priority: normal
Status: new
Distribution: Gentoo
Kernel Version: 2.6.12-gentoo-r1
======================================================================
Date Submitted: 10-24-2005 00:16 CEST
Last Modified: 04-07-2006 19:45 CEST
======================================================================
Summary: nForce2 IEC958 output is working when IEC958 control
is muted.
Description:
Good evening,
I'am using my MSI MEGA 180 under linux.
I'am using ALSA 1.0.9 Embedded inside the Linux ALSA kernel system.
***************************
*** USEFULL INFORMATION ***
***************************
<< lspci
0000:00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97
Audio Controler (MCP) (rev a1)
Subsystem: Micro-Star International Co., Ltd.: Unknown device
7960
Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 22
I/O ports at d400 [size=256]
I/O ports at d800 [size=128]
Memory at e1087000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
<< cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.9rc2 (Thu Mar 24
10:33:39 2005 UTC).
<< cat /proc/asound/cards
0 [nForce2 ]: NFORCE - NVidia nForce2
NVidia nForce2 with ALC650F at 0xe1087000, irq 22
1 [Modem ]: ICH-MODEM - NVidia nForce2 Modem
NVidia nForce2 Modem at 0xe1080000, irq 22
<< cat /proc/asound/devices
18: [0- 2]: digital audio playback
25: [0- 1]: digital audio capture
16: [0- 0]: digital audio playback
24: [0- 0]: digital audio capture
0: [0- 0]: ctl
1: : sequencer
33: : timer
48: [1- 0]: digital audio playback
56: [1- 0]: digital audio capture
32: [1- 0]: ctl
<< cat /proc/asound/pcm
00-00: Intel ICH : NVidia nForce2 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : NVidia nForce2 - MIC ADC : capture 1
00-02: Intel ICH - IEC958 : NVidia nForce2 - IEC958 : playback 1
01-00: Intel ICH - Modem : NVidia nForce2 Modem - Modem : playback 1 :
capture 1
<< cat /proc/asound/card0/codec97#0/ac97#0-0
0-0/0: Realtek ALC650F
Capabilities :
DAC resolution : 20-bit
ADC resolution : 18-bit
3D enhancement : Realtek 3D Stereo Enhancement
Current setup
Mic gain : +0dB [+0dB]
POP path : pre 3D
Sim. stereo : off
3D enhancement : on
Loudness : off
Mono output : MIX
Mic select : Mic1
ADC/DAC loopback : off
Double rate slots: 10/11
Extended ID : codec=0 rev=1 LDAC SDAC CDAC DSA=0 SPDIF DRA VRA
Extended status : SPCV LDAC SDAC CDAC SPDIF=10/11 VRA
PCM front DAC : 44100Hz
PCM Surr DAC : 44100Hz
PCM LFE DAC : 44100Hz
PCM ADC : 44100Hz
SPDIF Control : Consumer PCM Copyright Category=0x2 Generation=1
Rate=48kHz
SPDIF In Status : Not Locked
<< amixer | grep -A 5 IEC958
Simple mixer control 'IEC958',0
Capabilities: pswitch pswitch-joined cswitch cswitch-joined
Playback channels: Mono
Capture channels: Mono
Mono: Playback [on] Capture [off]
Simple mixer control 'IEC958 Playback AC97-SPSA',0
Capabilities: volume volume-joined
Playback channels: Mono
Limits: 0 - 3
Mono: 3 [100%]
Simple mixer control 'Analog to IEC958 Output',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [off]
***************************
My SPDIF output is referenced as hw:0,2, the chipset is a nForce2 (then i
use the snd-intel8x0 driver), the AC97 device seems to be a Realtek
ALC650F.
while using a basic application to send samples to the spdif output ex:
<< aplay -f dat -c 2 -D hw:0,2 anybigfile.gz
I need to mute the IEC958 control in order to ear something from my
DTS/Digital decoder/amplifier.
It seems that the control function is inverted. The problem is that all
application, xmms (for each playing file), mplayer, xine try to unmute the
IEC958 control before starting to play. Then, I have to manually mute the
IEC958 control after lauching the media application to ear the sound.
======================================================================
----------------------------------------------------------------------
damscot - 04-03-06 00:57
----------------------------------------------------------------------
The problem is more on ALC650F (AC97 Audio Codec) support rather than a
problem in intel8x0/nforce2 chipset (AC97 Controller). I develop a patch
of the ac97_codec.c (contact: damscot@yahoo.com) file in order to invert
the bit AC97_EA_SPDIF of the AC97_EXTENDED_STATUS register just in case of
ALC650F device. It is probably not the best place to set-up such patch,
but i'am not an expert in alsa development. I hope that an expert will be
able to integrate it in next version of alsa / linux kernel.
Currently the patch as been validated on alsa integrated with linux
2.6.14-gentoo kernel version.
to respond to "fearofcarpet", it seems that IEC958 volume is used to
control which ac97 slots are used to transmit SPDIF data.
----------------------------------------------------------------------
tiwai - 04-07-06 19:45
----------------------------------------------------------------------
What a hell, is the bit inverted?
I remember other ALC650 model works with the normal setting, so it's
likely a problem only on ALC650F.
Anyway, please post a patch instead of .c file.
Issue History
Date Modified Username Field Change
======================================================================
10-24-05 00:16 damscot New Issue
10-24-05 00:16 damscot Distribution => Gentoo
10-24-05 00:16 damscot Kernel Version => 2.6.12-gentoo-r1
01-16-06 17:11 fearofcarpet Note Added: 0007689
04-03-06 00:39 damscot File Added: ac97_codec.c
04-03-06 00:48 damscot Note Added: 0009074
04-03-06 00:51 damscot Note Edited: 0009074
04-03-06 00:57 damscot Note Edited: 0009074
04-07-06 19:45 tiwai Note Added: 0009153
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: Detecting deadlocks with hypervisor..
From: Anthony Liguori @ 2006-04-07 17:41 UTC (permalink / raw)
To: T S; +Cc: rthelen, Xen-devel, ewan, edwin.zhai
In-Reply-To: <BAY108-F4E6955F5CB48CF58AB23CF6C90@phx.gbl>
T S wrote:
>> From: Anthony Liguori <aliguori@us.ibm.com>
>> To: T S <thileepan_@hotmail.com>
>> CC: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] Detecting deadlocks with hypervisor..
>> Date: Fri, 24 Mar 2006 13:24:46 -0600
>>
>> T S wrote:
>>> This may sound a silly question (pardon me because i am relatively
>>> new to linux kernel) .. will it be possible to continue running
>>> reboot.c (or for that matter any kernel thread) when the kernel is
>>> deadlocked ? In Linux, is the kernel a single process or a bunch of
>>> parallelly executing entities? If later, then during a kernel
>>> deadlock (eg: by loading a faulty module that disables interrupts
>>> and do something silly) there can still be some other
>>> processes/threads run, right?
>>
>> Sorry for not making this more clear previously. You cannot restore a
>> dead-locked domain if a normal xm save doesn't work. One thing that
>> makes Xen unique is that guests actually are aware of what physical
>> pages are assigned to them. When one does a save/restore, the guest
>> has to canonicalize all of it's internal references to physical
>> pages. When it's restored, it then remaps it's newly assigned
>> physical pages to all the old places where it needed to know about
>> them for some reason or another.
>
> We took a look at the xc_linux_save() function ... and what we see is
> that
> the canonicalize action is actually done by the Dom-0 (and not by the
> Dom-U);
Take a look at linux-2.6-sparse/drivers/core/reboot.c:__do_suspend().
Canonicalization is done both in Dom-0 and in the guest itself. Dom-0
attempts to do as much of it as it can but as I've said before, it
cannot do all of it.
> Also, given that Dom-0 can access the page tables and other structures
> of the deadlocked guest,
> can one of you be able to tell me what changes I need to do to
> xm_linux_save( ) (and other related functions) to save the state of
> the deadlocked guest without doing any handshake with the guest OS ?
If you want to attempt to futz with the state of a guest while it's
running without the guest cooperating, your best bet is to do as Keir
suggested and pause the domain, make your changes, and then unpause.
Regards,
Anthony Liguori
>
> thanks!
> - T
>
>
>> If the guest isn't responsive when you do a save, then it will never
>> canonicalize itself and there is no way to restore the domain.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>> thanks
>>> TS
>>>
>>>>
>>>> If a suspend completes correctly, Xend will see it (another watch
>>>> will fire),
>>>> and xc_linux_save will be free to complete the save.
>>>>
>>>> > Also, does it seem viable to clone a copy of a deadlocked guest
>>>> OS in the
>>>> > first place?
>>>>
>>>> If you have a byte-for-byte copy of a deadlocked guest, even if you
>>>> could
>>>> suspend it, surely it will be deadlocked when it is resumed. How do
>>>> you
>>>> intend to break the deadlock, and how is it easier to do that from
>>>> outside
>>>> than it is to perform deadlock detection in the guest?
>>>>
>>>> Ewan.
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>>
>>> _________________________________________________________________
>>> Express yourself instantly with MSN Messenger! Download today - it's
>>> FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>
>
> _________________________________________________________________
> Don’t just search. Find. Check out the new MSN Search!
> http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>
^ permalink raw reply
* Re: [RFC] Hypercalls from HVM guests
From: Keir Fraser @ 2006-04-07 17:40 UTC (permalink / raw)
To: Petersson, Mats; +Cc: Steve Ofsthun, xen-devel
In-Reply-To: <907625E08839C4409CE5768403633E0BA7FBCD@sefsexmb1.amd.com>
On 7 Apr 2006, at 18:24, Petersson, Mats wrote:
> Good question - the way I'd say is to look at CPUID to see if it's
> "GeunineIntel" or "AuthenticAMD", but I'm not sure if that's the BEST.
> Of course, this assumes the code is already aware that it's in a HVM
> environment, which I'm not sure if you know that or not at the point
> you
> need to know if it's AMD or Intel... Of course, if CPUID is
> intercepted,
> it may return other things (but it's against the "rules" to lie about
> the brand of the CPU!)
I like the idea of stealing some MSR space for this, and doing some
initial interaction with the underlying hypervisor platform via
RDMSR/WRMSR to known MSRs. We could 'read' an 'MSR' that would tell us
the correct instruction sequence to do a hypercall (either directly, or
maybe tell us a 'physical address' to read the hypercall transport
information from -- then we could have a hypercall transfer page just
as we already do for paravirtualised guests).
We just need to pick some MSRs that won't get used by Intel or AMD in
the future. There's quite a lot of addressing space to carve up though.
:-)
-- Keir
^ permalink raw reply
* MAX_INST_LEN?
From: Petersson, Mats @ 2006-04-07 17:37 UTC (permalink / raw)
To: Xen-devel
In xen/include/asm-x86/hvm/io.h there is a definition for MAX_INST_LEN,
which is currently defined to 32.
The x86 spec says that any instruction longer than 15 bytes is invalid
(The processor gives General Protection fault if the instruction is
longer than 15 bytes - something that can only be achieved with
redundant prefixing).
So, my question is: Is there ANY OTHER reason why this shouldn't be 15
(or possibly 16 if you want to have a nice even 2^n number)?
By the way, I don't see any particular problem[1] it being 32, I just
noticed it when I started printing my buffer for the instruction when
trying to figure out if I was decoding something correctly, and I
expected to get a short line of bytes, but it overflowed the edge of my
screen by some fair amount - since it was 32 bytes, rather than my
expectation of 15-16 bytes.
Of course, there is a minor curiosity in that the svm.c uses a different
constant, MAX_INST_SIZE for ONE case of copying code from the guest.
This constant is 15. Every other piece of code copying instructions is
using the MAX_INST_LEN...
[1]It would of course have some minor performance impact (especially
since it's also filled with zero's before we copy the code in - and then
check that we filled the entire buffer ;-) ), but I think there's plenty
of other things to performance enhance before we start saving bytes
being copied from the guest when analyzing instructions...
--
Mats
^ permalink raw reply
* [PATCH] initramfs: CPIO unpacking fix
From: H. Peter Anvin @ 2006-04-07 17:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Kernel Mailing List, klibc, Al Viro, hpa, miltonm
In-Reply-To: <20060217160621.99b0ffd4.mikey@neuling.org>
Unlink files, symlinks, FIFOs, devices etc. (except directories) before
writing them when extracting CPIOs. This stops weird behaviour like:
1) writing through symlinks created in earlier CPIOs. eg foo->bar in
the first CPIO. Having foo as a non-link in a subsequent CPIO,
results in bar being written and foo remaining as a symlink.
2) if the first version of file foo is larger than foo in a
subsequent CPIO, we end up with a mix of the two. ie. neither
the first or second version of /foo.
3) special files like devices, fifo etc. can't be overwritten in
subsequent CPIOS.
With this, the kernel will more closely replicate
for i in *.cpio; do cpio --extract --unconditional < $i ; done
This is a change but it's regarded as fixing broken functionality.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
init/initramfs.c | 3 +++
1 files changed, 3 insertions(+)
Index: linux-2.6.15/init/initramfs.c
===================================================================
--- linux-2.6.15.orig/init/initramfs.c
+++ linux-2.6.15/init/initramfs.c
@@ -249,6 +249,7 @@ static int __init do_name(void)
if (dry_run)
return 0;
if (S_ISREG(mode)) {
+ sys_unlink(collected);
if (maybe_link() >= 0) {
wfd = sys_open(collected, O_WRONLY|O_CREAT, mode);
if (wfd >= 0) {
@@ -263,6 +264,7 @@ static int __init do_name(void)
sys_chmod(collected, mode);
} else if (S_ISBLK(mode) || S_ISCHR(mode) ||
S_ISFIFO(mode) || S_ISSOCK(mode)) {
+ sys_unlink(collected);
if (maybe_link() == 0) {
sys_mknod(collected, mode, rdev);
sys_chown(collected, uid, gid);
@@ -291,6 +293,7 @@ static int __init do_copy(void)
static int __init do_symlink(void)
{
collected[N_ALIGN(name_len) + body_len] = '\0';
+ sys_unlink(collected);
sys_symlink(collected + N_ALIGN(name_len), collected);
sys_lchown(collected, uid, gid);
state = SkipIt;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.