* [lm-sensors] latest findings - my older posting from ~ 11 days
From: Rudolf Marek @ 2006-05-05 21:38 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <200605022128.10627.dieter.jurzitza@t-online.de>
Thanks for the info,
ACPI is not to blame in this case. Lets focus on
the HW chipset/other chip bug.
Regards
Rudolf
^ permalink raw reply
* xen versioning scheme
From: Henning Sprang @ 2006-05-05 21:44 UTC (permalink / raw)
To: xen-devel
Hi,
I realized that the changes in xen versions between minor versions 3.0.1
and 3.0.2 seem to be quite big. One example seems to be API changes as
big as pci passthrough (I just read about it but didn't test that) and
that the linux kernel configs seem to be quite different, at least in
the xen section, probably also in the rest.
So I wonder why such big changes are only minor version numbers.
Is there some versioning scheme for the xen releases?
Henning
^ permalink raw reply
* Re: [PATCH][TAKE 4] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
From: John Coffman @ 2006-05-05 21:48 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Alon Bar-Lev, Linux Kernel Mailing List, Barry K. Nathan,
Adrian Bunk, tony.luck
In-Reply-To: <445B96D2.9070301@zytor.com>
At 11:17 AM Friday 5/5/2006, you wrote:
>John Coffman wrote:
>The problem isn't that LILO can't handle more than some number of
>characters; that's a LILO issue and doesn't affect the kernel.
>
>The problem is that some people have reported that the kernel
>crashes if booted with LILO and the size limit is more than
>255. They haven't so far commented on how they observed that, and
>that's a major problem.
Just re-compiling LILO with the COMMAND_LINE_SIZE parameter changed
from 256 to 512 will not work. A .bss area must be moved to avoid
clobbering the kernel header.
>If the issue is that LILO doesn't null-terminate overlong command
>lines, then that's pretty easy to deal with:
>
>- If the kernel sees protocol version <= 2.01, limit is 255+null.
>- If the kernel sees protocol version >= 2.02, but ID is 0x1X, limit
>is 255+null.
>- Otherwise limit is higher.
>
>When LILO is fixed, it has to bump the ID byte version number.
>
>What ID byte values has LILO used?
For the last 8 years LILO has used 0x02 as the loader ID.
If anyone wishes to test a version of LILO that is able to pass a 512
byte command line, then the "22.7.2-beta8" version in the "beta"
directory should be tried. It moves the offending ".bss" area to
avoid the header clobber. However, I have not yet changed the loader ID.
--John
PGP KeyID: 6781C9C8 (good until 31-Dec-2008)
Keyserver at ldap://keyserver.pgp.com OR http://pgp.mit.edu
LILO links at http://freshmeat.net/projects/lilo
and Help link at http://lilo.go.dyndns.org
^ permalink raw reply
* [Qemu-devel] bug reports and suggestions
From: Don Kitchen @ 2006-05-05 21:51 UTC (permalink / raw)
To: qemu-devel
First some suggestions for what they're worth...
$ qemu-img info someimage
image: someimage
file format: qcow
virtual size: 75G (80026361856 bytes)
disk size: 304K
For files with a backing file, has anyone thought about having it print out
the name of the backing file? Particularly this would be helpful to edit in
the case the backing file is relocated. I'm afraid I have been unable to
locate the correct code for this.
Next, it seems the *one* thing QEMU lacks that you-know-who does correctly
is networking, specifically bridged mode. I know about creating a tap device
and sticking it into a bridge (really hasn't worked for me, but that's the
subject for a different day.) I realize that it's a complicated issue
requiring kernel modules, etc, and exponentially more complicated with
cross platform, but I wonder if anyone has considered trying to tie into
the vmware-player's kernel modules and use them? There has to be some sort
of de-facto API for interaction between the modules and the player. Too
rife with IP problems?
And let me express my appreciation both to Fabrice and everyone else who
contributes. In many other emulators it seems like everything is like, Gee,
I wish this had the features that <loud voice> VMWARE </loud> has, but with
QEMU it seems like for everything but network it's Gee, I wish vmware did
that like QEMU. I read the stuff people contribute, stuff like fixing for
cdrom to be moved around, null block writes auto ignored, all great and
welcome stuff, not to mention a built-in vnc server out of the blue, wow.
Now on to the bug reports...Sorry it's in only one email, I thought best
not to blitz many different emails.
If I am starting QEMU on a second X server on another VT using this:
xinit qemu ... -full-screen -- :1
(In this case I am booting windows 2000) and I switch back to :0 *before*
Windoze switches from the splash screen to the light blue background (ie
still booting) X server :1 crashes with the following error:
BadValue (integer parameter out of range for operation)
Could someone else test this? I suspect that Qemu is involved somehow since
it depends on what is happening inside the guest machine. I have not had an
opportunity to test this on any hosts but FC3. Oh yeah, did I mention too
bad VMWARE is all but useless this way?
Next, relating to Image size:
I am creating a large image (320G):
qemu-img create -f raw big.img 312571224
but it's only recognized as being 137 GB. By my calculation there are
exactly 37 significant bits. Is this a limitation of the BIOS or qemu?
The only stuff I've found is about an old 2 GB limit.
What it should be:
Disk /dev/hda: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 1200 9638968+ 83 Linux
/dev/hda2 1201 1260 481950 82 Linux swap / Solaris
/dev/hda3 1261 38913 302447722+ 83 Linux
What it is:
Disk /dev/hda: 137.4 GB, 137438953472 bytes
255 heads, 63 sectors/track, 16709 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 1200 9638968+ 83 Linux
/dev/hda2 1201 1260 481950 82 Linux swap / Solaris
/dev/hda3 1261 38913 302447722+ 83 Linux
Next, relating to the "invisible wall" problem. Sorry I didn't get around to
writing this report earlier, but I have a Mar 25 CVS compile which does not
have this problem and an Apr 21 compile which does. I remember talk about
the tablet stuff about that time but hope this adds a little data to the
issue.
Thanks all for reading.
^ permalink raw reply
* Re: [RFC] Proposed structure for Regulatory/Geographical Wireless database
From: Larry Finger @ 2006-05-05 21:52 UTC (permalink / raw)
To: Dan Williams, netdev, Faidon Liambotis, Rick Jones, Ulrich Kunitz,
Harald Welte, Jouni Malinen, Christoph Hellwig
In-Reply-To: <1146863436.32242.23.camel@localhost.localdomain>
Dan Williams wrote:
> On Fri, 2006-05-05 at 15:14 -0500, Larry Finger wrote:
>> Thanks to all that responded to my earlier RFC. A number of changes in my thinking are based on
>> those comments, which came from Christoph Hellwig, Rick Jones, Ulrich Kunitz, Faidon Liambotis,
>> Jouni Malinen, and Harald Welte. The important points of my proposal are as follows:
>>
>> * The database will be maintained as a text file to be processed by a userland daemon that will
>> transform this database into the data structure needed by the ieee80211 code. In addition to the
>> regulatory data, this file will also contain the information needed for the daemon to set the size
>> of its data arrays dynamically.
>
> Can you explain a bit more about the dynamic array aspect here? What's
> that about? Shouldn't the geo-daemon be able to figure this stuff out
> automatically and tell the ieee80211 stack how many countries and groups
> there are? It has to parse the file anyway, so it should surely know
> how many groups and countries there are after parsing it. (or do I just
> not understand the issues...?)
The kernel only has a single geo object for each wireless interface initialized. The kernel routine
would state which country it wanted to the daemon, which would supply that one from the entities
created one when if parsed the database file. The dynamic aspect is to code the daemon in such a way
that changing the number of countries and/or groups will not necessitate changing the code in the
daemon.
>> * A new routine (ieee80211_init_geo ?) will be written to be called by the driver to load the geo
>> structure into the kernel. Information passed to the daemon will be the country code in ASCII and
>> whether the interface is to be used indoors or outdoors.
>>
>> * Checksum routines will be used to validate the data base. Such a simple scheme will not inhibit
>> anyone with moderate skills from hacking the channel/power settings, but such hacking will require
>> some effort.
>
> What I'm concerned about is error reporting. And as a distro packager,
> I don't want any user to have to touch the geo file. That's fine if
> they do, but nobody should _have_ to.
I agree.
> For error reporting, if the geo file does not exist, or contains invalid
> information, or if the checksum doesn't match for some reason, what's
> the failure case? It's not sufficient to just log that to dmesg and
> fail the attempt, because then a program like wpa_supplicant or
> NetworkManager will have no clue what the problem is if the driver just
> returns ENOENT or EFILESUCKS or whatever. This is the same problem we
> currently have with missing firmware. The failure case is not clearly
> recognizable by the client.
I plan to put the "unknown country" data into the init_geo routine. In case the geo database is not
available, has been corrupted, or the daemon is not running, the parameters will be the minimal set
of only bg channels 1-11 at minimum power and indoor usage. There would be a valid set of geo
parameters in the ieee80211 structure - likely not the ones that were wanted, but a valid set. In
addition, a failure code would be sent back to the driver, and the exact reason for the failure
logged to dmesg.
> If the geo data fails to be read, or fails to be validated by the
> driver, user apps that are trying to make connection attempts need to
> know exactly why the attempt failed, so they can inform users of the
> failure in a smart way. That information needs to come through the
> driver, because user apps that make network connection attempts
> shouldn't have to talk to the regulatory daemon _at all_.
Agreed.
> Conceptually, the regulatory/geo daemon is part of the kernel and the
> driver, and just happens to live in userspace because policy
> +kernel==ohmygodbad. But that means that it's the kernel's
> responsibility to marshal the error information back to clients of the
> wireless driver, not the clients problem to ask the regulatory/geo
> daemon, if it's actually running, what the heck the problem is and why
> the driver returned the error code it did.
>
> U NetworkManager geo-daemon
> ------------|-----------|-----------
> K | |
> driver/iee80211
>
> Think of it as a V, not a triangle. That's where we need to be WRT
> error reporting.
I'm not sure what additional error reporting mechanisms could/should be implemented. Any suggestions?
Larry
^ permalink raw reply
* Re: [PATCH][TAKE 4] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
From: H. Peter Anvin @ 2006-05-05 21:57 UTC (permalink / raw)
To: John Coffman
Cc: Alon Bar-Lev, Linux Kernel Mailing List, Barry K. Nathan,
Adrian Bunk, tony.luck
In-Reply-To: <6.2.3.4.0.20060505144445.03642988@pop-server.san.rr.com>
John Coffman wrote:
>>
>> The problem is that some people have reported that the kernel crashes
>> if booted with LILO and the size limit is more than 255. They haven't
>> so far commented on how they observed that, and that's a major problem.
>
> Just re-compiling LILO with the COMMAND_LINE_SIZE parameter changed
> from 256 to 512 will not work. A .bss area must be moved to avoid
> clobbering the kernel header.
>
Okay, let me ask this:
If the *kernel* limit is modified, but the LILO limit is not, what will happen? This is
the real crux of the matter.
-hpa
^ permalink raw reply
* Re: [PATCH][TAKE 4] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
From: Alon Bar-Lev @ 2006-05-05 22:02 UTC (permalink / raw)
To: John Coffman
Cc: H. Peter Anvin, Linux Kernel Mailing List, Barry K. Nathan,
Adrian Bunk, tony.luck
In-Reply-To: <6.2.3.4.0.20060505144445.03642988@pop-server.san.rr.com>
John Coffman wrote:
> Just re-compiling LILO with the COMMAND_LINE_SIZE parameter changed
> from 256 to 512 will not work. A .bss area must be moved to avoid
> clobbering the kernel header.
Hello John,
The COMMAND_LINE_SIZE should be fixed 256 bytes for boot
protocol < 2.02.
For boot protocol >= 2.02 it can be null terminated 256 and up.
>From LILO code I can see that COMMAND_LINE_SIZE is defined
in lilo.h, so I don't understand how a change in the
COMMAND_LINE_SIZE of the kernel affect LILO.
What we want to achieve is a kernel capable of accepting
command line size greater than 256 bytes... It is OK if LILO
will still pass 256 byte buffer as it already does.
Can you think of a reason why LILO will not work if we do
that? (lilo.h keeps #define COMMAND_LINE_SIZE 256).
Best Regards,
Alon Bar-Lev.
^ permalink raw reply
* [patch] add new uevent
From: Kristen Accardi @ 2006-05-05 22:13 UTC (permalink / raw)
To: linux-kernel; +Cc: arjan, greg
Add dock uevents so that userspace can be notified of dock and undock
events.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
---
include/linux/kobject.h | 2 ++
lib/kobject_uevent.c | 4 ++++
2 files changed, 6 insertions(+)
--- 2.6-git-kca2.orig/include/linux/kobject.h
+++ 2.6-git-kca2/include/linux/kobject.h
@@ -46,6 +46,8 @@ enum kobject_action {
KOBJ_UMOUNT = (__force kobject_action_t) 0x05, /* umount event for block devices (broken) */
KOBJ_OFFLINE = (__force kobject_action_t) 0x06, /* device offline */
KOBJ_ONLINE = (__force kobject_action_t) 0x07, /* device online */
+ KOBJ_UNDOCK = (__force kobject_action_t) 0x08, /* undocking */
+ KOBJ_DOCK = (__force kobject_action_t) 0x09, /* dock */
};
struct kobject {
--- 2.6-git-kca2.orig/lib/kobject_uevent.c
+++ 2.6-git-kca2/lib/kobject_uevent.c
@@ -48,6 +48,10 @@ static char *action_to_string(enum kobje
return "offline";
case KOBJ_ONLINE:
return "online";
+ case KOBJ_DOCK:
+ return "dock";
+ case KOBJ_UNDOCK:
+ return "undock";
default:
return NULL;
}
^ permalink raw reply
* Re: CFI Extended (Intel P30) problems on an ARM PXA255
From: Dan Merillat @ 2006-05-05 22:07 UTC (permalink / raw)
To: David Vrabel; +Cc: linux-mtd
In-Reply-To: <c0c067900605051348u5f7edf0esd23ff0ced74f904e@mail.gmail.com>
> On 5/5/06, David Vrabel <dvrabel@arcom.com> wrote:
> >
> > Perhaps the cache invalidating operation in the MTD map driver you're
> > using is wrong?
And no such luck there, either.
static void pxa25x_map_inval_cache(struct map_info *map, unsigned long from,
ssize_t len)
{
consistent_sync((char *)map->cached + from, len, DMA_FROM_DEVICE);
}
map_info.inval_cache=pxa25x_map_inval_cache;
Is that wrong? It is getting called after writes to flash.
>
> > If you suspect memory timings may be an issue I would advise slowing the
> > timings under Linux to the lowest possible. The experiment you describe
> > here changes two variables (the software and the timings) which is not
> > good practice.
Tried it the other way around as well, set msc0 to boot-up paranoid
mode: 0x7ff07ff8 or longest waits on all reads/writes and no
burst-mode read. No go, same deal.
# mount / -o remount,rw
# touch /tmp/test
# ls
JFFS2 notice: (1) read_unknown: node header CRC failed at 0x048f70.
But it must have been OK earlier.
Node totlen on flash (0x00800080) != totlen from node ref (0x0000004c)
JFFS2 warning: (1) jffs2_do_read_inode_internal: no data nodes found for ino #47
/bin/sh: ls: Input/output error
(xscale-gdb) monitor long 0xff000000
Read long at 0xff000000 : 0x00800080
(xscale-gdb) monitor short 0xff0000aa = 0xff
Wrote short to 0xff0000aa : 0xff
(xscale-gdb) monitor long 0xff000000
Read long at 0xff000000 : 0xea000212
same deal, I can remount RO and use the filesystem (aside from /bin/ls
which is marked invalid until I reboot)
Trying vanilla 2.6.16.14 now.
^ permalink raw reply
* Re: [PATCH 04/13] cell: remove broken __setup_cpu_be function
From: Paul Mackerras @ 2006-05-05 6:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: cbe-oss-dev, linuxppc-dev, linux-kernel, Geoff Levand,
Arnd Bergmann
In-Reply-To: <20060429233920.295209000@localhost.localdomain>
Arnd Bergmann writes:
> From: Geoff Levand <geoffrey.levand@am.sony.com>
>
> This patch removes the incorrect Cell processor setup routine
> __setup_cpu_be. This routine improperly accesses the hypervisor
> page size configuration at SPR HID6. The correct behavior is for
> firmware, or if needed, platform setup code, to set the correct
> page size.
> - .cpu_setup = __setup_cpu_be,
> + .cpu_setup = __setup_cpu_power4,
That looks a bit dodgy. Either just remove the contents of
__setup_cpu_be (leaving only the blr), or define a __setup_cpu_null
that does nothing, or make the identify_cpu not call the cpu setup
function if the pointer is NULL.
Paul.
^ permalink raw reply
* Re: [PATCH] device core: remove redundant call to device_initialize.
From: Russell King @ 2006-05-05 22:14 UTC (permalink / raw)
To: Paolo 'Blaisorblade' Giarrusso
Cc: Andrew Morton, Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20060505153907.12756.23295.stgit@zion.home.lan>
On Fri, May 05, 2006 at 05:39:08PM +0200, Paolo 'Blaisorblade' Giarrusso wrote:
> From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
>
> platform_device_add calls device_register which calls then again
> device_initialize, redundantly.
platform_device_add should be using device_add not device_register.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* [RFC][PATCH] Make sure UART is powered up when dumping MCTRL status
From: George G. Davis @ 2006-05-05 22:15 UTC (permalink / raw)
To: rmk+serial, linux-serial
Greetings,
Since serial devices are powered down when not in use and some of those
devices cannot be accessed when powered down, we need to enable power
around calls to get_mcrtl() when dumping port state via uart_line_info().
This resolves hangs observed on some machines while reading serial device
registers when a port is powered off.
Signed-off-by: George G. Davis <gdavis@mvista.com>
---
drivers/serial/serial_core.c | 12 ++++++++++++
1 files changed, 12 insertions(+)
Index: linux-2.6/drivers/serial/serial_core.c
===================================================================
--- linux-2.6.orig/drivers/serial/serial_core.c
+++ linux-2.6/drivers/serial/serial_core.c
@@ -1652,6 +1652,7 @@ static const char *uart_type(struct uart
static int uart_line_info(char *buf, struct uart_driver *drv, int i)
{
struct uart_state *state = drv->state + i;
+ int pm_state;
struct uart_port *port = state->port;
char stat_buf[32];
unsigned int status;
@@ -1674,9 +1675,16 @@ static int uart_line_info(char *buf, str
if(capable(CAP_SYS_ADMIN))
{
+ mutex_lock(&state->mutex);
+ pm_state = state->pm_state;
+ if (pm_state)
+ uart_change_pm(state, 0);
spin_lock_irq(&port->lock);
status = port->ops->get_mctrl(port);
spin_unlock_irq(&port->lock);
+ if (pm_state)
+ uart_change_pm(state, pm_state);
+ mutex_unlock(&state->mutex);
ret += sprintf(buf + ret, " tx:%d rx:%d",
port->icount.tx, port->icount.rx);
@@ -2068,6 +2076,10 @@ uart_configure_port(struct uart_driver *
uart_report_port(drv, port);
+ /* Power up port for set_mctrl() */
+ if (!uart_console(port))
+ uart_change_pm(state, 0);
+
/*
* Ensure that the modem control lines are de-activated.
* We probably don't need a spinlock around this, but
Comments appreciated. TIA!
--
Regards,
George
^ permalink raw reply
* Re: [PATCH] sendfile compat functions on x86_64 and ia64
From: Alexey Toptygin @ 2006-05-05 22:19 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel, tony.luck
In-Reply-To: <200605052328.21370.ak@suse.de>
On Fri, 5 May 2006, Andi Kleen wrote:
>> On a 32 bit kernel (and on a 64 bit kernel using the native interface),
>> count is passed to sendfile as unsigned. rw_verify_area explicitly casts
>> to signed
>
> To a 64bit signed.
>
>> before checking for negativeness. The only place anywhere in the
>> kernel that count is signed (other than where rw_verify area explicitly
>> casts it for one test) is in the declaration of sys32_sendfile in the
>> x86_64 compat code. I'm pretty sure it's supposed to be unsigned there
>> too, and the current code is a typo.
>
> It's a 32bit signed.
>
> Somehow the 32bit signed has to become a 64bit signed to be caught
> by rw_verify_area(). The only place that can do that is the compat
> layer.
I still think you misunderstand.
According to 32 bit libc, count is an unsigned 32 bit value. This unsigned
32 bit value is given to x86_64's sys32_sendfile, which _thinks_ it's a
signed 32 bit value. sys32_sendfile is passing it to sys_sendfile, which
expects an unsigned 64 bit value, so the compiler sign-extends it to 64
bits, then gives it to sys_sendfile as unsigned 64 bits. sys_sendfile
passes it to do_sendfile with the same type, so it goes there unchanged.
do_sendfile passes it to rw_verify_area with the same type, so it goes
there unchanged. rw_verify_area then does this:
if (unlikely((ssize_t) count < 0))
goto Einval;
I agree that this test will pass if we change the declaration of count to
u32 in sys32_sendfile, but it should pass: this test isn't meant to catch
values that shouldn't be passed by a 32 bit program, it is only protecting
against math involving count wrapping later on in rw_verify_area. The test
agains MAX_NON_LFS (passed via max from sys_sendfile) later in do_sendfile
will still fail and reject values greater than ((1<<31)-1) passed in from
32 bit libc.
The ia64 compat path declares count to be unsigned, and presumably this is
working fine. That path is identical to the above, except sign extension
doesn't happen: a u32 value is just placed in a u64 variable.
As a result, the x86_64 and ia64 compat paths are inconsistent, so I think
one of them needs to change. Since every other path from userland into a
sendfile function has an unsigned count (and none of them appear to be
broken), I think the change needs to be in x86_64 sys32_sendfile. I think
the sign extension that is going on there now is completely unnecessary
and confusing; I think it's a happy accident that it didn't break
anything.
The only thing my patch does other than changing the signedness of count
in the declaration of x86_64 sys32_sendfile is relabelling the types of
offset and count to compat_off_t and compat_size_t. The underlying types
shouldn't change as a result, but I think this way what is going on is
much clearer: the compat_ types were defined for exactly this scenario of
64 bit kernel functions getting off_t and size_t values from a 32 bit
userland, no?
Alexey
^ permalink raw reply
* Re: [patch] add new uevent
From: Alexey Dobriyan @ 2006-05-05 22:22 UTC (permalink / raw)
To: Kristen Accardi; +Cc: linux-kernel, arjan, greg
In-Reply-To: <1146867216.21633.6.camel@whizzy>
On Fri, May 05, 2006 at 03:13:36PM -0700, Kristen Accardi wrote:
> Add dock uevents so that userspace can be notified of dock and undock
> events.
> --- 2.6-git-kca2.orig/include/linux/kobject.h
> +++ 2.6-git-kca2/include/linux/kobject.h
> @@ -46,6 +46,8 @@ enum kobject_action {
> KOBJ_UMOUNT = (__force kobject_action_t) 0x05, /* umount event for block devices (broken) */
> KOBJ_OFFLINE = (__force kobject_action_t) 0x06, /* device offline */
> KOBJ_ONLINE = (__force kobject_action_t) 0x07, /* device online */
> + KOBJ_UNDOCK = (__force kobject_action_t) 0x08, /* undocking */
> + KOBJ_DOCK = (__force kobject_action_t) 0x09, /* dock */
> };
>
> struct kobject {
> --- 2.6-git-kca2.orig/lib/kobject_uevent.c
> +++ 2.6-git-kca2/lib/kobject_uevent.c
> @@ -48,6 +48,10 @@ static char *action_to_string(enum kobje
> return "offline";
> case KOBJ_ONLINE:
> return "online";
> + case KOBJ_DOCK:
> + return "dock";
> + case KOBJ_UNDOCK:
> + return "undock";
> default:
> return NULL;
> }
Where exactly are you going to generate them?
^ permalink raw reply
* Re: Re: HVM network performance
From: Randy Thelen @ 2006-05-05 22:25 UTC (permalink / raw)
To: xen-devel
In-Reply-To: <200605052133.13429.ak@suse.de>
Steve Dobbelstein
> or do we just punt and go for para-virt drivers.
Andi Kleen wrote:
> That's the easy and probably fastest way short term, but long term
> it's a lot more work (you will need to write drivers for all the
> old and new guest OS
> you want to run to get good performance)
Yes, but given a good back-end driver model, these should be
relatively simple. Especially if a couple examples were BSD licensed
to kick start the development of these drivers.
> Also it's a logistical problem because you'll need to distribute
> and setup
> all these drivers even if they are written.
I would think the performance benefit would greatly outweigh the
setup issues. But, what do you mean by 'distribute and setup'?
-- Randy Thelen
Network Appliance
^ permalink raw reply
* Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
From: Greg KH @ 2006-05-05 22:27 UTC (permalink / raw)
To: Jon Smirl; +Cc: Ian Romanick, Dave Airlie, Arjan van de Ven, linux-kernel
In-Reply-To: <9e4733910605051415o48fddbafpf0f8b096f971e482@mail.gmail.com>
On Fri, May 05, 2006 at 05:15:02PM -0400, Jon Smirl wrote:
> On 5/5/06, Greg KH <greg@kroah.com> wrote:
> >On Fri, May 05, 2006 at 04:35:17PM -0400, Jon Smirl wrote:
> >> On 5/5/06, Greg KH <greg@kroah.com> wrote:
> >> >On Fri, May 05, 2006 at 04:14:00PM -0400, Jon Smirl wrote:
> >> >> I would like to see other design alternatives considered on this
> >> >> issue. The 'enable' attribute has a clear problem in that you can't
> >> >> tell which user space program is trying to control the device.
> >> >> Multiple programs accessing the video hardware with poor coordination
> >> >> is already the source of many problems.
> >> >
> >> >Who cares who "enabled" the device. Remember, the majority of PCI
> >> >devices in the system are not video ones. Lots of other types of
> >> >devices want this ability to enable PCI devices from userspace. I've
> >> >been talking with some people about how to properly write PCI drivers in
> >> >userspace, and this attribute is a needed part of it.
> >>
> >> User space program enables the device.
> >> Next I load a device driver
> >> next I rmmod the device driver and it disables the device
> >> user space program trys to use the device
> >> No coordination and user space program faults
> >
> >Gun. Foot. Shoot.
>
> Why do we want to create problem like this when there is a simple
> solution to preventing them. All it takes is a couple of rules:
>
> 1) To use a device it must have a device driver. It may be as simple
> as a couple of lines of code. This driver will cause a device node to
> be created.
>
> 2) If a user app want to use the device it opens the device node.
>
> This builds a system where everybody knows what is going on. The
> driver knows that user space is using the device. Multiple user space
> users are blocked from conflicting because of the open. There is no
> way to shoot yourself in the foot.
That sounds like a nice way to mediate userspace usages of PCI devices,
yes. Much like a dot lockfile is done for tty devices today, all in
userspace (which hints that this too can be done in userspace with no
kernel involvement...)
But it still has nothing to do with this enable sysfs file :)
thanks,
greg k-h
^ permalink raw reply
* RE: Bug in Xen when terminating qemu
From: Ian Pratt @ 2006-05-05 22:32 UTC (permalink / raw)
To: xen, xen-devel
> Not sure if bugs should be reported on xen-user or xen-devel.
> Please point me elsewhere if this is the wrong list.
>
> We are running QEMU under a xenU to run a windows 2000 server
> instance since our processor doesn't support VT. Qemu runs
> great until it is closed, but when qemu closes the xenU dies
> hard. Qemu is running as a user (not root) which implies
> that xvm's are subject to local user DoS.
>
We've been unable to repro this.
Please can you tell us more about the setup, machine, exact version etc.
Thanks,
Ian
^ permalink raw reply
* [U-Boot-Users] (no subject)
From: Wolfgang Denk @ 2006-05-05 22:33 UTC (permalink / raw)
To: u-boot
In-Reply-To: <007601c67085$77b32bf0$3b8119ac@bc.ca.utstar.com>
Dear Peter,
please provide a *descriptive* Subject next time. And ask short and
simple questions instead of posting hundrets of lines of ighly
specific stuff which nobody will read. Maybe you should (re-) read
http://www.catb.org/%7eesr/faqs/smart-questions.html
N message <007601c67085$77b32bf0$3b8119ac@bc.ca.utstar.com> you wrote:
>
> I?ve added in board definition into it and modified the default MPC8560ADS
> configuration for it.? I have been able to burn it into flash on the > board,
What makes you think the MPC8560ADS would be a good starting point?
> The board I?ve been given is very bare.? It has 256 MByte DDR Main > RAM,? 32
> MByte Flash (64k sectors), Ethernet on MII, and Serial on SCC1.? > Nothing
> else on it.
I bet this is wrong. There are probabnly ten times more components on
your board which you did not mention that there are you did.
> This board use to run VxWorks so I took most of the settings used for > that
> and modified U-boot as following (I hope someone can tell me if I did
> something wrong)
No. How could we? We have absolutely no idea what your hardware looks like.
> Anyone have any idea on what I?ve done wrong?? Are there any other board
> definitions in U-Boot I could use that might meet what I have better?
How could we without even having the slightest ideas of what you have?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
panic: kernel trap (ignored)
^ permalink raw reply
* Re: [uml-devel] Problem on generation a locales on uml image
From: Stefano Melchior @ 2006-05-05 22:38 UTC (permalink / raw)
To: Blaisorblade; +Cc: user-mode-linux-devel, Mattia Dongili
In-Reply-To: <200605052247.29478.blaisorblade@yahoo.it>
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]
On Fri, May 05, 2006 at 10:47:28PM +0200, Blaisorblade wrote:
Dear all,
> > [...]
>
> > AFAIU, it's an harmless warning telling that UML didn't receive the
> > timer interrupt for too long.
>
> Yes, more exactly it happens when the kernel didn't schedule a certain task
> (watchdog/$CPUID) for execution for 10 seconds.
>
> The current impression is that it happens on high load, for instance on high
> disk load IIRC. It's harmless as long as UML keeps running.
I may understand that my public server (where I also use to play with uml
too, from remote, i.e. free time at the office) is a PIII500 with only
128MB of RAM and an old 12GB hdd: this lack of performances and the
temporary high cpu load (postfix+spamassassin+apache2+mysql) can be the
reason of this problems.
May it be reasonable to increase this schedule timeout? I mean moving the
limit to 15-20sec?
Thank you in advance of this support
Cheers
SteX
--
Stefano Melchior, GPG key = D52DF829 - <stefano.melchior@openlabs.it>
http://etinarcadiaego.dyndns.org -- http://www.stex.name
Skype ID "stefanomelchior"
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 309 bytes --]
^ permalink raw reply
* Changing Kernel Frequency
From: Akshay Singh @ 2006-05-05 22:38 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
All,
We use Linux 2.6 for VoIP solutions and I was using default kernel
frequency (1000) and everything works good ( A very minimum jitter) but
when I change the kernel frequency from 1000 to 100, jitter increases a
lot !
Any pointers on this.
FYI , we use 200 MHz MIPS based processor.
Thanks,
Akshay
[-- Attachment #2: Type: text/html, Size: 904 bytes --]
^ permalink raw reply
* Changing Kernel Frequency
From: Akshay Singh @ 2006-05-05 22:38 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
All,
We use Linux 2.6 for VoIP solutions and I was using default kernel
frequency (1000) and everything works good ( A very minimum jitter) but
when I change the kernel frequency from 1000 to 100, jitter increases a
lot !
Any pointers on this.
FYI , we use 200 MHz MIPS based processor.
Thanks,
Akshay
[-- Attachment #2: Type: text/html, Size: 904 bytes --]
^ permalink raw reply
* Re: [PATCH] loop.c: respect bio barrier and sync
From: Constantine Sapuntzakis @ 2006-05-05 22:37 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-kernel
In-Reply-To: <20060505145437.GW4324@suse.de>
Sorry about the patch as attachments.
> - You should handle sync_file() failure. If we don't have !f_op (will
> that ever hit, btw?) or ->fsync(), then fail the barrier with
> -EOPNOTSUPP. For fsync failure, well... You probably want to just
> error the bio with -EIO then.
Will fix.
> - Does this work for all loop_device types?
What are the other loop_device types?
BTW, should/does an fsync on a block device translate into a disk flush?
I was looking at sync_blockdev and couldn't figure out how that happened.
Thanks,
-Costa
^ permalink raw reply
* [U-Boot-Users] Add support for Memec Design DS-BD-2VPxx-FF1152 board
From: Wolfgang Denk @ 2006-05-05 22:37 UTC (permalink / raw)
To: u-boot
In-Reply-To: <OF193FEDE4.95E22440-ON07257165.00635029-07257165.0063AC66@mck.us.ray.com>
In message <OF193FEDE4.95E22440-ON07257165.00635029-07257165.0063AC66@mck.us.ray.com> you wrote:
> A patch was sent to Wolfgang Denk which adds support for this board. The
Was it? When and where and what was the subject? I cannot match this.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Of all the things I've lost, I miss my mind the most.
^ permalink raw reply
* Re: [PATCH] Move various PCI IDs to header file
From: Grant Coady @ 2006-05-05 22:37 UTC (permalink / raw)
Cc: Jes Sorensen, Randy.Dunlap, Brent Casavant, linux-kernel,
linux-ide, akpm, jeremy
In-Reply-To: <Pine.LNX.4.58.0605050926250.3161@shark.he.net>
On Fri, 5 May 2006 09:27:06 -0700 (PDT), "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>On Fri, 5 May 2006, Jes Sorensen wrote:
>
>> Randy.Dunlap wrote:
>> > On Thu, 4 May 2006 18:09:45 -0500 (CDT) Brent Casavant wrote:
>> >
>> >> Move various QLogic, Vitesse, and Intel storage
>> >> controller PCI IDs to the main header file.
>> >>
>> >> Signed-off-by: Brent Casavant <bcasavan@sgi.com>
>> >>
>> >> ---
>> >>
>> >> As suggested by Andrew Morton and Jes Sorenson.
>> >
>> > as compared to:
>> > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9b860b8c4bde5949b272968597d1426d53080532
>>
>> I guess Andrew and I should be blamed for that. I Andrew suggested
>> putting the IDs in the 'right place' and I took the right place as being
>> the pci_ids.h file.
>>
>> Can't say I agree with the recommendation, having them in pci_ids.h is
>> nice and clean and it allows one to go look through the list, instead
>> they now really become random hex values :( Brent's patch is a perfect
>> example of IDs being used in multiple places, ie. the qla1280 driver
>> and in the IOC4 driver, so the claim in that Documentation/ file doesn't
>> hold water.
>>
>> Anyway, if this is the new rule, then I guess it's back to using the
>> ugly patch :(
>
>FWIW, I'm not saying that I agree with the new rule, just that
>it's there/merged.
When I worked on pci_ids.h cleanup last year I didn't get a clear
idea of whether moving all #defines to the one header file was
desired. Last I looked there were heaps of them scattered all
over. Is there a preferred model for placing these #defines?
Grant.
^ permalink raw reply
* Re: [PATCH] Move various PCI IDs to header file
From: Grant Coady @ 2006-05-05 22:37 UTC (permalink / raw)
To: Randy.Dunlap
Cc: Jes Sorensen, Randy.Dunlap, Brent Casavant, linux-kernel,
linux-ide, akpm, jeremy
In-Reply-To: <Pine.LNX.4.58.0605050926250.3161@shark.he.net>
On Fri, 5 May 2006 09:27:06 -0700 (PDT), "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>On Fri, 5 May 2006, Jes Sorensen wrote:
>
>> Randy.Dunlap wrote:
>> > On Thu, 4 May 2006 18:09:45 -0500 (CDT) Brent Casavant wrote:
>> >
>> >> Move various QLogic, Vitesse, and Intel storage
>> >> controller PCI IDs to the main header file.
>> >>
>> >> Signed-off-by: Brent Casavant <bcasavan@sgi.com>
>> >>
>> >> ---
>> >>
>> >> As suggested by Andrew Morton and Jes Sorenson.
>> >
>> > as compared to:
>> > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9b860b8c4bde5949b272968597d1426d53080532
>>
>> I guess Andrew and I should be blamed for that. I Andrew suggested
>> putting the IDs in the 'right place' and I took the right place as being
>> the pci_ids.h file.
>>
>> Can't say I agree with the recommendation, having them in pci_ids.h is
>> nice and clean and it allows one to go look through the list, instead
>> they now really become random hex values :( Brent's patch is a perfect
>> example of IDs being used in multiple places, ie. the qla1280 driver
>> and in the IOC4 driver, so the claim in that Documentation/ file doesn't
>> hold water.
>>
>> Anyway, if this is the new rule, then I guess it's back to using the
>> ugly patch :(
>
>FWIW, I'm not saying that I agree with the new rule, just that
>it's there/merged.
When I worked on pci_ids.h cleanup last year I didn't get a clear
idea of whether moving all #defines to the one header file was
desired. Last I looked there were heaps of them scattered all
over. Is there a preferred model for placing these #defines?
Grant.
^ 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.