* Re: [LARTC] sangoma cards in linux
From: Martin A. Brown @ 2006-06-04 16:02 UTC (permalink / raw)
To: lartc
In-Reply-To: <c2cd58b40606020507u530acec2o7d2e5feeb3d80e12@mail.gmail.com>
Hello there,
: we only have a /29 internet routable network from our ISP and a
: Cisco 1601 router with serial interface doing all the routing.
:
: I was thinking of replacing that cisco with a linux box with a
: sangoma card, also using quagga with ospf on for my internel
: networks
I can't speak directly to quagga and ospf, but I can provide an
encomium for the Sangoma cards.
I have used the Sangoma cards (since 2000 or so, starting with the
S508/FT1) and found them to be extraordinarily reliable. Their
technical support is also very good. I have seen these cards used
in Australia and the U.S. and recommend them wholeheartedly.
Good luck,
-Martin
--
Martin A. Brown
http://linux-ip.net/
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [patch, -rc5-mm1] locking validator: special rule: 8390.c disable_irq()
From: Alan Cox @ 2006-06-04 16:10 UTC (permalink / raw)
To: Steven Rostedt
Cc: Arjan van de Ven, Alan Cox, Ingo Molnar, Andrew Morton,
linux-kernel
In-Reply-To: <1149426961.27696.7.camel@localhost.localdomain>
Ar Sul, 2006-06-04 am 09:16 -0400, ysgrifennodd Steven Rostedt:
> But I'm not sure if I fully understand this misrouting irq. Is it to
> fix broken machines that trigger interrupts on the wrong line? Or is
It is solely to deal with machines where IRQs turn up on the wrong line,
generally meaning broken ACPI IRQ tables. It has to be enabled as a boot
option.
Alan
^ permalink raw reply
* Re: Using subversion tools on Mozilla CVS
From: Jon Smirl @ 2006-06-04 15:48 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP08068F9BD23CF4FA8A1BDBAE970@CEZ.ICE>
On 6/4/06, Sean <seanlkml@sympatico.ca> wrote:
> On Sat, 3 Jun 2006 23:09:00 -0400
> "Jon Smirl" <jonsmirl@gmail.com> wrote:
>
> > I found this tool written in Python for importing CVS into Subversion.
> > It seems to be handling the Mozilla CVS repository with fewer problems
> > than parsecvs.
> >
> > http://cvs2svn.tigris.org/cvs2svn.html
> >
> > Since I'm not a native Python speaker, anyone else want to give a try
> > at changing it to support git?
>
> Hi Jon,
>
> If you haven't tried to import into git with a recent version of
> git-cvsimport, it would be worth a shot.
I tried it a couple of weeks ago and it barely made it into the
conversion. This repository is massive so if the tool doesn't scale
extremely well it quickly collapses.
I can't get it to run all the way, but I estimate that the git
parsecvs tool will need 11GB of RAM to import Mozilla CVS. Each time I
try to import the repository it runs 8-10 hours before failing. 11GB
process means you need a 64b machine.
> As for the tool you've referenced above, it does look pretty good.
> It makes multiple passes and saves to a temp file after each, letting
> you resume from that point and means it can use less memory overall.
This tool imported the Mozilla repository to SVN on the first try. It
needs about 10GB of temp disk space but it never took over 100MB of
RAM while running. It is much more advanced than anything git has. I'd
recommend reworking it to become git's main CVS import tool.
> It can produce a pretty straight forward looking dump file if you
> pass it the "--dump-only" option, rather than it pushing the results
> into svn; for instance:
>
> $ cvs2svn --dump-only --dumpfile DUMPFILE <cvs directory>
>
> It shouldn't be too hard to write a script that imports the revisions
> found in the resulting DUMPFILE into git.
I haven't learned enough about GIT yet to figure out how to import the
change sets.
The cvs2svn tool uses eight passes to convert CVS into something SVN can use.
In the last pass it has turned everything into change sets and it
pipes them to a SVN process that commits them. Mozilla has 205,787
change sets. It would be best if there was some way to pipe things
into git, I suspect the dumpfile for Mozilla would be huge.
This command imports Mozilla CVS, I had to add --use-cvs since the RCS
tools can't handle all the strange options used in Mozilla CVS files.
cvs2svn --use-cvs -s svntest \
--force-tag=THUNDERBIRD_0_7_RELEASE --force-tag=CVS \
--force-branch=JAVADEV_RTM_20001102 \
--force-branch=XPCOM_BRANCH_LANDING_981104 \
--force-branch=MOZILLA_1_3_BRANCH \
--force-branch=N3 \
--force-branch=SeaMonkey_M4_BRANCH \
--force-branch=NORMANDY_BRANCH \
--force-branch=FASTLOAD_20010529_BRANCH \
--force-branch=MozillaSourceClassic_19981026_BRANCH \
--force-branch=RDF_19981124_BRANCH \
--force-branch=OTIS_TEST_BRANCH \
--force-branch=Netscape61_PR1_Mini_BRANCH \
--force-branch=XPCOM20_BRANCH \
--force-branch=XPC_IDISP_20020417_BRANCH \
--force-branch=RDF_122898_BRANCH \
--force-branch=MOZILLA_1_4_BRANCH \
--force-branch=Netscape_20000922_BRANCH \
--force-branch=NETSCAPE_7_0_OEM_BRANCH \
--force-branch=RDF_19990407_BRANCH \
--force-branch=ALERT_SERVICE_BRANCH \
--force-branch=SeaMonkey_M12_BRANCH \
--force-branch=SpiderMonkey140_NES40Rtm_Branch \
mozilla/mozilla
It takes about 16 hours to convert MozCVS with this command on my
machine. Once you have done the full conversion you can rerun the last
pass without rerunning the others. That makes it easier to develop GIT
support since you don't have to do the entire conversion each time.
cvs2svn -p 8 --use-cvs -s svntest \
--force-tag=THUNDERBIRD_0_7_RELEASE --force-tag=CVS \
--force-branch=JAVADEV_RTM_20001102 \
--force-branch=XPCOM_BRANCH_LANDING_981104 \
--force-branch=MOZILLA_1_3_BRANCH \
--force-branch=N3 \
--force-branch=SeaMonkey_M4_BRANCH \
--force-branch=NORMANDY_BRANCH \
--force-branch=FASTLOAD_20010529_BRANCH \
--force-branch=MozillaSourceClassic_19981026_BRANCH \
--force-branch=RDF_19981124_BRANCH \
--force-branch=OTIS_TEST_BRANCH \
--force-branch=Netscape61_PR1_Mini_BRANCH \
--force-branch=XPCOM20_BRANCH \
--force-branch=XPC_IDISP_20020417_BRANCH \
--force-branch=RDF_122898_BRANCH \
--force-branch=MOZILLA_1_4_BRANCH \
--force-branch=Netscape_20000922_BRANCH \
--force-branch=NETSCAPE_7_0_OEM_BRANCH \
--force-branch=RDF_19990407_BRANCH \
--force-branch=ALERT_SERVICE_BRANCH \
--force-branch=SeaMonkey_M12_BRANCH \
--force-branch=SpiderMonkey140_NES40Rtm_Branch \
mozilla/mozilla
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Bug#322732: [Bluez-devel] [Pkg-bluetooth-maintainers] Bug#322732: more on this bug (was: rfcomm bind fails with obscure error message)
From: Marcel Holtmann @ 2006-06-04 15:46 UTC (permalink / raw)
To: BlueZ development; +Cc: 322732-submitter, 322732
In-Reply-To: <20060604151505.GA16780@esaurito.net>
Hi Filippo,
> > > comments?
> >
> > check for EOPNOTSUPP error code and only then print this error.
>
> allright, I fixed this with the attached patch
the patch has been applied to the CVS now. Thanks.
Regards
Marcel
_______________________________________________
Pkg-bluetooth-maintainers mailing list
Pkg-bluetooth-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-bluetooth-maintainers
^ permalink raw reply
* [lm-sensors] PATCH: hwmon-abituguru-nofans-detect-fix.patch
From: Jean Delvare @ 2006-06-04 15:45 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <4482F184.1040006@hhs.nl>
Hi Hans,
> One of my testers had a problem where the driver only saw 2 of the 4 fan
> sensors his uGuru has, this fixes this:
> -accept 0x40 (bit 6) being high as a valid fan sensor setting for all
> fans not just fan 1, I have a feeling this bit indicates whether or not
> a fan is actually connected .
>
> Signed-off-by: Hans de Goede <j.w.r.degoede at hhs.nl>
Applied, thanks.
> Well this is the first small fix to the uGuru driver I hope it will also
> be the last for atleast a couple of days. If this becomes a daily
> business (which I don't expect it to become) its probably the best to
> bundle fixes and send a patch once a week or do you prefer many small
> patches?
I told you this would happen, remember ;)
I'm totally fine with small patches, they're easier to review, revert
and/or backport.
--
Jean Delvare
^ permalink raw reply
* Re: [patch, -rc5-mm1] locking validator: special rule: 8390.c disable_irq()
From: Steven Rostedt @ 2006-06-04 15:44 UTC (permalink / raw)
To: Alan Cox; +Cc: Arjan van de Ven, Ingo Molnar, Andrew Morton, linux-kernel
In-Reply-To: <20060604153842.GA14801@devserv.devel.redhat.com>
On Sun, 2006-06-04 at 11:38 -0400, Alan Cox wrote:
> On Sun, Jun 04, 2006 at 09:16:01AM -0400, Steven Rostedt wrote:
> > that had its irq misrouted, couldn't it cause a storm if we don't call
> > the handler for it? So really disable_irq is broken for the misrouting
> > case, and perhaps needs to be replaced with a spin_lock_irqsave?
>
> For the ne2k at least that simply is not possible, the latencies are so
> bad that you start dropping serial characters and the like if you do.
>
> The disease is not as bad as the cure..
>
Forgive me on my ignorance of misrouted irqs. I really don't understand
when and why they happen.
But my question still stands (maybe because I don't understand). If we
don't call the handler of the misrouted irq because if disable_irq,
can't we still get an interrupt storm?
-- Steve
^ permalink raw reply
* Re: [Qemu-devel] yet another proposed solution for gcc 4.x
From: Carlo Marcelo Arenas Belon @ 2006-06-04 16:02 UTC (permalink / raw)
To: Paul Brook; +Cc: qemu-devel
In-Reply-To: <200606041246.07373.paul@codesourcery.com>
<SNIP>
> Why bother? As you say gcc4 has issues other than just op.c, so why not just
> compile everything with the old gcc?
using the new gcc for the parts that can compile with it, could lead to better
performance in some cases, as well to help clean up the code for conformance
to newer standards and overall maintainability, while making also clear that
there are at least 2 different uses for gcc.
1) to compile the code for qemu to generate working binaries
2) to generate the code to be used for opcode translation
this will free us to work in whatever technical solutions are needed to fix 2)
in our own schedule without the pressure from all the people that now feel
compelled to "port" qemu to a newer gcc, because it is now the default on
their corresponding distributions.
the long term solution for 2) will be to get the qemu hand written code
generator completed, but could also include having an in tree version of gcc
that can be used for that simple purpose (like a dependant library/tool) or a
reference to an external one as a dependency, and as an intermediate step.
Carlo
PS. eventhough it wasn't the cleanest build, gcc-4.1.1 when used to build
everything but op.c resulted in working binaries on my gentoo 2006.0 amd64
system.
^ permalink raw reply
* Re: [Bluez-devel] cant' update cvs
From: Brad Midgley @ 2006-06-04 15:43 UTC (permalink / raw)
To: listen, BlueZ development
In-Reply-To: <1149431821.7480.6.camel@johannes_01.kapune.local>
Johannes
sorry, looks like the "sf.net" is not always equivalent to "sourceforge.net"
try: bluetooth-alsa.cvs.sourceforge.net
i'll fix the docs now
brad
> Hello,
> I can't update my sources. I get the error-message:
>
> cvs [update aborted]: connect to cvs.sf.net(66.35.250.207):2401 failed:
> No route to host
>
> I try then:
>
> cvs
> -d:pserver:anonymous@bluetooth-alsa.cvs.sf.net:/cvsroot/bluetooth-alsa
> login
>
> and the answer is:
>
> Unknown host bluetooth-alsa.cvs.sf.net.
>
>
>
> Do the files move or is there a problem with cvs?
>
> Thanks a lot
> Johannes
>
>
>
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply
* [PATCH] jfs: possible deadlocks - continue
From: Evgeniy Dushistov @ 2006-06-04 15:44 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: jfs-discussion, linux-kernel, linux-fsdevel
For some reasons my post about "possible deadlocks"
didn't appear in jfs-discussion@lists.sourceforge.net.
>====================================
>[ BUG: possible deadlock detected! ]
>------------------------------------
>mount/5587 is trying to acquire lock:
> (&jfs_ip->commit_mutex){--..}, at: [<c02f7096>] mutex_lock+0x12/0x15
>
>but task is already holding lock:
> (&jfs_ip->commit_mutex){--..}, at: [<c02f7096>] mutex_lock+0x12/0x15
>
>which could potentially lead to deadlocks!
>
>other info that might help us debug this:
>2 locks held by mount/5587:
> #0: (&inode->i_mutex){--..}, at: [<c02f7096>] mutex_lock+0x12/0x15
> #1: (&jfs_ip->commit_mutex){--..}, at: [<c02f7096>] mutex_lock+0x12/0x15
>
>stack backtrace:
> [<c0103095>] show_trace+0x16/0x19
> [<c0103562>] dump_stack+0x1a/0x1f
> [<c012ddd7>] __lockdep_acquire+0x6c6/0x907
> [<c012e063>] lockdep_acquire+0x4b/0x63
> [<c02f6f0c>] __mutex_lock_slowpath+0xa4/0x21c
> [<c02f7096>] mutex_lock+0x12/0x15
> [<c01b99be>] jfs_create+0x90/0x2b8
> [<c0161016>] vfs_create+0x91/0xda
> [<c0163939>] open_namei+0x15a/0x5b0
> [<c015326c>] do_filp_open+0x22/0x39
> [<c01541a8>] do_sys_open+0x40/0xbc
> [<c015424d>] sys_open+0x13/0x15
> [<c02f875d>] sysenter_past_esp+0x56/0x8d
I should add that this happened during boot, when root jfs
file system become from ro->rw
I look at code, and see that
1)locks wasn't release in the opposite order in which
they were taken
2)in jfs_rename we lock new_ip, and in "error path" we didn't unlock it
3)I see strange expression: "! !"
May be this worth to fix?
Signed-off-by: Evgeniy Dushistov <dushistov@mail.ru>
---
Index: linux-2.6.16/fs/jfs/namei.c
===================================================================
--- linux-2.6.16.orig/fs/jfs/namei.c
+++ linux-2.6.16/fs/jfs/namei.c
@@ -165,8 +165,8 @@ static int jfs_create(struct inode *dip,
out3:
txEnd(tid);
- mutex_unlock(&JFS_IP(dip)->commit_mutex);
mutex_unlock(&JFS_IP(ip)->commit_mutex);
+ mutex_unlock(&JFS_IP(dip)->commit_mutex);
if (rc) {
free_ea_wmap(ip);
ip->i_nlink = 0;
@@ -300,8 +300,8 @@ static int jfs_mkdir(struct inode *dip,
out3:
txEnd(tid);
- mutex_unlock(&JFS_IP(dip)->commit_mutex);
mutex_unlock(&JFS_IP(ip)->commit_mutex);
+ mutex_unlock(&JFS_IP(dip)->commit_mutex);
if (rc) {
free_ea_wmap(ip);
ip->i_nlink = 0;
@@ -384,8 +384,8 @@ static int jfs_rmdir(struct inode *dip,
if (rc == -EIO)
txAbort(tid, 1);
txEnd(tid);
- mutex_unlock(&JFS_IP(dip)->commit_mutex);
mutex_unlock(&JFS_IP(ip)->commit_mutex);
+ mutex_unlock(&JFS_IP(dip)->commit_mutex);
goto out2;
}
@@ -422,8 +422,8 @@ static int jfs_rmdir(struct inode *dip,
txEnd(tid);
- mutex_unlock(&JFS_IP(dip)->commit_mutex);
mutex_unlock(&JFS_IP(ip)->commit_mutex);
+ mutex_unlock(&JFS_IP(dip)->commit_mutex);
/*
* Truncating the directory index table is not guaranteed. It
@@ -503,8 +503,8 @@ static int jfs_unlink(struct inode *dip,
if (rc == -EIO)
txAbort(tid, 1); /* Marks FS Dirty */
txEnd(tid);
- mutex_unlock(&JFS_IP(dip)->commit_mutex);
mutex_unlock(&JFS_IP(ip)->commit_mutex);
+ mutex_unlock(&JFS_IP(dip)->commit_mutex);
IWRITE_UNLOCK(ip);
goto out1;
}
@@ -527,8 +527,8 @@ static int jfs_unlink(struct inode *dip,
if ((new_size = commitZeroLink(tid, ip)) < 0) {
txAbort(tid, 1); /* Marks FS Dirty */
txEnd(tid);
- mutex_unlock(&JFS_IP(dip)->commit_mutex);
mutex_unlock(&JFS_IP(ip)->commit_mutex);
+ mutex_unlock(&JFS_IP(dip)->commit_mutex);
IWRITE_UNLOCK(ip);
rc = new_size;
goto out1;
@@ -556,9 +556,8 @@ static int jfs_unlink(struct inode *dip,
txEnd(tid);
- mutex_unlock(&JFS_IP(dip)->commit_mutex);
mutex_unlock(&JFS_IP(ip)->commit_mutex);
-
+ mutex_unlock(&JFS_IP(dip)->commit_mutex);
while (new_size && (rc == 0)) {
tid = txBegin(dip->i_sb, 0);
@@ -847,8 +846,8 @@ static int jfs_link(struct dentry *old_d
out:
txEnd(tid);
- mutex_unlock(&JFS_IP(dir)->commit_mutex);
mutex_unlock(&JFS_IP(ip)->commit_mutex);
+ mutex_unlock(&JFS_IP(dir)->commit_mutex);
jfs_info("jfs_link: rc:%d", rc);
return rc;
@@ -1037,8 +1036,8 @@ static int jfs_symlink(struct inode *dip
out3:
txEnd(tid);
- mutex_unlock(&JFS_IP(dip)->commit_mutex);
mutex_unlock(&JFS_IP(ip)->commit_mutex);
+ mutex_unlock(&JFS_IP(dip)->commit_mutex);
if (rc) {
free_ea_wmap(ip);
ip->i_nlink = 0;
@@ -1160,10 +1159,11 @@ static int jfs_rename(struct inode *old_
if (S_ISDIR(new_ip->i_mode)) {
new_ip->i_nlink--;
if (new_ip->i_nlink) {
- mutex_unlock(&JFS_IP(new_dir)->commit_mutex);
- mutex_unlock(&JFS_IP(old_ip)->commit_mutex);
+ mutex_unlock(&JFS_IP(new_ip)->commit_mutex);
if (old_dir != new_dir)
mutex_unlock(&JFS_IP(old_dir)->commit_mutex);
+ mutex_unlock(&JFS_IP(old_ip)->commit_mutex);
+ mutex_unlock(&JFS_IP(new_dir)->commit_mutex);
if (!S_ISDIR(old_ip->i_mode) && new_ip)
IWRITE_UNLOCK(new_ip);
jfs_error(new_ip->i_sb,
@@ -1281,13 +1281,12 @@ static int jfs_rename(struct inode *old_
out4:
txEnd(tid);
-
- mutex_unlock(&JFS_IP(new_dir)->commit_mutex);
- mutex_unlock(&JFS_IP(old_ip)->commit_mutex);
- if (old_dir != new_dir)
- mutex_unlock(&JFS_IP(old_dir)->commit_mutex);
if (new_ip)
mutex_unlock(&JFS_IP(new_ip)->commit_mutex);
+ if (old_dir != new_dir)
+ mutex_unlock(&JFS_IP(old_dir)->commit_mutex);
+ mutex_unlock(&JFS_IP(old_ip)->commit_mutex);
+ mutex_unlock(&JFS_IP(new_dir)->commit_mutex);
while (new_size && (rc == 0)) {
tid = txBegin(new_ip->i_sb, 0);
Index: linux-2.6.16/fs/jfs/jfs_txnmgr.c
===================================================================
--- linux-2.6.16.orig/fs/jfs/jfs_txnmgr.c
+++ linux-2.6.16/fs/jfs/jfs_txnmgr.c
@@ -2944,7 +2944,7 @@ int jfs_sync(void *arg)
* Inode is being freed
*/
list_del_init(&jfs_ip->anon_inode_list);
- } else if (! !mutex_trylock(&jfs_ip->commit_mutex)) {
+ } else if (mutex_trylock(&jfs_ip->commit_mutex)) {
/*
* inode will be removed from anonymous list
* when it is committed
--
/Evgeniy
^ permalink raw reply
* Re: [patch, -rc5-mm1] locking validator: special rule: 8390.c disable_irq()
From: Alan Cox @ 2006-06-04 15:38 UTC (permalink / raw)
To: Steven Rostedt
Cc: Arjan van de Ven, Alan Cox, Ingo Molnar, Andrew Morton,
linux-kernel
In-Reply-To: <1149426961.27696.7.camel@localhost.localdomain>
On Sun, Jun 04, 2006 at 09:16:01AM -0400, Steven Rostedt wrote:
> that had its irq misrouted, couldn't it cause a storm if we don't call
> the handler for it? So really disable_irq is broken for the misrouting
> case, and perhaps needs to be replaced with a spin_lock_irqsave?
For the ne2k at least that simply is not possible, the latencies are so
bad that you start dropping serial characters and the like if you do.
The disease is not as bad as the cure..
^ permalink raw reply
* Re: ANNOUNCE: Linux UWB and Wireless USB project
From: Jan Engelhardt @ 2006-06-04 15:29 UTC (permalink / raw)
To: Pavel Machek
Cc: Inaky Perez-Gonzalez, linux-kernel, linux-usb-devel,
inaky.perez-gonzalez
In-Reply-To: <20060531010701.GB4073@ucw.cz>
>> Intel is pleased to announce the launch of a project to
>> implement Linux kernel support for upcoming hardware that
>> complies with the WiMedia Ultra Wide Band (UWB) and Wireless
>> USB standards.
>
>Does wireless usb also supply power as wired USB does? ;-)
>
>From a physics POV, it is not impossible to do so, but I doubt that USB has
an implementation right now.
Jan Engelhardt
--
^ permalink raw reply
* [lm-sensors] sysfs interface for fan present capability
From: Jean Delvare @ 2006-06-04 15:27 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <4482843D.5020506@hhs.nl>
Hi Hans,
> It looks like I've discover yet another feature of the uguru, a bit in
> the fan bank which seemed to be sometimes 1 sometimes 0 actually seems
> to indicate whether a fan is present or not. I'm not 100% sure, but I'm
> starting to see a pattern and sofar it holds in 100% of the cases I
> have. I'll buy myself an extra 3 wire fan and put it on the aux fan
> connectors then I'll know for sure soon enough.
>
> Which brings me to the question, do we want to export this to userspace
> (I guess we do) and if we do how. May I suggest a readonly boolean
> fan[1-x]_present?
Sure, why not. fan[1-*]_present sounds like a good idea. I wonder how
this works physically. It would be great if other chips could implement
this feature, that would make autoconfig easier for fans. If you
implement this feature in the abituguru driver, just include a patch to
Documentation/hwmon/sysfs-interface describing this new interface file.
--
Jean Delvare
^ permalink raw reply
* Re: Using subversion tools on Mozilla CVS
From: Sean @ 2006-06-04 15:20 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606032009p252ff5fai7401401427ae3ec3@mail.gmail.com>
On Sat, 3 Jun 2006 23:09:00 -0400
"Jon Smirl" <jonsmirl@gmail.com> wrote:
> I found this tool written in Python for importing CVS into Subversion.
> It seems to be handling the Mozilla CVS repository with fewer problems
> than parsecvs.
>
> http://cvs2svn.tigris.org/cvs2svn.html
>
> Since I'm not a native Python speaker, anyone else want to give a try
> at changing it to support git?
Hi Jon,
If you haven't tried to import into git with a recent version of
git-cvsimport, it would be worth a shot.
As for the tool you've referenced above, it does look pretty good.
It makes multiple passes and saves to a temp file after each, letting
you resume from that point and means it can use less memory overall.
It can produce a pretty straight forward looking dump file if you
pass it the "--dump-only" option, rather than it pushing the results
into svn; for instance:
$ cvs2svn --dump-only --dumpfile DUMPFILE <cvs directory>
It shouldn't be too hard to write a script that imports the revisions
found in the resulting DUMPFILE into git.
Sean
^ permalink raw reply
* RE: [LARTC] Not understanding network setup!!
From: Martin A. Brown @ 2006-06-04 15:18 UTC (permalink / raw)
To: lartc
In-Reply-To: <1154.202.123.9.97.1149188252.squirrel@mx.uom.ac.mu>
Visham,
: By the way, do you know if there's a way to distinguish between
: the ACK packet sent during the connection establishment phase of
: a TCP connection and subsequent ACK packets sent during the data
: transfer phase.
:
: I now that the ACK number sent during the connection
: establishment will be equal to the 'sequence number for the SYN
: in the SYN/ACK packet' + 1
:
: Is there a way to distinguish between this 3rd packet and any
: other ACK packet during data transfer w/o having to keep track of
: sequence numbers? Are there other characteristics or options that
: are set in the former and not in the latter?
:
: Basically I want to capture the three packets sent during the
: connection establishment phase of TCP. How can I do that?
How many times (or how quickly) do you need to do this? I have a
somewhat simple-minded solution for you, but it doesn't scale, and
may not actually solve you problem(s).
If you have anything more than a few connections on which you wish
to snoop (to see that they have successfully completed the
handshake) my solution will not work for you. I have used this to
capture the first three packets exchanged on a particular TCP
connection:
tcpdump -nni $INTERFACE -c 3 host $TARGET and port $DPORT and \
'( tcp[tcpflags] & tcp-syn = tcp-syn
or tcp[tcpflags] & tcp-ack = tcp-ack )'
If you are looking at inbound traffic to one of your servers, that
can be a bit trickier. You could, however tcpdump the entire stream
line-bufferered and write a filter (sed/perl) that prints out only
lines showing SYN flag and lines containing 'ack 1 win'.
10:16:11.232505 IP xx.yy.zz.44.7284 > aa.bb.cc.130.25: S 2114067570:2114067570(0) win 5840 <mss 1460,sackOK,timestamp 906238871 0,nop,wscale 2>
10:16:11.257184 IP aa.bb.cc.130.25 > xx.yy.zz.44.7284: S 1756590593:1756590593(0) ack 2114067571 win 5792 <mss 1380,sackOK,timestamp 3428194314 906238871,nop,wscale 2>
10:16:11.257242 IP xx.yy.zz.44.7284 > aa.bb.cc.130.25: . ack 1 win 1460 <nop,nop,timestamp 906238896 3428194314>
Good luck,
-Martin
--
Martin A. Brown
http://linux-ip.net/
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [uml-devel] non-scalar ktime addition and subtraction broken
From: Blaisorblade @ 2006-06-04 15:04 UTC (permalink / raw)
To: user-mode-linux-devel
Cc: Jeff Dike, Thomas Gleixner, linux-kernel, Christopher S. Aker
In-Reply-To: <20060602213455.GA5889@ccure.user-mode-linux.org>
On Friday 02 June 2006 23:34, Jeff Dike wrote:
> On Fri, Jun 02, 2006 at 08:28:37PM +0200, Blaisorblade wrote:
> > Ok, since I now I'll never finish it:
> > $ ll old-patch-scripts/patches/uml-fix-timers.patch
> > -rw-r--r-- 1 paolo paolo 6763 2005-07-24 06:41
> > old-patch-scripts/patches/uml-fix-timers.patch
> >
> > I'm attaching this incomplete patch. It won't apply (it was written
> > likely before 2.6.13 but surely after git was born), it likely introduces
> > bugs and I
> >
> > *) Rename timer() since it's a global and such a name is a "shooting
> > offense". Also, it's difficult to find the def with ctags
> > currently, because people miss fantasy.
>
> This is now gone, replaced by get_time. I can rename that if you feel
> it's objectionable.
I still see (around 2.6.17-rc3) timer() existing in the same place and with
the same definition - even if it now seems unused:
void timer(void)
{
gettimeofday(&xtime, NULL);
timeradd(&xtime, &local_offset, &xtime);
}
> > *) do_timer must be called with xtime_lock held. I'm not sure
> > boot_timer_handler needs this, however I don't think it hurts: it simply
> > disables irq and takes a spinlock.
>
> Fixed.
>
> > *) wall_to_monotonic must be normalized and have a posititive ts_nsec
> > part, see wall_to_monotonic definition and i386 usage in
> > arch/i386/kernel/time.c. Otherwise you can get negative tv_nsec results
> > with
> > do_posix_clock_monotonic_gettime and its callers, including
> > sys_timer_gettime.
>
> Bah, you almost completely diagnosed the bug. Fixed now.
Yep, however I didn't reproduce any misbehaviour at that time.
> > *) Remove um_time() and um_stime() syscalls since they are identical to
> > system-wide ones.
> Fixed. sys_time64 seems to be gone on x86_64, so I deleted it from
> here as well.
Yes, I deleted sys_time64 time ago, forgot to update
arch/um/sys-x86_64/syscall_table.c.
> > *) Move clock_was_set() from do_gettimeofday to do_settimeofday. Not
> > only from the name you guess this is needed, but I indeed verified
> > that for i386 it's in arch/i386/kernel/time.c:do_settimeofday().
> > *) XXX: Probably do_settimeofday should be copied from i386 to
> > replace the current version.
> >
> > *) XXX: do_[gs]ettimeofday() should use seqlocks like in i386,
> > instead of timer_lock() like they do. They also don't synchronize
> > with the rest, beyond the performance problems!
>
> You're probably right. These two are related, and I'm not sure what
> to do with them offhand.
And that's why I didn't send the patches then in first place - I wanted to
complete them (I have too many incomplete patches, and too little time to
finish them :-( ).
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
^ permalink raw reply
* Bug#322732: [Pkg-bluetooth-maintainers] Bug#322732: [Bluez-devel] more on this bug (was: rfcomm bind fails with obscure error message)
From: Filippo Giunchedi @ 2006-06-04 15:15 UTC (permalink / raw)
To: 322732; +Cc: 322732-submitter, bluez-devel
In-Reply-To: <1148908581.31689.35.camel@localhost>
[-- Attachment #1.1.1: Type: text/plain, Size: 381 bytes --]
On Mon, May 29, 2006 at 03:16:21PM +0200, Marcel Holtmann wrote:
> > comments?
>
> check for EOPNOTSUPP error code and only then print this error.
allright, I fixed this with the attached patch
thanks,
filippo
--
Filippo Giunchedi - http://esaurito.net
PGP key: 0x6B79D401
random quote follows:
Either this man is dead or my watch has stopped.
-- Groucho Marx
[-- Attachment #1.1.2: 010_rfcomm_tty.patch --]
[-- Type: text/plain, Size: 426 bytes --]
--- rfcomm/main.c (revision 154)
+++ rfcomm/main.c (working copy)
@@ -172,8 +172,12 @@
req.channel = 1;
}
- if ((err = ioctl(ctl, RFCOMMCREATEDEV, &req)) < 0 )
- perror("Can't create device");
+ if ((err = ioctl(ctl, RFCOMMCREATEDEV, &req)) < 0 ) {
+ if (err == EOPNOTSUPP)
+ fprintf(stderr, "RFCOMM TTY support not available\n");
+ else
+ perror("Can't create device");
+ }
return err;
}
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 211 bytes --]
_______________________________________________
Pkg-bluetooth-maintainers mailing list
Pkg-bluetooth-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-bluetooth-maintainers
^ permalink raw reply
* Re: SMP HT + USB2.0 crash
From: davor emard @ 2006-06-04 15:09 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20060604145420.GA26218@suse.de>
> Either hire a professional sysadmin, or disable CONFIG_PREEMPT
>
I tried it also with SMP enabled and disabled PREEMPT and
big kernel lock preempt - it also crashes.
So there's no need for a yet more professional sysadmin I guess.
Try it yourself on your machine if you have handy some intel 925X series
to crash.
I did it on 2 asus p5ad2-e premium boards, they both crash the same way.
^ permalink raw reply
* [lm-sensors] [PATCH] OpenCores I2C bus driver
From: Jean Delvare @ 2006-06-04 15:00 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <874q0n1505.fsf@sleipner.barco.com>
Hi Peter,
> >>>>> "Peter" = Peter Korsgaard <jacmet at sunsite.dk> writes:
>
> Peter> And here it is - Changes since last time:
>
> Peter> - Minor cleanups from Andrew Morton (2.6.17-rc3-mm1)
> Peter> - Better handling of reserved bits as suggested by Rudolf Marek
> Peter> - Documentation
>
> Comments?
Sorry for the long delay. I finally took some time to (briefly) review
your code. It looks OK overall, and I've applied it with the following
changes I hope you'll approve:
* Reorder includes, asm/* must come after linux/*.
* Tag ocores_i2c_driver.remove __devexit_p().
* Tag the driver EXPERIMENTAL for now. You can send a patch later to
remove that tag once it has spent some times in Linus' tree and is
believed to be completely safe and operational.
* In the documentation, replace the .dev.platform_data construct in struct
initialization, as I seem to remember not all compilers accept it.
Also don't initialize .id to 0 as this is the default for a static
struct.
* A few coding style adjustments.
I also have a few comments about things which looked suspicious to me,
but which I didn't dare to change:
> /* registers */
> #define OCI2C_PRELOW 0
> #define OCI2C_PREHIGH 1
> #define OCI2C_CONTROL 2
> #define OCI2C_DATA 3
> #define OCI2C_CMD 4
> #define OCI2C_STATUS 4
Two registers with the same number? If it's true this deserves a
comment, methinks.
> static struct i2c_adapter ocores_adapter = {
> .owner = THIS_MODULE,
> .name = "i2c-ocores",
> .class = I2C_CLASS_HWMON,
> .algo = &ocores_algorithm,
> .timeout = 2,
> .retries = 1,
> };
Why define .timeout and .retries if you don't use them in your driver?
If you want to change that (or anything else for that matter) please
send an incremental patch. The patch as I applied it for now is
(temporarily) available here:
http://khali.linux-fr.org/devel/i2c/linux-2.6/i2c-opencores-new-driver.patch
Last, I would like you to become the maintainer for this new driver if
you feel like it. If you accept, please send a patch to MAINTAINERS and
I'll apply it.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Testing status of fully virtualized guests (Intel VT) on 64bit XEN unstable
From: Ed Smith @ 2006-06-04 14:58 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 4637 bytes --]
Summary:
Changeset 10264
- 64bit UP and SMP guests boot cleanly
- 32bit UP guests boot clean and 32bit SMP guests still fail to boot
(see failure.7)
- 32bit UP guests sometimes lockup under load with "ata1: command
0x25 timeout" (see failure.4)
- 64bit SMP 2 CPU guest ran through regression tests but failed
several with GPFs or SEGVs (see failure.8)
- 32bit UP guest crashed on user load test with "(XEN) Couldn't alloc
shadow page! dom1 count=952" (see failure.3)
Test Configuration:
Dell Precision WorkStation 380, Dual Core, 2GB, 3 SATA (Intel VT)
64bit XEN Hypervisor on a RHEL4U2 64bit root (/dev/sda)
32bit fully virtualized (HVM) guest RHEL4U2 256MB (/dev/sdb)
pae=1, acpi=1, apic=1
kernargs (noapic with >1 VCPU & SMP kernel)
64bit fully virtualized (HVM) guest RHEL4U2 256MB (/dev/sdc)
pae=1, acpi=1, apic=1
kernargs (noapic with >1 VCPU & SMP kernel)
Boot Tests:
Boot a fully virtualized (HVM) guest to the login prompt
Results are marked Pass|Fail where (n) points to a failure description
Regression Tests:
851 tests (850 ltp tests and one 30 minute user load test)
Tests are marked #Pass/#Fail where (n) points to a failure description
XEN 64bit 2 CPU Hypervisor (booted smp):
----------------------------------------------------------------------
| XEN | Guest Kernel (SMP kernels booted with 2 CPUs) |
| Changeset|-----------------------------------------------------------|
| | 32bit UP | 32bit SMP | 64bit UP | 64bit SMP |
| |--------------|--------------|--------------|--------------|
| | Boot | Test | Boot | Test | Boot | Test | Boot | Test |
|----------|------|-------|------|-------|------|-------|------|-------|
| 10264 | Pass | 847/5 | Fail | | Pass | | Pass | 850/2 |
| | | (1,3) | (7) | | | | |(5,6,8)|
|----------|------|-------|------|-------|------|-------|------|-------|
| 10243 | Pass | 849/3 | Fail | | Pass | | Pass | 851/1 |
| | | (1,3) | (7) | | | | |(5,6,8)|
|----------|------|-------|------|-------|------|-------|------|-------|
| 10200 | Pass | 848/3 | Fail | | Pass | | Pass | 849/2 |
| | | (1,3) | (7) | | | | |(5,6,8)|
|----------|------|-------|------|-------|------|-------|------|-------|
| 10177 | Pass | | Fail | | Pass | | Pass | 848/3 |
| | | | (7) | | | | |(5,6,8)|
|----------|------|-------|------|-------|------|-------|------|-------|
| 10173 | Pass | | Fail | | Pass | | Pass | Fail |
| | | | (7) | | | | |(4,5,6)|
----------------------------------------------------------------------
Multiple Guest Boot Test
XEN 64bit 2 CPU Hypervisor (booted smp):
---------------------------
| XEN | Guest Kernel |
| Changeset|----------------|
| | 32bit UP & |
| | 64bit 2CPU SMP |
| |----------------|
| | Boot | Test |
|----------|------|---------|
| 10264 | Pass | Fail |
| | (10) | (9) |
|----------|------|---------|
| 10243 | Pass | Fail |
| | (10) | (9) |
|----------|------|---------|
| 10200 | Pass | Fail |
| | | (9) |
|----------|------|---------|
| | | |
| | | |
|----------|------|---------|
| | | |
| | | |
---------------------------
Failures:
1. BUG 666: 32bit UP guest fail ltp gettimeofday02:
"Time is going backwards"
2. BUG 664: 32bit UP guest hangs under load:
"ata1: command 0x25 timeout, stat 0x50 host_stat 0x64"
3. BUG 665: 32bit UP guest crashed during user load test:
"(XEN) Couldn't alloc shadow page! dom1 count=952"
4. BUG 664: 64bit SMP 2 CPU guest hangs under load:
"ata1: command 0x25 timeout, stat 0x50 host_stat 0x64"
5. BUG 663: 64bit SMP guest report these messages while running:
"(XEN) spurious IRQ irq got=-1"
6. BUG 662: 64bit SMP guest report this message in ltp pth_str01/2/3:
"(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252"
7. BUG 661: 32bit SMP guest crashes on boot:
"(XEN) __hvm_bug at vmx.c:2289"
8. 64bit 2CPU SMP guest failed several ltp tests with SEGVs or GPF
"sshd[23654] general protection rip:2a9555d426 rsp:7fbfffd000 error 0"
9. 32bit UP guest panic'd when I ran top on both guests
10. If you boot the 64bit guest first the 32bit guest will not boot
[-- Attachment #2: failure.1 --]
[-- Type: text/plain, Size: 1818 bytes --]
File: failure.1
Time Level Message
05:00:50 INFO Reporting status: 'Test Running' for test: ltp_gettimeofday02
05:00:52 INFO Preparing to run test 'ltp_gettimeofday02' using profile: /qa/conductor/profiles/ltp/syscalls/gettimeofday02.xml
05:00:52 INFO Starting test 'ltp_gettimeofday02' using profile: /qa/conductor/profiles/ltp/syscalls/gettimeofday02.xml
05:00:52 INFO Dispatching operation: RemoteShell
05:00:52 FINE Client sequencer got message requesting the start of a new test: ltp_gettimeofday02
05:00:52 FINER Client sequencer sent message of type: 4 with seq num: 1 of size: 289 bytes
05:00:52 FINER Client sequencer handling new operation from control sequencer
05:00:52 FINE Client sequencer looking for class: com.katana.conductor.operations.RemoteShell
05:00:52 INFO Operation RemoteShell running
05:00:52 FINE Client sequencer was told that an operation is now running
05:00:52 INFO RemoteShell: target node(s) = vs177
05:00:52 INFO ssh: /usr/bin/ssh root@vs177 cd /qa/conductor/tests/ltp/testcases/bin; gettimeofday02
05:00:52 FINE ssh: waiting for command to finish
05:00:53 INFO ssh: gettimeofday02 0 INFO : checking if gettimeofday is monotonous, takes 30s
05:00:53 INFO ssh: gettimeofday02 1 FAIL : Time is going backwards (old 1145696453.61428 vs new 1145696453.60660!
05:00:53 FINE executeShellCmd(ssh): exit value is 1
05:00:53 SEVERE RemoteShell: command failed with error = 1
05:00:53 SEVERE Operation RemoteShell failed
05:00:53 SEVERE Reporting status: 'Test Failed' for test: ltp_gettimeofday02
05:00:53 FINE Client sequencer detected operation completed with status of: Fail
05:00:53 FINER Client sequencer sent message of type: 5 with seq num: 2 of size: 429 bytes
05:00:53 SEVERE Crash Collection disabled for queue : RHEL4U2-32b-XEN
05:00:53 INFO Cleaning up after test
[-- Attachment #3: failure.2 --]
[-- Type: text/plain, Size: 7880 bytes --]
File: failure.2
Red Hat Enterprise Linux ES release 4 (Nahant Update 2)
Kernel 2.6.16.13-xen on an x86_64
tst110 login: Bridge firewalling registered
ip_tables: (C) 2000-2006 Netfilter Core Team
ip_tables: (C) 2000-2006 Netfilter Core Team
(XEN) (GUEST: 1) HVM Loader
(XEN) (GUEST: 1) Loading ROMBIOS ...
(XEN) (GUEST: 1) Loading Cirrus VGABIOS ...
(XEN) (GUEST: 1) Loading ACPI ...
(XEN) (GUEST: 1) Loading VMXAssist ...
(XEN) (GUEST: 1) VMX go ...
(XEN) (GUEST: 1) VMXAssist (May 18 2006)
(XEN) (GUEST: 1) Memory size 256 MB
(XEN) (GUEST: 1) E820 map:
(XEN) (GUEST: 1) 0000000000000000 - 000000000009F800 (RAM)
(XEN) (GUEST: 1) 000000000009F800 - 00000000000A0000 (Reserved)
(XEN) (GUEST: 1) 00000000000A0000 - 00000000000C0000 (Type 16)
(XEN) (GUEST: 1) 00000000000F0000 - 0000000000100000 (Reserved)
(XEN) (GUEST: 1) 0000000000100000 - 000000000FFFE000 (RAM)
(XEN) (GUEST: 1) 000000000FFFE000 - 000000000FFFF000 (Type 18)
(XEN) (GUEST: 1) 000000000FFFF000 - 0000000010000000 (Type 17)
(XEN) (GUEST: 1) 0000000010000000 - 0000000010003000 (ACPI NVS)
(XEN) (GUEST: 1) 0000000010003000 - 000000001000D000 (ACPI Data)
(XEN) (GUEST: 1) 00000000FEC00000 - 0000000100000000 (Type 16)
(XEN) (GUEST: 1)
(XEN) (GUEST: 1) Start BIOS ...
(XEN) (GUEST: 1) Starting emulated 16-bit real-mode: ip=F000:FFF0
(XEN) (GUEST: 1) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $
(XEN) (GUEST: 1) Remapping master: ICW2 0x8 -> 0x20
(XEN) (GUEST: 1) Remapping slave: ICW2 0x70 -> 0x28
(XEN) (GUEST: 1) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $
(XEN) domain_crash called from shadow_public.c:1561
(XEN) Domain 1 reported crashed by domain 0 on cpu#0:
(XEN) (GUEST: 2) HVM Loader
(XEN) (GUEST: 2) Loading ROMBIOS ...
(XEN) (GUEST: 2) Loading Cirrus VGABIOS ...
(XEN) (GUEST: 2) Loading ACPI ...
(XEN) (GUEST: 2) Loading VMXAssist ...
(XEN) (GUEST: 2) VMX go ...
(XEN) (GUEST: 2) VMXAssist (May 18 2006)
(XEN) (GUEST: 2) Memory size 256 MB
(XEN) (GUEST: 2) E820 map:
(XEN) (GUEST: 2) 0000000000000000 - 000000000009F800 (RAM)
(XEN) (GUEST: 2) 000000000009F800 - 00000000000A0000 (Reserved)
(XEN) (GUEST: 2) 00000000000A0000 - 00000000000C0000 (Type 16)
(XEN) (GUEST: 2) 00000000000F0000 - 0000000000100000 (Reserved)
(XEN) (GUEST: 2) 0000000000100000 - 000000000FFFE000 (RAM)
(XEN) (GUEST: 2) 000000000FFFE000 - 000000000FFFF000 (Type 18)
(XEN) (GUEST: 2) 000000000FFFF000 - 0000000010000000 (Type 17)
(XEN) (GUEST: 2) 0000000010000000 - 0000000010003000 (ACPI NVS)
(XEN) (GUEST: 2) 0000000010003000 - 000000001000D000 (ACPI Data)
(XEN) (GUEST: 2) 00000000FEC00000 - 0000000100000000 (Type 16)
(XEN) (GUEST: 2)
(XEN) (GUEST: 2) Start BIOS ...
(XEN) (GUEST: 2) Starting emulated 16-bit real-mode: ip=F000:FFF0
(XEN) (GUEST: 2) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $
(XEN) (GUEST: 2) Remapping master: ICW2 0x8 -> 0x20
(XEN) (GUEST: 2) Remapping slave: ICW2 0x70 -> 0x28
(XEN) (GUEST: 2) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $
(XEN) (GUEST: 2) HVMAssist BIOS, 8 cpus, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $
(XEN) (GUEST: 2)
(XEN) (GUEST: 2) ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) (GUEST: 2) ata0 master: QEMU HARDDISK ATA-2 Hard-Disk (10757 MBytes)
(XEN) (GUEST: 2) ata0 slave: Unknown device
(XEN) (GUEST: 2)
(XEN) (GUEST: 2) Booting from Hard Disk...
(XEN) (GUEST: 2) int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) (GUEST: 2) int13_harddisk: function 08, unmapped device for ELDL=81
(XEN) (GUEST: 2) *** int 15h function AX=00C0, BX=0000 not yet supported!
(XEN) (GUEST: 2) int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) (GUEST: 2) KBD: unsupported int 16h function 03
(XEN) (GUEST: 2) int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) (GUEST: 2) *** int 15h function AX=E980, BX=E6F5 not yet supported!
(XEN) (GUEST: 2) int13_harddisk: function 02, unmapped device for ELDL=81
(XEN) (GUEST: 2) int13_harddisk: function 41, unmapped device for ELDL=81
peth1: received packet with own address as source address
peth1: received packet with own address as source address
peth1: received packet with own address as source address
peth1: received packet with own address as source address
peth1: received packet with own address as source address
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x25 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
ata1: command 0x35 timeout, stat 0x50 host_stat 0x64
[-- Attachment #4: failure.3 --]
[-- Type: text/plain, Size: 4573 bytes --]
File: failure.3
Red Hat Enterprise Linux ES release 4 (Nahant Update 2)
Kernel 2.6.16.13-xen on an x86_64
tst110 login: root
Password:
Last login: Tue May 30 07:40:23 on ttyS0
You have new mail.
[root@tst110 ~]# /etc/init.d/xend start
Bridge firewalling registered
ip_tables: (C) 2000-2006 Netfilter Core Team
[root@tst110 ~]# xm info
host : tst110
release : 2.6.16.13-xen
version : #1 SMP Sat May 27 01:40:11 EDT 2006
machine : x86_64
nr_cpus : 1
nr_nodes : 1
sockets_per_node : 1
cores_per_socket : 1
threads_per_core : 1
cpu_mhz : 2793
hw_caps : bfebfbff:20100800:00000000:00000180:0000e43d:00000000:00000001
total_memory : 1023
free_memory : 68
xen_major : 3
xen_minor : 0
xen_extra : -unstable
xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
platform_params : virt_start=0xffff800000000000
xen_changeset : Fri May 26 17:22:30 2006 +0100 10173:954f4dea9da6
cc_compiler : gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)
cc_compile_by : build
cc_compile_domain : katana-technology.com
cc_compile_date : Sat May 27 00:48:47 EDT 2006
[root@tst110 ~]# ip_tables: (C) 2000-2006 Netfilter Core Team
(XEN) (GUEST: 1) HVM Loader
(XEN) (GUEST: 1) Loading ROMBIOS ...
(XEN) (GUEST: 1) Loading Cirrus VGABIOS ...
(XEN) (GUEST: 1) Loading ACPI ...
(XEN) (GUEST: 1) Loading VMXAssist ...
(XEN) (GUEST: 1) VMX go ...
(XEN) (GUEST: 1) VMXAssist (May 27 2006)
(XEN) (GUEST: 1) Memory size 256 MB
(XEN) (GUEST: 1) E820 map:
(XEN) (GUEST: 1) 0000000000000000 - 000000000009F800 (RAM)
(XEN) (GUEST: 1) 000000000009F800 - 00000000000A0000 (Reserved)
(XEN) (GUEST: 1) 00000000000A0000 - 00000000000C0000 (Type 16)
(XEN) (GUEST: 1) 00000000000F0000 - 0000000000100000 (Reserved)
(XEN) (GUEST: 1) 0000000000100000 - 000000000FFFE000 (RAM)
(XEN) (GUEST: 1) 000000000FFFE000 - 000000000FFFF000 (Type 18)
(XEN) (GUEST: 1) 000000000FFFF000 - 0000000010000000 (Type 17)
(XEN) (GUEST: 1) 0000000010000000 - 0000000010003000 (ACPI NVS)
(XEN) (GUEST: 1) 0000000010003000 - 000000001000D000 (ACPI Data)
(XEN) (GUEST: 1) 00000000FEC00000 - 0000000100000000 (Type 16)
(XEN) (GUEST: 1)
(XEN) (GUEST: 1) Start BIOS ...
(XEN) (GUEST: 1) Starting emulated 16-bit real-mode: ip=F000:FFF0
(XEN) (GUEST: 1) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $
(XEN) (GUEST: 1) Remapping master: ICW2 0x8 -> 0x20
(XEN) (GUEST: 1) Remapping slave: ICW2 0x70 -> 0x28
(XEN) (GUEST: 1) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $
(XEN) (GUEST: 1) HVMAssist BIOS, 8 cpus, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $
(XEN) (GUEST: 1)
(XEN) (GUEST: 1) ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) (GUEST: 1) ata0 master: QEMU HARDDISK ATA-2 Hard-Disk (10757 MBytes)
(XEN) (GUEST: 1) ata0 slave: Unknown device
(XEN) (GUEST: 1)
(XEN) (GUEST: 1) Booting from Hard Disk...
(XEN) (GUEST: 1) int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) (GUEST: 1) int13_harddisk: function 08, unmapped device for ELDL=81
(XEN) (GUEST: 1) *** int 15h function AX=00C0, BX=0000 not yet supported!
(XEN) (GUEST: 1) int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) (GUEST: 1) KBD: unsupported int 16h function 03
(XEN) (GUEST: 1) int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) (GUEST: 1) *** int 15h function AX=E980, BX=E6F5 not yet supported!
(XEN) (GUEST: 1) int13_harddisk: function 02, unmapped device for ELDL=81
(XEN) (GUEST: 1) int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) Couldn't alloc shadow page! dom1 count=956
(XEN) Shadow table counts: l1=0 l2=0 hl2=0 snapshot=0
(XEN) domain_crash_sync called from shadow.c:434
(XEN) Domain 1 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-3.0-unstable Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: 0060:[<00000000c01e5ccd>]
(XEN) RFLAGS: 0000000000010207 CONTEXT: hvm
(XEN) rax: 0000000009e24963 rbx: 0000000000000000 rcx: 0000000009e24960
(XEN) rdx: 00000000cb4a6000 rsi: 0000000000007fff rdi: 00000000c13c5748
(XEN) rbp: 00000000cb718000 rsp: 00000000cb4a6f80 r8: 0000000000000000
(XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000
(XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000
(XEN) r15: 0000000000000000 cr0: 000000008005003b cr3: 000000001000f000
(XEN) ds: 007b es: 007b fs: 0000 gs: 0000 ss: 0068 cs: 0060
[-- Attachment #5: failure.4 --]
[-- Type: text/plain, Size: 16321 bytes --]
File: failure.4
Red Hat Enterprise Linux ES release 4 (Nahant Update 2)
Kernel 2.6.16.13-xen on an x86_64
tst177 login: root
Password:
Last login: Fri May 12 10:16:55 on ttyS0
You have new mail.
[root@tst177 ~]# /etc/init.d/xend start
Bridge firewalling registered
ip_tables: (C) 2000-2006 Netfilter Core Team
[root@tst177 ~]# xm info
host : tst177
release : 2.6.16.13-xen
version : #1 SMP Fri May 12 01:45:32 EDT 2006
machine : x86_64
nr_cpus : 2
nr_nodes : 1
sockets_per_node : 1
cores_per_socket : 2
threads_per_core : 1
cpu_mhz : 2793
hw_caps : bfebfbff:20100800:00000000:00000180:0000e43d:00000000:00000001
total_memory : 2047
free_memory : 131
xen_major : 3
xen_minor : 0
xen_extra : -unstable
xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
platform_params : virt_start=0xffff800000000000
xen_changeset : Wed May 10 17:30:42 2006 +0100 9972:91c77df11b43
cc_compiler : gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)
cc_compile_by : build
cc_compile_domain : katana-technology.com
cc_compile_date : Fri May 12 00:48:20 EDT 2006
[root@tst177 ~]# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 1877 2 r----- 35.4
[root@tst177 ~]# ip_tables: (C) 2000-2006 Netfilter Core Team
(XEN) Failed vm entry
(XEN) domain_crash_sync called from vmx.c:2086
(XEN) Domain 1 (vcpu#0) crashed on cpu#1:
(XEN) ----[ Xen-3.0-unstable Not tainted ]----
(XEN) CPU: 1
(XEN) RIP: 0010:[<0000000000100000>]
(XEN) RFLAGS: 0000000000000002 CONTEXT: hvm
(XEN) rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000
(XEN) rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000
(XEN) rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000
(XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000
(XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000
(XEN) r15: 0000000000000000 cr0: 000000000005003b cr3: 0000000000000000
(XEN) ds: 0008 es: 0008 fs: 0008 gs: 0008 ss: 0008 cs: 0010
(XEN) (GUEST: 2) HVM Loader
(XEN) (GUEST: 2) Loading ROMBIOS ...
(XEN) (GUEST: 2) Loading Cirrus VGABIOS ...
(XEN) (GUEST: 2) Loading ACPI ...
(XEN) (GUEST: 2) Loading VMXAssist ...
(XEN) (GUEST: 2) VMX go ...
(XEN) (GUEST: 2) VMXAssist (May 12 2006)
(XEN) (GUEST: 2) Memory size 256 MB
(XEN) (GUEST: 2) E820 map:
(XEN) (GUEST: 2) 0000000000000000 - 000000000009F800 (RAM)
(XEN) (GUEST: 2) 000000000009F800 - 00000000000A0000 (Reserved)
(XEN) (GUEST: 2) 00000000000A0000 - 00000000000C0000 (Type 16)
(XEN) (GUEST: 2) 00000000000F0000 - 0000000000100000 (Reserved)
(XEN) (GUEST: 2) 0000000000100000 - 000000000FFFE000 (RAM)
(XEN) (GUEST: 2) 000000000FFFE000 - 000000000FFFF000 (Type 18)
(XEN) (GUEST: 2) 000000000FFFF000 - 0000000010000000 (Type 17)
(XEN) (GUEST: 2) 0000000010000000 - 0000000010003000 (ACPI NVS)
(XEN) (GUEST: 2) 0000000010003000 - 000000001000D000 (ACPI Data)
(XEN) (GUEST: 2) 00000000FEC00000 - 0000000100000000 (Type 16)
(XEN) (GUEST: 2)
(XEN) (GUEST: 2) Start BIOS ...
(XEN) (GUEST: 2) Starting emulated 16-bit real-mode: ip=F000:FFF0
(XEN) (GUEST: 2) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $
(XEN) (GUEST: 2) Remapping master: ICW2 0x8 -> 0x20
(XEN) (GUEST: 2) Remapping slave: ICW2 0x70 -> 0x28
(XEN) (GUEST: 2) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $
(XEN) (GUEST: 2) HVMAssist BIOS, 8 cpus, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $
(XEN) (GUEST: 2)
(XEN) (GUEST: 2) ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) (GUEST: 2) ata0 master: QEMU HARDDISK ATA-2 Hard-Disk (12997 MBytes)
(XEN) (GUEST: 2) ata0 slave: Unknown device
(XEN) (GUEST: 2)
(XEN) (GUEST: 2) Booting from Hard Disk...
(XEN) (GUEST: 2) int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) (GUEST: 2) int13_harddisk: function 08, unmapped device for ELDL=81
(XEN) (GUEST: 2) *** int 15h function AX=00C0, BX=0000 not yet supported!
(XEN) (GUEST: 2) int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) (GUEST: 2) *** int 15h function AX=EC00, BX=0002 not yet supported!
(XEN) (GUEST: 2) KBD: unsupported int 16h function 03
(XEN) (GUEST: 2) int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) (GUEST: 2) int13_harddisk: function 02, unmapped device for ELDL=81
(XEN) (GUEST: 2) int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) Local APIC Write to read-only register
(XEN) This hvm_vlapic is for P4, no work for De-assert init
(XEN) AP 1 bringup suceeded.
(XEN) (GUEST: 2) Start AP 1 from 00006000 ...
(XEN) (GUEST: 2) Starting emulated 16-bit real-mode: ip=0600:0000
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
Guest is hung at this point
[-- Attachment #6: failure.5 --]
[-- Type: text/plain, Size: 6441 bytes --]
File: failure.5
[root@tst177 ~]# xm info
host : tst177
release : 2.6.16.13-xen
version : #1 SMP Fri May 26 01:47:41 EDT 2006
machine : x86_64
nr_cpus : 2
nr_nodes : 1
sockets_per_node : 1
cores_per_socket : 2
threads_per_core : 1
cpu_mhz : 2793
hw_caps : bfebfbff:20100800:00000000:00000180:0000e43d:00000000:00000001
total_memory : 2047
free_memory : 270
xen_major : 3
xen_minor : 0
xen_extra : -unstable
xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
platform_params : virt_start=0xffff800000000000
xen_changeset : Thu May 25 22:57:44 2006 +0100 10166:ac4a961f7e64
cc_compiler : gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)
cc_compile_by : build
cc_compile_domain : katana-technology.com
cc_compile_date : Fri May 26 00:48:35 EDT 2006
[root@tst177 ~]# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 1737 2 r----- 129.6
[root@tst177 ~]# (XEN) (GUEST: 6) HVM Loader
(XEN) (GUEST: 6) Loading ROMBIOS ...
(XEN) (GUEST: 6) Loading Cirrus VGABIOS ...
(XEN) (GUEST: 6) Loading ACPI ...
(XEN) (GUEST: 6) Loading VMXAssist ...
(XEN) (GUEST: 6) VMX go ...
(XEN) (GUEST: 6) VMXAssist (May 26 2006)
(XEN) (GUEST: 6) Memory size 256 MB
(XEN) (GUEST: 6) E820 map:
(XEN) (GUEST: 6) 0000000000000000 - 000000000009F800 (RAM)
(XEN) (GUEST: 6) 000000000009F800 - 00000000000A0000 (Reserved)
(XEN) (GUEST: 6) 00000000000A0000 - 00000000000C0000 (Type 16)
(XEN) (GUEST: 6) 00000000000F0000 - 0000000000100000 (Reserved)
(XEN) (GUEST: 6) 0000000000100000 - 000000000FFFE000 (RAM)
(XEN) (GUEST: 6) 000000000FFFE000 - 000000000FFFF000 (Type 18)
(XEN) (GUEST: 6) 000000000FFFF000 - 0000000010000000 (Type 17)
(XEN) (GUEST: 6) 0000000010000000 - 0000000010003000 (ACPI NVS)
(XEN) (GUEST: 6) 0000000010003000 - 000000001000D000 (ACPI Data)
(XEN) (GUEST: 6) 00000000FEC00000 - 0000000100000000 (Type 16)
(XEN) (GUEST: 6)
(XEN) (GUEST: 6) Start BIOS ...
(XEN) (GUEST: 6) Starting emulated 16-bit real-mode: ip=F000:FFF0
(XEN) (GUEST: 6) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $
(XEN) (GUEST: 6) Remapping master: ICW2 0x8 -> 0x20
(XEN) (GUEST: 6) Remapping slave: ICW2 0x70 -> 0x28
(XEN) (GUEST: 6) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $
(XEN) (GUEST: 6) HVMAssist BIOS, 8 cpus, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $
(XEN) (GUEST: 6)
(XEN) (GUEST: 6) ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) (GUEST: 6) ata0 master: QEMU HARDDISK ATA-2 Hard-Disk (12997 MBytes)
(XEN) (GUEST: 6) ata0 slave: Unknown device
(XEN) (GUEST: 6)
(XEN) (GUEST: 6) Booting from Hard Disk...
(XEN) (GUEST: 6) int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) (GUEST: 6) int13_harddisk: function 08, unmapped device for ELDL=81
(XEN) (GUEST: 6) *** int 15h function AX=00C0, BX=0000 not yet supported!
(XEN) (GUEST: 6) int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) (GUEST: 6) *** int 15h function AX=EC00, BX=0002 not yet supported!
(XEN) (GUEST: 6) KBD: unsupported int 16h function 03
(XEN) (GUEST: 6) int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) (GUEST: 6) int13_harddisk: function 02, unmapped device for ELDL=81
(XEN) (GUEST: 6) int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) Local APIC Write to read-only register
(XEN) This hvm_vlapic is for P4, no work for De-assert init
(XEN) AP 1 bringup suceeded.
(XEN) (GUEST: 6) Start AP 1 from 00006000 ...
(XEN) (GUEST: 6) Starting emulated 16-bit real-mode: ip=0600:0000
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) spurious IRQ irq got=-1
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
[-- Attachment #7: failure.6 --]
[-- Type: text/plain, Size: 6441 bytes --]
File: failure.6
[root@tst177 ~]# xm info
host : tst177
release : 2.6.16.13-xen
version : #1 SMP Fri May 26 01:47:41 EDT 2006
machine : x86_64
nr_cpus : 2
nr_nodes : 1
sockets_per_node : 1
cores_per_socket : 2
threads_per_core : 1
cpu_mhz : 2793
hw_caps : bfebfbff:20100800:00000000:00000180:0000e43d:00000000:00000001
total_memory : 2047
free_memory : 270
xen_major : 3
xen_minor : 0
xen_extra : -unstable
xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
platform_params : virt_start=0xffff800000000000
xen_changeset : Thu May 25 22:57:44 2006 +0100 10166:ac4a961f7e64
cc_compiler : gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)
cc_compile_by : build
cc_compile_domain : katana-technology.com
cc_compile_date : Fri May 26 00:48:35 EDT 2006
[root@tst177 ~]# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 1737 2 r----- 129.6
[root@tst177 ~]# (XEN) (GUEST: 6) HVM Loader
(XEN) (GUEST: 6) Loading ROMBIOS ...
(XEN) (GUEST: 6) Loading Cirrus VGABIOS ...
(XEN) (GUEST: 6) Loading ACPI ...
(XEN) (GUEST: 6) Loading VMXAssist ...
(XEN) (GUEST: 6) VMX go ...
(XEN) (GUEST: 6) VMXAssist (May 26 2006)
(XEN) (GUEST: 6) Memory size 256 MB
(XEN) (GUEST: 6) E820 map:
(XEN) (GUEST: 6) 0000000000000000 - 000000000009F800 (RAM)
(XEN) (GUEST: 6) 000000000009F800 - 00000000000A0000 (Reserved)
(XEN) (GUEST: 6) 00000000000A0000 - 00000000000C0000 (Type 16)
(XEN) (GUEST: 6) 00000000000F0000 - 0000000000100000 (Reserved)
(XEN) (GUEST: 6) 0000000000100000 - 000000000FFFE000 (RAM)
(XEN) (GUEST: 6) 000000000FFFE000 - 000000000FFFF000 (Type 18)
(XEN) (GUEST: 6) 000000000FFFF000 - 0000000010000000 (Type 17)
(XEN) (GUEST: 6) 0000000010000000 - 0000000010003000 (ACPI NVS)
(XEN) (GUEST: 6) 0000000010003000 - 000000001000D000 (ACPI Data)
(XEN) (GUEST: 6) 00000000FEC00000 - 0000000100000000 (Type 16)
(XEN) (GUEST: 6)
(XEN) (GUEST: 6) Start BIOS ...
(XEN) (GUEST: 6) Starting emulated 16-bit real-mode: ip=F000:FFF0
(XEN) (GUEST: 6) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $
(XEN) (GUEST: 6) Remapping master: ICW2 0x8 -> 0x20
(XEN) (GUEST: 6) Remapping slave: ICW2 0x70 -> 0x28
(XEN) (GUEST: 6) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $
(XEN) (GUEST: 6) HVMAssist BIOS, 8 cpus, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $
(XEN) (GUEST: 6)
(XEN) (GUEST: 6) ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) (GUEST: 6) ata0 master: QEMU HARDDISK ATA-2 Hard-Disk (12997 MBytes)
(XEN) (GUEST: 6) ata0 slave: Unknown device
(XEN) (GUEST: 6)
(XEN) (GUEST: 6) Booting from Hard Disk...
(XEN) (GUEST: 6) int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) (GUEST: 6) int13_harddisk: function 08, unmapped device for ELDL=81
(XEN) (GUEST: 6) *** int 15h function AX=00C0, BX=0000 not yet supported!
(XEN) (GUEST: 6) int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) (GUEST: 6) *** int 15h function AX=EC00, BX=0002 not yet supported!
(XEN) (GUEST: 6) KBD: unsupported int 16h function 03
(XEN) (GUEST: 6) int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) (GUEST: 6) int13_harddisk: function 02, unmapped device for ELDL=81
(XEN) (GUEST: 6) int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) Local APIC Write to read-only register
(XEN) This hvm_vlapic is for P4, no work for De-assert init
(XEN) AP 1 bringup suceeded.
(XEN) (GUEST: 6) Start AP 1 from 00006000 ...
(XEN) (GUEST: 6) Starting emulated 16-bit real-mode: ip=0600:0000
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) spurious IRQ irq got=-1
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
(XEN) spurious IRQ irq got=-1
(XEN) <vlapic_accept_irq>level trig mode repeatedly for vector 252
[-- Attachment #8: failure.7 --]
[-- Type: text/plain, Size: 5227 bytes --]
File: failure.7
Red Hat Enterprise Linux ES release 4 (Nahant Update 2)
Kernel 2.6.16.13-xen on an x86_64
tst177 login: root
Password:
Last login: Tue May 30 07:43:44 from 10.1.2.13
You have new mail.
[root@tst177 ~]# xm info
host : tst177
release : 2.6.16.13-xen
version : #1 SMP Sat May 27 01:40:11 EDT 2006
machine : x86_64
nr_cpus : 1
nr_nodes : 1
sockets_per_node : 1
cores_per_socket : 1
threads_per_core : 1
cpu_mhz : 2793
hw_caps : bfebfbff:20100800:00000000:00000180:0000e43d:00000000:00000001
total_memory : 2047
free_memory : 131
xen_major : 3
xen_minor : 0
xen_extra : -unstable
xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
platform_params : virt_start=0xffff800000000000
xen_changeset : Fri May 26 17:22:30 2006 +0100 10173:954f4dea9da6
cc_compiler : gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)
cc_compile_by : build
cc_compile_domain : katana-technology.com
cc_compile_date : Sat May 27 00:48:47 EDT 2006
[root@tst177 ~]# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 1877 1 r----- 32.5
[root@tst177 ~]# ip_tables: (C) 2000-2006 Netfilter Core Team
(XEN) (GUEST: 1) HVM Loader
(XEN) (GUEST: 1) Loading ROMBIOS ...
(XEN) (GUEST: 1) Loading Cirrus VGABIOS ...
(XEN) (GUEST: 1) Loading ACPI ...
(XEN) (GUEST: 1) Loading VMXAssist ...
(XEN) (GUEST: 1) VMX go ...
(XEN) (GUEST: 1) VMXAssist (May 27 2006)
(XEN) (GUEST: 1) Memory size 256 MB
(XEN) (GUEST: 1) E820 map:
(XEN) (GUEST: 1) 0000000000000000 - 000000000009F800 (RAM)
(XEN) (GUEST: 1) 000000000009F800 - 00000000000A0000 (Reserved)
(XEN) (GUEST: 1) 00000000000A0000 - 00000000000C0000 (Type 16)
(XEN) (GUEST: 1) 00000000000F0000 - 0000000000100000 (Reserved)
(XEN) (GUEST: 1) 0000000000100000 - 000000000FFFE000 (RAM)
(XEN) (GUEST: 1) 000000000FFFE000 - 000000000FFFF000 (Type 18)
(XEN) (GUEST: 1) 000000000FFFF000 - 0000000010000000 (Type 17)
(XEN) (GUEST: 1) 0000000010000000 - 0000000010003000 (ACPI NVS)
(XEN) (GUEST: 1) 0000000010003000 - 000000001000D000 (ACPI Data)
(XEN) (GUEST: 1) 00000000FEC00000 - 0000000100000000 (Type 16)
(XEN) (GUEST: 1)
(XEN) (GUEST: 1) Start BIOS ...
(XEN) (GUEST: 1) Starting emulated 16-bit real-mode: ip=F000:FFF0
(XEN) (GUEST: 1) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $
(XEN) (GUEST: 1) Remapping master: ICW2 0x8 -> 0x20
(XEN) (GUEST: 1) Remapping slave: ICW2 0x70 -> 0x28
(XEN) (GUEST: 1) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $
(XEN) (GUEST: 1) HVMAssist BIOS, 8 cpus, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $
(XEN) (GUEST: 1)
(XEN) (GUEST: 1) ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) (GUEST: 1) ata0 master: QEMU HARDDISK ATA-2 Hard-Disk (12997 MBytes)
(XEN) (GUEST: 1) ata0 slave: Unknown device
(XEN) (GUEST: 1)
(XEN) (GUEST: 1) Booting from Hard Disk...
(XEN) (GUEST: 1) int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) (GUEST: 1) int13_harddisk: function 08, unmapped device for ELDL=81
(XEN) (GUEST: 1) *** int 15h function AX=00C0, BX=0000 not yet supported!
(XEN) (GUEST: 1) int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) (GUEST: 1) KBD: unsupported int 16h function 03
(XEN) (GUEST: 1) int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) (GUEST: 1) *** int 15h function AX=E980, BX=E6F5 not yet supported!
(XEN) (GUEST: 1) int13_harddisk: function 02, unmapped device for ELDL=81
(XEN) (GUEST: 1) int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) __hvm_bug at vmx.c:2284
(XEN) ----[ Xen-3.0-unstable Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: 0060:[<00000000c0100264>]
(XEN) RFLAGS: 0000000000010006 CONTEXT: hvm
(XEN) rax: 0000000000000671 rbx: 00000000c038fff0 rcx: 0000000000000003
(XEN) rdx: 0000000000000fc0 rsi: 000000000000fffe rdi: 00000000c040736c
(XEN) rbp: 000000000048c007 rsp: 00000000c031c058 r8: 0000000000000000
(XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000
(XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000
(XEN) r15: 0000000000000000 cr0: 0000000080050033 cr3: 00000000508f7000
(XEN) ds: 007b es: 007b fs: 0000 gs: 0000 ss: 0068 cs: 0060
(XEN) domain_crash_sync called from vmx.c:2284
(XEN) Domain 1 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-3.0-unstable Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: 0060:[<00000000c0100264>]
(XEN) RFLAGS: 0000000000010006 CONTEXT: hvm
(XEN) rax: 0000000000000671 rbx: 00000000c038fff0 rcx: 0000000000000003
(XEN) rdx: 0000000000000fc0 rsi: 000000000000fffe rdi: 00000000c040736c
(XEN) rbp: 000000000048c007 rsp: 00000000c031c058 r8: 0000000000000000
(XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000
(XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000
(XEN) r15: 0000000000000000 cr0: 0000000080050033 cr3: 00000000508f7000
(XEN) ds: 007b es: 007b fs: 0000 gs: 0000 ss: 0068 cs: 0060
[-- Attachment #9: failure.8 --]
[-- Type: text/plain, Size: 4712 bytes --]
File: failure.8
Test Log:
11:37:20 INFO Reporting status: 'Test Running' for test: ltp_page01
11:37:20 INFO Preparing to run test 'ltp_page01' using profile: /qa/conductor/profiles/ltp/mm/page01.xml
11:37:20 INFO Starting test 'ltp_page01' using profile: /qa/conductor/profiles/ltp/mm/page01.xml
11:37:20 INFO Dispatching operation: RemoteShell
11:37:20 FINE Client sequencer got message requesting the start of a new test: ltp_page01
11:37:20 FINER Client sequencer sent message of type: 4 with seq num: 1 of size: 278 bytes
11:37:20 FINER Client sequencer handling new operation from control sequencer
11:37:20 FINE Client sequencer looking for class: com.katana.conductor.operations.RemoteShell
11:37:20 INFO Operation RemoteShell running
11:37:20 FINE Client sequencer was told that an operation is now running
11:37:20 INFO RemoteShell: target node(s) = vs170
11:37:20 INFO ssh: /usr/bin/ssh root@vs170 cd /qa/conductor/tests/ltp/testcases/bin; page01
11:37:20 FINE ssh: waiting for command to finish
11:37:22 INFO ssh: page01 1 FAIL : Test failed
11:37:22 FINE executeShellCmd(ssh): exit value is 1
11:37:22 SEVERE RemoteShell: command failed with error = 1
11:37:22 SEVERE Operation RemoteShell failed
11:37:22 SEVERE Reporting status: 'Test Failed' for test: ltp_page01
11:37:22 FINE Client sequencer detected operation completed with status of: Fail
11:37:22 FINER Client sequencer sent message of type: 5 with seq num: 2 of size: 422 bytes
11:37:22 SEVERE Crash Collection disabled for queue : RHEL4U2-64b-XEN64
11:37:22 INFO Cleaning up after test
SEGV core produced:
[root@vs170 /]# uname -a
Linux vs170 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:00:54 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux
[root@vs170 /]# cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 2)
[root@vs170 /]# cat /proc/cpuinfo | grep processor
processor : 0
processor : 1
[root@vs170 /]# ls -l /qa/conductor/corefiles/vs170_page01_core.31837
-rw------- 1 root root 204800 May 31 11:37 /qa/conductor/corefiles/vs170_page01_core.31837
[root@vs170 /]# gdb /qa/conductor/tests/ltp/testcases/bin/page01 /qa/conductor/corefiles/vs170_page01_core.31837
GNU gdb Red Hat Linux (6.3.0.0-1.63rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `page01'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib64/libc.so.6...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
#0 0x000000374f3078c3 in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2
(gdb) bt
#0 0x000000374f3078c3 in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2
#1 0x000000374f30a60a in fixup () from /lib64/ld-linux-x86-64.so.2
#2 0x000000374f30a4d2 in _dl_runtime_resolve () from /lib64/ld-linux-x86-64.so.2
#3 0x00000000004013a5 in main (argc=Variable "argc" is not available.
) at page01.c:130
(gdb)
XEN info:
[root@tst177 ~]# xm info
host : tst177
release : 2.6.16.13-xen
version : #1 SMP Wed May 31 01:23:18 EDT 2006
machine : x86_64
nr_cpus : 2
nr_nodes : 1
sockets_per_node : 1
cores_per_socket : 2
threads_per_core : 1
cpu_mhz : 2793
hw_caps : bfebfbff:20100800:00000000:00000180:0000e43d:00000000:00000001
total_memory : 2047
free_memory : 7
xen_major : 3
xen_minor : 0
xen_extra : -unstable
xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
platform_params : virt_start=0xffff800000000000
xen_changeset : Tue May 30 11:44:23 2006 +0100 10177:d5f98d23427a
cc_compiler : gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)
cc_compile_by : build
cc_compile_domain : katana-technology.com
cc_compile_date : Wed May 31 00:44:13 EDT 2006
[root@tst177 ~]# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 1737 2 r----- 3663.0
vs170 5 256 2 ------ 9504.6
[root@tst177 ~]#
[root@tst177 ~]# (XEN) spurious IRQ irq got=-1
[-- Attachment #10: 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: SMP HT + USB2.0 crash
From: davor emard @ 2006-06-04 14:58 UTC (permalink / raw)
To: Con Kolivas; +Cc: linux-kernel
In-Reply-To: <beee72200606040729u4c660583g1b7e669b85db5bca@mail.gmail.com>
I tested it with kernel 2.6.15.7 with nvidia
7174 drivers from which syslog's this oops capture
probably came from but the same thing but less frequently
happens with kernel 2.6.16.19 without nvidia drivers
(nvidia 7174 can't be compiled for 2.6.16.19).
For 2.6.15.7 it takes 2-10 minutes to crash, while for 2.6.16.19
it takes 1-2 days to crash. Yes it is more stable.
Usually it reports the similar oops like I supplied, but sometimes
also 2.6.16.19 reports SMP type crash - sorry I didn't have serial
console connected and didn't write it down - it looks different than
usual oops, contains less registers and no call traces showing
where in the source it crashed (I have never seen such oops before).
2.6.16.19 was running in console only mode and only with
drivers shipped in kernel. No external binary for nvidia, no
external source for ethernet. As the crash location report was
not indicatve to which module caused it, I was removing
one by one suspect module (dvb, firewire ethernet etc) and
reinserting them again until I narrowed it down to the
combination of SMP and EHCI that caused the crash.
Removing either of them makes the machine stable
On 6/4/06, davor emard <davoremard@gmail.com> wrote:
> I tested this _A_LOT_ and it doesn't matter if I
> use "nvidia" binary drivers or x.org's free "nv" or
> have just a text console with no X at all.
> It happens on a production machine :(
>
> Most easily to trigger this bug is to use USB2.0 epson
> scanner over and have scanbuttond running - it will poll
> scan buttons via usb2.0 and crash
>
> On 6/4/06, Con Kolivas <kernel@kolivas.org> wrote:
> > On Sunday 04 June 2006 20:22, davor emard wrote:
> > > Usually SMP + EHCI crashes like this
> >
> > Unless you can reproduce your crash without binary only drivers such as
> the
> > nvidia one your bug report cannot be acted upon.
> >
> > --
> > -ck
> >
>
^ permalink raw reply
* Re: SMP HT + USB2.0 crash
From: Olaf Hering @ 2006-06-04 14:54 UTC (permalink / raw)
To: davor emard; +Cc: Con Kolivas, linux-kernel
In-Reply-To: <beee72200606040729u4c660583g1b7e669b85db5bca@mail.gmail.com>
On Sun, Jun 04, davor emard wrote:
> It happens on a production machine :(
Either hire a professional sysadmin, or disable CONFIG_PREEMPT
^ permalink raw reply
* [linux-lvm] Is it better to use partitions or entire disk for LVM?
From: Mag Gam @ 2006-06-04 14:46 UTC (permalink / raw)
To: LVM general discussion and development
[-- Attachment #1: Type: text/plain, Size: 139 bytes --]
Is it better to create 1 partition on a disk, and use that into the LVM, or
have a blank disk, and use that in the LVM (if possible)?
TIA
[-- Attachment #2: Type: text/html, Size: 154 bytes --]
^ permalink raw reply
* [PATCH] Preliminary branch-import support for git in tailor
From: Yann Dirson @ 2006-06-04 14:59 UTC (permalink / raw)
To: lele, tailor; +Cc: GIT list
[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]
Here is my first try at working with branches with tailor.
This patch applies to current tailor from the darcs repo.
Attached: the patch, and the sample config I used to test it against a
public repo.
Possible improvements:
- the parent-repo parameter is probably generic enough to be useful
for other targets, but it is currently a git-target parameter only
- the change to tailor.py to avoid loosing the initial commit log on
the imported branch probably breaks all other targets because of the
previous issue
- autodetection of the branchpoint would be great, but that surely
deserves to be done in core tailor
- I'll have a try next to add support for pushing git branches to cvs
ones: that will give us a real 2-way sync between cvs and git
Generic problems noticed:
- not all tags from the cvs repo I tested against were imported
(problem specific to the cvs source ?)
- I could not make the cvsps source work to verify it fetches tags
better than the cvs one
- the "projects" parameter has to be specified explicitely to force
the ordering of branch imports - I would have expected the declaration
order to be used.
- it would probably be cleaner to have the *Repository classes in
repository.py moved into their own files: currently we have to modify
a generic file to add backend-specific options, that's not really
generic. What about loading the necessary class when it is found
mentionned in the config ?
Comparison with git-cvsimport
- tailor can give strange results in some cases, but I believe it is
more correct than git-cvsimport. An example is when the cvs branch
you import does not exist in some files for any reason (I had a branch
only for the src/ dir - corrected that now): in that case tailor
correctly shows deletions for those files in the branch initial
commit, whereas git-cvsimport only works on changes, and does not do
anything special (this may be cvsps doing magic behind his back).
- run against a local copy of the repository, tailor is orders of
magnitude slower than git-cvsimport (git-cvsimport returned instantly
on my repo), some profiling has to be done.
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
[-- Attachment #2: darcs.diff --]
[-- Type: text/plain, Size: 4521 bytes --]
diff -rN -u old-tailor/README new-tailor/README
--- old-tailor/README 2006-06-04 16:42:52.000000000 +0200
+++ new-tailor/README 2006-06-04 16:42:52.000000000 +0200
@@ -661,7 +661,21 @@
git
%%%
-.. no specific options
+parent-repo : string
+ Relative path to a git directory to use as a parent. This is useful
+ to import repository branches. If this parameter is empty, the
+ branch has no parent (default behaviour).
+
+parent-rev : string
+ A reference to the git commit which is the parent for the first
+ revision on the branch to be imported (ie, the branch point). It
+ can be a tag name or any syntax acceptable by git (eg. something
+ like "tag~2", if you want to correct the idea of where the
+ branchpoint is.
+
+ Since tailor generates mostly-stable SHA1 revisions, you can also
+ use a SHA1 as branchpoint. Just import your trunk first, find the
+ correct SHA1, and setup and import your branch.
hg
%%
diff -rN -u old-tailor/vcpx/git.py new-tailor/vcpx/git.py
--- old-tailor/vcpx/git.py 2006-06-04 16:42:52.000000000 +0200
+++ new-tailor/vcpx/git.py 2006-06-04 16:42:52.000000000 +0200
@@ -298,19 +298,39 @@
def _prepareTargetRepository(self):
"""
- Execute ``git init-db``.
+ Initialize .git through ``git init-db`` or ``git-clone``.
"""
+ from os import renames
from os.path import join, exists
if not exists(join(self.basedir, self.repository.METADIR)):
- init = ExternalCommand(cwd=self.basedir,
- command=self.repository.command("init-db"))
- init.execute()
-
- if init.exit_status:
- raise TargetInitializationFailure(
- "%s returned status %s" % (str(init), init.exit_status))
+ if self.repository.PARENT_REPO == '':
+ cmd = self.repository.command("init-db")
+ init = ExternalCommand(cwd=self.basedir, command=cmd)
+ init.execute()
+ if init.exit_status:
+ raise TargetInitializationFailure(
+ "%s returned status %s" % (str(init), init.exit_status))
+ else:
+ cmd = self.repository.command("clone", "--shared", "-n",
+ self.repository.PARENT_REPO, 'tmp')
+ clone = ExternalCommand(cwd=self.basedir, command=cmd)
+ clone.execute()
+ if clone.exit_status:
+ raise TargetInitializationFailure(
+ "%s returned status %s" % (str(clone), clone.exit_status))
+
+ renames('%s/%s/tmp/.git' % (self.repository.rootdir, self.repository.subdir),
+ '%s/%s/.git' % (self.repository.rootdir, self.repository.subdir))
+
+ cmd = self.repository.command("reset", "--soft", self.repository.PARENT_REV)
+ reset = ExternalCommand(cwd=self.basedir, command=cmd)
+ reset.execute()
+ if reset.exit_status:
+ raise TargetInitializationFailure(
+ "%s returned status %s" % (str(reset), reset.exit_status))
+
def _prepareWorkingDirectory(self, source_repo):
"""
diff -rN -u old-tailor/vcpx/repository.py new-tailor/vcpx/repository.py
--- old-tailor/vcpx/repository.py 2006-06-04 16:42:52.000000000 +0200
+++ new-tailor/vcpx/repository.py 2006-06-04 16:42:52.000000000 +0200
@@ -287,6 +287,8 @@
def _load(self, project):
Repository._load(self, project)
self.EXECUTABLE = project.config.get(self.name, 'git-command', 'git')
+ self.PARENT_REPO = project.config.get(self.name, 'parent-repo', '')
+ self.PARENT_REV = project.config.get(self.name, 'parent-rev', 'HEAD')
class HgRepository(Repository):
diff -rN -u old-tailor/vcpx/tailor.py new-tailor/vcpx/tailor.py
--- old-tailor/vcpx/tailor.py 2006-06-04 16:42:52.000000000 +0200
+++ new-tailor/vcpx/tailor.py 2006-06-04 16:42:52.000000000 +0200
@@ -74,7 +74,9 @@
raise
try:
- dwd.importFirstRevision(self.source, actual, 'INITIAL'==revision)
+ dwd.importFirstRevision(self.source, actual,
+ self.target.PARENT_REPO != '' or
+ 'INITIAL'==revision)
except:
self.log.critical('Could not import checked out tree in "%s"!',
self.rootdir)
[-- Attachment #3: bigdiesel.tailor --]
[-- Type: text/plain, Size: 895 bytes --]
[DEFAULT]
#verbose=yes
patch-name-format=%(firstlogline)s
remove-first-log-line=True
# that one seems necessary to force ordering
projects = trunk-pull, branch-pull
[trunk-pull]
root-directory = /export/work/yann/tailor/test/root
source = cvs:bigdiesel
target = git:bigdiesel
start-revision = INITIAL
state-file = trunk-pull.state
subdir = trunk
[branch-pull]
root-directory = /export/work/yann/tailor/test/root
source = cvs:bigdiesel
target = git:bigdiesel-branch
start-revision = bigloo-parser INITIAL
state-file = branch-pull.state
subdir = bigloo-parser
[cvs:bigdiesel]
repository = :pserver:anonymous@cvs.savannah.nongnu.org:/sources/dsssl-utils
#repository = /export/work/yann/tailor/test/cvsroot
module = dsssl-utils/bigdiesel
[git:bigdiesel]
[git:bigdiesel-branch]
parent-repo = ../trunk
#parent-rev = 0bbd4b84fce498793db7fdf01388dcb5ed9ada88
parent-rev = bigloo-parser_branchpoint
^ permalink raw reply
* [lm-sensors] PATCH: hwmon-abituguru-nofans-detect-fix.patch
From: Hans de Goede @ 2006-06-04 14:43 UTC (permalink / raw)
To: lm-sensors
Hi all,
One of my testers had a problem where the driver only saw 2 of the 4 fan
sensors his uGuru has, this fixes this:
-accept 0x40 (bit 6) being high as a valid fan sensor setting for all
fans not just fan 1, I have a feeling this bit indicates whether or not
a fan is actually connected .
Signed-off-by: Hans de Goede <j.w.r.degoede at hhs.nl>
Well this is the first small fix to the uGuru driver I hope it will also
be the last for atleast a couple of days. If this becomes a daily
business (which I don't expect it to become) its probably the best to
bundle fixes and send a patch once a week or do you prefer many small
patches?
Regards,
Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hwmon-abituguru-nofans-detect-fix.patch
Type: text/x-patch
Size: 1076 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060604/a7dc407c/attachment.bin
^ permalink raw reply
* [Bluez-devel] cant' update cvs
From: Johannes Kapune @ 2006-06-04 14:37 UTC (permalink / raw)
To: bluez-devel
Hello,
I can't update my sources. I get the error-message:
cvs [update aborted]: connect to cvs.sf.net(66.35.250.207):2401 failed:
No route to host
I try then:
cvs
-d:pserver:anonymous@bluetooth-alsa.cvs.sf.net:/cvsroot/bluetooth-alsa
login
and the answer is:
Unknown host bluetooth-alsa.cvs.sf.net.
Do the files move or is there a problem with cvs?
Thanks a lot
Johannes
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-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.