* Returned mail: see transcript for details
From: Mail Delivery Subsystem @ 2006-03-09 22:43 UTC (permalink / raw)
To: linux-mtd
The original message was received at Thu, 9 Mar 2006 22:43:37 GMT
from [207.178.218.197] (may be forged)
----- The following addresses had permanent fatal errors -----
<willy@bofh.ai>
(reason: 550-Verification failed for <linux-mtd@lists.infradead.org>)
----- Transcript of session follows -----
... while talking to pentafluge.infradead.org.:
>>> MAIL From:<linux-mtd@lists.infradead.org> SIZE=41935
<<< 550-Verification failed for <linux-mtd@lists.infradead.org>
<<< 550-Lists do not send messages and should not receive bounces
<<< 550 Sender verify failed
554 5.0.0 Service unavailable
----- Message header follows -----
Return-Path: <linux-mtd@lists.infradead.org>
Received: from bofh.ai ( [207.178.218.197] (may be forged))
by mailgw0.mh.bbc.co.uk (8.12.11/8.12.11) with ESMTP id k29Mhbu5025818
for <willy@bofh.ai>; Thu, 9 Mar 2006 22:43:37 GMT
Message-Id: <200603092243.k29Mhbu5025818@mailgw0.mh.bbc.co.uk>
From: linux-mtd@lists.infradead.org
To: willy@bofh.ai
Subject: Mail Delivery (failure willy@bofh.ai)
Date: Thu, 9 Mar 2006 14:43:49 -0800
MIME-Version: 1.0
Content-Type: multipart/related;
type="multipart/alternative";
boundary="----=_NextPart_000_001B_01C0CA80.6B015D10"
X-Priority: 3
X-MSMail-Priority: Normal
----- Message body suppressed -----
^ permalink raw reply
* Re: [PATCH] mm: yield during swap prefetching
From: Peter Williams @ 2006-03-09 22:44 UTC (permalink / raw)
To: Con Kolivas; +Cc: Helge Hafting, Andrew Morton, linux-kernel, linux-mm, ck
In-Reply-To: <200603092008.16792.kernel@kolivas.org>
Con Kolivas wrote:
> On Thursday 09 March 2006 19:57, Helge Hafting wrote:
>
>>Con Kolivas wrote:
>>
>>>On Wed, 8 Mar 2006 12:11 pm, Andrew Morton wrote:
>>>
>>>>but, but. If prefetching is prefetching stuff which that game will soon
>>>>use then it'll be an aggregate improvement. If prefetch is prefetching
>>>>stuff which that game _won't_ use then prefetch is busted. Using yield()
>>>>to artificially cripple kprefetchd is a rather sad workaround isn't it?
>>>
>>>It's not the stuff that it prefetches that's the problem; it's the disk
>>>access.
>>
>>Well, seems you have some sorry kind of disk driver then?
>>An ide disk not using dma?
>>
>>A low-cpu task that only abuses the disk shouldn't make an impact
>>on a 3D game that hogs the cpu only. Unless the driver for your
>>harddisk is faulty, using way more cpu than it need.
>>
>>Use hdparm, check the basics:
>>unmaksirq=1, using_dma=1, multcount is some positive number,
>>such as 8 or 16, readahead is some positive number.
>>Also use hdparm -i and verify that the disk is using some
>>nice udma mode. (too old for that, and it probably isn't worth
>>optimizing this for...)
>>
>>Also make sure the disk driver isn't sharing an irq with the
>>3D card.
>>
>>Come to think of it, if your 3D game happens to saturate the
>>pci bus for long times, then disk accesses might indeed
>>be noticeable as they too need the bus. Check if going to
>>a slower dma mode helps - this might free up the bus a bit.
>
>
> Thanks for the hints.
>
> However I actually wrote the swap prefetch code and this is all about changing
> its behaviour to make it do what I want. The problem is that nice 19 will
> give it up to 5% cpu in the presence of a nice 0 task when I really don't
> want swap prefetch doing anything.
I'm working on a patch to add soft and hard CPU rate caps to the
scheduler and the soft caps may be useful for what you're trying to do.
They are a generalization of your SCHED_BATCH implementation in
staircase (which would have been better called SCHED_BACKGROUND :-)
IMHO) in that a task with a soft cap will only use more CPU than that
cap if it (the cpu) would otherwise go unused. The main difference
between this mechanism and staircase's SCHED_BATCH mechanism is that you
can specify how much (as parts per thousand of a CPU) the task can use
instead of just being background or not background. With the soft cap
set to zero the effect would be essentially the same.
> Furthermore because it is constantly
> waking up from sleep (after disk activity) it is always given lower latency
> scheduling than a fully cpu bound nice 0 task - this is normally appropriate
> behaviour. Yielding regularly works around that issue.
>
> Ideally taking into account cpu usage and only working below a certain cpu
> threshold may be the better mechanism and it does appear this would be more
> popular. It would not be hard to implement, but does add yet more code to an
> increasingly complex heuristic used to detect "idleness". I am seriously
> considering it.
See above re CPU rate soft caps. I'm holding off on submitting this
patch for consideration until the current scheduler modifications being
tested in -mm have had time to settle.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Alsa-user] arecord under 2.6.15.4-rt17 ->overruns...
From: Lee Revell @ 2006-03-09 22:46 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Sergei Steshenko, alsa-user, linux-kernel, gregkh, Adrian Bunk
In-Reply-To: <Pine.LNX.4.60.0603092336150.14584@poirot.grange>
On Thu, 2006-03-09 at 23:41 +0100, Guennadi Liakhovetski wrote:
> On Tue, 7 Mar 2006, Lee Revell wrote:
>
> > Does the OSS driver have the same problem?
>
> Surprise - I was not able to reproduce the problem with oss. Whereas with
> alsa I was able to lock my PC again. What I do - just load respective
> drivers and either "jackd -v -d alsa" or "jackd -v -d oss". And then just
> put some load in the background + try to start ardour... With alsa I
> wasn't even able to start it. With oss it did run, and no xruns reported
> from jackd. Normal non-rt kernel. jackd started without --realtime.
>
> Ouch
>
OK, please file a report in the ALSA bug tracker against this driver.
Adrian, please add VIA to your list of OSS drivers that need to remain in the kernel.
Lee
^ permalink raw reply
* Re: silo-1.4.11
From: Ben Collins @ 2006-03-09 22:54 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <4410A7F7.9090405@gmail.com>
On Thu, 2006-03-09 at 17:11 -0500, Joe Ciccone wrote:
> One update to this monster of a patch because with the version change in
> Rules.make it didn't apply cleanly.
>
> http://www.crazyeyesoft.com/silo-1.4.11-fixes-1.patch
I can't really take this patch into silo directly. Can you separate the
parts that patch up the current code from the part where you basically
import all of libext2fs and add the emul_32 headers?
I can take the build changes, but the rest of it is just creating
headache for me because it requires syncing to external source.
--
Ubuntu - http://www.ubuntu.com/
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
SwissDisk - http://www.swissdisk.com/
^ permalink raw reply
* RFC: 9p filesystem interface
From: Latchesar Ionkov @ 2006-03-09 22:57 UTC (permalink / raw)
To: kernel-mentors, linux-fsdevel; +Cc: v9fs-developer
Hi,
Translating Plan9's 9P protocol to the Unix world is not very
straightforward task. We already have the basic functionality implemented,
but there are still some missing pieces:
User authentication
9P protocol requires every user the authenticate separately to the server.
There is not defined authentication protocol, 9P assumes that the
client knows what authentication is required by the server. The
authentication is performed by creating an authentication channel to the
server and reading/writing on it. When the auth conversation is done, the
client "attaches" to the server passing the authentication channel id. We
don't want to hardcode any specific auth protocol in the kernel, we would
rather have a way to expose the per-user per-mount authentication channel
to the user space and let a program take care of the authentication. We
are discussing whether to do on-demand, user-initiated authentication, or
both. Currently v9fs attaches as a single user and the file operations for
all users are done with that user name.
Error mapping
In the 9P protocol all errors are reported as textual strings. VFS expects
errors to be numeric values. Different file servers return different error
names, there is no common set of error names. We need a way to configure
v9fs of the mapping for particular file server. Currently v9fs has a static
mapping of the error names found in the most used file servers.
User mapping
Users and groups in 9P are also identified by textual strings. VFS expects
numeric uids. We need a way to configure a mapping between the user names
and user ids. Currently we don't do any mapping.
We need a per-v9fs-mount interface that we can use for authentication, error
and user mapping. We are evaluating three options -- adding v9fs tree in
procfs, adding v9fs tree in sysfs, and defining a special directory on the
root level of the tree served by v9fs.
Procfs
If we implement procfs interface, we would add a new directory -- fs/v9fs.
The top level will contain the global configuration options for the fs.
There will be subdirectories that will contain the files used to configure
the specific mounts. When an unauthenticated user tries to perform a file
operation on an v9fs file, v9fs will create a file in fs/v9fs/nnn
directory that can be used for authenticating that user.
Pros: It is going to use existing kernel framework.
Cons: Having chroot, mount --bind, multiple mounts on the same mount-point
etc., it is going to be hard to find out which fs/v9fs/nnn subdirectory
belongs to which tree.
Sysfs
Sysfs is similar to procfs, but it has one more disadvantage: there is a
limit of the size of the files. There is no guarantee how much data will
be tranferred during the authentication conversation. We can work around
that restriction by doing lseek(fd, 0, SEEK_SET) before we read from the
authentication file exposed in sysfs, but it is ugly and against common
sense.
Special directory
The third option is to expose the files as a special directory in the roots
of the trees served by v9fs. The directory (.9p or #9p) is going to behave
differently than the rest of the files v9fs serves. The files in the
directory will be handled by v9fs locally and will be used for
authentication, error and user mapping.
Pros: It is easier to find the files for a specific mount.
Cons: Having special files that behave differently may lead to some
confusion.
We would like to get your opinions on what is the preferred linux-kernel way
of implementing the 9p-to-user-space interface.
Thanks,
Lucho
^ permalink raw reply
* Re: [Alsa-user] arecord under 2.6.15.4-rt17 ->overruns...
From: Adrian Bunk @ 2006-03-09 22:56 UTC (permalink / raw)
To: Lee Revell
Cc: Guennadi Liakhovetski, Sergei Steshenko, alsa-user, linux-kernel,
gregkh
In-Reply-To: <1141944417.13319.84.camel@mindpipe>
On Thu, Mar 09, 2006 at 05:46:56PM -0500, Lee Revell wrote:
> On Thu, 2006-03-09 at 23:41 +0100, Guennadi Liakhovetski wrote:
> > On Tue, 7 Mar 2006, Lee Revell wrote:
> >
> > > Does the OSS driver have the same problem?
> >
> > Surprise - I was not able to reproduce the problem with oss. Whereas with
> > alsa I was able to lock my PC again. What I do - just load respective
> > drivers and either "jackd -v -d alsa" or "jackd -v -d oss". And then just
> > put some load in the background + try to start ardour... With alsa I
> > wasn't even able to start it. With oss it did run, and no xruns reported
> > from jackd. Normal non-rt kernel. jackd started without --realtime.
> >
> > Ouch
> >
>
> OK, please file a report in the ALSA bug tracker against this driver.
>
> Adrian, please add VIA to your list of OSS drivers that need to remain in the kernel.
As soon as I get a bug number from the ALSA bug tracker I'll add
SOUND_VIA82CXXX to my list of OSS drivers that should stay.
> Lee
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: 2.6.15-rt20, "bad page state", jackd
From: Nick Piggin @ 2006-03-09 22:57 UTC (permalink / raw)
To: Fernando Lopez-Lezcano
Cc: Ingo Molnar, Heiko Carstens, Steven Rostedt,
Linux Kernel Mailing List
In-Reply-To: <1141938488.22708.28.camel@cmn3.stanford.edu>
Fernando Lopez-Lezcano wrote:
> In my case it is completely repeatable.
> Boot, start jackd, stop jackd -> problem appears.
>
> This does not happen on all computers so it would seem to me it is
> related to the sound drivers. I'll try to see if there is a correlation
> with the sound card being used.
>
> Is there anything else I could do to try to help resolve this?
Can you test with the latest mainline -git snapshot, or is it only
the -rt tree that causes the warnings?
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: [Mactel-linux-devel] Re: [PATCH] /sys/firmware/efi/systab giving incorrect value for smbios
From: gimli @ 2006-03-09 23:00 UTC (permalink / raw)
To: Tolentino, Matthew E; +Cc: Matthew Garrett, mactel-linux-devel, linux-kernel
In-Reply-To: <D36CE1FCEFD3524B81CA12C6FE5BCAB00CA2309B@fmsmsx406.amr.corp.intel.com>
The latest mm patches makes the kernel unbootable on ma iMac.
cu
Edgar (gimli) Hucek
Tolentino, Matthew E wrote:
> gimli <> wrote:
>> Hi.
>>
>> Do you have any idea why the kernel crashes on machines with more
>> then 512 MB ram ?
>>
>
> Can you try the latest -mm with the attached patch on your machine?
> This should fix it.
>
> matt
^ permalink raw reply
* Re: [PATCH 4 of 20] ipath - support for HyperTransport devices
From: Roland Dreier @ 2006-03-09 23:01 UTC (permalink / raw)
To: Bryan O'Sullivan
Cc: rolandd, gregkh, akpm, davem, linux-kernel, openib-general
In-Reply-To: <0b1b4f4c093e2db6153e.1141922817@localhost.localdomain>
> + /* the HT capability type byte is 3 bytes after the
> + * capability byte.
> + */
> + if (pci_read_config_byte(pdev, pos + 3, &cap_type)) {
> + dev_info(&pdev->dev, "Couldn't read config "
> + "command @ %d\n", pos);
> + continue;
> + }
> + if (!(cap_type & 0xE0)) {
It seems like all these hypertransport magic constants should be in a
general .h somewhere. I'm not sure if it makes sense to put them in
<linux/pci.h>, or start a <linux/hypertransport.h>.
> + else if (linkctrl & (0xf << 8)) {
> + ipath_cdbg(
> + VERBOSE,
> + "Clear linkctrl%d CRC "
> + "Error bits %x\n", i,
> + linkctrl & (0xf << 8));
> + /*
> + * now write them back to clear
> + * the error.
> + */
> + pci_write_config_byte(
> + pdev, link_off,
> + linkctrl & (0xf << 8));
The logic here is pretty hard to follow, and you're getting squeezed
pretty hard by indenting 5 tabs stops. Can ipath_setup_ht_config() be
split up into subfunctions?
^ permalink raw reply
* [RFC: 2.6 patch] hostap_hw.c:hfa384x_set_rid(): fix error handling
From: Adrian Bunk @ 2006-03-09 23:06 UTC (permalink / raw)
To: jkmaline; +Cc: hostap, linux-kernel, netdev, linville
The Coverity checker noted that the call to prism2_hw_reset() was dead
code.
Does this patch change the code to what was intended?
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.16-rc5-mm3-full/drivers/net/wireless/hostap/hostap_hw.c.old 2006-03-09 23:28:30.000000000 +0100
+++ linux-2.6.16-rc5-mm3-full/drivers/net/wireless/hostap/hostap_hw.c 2006-03-09 23:30:19.000000000 +0100
@@ -928,16 +928,16 @@ static int hfa384x_set_rid(struct net_de
res = hfa384x_cmd(dev, HFA384X_CMDCODE_ACCESS_WRITE, rid, NULL, NULL);
up(&local->rid_bap_sem);
+
if (res) {
+ if (res == -ETIMEDOUT)
+ prism2_hw_reset(dev);
+
printk(KERN_DEBUG "%s: hfa384x_set_rid: CMDCODE_ACCESS_WRITE "
"failed (res=%d, rid=%04x, len=%d)\n",
dev->name, res, rid, len);
- return res;
}
- if (res == -ETIMEDOUT)
- prism2_hw_reset(dev);
-
return res;
}
^ permalink raw reply
* [2.6 patch] tg3.c:tg3_bus_string(): remove dead code
From: Adrian Bunk @ 2006-03-09 23:06 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linux-kernel
The Coverity checker spotted this dead code (note that (clock_ctrl == 7)
is already handled above).
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.16-rc5-mm3-full/drivers/net/tg3.c.old 2006-03-09 23:25:25.000000000 +0100
+++ linux-2.6.16-rc5-mm3-full/drivers/net/tg3.c 2006-03-09 23:25:39.000000000 +0100
@@ -10596,26 +10596,24 @@ static char * __devinit tg3_bus_string(s
if ((clock_ctrl == 7) ||
((tr32(GRC_MISC_CFG) & GRC_MISC_CFG_BOARD_ID_MASK) ==
GRC_MISC_CFG_BOARD_ID_5704CIOBE))
strcat(str, "133MHz");
else if (clock_ctrl == 0)
strcat(str, "33MHz");
else if (clock_ctrl == 2)
strcat(str, "50MHz");
else if (clock_ctrl == 4)
strcat(str, "66MHz");
else if (clock_ctrl == 6)
strcat(str, "100MHz");
- else if (clock_ctrl == 7)
- strcat(str, "133MHz");
} else {
strcpy(str, "PCI:");
if (tp->tg3_flags & TG3_FLAG_PCI_HIGH_SPEED)
strcat(str, "66MHz");
else
strcat(str, "33MHz");
}
if (tp->tg3_flags & TG3_FLAG_PCI_32BIT)
strcat(str, ":32-bit");
else
strcat(str, ":64-bit");
return str;
^ permalink raw reply
* [2.6 patch] some fixups for the X86_NUMAQ dependencies
From: Adrian Bunk @ 2006-03-09 23:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Martin J. Bligh
You must always ensure to fulfill the dependencies of what you are
select'ing.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 20 Feb 2006
arch/i386/Kconfig | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- linux-2.6.16-rc3-mm1-full/arch/i386/Kconfig.old 2006-02-20 00:12:50.000000000 +0100
+++ linux-2.6.16-rc3-mm1-full/arch/i386/Kconfig 2006-02-20 00:17:57.000000000 +0100
@@ -84,6 +84,7 @@
config X86_NUMAQ
bool "NUMAQ (IBM/Sequent)"
+ select SMP
select NUMA
help
This option is used for getting Linux to run on a (IBM/Sequent) NUMA
@@ -419,6 +420,7 @@
config NOHIGHMEM
bool "off"
+ depends on !X86_NUMAQ
---help---
Linux can use up to 64 Gigabytes of physical memory on x86 systems.
However, the address space of 32-bit x86 processors is only 4
@@ -455,6 +457,7 @@
config HIGHMEM4G
bool "4GB"
+ depends on !X86_NUMAQ
help
Select this if you have a 32-bit processor and between 1 and 4
gigabytes of physical RAM.
@@ -522,10 +525,6 @@
default n if X86_PC
default y if (X86_NUMAQ || X86_SUMMIT)
-# Need comments to help the hapless user trying to turn on NUMA support
-comment "NUMA (NUMA-Q) requires SMP, 64GB highmem support"
- depends on X86_NUMAQ && (!HIGHMEM64G || !SMP)
-
comment "NUMA (Summit) requires SMP, 64GB highmem support, ACPI"
depends on X86_SUMMIT && (!HIGHMEM64G || !ACPI)
^ permalink raw reply
* [RFC: 2.6 patch] chelsio/espi.c:tricn_init(): remove dead code
From: Adrian Bunk @ 2006-03-09 23:06 UTC (permalink / raw)
To: maintainers; +Cc: jgarzik, netdev, linux-kernel
The Coverity checker spotted these two unused variables.
Please check whether this patch is correct or whether they should be
used.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/net/chelsio/espi.c | 14 +++-----------
1 file changed, 3 insertions(+), 11 deletions(-)
--- linux-2.6.16-rc5-mm3-full/drivers/net/chelsio/espi.c.old 2006-03-09 23:19:54.000000000 +0100
+++ linux-2.6.16-rc5-mm3-full/drivers/net/chelsio/espi.c 2006-03-09 23:20:35.000000000 +0100
@@ -87,15 +87,9 @@
static int tricn_init(adapter_t *adapter)
{
int i = 0;
- int sme = 1;
int stat = 0;
int timeout = 0;
int is_ready = 0;
- int dynamic_deskew = 0;
-
- if (dynamic_deskew)
- sme = 0;
-
/* 1 */
timeout=1000;
@@ -113,11 +107,9 @@
}
/* 2 */
- if (sme) {
- tricn_write(adapter, 0, 0, 0, TRICN_CNFG, 0x81);
- tricn_write(adapter, 0, 1, 0, TRICN_CNFG, 0x81);
- tricn_write(adapter, 0, 2, 0, TRICN_CNFG, 0x81);
- }
+ tricn_write(adapter, 0, 0, 0, TRICN_CNFG, 0x81);
+ tricn_write(adapter, 0, 1, 0, TRICN_CNFG, 0x81);
+ tricn_write(adapter, 0, 2, 0, TRICN_CNFG, 0x81);
for (i=1; i<= 8; i++) tricn_write(adapter, 0, 0, i, TRICN_CNFG, 0xf1);
for (i=1; i<= 2; i++) tricn_write(adapter, 0, 1, i, TRICN_CNFG, 0xf1);
for (i=1; i<= 3; i++) tricn_write(adapter, 0, 2, i, TRICN_CNFG, 0xe1);
^ permalink raw reply
* [RFC: 2.6 patch] video/sis/init301.c:SiS_ChrontelDoSomething2(): remove dead code
From: Adrian Bunk @ 2006-03-09 23:06 UTC (permalink / raw)
To: thomas; +Cc: adaplas, linux-fbdev-devel, linux-kernel
The Coverity checker spotted these two unused variables.
Please check whether this patch is correct or whether they should be
used.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/video/sis/init301.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
--- linux-2.6.16-rc5-mm3-full/drivers/video/sis/init301.c.old 2006-03-09 23:39:56.000000000 +0100
+++ linux-2.6.16-rc5-mm3-full/drivers/video/sis/init301.c 2006-03-09 23:40:48.000000000 +0100
@@ -8560,39 +8560,30 @@
}
}
static void
SiS_ChrontelDoSomething2(struct SiS_Private *SiS_Pr)
{
- unsigned short temp,tempcl,tempch;
+ unsigned short temp;
SiS_LongDelay(SiS_Pr, 1);
- tempcl = 3;
- tempch = 0;
do {
temp = SiS_GetCH701x(SiS_Pr,0x66);
temp &= 0x04; /* PLL stable? -> bail out */
if(temp == 0x04) break;
if(SiS_Pr->ChipType == SIS_740) {
/* Power down LVDS output, PLL normal operation */
SiS_SetCH701x(SiS_Pr,0x76,0xac);
}
SiS_SetCH701xForLCD(SiS_Pr);
- if(tempcl == 0) {
- if(tempch == 3) break;
- SiS_ChrontelResetDB(SiS_Pr);
- tempcl = 3;
- tempch++;
- }
- tempcl--;
temp = SiS_GetCH701x(SiS_Pr,0x76);
temp &= 0xfb; /* Reset PLL */
SiS_SetCH701x(SiS_Pr,0x76,temp);
SiS_LongDelay(SiS_Pr, 2);
temp = SiS_GetCH701x(SiS_Pr,0x76);
temp |= 0x04; /* PLL normal operation */
SiS_SetCH701x(SiS_Pr,0x76,temp);
^ permalink raw reply
* [RFC: 2.6 patch] video/sis/init301.c:SiS_ChrontelDoSomething2(): remove dead code
From: Adrian Bunk @ 2006-03-09 23:06 UTC (permalink / raw)
To: thomas; +Cc: adaplas, linux-fbdev-devel, linux-kernel
The Coverity checker spotted these two unused variables.
Please check whether this patch is correct or whether they should be
used.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/video/sis/init301.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
--- linux-2.6.16-rc5-mm3-full/drivers/video/sis/init301.c.old 2006-03-09 23:39:56.000000000 +0100
+++ linux-2.6.16-rc5-mm3-full/drivers/video/sis/init301.c 2006-03-09 23:40:48.000000000 +0100
@@ -8560,39 +8560,30 @@
}
}
static void
SiS_ChrontelDoSomething2(struct SiS_Private *SiS_Pr)
{
- unsigned short temp,tempcl,tempch;
+ unsigned short temp;
SiS_LongDelay(SiS_Pr, 1);
- tempcl = 3;
- tempch = 0;
do {
temp = SiS_GetCH701x(SiS_Pr,0x66);
temp &= 0x04; /* PLL stable? -> bail out */
if(temp == 0x04) break;
if(SiS_Pr->ChipType == SIS_740) {
/* Power down LVDS output, PLL normal operation */
SiS_SetCH701x(SiS_Pr,0x76,0xac);
}
SiS_SetCH701xForLCD(SiS_Pr);
- if(tempcl == 0) {
- if(tempch == 3) break;
- SiS_ChrontelResetDB(SiS_Pr);
- tempcl = 3;
- tempch++;
- }
- tempcl--;
temp = SiS_GetCH701x(SiS_Pr,0x76);
temp &= 0xfb; /* Reset PLL */
SiS_SetCH701x(SiS_Pr,0x76,temp);
SiS_LongDelay(SiS_Pr, 2);
temp = SiS_GetCH701x(SiS_Pr,0x76);
temp |= 0x04; /* PLL normal operation */
SiS_SetCH701x(SiS_Pr,0x76,temp);
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [2.6 patch] tg3.c:tg3_bus_string(): remove dead code
From: David S. Miller @ 2006-03-09 23:09 UTC (permalink / raw)
To: bunk; +Cc: jgarzik, netdev, linux-kernel
In-Reply-To: <20060309230650.GJ21864@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Fri, 10 Mar 2006 00:06:50 +0100
> The Coverity checker spotted this dead code (note that (clock_ctrl == 7)
> is already handled above).
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied, thanks Adrian.
^ permalink raw reply
* Re: [PATCH 7 of 20] ipath - misc driver support code
From: Roland Dreier @ 2006-03-09 23:11 UTC (permalink / raw)
To: Bryan O'Sullivan
Cc: rolandd, gregkh, akpm, davem, linux-kernel, openib-general
In-Reply-To: <2f16f504dd4b98c2ce7c.1141922820@localhost.localdomain>
> +static unsigned handle_frequent_errors(struct ipath_devdata *dd,
> + ipath_err_t errs, char msg[512],
> + int *noprint)
> +{
> + cycles_t nc;
> + static cycles_t nextmsg_time;
> + static unsigned nmsgs, supp_msgs;
> +
> + /*
> + * throttle back "fast" messages to no more than 10 per 5 seconds
> + * (1.4-2GHz clock). This isn't perfect, but it's a reasonable
> + * heuristic. If we get more than 10, give a 5x longer delay
> + */
Could this be replaced by printk_ratelimit()?
- R.
^ permalink raw reply
* Re: [PATCH 7 of 20] ipath - misc driver support code
From: Roland Dreier @ 2006-03-09 23:13 UTC (permalink / raw)
To: Bryan O'Sullivan
Cc: rolandd, gregkh, akpm, davem, linux-kernel, openib-general
In-Reply-To: <2f16f504dd4b98c2ce7c.1141922820@localhost.localdomain>
> +/**
> + * ipath_unordered_wc - indicate whether write combining is ordered
> + *
> + * Because our performance depends on our ability to do write combining mmio
> + * writes in the most efficient way, we need to know if we are on an Intel
> + * or AMD x86_64 processor. AMD x86_64 processors flush WC buffers out in
> + * the order completed, and so no special flushing is required to get
> + * correct ordering. Intel processors, however, will flush write buffers
> + * out in "random" orders, and so explict ordering is needed at times.
> + */
> +int ipath_unordered_wc(void)
> +{
> + return boot_cpu_data.x86_vendor == X86_VENDOR_INTEL;
> +}
This is kind of theoritical, but it seems to me that it would be safer
to write this as
int ipath_unordered_wc(void)
{
return boot_cpu_data.x86_vendor != X86_VENDOR_AMD;
}
after all, Via is probably going to have an x86-64 CPU one of these
days, and I doubt you've checked that their WC flush is ordered.
- R.
^ permalink raw reply
* Re: [Alsa-user] arecord under 2.6.15.4-rt17 ->overruns...
From: Guennadi Liakhovetski @ 2006-03-09 23:15 UTC (permalink / raw)
To: Lee Revell; +Cc: Sergei Steshenko, alsa-user, linux-kernel, gregkh, Adrian Bunk
In-Reply-To: <1141944417.13319.84.camel@mindpipe>
On Thu, 9 Mar 2006, Lee Revell wrote:
> OK, please file a report in the ALSA bug tracker against this driver.
Yep, I will. I am afraid, I lied to you at one place - as I said that
2.4.32 didn't work either. I tested 2.4.32, but used drivers from
alsa-driver-1.0.3. I wasn't able to compile any recent version of
alsa-library against 2.4.x native alsa drivers. I might try some older
version of alsa-lib. I'll try to put as much information as possible in
the bug-report.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* RE: Grant tables from dom0 userspace?
From: King, Steven R @ 2006-03-09 23:16 UTC (permalink / raw)
To: Andrew Warfield; +Cc: Cihula, Joseph, Jacob Gorm Hansen, xen-devel Devel
Hi Andrew --
> Are there implicit unmapping problems that you thing would remain
unsolved if,
> for instance, there was a vm area destructor early enough to allow the
OS to
> properly unmap active grants?
I'm having a post-unmap balloon driver problem, but could be my fault
(see below). I'm not convinced that implicit unmapping is an
unreasonable thing to ask of Xen. It feels less complex overall to have
Xen deal with this once, rather than N operating system deal with it N
different ways. I'd be interested to hear arguments here.
> When you say, "others remain," can you provide a little more detail?
I tried to list some in my reply to Keir.
While I've got you on the line... :^) I'm having two problems right now
with my attempt at implicit unmap. The hacks let me limp along well
enough to make progress on the code that uses the shared memory, but any
thoughts on further improvements are most welcome.
The implicit unmap code executes when the cleanup_writable_pagetable()
code _PAGE_GNTMAP flag is found in a modified pte. The backtrace looks
like this:
(XEN) [<ff13603e>] put_page_from_l1e+0xd0/0x1af
(XEN) [<ff13a891>] revalidate_l1+0x159/0x168
(XEN) [<ff13aac1>] ptwr_flush+0x221/0x32f
(XEN) [<ff13b6a7>] cleanup_writable_pagetable+0x5c/0x7d
(XEN) [<ff137c20>] do_mmuext_op+0x85/0x8c1
(XEN) [<ff149e0f>] hypercall+0x8f/0xaf
At this point, the Linux has just squashed the pte. Xen code knows the
l1e, and I've added a few more bits to the maptrack object to allow me
to find a match from the corresponding pfn. It's kludgey, because this
only works in the special case where only one map track entity exists
for a given pfn per domain. This is problem #1. Ideas? If we had the
exact address of the pte, there would be no ambiguity in which maptrack
entry owns the mapping. I nosed around and did not find a way to get
the pte addr, but still hold out hope that it's possible.
Armed with the "correct" maptrack entry, I can do most of the ummapping
work then and there. Later, I get the "late" vma_close() from the OS
where my guest driver explicitly unmaps to finish the job.
All is well, and I'm back at the guest command prompt. Problem #2 is
that the balloon driver crashes me if I try to restart my user-level
app. The dump looks like this:
kernel BUG at drivers/xen/balloon/balloon.c:218!
invalid operand: 0000 [#1]
SMP
Modules linked in:
CPU: 0
EIP: 0061:[<c023d8c4>] Not tainted VLI
EFLAGS: 00010097 (2.6.14-xenU)
EIP is at increase_reservation+0x1c4/0x230
eax: c1000000 ebx: 0000f377 ecx: c11e6eec edx: c0042000
esi: 00000004 edi: c11e6ee0 ebp: c038bf18 esp: c038bed8
ds: 007b es: 007b ss: 0069
Process events/0 (pid: 5, threadinfo=c038a000 task=c03b3530)
Stack: c11e6e80 c0346d00 00000000 00000000 cf3ac000 cf3ac000 00000004
00000000
00000000 00007ff0 cf8f5030 c03b3658 00000005 00000004 00000000
c038a000
c038bf34 c023db8a 00000004 c0132dff 00000000 c03b1c00 c02ff004
c038bfb4
Call Trace:
[<c010845f>] show_stack+0x7f/0xa0
[<c0108612>] show_registers+0x162/0x1d0
[<c0108824>] die+0xf4/0x180
[<c02adb85>] do_trap+0xb5/0xc0
[<c0108bec>] do_invalid_op+0xbc/0xd0
[<c0108127>] error_code+0x2b/0x30
[<c023db8a>] balloon_process+0x3a/0xb0
[<c012e05c>] worker_thread+0x19c/0x240
[<c0132ada>] kthread+0xba/0xc0
[<c0105f49>] kernel_thread_helper+0x5/0xc
Code: 00 00 00 00 31 d2 89 f8 e8 5a 51 f0 ff ff 45 cc 8b 55 08 39 55 cc
0f 82 6b ff ff ff e9 2b ff ff ff 0f 0b e7 00 3a 92 2d c0 eb cd <0f> 0b
da 00 3a 92 2d c0 e9 76 ff ff ff 0f 0b d7 00 3a 92 2d c0
I haven't pursed this one at all, so it could be the result a dumb
mistake on my part.
-steve
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Andrew
Warfield
Sent: Thursday, March 09, 2006 10:59 AM
To: King, Steven R
Cc: Cihula, Joseph; Jacob Gorm Hansen; xen-devel Devel
Subject: Re: [Xen-devel] Grant tables from dom0 userspace?
Hi Steven,
> I've hacked around many of
> the problems, such as implicit unmapping of grant references, but
> others remain. Some of the issues have no resolution in the grant
> table architecture.
It would be quite useful to know what specific problems you have
encountered in this effort as insight for future versions of the code.
The main problem that I have encountered in user-level foreign page
mappings is (as discussed previously) that Linux is a bit hasty in
blowing away user virtual memory areas, and doesn't provide a good
mechanism to safely unmap the pages. The kernel has all the information
it needs to do the right thing though, and I think this should be
reasonably fixed in the future -- i don't see a compelling reason for
Xen to do extra book-keeping to cover for something that the OS could
just as easily do. Especially for something like cross-VM mappings,
which don't exist in the non-virtualized system.
Are there implicit unmapping problems that you thing would remain
unsolved if, for instance, there was a vm area destructor early enough
to allow the OS to properly unmap active grants?
When you say, "others remain," can you provide a little more detail?
thanks!
a.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* [lm-sensors] Memory usage of sysfs files
From: Hans de Goede @ 2006-03-09 23:16 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <Pine.LNX.4.63.0603082311220.3051@Laila>
Hi,
I've given this some more thought and I've decided against implementing
my way for a couple of other drivers to be able to really measure the
difference. I believe we agree my way is somewhat more efficient, but
that the differences aren't big enough to swing the scales to my way
only on the efficiency reasons.
Instead of spending more time coding test-cases I'd rather just see a
decision soon and (if nescessarry) I'll update the uguru driver to match .
There are 2 arguments I would still like to make in favor of my way though:
1) you initially did it this way too for atleast one driver. Remember,
usually your first hunch is a good one.
2) I've also written support for libsensors and the sensors application
when doing things my way and that fits nicely. I'm afraid that the many
files way will be a problem with the current libsensors. I don't want to
now wath the lib and the progs chips.* will look like. 100+ additional
entries for the uguru alone! And I don't think the chip specific reading
and report code in the sensors application will get any pretter too.
Now I know that libsensors is destined to be replaced, but it will be
around for a while I think.
I've attached a patch adding support for the uguru to both lib and prog
with alarm reporting to give you an idea how this will look like when
doing things my way. Please note that this patch needs updating for
2.10 / cvs and thus won't apply.
Regards,
Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lm_sensors-2.9.1-uguru.patch
Type: text/x-patch
Size: 15184 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060310/73c52b90/lm_sensors-2.9.1-uguru-0001.bin
^ permalink raw reply
* Re: [PATCH] allow double click on current HEAD id after git-pull
From: Junio C Hamano @ 2006-03-09 23:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: junkio, Olaf Hering, git
In-Reply-To: <20060309210250.GY31278@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Sat, Feb 11, 2006 at 12:26:30PM CET, I got a letter
> where Olaf Hering <olh@suse.de> said that...
>> Double click on to current HEAD commit id is not possible,
>> the dot has to go.
>>
>> olaf@pomegranate:~/kernel/git/linux-2.6> git-pull
>> Unpacking 194 objects
>> 100% (194/194) done
>> * refs/heads/origin: fast forward to branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
>> Updating from 5bc159e6cb7ca8d173195919ee935885c129011e to 25bf368b3d98668c5d5f38e2201d8bca16e52680.
> ^
>
> Junio, is there any particular reason why this hasn't been applied?
Well I kind of like ending a sentence with a full stop. Isn't
this something you can do by confuguiring your cut&paste?
But I do not have a _very_ strong feeling either way. If
majority of the list wants it that way I do not mind.
^ permalink raw reply
* Re: [RFC] Badness in __mutex_unlock_slowpath with XFS stress tests
From: Nathan Scott @ 2006-03-09 23:14 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Suzuki, linux-fsdevel, linux-aio kvack.org, lkml, suparna, akpm,
linux-xfs
In-Reply-To: <20060309224219.GA6709@infradead.org>
On Thu, Mar 09, 2006 at 10:42:19PM +0000, Christoph Hellwig wrote:
> On Fri, Mar 10, 2006 at 09:30:42AM +1100, Nathan Scott wrote:
> > Not for reads AFAICT - __generic_file_aio_read + own-locking
> > should always have released i_mutex at the end of the direct
> > read - are you thinking of writes or have I missed something?
>
> if an error occurs before a_ops->direct_IO is called __generic_file_aio_read
> will return with i_mutex still locked. Note that checking for negative
> return values is not enough as __blockdev_direct_IO can return errors
> aswell.
*groan* - right you are. Another option may be to have the
generic dio+own-locking case reacquire i_mutex if it drops
it, before returning... thoughts? Seems alot less invasive
than the filemap.c code dup'ing thing.
cheers.
--
Nathan
^ permalink raw reply
* Re: [PATCH 8 of 20] ipath - sysfs support for core driver
From: Roland Dreier @ 2006-03-09 23:18 UTC (permalink / raw)
To: Bryan O'Sullivan
Cc: rolandd, gregkh, akpm, davem, linux-kernel, openib-general
In-Reply-To: <ef8042c934401522ed3f.1141922821@localhost.localdomain>
> +static ssize_t show_version(struct device_driver *dev, char *buf)
> +{
> + return scnprintf(buf, PAGE_SIZE, "%s", ipath_core_version);
> +}
Any reason you left a "\n" off of this attribute?
> +static ssize_t show_atomic_stats(struct device_driver *dev, char *buf)
> +{
> + memcpy(buf, &ipath_stats, sizeof(ipath_stats));
> +
> + return sizeof(ipath_stats);
> +}
I think putting a whole binary struct in a sysfs attribute is
considered a no-no.
> +static ssize_t show_boardversion(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct ipath_devdata *dd = dev_get_drvdata(dev);
> + return scnprintf(buf, PAGE_SIZE, "%s", dd->ipath_boardversion);
> +}
Another missing "\n"
^ permalink raw reply
* Re: [PATCH 9 of 20] ipath - char devices for diagnostics and lightweight subnet management
From: Roland Dreier @ 2006-03-09 23:20 UTC (permalink / raw)
To: Bryan O'Sullivan
Cc: rolandd, gregkh, akpm, davem, linux-kernel, openib-general
In-Reply-To: <eac2ad3017b5f160d24c.1141922822@localhost.localdomain>
Bryan> The ipath_sma.c file supports a lightweight userspace
Bryan> subnet management agent (SMA). This is used in deployments
Bryan> (such as HPC clusters) where a full Infiniband protocol
Bryan> stack is not needed.
I've never understood what forces you to maintain two separate SMAs.
Why can't you pick one of the two SMAs and use that unconditionally?
- R.
^ 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.