Regression between 2.6.20 and 2.6.21-rc1: NCQ problem with ahci and Hitachi drive
Hello, I have and laptop with an ICH6M SATA Controller and an Hitachi hard drive. While it worked well using the ahci module and with NCQ enabled using Linux 2.6.20, it does not work anymore (hang at boot) with 2.6.21-rc* My drive is among those that were recently blacklisted (see lkml post [PATCH] libata: add NCQ blacklist entries from Silicon Image Windowsdriver) (Model Number: HTS541010G9SA00 and Firmware Revision: MBZOC60D) This blacklisting patch is in -mm now. So there is probably a drive related issue here, I'm just wondering why it just work flawlessly with a 2.6.20... Relevant part of kernel log: 2.6.20: [ 41.076963] SCSI subsystem initialized [ 41.083119] ACPI: PCI Interrupt :00:1f.2[B] - GSI 19 (level, low) - IRQ 19 [ 42.083637] ahci :00:1f.2: AHCI 0001. 32 slots 4 ports 1.5 Gbps 0x5 impl IDE mode [ 42.083695] ahci :00:1f.2: flags: 64bit ncq pm led slum part [ 42.083825] ata1: SATA max UDMA/133 cmd 0xF8872D00 ctl 0x0 bmdma 0x0 irq 19 [ 42.083938] ata2: SATA max UDMA/133 cmd 0xF8872D80 ctl 0x0 bmdma 0x0 irq 19 [ 42.084049] ata3: SATA max UDMA/133 cmd 0xF8872E00 ctl 0x0 bmdma 0x0 irq 19 [ 42.084165] ata4: SATA max UDMA/133 cmd 0xF8872E80 ctl 0x0 bmdma 0x0 irq 19 [ 42.084221] scsi0 : ahci [ 42.541356] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 42.542404] ata1.00: ATA-7, max UDMA/100, 195371568 sectors: LBA48 NCQ (depth 31/32) [ 42.542460] ata1.00: ata1: dev 0 multi count 0 [ 42.543731] ata1.00: configured for UDMA/100 [ 42.543781] scsi1 : ahci [ 42.846169] ata2: SATA link down (SStatus 0 SControl 0) [ 42.846223] scsi2 : ahci [ 43.148995] ata3: SATA link down (SStatus 0 SControl 300) [ 43.149049] scsi3 : ahci [ 43.451821] ata4: SATA link down (SStatus 0 SControl 0) [ 43.451957] scsi 0:0:0:0: Direct-Access ATA HTS541010G9SA00 MBZO PQ: 0 ANSI: 5 [ 43.487465] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB) [ 43.487544] sda: Write Protect is off [ 43.487810] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 43.488805] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB) [ 43.488879] sda: Write Protect is off [ 43.489462] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA 2.6.21-rc1: [ 14.580991] SCSI subsystem initialized [ 14.586026] ACPI: PCI Interrupt :00:1f.2[B] - GSI 19 (level, low) - IRQ 19 [ 15.586790] ahci :00:1f.2: AHCI 0001. 32 slots 4 ports 1.5 Gbps 0x5 impl IDE mode [ 15.586847] ahci :00:1f.2: flags: 64bit ncq pm led slum part [ 15.586974] ata1: SATA max UDMA/133 cmd 0xf8824d00 ctl 0x bmdma 0x irq 19 [ 15.587093] ata2: SATA max UDMA/133 cmd 0xf8824d80 ctl 0x bmdma 0x irq 19 [ 15.587211] ata3: SATA max UDMA/133 cmd 0xf8824e00 ctl 0x bmdma 0x irq 19 [ 15.587331] ata4: SATA max UDMA/133 cmd 0xf8824e80 ctl 0x bmdma 0x irq 19 [ 15.587394] scsi0 : ahci [ 16.044663] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 16.089475] ata1.00: ATA-7: HTS541010G9SA00, MBZOC60D, max UDMA/100 [ 16.089525] ata1.00: 195371568 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 16.091804] ata1.00: configured for UDMA/100 [ 16.091855] scsi1 : ahci [ 16.394567] ata2: SATA link down (SStatus 0 SControl 0) [ 16.394620] scsi2 : ahci [ 16.697494] ata3: SATA link down (SStatus 0 SControl 300) [ 16.697547] scsi3 : ahci [ 17.000422] ata4: SATA link down (SStatus 0 SControl 0) [ 17.000552] scsi 0:0:0:0: Direct-Access ATA HTS541010G9SA00 MBZO PQ: 0 ANSI: 5 [] [ 18.151756] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 18.151856] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB) [ 18.151911] sda: Write Protect is off [ 18.151977] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA [] [ 48.143940] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen [ 48.143999] ata1.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 4096 in [ 48.144000] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 48.446854] ata1: soft resetting port [ 48.601835] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 48.607218] ata1.00: configured for UDMA/100 [ 48.607272] ata1: EH complete [ 48.607355] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB) [ 48.607411] sda: Write Protect is off [ 48.607478] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 78.599605] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen [ 78.599659] ata1.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 4096 in [ 78.599661] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 78.902526] ata1: soft resetting port [ 79.057505] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [
[-mm patch] drivers/cpuidle/: make code static
On Fri, Mar 02, 2007 at 03:00:26AM -0800, Andrew Morton wrote:
...
Changes since 2.6.20-mm2:
...
git-acpi.patch
...
git trees
...
This patch makes the following needlessly global code static:
- driver.c: __cpuidle_find_driver()
- governor.c: __cpuidle_find_governor()
- ladder.c: struct ladder_governor
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/cpuidle/cpuidle.h |2 --
drivers/cpuidle/driver.c |2 +-
drivers/cpuidle/governor.c |2 +-
drivers/cpuidle/governors/ladder.c |2 +-
4 files changed, 3 insertions(+), 5 deletions(-)
--- linux-2.6.21-rc2-mm1/drivers/cpuidle/cpuidle.h.old 2007-03-04
20:42:29.0 +0100
+++ linux-2.6.21-rc2-mm1/drivers/cpuidle/cpuidle.h 2007-03-04
20:43:13.0 +0100
@@ -23,13 +23,11 @@
/* drivers */
extern int cpuidle_attach_driver(struct cpuidle_device *dev);
extern void cpuidle_detach_driver(struct cpuidle_device *dev);
-extern struct cpuidle_driver * __cpuidle_find_driver(const char *str);
extern int cpuidle_switch_driver(struct cpuidle_driver *drv);
/* governors */
extern int cpuidle_attach_governor(struct cpuidle_device *dev);
extern void cpuidle_detach_governor(struct cpuidle_device *dev);
-extern struct cpuidle_governor * __cpuidle_find_governor(const char *str);
extern int cpuidle_switch_governor(struct cpuidle_governor *gov);
/* sysfs */
--- linux-2.6.21-rc2-mm1/drivers/cpuidle/driver.c.old 2007-03-04
20:42:46.0 +0100
+++ linux-2.6.21-rc2-mm1/drivers/cpuidle/driver.c 2007-03-04
20:42:55.0 +0100
@@ -73,7 +73,7 @@
*
* Must be called with cpuidle_lock aquired.
*/
-struct cpuidle_driver * __cpuidle_find_driver(const char *str)
+static struct cpuidle_driver * __cpuidle_find_driver(const char *str)
{
struct cpuidle_driver *drv;
--- linux-2.6.21-rc2-mm1/drivers/cpuidle/governor.c.old 2007-03-04
20:43:22.0 +0100
+++ linux-2.6.21-rc2-mm1/drivers/cpuidle/governor.c 2007-03-04
20:43:29.0 +0100
@@ -72,7 +72,7 @@
*
* Must be called with cpuidle_lock aquired.
*/
-struct cpuidle_governor * __cpuidle_find_governor(const char *str)
+static struct cpuidle_governor * __cpuidle_find_governor(const char *str)
{
struct cpuidle_governor *gov;
--- linux-2.6.21-rc2-mm1/drivers/cpuidle/governors/ladder.c.old 2007-03-04
20:43:51.0 +0100
+++ linux-2.6.21-rc2-mm1/drivers/cpuidle/governors/ladder.c 2007-03-04
20:44:01.0 +0100
@@ -199,7 +199,7 @@
kfree(dev-governor_data);
}
-struct cpuidle_governor ladder_governor = {
+static struct cpuidle_governor ladder_governor = {
.name = ladder,
.init = ladder_init_device,
.exit = ladder_exit_device,
-
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/
[4/6] 2.6.21-rc2: known regressions
This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: Asus A8N-VM motherboard: framebuffer/console boot failure boot failure (ACPI related) References : http://lkml.org/lkml/2007/2/23/132 Submitter : Andrew Nelless [EMAIL PROTECTED] Caused-By : Len Brown [EMAIL PROTECTED] commit 7f8f97c3cc75d5783d0b45cf323dedf17684be19 Handled-By : Antonino A. Daplas [EMAIL PROTECTED] Status : problem is being debugged Subject: LCD is dimmed (ibm-acpi related) References : http://lkml.org/lkml/2007/2/25/206 Submitter : Jiri Kosina [EMAIL PROTECTED] Caused-By : Richard Purdie [EMAIL PROTECTED] commit 994efacdf9a087b52f71e620b58dfa526b0cf928 Handled-By : Jiri Kosina [EMAIL PROTECTED] Richard Purdie [EMAIL PROTECTED] Henrique de Moraes Holschuh [EMAIL PROTECTED] Status : patches are being discussed Subject: no backlight on radeon References : http://lkml.org/lkml/2007/2/19/1 Submitter : Yaroslav Halchenko [EMAIL PROTECTED] Alex Romosan [EMAIL PROTECTED] David Miller [EMAIL PROTECTED] Caused-By : James Simmons [EMAIL PROTECTED] commit e0e34ef7f02915cfe50e501e9f32c24217177a96 Handled-By : Richard Purdie [EMAIL PROTECTED] James Simmons [EMAIL PROTECTED] Henrique de Moraes Holschuh [EMAIL PROTECTED] Status : problem is being discussed Subject: nvidiafb broken References : http://lkml.org/lkml/2007/2/24/36 Submitter : Andreas Schwab [EMAIL PROTECTED] Caused-By : Richard Purdie [EMAIL PROTECTED] commit 599a52d12629394236d785615808845823875868 Handled-By : Richard Purdie [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/2/26/43 Status : patch available - 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/
[3/6] 2.6.21-rc2: known regressions
This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: NCQ problem with ahci and Hitachi drive References : http://lkml.org/lkml/2007/3/4/178 Submitter : Mathieu Bérard [EMAIL PROTECTED] Status : unknown Subject: kernels fail to boot with drives on ATIIXP controller References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 Submitter : Michal Jaegermann [EMAIL PROTECTED] Status : unknown Subject: libata: PATA UDMA/100 configured as UDMA/33 References : http://lkml.org/lkml/2007/2/20/294 http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html Submitter : Fabio Comolli [EMAIL PROTECTED] Handled-By : Tejun Heo [EMAIL PROTECTED] Status : problem is being discussed Subject: SATA_ACPI errors during kernel boot References : http://bugzilla.kernel.org/show_bug.cgi?id=8080 http://bugzilla.kernel.org/show_bug.cgi?id=8046 http://bugzilla.kernel.org/show_bug.cgi?id=8095 http://lkml.org/lkml/2007/2/22/159 Submitter : Janosch Machowinski [EMAIL PROTECTED] Lukas Hejtmanek [EMAIL PROTECTED] Meelis Roos [EMAIL PROTECTED] Olivier Mondoloni [EMAIL PROTECTED] Handled-By : Thomas Renninger [EMAIL PROTECTED] Tejun Heo [EMAIL PROTECTED] Robert Moore [EMAIL PROTECTED] Status : problem is being debugged - 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: Regression between 2.6.20 and 2.6.21-rc1: NCQ problem with ahci and Hitachi drive
Hello, Mathieu. Mathieu Bérard wrote: Hello, I have and laptop with an ICH6M SATA Controller and an Hitachi hard drive. While it worked well using the ahci module and with NCQ enabled using Linux 2.6.20, it does not work anymore (hang at boot) with 2.6.21-rc* My drive is among those that were recently blacklisted (see lkml post [PATCH] libata: add NCQ blacklist entries from Silicon Image Windowsdriver) (Model Number: HTS541010G9SA00 and Firmware Revision: MBZOC60D) This blacklisting patch is in -mm now. So there is probably a drive related issue here, I'm just wondering why it just work flawlessly with a 2.6.20... Relevant part of kernel log: [ 16.044663] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 16.089475] ata1.00: ATA-7: HTS541010G9SA00, MBZOC60D, max UDMA/100 [ 16.089525] ata1.00: 195371568 sectors, multi 0: LBA48 NCQ (depth 31/32) No, your drive isn't blacklisted yet. NCQ is still being enabled. [ 16.091804] ata1.00: configured for UDMA/100 [ 18.151756] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA [--snip--] [ 18.151856] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB) [ 18.151911] sda: Write Protect is off [ 18.151977] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA [] [ 48.143940] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen [ 48.143999] ata1.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 4096 in [ 48.144000] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) It looks like IRQ isn't getting through. Does giving acpi=off kernel parameter make any difference? -- 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: [PATCH] ext3: dirindex error pointer issues
On Mar 04, 2007 17:18 +0300, Dmitriy Monakhov wrote:
- ext3_dx_find_entry() exit with out setting proper error pointer
- do_split() exit with out setting proper error pointer
it is realy painful because many callers contain folowing code:
de = do_split(handle,dir, bh, frame, hinfo, retval);
if (!(de))
return retval;
WOW retval wasn't changed by do_split(), so caller failed
but return SUCCESS :)
- Rearrange do_split() error path. Current error path is realy ugly, all
this up and down jump stuff doesn't make code easy to understand.
Signed-off-by: Monakhov Dmitriy [EMAIL PROTECTED]
---
fs/ext3/namei.c | 26 +++---
fs/ext4/namei.c | 26 +++---
2 files changed, 30 insertions(+), 22 deletions(-)
diff --git a/fs/ext3/namei.c b/fs/ext3/namei.c
index 49159f1..1a52586 100644
--- a/fs/ext3/namei.c
+++ b/fs/ext3/namei.c
@@ -969,6 +969,7 @@ static struct buffer_head * ext3_dx_find_entry(struct
dentry *dentry,
(blockEXT3_BLOCK_SIZE_BITS(sb))
+((char *)de - bh-b_data))) {
brelse (bh);
+ *err = ERR_BAD_DX_DIR;
goto errout;
}
*res_dir = de;
I have no objection to this change (by principle of least surprise) but
I don't know if it fixes a real problem. The one caller of this function
treats ERR_BAD_DX_DIR the same as bh == NULL.
@@ -1134,9 +1135,9 @@ static struct ext3_dir_entry_2 *do_split(handle_t
*handle, struct inode *dir,
char *data1 = (*bh)-b_data, *data2;
unsigned split;
struct ext3_dir_entry_2 *de = NULL, *de2;
- int err;
+ int err = 0;
- bh2 = ext3_append (handle, dir, newblock, error);
+ bh2 = ext3_append (handle, dir, newblock, err);
Why don't we just remove err entirely and use *error to avoid any risk
of setting err and not returning it in error? Also reduces stack usage
that tiny little bit.
In ext3_dx_add_entry() it appears like we should goto journal_error
to report an error after the failed call to do_split(), instead of just
goto cleanup so that we report an error in the filesystem. Not 100%
sure of this.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
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: [6/6] 2.6.21-rc2: known regressions
On Sun, Mar 04, 2007 at 06:07:25PM -0800, David Miller wrote: From: Adrian Bunk [EMAIL PROTECTED] Date: Mon, 5 Mar 2007 02:50:45 +0100 Subject: sparc64 compile error due to GENERIC_ISA_DMA removal References : http://bugzilla.kernel.org/show_bug.cgi?id=8097 Submitter : Horst H. von Brand [EMAIL PROTECTED] Caused-By : David S. Miller [EMAIL PROTECTED] commit 1b51d3a08b6c80a1e47d4c579c41abbe56cd3c44 Status : unknown Fixed in current GIT. commit 74bd7d093b8e87f35eaf3b14459b96a0e20d1d10 Author: David S. Miller [EMAIL PROTECTED] Date: Wed Feb 28 13:09:34 2007 -0800 [SPARC64]: Fix parport_pc build. Signed-off-by: David S. Miller [EMAIL PROTECTED] Horst's problem is with the floppy driver and claim_dma_lock/release_dma_lock in include/asm-sparc64/dma.h . cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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: [6/6] 2.6.21-rc2: known regressions
From: Adrian Bunk [EMAIL PROTECTED] Date: Mon, 5 Mar 2007 03:26:02 +0100 On Sun, Mar 04, 2007 at 06:07:25PM -0800, David Miller wrote: From: Adrian Bunk [EMAIL PROTECTED] Date: Mon, 5 Mar 2007 02:50:45 +0100 Subject: sparc64 compile error due to GENERIC_ISA_DMA removal References : http://bugzilla.kernel.org/show_bug.cgi?id=8097 Submitter : Horst H. von Brand [EMAIL PROTECTED] Caused-By : David S. Miller [EMAIL PROTECTED] commit 1b51d3a08b6c80a1e47d4c579c41abbe56cd3c44 Status : unknown Fixed in current GIT. commit 74bd7d093b8e87f35eaf3b14459b96a0e20d1d10 Author: David S. Miller [EMAIL PROTECTED] Date: Wed Feb 28 13:09:34 2007 -0800 [SPARC64]: Fix parport_pc build. Signed-off-by: David S. Miller [EMAIL PROTECTED] Horst's problem is with the floppy driver and claim_dma_lock/release_dma_lock in include/asm-sparc64/dma.h . Thanks for the clarification, I was thinking of the parport problem reported by Meelis Roos. I'll look into 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/
[ANNOUNCE] GIT 1.5.0.3
The latest maintenance release GIT 1.5.0.3 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.0.3.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.0.3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.0.3.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.0.3-1.$arch.rpm (RPM)
GIT v1.5.0.3 Release Notes
==
Fixes since v1.5.0.2
* Bugfixes
- 'git.el' honors the commit coding system from the configuration.
- 'blameview' in contrib/ correctly digs deeper when a line is
clicked.
- 'http-push' correctly makes sure the remote side has leading
path. Earlier it started in the middle of the path, and
incorrectly.
- 'git-merge' did not exit with non-zero status when the
working tree was dirty and cannot fast forward. It does
now.
- 'cvsexportcommit' does not lose yet-to-be-used message file.
- int-vs-size_t typefix when running combined diff on files
over 2GB long.
- 'git apply --whitespace=strip' should not touch unmodified
lines.
- 'git-mailinfo' choke when a logical header line was too long.
- 'git show A..B' did not error out. Negative ref (not A in
this example) does not make sense for the purpose of the
command, so now it errors out.
- 'git fmt-merge-msg --file' without file parameter did not
correctly error out.
- 'git archimport' barfed upon encountering a commit without
summary.
- 'git index-pack' did not protect itself from getting a short
read out of pread(2).
- 'git http-push' had a few buffer overruns.
- Build dependency fixes to rebuild fetch.o when other headers
change.
* Documentation updates
- user-manual updates.
- Options to 'git remote add' were described insufficiently.
- Configuration format.suffix was not documented.
- Other formatting and spelling fixes.
Shortlog since v1.5.0.2
---
Alexandre Julliard (1):
git.el: Set the default commit coding system from the repository config.
Aneesh Kumar K.V (1):
blameview: Fix the browse behavior in blameview
Christian Schlotter (1):
Documentation: Correct minor typo in git-add documentation.
Eygene Ryabinkin (2):
http-push.c::lock_remote(): validate all remote refs.
Another memory overrun in http-push.c
Gerrit Pape (2):
git-cvsexportcommit: don't cleanup .msg if not yet committed to cvs.
Fix quoting in update hook template
J. Bruce Fields (6):
Documentation: mention module option to git-cvsimport
user-manual: reset to ORIG_HEAD not HEAD to undo merge
user-manual: ensure generated manual references stylesheet
user-manual: insert earlier of mention content-addressable architecture
user-manual: how to replace commits older than most recent
user-manual: more detailed merge discussion
Jim Meyering (1):
diff --cc: integer overflow given a 2GB-or-larger file
Johannes Schindelin (3):
fetch.o depends on the headers, too.
builtin-archive: use RUN_SETUP
Document the config variable format.suffix
Junio C Hamano (5):
git-apply: do not fix whitespaces on context lines.
Documentation: git-remote add [-t branch] [-m branch] [-f] name url
Start preparing Release Notes for 1.5.0.3
git-merge: fail correctly when we cannot fast forward.
GIT 1.5.0.3
Linus Torvalds (2):
mailinfo: do not get confused with logical lines that are too long.
git-show: Reject native ref
Matthias Kestenholz (1):
Fix git-gc usage note
Michael Coleman (2):
Fix minor typos/grammar in user-manual.txt
builtin-fmt-merge-msg: fix bugs in --file option
Michael Poole (1):
Correct ordering in git-cvsimport's option documentation
Paolo Bonzini (1):
git-archimport: support empty summaries, put summary on a single line.
Ramsay Allan Jones (5):
Fix a label defined but unreferenced warning.
Fix an implicit function definition warning.
Fix some comparison is always true/false warnings.
Fix a pointer type missmatch warning.
Unset NO_C99_FORMAT on Cygwin.
Sergey Vlasov (3):
Documentation/build-docdep.perl: Fix dependencies for included asciidoc
files
Documentation/git-quiltimport.txt: Fix labeled list formatting
Documentation/git-send-email.txt: Fix labeled list formatting
Shawn O. Pearce (1):
index-pack: Loop over pread until data loading is complete.
Theodore Ts'o (1):
Fix git-show man page formatting in the EXAMPLES section
Uwe Kleine-König (1):
Include config.mak in doc/Makefile
Yasushi SHOJI (1):
glossary: Add definitions for dangling and unreachable objects
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[PATCH/RFC] implement __attribute_discard_text/data__ and use it to leave out PM functions if !CONFIG_PM
Hello, all.
This patch is the result from the following discussion.
http://thread.gmane.org/gmane.linux.ide/16475
The problem is that CONFIG_PM affects a lot of low level drivers and
scattering CONFIG_PM all over the place is too ugly. This patch...
* implements __attribute_discard_text__ and __attribute_discard_data__
(not implemented for modules yet, only for built-ins)
* uses them to implement __pm and __pmdata markers
* convert libata midlayer and ahci to use it instead of CONFIG_PM
__attribute_discard_text/data__ puts the marked symbols in separate
sections which are located from VMA 0 and discarded when generating
the final image. It's similar to putting those into /DISCARD/ section
but won't complain even if the discarded symbols are referenced by
active sections. As the discard sections are located from VMA 0,
actually dereferencing such symbols will result in OOPS.
This trick certainly makes LLDs cleaner but there are also some
downsides, so here are the cons.
* Cannot depend on the compiler to detect illegal dereferences to
discarded symbols. We probably can do this using sparse.
* Cannot use the compiler to detect unused but unmarked symbols. This
also probably can be done with sparse.
* EXPORT_SYMBOL() is nullified, so it will take extra bytes for
each symbol marked with __pm. (insignificant)
* Implementation involves modifying kernel image, module build process
and possibly sparse. It might be too expensive to achieve device
driver prettiness, but there are a lot of device drivers out there
and a lot of CONFIG_PM's to be added. Also, discard attributes can
be used for other purposes too.
Any better ideas? Comments?
DO NOT APPLY.
diff --git a/arch/i386/Makefile b/arch/i386/Makefile
index bd28f9f..2806dfe 100644
--- a/arch/i386/Makefile
+++ b/arch/i386/Makefile
@@ -25,7 +25,7 @@ CC := $(CC) -m32
endif
LDFLAGS:= -m elf_i386
-OBJCOPYFLAGS := -O binary -R .note -R .comment -S
+OBJCOPYFLAGS := -O binary -R .note -R .comment -R .discard -S
ifdef CONFIG_RELOCATABLE
LDFLAGS_vmlinux := --emit-relocs
endif
diff --git a/arch/i386/kernel/vmlinux.lds.S b/arch/i386/kernel/vmlinux.lds.S
index ca51610..69b18c6 100644
--- a/arch/i386/kernel/vmlinux.lds.S
+++ b/arch/i386/kernel/vmlinux.lds.S
@@ -32,6 +32,7 @@ PHDRS {
text PT_LOAD FLAGS(5); /* R_E */
data PT_LOAD FLAGS(7); /* RWE */
note PT_NOTE FLAGS(4); /* R__ */
+ QUIET_DISCARD_PHDR
}
SECTIONS
{
@@ -217,6 +218,8 @@ SECTIONS
}
/* Sections to be discarded */
+ QUIET_DISCARD
+
/DISCARD/ : {
*(.exitcall.exit)
}
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 43cc43d..bfb0135 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -219,12 +219,10 @@ static void ahci_thaw(struct ata_port *ap);
static void ahci_error_handler(struct ata_port *ap);
static void ahci_vt8251_error_handler(struct ata_port *ap);
static void ahci_post_internal_cmd(struct ata_queued_cmd *qc);
-#ifdef CONFIG_PM
static int ahci_port_suspend(struct ata_port *ap, pm_message_t mesg);
static int ahci_port_resume(struct ata_port *ap);
static int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg);
static int ahci_pci_device_resume(struct pci_dev *pdev);
-#endif
static struct scsi_host_template ahci_sht = {
.module = THIS_MODULE,
@@ -243,10 +241,8 @@ static struct scsi_host_template ahci_sht = {
.slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
-#ifdef CONFIG_PM
.suspend= ata_scsi_device_suspend,
.resume = ata_scsi_device_resume,
-#endif
};
static const struct ata_port_operations ahci_ops = {
@@ -275,10 +271,8 @@ static const struct ata_port_operations ahci_ops = {
.error_handler = ahci_error_handler,
.post_internal_cmd = ahci_post_internal_cmd,
-#ifdef CONFIG_PM
.port_suspend = ahci_port_suspend,
.port_resume= ahci_port_resume,
-#endif
.port_start = ahci_port_start,
.port_stop = ahci_port_stop,
@@ -310,10 +304,8 @@ static const struct ata_port_operations ahci_vt8251_ops = {
.error_handler = ahci_vt8251_error_handler,
.post_internal_cmd = ahci_post_internal_cmd,
-#ifdef CONFIG_PM
.port_suspend = ahci_port_suspend,
.port_resume= ahci_port_resume,
-#endif
.port_start = ahci_port_start,
.port_stop = ahci_port_stop,
@@ -444,10 +436,8 @@ static struct pci_driver ahci_pci_driver = {
.id_table = ahci_pci_tbl,
.probe = ahci_init_one,
.remove = ata_pci_remove_one,
-#ifdef CONFIG_PM
.suspend= ahci_pci_device_suspend,
Re: CK804 SATA Errors (still got them)
On Sunday 04 March 2007 23:25, Robert Hancock wrote: Alistair John Strachan wrote: Can you try reverting commit 721449bf0d51213fe3abf0ac3e3561ef9ea7827a (link below) and see what effect that has? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi t;h =721449bf0d51213fe3abf0ac3e3561ef9ea7827a Obviously, I'll let you know if it happens again, but I've reverted this commit and transferred 22.5GB over 45 minutes onto a RAID5 with 4 HDs on an NVIDIA sata controller, and this error hasn't appeared. So I'm inclined to (very unscientifically) say that this brings it back to 2.6.20's level of stability. Interesting. Can you try un-reverting that patch, and applying this one? The reading of the status register is something that was part of the original NVidia code, which I'm not really sure why is there. Given that reading the status register clears the drive's interrupt status, that might be causing some wierd interaction with the ADMA controller. Also, I added in a printk for cases where notifiers are triggered but the command doesn't indicate completion - if you still get problems, let me know if you see that message. Didn't take long to observe the problem again, so I'm guessing that this isn't it. I was definitely using a kernel compiled with your patch: [EMAIL PROTECTED]:~$ uname -v #1 SMP Sun Mar 4 23:39:56 GMT 2007 I got the following in dmesg: ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 status 0x500 next cpb count 0x0 next cpb idx 0x0 ata1: CPB 0: ctl_flags 0xd, resp_flags 0x1 ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd c8/00:08:37:77:61/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: soft resetting port ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: configured for UDMA/133 ata1: EH complete SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA Your debugging message did not appear in dmesg, however. -- 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: 2.6.21-rc2-mm1 -- kernel/sched.c:3384: error: 'struct rq' has no member named 'in_nohz_recently'
Ah, I see this was already reported. Sorry. My query at marc.theaimsgroup.com didn't find the previous report. I just stumbled onto it while browsing for other information. Miles - 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][patch] dynamic resizing dentry hash using RCU
From: Nick Piggin [EMAIL PROTECTED]
Date: Fri, 23 Feb 2007 16:37:43 +0100
So I introduce a new method for resizing hash tables with RCU, and apply
that to the dentry hash.
Thanks for doing this work Nick. I'm going to take your ideas
and apply them to an ipv4 routing cache dynamic growth patch I
worked on a while ago.
One minor nit:
+struct dentry_hash {
+ unsigned int shift;
+ unsigned long mask;
+ struct hlist_head *table;
+};
I don't see any reason to make 'mask' an unsigned long
and this makes this structure take up 8 bytes more than
necessary on 64-bit.
-
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.21-rc2-mm1 -- WARNING: pcmcia_access_configuration_register [drivers/ssb/ssb.ko] undefined!
WARNING: pcmcia_access_configuration_register [drivers/ssb/ssb.ko] undefined! WARNING: pccard_parse_tuple [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: pcmcia_register_driver [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: pccard_get_tuple_data [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: pcmcia_request_configuration [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: pcmcia_request_window [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: pccard_get_first_tuple [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: pcmcia_release_window [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: pcmcia_map_mem_page [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: pcmcia_unregister_driver [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: pcmcia_disable_device [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! make[1]: *** [__modpost] Error 1 # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set CONFIG_BCM43XX_MAC80211=m CONFIG_BCM43XX_MAC80211_PCI=y CONFIG_BCM43XX_MAC80211_PCMCIA=y CONFIG_BCM43XX_MAC80211_DEBUG=y CONFIG_BCM43XX_MAC80211_DMA=y CONFIG_BCM43XX_MAC80211_PIO=y CONFIG_BCM43XX_MAC80211_DMA_AND_PIO_MODE=y # CONFIG_BCM43XX_MAC80211_DMA_MODE is not set # CONFIG_BCM43XX_MAC80211_PIO_MODE is not set # CONFIG_RT2X00 is not set # CONFIG_ADM8211 is not set # CONFIG_P54_COMMON is not set # CONFIG_ZD1211RW_MAC80211 is not set # CONFIG_RTL818X is not set # CONFIG_RTL8187 is not set CONFIG_NET_WIRELESS=y CONFIG_MAC80211=m CONFIG_MAC80211_LEDS=y CONFIG_MAC80211_DEBUG=y CONFIG_MAC80211_VERBOSE_DEBUG=y CONFIG_MAC80211_LOWTX_FRAME_DUMP=y CONFIG_TKIP_DEBUG=y CONFIG_MAC80211_DEBUG_COUNTERS=y CONFIG_HOSTAPD_WPA_TESTING=y CONFIG_MAC80211_IBSS_DEBUG=y CONFIG_MAC80211_VERBOSE_PS_DEBUG=y # CONFIG_IEEE80211 is not set CONFIG_WIRELESS_EXT=y CONFIG_CFG80211=y CONFIG_CFG80211_WEXT_COMPAT=y CONFIG_NL80211=y - 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] Fixes and cleanups for earlyprintk aka boot console.
Gerd Hoffmann writes: This patch fixes the console selection code to *not* consider a boot console a full-featured one, so the first non-boot console registering will become the default console instead. This way the unregister call for the boot console in the register_console() function actually triggers and the handover from the boot console to the real console device works smoothly. Added a printk for the handover, so you know which console device the output goes to when the boot console stops printing messages. You have removed functionality that is useful for debugging, that 3 architectures had, namely a way to keep using the early boot console and not replace it with a console that comes later, using a kernel command line option. Perhaps you could provide a way to do that in your patch. Paul. - 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][patch] dynamic resizing dentry hash using RCU
On Sun, Mar 04, 2007 at 08:11:42PM -0800, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Fri, 23 Feb 2007 16:37:43 +0100
So I introduce a new method for resizing hash tables with RCU, and apply
that to the dentry hash.
Thanks for doing this work Nick. I'm going to take your ideas
and apply them to an ipv4 routing cache dynamic growth patch I
worked on a while ago.
Sounds great, I would be happy to help review it. If we can create a
bit of common infrastructure, the dcache conversion might become a bit
more palatable and we could look at other things like the inode hash
as well.
One minor nit:
+struct dentry_hash {
+ unsigned int shift;
+ unsigned long mask;
+ struct hlist_head *table;
+};
I don't see any reason to make 'mask' an unsigned long
and this makes this structure take up 8 bytes more than
necessary on 64-bit.
You're right, the mask is currently just an int, so my patch should
not be messing with that. Thanks.
The other thing you'll have to be careful of when looking at doing
an implementation, is that I think I forgot to use the RCU accessors
(rcu_assign_pointer, rcu_dereference) when assigning and loading
the new/old hash table pointers.
-
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/
[BUG} usb regression in 2.6.21-rc2-git3
Adrian Bunk wrote: This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree. Here's another one for Greg: I have a Targus USB 1.1 dock, basically a hub with built-in serial, parallel, PS/2 KB, PS/2 Mouse, and extra USB ports. Simply connecting, and then disconnecting it causes an oops with 2.6.21-rc2: Mar 4 23:29:51 silvy kernel: usb 4-2: new full speed USB device using uhci_hcd and address 2 Mar 4 23:29:51 silvy kernel: usb 4-2: configuration #1 chosen from 1 choice Mar 4 23:29:51 silvy kernel: hub 4-2:1.0: USB hub found Mar 4 23:29:51 silvy kernel: hub 4-2:1.0: 5 ports detected Mar 4 23:29:52 silvy kernel: usb 4-2.3: new full speed USB device using uhci_hcd and address 3 Mar 4 23:29:52 silvy kernel: usb 4-2.3: configuration #1 chosen from 1 choice Mar 4 23:29:52 silvy kernel: input: MTC PS/2 to USB converter as /class/input/input9 Mar 4 23:29:52 silvy kernel: input: USB HID v1.10 Keyboard [MTC PS/2 to USB converter] on usb-:00:1d.3-2.3 Mar 4 23:29:52 silvy kernel: input: MTC PS/2 to USB converter as /class/input/input10 Mar 4 23:29:52 silvy kernel: input: USB HID v1.10 Mouse [MTC PS/2 to USB converter] on usb-:00:1d.3-2.3 Mar 4 23:29:52 silvy kernel: usb 4-2.5: new full speed USB device using uhci_hcd and address 4 Mar 4 23:29:52 silvy kernel: usb 4-2.5: configuration #1 chosen from 1 choice Mar 4 23:29:52 silvy kernel: usb 4-2.4: new full speed USB device using uhci_hcd and address 5 Mar 4 23:29:52 silvy kernel: usb 4-2.4: configuration #1 chosen from 1 choice Mar 4 23:29:52 silvy kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 4 if 0 alt 1 proto 2 vid 0x0711 pid 0x0300 Mar 4 23:29:52 silvy kernel: usbcore: registered new interface driver usblp Mar 4 23:29:52 silvy kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver Mar 4 23:29:52 silvy kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for MCT U232 Mar 4 23:29:52 silvy kernel: mct_u232 4-2.4:1.0: MCT U232 converter detected Mar 4 23:29:52 silvy kernel: usb-serial ttyUSB0: Error registering port device, continuing Mar 4 23:29:52 silvy kernel: usbcore: registered new interface driver mct_u232 Mar 4 23:29:52 silvy kernel: drivers/usb/serial/mct_u232.c: Magic Control Technology USB-RS232 converter driver z2.0 Mar 4 23:29:57 silvy kernel: usb 4-2: USB disconnect, address 2 Mar 4 23:29:57 silvy kernel: usb 4-2.3: USB disconnect, address 3 Mar 4 23:29:57 silvy kernel: usb 4-2.4: USB disconnect, address 5 Mar 4 23:29:57 silvy kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 000c Mar 4 23:29:57 silvy kernel: printing eip: Mar 4 23:29:57 silvy kernel: c027c251 Mar 4 23:29:57 silvy kernel: *pde = Mar 4 23:29:57 silvy kernel: Oops: [#1] Mar 4 23:29:57 silvy kernel: PREEMPT Mar 4 23:29:57 silvy kernel: Modules linked in: mct_u232 usblp radeon drm nfsd exportfs lockd nfs_acl sunrpc acpi_cpufreq cpufreq_ondemand cpufreq_powersave cpufreq_userspace cpufreq_stats freq_table cpufreq_conservative ac fan button thermal video battery container processor rfcomm l2cap bluetooth cfq_iosched deflate zlib_deflate twofish twofish_common serpent blowfish des cbc ecb blkcipher aes xcbc sha256 sha1 crypto_null af_key af_packet sbp2 usbhid hid pl2303 usbserial mousedev snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss pcmcia snd_pcm snd_timer snd ipw2200 soundcore ieee80211 ieee80211_crypt pcspkr psmouse serio_raw b44 ahci ohci1394 ieee1394 snd_page_alloc sdhci mmc_core firmware_class yenta_socket rsrc_nonstatic pcmcia_core mii intel_agp ehci_hcd uhci_hcd usbcore agpgart sg sr_mod cdrom unix Mar 4 23:29:57 silvy kernel: CPU:0 Mar 4 23:29:57 silvy kernel: EIP:0060:[klist_del+6/69]Not tainted VLI Mar 4 23:29:57 silvy kernel: EFLAGS: 00010286 (2.6.21-rc2-git3 #5) Mar 4 23:29:57 silvy kernel: EIP is at klist_del+0x6/0x45 Mar 4 23:29:57 silvy kernel: eax: ebx: f619f278 ecx: 0001 edx: f66873c8 Mar 4 23:29:57 silvy kernel: esi: f619f288 edi: f66873c0 ebp: f619f618 esp: f742fe24 Mar 4 23:29:57 silvy kernel: ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Mar 4 23:29:57 silvy kernel: Process khubd (pid: 1970, ti=f742e000 task=f7c20070 task.ti=f742e000) Mar 4 23:29:57 silvy kernel: Stack: f619f278 0001 c01fb571 f619f278 0001 f66873c0 c01fb6f2 Mar 4 23:29:57 silvy kernel:f66873c0 f8a05d0e fffe f6146340 f66873c0 f66873c0 f66873f4 f8a05c8e Mar 4 23:29:57 silvy kernel:f66873c0 f619f618 c01aafd5 0202 f619f200 f66873c0 f619f200 Mar 4 23:29:57 silvy kernel: Call Trace: Mar 4 23:29:57 silvy kernel: [device_del+21/398] device_del+0x15/0x18e Mar 4 23:29:57 silvy kernel: [device_unregister+8/16] device_unregister+0x8/0x10 Mar 4 23:29:57 silvy kernel: [f8a05d0e] destroy_serial+0x80/0xcc [usbserial] Mar 4 23:29:57 silvy kernel: [f8a05c8e]
Re: [IPW3945] Can't load microcode
On 3/4/07, Patrick Ale [EMAIL PROTECTED] wrote: ieee80211_crypt: registered algorithm 'NULL' ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation [EMAIL PROTECTED] ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0d ipw3945: Copyright(c) 2003-2006 Intel Corporation ACPI: PCI Interrupt :05:00.0[A] - GSI 18 (level, low) - IRQ 22 PCI: Setting latency timer of device :05:00.0 to 64 ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection ipw3945: ipw3945.ucode load failed: Reason -2 ipw3945: Could not read microcode: -2 ipw3945: probe of :05:00.0 failed with error -2 Error -2 is No such file or directory. Maybe it expects the firmware to be somewhere other than /lib/firmware or your driver and firmware versions don't match. Try adding some debug printk()s around the request_firmware() call in the driver. If you're using out of tree drivers the error should be reported to Intel rather than this list. Lee - 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/
[BUG] sdhci regression in 2.6.21-rc2
Another regression, for Pierre Ossman this time. My syslog gets spammed like this (below) on suspend/resume (to RAM) cycles. Worked fine, without all of the noise, in all previous kernels up to 2.6.20+. Mar 4 23:28:45 silvy logger: suspending Mar 4 23:29:09 silvy kernel: Stopping tasks ... done. Mar 4 23:29:09 silvy kernel: Suspending console(s) Mar 4 23:29:09 silvy kernel: pl2303 5-1.3:1.0: no suspend for driver pl2303? Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :03:01.2 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :03:00.0 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :00:1f.2 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :00:1e.2 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :00:1d.7 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :00:1d.3 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :00:1d.2 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :00:1d.1 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :00:1d.0 disabled Mar 4 23:29:09 silvy kernel: Intel machine check architecture supported. Mar 4 23:29:09 silvy kernel: Intel machine check reporting enabled on CPU#0. Mar 4 23:29:09 silvy kernel: Back to C! Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:01.0 at offset 7 (was 2000d0d0, writing d0d0) Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:01.0 at offset 3 (was 1, writing 10010) Mar 4 23:29:09 silvy kernel: PCI: Setting latency timer of device :00:01.0 to 64 Mar 4 23:29:09 silvy kernel: ACPI: PCI Interrupt :00:1d.0[A] - GSI 16 (level, low) - IRQ 16 Mar 4 23:29:09 silvy kernel: PCI: Setting latency timer of device :00:1d.0 to 64 Mar 4 23:29:09 silvy kernel: usb usb1: root hub lost power or was reset Mar 4 23:29:09 silvy kernel: PCI: Enabling device :00:1d.1 ( - 0001) Mar 4 23:29:09 silvy kernel: ACPI: PCI Interrupt :00:1d.1[B] - GSI 17 (level, low) - IRQ 18 Mar 4 23:29:09 silvy kernel: PCI: Setting latency timer of device :00:1d.1 to 64 Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:1d.1 at offset f (was 200, writing 20a) Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:1d.1 at offset 8 (was 1, writing bf61) Mar 4 23:29:09 silvy kernel: usb usb2: root hub lost power or was reset Mar 4 23:29:09 silvy kernel: PCI: Enabling device :00:1d.2 ( - 0001) Mar 4 23:29:09 silvy kernel: ACPI: PCI Interrupt :00:1d.2[C] - GSI 18 (level, low) - IRQ 19 Mar 4 23:29:09 silvy kernel: PCI: Setting latency timer of device :00:1d.2 to 64 Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:1d.2 at offset f (was 300, writing 309) Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:1d.2 at offset 8 (was 1, writing bf41) Mar 4 23:29:09 silvy kernel: usb usb3: root hub lost power or was reset Mar 4 23:29:09 silvy kernel: PCI: Enabling device :00:1d.3 ( - 0001) Mar 4 23:29:09 silvy kernel: ACPI: PCI Interrupt :00:1d.3[D] - GSI 19 (level, low) - IRQ 17 Mar 4 23:29:09 silvy kernel: PCI: Setting latency timer of device :00:1d.3 to 64 Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:1d.3 at offset f (was 400, writing 407) Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:1d.3 at offset 8 (was 1, writing bf21) Mar 4 23:29:09 silvy kernel: usb usb4: root hub lost power or was reset Mar 4 23:29:09 silvy kernel: mmc0: Got command interrupt even though no command operation was in progress. Mar 4 23:29:09 silvy kernel: sdhci: == REGISTER DUMP == Mar 4 23:29:09 silvy kernel: sdhci: Sys addr: 0x | Version: 0x Mar 4 23:29:09 silvy kernel: sdhci: Blk size: 0x | Blk cnt: 0x Mar 4 23:29:09 silvy kernel: sdhci: Argument: 0x | Trn mode: 0x Mar 4 23:29:09 silvy kernel: sdhci: Present: 0x | Host ctl: 0x00ff Mar 4 23:29:09 silvy kernel: sdhci: Power:0x00ff | Blk gap: 0x00ff Mar 4 23:29:09 silvy kernel: sdhci: Wake-up: 0x00ff | Clock:0x Mar 4 23:29:09 silvy kernel: sdhci: Timeout: 0x00ff | Int stat: 0x Mar 4 23:29:09 silvy kernel: sdhci: Int enab: 0x | Sig enab: 0x Mar 4 23:29:09 silvy kernel: sdhci: AC12 err: 0x | Slot int: 0x Mar 4 23:29:09 silvy kernel: sdhci: Caps: 0x | Max curr: 0x Mar 4 23:29:09 silvy kernel: sdhci: === Mar 4 23:29:09 silvy kernel: mmc0: Card is consuming too much power! Mar 4 23:29:09 silvy kernel: mmc0: Unexpected interrupt 0x0080. Mar 4 23:29:09 silvy kernel: sdhci: == REGISTER DUMP == Mar
Re: [rfc][patch] dynamic resizing dentry hash using RCU
From: Nick Piggin [EMAIL PROTECTED] Date: Mon, 5 Mar 2007 05:27:24 +0100 Sounds great, I would be happy to help review it. If we can create a bit of common infrastructure, the dcache conversion might become a bit more palatable and we could look at other things like the inode hash as well. Absolutely, I'll run my patch by you once I have it ready. The other thing you'll have to be careful of when looking at doing an implementation, is that I think I forgot to use the RCU accessors (rcu_assign_pointer, rcu_dereference) when assigning and loading the new/old hash table pointers. Thanks for the heads-up. - 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][patch] dynamic resizing dentry hash using RCU
On Mon, Mar 05, 2007 at 05:27:24AM +0100, Nick Piggin wrote:
On Sun, Mar 04, 2007 at 08:11:42PM -0800, David Miller wrote:
One minor nit:
+struct dentry_hash {
+ unsigned int shift;
+ unsigned long mask;
+ struct hlist_head *table;
+};
I don't see any reason to make 'mask' an unsigned long
and this makes this structure take up 8 bytes more than
necessary on 64-bit.
You're right, the mask is currently just an int, so my patch should
not be messing with that. Thanks.
The other thing you'll have to be careful of when looking at doing
an implementation, is that I think I forgot to use the RCU accessors
(rcu_assign_pointer, rcu_dereference) when assigning and loading
the new/old hash table pointers.
Also, now that I think of it, if resize performance is far far less
important than read-side performance, then you should be able to get
away without the additional smp_rmb() that I add to the read-side
in the algorithm I described.
All you have to do is introduce an additional RCU grace period between
assigning the old pointer to the current table, and the current pointer
to the new table. This will still ensure that an (old_table == NULL
cur_table == new_table) condition is impossible (that condition would
mean that one of our active tables is invisible to the reader).
This should truely reduce read-side fastpath overhead to just a single,
predictable branch, an extra read_mostly load or two and the rcu_blah()
bits.
-
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: [BUG} usb regression in 2.6.21-rc2-git3
Mark Lord wrote: Here's another one for Greg: I have a Targus USB 1.1 dock, basically a hub with built-in serial, parallel, PS/2 KB, PS/2 Mouse, and extra USB ports. Simply connecting, and then disconnecting it causes an oops with 2.6.21-rc2: .. Same behaviour with a second, different USB 1.1 dock here as well: Mar 4 23:40:16 silvy kernel: usb 5-8: new high speed USB device using ehci_hcd and address 5 Mar 4 23:40:16 silvy kernel: usb 5-8: configuration #1 chosen from 1 choice Mar 4 23:40:16 silvy kernel: hub 5-8:1.0: USB hub found Mar 4 23:40:16 silvy kernel: hub 5-8:1.0: 4 ports detected Mar 4 23:40:16 silvy kernel: usb 5-8.4: new full speed USB device using ehci_hcd and address 6 Mar 4 23:40:17 silvy kernel: usb 5-8.4: configuration #1 chosen from 1 choice Mar 4 23:40:17 silvy kernel: hub 5-8.4:1.0: USB hub found Mar 4 23:40:17 silvy kernel: hub 5-8.4:1.0: 4 ports detected Mar 4 23:40:17 silvy kernel: usb 5-8.4.1: new full speed USB device using ehci_hcd and address 7 Mar 4 23:40:17 silvy kernel: usb 5-8.4.1: configuration #1 chosen from 1 choice Mar 4 23:40:17 silvy kernel: usb 5-8.4.3: new low speed USB device using ehci_hcd and address 8 Mar 4 23:40:17 silvy kernel: usb 5-8.4.3: configuration #1 chosen from 1 choice Mar 4 23:40:17 silvy kernel: input: Composite USB PS2 Converter USB to PS2 Adaptor v1.12 as /class/input/input8 Mar 4 23:40:17 silvy kernel: input: USB HID v1.10 Keyboard [Composite USB PS2 Converter USB to PS2 Adaptor v1.12] on usb-:00:1d.7-8.4.3 Mar 4 23:40:17 silvy kernel: input: Composite USB PS2 Converter USB to PS2 Adaptor v1.12 as /class/input/input9 Mar 4 23:40:17 silvy kernel: input: USB HID v1.10 Mouse [Composite USB PS2 Converter USB to PS2 Adaptor v1.12] on usb-:00:1d.7-8.4.3 Mar 4 23:40:17 silvy kernel: usb 5-8.4.4: new full speed USB device using ehci_hcd and address 9 Mar 4 23:40:17 silvy kernel: usb 5-8.4.4: configuration #1 chosen from 1 choice Mar 4 23:40:17 silvy kernel: pl2303 5-8.4.4:1.0: pl2303 converter detected Mar 4 23:40:17 silvy kernel: usb-serial ttyUSB0: Error registering port device, continuing Mar 4 23:40:17 silvy kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 7 if 0 alt 1 proto 2 vid 0x0B39 pid 0x0801 Mar 4 23:40:17 silvy kernel: usbcore: registered new interface driver usblp Mar 4 23:40:17 silvy kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver Mar 4 23:41:05 silvy kernel: usb 5-8: USB disconnect, address 5 Mar 4 23:41:05 silvy kernel: usb 5-8.4: USB disconnect, address 6 Mar 4 23:41:05 silvy kernel: usb 5-8.4.1: USB disconnect, address 7 Mar 4 23:41:05 silvy kernel: drivers/usb/class/usblp.c: usblp0: removed Mar 4 23:41:05 silvy kernel: usb 5-8.4.3: USB disconnect, address 8 Mar 4 23:41:05 silvy kernel: usb 5-8.4.4: USB disconnect, address 9 Mar 4 23:41:05 silvy kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 000c Mar 4 23:41:05 silvy kernel: printing eip: Mar 4 23:41:05 silvy kernel: c027c251 Mar 4 23:41:05 silvy kernel: *pde = Mar 4 23:41:05 silvy kernel: Oops: [#1] Mar 4 23:41:05 silvy kernel: PREEMPT Mar 4 23:41:05 silvy kernel: Modules linked in: usblp radeon drm nfsd exportfs lockd nfs_acl sunrpc acpi_cpufreq cpufreq_ondemand cpufreq_powersave cpufreq_userspace cpufreq_stats freq_table cpufreq_conservative ac fan button thermal video battery container processor rfcomm l2cap bluetooth cfq_iosched deflate zlib_deflate twofish twofish_common serpent blowfish des cbc ecb blkcipher aes xcbc sha256 sha1 crypto_null af_key af_packet sbp2 usbhid hid pl2303 usbserial mousedev pcmcia snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore ipw2200 ahci psmouse serio_raw pcspkr ieee80211 ieee80211_crypt sdhci mmc_core snd_page_alloc yenta_socket rsrc_nonstatic firmware_class ohci1394 ieee1394 b44 mii pcmcia_core intel_agp ehci_hcd uhci_hcd usbcore agpgart sg sr_mod cdrom unix Mar 4 23:41:05 silvy kernel: CPU:0 Mar 4 23:41:05 silvy kernel: EIP:0060:[klist_del+6/69]Not tainted VLI Mar 4 23:41:05 silvy kernel: EFLAGS: 00010286 (2.6.21-rc2-git3 #5) Mar 4 23:41:05 silvy kernel: EIP is at klist_del+0x6/0x45 Mar 4 23:41:05 silvy kernel: eax: ebx: f6730a78 ecx: 0001 edx: f63f5248 Mar 4 23:41:05 silvy kernel: esi: f6730a88 edi: f63f5240 ebp: f6706618 esp: f7ba7e00 Mar 4 23:41:05 silvy kernel: ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Mar 4 23:41:05 silvy kernel: Process khubd (pid: 1925, ti=f7ba6000 task=f7c275e0 task.ti=f7ba6000) Mar 4 23:41:05 silvy kernel: Stack: f6730a78 0001 c01fb571 f6730a78 0001 f63f5240 c01fb6f2 Mar 4 23:41:05 silvy kernel:f63f5240 f89ffd0e fffe f6c62a40 f63f5240 f63f5240 f63f5274 f89ffc8e Mar 4 23:41:05 silvy kernel:f63f5240 f6706618 c01aafd5 0202 f6730a00 f63f5240 f6730a00 Mar 4 23:41:05 silvy kernel: Call Trace: Mar
Re: [patch] sched: optimize siblings status check logic in wake_idle()
On Mon, Mar 05, 2007 at 03:35:34AM +0100, Nick Piggin wrote: On Fri, Mar 02, 2007 at 08:23:32PM -0800, Suresh B wrote: When a logical cpu 'x' already has more than one process running, then most likely the siblings of that cpu 'x' must be busy. Otherwise the idle siblings would have likely(in most of the scenarios) picked up the extra load making the load on 'x' atmost one. Do you have any stats on this? Its more of a theory. There will be some conditions that this won't be true but IMO those won't be common cases. Use this logic to eliminate the siblings status check and minimize the cache misses encountered on a heavily loaded system. Well it does increase the cacheline footprint a bit, but all cachelines should be local to our L1 cache, presuming you don't have any CPUs where threads have seperate caches. These wakeup's can happen across SMP and NUMA domains. In those cases, most likely the sibling runqueue lines won't be in the caches. This has nothing to do with siblings sharing caches or not. What sort of numbers do you have? On a 16 node system, we have seen ~1.25% perf improvement on a database workload when we completely short circuited wake_idle(). This patch is trying to comeup with a best compromise to avoid the cache misses and also minimize the latenices, perf impact. thanks, suresh - 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] sched: optimize siblings status check logic in wake_idle()
On Sun, Mar 04, 2007 at 08:13:09PM -0800, Suresh B wrote: On Mon, Mar 05, 2007 at 03:35:34AM +0100, Nick Piggin wrote: On Fri, Mar 02, 2007 at 08:23:32PM -0800, Suresh B wrote: When a logical cpu 'x' already has more than one process running, then most likely the siblings of that cpu 'x' must be busy. Otherwise the idle siblings would have likely(in most of the scenarios) picked up the extra load making the load on 'x' atmost one. Do you have any stats on this? Its more of a theory. There will be some conditions that this won't be true but IMO those won't be common cases. Use this logic to eliminate the siblings status check and minimize the cache misses encountered on a heavily loaded system. Well it does increase the cacheline footprint a bit, but all cachelines should be local to our L1 cache, presuming you don't have any CPUs where threads have seperate caches. These wakeup's can happen across SMP and NUMA domains. In those cases, most likely the sibling runqueue lines won't be in the caches. This has nothing to do with siblings sharing caches or not. Oh that's true. What sort of numbers do you have? On a 16 node system, we have seen ~1.25% perf improvement on a database workload when we completely short circuited wake_idle(). This patch is trying to comeup with a best compromise to avoid the cache misses and also minimize the latenices, perf impact. Hmm, I wonder what if we only wake_idle if the wakeup comes from this CPU or a sibling? That's probably going to have downsides in some workloads as well, though. - 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] sched: optimize siblings status check logic in wake_idle()
On Mon, Mar 05, 2007 at 05:58:31AM +0100, Nick Piggin wrote: On Sun, Mar 04, 2007 at 08:13:09PM -0800, Suresh B wrote: On a 16 node system, we have seen ~1.25% perf improvement on a database workload when we completely short circuited wake_idle(). This patch is trying to comeup with a best compromise to avoid the cache misses and also minimize the latenices, perf impact. Hmm, I wonder what if we only wake_idle if the wakeup comes from this CPU or a sibling? That's probably going to have downsides in some workloads as well, though. yep. I thought about it and thought this patch is a decent solution. thanks, suresh - 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 00/13] Syslets, Threadlets, generic AIO support, v3
Kirk Kuchov wrote: [snip] This is a stupid comparaison. By your logic we should also have /dev/stdin, /dev/stdout and /dev/stderr. Well, as a matter of fact (on my system): # ls -l /dev/std* lrwxrwxrwx 1 root root 4 Feb 1 2006 /dev/stderr - fd/2 lrwxrwxrwx 1 root root 4 Feb 1 2006 /dev/stdin - fd/0 lrwxrwxrwx 1 root root 4 Feb 1 2006 /dev/stdout - fd/1 Please don't bother to respond to this mail, I just saw that you apparently needed the info. Magnus P.S.: *PLONK* - 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 00/13] Syslets, Threadlets, generic AIO support, v3
On 3/4/07, Kyle Moffett [EMAIL PROTECTED] wrote: Well, even this far into 2.6, Linus' patch from 2003 still (mostly) applies; the maintenance cost for this kind of code is virtually zilch. If it matters that much to you clean it up and make it apply; add an alarmfd() syscall (another 100 lines of code at most?) and make a read return an architecture-independent siginfo-like structure and submit it for inclusion. Adding epoll() support for random objects is as simple as a 75-line object-filesystem and a 25- line syscall to return an FD to a new inode. Have fun! Go wild! Something this trivially simple could probably spend a week in -mm and go to linus for 2.6.22. Or, if you want to do slightly more work and produce something a great deal more useful, you could implement additional netlink address families for additional event sources. The socket - setsockopt - bind - sendmsg/recvmsg sequence is a well understood and well documented UNIX paradigm for multiplexing non-blocking I/O to many destinations over one socket. Everyone who has read Stevens is familiar with the basic UDP and fd open server techniques, and if you look at Linux's IP_PKTINFO and NETLINK_W1 (bravo, Evgeniy!) you'll see how easily they could be extended to file AIO and other kinds of event sources. For file AIO, you might have the application open one AIO socket per mount point, open files indirectly via the SCM_RIGHTS mechanism, and submit/retire read/write requests via sendmsg/recvmsg with ancillary data consisting of an lseek64 tuple and a user-provided cookie. Although the process still has to have one fd open per actual open file (because trying to authenticate file accesses without opening fds is madness), the only fds it has to manipulate directly are those representing entire pools of outstanding requests. This is usually a small enough set that select() will do just fine, if you're careful with fd allocation. (You can simply punt indirectly opened fds up to a high numerical range, where they can't be accessed directly from userspace but still make fine cookies for use in lseek64 tuples within cmsg headers). The same basic approach will work for timers, signals, and just about any other event source. Userspace is of course still stuck doing its own state machines / thread scheduling / however you choose to think of it. But all the important activity goes through socketcall(), and the data and control parameters are all packaged up into a struct msghdr instead of the bare buffer pointers of read/write. So if someone else does come along later and design an ultralight threading mechanism that isn't a total botch, the actual data paths won't need much rework; the exception handling will just get a lot simpler. Cheers, - Michael - 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: [BUG] sdhci regression in 2.6.21-rc2
Mark Lord wrote: Another regression, for Pierre Ossman this time. My syslog gets spammed like this (below) on suspend/resume (to RAM) cycles. Worked fine, without all of the noise, in all previous kernels up to 2.6.20+. This looks like a PCI configuration issue. Can you bisect which commit caused the issue? And what's the PCI address of the device? 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: [RFC] Heads up on sys_fallocate()
On Sun, 4 March 2007 14:38:13 -0800, Ulrich Drepper wrote: When you do it like this, who can the kernel/filesystem *guarantee* that when the data is written there actually is room on the harddrive? What you described seems like using truncate/ftruncate to increase the file's size. That is not at all what posix_fallocate is for. posix_fallocate must make sure that the requested blocks on the disk are reserved (allocated) for the file's use and that at no point in the future will, say, a msync() fail because a mmap(MAP_SHARED) page has been written to. That actually causes an interesting problem for compressing filesystems. The space consumed by blocks depends on their contents and how well it compresses. At the moment, the only option I see to support posix_fallocate for LogFS is to set an inode flag disabling compression, then allocate the blocks. But if the file already contains large amounts of compressed data, I have a problem. Disabling compression for a range within a file is not supported, so I can only return an error. But which one? Jörn -- A surrounded army must be given a way out. -- Sun Tzu - 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] Heads up on sys_fallocate()
On Sun, Mar 04, 2007 at 08:11:17PM +, Anton Altaparmakov wrote: glibc cannot ever be smart enough because a file system driver will always know better and be able to do things in a much more optimized way. Please read the thread again. That is not what anyone proposed. The issues we're discussing is whether fallback for a filesystem that does not support preallocation natively should be done in kernelspace or in userspace. - 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: [6/6] 2.6.21-rc2: known regressions
From: Adrian Bunk [EMAIL PROTECTED]
Date: Mon, 5 Mar 2007 03:26:02 +0100
On Sun, Mar 04, 2007 at 06:07:25PM -0800, David Miller wrote:
From: Adrian Bunk [EMAIL PROTECTED]
Date: Mon, 5 Mar 2007 02:50:45 +0100
Subject: sparc64 compile error due to GENERIC_ISA_DMA removal
References : http://bugzilla.kernel.org/show_bug.cgi?id=8097
Submitter : Horst H. von Brand [EMAIL PROTECTED]
Caused-By : David S. Miller [EMAIL PROTECTED]
commit 1b51d3a08b6c80a1e47d4c579c41abbe56cd3c44
Status : unknown
Fixed in current GIT.
commit 74bd7d093b8e87f35eaf3b14459b96a0e20d1d10
Author: David S. Miller [EMAIL PROTECTED]
Date: Wed Feb 28 13:09:34 2007 -0800
[SPARC64]: Fix parport_pc build.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
Horst's problem is with the floppy driver and
claim_dma_lock/release_dma_lock in include/asm-sparc64/dma.h .
Here is the fix I will send to Linus for this, thanks:
commit 08414aa2516da65ae7a522c6834b8ea576f38c4b
Author: David S. Miller [EMAIL PROTECTED]
Date: Sun Mar 4 20:36:18 2007 -0800
[SPARC64]: Fix floppy build failure.
Just define a local {claim,release}_dma_lock() implementation
for the floppy driver to use so we don't need to define and
export to modules the silly dma_spin_lock.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/include/asm-sparc64/dma.h b/include/asm-sparc64/dma.h
index 1bf4f7a..a9fd061 100644
--- a/include/asm-sparc64/dma.h
+++ b/include/asm-sparc64/dma.h
@@ -15,17 +15,6 @@
#include asm/delay.h
#include asm/oplib.h
-extern spinlock_t dma_spin_lock;
-
-#define claim_dma_lock() \
-({ unsigned long flags; \
- spin_lock_irqsave(dma_spin_lock, flags); \
- flags; \
-})
-
-#define release_dma_lock(__flags) \
- spin_unlock_irqrestore(dma_spin_lock, __flags);
-
/* These are irrelevant for Sparc DMA, but we leave it in so that
* things can compile.
*/
diff --git a/include/asm-sparc64/floppy.h b/include/asm-sparc64/floppy.h
index dbe033e..331013a 100644
--- a/include/asm-sparc64/floppy.h
+++ b/include/asm-sparc64/floppy.h
@@ -854,4 +854,15 @@ static unsigned long __init sun_floppy_init(void)
#define EXTRA_FLOPPY_PARAMS
+static DEFINE_SPINLOCK(dma_spin_lock);
+
+#define claim_dma_lock() \
+({ unsigned long flags; \
+ spin_lock_irqsave(dma_spin_lock, flags); \
+ flags; \
+})
+
+#define release_dma_lock(__flags) \
+ spin_unlock_irqrestore(dma_spin_lock, __flags);
+
#endif /* !(__ASM_SPARC64_FLOPPY_H) */
-
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/
Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
Recent kernels are having troubles with wireless for me. Two seemingly related problems: a) NetworkManager seems oblivious to the existence of my IPW2200 b) Manual iwconfig waits for 60s and then reports: Error for wireless request Set Encode (8B2A) : SET failed on device eth1 ; Operation not supported. During this time, my keyboard in X is unresponsive, but everything else seems to be functioning properly. Queued keypresses eventually show up. Alt-sysrq-w gives: ieee80211_crypt: registered algorithm 'WEP' SysRq : Show Blocked State freesibling task PCstack pid father child younger older events/0 D C0102D3C 0 4 1 5 3 (L-TLB) c1d0bf1c 0046 c1d0ac20 c0102d3c c1d0aa70 0022 000a c1d0aa70 ca8ed618 0034 0cd3 c1d0ab7c 0287 0002 f581f040 0002 c1d0bf34 0246 f7b5cb04 c1d0aa70 c038224e c0102c3a Call Trace: [c0102d3c] __switch_to+0x11b/0x143 [c038224e] __mutex_lock_slowpath+0xfb/0x1e2 [c0102c3a] __switch_to+0x19/0x143 [f994a291] ipw_bg_link_down+0x19/0xbd [ipw2200] [f994a278] ipw_bg_link_down+0x0/0xbd [ipw2200] [c0122604] run_workqueue+0x97/0x156 [c0122bc7] worker_thread+0x105/0x12e [c0112399] default_wake_function+0x0/0xc [c0122ac2] worker_thread+0x0/0x12e [c01251f7] kthread+0xa0/0xc9 [c0125157] kthread+0x0/0xc9 [c0103f87] kernel_thread_helper+0x7/0x10 === ipw2200/0 D 0020 0 1985 6 2260 1983 (L-TLB) f7981f24 0046 0001 0020 c1cdf8c0 000a f7d09030 e1fdc8c3 0034 093a f7d0913c 0086 0020 f7c4a740 0086 f7981f3c 0246 f7b5cb04 f7d09030 c038224e f7d09030 c0496550 Call Trace: [c038224e] __mutex_lock_slowpath+0xfb/0x1e2 [c0381233] __sched_text_start+0x4b3/0x56b [f99445c6] ipw_bg_gather_stats+0x0/0x27 [ipw2200] [f99445dd] ipw_bg_gather_stats+0x17/0x27 [ipw2200] [c0122604] run_workqueue+0x97/0x156 [c0122bc7] worker_thread+0x105/0x12e [c0112399] default_wake_function+0x0/0xc [c0122ac2] worker_thread+0x0/0x12e [c01251f7] kthread+0xa0/0xc9 [c0125157] kthread+0x0/0xc9 [c0103f87] kernel_thread_helper+0x7/0x10 === ieee80211_crypt_wep: could not allocate crypto API arc4 eth1: could not initialize WEP: load module ieee80211_crypt_wep ADDRCONF(NETDEV_UP): eth1: link is not ready A second attempt to enable WEP via iwconfig succeeds and network connectivity is normal. However, NetworkManager still ignores the device at this point. Bisect with Mercurial points to this patch: $ hg bisect bad The first bad revision is: changeset: 46985:f701b96bb2f7 user:Greg Kroah-Hartman [EMAIL PROTECTED] date:Wed Feb 07 10:37:11 2007 -0800 summary: Network: convert network devices to use struct device instead of class_device which corresponds to 43cb76d91ee85f579a69d42bc8efc08bac560278 in git. -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - 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: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
[adding linux-wireless to CC] On Sun, 2007-03-04 at 16:08 -0600, Matt Mackall wrote: Recent kernels are having troubles with wireless for me. Two seemingly related problems: I don't think they are related actually. a) NetworkManager seems oblivious to the existence of my IPW2200 This is due to the recent sysfs restructuring I think. IIRC the fix is to upgrade hal to a current git version. b) Manual iwconfig waits for 60s and then reports: That one's strange. A second attempt to enable WEP via iwconfig succeeds and network connectivity is normal. However, NetworkManager still ignores the device at this point. I'd think it's a ipw bug but I have no idea if that was even touched during this time. Bisect with Mercurial points to this patch: $ hg bisect bad The first bad revision is: changeset: 46985:f701b96bb2f7 user:Greg Kroah-Hartman [EMAIL PROTECTED] date:Wed Feb 07 10:37:11 2007 -0800 summary: Network: convert network devices to use struct device instead of class_device which corresponds to 43cb76d91ee85f579a69d42bc8efc08bac560278 in git. Yup, sysfs breakage/hal stuff. Can you try with a recent hal? And maybe try to bisect the iwconfig stop thing if you've got enough time... johannes signature.asc Description: This is a digitally signed message part
Re: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Mon, Mar 05, 2007 at 12:39:24AM +0100, Johannes Berg wrote: [adding linux-wireless to CC] On Sun, 2007-03-04 at 16:08 -0600, Matt Mackall wrote: Recent kernels are having troubles with wireless for me. Two seemingly related problems: I don't think they are related actually. a) NetworkManager seems oblivious to the existence of my IPW2200 This is due to the recent sysfs restructuring I think. IIRC the fix is to upgrade hal to a current git version. If that's the cause, the fix is to back out whatever was done to break userspace. Breaking userspace is not ok. Upgrading from 2.6.x to 2.6.x+1 should not entail replacing substantial parts of userspace, especially with NOT-EVEN-FRAKKING-RELEASED-YET CODE. I will try a new HAL when it shows up in Debian/unstable and not a moment sooner. b) Manual iwconfig waits for 60s and then reports: That one's strange. A second attempt to enable WEP via iwconfig succeeds and network connectivity is normal. However, NetworkManager still ignores the device at this point. I'd think it's a ipw bug but I have no idea if that was even touched during this time. Bisect with Mercurial points to this patch: $ hg bisect bad The first bad revision is: changeset: 46985:f701b96bb2f7 user:Greg Kroah-Hartman [EMAIL PROTECTED] date:Wed Feb 07 10:37:11 2007 -0800 summary: Network: convert network devices to use struct device instead of class_device which corresponds to 43cb76d91ee85f579a69d42bc8efc08bac560278 in git. Yup, sysfs breakage/hal stuff. Can you try with a recent hal? And maybe try to bisect the iwconfig stop thing if you've got enough time... Will double-check the iwconfig tests. It's been masked by NetworkManager for a while. -- Mathematics is the supreme nostalgia of our time. - 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: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On 3/5/07, Matt Mackall [EMAIL PROTECTED] wrote: This is due to the recent sysfs restructuring I think. IIRC the fix is to upgrade hal to a current git version. If that's the cause, the fix is to back out whatever was done to break userspace. Breaking userspace is not ok. Upgrading from 2.6.x to 2.6.x+1 should not entail replacing substantial parts of userspace, especially with NOT-EVEN-FRAKKING-RELEASED-YET CODE. I will try a new HAL when it shows up in Debian/unstable and not a moment sooner. But you're running a kernel that's not in Debian/unstable so this seems a bit hypocritical. When you work with bleeding edge kernels you have to be prepared to work around things. Hell for ages git wasn't in Debian - unstable even, udev would break things etc. Just my 2c worth. -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group - 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: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Sun, 4 Mar 2007 18:25:50 -0600 Matt Mackall [EMAIL PROTECTED] wrote: On Mon, Mar 05, 2007 at 12:39:24AM +0100, Johannes Berg wrote: [adding linux-wireless to CC] On Sun, 2007-03-04 at 16:08 -0600, Matt Mackall wrote: Recent kernels are having troubles with wireless for me. Two seemingly related problems: I don't think they are related actually. a) NetworkManager seems oblivious to the existence of my IPW2200 This is due to the recent sysfs restructuring I think. IIRC the fix is to upgrade hal to a current git version. If that's the cause, the fix is to back out whatever was done to break userspace. Breaking userspace is not ok. Upgrading from 2.6.x to 2.6.x+1 should not entail replacing substantial parts of userspace, especially with NOT-EVEN-FRAKKING-RELEASED-YET CODE. yep. Adrian, I think we should track this as a blocking regression, at least until we've fully understood the implications and had the usual arguments. - 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: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Sun, Mar 04, 2007 at 04:45:25PM -0800, Andrew Morton wrote: On Sun, 4 Mar 2007 18:25:50 -0600 Matt Mackall [EMAIL PROTECTED] wrote: On Mon, Mar 05, 2007 at 12:39:24AM +0100, Johannes Berg wrote: [adding linux-wireless to CC] On Sun, 2007-03-04 at 16:08 -0600, Matt Mackall wrote: Recent kernels are having troubles with wireless for me. Two seemingly related problems: I don't think they are related actually. a) NetworkManager seems oblivious to the existence of my IPW2200 This is due to the recent sysfs restructuring I think. IIRC the fix is to upgrade hal to a current git version. If that's the cause, the fix is to back out whatever was done to break userspace. Breaking userspace is not ok. Upgrading from 2.6.x to 2.6.x+1 should not entail replacing substantial parts of userspace, especially with NOT-EVEN-FRAKKING-RELEASED-YET CODE. yep. Adrian, I think we should track this as a blocking regression, at least until we've fully understood the implications and had the usual arguments. I'm currently tracking it as one of the 31 2.6.21-rc regressions that are not yet fixed in Linus' tree, and for me each of them is a blocker until proven otherwise. Whether Linus releases 2.6.21 despite blocking regressions is a different question... cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Sun, Mar 04, 2007 at 04:08:57PM -0600, Matt Mackall wrote: Recent kernels are having troubles with wireless for me. Two seemingly related problems: a) NetworkManager seems oblivious to the existence of my IPW2200 b) Manual iwconfig waits for 60s and then reports: Error for wireless request Set Encode (8B2A) : SET failed on device eth1 ; Operation not supported. Do you have CONFIG_SYSFS_DEPRECATED enabled? If not, please do as that will keep you from having to change any userspace code. thanks, greg k-h - 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: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Sun, Mar 04, 2007 at 06:25:50PM -0600, Matt Mackall wrote: On Mon, Mar 05, 2007 at 12:39:24AM +0100, Johannes Berg wrote: [adding linux-wireless to CC] On Sun, 2007-03-04 at 16:08 -0600, Matt Mackall wrote: Recent kernels are having troubles with wireless for me. Two seemingly related problems: I don't think they are related actually. a) NetworkManager seems oblivious to the existence of my IPW2200 This is due to the recent sysfs restructuring I think. IIRC the fix is to upgrade hal to a current git version. If that's the cause, the fix is to back out whatever was done to break userspace. Breaking userspace is not ok. Upgrading from 2.6.x to 2.6.x+1 should not entail replacing substantial parts of userspace, especially with NOT-EVEN-FRAKKING-RELEASED-YET CODE. I should not have broken any userspace if CONFIG_SYSFS_DEPRECATED is enabled with that patch. If that is enabled, and that patch still causes problems, please let me know. thanks, greg k-h - 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/
[-mm patch] drivers/net/bonding/bond_main.c:make 3 functions static
This patch makes the following needlessly global functions static:
- bond_mode_name()
- bond_sethwaddr()
- bond_mii_monitor()
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/bonding/bond_main.c |7 ---
drivers/net/bonding/bonding.h |3 ---
2 files changed, 4 insertions(+), 6 deletions(-)
--- linux-2.6.21-rc2-mm1/drivers/net/bonding/bonding.h.old 2007-03-04
21:33:14.0 +0100
+++ linux-2.6.21-rc2-mm1/drivers/net/bonding/bonding.h 2007-03-04
21:34:46.0 +0100
@@ -301,13 +301,10 @@
void bond_destroy_slave_symlinks(struct net_device *master, struct net_device
*slave);
int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev);
int bond_release(struct net_device *bond_dev, struct net_device *slave_dev);
-int bond_sethwaddr(struct net_device *bond_dev, struct net_device *slave_dev);
-void bond_mii_monitor(struct work_struct *work);
void bond_loadbalance_arp_mon(struct work_struct *work);
void bond_activebackup_arp_mon(struct work_struct *work);
void bond_set_mode_ops(struct bonding *bond, int mode);
int bond_parse_parm(char *mode_arg, struct bond_parm_tbl *tbl);
-const char *bond_mode_name(int mode);
void bond_select_active_slave(struct bonding *bond);
void bond_change_active_slave(struct bonding *bond, struct slave *new_active);
void bond_register_arp(struct bonding *);
--- linux-2.6.21-rc2-mm1/drivers/net/bonding/bond_main.c.old2007-03-04
21:33:29.0 +0100
+++ linux-2.6.21-rc2-mm1/drivers/net/bonding/bond_main.c2007-03-04
21:34:56.0 +0100
@@ -187,7 +187,7 @@
/* General routines -*/
-const char *bond_mode_name(int mode)
+static const char *bond_mode_name(int mode)
{
switch (mode) {
case BOND_MODE_ROUNDROBIN :
@@ -1200,7 +1200,8 @@
/*-- IOCTL --*/
-int bond_sethwaddr(struct net_device *bond_dev, struct net_device *slave_dev)
+static int bond_sethwaddr(struct net_device *bond_dev,
+ struct net_device *slave_dev)
{
dprintk(bond_dev=%p\n, bond_dev);
dprintk(slave_dev=%p\n, slave_dev);
@@ -2014,7 +2015,7 @@
/* Monitoring ---*/
/* this function is called regularly to monitor each slave's link. */
-void bond_mii_monitor(struct work_struct *work)
+static void bond_mii_monitor(struct work_struct *work)
{
struct bonding *bond = container_of(work, struct bonding,
mii_work.work);
struct net_device *bond_dev = bond-dev;
-
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 patch] make drivers/net/s2io.c:vlan_strip_flag static
This patch makes the needlessly global vlan_strip_flag static. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- --- linux-2.6.21-rc2-mm1/drivers/net/s2io.c.old 2007-03-04 21:37:59.0 +0100 +++ linux-2.6.21-rc2-mm1/drivers/net/s2io.c 2007-03-04 21:38:14.0 +0100 @@ -316,7 +316,7 @@ } /* A flag indicating whether 'RX_PA_CFG_STRIP_VLAN_TAG' bit is set or not */ -int vlan_strip_flag; +static int vlan_strip_flag; /* Unregister the vlan */ static void s2io_vlan_rx_kill_vid(struct net_device *dev, unsigned long vid) - 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/
[1/6] 2.6.21-rc2: known regressions
This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: kwin dies silently References : http://lkml.org/lkml/2007/2/28/112 Submitter : Sid Boyce [EMAIL PROTECTED] Status : unknown Subject: resume: slab error in verify_redzone_free(): cache `size-512': memory outside object was overwritten References : http://lkml.org/lkml/2007/2/24/41 Submitter : Pavel Machek [EMAIL PROTECTED] Handled-By : Marcel Holtmann [EMAIL PROTECTED] Status : unknown Subject: bluetooth hardlocks References : http://lkml.org/lkml/2007/3/2/85 Submitter : Pavel Machek [EMAIL PROTECTED] Status : unknown Subject: Bluetooth RFComm locks up the machine (device_move() related) References : http://lkml.org/lkml/2007/3/4/64 Submitter : Mark Lord [EMAIL PROTECTED] Caused-By : Marcel Holtmann [EMAIL PROTECTED] commit c1a3313698895d8ad4760f98642007bf236af2e8 Status : unknown Subject: kref refcounting breakage References : http://lkml.org/lkml/2007/3/2/67 Submitter : Andrew Morton [EMAIL PROTECTED] Handled-By : Greg KH [EMAIL PROTECTED] Status : unknown Subject: wireless breakage (ipw2200, iwconfig, NetworkManager) References : http://lkml.org/lkml/2007/3/4/135 Submitter : Matt Mackall [EMAIL PROTECTED] Caused-By : Greg Kroah-Hartman [EMAIL PROTECTED] (?) commit 43cb76d91ee85f579a69d42bc8efc08bac560278 (?) Handled-By : Johannes Berg [EMAIL PROTECTED] Status : unknown Subject: forcedeth: skb_over_panic References : http://bugzilla.kernel.org/show_bug.cgi?id=8058 Submitter : Albert Hopkins [EMAIL PROTECTED] Status : unknown - 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 patch] drivers/net/qla3xxx.c: make 2 functions static
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- linux-2.6.21-rc2-mm1/drivers/net/qla3xxx.c.old 2007-03-04
21:41:27.0 +0100
+++ linux-2.6.21-rc2-mm1/drivers/net/qla3xxx.c 2007-03-04 21:41:39.0
+0100
@@ -1797,14 +1797,14 @@
atomic_inc(qdev-tx_count);
}
-void ql_get_sbuf(struct ql3_adapter *qdev)
+static void ql_get_sbuf(struct ql3_adapter *qdev)
{
if (++qdev-small_buf_index == NUM_SMALL_BUFFERS)
qdev-small_buf_index = 0;
qdev-small_buf_release_cnt++;
}
-struct ql_rcv_buf_cb *ql_get_lbuf(struct ql3_adapter *qdev)
+static struct ql_rcv_buf_cb *ql_get_lbuf(struct ql3_adapter *qdev)
{
struct ql_rcv_buf_cb *lrg_buf_cb = NULL;
lrg_buf_cb = qdev-lrg_buf[qdev-lrg_buf_index];
-
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: [1/6] 2.6.21-rc2: known regressions
On Mon, 5 Mar 2007 02:50:31 +0100 Adrian Bunk [EMAIL PROTECTED] wrote: This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree. We seem to have broken an unusually large amount of stuff this time. partial post-mortem: - The ACPICA merge landed in -mm super-late: basically it was in mainline a week afterwards and saw only a single -mm release. Part of the reason for this short period in -mm was that ACPICA had its paws all over x86_64 code and conflicted badly with significant changes in the x86_64 tree. That happens sometimes. But when it does, the mess lands in my lap rather than in the laps of the perpetrators. Lesson: keep the code well-factored so that different subsystems don't soil each others' kennels. - The hrtimers/dynticks stuff is simply hard: timekeeping, low-level x86, even APICs. These are areas in which things break a lot, so churning it was inevitably going to cause problems. Lesson: none, I think. Low-level x86 support is just hard, and changing it breaks things. So that accounts for _some_ of the damage, but I wonder if there's more to it than that. - 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: [1/6] 2.6.21-rc2: known regressions
On Mon, Mar 05, 2007 at 02:50:31AM +0100, Adrian Bunk wrote: Subject: kref refcounting breakage References : http://lkml.org/lkml/2007/3/2/67 Submitter : Andrew Morton [EMAIL PROTECTED] Handled-By : Greg KH [EMAIL PROTECTED] Status : unknown I'm working on tracking this down still... Subject: wireless breakage (ipw2200, iwconfig, NetworkManager) References : http://lkml.org/lkml/2007/3/4/135 Submitter : Matt Mackall [EMAIL PROTECTED] Caused-By : Greg Kroah-Hartman [EMAIL PROTECTED] (?) commit 43cb76d91ee85f579a69d42bc8efc08bac560278 (?) Handled-By : Johannes Berg [EMAIL PROTECTED] Status : unknown I really think this is a CONFIG_SYSFS_DEPRECATED issue (not being set), but want to get Matt confirm either way before saying this is a real issue or not. thanks, greg k-h - 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: [1/6] 2.6.21-rc2: known regressions
Adrian Bunk wrote: Subject: Bluetooth RFComm locks up the machine (device_move() related) References : http://lkml.org/lkml/2007/3/4/64 Submitter : Mark Lord [EMAIL PROTECTED] Caused-By : Marcel Holtmann [EMAIL PROTECTED] commit c1a3313698895d8ad4760f98642007bf236af2e8 Status : unknown A 2-line patch exists for fs/sysfs/dir.c to address this. Waiting on Greg to apply it or substitute something prettier. ;) Cheers - 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: [1/6] 2.6.21-rc2: known regressions
On Sun, Mar 04, 2007 at 11:01:33PM -0500, Mark Lord wrote: Adrian Bunk wrote: Subject: Bluetooth RFComm locks up the machine (device_move() related) References : http://lkml.org/lkml/2007/3/4/64 Submitter : Mark Lord [EMAIL PROTECTED] Caused-By : Marcel Holtmann [EMAIL PROTECTED] commit c1a3313698895d8ad4760f98642007bf236af2e8 Status : unknown A 2-line patch exists for fs/sysfs/dir.c to address this. Waiting on Greg to apply it or substitute something prettier. ;) I want to see if Marcel agrees with it, as he did the original patch in that area. thanks, greg k-h - 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/
[6/6] 2.6.21-rc2: known regressions
This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: sparc64 compile error due to GENERIC_ISA_DMA removal References : http://bugzilla.kernel.org/show_bug.cgi?id=8097 Submitter : Horst H. von Brand [EMAIL PROTECTED] Caused-By : David S. Miller [EMAIL PROTECTED] commit 1b51d3a08b6c80a1e47d4c579c41abbe56cd3c44 Status : unknown Subject: mmc reader no longer works References : http://lkml.org/lkml/2007/2/27/91 Submitter : Pavel Machek [EMAIL PROTECTED] Caused-By : Oliver Neukum [EMAIL PROTECTED] Status : problem is being debugged Subject: usb-serial broken (ftdi serial device shows up as ttyUSB140 instead of ttyUSB0) Submitter : Craig Schlenter [EMAIL PROTECTED] Caused-By : Oliver Neukum [EMAIL PROTECTED] commit 34ef50e5b1f96c2d8c0f3d28b7d407743806256c Handled-By : Oliver Neukum [EMAIL PROTECTED] Status : patch available Subject: Oops in rtc_cmos References : http://lkml.org/lkml/2007/3/4/112 http://lkml.org/lkml/2007/2/18/172 Submitter : Paul Rolland [EMAIL PROTECTED] Rafael J. Wysocki [EMAIL PROTECTED] Caused-By : David Brownell [EMAIL PROTECTED] commit 7be2c7c96aff2871240d61fef508c41176c688b5 Patch : http://lkml.org/lkml/2007/2/23/184 Status : patch available - 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: [6/6] 2.6.21-rc2: known regressions
From: Adrian Bunk [EMAIL PROTECTED] Date: Mon, 5 Mar 2007 02:50:45 +0100 Subject: sparc64 compile error due to GENERIC_ISA_DMA removal References : http://bugzilla.kernel.org/show_bug.cgi?id=8097 Submitter : Horst H. von Brand [EMAIL PROTECTED] Caused-By : David S. Miller [EMAIL PROTECTED] commit 1b51d3a08b6c80a1e47d4c579c41abbe56cd3c44 Status : unknown Fixed in current GIT. commit 74bd7d093b8e87f35eaf3b14459b96a0e20d1d10 Author: David S. Miller [EMAIL PROTECTED] Date: Wed Feb 28 13:09:34 2007 -0800 [SPARC64]: Fix parport_pc build. Signed-off-by: David S. Miller [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: [6/6] 2.6.21-rc2: known regressions
On Mon, Mar 05, 2007 at 02:50:45AM +0100, Adrian Bunk wrote: Subject: usb-serial broken (ftdi serial device shows up as ttyUSB140 instead of ttyUSB0) Submitter : Craig Schlenter [EMAIL PROTECTED] Caused-By : Oliver Neukum [EMAIL PROTECTED] commit 34ef50e5b1f96c2d8c0f3d28b7d407743806256c Handled-By : Oliver Neukum [EMAIL PROTECTED] Status : patch available Patch is queued up in my tree and will go to Linus in a few days. But I think there is another usb-serial patch that Oliver needs to send me to fix another problem with the usb-serial core... thanks, greg k-h - 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/
[-mm patch] make drivers/char/drm/drm_vm.c:drm_io_prot() static
On Fri, Mar 02, 2007 at 03:00:26AM -0800, Andrew Morton wrote:
...
Changes since 2.6.20-mm2:
...
git-drm.patch
...
git trees
...
This patch makes the needlessly global drm_io_prot() static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- linux-2.6.21-rc2-mm1/drivers/char/drm/drm_vm.c.old 2007-03-04
20:39:25.0 +0100
+++ linux-2.6.21-rc2-mm1/drivers/char/drm/drm_vm.c 2007-03-04
20:39:34.0 +0100
@@ -41,7 +41,7 @@
static void drm_vm_open(struct vm_area_struct *vma);
static void drm_vm_close(struct vm_area_struct *vma);
-pgprot_t drm_io_prot(uint32_t map_type, struct vm_area_struct *vma)
+static pgprot_t drm_io_prot(uint32_t map_type, struct vm_area_struct *vma)
{
pgprot_t tmp = vm_get_page_prot(vma-vm_flags);
-
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: [3/6] 2.6.21-rc2: known regressions
On Mon, Mar 05, 2007 at 02:50:36AM +0100, Adrian Bunk wrote: This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree. Subject: kernels fail to boot with drives on ATIIXP controller References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 Submitter : Michal Jaegermann [EMAIL PROTECTED] Status : unknown Alan added comment to my posting that my problems are caused by messed up IRQ routing on that box I tried. Indeed, I can boot kernel 2.6.20-1.2962.fc7, which really is 2.6.21-rc2, provided I will use 'acpi=off irqpoll'. Anything else and a boot silently dies if 'acpi=off' is skipped or is not finding disk if 'irqpoll' is missing. Somehow 2.6.19 is booting on the same hardware without valliant efforts; OTOH 'ahci' driver was not used there. Michal - 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: [PATA] Failed to set xfermode on LITE-ON LTR-48246S
Philipp Matthias Hahn wrote:
Hello!
As reported by John Williams and others like in
http://www.mail-archive.com/linux-ide@vger.kernel.org/msg03088.html
I too have a problem with 2.6.20.1 using ata_piix not detecting the
CD-ROM any more. Applying the patch from
http://lkml.org/lkml/2007/2/12/24 did not help, but additionally
applying
http://readlist.com/lists/vger.kernel.org/linux-kernel/45/228948.html
made it work. Here's the relevant extra debugging output:
* Did it work with previous kernels?
* Does applying the attached patch over unpatched 2.6.20.1 fix the problem?
--
tejun
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index dc42ba1..78e6ac5 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -105,8 +105,10 @@ enum {
PIIX_FLAG_AHCI = (1 27), /* AHCI possible */
PIIX_FLAG_CHECKINTR = (1 28), /* make sure PCI INTx enabled */
- PIIX_PATA_FLAGS = ATA_FLAG_SLAVE_POSS,
- PIIX_SATA_FLAGS = ATA_FLAG_SATA | PIIX_FLAG_CHECKINTR,
+ PIIX_PATA_FLAGS = ATA_FLAG_SLAVE_POSS |
+ ATA_FLAG_SETXFER_POLLING,
+ PIIX_SATA_FLAGS = ATA_FLAG_SATA | PIIX_FLAG_CHECKINTR |
+ ATA_FLAG_SETXFER_POLLING,
/* combined mode. if set, PATA is channel 0.
* if clear, PATA is channel 1.
Re: sata_sil problems with recent kernels
Dale Blount wrote: On Tue, 2007-02-27 at 13:54 -0500, Dale Blount wrote: On Fri, 2007-02-23 at 12:00 -0500, Dale Blount wrote: Hi, Excuse me if this has been covered or fixed, I couldn't find anything in the archives. I upgraded from 2.6.11.7 to 2.6.20.1 today and found all the drives connected to 2 brands of sata_sil sata controllers not working. The drives are also (now) of various brands, Maxtor 300GB and 500GB Seagates. For the archives, the fix is documented here: http://article.gmane.org/gmane.linux.ide/16304 Yeap, that's the correct fix and the problem is introduced in 2.6.20 by using polling IDENTIFY by default. Well, the bug has always been there but no one was issuing polling command to sata_sil upto 2.6.19. This will probably included in the next -stable iteration. Thanks. -- 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: [git patches] libata fixes
[cc'ing Eric D. Mudama. Hi!] Paul Rolland wrote: ata1.00: exception Emask 0x2 SAct 0xffe0 SErr 0x0 action 0x2 frozen ata1.00: (spurious completions during NCQ issue=0x0 SAct=0xffe0 FIS=004040a1:0010) ata1.00: cmd 60/02:28:52:ec:c4/00:00:0e:00:00/40 tag 5 cdb 0x0 data 1024 in res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/02:30:54:ec:c4/00:00:0e:00:00/40 tag 6 cdb 0x0 data 1024 in res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/02:38:56:ec:c4/00:00:0e:00:00/40 tag 7 cdb 0x0 data 1024 in res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/02:40:58:ec:c4/00:00:0e:00:00/40 tag 8 cdb 0x0 data 1024 in res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/02:48:5a:ec:c4/00:00:0e:00:00/40 tag 9 cdb 0x0 data 1024 in res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/02:50:5c:ec:c4/00:00:0e:00:00/40 tag 10 cdb 0x0 data 1024 in res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/02:58:5e:ec:c4/00:00:0e:00:00/40 tag 11 cdb 0x0 data 1024 in res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/02:60:60:ec:c4/00:00:0e:00:00/40 tag 12 cdb 0x0 data 1024 in res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/02:68:62:ec:c4/00:00:0e:00:00/40 tag 13 cdb 0x0 data 1024 in res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/02:70:64:ec:c4/00:00:0e:00:00/40 tag 14 cdb 0x0 data 1024 in res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/02:78:66:ec:c4/00:00:0e:00:00/40 tag 15 cdb 0x0 data 1024 in res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) ata1: soft resetting port ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: configured for UDMA/133 ata1: EH complete SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA This last part was not present when booting stock 2.6.21-rc1 Your drive has some issues with NCQ and is scheduled to be blacklisted such that it isn't enabled. libata used to ignore the condition but now considers it NCQ protocol violation and fails all pending commands. libata EH should turn NCQ off automatically after a few of the above errors. I'd love to see how that actually works in the field (full dmesg please). If it doesn't, it needs fixing. Thanks. -- 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: [git patches] libata fixes
Hello,
Paul Rolland wrote:
Hello,
Applied this on top of 2.6.21-rc1 and your previous patch (see my previous
mail).
Still booting, no more the weird error I've reported minutes ago.
pata_jmicron still unable to detect my DVD-RW :
scsi8 : pata_jmicron
ata9.00: ATAPI, max UDMA/66
ata9.00: qc timeout (cmd 0xef)
ata9.00: failed to set xfermode (err_mask=0x4)
ata9.00: limiting speed to UDMA/44
ata9: failed to recover some devices, retrying in 5 secs
ata9.00: qc timeout (cmd 0xef)
ata9.00: failed to set xfermode (err_mask=0x4)
ata9.00: limiting speed to PIO0
ata9: failed to recover some devices, retrying in 5 secs
ata9.00: qc timeout (cmd 0xef)
ata9.00: failed to set xfermode (err_mask=0x4)
ata9.00: disabled
scsi9 : pata_jmicron
ATA: abnormal status 0x7F on port 0x00019807
1. Has it ever worked with the previous kernels?
2. If you connect a harddisk to pata_jmicron, does it work?
3. Does applying the attached patch fix your problem?
--
tejun
diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c
index 43763c9..8a95a56 100644
--- a/drivers/ata/pata_jmicron.c
+++ b/drivers/ata/pata_jmicron.c
@@ -196,7 +196,8 @@ static int jmicron_init_one (struct pci_dev *pdev, const struct pci_device_id *i
{
static struct ata_port_info info = {
.sht = jmicron_sht,
- .flags = ATA_FLAG_SLAVE_POSS | ATA_FLAG_SRST,
+ .flags = ATA_FLAG_SLAVE_POSS | ATA_FLAG_SRST |
+ ATA_FLAG_SETXFER_POLLING,
.pio_mask = 0x1f,
.mwdma_mask = 0x07,
Re: 2.6.21-rc1: framebuffer/console boot failure
On Sun, 2007-03-04 at 14:52 +, Andrew Nelless wrote: On Mon, February 26, 2007 11:09 pm, Antonino A. Daplas wrote: Not sure if the timer override workaround for nvidia chipsets is the culprit, but if you want, you can choose to revert that to the previous behavior (which is ignoring ACPI timer override). Open arch/x86_64/kernel/earlyquirk.c:nvidia_bugs() and change this line: if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) return; into this: acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check); /* return; */ Tony This fixes the problem. After a lot of rebooting and testing the problem is definitely gone when this check is patched out and the ACPI timer override is ignored. It looks like there should be a cleaner patch than just obliterating the condition and return though. Perhaps the code should remain as is and acpi_use_timer_override could be complimented by exposing the acpi_skip_timer_override option to the kernel command line? acpi_skip_timer_override is still documented in Documentation/kernel-parameters.txt. Tony - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
Chip Coldwell wrote:
On Wed, 17 Jan 2007, Andi Kleen wrote:
On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
I agree,... it seems drastic, but this is the only really secure
solution.
I'd like to here from Andi how he feels about this? It seems like a
somewhat drastic solution in some ways given a lot of hardware doesn't
seem to be affected (or maybe in those cases it's just really hard to
hit, I don't know).
AMD is looking at the issue. Only Nvidia chipsets seem to be affected,
although there were similar problems on VIA in the past too.
Unless a good workaround comes around soon I'll probably default
to iommu=soft on Nvidia.
We (Sun, AMD, Nvidia and Red Hat) have been testing a patch that seems
to solve the problem. AMD and Nvidia analyzed an HDT trace that
seemed to indicate that CPU updates of the GATT were still in cache
when a subsequent table walk caused by a device load used a stale GATT
PTE. That analysis inspired this patch, submitted to this list as an
RFC. It is not obvious (to me, at least) why this problem has only
shown up on Nvidia SATA controllers.
We are continuing to investigate.
diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c
index 030eb37..1dd461a 100644
--- a/arch/x86_64/kernel/pci-gart.c
+++ b/arch/x86_64/kernel/pci-gart.c
@@ -69,6 +69,8 @@ static u32 gart_unmapped_entry;
#define AGPEXTERN
#endif
+#define GATT_CLFLUSH(i) asm volatile (clflush (%0) :: r (iommu_gatt_base + (i)))
+
/* backdoor interface to AGP driver */
AGPEXTERN int agp_memory_reserved;
AGPEXTERN __u32 *agp_gatt_table;
@@ -221,6 +223,7 @@ static dma_addr_t dma_map_area(struct device *dev,
dma_addr_t phys_mem,
for (i = 0; i npages; i++) {
iommu_gatt_base[iommu_page + i] = GPTE_ENCODE(phys_mem);
SET_LEAK(iommu_page + i);
+ GATT_CLFLUSH(iommu_page + i);
phys_mem += PAGE_SIZE;
}
return iommu_bus_base + iommu_page*PAGE_SIZE + (phys_mem ~PAGE_MASK);
@@ -348,6 +351,7 @@ static int __dma_map_cont(struct scatterlist *sg, int
start, int stopat,
while (pages--) {
iommu_gatt_base[iommu_page] = GPTE_ENCODE(addr);
SET_LEAK(iommu_page);
+ GATT_CLFLUSH(iommu_page);
addr += PAGE_SIZE;
iommu_page++;
}
Andi, have you had a look at this? I'm a bit surprised at the lack of
reaction to this find..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.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 -mm 1/5] Blackfin: blackfin architecture patch update
On 3/4/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
On Thursday 01 March 2007 05:14:40 Wu, Bryan wrote:
Here is the update version of blackfin-arch.patch in -mm tree.
simply add support to utrace and it was tested on blackfin STAMP board
as well as other following patches.
Wow, this has come a long way since I looked at the patches last
year, good work!
I've gone through the complete patch again now, and these are the
issues I've found in it. None of these are show-stoppers and I'd
like to see it all go in during the next merge window. There should
be enough time until then to address these points:
+EXPORT_SYMBOL(__ioremap);
+EXPORT_SYMBOL(strcmp);
+EXPORT_SYMBOL(strncmp);
+EXPORT_SYMBOL(dump_thread);
+
+EXPORT_SYMBOL(ip_fast_csum);
+
+EXPORT_SYMBOL(kernel_thread);
+
+EXPORT_SYMBOL(__up);
+EXPORT_SYMBOL(__down);
+EXPORT_SYMBOL(__down_trylock);
+EXPORT_SYMBOL(__down_interruptible);
+
+EXPORT_SYMBOL(is_in_rom);
In general, please put EXPORT_SYMBOL lines below the definition
of the symbol itself. This list of exports should only be used
for symbols that come from assembly files.
What is the right way to export symbol coming from c files?
You should probably also think about whether some of them are
better done as EXPORT_SYMBOL_GPL.
It is probably not. We need code using those symbols, no matter it's
non-GPLd or GPLd.
+ pending = bfin_read_IPEND() ~0x8000;
+ other_ints = pending (pending - 1);
+ if (other_ints == 0)
+ lower_to_irq14();
+ irq_exit();
+
The last line here has trailing whitespace. While this gets automatically
removed by akpm's scripts, you're normally better off not adding it
in the first place, because it may cause your follow-on patches not
to apply, aside from being wrong to start with.
+void machine_halt(void)
+{
+ for (;;)
+ /* nothing */ ;
+}
+
+void machine_power_off(void)
+{
+ for (;;)
+ /* nothing */ ;
+}
It might be nicer to make this
for (;;)
asm volatile (idle);
Otherwise you end up burning CPU cycles after a halt without
any particular need.
Good suggestion, thanks.
+#if defined(CONFIG_MTD_UCLINUX)
+ /* generic memory mapped MTD driver */
+ memory_mtd_end = memory_end;
+
+ mtd_phys = _ramstart;
+ mtd_size = PAGE_ALIGN(*((unsigned long *)(mtd_phys + 8)));
+
+# if defined(CONFIG_EXT2_FS) || defined(CONFIG_EXT3_FS)
+ if (*((unsigned short *)(mtd_phys + 0x438)) == EXT2_SUPER_MAGIC)
+ mtd_size =
+ PAGE_ALIGN(*((unsigned long *)(mtd_phys + 0x404)) 10);
+# endif
+
+# if defined(CONFIG_CRAMFS)
+ if (*((unsigned long *)(mtd_phys)) == CRAMFS_MAGIC)
+ mtd_size = PAGE_ALIGN(*((unsigned long *)(mtd_phys + 0x4)));
+# endif
+
+# if defined(CONFIG_ROMFS_FS)
+ if (((unsigned long *)mtd_phys)[0] == ROMSB_WORD0
+ ((unsigned long *)mtd_phys)[1] == ROMSB_WORD1)
+ mtd_size =
+ PAGE_ALIGN(be32_to_cpu(((unsigned long *)mtd_phys)[2]));
This detection seems to me like a strange thing to do in setup_arch().
It should be possible to do this much later, at a point where the system
is much less fragile and e.g. printk works. It could even be moved into
some place in the mtd code itself, since other architectures might want
to do the same thing.
After download the rootfs image from host to the target ram, we need
to move the image to the right place, so we need to know the size of
the image at this time.
+#if defined(CONFIG_BF561)
+static struct cpu cpu[2];
+#else
+static struct cpu cpu[1];
+#endif
+static int __init topology_init(void)
+{
+#if defined (CONFIG_BF561)
+ register_cpu(cpu[0], 0);
+ register_cpu(cpu[1], 1);
+ return 0;
+#else
+ return register_cpu(cpu, 0);
+#endif
+}
I think you should try to avoid the special-case stuff here. You can
have CONFIG_NR_CPUS in Kconfig set dependent on CONFIG_BF561 and change
the code here (and similarly in other places) to
static struct cpu cpu[NR_CPUS];
static int __init topology_init(void)
{
int i;
for (i=0; i NR_CPUS; i++) {
register_cpu(cpu[i], i);
return 0;
}
Good suggestions, thanks.
+ for (i = ZERO_P; i = L2_MEM; i++) {
+
+ if (cplb_data[i].valid) {
+
+ as_1m = cplb_data[i].start % SIZE_1M;
+
+ /* We need to make sure all sections are properly 1M
aligned
+ * However between Kernel Memory and the Kernel mtd
section, depending
on the
+ * rootfs size, there can be overlapping memory areas.
+ */
+
+ if (as_1m) {
+#ifdef CONFIG_MTD_UCLINUX
+ if (i == SDRAM_RAM_MTD) {
+ if ((cplb_data[SDRAM_KERN].end + 1)
cplb_data[SDRAM_RAM_MTD].start)
+
Re: [RFC] hwbkpt: Hardware breakpoints (was Kwatch)
Thanks, Alan. Great work. I have some suggestions for changes.
I pretty much copied the existing code for handling vm86 mode
and single-step exceptions, without fully understanding it.
The code doesn't virtualize the BS (single-step) flag in DR6
for userspace. It could be added, but I wonder whether it is
really needed.
There is only one TF flag, it and the DR_STEP bit in dr6 are part of the
unitary thread state. You should not be doing anything at all on
single-step exceptions.
Setting user breakpoints on I/O ports should require permissions
checking. I haven't tried to figure out how that works or
how to implement it yet.
I would just leave the I/O breakpoint feature out for the first cut.
See if there is demand for it.
It requires setting CR4.DE, which we don't do. The validation is
relatively simple, comparing against the io_bitmap_ptr data (if any).
You can check at insertion time (requiring doing ioperm before inserting
an I/O breakpoint), and then check again at exception time if the hit
was in kernel mode and ignore it for a user-only breakpoint, or perhaps
check again and eject the breakpoint if it's been cleared from the
ioperm bitmap.
It seems likely that some of the new routines should be marked
__kprobes, but I don't know which, or even what that annotation
is supposed to mean.
That annotation is for code that is in the kprobes maintenance code path
(where you cannot insert kprobes). do_debug has it for the notify_die
path that might lead to kprobes. The only thing in your code that
should need it is your notifier function, which might get called for an
exception that turns out to be a kprobes single-step. There shouldn't
be any problem inserting kprobes into the other hwbkpt code.
The parts relating to kernel breakpoints could be made conditional
on a Kconfig option. The amount of code space saved would be
relatively small; I'm not sure that it would be worthwhile.
In a utrace merge, the user parts can be made conditional on CONFIG_UTRACE.
Then with both turned off, the code goes away completely. It's unlikely it
will ever be turned off, but it is a clean way to go about things in case
someone wants the smallest possible config for a limited-use installation.
+ void(*installed)(struct hwbkpt *);
+ void(*uninstalled)(struct hwbkpt *);
Save space in the struct by having just one function for both installed
and uninstalled, taking an argument. Probably a caller should be able to
pass a null function here to say that the registration call should fail if
it can't be installed due to higher-priority or no-callback registrations
existing, and that its registration cannot be ejected by another (i.e., an
ill-behaved user).
+ void*data;
Leave this out. Let the caller embed struct hwbkpt in his larger struct
and use container_of.
+/*
+ * The tsk argument in the following three routines will usually be a
+ * process being PTRACEd by the current task, normally a debugger.
+ * It is also legal for tsk to be the current task. In either case we
+ * can guarantee that tsk will not start running on another CPU while
+ * its breakpoints are being modified. If that happened it could cause
+ * a crash.
+ */
+int register_user_hwbkpt(struct task_struct *tsk, struct hwbkpt *bp);
+void unregister_user_hwbkpt(struct task_struct *tsk, struct hwbkpt *bp);
+int modify_user_hwbkpt(struct task_struct *tsk, struct hwbkpt *bp,
+ void *address, u8 len, u8 type);
These are the kinds of constraints utrace is there to make doable.
(I'm assuming that guarantee is really will not start running in
user mode, since SIGKILL is always possible.) In a utrace merge,
I think we want the only entry points for this to be a utrace-based
interface that explicitly requires utrace's notion of quiescence
(as its accessors for thread register data do).
+/*
+ * Kernel breakpoints are not associated with any particular thread.
+ */
+int register_kernel_hwbkpt(struct hwbkpt *bp);
+void unregister_kernel_hwbkpt(struct hwbkpt *bp);
Potentially kernel users might want per-thread installations, if
it's simple to provide the option. e.g., a probe at some syscall
entry that installs a watchpoint while calling into complex
subsystems, and then removes it before returning.
@@ -379,15 +381,15 @@ void exit_thread(void)
tss-io_bitmap_base = INVALID_IO_BITMAP_OFFSET;
put_cpu();
}
+ flush_thread_hwbkpt(tsk);
I'd make this do if (unlikely(test_tsk_thread_flag(tsk, TIF_DEBUG))),
or make it an inline doing that test before calling out to the guts.
Most of the time the hwbkpt code need not be on a hot path, and the
exit path will be one.
+struct thread_hwbkpt { /* HW breakpoint info for a thread */
+
+ /* utrace support */
+ struct list_headnode; /* Entry in
Re: [v4l-dvb-maintainer] [-mm patch] drivers/media/video/ivtv/: possible cleanups
On Monday 05 March 2007 02:49, Adrian Bunk wrote:
On Fri, Mar 02, 2007 at 03:00:26AM -0800, Andrew Morton wrote:
...
Changes since 2.6.20-mm2:
...
git-dvb.patch
...
git trees
...
This patch contains the following possible cleanups:
- every file should #include the headers containing the prototypes
for it's global functions
- make the following needlessly global variables static:
- ivtv-driver.c: newi2c
- ivtv-streams.c: struct ivtv_stream_info[]
- make the following needlessly global functions static:
- ivtv-fileops.c: ivtv_stop_decoding()
- ivtv-i2c.c: ivtv_i2c_id_addr()
- #if 0 the following unused global functions:
- ivtv-i2c.c: ivtv_msp34xx()
- ivtv-udma.c: ivtv_udma_setup()
- ivtv-video.c: ivtv_encoder_enable()
- ivtv-driver.c: remove the unused EXPORT_SYMBOL's
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
NACK.
A patch to fix the needlessly global functions is already in v4l-dvb,
and the 'unused EXPORT_SYMBOLs' ARE in fact used by the ivtv-fb
framebuffer. This module is not yet in the kernel, although I hope to
do that for 2.6.22.
Regards,
Hans
---
drivers/media/video/ivtv/ivtv-driver.c | 16 +---
drivers/media/video/ivtv/ivtv-fileops.c |2 +-
drivers/media/video/ivtv/ivtv-fileops.h |1 -
drivers/media/video/ivtv/ivtv-i2c.c |5 -
drivers/media/video/ivtv/ivtv-i2c.h |2 --
drivers/media/video/ivtv/ivtv-streams.c |2 +-
drivers/media/video/ivtv/ivtv-udma.c|2 ++
drivers/media/video/ivtv/ivtv-udma.h|2 --
drivers/media/video/ivtv/ivtv-video.c |2 ++
drivers/media/video/ivtv/ivtv-video.h |1 -
drivers/media/video/ivtv/ivtv-yuv.c |1 +
11 files changed, 12 insertions(+), 24 deletions(-)
---
linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-driver.c.old 2007-
03-04 21:00:12.0 +0100 +++
linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-driver.c 2007-03-0
4 21:04:50.0 +0100 @@ -121,7 +121,7 @@
int ivtv_debug = 0;
-int newi2c = -1;
+static int newi2c = -1;
module_param_array(tuner, int, tuner_c, 0644);
module_param_array(radio, bool, radio_c, 0644);
@@ -1367,19 +1367,5 @@
pci_unregister_driver(ivtv_pci_driver);
}
-EXPORT_SYMBOL(ivtv_set_irq_mask);
-EXPORT_SYMBOL(ivtv_cards_active);
-EXPORT_SYMBOL(ivtv_cards);
-EXPORT_SYMBOL(ivtv_api);
-EXPORT_SYMBOL(ivtv_vapi);
-EXPORT_SYMBOL(ivtv_vapi_result);
-EXPORT_SYMBOL(ivtv_clear_irq_mask);
-EXPORT_SYMBOL(ivtv_debug);
-EXPORT_SYMBOL(ivtv_reset_ir_gpio);
-EXPORT_SYMBOL(ivtv_udma_setup);
-EXPORT_SYMBOL(ivtv_udma_unmap);
-EXPORT_SYMBOL(ivtv_udma_alloc);
-EXPORT_SYMBOL(ivtv_udma_prepare);
-
module_init(module_start);
module_exit(module_cleanup);
---
linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-fileops.h.old 2007
-03-04 21:00:35.0 +0100 +++
linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-fileops.h 2007-03-
04 21:00:41.0 +0100 @@ -30,7 +30,6 @@
int ivtv_start_capture(struct ivtv_open_id *id);
void ivtv_stop_capture(struct ivtv_open_id *id, int gop_end);
int ivtv_start_decoding(struct ivtv_open_id *id, int speed);
-void ivtv_stop_decoding(struct ivtv_open_id *id, int flags, u64
pts); void ivtv_mute(struct ivtv *itv);
void ivtv_unmute(struct ivtv *itv);
---
linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-fileops.c.old 2007
-03-04 21:00:50.0 +0100 +++
linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-fileops.c 2007-03-
04 21:01:01.0 +0100 @@ -730,7 +730,7 @@
ivtv_release_stream(s);
}
-void ivtv_stop_decoding(struct ivtv_open_id *id, int flags, u64 pts)
+static void ivtv_stop_decoding(struct ivtv_open_id *id, int flags,
u64 pts) {
struct ivtv *itv = id-itv;
struct ivtv_stream *s = itv-streams[id-type];
---
linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-i2c.h.old 2007-03-
04 21:01:31.0 +0100 +++
linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-i2c.h 2007-03-04
21:02:07.0 +0100 @@ -22,11 +22,9 @@
int ivtv_saa7115(struct ivtv *itv, unsigned int cmd, void *arg);
int ivtv_saa7127(struct ivtv *itv, unsigned int cmd, void *arg);
int ivtv_saa717x(struct ivtv *itv, unsigned int cmd, void *arg);
-int ivtv_msp34xx(struct ivtv *itv, unsigned int cmd, void *arg);
int ivtv_upd64031a(struct ivtv *itv, unsigned int cmd, void *arg);
int ivtv_upd64083(struct ivtv *itv, unsigned int cmd, void *arg);
-int ivtv_i2c_id_addr(struct ivtv *itv, u32 id);
int ivtv_i2c_hw_addr(struct ivtv *itv, u32 hw);
int ivtv_i2c_hw(struct ivtv *itv, u32 hw, unsigned int cmd, void
*arg); int ivtv_i2c_id(struct ivtv *itv, u32 id, unsigned int cmd,
void *arg); ---
linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-i2c.c.old 2007-03-
04 21:01:43.0 +0100 +++
linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-i2c.c 2007-03-04
21:27:22.0 +0100 @@ -62,6 +62,7 @@
#include ivtv-driver.h
#include ivtv-cards.h
#include
[PATCH -mm] Blackfin: blackfin utrace patch
Hi folks,
As utrace is very promising in the -mm tree, a simple support is added
to blackfin architecture. I send this patch out just for review and it
is only a start point, we will make it fully work in the future.
Now after applying this patch, the blackfin-arch can be compile in the
2.6.21-rc2-mm1 with utrace enabled and ptrace disabled.
[PATCH -mm] Blackfin: blackfin utrace patch
This patch adds support utrace in blackfin architecture.
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
arch/blackfin/kernel/asm-offsets.c |2
arch/blackfin/kernel/ptrace.c |8 +++
include/asm-blackfin/thread_info.h |2
include/asm-blackfin/tracehook.h | 79 +
4 files changed, 91 insertions(+)
diff -uprN linux-2.6-orig/arch/blackfin/kernel/asm-offsets.c
linux-2.6/arch/blackfin/kernel/asm-offsets.c
--- linux-2.6-orig/arch/blackfin/kernel/asm-offsets.c 2007-03-05
11:50:21.0 +0800
+++ linux-2.6/arch/blackfin/kernel/asm-offsets.c2007-03-05
11:57:23.0 +0800
@@ -45,7 +45,9 @@ int main(void)
/* offsets into the task struct */
DEFINE(TASK_STATE, offsetof(struct task_struct, state));
DEFINE(TASK_FLAGS, offsetof(struct task_struct, flags));
+#if 0
DEFINE(TASK_PTRACE, offsetof(struct task_struct, ptrace));
+#endif
DEFINE(TASK_BLOCKED, offsetof(struct task_struct, blocked));
DEFINE(TASK_THREAD, offsetof(struct task_struct, thread));
DEFINE(TASK_THREAD_INFO, offsetof(struct task_struct, thread_info));
diff -uprN linux-2.6-orig/arch/blackfin/kernel/ptrace.c
linux-2.6/arch/blackfin/kernel/ptrace.c
--- linux-2.6-orig/arch/blackfin/kernel/ptrace.c2007-03-05
11:50:21.0 +0800
+++ linux-2.6/arch/blackfin/kernel/ptrace.c 2007-03-05 11:57:23.0
+0800
@@ -34,12 +34,14 @@
#include linux/mm.h
#include linux/smp.h
#include linux/smp_lock.h
+#include linux/tracehook.h
#include linux/errno.h
#include linux/ptrace.h
#include linux/user.h
#include linux/signal.h
#include asm/uaccess.h
+#include asm/tracehook.h
#include asm/page.h
#include asm/pgtable.h
#include asm/system.h
@@ -173,6 +175,8 @@ static inline int is_user_addr_valid(str
return -EIO;
}
+#ifdef CONFIG_PTRACE
+
/*
* Called by kernel/ptrace.c when detaching..
*
@@ -386,12 +390,15 @@ long arch_ptrace(struct task_struct *chi
return ret;
}
+#endif /* CONFIG_PTRACE */
+
asmlinkage void syscall_trace(void)
{
if (!test_thread_flag(TIF_SYSCALL_TRACE))
return;
+#if 0
if (!(current-ptrace PT_PTRACED))
return;
@@ -400,6 +407,7 @@ asmlinkage void syscall_trace(void)
*/
ptrace_notify(SIGTRAP | ((current-ptrace PT_TRACESYSGOOD)
? 0x80 : 0));
+#endif
/*
* this isn't the same as continuing with a signal, but it will do
diff -uprN linux-2.6-orig/include/asm-blackfin/thread_info.h
linux-2.6/include/asm-blackfin/thread_info.h
--- linux-2.6-orig/include/asm-blackfin/thread_info.h 2007-03-05
11:50:22.0 +0800
+++ linux-2.6/include/asm-blackfin/thread_info.h2007-03-05
11:57:23.0 +0800
@@ -127,6 +127,7 @@ static inline struct thread_info *curren
#define TIF_MEMDIE 5
#define TIF_RESTORE_SIGMASK6 /* restore signal mask in do_signal() */
#define TIF_FREEZE 7 /* is freezing for suspend */
+#define TIF_SINGLESTEP 8 /* restore singlestep on return to user
mode */
/* as above, but as bit values */
#define _TIF_SYSCALL_TRACE (1TIF_SYSCALL_TRACE)
@@ -136,6 +137,7 @@ static inline struct thread_info *curren
#define _TIF_POLLING_NRFLAG(1TIF_POLLING_NRFLAG)
#define _TIF_RESTORE_SIGMASK (1TIF_RESTORE_SIGMASK)
#define _TIF_FREEZE (1TIF_FREEZE)
+#define _TIF_SINGLESTEP(1TIF_SINGLESTEP)
#define _TIF_WORK_MASK 0xFFFE /* work to do on
interrupt/exception return */
diff -uprN linux-2.6-orig/include/asm-blackfin/tracehook.h
linux-2.6/include/asm-blackfin/tracehook.h
--- linux-2.6-orig/include/asm-blackfin/tracehook.h 1970-01-01
08:00:00.0 +0800
+++ linux-2.6/include/asm-blackfin/tracehook.h 2007-03-05 11:57:23.0
+0800
@@ -0,0 +1,79 @@
+/*
+ * Tracing hooks, Blackfin Architecture support
+ *
+ * Copyright (C) 2006, 2007 Analog Devices, Inc. All rights reserved.
+ * Copyright (C) 2006, 2007 Red Hat, Inc. All rights reserved.
+ *
+ * This copyrighted material is made available to anyone wishing to use,
+ * modify, copy, or redistribute it subject to the terms and conditions
+ * of the GNU General Public License v.2.
+ *
+ * ADI Author: Bryan Wu
+ * Red Hat Author: Roland McGrath.
+ */
+
+#ifndef _ASM_TRACEHOOK_H
+#define _ASM_TRACEHOOK_H 1
+
+#include linux/sched.h
+#include asm/ptrace.h
+
+/*
+ * See linux/tracehook.h for the descriptions of what these need to do.
+ */
+
+#define ARCH_HAS_SINGLE_STEP (1)
+
Re: [PATCH] highres: Do not run the TIMER_SOFTIRQ after switching to highres mode
* Andres Salomon [EMAIL PROTECTED] wrote: Thomas Gleixner wrote: The question is, how the tick timer gets enqueued in the softirq queue. Can you isolate the codepath, where this happens ? The TIMER_SOFTIRQ runs the hrtimers during bootup until a usable clocksource and clock event sources are registered. The switch to high resolution mode happens inside of the TIMER_SOFTIRQ, but runs the softirq afterwards. That way the tick emulation timer, which was set up in the switch to highres might be executed in the softirq context, which is a BUG. The rbtree has not to be touched by the softirq after the highres switch. And an additional request, just to make it explicit that we should not have any NO_SOFTIRQ callbacks in the tree; BUG out if we encounter such a thing. please change it to WARN_ON_ONCE()... 'bug out' might mean: 'dead box'/'no resume'/'no bootup'. Ingo - 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 -mm 1/5] Blackfin: blackfin architecture patch update
On Sat, 2007-03-03 at 17:30 -0500, Arnd Bergmann wrote: On Thursday 01 March 2007 05:14:40 Wu, Bryan wrote: Here is the update version of blackfin-arch.patch in -mm tree. simply add support to utrace and it was tested on blackfin STAMP board as well as other following patches. Wow, this has come a long way since I looked at the patches last year, good work! Yeah, old friend comes back. Thanks a lot for your review. We fixed lots of things according to your review since last year. I've gone through the complete patch again now, and these are the issues I've found in it. None of these are show-stoppers and I'd like to see it all go in during the next merge window. There should be enough time until then to address these points: Lots of valuable comments got from you, we will get things done soon. So could please give us some information about the merge window schedule, we may try to catch this. + +/* Clock and System Control (0xFFC0 0400-0xFFC0 07FF) */ +#define bfin_read_PLL_CTL() bfin_read16(PLL_CTL) +#define bfin_write_PLL_CTL(val) bfin_write16(PLL_CTL,val) +#define bfin_read_PLL_STAT() bfin_read16(PLL_STAT) +#define bfin_write_PLL_STAT(val) bfin_write16(PLL_STAT,val) +#define bfin_read_PLL_LOCKCNT() bfin_read16(PLL_LOCKCNT) +#define bfin_write_PLL_LOCKCNT(val) bfin_write16(PLL_LOCKCNT,val) +#define bfin_read_CHIPID() bfin_read32(CHIPID) +#define bfin_read_SWRST()bfin_read16(SWRST) +#define bfin_write_SWRST(val) bfin_write16(SWRST,val) I remember that we have discussed these macro abstractions before, but don't recall the result of the discussion. You have around 5000 such macros, and I still think it's not a helpful abstraction. It is much more common for device drivers to just use the read/write accessors directly. IIRC the objections that were raised (and my replies to them) were roughly: the driver writer doesn't want to know the size of the variable, and if it changes, they need to change every instance in the code, not just the macro. A driver writer should better know the type of variable he is changing, e.g. because of the type he passes in and out. Also, hardware registers don't suddenly change in size. These macros allow us to work around hardware bugs when accessing the registers by simply redefining the accessor to do something more complex. If there is a bug in the hardware, the workaround belongs into the driver. You can then still define a special inline function to access that particular register. Oh, if we should fix this issue, there are lots of work to do because tons of drivers rely on this. Maybe after some team internal discussion, we will give a solution to this. Thanks again Best Regards, -Bryan Wu - 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] Fixes and cleanups for earlyprintk aka boot console.
Paul Mackerras wrote: Gerd Hoffmann writes: This patch fixes the console selection code to *not* consider a boot console a full-featured one, so the first non-boot console registering will become the default console instead. This way the unregister call for the boot console in the register_console() function actually triggers and the handover from the boot console to the real console device works smoothly. Added a printk for the handover, so you know which console device the output goes to when the boot console stops printing messages. You have removed functionality that is useful for debugging, that 3 architectures had, namely a way to keep using the early boot console and not replace it with a console that comes later, using a kernel command line option. Perhaps you could provide a way to do that in your patch. --verbose please. I don't think I broke that. I've seen code for that in i386/x86_64 and one of the other archs (via earlyprintk=foo,keep). The code clears now the CON_BOOT flag in case keep is present, which has the wanted effect: The earlyprintk console will not be replaced. cheers, Gerd -- Gerd Hoffmann [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] highres: Do not run the TIMER_SOFTIRQ after switching to highres mode
Ingo Molnar wrote: * Andres Salomon [EMAIL PROTECTED] wrote: Thomas Gleixner wrote: The question is, how the tick timer gets enqueued in the softirq queue. Can you isolate the codepath, where this happens ? The TIMER_SOFTIRQ runs the hrtimers during bootup until a usable clocksource and clock event sources are registered. The switch to high resolution mode happens inside of the TIMER_SOFTIRQ, but runs the softirq afterwards. That way the tick emulation timer, which was set up in the switch to highres might be executed in the softirq context, which is a BUG. The rbtree has not to be touched by the softirq after the highres switch. And an additional request, just to make it explicit that we should not have any NO_SOFTIRQ callbacks in the tree; BUG out if we encounter such a thing. please change it to WARN_ON_ONCE()... 'bug out' might mean: 'dead box'/'no resume'/'no bootup'. Ingo Certainly; note that hrtimers.c has quite a few BUG calls which could render a box dead, though. Patch to follow.. - 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] ext3: dirindex error pointer issues
Andreas Dilger [EMAIL PROTECTED] writes:
On Mar 04, 2007 17:18 +0300, Dmitriy Monakhov wrote:
- ext3_dx_find_entry() exit with out setting proper error pointer
- do_split() exit with out setting proper error pointer
it is realy painful because many callers contain folowing code:
de = do_split(handle,dir, bh, frame, hinfo, retval);
if (!(de))
return retval;
WOW retval wasn't changed by do_split(), so caller failed
but return SUCCESS :)
- Rearrange do_split() error path. Current error path is realy ugly, all
this up and down jump stuff doesn't make code easy to understand.
Signed-off-by: Monakhov Dmitriy [EMAIL PROTECTED]
---
fs/ext3/namei.c | 26 +++---
fs/ext4/namei.c | 26 +++---
2 files changed, 30 insertions(+), 22 deletions(-)
diff --git a/fs/ext3/namei.c b/fs/ext3/namei.c
index 49159f1..1a52586 100644
--- a/fs/ext3/namei.c
+++ b/fs/ext3/namei.c
@@ -969,6 +969,7 @@ static struct buffer_head * ext3_dx_find_entry(struct
dentry *dentry,
(blockEXT3_BLOCK_SIZE_BITS(sb))
+((char *)de - bh-b_data))) {
brelse (bh);
+*err = ERR_BAD_DX_DIR;
goto errout;
}
*res_dir = de;
I have no objection to this change (by principle of least surprise) but
I don't know if it fixes a real problem. The one caller of this function
treats ERR_BAD_DX_DIR the same as bh == NULL.
Execly ERR_BAD_DX_DIR treats the same as bh == NULL and let's look at
callers code:
struct buffer_head * ext3_find_entry(..)
{
...
bh = ext3_dx_find_entry(dentry, res_dir, err);
/*
* On success, or if the error was file not found,
* return. Otherwise, fall back to doing a search the
* old fashioned way.
*/
if (bh || (err != ERR_BAD_DX_DIR))
after ext3_dx_find_entry() has failed , but don't set err pointer
we get (bh == NULL, err == 0) , and then just return NULL.
return bh;
...
}
@@ -1134,9 +1135,9 @@ static struct ext3_dir_entry_2 *do_split(handle_t
*handle, struct inode *dir,
char *data1 = (*bh)-b_data, *data2;
unsigned split;
struct ext3_dir_entry_2 *de = NULL, *de2;
-int err;
+int err = 0;
-bh2 = ext3_append (handle, dir, newblock, error);
+bh2 = ext3_append (handle, dir, newblock, err);
Why don't we just remove err entirely and use *error to avoid any risk
of setting err and not returning it in error? Also reduces stack usage
that tiny little bit.
I've chosen this approuch becouse of:
1) this approuch was used in block allocation code.
2) this approuch prevent folowing errors:
*error = do_some_function(.)
/* some code*/
if(error)
we do this checking as we do it thousands times before, but forget
what error it pointer here. And compiler can't warn us here because
it is absolutely legal operation. At least it is better to rename
error to errorp.
Btw: I've thought about adding assertations to error path witch may check
what errp pointer was properly initialized after error happends.
folowing code is draft only:
--- a/fs/ext3/namei.c
+++ b/fs/ext3/namei.c
@@ -63,6 +63,7 @@ static struct buffer_head *ext3_append(handle_t *handle,
EXT3_I(inode)-i_disksize = inode-i_size;
ext3_journal_get_write_access(handle,bh);
}
+ assert(bh || *err);
return bh;
}
@@ -433,6 +434,7 @@ fail2:
frame--;
}
fail:
+ assert(*err != 0);
return NULL;
}
In ext3_dx_add_entry() it appears like we should goto journal_error
to report an error after the failed call to do_split(), instead of just
goto cleanup so that we report an error in the filesystem. Not 100%
sure of this.
do_split() already invoked ext3_std_error() on it's journal_error path.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
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/
-
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] usb/hid:Microsoft Natural Ergonomic Keyboard 4000 Driver 0.5.0
Changelogs:
1. Port to HID simple driver layer 0.5.0.
It can be applied on 2.6.21 at least.
Signed-off-by: Liyu [EMAIL PROTECTED]
--- linux-2.6.18/drivers/usb/input.orig/usbnek4k.c 1970-01-01
08:00:00.0 +0800
+++ linux-2.6.18/drivers/usb/input/usbnek4k.c 2006-10-12 13:29:28.0
+0800
@@ -0,0 +1,252 @@
+/*
+ * Microsoft Natural Ergonomic Keyboard 4000 Driver
+ *
+ * Version: 0.4.0
+ *
+ * Copyright (c) 2006 Li Yu [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.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/input.h
+#include hid.h
+#include hid-simple.h
+
+static int ascii_keycode;
+module_param(ascii_keycode, bool, 0444);
+MODULE_PARM_DESC(ascii_keycode, Only yield ASCII keycodes when turn on this,
default=n);
+
+#define USAGE_ZOOM_IN 0x22d
+#define USAGE_ZOOM_OUT 0x22e
+#define USAGE_HOME 0x223
+#define USAGE_SEARCH 0x221
+#define USAGE_EMAIL0x18a
+#define USAGE_FAVORITES0x182
+#define USAGE_MUTE 0xe2
+#define USAGE_VOLUME_DOWN 0xea
+#define USAGE_VOLUME_UP0xe9
+#define USAGE_PLAY_PAUSE 0xcd
+#define USAGE_CALCULATOR 0x192
+#define USAGE_BACK 0x224
+#define USAGE_FORWARD 0x225
+#define USAGE_CUSTOM 0xff05
+
+#define USAGE_CUSTOM_RELEASE 0x0
+#define USAGE_CUSTOM_1 0x1
+#define USAGE_CUSTOM_2 0x2
+#define USAGE_CUSTOM_3 0x4
+#define USAGE_CUSTOM_4 0x8
+#define USAGE_CUSTOM_5 0x10
+
+#define USAGE_HELP 0x95
+#define USAGE_UNDO 0x21a
+#define USAGE_REDO 0x279
+#define USAGE_NEW 0x201
+#define USAGE_OPEN 0x202
+#define USAGE_CLOSE0x203
+
+#define USAGE_REPLY0x289
+#define USAGE_FWD 0x28b
+#define USAGE_SEND 0x28c
+#define USAGE_SPELL0x1ab
+#define USAGE_SAVE 0x207
+#define USAGE_PRINT0x208
+
+#define USAGE_KEYPAD_EQUAL 0x67
+#define USAGE_KEYPAD_LEFT_PAREN0xb6
+#define USAGE_KEYPAD_RIGHT_PAREN 0xb7
+
+#define MSNEK4K_ID_VENDOR 0x045e
+#define MSNEK4K_ID_PRODUCT 0x00db
+
+#define map_key(c) do { usage-code = c; usage-type = EV_KEY;
set_bit(c,input-keybit); } while (0)
+#define clear_key(c) do { usage-code = 0; usage-type = 0;
clear_bit(c,input-keybit); } while (0)
+
+static struct usb_device_id nek4k_id_table[] = {
+ { USB_DEVICE(MSNEK4K_ID_VENDOR, MSNEK4K_ID_PRODUCT) },
+ {}
+};
+
+MODULE_DEVICE_TABLE(usb, nek4k_id_table);
+MODULE_DESCRIPTION(Microsoft Natural Ergonomic Keyboard 4000 Driver);
+MODULE_VERSION(0.4.0);
+
+struct usage_block consumer_usage_block[] = {
+ USAGE_BLOCK(USAGE_ZOOM_IN, 0, EV_KEY, KEY_F13, 0),
+ USAGE_BLOCK(USAGE_ZOOM_OUT, 0, EV_KEY, KEY_F14, 0),
+ USAGE_BLOCK(USAGE_HOME, 0, EV_KEY, KEY_HOMEPAGE, 0),
+ USAGE_BLOCK(USAGE_SEARCH, 0, EV_KEY, KEY_SEARCH, 0),
+ USAGE_BLOCK(USAGE_EMAIL, 0, EV_KEY, KEY_EMAIL, 0),
+ USAGE_BLOCK(USAGE_MUTE, 0, EV_KEY, KEY_MUTE, 0),
+ USAGE_BLOCK(USAGE_VOLUME_DOWN, 0, EV_KEY, KEY_VOLUMEDOWN, 0),
+ USAGE_BLOCK(USAGE_VOLUME_UP, 0, EV_KEY, KEY_VOLUMEUP, 0),
+ USAGE_BLOCK(USAGE_PLAY_PAUSE, 0, EV_KEY, KEY_PLAYPAUSE, 0),
+ USAGE_BLOCK(USAGE_CALCULATOR, 0, EV_KEY, KEY_CALC, 0),
+ USAGE_BLOCK(USAGE_BACK, 0, EV_KEY, KEY_BACK, 0),
+ USAGE_BLOCK(USAGE_FORWARD, 0, EV_KEY, KEY_FORWARD, 0),
+ USAGE_BLOCK(USAGE_HELP, 0, EV_KEY, KEY_HELP, 0),
+ USAGE_BLOCK(USAGE_UNDO, 0, EV_KEY, KEY_UNDO, 0),
+ USAGE_BLOCK(USAGE_REDO, 0, EV_KEY, KEY_REDO, 0),
+ USAGE_BLOCK(USAGE_NEW, 0, EV_KEY, KEY_NEW, 0),
+ USAGE_BLOCK(USAGE_OPEN, 0, EV_KEY, KEY_OPEN, 0),
+ USAGE_BLOCK(USAGE_CLOSE, 0, EV_KEY, KEY_CLOSE, 0),
+ USAGE_BLOCK(USAGE_REPLY, 0, EV_KEY, KEY_REPLY, 0),
+ USAGE_BLOCK(USAGE_FWD, 0, EV_KEY, KEY_FORWARDMAIL, 0),
+ USAGE_BLOCK(USAGE_SEND, 0, EV_KEY, KEY_SEND, 0),
+ USAGE_BLOCK(USAGE_SPELL, 0, EV_KEY, KEY_F15, 0),
+ USAGE_BLOCK(USAGE_SAVE, 0, EV_KEY, KEY_SAVE, 0),
+ USAGE_BLOCK(USAGE_PRINT, 0, EV_KEY, KEY_PRINT, 0),
+ USAGE_BLOCK_NULL
+};
+
+struct usage_block msvendor_usage_block[] = {
+ USAGE_BLOCK(USAGE_CUSTOM, USAGE_CUSTOM_1, EV_KEY, KEY_FN_F1, 0),
+ USAGE_BLOCK(USAGE_CUSTOM, USAGE_CUSTOM_2, EV_KEY, KEY_FN_F2, 0),
+ USAGE_BLOCK(USAGE_CUSTOM, USAGE_CUSTOM_3, EV_KEY, KEY_FN_F3, 0),
+ USAGE_BLOCK(USAGE_CUSTOM, USAGE_CUSTOM_4, EV_KEY, KEY_FN_F4, 0),
+ USAGE_BLOCK(USAGE_CUSTOM, USAGE_CUSTOM_5, EV_KEY, KEY_FN_F5, 0),
+ USAGE_BLOCK_NULL
+};
+
+struct usage_block keyboard_usage_block[] = {
+ USAGE_BLOCK(USAGE_KEYPAD_EQUAL, 0, EV_KEY, KEY_KPEQUAL, 0),
+ USAGE_BLOCK(USAGE_KEYPAD_LEFT_PAREN, 0, EV_KEY, KEY_KPLEFTPAREN, 0),
+ USAGE_BLOCK(USAGE_KEYPAD_RIGHT_PAREN, 0, EV_KEY, KEY_KPRIGHTPAREN, 0),
+ USAGE_BLOCK_NULL
+};
+
+struct usage_page_block
[PATCH] usb/hid:The HID Simple Driver Patches 0.5.0 (all-in-one)
This patch set include follow patches:
1. [PATCH] usb/hid: The HID Simple Driver Interface 0.5.0 (core)
2. [PATCH] usb/hid:Microsoft Natural Ergonomic Keyboard 4000 Driver
0.5.0
3. Some related kbuild changes.
The code base is 2.6.21-rc2
Signed-off-by: Liyu [EMAIL PROTECTED]
diff -Naurp linux-2.6.21-rc2.orig/include/linux/hid.h
linux-2.6.21-rc2/include/linux/hid.h
--- linux-2.6.21-rc2.orig/include/linux/hid.h 2007-03-05 09:09:35.0
+0800
+++ linux-2.6.21-rc2/include/linux/hid.h2007-03-05 11:17:22.0
+0800
@@ -35,6 +35,7 @@
#include linux/timer.h
#include linux/workqueue.h
#include linux/input.h
+#include linux/mutex.h
/*
* USB HID (Human Interface Device) interface class code
@@ -397,8 +398,15 @@ struct hid_input {
struct list_head list;
struct hid_report *report;
struct input_dev *input;
+ unsigned long input_lock; /* To protect accessing input_dev from
+* hid-input processing. But it not
+* necessary for accessing this
input_dev
+* instance from input subsystem. */
+ void *private;
};
+struct hidinput_simple_driver;
+
struct hid_device {/*
device report descriptor */
__u8 *rdesc;
unsigned rsize;
@@ -429,6 +437,8 @@ struct hid_device {
/* device repo
char phys[64]; /*
Device physical location */
char uniq[64]; /*
Device unique identifier (serial #) */
+ struct hidinput_simple_driver *simple;
+
void *driver_data;
/* device-specific function pointers */
@@ -483,6 +493,8 @@ extern void hidinput_hid_event(struct hi
extern void hidinput_report_event(struct hid_device *hid, struct hid_report
*report);
extern int hidinput_connect(struct hid_device *);
extern void hidinput_disconnect(struct hid_device *);
+extern void hidinput_reconnect_core(struct hid_device *);
+extern int hidinput_disconnect_core(struct hid_device *);
int hid_set_field(struct hid_field *, unsigned, __s32);
int hid_input_report(struct hid_device *, int type, u8 *, int, int);
diff -Naurp linux-2.6.21-rc2.orig/include/linux/hid-simple.h
linux-2.6.21-rc2/include/linux/hid-simple.h
--- linux-2.6.21-rc2.orig/include/linux/hid-simple.h1970-01-01
08:00:00.0 +0800
+++ linux-2.6.21-rc2/include/linux/hid-simple.h 2007-03-05 13:37:42.0
+0800
@@ -0,0 +1,260 @@
+/*
+ * NOTE:
+ * For use me , you must include hid.h in your source first.
+ */
+#ifndef __HID_SIMPLE_H
+#define __HID_SIMPLE_H
+
+#ifdef __KERNEL__
+
+#include asm/bitops.h
+/* The public interface for simple device driver */
+struct usage_block {
+ int usage; /* usage code */
+ int value; /* not used, for F_EVENT_BY_VALUE in future */
+ int event; /* input event type, e.g. EV_KEY. */
+ int code; /* input subsystem code, e.g. KEY_F1. */
+ int flags; /* not used */
+};
+
+struct usage_page_block {
+ int page; /* usage page code */
+ int flags; /* not used */
+ struct usage_block *usage_blockes;
+};
+
+extern struct mutex matched_devices_lock;
+extern struct mutex simple_drivers_lock;
+extern struct list_head simple_drivers_list;
+extern struct list_head matched_devices_list;
+
+/* usage_block flags list */
+#define F_EVENT_BY_VALUE (0x1) /* submit input event by usage_block.value,
+ not implement yet */
+
+#define USAGE_BLOCK(i_usage, i_value, i_event, i_code, i_flags) \
+ {\
+ .usage = (i_usage),\
+ .value = (i_value),\
+ .event = (i_event),\
+ .code = (i_code),\
+ .flags = (i_flags),\
+ }
+
+#define USAGE_BLOCK_NULL {}
+
+#define USAGE_PAGE_BLOCK(i_page, i_usage_blockes) \
+ {\
+ .page = (i_page),\
+ .usage_blockes = (i_usage_blockes),\
+ }
+
+#define USAGE_PAGE_BLOCK_NULL {}
+
+#define __SIMPLE_DRIVER_INIT \
+ .owner = THIS_MODULE,
+
+struct matched_device;
+
+struct hidinput_simple_driver {
+/* private */
+ struct list_head node; /* link with simple_drivers_list */
+ struct list_head raw_devices;
+ unsigned long flags;
+/* public for hid sub-layer, for example, USB. */
+ int (*match_device)(struct hidinput_simple_driver *drv,
+ struct matched_device *dev);
+/* public for drivers. */
+ struct module *owner;
+ char *name;
+ int (*connect)(struct hid_device *, struct hid_input *);
+ void (*disconnect)(struct hid_device *, struct hid_input *);
+ void (*setup_usage)(struct hid_field *, struct hid_usage *);
+ void (*clear_usage)(struct hid_field *, struct
[PATCH] usb/hid:The HID Simple Driver Interface 0.5.0 (core)
Changelogs (since 0.4.1):
1. port to 2.6.21.
2. One bugfix.
The code base is 2.6.21-rc2.
Signed-off-by: Liyu [EMAIL PROTECTED]
diff -Naurp linux-2.6.21-rc2.orig/include/linux/hid.h
linux-2.6.21-rc2/include/linux/hid.h
--- linux-2.6.21-rc2.orig/include/linux/hid.h 2007-03-05 09:09:35.0
+0800
+++ linux-2.6.21-rc2/include/linux/hid.h2007-03-05 11:17:22.0
+0800
@@ -35,6 +35,7 @@
#include linux/timer.h
#include linux/workqueue.h
#include linux/input.h
+#include linux/mutex.h
/*
* USB HID (Human Interface Device) interface class code
@@ -397,8 +398,15 @@ struct hid_input {
struct list_head list;
struct hid_report *report;
struct input_dev *input;
+ unsigned long input_lock; /* To protect accessing input_dev from
+* hid-input processing. But it not
+* necessary for accessing this
input_dev
+* instance from input subsystem. */
+ void *private;
};
+struct hidinput_simple_driver;
+
struct hid_device {/*
device report descriptor */
__u8 *rdesc;
unsigned rsize;
@@ -429,6 +437,8 @@ struct hid_device {
/* device repo
char phys[64]; /*
Device physical location */
char uniq[64]; /*
Device unique identifier (serial #) */
+ struct hidinput_simple_driver *simple;
+
void *driver_data;
/* device-specific function pointers */
@@ -483,6 +493,8 @@ extern void hidinput_hid_event(struct hi
extern void hidinput_report_event(struct hid_device *hid, struct hid_report
*report);
extern int hidinput_connect(struct hid_device *);
extern void hidinput_disconnect(struct hid_device *);
+extern void hidinput_reconnect_core(struct hid_device *);
+extern int hidinput_disconnect_core(struct hid_device *);
int hid_set_field(struct hid_field *, unsigned, __s32);
int hid_input_report(struct hid_device *, int type, u8 *, int, int);
diff -Naurp linux-2.6.21-rc2.orig/include/linux/hid-simple.h
linux-2.6.21-rc2/include/linux/hid-simple.h
--- linux-2.6.21-rc2.orig/include/linux/hid-simple.h1970-01-01
08:00:00.0 +0800
+++ linux-2.6.21-rc2/include/linux/hid-simple.h 2007-03-05 13:37:42.0
+0800
@@ -0,0 +1,260 @@
+/*
+ * NOTE:
+ * For use me , you must include hid.h in your source first.
+ */
+#ifndef __HID_SIMPLE_H
+#define __HID_SIMPLE_H
+
+#ifdef __KERNEL__
+
+#include asm/bitops.h
+/* The public interface for simple device driver */
+struct usage_block {
+ int usage; /* usage code */
+ int value; /* not used, for F_EVENT_BY_VALUE in future */
+ int event; /* input event type, e.g. EV_KEY. */
+ int code; /* input subsystem code, e.g. KEY_F1. */
+ int flags; /* not used */
+};
+
+struct usage_page_block {
+ int page; /* usage page code */
+ int flags; /* not used */
+ struct usage_block *usage_blockes;
+};
+
+extern struct mutex matched_devices_lock;
+extern struct mutex simple_drivers_lock;
+extern struct list_head simple_drivers_list;
+extern struct list_head matched_devices_list;
+
+/* usage_block flags list */
+#define F_EVENT_BY_VALUE (0x1) /* submit input event by usage_block.value,
+ not implement yet */
+
+#define USAGE_BLOCK(i_usage, i_value, i_event, i_code, i_flags) \
+ {\
+ .usage = (i_usage),\
+ .value = (i_value),\
+ .event = (i_event),\
+ .code = (i_code),\
+ .flags = (i_flags),\
+ }
+
+#define USAGE_BLOCK_NULL {}
+
+#define USAGE_PAGE_BLOCK(i_page, i_usage_blockes) \
+ {\
+ .page = (i_page),\
+ .usage_blockes = (i_usage_blockes),\
+ }
+
+#define USAGE_PAGE_BLOCK_NULL {}
+
+#define __SIMPLE_DRIVER_INIT \
+ .owner = THIS_MODULE,
+
+struct matched_device;
+
+struct hidinput_simple_driver {
+/* private */
+ struct list_head node; /* link with simple_drivers_list */
+ struct list_head raw_devices;
+ unsigned long flags;
+/* public for hid sub-layer, for example, USB. */
+ int (*match_device)(struct hidinput_simple_driver *drv,
+ struct matched_device *dev);
+/* public for drivers. */
+ struct module *owner;
+ char *name;
+ int (*connect)(struct hid_device *, struct hid_input *);
+ void (*disconnect)(struct hid_device *, struct hid_input *);
+ void (*setup_usage)(struct hid_field *, struct hid_usage *);
+ void (*clear_usage)(struct hid_field *, struct hid_usage *);
+ int (*pre_event)(const struct hid_device *, const struct hid_field *,
+ const struct hid_usage *, const
[DOC] The documentation for HID Simple Driver Interface 0.5.0
==
HID device simple driver interface
==
Note
If you just begin to study from writing input device driver, please see the
input-programming.txt, I am afraid this is not you want, do not confuse with the
simple in this name.
Version
This is used for the version 0.5.0
--
Overview
--
Under standard HID device driver development means, we need to write
one interrupt handler for each new HID device to report event to
input subsystem. However, although the most of they can not merge into
mainstream kernel tree, they have only some extended keys, e.g. many
remote controllers. I think it seem break a fly on the wheel, which
write one new interrupt handler for this reason.
The basic idea is reuse the interrupt handler in hid-core.c. so writing
driver for new simple HID device will be more easier, quickly, and do not
need touch hid core.
In essence, this interface just is some hooks in HID core.
The hid-simple.h include this API. But, defore use this interface, you must
include hid.h first.
What's you will get from this interface.
Use me, you can:
1. Write the driver of USB input device without write code take care of
details of setup and clear usage.
2. A driver use this interface can be as a HID device input filter.
This interface can not support the more drivers handle one device at same time
yet. I can not sure if we really need this feature.
-
Prepare
-
Before use this interface, you must turn on these kernel configuration
items:
CONFIG_HID_SIMPLE : HID simple driver interface
--
Register and unregister
--
1. Register a simple driver.
int hidinput_register_simple_driver(struct hidinput_simple_driver *simple)
Like any driver register function, it register your driver to kernel,
when the chance that match device come, your driver can probe it. At least, you
must fill the member of parameter simple : name.
Return 0 mean register successfully. elsewise mean there have some
failures in register process.
So far, this function only can return 0 and -EINVAL.
When you driver matched one device, it will reregister it into input
subsystem (see the function hidinput_reconnect_core(), if you want).
This function generally is used in HID sublayer.
2. Unregister a simple driver.
void hidinput_unregister_simple_driver(struct hidinput_simple_driver *simple)
Like any driver register function, it clean your driver from kernel, and
in this process, your driver will disconnect any device which it matched.
However,
it do not free your memory of driver structure, that's your task.
This may reregister the device into input subsystem (see the function
hidinput_reconnect_core(), if you want).
This function generally is used in HID sublayer.
3. USB device driver.
You should use follow functions for USB device. the usage of these functions
is
same with aboves.
int hidinput_register_simple_usb_driver(struct hidinput_simple_driver *simple)
void hidinput_unregister_simple_usb_driver(struct hidinput_simple_driver
*simple)
Both functions is used in driver.
--
Usage
--
Each simple driver have one data structure hidinput_simple_driver:
struct hidinput_simple_driver {
/*
* The members for implement only are ignored here,
* please do not depend on them
*/
/* public for HID sublayer. */
int (*match_device)(struct hidinput_simple_driver *drv,
struct matched_device *dev);
/* public for drivers */
struct module *owner;
char *name;
int (*connect)(struct hid_device *, struct hid_input *);
void (*disconnect)(struct hid_device *, struct hid_input *);
void (*setup_usage)(struct hid_field *, struct hid_usage *);
void (*clear_usage)(struct hid_field *, struct hid_usage *);
int (*pre_event)(const struct hid_device *, const struct hid_field *,
const struct hid_usage *, const __s32);
int (*post_event)(const struct hid_device *, const struct hid_field *,
const struct hid_usage *, const __s32);
int (*open)(struct input_dev *dev);
void (*close)(struct input_dev *dev);
void *private;
struct usb_device_id *id_table;
struct usage_page_block *usage_page_table;
};
The data member description:
struct module *owner;
In most cases, set this member to THIS_MODULE is your want to.
char *name;
The name of your driver. you must fill this member before register it.
void *private;
You can save the data that your driver use only here. HID simple driver
core do not take care of this.
struct usb_device_id *id_table;
As same with other USB device driver, this is used by
Re: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Sun, Mar 04, 2007 at 05:16:25PM -0800, Greg KH wrote: On Sun, Mar 04, 2007 at 04:08:57PM -0600, Matt Mackall wrote: Recent kernels are having troubles with wireless for me. Two seemingly related problems: a) NetworkManager seems oblivious to the existence of my IPW2200 b) Manual iwconfig waits for 60s and then reports: Error for wireless request Set Encode (8B2A) : SET failed on device eth1 ; Operation not supported. Do you have CONFIG_SYSFS_DEPRECATED enabled? If not, please do as that will keep you from having to change any userspace code. No, it's disabled. Will test once I'm done tracking down the iwconfig problem. From the help text for SYSFS_DEPRECATED: If you are using a distro that was released in 2006 or later, it should be safe to say N here. If we need an as-yet-unreleased HAL without it, I would say the above should be changed to 2008 or so. If Debian actually cuts a release in the next few months, you might make that 2010. -- Mathematics is the supreme nostalgia of our time. - 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: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Mon, Mar 05, 2007 at 12:42:29AM -0600, Matt Mackall wrote: On Sun, Mar 04, 2007 at 05:16:25PM -0800, Greg KH wrote: On Sun, Mar 04, 2007 at 04:08:57PM -0600, Matt Mackall wrote: Recent kernels are having troubles with wireless for me. Two seemingly related problems: a) NetworkManager seems oblivious to the existence of my IPW2200 b) Manual iwconfig waits for 60s and then reports: Error for wireless request Set Encode (8B2A) : SET failed on device eth1 ; Operation not supported. Do you have CONFIG_SYSFS_DEPRECATED enabled? If not, please do as that will keep you from having to change any userspace code. No, it's disabled. Will test once I'm done tracking down the iwconfig problem. From the help text for SYSFS_DEPRECATED: If you are using a distro that was released in 2006 or later, it should be safe to say N here. If we need an as-yet-unreleased HAL without it, I would say the above should be changed to 2008 or so. If Debian actually cuts a release in the next few months, you might make that 2010. Well, just because Debian has such a slow release cycle, should the rest of the world be forced to follow suit? :) When I originally wrote that, I thought Debian would have already done their release, my mistake... thanks, greg k-h - 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: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Sun, Mar 04, 2007 at 11:02:48PM -0800, Greg KH wrote: On Mon, Mar 05, 2007 at 12:42:29AM -0600, Matt Mackall wrote: On Sun, Mar 04, 2007 at 05:16:25PM -0800, Greg KH wrote: On Sun, Mar 04, 2007 at 04:08:57PM -0600, Matt Mackall wrote: Recent kernels are having troubles with wireless for me. Two seemingly related problems: a) NetworkManager seems oblivious to the existence of my IPW2200 b) Manual iwconfig waits for 60s and then reports: Error for wireless request Set Encode (8B2A) : SET failed on device eth1 ; Operation not supported. Do you have CONFIG_SYSFS_DEPRECATED enabled? If not, please do as that will keep you from having to change any userspace code. No, it's disabled. Will test once I'm done tracking down the iwconfig problem. From the help text for SYSFS_DEPRECATED: If you are using a distro that was released in 2006 or later, it should be safe to say N here. If we need an as-yet-unreleased HAL without it, I would say the above should be changed to 2008 or so. If Debian actually cuts a release in the next few months, you might make that 2010. Well, just because Debian has such a slow release cycle, should the rest of the world be forced to follow suit? :) When I originally wrote that, I thought Debian would have already done their release, my mistake... That's not the point. The point is that Debian/unstable as of _this morning_ doesn't work. For reference, I'm running both the latest releases of both hal (0.5.8.1-6.1) and network-manager (0.6.4-6). And there are people telling me I need a copy of HAL out of git that hasn't even been released for Debian to package. Debian isn't the problem here. If it is indeed the case that HAL needs to be upgraded here, the clock on deprecating these features can't even start counting until a usable HAL version is released. And then you need to give it at least a year after that before you can start recommending people disable it. -- Mathematics is the supreme nostalgia of our time. - 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/
