Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer
Can you reproduce it with other ftp client and/or server? I tried the proftpd-1.3.0a-1.fc6(kernel version is 2.6.19). The ftp stop problem does not happen. Therefore, this problem is reproduced when client's kernel-version is 2.6.20-rc1 or later and server is vsftpd. Server's kernel-version is not related with this problem. The ftp-stop-problem happens on client's PC. Please advise. Best Regards Komuro - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] KVM: Implement a few system configuration msrs
Ingo Oeser wrote:
Hi,
On Thursday, 28. December 2006 11:11, Avi Kivity wrote:
Index: linux-2.6/drivers/kvm/svm.c
===
--- linux-2.6.orig/drivers/kvm/svm.c
+++ linux-2.6/drivers/kvm/svm.c
@@ -1068,6 +1068,9 @@ static int emulate_on_interception(struc
static int svm_get_msr(struct kvm_vcpu *vcpu, unsigned ecx, u64 *data)
{
switch (ecx) {
+ case 0xc0010010: /* SYSCFG */
+ case 0xc0010015: /* HWCR */
+ case MSR_IA32_PLATFORM_ID:
case MSR_IA32_P5_MC_ADDR:
case MSR_IA32_P5_MC_TYPE:
case MSR_IA32_MC0_CTL:
What about just defining constants for these?
Then you can rip out these comments.
Same for linux-2.6/drivers/kvm/vmx.c
Yes, there are a few more of these as well. I'll clean them up once
things quiet down a bit.
--
error compiling committee.c: too many arguments to function
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: Explain a second alternative for multi-line macros.
On Mon, 1 Jan 2007, Segher Boessenkool wrote:
In this case, the second form
should be used when the macro needs to return a value (and you can't
use an inline function for whatever reason), whereas the first form
should be used at all other times.
that's a fair point, although it's certainly not the coding style
that's in play now. for example,
#define setcc(cc) ({ \
partial_status = ~(SW_C0|SW_C1|SW_C2|SW_C3); \
partial_status |= (cc) (SW_C0|SW_C1|SW_C2|SW_C3); })
This _does_ return a value though, bad example.
sigh ... you're right. here's a thought. my original patch
submission simply added an explanation for allowing the ({ }) notation
for defining a multi-line macro, without getting into recommending an
actual coding style. at a minimum, something like that should be
added to the style document.
if someone wants to extend that explanation recommending *when* each
of those two styles should be used, feel free. but a simple
decription of alternatives should *at least* be added, no?
rday
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86-64 Calgary: tighten up printks
Signed-off-by: Muli Ben-Yehuda [EMAIL PROTECTED]
---
arch/x86_64/kernel/pci-calgary.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86_64/kernel/pci-calgary.c b/arch/x86_64/kernel/pci-calgary.c
index 87d90cb..3d65b1d 100644
--- a/arch/x86_64/kernel/pci-calgary.c
+++ b/arch/x86_64/kernel/pci-calgary.c
@@ -1068,6 +1068,8 @@ void __init detect_calgary(void)
if (!early_pci_allowed())
return;
+ printk(KERN_DEBUG Calgary: detecting Calgary via BIOS EBDA area\n);
+
ptr = (unsigned long)phys_to_virt(get_bios_ebda());
rio_table_hdr = NULL;
@@ -1088,14 +1090,14 @@ void __init detect_calgary(void)
offset = *((unsigned short *)(ptr + offset));
}
if (!rio_table_hdr) {
- printk(KERN_ERR Calgary: Unable to locate
- Rio Grande Table in EBDA - bailing!\n);
+ printk(KERN_DEBUG Calgary: Unable to locate Rio Grande table
+ in EBDA - bailing!\n);
return;
}
ret = build_detail_arrays();
if (ret) {
- printk(KERN_ERR Calgary: build_detail_arrays ret %d\n, ret);
+ printk(KERN_DEBUG Calgary: build_detail_arrays ret %d\n, ret);
return;
}
@@ -1128,6 +1130,9 @@ void __init detect_calgary(void)
}
}
+ printk(KERN_DEBUG Calgary: finished detection, Calgary %s\n,
+ calgary_found ? found : not found);
+
if (calgary_found) {
iommu_detected = 1;
calgary_detected = 1;
--
1.4.1
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: replace memset(...,0,PAGE_SIZE) calls with clear_page()?
On Mon, 1 Jan 2007, Folkert van Heusden wrote: regarding alignment that don't allow clear_page() to be used copy_page() in the memcpy() case), but it's going to need a lot of Maybe these optimalisations should be in the coding style docs? i was thinking of submitting the following as a new chapter for the doc -- it would address *some* of these issues: Chapter XX: Page-related memory management The following functions and macro definitions are available via include/linux/gfp.h for page-based memory management: struct page *alloc_pages(gfp_mask, order); unsigned long __get_free_pages(gfp_mask, order); unsigned long get_zeroed_page(gfp_mask); void __free_pages(struct page *page, order); void free_pages(unsigned long addr, order); #define alloc_page(gfp_mask) alloc_pages(gfp_mask, 0) #define __get_free_page(gfp_mask) __get_free_pages((gfp_mask),0) #define __free_page(page) __free_pages((page), 0) #define free_page(addr) free_pages((addr),0) #define __get_dma_pages(gfp_mask, order) \ __get_free_pages((gfp_mask) | GFP_DMA,(order)) Given the above, some basic suggestions for page-based memory management: (a) If you need to allocate or free a single page, use the single page version of the routine/macro, rather than calling the multi-page version with an order value of zero, such as: alloc_pages(gfp_mask, 0); /* no */ alloc_page(gfp_mask); /* better */ (b) If you need to allocate a single zeroed page by logical address, use get_zeroed_page(), rather than __get_free_page() followed by a call to memset() to clear that page. (c) If you need to specifically allocate some DMA pages, use the __get_dma_pages() macro, as in: __get_free_pages(GFP_KERNEL|GFP_DMA, order) /* no */ __get_dma_pages(GFP_KERNEL, order) /* better */ (d) If you need to clear (zero) a page, be aware that every architecture defines a clear_page() routine, either as a macro in include/arch/page.h or as an assembler routine. You should check if it's appropriate to use that routine/macro, rather than making an explicit call to memset(...,0, PAGE_SIZE). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: replace memset(...,0,PAGE_SIZE) calls with clear_page()?
On Mon, Jan 01, 2007 at 02:59:32AM +0100, Folkert van Heusden wrote: regarding alignment that don't allow clear_page() to be used copy_page() in the memcpy() case), but it's going to need a lot of Maybe these optimalisations should be in the coding style docs? For what purpose? CodingStyle is not about documenting usage constraints for every minor part of the kernel. If someone intends to use an API, it's up to them to figure out the semantics for doing so. Let's not confuse common sense with style. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/core/flow.c: compare data with memcmp
From: Daniel_Marjamäki [EMAIL PROTECTED] Date: Mon, 1 Jan 2007 08:47:48 +0100 So you mean that in this particular case it's faster with a handcoded comparison than memcmp? Because both key1 and key2 are located at word-aligned addresses? That's fascinating. Essentially, yes. However, I wonder. GCC should be able to see this also, and if it expands the memset() inline the code emitted should be very similar. It is something to investigate on a few cpu types, for sure. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Open Firmware device tree virtual filesystem
From: David Kahn [EMAIL PROTECTED] Date: Sun, 31 Dec 2006 19:37:52 -0800 IMHO, the directory entries in the filesystem should be in the form [EMAIL PROTECTED] (eg: /[EMAIL PROTECTED],0, pci is the node name, @ is the separator character defined by IEEE 1275, and 1f,0 is the unit-address, which are always guaranteed to be unique. That's part of the reason we did a separate implementation. I'm not sure how we'll resolve that part of it or what problem that code is trying to resolve by changing the directory names that appear in the filesystem in a rather odd way. It's not possible to have two ambiguously fully qualified nodes in the OFW device tree, otherwise you would never be able to select a specific one by name. Absolutely, and if you look that's how Sparc's openpromfs names things now. It even goes through all of the trouble to make sure the unit addressing matches what the Sparc OBP uses precisely. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Open Firmware device tree virtual filesystem
From: Segher Boessenkool [EMAIL PROTECTED] Date: Mon, 1 Jan 2007 04:33:13 +0100 All we've done is created a trivial implementation for exporting the device tree to userland that isn't burdened by the powerpc and sparc legacy code that's in there now. So now we'll have _3_ different implementations of exporting the OFW device tree via procfs. Your's, the proc_devtree of powerpc, and sparc's /proc/openprom That doesn't make any sense to me, having 3 ways of doing the same exact thing and making no attempt to share code at all. Not the same exact thing -- using a text representation for the property contents is a very different thing (and completely braindead). The filesystem bit is for groveling around and getting information from the shell prompt, or shell scripts. Text processing. If you want the binary bits, export it with something like /dev/openprom. We don't generally export binary representation files out of /proc or /sys, in fact this rule I believe is layed our precisely somewhere at least in the sysfs case. Every architecture that supports the device tree filesystem, initialises a struct device_tree_ops with a bunch of pointers to functions that allow you to traverse the device tree and read its properties (and maybe write properties, or even delete and create new nodes. The devtree filesystem code simply calls into these functions to do the actual operations on the device tree (access an in-kernel data structure, call the OF, or both -- or something entirely different, who knows). That's the only key point in my opinion, any clean interface that sits in front of this stuff is fine as long as it encompasses all of the necessary operations and allows just about any implementation underneath. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/core/flow.c: compare data with memcmp
Hello!
I have done a little testing on my own. My results is that memcpy is
many times faster even with aligned data.
I am testing in an ordinary console program. I am including the code below.
If I'm doing something wrong, please tell me so.
As you can see I am not using the same datadeclarations as the kernel
but I'm testing the algorithm here not the data. By testing various
data and types of data I can make sure the algorithm behaves correctly
in all situations.
The datamember 'd' in flowi is not part of the comparison, but by
changing it into an 'unsigned int' it becomes part of the comparison.
const int NUM_REP = 0x7FFF;
typedef unsigned int flow_compare_t;
struct flowi {
unsigned int a,b,c;
unsigned char d;
};
/* I hear what you're saying, use memcmp. But memcmp cannot make
* important assumptions that we can here, such as alignment and
* constant size.
*/
static int flow_key_compare(struct flowi *key1, struct flowi *key2)
{
flow_compare_t *k1, *k1_lim, *k2;
const int n_elem = sizeof(struct flowi) / sizeof(flow_compare_t);
k1 = (flow_compare_t *) key1;
k1_lim = k1 + n_elem;
k2 = (flow_compare_t *) key2;
do {
if (*k1++ != *k2++)
return 1;
} while (k1 k1_lim);
return 0;
}
static int flow_key_compare2(struct flowi *key1, struct flowi *key2)
{
return memcmp(key1, key2, (sizeof(struct flowi) /
sizeof(flow_compare_t)) * sizeof(flow_compare_t));
}
int main()
{
struct flowi key1 = {0,1,2,3};
struct flowi key2 = {0,1,2,0};
char str[300];
int i;
/* put data in aligned addresses */
struct flowi *k1 = (struct flowi *)((int)(str[100]) 0xFFF0);
struct flowi *k2 = (struct flowi *)((int)(str[200]) 0xFFF0);
memcpy(k1, key1, sizeof(struct flowi));
memcpy(k2, key2, sizeof(struct flowi));
/* Compare data */
printf(compare1..\n);
for (i = 0; i NUM_REP; i++)
flow_key_compare(k1, k2);
printf(compare2..\n);
for (i = 0; i NUM_REP; i++)
flow_key_compare2(k1, k2);
printf((flow_key_compare(k1,k2)==(flow_key_compare2(k1,k2)?1:0))?ok\n:error\n);
return 0;
}
2007/1/1, Daniel Marjamäki [EMAIL PROTECTED]:
Hello!
So you mean that in this particular case it's faster with a handcoded
comparison than memcmp? Because both key1 and key2 are located at
word-aligned addresses?
That's fascinating.
Best regards,
Daniel
2006/12/31, David Miller [EMAIL PROTECTED]:
From: Daniel_Marjamäki [EMAIL PROTECTED]
Date: Sun, 31 Dec 2006 17:37:05 +0100
From: Daniel Marjamäki
This has been tested by me.
Signed-off-by: Daniel Marjamäki [EMAIL PROTECTED]
Please do not do this.
memcmp() cannot assume the alignment of the source and
destination buffers and thus will run more slowly than
that open-coded comparison.
That code was done like that on purpose because it is
one of the most critical paths in the networking flow
cache lookup which runs for every IPSEC packet going
throught the system.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Happy New Year (and v2.6.20-rc3 released)
On Monday 01 January 2007 10:45, you wrote: | Cyrill V. Gorcnov wrote: | On Monday 01 January 2007 04:19, you wrote: | | | | In order to not get in trouble with MADR (Mothers Against Drunk | | Releases) I decided to cut the 2.6.20-rc3 release early rather than wait | | for midnight, because it's bound to be new years _somewhere_ out there. So | | here's to a happy 2007 for everybody. | | | | I've tried to clone linux git repo and got: | | git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git | fatal: unexpected EOF | fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed. | | What's wrong? | | I think that git does not like year rollover. I've tried it after Linus | sent message out, and it was not giving me anything new (cca from 5PM | PST when Linus sent change to 8PM). Then it gave out random changes | (8PM to 9PM). After that it was dead, as you've noticed. But after | that I was able to get 2.6.20-rc3 out - compiling now. So perhaps just | try it again... | Petr | | P.S.: Happy New Year. Here in California we still have 15 minutes of | year 2006 to go. | | | Yea, I've got linux git clone later. I think that was some files activity on git server so that is why I was noticed with fatal: unexpected EOF git message. -- - Cyrill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: replace memset(...,0,PAGE_SIZE) calls with clear_page()?
Given the above, some basic suggestions for page-based memory management: (a) If you need to allocate or free a single page, use the single page version of the routine/macro, rather than calling the multi-page version with an order value of zero, such as: alloc_pages(gfp_mask, 0); /* no */ alloc_page(gfp_mask); /* better */ (b) If you need to allocate a single zeroed page by logical address, use get_zeroed_page(), rather than __get_free_page() followed by a call to memset() to clear that page. both look good... I'd be in favor of this. Maybe also add a part about using GFP_KERNEL whenever possible, GFP_NOFS from filesystem writeout code and GFP_NOIO from block writeout code (and never doing in_interrupt()?GFP_ATOMIC:GFP_KERNEL !) (c) If you need to specifically allocate some DMA pages, use the __get_dma_pages() macro, as in: __get_free_pages(GFP_KERNEL|GFP_DMA, order) /* no */ __get_dma_pages(GFP_KERNEL, order) /* better */ this.. does not really. GFP_DMA is an ancient artifact from the ISA days. Better to describe the dma mapping interface (well give a pointer to the doc that already exists about that), that one is REALLY for allocating dma pages in this century. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: new harddrive with media error
Al Viro wrote: From the look of it, I'd say that it's size reported by disk being more than what's accessible. Take a look at the block numbers... How so? ata1.00: ATA-7, max UDMA/133, 976773168 sectors: LBA48 NCQ (depth 0/32) sda: Current: sense key: Medium Error Additional sense: Unrecovered read error - auto reallocate failed end_request: I/O error, dev sda, sector 976751999 Buffer I/O error on device sda1, logical block 976751936 It seems like a genuine media error to me. Many drives suffer a number of media errors in its lifetime. Read errors happen regularly and most such errors are corrected by ECC, but sometimes you're just not lucky enough. Some of them are real bad sectors while others might be due to degraded record quality even when the sector itself isn't necessary bad. In most cases, the drive will reallocate the area including the sector when you write to it. Simply rewriting the affected file should solve the problem. Examine the result of 'smartctl -d ata -a' just in case. For data of any importance, it's always wise to use raid 1 or 5 and backup regularly. Both help keeping your data safe in more than one way. Raid re-sync is an easy way out of partial media failures and backing up not only gives you another copy of the data but gives the drives chance to detect degrading area quickly and reallocate before actual read failures begin to occur. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: replace memset(...,0,PAGE_SIZE) calls with clear_page()?
On Mon, 1 Jan 2007, Arjan van de Ven wrote: Given the above, some basic suggestions for page-based memory management: (a) If you need to allocate or free a single page, use the single page version of the routine/macro, rather than calling the multi-page version with an order value of zero, such as: alloc_pages(gfp_mask, 0); /* no */ alloc_page(gfp_mask); /* better */ (b) If you need to allocate a single zeroed page by logical address, use get_zeroed_page(), rather than __get_free_page() followed by a call to memset() to clear that page. both look good... I'd be in favor of this. Maybe also add a part about using GFP_KERNEL whenever possible, GFP_NOFS from filesystem writeout code and GFP_NOIO from block writeout code (and never doing in_interrupt()?GFP_ATOMIC:GFP_KERNEL !) it strikes me that that latter part is starting to go beyond the scope of simple coding style aesthetics and getting into actual coding distinctions. would that really be appropriate for the CodingStyle doc? i'm just asking. (c) If you need to specifically allocate some DMA pages, use the __get_dma_pages() macro, as in: __get_free_pages(GFP_KERNEL|GFP_DMA, order) /* no */ __get_dma_pages(GFP_KERNEL, order) /* better */ this.. does not really. GFP_DMA is an ancient artifact from the ISA days. Better to describe the dma mapping interface (well give a pointer to the doc that already exists about that), that one is REALLY for allocating dma pages in this century. ok, i was just trying to make the calls consistent based on what i could see in the current source code. i'm still reviewing the material on DMA -- feel free to suggest better wording. rday p.s. what DMA doc are you referring to above? DMA-mapping.txt? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Happy New Year (and v2.6.20-rc3 released)
On Monday 01 January 2007 02:19, Linus Torvalds wrote: In order to not get in trouble with MADR (Mothers Against Drunk Releases) I decided to cut the 2.6.20-rc3 release early rather than wait for midnight, because it's bound to be new years _somewhere_ out there. So here's to a happy 2007 for everybody. I hope that upcoming gcc 4.2 will be considered as supported compiler before final 2.6.20 release and patch which broke build is reverted or the thing fixed :) MODPOST 1371 modules WARNING: _proxy_pda [fs/fuse/fuse.ko] undefined! make[1]: *** [__modpost] Błąd 1 + some other modules which I didn't enable this time -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Happy New Year (and v2.6.20-rc3 released)
On 1/1/07, Linus Torvalds [EMAIL PROTECTED] wrote: In order to not get in trouble with MADR (Mothers Against Drunk Releases) I decided to cut the 2.6.20-rc3 release early rather than wait for midnight, because it's bound to be new years _somewhere_ out there. So here's to a happy 2007 for everybody. The big thing at least for me personally is that nasty shared mmap corruption fix, but there's a number of other changes in here, many of them just documentation (and some media and network drivers). Shortlog and diffstat appended.. The git trees have been updated, and the tar-tree and patches seem to have finisged crawling out my poor DSL connection too. As usual, mirroring might take a while, although the delay has not been all that horrible lately, so it's probably going to be up-to-date by the time the hangovers are mostly gone. At which point the first thing on any self-respecting geek's mind should obviously be: is there a new kernel release for me to try? Right? Right ! And this one is still broken in -rc3: Subject: kernel panics on boot (libata-sff) References : http://lkml.org/lkml/2006/12/3/99 http://lkml.org/lkml/2006/12/14/153 http://lkml.org/lkml/2006/12/24/33 Submitter : Alessandro Suardi [EMAIL PROTECTED] Caused-By : Alan Cox [EMAIL PROTECTED] commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f Handled-By : Alan Cox [EMAIL PROTECTED] Status : people are working on a fix Happy 2007 everyone, --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Freezer.h updated patch.
On Sun, Oct 22, Nigel Cunningham wrote: +++ b/drivers/macintosh/via-pmu.c -#include linux/suspend.h +#include linux/freezer.h This change will lead to compile errors with -Wimplicit-function-declaration. What part of freezer.h is used in via-pmu.c? drivers/macintosh/via-pmu.c:2014: warning: implicit declaration of function `pm_prepare_console' drivers/macintosh/via-pmu.c:2139: warning: implicit declaration of function `pm_restore_console' - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Sparse 0.2 warnings from {asm,net}/checksum.h
With sparse 0.2, my previously sparse-clean driver generates the following warnings: include/asm/checksum.h:182:6: warning: symbol 'sum' shadows an earlier one include/asm/checksum.h:178:28: originally declared here include/net/checksum.h:33:6: warning: symbol 'sum' shadows an earlier one include/net/checksum.h:31:27: originally declared here Architecture is i386. The lines referred to are in the functions csum_and_copy_to_user() and csum_and_copy_from_user(), but I don't see why sparse would emit such a warning for that code. Any chance of getting rid of these? Thanks Tilman -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: [PATCH] Documentation: Explain a second alternative for multi-line macros.
On Sun, Dec 31, 2006 at 02:32:25PM -0500, Robert P. J. Day wrote:
+ (a) Enclose those statements in a do - while block:
+
+ #define macrofun(a, b, c) \
+ do {\
+ if (a == 5) \
+ do_this(b, c); \
+ } while (0)
nitpick, please don't add an indentaion level for the do {. Do this
should look like:
#define macrofun(a, b, c) \
do {\
if (a == 5) \
do_this(b, c); \
} while (0)
+ (b) Use the gcc extension that a compound statement enclosed in
+ parentheses represents an expression:
+
+ #define macrofun(a, b, c) ({\
if (a == 5) \
do_this(b, c); \
- } while (0)
+ })
I'd rather document to not use this - it makes the code far less
redable. And it's a non-standard extension, something we only
use if it provides us a benefit which it doesn't here.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Using _syscall3 to manipulate files in a driver
On Sun, Dec 31, 2006 at 12:13:52PM -0500, Jon Smirl wrote: What is the simplest way to get open/close/read/write working under 2.6.20-rc2? I know this is horrible and shouldn't be done, I just want to get the driver working long enough to see if it is worth saving. I'm no expert, but try looking at the firmware loading code in the kernel, it reads files, so it should contain the code you need. It may even do exactly what you want, perhaps. Good luck! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: Explain a second alternative for multi-line macros.
On Mon, 1 Jan 2007, Christoph Hellwig wrote:
On Sun, Dec 31, 2006 at 02:32:25PM -0500, Robert P. J. Day wrote:
+ (a) Enclose those statements in a do - while block:
+
+ #define macrofun(a, b, c) \
+ do {\
+ if (a == 5) \
+ do_this(b, c); \
+ } while (0)
nitpick, please don't add an indentaion level for the do {. Do this
should look like:
#define macrofun(a, b, c) \
do {\
if (a == 5) \
do_this(b, c); \
} while (0)
the former is the way it's presented in CodingStyle currently, it
wasn't my personal opinion on the subject. i was just reproducing
what was already there.
+ (b) Use the gcc extension that a compound statement enclosed in
+ parentheses represents an expression:
+
+ #define macrofun(a, b, c) ({\
if (a == 5) \
do_this(b, c); \
- } while (0)
+ })
I'd rather document to not use this - it makes the code far less
redable. And it's a non-standard extension, something we only
use if it provides us a benefit which it doesn't here.
it might be a bit late to put a cork in *that* bottle:
$ grep -r #define.*({ *
rday
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6.20-rc3] PATA_MARVELL: total machine freeze
Hello,
Hardware
MOBOIntel DG965SS (chipset G965 Express)
PATA CDRW LG GCE-8400B
I'm using PATA_MARVELL driver, and trying to burn a CD results in a
total machine freeze (no SysRq / no output over serial console).
The freeze doesn't happens immediately: the writing process stalls for
several seconds during which the machine works flawlessy.
I've found that even a simple sdparm -a /dev/sr0 have the same
effect, so I've done an strace:
execve(/usr/bin/sdparm, [sdparm, -a, /dev/sr0], [/* 63 vars */]) = 0
brk(0) = 0x52c000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2b3bfa0b3000
uname({sys=Linux, node=tux, ...}) = 0
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=129796, ...}) = 0
mmap(NULL, 129796, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b3bfa0b4000
close(3)= 0
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\\322\1..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1256568, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2b3bfa0d4000
mmap(NULL, 2273448, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2b3bfa1b4000
mprotect(0x2b3bfa2d6000, 1048576, PROT_NONE) = 0
mmap(0x2b3bfa3d6000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x122000) = 0x2b3bfa3d6000
mmap(0x2b3bfa3db000, 16552, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b3bfa3db000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2b3bfa3e
arch_prctl(ARCH_SET_FS, 0x2b3bfa3e06d0) = 0
mprotect(0x2b3bfa3d6000, 12288, PROT_READ) = 0
mprotect(0x2b3bfa1b2000, 4096, PROT_READ) = 0
munmap(0x2b3bfa0b4000, 129796) = 0
open(/dev/sr0, O_RDONLY|O_NONBLOCK) = 3
brk(0) = 0x52c000
brk(0x54d000) = 0x54d000
ioctl(3, SG_IO, 0x52c010) = 0
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2b3bfa0b4000
write(1, /dev/sr0: HL-DT-ST CD-RW GC..., 57) = 57
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
write(1, Read write error recovery mode p..., 37) = 37
write(1, AWRE0 [cha: n, def: ..., 35) = 35
write(1, ARRE0 [cha: n, def: ..., 35) = 35
write(1, TB 0 [cha: n, def: ..., 35) = 35
write(1, RC 0 [cha: n, def: ..., 35) = 35
write(1, EER 0 [cha: n, def: ..., 35) = 35
write(1, PER 0 [cha: n, def: ..., 35) = 35
write(1, DTE 0 [cha: n, def: ..., 35) = 35
write(1, DCR 0 [cha: y, def: ..., 35) = 35
write(1, RRC32 [cha: y, def: 3..., 35) = 35
write(1, COR_S 0 [cha: n, def: ..., 35) = 35
write(1, HOC 0 [cha: n, def: ..., 35) = 35
write(1, DSOC0 [cha: n, def: ..., 35) = 35
write(1, EMCDR 0 [cha: n, def: ..., 35) = 35
write(1, WRC 0 [cha: n, def: ..., 35) = 35
write(1, ERTL0 [cha: n, def: ..., 35) = 35
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
write(1, Write parameters (MMC) mode page..., 34) = 34
write(1, BUFE0 [cha: y, def: ..., 35) = 35
write(1, LS_V0 [cha: n, def: ..., 35) = 35
write(1, TST_W 0 [cha: y, def: ..., 35) = 35
write(1, WR_T1 [cha: y, def: ..., 35) = 35
write(1, MULTI_S 0 [cha: y, def: ..., 35) = 35
write(1, FP 0 [cha: y, def: ..., 35) = 35
write(1, COPY0 [cha: y, def: ..., 35) = 35
write(1, TRACK_M 4 [cha: y, def: ..., 35) = 35
write(1, DBT 8 [cha: y, def: ..., 35) = 35
write(1, LINK_S 0 [cha: n, def: ..., 35) = 35
write(1, IAC 0 [cha: y, def: ..., 35) = 35
write(1, SESS_F 0 [cha: y, def: ..., 35) = 35
write(1, PACK_S 0 [cha: y, def: ..., 35) = 35
write(1, APL 150 [cha: y, def:15..., 35) = 35
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
ioctl(3, SG_IO, 0x52c010) = 0
write(1, Protocol specific logical unit m..., 42) = 42
write(1, LUPID 0 [cha: n,
Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
On Sat, 2006-12-30 at 10:26 -0800, Linus Torvalds wrote: On Sat, 30 Dec 2006, Russell King wrote: And here's the flush_anon_page() part. This looks fine to me (if you need my ack). Add flush_anon_page() for ARM, to avoid data corruption issues when using fuse or other subsystems using get_user_pages(). Btw, since this doesn't actually change any code for anybody but ARM, just adds a parameter that is obviously unused by everybody else, and if it actually fixes a real bug for ARM, I'll obviously happily take it even before 2.6.20. So go ahead put it in your ARM tree, and we'll get some testing through that. And just ask me to pull at some point. I wonder why nobody else seems to have a flush_anon_page()? This would seem to be a potential issue for architectures like sparc too.. Although maybe sparc can do a flush by physical index with flush_dcache_page(). The sparc handling of anonymous pages is different ... they accitentally sweep them up in flush_dcache_page(). When I audited the architectures to try to make fuse work on parisc, parisc and arm were the only ones that actually needed flush_anon_page(). James - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: chaostables-0.2 2.6.19.1
On Jan 1 2007 15:38, Folkert van Heusden wrote: Hi, I'm trying to compile chaostables v0.2 on a system with kernel 2.6.19.1 and c-compiler 3.4.6: [EMAIL PROTECTED]:/usr/src/chaostables-0.2/kernel# make all make -C /lib/modules/2.6.19.1/build M=$PWD modules; make[1]: Entering directory `/usr/src/linux-2.6.19.1' CC [M] /usr/src/chaostables-0.2/kernel/xt_CHAOS.o /usr/src/chaostables-0.2/kernel/xt_CHAOS.c: In function `xt_chaos_target': /usr/src/chaostables-0.2/kernel/xt_CHAOS.c:53: error: too many arguments to function Yes I found this one this morning. The issue is simple: function signatures have changed in 2.6.19 and 2.6.20 which I did not all catch yet. chaostables compiles fine with 2.6.18 however. I shall have it workarounded in the next release. Thanks for noticing! (cc to linuxkernel and netfilter before more people run into the same problem) Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ACPI: EC: evaluating _Q10
I know this topic was already on the list. But 2.6.20-rc3 still gives me tons of these messages in the log buffer: ACPI: EC: evaluating _Q10 ACPI: EC: evaluating _Q10 ACPI: EC: evaluating _Q10 ACPI: EC: evaluating _Q10 ACPI: EC: evaluating _Q10 [and so on] Is this an error at all? With kind regards Thomas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Using _syscall3 to manipulate files in a driver
On Sun, Dec 31, 2006 at 12:13:52PM -0500, Jon Smirl wrote: I have the source code for a vendor written driver that is targeted at 2.6.9. It includes this and then proceeds to manipulate files from the driver. asmlinkage _syscall3(int,write,int,fd,const char *,buf,off_t,count) asmlinkage _syscall3(int,read,int,fd,char *,buf,off_t,count) asmlinkage _syscall3(int,open,const char *,file,int,flag,int,mode) asmlinkage _syscall1(int,close,int,fd) What is the simplest way to get open/close/read/write working under 2.6.20-rc2? I know this is horrible and shouldn't be done, I just want to get the driver working long enough to see if it is worth saving. I'm on x86. In-kernel syscalls were removed by f5738ceed46782aea7663d62cb6398eb05fc4ce0. You can stub them back in if you want a quick and lame fix for the driver, but you're better off rewriting it to behave sensibly rather than wasting your time on vendor hacks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
On Thu, 2006-12-21 at 16:57 +, Russell King wrote: I'm not entirely convinced that it can be replaced. What if the page is in the page cache and is shared with other processes? That quite clearly falls under flush_dcache_page()'s remit. Actually, it should work. flush_dcache_page() is the big hammer, it clears the caches of all the user processes and the kernel for that page. On most architectures this is not that expensive, but on parisc it is. Most of the paths out of fuse have already called flush_dcache_page() coming in to make the page coherent for the kernel to use. Then fuse writes data to the page. There's no point calling it again since there shouldn't be anything in the user cache (the model has the kernel owning the page), so flush_kernel_dcache_page() is the shortcut to simply flush out the kernel cache above the page (knowing the users still have the page uncached). James - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: chaostables-0.2 2.6.19.1
I'm trying to compile chaostables v0.2 on a system with kernel 2.6.19.1 and c-compiler 3.4.6: [EMAIL PROTECTED]:/usr/src/chaostables-0.2/kernel# make all make -C /lib/modules/2.6.19.1/build M=$PWD modules; make[1]: Entering directory `/usr/src/linux-2.6.19.1' CC [M] /usr/src/chaostables-0.2/kernel/xt_CHAOS.o /usr/src/chaostables-0.2/kernel/xt_CHAOS.c: In function `xt_chaos_target': /usr/src/chaostables-0.2/kernel/xt_CHAOS.c:53: error: too many arguments to function Yes I found this one this morning. The issue is simple: function signatures have changed in 2.6.19 and 2.6.20 which I did not all catch yet. chaostables compiles fine with 2.6.18 however. I shall have it workarounded in the next release. Thanks for noticing! (cc to linuxkernel and netfilter before more people run into the same problem) Not wanting to put you under pressure but when is that version expected? Folkert van Heusden -- Looking for a cheap but fast webhoster with an excellent helpdesk? http://keetweej.vanheusden.com/redir.php?id=1001 -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.19] mmc: Add support for SDHC cards
I will post the updated diff as a separate follow up. Pierre Ossman wrote: When you have a commit message larger than the patch, you know there is something wrong. ;) Please skip the part about MMC at least. Heh. I forget that you don't want to manually alter the email. Will do. Actually, the way the spec describes version 2.0 of the CSD leaves my stomach a bit upset. I think we will find cards that put bogus values in the fields, expecting most hosts to use the well defined values. So I'd prefer a switch statement here, where csd_struct == 1 results in hard coded values for many fields. I'm less pessimistic than you about this, but I have no problems with hard-coding. +cmd.opcode = SD_SEND_IF_COND; Put this in mmc_setup() with the rest of the initialisation. Hiding in here just confuses things. Done. I thought we needed it before both SD_APP_SEND_OP_COND calls but it's only needed before the second one so I've moved it inline into mmc_setup. Also, please add a comment about why you manipulate the ocr. Done. Wrong. R7 is defined as MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE. (So is R6 btw, wonder why that is...) Ah - I knew they were both the same so I made R7 match R6. :-) I've added OPCODE to both. Thanks, --phil - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: chaostables-0.2 2.6.19.1
On Jan 1 2007 16:15, Folkert van Heusden wrote: I'm trying to compile chaostables v0.2 on a system with kernel 2.6.19.1 and c-compiler 3.4.6: /usr/src/chaostables-0.2/kernel/xt_CHAOS.c: In function `xt_chaos_target': /usr/src/chaostables-0.2/kernel/xt_CHAOS.c:53: error: too many arguments to function Yes I found this one this morning. The issue is simple: function signatures have changed in 2.6.19 and 2.6.20 which I did not all catch yet. chaostables compiles fine with 2.6.18 however. I shall have it workarounded in the next release. Thanks for noticing! (cc to linuxkernel and netfilter before more people run into the same problem) Not wanting to put you under pressure but when is that version expected? Just about now, I just made a snapshot. http://jengelh.hopto.org/f/chaostables/chaostables-0.3.tar.bz2 (The new (note above: snapshot) SREJECT is not complete. Just fixed the 2.6.19 and 2.6.20 compiles.) -`J' -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.19] mmc: Add support for SDHC cards (Take 2)
Thanks to the generous donation of an SDHC card by John Gilmore, and the
surprisingly enlightened decision by the SD Card Association to publish
useful specs, I've been able to bash out support for SDHC. The changes
are not too profound:
i) Add a card flag indicating the card uses block level addressing and check
it in the block driver. As we never took advantage of byte-level addressing,
this simply involves skipping the block - byte translation when sending
commands.
ii) The layout of the CSD is changed - a set of fields are discarded to make
space
for a larger C_SIZE. We did not reference any of the discarded fields except
those
related to the C_SIZE.
iii) Read and write timeouts are fixed values and not calculated from CSD
values.
iv) Before invoking SEND_APP_OP_COND, we must invoke the new SEND_IF_COND to
inform
the card we support SDHC.
I've done some basic read and write tests and everything seems to work fine but
one
should obviously use caution in case it eats your data.
Signed-off-by: Philipl Langdale [EMAIL PROTECTED]
---
drivers/mmc/mmc.c| 115 ---
drivers/mmc/mmc_block.c |8 ++
include/linux/mmc/card.h |3 +
include/linux/mmc/mmc.h |3 -
include/linux/mmc/protocol.h | 13
5 files changed, 112 insertions(+), 30 deletions(-)
--- /usr/src/linux/drivers/mmc/mmc.c2007-01-01 07:12:02.0 -0800
+++ linux-2.6.19-sdhc/drivers/mmc/mmc.c 2007-01-01 06:41:01.0 -0800
@@ -289,7 +289,10 @@
else
limit_us = 10;
- if (timeout_us limit_us) {
+ /*
+* SDHC cards always use these fixed values.
+*/
+ if (timeout_us limit_us || mmc_card_blockaddr(card)) {
data-timeout_ns = limit_us * 1000;
data-timeout_clks = 0;
}
@@ -588,34 +591,65 @@
if (mmc_card_sd(card)) {
csd_struct = UNSTUFF_BITS(resp, 126, 2);
- if (csd_struct != 0) {
+
+ switch (csd_struct) {
+ case 0:
+ m = UNSTUFF_BITS(resp, 115, 4);
+ e = UNSTUFF_BITS(resp, 112, 3);
+ csd-tacc_ns = (tacc_exp[e] * tacc_mant[m] + 9) /
10;
+ csd-tacc_clks = UNSTUFF_BITS(resp, 104, 8) * 100;
+
+ m = UNSTUFF_BITS(resp, 99, 4);
+ e = UNSTUFF_BITS(resp, 96, 3);
+ csd-max_dtr = tran_exp[e] * tran_mant[m];
+ csd-cmdclass = UNSTUFF_BITS(resp, 84, 12);
+
+ e = UNSTUFF_BITS(resp, 47, 3);
+ m = UNSTUFF_BITS(resp, 62, 12);
+ csd-capacity = (1 + m) (e + 2);
+
+ csd-read_blkbits = UNSTUFF_BITS(resp, 80, 4);
+ csd-read_partial = UNSTUFF_BITS(resp, 79, 1);
+ csd-write_misalign = UNSTUFF_BITS(resp, 78, 1);
+ csd-read_misalign = UNSTUFF_BITS(resp, 77, 1);
+ csd-r2w_factor = UNSTUFF_BITS(resp, 26, 3);
+ csd-write_blkbits = UNSTUFF_BITS(resp, 22, 4);
+ csd-write_partial = UNSTUFF_BITS(resp, 21, 1);
+ break;
+ case 1:
+ /*
+* This is a block-addressed SDHC card. Most
+* interesting fields are unused and have fixed
+* values. To avoid getting tripped by buggy cards,
+* we assume those fixed values ourselves.
+*/
+ mmc_card_set_blockaddr(card);
+
+ csd-tacc_ns = 0; /* Unused */
+ csd-tacc_clks = 0; /* Unused */
+
+ m = UNSTUFF_BITS(resp, 99, 4);
+ e = UNSTUFF_BITS(resp, 96, 3);
+ csd-max_dtr = tran_exp[e] * tran_mant[m];
+ csd-cmdclass = UNSTUFF_BITS(resp, 84, 12);
+
+ m = UNSTUFF_BITS(resp, 48, 22);
+ csd-capacity = (1 + m) 10;
+
+ csd-read_blkbits = 9;
+ csd-read_partial = 0;
+ csd-write_misalign = 0;
+ csd-read_misalign = 0;
+ csd-r2w_factor = 4; /* Unused */
+ csd-write_blkbits = 9;
+ csd-write_partial = 0;
+ break;
+ default:
printk(%s: unrecognised CSD structure version %d\n,
mmc_hostname(card-host), csd_struct);
mmc_card_set_bad(card);
return;
}
-
- m =
Re: Using _syscall3 to manipulate files in a driver
On 1/1/07, Paul Mundt [EMAIL PROTECTED] wrote:
On Sun, Dec 31, 2006 at 12:13:52PM -0500, Jon Smirl wrote:
I have the source code for a vendor written driver that is targeted at
2.6.9. It includes this and then proceeds to manipulate files from the
driver.
asmlinkage _syscall3(int,write,int,fd,const char *,buf,off_t,count)
asmlinkage _syscall3(int,read,int,fd,char *,buf,off_t,count)
asmlinkage _syscall3(int,open,const char *,file,int,flag,int,mode)
asmlinkage _syscall1(int,close,int,fd)
What is the simplest way to get open/close/read/write working under
2.6.20-rc2? I know this is horrible and shouldn't be done, I just want
to get the driver working long enough to see if it is worth saving.
I'm on x86.
In-kernel syscalls were removed by f5738ceed46782aea7663d62cb6398eb05fc4ce0.
You can stub them back in if you want a quick and lame fix for the
driver, but you're better off rewriting it to behave sensibly rather than
wasting your time on vendor hacks.
I was able to achieve a temporary work around by manipulating 'struct
file' directly. This fixed things enough so that I could load the
driver and check it out. zd1211 wireless is a case where we have the
vendor supplying and supporting a GPL driver based on 2.6.9 that is
300K and not very integrated into the networking code. Then there is
the zd1211rw project, 85K, which is in the kernel source and is a
rework of the vendor code by non-vendor developers, It is integrated
with the Linux networking internals.
The problem is that the vendor driver can do some things that the
zd1211rw version can't. I'm trying to figure out why some things are
working the vendor driver that fail in zd1211rw.
@@ -8684,7 +8691,8 @@ #endif
void zd1205_load_card_setting(struct zd1205_private *macp, u8 bInit)
{
- int ifp;
+ struct file *filp = NULL;
int bcount = 0;
mm_segment_t fs;
unsigned int file_length;
@@ -8705,12 +8713,17 @@ void zd1205_load_card_setting(struct zd1
set_fs(KERNEL_DS);
// open the file with the firmware for uploading
- if (ifp = open(config_filename, O_RDONLY, 0 ), ifp 0){
+ filp = filp_open(config_filename, O_RDONLY, 0);
+ if (IS_ERR_VALUE(PTR_ERR(filp))){
// error opening the file
ZD1211DEBUG(0, File opening did not success\n);
set_fs(fs);
return;
}
+ get_file(filp);
/* Get information about the file. */
//fstat (ifp, file_info);
@@ -8722,11 +8735,13 @@ void zd1205_load_card_setting(struct zd1
old_buffer = buffer;
/* Read the file into the buffer. */
- bcount = read(ifp, buffer, file_length);
+ bcount = filp-f_op-read(filp, buffer, file_length, 0);
ZD1211DEBUG(1, bcount=%d\n, bcount);
// close the file
- close(ifp);
+ filp_close(filp, 0);
// switch back the segment setting
set_fs(fs);
--
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: Explain a second alternative for multi-line macros.
On Dec 31 2006 19:23, Randy Dunlap wrote:
#define setcc(cc) ({ \
partial_status = ~(SW_C0|SW_C1|SW_C2|SW_C3); \
partial_status |= (cc) (SW_C0|SW_C1|SW_C2|SW_C3); })
This _does_ return a value though, bad example.
Where does it return a value? I don't see any uses of it
in arch/i386/math-emu/* that use it as returning a value.
And with a small change to put it inside a do-while block
instead of ({ ... }), it at least builds cleanly.
I expected some complaints.
If people want to return something from a ({ }) construct, they should do it
explicitly, e.g.
#define setcc(cc) ({ \
partial_status = ~(SW_C0|SW_C1|SW_C2|SW_C3); \
partial_status |= (cc) (SW_C0|SW_C1|SW_C2|SW_C3); \
partial_status; \
})
-`J'
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Happy New Year (and v2.6.20-rc3 released)
The final 2.6.20 release note should mention the following commit in some way: [NETFILTER]: Kconfig: improve conntrack selection It will break existing iptable setups without warning becausee it disables all related .config options. If one says NO to the new NF_CONNTRACK_ENABLED Netfilter connection tracking support, NAT and other stuff will disappear. One has to choose '2 Layer 3 Dependent Connection tracking (OBSOLETE)' in a following question, to keep most of the existing modules during a make oldconfig. Its not obvious why make oldconfig still asks that many questions about existing .config options. config-2.6.16.gz Description: application/gunzip
Re: new harddrive with media error
Thanks for the input of everybody. i think the drive is broken and i will return it. Happy gnu year @ all Alex Tejun Heo schrieb: Al Viro wrote: From the look of it, I'd say that it's size reported by disk being more than what's accessible. Take a look at the block numbers... How so? ata1.00: ATA-7, max UDMA/133, 976773168 sectors: LBA48 NCQ (depth 0/32) sda: Current: sense key: Medium Error Additional sense: Unrecovered read error - auto reallocate failed end_request: I/O error, dev sda, sector 976751999 Buffer I/O error on device sda1, logical block 976751936 It seems like a genuine media error to me. Many drives suffer a number of media errors in its lifetime. Read errors happen regularly and most such errors are corrected by ECC, but sometimes you're just not lucky enough. Some of them are real bad sectors while others might be due to degraded record quality even when the sector itself isn't necessary bad. In most cases, the drive will reallocate the area including the sector when you write to it. Simply rewriting the affected file should solve the problem. Examine the result of 'smartctl -d ata -a' just in case. For data of any importance, it's always wise to use raid 1 or 5 and backup regularly. Both help keeping your data safe in more than one way. Raid re-sync is an easy way out of partial media failures and backing up not only gives you another copy of the data but gives the drives chance to detect degrading area quickly and reallocate before actual read failures begin to occur. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
x86 instability with 2.6.1{8,9}
Hi, I've been running an athlon64 in 64-bit mode without problems, up to and incluing 2.6.19.1. A couple of weeks ago I decided to use it for testing x86 builds, since then it's been nothing but trouble in 32-bit mode. It still works fine when I boot it in 64-bit mode. I already had a 32-bit system on the disk, but it was somewhat old (gcc-3.4.6, udev from a long while ago, glibc-2.3.4) so I wasn't totally surprised when it started to spontaneously reboot. Eventually, I installed a recent system to build a fresh 32-bit system. Still suffered from reboots - sometimes within a few minutes of booting, sometimes it was fine for hours. Tried various versions of 2.6.18.x, eventually thought it was ok, built my new system in several stages. On Saturday it was running the fresh system under 2.6.18.6 for most of the day without problems (although admittedly the first part was from the console, and only the last 2 or 3 hours were running X). Yesterday I left it building arts, and it rebooted. It was then able to finish building much of kde, and then built 2.6.19.1. Booted into 2.6.19.1, spent several hours using the desktop and running compiles and tests. Today, in 2.6.19.1, the keyboard LEDs for caps and scroll lock started flashing about 30 minutes after I'd booted it, so I guess it had oopsed. Unfortunately, nothing from the oops made it to the logs, although SysRq+b worked, so I guess I need to look at the SysRq options before it happens again. So, at the moment I've still got nothing in the logs from any of this, and it isn't predictable. This all happens while running X (originally 6.8.2, now 7.1). I'm beginning to despair of getting any indications about what is going wrong. Any suggestions, please ? Current ver_linux and config follow. Ken If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux bluesbreaker 2.6.19.1 #1 PREEMPT Sun Dec 31 17:44:47 GMT 2006 i686 athlon-4 i386 GNU/Linux Gnu C 4.1.1 Gnu make 3.81 binutils 2.17 util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.39 Linux C Library libc.2.5 Dynamic linker (ldd) 2.5 Linux C++ Library 6.0.8 Procps 3.2.7 Kbd1.12 Sh-utils 6.6 udev 103 Modules Loaded snd_via82xx snd_mpu401_uart r8169 snd_rawmidi # # Automatically generated make config: don't edit # Linux kernel version: 2.6.19.1 # Sun Dec 31 17:37:29 2006 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODULE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set #
Re: [PATCH] [DISCUSS] Make the variable NULL after freeing it.
Hi,
On Monday, 1. January 2007 07:37, Amit Choudhary wrote:
--- Ingo Oeser [EMAIL PROTECTED] wrote:
#define kfree_nullify(x) do { \
if (__builtin_constant_p(x)) { \
kfree(x); \
} else { \
typeof(x) *__addr_x = x; \
Ok, I should change that line to
typeof(x) *__addr_x = (x); \
kfree(*__addr_x); \
*__addr_x = NULL; \
} \
} while (0)
Regards
Ingo Oeser
This is a nice approach but what if someone does kfree_nullify(x+20).
Then this works, because the side effect (+20) is evaluated only once.
AFAIK __builtin_constant_p() and typeof() are both free of side effects.
I decided to keep it simple. If someone is calling kfree_nullify() with
anything other than a
simple variable, then they should call kfree().
kfree_nullify() has to replace kfree() to be of any use one day. So this is not
an option.
Anybody thinking of Hey, this must be NULL afterwards!, will set it to NULL
himself.
Anybody else doesn't know or care about it, which is the case we like to catch.
But definitely an approach that takes care of all
situations is the best but I cannot think of a macro that can handle all
situations. The simple
macro that I sent earlier will catch all the other usage at compile time.
The problems I see are:
1. parameter to kfree is a value not a pointer
- solved by using a macro instead of function,
but generate new (the other) problems
- take the address of the value there.
2. possible side effects of macro parameter usage
- solved by assigning once only and using typeof
3. Constants don't have an address
- need to check for constant
So apart from missing braces before taking the address, I don't see
any problem with my solution :-)
Should I send a patch?
Please let me know if I have missed something.
I reviewed it and you missed side effects (kfree(x); x = NULL).
Regards
Ingo Oeser
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [DISCUSS] Make the variable NULL after freeing it.
Ingo Oeser [EMAIL PROTECTED] writes:
Hi,
On Monday, 1. January 2007 07:37, Amit Choudhary wrote:
--- Ingo Oeser [EMAIL PROTECTED] wrote:
#define kfree_nullify(x) do { \
if (__builtin_constant_p(x)) { \
kfree(x); \
} else { \
typeof(x) *__addr_x = x; \
Ok, I should change that line to
typeof(x) *__addr_x = (x); \
kfree(*__addr_x); \
*__addr_x = NULL; \
} \
} while (0)
Regards
Ingo Oeser
This is a nice approach but what if someone does kfree_nullify(x+20).
Then this works, because the side effect (+20) is evaluated only once.
It's not a side effect, it's a non-lvalue, and you can't take the address
of a non-lvalue.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
On Mon, Jan 01, 2007 at 09:35:17AM -0500, James Bottomley wrote: On Sat, 2006-12-30 at 10:26 -0800, Linus Torvalds wrote: On Sat, 30 Dec 2006, Russell King wrote: And here's the flush_anon_page() part. This looks fine to me (if you need my ack). Add flush_anon_page() for ARM, to avoid data corruption issues when using fuse or other subsystems using get_user_pages(). Btw, since this doesn't actually change any code for anybody but ARM, just adds a parameter that is obviously unused by everybody else, and if it actually fixes a real bug for ARM, I'll obviously happily take it even before 2.6.20. So go ahead put it in your ARM tree, and we'll get some testing through that. And just ask me to pull at some point. I wonder why nobody else seems to have a flush_anon_page()? This would seem to be a potential issue for architectures like sparc too.. Although maybe sparc can do a flush by physical index with flush_dcache_page(). The sparc handling of anonymous pages is different ... they accitentally sweep them up in flush_dcache_page(). When I audited the architectures to try to make fuse work on parisc, parisc and arm were the only ones that actually needed flush_anon_page(). However, as David has said, anonymous pages _are_ supposed to be handled by flush_dcache_page(), so I now have an (untested) implementation for ARM which does this. Therefore, I'm revoking the previous two patches. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Finding hardlinks
Hi! If user (or script) doesn't specify that flag, it doesn't help. I think the best solution for these filesystems would be either to add new syscall int is_hardlink(char *filename1, char *filename2) (but I know adding syscall bloat may be objectionable) it's also the wrong api; the filenames may have been changed under you just as you return from this call, so it really is a was_hardlink_at_some_point() as you specify it. If you make it work on fd's.. it has a chance at least. Yes, but it doesn't matter --- if the tree changes under cp -a command, no one guarantees you what you get. int fis_hardlink(int handle1, int handle 2); Is another possibility but it can't detect hardlinked symlinks. Ugh. Is it even legal to hardlink symlinks? Anyway, cp -a is not the only application that wants to do hardlink detection. Pavel -- Thanks for all the (sleeping) penguins. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.19] mmc: Add support for SDHC cards
Hi! Hi all, Thanks to the generous donation of an SDHC card by John Gilmore, and the surprisingly enlightened decision by the SD Card Association to publish useful specs, I've been able to bash out support for SDHC. The changes are not too profound: So I sent that with the wrong From: address (damn you thunderbird!). Please reply to my personal address (this one) and not my work one. :-) Would you describe what SDHC is? I know SD flash cards, and IIRC SDIO cards exist, with functionality such as bluetooth...? But SDHC? -- Thanks for all the (sleeping) penguins. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LCA 2007 Kernel Miniconf CFP (better late than never...)
Hi! The Kernel miniconference at LCA 20007 is finally being organised and this is the call for participation: http://lca2007.linux.org.au/Miniconfs/Kernel The current schedule gives us 6 slots. ... (s2ram debugging session). Hmmm, it would be nice to be there... The other 3 slots are currently open, and this is the call for presentations, We'd like some presentations targetting kernel hacking, kernel janitors, kernel newbies, and perhaps a using git to maintain a kernel tree type of presentation. We'd rather avoid any papers that mention Xen or that are being presented at the main conference. I could do where-to-save-power-in-kernel presentation, I guess. ...but LCA is quite far away, I guess I'd need some visa or something, and am not sure if Novell is willing to send me there...? Pavel -- Thanks for all the (sleeping) penguins. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
Hi! You're not alone, I think everybody who knows, how things in a computer work shares this view. --- Two of the specific arguments I've heard are (a) that the board (and its hardware interfaces that the documentation would describe) involve IP licensed from a third party, which the board manufacturer does not have a legal right to disclose, or (b) that there is, in fact, no suitable documentation, because the boards are developed somewhat fluidly and the driver is developed directly from low-level knowledge that simply isn't written down in a form suitable for passing on. So just opensource the driver. It is usually easy to port it, and possible to clean it up. I have once ported cd-rom driver from DOS to linux (do you still remember cdroms not talking ATA?) -- in 2days or so, and the comments in driver were in korean. Pavel -- Thanks for all the (sleeping) penguins. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: Explain a second alternative for multi-line macros.
Robert P. J. Day wrote:
On Mon, 1 Jan 2007, Christoph Hellwig wrote:
On Sun, Dec 31, 2006 at 02:32:25PM -0500, Robert P. J. Day wrote:
+ (a) Enclose those statements in a do - while block:
+
+ #define macrofun(a, b, c) \
+ do {\
+ if (a == 5) \
+ do_this(b, c); \
+ } while (0)
nitpick, please don't add an indentaion level for the do {. Do this
should look like:
#define macrofun(a, b, c) \
do {\
if (a == 5) \
do_this(b, c); \
} while (0)
the former is the way it's presented in CodingStyle currently, it
wasn't my personal opinion on the subject. i was just reproducing
what was already there.
+ (b) Use the gcc extension that a compound statement enclosed in
+ parentheses represents an expression:
+
+ #define macrofun(a, b, c) ({\
if (a == 5) \
do_this(b, c); \
- } while (0)
+ })
I'd rather document to not use this - it makes the code far less
redable. And it's a non-standard extension, something we only
use if it provides us a benefit which it doesn't here.
it might be a bit late to put a cork in *that* bottle:
$ grep -r #define.*({ *
We aren't trying to prevent its past use. We just aren't encouraging
the use of gcc extensions if there are reasonable better ways to
do something.
--
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86 instability with 2.6.1{8,9}
On Monday 01 January 2007 16:01, Ken Moffat wrote: Hi, I've been running an athlon64 in 64-bit mode without problems, up to and incluing 2.6.19.1. A couple of weeks ago I decided to use it for testing x86 builds, since then it's been nothing but trouble in 32-bit mode. It still works fine when I boot it in 64-bit mode. Obviously papering over a severe bug, but why is it necessary for you to run a 32bit kernel to test 32bit userspace? If your 64bit kernel is stable, use the IA32 emulation surely? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
On Sun, 2006-12-31 at 13:12 -0800, David Miller wrote: From: Linus Torvalds [EMAIL PROTECTED] Date: Sun, 31 Dec 2006 12:58:45 -0800 (PST) So there really is two different cases here: - flush the cache as seen by A PARTICULAR virtual mapping. This is ptrace, but it's other things like unmap page from this VM too. - flush the cache for all possible virtual mappings - simply because we don't even know who has it mapped dirty. And the thing is, the more I think about it, the more I end up wondering: I'm not even sure how valid this is. Whatever path needs to do this is likely doing something wrong anyway. If there are multiple possible sources of cache conflicts, the thing is a disaster and the end result depends on our ordering anyway, so I'd argue that it is just about as correct to flush as it is to NOT flush. So I have this nagging suspicion that flush_dcache_page() is always a bug when it is about virtual caches. It should NEVER flush any virtual caches, since that whole operations is by necessity something where you should be talking about _which_ virtual cache you should flush. It's the aliasing between the _1_ valid user mapping and the kernel's virtual mapping, that's the problem and that's very valid and that's why we have flush_dcache_page() to begin with. So flush_dcache_page() is - I think - more validtly thought about as just DMA coherency (in a system where DMA does not participate in _physical_ cache coherency). Not about virtual caches at all. And I guess that's what you're trying to say here. I'm beginning to think that Ralf Baechle had the best idea here, where he recently made it such that platforms could override kmap() and friends even on non-HIGHMEM configurations. In theory it's the perfect interface to handle this problem, you flush exactly where the physical page is made visible to the kernel for a cpu load/store. All the locations where that happens are perfectly annotated already with kmap() calls. Actually, this was proposed here: http://marc.theaimsgroup.com/?t=11540975413 When I updated the interface to work for the combined VIPT/PIPT cache on the latest pariscs. However, there were no takers for the idea. James - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 instability with 2.6.1{8,9}
On Mon, Jan 01, 2007 at 04:48:55PM +, Alistair John Strachan wrote: Obviously papering over a severe bug, but why is it necessary for you to run a 32bit kernel to test 32bit userspace? If your 64bit kernel is stable, use the IA32 emulation surely? My 64-bit is pure64 on this machine, so it doesn't have any suitable libs or tools. Anyway, I really do need a 32-bit kernel to test some linuxfromscratch build instructions. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: replace memset(...,0,PAGE_SIZE) calls with clear_page()?
On Mon, 1 Jan 2007 17:42:31 +0900 Paul Mundt wrote: On Mon, Jan 01, 2007 at 02:59:32AM +0100, Folkert van Heusden wrote: regarding alignment that don't allow clear_page() to be used copy_page() in the memcpy() case), but it's going to need a lot of Maybe these optimalisations should be in the coding style docs? For what purpose? CodingStyle is not about documenting usage constraints for every minor part of the kernel. If someone intends to use an API, it's up to them to figure out the semantics for doing so. Let's not confuse common sense with style. - I agree, these aren't CodingStyle material. They could make sense in some other doc, either MM/VM-related or more general. I've often wanted a somewhat introductory doc about Linux environmental assumptions (memory model, pointers/longs, data cleared to 0, many other items that I don't have on my fingertips). --- ~Randy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OHCI: disallow autostop when wakeup is not available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 15 November 2006 00:28, Alan Stern wrote: This patch (as822) prevents the OHCI autostop mechanism from kicking in if the root hub is not able or not allowed to issue wakeup requests. Signed-off-by: Alan Stern [EMAIL PROTECTED] --- Greg: This patch should go into 2.6.19-rc ASAP. It does solve a real problem. The larger-scale changes Dave and I have been discussing will be submitted separately, for inclusion in 2.6.20. Is the original problem (OHCI constantly attempting and failing to suspend root hub) supposed to be fixed in 2.6.20? Currently in rc3 I have ohci_hcd :00:02.0: new USB bus registered, assigned bus number 1 ohci_hcd :00:02.0: created debug files ohci_hcd :00:02.0: irq 11, io mem 0xf7eff000 ohci_hcd :00:02.0: resetting from state 'reset', control = 0x0 ohci_hcd :00:02.0: enabling initreset quirk ohci_hcd :00:02.0: OHCI controller state ohci_hcd :00:02.0: OHCI 1.0, NO legacy support registers ohci_hcd :00:02.0: control 0x083 HCFS=operational CBSR=3 ohci_hcd :00:02.0: cmdstatus 0x0 SOC=0 ohci_hcd :00:02.0: intrstatus 0x0044 RHSC SF ohci_hcd :00:02.0: intrenable 0x800a MIE RD WDH ohci_hcd :00:02.0: hcca frame #0003 ohci_hcd :00:02.0: roothub.a 01000203 POTPGT=1 NPS NDP=3(3) ohci_hcd :00:02.0: roothub.b PPCM= DR= ohci_hcd :00:02.0: roothub.status 8000 DRWE ohci_hcd :00:02.0: roothub.portstatus [0] 0x0100 PPS ohci_hcd :00:02.0: roothub.portstatus [1] 0x0100 PPS ohci_hcd :00:02.0: roothub.portstatus [2] 0x0100 PPS usb usb1: default language 0x0409 usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: OHCI Host Controller usb usb1: Manufacturer: Linux 2.6.20-rc3-1avb ohci_hcd usb usb1: SerialNumber: :00:02.0 usb usb1: uevent usb usb1: usb_probe_device usb usb1: configuration #1 chosen from 1 choice usb usb1: adding 1-0:1.0 (config #1, interface 0) usb 1-0:1.0: uevent hub 1-0:1.0: usb_probe_interface hub 1-0:1.0: usb_probe_interface - got id hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected hub 1-0:1.0: standalone hub hub 1-0:1.0: no power switching (usb 1.0) hub 1-0:1.0: global over-current protection hub 1-0:1.0: power on to power good time: 2ms hub 1-0:1.0: local power source is good hub 1-0:1.0: no over-current condition exists hub 1-0:1.0: trying to enable port power on non-switchable hub hub 1-0:1.0: state 7 ports 3 chg evt /home/bor/src/linux-git/drivers/usb/core/inode.c: creating file '001' ohci_hcd :00:02.0: auto-stop root hub ohci_hcd :00:02.0: auto-wakeup root hub ohci_hcd :00:02.0: auto-stop root hub ohci_hcd :00:02.0: auto-wakeup root hub ... and it goes on and on until I stop it manually by usual method: usb usb1: remote wakeup needed for autosuspend Welcome to new year :) - -andrey -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFmT/oR6LMutpd94wRAtqLAJ4yNCupGqAC8G6hkAxvuXrW7Jr7KQCgrgyE ZZ5Sd4qeeVy+NiGHjNZ6yR8= =Gwng -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Open Firmware device tree virtual filesystem
Not the same exact thing -- using a text representation for the property contents is a very different thing (and completely braindead). The filesystem bit is for groveling around and getting information from the shell prompt, or shell scripts. Text processing. If you want the binary bits, export it with something like /dev/openprom. But we'd have to implement a tree structure on top of that. If for doing real things we have to use some device file with some helper program, we can do away with the whole filesystem thing just as well -- *always* use that helper program. On the PowerPC side of things, we have binary properties in the device tree filesystem, and have a simple user space program to make it readable as text. We don't generally export binary representation files out of /proc or /sys, in fact this rule I believe is layed our precisely somewhere at least in the sysfs case. That only works for sysfs because there is the one value per file rule -- something the OF device tree doesn't do, and doesn't need to do, since it uses a well-defined binary format. If you *really* want (the option of) showing things as text in the filesystem, you better make it so that there is a one-to-one translation back to binary. For example, what does this mean, is it a text string or two bytes: 01.02 Yes you as a user can guess, but scripts can't (reliably). Every architecture that supports the device tree filesystem, initialises a struct device_tree_ops with a bunch of pointers to functions that allow you to traverse the device tree and read its properties (and maybe write properties, or even delete and create new nodes. The devtree filesystem code simply calls into these functions to do the actual operations on the device tree (access an in-kernel data structure, call the OF, or both -- or something entirely different, who knows). That's the only key point in my opinion, any clean interface that sits in front of this stuff is fine as long as it encompasses all of the necessary operations and allows just about any implementation underneath. Yeah. And I'd like to have it as a collection of function pointers so the arch code can put in the implementation it needs at boot time. Flexibility is good. Segher - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.19] mmc: Add support for SDHC cards
Pavel Machek wrote: Would you describe what SDHC is? I know SD flash cards, and IIRC SDIO cards exist, with functionality such as bluetooth...? But SDHC? SDHC is short for Secure Digital High Capacity. It's simply SD flash cards than conform to a new version of the protocol, a version where addressing is done on a sector (512 byte) basis instead of bytes. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: Explain a second alternative for multi-line macros.
If people want to return something from a ({ }) construct, they should
do it
explicitly, e.g.
#define setcc(cc) ({ \
partial_status = ~(SW_C0|SW_C1|SW_C2|SW_C3); \
partial_status |= (cc) (SW_C0|SW_C1|SW_C2|SW_C3); \
partial_status; \
})
No, they generally should use an inline function instead.
Segher
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sound: hda: detect ALC883 on MSI K9A Platinum motherboards (MS-7280)
From: Leonard Norrgård [EMAIL PROTECTED]
Recognize the Realtek ALC883 chip on MSI K9A Platinum motherboards
(model no. MS-7280), enabling full sound capabilities.
Signed-off-by: Leonard Norrgård [EMAIL PROTECTED]
---
Error messages seen before this patch:
cannot find the slot for index 0 (range 0-0)
hda-intel: Error creating card!
HDA Intel: probe of :00:14.2 failed with error -12
---
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 29e4c48..4e0c3c1 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5070,6 +5070,8 @@ static struct hda_board_config alc883_cfg_tbl[] = {
{ .modelname = 6stack-dig, .config = ALC883_6ST_DIG },
{ .pci_subvendor = 0x1462, .pci_subdevice = 0x6668,
.config = ALC883_6ST_DIG }, /* MSI */
+{ .pci_subvendor = 0x1462, .pci_subdevice = 0x7280,
+ .config = ALC883_6ST_DIG }, /* MSI K9A Platinum (MS-7280) */
{ .pci_subvendor = 0x105b, .pci_subdevice = 0x6668,
.config = ALC883_6ST_DIG }, /* Foxconn */
{ .modelname = 6stack-dig-demo, .config = ALC888_DEMO_BOARD },
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [DISCUSS] Make the variable NULL after freeing it.
Hi! I decided to keep it simple. If someone is calling kfree_nullify() with anything other than a simple variable, then they should call kfree(). kfree_nullify() has to replace kfree() to be of any use one day. So this is not an option. Doing kfree() that writes to its argument is not an option. kfree() looks like a function, so it should behave as one. KFREE() might be okay. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
Hi! Okay, I spoke too soon. bluetooth suspend memory corruption was _way_ harder to reproduce than expected. Took me 5-or-so-suspend cycles... so it is probably unrelated to the previous crash. can you try to reproduce this with 2.6.20-rc2 as well. Yep, here it is, reproduced on 6-th-or-so suspend. bluetooth may need to be actively used in order for this to trigger; connecting to the net over my cellphone seems to work okay. (Full logs in attachment). Is this issue also present in 2.6.19 or is it a regression? Not sure... but I know there were some bluetooth suspend problems before. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: replace memset(...,0,PAGE_SIZE) calls with clear_page()?
On Mon, Jan 01, 2007 at 05:27:10AM -0500, Robert P. J. Day wrote: both look good... I'd be in favor of this. Maybe also add a part about using GFP_KERNEL whenever possible, GFP_NOFS from filesystem writeout code and GFP_NOIO from block writeout code (and never doing in_interrupt()?GFP_ATOMIC:GFP_KERNEL !) it strikes me that that latter part is starting to go beyond the scope of simple coding style aesthetics and getting into actual coding distinctions. would that really be appropriate for the CodingStyle doc? i'm just asking. Adding a separate 'good practices' doc wouldn't be a bad idea. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Consolidate default sched_clock()
Hello, what about the following, on top of your patch ? It's trivial modif to kernel-doc style comment... -- Vincent Legoll diff --git a/kernel/sched.c b/kernel/sched.c index f92a239..2c51ec0 100644 --- a/kernel/sched.c +++ b/kernel/sched.c @@ -56,8 +56,8 @@ #include asm/unistd.h -/* - * Scheduler clock - returns current time in nanosec units. +/** + * sched_clock - returns current scheduler clock time in nanosec units. * This is default implementation. * Architectures and sub-architectures can override this. */
Re: Sparse 0.2 warnings from {asm,net}/checksum.h
On Mon, Jan 01, 2007 at 03:23:45PM +0100, Tilman Schmidt wrote: With sparse 0.2, my previously sparse-clean driver generates the following warnings: include/asm/checksum.h:182:6: warning: symbol 'sum' shadows an earlier one include/asm/checksum.h:178:28: originally declared here include/net/checksum.h:33:6: warning: symbol 'sum' shadows an earlier one include/net/checksum.h:31:27: originally declared here Architecture is i386. The lines referred to are in the functions csum_and_copy_to_user() and csum_and_copy_from_user(), but I don't see why sparse would emit such a warning for that code. It's complaining about the 'sum' declaration in __range_not_ok used by access_ok(), which shadows the variable declared in the prototype of the functions you mention. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Open Firmware device tree virtual filesystem
David Miller wrote: We don't generally export binary representation files out of /proc or /sys, in fact this rule I believe is layed our precisely somewhere at least in the sysfs case. pci-sysfs exports PCI config space in binary. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] preliminary sata_promise ATAPI support
On Sat, 30 Dec 2006 18:37:18 +0100 (MET), Mikael Pettersson wrote:
This patch against 2.6.20-rc2 adds partial ATAPI support to
the sata_promise driver. This patch is preliminary and for
review only.
...
As to why CD-writing fails with DMA enabled, I suspect that I
either need to blacklist specific packet commands from using
DMA, or ...
That was it: -check_atapi_dma() needs to inspect the packet
command and only enable DMA for bulk data transfers. With this
change sata_promise successfully both reads and writes CDs.
The rules for which commands should use DMA are taken from
Promise's drivers. I missed this filter originally because it
is located in their high-level Linux glue driver while I was
mostly studying their low-level hardware driver. The filter matches
the corresponding code in pata_pdc2027x.c, with the exception
of an additional no-DMA restriction for WRITE_10 with large LBA.
The patch below goes on top of the first preliminary patch.
/Mikael
--- linux-2.6.20-rc3/drivers/ata/sata_promise.c.~1~ 2007-01-01
17:13:05.0 +0100
+++ linux-2.6.20-rc3/drivers/ata/sata_promise.c 2007-01-01 19:14:00.0
+0100
@@ -39,6 +39,7 @@
#include linux/interrupt.h
#include linux/sched.h
#include linux/device.h
+#include scsi/scsi.h
#include scsi/scsi_host.h
#include scsi/scsi_cmnd.h
#include linux/libata.h
@@ -430,16 +431,10 @@ static void pdc_qc_prep(struct ata_queue
qc-tf.protocol = ATA_PROT_DMA;
pdc_pkt_header(qc-tf, qc-ap-prd_dma, qc-dev-devno,
pp-pkt);
qc-tf.protocol = ATA_PROT_ATAPI_DMA;
- if (qc-dev-cdb_len ~0x1E) { /* 2/4/6/8/10/12/14/16 are Ok */
- printk(KERN_ERR %s: bad cdb_len %u\n, __FUNCTION__,
qc-dev-cdb_len);
- BUG();
- }
+ /* we can represent cdb lengths 2/4/6/8/10/12/14/16 */
+ BUG_ON(qc-dev-cdb_len ~0x1E);
pp-pkt[12] = (((qc-dev-cdb_len 1) 7) 5) | 0x00 |
0x08;
memcpy(pp-pkt+13, qc-cdb, qc-dev-cdb_len);
-#if 0
- /* pdc-ultra/cam/cam_ata.c will pad SG length to a multiple
- of 4 here, but libata has already done that for us */
-#endif
break;
default:
@@ -788,7 +783,29 @@ static void pdc_exec_command_mmio(struct
static int pdc_check_atapi_dma(struct ata_queued_cmd *qc)
{
- return 0; /* ATAPI DMA is supported */
+ u8 *scsicmd = qc-scsicmd-cmnd;
+ int pio = 1; /* atapi dma off by default */
+
+ /* Whitelist commands that may use DMA. */
+ switch (scsicmd[0]) {
+ case WRITE_12:
+ case WRITE_10:
+ case WRITE_6:
+ case READ_12:
+ case READ_10:
+ case READ_6:
+ case 0xad: /* READ_DVD_STRUCTURE */
+ case 0xbe: /* READ_CD */
+ pio = 0;
+ }
+ /* -45150 (4FA2) to -1 () shall use PIO mode */
+ if (scsicmd[0] == WRITE_10) {
+ unsigned int lba;
+ lba = (scsicmd[2] 24) | (scsicmd[3] 16) | (scsicmd[4]
8) | scsicmd[5];
+ if (lba = 0x4FA2)
+ pio = 1;
+ }
+ return pio;
}
static void pdc_ata_setup_port(struct ata_ioports *port, unsigned long base)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86 instability with 2.6.1{8,9}
On Mon, Jan 01, 2007 at 05:07:58PM +, Ken Moffat wrote: On Mon, Jan 01, 2007 at 04:48:55PM +, Alistair John Strachan wrote: Obviously papering over a severe bug, but why is it necessary for you to run a 32bit kernel to test 32bit userspace? If your 64bit kernel is stable, use the IA32 emulation surely? My 64-bit is pure64 on this machine, so it doesn't have any suitable libs or tools. Anyway, I really do need a 32-bit kernel to test some linuxfromscratch build instructions. Sorry, I think last night is still interfering with my own logic circuits. Yes, I could use 'linux32' to change the personality as a work-around now that I've built the system. Mainly, I was hoping somebody would notice something bad in the config, but I might use the work-around in the meantime. Thanks for reminding me about it. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: Explain a second alternative for multi-line macros.
On Jan 1 2007 18:51, Segher Boessenkool wrote:
If people want to return something from a ({ }) construct, they should do
it
explicitly, e.g.
#define setcc(cc) ({ \
partial_status = ~(SW_C0|SW_C1|SW_C2|SW_C3); \
partial_status |= (cc) (SW_C0|SW_C1|SW_C2|SW_C3); \
partial_status; \
})
No, they generally should use an inline function instead.
Perhaps. But that won't work with defines where typeof is involved.
-`J'
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] HZ free ntp
Hi, On Wednesday 20 December 2006 02:32, john stultz wrote: I know and all you have to change in the ntp and some related code is to replace HZ there with a variable, thus make it changable, so you can increase the update interval (i.e. it becomes 1s/hz instead of 1s/HZ). Untested patch below. Does this vibe better with you are suggesting? Yes, thanks. tick_nsec doesn't require special treatment, in the middle term it's obsolete anyway, it could be replaced with (current_tick_length() TICK_LENGTH_SHIFT) and current_tick_length() being inlined. NTP_INTERVAL_FREQ could be a real variable (so it can be initialized at runtime), it's already gone from all important paths. In the short term I'd prefered a clock would store its frequency instead of using NTP_INTERVAL_LENGTH in clocksource_calculate_interval(), so it doesn't has to be derived there. bye, Roman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] HZ free ntp
On Wednesday 20 December 2006 02:54, john stultz wrote:
And here would be the follow on patch (again *untested*) for
CONFIG_NO_HZ slowing the time accumulation down to once per second.
Changing it to one creates a potential problem with calling second_overflow().
It should be called every NTP_INTERVAL_FREQ times, but occasionally it's off
by one (when xtime is close to a full second and the tick length is different
from 1sec). At a higher frequency that's not much of a problem, but at one it
means second_overflow() is occasionally called twice a second or skipped for
a second. Usually the error should be quite small, but sometimes it can be
significant.
So in this case the loop in update_wall_time() should rather look like this:
while (offset = clock-cycle_interval) {
...
second_overflow();
while (clock-xtime_nsec = (u64)NSEC_PER_SEC clock-shift) {
clock-xtime_nsec -= (u64)NSEC_PER_SEC clock-shift;
xtime.tv_sec++;
}
...
}
(Also note the change from if to while.)
Another problem area is that the clock shift value might need adjustments,
since when you reduce the update frequency, it also increases the error
adjustment steps and thus influences the jitter. This is especially important
if we want to synchronize the TSC on multiple cpu's.
bye, Roman
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.20 regression: suspend to disk no more works
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In *the same* configuration STD now fails with Cannot find swap device. The reason is changes in kernel/power/swap.c. In 2.6.19 it did not require valid swsusp_resume_device at all - it took first available swap device and saved image. Later during resume swsusp_resume_device was set either by command line or sysfs and everything worked nicely. Now swsusp_swap_check() unfortunately checks for swsusp_resume_device at *suspend* time: res = swap_type_of(swsusp_resume_device, swsusp_resume_block); if (res 0) return res; root_swap = res; resume_bdev = open_by_devnum(swsusp_resume_device, FMODE_WRITE); if (IS_ERR(resume_bdev)) return PTR_ERR(resume_bdev); but in case of modular driver for swap device this is likely to be undefined. This is as of 2.6.20-rc3. I already have seen these reports. While 'echo a:b /sys/power/resume' before suspend is a workaround, this still breaks perfectly valid setup that worked before. Also 'echo a:b /sys/power/resume' is actually wrong - we are not going to resume at this point; but there is no way to just tell kernel use this device for next STD ... also the error message is misleading, it should complaint no resume device found. Swap is there all right. - -andrey -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFmWSqR6LMutpd94wRAu61AJ9mdbF4W6RNQ848PU0e4n/3MKtNnwCgzwOh HkZ9e8lHPMH1tRNzCw/2O58= =HlW4 -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 instability with 2.6.1{8,9}
On Monday 01 January 2007 19:13, Ken Moffat wrote:
On Mon, Jan 01, 2007 at 05:07:58PM +, Ken Moffat wrote:
On Mon, Jan 01, 2007 at 04:48:55PM +, Alistair John Strachan wrote:
Obviously papering over a severe bug, but why is it necessary for you
to run a 32bit kernel to test 32bit userspace? If your 64bit kernel is
stable, use the IA32 emulation surely?
My 64-bit is pure64 on this machine, so it doesn't have any
suitable libs or tools. Anyway, I really do need a 32-bit kernel
to test some linuxfromscratch build instructions.
Sorry, I think last night is still interfering with my own logic
circuits. Yes, I could use 'linux32' to change the personality as a
work-around now that I've built the system. Mainly, I was hoping
somebody would notice something bad in the config, but I might use
the work-around in the meantime. Thanks for reminding me about it.
Personally when I built an embedded LFS for a customer, I wrote a dummy arch
and uname and then bootstrapped the 32bit LFS book, then built a cross
compiler with the CLFS book and built a 64bit kernel. Seemed to work okay.
However, there isn't 100% compatibility in a 64bit kernel for all syscalls, I
think one of the VFAT syscall wrappers is currently broken.
[ 5807.639755] ioctl32(war3.exe:4998): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/alistair/.wine/drive_c/Program Files/Warcraft III
Other than that, I've had no problem with running a purely 32bit userspace.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Happy New Year (and v2.6.20-rc3 released)
Jeff, what was the resolution to this one? Just revert the offending commit, or what? We're about five weeks into the 2.6.20-rc series. I was hoping for a two-month release rather than the usual dragged-out three months, so I'd like to get these regressions to be actively fixed. By forcible reverts if that is what it takes. Linus On Mon, 1 Jan 2007, Alessandro Suardi wrote: Right ! And this one is still broken in -rc3: Subject: kernel panics on boot (libata-sff) References : http://lkml.org/lkml/2006/12/3/99 http://lkml.org/lkml/2006/12/14/153 http://lkml.org/lkml/2006/12/24/33 Submitter : Alessandro Suardi [EMAIL PROTECTED] Caused-By : Alan Cox [EMAIL PROTECTED] commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f Handled-By : Alan Cox [EMAIL PROTECTED] Status : people are working on a fix Happy 2007 everyone, --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kref refcnt and false positives
This makes my Maple board very unhappy -- it triggers a WARN_ON() in kref_get() lots of times... Maybe the refounting in prom.c is broken ? I'll have a look. Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.20-rc1 4/6] PXA GPIO wrappers
For the list archives: here's the latest version of this.
The signed-off-by discussion is offlist right now, so this
version has none; see what eventually merges.
From: Philipp Zabel [EMAIL PROTECTED]
Arch-neutral GPIO calls for PXA.
Index: pxa/include/asm-arm/arch-pxa/gpio.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ pxa/include/asm-arm/arch-pxa/gpio.h 2007-01-01 11:23:43.0 -0800
@@ -0,0 +1,97 @@
+/*
+ * linux/include/asm-arm/arch-pxa/gpio.h
+ *
+ * PXA GPIO wrappers for arch-neutral GPIO calls
+ *
+ * Written by Philipp Zabel [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#ifndef __ASM_ARCH_PXA_GPIO_H
+#define __ASM_ARCH_PXA_GPIO_H
+
+#include asm/errno.h
+#include asm/hardware.h
+#include asm/irq.h
+
+#include asm/arch/pxa-regs.h
+
+static inline int gpio_get_value(unsigned gpio);
+static inline void gpio_set_value(unsigned gpio, int value);
+
+#include asm-generic/gpio.h /* cansleep wrappers */
+
+static inline int gpio_request(unsigned gpio, const char *label)
+{
+ return 0;
+}
+
+static inline void gpio_free(unsigned gpio)
+{
+ return;
+}
+
+static inline int gpio_direction_input(unsigned gpio)
+{
+ return pxa_gpio_mode(gpio | GPIO_IN);
+}
+
+static inline int gpio_direction_output(unsigned gpio)
+{
+ return pxa_gpio_mode(gpio | GPIO_OUT);
+}
+
+static inline int __gpio_get_value(unsigned gpio)
+{
+ return GPLR(gpio) GPIO_bit(gpio);
+}
+
+static inline int gpio_get_value(unsigned gpio)
+{
+ if (__builtin_constant_p(gpio))
+ return __gpio_get_value(gpio);
+ else
+ pxa_gpio_get_value(gpio);
+}
+
+static inline void __gpio_set_value(unsigned gpio, int value)
+{
+ if (value)
+ GPSR(gpio) = GPIO_bit(gpio);
+ else
+ GPCR(gpio) = GPIO_bit(gpio);
+}
+
+static inline void gpio_set_value(unsigned gpio, int value)
+{
+ if (__builtin_constant_p(gpio))
+ __gpio_set_value(gpio, value);
+ else
+ pxa_gpio_set_value(gpio, value);
+}
+
+static inline int gpio_to_irq(unsigned gpio)
+{
+ if (gpio = PXA_LAST_GPIO)
+ return IRQ_GPIO(gpio);
+ return -EINVAL;
+}
+
+#define irq_to_gpio(irq) IRQ_TO_GPIO(irq)
+
+
+#endif
Index: pxa/arch/arm/mach-pxa/generic.c
===
--- pxa.orig/arch/arm/mach-pxa/generic.c2006-12-31 17:03:59.0
-0800
+++ pxa/arch/arm/mach-pxa/generic.c 2006-12-31 17:08:37.0 -0800
@@ -36,6 +36,7 @@
#include asm/mach/map.h
#include asm/arch/pxa-regs.h
+#include asm/arch/gpio.h
#include asm/arch/udc.h
#include asm/arch/pxafb.h
#include asm/arch/mmc.h
@@ -104,13 +105,16 @@ unsigned long long sched_clock(void)
* Handy function to set GPIO alternate functions
*/
-void pxa_gpio_mode(int gpio_mode)
+int pxa_gpio_mode(int gpio_mode)
{
unsigned long flags;
int gpio = gpio_mode GPIO_MD_MASK_NR;
int fn = (gpio_mode GPIO_MD_MASK_FN) 8;
int gafr;
+ if (gpio PXA_LAST_GPIO)
+ return -EINVAL;
+
local_irq_save(flags);
if (gpio_mode GPIO_DFLT_LOW)
GPCR(gpio) = GPIO_bit(gpio);
@@ -123,11 +127,33 @@ void pxa_gpio_mode(int gpio_mode)
gafr = GAFR(gpio) ~(0x3 (((gpio) 0xf)*2));
GAFR(gpio) = gafr | (fn (((gpio) 0xf)*2));
local_irq_restore(flags);
+
+ return 0;
}
EXPORT_SYMBOL(pxa_gpio_mode);
/*
+ * Return GPIO level
+ */
+int pxa_gpio_get_value(unsigned gpio)
+{
+ return __gpio_get_value(gpio);
+}
+
+EXPORT_SYMBOL(pxa_gpio_get_value);
+
+/*
+ * Set output GPIO level
+ */
+void pxa_gpio_set_value(unsigned gpio, int value)
+{
+ __gpio_set_value(gpio, value);
+}
+
+EXPORT_SYMBOL(pxa_gpio_set_value);
+
+/*
* Routine to safely enable or disable a clock in the CKEN
*/
void pxa_set_cken(int clock, int enable)
Index: pxa/include/asm-arm/arch-pxa/hardware.h
===
--- pxa.orig/include/asm-arm/arch-pxa/hardware.h2006-12-31
17:03:59.0 -0800
+++ pxa/include/asm-arm/arch-pxa/hardware.h 2006-12-31 17:08:37.0
-0800
@@ -65,7
Re: [patch 2.6.20-rc1 0/6] arch-neutral GPIO calls
On Sunday 31 December 2006 11:11 am, Kevin O'Connor wrote: Based on earlier discussion, I'm sending a refresh of the generic GPIO patch, with several (ARM based) implementations in separate patches: Hi Dave, I'm very interested in seeing an abstraction for gpios. Good! I suspect most folk who've had to work on a few different embedded Linux boards have noticed lots of needlessly-different GPIO code. Not many folk are actually seeing that as more than just ugliness though. Unfortunately, I fear the implementation you propose is not robust enough to handle the cases I need to handle. The _interface_ allows those additional GPIO controllers though. Specifically of the type you mentioned ... that's why this version defined new cansleep call variants. The concern I have with your current implementation is that I don't see a way to flexibly add in support for additional gpio pins on a machine by machine basis. The code does do a good job of abstracting gpios based on the primary architecture (eg, PXA vs OMAP), but not on a chip basis (eg, PXA vs ASIC3). You used the key word: implementation. The interface allows it, but such board-specific extensions haven't yet been needed; so they've not yet been implemented. See the appended for a patch roughly along the lines of what has previously been discussed here. No interface change, just updated implementation code. And the additional implementation logic won't kick on boards that don't need it. Note that the current implementations are a win even without yet being able to handle the board-specific external GPIO controllers. The API is clearer than chip-specific register access, and since it's arch-neutral it already solves integration problems (like having one SPI controller driver work on both AT91 and AVR). Other than clarifications, the main change in the doc is defining new calls safe for use with GPIOs on things like pcf8574 I2C gpio expanders; those new calls can sleep, but are otherwise the same as the spinlock-safe versions. The implementations above implement that as a wrapper (the asm-generic header) around the spinlock-safe calls. As above, I'm confused how these expanders would work in practice. One approach: updating implementations along the lines the patch below. Other implementations could work too. Note that I see that kind of update as happening after the first round of patches go upstream: accept the interface first, then update boards to support it ... including later the cansleep calls, on some boards. I like the idea of first replacing the old GPIO accesses with ones using the new APIs ... and only then starting to convert old I2C (etc) accesses. The expanders would be present on a machine by machine basis but the code seems to be implemented on an arch by arch basis. Perhaps an example would help me. An example showing one way to implement that interface ... appended. The expanders would be board-specific, not arch/.../mach-* specific. (I try to avoid using the word machine there; it's too ambiguous.) The code below just show how boards could plug in; it doesn't actually convert any boards to use that infrastructure. It should be obvious how to do that, if you've got a board needing it which works with the kernel.org GIT tree... - Dave = CUT HERE Preliminary version of support for board-specific declaring GPIO controllers, primarily for use with things like I2C access to GPIOs. * GPIOs numbered 0..ARCH_GPIO_MAX always use internal arch/SOC specific controller access, and are spinlock-safe. * All other GPIO numbers are allocated semi-dynamically, as part of declaring a GPIO controller, and are assumed spinlock-unsafe. * Such external GPIO controllers provide a simple ops vector for setting direction, and accessing GPIO values. Board-specific init code can declare the controllers, then hand out the GPIOs to code that needs them. Index: pxa/include/asm-generic/gpio.h === --- pxa.orig/include/asm-generic/gpio.h 2007-01-01 11:20:14.0 -0800 +++ pxa/include/asm-generic/gpio.h 2007-01-01 11:34:42.0 -0800 @@ -1,7 +1,51 @@ #ifndef _ASM_GENERIC_GPIO_H #define _ASM_GENERIC_GPIO_H -/* platforms that don't directly support access to GPIOs through I2C, SPI, +#ifdef CONFIG_GPIOLIB + +/* Boards with GPIOs accessed through I2C etc can access them through some + * gpio expander library code: + * + * - Define ARCH_GPIO_MAX. All GPIO ids accessed through such expanders + *will be above this number. Most other GPIOs are SOC-integrated, and + *could be accessed by inlined direct register reads/writes. + * + * - Board-specific setup code declares each controller and how many GPIOs + *it handles. The return value is the first GPIO associated with that + *controller; other GPIOs immediately follow. These GPIO numbers are + *then handed out to the
Re: [2.6 patch] kconfig: remove the unused requires syntax
Hi,
On Thursday 28 December 2006 22:05, Adrian Bunk wrote:
How to add some warning prints?
Simple, see the attached patch.
And what's the problem with changing the generated files?
There doesn't seem to be much activity in this area, and the noise of
changing the generated files doesn't seem to be a problem for me (except
if anyone else is semnding patches for the same area at the same time.
It's not as if this noise was big compared to the diff between two Linux
releases...
The additional syntax doesn't hurt anyone, thus I prefer the simpler change.
Regarding external trees:
Do you know about anyone actually using it?
No and that's not the point, there is simply no need to change the syntax this
drastically. Just printing a warning is sufficient, which actually tells the
user more specifically what to change, instead of an anonymous syntax error.
bye, Roman
---
scripts/kconfig/zconf.tab.c_shipped |2 ++
scripts/kconfig/zconf.y |2 ++
2 files changed, 4 insertions(+)
Index: linux-2.6/scripts/kconfig/zconf.tab.c_shipped
===
--- linux-2.6.orig/scripts/kconfig/zconf.tab.c_shipped 2007-01-01 19:54:14.0 +0100
+++ linux-2.6/scripts/kconfig/zconf.tab.c_shipped 2007-01-01 19:55:16.0 +0100
@@ -1738,6 +1738,7 @@ yyreduce:
{
menu_add_dep((yyvsp[-1].expr));
+ zconfprint(warning: 'depends' used without 'on' keyword);
printd(DEBUG_PARSE, %s:%d:depends\n, zconf_curname(), zconf_lineno());
;}
break;
@@ -1746,6 +1747,7 @@ yyreduce:
{
menu_add_dep((yyvsp[-1].expr));
+ zconfprint(warning: 'requires' keyword is deprecated);
printd(DEBUG_PARSE, %s:%d:requires\n, zconf_curname(), zconf_lineno());
;}
break;
Index: linux-2.6/scripts/kconfig/zconf.y
===
--- linux-2.6.orig/scripts/kconfig/zconf.y 2007-01-01 19:52:20.0 +0100
+++ linux-2.6/scripts/kconfig/zconf.y 2007-01-01 19:53:57.0 +0100
@@ -422,11 +422,13 @@ depends: T_DEPENDS T_ON expr T_EOL
| T_DEPENDS expr T_EOL
{
menu_add_dep($2);
+ zconfprint(warning: 'depends' used without 'on' keyword);
printd(DEBUG_PARSE, %s:%d:depends\n, zconf_curname(), zconf_lineno());
}
| T_REQUIRES expr T_EOL
{
menu_add_dep($2);
+ zconfprint(warning: 'requires' keyword is deprecated);
printd(DEBUG_PARSE, %s:%d:requires\n, zconf_curname(), zconf_lineno());
};
Re: [PATCH] Open Firmware device tree virtual filesystem
On Jan 1 2007 08:10, Mitch Bradley wrote: We don't generally export binary representation files out of /proc or /sys, in fact this rule I believe is layed our precisely somewhere at least in the sysfs case. pci-sysfs exports PCI config space in binary. cat /sys/bus/pci/devices/\:01\:00.0/subsystem_device 0x0c60 Can't find the binary thing. But I've seen it before -- esp. /proc/usb when it existed. It's really sad, because you can learn a lot from the text representations. Having to figure out what the proper utility and all its options is often takes some time. -`J' -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/8] UML - Locking fixes and code cleanup
As before, this is post-2.6.20 material. These patches fix locking, style and whitespace problems, and make small code cleanups. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] UML - audio driver locking
Comment the lack of locking and make a couple of variables static.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/drivers/hostaudio_kern.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
Index: linux-2.6.18-mm/arch/um/drivers/hostaudio_kern.c
===
--- linux-2.6.18-mm.orig/arch/um/drivers/hostaudio_kern.c 2006-12-29
18:25:36.0 -0500
+++ linux-2.6.18-mm/arch/um/drivers/hostaudio_kern.c2006-12-29
21:09:09.0 -0500
@@ -25,9 +25,12 @@ struct hostmixer_state {
#define HOSTAUDIO_DEV_DSP /dev/sound/dsp
#define HOSTAUDIO_DEV_MIXER /dev/sound/mixer
-/* Only changed from linux_main at boot time */
-char *dsp = HOSTAUDIO_DEV_DSP;
-char *mixer = HOSTAUDIO_DEV_MIXER;
+/* Changed either at boot time or module load time. At boot, this is
+ * single-threaded; at module load, multiple modules would each have
+ * their own copy of these variables.
+ */
+static char *dsp = HOSTAUDIO_DEV_DSP;
+static char *mixer = HOSTAUDIO_DEV_MIXER;
#define DSP_HELP \
This is used to specify the host dsp device to the hostaudio driver.\n \
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8] UML - audio driver formatting
Whitespace and style fixes.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/drivers/hostaudio_kern.c | 160 +--
1 file changed, 73 insertions(+), 87 deletions(-)
Index: linux-2.6.18-mm/arch/um/drivers/hostaudio_kern.c
===
--- linux-2.6.18-mm.orig/arch/um/drivers/hostaudio_kern.c 2006-12-29
21:13:41.0 -0500
+++ linux-2.6.18-mm/arch/um/drivers/hostaudio_kern.c2006-12-29
21:13:42.0 -0500
@@ -15,11 +15,11 @@
#include os.h
struct hostaudio_state {
- int fd;
+ int fd;
};
struct hostmixer_state {
- int fd;
+ int fd;
};
#define HOSTAUDIO_DEV_DSP /dev/sound/dsp
@@ -72,12 +72,12 @@ MODULE_PARM_DESC(mixer, MIXER_HELP);
static ssize_t hostaudio_read(struct file *file, char __user *buffer,
size_t count, loff_t *ppos)
{
-struct hostaudio_state *state = file-private_data;
+ struct hostaudio_state *state = file-private_data;
void *kbuf;
int err;
#ifdef DEBUG
-printk(hostaudio: read called, count = %d\n, count);
+ printk(hostaudio: read called, count = %d\n, count);
#endif
kbuf = kmalloc(count, GFP_KERNEL);
@@ -91,7 +91,7 @@ static ssize_t hostaudio_read(struct fil
if(copy_to_user(buffer, kbuf, err))
err = -EFAULT;
- out:
+out:
kfree(kbuf);
return(err);
}
@@ -99,12 +99,12 @@ static ssize_t hostaudio_read(struct fil
static ssize_t hostaudio_write(struct file *file, const char __user *buffer,
size_t count, loff_t *ppos)
{
-struct hostaudio_state *state = file-private_data;
+ struct hostaudio_state *state = file-private_data;
void *kbuf;
int err;
#ifdef DEBUG
-printk(hostaudio: write called, count = %d\n, count);
+ printk(hostaudio: write called, count = %d\n, count);
#endif
kbuf = kmalloc(count, GFP_KERNEL);
@@ -128,24 +128,24 @@ static ssize_t hostaudio_write(struct fi
static unsigned int hostaudio_poll(struct file *file,
struct poll_table_struct *wait)
{
-unsigned int mask = 0;
+ unsigned int mask = 0;
#ifdef DEBUG
-printk(hostaudio: poll called (unimplemented)\n);
+ printk(hostaudio: poll called (unimplemented)\n);
#endif
-return(mask);
+ return(mask);
}
static int hostaudio_ioctl(struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg)
{
-struct hostaudio_state *state = file-private_data;
+ struct hostaudio_state *state = file-private_data;
unsigned long data = 0;
int err;
#ifdef DEBUG
-printk(hostaudio: ioctl called, cmd = %u\n, cmd);
+ printk(hostaudio: ioctl called, cmd = %u\n, cmd);
#endif
switch(cmd){
case SNDCTL_DSP_SPEED:
@@ -182,42 +182,40 @@ static int hostaudio_ioctl(struct inode
static int hostaudio_open(struct inode *inode, struct file *file)
{
-struct hostaudio_state *state;
-int r = 0, w = 0;
-int ret;
+ struct hostaudio_state *state;
+ int r = 0, w = 0;
+ int ret;
#ifdef DEBUG
-printk(hostaudio: open called (host: %s)\n, dsp);
+ printk(hostaudio: open called (host: %s)\n, dsp);
#endif
-state = kmalloc(sizeof(struct hostaudio_state), GFP_KERNEL);
-if(state == NULL)
+ state = kmalloc(sizeof(struct hostaudio_state), GFP_KERNEL);
+ if(state == NULL)
return(-ENOMEM);
-if(file-f_mode FMODE_READ) r = 1;
-if(file-f_mode FMODE_WRITE) w = 1;
+ if(file-f_mode FMODE_READ) r = 1;
+ if(file-f_mode FMODE_WRITE) w = 1;
ret = os_open_file(dsp, of_set_rw(OPENFLAGS(), r, w), 0);
-if(ret 0){
+ if(ret 0){
kfree(state);
return(ret);
-}
-
+ }
state-fd = ret;
-file-private_data = state;
-return(0);
+ file-private_data = state;
+ return(0);
}
static int hostaudio_release(struct inode *inode, struct file *file)
{
-struct hostaudio_state *state = file-private_data;
+ struct hostaudio_state *state = file-private_data;
#ifdef DEBUG
-printk(hostaudio: release called\n);
+ printk(hostaudio: release called\n);
#endif
-
- os_close_file(state-fd);
-kfree(state);
+ os_close_file(state-fd);
+ kfree(state);
return(0);
}
@@ -227,10 +225,10 @@ static int hostaudio_release(struct inod
static int hostmixer_ioctl_mixdev(struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg)
{
-struct hostmixer_state *state = file-private_data;
+ struct hostmixer_state *state = file-private_data;
#ifdef DEBUG
-printk(hostmixer: ioctl called\n);
+ printk(hostmixer:
[PATCH 2/8] UML - watchdog driver formatting
Whitespace and style fixes.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/drivers/harddog_kern.c | 33 +++--
arch/um/drivers/harddog_user.c | 23 ++-
2 files changed, 17 insertions(+), 39 deletions(-)
Index: linux-2.6.18-mm/arch/um/drivers/harddog_kern.c
===
--- linux-2.6.18-mm.orig/arch/um/drivers/harddog_kern.c 2006-12-29
21:02:50.0 -0500
+++ linux-2.6.18-mm/arch/um/drivers/harddog_kern.c 2006-12-29
21:13:36.0 -0500
@@ -9,10 +9,10 @@
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
- *
- * Neither Alan Cox nor CymruNet Ltd. admit liability nor provide
- * warranty for any of this software. This material is provided
- * AS-IS and at no charge.
+ *
+ * Neither Alan Cox nor CymruNet Ltd. admit liability nor provide
+ * warranty for any of this software. This material is provided
+ * AS-IS and at no charge.
*
* (c) Copyright 1995Alan Cox [EMAIL PROTECTED]
*
@@ -29,11 +29,11 @@
* Made SMP safe for 2.3.x
*
* 20011127 Joel Becker ([EMAIL PROTECTED]
- * Added soft_noboot; Allows testing the softdog trigger without
+ * Added soft_noboot; Allows testing the softdog trigger without
* requiring a recompile.
* Added WDIOC_GETTIMEOUT and WDIOC_SETTIMOUT.
*/
-
+
#include linux/module.h
#include linux/types.h
#include linux/kernel.h
@@ -58,7 +58,7 @@ static int harddog_out_fd = -1;
/*
* Allow only one person to hold it open
*/
-
+
extern int start_watchdog(int *in_fd_ret, int *out_fd_ret, char *sock);
static int harddog_open(struct inode *inode, struct file *file)
@@ -69,7 +69,7 @@ static int harddog_open(struct inode *in
spin_lock(lock);
if(timer_alive)
goto err;
-#ifdef CONFIG_HARDDOG_NOWAYOUT
+#ifdef CONFIG_HARDDOG_NOWAYOUT
__module_get(THIS_MODULE);
#endif
@@ -117,7 +117,7 @@ static ssize_t harddog_write(struct file
* Refresh the timer.
*/
if(len)
- return(ping_watchdog(harddog_out_fd));
+ return ping_watchdog(harddog_out_fd);
return 0;
}
@@ -141,7 +141,7 @@ static int harddog_ioctl(struct inode *i
case WDIOC_GETBOOTSTATUS:
return put_user(0,(int __user *)argp);
case WDIOC_KEEPALIVE:
- return(ping_watchdog(harddog_out_fd));
+ return ping_watchdog(harddog_out_fd);
}
}
@@ -172,7 +172,7 @@ static int __init harddog_init(void)
printk(banner);
- return(0);
+ return 0;
}
static void __exit harddog_exit(void)
@@ -182,14 +182,3 @@ static void __exit harddog_exit(void)
module_init(harddog_init);
module_exit(harddog_exit);
-
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only. This must remain at the end
- * of the file.
- * ---
- * Local variables:
- * c-file-style: linux
- * End:
- */
Index: linux-2.6.18-mm/arch/um/drivers/harddog_user.c
===
--- linux-2.6.18-mm.orig/arch/um/drivers/harddog_user.c 2006-12-29
18:25:36.0 -0500
+++ linux-2.6.18-mm/arch/um/drivers/harddog_user.c 2006-12-29
21:12:41.0 -0500
@@ -1,4 +1,4 @@
-/*
+/*
* Copyright (C) 2002 Jeff Dike ([EMAIL PROTECTED])
* Licensed under the GPL
*/
@@ -38,7 +38,7 @@ int start_watchdog(int *in_fd_ret, int *
int in_fds[2], out_fds[2], pid, n, err;
char pid_buf[sizeof(n\0)], c;
char *pid_args[] = { /usr/bin/uml_watchdog, -pid, pid_buf, NULL };
- char *mconsole_args[] = { /usr/bin/uml_watchdog, -mconsole, NULL,
+ char *mconsole_args[] = { /usr/bin/uml_watchdog, -mconsole, NULL,
NULL };
char **args = NULL;
@@ -96,7 +96,7 @@ int start_watchdog(int *in_fd_ret, int *
}
*in_fd_ret = in_fds[0];
*out_fd_ret = out_fds[1];
- return(0);
+ return 0;
out_close_in:
os_close_file(in_fds[0]);
@@ -105,7 +105,7 @@ int start_watchdog(int *in_fd_ret, int *
os_close_file(out_fds[0]);
os_close_file(out_fds[1]);
out:
- return(err);
+ return err;
}
void stop_watchdog(int in_fd, int out_fd)
@@ -123,20 +123,9 @@ int ping_watchdog(int fd)
if(n != sizeof(c)){
printk(ping_watchdog - write failed, err = %d\n, -n);
if(n 0)
- return(n);
- return(-EIO);
+ return n;
+ return -EIO;
[PATCH 1/8] UML - watchdog driver locking
Replace BKL use with a spinlock.
Also fix the control so that open doesn't return holding a lock.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/drivers/harddog_kern.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
Index: linux-2.6.18-mm/arch/um/drivers/harddog_kern.c
===
--- linux-2.6.18-mm.orig/arch/um/drivers/harddog_kern.c 2006-12-29
18:25:36.0 -0500
+++ linux-2.6.18-mm/arch/um/drivers/harddog_kern.c 2006-12-29
21:02:50.0 -0500
@@ -44,12 +44,13 @@
#include linux/reboot.h
#include linux/smp_lock.h
#include linux/init.h
+#include linux/spinlock.h
#include asm/uaccess.h
#include mconsole.h
MODULE_LICENSE(GPL);
-/* Locked by the BKL in harddog_open and harddog_release */
+static DEFINE_SPINLOCK(lock);
static int timer_alive;
static int harddog_in_fd = -1;
static int harddog_out_fd = -1;
@@ -62,12 +63,12 @@ extern int start_watchdog(int *in_fd_ret
static int harddog_open(struct inode *inode, struct file *file)
{
- int err;
+ int err = -EBUSY;
char *sock = NULL;
- lock_kernel();
+ spin_lock(lock);
if(timer_alive)
- return -EBUSY;
+ goto err;
#ifdef CONFIG_HARDDOG_NOWAYOUT
__module_get(THIS_MODULE);
#endif
@@ -76,11 +77,15 @@ static int harddog_open(struct inode *in
sock = mconsole_notify_socket();
#endif
err = start_watchdog(harddog_in_fd, harddog_out_fd, sock);
- if(err) return(err);
+ if(err)
+ goto err;
timer_alive = 1;
- unlock_kernel();
+ spin_unlock(lock);
return nonseekable_open(inode, file);
+err:
+ spin_unlock(lock);
+ return err;
}
extern void stop_watchdog(int in_fd, int out_fd);
@@ -90,14 +95,16 @@ static int harddog_release(struct inode
/*
* Shut off the timer.
*/
- lock_kernel();
+
+ spin_lock(lock);
stop_watchdog(harddog_in_fd, harddog_out_fd);
harddog_in_fd = -1;
harddog_out_fd = -1;
timer_alive=0;
- unlock_kernel();
+ spin_unlock(lock);
+
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] UML - make two variables static
Make a couple of variables static.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/drivers/port_kern.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.18-mm/arch/um/drivers/port_kern.c
===
--- linux-2.6.18-mm.orig/arch/um/drivers/port_kern.c2007-01-01
11:32:22.0 -0500
+++ linux-2.6.18-mm/arch/um/drivers/port_kern.c 2007-01-01 12:03:54.0
-0500
@@ -129,8 +129,8 @@ static int port_accept(struct port_list
return(ret);
}
-DECLARE_MUTEX(ports_sem);
-struct list_head ports = LIST_HEAD_INIT(ports);
+static DECLARE_MUTEX(ports_sem);
+static struct list_head ports = LIST_HEAD_INIT(ports);
void port_work_proc(struct work_struct *unused)
{
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] UML - port driver formatting
Whitespace and style fixes.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/drivers/port_kern.c | 46 +++
arch/um/drivers/port_user.c | 51 +---
2 files changed, 43 insertions(+), 54 deletions(-)
Index: linux-2.6.18-mm/arch/um/drivers/port_kern.c
===
--- linux-2.6.18-mm.orig/arch/um/drivers/port_kern.c2007-01-01
13:28:27.0 -0500
+++ linux-2.6.18-mm/arch/um/drivers/port_kern.c 2007-01-01 13:29:38.0
-0500
@@ -1,4 +1,4 @@
-/*
+/*
* Copyright (C) 2001, 2002 Jeff Dike ([EMAIL PROTECTED])
* Licensed under the GPL
*/
@@ -55,9 +55,9 @@ static irqreturn_t pipe_interrupt(int ir
fd = os_rcv_fd(conn-socket[0], conn-helper_pid);
if(fd 0){
if(fd == -EAGAIN)
- return(IRQ_NONE);
+ return IRQ_NONE;
- printk(KERN_ERR pipe_interrupt : os_rcv_fd returned %d\n,
+ printk(KERN_ERR pipe_interrupt : os_rcv_fd returned %d\n,
-fd);
os_close_file(conn-fd);
}
@@ -68,7 +68,7 @@ static irqreturn_t pipe_interrupt(int ir
list_add(conn-list, conn-port-connections);
complete(conn-port-done);
- return(IRQ_HANDLED);
+ return IRQ_HANDLED;
}
#define NO_WAITER_MSG \
@@ -97,14 +97,14 @@ static int port_accept(struct port_list
connection\n);
goto out_close;
}
- *conn = ((struct connection)
+ *conn = ((struct connection)
{ .list = LIST_HEAD_INIT(conn-list),
.fd = fd,
.socket = { socket[0], socket[1] },
.telnetd_pid = pid,
.port = port });
- if(um_request_irq(TELNETD_IRQ, socket[0], IRQ_READ, pipe_interrupt,
+ if(um_request_irq(TELNETD_IRQ, socket[0], IRQ_READ, pipe_interrupt,
IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM,
telnetd, conn)){
printk(KERN_ERR port_accept : failed to get IRQ for
@@ -117,17 +117,17 @@ static int port_accept(struct port_list
printk(No one waiting for port\n);
}
list_add(conn-list, port-pending);
- return(1);
+ return 1;
out_free:
kfree(conn);
out_close:
os_close_file(fd);
- if(pid != -1)
+ if(pid != -1)
os_kill_process(pid, 1);
out:
- return(ret);
-}
+ return ret;
+}
static DECLARE_MUTEX(ports_sem);
static struct list_head ports = LIST_HEAD_INIT(ports);
@@ -158,8 +158,8 @@ static irqreturn_t port_interrupt(int ir
port-has_connection = 1;
schedule_work(port_work);
- return(IRQ_HANDLED);
-}
+ return IRQ_HANDLED;
+}
void *port_data(int port_num)
{
@@ -185,14 +185,14 @@ void *port_data(int port_num)
port_num, -fd);
goto out_free;
}
- if(um_request_irq(ACCEPT_IRQ, fd, IRQ_READ, port_interrupt,
- IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM,
port,
- port)){
+ if(um_request_irq(ACCEPT_IRQ, fd, IRQ_READ, port_interrupt,
+ IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM,
+ port, port)){
printk(KERN_ERR Failed to get IRQ for port %d\n, port_num);
goto out_close;
}
- *port = ((struct port_list)
+ *port = ((struct port_list)
{ .list = LIST_HEAD_INIT(port-list),
.wait_count = ATOMIC_INIT(0),
.has_connection = 0,
@@ -222,7 +222,7 @@ void *port_data(int port_num)
os_close_file(fd);
out:
up(ports_sem);
- return(dev);
+ return dev;
}
int port_wait(void *data)
@@ -232,15 +232,15 @@ int port_wait(void *data)
struct port_list *port = dev-port;
int fd;
-atomic_inc(port-wait_count);
+ atomic_inc(port-wait_count);
while(1){
fd = -ERESTARTSYS;
-if(wait_for_completion_interruptible(port-done))
-goto out;
+ if(wait_for_completion_interruptible(port-done))
+ goto out;
spin_lock(port-lock);
- conn = list_entry(port-connections.next, struct connection,
+ conn = list_entry(port-connections.next, struct connection,
list);
list_del(conn-list);
spin_unlock(port-lock);
@@ -248,12 +248,12 @@ int port_wait(void *data)
os_shutdown_socket(conn-socket[0], 1, 1);
os_close_file(conn-socket[0]);
os_shutdown_socket(conn-socket[1], 1, 1);
-
[PATCH 8/8] UML - Kill a compilation warning
Kill a compilation warning.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/kernel/exec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.18-mm/arch/um/kernel/exec.c
===
--- linux-2.6.18-mm.orig/arch/um/kernel/exec.c 2007-01-01 11:32:22.0
-0500
+++ linux-2.6.18-mm/arch/um/kernel/exec.c 2007-01-01 11:45:15.0
-0500
@@ -39,9 +39,9 @@ static long execve1(char *file, char __u
char __user *__user *env)
{
long error;
+#ifdef CONFIG_TTY_LOG
struct tty_struct *tty;
-#ifdef CONFIG_TTY_LOG
mutex_lock(tty_mutex);
tty = get_current_tty();
if (tty)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/8] UML - mconsole locking
Locking fixes. Locking was totally lacking for the mconsole_devices,
which got a spin lock, and the unplugged pages data, which got a
mutex.
The locking of the mconsole console output code was confused. Now,
the console_lock (renamed to client_lock) protects the clients list.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/drivers/mconsole_kern.c | 21 +++--
arch/um/drivers/net_kern.c |1 +
arch/um/drivers/ssl.c |1 +
arch/um/drivers/ubd_kern.c |1 +
arch/um/kernel/tt/gdb_kern.c|1 +
5 files changed, 19 insertions(+), 6 deletions(-)
Index: linux-2.6.18-mm/arch/um/drivers/mconsole_kern.c
===
--- linux-2.6.18-mm.orig/arch/um/drivers/mconsole_kern.c2007-01-01
11:32:22.0 -0500
+++ linux-2.6.18-mm/arch/um/drivers/mconsole_kern.c 2007-01-01
12:12:53.0 -0500
@@ -337,13 +337,15 @@ void mconsole_stop(struct mc_request *re
mconsole_reply(req, , 0, 0);
}
-/* This list is populated by __initcall routines. */
-
+static DEFINE_SPINLOCK(mc_devices_lock);
static LIST_HEAD(mconsole_devices);
void mconsole_register_dev(struct mc_device *new)
{
+ spin_lock(mc_devices_lock);
+ BUG_ON(!list_empty(new-list));
list_add(new-list, mconsole_devices);
+ spin_unlock(mc_devices_lock);
}
static struct mc_device *mconsole_find_dev(char *name)
@@ -367,6 +369,7 @@ struct unplugged_pages {
void *pages[UNPLUGGED_PER_PAGE];
};
+static DECLARE_MUTEX(plug_mem_mutex);
static unsigned long long unplugged_pages_count = 0;
static struct list_head unplugged_pages = LIST_HEAD_INIT(unplugged_pages);
static int unplug_index = UNPLUGGED_PER_PAGE;
@@ -402,6 +405,7 @@ static int mem_config(char *str, char **
diff /= PAGE_SIZE;
+ down(plug_mem_mutex);
for(i = 0; i diff; i++){
struct unplugged_pages *unplugged;
void *addr;
@@ -447,7 +451,7 @@ static int mem_config(char *str, char **
printk(Failed to release memory -
errno = %d\n, err);
*error_out = Failed to release memory;
- goto out;
+ goto out_unlock;
}
unplugged-pages[unplug_index++] = addr;
}
@@ -457,6 +461,8 @@ static int mem_config(char *str, char **
}
err = 0;
+out_unlock:
+ up(plug_mem_mutex);
out:
return err;
}
@@ -487,6 +493,7 @@ static int mem_remove(int n, char **erro
}
static struct mc_device mem_mc = {
+ .list = LIST_HEAD_INIT(mem_mc.list),
.name = mem,
.config = mem_config,
.get_config = mem_get_config,
@@ -629,7 +636,7 @@ struct mconsole_output {
struct mc_request *req;
};
-static DEFINE_SPINLOCK(console_lock);
+static DEFINE_SPINLOCK(client_lock);
static LIST_HEAD(clients);
static char console_buf[MCONSOLE_MAX_DATA];
static int console_index = 0;
@@ -684,16 +691,18 @@ static void with_console(struct mc_reque
unsigned long flags;
entry.req = req;
+ spin_lock_irqsave(client_lock, flags);
list_add(entry.list, clients);
- spin_lock_irqsave(console_lock, flags);
+ spin_unlock_irqrestore(client_lock, flags);
(*proc)(arg);
mconsole_reply_len(req, console_buf, console_index, 0, 0);
console_index = 0;
- spin_unlock_irqrestore(console_lock, flags);
+ spin_lock_irqsave(client_lock, flags);
list_del(entry.list);
+ spin_unlock_irqrestore(client_lock, flags);
}
#ifdef CONFIG_MAGIC_SYSRQ
Index: linux-2.6.18-mm/arch/um/drivers/net_kern.c
===
--- linux-2.6.18-mm.orig/arch/um/drivers/net_kern.c 2006-12-29
18:24:20.0 -0500
+++ linux-2.6.18-mm/arch/um/drivers/net_kern.c 2007-01-01 12:18:47.0
-0500
@@ -690,6 +690,7 @@ static int net_remove(int n, char **erro
}
static struct mc_device net_mc = {
+ .list = LIST_HEAD_INIT(net_mc.list),
.name = eth,
.config = net_config,
.get_config = NULL,
Index: linux-2.6.18-mm/arch/um/drivers/ssl.c
===
--- linux-2.6.18-mm.orig/arch/um/drivers/ssl.c 2006-12-29 17:26:54.0
-0500
+++ linux-2.6.18-mm/arch/um/drivers/ssl.c 2007-01-01 12:18:42.0
-0500
@@ -64,6 +64,7 @@ static struct line_driver driver = {
.symlink_from = serial,
.symlink_to = tts,
.mc = {
+ .list = LIST_HEAD_INIT(driver.mc.list),
.name = ssl,
.config = ssl_config,
Re: [PATCH 1/6] UML - Console locking fixes
On Fri, Dec 29, 2006 at 03:48:02PM -0800, Randy Dunlap wrote: /* * Normally, ... if ( (several of these) Yeah, I'm working off the most blatant style violations at the moment. Jeff -- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Happy New Year (and v2.6.20-rc3 released)
Linus Torvalds wrote: Jeff, what was the resolution to this one? Just revert the offending commit, or what? We're about five weeks into the 2.6.20-rc series. I was hoping for a two-month release rather than the usual dragged-out three months, so I'd like to get these regressions to be actively fixed. By forcible reverts if that is what it takes. Data points: * I was unable to argue against Alan's logic behind 368c73d4f689dae0807d0a2aa74c61fd2b9b075f but I just don't like it. Regardless of whether or not this truly reflects how the PCI device is wired, it makes pci_request_regions() and similar resource handling code behave differently. * Alan's 368c73d4f689dae0807d0a2aa74c61fd2b9b075f change was IMO incomplete, because he obviously did not fix all the breakage it caused * Alan proposed a libata fix patch. I noted two key breakages in his fix patch, one of which Alan agreed was a problem. * Outside of the two bugfix pushes, I've been actively avoiding computers during the holidays. It's a shocking concept I'm trying with the new wife :) Don't expect anything useful from me until Jan 4th or so. * This affects a lot of Intel ICH platforms in legacy/combined mode, so it's definitely high on my post-holiday priority list. If the patch is not reverted, then I'll definitely fix it sooner rather than later. * For 2.6.21, I proposed to yank out all the ugly combined mode hacks (grep for 'request_resource'), which should make Alan's change a bit easier... but nonetheless stirs the IDE quirks code again. * I am lazy and would rather not touch the fragile ata_pci_init_one() code now /and/ in 2.6.21. So I vote for revert, for 2.6.20, but I know Alan will squawk loudly. Also NOTE thoughfb0f2b40faff41f03acaa2ee6e6231fc96ca497c which fixes fallout from Alan's change, too. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.20-rc1 1/6] GPIO core
Hi! Well. when you see (something) = gpio_number + 5 ... you most likely have an error. One could surely apply that argument to hundreds of places throughout the kernel ... that doesn't make it a good one. One of the downfalls of many object oriented programming efforts was this same desire to encapsulate things that don't need it; it's lose, not a don't-care. Think of it as cookies represented by integers if you like. typedef int gpio_t would hurt, and would serve as a useful documentation hint. Furthermore, you could switch it to enum on platform where it makes sense. No, that's a wrong way. I want you to admit that gpio numbers are opaque cookies noone should look at, and use (something like) gpio_t... so that we can teach sparse to check them. You're welcome to dream on. :) The goal here is not to create new complexity, it's to wrap the ...it adds exactly one line. +The get/set calls have no error returns because invalid GPIO should have +been reported earlier in gpio_set_direction(). However, note that not all +platforms can read the value of output pins; those that can't should always +return zero. Also, these calls will be ignored for GPIOs that can't safely +be accessed without sleeping (see below). 'Silently ignored' is ugly. BUG() would be okay there. The reason for silently ignored is that we really don't want to be cluttering up the code (source or object) with logic to test for this kind of can't happen failure, especially since there's not going to be any way to _resolve_ such failures cleanly. You may not want to clutter up code for one arch, but for some of them maybe it is okay and welcome. Please do not document silently ignored into API. Those words were yours; so you can consider that already done. Should it instead say that's an (obviously unchecked) error? Saying it is an error would be okay by me. (Or Behaviour of these calls for GPIOs that can't be safely accessed without sleeping is undefined.). You are perverting what _I_ said. (As you've done before; stop that.) Sorry. In terms of API specs, emitting any warning is traditionally out-of-scope. Ok, I mis-read your specs as trying to push warnings into the scope. +... It is an unchecked error to use a GPIO +number that hasn't been marked as an input using gpio_set_direction(), or It should be valid to do irqs on outputs, Good point -- it _might_ be valid to do that, on some platforms. Such things have been used as a software IRQ trigger, which can make bootstrapping some things easier. That's not incompatible with it being an error for portable code to try that, or with refusing to check it so that those platforms don't needlessly cause trouble! I believe your text suggests it _is_ incompatible. Plus that seems to mean that architecture must not check for that error... Which -- that portable code mustn't try such things? That seems clearly wrong; that's what the is an error phrase means. Or that code Ok, debug behaviour is out of scope, again. What about Behavour of reading a GPIO that hasn't been marked as an input using gpio_set_direction() is implementation-defined? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Cut power to a USB port?
I have a simple question perhaps someone can help me with here... I have one of those simple LED keyboard lamps that get their power from the USB port. Is there some way in Linux, using files under /sys I would imagine, to cut power to the USB port into which this lamp is plugged? I know I would have to manually figure out what port it's plugged into, as it is not a real USB device...e.g. it just draws power. I would like to be able to programmatically switch the lamp on and off. Thanks in advance, Andrew Barr Please CC any replies - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Happy New Year (and v2.6.20-rc3 released)
On Mon, 1 Jan 2007 12:13:08 -0800 (PST) Linus Torvalds [EMAIL PROTECTED] wrote: Jeff, what was the resolution to this one? Just revert the offending commit, or what? If you revert the commit you end with all the PCI resource tree breakage back We're about five weeks into the 2.6.20-rc series. I was hoping for a two-month release rather than the usual dragged-out three months, so I'd like to get these regressions to be actively fixed. By forcible reverts if that is what it takes. The patch I sent ages back is perfectly adequate for 2.6.20-rc/2.6.20 final. Jeff is correct that it isn't perfection in all cases but it does no real harm and the right fix (removing the whole bogus combined mode garbage) is short and simple. If Jeff doesn't get you a patch please let me know before reverting it and I'll send you the one I'm using that folks have tested and works. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Happy New Year (and v2.6.20-rc3 released)
* I was unable to argue against Alan's logic behind 368c73d4f689dae0807d0a2aa74c61fd2b9b075f but I just don't like it. Regardless of whether or not this truly reflects how the PCI device is wired, it makes pci_request_regions() and similar resource handling code behave differently. Correctly: The resource tree is no longer corrupt for example and pci_* resource functions actually now do the right thing. The old code works by chance due to link order, not because anything was broken by the corrections. * Alan proposed a libata fix patch. I noted two key breakages in his fix patch, one of which Alan agreed was a problem. Not a 2.6.20 stopping problem and trivial to fix further. So I vote for revert, for 2.6.20, but I know Alan will squawk loudly. Also NOTE thoughfb0f2b40faff41f03acaa2ee6e6231fc96ca497c which fixes fallout from Alan's change, too. I'm very concerned about what that will break that depends upon it - eg all the work done for suspend/resume PCI handling has not been tested without the patch. Thus I'd rather fix it given the fix is trivial. Want a fix Linus given Jeff is away ? Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/linux/slab.h: new KFREE() macro.
On 1/1/07, Amit Choudhary [EMAIL PROTECTED] wrote:
+#define KFREE(x) \
+ do {\
+ kfree(x); \
+ x = NULL; \
+ } while(0)
NAK until you have actual callers for it. CONFIG_SLAB_DEBUG already
catches use after free and double-free so I don't see the point of
this.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.20-rc1 1/6] GPIO core
On Monday 01 January 2007 12:55 pm, Pavel Machek wrote: Think of it as cookies represented by integers if you like. typedef int gpio_t would hurt, and would serve as a useful documentation hint. Yes, I agree that such needless obfuscation hurts. ;) Plus, such a typedef would disagree with Documentation/CodingStyle which says ... the rule should basically be to NEVER EVER use a typedef (with some exceptions not matched here). Should it instead say that's an (obviously unchecked) error? Saying it is an error would be okay by me. (Or Behaviour of these calls for GPIOs that can't be safely accessed without sleeping is undefined.). See the appended doc patch ... better? - Dave = CUT HERE Index: at91/Documentation/gpio.txt === --- at91.orig/Documentation/gpio.txt2006-12-29 00:00:28.0 -0800 +++ at91/Documentation/gpio.txt 2006-12-29 15:47:18.0 -0800 @@ -78,7 +78,8 @@ Identifying GPIOs - GPIOs are identified by unsigned integers in the range 0..MAX_INT. That reserves negative numbers for other purposes like marking signals as -not available on this board, or indicating faults. +not available on this board, or indicating faults. Code that doesn't +touch the underlying hardware treats these integers as opaque cookies. Platforms define how they use those integers, and usually #define symbols for the GPIO lines so that board-specific setup code directly corresponds @@ -139,8 +140,8 @@ issues including wire-OR and output late The get/set calls have no error returns because invalid GPIO should have been reported earlier in gpio_set_direction(). However, note that not all platforms can read the value of output pins; those that can't should always -return zero. Also, these calls will be ignored for GPIOs that can't safely -be accessed wihtout sleeping (see below). +return zero. Also, using these calls for GPIOs that can't safely be accessed +without sleeping (see below) is an error. Platform-specific implementations are encouraged to optimise the two calls to access the GPIO value in cases where the GPIO number (and for @@ -239,7 +240,8 @@ options are part of the IRQ interface, e system wakeup capabilities. Non-error values returned from irq_to_gpio() would most commonly be used -with gpio_get_value(). +with gpio_get_value(), for example to initialize or update driver state +when the IRQ is edge-triggered. @@ -262,7 +264,8 @@ like the aforementioned options for inpu Hardware may support reading or writing GPIOs in gangs, but that's usually configuration dependednt: for GPIOs sharing the same bank. (GPIOs are commonly grouped in banks of 16 or 32, with a given SOC having several such -banks.) Code relying on such mechanisms will necessarily be nonportable. +banks.) Some systems can trigger IRQs from output GPIOs. Code relying on +such mechanisms will necessarily be nonportable. Dynamic definition of GPIOs is not currently supported; for example, as a side effect of configuring an add-on board with some GPIO expanders. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch i386: Relocatable kernel support causes instant reboot
Hi Vivek, Sorry for the delay, I'm just back from vacation. I tried it all again with 2.6.20-rc3 just in case, but the problem I've hit is still present. On Fri, 22 Dec 2006 16:10:56 +0530, Vivek Goyal wrote: Can you please also upload boot/compressed/vmlinux. I've shared the whole build tree so that you can peek at files without waiting for me to upload them. It is temporarily available at: http://jdelvare.pck.nerim.net/linux/relocatable-bug/ Hidden files are there too, just not listed. Thanks, -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [DISCUSS] Make the variable NULL after freeing it.
On Monday, 1. January 2007 17:25, Andreas Schwab wrote: Ingo Oeser [EMAIL PROTECTED] writes: Then this works, because the side effect (+20) is evaluated only once. It's not a side effect, it's a non-lvalue, and you can't take the address of a non-lvalue. Just verified this. So If we cannot make it work in all cases, it will cause more problems then it will solve. So we are left with a function, which will a) only be used by janitors to provide kfree(x); x = NULL; with an macro KFREE(x) in all the simple cases. b) be used by developers, who are aware of the fact that reusable pointer values should set to NULL after kfree(). Doing a) and b) is running into open doors, so doesn't prevent any error, obfuscates code more and works only sometimes. I give up here and would vote for dropping that idea then. Regards Ingo Oeser pgpcCSfafJsC7.pgp Description: PGP signature
Re: [PATCH] radeonfb: add support for newer cards
Il Mon, Jan 01, 2007 at 10:25:51PM +0100, Luca Tettamanti ha scritto:
Hi Ben, Andrew,
I've rebased 'ATOM BIOS patch' from Solomon Peachy to apply to 2.6.20.
The patch adds support for newer Radeon cards and is mainly based on
X.Org code.
And - for an easier review - this is the diff between
radeonfb-atom-2.6.19-v6a.diff from Solomon and my patch (whitespace-only
changes not included).
---
drivers/video/aty/radeon_base.c| 26 +-
drivers/video/aty/radeon_i2c.c |8
drivers/video/aty/radeon_monitor.c | 347 ++-
3 files changed, 198 insertions(+), 183 deletions(-)
diff -wu linux-2.6/drivers/video/aty/radeon_base.c
linux-2.6.git/drivers/video/aty/radeon_base.c
--- linux-2.6/drivers/video/aty/radeon_base.c 2007-01-01 22:31:14.0
+0100
+++ linux-2.6.git/drivers/video/aty/radeon_base.c 2007-01-01
19:38:54.0 +0100
@@ -287,7 +287,6 @@
/*
* globals
*/
-
static char *mode_option;
static char *monitor_layout;
static int noaccel = 0;
@@ -663,21 +662,20 @@
{
#ifdef CONFIG_PPC_OF
rinfo-is_atom_bios = 0;
- rinfo-get_pll_info = radeon_get_pll_info_openfirmware;
- rinfo-get_lvds_info = radeon_get_lvds_info_openfirmware;
+ rinfo-radeon_get_pll_info = radeon_get_pll_info_openfirmware;
+ rinfo-radeon_get_lvds_info = radeon_get_lvds_info_openfirmware;
rinfo-radeon_get_tmds_info = NULL;
- rinfo-get_conn_info = radeon_get_conn_info_openfirmware;
+ rinfo-radeon_get_conn_info = radeon_get_conn_info_openfirmware;
#else
int tmp = rinfo-fp_bios_start + 4;
+ unsigned char sign[4];
+
+ sign[0] = BIOS_IN8(tmp);
+ sign[1] = BIOS_IN8(tmp + 1);
+ sign[2] = BIOS_IN8(tmp + 2);
+ sign[3] = BIOS_IN8(tmp + 3);
- if ((BIOS_IN8(tmp) == 'A'
- BIOS_IN8(tmp+1) == 'T'
- BIOS_IN8(tmp+2) == 'O'
- BIOS_IN8(tmp+3) == 'M') ||
- (BIOS_IN8(tmp) == 'M'
- BIOS_IN8(tmp+1) == 'O'
- BIOS_IN8(tmp+2) == 'T'
- BIOS_IN8(tmp+3) == 'A')) {
+ if (!memcmp(sign, ATOM, 4) || !memcmp(sign, MOTA, 4)) {
rinfo-is_atom_bios = 1;
rinfo-atom_data_start = BIOS_IN16(rinfo-fp_bios_start + 32);
@@ -1075,7 +1073,8 @@
OUTREG(CRTC_EXT_CNTL, val);
for (i = 0 ; i RADEON_MAX_CONNECTORS ; i++) {
- if (i == -1) continue;
+ if (rinfo-heads[i] == -1)
+ continue;
switch (rinfo-connectors[rinfo-heads[i]].mon_type) {
case MT_DFP:
@@ -2571,7 +2570,6 @@
{
struct fb_info *info = pci_get_drvdata(pdev);
struct radeonfb_info *rinfo = info-par;
-
int i;
if (!rinfo)
diff -wu linux-2.6/drivers/video/aty/radeon_i2c.c
linux-2.6.git/drivers/video/aty/radeon_i2c.c
--- linux-2.6/drivers/video/aty/radeon_i2c.c2007-01-01 22:31:14.0
+0100
+++ linux-2.6.git/drivers/video/aty/radeon_i2c.c2007-01-01
19:16:03.0 +0100
@@ -149,14 +149,18 @@
(INREG(LVDS_GEN_CNTL) (LVDS_ON|LVDS_EN))) {
RTRACE(radeonfb: I2C (port %d) ... found LVDS
panel\n, conn-ddc_type);
mon_type = MT_LCD;
+ edid = NULL;
goto done;
}
+ if (conn-ddc_type == ddc_none)
+ return 1;
edid = fb_ddc_read(rinfo-i2c[conn-ddc_type].adapter);
if (!edid) {
- // what about the special case where we are a DFP/LVDS, but have a
DDC connection..
- // but no EDID? We should fall back to MT_LCD...?
+ /* what about the special case where we are a DFP/LVDS, but
have a DDC connection
+* but no EDID? We should fall back to MT_LCD...?
+*/
RTRACE(radeonfb: I2C (port %d) ... not found\n,
conn-ddc_type);
mon_type = MT_NONE;
goto done;
diff -wu linux-2.6/drivers/video/aty/radeon_monitor.c
linux-2.6.git/drivers/video/aty/radeon_monitor.c
--- linux-2.6/drivers/video/aty/radeon_monitor.c2007-01-01
22:31:14.0 +0100
+++ linux-2.6.git/drivers/video/aty/radeon_monitor.c2007-01-01
19:36:51.0 +0100
@@ -16,7 +16,7 @@
{{15000, 0xa1b}, {0x, 0xa3f}, {0, 0}, {0, 0}},
/*CHIP_FAMILY_R200*/
{{15500, 0x81b}, {0x, 0x83f}, {0, 0}, {0, 0}},
/*CHIP_FAMILY_RV250*/
{{0, 0}, {0, 0}, {0, 0}, {0, 0}},
/*CHIP_FAMILY_RS300*/
-{{13000, 0x400f4}, {15000, 0x400f7}, {0x, 0x400f7/*0x40111*/}, {0,
0}},/*CHIP_FAMILY_RV280*/
+ {{13000, 0x400f4}, {15000, 0x400f7}, {0x, 0x400f7}, {0, 0}},
/*CHIP_FAMILY_RV280*/
{{0x, 0xb01cb}, {0, 0}, {0, 0}, {0, 0}},
/*CHIP_FAMILY_R300*/
{{0x, 0xb01cb}, {0, 0}, {0, 0}, {0, 0}},
/*CHIP_FAMILY_R350*/
{{15000,
Re: [PATCH] [DISCUSS] Make the variable NULL after freeing it.
On Jan 1 2007 22:40, Ingo Oeser wrote: On Monday, 1. January 2007 17:25, Andreas Schwab wrote: Ingo Oeser [EMAIL PROTECTED] writes: Then this works, because the side effect (+20) is evaluated only once. It's not a side effect, it's a non-lvalue, and you can't take the address of a non-lvalue. Just verified this. So If we cannot make it work in all cases, it will cause more problems then it will solve. So we are left with a function, which will a) only be used by janitors to provide kfree(x); x = NULL; with an macro KFREE(x) in all the simple cases. Just checking, where has it been decided that we actually are going to have kfree_nullify() or whatever the end result happens to be called? Thanks, -`J' -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cut power to a USB port?
Am Montag, 1. Januar 2007 21:56 schrieb Andrew Barr: I have a simple question perhaps someone can help me with here... I have one of those simple LED keyboard lamps that get their power from the USB port. Is there some way in Linux, using files under /sys I would imagine, to cut power to the USB port into which this lamp is plugged? I You could use usbfs to send commands to the hub. know I would have to manually figure out what port it's plugged into, as it is not a real USB device...e.g. it just draws power. I would like to be able to programmatically switch the lamp on and off. The ability to cut each port's power individually is optional. Your hardware may well be incapable of what you want. Regards Oliver - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [RESEND] include/linux/slab.h: new KFREE() macro.
Description: new KFREE() macro to set the variable NULL after freeing it.
Signed-off-by: Amit Choudhary [EMAIL PROTECTED]
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 1ef822e..28da74c 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -75,6 +75,12 @@ void *__kzalloc(size_t, gfp_t);
void kfree(const void *);
unsigned int ksize(const void *);
+#define KFREE(x) \
+ do {\
+ kfree(x); \
+ x = NULL; \
+ } while(0)
+
/**
* kcalloc - allocate memory for an array. The memory is set to zero.
* @n: number of elements.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
I'm willing to do that - and I guess this means we can probably do this instead of walking the list of VMAs for the shared mapping, thereby hitting both anonymous and shared mappings with the same code? But for the get_user_pages() case there's no point, is there? The VMA and the virtual address is already available, so trying to find it again through RMAP doesn't much make sense. Users of get_user_pages() don't care about any other mappings (maybe ptrace does, I don't know) only about one single user mapping and one kernel mapping. So using flush_dcache_page() there is an overkill, trying to teach it about anonymous pages is not the real solution, flush_dcache_page() was never meant to be used on anything but file mapped pages. It's not actually. For flush_anon_page() we currently have to flush the user mapping and the kernel mapping. For flush_dcache_page(), it's exactly the same - we have to flush the kernel mapping and the user mapping. I was never advocating flush_anon_page(). I was suggesting a _new_ cache operation: flush_kernel_user_page(page, vma, virt_addr) which flushes the kernel mapping and the given user mapping. Just like flush_dcache_page() but without needing to find the user mapping(s). However the cache flushing in kmap/kunmap idea might be cleaner and better. Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] MTD driver for MMC cards
On Sunday 31 December 2006 13:32, Pierre Ossman wrote:
Arnd Bergmann wrote:
I'm a complete MTD noob, but what uses does the MTD layer have besides
JFFS2. If it's none, than this advantage isn't that big of a deal.
* It becomes possible to use MMC cards with jffs2 even with CONFIG_BLOCK
disabled, which can save a significant amount of kernel memory on
small machines that have an MMC slot but no other block device.
From what I've heard, JFFS2 is close to unusuable on the sizes of modern
SD/MMC cards. So I'd like to see some more use cases before I'm ready
to let this in.
There are multiple efforts in progress to get a jffs2 replacement. NAND
flash in embedded devices has the same size as it has on MMC card
potentially, so we will need one soon. David Woodhouse has pushed the
limit that jffs2 can reasonably used to 512MB, which is the size used
in the OLPC XO laptop. If there are ways to get beyond that (which I
find unlikely), there will be a hard limit 2GB or 4GB because of
limitations in the fs layout.
One promising effort for a replacement is Jörn's logfs
(http://wiki.laptop.org/go/Logfs), which should scale well to many
gigabytes. A driver based on MMC would be a nice development tool
for that, since it enables regular PCs as a debugging machine
instead of having to load test kernels onto an actual embedded
machine.
Another thing I have been thinking about was an MTD version of
fat16/fat32. There are a number of optimizations that you can
do for flash media, including:
- limiting the number of writes to the FAT
- erasing blocks when they are freed in the FS
- always writing full erase blocks if the erase block
size matches the cluster size
- optimize for wear leveling instead of avoiding
fragmentation
I read that the SD cards have some restrictions of how
the fat fs needs to be laid out on them, presumably to
make sure clusters are aligned with erase blocks.
Do you have any specific information on what SD actually
requires?
I still want to be sure that I'm on the right track with this driver
and did not make a conceptual mistake.
I can comment it from a MMC perspective, but the MTD stuff I will have to
assume is correct.
ok, that's fine. I've talked to a few MTD people about it already
and I understand much more about MTD than I do about MMC ;-)
@@ -616,6 +616,8 @@ static void mmc_decode_csd(struct mmc_ca
csd-r2w_factor = UNSTUFF_BITS(resp, 26, 3);
csd-write_blkbits = UNSTUFF_BITS(resp, 22, 4);
csd-write_partial = UNSTUFF_BITS(resp, 21, 1);
+ csd-erase_blksize = (UNSTUFF_BITS(resp, 37, 5) + 1) *
+ (UNSTUFF_BITS(resp, 42, 5) + 1);
} else {
/*
* We only understand CSD structure v1.1 and v1.2.
NAK. SD uses another format for erase blocks. See the simplified physical
spec.
ok, I'll have a look. I keep having trouble identifying the right
specifications (physical spec sounded like it was only about wiring
and electric properties, so I did not look at that). Maybe it would
be good if you could put pointers to the relevant documents into
your Wiki?
+/*
+ * transfer a block to/from the card. The block needs to be aligned
+ * to mtd-writesize. If we want to implement an mtd_writev method,
+ * this needs to use stream operations with an appropriate stop
+ * command as well.
+ */
+static int mmc_mtd_transfer_low(struct mmc_card *card, loff_t off, size_t
len,
+ size_t *retlen, u_char *buf, int write)
+{
+ struct scatterlist sg;
+ struct mmc_data data = {
+ .blksz = 1 card-csd.read_blkbits,
+ .blocks = len card-csd.read_blkbits,
First of all, you cannot assume that read_blkbits is a valid block
size when doing writes.
Right, I see. I introduced that bug when I merged parts of the read and
write paths.
Is it fair to assume that write_blkbits is always bigger than
read_blkbits, so that one can be used in both cases?
Secondly, the cards default in a block size of 512 bytes, so you need
to tell the card your desired block size during probe.
Ok.
+ .flags = write ? MMC_DATA_WRITE : MMC_DATA_READ,
+ .sg = sg,
+ .sg_len = 1,
+ };
+ struct mmc_command cmd = {
+ .arg = off,
+ .data = data,
+ .flags = MMC_RSP_R1 | MMC_CMD_ADTC,
+ .opcode = write ? MMC_WRITE_BLOCK : MMC_READ_SINGLE_BLOCK,
You set .blocks above, so I have to assume it can be more than 1.
So you need to change the opcodes accordingly.
+ };
+ struct mmc_request mrq = {
+ .cmd = cmd,
+ .data = data,
+ };
And it also means you need a stop command.
I tried to do multiple block access at first, but then took it out again.
If it turns out valuable to have these, I'll implement it properly later.
Does it make a difference performance-wise to do larger accesses?
+
+
2.6.20-rc2+: CFQ halving disk throughput.
Tejun Heo wrote: Everything seems fine in the dmesg. Performance degradation is probably some other issue in -rc kernel. I'm suspecting recently fixed block layer bug. If it's still the same in the next -rc, please report. In fact, it's CFQ. The PATA thing was a red herring. 2.6.20-rc2 and 3 give me ~ 24 MB/s from hdparm t /dev/hda while 2.6.20-rc1 and below give me ~ 50 MB/s. Jens: this is due to [PATCH] cfq-iosched: tighten allow merge criteria, 719d34027e1a186e46a3952e8a24bf91ecc33837: http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=719d34027e1a186e46a3952e8a24bf91ecc33837 If I revert that one, I have my 50 M/s back. config and dmesg attached in case they're useful. Rene # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20-rc3 # Mon Jan 1 15:04:04 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION=-local # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_TSC=y # CONFIG_HPET_TIMER is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_X86_UP_APIC is not set CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # # Firmware Drivers # CONFIG_EDD=y # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_3G_OPT is not set # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC000 CONFIG_ARCH_FLATMEM_ENABLE=y
Re: 2.6.20-rc2+: CFQ halving disk throughput.
Rene Herman wrote: In fact, it's CFQ. The PATA thing was a red herring. 2.6.20-rc2 and 3 give me ~ 24 MB/s from hdparm t /dev/hda while 2.6.20-rc1 and below give me ~ 50 MB/s. Jens: this is due to [PATCH] cfq-iosched: tighten allow merge criteria, 719d34027e1a186e46a3952e8a24bf91ecc33837: [EMAIL PROTECTED] bounces for me. Could one of the other recipients of parent message try to forward? Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Finding hardlinks
Hi! If user (or script) doesn't specify that flag, it doesn't help. I think the best solution for these filesystems would be either to add new syscall int is_hardlink(char *filename1, char *filename2) (but I know adding syscall bloat may be objectionable) it's also the wrong api; the filenames may have been changed under you just as you return from this call, so it really is a was_hardlink_at_some_point() as you specify it. If you make it work on fd's.. it has a chance at least. Yes, but it doesn't matter --- if the tree changes under cp -a command, no one guarantees you what you get. int fis_hardlink(int handle1, int handle 2); Is another possibility but it can't detect hardlinked symlinks. Ugh. Is it even legal to hardlink symlinks? Why it shoudln't be? It seems to work quite fine in Linux. Anyway, cp -a is not the only application that wants to do hardlink detection. I tested programs for ino_t collision (I intentionally injected it) and found that CP from coreutils 6.7 fails to copy directories but displays error messages (coreutils 5 work fine). MC and ARJ skip directories with colliding ino_t and pretend that operation completed successfuly. FTS library fails to walk directories returning FTS_DC error. Diffutils, find, grep fail to search directories with coliding inode numbers. Tar seems tolerant except incremental backup (which I didn't try). All programs except diff were tolerant to coliding ino_t on files. ino_t is no longer unique in many filesystems, it seems like quite serious data corruption possibility. Mikulas Pavel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
