* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Chris Wright @ 2006-05-09 23:39 UTC (permalink / raw)
To: Stephen Hemminger
Cc: xen-devel, Ian Pratt, netdev, linux-kernel, Chris Wright,
virtualization, Christian Limpach
In-Reply-To: <20060509115633.36b4879e@localhost.localdomain>
* Stephen Hemminger (shemminger@osdl.org) wrote:
> The stuff in /proc could easily just be added attributes to the class_device kobject
> of the net device (and then show up in sysfs).
Agreed, it's on the todo list to drop proc support there. Thought that
was marked in the patch.
> > +#define GRANT_INVALID_REF 0
> > +
> > +#define NET_TX_RING_SIZE __RING_SIZE((struct netif_tx_sring *)0, PAGE_SIZE)
> > +#define NET_RX_RING_SIZE __RING_SIZE((struct netif_rx_sring *)0, PAGE_SIZE)
> > +
> > +static inline void init_skb_shinfo(struct sk_buff *skb)
> > +{
> > + atomic_set(&(skb_shinfo(skb)->dataref), 1);
> > + skb_shinfo(skb)->nr_frags = 0;
> > + skb_shinfo(skb)->frag_list = NULL;
> > +}
>
> Could you use existing sk_buff_head instead of inventing your
> own skb queue?
Hmm, there is some standard skb_queue_tail happening. I don't have a
clear idea what you mean.
> > + u8 mac[ETH_ALEN];
>
> Isn't mac address already stored in dev->dev_addr and/or dev->perm_addr?
Yes, I don't see the reason to keep in twice. It's basically a temp
buffer, but it certainly appears we can eliminate it.
thanks,
-chris
^ permalink raw reply
* RE: ParaGuest cannot see 30GB memory
From: pak333 @ 2006-05-09 23:36 UTC (permalink / raw)
To: Puthiyaparambil, Aravindh, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1056 bytes --]
Hi, I tried with 15GB and that too did not work. kernel panic: not syncing : BUG
This may be related to some of the other traffic I am seeing
- Thanks
- padma
-------------- Original message --------------
From: "Puthiyaparambil, Aravindh" <aravindh.puthiyaparambil@unisys.com>
Xen can only see 16GB of memory in PAE mode. So the greatest amount of memory you can assign to guest is a little less than 16GB – dom0_mem.
Aravindh
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of pak333@comcast.net
Sent: Tuesday, May 09, 2006 7:02 PM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] ParaGuest cannot see 30GB memory
Hi,
I have buit Xen (32 bit) with PAE and can start multiple Paraguests with 4 gig memory, but cannot launch a single VM with more than 4 gb memory. I would like to launch 1 VM with 30GB or so memory. Are there any config paramters like kernel,/inittrd that need to be changed.
I have the ramdisk set to the initrd I used to boot xen with PAE.
Thanks
- padma
[-- Attachment #1.2: Type: text/html, Size: 4954 bytes --]
[-- Attachment #2: Type: message/rfc822, Size: 676 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Chris Wright @ 2006-05-09 23:39 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Chris Wright, linux-kernel, virtualization, xen-devel, Ian Pratt,
Christian Limpach, netdev
In-Reply-To: <20060509115633.36b4879e@localhost.localdomain>
* Stephen Hemminger (shemminger@osdl.org) wrote:
> The stuff in /proc could easily just be added attributes to the class_device kobject
> of the net device (and then show up in sysfs).
Agreed, it's on the todo list to drop proc support there. Thought that
was marked in the patch.
> > +#define GRANT_INVALID_REF 0
> > +
> > +#define NET_TX_RING_SIZE __RING_SIZE((struct netif_tx_sring *)0, PAGE_SIZE)
> > +#define NET_RX_RING_SIZE __RING_SIZE((struct netif_rx_sring *)0, PAGE_SIZE)
> > +
> > +static inline void init_skb_shinfo(struct sk_buff *skb)
> > +{
> > + atomic_set(&(skb_shinfo(skb)->dataref), 1);
> > + skb_shinfo(skb)->nr_frags = 0;
> > + skb_shinfo(skb)->frag_list = NULL;
> > +}
>
> Could you use existing sk_buff_head instead of inventing your
> own skb queue?
Hmm, there is some standard skb_queue_tail happening. I don't have a
clear idea what you mean.
> > + u8 mac[ETH_ALEN];
>
> Isn't mac address already stored in dev->dev_addr and/or dev->perm_addr?
Yes, I don't see the reason to keep in twice. It's basically a temp
buffer, but it certainly appears we can eliminate it.
thanks,
-chris
^ permalink raw reply
* Re: [openib-general] [PATCH 07/16] ehca: interrupt handling routines
From: Segher Boessenkool @ 2006-05-09 23:35 UTC (permalink / raw)
To: Roland Dreier
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <adalktbcgl1.fsf@cisco.com>
> Heiko> Yes, I agree. It would not be an optimal solution, because
> Heiko> other upper level protocols (e.g. SDP, SRP, etc.) or
> Heiko> userspace verbs would not be affected by this
> Heiko> changes. Nevertheless, how can an improved "scaling" or
> Heiko> "SMP" version of IPoIB look like. How could it be
> Heiko> implemented?
>
> The trivial way to do it would be to use the same idea as the current
> ehca driver: just create a thread for receive CQ events and a thread
> for send CQ events, and defer CQ polling into those two threads.
>
> Something even better may be possible by specializing to IPoIB of
> course.
The hardware IRQ should go to some CPU close to the hardware itself.
The
softirq (or whatever else) should go to the same CPU that is handling
the
user-level task for that message. Or a CPU close to it, at least.
Segher
^ permalink raw reply
* Re: [openib-general] [PATCH 07/16] ehca: interrupt handling routines
From: Segher Boessenkool @ 2006-05-09 23:35 UTC (permalink / raw)
To: Roland Dreier
Cc: Heiko J Schick, linux-kernel, openib-general, linuxppc-dev,
Christoph Raisch, Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <adalktbcgl1.fsf@cisco.com>
> Heiko> Yes, I agree. It would not be an optimal solution, because
> Heiko> other upper level protocols (e.g. SDP, SRP, etc.) or
> Heiko> userspace verbs would not be affected by this
> Heiko> changes. Nevertheless, how can an improved "scaling" or
> Heiko> "SMP" version of IPoIB look like. How could it be
> Heiko> implemented?
>
> The trivial way to do it would be to use the same idea as the current
> ehca driver: just create a thread for receive CQ events and a thread
> for send CQ events, and defer CQ polling into those two threads.
>
> Something even better may be possible by specializing to IPoIB of
> course.
The hardware IRQ should go to some CPU close to the hardware itself.
The
softirq (or whatever else) should go to the same CPU that is handling
the
user-level task for that message. Or a CPU close to it, at least.
Segher
^ permalink raw reply
* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Chris Wright @ 2006-05-09 23:37 UTC (permalink / raw)
To: Christoph Hellwig, Chris Wright, linux-kernel, virtualization,
xen-devel, Ian Pratt, Christian Limpach, netdev
In-Reply-To: <20060509115826.GA2213@infradead.org>
* Christoph Hellwig (hch@infradead.org) wrote:
> On Tue, May 09, 2006 at 12:00:34AM -0700, Chris Wright wrote:
> > The network device frontend driver allows the kernel to access network
> > devices exported exported by a virtual machine containing a physical
> > network device driver.
>
> Please don't add procfs code to new network drivers. Especially if it's oopsable
> like the code in this driver by simple device renaming.
Agreed, no reason to keep the cruft around. I thought I had a comment
of the sort in there.
thanks,
-chris
^ permalink raw reply
* Re: [PATCH] Fix console utf8 composing
From: Ingo Oeser @ 2006-05-09 23:31 UTC (permalink / raw)
To: Alexander E. Patrakov; +Cc: Jan Engelhardt, LKML
In-Reply-To: <44604977.1090008@ums.usu.ru>
Hi Alex,
Just for the archive...
On Tuesday, 9. May 2006 09:49, Alexander E. Patrakov wrote:
> Both the current situation and my patch share the defect that an accent
> cannot be put on top of a multibyte character, such as Greek letter alpha.
This is also a problem for proper Vietnamese console support,
which requires two accents per character.
Like "~" on top of "^" ontop of "a".
Regards
Ingo Oeser
^ permalink raw reply
* Re: [openib-general] Re: [PATCH 07/16] ehca: interrupt handling routines
From: Shirley Ma @ 2006-05-09 18:27 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Roland Dreier, linux-kernel, openib-general, linuxppc-dev,
Christoph Raisch, Hoang-Nam Nguyen, Marcus Eder,
openib-general-bounces
In-Reply-To: <20060509164919.GC5063@mellanox.co.il>
[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]
openib-general-bounces@openib.org wrote on 05/09/2006 09:49:19 AM:
> Quoting r. Roland Dreier <rdreier@cisco.com>:
> > The trivial way to do it would be to use the same idea as the current
> > ehca driver: just create a thread for receive CQ events and a thread
> > for send CQ events, and defer CQ polling into those two threads.
I have done some patch like that on top of splitting CQ. The problem I
found that hardware interrupt favors one CPU. Most of the time these two
threads are running on the same cpu according to my debug output. You can
easily find out by cat /proc/interrupts and /proc/irq/XXX/smp_affinity.
ehca has distributed interrupts evenly on SMP, so it gets the benefits of
two threads, and gains much better throughputs.
The interesting thing is the UP results are much better than SMP results
with this approach on mthca.
> For RX, isn't this basically what NAPI is doing?
> Only NAPI seems better, avoiding interrupts completely and avoiding
> latency hit
> by only getting triggered on high load ...
>
> --
> MST
According to some results from different resouces, NAPI only gives 3%-10%
performance improvement on single CQ.
I am trying a simple NAPI patch on splitting CQ now to see how much
performance there.
Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone(Fax): (503) 578-7638
[-- Attachment #2: Type: text/html, Size: 1767 bytes --]
^ permalink raw reply
* Re: [Xen-devel] [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Chris Wright @ 2006-05-09 23:35 UTC (permalink / raw)
To: David Boutcher
Cc: Christian Limpach, chrisw, Herbert Xu, ian.pratt, linux-kernel,
netdev, virtualization, xen-devel
In-Reply-To: <OFE128D80F.BD59DF3E-ON86257169.004F91EA-86257169.004F6870@us.ibm.com>
* David Boutcher (boutcher@us.ibm.com) wrote:
> Then make a generic solution. VMWare supports migration, the Power
> virtualization will get around to it eventually. All will need something
> similar. So either make a common user-land tool, or (if you insist on
> incorrectly driving this into the kernel) add some kind of common hook to
> the TCP/IP stack.
I'm not that fond of the in-kernel solution either. HA failover does
this stuff in userspace, and has the same gratuitous arp requirements.
Perhaps we should see some numbers showing the migration latency
introduced. At the very least, it's easy to factor out as suggested.
thanks,
-chris
^ permalink raw reply
* Re:[PATCH] hptiop: HighPoint RocketRAID 3xxx controller driver
From: Yum Rayan @ 2006-05-09 23:29 UTC (permalink / raw)
To: amah, linux-kernel, linux-scsi, akpm
In-Reply-To: <464B3C0C5BFD894FADEFDD94B6D734E488181E@taus-ies1.dom1.taus.us.thales>
> +static ssize_t hptiop_show_devicelist(struct class_device *class_dev,
> char
> *buf)
There is a one value per sysfs attribute rule. Seems like you are
returning quite some info here.
> + /* map buffer to kernel. */
> + if (ioctl_k.inbuf_size) {
> + ioctl_k.inbuf = kmalloc(ioctl_k.inbuf_size, GFP_KERNEL);
> + if (!ioctl_k.inbuf) {
> + dprintk("scsi%d: fail to alloc inbuf\n",
> + hba->host->host_no);
> + err = -ENOMEM;
> + goto err_exit;
> + }
> +
> + if (copy_from_user(ioctl_k.inbuf,
> + ioctl_u->inbuf, ioctl_k.inbuf_size)) {
> + goto err_exit;
> + }
You are essentially wrapping ioctl with sysfs and passing user space
buffers....
> + .proc_name = driver_name,
I believe this is going away.
> + printk(KERN_INFO "%s %s\n", driver_name_long, driver_ver);
> +
> + return pci_module_init(&hptiop_pci_driver);
> +}
> +
pci_register_driver? pci.h indicates that pci_module_init is being obsoleted...
^ permalink raw reply
* RE: ParaGuest cannot see 30GB memory
From: Puthiyaparambil, Aravindh @ 2006-05-09 23:29 UTC (permalink / raw)
To: pak333, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 860 bytes --]
Xen can only see 16GB of memory in PAE mode. So the greatest amount of
memory you can assign to guest is a little less than 16GB - dom0_mem.
Aravindh
________________________________
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of
pak333@comcast.net
Sent: Tuesday, May 09, 2006 7:02 PM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] ParaGuest cannot see 30GB memory
Hi,
I have buit Xen (32 bit) with PAE and can start multiple Paraguests with
4 gig memory, but cannot launch a single VM with more than 4 gb memory.
I would like to launch 1 VM with 30GB or so memory. Are there any config
paramters like kernel,/inittrd that need to be changed.
I have the ramdisk set to the initrd I used to boot xen with PAE.
Thanks
- padma
[-- Attachment #1.2: Type: text/html, Size: 4827 bytes --]
[-- Attachment #2: 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: "Badness in local_bh_enable at kernel/softirq.c:140" - sgiseeq and conntrack?
From: Sam Cannell @ 2006-05-09 23:29 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <1147217122.20432.14.camel@pkunk.wgtn.cat-it.co.nz>
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
Sorry .. should have said - I'm running 2.6.16.11.
On Wed, 2006-05-10 at 11:25 +1200, Sam Cannell wrote:
> [4294795.111000] Badness in local_bh_enable at kernel/softirq.c:140
> [4294795.111000] Call Trace:
> [4294795.111000] [<8802cfdc>] local_bh_enable+0x78/0xa0
> [4294795.111000] [<c007a70c>] destroy_conntrack+0xdc/0x178
> [ip_conntrack]
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* RE: [PATCH] Add PRCM scheme I on omap2420
From: Kyungmin Park @ 2006-05-09 23:26 UTC (permalink / raw)
To: 'Woodruff, Richard', linux-omap-open-source
In-Reply-To: <EA12F909C0431D458B9D18A176BEE4A5058CE854@dlee02.ent.ti.com>
Hi Richard W.
O.K. the value modified 165MHz.
I have a question about 2430 SDP.
Is it possible to use current kernel source for 2430 platform? or more work
needed to 2430?
Can you tell me where to referece the 2430?
Regards,
Kyungmin Park
--
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 6c78d47..2eb0d04 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -174,7 +174,7 @@ struct prcm_config {
#define RII_CLKSEL_DSP (3 << 0) /* c5x - 200MHz */
#define RII_CLKSEL_DSP_IF (2 << 5) /* c5x - 100MHz */
#define RII_SYNC_DSP (0 << 7) /* Bypass sync */
-#define RII_CLKSEL_IVA (6 << 8) /* iva1 - 200MHz */
+#define RII_CLKSEL_IVA (3 << 8) /* iva1 - 200MHz */
#define RII_SYNC_IVA (0 << 13) /* Bypass sync */
#define RII_CM_CLKSEL_DSP_VAL RII_SYNC_IVA | RII_CLKSEL_IVA | \
RII_SYNC_DSP | RII_CLKSEL_DSP_IF | \
@@ -182,6 +182,27 @@ struct prcm_config {
#define RII_CLKSEL_GFX (2 << 0) /* 50MHz */
#define RII_CM_CLKSEL_GFX_VAL RII_CLKSEL_GFX
+/* 2420-PRCM I 660MHz core */
+#define RI_CLKSEL_L3 (4 << 0) /* 165MHz */
+#define RI_CLKSEL_L4 (2 << 5) /* 82.5MHz */
+#define RI_CLKSEL_USB (4 << 25) /* 41.25MHz */
+#define RI_CM_CLKSEL1_CORE_VAL RI_CLKSEL_USB | \
+ RXX_CLKSEL_SSI | RXX_CLKSEL_VLYNQ |
\
+ RX_CLKSEL_DSS2 | RX_CLKSEL_DSS1 | \
+ RI_CLKSEL_L4 | RI_CLKSEL_L3
+#define RI_CLKSEL_MPU (2 << 0) /* 330MHz */
+#define RI_CM_CLKSEL_MPU_VAL RI_CLKSEL_MPU
+#define RI_CLKSEL_DSP (3 << 0) /* c5x - 220MHz */
+#define RI_CLKSEL_DSP_IF (2 << 5) /* c5x - 110MHz */
+#define RI_SYNC_DSP (1 << 7) /* Activate sync */
+#define RI_CLKSEL_IVA (4 << 8) /* iva1 - 165MHz */
+#define RI_SYNC_IVA (0 << 13) /* Bypass sync */
+#define RI_CM_CLKSEL_DSP_VAL RI_SYNC_IVA | RI_CLKSEL_IVA | \
+ RI_SYNC_DSP | RI_CLKSEL_DSP_IF | \
+ RI_CLKSEL_DSP
+#define RI_CLKSEL_GFX (1 << 0) /* 165MHz */
+#define RI_CM_CLKSEL_GFX_VAL RI_CLKSEL_GFX
+
/* 2420-PRCM VII (boot) */
#define RVII_CLKSEL_L3 (1 << 0)
#define RVII_CLKSEL_L4 (1 << 5)
@@ -300,6 +321,13 @@ struct prcm_config {
* boot (boot)
*/
+/* PRCM I target DPLL = 2*330MHz = 660MHz */
+#define MI_DPLL_MULT_12 (55 << 12)
+#define MI_DPLL_DIV_12 (1 << 8)
+#define MI_CM_CLKSEL1_PLL_12_VAL MX_48M_SRC | MX_54M_SRC | \
+ MI_DPLL_DIV_12 | MI_DPLL_MULT_12 | \
+ MX_APLLS_CLIKIN_12
+
/*
* 2420 Equivalent - mode registers
* PRCM II , target DPLL = 2*300MHz = 600MHz
@@ -352,6 +380,7 @@ struct prcm_config {
* By having the boot loader boot up in the fastest L4 speed available
likely
* will result in something which you can switch between.
*/
+#define V24XX_SDRC_RFR_CTRL_165MHz (0x00044c00 | 1)
#define V24XX_SDRC_RFR_CTRL_133MHz (0x0003de00 | 1)
#define V24XX_SDRC_RFR_CTRL_100MHz (0x0002da01 | 1)
#define V24XX_SDRC_RFR_CTRL_110MHz (0x0002da01 | 1) /* Need to calc */
@@ -394,6 +423,13 @@ struct prcm_config {
* Note: This table needs to be sorted, fastest to slowest.
*-------------------------------------------------------------------------
*/
static struct prcm_config rate_table[] = {
+ /* PRCM I - FAST */
+ {S12M, S660M, S330M, RI_CM_CLKSEL_MPU_VAL, /* 330MHz
ARM */
+ RI_CM_CLKSEL_DSP_VAL, RI_CM_CLKSEL_GFX_VAL,
+ RI_CM_CLKSEL1_CORE_VAL, MI_CM_CLKSEL1_PLL_12_VAL,
+ MX_CLKSEL2_PLL_2x_VAL, 0, V24XX_SDRC_RFR_CTRL_166MHz,
+ RATE_IN_242X},
+
/* PRCM II - FAST */
{S12M, S600M, S300M, RII_CM_CLKSEL_MPU_VAL, /* 300MHz
ARM */
RII_CM_CLKSEL_DSP_VAL, RII_CM_CLKSEL_GFX_VAL,
> -----Original Message-----
> From: Woodruff, Richard [mailto:r-woodruff2@ti.com]
> Sent: Tuesday, May 09, 2006 12:13 AM
> To: kyungmin.park@samsung.com; linux-omap-open-source@linux.omap.com
> Subject: RE: [PATCH] Add PRCM scheme I on omap2420
>
> Kyungmin,
>
> Locally I use the following RFR defines.
>
> #define V24XX_SDRC_RFR_CTRL_165MHz (0x0004e200 | 1)
> #define V24XX_SDRC_RFR_CTRL_133MHz (0x0003de00 | 1)
> #define V24XX_SDRC_RFR_CTRL_110MHz (0x00032801 | 1)
> #define V24XX_SDRC_RFR_CTRL_100MHz (0x0002da01 | 1)
> #define V24XX_SDRC_RFR_CTRL_BYPASS (0x00005000 | 1)
>
> This is for DDR's used on H4 and 2430SDP's. Really I suppose
> we should
> have a board specific table setting imported. Your 44c00
> perhaps could
> be a little better; it really depends on the part. Many of the mDDRs
> seem to be pretty compatible in this regard given a frequency.
>
> I also don't use _166MHz for the speed as it's really set to
> 165. 660/4
> = 165.
>
> Otherwise it looks fine.
>
> Regards,
> Richard W.
>
>
> -----Original Message-----
> From: linux-omap-open-source-bounces+r-woodruff2=ti.com@linux.omap.com
> [mailto:linux-omap-open-source-bounces+r-woodruff2=ti.com@linu
> x.omap.com
> ] On Behalf Of Kyungmin Park
> Sent: Monday, May 08, 2006 1:03 AM
> To: linux-omap-open-source@linux.omap.com
> Subject: [PATCH] Add PRCM scheme I on omap2420
>
> Hi
>
> This patch add PRCM scheme I on omap2420.
>
> The Apollon can run with 660MHz with SDRAM 166MHz.
>
> please check the setting values.
>
> Thank you
> Kyungmin Park
>
> --
>
> diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
> index 6c78d47..94ded7b 100644
> --- a/arch/arm/mach-omap2/clock.h
> +++ b/arch/arm/mach-omap2/clock.h
> @@ -174,7 +174,7 @@ struct prcm_config {
> #define RII_CLKSEL_DSP (3 << 0)
> /* c5x - 200MHz
> */
> #define RII_CLKSEL_DSP_IF (2 << 5) /* c5x - 100MHz
> */
> #define RII_SYNC_DSP (0 << 7) /* Bypass sync
> */
> -#define RII_CLKSEL_IVA (6 << 8)
> /* iva1 - 200MHz
> */
> +#define RII_CLKSEL_IVA (3 << 8)
> /* iva1 - 200MHz
> */
> #define RII_SYNC_IVA (0 << 13) /* Bypass sync
> */
> #define RII_CM_CLKSEL_DSP_VAL RII_SYNC_IVA |
> RII_CLKSEL_IVA |
> \
> RII_SYNC_DSP | RII_CLKSEL_DSP_IF
> | \
> @@ -182,6 +182,27 @@ struct prcm_config {
> #define RII_CLKSEL_GFX (2 << 0)
> /* 50MHz */
> #define RII_CM_CLKSEL_GFX_VAL RII_CLKSEL_GFX
>
> +/* 2420-PRCM I 660MHz core */
> +#define RI_CLKSEL_L3 (4 << 0) /* 165MHz */
> +#define RI_CLKSEL_L4 (2 << 5) /* 82.5MHz */
> +#define RI_CLKSEL_USB (4 << 25)
> /* 41.25MHz */
> +#define RI_CM_CLKSEL1_CORE_VAL RI_CLKSEL_USB | \
> + RXX_CLKSEL_SSI |
> RXX_CLKSEL_VLYNQ |
> \
> + RX_CLKSEL_DSS2 | RX_CLKSEL_DSS1
> | \
> + RI_CLKSEL_L4 | RI_CLKSEL_L3
> +#define RI_CLKSEL_MPU (2 << 0)
> /* 330MHz */
> +#define RI_CM_CLKSEL_MPU_VAL RI_CLKSEL_MPU
> +#define RI_CLKSEL_DSP (3 << 0)
> /* c5x - 220MHz
> */
> +#define RI_CLKSEL_DSP_IF (2 << 5) /* c5x - 110MHz
> */
> +#define RI_SYNC_DSP (1 << 7) /* Activate sync
> */
> +#define RI_CLKSEL_IVA (4 << 8)
> /* iva1 - 165MHz
> */
> +#define RI_SYNC_IVA (0 << 13) /* Bypass sync
> */
> +#define RI_CM_CLKSEL_DSP_VAL RI_SYNC_IVA | RI_CLKSEL_IVA | \
> + RI_SYNC_DSP | RI_CLKSEL_DSP_IF |
> \
> + RI_CLKSEL_DSP
> +#define RI_CLKSEL_GFX (1 << 0)
> /* 165MHz */
> +#define RI_CM_CLKSEL_GFX_VAL RI_CLKSEL_GFX
> +
> /* 2420-PRCM VII (boot) */
> #define RVII_CLKSEL_L3 (1 << 0)
> #define RVII_CLKSEL_L4 (1 << 5)
> @@ -300,6 +321,13 @@ struct prcm_config {
> * boot (boot)
> */
>
> +/* PRCM I target DPLL = 2*330MHz = 660MHz */
> +#define MI_DPLL_MULT_12 (55 << 12)
> +#define MI_DPLL_DIV_12 (1 << 8)
> +#define MI_CM_CLKSEL1_PLL_12_VAL MX_48M_SRC | MX_54M_SRC | \
> + MI_DPLL_DIV_12 | MI_DPLL_MULT_12
> | \
> + MX_APLLS_CLIKIN_12
> +
> /*
> * 2420 Equivalent - mode registers
> * PRCM II , target DPLL = 2*300MHz = 600MHz
> @@ -352,6 +380,7 @@ struct prcm_config {
> * By having the boot loader boot up in the fastest L4 speed
> available
> likely
> * will result in something which you can switch between.
> */
> +#define V24XX_SDRC_RFR_CTRL_166MHz (0x00044c00 | 1)
> #define V24XX_SDRC_RFR_CTRL_133MHz (0x0003de00 | 1)
> #define V24XX_SDRC_RFR_CTRL_100MHz (0x0002da01 | 1)
> #define V24XX_SDRC_RFR_CTRL_110MHz (0x0002da01 | 1) /* Need to calc
> */
> @@ -394,6 +423,13 @@ struct prcm_config {
> * Note: This table needs to be sorted, fastest to slowest.
>
> *-------------------------------------------------------------
> ----------
> --
> */
> static struct prcm_config rate_table[] = {
> + /* PRCM I - FAST */
> + {S12M, S660M, S330M, RI_CM_CLKSEL_MPU_VAL, /*
> 330MHz
> ARM */
> + RI_CM_CLKSEL_DSP_VAL, RI_CM_CLKSEL_GFX_VAL,
> + RI_CM_CLKSEL1_CORE_VAL, MI_CM_CLKSEL1_PLL_12_VAL,
> + MX_CLKSEL2_PLL_2x_VAL, 0, V24XX_SDRC_RFR_CTRL_166MHz,
> + RATE_IN_242X},
> +
> /* PRCM II - FAST */
> {S12M, S600M, S300M, RII_CM_CLKSEL_MPU_VAL, /*
> 300MHz
> ARM */
> RII_CM_CLKSEL_DSP_VAL, RII_CM_CLKSEL_GFX_VAL,
>
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>
>
^ permalink raw reply related
* "Badness in local_bh_enable at kernel/softirq.c:140" - sgiseeq and conntrack?
From: Sam Cannell @ 2006-05-09 23:25 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 3631 bytes --]
Since putting a stateful firewall on my Indy, I'm seeing the following
error in dmesg fairly often - I believe whenever a tcp connection is
closed. Other than filling /var/log/messages, it doesn't seem to be
causing any problems - network connections work fine.
Is this a known problem? Anything I can or should do about it?
[4294795.111000] Badness in local_bh_enable at kernel/softirq.c:140
[4294795.111000] Call Trace:
[4294795.111000] [<8802cfdc>] local_bh_enable+0x78/0xa0
[4294795.111000] [<c007a70c>] destroy_conntrack+0xdc/0x178
[ip_conntrack]
[4294795.111000] [<c007a6a4>] destroy_conntrack+0x74/0x178
[ip_conntrack]
[4294795.111000] [<8817bcbc>] __kfree_skb+0xe4/0x170
[4294795.111000] [<8813ef1c>] sgiseeq_start_xmit+0x2bc/0x388
[4294795.111000] [<c0000b80>] ip_nat_out+0x104/0x130 [iptable_nat]
[4294795.111000] [<c0000ae8>] ip_nat_out+0x6c/0x130 [iptable_nat]
[4294795.111000] [<88190038>] qdisc_restart+0x70/0x22c
[4294795.111000] [<881a2074>] ip_finish_output+0x0/0x2e8
[4294795.111000] [<88182870>] dev_queue_xmit+0x250/0x2f8
[4294795.111000] [<88182854>] dev_queue_xmit+0x234/0x2f8
[4294795.111000] [<88189748>] neigh_resolve_output+0x1d0/0x2f0
[4294795.111000] [<881a2074>] ip_finish_output+0x0/0x2e8
[4294795.111000] [<881a2510>] ip_output+0x1b4/0x3cc
[4294795.111000] [<881a0900>] dst_output+0x0/0x10
[4294795.111000] [<881a2074>] ip_finish_output+0x0/0x2e8
[4294795.111000] [<881a41d0>] ip_push_pending_frames+0x4ec/0x54c
[4294795.111000] [<881c5654>] icmp_push_reply+0x58/0x140
[4294795.111000] [<881c5530>] icmp_glue_bits+0x0/0xcc
[4294795.111000] [<881a0900>] dst_output+0x0/0x10
[4294795.111000] [<881c58dc>] icmp_reply+0x1a0/0x260
[4294795.111000] [<c0079954>] ip_confirm+0x4c/0x60 [ip_conntrack]
[4294795.111000] [<881c6210>] icmp_echo+0x60/0x6c
[4294795.111000] [<c00009c4>] ip_nat_in+0x38/0xf0 [iptable_nat]
[4294795.111000] [<8819cabc>] ip_local_deliver_finish+0x0/0x2b4
[4294795.111000] [<8819d0d4>] ip_rcv_finish+0x0/0x378
[4294795.111000] [<8819cabc>] ip_local_deliver_finish+0x0/0x2b4
[4294795.111000] [<881c6668>] icmp_rcv+0x138/0x220
[4294795.111000] [<8819cf74>] ip_local_deliver+0x204/0x364
[4294795.111000] [<8819cabc>] ip_local_deliver_finish+0x0/0x2b4
[4294795.111000] [<8819d7fc>] ip_rcv+0x3b0/0x6e4
[4294795.111000] [<8802cde0>] __do_softirq+0x90/0x158
[4294795.111000] [<8819d0d4>] ip_rcv_finish+0x0/0x378
[4294795.111000] [<88182f14>] netif_receive_skb+0x1b8/0x250
[4294795.111000] [<88183088>] process_backlog+0xdc/0x20c
[4294795.111000] [<88183284>] net_rx_action+0xcc/0x214
[4294795.111000] [<8802cde0>] __do_softirq+0x90/0x158
[4294795.111000] [<88258ae0>] pidhash_init+0x130/0x1a4
[4294795.111000] [<8802cf38>] do_softirq+0x90/0xbc
[4294795.111000] [<88258ae0>] pidhash_init+0x130/0x1a4
[4294795.111000] [<880065d4>] do_IRQ+0x24/0x34
[4294795.111000] [<88003640>] indyIRQ+0x120/0x180
[4294795.111000] [<8805bec4>] do_wp_page+0x280/0x524
[4294795.111000] [<88258ae0>] pidhash_init+0x130/0x1a4
[4294795.111000] [<88258b14>] pidhash_init+0x164/0x1a4
[4294795.111000] [<88258ae0>] pidhash_init+0x130/0x1a4
[4294795.111000] [<88042574>] ktime_get+0x18/0x3c
[4294795.111000] [<8800eacc>] do_page_fault+0x9c/0x3d0
[4294795.111000] [<8805e328>] find_vma+0x58/0x98
[4294795.111000] [<882581e0>] printk_time_setup+0x8/0x20
[4294795.111000] [<88031b34>] run_timer_softirq+0x34/0x240
[4294795.111000] [<8802cde0>] __do_softirq+0x90/0x158
[4294795.111000] [<8800f264>] tlb_do_page_fault_0+0x104/0x10c
[4294795.111000] [<88003628>] indyIRQ+0x108/0x180
[4294795.111000]
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 01/35] Add XEN config options and disable unsupported config options.
From: Chris Wright @ 2006-05-09 23:25 UTC (permalink / raw)
To: Daniel Walker
Cc: xen-devel, Ian Pratt, linux-kernel, Chris Wright, virtualization,
Christian Limpach
In-Reply-To: <1147190433.21536.28.camel@c-67-180-134-207.hsd1.ca.comcast.net>
* Daniel Walker (dwalker@mvista.com) wrote:
> I guess that true .. Might be better just to support SMP then ..
Yes, and of course Xen does. This is just the smallest functional set of
patches to get discussion, so the SMP bits were dropped for now.
thanks,
-chris
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Pavel Roskin @ 2006-05-09 23:23 UTC (permalink / raw)
To: sean; +Cc: Junio C Hamano, torvalds, Johannes.Schindelin, git
In-Reply-To: <20060509184519.5a707231.seanlkml@sympatico.ca>
On Tue, 2006-05-09 at 18:45 -0400, sean wrote:
> On Tue, 09 May 2006 15:42:25 -0700
> Junio C Hamano <junkio@cox.net> wrote:
> > Does this mean you can have anything other than LF and ']'?
>
> Anything but LF; how's this for ugly:
>
> ["hello Worl\]d \\backslash]
Actually, LF is already handled just fine in the value part:
[proski@dv .git]$ git-repo-config s1.k1 $'v1\nv2'
[proski@dv .git]$ grep [sk]1 config
[s1]
k1 = v1\nv2
Note that quoting doesn't solve this problem (unless multi-line section
headers are allowed), but backslash escaping does.
But I guess everybody prefers quotes for their friendly look.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [RFC PATCH 01/35] Add XEN config options and disable unsupported config options.
From: Chris Wright @ 2006-05-09 23:23 UTC (permalink / raw)
To: Adrian Bunk
Cc: xen-devel, Ian Pratt, linux-kernel, Chris Wright, virtualization,
Christian Limpach
In-Reply-To: <20060509100547.GL3570@stusta.de>
* Adrian Bunk (bunk@stusta.de) wrote:
> On Tue, May 09, 2006 at 12:00:01AM -0700, Chris Wright wrote:
> >...
> > --- linus-2.6.orig/arch/i386/Kconfig
> > +++ linus-2.6/arch/i386/Kconfig
> >...
> > config X86_IO_APIC
> > bool
> > - depends on X86_UP_IOAPIC || (SMP && !(X86_VISWS || X86_VOYAGER))
> > + depends on X86_UP_IOAPIC || (SMP && !(X86_VISWS || X86_VOYAGER || X86_XEN))
> > default y
> >...
>
> <nitpick>not required</nitpick>
True, although SMP is just disabled in this patchset which is a subset
of full Xen support.
thanks,
-chris
^ permalink raw reply
* Re: [RFC PATCH 01/35] Add XEN config options and disable unsupported config options.
From: Chris Wright @ 2006-05-09 23:23 UTC (permalink / raw)
To: Adrian Bunk
Cc: Chris Wright, linux-kernel, virtualization, xen-devel, Ian Pratt,
Christian Limpach
In-Reply-To: <20060509100547.GL3570@stusta.de>
* Adrian Bunk (bunk@stusta.de) wrote:
> On Tue, May 09, 2006 at 12:00:01AM -0700, Chris Wright wrote:
> >...
> > --- linus-2.6.orig/arch/i386/Kconfig
> > +++ linus-2.6/arch/i386/Kconfig
> >...
> > config X86_IO_APIC
> > bool
> > - depends on X86_UP_IOAPIC || (SMP && !(X86_VISWS || X86_VOYAGER))
> > + depends on X86_UP_IOAPIC || (SMP && !(X86_VISWS || X86_VOYAGER || X86_XEN))
> > default y
> >...
>
> <nitpick>not required</nitpick>
True, although SMP is just disabled in this patchset which is a subset
of full Xen support.
thanks,
-chris
^ permalink raw reply
* Re: [RFC PATCH 01/35] Add XEN config options and disable unsupported config options.
From: Chris Wright @ 2006-05-09 23:25 UTC (permalink / raw)
To: Daniel Walker
Cc: Christian Limpach, Chris Wright, linux-kernel, virtualization,
xen-devel, Ian Pratt
In-Reply-To: <1147190433.21536.28.camel@c-67-180-134-207.hsd1.ca.comcast.net>
* Daniel Walker (dwalker@mvista.com) wrote:
> I guess that true .. Might be better just to support SMP then ..
Yes, and of course Xen does. This is just the smallest functional set of
patches to get discussion, so the SMP bits were dropped for now.
thanks,
-chris
^ permalink raw reply
* Re: [Qemu-devel] QEMU 0.8.1
From: Thomas Han @ 2006-05-09 23:18 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <445AB8FE.9040003@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2680 bytes --]
Hi Anthony,
Sorry for the late reply. I did try out the patch with my local build and I
haven't see that "invisible wall" mouse problem for a few days now.
Thanks very much,
Thomas
On 5/4/06, Anthony Liguori <aliguori@us.ibm.com> wrote:
>
> Thomas Han wrote:
> > Hi,
> >
> > For what it's worth. I have also seen this "invisible wall" problem
> > with my mouse for a few weeks off the CVS build too.
>
> Can you try out the following patch. *grumbles about SDL's brokenness*
>
> Regards,
>
> Anthony Liguori
>
> > Since 0.8.1 came out yesterday, Instead of using CVS build, I'm now
> > running Qemu 0.8.1 + kqemu-1.3.0pre6. My host OS is FC5 and I'm
> > running XP inside it.
> >
> > Thanks,
> > Thomas
> >
> > On 5/4/06, *Christian MICHON* < christian.michon@gmail.com
> > <mailto:christian.michon@gmail.com>> wrote:
> >
> > qemu 0.8.0 does not show this invisible barrier issue.
> > if this is worth anything, I use SDL 1.2.9.
> >
> > If someone can reproduce the issue also on linux hosts,
> > there could be a lead.
> >
> > On 5/4/06, Christian MICHON <christian.michon@gmail.com
> > <mailto:christian.michon@gmail.com>> wrote:
> > > I removed manually vnc_display_init, and this is not the
> culprit...
> > > I'll check anyway versus qemu-0.8.0...
> > >
> > --
> > Christian
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org <mailto:Qemu-devel@nongnu.org>
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> >
>
>
>
> diff -r 39a6dd1136c6 sdl.c
> --- a/sdl.c Thu May 04 04:13:13 2006 +0000
> +++ b/sdl.c Thu May 04 21:30:11 2006 -0500
> @@ -280,13 +280,18 @@ static void sdl_update_caption(void)
>
> static void sdl_hide_cursor(void)
> {
> - SDL_SetCursor(sdl_cursor_hidden);
> + if (kbd_mouse_is_absolute()) {
> + SDL_ShowCursor(1);
> + SDL_SetCursor(sdl_cursor_hidden);
> + } else {
> + SDL_ShowCursor(0);
> + }
> }
>
> static void sdl_show_cursor(void)
> {
> if (!kbd_mouse_is_absolute()) {
> - SDL_SetCursor(sdl_cursor_normal);
> + SDL_ShowCursor(1);
> }
> }
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>
[-- Attachment #2: Type: text/html, Size: 4400 bytes --]
^ permalink raw reply
* RE: Information for setting up SMT related parameters on linux 2.6.16 on POWER5
From: Meswani, Mitesh @ 2006-05-09 23:17 UTC (permalink / raw)
To: Segher Boessenkool, will_schmidt; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <18583972-9E29-4B52-BF2E-53102F1794EB@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2833 bytes --]
Thanks guys
That answered so many of my questions.
If I were to use these macros from user space, would they remain set until next reboot or change ? POWER5 allows priorities 2 through 4 for user apps, so considering this, and the fact that the normal prioirity is level 4, if a user app resets it to say 2 and then finishes without changing it back to 4 , would all the subsequent user apps run at the new level 2. I wonder what I am saying even makes sense, because the kernel internally throttles the priority for various sections of the kernel code and it may even overwrite it.
On a slightly unrelated note, I appended some boot parameters like smt-enabled=on/off to /etc/lilo.conf and unfortunately I am not able to see any effect and it boots the same way. I am switching from the AIX world so I maybe doing something dumb, please point out if I am ! This kind of seems to effect the bind processor calls using sys_setaffinity when there are 4 logical processors 0-3 on two physical processors, bind only allows me to set affinity to either cpu 0 or 2, this seems weird to me because my system is booting with two logical cpus and then I set online bit to 1 to turn the remaining on, thereafter I try binding and havent been very successful.
Thanks for all your replies.
Mitesh R. Meswani
Ph.D. Candidate
Research Associate, PLS2 Group
Room 106 F, Department of Computer Science
The University of Texas at El Paso,
El Paso, Texas 79968
Tel: 915 747 8012 (O)
Email: mmeswani@utep.edu
________________________________
From: Segher Boessenkool [mailto:segher@kernel.crashing.org]
Sent: Mon 5/8/2006 5:04 PM
To: will_schmidt@vnet.ibm.com
Cc: Meswani, Mitesh; linuxppc-dev@ozlabs.org; Arnd Bergmann; linux-kernel@vger.kernel.org; cbe-oss-dev@ozlabs.org
Subject: Re: Information for setting up SMT related parameters on linux 2.6.16 on POWER5
> the HMT_* macros are telling firmware that "this processor thread
> should
> run at this priority". Typically used when we're waiting on a
> spinlock.
> I.e. When we are waiting on a spinlock, we hit the HMT_low macro to
> drop
> our threads priority, allowing the other thread to use those extra
> cycles finish it's stuff quicker, and maybe even release the lock
> we're
> waiting for. HMT_* is all within the kernel though, no
> exposure
> to userspace apps.
Actually, those macros translate straight into a single machine insn.
No firmware is involved. See include/asm-powerpc/processor.h. For
example:
#define HMT_very_low() asm volatile("or 31,31,31 # very low
priority")
You can use those same macros from user space, although it is CPU
implementation dependent which priorities you can actually set (you
probably can do low and medium priority).
Segher
[-- Attachment #2: Type: text/html, Size: 4525 bytes --]
^ permalink raw reply
* O dia Mundial da Criança
From: Está a chegar @ 2006-05-09 23:15 UTC (permalink / raw)
To: nfs
[-- Attachment #1.1: Type: text/plain, Size: 464 bytes --]
All-Days
Tshirts & Gifts DIA 1 de Junho é o dia MUNDIAL
da CRIANÇA
Tees para todas as ocasiões.
Vários modelos e cores.
Totalmente personalizáveis.
Promoção Primavera
- Três tees por 19,00
- Três sweats oferta portes
- Pólo Grande qualidade oferta de um boné
Ofereça-lhes com amor
uma t-shirt diferente
Retirem o meu email da vossa lista
[-- Attachment #1.2: Type: text/html, Size: 3195 bytes --]
[-- Attachment #2: dia1.jpg --]
[-- Type: image/jpeg, Size: 11289 bytes --]
^ permalink raw reply
* Re: Some questions about using heavy iptables rules in a Linux box ....
From: John A. Sullivan III @ 2006-05-09 23:14 UTC (permalink / raw)
To: hbchen; +Cc: netfilter-devel
In-Reply-To: <4460B502.4080903@lanl.gov>
On Tue, 2006-05-09 at 09:28 -0600, hbchen wrote:
> Hi,
> I have some questions about using heavy iptables rules in a Linux box.
> 1. Has anyone done a comparison of latency and throughput on traffic
> through an
> Linux node with and without IPtables (using lots of filtering rules)?
> 2. How much CPU time is spending on iptables (heavy filtering rules)?
> 3. Any significant impact (latency and throughput) on 10G ethernet link?
<snip>
I cannot help you much with measurements but I can relate some
production experiences we have had using the ISCS network security
management project with iptables to implement intra-perimeter security.
In these cases, we needed to deal with massive rule sets (>150,000
rules). As a result, we are successfully running this installation on
low end, off-the-shelf iptables appliances from CyberGuard (SG series).
Obviously, these are not handling 10Gbps traffic streams!
The ISCS (http://iscs.sourceforge.net) paradigm uses standard iptables
in a slightly different way to reduce the overhead associated with very
large rule sets such as those needed for interior security. We still
answer the question who has access to what but evaluate who separately
from what. The result is a modular rather than monolithic rule set.
Instead of needing a separate rule for every possible combination of who
and what, we need a single rule for each who and a single rule for each
what and then mix and match them.
In this particular installation, the 150,000 monolithic rules were
reduced to about 13,000 modular rules. I suppose we could do much
better if we implemented ipset. Not only that, but the traversal of the
rules is effectively indexed by "who" thus dramatically improving
performance. And the entire rule set took only a few hours to
automatically create and distribute using ISCS.
Hopefully, you can use a similar approach to reduce the load and
increase processing efficiency in your environment - John
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com
Financially sustainable open source development
http://www.opensourcedevel.com
^ permalink raw reply
* Re: [RFC PATCH 25/35] Add Xen time abstractions
From: Chris Wright @ 2006-05-09 23:13 UTC (permalink / raw)
To: Ingo Oeser
Cc: xen-devel, Ian Pratt, Andi Kleen, linux-kernel, Chris Wright,
virtualization
In-Reply-To: <200605100103.54875.ioe-lkml@rameria.de>
* Ingo Oeser (ioe-lkml@rameria.de) wrote:
> On Tuesday, 9. May 2006 23:50, Andi Kleen wrote:
> > On Tuesday 09 May 2006 09:00, Chris Wright wrote:
> > > Add support for Xen time abstractions. To avoid expensive traps into
> > > the hypervisor, the passage of time is extrapolated from the local TSC
> > > and a set of timestamps and scaling factors exported to the guest via
> > > shared memory. Xen also provides a periodic interrupt facility which
> > > is used to drive updates of xtime and jiffies, and perform the usual
> > > process accounting and profiling.
> >
> > There is far too much code duplication in there. I think you need to
> > refactor the main time.c a bit first and strip that down.
> >
> > Also you can drop all the __x86_64__ support for now.
>
> Isn't time and timer handling a moving target anyway?
> The refactoring will be done by the timer people in a completly different
> manner anyway.
>
> Are you sure, you want to disturb these efforts by requiring another
> refactoring here?
Yes. Otherwise we end up with either duplicated code if the moving
target winds up not moving, or outdated code if it does. I agree with
Andi. It's on the todo list to refactor, but I wanted to get the
patches out even though it's a work in progress.
thanks,
-chris
^ permalink raw reply
* RE: [Qemu-devel] [PATCH]Fix for minor video corruption under Windows
From: Dugger, Donald D @ 2006-05-09 23:12 UTC (permalink / raw)
To: qemu-devel
Leo-
Yeah, I started there but it turns out there are multiple reasons why
that is the wrong place to fix things:
1) `hw/vga.c' only knows about resolution changes, the bug also appears
if you change the pixel size, e.g. 24 bpp to 16 bpp.
2) Technically, because of the lazy screen update, your change would be
too late. To improve performance the vga code is only called
periodically, not after every VRAM change. It is theoretically possible
for the target to change video mode, assume VRAM got reset, do a bitblt
from non-visible VRAM to visible VRAM and then have the `hw/vga.c' code
get called, overwriting the changes done to visible VRAM.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Donald.D.Dugger@intel.com
Ph: (303)440-1368
>-----Original Message-----
>From: qemu-devel-bounces+donald.d.dugger=intel.com@nongnu.org
>[mailto:qemu-devel-bounces+donald.d.dugger=intel.com@nongnu.org
>] On Behalf Of Leonardo E. Reiter
>Sent: Tuesday, May 09, 2006 2:29 PM
>To: qemu-devel@nongnu.org
>Subject: Re: [Qemu-devel] [PATCH]Fix for minor video
>corruption under Windows
>
>Donald...
>
>thanks... I actually posted a patch to fix this sometime ago, but your
>patch seems more thorough and probably more correct. Just FYI, I
>attached my patch again. I will test your patch as well.
>
>Thanks again,
>
>Leo Reiter
>
>Donald D. Dugger wrote:
>> If you change the video resolution while running a Windows
>XP image such that
>> it uses fewer bytes of VRAM (either by using fewer bytes per
>pixel or by
>> lowering the resolution) then some window backgrounds will
>become corrupted.
>> This happens because the Windows XP Cirrus Logic driver
>assumes that VRAM is
>> initialized to 0xff whenever the video mode switches between
>VGA and SVGA.
>>
>> This patch fixes this problem by resetting VRAM whenever a
>VGA/SVGA mode switch
>> occurs.
>>
>> Signed-off-by: Donald.D.Dugger@intel.com
>>
>
>--
>Leonardo E. Reiter
>Vice President of Product Development, CTO
>
>Win4Lin, Inc.
>Virtual Computing that means Business
>Main: +1 512 339 7979
>Fax: +1 512 532 6501
>http://www.win4lin.com
>
^ 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.