* Re: [Qemu-devel] QEMU 0.8.1
From: Natalia Portillo @ 2006-05-05 11:33 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <445B2A0B.7020501@gmx.de>
That's good.
Then someone should create drivers for the OSes that doesn't include
USB tablet support and will be great.
El 05/05/2006, a las 12:33, Oliver Gerlich escribió:
> Natalia Portillo wrote:
>> That requires a driver in guest side that communicates with qemu.
>> VMWare and VirtualPC does this but requires a driver in the guest
>> side, so in unsupported systems you still have to click to grab.
>
> Just as a side note, the USB tablet support makes this quite easy
> at least on Win2k - it already has the required driver, so for me
> it was enough to add -usbdevice tablet to the command line to have
> the mouse cursor automatically grabbed/ungrabbed (it seems that the
> behaviour of Ctrl+Alt changed a bit, but one gets used to it).
>
> Thanks to Brad and Anthony for making that possible :D
>
> Regards,
> Oliver
>
>> El 05/05/2006, a las 8:57, Christian MICHON escribió:
>>> it works. Side effect: after the first ungrab, I can't see the host
>>> pointer over the SDL windows.
>>>
>>> Yet, it's nothing as compared to the invisible wall.
>>> I know nothing about most qemu internals, but would it be
>>> possible to make it like vmw*re, ie the mouse is automagically
>>> grabbed/ungrabbed whenever you reach the limits of the
>>> SDL window ?
>>>
>>> On 5/5/06, Anthony Liguori <aliguori@us.ibm.com> wrote:
>>>
>>>> Thomas Han wrote:
>>>> > Hi,
>>>> >
>>>> > For what it's worth. I have also seen this "invisible wall"
>>>> problem
>>>> > with my mouse for a few weeks off the CVS build too.
>>>>
>>>> Can you try out the following patch. *grumbles about SDL's
>>>> brokenness*
>>>>
>>>> Regards,
>>>>
>>>> Anthony Liguori
>>>
>>>
>>> --
>>> Christian
>>>
>>>
>>> _______________________________________________
>>> Qemu-devel mailing list
>>> Qemu-devel@nongnu.org
>>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
^ permalink raw reply
* lunch atty.
From: Lawrence Vickers @ 2006-05-05 10:51 UTC (permalink / raw)
To: nfs
[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #1.2: Type: text/html, Size: 421 bytes --]
[-- Attachment #2: relic.gif --]
[-- Type: image/gif, Size: 40596 bytes --]
^ permalink raw reply
* [PATCH, updated] fix x86 microcode driver handling of multiple matching revisions
From: Jan Beulich @ 2006-05-05 11:26 UTC (permalink / raw)
To: tigran; +Cc: Suresh B Siddha, akpm, linux-kernel
In-Reply-To: <20060504100940.A2571@unix-os.sc.intel.com>
When multiple updates matching a given CPU are found in the update file, the
action taken by the microcode update driver was inappropriate:
- when lower revision microcode was found before matching or higher revision
one, the driver would needlessly complain that it would not downgrade the
CPU
- when microcode matching the currently installed revision was found before
newer revision code, no update would actually take place
To change this behavior, the driver now concludes about possibly updates and
issues messages only when the entire input was parsed.
Additionally, this adds back (in different places, and conditionalized upon
a new module option) some messages removed by a previous patch.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Cc: Suresh B Siddha <suresh.b.siddha@intel.com>
--- /home/jbeulich/tmp/linux-2.6.17-rc3/arch/i386/kernel/microcode.c 2006-04-28 11:47:26.000000000 +0200
+++ 2.6.17-rc3-x86-microcode/arch/i386/kernel/microcode.c 2006-03-27 22:46:38.000000000 +0200
@@ -91,7 +91,10 @@ MODULE_DESCRIPTION("Intel CPU (IA-32) Mi
MODULE_AUTHOR("Tigran Aivazian <tigran@veritas.com>");
MODULE_LICENSE("GPL");
-#define MICROCODE_VERSION "1.14"
+static int verbose;
+module_param(verbose, int, 0644);
+
+#define MICROCODE_VERSION "1.14a"
#define DEFAULT_UCODE_DATASIZE (2000) /* 2000 bytes */
#define MC_HEADER_SIZE (sizeof (microcode_header_t)) /* 48 bytes */
@@ -122,14 +125,15 @@ static unsigned int user_buffer_size; /*
typedef enum mc_error_code {
MC_SUCCESS = 0,
- MC_NOTFOUND = 1,
- MC_MARKED = 2,
- MC_ALLOCATED = 3,
+ MC_IGNORED = 1,
+ MC_NOTFOUND = 2,
+ MC_MARKED = 3,
+ MC_ALLOCATED = 4,
} mc_error_code_t;
static struct ucode_cpu_info {
unsigned int sig;
- unsigned int pf;
+ unsigned int pf, orig_pf;
unsigned int rev;
unsigned int cksum;
mc_error_code_t err;
@@ -164,6 +168,7 @@ static void collect_cpu_info (void *unus
rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]);
uci->pf = 1 << ((val[1] >> 18) & 7);
}
+ uci->orig_pf = uci->pf;
}
wrmsr(MSR_IA32_UCODE_REV, 0, 0);
@@ -197,21 +202,34 @@ static inline void mark_microcode_update
pr_debug(" Checksum 0x%x\n", cksum);
if (mc_header->rev < uci->rev) {
- printk(KERN_ERR "microcode: CPU%d not 'upgrading' to earlier revision"
- " 0x%x (current=0x%x)\n", cpu_num, mc_header->rev, uci->rev);
- goto out;
+ if (uci->err == MC_NOTFOUND) {
+ uci->err = MC_IGNORED;
+ uci->cksum = mc_header->rev;
+ } else if (uci->err == MC_IGNORED && uci->cksum < mc_header->rev)
+ uci->cksum = mc_header->rev;
} else if (mc_header->rev == uci->rev) {
- /* notify the caller of success on this cpu */
- uci->err = MC_SUCCESS;
- goto out;
+ if (uci->err < MC_MARKED) {
+ /* notify the caller of success on this cpu */
+ uci->err = MC_SUCCESS;
+ }
+ } else if (uci->err != MC_ALLOCATED || mc_header->rev > uci->mc->hdr.rev) {
+ pr_debug("microcode: CPU%d found a matching microcode update with "
+ " revision 0x%x (current=0x%x)\n", cpu_num, mc_header->rev, uci->rev);
+ uci->cksum = cksum;
+ uci->pf = pf; /* keep the original mc pf for cksum calculation */
+ uci->err = MC_MARKED; /* found the match */
+ for_each_online_cpu(cpu_num) {
+ if (ucode_cpu_info + cpu_num != uci
+ && ucode_cpu_info[cpu_num].mc == uci->mc) {
+ uci->mc = NULL;
+ break;
+ }
+ }
+ if (uci->mc != NULL) {
+ vfree(uci->mc);
+ uci->mc = NULL;
+ }
}
-
- pr_debug("microcode: CPU%d found a matching microcode update with "
- " revision 0x%x (current=0x%x)\n", cpu_num, mc_header->rev, uci->rev);
- uci->cksum = cksum;
- uci->pf = pf; /* keep the original mc pf for cksum calculation */
- uci->err = MC_MARKED; /* found the match */
-out:
return;
}
@@ -253,10 +271,8 @@ static int find_matching_ucodes (void)
for_each_online_cpu(cpu_num) {
struct ucode_cpu_info *uci = ucode_cpu_info + cpu_num;
- if (uci->err != MC_NOTFOUND) /* already found a match or not an online cpu*/
- continue;
- if (sigmatch(mc_header.sig, uci->sig, mc_header.pf, uci->pf))
+ if (sigmatch(mc_header.sig, uci->sig, mc_header.pf, uci->orig_pf))
mark_microcode_update(cpu_num, &mc_header, mc_header.sig, mc_header.pf,
mc_header.cksum);
}
@@ -295,9 +311,8 @@ static int find_matching_ucodes (void)
}
for_each_online_cpu(cpu_num) {
struct ucode_cpu_info *uci = ucode_cpu_info + cpu_num;
- if (uci->err != MC_NOTFOUND) /* already found a match or not an online cpu*/
- continue;
- if (sigmatch(ext_sig.sig, uci->sig, ext_sig.pf, uci->pf)) {
+
+ if (sigmatch(ext_sig.sig, uci->sig, ext_sig.pf, uci->orig_pf)) {
mark_microcode_update(cpu_num, &mc_header, ext_sig.sig, ext_sig.pf,
ext_sig.cksum);
}
}
@@ -368,6 +383,13 @@ static void do_update_one (void * unused
struct ucode_cpu_info *uci = ucode_cpu_info + cpu_num;
if (uci->mc == NULL) {
+ if (verbose) {
+ if (uci->err == MC_SUCCESS)
+ printk(KERN_INFO "microcode: CPU%d already at revision 0x%x\n",
+ cpu_num, uci->rev);
+ else
+ printk(KERN_INFO "microcode: No new microcode data for CPU%d\n", cpu_num);
+ }
return;
}
@@ -426,6 +448,9 @@ out_free:
ucode_cpu_info[j].mc = NULL;
}
}
+ if (ucode_cpu_info[i].err == MC_IGNORED && verbose)
+ printk(KERN_WARNING "microcode: CPU%d not 'upgrading' to earlier revision"
+ " 0x%x (current=0x%x)\n", i, ucode_cpu_info[i].cksum, ucode_cpu_info[i].rev);
}
out:
return error;
^ permalink raw reply
* Folder in NFS-Share-Permission denied-but the user is group member
From: Steffen Kolbe @ 2006-05-05 11:03 UTC (permalink / raw)
To: nfs
Hi,
- a client has mounted some nfs shares
- in these shares are folders wich are owned by different groups
- rights of these folders are 2770
- getent group: user is member in these groups (on server and client via
ldap)
but access to these folders says "Permission denied"
- if I copy the folder to local disk this error does not occur and the
user has access
NFS-Server: Debian amd64 with nfs-kernel-server 1.0.7-12
NFS-Client: Debian i386 with nfs-common 1.0.7-11
Can anybody help, where I should search ?
Thanks
Steffen
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* [PATCH]: Fix netback skb accounting
From: Herbert Xu @ 2006-05-05 11:21 UTC (permalink / raw)
To: Xen Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 562 bytes --]
Hi:
When you generate non-linear skb's as netback does, it is up to you
to ensure that truesize reflects the size of paged part of the skb.
Otherwise socket memory accounting in Linux falls apart.
Thanks to the new check that David Miller added to TCP we were able
to catch this bug.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: xen-netback-truesize.patch --]
[-- Type: text/plain, Size: 507 bytes --]
diff -r decf309fb47b linux-2.6-xen-sparse/drivers/xen/netback/netback.c
--- a/linux-2.6-xen-sparse/drivers/xen/netback/netback.c Tue May 02 17:23:21 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/netback/netback.c Wed May 03 21:14:13 2006 +1000
@@ -659,6 +659,7 @@ static void net_tx_action(unsigned long
skb->data_len = txreq.size - data_len;
skb->len += skb->data_len;
+ skb->truesize += skb->data_len;
skb->dev = netif->dev;
skb->protocol = eth_type_trans(skb, skb->dev);
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* [PATCH] Fix bashism in scripts/Makefile.xen
From: Herbert Xu @ 2006-05-05 11:20 UTC (permalink / raw)
To: Xen Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 473 bytes --]
Hi:
The following patch replaces a bash-specific substitution with equivalent
POSIX /bin/sh substitutions. This allows a Xen-patched Linux to build
when /bin/sh is a POSIX shell other than bash.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: xen-bashism.patch --]
[-- Type: text/plain, Size: 588 bytes --]
diff -r decf309fb47b linux-2.6-xen-sparse/scripts/Makefile.xen
--- a/linux-2.6-xen-sparse/scripts/Makefile.xen Tue May 02 17:23:21 2006 +0100
+++ b/linux-2.6-xen-sparse/scripts/Makefile.xen Wed May 03 15:41:23 2006 +1000
@@ -2,9 +2,9 @@
# cherrypickxen($1 = allobj)
cherrypickxen = $(foreach var, $(1), \
$(shell o=$(var); \
- c=$${o/%.o/-xen.c}; \
- s=$${o/%.o/-xen.S}; \
- oxen=$${o/%.o/-xen.o}; \
+ c=$${o%.o}-xen.c; \
+ s=$${o%.o}-xen.S; \
+ oxen=$${o%.o}-xen.o; \
[ -f $(srctree)/$(src)/$${c} ] || \
[ -f $(srctree)/$(src)/$${s} ] \
&& echo $$oxen \
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [PATCH/RFC (git-core)] squelch pack-object eye-candy on non-tty
From: Johannes Schindelin @ 2006-05-05 11:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzdwzsar.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 5 May 2006, Junio C Hamano wrote:
> This defaults not to do the progress report when not on a tty.
Melikes,
Dscho
^ permalink raw reply
* Re: How To Recover Files From ext3 Partition??
From: Erik Mouw @ 2006-05-05 11:18 UTC (permalink / raw)
To: UZAIR LAKHANI; +Cc: linux-fsdevel, adilger
In-Reply-To: <20060505051618.95519.qmail@web37902.mail.mud.yahoo.com>
On Thu, May 04, 2006 at 10:16:18PM -0700, UZAIR LAKHANI wrote:
> --- Erik Mouw <erik@harddisk-recovery.com> wrote:
> > On Thu, May 04, 2006 at 07:18:38AM -0700, UZAIR
> > LAKHANI wrote:
> > > Is there any way to recover the deleted files from
> > a
> > > folder in ext3 partition. Basically in one
> > directory,
> > > I gave the command (rm -rf *) and all the files
> > and
> > > folders of this directory are lost. How to recover
> > > these. I had once found an article regarding
> > > un-deleting ext2 files.
> >
> > It *should* work the same, though the the last time
> > I tried such a
> > recovery from and ext3 filesystem, ext3 made it
> > particularly hard cause
> > it zeros most of the inode on delete (including
> > ext3_inode->i_block[]).
> > Ext2 leaves much more information behind.
> >
> > You could try with the undelfs feature in Midnight
> > Commander, but first
> > be sure to mount the filesystem read-only in order
> > to avoid any further
> > changes.
>
> Thanks for the reply. Yes it is difficult to recover
> files from ext3 as compared to ext2. I found this
> helpful info from one website.
>
> Q: How can I recover (undelete) deleted files from my
> ext3 partition?
> Actually, you can't! This is what one of the
> developers, Andreas Dilger, said about it:
> In order to ensure that ext3 can safely resume an
> unlink after a crash, it actually zeros out the block
> pointers in the inode, whereas
> ext2 just marks these blocks as unused in the block
> bitmaps and marks the inode as "deleted" and leaves
> the block pointers alone.
>
> Your only hope is to "grep" for parts of your files
> that have been deleted and hope for the best.
>
> [Source] =
> http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html
Andreas, care to elaborate? AFAICS resetting ->i_mode to 0000, setting
->i_links_count to 0, and setting ->i_dtime should be enough to
uniquely mark an inode as deleted. Doing so would make an occasional
undelete much easier to recover for Joe Sixpack (and for us a lot less
work to reconstruct files by scavenging the whole partition for clues).
> Additionally where can I get the source for Midnight
> Commander.
IIRC it lives somewhere on ftp.gnome.org and/or on ftp.gnu.org. Look
for mc-XXX.tar.gz. It started its life as a text based file manager
similar to the Norton Commander. Later on it was used by the Gnome
project to make a graphical file manager (gmc) which was later on
replaced by Nautilus.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* [U-Boot-Users] PXA27x/Au1x00 USB support?
From: Rodolfo Giometti @ 2006-05-05 11:06 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20060505102626.GH22329@gundam.enneenne.com>
Hello,
using an USB traker I see that the USB driver do _not_ send any
packets on the bus, neither the ?setup? one!
Also I noticed that if I enable the periodic list (OHCI_CTRL_PLE) the
controller sends some OUT packets even if the periodic list descriptor
are 0!
I think that the driver wrong initialize the USB host...
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti at enneenne.com
Linux Device Driver giometti at gnudd.com
Embedded Systems giometti at linux.it
UNIX programming phone: +39 349 2432127
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20060505/cf9c8561/attachment.pgp
^ permalink raw reply
* Re: New patch for video subsystem...
From: Johan Rydberg @ 2006-05-05 11:06 UTC (permalink / raw)
To: The development of GRUB 2
In-Reply-To: <445B0AED.9090409@nic.fi>
Vesa Jääskeläinen <chaac@nic.fi> writes:
> But the idea here was to make it easier to make function that operates
> on different render targets without knowing about it. eg:
>
> set_target a
> call common_func
> set target b
> call common_func
> set target c
>
> With your proposal this would require to pass this render target pointer
> all around and would make video function calls longer.
I do not see a problem with that. The overhead for passing of an
extra argument is probably less than the overhead of the function
calls (esp since set_active_render_target is an indirect call)
> There is also another problem in your proposal. What happens if video
> driver get's changed and you still have pointers to render targets (or
> to raw memory)?
Possibly the same thing as with the current method; I do not see how
this would make things different?
>> Also, I think it is important the user can get hold of a pointer to
>> the render targets data, and an exact pixel format, to do private
>> rendering. It would be hard to make a perfect gradient using fill_rect.
>
> That might not be possible on all architectures. That's the reason there
> is a bitmap support (which I am working on currently). Bitmaps are
> located on host memory so they can be modified.
I'm not sure "bitmap" is a good word here; maybe "image" would be better.
> Render targets can be located on host memory or on video memory
> depending on arch. If they are located on video memory then there is
> only need to have video-video blit functionality and some archs might
> even provide hardware accelerated helper functions.
If the architecture does not support direct access to the video
memory, it just falls back on returning a render target with
malloc()ed memory.
> One idea of the render targets are that they hide the real bitmap data
> format. So one could make a 24 bit RGB picture and then just blit it to
> render target and underlying video driver would convert it to correct
> format. This frees API user from thinking all possible formats and can
> concentrate to make one working implementation.
Iter-format blits can of course also be supported if you have direct
access to the render target pixel data.
> If one needs to modify render target on all platforms there should be
> support to direct access to memory or ability to read contents of frame
> buffer to host memory and then write it back or requirement to store
> data on host memory and then do blit from there to video memory, but
> that is a bit costy on performance.
I do not see why that should be needed.
Have you looked at for example DirectFB's API? Even through their
coding style is fucked up, the overall design of the API is quite
nice.
I'm just afraid that we will see the exact same thing that happened to
legacy GRUB; a lot of distribution vendors hack up something of their
own. Therefor it is important that we get this right.
~j
^ permalink raw reply
* Re: [PATCH 7/7] uts namespaces: Implement CLONE_NEWUTS flag
From: Andi Kleen @ 2006-05-05 11:02 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Eric W. Biederman, herbert, dev, linux-kernel, sam, xemul,
haveblue, clg, frankeh
In-Reply-To: <20060503161143.GA18576@sergelap.austin.ibm.com>
> But, either the nsproxy is shared between tasks and you need to copy
> youself a new one as soon as any ns changes
That would be the case. But it is only shared between tasks where
all the name spaces are the same.
> , or it is not shared, and
> you don't need that info at all (just make the change in the nsproxy
> immediately)
Don't follow you here.
Basically the goal is to have a minimum number of nsproxies in the system without
having to maintain a global hash table. So instead you assume that name space
changes are infrequent. In the common case of clone without a name space change
you just share the nsproxy of the parent. If there is a name space change of
any kind you get a new one.
This won't get the absolute minimum number of nsproxies, but should be reasonably
good without too much effort.
-Andi
>
^ permalink raw reply
* Any reason for passing "tlb" to "free_pgtables()" by address?
From: Zoltan Menyhart @ 2006-05-05 10:53 UTC (permalink / raw)
To: linux-mm; +Cc: Zoltan.Menyhart
Apparently, there is no reason for passing "tlb" to "free_pgtables()"
by address, because there is no need for re-scheduling inside this
function => no other "mmu_gather" can / will be used.
Thanks,
Zoltan
--- linux-2.6.16.9-save/include/linux/mm.h 2006-04-19 08:10:14.000000000 +0200
+++ linux-2.6.16.9/include/linux/mm.h 2006-05-05 11:33:56.000000000 +0200
@@ -700,9 +700,9 @@
struct vm_area_struct *start_vma, unsigned long start_addr,
unsigned long end_addr, unsigned long *nr_accounted,
struct zap_details *);
-void free_pgd_range(struct mmu_gather **tlb, unsigned long addr,
+void free_pgd_range(struct mmu_gather *tlb, unsigned long addr,
unsigned long end, unsigned long floor, unsigned long ceiling);
-void free_pgtables(struct mmu_gather **tlb, struct vm_area_struct *start_vma,
+void free_pgtables(struct mmu_gather *tlb, struct vm_area_struct *start_vma,
unsigned long floor, unsigned long ceiling);
int copy_page_range(struct mm_struct *dst, struct mm_struct *src,
struct vm_area_struct *vma);
--- linux-2.6.16.9-save/mm/mmap.c 2006-04-19 08:10:14.000000000 +0200
+++ linux-2.6.16.9/mm/mmap.c 2006-05-05 11:31:51.000000000 +0200
@@ -1661,7 +1661,7 @@
update_hiwater_rss(mm);
unmap_vmas(&tlb, vma, start, end, &nr_accounted, NULL);
vm_unacct_memory(nr_accounted);
- free_pgtables(&tlb, vma, prev? prev->vm_end: FIRST_USER_ADDRESS,
+ free_pgtables(tlb, vma, prev? prev->vm_end: FIRST_USER_ADDRESS,
next? next->vm_start: 0);
tlb_finish_mmu(tlb, start, end);
}
@@ -1944,7 +1944,7 @@
/* Use -1 here to ensure all VMAs in the mm are unmapped */
end = unmap_vmas(&tlb, vma, 0, -1, &nr_accounted, NULL);
vm_unacct_memory(nr_accounted);
- free_pgtables(&tlb, vma, FIRST_USER_ADDRESS, 0);
+ free_pgtables(tlb, vma, FIRST_USER_ADDRESS, 0);
tlb_finish_mmu(tlb, 0, end);
/*
--- linux-2.6.16.9-save/mm/memory.c 2006-04-19 08:10:14.000000000 +0200
+++ linux-2.6.16.9/mm/memory.c 2006-05-05 11:30:27.000000000 +0200
@@ -201,7 +201,7 @@
*
* Must be called with pagetable lock held.
*/
-void free_pgd_range(struct mmu_gather **tlb,
+void free_pgd_range(struct mmu_gather *tlb,
unsigned long addr, unsigned long end,
unsigned long floor, unsigned long ceiling)
{
@@ -252,19 +252,19 @@
return;
start = addr;
- pgd = pgd_offset((*tlb)->mm, addr);
+ pgd = pgd_offset(tlb->mm, addr);
do {
next = pgd_addr_end(addr, end);
if (pgd_none_or_clear_bad(pgd))
continue;
- free_pud_range(*tlb, pgd, addr, next, floor, ceiling);
+ free_pud_range(tlb, pgd, addr, next, floor, ceiling);
} while (pgd++, addr = next, addr != end);
- if (!(*tlb)->fullmm)
- flush_tlb_pgtables((*tlb)->mm, start, end);
+ if (!tlb->fullmm)
+ flush_tlb_pgtables(tlb->mm, start, end);
}
-void free_pgtables(struct mmu_gather **tlb, struct vm_area_struct *vma,
+void free_pgtables(struct mmu_gather *tlb, struct vm_area_struct *vma,
unsigned long floor, unsigned long ceiling)
{
while (vma) {
--- linux-2.6.16.9-save/include/asm-ia64/pgtable.h 2006-04-21 09:59:12.000000000 +0200
+++ linux-2.6.16.9/include/asm-ia64/pgtable.h 2006-05-05 11:49:21.000000000 +0200
@@ -506,7 +506,7 @@
#define HUGETLB_PGDIR_SIZE (__IA64_UL(1) << HUGETLB_PGDIR_SHIFT)
#define HUGETLB_PGDIR_MASK (~(HUGETLB_PGDIR_SIZE-1))
struct mmu_gather;
-void hugetlb_free_pgd_range(struct mmu_gather **tlb, unsigned long addr,
+void hugetlb_free_pgd_range(struct mmu_gather *tlb, unsigned long addr,
unsigned long end, unsigned long floor, unsigned long ceiling);
#endif
--- linux-2.6.16.9-save/arch/ia64/mm/hugetlbpage.c 2006-04-21 09:58:55.000000000 +0200
+++ linux-2.6.16.9/arch/ia64/mm/hugetlbpage.c 2006-05-05 11:48:46.000000000 +0200
@@ -107,7 +107,7 @@
return NULL;
}
-void hugetlb_free_pgd_range(struct mmu_gather **tlb,
+void hugetlb_free_pgd_range(struct mmu_gather *tlb,
unsigned long addr, unsigned long end,
unsigned long floor, unsigned long ceiling)
{
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Remove silly messages from input layer.
From: Valdis.Kletnieks @ 2006-05-05 10:51 UTC (permalink / raw)
To: Sergei Organov; +Cc: Pavel Machek, linux-kernel
In-Reply-To: <87y7xg92n4.fsf@javad.com>
[-- Attachment #1: Type: text/plain, Size: 594 bytes --]
On Fri, 05 May 2006 14:39:27 +0400, Sergei Organov said:
> Pavel Machek <pavel@ucw.cz> writes:
> [...]
> > OTOH for example I now know that capslock-x-c is combination X32 does
> > not like. Unfortunately, if you swap capslock and ctrl, and type too
> > fast... you'll press this combination while exiting emacs.
>
> Fortunately nobody ever needs to exit emacs :)
M-x save-buffers-shutdown-h-now
I'm not sure which surprised and worried me more - that I saw somebody try that
with the expectation that it would work, or that he was running emacs in a
configuration where it *did* work. ;)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* [PATH]: Add missing spin_unlock_irq() to x86
From: Juan Quintela @ 2006-05-05 10:45 UTC (permalink / raw)
To: xen-devel
Add missing spin_unlock_irq() at xen/arch/x86/irq.c
Changeset 9889:42a8e3101c6c reorganized the code on this file, and
missed this spin_unlock_irq(). Without this patch, my machine hang
completely during boot. With this, it works.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
diff -r 1a84eec74331 xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c Thu May 04 11:24:19 2006 +0100
+++ b/xen/arch/x86/irq.c Thu May 04 19:19:46 2006 +0200
@@ -318,6 +318,7 @@ static void __pirq_guest_eoi(struct doma
{
ASSERT(cpus_empty(action->cpu_eoi_map));
desc->handler->end(irq_to_vector(irq));
+ spin_unlock_irq(&desc->lock);
return;
}
^ permalink raw reply
* fixed samsung r65 dsdt
From: Stefan Kombrink @ 2006-05-05 10:45 UTC (permalink / raw)
To: linux-acpi
[-- Attachment #1: Type: text/plain, Size: 499 bytes --]
Hi there,
I've got a Samsung R65 Charis several days ago, and noticed that the
DSDT is not found by the kernel.
After fixing it (11 Errors, 1 Warning still left) the frequency
scaling seems to work (1.0/1.3/1.6GHz)
Since most probably I am going to return the notebook, I cannot do
further testings (means suspend/hibernate).
(I think the NVidia card might cause the trouble as well)
However, compile the .hex into your kernel, and speed step should work :)
greetings,
Stefan >8^)
[-- Attachment #2: samsung-r65.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 68223 bytes --]
^ permalink raw reply
* PAE mode errors: in shadow.c
From: pak333 @ 2006-05-05 10:41 UTC (permalink / raw)
To: xen-devel, Anthony Liguori; +Cc: chengyuan.li, Jun Nakajima
[-- Attachment #1.1: Type: text/plain, Size: 12081 bytes --]
Looks like the file shadow.c has not been updated to support PAE thought it says
"Extended to support 32-bit PAE and 64-bit guests" at the beginning of the file
If anyone has a pacth for this, please share with me
Thanks
- Padma
-------------- Original message --------------
From: pak333@comcast.net
Maybe the attachment isn't going thru. here are the errors
---------------------------
make -C xen install
make[1]: Entering directory `/home/xen-unstable/xen'
make -C tools
make[2]: Entering directory `/home/xen-unstable/xen/tools'
make -C figlet
make[3]: Entering directory `/home/xen-unstable/xen/tools/figlet'
make[3]: `figlet' is up to date.
make[3]: Leaving directory `/home/xen-unstable/xen/tools/figlet'
make symbols
make[3]: Entering directory `/home/xen-unstable/xen/tools'
make[3]: `symbols' is up to date.
make[3]: Leaving directory `/home/xen-unstable/xen/tools'
make[2]: Leaving directory `/home/xen-unstable/xen/tools'
make include/xen/compile.h
make[2]: Entering directory `/home/xen-unstable/xen'
tools/figlet/figlet -d tools/figlet Xen 3.0.0 > include/xen/banner.h.new
__ __ _____ ___ ___
\ \/ /___ _ __ |___ / / _ \ / _ \
\ // _ \ '_ \ |_ \| | | | | | |
/ \ __/ | | | ___) | |_| | |_| |
/_/\_\___|_| |_| |____(_)___(_)___/
make[2]: Leaving directory `/home/xen-unstable/xen'
make include/xen/acm_policy.h
make[2]: Entering directory `/home/xen-unstable/xen'
make[2]: `include/xen/acm_policy.h' is up to date.
make[2]: Leaving directory `/home/xen-unstable/xen'
[ -e include/asm ] || ln -sf asm-x86 include/asm
make -C arch/x86 asm-offsets.s
make[2]: Entering directory `/home/xen-unstable/xen/arch/x86'
make[2]: `asm-offsets.s' is up to date.
make[2]: Leaving directory `/home/xen-unstable/xen/arch/x86'
make include/asm-x86/asm-offsets.h
make[2]: Entering directory `/home/xen-unstable/xen'
make[2]: `include/asm-x86/asm-offsets.h' is up to date.
make[2]: Leaving directory `/home/xen-unstable/xen'
make -C common
make[2]: Entering directory `/home/xen-unstable/xen/common'
gcc -Wdeclaration-after-statement -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -Wno-pointer-arith -pipe -I/home/xen-unstable/xen/include -I/home/xen-unstable/xen/include/asm-x86/mach-generic -I/home/xen-unstable/xen/include/asm-x86/mach-default -O3 -fomit-frame-pointer -msoft-float -m32 -march=i686 -DNDEBUG -c kernel.c -o kernel.o
ld -m elf_i386 -r -o common.o acm_ops.o ac_timer.o bitmap.o dom0_ops.o domain.o elf.o event_channel.o grant_table.o kernel.o keyhandler.o lib.o memory.o multicall.o page_alloc.o sched_bvt.o sched_sedf.o schedule.o softirq.o string.o symbols.o trace.o vsprintf.o xmalloc.o
make[2]: Leaving directory `/home/xen-unstable/xen/common'
make -C drivers
make[2]: Entering directory `/home/xen-unstable/xen/drivers'
make -C char
make[3]: Entering directory `/home/xen-unstable/xen/drivers/char'
gcc -Wdeclaration-after-statement -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -Wno-pointer-arith -pipe -I/home/xen-unstable/xen/include -I/home/xen-unstable/xen/include/asm-x86/mach-generic -I/home/xen-unstable/xen/include/asm-x86/mach-default -O3 -fomit-frame-pointer -msoft-float -m32 -march=i686 -DNDEBUG -c console.c -o console.o
ld -m elf_i386 -r -o driver.o console.o ns16550.o serial.o
make[3]: Leaving directory `/home/xen-unstable/xen/drivers/char'
make -C acpi
make[3]: Entering directory `/home/xen-unstable/xen/drivers/acpi'
make[3]: Nothing to be done for `default'.
make[3]: Leaving directory `/home/xen-unstable/xen/drivers/acpi'
make[2]: Leaving directory `/home/xen-unstable/xen/drivers'
make -C arch/x86
make[2]: Entering directory `/home/xen-unstable/xen/arch/x86'
gcc -Wdeclaration-after-statement -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -Wno-pointer-arith -pipe -I/home/xen-unstable/xen/include -I/home/xen-unstable/xen/include/asm-x86/mach-generic -I/home/xen-unstable/xen/include/asm-x86/mach-default -O3 -fomit-frame-pointer -msoft-float -m32 -march=i686 -DNDEBUG -c shadow.c -o shadow.o
In file included from shadow.c:37:
/home/xen-unstable/xen/include/asm/shado L2_PAGETABLE_SHIFTw_64.h: In function `table_offset_64':
/home/xen-unstable/xen/include/asm/shadow_64.h:105: error: `L3_PAGETABLE_SHIFT' undeclared (first use in this function)
/home/xen-unstable/xen/include/asm/shadow_64.h:105: error: (Each undeclared identifier is reported only once
/home/xen-unstable/xen/include/asm/shadow_64.h:105: error: for each function it appears in.)
/home/xen-unstable/xen/include/asm/shadow_64.h:105: error: `L3_PAGETABLE_ENTRIES' undeclared (first use in this function)
/home/xen-unstable/xen/include/asm/shadow_64.h: In function `free_out_of_sync_state':
/home/xen-unstable/xen/include/asm/shadow_64.h:137: warning: implicit declaration of function `release_out_of_sync_entry'
/home/xen-unstable/xen/include/asm/shadow_64.h: In function `__entry':
/home/xen-unstable/xen/include/asm/shadow_64.h:164: error: dereferencing pointer to incomplete type
/home/xen-unstable/xen/include/asm/shadow_64.h: At top level:
/home/xen-unstable/xen/include/asm/shadow_64.h:239: error: conflicting types for '__guest_set_l2e'
/home/xen-unstable/xen/include/asm/shadow.h:545: error: previous definition of '__guest_set_l2e' was here
/home/xen-unstable/xen/include/asm/shadow_64.h:265: error: conflicting types for '__guest_get_l2e'
/home/xen-unstable/xen/include/asm/shadow.h:538: error: previous definition of '__guest_get_l2e' was here
/home/xen-unstable/xen/include/asm/shadow_64.h: In function `entry_general':
/home/xen-unstable/xen/include/asm/shadow_64.h:397: error: dereferencing pointer to incomplete type
shadow.c: In function `alloc_shadow_page':
shadow.c:226: error: dereferencing pointer to incomplete type
shadow.c:381: error: dereferencing pointer to incomplete type
shadow.c: At top level:
shadow.c:547: warning: static declaration of 'shadow_map_l1_into_current_l2' follows non-static declaration
/home/xen-unstable/xen/include/asm/shadow.h:1521: warning: previous declaration of 'shadow_map_l1_into_current_l2' was here
shadow.c:684: error: redefinition of 'shadow_set_l1e'
/home/xen-unstable/xen/include/asm/shadow.h:1525: error: previous definition of 'shadow_set_l1e' was here
shadow.c:1026: warning: static declaration of 'shadow_mark_va_out_of_sync' follows non-static declaration
/home/xen-unstable/xen/include/asm/shadow.h:745: warning: previous declaration of 'shadow_mark_va_out_of_sync' was here
shadow.c: In function `remove_all_write_access':
shadow.c:1387: warning: implicit declaration of function `MFN_PINNED'
shadow.c: In function `resync_all':
shadow.c:1549: error: dereferencing pointer to incomplete type
shadow.c:1583: warning: ISO C90 forbids mixed declarations and code
shadow.c:1626: warning: ISO C90 forbids mixed declarations and code
shadow.c: In function `sync_all':
shadow.c:1810: error: dereferencing pointer to incomplete type
shadow.c: At top level:
shadow.c:1839: error: redefinition of 'l1pte_write_fault'
/home/xen-unstable/xen/include/asm/shadow.h:750: error: previous definition of 'l1pte_write_fault' was here
shadow.c:1875: error: redefinition of 'l1pte_read_fault'
/home/xen-unstable/xen/include/asm/shadow.h:786: error: previous definition of 'l1pte_read_fault' was here
shadow.c:3590: error: variable `MODE_A_HANDLER' has initializer but incomplete type
shadow.c:3591: error: unknown field `guest_paging_levels' specified in initializer
shadow.c:3591: warning: excess elements in struct initializer
shadow.c:3591: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3592: error: unknown field `invlpg' specified in initializer
shadow.c:3592: warning: excess elements in struct initializer
shadow.c:3592: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3593: error: unknown field `fault' specified in initializer
shadow.c:3593: warning: excess elements in struct initializer
shadow.c:3593: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3594: error: unknown field `update_pagetables' specified in initializer
shadow.c:3594: warning: excess elements in struct initializer
shadow.c:3594: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3595: error: unknown field `sync_all' specified in initializer
shadow.c:3595: warning: excess elements in struct initializer
shadow.c:3595: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3596: error: unknown field `remove_all_write_access' specified in initializer
shadow.c:3596: warning: excess elements in struct initializer
shadow.c:3596: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3597: error: unknown field `do_update_va_mapping' specified in initializer
shadow.c:3597: warning: excess elements in struct initializer
shadow.c:3597: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3598: error: unknown field `mark_mfn_out_of_sync' specified in initializer
shadow.c:3598: warning: excess elements in struct initializer
shadow.c:3598: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3599: error: unknown field `is_out_of_sync' specified in initializer
shadow.c:3599: warning: excess elements in struct initializer
shadow.c:3599: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3600: error: unknown field `gva_to_gpa' specified in initializer
shadow.c:3600: error: `gva_to_gpa_64' undeclared here (not in a function)
shadow.c:3600: warning: excess elements in struct initializer
shadow.c:3600: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3590: error: storage size of `MODE_A_HANDLER' isn't known
make[2]: *** [shadow.o] Error 1
make[2]: Leaving directory `/home/xen-unstable/xen/arch/x86'
make[1]: *** [/home/xen-unstable/xen/xen] Error 2
make[1]: Leaving directory `/home/xen-unstable/xen'
make: *** [install-xen] Error 2
-------------- Original message --------------
From: pak333@comcast.net
Looks like the attachement did not go thru. Attached error file again. Let me know if you cannot see the attached file
Changed memory to 16GB
and still get errros
- padma
-------------- Original message --------------
From: Anthony Liguori <aliguori@us.ibm.com>
> pak333@comcast.net wrote:
> > Thanks, I just tried this and it gives me a bunch of errors
>
> Care to share those errors? :-)
>
> Regards,
>
> Anthony Liguori
>
> > - Padma
> >
> >
> >
> >
> > -------------- Original message --------------
> > From: Anthony Liguori
> >
> > > You need to rebuild Xen (the hypervisor) with pae support.
> > >
> > > I believe it's something like make pae=yes
> > >
> > > Regards,
> > >
> > > Anthony Liguori
> > >
> > > pak333@comcast.net wrote:
> > > > Hi,
> > ; ; > >
> > > > I just added 32GB memory in my system and wanted Xen to see that
> > > > memory, so enabled PAE in xen0 and XenU. I did a make
> > menuconfig in
> > > > xen0 and xenU, then did a make in xen-unstable and a make
> > install.
> > > >
> > > > Whilebooting this kernel, I get the above error PAE mode
> > mismatch. I
> > > > looked under xen/include/asm-x86/processor.h has #define
> > X86_CR4_PAE
> > > > defined and so does cpufeature.h have this defined. #define
> > > > X86_FEATURE_PAE
> > ! > &g t;
> > > > What else should I have done to enable a PAE enabled Xen
> > kernel. I am
> > > > using xen 3.0.0 (xen-unstable) and cannot move to 3.02 due to
> > > > xenoprofile not ready there
> > > >
> > > &g t; Thanks
> > > > - Padma
> > > >
> > ------------------------------------------------------------------------
> >
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xensource.com
> > > > http://lists.xensource.com/xen-devel
> > > >
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> >
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 14437 bytes --]
[-- Attachment #2: Type: message/rfc822, Size: 1390 bytes --]
[-- Attachment #2.1.1: Type: message/rfc822, Size: 654 bytes --]
[-- Attachment #2.1.1.1.1: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #2.1.2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: Remove silly messages from input layer.
From: Sergei Organov @ 2006-05-05 10:39 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-kernel
In-Reply-To: <20060505103123.GB4206@elf.ucw.cz>
Pavel Machek <pavel@ucw.cz> writes:
[...]
> OTOH for example I now know that capslock-x-c is combination X32 does
> not like. Unfortunately, if you swap capslock and ctrl, and type too
> fast... you'll press this combination while exiting emacs.
Fortunately nobody ever needs to exit emacs :)
--
Sergei.
^ permalink raw reply
* au88x0_mpu401 init / fail first open
From: Alan Horstmann @ 2006-05-05 10:39 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
I've noticed that au88x0 has an error on the first use of the midi port only.
With 1.0.11 midi play continues OK anyway; with the later 'fix-hang' patch it
results in failled I/O.
Sprinkling with printks has enabled me to trace it. It seems that when the
port is sent 'ENTER_UART' ACK (0xfe) can be read, but the following command
does not result in ACK, even though on it's own it would. In its init,
au88x0_mpu401 sends 'RESET' then 'ENTER_UART'. Subsequently, when playng
midi, mpu401_uart attempts output_open and also sends 'RESET' and expects ACK
-but 0xf9 is read instead. A second attempt to play is successful. During
normal use, when the output is closed, 'RESET' is sent again, but not tested
for ACK (which would fail) and the next output_open is sucessful.
Any comments?? A hacked diff is attached which shows the affected bits of
code, and additional writes and reads in au88x0_mpu401 which demonstrate the
behaviour. Result is: Temp1 0xfe, Temp2 0xfe, Temp3 0xf9, Temp4 0xfe, Temp5
0xf9.
To fix (though not necessarily the solution) either omit the 'ENTER_UART' in
au88x0_mpu401, or add an extra 'RESET' afterwards.
Regards Alan
[-- Attachment #2: mpu401changes.diff --]
[-- Type: text/x-diff, Size: 4067 bytes --]
diff -ru /usr/share/alsa1.0.11/alsa-driver-1.0.11-orig/alsa-kernel/drivers/mpu401/mpu401_uart.c alsa-kernel/drivers/mpu401/mpu401_uart.c
--- /usr/share/alsa1.0.11/alsa-driver-1.0.11-orig/alsa-kernel/drivers/mpu401/mpu401_uart.c 2005-11-18 18:52:14.000000000 +0000
+++ alsa-kernel/drivers/mpu401/mpu401_uart.c 2006-05-04 22:41:23.000000000 +0100
@@ -204,23 +205,29 @@
}
mpu->write(mpu, cmd, MPU401C(mpu));
if (ack) {
+ printk("ACK\n");
ok = 0;
timeout = 10000;
while (!ok && timeout-- > 0) {
- if (snd_mpu401_input_avail(mpu)) {
+ if (timeout == 5000) printk("%i",timeout);
+// if (snd_mpu401_input_avail(mpu)) {
+// printk("InAv\n");
if (mpu->read(mpu, MPU401D(mpu)) == MPU401_ACK)
ok = 1;
- }
+// }
}
if (!ok && mpu->read(mpu, MPU401D(mpu)) == MPU401_ACK)
ok = 1;
} else {
ok = 1;
}
+ printk("OK %i \n", ok);
spin_unlock_irqrestore(&mpu->input_lock, flags);
- if (! ok)
+ if (!ok) {
snd_printk("cmd: 0x%x failed at 0x%lx (status = 0x%x, data = 0x%x)\n", cmd, mpu->port, mpu->read(mpu, MPU401C(mpu)), mpu->read(mpu, MPU401D(mpu)));
+ return 1;
+ }
+ return 0;
}
/*
@@ -252,39 +266,53 @@
if (mpu->open_output && (err = mpu->open_output(mpu)) < 0)
return err;
if (! test_bit(MPU401_MODE_BIT_INPUT, &mpu->mode)) {
- snd_mpu401_uart_cmd(mpu, MPU401_RESET, 1);
- snd_mpu401_uart_cmd(mpu, MPU401_ENTER_UART, 1);
+// snd_mpu401_uart_cmd(mpu, MPU401_RESET, 0);
+ if (snd_mpu401_uart_cmd(mpu, MPU401_RESET, 1))
+ goto error_out;
+ if (snd_mpu401_uart_cmd(mpu, MPU401_ENTER_UART, 1))
+ goto error_out;
}
mpu->substream_output = substream;
set_bit(MPU401_MODE_BIT_OUTPUT, &mpu->mode);
return 0;
+
+error_out:
+ if (mpu->open_output && mpu->close_output)
+ mpu->close_output(mpu);
+ return -EIO;
}
static int snd_mpu401_uart_output_close(struct snd_rawmidi_substream *substream)
{
struct snd_mpu401 *mpu;
+ int err = 0;
mpu = substream->rmidi->private_data;
clear_bit(MPU401_MODE_BIT_OUTPUT, &mpu->mode);
mpu->substream_output = NULL;
if (! test_bit(MPU401_MODE_BIT_INPUT, &mpu->mode))
- snd_mpu401_uart_cmd(mpu, MPU401_RESET, 0);
+ err = snd_mpu401_uart_cmd(mpu, MPU401_RESET, 0);
if (mpu->close_output)
mpu->close_output(mpu);
+ if (err)
+ return -EIO;
return 0;
}
diff -ru /usr/share/alsa1.0.11/alsa-driver-1.0.11-orig/alsa-kernel/pci/au88x0/au88x0_mpu401.c alsa-kernel/pci/au88x0/au88x0_mpu401.c
--- /usr/share/alsa1.0.11/alsa-driver-1.0.11-orig/alsa-kernel/pci/au88x0/au88x0_mpu401.c 2006-01-13 17:16:29.000000000 +0000
+++ alsa-kernel/pci/au88x0/au88x0_mpu401.c 2006-05-04 21:45:50.000000000 +0100
@@ -65,24 +65,45 @@
hwwrite(vortex->mmio, VORTEX_CTRL, temp);
#endif
/* Mpu401UartInit() */
+ printk("401 init");
mode = 1;
temp = hwread(vortex->mmio, VORTEX_CTRL2) & 0xffff00cf;
temp |= (MIDI_CLOCK_DIV << 8) | ((mode >> 24) & 0xff) << 4;
hwwrite(vortex->mmio, VORTEX_CTRL2, temp);
hwwrite(vortex->mmio, VORTEX_MIDI_CMD, MPU401_RESET);
+
+ temp = hwread(vortex->mmio, VORTEX_MIDI_DATA);
+ printk("Temp1 0x%x\n", temp);
+
/* Set some kind of mode */
if (mode)
hwwrite(vortex->mmio, VORTEX_MIDI_CMD, MPU401_ENTER_UART);
/* Check if anything is OK. */
temp = hwread(vortex->mmio, VORTEX_MIDI_DATA);
+ printk("Temp2 0x%x\n", temp);
if (temp != MPU401_ACK /*0xfe */ ) {
printk(KERN_ERR "midi port doesn't acknowledge!\n");
return -ENODEV;
}
+
+ hwwrite(vortex->mmio, VORTEX_MIDI_CMD, MPU401_RESET);
+ temp = hwread(vortex->mmio, VORTEX_MIDI_DATA);
+ printk("Temp3 0x%x\n", temp);
+
+ hwwrite(vortex->mmio, VORTEX_MIDI_CMD, MPU401_ENTER_UART);
+ temp = hwread(vortex->mmio, VORTEX_MIDI_DATA);
+ printk("Temp4 0x%x\n", temp);
+
+ hwwrite(vortex->mmio, VORTEX_MIDI_CMD, MPU401_RESET);
+ temp = hwread(vortex->mmio, VORTEX_MIDI_DATA);
+ printk("Temp5 0x%x\n", temp);
+
+
/* Enable MPU401 interrupts. */
hwwrite(vortex->mmio, VORTEX_IRQ_CTRL,
hwread(vortex->mmio, VORTEX_IRQ_CTRL) | IRQ_MIDI);
+// hwwrite(vortex->mmio, VORTEX_MIDI_CMD, MPU401_RESET);
/* Create MPU401 instance. */
#ifdef VORTEX_MPU401_LEGACY
^ permalink raw reply
* Re: Au1200 MMC/SD problem
From: Wolfgang Ocker @ 2006-05-05 10:39 UTC (permalink / raw)
To: Jordan Crouse; +Cc: linux-mips
In-Reply-To: <20060503145927.GD24185@cosmic.amd.com>
On Wed, 2006-05-03 at 08:59 -0600, Jordan Crouse wrote:
> > The last one. In au1xmmc_irq() the status register is read with the
> > SD_STATUS_RAT bit set.
>
> Ok - so the card is timing out. That could be a series of problems, some
> of which could be hardware, some of which could be software. Since you are
> using a db1200, I'll rule out hardware for the moment, unless you have a
> modified board.
Today I tested a third SD card from SanDisk, 128MB, same problem and log
output (time out in command 9).
> Do MMC cards work? Try one - that will give us another data point.
Today I received a SanDisk 64 MB MMC card, it doesn't work either. Here
the log output:
au1xx(0): DEBUG: set_ios (power=0, clock=0Hz, vdd=0, mode=1)
au1xxx-mmc: MMC Controller 0 set up at B0600000 (mode=dma)
au1xx(0): DEBUG: set_ios (power=1, clock=0Hz, vdd=23, mode=1)
au1xx(0): DEBUG: set_ios (power=2, clock=450000Hz, vdd=23, mode=1)
au1xx(0): DEBUG: set_ios (power=2, clock=450000Hz, vdd=23, mode=1)
MMC: starting cmd 00 arg 00000000 flags 00000040
MMC: req done (00): 0: 00000000 00000000 00000000 00000000
au1xx(0): DEBUG: set_ios (power=2, clock=450000Hz, vdd=23, mode=1)
MMC: starting cmd 37 arg 00000000 flags 00000015
au1xx(0): DEBUG: au1xmmc_irq(), SD_STATUS_RAT set
MMC: req done (37): 1: 00000000 00000000 00000000 00000000
MMC: starting cmd 37 arg 00000000 flags 00000015
au1xx(0): DEBUG: au1xmmc_irq(), SD_STATUS_RAT set
MMC: req done (37): 1: 00000000 00000000 00000000 00000000
MMC: starting cmd 37 arg 00000000 flags 00000015
au1xx(0): DEBUG: au1xmmc_irq(), SD_STATUS_RAT set
MMC: req done (37): 1: 00000000 00000000 00000000 00000000
MMC: starting cmd 37 arg 00000000 flags 00000015
au1xx(0): DEBUG: au1xmmc_irq(), SD_STATUS_RAT set
MMC: req done (37): 1: 00000000 00000000 00000000 00000000
MMC: mmc_setup(), send_app_op_cond, ocr = 1000fc00, err = 1
MMC: mmc_setup(), no SD card found (1)
MMC: starting cmd 01 arg 00000000 flags 00000061
au1xx(0): DEBUG: au1xmmc_irq(), SD_STATUS_RAT set
MMC: req done (01): 1: 00000000 00000000 00000000 00000000
MMC: mmc_rescan(): no card found!
au1xx(0): DEBUG: set_ios (power=0, clock=0Hz, vdd=0, mode=1)
Thanks,
Wolfgang
^ permalink raw reply
* Linux 2.6.14 NAND driver crash.
From: Han Chang @ 2006-05-05 10:19 UTC (permalink / raw)
To: linux-mtd
I'm moving from linux from 2.6.12 to 2.6.14. The NAND driver was working OK
on 2.6.12. But on 2.6.14, when I tried to dd a file to the NAND device,
sometime it crashed without dumping out anything, but sometime it dumped out
following message. Any suggestion? Thanks!
=================================
# dd if=/sbin/mkdosfs of=/dev/mtdblock2 bs=25000 count=1
slab: Internal list corruption detected in cache 'blkdev_ioc'(92), slabp
c029100
0(-1071021006). Hexdump:
000: 00 01 10 00 00 02 20 00 2a 84 29 c0 2e 84 29 c0
010: 32 84 29 c0 36 84 29 c0 3a 84 29 c0 3e 84 29 c0
020: 42 84 29 c0 46 84 29 c0 4a 84 29 c0 4e 84 29 c0
030: 52 84 29 c0 56 84 29 c0 5a 84 29 c0 5e 84 29 c0
040: 62 84 29 c0 66 84 29 c0 6a 84 29 c0 6e 84 29 c0
050: 72 84 29 c0 76 84 29 c0 7a 84 29 c0 7e 84 29 c0
060: 82 84 29 c0 86 84 29 c0 8a 84 29 c0 8e 84 29 c0
070: 92 84 29 c0 96 84 29 c0 9a 84 29 c0 9e 84 29 c0
080: a2 84 29 c0 a6 84 29 c0 aa 84 29 c0 ae 84 29 c0
090: b2 84 29 c0 b6 84 29 c0 ba 84 29 c0 be 84 29 c0
0a0: c2 84 29 c0 c6 84 29 c0 ca 84 29 c0 ce 84 29 c0
0b0: d2 84 29 c0 d6 84 29 c0 da 84 29 c0 de 84 29 c0
0c0: e2 84 29 c0 e6 84 29 c0 ea 84 29 c0 ee 84 29 c0
0d0: f2 84 29 c0 f6 84 29 c0 fa 84 29 c0 fe 84 29 c0
0e0: 02 85 29 c0 06 85 29 c0 0a 85 29 c0 0e 85 29 c0
0f0: 12 85 29 c0 16 85 29 c0 1a 85 29 c0 1e 85 29 c0
100: 22 85 29 c0 26 85 29 c0 2a 85 29 c0 2e 85 29 c0
110: 32 85 29 c0 36 85 29 c0 3a 85 29 c0 3e 85 29 c0
120: 42 85 29 c0 46 85 29 c0 4a 85 29 c0 4e 85 29 c0
130: 52 85 29 c0 56 85 29 c0 5a 85 29 c0 5e 85 29 c0
140: 62 85 29 c0 66 85 29 c0 6a 85 29 c0 6e 85 29 c0
150: 72 85 29 c0 76 85 29 c0 7a 85 29 c0 7e 85 29 c0
160: 82 85 29 c0 86 85 29 c0 8a 85 29 c0 8e 85 29 c0
170: 92 85 29 c0
kernel BUG at mm/slab.c:2348!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=c0003021, *pte=c00010c3, *ppte=c0001212
Internal error: Oops: 81f [#1]
Modules linked in:
CPU: 0
PC is at __bug+0x44/0x58
LR is at 0x1
pc : [<c002482c>] lr : [<00000001>] Not tainted
sp : c01dfebc ip : 00000000 fp : c01dfec8
r10: 00000000 r9 : 00000007 r8 : c0291394
r7 : c01c42a0 r6 : c0291000 r5 : c01c42a0 r4 : 00000000
r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : 00000001
Flags: nZCv IRQs off FIQs on Mode SVC_32 Segment kernel
Control: E5187B Table: C08B4000 DAC: 00000017
Process events/0 (pid: 4, stack limit = 0xc01de194)
Stack: (0xc01dfebc to 0xc01e0000)
fea0:
c01dfee8
fec0: c01dfecc c005938c c00247f4 c0298432 c0291000 c01bb744 06666395
c01dff1c
fee0: c01dfeec c005a1c0 c00592b4 00000000 c01f4254 00000007 c01f4244
0000000f
ff00: c01f4254 c01c42a0 00000000 00000000 c01dff44 c01dff20 c005a350
c005a134
ff20: c01bb744 c01c42a0 00000000 c01c42ec c017bc00 c017bc10 c01dff70
c01dff48
ff40: c005b404 c005a2cc c01c6eac 80000013 c01c6ea4 c005b36c 00000001
c01dff8c
ff60: c01c6e9c c01dffc8 c01dff74 c0044cd0 c005b378 ffffffff ffffffff
00000001
ff80: 00000000 c00320f0 00010000 00000000 00000000 c01c8540 c00320f0
00100100
ffa0: 00200200 c01c6e9c c01de000 c0044b0c c01cdf2c fffffffc 00000000
c01dfff4
ffc0: c01dffcc c0049054 c0044b18 ffffffff ffffffff 00000000 00000000
00000000
ffe0: 00000000 00000000 00000000 c01dfff8 c0037088 c0048f90 00000000
00000000
Backtrace:
[<c00247e8>] (__bug+0x0/0x58) from [<c005938c>] (check_slabp+0xe4/0xfc)
[<c00592a8>] (check_slabp+0x0/0xfc) from [<c005a1c0>]
(free_block+0x98/0x198)
r6 = 06666395 r5 = C01BB744 r4 = C0291000
[<c005a128>] (free_block+0x0/0x198) from [<c005a350>]
(drain_array_locked+0x90/0
xb4)
[<c005a2c0>] (drain_array_locked+0x0/0xb4) from [<c005b404>]
(cache_reap+0x98/0x
1f0)
[<c005b36c>] (cache_reap+0x0/0x1f0) from [<c0044cd0>]
(worker_thread+0x1c4/0x254
)
[<c0044b0c>] (worker_thread+0x0/0x254) from [<c0049054>]
(kthread+0xd0/0x104)
[<c0048f84>] (kthread+0x0/0x104) from [<c0037088>] (do_exit+0x0/0xb24)
r8 = 00000000 r7 = 00000000 r6 = 00000000 r5 = 00000000
r4 = 00000000
Code: eb0044d7 e59f0014 eb0044d5 e3a03000 (e5833000)
==========================================================
^ permalink raw reply
* Re: [PATCH] bcm43xx-d80211: proper implementation of virtual interface support
From: Jiri Benc @ 2006-05-05 10:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: Ulrich Kunitz, Ivo van Doorn, Marcus Better, netdev
In-Reply-To: <1146824140.1137.67.camel@localhost>
On Fri, 05 May 2006 12:15:40 +0200, Johannes Berg wrote:
> On Fri, 2006-05-05 at 07:45 +0200, Ulrich Kunitz wrote:
> > But there could be also
> > support for one interface in AP and the other in STA mode.
>
> That's actually a much more interesting use case for WDS.
You don't need different MAC address for WDS.
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: [Qemu-devel] QEMU 0.8.1
From: Oliver Gerlich @ 2006-05-05 10:33 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <4D5D7ECC-9895-466F-BEF5-6FD465202C12@claunia.com>
Natalia Portillo wrote:
> That requires a driver in guest side that communicates with qemu.
>
> VMWare and VirtualPC does this but requires a driver in the guest side,
> so in unsupported systems you still have to click to grab.
Just as a side note, the USB tablet support makes this quite easy at
least on Win2k - it already has the required driver, so for me it was
enough to add -usbdevice tablet to the command line to have the mouse
cursor automatically grabbed/ungrabbed (it seems that the behaviour of
Ctrl+Alt changed a bit, but one gets used to it).
Thanks to Brad and Anthony for making that possible :D
Regards,
Oliver
>
> El 05/05/2006, a las 8:57, Christian MICHON escribió:
>
>> it works. Side effect: after the first ungrab, I can't see the host
>> pointer over the SDL windows.
>>
>> Yet, it's nothing as compared to the invisible wall.
>> I know nothing about most qemu internals, but would it be
>> possible to make it like vmw*re, ie the mouse is automagically
>> grabbed/ungrabbed whenever you reach the limits of the
>> SDL window ?
>>
>> On 5/5/06, Anthony Liguori <aliguori@us.ibm.com> wrote:
>>
>>> Thomas Han wrote:
>>> > Hi,
>>> >
>>> > For what it's worth. I have also seen this "invisible wall" problem
>>> > with my mouse for a few weeks off the CVS build too.
>>>
>>> Can you try out the following patch. *grumbles about SDL's brokenness*
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>
>>
>> --
>> Christian
>>
>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
^ permalink raw reply
* Re: Remove silly messages from input layer.
From: Pavel Machek @ 2006-05-05 10:31 UTC (permalink / raw)
To: Dave Jones, dtor_core, Martin J. Bligh, Linux Kernel
In-Reply-To: <20060504183840.GE18962@redhat.com>
On Čt 04-05-06 14:38:40, Dave Jones wrote:
> On Thu, May 04, 2006 at 02:34:34PM -0400, Dmitry Torokhov wrote:
>
> > >Perhaps it should say that then ;-)
> >
> > Do you have a beter wording in mind? "Keyboard reports too many keys
> > were pessed at once, some keystrokes might be dropped"?
>
> It still doesn't make sense when the user only pressed a single key,
> or in some cases, never pressed *any* key (don't have that report to hand,
> but it was a laptop keyboard)
If you only pressed single key -- your keyboard is crap or there's
some problem in the driver.
If you never pressed any key -- your keyboard is crap or there's
some problem in the driver.
...in both of these cases the message is actually useful. Where it is
not useful is when cat walks over your keyboard, because you can
actually expect this message when pressing 10 keys at once.
...in both of these cases failure should be investigated to find out
what is going on.
OTOH for example I now know that capslock-x-c is combination X32 does
not like. Unfortunately, if you swap capslock and ctrl, and type too
fast... you'll press this combination while exiting emacs.
Pavel
--
Thanks for all the (sleeping) penguins.
^ permalink raw reply
* bad bread
From: boricua @ 2006-05-05 10:28 UTC (permalink / raw)
To: reiserfs-list
running reiserfsck -B bbfile /dev/hda4 is giving me following error
"bread: cannot read the block 16 [i/o error]
anyway aroound this?
^ permalink raw reply
* Re: PAE mode mismatch in Xen (xen=no Dom0=yes)
From: pak333 @ 2006-05-05 10:26 UTC (permalink / raw)
To: Anthony Liguori; +Cc: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 11772 bytes --]
Maybe the attachment isn't going thru. here are the errors
---------------------------
make -C xen install
make[1]: Entering directory `/home/xen-unstable/xen'
make -C tools
make[2]: Entering directory `/home/xen-unstable/xen/tools'
make -C figlet
make[3]: Entering directory `/home/xen-unstable/xen/tools/figlet'
make[3]: `figlet' is up to date.
make[3]: Leaving directory `/home/xen-unstable/xen/tools/figlet'
make symbols
make[3]: Entering directory `/home/xen-unstable/xen/tools'
make[3]: `symbols' is up to date.
make[3]: Leaving directory `/home/xen-unstable/xen/tools'
make[2]: Leaving directory `/home/xen-unstable/xen/tools'
make include/xen/compile.h
make[2]: Entering directory `/home/xen-unstable/xen'
tools/figlet/figlet -d tools/figlet Xen 3.0.0 > include/xen/banner.h.new
__ __ _____ ___ ___
\ \/ /___ _ __ |___ / / _ \ / _ \
\ // _ \ '_ \ |_ \| | | | | | |
/ \ __/ | | | ___) | |_| | |_| |
/_/\_\___|_| |_| |____(_)___(_)___/
make[2]: Leaving directory `/home/xen-unstable/xen'
make include/xen/acm_policy.h
make[2]: Entering directory `/home/xen-unstable/xen'
make[2]: `include/xen/acm_policy.h' is up to date.
make[2]: Leaving directory `/home/xen-unstable/xen'
[ -e include/asm ] || ln -sf asm-x86 include/asm
make -C arch/x86 asm-offsets.s
make[2]: Entering directory `/home/xen-unstable/xen/arch/x86'
make[2]: `asm-offsets.s' is up to date.
make[2]: Leaving directory `/home/xen-unstable/xen/arch/x86'
make include/asm-x86/asm-offsets.h
make[2]: Entering directory `/home/xen-unstable/xen'
make[2]: `include/asm-x86/asm-offsets.h' is up to date.
make[2]: Leaving directory `/home/xen-unstable/xen'
make -C common
make[2]: Entering directory `/home/xen-unstable/xen/common'
gcc -Wdeclaration-after-statement -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -Wno-pointer-arith -pipe -I/home/xen-unstable/xen/include -I/home/xen-unstable/xen/include/asm-x86/mach-generic -I/home/xen-unstable/xen/include/asm-x86/mach-default -O3 -fomit-frame-pointer -msoft-float -m32 -march=i686 -DNDEBUG -c kernel.c -o kernel.o
ld -m elf_i386 -r -o common.o acm_ops.o ac_timer.o bitmap.o dom0_ops.o domain.o elf.o event_channel.o grant_table.o kernel.o keyhandler.o lib.o memory.o multicall.o page_alloc.o sched_bvt.o sched_sedf.o schedule.o softirq.o string.o symbols.o trace.o vsprintf.o xmalloc.o
make[2]: Leaving directory `/home/xen-unstable/xen/common'
make -C drivers
make[2]: Entering directory `/home/xen-unstable/xen/drivers'
make -C char
make[3]: Entering directory `/home/xen-unstable/xen/drivers/char'
gcc -Wdeclaration-after-statement -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -Wno-pointer-arith -pipe -I/home/xen-unstable/xen/include -I/home/xen-unstable/xen/include/asm-x86/mach-generic -I/home/xen-unstable/xen/include/asm-x86/mach-default -O3 -fomit-frame-pointer -msoft-float -m32 -march=i686 -DNDEBUG -c console.c -o console.o
ld -m elf_i386 -r -o driver.o console.o ns16550.o serial.o
make[3]: Leaving directory `/home/xen-unstable/xen/drivers/char'
make -C acpi
make[3]: Entering directory `/home/xen-unstable/xen/drivers/acpi'
make[3]: Nothing to be done for `default'.
make[3]: Leaving directory `/home/xen-unstable/xen/drivers/acpi'
make[2]: Leaving directory `/home/xen-unstable/xen/drivers'
make -C arch/x86
make[2]: Entering directory `/home/xen-unstable/xen/arch/x86'
gcc -Wdeclaration-after-statement -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -Wno-pointer-arith -pipe -I/home/xen-unstable/xen/include -I/home/xen-unstable/xen/include/asm-x86/mach-generic -I/home/xen-unstable/xen/include/asm-x86/mach-default -O3 -fomit-frame-pointer -msoft-float -m32 -march=i686 -DNDEBUG -c shadow.c -o shadow.o
In file included from shadow.c:37:
/home/xen-unstable/xen/include/asm/shado L2_PAGETABLE_SHIFTw_64.h: In function `table_offset_64':
/home/xen-unstable/xen/include/asm/shadow_64.h:105: error: `L3_PAGETABLE_SHIFT' undeclared (first use in this function)
/home/xen-unstable/xen/include/asm/shadow_64.h:105: error: (Each undeclared identifier is reported only once
/home/xen-unstable/xen/include/asm/shadow_64.h:105: error: for each function it appears in.)
/home/xen-unstable/xen/include/asm/shadow_64.h:105: error: `L3_PAGETABLE_ENTRIES' undeclared (first use in this function)
/home/xen-unstable/xen/include/asm/shadow_64.h: In function `free_out_of_sync_state':
/home/xen-unstable/xen/include/asm/shadow_64.h:137: warning: implicit declaration of function `release_out_of_sync_entry'
/home/xen-unstable/xen/include/asm/shadow_64.h: In function `__entry':
/home/xen-unstable/xen/include/asm/shadow_64.h:164: error: dereferencing pointer to incomplete type
/home/xen-unstable/xen/include/asm/shadow_64.h: At top level:
/home/xen-unstable/xen/include/asm/shadow_64.h:239: error: conflicting types for '__guest_set_l2e'
/home/xen-unstable/xen/include/asm/shadow.h:545: error: previous definition of '__guest_set_l2e' was here
/home/xen-unstable/xen/include/asm/shadow_64.h:265: error: conflicting types for '__guest_get_l2e'
/home/xen-unstable/xen/include/asm/shadow.h:538: error: previous definition of '__guest_get_l2e' was here
/home/xen-unstable/xen/include/asm/shadow_64.h: In function `entry_general':
/home/xen-unstable/xen/include/asm/shadow_64.h:397: error: dereferencing pointer to incomplete type
shadow.c: In function `alloc_shadow_page':
shadow.c:226: error: dereferencing pointer to incomplete type
shadow.c:381: error: dereferencing pointer to incomplete type
shadow.c: At top level:
shadow.c:547: warning: static declaration of 'shadow_map_l1_into_current_l2' follows non-static declaration
/home/xen-unstable/xen/include/asm/shadow.h:1521: warning: previous declaration of 'shadow_map_l1_into_current_l2' was here
shadow.c:684: error: redefinition of 'shadow_set_l1e'
/home/xen-unstable/xen/include/asm/shadow.h:1525: error: previous definition of 'shadow_set_l1e' was here
shadow.c:1026: warning: static declaration of 'shadow_mark_va_out_of_sync' follows non-static declaration
/home/xen-unstable/xen/include/asm/shadow.h:745: warning: previous declaration of 'shadow_mark_va_out_of_sync' was here
shadow.c: In function `remove_all_write_access':
shadow.c:1387: warning: implicit declaration of function `MFN_PINNED'
shadow.c: In function `resync_all':
shadow.c:1549: error: dereferencing pointer to incomplete type
shadow.c:1583: warning: ISO C90 forbids mixed declarations and code
shadow.c:1626: warning: ISO C90 forbids mixed declarations and code
shadow.c: In function `sync_all':
shadow.c:1810: error: dereferencing pointer to incomplete type
shadow.c: At top level:
shadow.c:1839: error: redefinition of 'l1pte_write_fault'
/home/xen-unstable/xen/include/asm/shadow.h:750: error: previous definition of 'l1pte_write_fault' was here
shadow.c:1875: error: redefinition of 'l1pte_read_fault'
/home/xen-unstable/xen/include/asm/shadow.h:786: error: previous definition of 'l1pte_read_fault' was here
shadow.c:3590: error: variable `MODE_A_HANDLER' has initializer but incomplete type
shadow.c:3591: error: unknown field `guest_paging_levels' specified in initializer
shadow.c:3591: warning: excess elements in struct initializer
shadow.c:3591: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3592: error: unknown field `invlpg' specified in initializer
shadow.c:3592: warning: excess elements in struct initializer
shadow.c:3592: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3593: error: unknown field `fault' specified in initializer
shadow.c:3593: warning: excess elements in struct initializer
shadow.c:3593: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3594: error: unknown field `update_pagetables' specified in initializer
shadow.c:3594: warning: excess elements in struct initializer
shadow.c:3594: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3595: error: unknown field `sync_all' specified in initializer
shadow.c:3595: warning: excess elements in struct initializer
shadow.c:3595: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3596: error: unknown field `remove_all_write_access' specified in initializer
shadow.c:3596: warning: excess elements in struct initializer
shadow.c:3596: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3597: error: unknown field `do_update_va_mapping' specified in initializer
shadow.c:3597: warning: excess elements in struct initializer
shadow.c:3597: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3598: error: unknown field `mark_mfn_out_of_sync' specified in initializer
shadow.c:3598: warning: excess elements in struct initializer
shadow.c:3598: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3599: error: unknown field `is_out_of_sync' specified in initializer
shadow.c:3599: warning: excess elements in struct initializer
shadow.c:3599: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3600: error: unknown field `gva_to_gpa' specified in initializer
shadow.c:3600: error: `gva_to_gpa_64' undeclared here (not in a function)
shadow.c:3600: warning: excess elements in struct initializer
shadow.c:3600: warning: (near initialization for `MODE_A_HANDLER')
shadow.c:3590: error: storage size of `MODE_A_HANDLER' isn't known
make[2]: *** [shadow.o] Error 1
make[2]: Leaving directory `/home/xen-unstable/xen/arch/x86'
make[1]: *** [/home/xen-unstable/xen/xen] Error 2
make[1]: Leaving directory `/home/xen-unstable/xen'
make: *** [install-xen] Error 2
-------------- Original message --------------
From: pak333@comcast.net
Looks like the attachement did not go thru. Attached error file again. Let me know if you cannot see the attached file
Changed memory to 16GB
and still get errros
- padma
-------------- Original message --------------
From: Anthony Liguori <aliguori@us.ibm.com>
> pak333@comcast.net wrote:
> > Thanks, I just tried this and it gives me a bunch of errors
>
> Care to share those errors? :-)
>
> Regards,
>
> Anthony Liguori
>
> > - Padma
> >
> >
> >
> >
> > -------------- Original message --------------
> > From: Anthony Liguori
> >
> > > You need to rebuild Xen (the hypervisor) with pae support.
> > >
> > > I believe it's something like make pae=yes
> > >
> > > Regards,
> > >
> > > Anthony Liguori
> > >
> > > pak333@comcast.net wrote:
> > > > Hi,
> > ; > >
> > > > I just added 32GB memory in my system and wanted Xen to see that
> > > > memory, so enabled PAE in xen0 and XenU. I did a make
> > menuconfig in
> > > > xen0 and xenU, then did a make in xen-unstable and a make
> > install.
> > > >
> > > > Whilebooting this kernel, I get the above error PAE mode
> > mismatch. I
> > > > looked under xen/include/asm-x86/processor.h has #define
> > X86_CR4_PAE
> > > > defined and so does cpufeature.h have this defined. #define
> > > > X86_FEATURE_PAE
> > ! > &g t;
> > > > What else should I have done to enable a PAE enabled Xen
> > kernel. I am
> > > > using xen 3.0.0 (xen-unstable) and cannot move to 3.02 due to
> > > > xenoprofile not ready there
> > > >
> > > &g t; Thanks
> > > > - Padma
> > > >
> > ------------------------------------------------------------------------
> >
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xensource.com
> > > > http://lists.xensource.com/xen-devel
> > > >
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> >
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 13929 bytes --]
[-- Attachment #2: Type: message/rfc822, Size: 654 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ 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.