Re: [ANNOUNCE] GIT 1.5.4-rc3
Ismail Dönmez <[EMAIL PROTECTED]> writes:
> Saturday 12 January 2008 09:11:23 tarihinde Junio C Hamano şunları yazmıştı:
>> The third rc for the next feature release GIT 1.5.4 is available
>> at the usual places:
>>
>> http://www.kernel.org/pub/software/scm/git/
>>
>> git-1.5.4.rc3.tar.{gz,bz2} (tarball)
>> git-htmldocs-1.5.4.rc3.tar.{gz,bz2}(preformatted docs)
>> git-manpages-1.5.4.rc3.tar.{gz,bz2}(preformatted docs)
>> testing/git-*-1.5.4.rc3-1.$arch.rpm(RPM)
>
> I am seeing new failures compared to rc2 :
>
> *** t9200-git-cvsexportcommit.sh ***
> * FAIL 1: New file
> mkdir A B C D E F &&
> echo hello1 >A/newfile1.txt &&
> echo hello2 >B/newfile2.txt &&
> cp ../test9200a.png C/newfile3.png &&
> cp ../test9200a.png D/newfile4.png &&
> git add A/newfile1.txt &&
> git add B/newfile2.txt &&
> git add C/newfile3.png &&
> git add D/newfile4.png &&
> git commit -a -m "Test: New file" &&
> id=$(git rev-list --max-count=1 HEAD) &&
> (cd "$CVSWORK" &&
> git cvsexportcommit -c $id &&
> check_entries A "newfile1.txt/1.1/" &&
> check_entries B "newfile2.txt/1.1/" &&
> check_entries C "newfile3.png/1.1/-kb" &&
> check_entries D "newfile4.png/1.1/-kb" &&
> diff A/newfile1.txt ../A/newfile1.txt &&
> diff B/newfile2.txt ../B/newfile2.txt &&
> diff C/newfile3.png ../C/newfile3.png &&
> diff D/newfile4.png ../D/newfile4.png
> )
> Ideas appreciated.
Often the first failure is the most interesting one. Running
the test under sh -x like this:
$ cd t
$ sh t9200-git-cvsexportcommit.sh -i -v
and then looking at "trash" directory would tell you which one
of the long sequence of commands failed, and further
investigation can be made from there.
Thanks.
--
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: [TOMOYO #6 retry 08/21] Utility functions and policymanipulationinterface.
Hello. Greg KH wrote: > > If sysfs becomes not available at /sys/ , where securityfs is going to be > > mounted? > > sysfs is not going away any time soon, don't worry :) I see. Thanks. -- 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: PCI Failed to allocate mem for PCI ROM
On Fri, Jan 11, 2008 at 02:27:16PM -0600, Kumar Gala wrote: >>> I'm getting the following message from the kernel on an embedded ppc32 >>> system: >>> >>> PCI: Failed to allocate mem resource #9:[EMAIL PROTECTED] for :00:00.0 >>> >>> The HW setup is a PCIe host controller and an e1000 NIC card. ... > I'm happy to debug, is the fact that the resno == 9 ok or does that seem > wrong? That is fine for the Bridge. See include/linux/pci.h : #define PCI_ROM_RESOURCE6 #define PCI_BRIDGE_RESOURCES7 #define PCI_NUM_RESOURCES 11 IIRC, Bridges may have two 32-bit or one 64-bit BAR, Expansion ROM BAR and three "range" registers: IO Port, MMIO (Prefetchable and non-prefetchable). The BRIDGE_RESOURCES (7-10) are what failed to be assigned for some reason. Looking at setup-bus.c:pci_bridge_check_ranges(), I'm concluding that: [7] is IO Range. [8] is MMIO [9] is Prefetchable MMIO [10] no clue...maybe used by host PCI bus controllers. 0x10 is 1MB and would be the minimum MMIO range that can be allocated. So that looks right too. Probably need to find out what is allocating 0xe000 instead. hth, grant -- 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: [ANNOUNCE] GIT 1.5.4-rc3
Saturday 12 January 2008 09:11:23 tarihinde Junio C Hamano şunları yazmıştı:
> The third rc for the next feature release GIT 1.5.4 is available
> at the usual places:
>
> http://www.kernel.org/pub/software/scm/git/
>
> git-1.5.4.rc3.tar.{gz,bz2} (tarball)
> git-htmldocs-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
> git-manpages-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
> testing/git-*-1.5.4.rc3-1.$arch.rpm (RPM)
I am seeing new failures compared to rc2 :
*** t9200-git-cvsexportcommit.sh ***
* FAIL 1: New file
mkdir A B C D E F &&
echo hello1 >A/newfile1.txt &&
echo hello2 >B/newfile2.txt &&
cp ../test9200a.png C/newfile3.png &&
cp ../test9200a.png D/newfile4.png &&
git add A/newfile1.txt &&
git add B/newfile2.txt &&
git add C/newfile3.png &&
git add D/newfile4.png &&
git commit -a -m "Test: New file" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
check_entries A "newfile1.txt/1.1/" &&
check_entries B "newfile2.txt/1.1/" &&
check_entries C "newfile3.png/1.1/-kb" &&
check_entries D "newfile4.png/1.1/-kb" &&
diff A/newfile1.txt ../A/newfile1.txt &&
diff B/newfile2.txt ../B/newfile2.txt &&
diff C/newfile3.png ../C/newfile3.png &&
diff D/newfile4.png ../D/newfile4.png
)
* FAIL 2: Remove two files, add two and update two
echo Hello1 >>A/newfile1.txt &&
rm -f B/newfile2.txt &&
rm -f C/newfile3.png &&
echo Hello5 >E/newfile5.txt &&
cp ../test9200b.png D/newfile4.png &&
cp ../test9200a.png F/newfile6.png &&
git add E/newfile5.txt &&
git add F/newfile6.png &&
git commit -a -m "Test: Remove, add and update" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
check_entries A "newfile1.txt/1.2/" &&
check_entries B "" &&
check_entries C "" &&
check_entries D "newfile4.png/1.2/-kb" &&
check_entries E "newfile5.txt/1.1/" &&
check_entries F "newfile6.png/1.1/-kb" &&
diff A/newfile1.txt ../A/newfile1.txt &&
diff D/newfile4.png ../D/newfile4.png &&
diff E/newfile5.txt ../E/newfile5.txt &&
diff F/newfile6.png ../F/newfile6.png
)
* FAIL 4: Remove only binary files
git reset --hard HEAD^^ &&
rm -f D/newfile4.png &&
git commit -a -m "test: remove only a binary file" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
check_entries A "newfile1.txt/1.2/" &&
check_entries B "" &&
check_entries C "" &&
check_entries D "" &&
check_entries E "newfile5.txt/1.1/" &&
check_entries F "newfile6.png/1.1/-kb" &&
diff A/newfile1.txt ../A/newfile1.txt &&
diff E/newfile5.txt ../E/newfile5.txt &&
diff F/newfile6.png ../F/newfile6.png
)
* FAIL 5: Remove only a text file
rm -f A/newfile1.txt &&
git commit -a -m "test: remove only a binary file" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
check_entries A "" &&
check_entries B "" &&
check_entries C "" &&
check_entries D "" &&
check_entries E "newfile5.txt/1.1/" &&
check_entries F "newfile6.png/1.1/-kb" &&
diff E/newfile5.txt ../E/newfile5.txt &&
diff F/newfile6.png ../F/newfile6.png
)
* FAIL 6: New file with spaces in file name
mkdir "G g" &&
echo ok then >"G g/with spaces.txt" &&
git add "G g/with spaces.txt" && \
cp ../test9200a.png "G g/with spaces.png" && \
git add "G g/with spaces.png" &&
git commit -a -m "With spaces" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git-cvsexportcommit -c $id &&
check_entries "G g" "with spaces.png/1.1/-kb|with
spaces.txt/1.1/"
)
* FAIL 7: Update file with spaces in file name
echo Ok then >>"G g/with spaces.txt" &&
cat ../test9200a.png >>"G g/with spaces.png" && \
git add "G g/with spaces.png" &&
git commit -a -m "Update with spaces" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git-cvsexportcommit -c $id
check_entries "G g" "wit
Re: The ext3 way of journalling
Bodo Eggert <[EMAIL PROTECTED]> said on Sat, 12 Jan 2008 02:41:17 +0100 (CET): > On Fri, 11 Jan 2008, Lennart Sorensen wrote: > > On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote: > > > > What can happen if someone does tune2fs -Lroot /dev/usbstick > > > and puts that stick into this system? > > > > Don't know. I use UUIDs rather than LABELs. Having duplicated labels > > just means being careless. Having duplicate UUIDs should require being > > malicous. > > That's exactly what you have to assume for your users. Otherwise, you could > remove any security feature from the system. If they've got physical access to your machine, you've already lost. -- TimC A bug in the code is worth two in the documentation. --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/
[ANNOUNCE] GIT 1.5.4-rc3
The third rc for the next feature release GIT 1.5.4 is available
at the usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.4.rc3.tar.{gz,bz2}(tarball)
git-htmldocs-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
testing/git-*-1.5.4.rc3-1.$arch.rpm (RPM)
Sorry, this is a few days late than I promised. Partly due to
day-job pressure, partly because I am not familiar with RPM spec
file and ended up failing to get the spec file into a reasonable
shape after gitk i18n merge more than twice, and partly because
I involved myself to discussion on the list I should not have
been deeply involved in during the rc freeze.
In any case, we managed to keep the changes only to fixes (both
code and documentation) this round, aside from the promised gitk
i18n enhancements. This should be pretty much the same as what
we will have in final, hopefully due by the end of the month.
Please give it a good beating. Especially if you care about the
final RPM, and you are familiar with RPM generation, I would
appreciate extra set of eyeballs to see if dependencies and
other metainformation is set up correctly, as I do not think
many people have tested it.
Changes since v1.5.4-rc2 are as follows:
Alexandre Julliard (6):
git.el: Support for getting diffs from inside the log-edit buffer.
git.el: Retrieve the permissions for up-to-date files.
git.el: Display file types and type changes.
git.el: Make sure we never insert the same file twice.
git.el: Refresh files from their real state upon commit.
git.el: Make status refresh faster.
Bernt Hansen (1):
git-gui: Make commit log messages end with a newline
Brandon Casey (1):
git-relink.txt: describe more clearly how hard linking occurs
Charles Bailey (1):
gitk: Fix the Makefile to cope with systems lacking msgfmt
Christian Couder (1):
Documentation: config: add 'help.*' and 'instaweb.*' variables.
Christian Stimming (10):
gitk i18n: Add Makefile with rules for po file creation and installation
gitk i18n: Import msgcat for message string translation; load translation
catalogs
gitk i18n: Markup several strings for translation
gitk i18n: Initial German translation
gitk i18n: More markup -- various options menus
gitk i18n: Recode gitk from latin1 to utf8 so that the (c) copyright
character is valid utf8.
gitk: Update and fix Makefile
gitk: Update German translation
gitk: Fix typo in user message.
gitk: Update German translation.
Dan McGee (1):
Documentation: rename gitlink macro to linkgit
Eric Wong (4):
git-svn: allow dcommit --no-rebase to commit multiple, dependent changes
git-svn: unlink index files that were globbed, too
git-svn: support for funky branch and project names over HTTP(S)
git-svn: clarify the "Ignoring error from SVN" piece
Florian La Roche (1):
Change git-gc documentation to reflect gc.packrefs implementation.
Gerrit Pape (1):
gitk: use user-configured background in view definition dialog
Grégoire Barbier (1):
Fix double-free() in http-push.c:remote_exists()
Gustaf Hendeby (1):
Documentation/user-manual.txt: fix typo
J. Bruce Fields (1):
Documentation: fix remote..skipDefaultUpdate description
James Bowes (1):
Make the git metapackage require the same version of the subpackages.
Jeff King (8):
config: handle lack of newline at end of file better
git-reset: refuse to do hard reset in a bare repository
add a "basic" diff config callback
diff: load funcname patterns in "basic" config
diff: remove lazy config loading
add--interactive: remove unused diff colors
add--interactive: allow diff colors without interactive colors
Document the color.interactive semantics
Jim Meyering (3):
Fix grammar nits in documentation and in code comments.
Don't access line[-1] for a zero-length "line" from fgets.
bundle, fast-import: detect write failure
Johannes Schindelin (2):
Optimize prefixcmp()
shortlog: mention the "-e" option in the usage
Johannes Sixt (2):
git-gui: Move frequently used commands to the top of the context menu.
recv_sideband: Do not use ANSI escape sequence on dumb terminals.
Junio C Hamano (27):
Documentation/git-submodule.txt: typofix
"git pull --tags": error out with a better message.
git-rebase -i behaves better on commits with incomplete messages
git-rebase -i: clean-up error check codepath.
lock_any_ref_for_update(): reject wildcard return from check_ref_format
Update callers of check_ref_format()
Uninline prefixcmp()
git-clean: make "Would remove ..." path relative to cwd again
t/t7600: avoid GNUism in grep
t/t{3600,3800,5401}: do no
Re: [PATCH x86/mm] x86_64 save_i387_ia32 snafu
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Fri, 11 Jan 2008 13:31:47 PST, Roland McGrath said: > > > thanks, applied. Does this explain the crash/hang problems with 32-bit > > > apps on 64-bit kernels? What was the exact failure mode? > > > > It does. Any 32-bit process trying to run a signal handler when it had > > used the FPU, would clobber "current" with FP bits. The observed failure > > mode was shortly after this in the signal handler setup code, when it > > crashed due to current->mm being zero (current->pid also being zero, and > > the whole first 512 bytes of the task_struct being garbage). > > For what it's worth, this patch fixes a problem I had in 24-rc6-mm1 > with kernel panics when certain X programs exited (Eterm being the > biggest cause), that I had bisected to "somewhere in > git-x86.patch" ok, good. Yesterday's x86.git update has this fix included so the next -mm iteration should have the fix as well. 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 0/8] Series to improve the x86 backtracing code
* Arjan van de Ven <[EMAIL PROTECTED]> wrote: > this patch series improves the x86 backtracing code in the following ways: > 1) Fix a bad bug in x86 (32 bit) FRAME_POINTER backtracing (2.6.24 material) > 2) Add the capability to mark a backtrace entry as reliable / unreliable > 3) Change the x86 (32 bit) FRAME_POINTER backtracing to use the normal > backtrace but use the frames >as guidance to the reliability of the backtrace entries > 4) Patch to capture the EBP register earlier in the backtrace callchain to > get a better FRAME_POINTER >based backtrace > 5) Split the x86 (64 bit) backtrace code up similar to the 32 bit code by > turning a macro into a function > 6) Enable FRAME_POINTER backtracing on 64 bit similar to the 32 bit patch in > number 3 > 7) Add a simple self-test module for backtraces (will move to tests/ later > when that gets merged) > 8) Add the feature to x86 64bit to print a set of bytes prior to the current > EIP in the Code: line >(already present in 32 bit) thanks, i've applied your new series to x86.git. (Note that i had to move around some of the changes to make the series bisectable.) 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] Clustering indirect blocks in Ext3
On Friday 11 January 2008 16:04, Andrew Morton wrote: > It needs to be reviewed. In exhaustive detail. Few people can do > that and fewer are inclined to do so. Agreed, there just have to be a few bugs in this many lines of code. I spent a couple of hours going through it, not really looking at the algorithms but just the superficial details. I only found minor nits, and not many of those. For example, I do not like to see "if (free_blocks == 0)" written as"if (free_blocks <= 0)" in an attempt to increase robustness. What it actually does is make the effect of an error more subtle, or even "corrects" it. Firmly in the niggle category. I checked the locking of sbi->bginfo and didn't see a flaw, good. I see a missing KERN_INFO added to a printk, it technically counts as an unrelated change but oh well. Stylistically this new code is hard to tell apart from the incumbent code, except for being more heavily commented. I wish all kernel code was written this clearly. At this point I will run away in favor of for-real Ext3 hackers (you know who you are:-) > I went to merge it so it could get some testing while we await review > but the patch has all its tabs replaced with spaces, is seriously > wordwrapped and has random newlines added to it. Please fix email > client and resend (offlist is OK if it is unaltered). Odd, the original post has tabs and the updated one does not, though the client seems to be kmail in both cases. > We should have a think about which workloads are most likely to be > adversely affected by this change. I was just rolling up my sleeves to construct the nasty sequential case where the head keeps seeking back to the center of the group after picking up each 4 MB of doubly indexed data when I realized that even the most simple minded disk cache makes this case a non-issue. The drive will most likely suck a full track (roughly .5 MB) or big chunk thereof into cache the first time it seeks to the index cluster, thus having a whole group of double index blocks in cache and then will proceed to chew happily and linearly through the data blocks. It seems like placing those second level index blocks all together really helps this case. Hmm, how to break it. How about having a disk full of 100 MB files and skipping all over the disk randomly reading one block each time. That will fill the disk cache, and each random read then requires seeking to two places that were hopefully close together without index node clustering, and now will be an average of 32 MB apart. Each of these "extra" seeks costs a couple of ms worth of head travel plus average rotational latency of 4 ms or so, for a total 6 ms. However, even with a perfect non-clustered layout, the index mode will still be an average of 2 MB away from the data block, so the rotational latency is still incurred and only the head travel is a little less, say 1 ms less. So the "extra" seek time for clustered is 6 ms vs 5 ms for non-clustered. Add in 8 ms for the long random seek and we have 14 ms vs 13 ms, or about 8% difference. Only a small regression there, and I tried hard. Barring mistakes in my estimates the sequential improvement above is large while the regression for the nasty random construction is small. Maybe somebody else will have better luck breaking it. Regards, Daniel -- 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.24-rc6-mm1 - drivers/char/tpm/tpm_bios.c oddness?
(Reposting, nobody from lkml or tpmdd-devel chirped on the Dec 27 post)
On Sat, 22 Dec 2007 23:30:56 PST, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/
Looks like an uninitialized variable dereference for SEPARATOR events:
# mount -t securityfs none /sys/kernel/security/
# ls /sys/kernel/security/
tpm0
# ls -l /sys/kernel/security/tpm0/
total 0
0 -r--r- 1 root root 0 2007-12-26 23:28 ascii_bios_measurements
0 -r--r- 1 root root 0 2007-12-26 23:28 binary_bios_measurements
# cat /sys/kernel/security/tpm0/ascii_bios_measurements
0 07 [S-CRTM Contents]
0 07 [S-CRTM Contents]
0 07 [S-CRTM Contents]
0 07 [S-CRTM Contents]
4 c1e25c3f6b0dc78d57296aa2870ca6f782ccf80f 05 [Calling INT 19h]
0 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
1 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
2 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
3 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
4 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
5 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
6 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
7 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
4 38f30a0a967fcf2bfee1e3b2971de540115048c8 05 [Returned INT 19h]
4 f9d3a33e4ba6109fb60e8df6ec0f10330733c8b2 0c [Compact Hash]
5 9bd5c812613f67ce1c75d0ea48b9933a547683cb 0c [Compact Hash]
Looks like the problem is likely in get_event_name:
case NONHOST_INFO:
name = tcpa_event_type_strings[event->event_type];
n_len = strlen(name);
break;
case SEPARATOR:
case ACTION:
if (MAX_TEXT_EVENT > event->event_size) {
name = event_entry;
n_len = event->event_size;
}
break;
Should there be a 'break;' after the SEPARATOR line? Given the name, it
probably doesn't have a name/length pair attached to an event, right?
pgpOz45DhqQ58.pgp
Description: PGP signature
Qustion on function try_module_get()
Hi,
I have a problem about the try_module_get function, I don't know if someone
removed the module just AFTER line 372 and BEFORE line 373, then
what happens? Because in this situation, the variable "module" will be
incorrect, and module_is_live function will lead to unpredicatable behaviour.
368 static inline int try_module_get(struct module *module)
369 {
370 int ret = 1;
371
372 if (module) {
373 unsigned int cpu = get_cpu();
374 if (likely(module_is_live(module)))
375 local_inc(&module->ref[cpu].count);
376 else
377 ret = 0;
378 put_cpu();
379 }
380 return ret;
381 }
Best wishes to all,
rmingming
--
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 x86/mm] x86_64 save_i387_ia32 snafu
On Fri, 11 Jan 2008 13:31:47 PST, Roland McGrath said: > > thanks, applied. Does this explain the crash/hang problems with 32-bit > > apps on 64-bit kernels? What was the exact failure mode? > > It does. Any 32-bit process trying to run a signal handler when it had > used the FPU, would clobber "current" with FP bits. The observed failure > mode was shortly after this in the signal handler setup code, when it > crashed due to current->mm being zero (current->pid also being zero, and > the whole first 512 bytes of the task_struct being garbage). For what it's worth, this patch fixes a problem I had in 24-rc6-mm1 with kernel panics when certain X programs exited (Eterm being the biggest cause), that I had bisected to "somewhere in git-x86.patch" pgpaZgIuSHQiw.pgp Description: PGP signature
Re: [PATCH 001/001] ipv4: enable use of 240/4 address space
Hello. In article <[EMAIL PROTECTED]> (at Mon, 7 Jan 2008 17:10:57 -0800), Vince Fuller <[EMAIL PROTECTED]> says: > #define IN_MULTICAST_NET 0xF000 > > +#define IN_CLASSE(a) long int) (a)) & 0xf000) == 0xf000) > +#define IN_CLASSE_NET 0xff00 > +#define IN_CLASSE_NSHIFT8 > +#define IN_CLASSE_HOST (0x & ~IN_CLASSE_NET) > + > +/* > + * these are no longer used > #define IN_EXPERIMENTAL(a) long int) (a)) & 0xf000) == > 0xf000) > #define IN_BADCLASS(a) IN_EXPERIMENTAL((a)) > +*/ Please do not remove this, but have these instead: #define IN_EXPERIMENTAL(a) IN_CLASSE((a)) #define IN_BADCASS(a) IN_CLASSE((a)) And, I think it is good to remove BADCLASS() (inside #ifdef __KERNEL__ .. #endif) because we do not have its users any longer, right? Regards, --yoshfuji -- 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: questions on NAPI processing latency and dropped network packets
On Jan 10, 2008 9:24 AM, Chris Friesen <[EMAIL PROTECTED]> wrote: > After a recent userspace app change, we've started seeing packets being > dropped by the ethernet hardware (e1000, NAPI is enabled). The > error/dropped/fifo counts are going up in ethtool: (These are perhaps too obvious, but I didn't see the questions or answers in the thread.) Can you reproduce it with a simple userspace cpu hog? (Two, really, one per cpu.) Can you reproduce it with the newer e1000? Can you reproduce it with git head? If the answer to the first one is yes, the last no, then bisect until you get a kernel that doesn't show the problem. Backport the fix, unless the fix happens to be CFS. However, I suspect that your userpace app is just starving the system from time to 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/
[patch 2/8] x86: Add the capability to print fuzzy backtraces
Subject: x86: Add the capability to print fuzzy backtraces
From: Arjan van de Ven <[EMAIL PROTECTED]>
For enhancing the 32 bit EBP based backtracer, I need the capability
for the backtracer to tell it's customer that an entry is either
reliable or unreliable, and the backtrace printing code then needs to
print the unreliable ones slightly different.
This patch adds the basic capability, the next patch will add a user
of this capability.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
arch/x86/kernel/stacktrace.c |2 +-
arch/x86/kernel/traps_32.c|8 +---
arch/x86/kernel/traps_64.c| 37 ++---
arch/x86/oprofile/backtrace.c |2 +-
include/asm-x86/stacktrace.h |2 +-
5 files changed, 30 insertions(+), 21 deletions(-)
Index: linux-2.6.24-rc7/arch/x86/kernel/traps_32.c
===
--- linux-2.6.24-rc7.orig/arch/x86/kernel/traps_32.c
+++ linux-2.6.24-rc7/arch/x86/kernel/traps_32.c
@@ -125,7 +125,7 @@ static inline unsigned long print_contex
addr = frame->return_address;
if (__kernel_text_address(addr))
- ops->address(data, addr);
+ ops->address(data, addr, 1);
/*
* break out of recursive entries (such as
* end_of_stack_stop_unwind_function). Also,
@@ -144,7 +144,7 @@ static inline unsigned long print_contex
addr = *stack++;
if (__kernel_text_address(addr))
- ops->address(data, addr);
+ ops->address(data, addr, 1);
}
#endif
return ebp;
@@ -219,9 +219,11 @@ static int print_trace_stack(void *data,
/*
* Print one address/symbol entries per line.
*/
-static void print_trace_address(void *data, unsigned long addr)
+static void print_trace_address(void *data, unsigned long addr, int reliable)
{
printk("%s [<%08lx>] ", (char *)data, addr);
+ if (!reliable)
+ printk("? ");
print_symbol("%s\n", addr);
touch_nmi_watchdog();
}
Index: linux-2.6.24-rc7/arch/x86/kernel/traps_64.c
===
--- linux-2.6.24-rc7.orig/arch/x86/kernel/traps_64.c
+++ linux-2.6.24-rc7/arch/x86/kernel/traps_64.c
@@ -99,13 +99,14 @@ static inline void preempt_conditional_c
int kstack_depth_to_print = 12;
#ifdef CONFIG_KALLSYMS
-void printk_address(unsigned long address)
+void printk_address(unsigned long address, int reliable)
{
unsigned long offset = 0, symsize;
const char *symname;
char *modname;
char *delim = ":";
char namebuf[128];
+ char reliab[4] = "";;
symname = kallsyms_lookup(address, &symsize, &offset,
&modname, namebuf);
@@ -113,13 +114,16 @@ void printk_address(unsigned long addres
printk(" [<%016lx>]\n", address);
return;
}
+ if (!reliable)
+ strcpy(reliab,"? ");
+
if (!modname)
modname = delim = "";
- printk(" [<%016lx>] %s%s%s%s+0x%lx/0x%lx\n",
- address, delim, modname, delim, symname, offset, symsize);
+ printk(" [<%016lx>] %s%s%s%s%s+0x%lx/0x%lx\n",
+ address, reliab, delim, modname, delim, symname, offset,
symsize);
}
#else
-void printk_address(unsigned long address)
+void printk_address(unsigned long address, int reliable)
{
printk(" [<%016lx>]\n", address);
}
@@ -215,7 +219,7 @@ static inline int valid_stack_ptr(struct
}
void dump_trace(struct task_struct *tsk, struct pt_regs *regs,
- unsigned long *stack,
+ unsigned long *stack, unsigned long ebp,
const struct stacktrace_ops *ops, void *data)
{
const unsigned cpu = get_cpu();
@@ -252,7 +256,7 @@ void dump_trace(struct task_struct *tsk,
* down the cause of the crash will be able to figure \
* out the call path that was taken. \
*/ \
- ops->address(data, addr); \
+ ops->address(data, addr, 1); \
} \
} while (0)
@@ -331,10 +335,10 @@ static int print_trace_stack(void *data,
return 0;
}
-static void print_trace_address(void *data, unsigned long addr)
+static void print_trace_address(void *data, unsigned long addr, int reliable)
{
touch_nmi_watchdog();
- printk_address(addr);
+ printk_address(addr, reliable);
}
static const struct stacktrace_ops print_trace_ops = {
@@ -345,15 +349,17 @@ static const struct stacktrace_ops print
};
void
-show_trace(struct task_struct *tsk, struct pt_regs *regs, unsigned long *stack)
+show_trace(struct task_struct *tsk, struct pt_regs *regs, unsigned long *stack,
+ unsigned long ebp)
{
prin
[patch 8/8] x86: Add the "print code before the trapping instruction" feature to 64 bit
Subject: x86: Add the "print code before the trapping instruction" feature to
64 bit
From: Arjan van de Ven <[EMAIL PROTECTED]>
The 32 bit x86 tree has a very useful feature that prints the Code: line
for the code even before the trapping instrution (and the start of the
trapping instruction is then denoted with a <>). Unfortunately, the 64 bit
x86 tree does not yet have this feature, making diagnosing backtraces harder
than needed.
This patch adds this feature in the same was as the 32 bit tree has
(including the same kernel boot parameter), and including a bugfix
to make the code use probe_kernel_address() rarther than a buggy (deadlocking)
__get_user.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |4 +--
arch/x86/kernel/traps_64.c | 44 +++-
2 files changed, 35 insertions(+), 13 deletions(-)
Index: linux-2.6.24-rc7/Documentation/kernel-parameters.txt
===
--- linux-2.6.24-rc7.orig/Documentation/kernel-parameters.txt
+++ linux-2.6.24-rc7/Documentation/kernel-parameters.txt
@@ -408,8 +408,8 @@ and is between 256 and 4096 characters.
[SPARC64] tick
[X86-64] hpet,tsc
- code_bytes [IA32] How many bytes of object code to print in an
- oops report.
+ code_bytes [IA32/X86_64] How many bytes of object code to print
+ in an oops report.
Range: 0 - 8192
Default: 64
Index: linux-2.6.24-rc7/arch/x86/kernel/traps_64.c
===
--- linux-2.6.24-rc7.orig/arch/x86/kernel/traps_64.c
+++ linux-2.6.24-rc7/arch/x86/kernel/traps_64.c
@@ -74,6 +74,8 @@ asmlinkage void alignment_check(void);
asmlinkage void machine_check(void);
asmlinkage void spurious_interrupt_bug(void);
+static unsigned int code_bytes = 64;
+
static inline void conditional_sti(struct pt_regs *regs)
{
if (regs->eflags & X86_EFLAGS_IF)
@@ -459,12 +461,15 @@ EXPORT_SYMBOL(dump_stack);
void show_registers(struct pt_regs *regs)
{
int i;
- int in_kernel = !user_mode(regs);
unsigned long rsp;
const int cpu = smp_processor_id();
struct task_struct *cur = cpu_pda(cpu)->pcurrent;
+ u8 *rip;
+ unsigned int code_prologue = code_bytes * 43 / 64;
+ unsigned int code_len = code_bytes;
rsp = regs->rsp;
+ rip = (u8 *) regs->rip - code_prologue;
printk("CPU %d ", cpu);
__show_regs(regs);
printk("Process %s (pid: %d, threadinfo %p, task %p)\n",
@@ -474,22 +479,28 @@ void show_registers(struct pt_regs *regs
* When in-kernel, we also print out the stack and code at the
* time of the fault..
*/
- if (in_kernel) {
+ if (!user_mode(regs)) {
+ unsigned char c;
printk("Stack: ");
_show_stack(NULL, regs, (unsigned long *)rsp, regs->rbp);
+ printk("\n");
- printk("\nCode: ");
- if (regs->rip < PAGE_OFFSET)
- goto bad;
-
- for (i=0; i<20; i++) {
- unsigned char c;
- if (__get_user(c, &((unsigned char*)regs->rip)[i])) {
-bad:
+ printk(KERN_EMERG "Code: ");
+ if (rip < (u8 *)PAGE_OFFSET || probe_kernel_address(rip, c)) {
+ /* try starting at RIP */
+ rip = (u8 *) regs->rip;
+ code_len = code_len - code_prologue + 1;
+ }
+ for (i = 0; i < code_len; i++, rip++) {
+ if (rip < (u8 *)PAGE_OFFSET ||
+ probe_kernel_address(rip, c)) {
printk(" Bad RIP value.");
break;
}
- printk("%02x ", c);
+ if (rip == (u8 *)regs->rip)
+ printk("<%02x> ", c);
+ else
+ printk("%02x ", c);
}
}
printk("\n");
@@ -1187,3 +1198,14 @@ static int __init kstack_setup(char *s)
return 0;
}
early_param("kstack", kstack_setup);
+
+
+static int __init code_bytes_setup(char *s)
+{
+ code_bytes = simple_strtoul(s, NULL, 0);
+ if (code_bytes > 8192)
+ code_bytes = 8192;
+
+ return 1;
+}
+__setup("code_bytes=", code_bytes_setup);
--
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings,
visit http://www.lesswatts.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
P
[patch 6/8] x86: Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER on x86-64
Subject: x86: Use the stack frames to get exact stack-traces for
CONFIG_FRAMEPOINTER on x86-64
From: Arjan van de Ven <[EMAIL PROTECTED]>
x86 32 bit already has this feature: This patch uses the stack frames with
frame pointer into an exact stack trace, by following the frame pointer.
This only affects kernels built with the CONFIG_FRAME_POINTER config option
enabled, and greatly reduces the amount of noise in oopses.
This code uses the traditional method of doing backtraces, but if it
finds a valid frame pointer chain, will use that to show which parts
of the backtrace are reliable and which parts are not
Due to the fragility and importance of the backtrace code, this needs to
be well reviewed and well tested before merging into mainlne.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
arch/x86/kernel/traps_64.c | 67 +
1 file changed, 44 insertions(+), 23 deletions(-)
Index: linux-2.6.24-rc7/arch/x86/kernel/traps_64.c
===
--- linux-2.6.24-rc7.orig/arch/x86/kernel/traps_64.c
+++ linux-2.6.24-rc7/arch/x86/kernel/traps_64.c
@@ -225,31 +225,34 @@ static inline int valid_stack_ptr(struct
return p > t && p < t + THREAD_SIZE - size;
}
+/* The form of the top of the frame on the stack */
+struct stack_frame {
+ struct stack_frame *next_frame;
+ unsigned long return_address;
+};
+
+
static inline unsigned long print_context_stack(struct thread_info *tinfo,
unsigned long *stack, unsigned long ebp,
const struct stacktrace_ops *ops, void *data,
unsigned long *end)
{
- /*
-* Print function call entries within a stack. 'cond' is the
-* "end of stackframe" condition, that the 'stack++'
-* iteration will eventually trigger.
-*/
- while (valid_stack_ptr(tinfo, stack, 3, end))) {
- unsigned long addr = *stack++;
- /* Use unlocked access here because except for NMIs
- we should be already protected against module unloads */
+ struct stack_frame *frame = (struct stack_frame *)ebp;
+
+ while (valid_stack_ptr(tinfo, stack, sizeof(*stack), end)) {
+ unsigned long addr;
+
+ addr = *stack;
if (__kernel_text_address(addr)) {
- /*
-* If the address is either in the text segment of the
-* kernel, or in the region which contains vmalloc'ed
-* memory, it *may* be the address of a calling
-* routine; if so, print it so that someone tracing
-* down the cause of the crash will be able to figure
-* out the call path that was taken.
-*/
- ops->address(data, addr, 1);
+ if ((unsigned long) stack == ebp + 8) {
+ ops->address(data, addr, 1);
+ frame = frame->next_frame;
+ ebp = (unsigned long) frame;
+ } else {
+ ops->address(data, addr, ebp == 0);
+ }
}
+ stack++;
}
return ebp;
}
@@ -274,6 +277,19 @@ void dump_trace(struct task_struct *tsk,
stack = (unsigned long *)tsk->thread.rsp;
}
+#ifdef CONFIG_FRAME_POINTER
+ if (!ebp) {
+ if (tsk == current) {
+ /* Grab ebp right from our regs */
+ asm("movq %%rbp, %0" : "=r" (ebp):);
+ } else {
+ /* ebp is the last reg pushed by switch_to */
+ ebp = *(unsigned long *) tsk->thread.rsp;
+ }
+ }
+#endif
+
+
/*
* Print function call entries in all stacks, starting at the
@@ -290,8 +306,8 @@ void dump_trace(struct task_struct *tsk,
if (ops->stack(data, id) < 0)
break;
- print_context_stack(tinfo, stack, 0, ops,
- data, estack_end);
+ ebp = print_context_stack(tinfo, stack, ebp, ops,
+ data, estack_end);
ops->stack(data, "");
/*
* We link to the next stack via the
@@ -309,8 +325,8 @@ void dump_trace(struct task_struct *tsk,
if (stack >= irqstack && stack < irqstack_end) {
if (ops->stack(data, "IRQ") < 0)
break;
- print_context_stack(tinfo, stack, 0, ops,
-
[patch 7/8] x86: Add a simple backtrace test module
Subject: x86: Add a simple backtrace test module
From: Arjan van de Ven <[EMAIL PROTECTED]>
During the work on the x86 32 and 64 bit backtrace code I found it useful
to have a simple test module to test a process and irq context backtrace.
Since the existing backtrace code was buggy, I figure it might be useful
to have such a test module in the kernel so that maybe we can even
detect such bugs earlier..
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
kernel/Makefile|1 +
kernel/backtracetest.c | 47 +++
lib/Kconfig.debug | 12
3 files changed, 60 insertions(+)
Index: linux-2.6.24-rc7/kernel/Makefile
===
--- linux-2.6.24-rc7.orig/kernel/Makefile
+++ linux-2.6.24-rc7/kernel/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_DETECT_SOFTLOCKUP) += softl
obj-$(CONFIG_GENERIC_HARDIRQS) += irq/
obj-$(CONFIG_SECCOMP) += seccomp.o
obj-$(CONFIG_RCU_TORTURE_TEST) += rcutorture.o
+obj-$(CONFIG_BACKTRACE_SELF_TEST) += backtracetest.o
obj-$(CONFIG_RELAY) += relay.o
obj-$(CONFIG_SYSCTL) += utsname_sysctl.o
obj-$(CONFIG_TASK_DELAY_ACCT) += delayacct.o
Index: linux-2.6.24-rc7/kernel/backtracetest.c
===
--- /dev/null
+++ linux-2.6.24-rc7/kernel/backtracetest.c
@@ -0,0 +1,47 @@
+/*
+ * Simple stack backtrace regression test module
+ *
+ * (C) Copyright 2008 Intel Corporation
+ * Author: Arjan van de Ven <[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; version 2
+ * of the License.
+ */
+
+#include
+#include
+
+static struct timer_list backtrace_timer;
+
+static void backtrace_test_timer(unsigned long data)
+{
+ printk("Testing a backtrace from irq context.\n");
+ printk("The following trace is a kernel self test and not a bug!\n");
+ dump_stack();
+}
+static int backtrace_regression_test(void)
+{
+ printk("[ backtrace testing ]===\n");
+ printk("Testing a backtrace from process context.\n");
+ printk("The following trace is a kernel self test and not a bug!\n");
+ dump_stack();
+
+ init_timer(&backtrace_timer);
+ backtrace_timer.function = backtrace_test_timer;
+ mod_timer(&backtrace_timer, jiffies + 10);
+
+ msleep(10);
+ printk("[ end of backtrace testing ]\n");
+ return 0;
+}
+
+static void exitf(void)
+{
+}
+
+module_init(backtrace_regression_test);
+module_exit(exitf);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Arjan van de Ven <[EMAIL PROTECTED]>");
Index: linux-2.6.24-rc7/lib/Kconfig.debug
===
--- linux-2.6.24-rc7.orig/lib/Kconfig.debug
+++ linux-2.6.24-rc7/lib/Kconfig.debug
@@ -462,6 +462,18 @@ config RCU_TORTURE_TEST
Say M if you want the RCU torture tests to build as a module.
Say N if you are unsure.
+config BACKTRACE_SELF_TEST
+ tristate "Self test for the backtrace code"
+ depends on DEBUG_KERNEL
+ default n
+ help
+ This option provides a kernel module that can be used to test
+ the kernel stack backtrace code. This option is not useful
+ for distributions or general kernels, but only for kernel
+ developers working on architecture code.
+
+ Say N if you are unsure.
+
config LKDTM
tristate "Linux Kernel Dump Test Tool Module"
depends on DEBUG_KERNEL
--
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings,
visit http://www.lesswatts.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/
[patch 5/8] x86: Turn 64 bit x86 HANDLE_STACK into print_context_stack like 32 bit has
Subject: x86: Turn 64 bit x86 HANDLE_STACK into print_context_stack like 32 bit
has
From: Arjan van de Ven <[EMAIL PROTECTED]>
This patch turns the x86 64 bit HANDLE_STACK macro in the backtrace code
into a function, just like 32 bit has. This is needed pre work in order to
get exact backtraces for CONFIG_FRAME_POINTER to work.
The function and it's arguments are not the same as 32 bit; due to the
exception/interrupt stack way of x86-64 there are a few differences.
This patch should not have any behavior changes, only code movement.
Due to the fragility and importance of the backtrace code, this needs to be
well reviewed and well tested before merging into mainlne.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
arch/x86/kernel/traps_64.c | 74 +++--
1 file changed, 45 insertions(+), 29 deletions(-)
Index: linux-2.6.24-rc7/arch/x86/kernel/traps_64.c
===
--- linux-2.6.24-rc7.orig/arch/x86/kernel/traps_64.c
+++ linux-2.6.24-rc7/arch/x86/kernel/traps_64.c
@@ -212,10 +212,46 @@ static unsigned long *in_exception_stack
* severe exception (double fault, nmi, stack fault, debug, mce) hardware stack
*/
-static inline int valid_stack_ptr(struct thread_info *tinfo, void *p)
+static inline int valid_stack_ptr(struct thread_info *tinfo,
+ void *p, unsigned int size, void *end)
{
void *t = (void *)tinfo;
-return p > t && p < t + THREAD_SIZE - 3;
+ if (end) {
+ if (p < end && p >= (end-THREAD_SIZE))
+ return 1;
+ else
+ return 0;
+ }
+ return p > t && p < t + THREAD_SIZE - size;
+}
+
+static inline unsigned long print_context_stack(struct thread_info *tinfo,
+ unsigned long *stack, unsigned long ebp,
+ const struct stacktrace_ops *ops, void *data,
+ unsigned long *end)
+{
+ /*
+* Print function call entries within a stack. 'cond' is the
+* "end of stackframe" condition, that the 'stack++'
+* iteration will eventually trigger.
+*/
+ while (valid_stack_ptr(tinfo, stack, 3, end))) {
+ unsigned long addr = *stack++;
+ /* Use unlocked access here because except for NMIs
+ we should be already protected against module unloads */
+ if (__kernel_text_address(addr)) {
+ /*
+* If the address is either in the text segment of the
+* kernel, or in the region which contains vmalloc'ed
+* memory, it *may* be the address of a calling
+* routine; if so, print it so that someone tracing
+* down the cause of the crash will be able to figure
+* out the call path that was taken.
+*/
+ ops->address(data, addr, 1);
+ }
+ }
+ return ebp;
}
void dump_trace(struct task_struct *tsk, struct pt_regs *regs,
@@ -229,6 +265,7 @@ void dump_trace(struct task_struct *tsk,
if (!tsk)
tsk = current;
+ tinfo = task_thread_info(tsk);
if (!stack) {
unsigned long dummy;
@@ -237,28 +274,6 @@ void dump_trace(struct task_struct *tsk,
stack = (unsigned long *)tsk->thread.rsp;
}
- /*
-* Print function call entries within a stack. 'cond' is the
-* "end of stackframe" condition, that the 'stack++'
-* iteration will eventually trigger.
-*/
-#define HANDLE_STACK(cond) \
- do while (cond) { \
- unsigned long addr = *stack++; \
- /* Use unlocked access here because except for NMIs \
- we should be already protected against module unloads */ \
- if (__kernel_text_address(addr)) { \
- /* \
-* If the address is either in the text segment of the \
-* kernel, or in the region which contains vmalloc'ed \
-* memory, it *may* be the address of a calling \
-* routine; if so, print it so that someone tracing \
-* down the cause of the crash will be able to figure \
-* out the call path that was taken. \
-*/ \
- ops->address(data, addr, 1); \
- } \
- } while (0)
/*
* Print function call entries in all stacks, starting at the
@@ -274,7 +289,9 @@ void dump_trace(struct task_struct *tsk,
if (estack_end) {
if (ops->stack(data, id) < 0)
break;
- HANDLE_STACK (stack < estack
[patch 3/8] x86: Improve the 32 bit Frame Pointer backtracer to also use the traditional backtrace
Subject: x86: Improve the 32 bit Frame Pointer backtracer to also use the
traditional backtrace
From: Arjan van de Ven <[EMAIL PROTECTED]>
The 32 bit Frame Pointer backtracer code checks if the EBP is valid
to do a backtrace; however currently on a failure it just gives up
and prints nothing. That's not very nice; we can do better and still
print a decent backtrace.
This patch changes the backtracer to use the regular backtracing algorithm
at the same time as the EBP backtracer; the EBP backtracer is basically
used to figure out which part of the backtrace are reliable vs those
which are likely to be noise.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
arch/x86/kernel/traps_32.c | 44
1 file changed, 20 insertions(+), 24 deletions(-)
Index: linux-2.6.24-rc7/arch/x86/kernel/traps_32.c
===
--- linux-2.6.24-rc7.orig/arch/x86/kernel/traps_32.c
+++ linux-2.6.24-rc7/arch/x86/kernel/traps_32.c
@@ -117,36 +117,32 @@ static inline unsigned long print_contex
unsigned long *stack, unsigned long ebp,
const struct stacktrace_ops *ops, void *data)
{
-#ifdef CONFIG_FRAME_POINTER
struct stack_frame *frame = (struct stack_frame *)ebp;
- while (valid_stack_ptr(tinfo, frame, sizeof(*frame))) {
- struct stack_frame *next;
- unsigned long addr;
- addr = frame->return_address;
- if (__kernel_text_address(addr))
- ops->address(data, addr, 1);
- /*
-* break out of recursive entries (such as
-* end_of_stack_stop_unwind_function). Also,
-* we can never allow a frame pointer to
-* move downwards!
-*/
- next = frame->next_frame;
- ebp = (unsigned long) next;
- if (next <= frame)
- break;
- frame = next;
- }
-#else
+ /*
+* if EBP is "deeper" into the stack than the actual stack pointer,
+* we need to rewind the stack pointer a little to start at the
+* first stack frame, but only if EBP is in this stack frame.
+*/
+ if (stack > (unsigned long *) ebp
+ && valid_stack_ptr(tinfo, frame, sizeof(*frame)))
+ stack = (unsigned long *) ebp;
+
while (valid_stack_ptr(tinfo, stack, sizeof(*stack))) {
unsigned long addr;
- addr = *stack++;
- if (__kernel_text_address(addr))
- ops->address(data, addr, 1);
+ addr = *stack;
+ if (__kernel_text_address(addr)) {
+ if ((unsigned long) stack == ebp + 4) {
+ ops->address(data, addr, 1);
+ frame = frame->next_frame;
+ ebp = (unsigned long) frame;
+ } else {
+ ops->address(data, addr, 0);
+ }
+ }
+ stack++;
}
-#endif
return ebp;
}
--
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings,
visit http://www.lesswatts.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/
[patch 4/8] x86: pull EBP calculation earlier into the backtrace path
Subject: x86: pull EBP calculation earlier into the backtrace path
From: Arjan van de Ven <[EMAIL PROTECTED]>
Right now, we take the stack pointer early during the backtrace path, but
only calculate EBP several functions deep later, making it hard to reconcile
the stack and EBP backtraces (as well as showing several internal backtrace
functions on the stack with EBP based backtracing).
This patch moves the EBP taking to the same place we take the stack pointer;
sadly this ripples through several layers of the back tracing stack,
but it's not all that bad in the end I hope.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
arch/x86/kernel/process_32.c |2 +-
arch/x86/kernel/process_64.c |2 +-
arch/x86/kernel/stacktrace.c |2 +-
arch/x86/kernel/traps_32.c | 39 +--
arch/x86/oprofile/backtrace.c |2 +-
include/asm-x86/processor_32.h |3 ++-
include/asm-x86/proto.h|3 ++-
include/asm-x86/stacktrace.h |1 +
8 files changed, 26 insertions(+), 28 deletions(-)
Index: linux-2.6.24-rc7/arch/x86/kernel/process_32.c
===
--- linux-2.6.24-rc7.orig/arch/x86/kernel/process_32.c
+++ linux-2.6.24-rc7/arch/x86/kernel/process_32.c
@@ -358,7 +358,7 @@ void __show_registers(struct pt_regs *re
void show_regs(struct pt_regs *regs)
{
__show_registers(regs, 1);
- show_trace(NULL, regs, ®s->esp);
+ show_trace(NULL, regs, ®s->esp, regs->ebp);
}
/*
Index: linux-2.6.24-rc7/arch/x86/kernel/process_64.c
===
--- linux-2.6.24-rc7.orig/arch/x86/kernel/process_64.c
+++ linux-2.6.24-rc7/arch/x86/kernel/process_64.c
@@ -368,7 +368,7 @@ void show_regs(struct pt_regs *regs)
{
printk("CPU %d:", smp_processor_id());
__show_regs(regs);
- show_trace(NULL, regs, (void *)(regs + 1));
+ show_trace(NULL, regs, (void *)(regs + 1), regs->rbp);
}
/*
Index: linux-2.6.24-rc7/arch/x86/kernel/stacktrace.c
===
--- linux-2.6.24-rc7.orig/arch/x86/kernel/stacktrace.c
+++ linux-2.6.24-rc7/arch/x86/kernel/stacktrace.c
@@ -45,7 +45,7 @@ static const struct stacktrace_ops save_
*/
void save_stack_trace(struct stack_trace *trace)
{
- dump_trace(current, NULL, NULL, &save_stack_ops, trace);
+ dump_trace(current, NULL, NULL, 0, &save_stack_ops, trace);
if (trace->nr_entries < trace->max_entries)
trace->entries[trace->nr_entries++] = ULONG_MAX;
}
Index: linux-2.6.24-rc7/arch/x86/kernel/traps_32.c
===
--- linux-2.6.24-rc7.orig/arch/x86/kernel/traps_32.c
+++ linux-2.6.24-rc7/arch/x86/kernel/traps_32.c
@@ -119,15 +119,6 @@ static inline unsigned long print_contex
{
struct stack_frame *frame = (struct stack_frame *)ebp;
- /*
-* if EBP is "deeper" into the stack than the actual stack pointer,
-* we need to rewind the stack pointer a little to start at the
-* first stack frame, but only if EBP is in this stack frame.
-*/
- if (stack > (unsigned long *) ebp
- && valid_stack_ptr(tinfo, frame, sizeof(*frame)))
- stack = (unsigned long *) ebp;
-
while (valid_stack_ptr(tinfo, stack, sizeof(*stack))) {
unsigned long addr;
@@ -138,7 +129,7 @@ static inline unsigned long print_contex
frame = frame->next_frame;
ebp = (unsigned long) frame;
} else {
- ops->address(data, addr, 0);
+ ops->address(data, addr, ebp == 0);
}
}
stack++;
@@ -149,11 +140,9 @@ static inline unsigned long print_contex
#define MSG(msg) ops->warning(data, msg)
void dump_trace(struct task_struct *task, struct pt_regs *regs,
- unsigned long *stack,
+ unsigned long *stack, unsigned long ebp,
const struct stacktrace_ops *ops, void *data)
{
- unsigned long ebp = 0;
-
if (!task)
task = current;
@@ -233,20 +222,20 @@ static const struct stacktrace_ops print
static void
show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs,
- unsigned long * stack, char *log_lvl)
+ unsigned long *stack, unsigned long ebp, char *log_lvl)
{
- dump_trace(task, regs, stack, &print_trace_ops, log_lvl);
+ dump_trace(task, regs, stack, ebp, &print_trace_ops, log_lvl);
printk("%s ===\n", log_lvl);
}
void show_trace(struct task_struct *task, struct pt_regs *regs,
- unsigned long * stack)
+ unsigned long *stack, unsigned long ebp)
{
- show_trace_log_lvl(task, regs, stack, "");
+
[patch 1/8] x86: Fix x86 32 bit FRAME_POINTER chasing code
Subject: Fix x86 32 bit FRAME_POINTER chasing code From: Arjan van de Ven <[EMAIL PROTECTED]> The current x86 32 bit FRAME_POINTER chasing code has a nasty bug in that the EBP tracer doesn't actually update the value of EBP it is tracing, so that the code doesn't actually switch to the irq stack properly. The result is a truncated backtrace: WARNING: at timeroops.c:8 kerneloops_regression_test() (Not tainted) Pid: 0, comm: swapper Not tainted 2.6.24-0.77.rc4.git4.fc9 #1 [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x6c/0x72 [] kerneloops_regression_test+0x44/0x46 [timeroops] [] run_timer_softirq+0x127/0x18f [] __do_softirq+0x78/0xff [] do_softirq+0x74/0xf7 === This patch fixes the code to update EBP properly, and to check the EIP before printing (as the non-framepointer backtracer does) so that the same test backtrace now looks like this: WARNING: at timeroops.c:8 kerneloops_regression_test() Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #4 [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x6a/0x70 [] kerneloops_regression_test+0x3b/0x3d [timeroops] [] run_timer_softirq+0x11b/0x17c [] __do_softirq+0x42/0x94 [] do_softirq+0x50/0xb6 [] irq_exit+0x37/0x67 [] do_IRQ+0x9a/0xaf [] common_interrupt+0x2e/0x34 [] cpuidle_idle_call+0x52/0x78 [] cpu_idle+0x46/0x60 [] rest_init+0x43/0x45 [] start_kernel+0x279/0x27f === This shows that the backtrace goes all the way down to user context now. This bug was found during the port to 64 bit of the frame pointer backtracer. Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]> --- arch/x86/kernel/traps_32.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Index: linux-2.6.24-rc7/arch/x86/kernel/traps_32.c === --- linux-2.6.24-rc7.orig/arch/x86/kernel/traps_32.c +++ linux-2.6.24-rc7/arch/x86/kernel/traps_32.c @@ -124,7 +124,8 @@ static inline unsigned long print_contex unsigned long addr; addr = frame->return_address; - ops->address(data, addr); + if (__kernel_text_address(addr)) + ops->address(data, addr); /* * break out of recursive entries (such as * end_of_stack_stop_unwind_function). Also, @@ -132,6 +133,7 @@ static inline unsigned long print_contex * move downwards! */ next = frame->next_frame; + ebp = (unsigned long) next; if (next <= frame) break; frame = next; -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.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/
[patch 0/8] Series to improve the x86 backtracing code
Hi, this patch series improves the x86 backtracing code in the following ways: 1) Fix a bad bug in x86 (32 bit) FRAME_POINTER backtracing (2.6.24 material) 2) Add the capability to mark a backtrace entry as reliable / unreliable 3) Change the x86 (32 bit) FRAME_POINTER backtracing to use the normal backtrace but use the frames as guidance to the reliability of the backtrace entries 4) Patch to capture the EBP register earlier in the backtrace callchain to get a better FRAME_POINTER based backtrace 5) Split the x86 (64 bit) backtrace code up similar to the 32 bit code by turning a macro into a function 6) Enable FRAME_POINTER backtracing on 64 bit similar to the 32 bit patch in number 3 7) Add a simple self-test module for backtraces (will move to tests/ later when that gets merged) 8) Add the feature to x86 64bit to print a set of bytes prior to the current EIP in the Code: line (already present in 32 bit) I have not yet implemented 2 requested items 1) To give dump_stack() and co a parameter towards the KERN_ log level; this is a patch that touches 125 files and while I like the idea I'm not sure it's worth THAT. 2) Linus' request to only print the first 5 entries of a backtrace with a important loglevel, and do the rest as KERN_WARNING or so. This realistically wants 1) and I've not gotten to it yet (and it's independent functionality anyway) Andrew: You already have patch 1 in your tree, and it's not modified since that, so no need to refresh -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] attribute_container: update to use the group interface
On Wed, Jan 02, 2008 at 06:48:47PM -0600, James Bottomley wrote: > This patch is the beginning of moving the attribute_containers to use > attribute groups exclusively. The attr element is now deprecated and > will eventually be removed (along with all the hand rolled code for > doing exactly what attribute groups do) when all the consumers are > converted to attribute groups. > > Signed-off-by: James Bottomley <[EMAIL PROTECTED]> Feel free to add: Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> and take it through your tree. 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: [PATCH] fix the sysfs_add_file_to_group interfaces
On Wed, Jan 02, 2008 at 06:44:05PM -0600, James Bottomley wrote: > I can't see a reason why these shouldn't work on every group. However, > they only seem to work on named groups. This patch allows the group > functions to work on anonymous groups (those with NULL names). > > Signed-off-by: James Bottomley <[EMAIL PROTECTED]> Feel free to add: Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> and take it through your tree. 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: [PATCH 001/001] ipv4: enable use of 240/4 address space
In article <[EMAIL PROTECTED]> (at Fri, 11 Jan 2008 17:48:57 -0800 (PST)), David Miller <[EMAIL PROTECTED]> says: > From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> > Date: Fri, 11 Jan 2008 21:41:20 +0900 (JST) > > > There is no positive consesus on this draft > > at the intarea meeting in Vancouver, right? > > > > We cannot / should not enable that space until we have reached > > a consensus on it. > > This is so incredibly incorrect. > > There is consensus on making network stacks able to use this > address space. And that is all that the patch does. No, we did never make consensus on it. > The consensus is only missing on whether to make the address > space public or private. > > This is also clearly spelled out in the draft. > > It is important to get as large of a head start on this as > possible because of how long it takes to deploy something > like this. Okay, though I am afraid this space will not be used widely, we should be ready for it. I'll make some more comments on the patch itself from another point view. --yoshfuji -- 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] per-task I/O throttling
On Fri, 11 Jan 2008 17:32:49 +0100, Andrea Righi said: > The interesting feature is that it allows to set a priority for each > process container, but AFAIK it doesn't allow to "partition" the > bandwidth between different containers (that would be a nice feature > IMHO). For example it would be great to be able to define per-container > limits, like assign 10MB/s for processes in container A, 30MB/s to > container B, 20MB/s to container C, etc. Has anybody considered allocating based on *seeks* rather than bytes moved, or counting seeks as "virtual bytes" for the purposes of accounting (if the disk can do 50mbytes/sec, and a seek takes 5millisecs, then count it as 100K of data)? pgpLJCx5zrQRv.pgp Description: PGP signature
Re: [TOMOYO #6 retry 08/21] Utility functions and policy manipulationinterface.
On Sat, Jan 12, 2008 at 11:06:17AM +0900, Tetsuo Handa wrote: > Hello. > > James Morris wrote: > > > > TOMOYO Linux uses /sys/kernel/security/tomoyo interface for > > > > configuration. > > > > > > Why aren't you using securityfs for this? (It was designed for LSMs). > > > > Doh, it is using securityfs, don't worry. > > > I got a mm-commits mail titled > "+ sysfs-make-sysfs_deprecated-depend-on-sysfs.patch added to -mm tree" . > > Is sysfs going to be deprecated? No, there is a config option, CONFIG_SYSFS_DEPRECATED which enables some older sysfs symlinks and layouts. That patch from Randy Dunlap was just fixing up some config dependancies that were found, that's all. > If sysfs becomes not available at /sys/ , where securityfs is going to be > mounted? sysfs is not going away any time soon, don't worry :) 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/
Is try_module_get buggy?
Hi,
I have a problem about the try_module_get function, I don't know if someone
removed the module just AFTER line 372, then what happens? Because in this
situation, the variable module will be incorrect, and module_is_live
function will lead to unpredicatable behaviour.
368 static inline int try_module_get(struct module *module)
369 {
370 int ret = 1;
371
372 if (module) {
373 unsigned int cpu = get_cpu();
374 if (likely(module_is_live(module)))
375 local_inc(&module->ref[cpu].count);
376 else
377 ret = 0;
378 put_cpu();
379 }
380 return ret;
381 }
Best wishes to all,
rmingming
--
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 0/4] PM: Do not destroy/create devices while suspended (rev. 2)
On Fri, Jan 11, 2008 at 10:11:52PM -0500, Alan Stern wrote: > On Fri, 11 Jan 2008, Greg KH wrote: > > > On Fri, Jan 11, 2008 at 04:49:04PM -0800, Andrew Morton wrote: > > > > err, no. pm-introduce-destroy_suspended_device.patch demolishes > > > pm-acquire-device-locks-on-suspend-rev-3.patch > > > > > > Confused, giving up. > > > > I'm confused too, I have no idea what the proper order of things should > > be either. Anyone want to give me a hint? > > Sorry for the confusion. The correct patch to apply is > pm-acquire-device-locks-on-suspend-rev-3 (plus the attending > style-fixups). It encompasses those earlier patches. Can someone resend this to me? Do I need to drop the patch I currently have in my tree as well? Or put it before/after that one? > The real problem is that our current email workflow patterns don't > provide a standardized way for maintainers to tell when a new patch > submission is meant to override or replace an earlier submission (or > even a set of earlier submissions). Does anybody have some suggestions > for a good way to do this? Yeah, just tell me what you want me to do with it (drop an old one, replace it, add it, etc.) We usually can handle this pretty well :) 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/
problem about try_module_get(struct module *module)
Hi,
I have a problem about the try_module_get function, I don't know if someone
removed the module just AFTER line 372, then what happens? Because in this
situation, the variable module will be incorrect, and module_is_live
function will
lead to unpredicatable behaviour.
368 static inline int try_module_get(struct module *module)
369 {
370 int ret = 1;
371
372 if (module) {
373 unsigned int cpu = get_cpu();
374 if (likely(module_is_live(module)))
375 local_inc(&module->ref[cpu].count);
376 else
377 ret = 0;
378 put_cpu();
379 }
380 return ret;
381 }
Best wishes to all,
rmingming
--
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 19 4/5] Convert PowerPC MPC i2c to of_platform_driver from platform_driver
Hi Jon,
On Fri, 11 Jan 2008 21:47:46 -0500 Jon Smirl <[EMAIL PROTECTED]> wrote:
>
> +++ b/drivers/i2c/busses/i2c-mpc.c
> +static void of_register_i2c_devices(struct i2c_adapter *adap, struct
> device_node *adap_node)
> +{
> + struct device_node *node = NULL;
> +
> + while ((node = of_get_next_child(adap_node, node))) {
We have for_each_child_of_node(adap_node, node) now for this (and it
means you don't need to initialize the "node" above).
> + struct i2c_board_info info;
> + const u32 *addr;
> + const char *compatible;
> + int len;
> +
> + addr = of_get_property(node, "reg", &len);
> + if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
> + printk(KERN_ERR "i2c-mpc.c: invalid entry, missing reg
> attribute\n");
> + continue;
> + }
> +
> + info.irq = irq_of_parse_and_map(node, 0);
> + if (info.irq == NO_IRQ)
> + info.irq = -1;
> +
> + compatible = of_get_property(node, "compatible", &len);
> + if (!compatible) {
> + printk(KERN_ERR "i2c-mpc.c: invalid entry, missing
> compatible attribute\n");
> + continue;
You may need to clean up from the irq_of_pase_and_map().
> + }
> +
> + /* need full alias i2c:NOF,vendor,device */
> + strcpy(info.type, I2C_OF_MODULE_PREFIX);
> + strncat(info.type, compatible, sizeof(info.type));
> + request_module(info.type);
> +
> + /* need module alias OF,vendor,device */
> + strcpy(info.type, OF_I2C_PREFIX);
> + strncat(info.type, compatible, sizeof(info.type));
> +
> + info.driver_name[0] = '\0';
> + info.platform_data = NULL;
> + info.addr = *addr;
> +
> + if (!i2c_new_device(adap, &info)) {
> + printk(KERN_ERR "i2c-mpc.c: Failed to load driver for
> %s\n", info.type);
> + continue;
And again.
> + }
> + }
> +}
> +
> +static int mpc_i2c_probe(struct of_device *op, const struct of_device_id
> *match)
> +{
> + dev_set_drvdata(&op->dev, i2c);
> +
> + i2c->adap = mpc_ops;
> + i2c_set_adapdata(&i2c->adap, i2c);
> + i2c->adap.dev.parent = &op->dev;
> +
> + result = i2c_add_adapter(&i2c->adap);
> + if (result < 0) {
> + printk(KERN_ERR "i2c-mpc - failed to add adapter\n");
> + goto fail_add;
> + }
> +
> + of_register_i2c_devices(&i2c->adap, op->node);
> +
> + return result;
> +
> +fail_add:
dev_set_dvdata(&op->dev, NULL);
> + free_irq(i2c->irq, i2c);
> +fail_request:
> + irq_dispose_mapping(i2c->irq);
> +fail_irq:
> + iounmap(i2c->base);
> +fail_map:
> + kfree(i2c);
> + return result;
> +};
> +static struct of_device_id mpc_i2c_of_match[] = {
const, please.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpVOoSLzHK33.pgp
Description: PGP signature
Re: [i2c] [PATCH 19 1/5] Implement module aliasing for i2c to translate from device tree names
Hi Jon,
On Fri, 11 Jan 2008 22:00:42 -0500 "Jon Smirl" <[EMAIL PROTECTED]> wrote:
>
> +++ b/drivers/hwmon/f75375s.c
> @@ -117,7 +117,7 @@ struct f75375_data {
> static int f75375_attach_adapter(struct i2c_adapter *adapter);
> static int f75375_detect(struct i2c_adapter *adapter, int address, int kind);
> static int f75375_detach_client(struct i2c_client *client);
> -static int f75375_probe(struct i2c_client *client);
> +static int f75375_probe(struct i2c_client *client, const struct
> i2c_device_id *id);
Looks like your mail client has wrapped this. Also in various later
spots.
> +++ b/drivers/i2c/i2c-core.c
> @@ -47,6 +47,19 @@ static DEFINE_IDR(i2c_adapter_idr);
>
> /* -
> */
>
> +static const struct i2c_device_id *i2c_match_id(
> + const struct i2c_device_id *id, struct i2c_client *client)
Any reason that the "client" argument is not const as well?
> +++ b/include/linux/i2c.h
> @@ -141,11 +141,10 @@ struct i2c_driver {
>
> struct device_driver driver;
> struct list_head list;
> + struct i2c_device_id *id_table;
Any reason that this is not const? Making it const would allow divers to
make their tables const.
These are just small things (apart from the wrapping) that can be fixed
up with followup patches.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpxrJjcw8Inu.pgp
Description: PGP signature
Re: [PATCH 0/4] PM: Do not destroy/create devices while suspended (rev. 2)
On Fri, 11 Jan 2008 22:11:52 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > On Fri, 11 Jan 2008, Greg KH wrote: > > > On Fri, Jan 11, 2008 at 04:49:04PM -0800, Andrew Morton wrote: > > > > err, no. pm-introduce-destroy_suspended_device.patch demolishes > > > pm-acquire-device-locks-on-suspend-rev-3.patch > > > > > > Confused, giving up. > > > > I'm confused too, I have no idea what the proper order of things should > > be either. Anyone want to give me a hint? > > Sorry for the confusion. The correct patch to apply is > pm-acquire-device-locks-on-suspend-rev-3 (plus the attending > style-fixups). It encompasses those earlier patches. > > The real problem is that our current email workflow patterns don't > provide a standardized way for maintainers to tell when a new patch > submission is meant to override or replace an earlier submission (or > even a set of earlier submissions). Does anybody have some suggestions > for a good way to do this? > Don't formally send it until it's ready. Seriously. You can always resend it if it didn't get applied anywhere. Once a patch reaches a sufficient level of maturity for it to be ready to be merged into a subsystem tree, any subsequent changes should be sufficiently small that incremental patches are the way to apply touchups. The core problem here is that (lots of) people are flinging patches at tree-owners before they are sufficiently baked. -- 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 0/4] PM: Do not destroy/create devices while suspended (rev. 2)
> The real problem is that our current email workflow patterns don't > provide a standardized way for maintainers to tell when a new patch > submission is meant to override or replace an earlier submission (or > even a set of earlier submissions). Does anybody have some suggestions > for a good way to do this? The versioning approach pioneered by Christoph Lameter seems to work reasonably well. If you post a new version increase a version number and add it with "vXXX" to the Subject. Also add a short change log between versions at the bottom; e.g. v1->v2: etc. Then it is always clear what is the latest'n'greatest. -Andi -- 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 0/4] PM: Do not destroy/create devices while suspended (rev. 2)
On Fri, 11 Jan 2008, Greg KH wrote: > On Fri, Jan 11, 2008 at 04:49:04PM -0800, Andrew Morton wrote: > > err, no. pm-introduce-destroy_suspended_device.patch demolishes > > pm-acquire-device-locks-on-suspend-rev-3.patch > > > > Confused, giving up. > > I'm confused too, I have no idea what the proper order of things should > be either. Anyone want to give me a hint? Sorry for the confusion. The correct patch to apply is pm-acquire-device-locks-on-suspend-rev-3 (plus the attending style-fixups). It encompasses those earlier patches. The real problem is that our current email workflow patterns don't provide a standardized way for maintainers to tell when a new patch submission is meant to override or replace an earlier submission (or even a set of earlier submissions). Does anybody have some suggestions for a good way to do this? Alan Stern -- 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: [TOMOYO #6 retry 08/21] Utility functions and policy manipulationinterface.
On Sat, 12 Jan 2008, Tetsuo Handa wrote: > Hello. > > James Morris wrote: > > > > TOMOYO Linux uses /sys/kernel/security/tomoyo interface for > > > > configuration. > > > > > > Why aren't you using securityfs for this? (It was designed for LSMs). > > > > Doh, it is using securityfs, don't worry. > > > I got a mm-commits mail titled > "+ sysfs-make-sysfs_deprecated-depend-on-sysfs.patch added to -mm tree" . > > Is sysfs going to be deprecated? Unlikely -- what's in the patches? - James -- James Morris <[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: [i2c] [PATCH 19 1/5] Implement module aliasing for i2c to translate from device tree names
Comment was wrong, I2C_OF_MODULE_PREFIX was needed. Add it back.
Implement module aliasing for i2c to translate from device tree names
This patch allows new style i2c chip drivers to have alias names using
the official kernel aliasing system and MODULE_DEVICE_TABLE(). I've
tested it on PowerPC and x86. This change is required for PowerPC
device tree support.
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
drivers/hwmon/f75375s.c |4 ++--
drivers/i2c/chips/ds1682.c |2 +-
drivers/i2c/chips/menelaus.c|2 +-
drivers/i2c/chips/tps65010.c|2 +-
drivers/i2c/chips/tsl2550.c |2 +-
drivers/i2c/i2c-core.c | 24 +++-
drivers/rtc/rtc-ds1307.c|2 +-
drivers/rtc/rtc-ds1374.c|2 +-
drivers/rtc/rtc-m41t80.c|2 +-
drivers/rtc/rtc-rs5c372.c |2 +-
include/linux/i2c.h |5 ++---
include/linux/mod_devicetable.h | 20
scripts/mod/file2alias.c| 12
13 files changed, 67 insertions(+), 14 deletions(-)
diff --git a/drivers/hwmon/f75375s.c b/drivers/hwmon/f75375s.c
index 6892f76..2247de6 100644
--- a/drivers/hwmon/f75375s.c
+++ b/drivers/hwmon/f75375s.c
@@ -117,7 +117,7 @@ struct f75375_data {
static int f75375_attach_adapter(struct i2c_adapter *adapter);
static int f75375_detect(struct i2c_adapter *adapter, int address, int kind);
static int f75375_detach_client(struct i2c_client *client);
-static int f75375_probe(struct i2c_client *client);
+static int f75375_probe(struct i2c_client *client, const struct
i2c_device_id *id);
static int f75375_remove(struct i2c_client *client);
static struct i2c_driver f75375_legacy_driver = {
@@ -628,7 +628,7 @@ static void f75375_init(struct i2c_client *client,
struct f75375_data *data,
}
-static int f75375_probe(struct i2c_client *client)
+static int f75375_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct f75375_data *data = i2c_get_clientdata(client);
struct f75375s_platform_data *f75375s_pdata = client->dev.platform_data;
diff --git a/drivers/i2c/chips/ds1682.c b/drivers/i2c/chips/ds1682.c
index 9e94542..93c0441 100644
--- a/drivers/i2c/chips/ds1682.c
+++ b/drivers/i2c/chips/ds1682.c
@@ -200,7 +200,7 @@ static struct bin_attribute ds1682_eeprom_attr = {
/*
* Called when a ds1682 device is matched with this driver
*/
-static int ds1682_probe(struct i2c_client *client)
+static int ds1682_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
int rc;
diff --git a/drivers/i2c/chips/menelaus.c b/drivers/i2c/chips/menelaus.c
index 2dea012..89ef9b6 100644
--- a/drivers/i2c/chips/menelaus.c
+++ b/drivers/i2c/chips/menelaus.c
@@ -1149,7 +1149,7 @@ static inline void menelaus_rtc_init(struct
menelaus_chip *m)
static struct i2c_driver menelaus_i2c_driver;
-static int menelaus_probe(struct i2c_client *client)
+static int menelaus_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct menelaus_chip*menelaus;
int rev = 0, val;
diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c
index e320994..6b13642 100644
--- a/drivers/i2c/chips/tps65010.c
+++ b/drivers/i2c/chips/tps65010.c
@@ -465,7 +465,7 @@ static int __exit tps65010_remove(struct i2c_client *client)
return 0;
}
-static int tps65010_probe(struct i2c_client *client)
+static int tps65010_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct tps65010 *tps;
int status;
diff --git a/drivers/i2c/chips/tsl2550.c b/drivers/i2c/chips/tsl2550.c
index 3de4b19..27c553d 100644
--- a/drivers/i2c/chips/tsl2550.c
+++ b/drivers/i2c/chips/tsl2550.c
@@ -364,7 +364,7 @@ static int tsl2550_init_client(struct i2c_client *client)
*/
static struct i2c_driver tsl2550_driver;
-static int __devinit tsl2550_probe(struct i2c_client *client)
+static int __devinit tsl2550_probe(struct i2c_client *client, const
struct i2c_device_id *id)
{
struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
struct tsl2550_data *data;
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index b5e13e4..5f62230 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -47,6 +47,19 @@ static DEFINE_IDR(i2c_adapter_idr);
/* - */
+static const struct i2c_device_id *i2c_match_id(
+ const struct i2c_device_id *id, struct i2c_client *client)
+{
+ /* only powerpc drivers implement the id_table,
+* it is empty on other platforms */
+ while (id->name[0]) {
+ if (strcmp(client->name, id->name) == 0)
+ return id;
+ id++;
+ }
+ return NULL;
+}
+
static int i2c_device_match(struct device *dev, struct device_driver *drv)
{
struct i2c_client *client = to_i2c_clie
[PATCH 19 1/5] Implement module aliasing for i2c to translate from device tree names
This patch allows new style i2c chip drivers to have alias names using
the official kernel aliasing system and MODULE_DEVICE_TABLE(). I've
tested it on PowerPC and x86. This change is required for PowerPC
device tree support.
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
drivers/hwmon/f75375s.c |4 ++--
drivers/i2c/chips/ds1682.c |2 +-
drivers/i2c/chips/menelaus.c|2 +-
drivers/i2c/chips/tps65010.c|2 +-
drivers/i2c/chips/tsl2550.c |2 +-
drivers/i2c/i2c-core.c | 24 +++-
drivers/rtc/rtc-ds1307.c|2 +-
drivers/rtc/rtc-ds1374.c|2 +-
drivers/rtc/rtc-m41t80.c|2 +-
drivers/rtc/rtc-rs5c372.c |2 +-
include/linux/i2c.h |5 ++---
include/linux/mod_devicetable.h | 19 +++
scripts/mod/file2alias.c| 14 ++
13 files changed, 68 insertions(+), 14 deletions(-)
diff --git a/drivers/hwmon/f75375s.c b/drivers/hwmon/f75375s.c
index 6892f76..2247de6 100644
--- a/drivers/hwmon/f75375s.c
+++ b/drivers/hwmon/f75375s.c
@@ -117,7 +117,7 @@ struct f75375_data {
static int f75375_attach_adapter(struct i2c_adapter *adapter);
static int f75375_detect(struct i2c_adapter *adapter, int address, int kind);
static int f75375_detach_client(struct i2c_client *client);
-static int f75375_probe(struct i2c_client *client);
+static int f75375_probe(struct i2c_client *client, const struct i2c_device_id
*id);
static int f75375_remove(struct i2c_client *client);
static struct i2c_driver f75375_legacy_driver = {
@@ -628,7 +628,7 @@ static void f75375_init(struct i2c_client *client, struct
f75375_data *data,
}
-static int f75375_probe(struct i2c_client *client)
+static int f75375_probe(struct i2c_client *client, const struct i2c_device_id
*id)
{
struct f75375_data *data = i2c_get_clientdata(client);
struct f75375s_platform_data *f75375s_pdata = client->dev.platform_data;
diff --git a/drivers/i2c/chips/ds1682.c b/drivers/i2c/chips/ds1682.c
index 9e94542..93c0441 100644
--- a/drivers/i2c/chips/ds1682.c
+++ b/drivers/i2c/chips/ds1682.c
@@ -200,7 +200,7 @@ static struct bin_attribute ds1682_eeprom_attr = {
/*
* Called when a ds1682 device is matched with this driver
*/
-static int ds1682_probe(struct i2c_client *client)
+static int ds1682_probe(struct i2c_client *client, const struct i2c_device_id
*id)
{
int rc;
diff --git a/drivers/i2c/chips/menelaus.c b/drivers/i2c/chips/menelaus.c
index 2dea012..89ef9b6 100644
--- a/drivers/i2c/chips/menelaus.c
+++ b/drivers/i2c/chips/menelaus.c
@@ -1149,7 +1149,7 @@ static inline void menelaus_rtc_init(struct menelaus_chip
*m)
static struct i2c_driver menelaus_i2c_driver;
-static int menelaus_probe(struct i2c_client *client)
+static int menelaus_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct menelaus_chip*menelaus;
int rev = 0, val;
diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c
index e320994..6b13642 100644
--- a/drivers/i2c/chips/tps65010.c
+++ b/drivers/i2c/chips/tps65010.c
@@ -465,7 +465,7 @@ static int __exit tps65010_remove(struct i2c_client *client)
return 0;
}
-static int tps65010_probe(struct i2c_client *client)
+static int tps65010_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct tps65010 *tps;
int status;
diff --git a/drivers/i2c/chips/tsl2550.c b/drivers/i2c/chips/tsl2550.c
index 3de4b19..27c553d 100644
--- a/drivers/i2c/chips/tsl2550.c
+++ b/drivers/i2c/chips/tsl2550.c
@@ -364,7 +364,7 @@ static int tsl2550_init_client(struct i2c_client *client)
*/
static struct i2c_driver tsl2550_driver;
-static int __devinit tsl2550_probe(struct i2c_client *client)
+static int __devinit tsl2550_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
struct tsl2550_data *data;
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index b5e13e4..5f62230 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -47,6 +47,19 @@ static DEFINE_IDR(i2c_adapter_idr);
/* - */
+static const struct i2c_device_id *i2c_match_id(
+ const struct i2c_device_id *id, struct i2c_client *client)
+{
+ /* only powerpc drivers implement the id_table,
+* it is empty on other platforms */
+ while (id->name[0]) {
+ if (strcmp(client->name, id->name) == 0)
+ return id;
+ id++;
+ }
+ return NULL;
+}
+
static int i2c_device_match(struct device *dev, struct device_driver *drv)
{
struct i2c_client *client = to_i2c_client(dev);
@@ -58,6 +71,10 @@ static int i2c_device_match(struct device *dev, struct
device_driver *drv)
if (!i
[PATCH 19 0/5] Version 18, series to add device tree naming to i2c
Updated to reflect comments in: http://lkml.org/lkml/2008/1/11/272 Since copying i2c-mpc.c to maintain support for the ppc architecture seems to be an issue; instead rework i2c-mpc.c to use CONFIG_PPC_MERGE #ifdefs to support both the ppc and powerpc architecture. When ppc is deleted in six months these #ifdefs will need to be removed. Another rework of the i2c for powerpc device tree patch. This version implements standard alias naming only on the powerpc platform and only for the device tree names. The old naming mechanism of i2c_client.name,driver_name is left in place and not changed for non-powerpc platforms. This patch is fully capable of dynamically loading the i2c modules. You can modprobe in the i2c-mpc driver and the i2c modules described in the device tree will be automatically loaded. Modules also work if compiled in. The follow on patch to module-init-tools is also needed since the i2c subsystem has never implemented dynamic loading. http://lkml.org/lkml/2007/12/17/493 The following series implements standard linux module aliasing for i2c modules on arch=powerpc. It then converts the mpc i2c driver from being a platform driver to an open firmware one. I2C device names are picked up from the device tree. Module aliasing is used to translate from device tree names into to linux kernel names. Several i2c drivers are updated to use the new aliasing. -- Jon Smirl [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 19 5/5] Convert pfc8563 i2c driver from old style to new style
Convert pfc8563 i2c driver from old style to new style. The
driver is also modified to support device tree names via the
i2c mod alias mechanism.
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
drivers/rtc/rtc-pcf8563.c | 107 +++--
1 files changed, 27 insertions(+), 80 deletions(-)
diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index 0242d80..e1ea2a0 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -25,10 +25,6 @@
* located at 0x51 will pass the validation routine due to
* the way the registers are implemented.
*/
-static unsigned short normal_i2c[] = { I2C_CLIENT_END };
-
-/* Module parameters */
-I2C_CLIENT_INSMOD;
#define PCF8563_REG_ST10x00 /* status */
#define PCF8563_REG_ST20x01
@@ -72,9 +68,6 @@ struct pcf8563 {
int c_polarity; /* 0: MO_C=1 means 19xx, otherwise MO_C=1 means 20xx */
};
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind);
-static int pcf8563_detach(struct i2c_client *client);
-
/*
* In the routines that deal directly with the pcf8563 hardware, we use
* rtc_time -- month 0-11, hour 0-23, yr = calendar year-epoch.
@@ -257,98 +250,52 @@ static const struct rtc_class_ops pcf8563_rtc_ops = {
.set_time = pcf8563_rtc_set_time,
};
-static int pcf8563_attach(struct i2c_adapter *adapter)
+static int pcf8563_remove(struct i2c_client *client)
{
- return i2c_probe(adapter, &addr_data, pcf8563_probe);
+ struct rtc_device *rtc = i2c_get_clientdata(client);
+
+ if (rtc)
+ rtc_device_unregister(rtc);
+
+ return 0;
}
+static struct i2c_device_id pcf8563_id[] = {
+ OF_I2C_ID("philips,pcf8563", 0)
+ OF_I2C_ID("epson,rtc8564", 0)
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, pcf8563_id);
+
+static int pcf8563_probe(struct i2c_client *client, const struct i2c_device_id
*id);
+
static struct i2c_driver pcf8563_driver = {
.driver = {
- .name = "pcf8563",
+ .name = "rtc-pcf8563",
},
.id = I2C_DRIVERID_PCF8563,
- .attach_adapter = &pcf8563_attach,
- .detach_client = &pcf8563_detach,
+ .probe = &pcf8563_probe,
+ .remove = &pcf8563_remove,
+ .id_table = pcf8563_id,
};
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind)
+static int pcf8563_probe(struct i2c_client *client, const struct i2c_device_id
*id)
{
- struct pcf8563 *pcf8563;
- struct i2c_client *client;
+ int result;
struct rtc_device *rtc;
- int err = 0;
-
- dev_dbg(&adapter->dev, "%s\n", __FUNCTION__);
-
- if (!i2c_check_functionality(adapter, I2C_FUNC_I2C)) {
- err = -ENODEV;
- goto exit;
- }
-
- if (!(pcf8563 = kzalloc(sizeof(struct pcf8563), GFP_KERNEL))) {
- err = -ENOMEM;
- goto exit;
- }
-
- client = &pcf8563->client;
- client->addr = address;
- client->driver = &pcf8563_driver;
- client->adapter = adapter;
-
- strlcpy(client->name, pcf8563_driver.driver.name, I2C_NAME_SIZE);
-
- /* Verify the chip is really an PCF8563 */
- if (kind < 0) {
- if (pcf8563_validate_client(client) < 0) {
- err = -ENODEV;
- goto exit_kfree;
- }
- }
-
- /* Inform the i2c layer */
- if ((err = i2c_attach_client(client)))
- goto exit_kfree;
-
- dev_info(&client->dev, "chip found, driver version " DRV_VERSION "\n");
+ result = pcf8563_validate_client(client);
+ if (result)
+ return result;
rtc = rtc_device_register(pcf8563_driver.driver.name, &client->dev,
&pcf8563_rtc_ops, THIS_MODULE);
-
- if (IS_ERR(rtc)) {
- err = PTR_ERR(rtc);
- goto exit_detach;
- }
+ if (IS_ERR(rtc))
+ return PTR_ERR(rtc);
i2c_set_clientdata(client, rtc);
return 0;
-
-exit_detach:
- i2c_detach_client(client);
-
-exit_kfree:
- kfree(pcf8563);
-
-exit:
- return err;
-}
-
-static int pcf8563_detach(struct i2c_client *client)
-{
- struct pcf8563 *pcf8563 = container_of(client, struct pcf8563, client);
- int err;
- struct rtc_device *rtc = i2c_get_clientdata(client);
-
- if (rtc)
- rtc_device_unregister(rtc);
-
- if ((err = i2c_detach_client(client)))
- return err;
-
- kfree(pcf8563);
-
- return 0;
}
static int __init pcf8563_init(void)
--
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 19 4/5] Convert PowerPC MPC i2c to of_platform_driver from platform_driver
Convert MPC i2c driver from being a platform_driver to an open firmware
version. Error returns were improved. Routine names were changed from fsl_ to
mpc_ to make them match the file name.
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c | 96 --
drivers/i2c/busses/i2c-mpc.c | 183 -
2 files changed, 180 insertions(+), 99 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 94e5c73..d6ef264 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -318,102 +318,6 @@ err:
arch_initcall(gfar_of_init);
-#ifdef CONFIG_I2C_BOARDINFO
-#include
-
-static void __init of_register_i2c_devices(struct device_node *adap_node,
- int bus_num)
-{
- struct device_node *node = NULL;
- const char *compatible;
-
- while ((node = of_get_next_child(adap_node, node))) {
- struct i2c_board_info info = {};
- const u32 *addr;
- int len;
-
- addr = of_get_property(node, "reg", &len);
- if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
- printk(KERN_WARNING "fsl_soc.c: invalid i2c device
entry\n");
- continue;
- }
-
- info.irq = irq_of_parse_and_map(node, 0);
- if (info.irq == NO_IRQ)
- info.irq = -1;
-
- compatible = of_get_property(node, "compatible", &len);
- if (!compatible) {
- printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing
compatible attribute\n");
- continue;
- }
- strncpy(info.type, compatible, sizeof(info.type));
-
- info.addr = *addr;
-
- i2c_register_board_info(bus_num, &info, 1);
- }
-}
-
-static int __init fsl_i2c_of_init(void)
-{
- struct device_node *np;
- unsigned int i;
- struct platform_device *i2c_dev;
- int ret;
-
- for (np = NULL, i = 0;
-(np = of_find_compatible_node(np, "i2c", "fsl-i2c")) != NULL;
-i++) {
- struct resource r[2];
- struct fsl_i2c_platform_data i2c_data;
- const unsigned char *flags = NULL;
-
- memset(&r, 0, sizeof(r));
- memset(&i2c_data, 0, sizeof(i2c_data));
-
- ret = of_address_to_resource(np, 0, &r[0]);
- if (ret)
- goto err;
-
- of_irq_to_resource(np, 0, &r[1]);
-
- i2c_dev = platform_device_register_simple("fsl-i2c", i, r, 2);
- if (IS_ERR(i2c_dev)) {
- ret = PTR_ERR(i2c_dev);
- goto err;
- }
-
- i2c_data.device_flags = 0;
- flags = of_get_property(np, "dfsrr", NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
-
- flags = of_get_property(np, "fsl5200-clocking", NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_CLOCK_5200;
-
- ret =
- platform_device_add_data(i2c_dev, &i2c_data,
-sizeof(struct
- fsl_i2c_platform_data));
- if (ret)
- goto unreg;
-
- of_register_i2c_devices(np, i);
- }
-
- return 0;
-
-unreg:
- platform_device_unregister(i2c_dev);
-err:
- return ret;
-}
-
-arch_initcall(fsl_i2c_of_init);
-#endif
-
#ifdef CONFIG_PPC_83xx
static int __init mpc83xx_wdt_init(void)
{
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 7c35a8f..91fa73c 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -17,7 +17,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -25,13 +25,13 @@
#include
#include
-#define MPC_I2C_ADDR 0x00
+#define DRV_NAME "mpc-i2c"
+
#define MPC_I2C_FDR0x04
#define MPC_I2C_CR 0x08
#define MPC_I2C_SR 0x0c
#define MPC_I2C_DR 0x10
#define MPC_I2C_DFSRR 0x14
-#define MPC_I2C_REGION 0x20
#define CCR_MEN 0x80
#define CCR_MIEN 0x40
@@ -316,6 +316,181 @@ static struct i2c_adapter mpc_ops = {
.retries = 1
};
+struct i2c_driver_device {
+ char*of_device;
+ char*i2c_driver;
+ char*i2c_type;
+};
+
+#ifdef CONFIG_PPC_MERGE
+
+static void of_register_i2c_devices(struct i2c_adapter *adap, struct
device_node *adap_node)
+{
+ struct device_node *node = NULL;
+
+ while ((node = of_get_next_child(adap_node, node))) {
+ struct i2c_board_info info;
+ const u32 *addr;
+ const char *compatible;
+ int len;
+
Lenovo ThinkPads need acpi_osi="Linux"
While helping a user find out what happened to his mute key, I found out that the Lenovo BIOSes need the OSI string Linux defined to behave properly in Linux. Lenovo has been attempting to make things a bit easier for Linux on their ThinkPads, by disabling the more obnoxious behaviours of the firmware (used by their Windows drivers) when in Linux. It looks like they used the OSI string for that. It is probably worthwhile to give a head's up: regressions involving thinkpads and 2.6.23+ should probably have a 'please test with acpi_osi="Linux"' step added if there is any chance ACPI AML code, BIOS or SMBIOS code, or EC behaviour could be involved. The most concrete example I have right now of changed behaviour is the Mute key on the T61, which just plain disappears if acpi_osi="!Linux" (2.6.23 default). I have also seen some hacked DSDTs around (mostly for older T4x models) which used the Linux OSI string to fix or work around AML weirdness. Those would break in 2.6.23 (and 2.6.24?) as well. Now, what should we do about it? Add a quirk to always define the Linux OSI string on ThinkPads (based on DMI information)? All IBM ones (which won't have BIOS revisions anymore, anyway) deal well with it, and Lenovo ones seem to benefit from it. We could also ask Lenovo to change the BIOS to stop paying attention to that OSI string, but they will likely want/need a trigger for the AML code to know it should change behaviour anyway, and the OSI string *does* look like the proper thing to use IMHO. I don't know if we could get them to arrive to a behaviour that is acceptable both to us, and also to their Windows drivers... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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 19 3/5] Clean up error returns
Return errors that were being ignored in the mpc-i2c driver
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-mpc.c | 30 +-
1 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index d8de4ac..7c35a8f 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -180,7 +180,7 @@ static void mpc_i2c_stop(struct mpc_i2c *i2c)
static int mpc_write(struct mpc_i2c *i2c, int target,
const u8 * data, int length, int restart)
{
- int i;
+ int i, result;
unsigned timeout = i2c->adap.timeout;
u32 flags = restart ? CCR_RSTA : 0;
@@ -192,15 +192,17 @@ static int mpc_write(struct mpc_i2c *i2c, int target,
/* Write target byte */
writeb((target << 1), i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result < 0)
+ return result;
for (i = 0; i < length; i++) {
/* Write data byte */
writeb(data[i], i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result < 0)
+ return result;
}
return 0;
@@ -210,7 +212,7 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
u8 * data, int length, int restart)
{
unsigned timeout = i2c->adap.timeout;
- int i;
+ int i, result;
u32 flags = restart ? CCR_RSTA : 0;
/* Start with MEN */
@@ -221,8 +223,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
/* Write target address byte - this time with the read flag set */
writeb((target << 1) | 1, i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result < 0)
+ return result;
if (length) {
if (length == 1)
@@ -234,8 +237,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
}
for (i = 0; i < length; i++) {
- if (i2c_wait(i2c, timeout, 0) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 0);
+ if (result < 0)
+ return result;
/* Generate txack on next to last byte */
if (i == length - 2)
@@ -321,9 +325,9 @@ static int fsl_i2c_probe(struct platform_device *pdev)
pdata = (struct fsl_i2c_platform_data *) pdev->dev.platform_data;
- if (!(i2c = kzalloc(sizeof(*i2c), GFP_KERNEL))) {
+ i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
+ if (!i2c)
return -ENOMEM;
- }
i2c->irq = platform_get_irq(pdev, 0);
if (i2c->irq < 0) {
@@ -381,7 +385,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
i2c_del_adapter(&i2c->adap);
platform_set_drvdata(pdev, NULL);
- if (i2c->irq != 0)
+ if (i2c->irq != NO_IRQ)
free_irq(i2c->irq, i2c);
iounmap(i2c->base);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 19 2/5] Modify several rtc drivers to use the alias names list property of i2c
This patch modifies the ds1307, ds1374, and rs5c372 i2c drivers to support
device tree names using the new i2c mod alias support
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c | 44 -
drivers/rtc/rtc-ds1307.c | 18 +
drivers/rtc/rtc-ds1374.c |7 +
drivers/rtc/rtc-m41t80.c | 55 -
drivers/rtc/rtc-rs5c372.c | 14 ++
5 files changed, 81 insertions(+), 57 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..94e5c73 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -320,48 +320,12 @@ arch_initcall(gfar_of_init);
#ifdef CONFIG_I2C_BOARDINFO
#include
-struct i2c_driver_device {
- char*of_device;
- char*i2c_driver;
- char*i2c_type;
-};
-
-static struct i2c_driver_device i2c_devices[] __initdata = {
- {"ricoh,rs5c372a", "rtc-rs5c372", "rs5c372a",},
- {"ricoh,rs5c372b", "rtc-rs5c372", "rs5c372b",},
- {"ricoh,rv5c386", "rtc-rs5c372", "rv5c386",},
- {"ricoh,rv5c387a", "rtc-rs5c372", "rv5c387a",},
- {"dallas,ds1307", "rtc-ds1307", "ds1307",},
- {"dallas,ds1337", "rtc-ds1307", "ds1337",},
- {"dallas,ds1338", "rtc-ds1307", "ds1338",},
- {"dallas,ds1339", "rtc-ds1307", "ds1339",},
- {"dallas,ds1340", "rtc-ds1307", "ds1340",},
- {"stm,m41t00", "rtc-ds1307", "m41t00"},
- {"dallas,ds1374", "rtc-ds1374", "rtc-ds1374",},
-};
-
-static int __init of_find_i2c_driver(struct device_node *node,
-struct i2c_board_info *info)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
- if (!of_device_is_compatible(node, i2c_devices[i].of_device))
- continue;
- if (strlcpy(info->driver_name, i2c_devices[i].i2c_driver,
- KOBJ_NAME_LEN) >= KOBJ_NAME_LEN ||
- strlcpy(info->type, i2c_devices[i].i2c_type,
- I2C_NAME_SIZE) >= I2C_NAME_SIZE)
- return -ENOMEM;
- return 0;
- }
- return -ENODEV;
-}
static void __init of_register_i2c_devices(struct device_node *adap_node,
int bus_num)
{
struct device_node *node = NULL;
+ const char *compatible;
while ((node = of_get_next_child(adap_node, node))) {
struct i2c_board_info info = {};
@@ -378,8 +342,12 @@ static void __init of_register_i2c_devices(struct
device_node *adap_node,
if (info.irq == NO_IRQ)
info.irq = -1;
- if (of_find_i2c_driver(node, &info) < 0)
+ compatible = of_get_property(node, "compatible", &len);
+ if (!compatible) {
+ printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing
compatible attribute\n");
continue;
+ }
+ strncpy(info.type, compatible, sizeof(info.type));
info.addr = *addr;
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index 9b0eab9..d4874ff 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -139,6 +139,17 @@ static inline const struct chip_desc *find_chip(const char
*s)
return NULL;
}
+static struct i2c_device_id ds1307_id[] = {
+ OF_I2C_ID("dallas,ds1307", ds_1307)
+ OF_I2C_ID("dallas,ds1337", ds_1337)
+ OF_I2C_ID("dallas,ds1338", ds_1338)
+ OF_I2C_ID("dallas,ds1339", ds_1339)
+ OF_I2C_ID("dallas,ds1340", ds_1340)
+ OF_I2C_ID("stm,m41t00", m41t00)
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, ds1307_id);
+
static int ds1307_get_time(struct device *dev, struct rtc_time *t)
{
struct ds1307 *ds1307 = dev_get_drvdata(dev);
@@ -334,7 +345,11 @@ static int __devinit ds1307_probe(struct i2c_client
*client, const struct i2c_de
const struct chip_desc *chip;
struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
- chip = find_chip(client->name);
+ if (id)
+ chip = &chips[id->driver_data];
+ else
+ chip = find_chip(client->name);
+
if (!chip) {
dev_err(&client->dev, "unknown chip type '%s'\n",
client->name);
@@ -537,6 +552,7 @@ static struct i2c_driver ds1307_driver = {
},
.probe = ds1307_probe,
.remove = __devexit_p(ds1307_remove),
+ .id_table = ds1307_id,
};
static int __init ds1307_init(void)
diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
index dab6008..6dc05c4 100644
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -41,6 +41,12 @@
#define DS1374_REG_SR_AF 0x01 /* Alarm Flag */
#define DS1374_REG_TCR 0x09 /*
Re: [PATCH/RFC] synchronize_rcu(): high latency on idle system
> And yes, the > network stack shouldn't call synchronize_rcu() quite so much, but fixing that > is a little more involved. ... but the correct solution. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2][RFC][BUG] msync: updating ctime and mtime at syncing
2008/1/11, Peter Staubach <[EMAIL PROTECTED]>:
> Anton Salikhmetov wrote:
> > From: Anton Salikhmetov <[EMAIL PROTECTED]>
> >
> > The patch contains changes for updating the ctime and mtime fields for
> > memory mapped files:
> >
> > 1) adding a new flag triggering update of the inode data;
> > 2) implementing a helper function for checking that flag and updating ctime
> > and mtime;
> > 3) updating time stamps for mapped files in sys_msync() and do_fsync().
>
> Sorry, one other issue to throw out too -- an mmap'd block device
> should also have its inode time fields updated. This is a little
> tricky because the inode referenced via mapping->host isn't the
> one that needs to have the time fields updated on.
>
> I have attached the patch that I submitted last. It is quite out
> of date, but does show my attempt to resolve some of these issues.
It looks very strange to me that your patch received no reaction whatsoever:
http://lkml.org/lkml/2007/2/20/255
I've just tried to adapt your patch to my solution. I'm afraid ctime
and mtime stamps
for memory-mapped block device files are still not updated with your
code integrated
into what I'm doing. I set up the loopback device /dev/loop0, then ran
my test program:
http://bugzilla.kernel.org/attachment.cgi?id=14398
The unit test shows that ctime and mtime are not updated.
However, regular files are updated properly.
Also I have a couple of questions about your patch. Please see below.
>
> Thanx...
>
>ps
>
> --- linux-2.6.20.i686/fs/buffer.c.org
> +++ linux-2.6.20.i686/fs/buffer.c
> @@ -710,6 +710,7 @@ EXPORT_SYMBOL(mark_buffer_dirty_inode);
> int __set_page_dirty_buffers(struct page *page)
> {
> struct address_space * const mapping = page_mapping(page);
> + int ret = 0;
>
> if (unlikely(!mapping))
> return !TestSetPageDirty(page);
> @@ -727,7 +728,7 @@ int __set_page_dirty_buffers(struct page
> spin_unlock(&mapping->private_lock);
>
> if (TestSetPageDirty(page))
> - return 0;
> + goto out;
>
> write_lock_irq(&mapping->tree_lock);
> if (page->mapping) {/* Race with truncate? */
> @@ -740,7 +741,11 @@ int __set_page_dirty_buffers(struct page
> }
> write_unlock_irq(&mapping->tree_lock);
> __mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
> - return 1;
> + ret = 1;
> +out:
> + if (page_mapped(page))
> + set_bit(AS_MCTIME, &mapping->flags);
> + return ret;
> }
> EXPORT_SYMBOL(__set_page_dirty_buffers);
>
> --- linux-2.6.20.i686/fs/fs-writeback.c.org
> +++ linux-2.6.20.i686/fs/fs-writeback.c
> @@ -167,6 +167,13 @@ __sync_single_inode(struct inode *inode,
>
> spin_unlock(&inode_lock);
>
> + if (test_and_clear_bit(AS_MCTIME, &mapping->flags)) {
> + if (S_ISBLK(inode->i_mode))
> + bd_inode_update_time(inode);
> + else
> + inode_update_time(inode);
> + }
> +
Why the S_ISBLK check is done only here? I think sys_msync() should contain
the same logic.
> ret = do_writepages(mapping, wbc);
>
> /* Don't write the inode if only I_DIRTY_PAGES was set */
> --- linux-2.6.20.i686/fs/inode.c.org
> +++ linux-2.6.20.i686/fs/inode.c
> @@ -1201,8 +1201,8 @@ void touch_atime(struct vfsmount *mnt, s
> EXPORT_SYMBOL(touch_atime);
>
> /**
> - * file_update_time- update mtime and ctime time
> - * @file: file accessed
> + * inode_update_time - update mtime and ctime time
> + * @inode: file accessed
> *
> * Update the mtime and ctime members of an inode and mark the inode
> * for writeback. Note that this function is meant exclusively for
> @@ -1212,9 +1212,8 @@ EXPORT_SYMBOL(touch_atime);
> * timestamps are handled by the server.
> */
>
> -void file_update_time(struct file *file)
> +void inode_update_time(struct inode *inode)
> {
> - struct inode *inode = file->f_path.dentry->d_inode;
> struct timespec now;
> int sync_it = 0;
>
> @@ -1238,7 +1237,7 @@ void file_update_time(struct file *file)
> mark_inode_dirty_sync(inode);
> }
>
> -EXPORT_SYMBOL(file_update_time);
> +EXPORT_SYMBOL(inode_update_time);
>
> int inode_needs_sync(struct inode *inode)
> {
> --- linux-2.6.20.i686/fs/block_dev.c.org
> +++ linux-2.6.20.i686/fs/block_dev.c
> @@ -608,6 +608,22 @@ void bdput(struct block_device *bdev)
>
> EXPORT_SYMBOL(bdput);
>
> +void bd_inode_update_time(struct inode *inode)
> +{
> + struct block_device *bdev = inode->i_bdev;
> + struct list_head *p;
> +
> + if (bdev == NULL)
> + return;
> +
> + spin_lock(&bdev_lock);
> + list_for_each(p, &bdev->bd_inodes) {
> + inode = list_entry(p, struct inode, i_devices);
> + inode_update_time(inode);
> + }
> + spin_unlock(&bdev_lock);
> +}
> +
> static struct block_device *bd_ac
Re: [TOMOYO #6 retry 08/21] Utility functions and policy manipulationinterface.
Hello. James Morris wrote: > > > TOMOYO Linux uses /sys/kernel/security/tomoyo interface for configuration. > > > > Why aren't you using securityfs for this? (It was designed for LSMs). > > Doh, it is using securityfs, don't worry. > I got a mm-commits mail titled "+ sysfs-make-sysfs_deprecated-depend-on-sysfs.patch added to -mm tree" . Is sysfs going to be deprecated? If sysfs becomes not available at /sys/ , where securityfs is going to be mounted? Regards. -- 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/
[Fwd: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in]
Sorry,
Meant to press reply/all.
Forwarded Message
From: Tony Camuso <[EMAIL PROTECTED]>
To: Greg KH <[EMAIL PROTECTED]>
Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a
driver opt-in
Date: Fri, 11 Jan 2008 20:58:52 -0500
Greg KH wrote:
> Ivan, you posted one a while ago, but never seemed to get any
> confirmation if it helped or not. Should I use that and drop Arjan's?
> Or use both? Or something else like the patches proposed by Tony
> Camuso?
The 5-patch set I submitted is for Northbridges that don't respond to
MMCONFIG cycles at all. We (RH & HP) were blacklisting boxes in RHEL,
limiting them to legacy PCI, platform-wide. This was bad for systems
that had both PCI legacy and PCI express buses, because it limited
the functionality of the PCI express buses.
The problem Matthew described is different, having to do with bus
sizing code causing the large displacement of the graphics chip to
overlap the decode for MMCONFIG space.
Ivan suggested a fix for this problem that limits offsets below 64 bytes
to lgecacy PCI config access.
I tried this and it works perfectly!
I submitted an informal patch for folks to try.
Here it is again.
diff --git a/arch/x86/pci/mmconfig_32.c b/arch/x86/pci/mmconfig_32.c
index 1bf5816..4474979 100644
--- a/arch/x86/pci/mmconfig_32.c
+++ b/arch/x86/pci/mmconfig_32.c
@@ -73,7 +73,7 @@ static int pci_mmcfg_read(unsigned int seg, unsigned int bus,
}
base = get_base_addr(seg, bus, devfn);
- if (!base)
+ if ((!base) || (reg < 0x40))
return pci_conf1_read(seg,bus,devfn,reg,len,value);
spin_lock_irqsave(&pci_config_lock, flags);
@@ -106,7 +106,7 @@ static int pci_mmcfg_write(unsigned int seg, unsigned int
bus,
return -EINVAL;
base = get_base_addr(seg, bus, devfn);
- if (!base)
+ if ((!base) || (reg < 0x40))
return pci_conf1_write(seg,bus,devfn,reg,len,value);
spin_lock_irqsave(&pci_config_lock, flags);
diff --git a/arch/x86/pci/mmconfig_64.c b/arch/x86/pci/mmconfig_64.c
index 4095e4d..4ad1fcb 100644
--- a/arch/x86/pci/mmconfig_64.c
+++ b/arch/x86/pci/mmconfig_64.c
@@ -61,7 +61,7 @@ static int pci_mmcfg_read(unsigned int seg, unsigned int bus,
}
addr = pci_dev_base(seg, bus, devfn);
- if (!addr)
+ if ((!addr) || (reg < 0x40))
return pci_conf1_read(seg,bus,devfn,reg,len,value);
switch (len) {
@@ -89,7 +89,7 @@ static int pci_mmcfg_write(unsigned int seg, unsigned int bus,
return -EINVAL;
addr = pci_dev_base(seg, bus, devfn);
- if (!addr)
+ if ((!addr) || (reg < 0x40))
return pci_conf1_write(seg,bus,devfn,reg,len,value);
switch (len) {
--
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-RFC] x86: do_page_fault small unification
Copy the prefetch of map_sem from X86_64 and move the check notify_page_fault (soon to be kprobe_handle_fault) out of the unlikely if() statement. This makes the X86_32|64 pagefault handlers closer to each other. Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]> --- Ingo, I'll go back to the zero changes unifications now, just wanted to send the last few for comment as they will eventually need to be dealt with. arch/x86/mm/fault_32.c | 16 +++- arch/x86/mm/fault_64.c |7 ++- 2 files changed, 9 insertions(+), 14 deletions(-) diff --git a/arch/x86/mm/fault_32.c b/arch/x86/mm/fault_32.c index f8fc240..363267a 100644 --- a/arch/x86/mm/fault_32.c +++ b/arch/x86/mm/fault_32.c @@ -306,13 +306,18 @@ void __kprobes do_page_fault(struct pt_regs *regs, unsigned long error_code) */ trace_hardirqs_fixup(); + tsk = current; + mm = tsk->mm; + prefetchw(&mm->mmap_sem); + /* get the address */ address = read_cr2(); - tsk = current; - si_code = SEGV_MAPERR; + if (notify_page_fault(regs)) + return; + /* * We fault-in kernel-space virtual memory on-demand. The * 'reference' page table is init_mm.pgd. @@ -330,8 +335,6 @@ void __kprobes do_page_fault(struct pt_regs *regs, unsigned long error_code) if (!(error_code & (PF_RSVD|PF_USER|PF_PROT)) && vmalloc_fault(address) >= 0) return; - if (notify_page_fault(regs)) - return; /* * Don't take the mm semaphore here. If we fixup a prefetch * fault we could otherwise deadlock. @@ -339,16 +342,11 @@ void __kprobes do_page_fault(struct pt_regs *regs, unsigned long error_code) goto bad_area_nosemaphore; } - if (notify_page_fault(regs)) - return; - /* It's safe to allow irq's after cr2 has been saved and the vmalloc fault has been handled. */ if (regs->flags & (X86_EFLAGS_IF|VM_MASK)) local_irq_enable(); - mm = tsk->mm; - /* * If we're in an interrupt, have no user context or are running in an * atomic region then we must not take the fault. diff --git a/arch/x86/mm/fault_64.c b/arch/x86/mm/fault_64.c index 11e9398..128f812 100644 --- a/arch/x86/mm/fault_64.c +++ b/arch/x86/mm/fault_64.c @@ -366,6 +366,8 @@ asmlinkage void __kprobes do_page_fault(struct pt_regs *regs, si_code = SEGV_MAPERR; + if (notify_page_fault(regs)) + return; /* * We fault-in kernel-space virtual memory on-demand. The @@ -391,8 +393,6 @@ asmlinkage void __kprobes do_page_fault(struct pt_regs *regs, if (vmalloc_fault(address) >= 0) return; } - if (notify_page_fault(regs)) - return; /* * Don't take the mm semaphore here. If we fixup a prefetch * fault we could otherwise deadlock. @@ -400,9 +400,6 @@ asmlinkage void __kprobes do_page_fault(struct pt_regs *regs, goto bad_area_nosemaphore; } - if (notify_page_fault(regs)) - return; - if (likely(regs->flags & X86_EFLAGS_IF)) local_irq_enable(); -- 1.5.4.rc2.1164.g6451 -- 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: questions on NAPI processing latency and dropped network packets
From: "Chris Friesen" <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 08:59:26 -0600 > I'd love to work on newer kernels, but we have a commitment to our > customers to support multiple releases for a significant amount of time. And by asking here for people to dig into it for you, you are asking people for free help providing that support. That's why there is such negative backlash to asking questions about such ancient kernel here, you're asking us to do your work, for free. -- 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 001/001] ipv4: enable use of 240/4 address space
From: Vince Fuller <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 09:29:15 -0800 > I leave it up to you, the developers, to decide if you want to use these > patches. Vince, please just ignore these turkeys who are dismissing your patch and respin it against current sources as I asked of you. I'll apply it, immediately, because it is the only correct course of action. Thanks a lot. -- 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 001/001] ipv4: enable use of 240/4 address space
From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 21:41:20 +0900 (JST) > There is no positive consesus on this draft > at the intarea meeting in Vancouver, right? > > We cannot / should not enable that space until we have reached > a consensus on it. This is so incredibly incorrect. There is consensus on making network stacks able to use this address space. And that is all that the patch does. The consensus is only missing on whether to make the address space public or private. This is also clearly spelled out in the draft. It is important to get as large of a head start on this as possible because of how long it takes to deploy something like this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Fri, 11 Jan 2008, Lennart Sorensen wrote: > On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote: > > What can happen if someone does tune2fs -Lroot /dev/usbstick > > and puts that stick into this system? > > Don't know. I use UUIDs rather than LABELs. Having duplicated labels > just means being careless. Having duplicate UUIDs should require being > malicous. That's exactly what you have to assume for your users. Otherwise, you could remove any security feature from the system. -- Fun things to slip into your budget Not in a budget, but in an annual report: An employee stole 500,000+. They accounted for it on the annual report as 'involountary employee relations expense' -- 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: Usage semantics of atomic_set ( )
Vineet Gupta wrote: I'm trying to implement atomic ops for a CPU which has no inherent support for Read-Modify-Write Ops. Instead of using a global spin lock which protects all the atomic APIs, I want to use a spin lock per instance of atomic_t. What operations are you using to implement spinlocks? A few architectures use arrays of spinlocks to implement atomic_t. I believe sparc and parisc are among them. Assuming your spinlock implementation is sound and efficient, the same technique should work for you. -- Chris -- 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] pcmcia: Add support P2CCLK bit enabler for TI PC1520
On Sat, 12 Jan 2008 10:04:11 +0900
"Nobuhiro Iwamatsu" <[EMAIL PROTECTED]> wrote:
> 2007/12/26, Andrew Morton <[EMAIL PROTECTED]>:
> > On Tue, 18 Dec 2007 18:57:24 +0900 Nobuhiro Iwamatsu <[EMAIL PROTECTED]>
> > wrote:
> >
> > > There is a device that doesn't work when P2CCLK's bit of TI PC1520 was
> > > disable.
> > > This patch supports P2CCLK bit enabler for TI PC1520.
> > >
> > > ...
> > >
> > > config YENTA_TOSHIBA
> > > default y
> > > bool "Special initialization for Toshiba ToPIC bridges" if EMBEDDED
> > > diff --git a/drivers/pcmcia/ti113x.h b/drivers/pcmcia/ti113x.h
> > > index d29657b..ea749e8 100644
> > > --- a/drivers/pcmcia/ti113x.h
> > > +++ b/drivers/pcmcia/ti113x.h
> > > @@ -59,6 +59,7 @@
> > > #define TI122X_SCR_SER_STEP 0xc000
> > > #define TI122X_SCR_INTRTIE 0x2000
> > > #define TIXX21_SCR_TIEALL 0x1000
> > > +#define TI122X_SCR_P2CCLK 0x0800
> > > #define TI122X_SCR_CBRSVD 0x0040
> > > #define TI122X_SCR_MRBURSTDN0x8000
> > > #define TI122X_SCR_MRBURSTUP0x4000
> > > @@ -822,6 +823,13 @@ static int ti12xx_override(struct yenta_socket
> > > *socket)
> > > printk(KERN_INFO "Yenta: Enabling burst memory read
> > > transactions\n");
> > > val |= TI122X_SCR_MRBURSTUP;
> > > }
> > > +
> > > +#ifdef CONFIG_YENTA_TI_P2CCLK
> > > + if ( !(val & TI122X_SCR_P2CCLK)) {
> > > + printk(KERN_INFO "Yenta: Clock generated by internal
> > > oscillator\n");
> > > + val |= TI122X_SCR_P2CCLK;
> > > + }
> > > +#endif
> > > if (val_orig != val)
> > > config_writel(socket, TI113X_SYSTEM_CONTROL, val);
> >
> > It would be much better if we cold do this without the config option: just
> > detect the appropriate device and make it work.
>
> This bit is enable for PC in BIOS.
> However, I think that I want to control even by the kernel in
> building in because it is a boot loader situation.
>
> I think that this will not be able to be done by automatic.
>
> Please apply this patch.
>
What does the TI122X_SCR_P2CCLK bit do?
The printk which you're adding is ambiguous. Does it mean that the clock
is already generated by the internal oscillator, or that it is not, and
that the kernel is now arranging for it to be generated by the internal
oscillator?
What did the BIOS actually do? Did it enable an external oscillator when
the motherboard doesn't actually connect an oscillator to the
external-oscillator pin? Or what?
So. Please generally tell us (completely) what the problem is, and how
this patch attempts to fix it. Please also fully explain why we cannot
fix this problem without resorting to a config option, because avoiding
the config option is highly desirable.
Please bear in mind that this part of the kernel is effectively
unmaintained, so poor ignorant people like me need to try to look after it
so I need to be carefully educated about what's going on.
Thanks.
--
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/4] genhd: fixup kobj_to_dev() macro
On Tue, Jan 08, 2008 at 11:43:04AM +0300, Alexey Dobriyan wrote: > Please, fold into gregkh-driver-block-device.patch > --- > [PATCH -mm 1/4] genhd: fixup kobj_to_dev() macro Thanks, I've now merged it in. 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: [PATCH -mm 3/4] hvcs: fixup container_of() usage
On Tue, Jan 08, 2008 at 11:45:20AM +0300, Alexey Dobriyan wrote: > Please, fold into > gregkh-driver-kobject-convert-hvcs-to-use-kref-not-kobject.patch > -- > [PATCH -mm 3/4] hvcs: fixup container_of() usage > > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> Thanks, i've now merged it in. 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/
[PATCH/RFC] synchronize_rcu(): high latency on idle system
Hello folks, I'd like to put the patch below out for comments to see if folks think the approach is a valid fix to reduce the latency of synchronize_rcu(). The motivation is that an otherwise idle system takes about 3 ticks per network interface in unregister_netdev() due to multiple calls to synchronize_rcu(), which adds up to quite a few seconds for tearing down thousands of interfaces. By flushing pending rcu callbacks in the idle loop, the system makes progress hundreds of times faster. If this is indeed a sane thing to, it probably needs to be done for other architectures than x86. And yes, the network stack shouldn't call synchronize_rcu() quite so much, but fixing that is a little more involved. -ben diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c index 9663c2a..592f6e4 100644 --- a/arch/x86/kernel/process_32.c +++ b/arch/x86/kernel/process_32.c @@ -188,6 +188,9 @@ void cpu_idle(void) rmb(); idle = pm_idle; + if (rcu_pending(cpu)) + rcu_check_callbacks(cpu, 0); + if (!idle) idle = default_idle; -- 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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On 11-01-08 19:40, Ondrej Zary wrote:
On Friday 11 January 2008 15:21:55 Rene Herman wrote:
Hrmpf. Well, okay. Ondrej -- I assume this patch fixes things?
Yes, it works fine. 3c509 card still does not work after resume, but that
looks like another problem.
Okay. Would now only still like to know why the test in resume() means
trouble for you while it seems the same test in suspend() should've
triggered as well and not have stopped the device in the first place.
Know absolutely nothing about hibernation so added the listed maintainers to
the CC.
Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for
Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test
triggering in pnp_bus_resume() and keeping the card in a suspended state.
There's issues on wether or not the flag _should_ be set (that is, be part
of PNP_DRIVER_RES_DISABLE) and that it shouldn't be tested by these code
patchs in the first place, but is it in fact expected that this would be
neccessary?
That is, is it expected/designed that the same test in pnp_bus_suspend()
didn't cause the device to not be disabled in the first place?
Rene.
commit 7d16e8b3e7739599d32c8006f9e84fadb86b8296
Author: Rene Herman <[EMAIL PROTECTED]>
Date: Sat Jan 12 00:00:35 2008 +0100
PNP: do not test PNP_DRIVER_RES_DO_NOT_CHANGE on suspend/resume
The PNP_DRIVER_RES_DO_NOT_CHANGE flag is meant to signify that
the PNP core should not change resources for the device -- not
that it shouldn't disable/enable the device on suspend/resume.
ALSA ISAPnP drivers set PNP_DRIVER_RES_DO_NOT_CHANAGE (0x0001)
through setting PNP_DRIVER_RES_DISABLE (0x0003). The latter
including the former may in itself be considered rather
unexpected but doesn't change that suspend/resume wouldn't seem
to have any business testing the flag.
As reported by Ondrej Zary for snd-cs4236, ALSA driven ISAPnP
cards don't survive swsusp hibernation with the resume skipping
setting the resources due to testing the flag -- the same test
in the suspend path isn't enough to keep hibernation from
disabling the card it seems.
These tests were added (in 2005) by Piere Ossman in commit
68094e3251a664ee1389fcf179497237cbf78331, "alsa: Improved PnP
suspend support" who doesn't remember why. This deletes them.
Signed-off-by: Rene Herman <[EMAIL PROTECTED]>
Tested-by: Ondrej Zary <[EMAIL PROTECTED]>
diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
index a262762..12a1645 100644
--- a/drivers/pnp/driver.c
+++ b/drivers/pnp/driver.c
@@ -161,8 +161,7 @@ static int pnp_bus_suspend(struct device *dev, pm_message_t
state)
return error;
}
- if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE) &&
- pnp_can_disable(pnp_dev)) {
+ if (pnp_can_disable(pnp_dev)) {
error = pnp_stop_dev(pnp_dev);
if (error)
return error;
@@ -185,14 +184,17 @@ static int pnp_bus_resume(struct device *dev)
if (pnp_dev->protocol && pnp_dev->protocol->resume)
pnp_dev->protocol->resume(pnp_dev);
- if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) {
+ if (pnp_can_write(pnp_dev)) {
error = pnp_start_dev(pnp_dev);
if (error)
return error;
}
- if (pnp_drv->resume)
- return pnp_drv->resume(pnp_dev);
+ if (pnp_drv->resume) {
+ error = pnp_drv->resume(pnp_dev);
+ if (error)
+ return error;
+ }
return 0;
}
Re: sata_nv + ADMA + Samsung disk problem
Gabor Gombas wrote:
On Mon, Jan 07, 2008 at 06:10:29PM -0600, Robert Hancock wrote:
Gabor, I just noticed you said that it worked OK in 2.6.20, yet 2.6.22
fails. 2.6.20 had ADMA support as well, so I wonder what change started
causing the problem. Would it be possible for you to do a git bisect (or
at least try 2.6.21 to try and narrow it down)?
I've now booted 2.6.21.7, we'll see. The problem with the bisection is
that I can't explicitely trigger the bug so I can't say for sure if a
kernel is good or it is just needs more time to trigger. The average
uptime of this machine is just a couple hours a day.
For example, with 2.6.24-rc6 it took over 3 hours for the first disk to
trigger the bug and the second disk needed more than 7 hours. This
machine is seldom turned on for that long.
If you want to try to reproduce the problem more rapidly, you can try
the recipe I just suggested to the NVIDIA guys:
Run 2 instances of this C program, with different output files as the
argument, i.e. save this to fsynctest.c, and do
gcc fsynctest.c -o fsynctest
./fsynctest testfile & ./fsynctest testfile2 &
#include
#include
#include
#include
#include
#include
int main(int argc, char* argv[])
{
int i;
int fd = open( argv[1], O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR |
S_IWUSR);
if(fd == -1)
{
perror("open");
return 1;
}
for(i=0;i<100;i++)
{
int rc = write(fd, "0", 1);
if( rc != 1 )
{
perror("write");
return 2;
}
rc = fsync(fd);
if(rc)
{
perror("fsync");
return 2;
}
}
return 0;
}
Also run one instance of this:
dd if=/dev/zero of=blankfile bs=512 count=10 oflag=direct
and one of this:
while /bin/true; do sdparm --command=sync /dev/sdb; done
all at the same time. In my experience, it helps to disable cpufreq (on
Red Hat/Fedora, /sbin/service cpuspeed stop) to force the CPU to run at
max frequency all the time. After a few minutes I got this:
ata4: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000
status 0x400 next cpb count 0x2 next cpb idx 0x0
ata4: CPB 0: ctl_flags 0x1f, resp_flags 0x0
ata4: CPB 1: ctl_flags 0x1f, resp_flags 0x0
ata4: CPB 2: ctl_flags 0x1f, resp_flags 0x0
ata4: timeout waiting for ADMA IDLE, stat=0x400
ata4: timeout waiting for ADMA LEGACY, stat=0x400
ata4.00: exception Emask 0x0 SAct 0x7 SErr 0x0 action 0x2 frozen
ata4.00: cmd 61/08:00:e0:74:64/00:00:0a:00:00/40 tag 0 ncq 4096 out
res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
ata4.00: status: { DRDY }
ata4.00: cmd 61/08:08:30:5b:76/00:00:0c:00:00/40 tag 1 ncq 4096 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata4.00: status: { DRDY }
ata4.00: cmd 61/01:10:ba:51:77/00:00:0c:00:00/40 tag 2 ncq 512 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata4.00: status: { DRDY }
ata4: soft resetting link
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: configured for UDMA/133
ata4: EH complete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: refactor ioport unification
Refactor ioport unification to pull out common code.
Cc: [EMAIL PROTECTED]
Cc: Kevin Winchester <[EMAIL PROTECTED]>
Cc: Zach Brown <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: "H. Peter Anvin" <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
Applies atop the ioport unification fix for 32-bit
arch/x86/kernel/ioport.c | 40 +---
1 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index be72d80..50e5e4a 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -113,13 +113,9 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned
long num, int turn_on)
* on system-call entry - see also fork() and the signal handling
* code.
*/
-#ifdef CONFIG_X86_32
-asmlinkage long sys_iopl(unsigned long regsp)
+static int do_iopl(unsigned int level, struct pt_regs *regs)
{
- struct pt_regs *regs = (struct pt_regs *)®sp;
- unsigned int level = regs->bx;
unsigned int old = (regs->flags >> 12) & 3;
- struct thread_struct *t = ¤t->thread;
if (level > 3)
return -EINVAL;
@@ -128,25 +124,31 @@ asmlinkage long sys_iopl(unsigned long regsp)
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
}
- t->iopl = level << 12;
regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | (level << 12);
- set_iopl_mask(t->iopl);
+
return 0;
}
-#else
-asmlinkage long sys_iopl(unsigned int level, struct pt_regs *regs)
+
+#ifdef CONFIG_X86_32
+asmlinkage long sys_iopl(unsigned long regsp)
{
- unsigned int old = (regs->flags >> 12) & 3;
+ struct pt_regs *regs = (struct pt_regs *)®sp;
+ unsigned int level = regs->bx;
+ struct thread_struct *t = ¤t->thread;
+ int rc;
- if (level > 3)
- return -EINVAL;
- /* Trying to gain more privileges? */
- if (level > old) {
- if (!capable(CAP_SYS_RAWIO))
- return -EPERM;
- }
- regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | (level << 12);
+ rc = do_iopl(level, regs);
+ if (rc < 0)
+ goto out;
- return 0;
+ t->iopl = level << 12;
+ set_iopl_mask(t->iopl);
+out:
+ return rc;
+}
+#else
+asmlinkage long sys_iopl(unsigned int level, struct pt_regs *regs)
+{
+ return do_iopl(level, regs);
}
#endif
--
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: fixed a bug of adma in rhel4u5 with HDS7250SASUN500G.
Kuan Luo wrote:
hi robert,
I have fixed a bug in rhel4u5 2.6.9-55 when running adma mode
with HDS7250SASUN500G.
Could you check this code and if no problem, then help me to
submit to the newest kernel.
What problem does this resolve? I tested it against the cache flush/NCQ
write switching problem we've been trying to solve, and it doesn't look
like it fixes that one - if I apply this patch and then remove the
udelay(20) in sata_nv.c that I added which prevented me from seeing this
problem before, it shows up.
If you want to try and reproduce that problem, you can take out this
udelay(20) from the current version:
if (curr_ncq != pp->last_issue_ncq) {
/* Seems to need some delay before switching between NCQ and
non-NCQ commands, else we get command timeouts and such. */
udelay(20);
pp->last_issue_ncq = curr_ncq;
}
then run 2 instances of this C program, with different output files as
the argument:
#include
#include
#include
#include
#include
#include
int main(int argc, char* argv[])
{
int i;
int fd = open( argv[1], O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR |
S_IWUSR);
if(fd == -1)
{
perror("open");
return 1;
}
for(i=0;i<100;i++)
{
int rc = write(fd, "0", 1);
if( rc != 1 )
{
perror("write");
return 2;
}
rc = fsync(fd);
if(rc)
{
perror("fsync");
return 2;
}
}
return 0;
}
and one instance of this:
dd if=/dev/zero of=blankfile bs=512 count=10 oflag=direct
and one of this:
while /bin/true; do sdparm --command=sync /dev/sdb; done
all at the same time. In my experience, it helps to disable cpufreq (on
Red Hat/Fedora, /sbin/service cpuspeed stop) to force the CPU to run at
max frequency all the time. After a few minutes I got this:
ata4: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000
status 0x400 next cpb count 0x2 next cpb idx 0x0
ata4: CPB 0: ctl_flags 0x1f, resp_flags 0x0
ata4: CPB 1: ctl_flags 0x1f, resp_flags 0x0
ata4: CPB 2: ctl_flags 0x1f, resp_flags 0x0
ata4: timeout waiting for ADMA IDLE, stat=0x400
ata4: timeout waiting for ADMA LEGACY, stat=0x400
ata4.00: exception Emask 0x0 SAct 0x7 SErr 0x0 action 0x2 frozen
ata4.00: cmd 61/08:00:e0:74:64/00:00:0a:00:00/40 tag 0 ncq 4096 out
res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
ata4.00: status: { DRDY }
ata4.00: cmd 61/08:08:30:5b:76/00:00:0c:00:00/40 tag 1 ncq 4096 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata4.00: status: { DRDY }
ata4.00: cmd 61/01:10:ba:51:77/00:00:0c:00:00/40 tag 2 ncq 512 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata4.00: status: { DRDY }
ata4: soft resetting link
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: configured for UDMA/133
ata4: EH complete
--
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.24-rc6-mm1 (driver core/sysfs)
On Mon, Dec 31, 2007 at 12:11:15PM -0800, Randy Dunlap wrote: > On Sat, 22 Dec 2007 23:30:56 -0800 Andrew Morton wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/ > > > With CONFIG_BLOCK=n: > > LD drivers/block/built-in.o > /local/linsrc/linux-2.6.24-rc6-mm1/drivers/base/core.c: In function > 'device_add_class_symlinks': > /local/linsrc/linux-2.6.24-rc6-mm1/drivers/base/core.c:707: error: > 'part_type' undeclared (first use in this function) > /local/linsrc/linux-2.6.24-rc6-mm1/drivers/base/core.c: In function > 'device_remove_class_symlinks': > /local/linsrc/linux-2.6.24-rc6-mm1/drivers/base/core.c:746: error: > 'part_type' undeclared (first use in this function) > make[3]: *** [drivers/base/core.o] Error 1 > > > and that is after fixing (in some sense) the first CONFIG_BLOCK=n > problem with the patch below. Please test lots of configs. > and/or use 'make randconfig' (automated, scripted, e.g., etc.). > maybe check Documentation/SubmitChecklist. :) Ingo seems to be saying that he has some kind of "automated" build system to do this kind of checking. Ingo, did you ever post how you did this anywhere? I have enough spare machines here that I should be able to set up something to test my stuff this way easier than doing it by hand all the time (as the above problem proves I do miss things :( ) > --- > > From: Randy Dunlap <[EMAIL PROTECTED]> > > Parts of driver core use blk_lookup_devt() when CONFIG_BLOCK=n, > so provide an short inline version of it for that case. > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Thanks for this patch, I've merged it with the original block patch so there is no regression along the way. 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/
[PATCH] x86: fix ioport unification on 32-bit [was: Re: hwclock failure in x86.git]
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> thanks for tracking it down. I pulled that commit for now. But it would
> be nice to figure out what's going on there.
Zach was right. The unification was broken for 32-bit; it was missing
the actual pushf/popf EFLAGS manipluation (set_iopl_mask()) and would've
broken task switching between processes w/ different iopl in paravirt
guests too. 64-bit sys_iopl just does pt_regs->flags modification and
lets syscall/sysret plus ptregscall sync and do EFLAGS update.
Also, use of volatile looks like leftover cruft.
This patch in on top of Miguel's (can respin to standalone if that's better).
Tested (on both 32 and 64-bit) with simple:
#include
#include
main()
{
if (iopl(3) == 0)
asm ("cli\nsti\n"::);
}
thanks,
-chris
--
From: Chris Wright <[EMAIL PROTECTED]>
Subject: [PATCH] x86: fix ioport unification on 32-bit
ioport unification was broken for 32-bit; it was missing
the acutal pushf/popf EFLAGS manipulation (set_iopl_mask()).
Also, use of volatile looks like leftover cruft.
Cc: [EMAIL PROTECTED]
Cc: Kevin Winchester <[EMAIL PROTECTED]>
Cc: Zach Brown <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: "H. Peter Anvin" <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
arch/x86/kernel/ioport.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index e723ff3..be72d80 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -116,9 +116,10 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned
long num, int turn_on)
#ifdef CONFIG_X86_32
asmlinkage long sys_iopl(unsigned long regsp)
{
- volatile struct pt_regs *regs = (struct pt_regs *)®sp;
+ struct pt_regs *regs = (struct pt_regs *)®sp;
unsigned int level = regs->bx;
unsigned int old = (regs->flags >> 12) & 3;
+ struct thread_struct *t = ¤t->thread;
if (level > 3)
return -EINVAL;
@@ -127,8 +128,9 @@ asmlinkage long sys_iopl(unsigned long regsp)
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
}
+ t->iopl = level << 12;
regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | (level << 12);
-
+ set_iopl_mask(t->iopl);
return 0;
}
#else
--
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] pcmcia: Add support P2CCLK bit enabler for TI PC1520
2007/12/26, Andrew Morton <[EMAIL PROTECTED]>:
> On Tue, 18 Dec 2007 18:57:24 +0900 Nobuhiro Iwamatsu <[EMAIL PROTECTED]>
> wrote:
>
> > There is a device that doesn't work when P2CCLK's bit of TI PC1520 was
> > disable.
> > This patch supports P2CCLK bit enabler for TI PC1520.
> >
> > ...
> >
> > config YENTA_TOSHIBA
> > default y
> > bool "Special initialization for Toshiba ToPIC bridges" if EMBEDDED
> > diff --git a/drivers/pcmcia/ti113x.h b/drivers/pcmcia/ti113x.h
> > index d29657b..ea749e8 100644
> > --- a/drivers/pcmcia/ti113x.h
> > +++ b/drivers/pcmcia/ti113x.h
> > @@ -59,6 +59,7 @@
> > #define TI122X_SCR_SER_STEP 0xc000
> > #define TI122X_SCR_INTRTIE 0x2000
> > #define TIXX21_SCR_TIEALL 0x1000
> > +#define TI122X_SCR_P2CCLK 0x0800
> > #define TI122X_SCR_CBRSVD 0x0040
> > #define TI122X_SCR_MRBURSTDN0x8000
> > #define TI122X_SCR_MRBURSTUP0x4000
> > @@ -822,6 +823,13 @@ static int ti12xx_override(struct yenta_socket *socket)
> > printk(KERN_INFO "Yenta: Enabling burst memory read
> > transactions\n");
> > val |= TI122X_SCR_MRBURSTUP;
> > }
> > +
> > +#ifdef CONFIG_YENTA_TI_P2CCLK
> > + if ( !(val & TI122X_SCR_P2CCLK)) {
> > + printk(KERN_INFO "Yenta: Clock generated by internal
> > oscillator\n");
> > + val |= TI122X_SCR_P2CCLK;
> > + }
> > +#endif
> > if (val_orig != val)
> > config_writel(socket, TI113X_SYSTEM_CONTROL, val);
>
> It would be much better if we cold do this without the config option: just
> detect the appropriate device and make it work.
This bit is enable for PC in BIOS.
However, I think that I want to control even by the kernel in
building in because it is a boot loader situation.
I think that this will not be able to be done by automatic.
Please apply this patch.
regards,
Nobuhiro
--
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 0/4] PM: Do not destroy/create devices while suspended (rev. 2)
On Fri, Jan 11, 2008 at 04:49:04PM -0800, Andrew Morton wrote: > On Fri, 11 Jan 2008 16:46:13 -0800 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > The first patch in the series introduces such a mechanism. The remaining > > > three > > > patches modify the MSR, x86-64 MCE and cpuid drivers in accordance with > > > the > > > above approach. > > > > These patches are a preresuisite to > > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch and its > > later fixed-up versions. > > > > So what I have now is > > > > revert-gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch > > pm-introduce-destroy_suspended_device.patch > > pm-do-not-destroy-create-devices-while-suspended-in-msrc-rev-2.patch > > pm-do-not-destroy-create-devices-while-suspended-in-mce_64c.patch > > pm-do-not-destroy-create-devices-while-suspended-in-cpuidc.patch > > pm-acquire-device-locks-on-suspend-rev-3.patch > > pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes.patch > > pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes-2.patch > > > > So what needs to happen in Greg's tree is > > > > a) drop the old > > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch > > > > b) apply these four patches > > > > c) apply the new pm-acquire-device-locks-on-suspend-rev-3.patch (and its > > fixups) > > err, no. pm-introduce-destroy_suspended_device.patch demolishes > pm-acquire-device-locks-on-suspend-rev-3.patch > > Confused, giving up. I'm confused too, I have no idea what the proper order of things should be either. Anyone want to give me a hint? 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: [PATCH 0/4] PM: Do not destroy/create devices while suspended (rev. 2)
On Fri, 11 Jan 2008 16:46:13 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > > The first patch in the series introduces such a mechanism. The remaining > > three > > patches modify the MSR, x86-64 MCE and cpuid drivers in accordance with the > > above approach. > > These patches are a preresuisite to > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch and its > later fixed-up versions. > > So what I have now is > > revert-gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch > pm-introduce-destroy_suspended_device.patch > pm-do-not-destroy-create-devices-while-suspended-in-msrc-rev-2.patch > pm-do-not-destroy-create-devices-while-suspended-in-mce_64c.patch > pm-do-not-destroy-create-devices-while-suspended-in-cpuidc.patch > pm-acquire-device-locks-on-suspend-rev-3.patch > pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes.patch > pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes-2.patch > > So what needs to happen in Greg's tree is > > a) drop the old > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch > > b) apply these four patches > > c) apply the new pm-acquire-device-locks-on-suspend-rev-3.patch (and its > fixups) err, no. pm-introduce-destroy_suspended_device.patch demolishes pm-acquire-device-locks-on-suspend-rev-3.patch Confused, giving 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: [PATCH 0/4] PM: Do not destroy/create devices while suspended (rev. 2)
On Wed, 2 Jan 2008 00:32:44 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > Some device drivers register CPU hotplug notifiers and use them to destroy > device objects when removing the corresponding CPUs and to create these > objects > when adding the CPUs back. > > Unfortunately, this is not the right thing to do during suspend/hibernation, > since in that cases the CPU hotplug notifiers are called after suspending > devices and before resuming them, so the operations in question are carried > out on the objects representing suspended devices which shouldn't be > unregistered behing the PM core's back. __Although right now it usually > doesn't > lead to any practical complications, it will predictably deadlock if > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch is applied. > > The solution is to prevent drivers from removing/adding devices from within > CPU hotplug notifiers during suspend/hibernation using the FROZEN bit > in the notifier's action argument. However, this has to be done with care, > since the devices objects related to the nonboot CPUs that failed to go online > during resume should not be present in the system. For this reason, it seems > reasonable to introduce a mechanism allowing drivers to ask the PM core to > remove device objects corresponding to suspended devices on their behalf. > > The first patch in the series introduces such a mechanism. The remaining > three > patches modify the MSR, x86-64 MCE and cpuid drivers in accordance with the > above approach. These patches are a preresuisite to gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch and its later fixed-up versions. So what I have now is revert-gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch pm-introduce-destroy_suspended_device.patch pm-do-not-destroy-create-devices-while-suspended-in-msrc-rev-2.patch pm-do-not-destroy-create-devices-while-suspended-in-mce_64c.patch pm-do-not-destroy-create-devices-while-suspended-in-cpuidc.patch pm-acquire-device-locks-on-suspend-rev-3.patch pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes.patch pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes-2.patch So what needs to happen in Greg's tree is a) drop the old gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch b) apply these four patches c) apply the new pm-acquire-device-locks-on-suspend-rev-3.patch (and its fixups) -- 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 v2] Make PCI extended config space (MMCONFIG) a driver opt-in
On Friday, January 11, 2008 3:58 Ivan Kokshaysky wrote: > On Fri, Jan 11, 2008 at 02:38:03PM -0700, Matthew Wilcox wrote: > > On Fri, Jan 11, 2008 at 01:28:30PM -0800, Linus Torvalds wrote: > > > Hmm. Were all those reports root-caused to just that BAR probing? > > > If so, we may be in better shape than I worried. > > > > I believe so. > > Ditto. > > One typical problem is that on "Intel(r) 3 Series Experss Chipset > Family" MMCONFIG probing of the BAR #2 (frame buffer address) of > integrated graphics device locks up the machine (depending on BIOS > settings, of course). This happens because the frame buffer of IGD > has higher decode priority than MMCONFIG range, as stated in Intel > docs... Yeah, I'm only aware of 3: - the BAR overlapping w/MMCONFIG problem described above - ATI chipset config space retry bug - VIA (?) chipset host bridges don't respond well to having decode disabled (they stop decoding RAM addresses as well) That's it afaik, so I've never really known where Linus' paranoia comes from. OTOH I haven't been too keen to challenge it either; MMCONFIG space is only just beginning to be tested widely with the deployment of Vista, so we'll doubtless see more problems on older chipsets if we enable it by default. Jesse -- 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 09/11] PAT x86: Add ioremap_wc support
> >I don't think that's a good idea. Drivers should be able to
> >detect this somehow.
> >Handling UC mappings as WC will probably give very poor results.
> It is the other way. ioremap_wc aliases to ioremap_nocache.
> This was based on earlier feedback from Roland.
> >From: Roland Dreier [mailto:[EMAIL PROTECTED]
> >I think ioremap_wc() needs to be available on all archs for this to be
> >really useful to drivers. It can be a fallback to ioremap_nocache()
> >everywhere except 64-bit x86, but it's not nice for every driver that
> >wants to use this to need an "#ifdef X86" or whatever.
Yes... my basic point is simply that the kernel interfaces to this WC
stuff must be available on all architectures, even if it's stubbed out
on architectures that don't support write-combining or where it hasn't
been implemented yet. I think the only sane way to stub it out is to
fall back to uncached...
It's not going to be useful if drivers need crazy #ifdefs to decide
whether to use ioremap_wc(), pgprot_writecombine() or whatever. Just
look at the mess in drm_io_prot() in drm_vm.c to see what I want to
avoid.
Just to be explicit, my interest in this is that I want to be able to
merge the patch below and have the mlx4 driver still build and work on
every arch that has PCI support:
diff --git a/drivers/infiniband/hw/mlx4/main.c
b/drivers/infiniband/hw/mlx4/main.c
index d8287d9..5eac9c6 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -381,8 +381,7 @@ static int mlx4_ib_mmap(struct ib_ucontext *context, struct
vm_area_struct *vma)
PAGE_SIZE, vma->vm_page_prot))
return -EAGAIN;
} else if (vma->vm_pgoff == 1 && dev->dev->caps.bf_reg_size != 0) {
- /* FIXME want pgprot_writecombine() for BlueFlame pages */
- vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+ vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
if (io_remap_pfn_range(vma, vma->vm_start,
to_mucontext(context)->uar.pfn +
--
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: Date of linux-2.4.36 wrong
David Newall wrote: Heads up: linux-2.4.36 on kernel.org is dated 01/01/07 (ie six months before linux-2.4.35.) Surely a mistake. Bug in your FTP client. Compare Mozilla bug 61235. -hpa -- 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 v2] Make PCI extended config space (MMCONFIG) a driver opt-in
On Sat, Jan 12, 2008 at 02:58:56AM +0300, Ivan Kokshaysky wrote: > On Fri, Jan 11, 2008 at 02:38:03PM -0700, Matthew Wilcox wrote: > > On Fri, Jan 11, 2008 at 01:28:30PM -0800, Linus Torvalds wrote: > > > Hmm. Were all those reports root-caused to just that BAR probing? If so, > > > we may be in better shape than I worried. > > > > I believe so. > > Ditto. > > One typical problem is that on "Intel(r) 3 Series Experss Chipset Family" > MMCONFIG probing of the BAR #2 (frame buffer address) of integrated graphics > device locks up the machine (depending on BIOS settings, of course). > This happens because the frame buffer of IGD has higher decode priority > than MMCONFIG range, as stated in Intel docs... Ok, so what would the proposed patch look like to help resolve this? Ivan, you posted one a while ago, but never seemed to get any confirmation if it helped or not. Should I use that and drop Arjan's? Or use both? Or something else like the patches proposed by Tony Camuso? 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: [PATCH] 8390: split up 8390 with ISA delay and 8390 without
> > diff -u --new-file --recursive --exclude-from /usr/src/exclude > > linux.vanilla-2.6.24-rc6-mm1/drivers/net/hp.c > > linux-2.6.24-rc6-mm1/drivers/net/hp.c > > --- linux.vanilla-2.6.24-rc6-mm1/drivers/net/hp.c 2008-01-02 > > 16:04:00.0 + > > +++ linux-2.6.24-rc6-mm1/drivers/net/hp.c 2008-01-11 14:47:44.0 > > + > > > @@ -176,7 +176,7 @@ > > outb_p(irqmap[irq] | HP_RUN, ioaddr + > > HP_CONFIGURE); > > outb_p( 0x00 | HP_RUN, ioaddr + HP_CONFIGURE); > > ... didn't you miss two here? Otherwise, code looks great. The patch only changes the _p usage within the shared library. The hp.c code is used solely by the ISA HP driver and needed. > How will the user know when they need to use 8390p? They don't need to, any more than they need to know about 8390 right now. It is added to the Makefile so will be sucked in and built by Make as an extra module. The 8390p and 8390 use different wrapper symbols for ei_open etc so depmod will load the right one. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bsg : Add support for io vectors in bsg
James Bottomley wrote: On Thu, 2008-01-10 at 16:46 -0500, Pete Wyckoff wrote: [EMAIL PROTECTED] wrote on Thu, 10 Jan 2008 14:55 -0600: On Thu, 2008-01-10 at 15:43 -0500, Pete Wyckoff wrote: [EMAIL PROTECTED] wrote on Wed, 09 Jan 2008 09:11 +0900: On Tue, 8 Jan 2008 17:09:18 -0500 Pete Wyckoff <[EMAIL PROTECTED]> wrote: I took another look at the compat approach, to see if it is feasible to keep the compat handling somewhere else, without the use of #ifdef CONFIG_COMPAT and size-comparison code inside bsg.c. I don't see how. The use of iovec is within a write operation on a char device. It's not amenable to a compat_sys_ or a .compat_ioctl approach. I'm partial to #1 because the use of architecture-independent fields matches the rest of struct sg_io_v4. But if you don't want to have another iovec type in the kernel, could we do #2 but just return -EINVAL if the need for compat is detected? I.e. change dout_iovec_count to dout_iovec_length and do the math? If you are ok with removing the write/read interface and just have ioctl, we could can handle comapt stuff like others do. But I think that you (OSD people) really want to keep the write/read interface. Sorry, I think that there is no workaround to support iovec in bsg. I don't care about read/write in particular. But we do need some way to launch asynchronous SCSI commands, and currently read/write are the only way to do that in bsg. The reason is to keep multiple spindles busy at the same time. Won't multi-threading the ioctl calls achieve the same effect? Or do you trip over BKL there? There's no BKL on (new) ioctls anymore, at least. A thread per device would be feasible perhaps. But if you want any sort of pipelining out of the device, esp. in the remote iSCSI case, you need to have a good number of commands outstanding to each device. So a thread per command per device. Typical iSCSI queue depth of 128 times 16 devices for a small setup is a lot of threads. I was actually thinking of a thread per outstanding command. The pthread/pipe latency overhead is not insignificant for fast storage networks too. How about these new ioctls instead of read/write: SG_IO_SUBMIT - start a new blk_execute_rq_nowait() SG_IO_TEST - complete and return a previous req SG_IO_WAIT - wait for a req to finish, interruptibly Then old write users will instead do ioctl SUBMIT. Read users will do TEST for non-blocking fd, or WAIT for blocking. And SG_IO could be implemented as SUBMIT + WAIT. Then we can do compat_ioctl and convert up iovecs out-of-line before calling the normal functions. Let me know if you want a patch for this. Really, the thought of re-inventing yet another async I/O interface isn't very appealing. I'm fine with read/write, except Tomo is against handling iovecs because of the compat complexity with struct iovec being different on 32- vs 64-bit. There is a standard way to do "compat" ioctl that hides this handling in a different file (not bsg.c), which is the only reason I'm even considering these ioctls. I don't care about compat setups per se. Is there another async I/O mechanism? Userspace builds the CDBs, just needs some way to drop them in SCSI ML. BSG is almost perfect for this, but doesn't do iovec, leading to lots of memcpy. No, it's just that async interfaces in Linux have a long and fairly unhappy history. The sg driver's async interface has been pretty stable for a long time. The sync SG_IO ioctl is built on top of the async interface. That makes the async interface extremely well tested. The write()/read() async interface in sg does have one problem: when a command is dispatched via a write() it would be very useful to get back a tag but that violates write()'s second argument: 'const void * buf'. That tag could be useful both for identification of the response and by task management functions. I was hoping that the 'flags' field in sgv4 could be used to implement the variants: SG_IO_SUBMIT - start a new blk_execute_rq_nowait() SG_IO_TEST - complete and return a previous req SG_IO_WAIT - wait for a req to finish, interruptibly that way the existing SG_IO ioctl is sufficient. And if Tomo doesn't want to do it in the bsg driver, then it could be done it the sg driver. Doug Gilbert -- 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: CONFIG_NO_HZ breaks blktrace timestamps
Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> FYI, I'm currently trying to track down where rq->clock started to
> overflow with nohz=off, and it seems to be before 2.6.23, so my patches
> are not at fault ;-) Or maybe I am dreaming and it was always
> overflowing. Investigating ...
And the winner is:
commit 529c77261bccd9d37f110f58b0753d95beaa9fa2
Author: Ingo Molnar <[EMAIL PROTECTED]>
Date: Fri Aug 10 23:05:11 2007 +0200
sched: improve rq-clock overflow logic
improve the rq-clock overflow logic: limit the absolute rq->clock
delta since the last scheduler tick, instead of limiting the delta
itself.
tested by Arjan van de Ven - whole laptop was misbehaving due to
an incorrectly calibrated cpu_khz confusing sched_clock().
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
diff --git a/kernel/sched.c b/kernel/sched.c
index b0afd8d..6247e4a 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -263,6 +263,7 @@ struct rq {
unsigned int clock_warps, clock_overflows;
unsigned int clock_unstable_events;
+ u64 tick_timestamp;
atomic_t nr_iowait;
@@ -341,8 +342,11 @@ static void __update_rq_clock(struct rq *rq)
/*
* Catch too large forward jumps too:
*/
- if (unlikely(delta > 2*TICK_NSEC)) {
- clock++;
+ if (unlikely(clock + delta > rq->tick_timestamp + TICK_NSEC)) {
+ if (clock < rq->tick_timestamp + TICK_NSEC)
+ clock = rq->tick_timestamp + TICK_NSEC;
+ else
+ clock++;
rq->clock_overflows++;
} else {
if (unlikely(delta > rq->clock_max_delta))
@@ -3308,9 +3312,16 @@ void scheduler_tick(void)
int cpu = smp_processor_id();
struct rq *rq = cpu_rq(cpu);
struct task_struct *curr = rq->curr;
+ u64 next_tick = rq->tick_timestamp + TICK_NSEC;
spin_lock(&rq->lock);
__update_rq_clock(rq);
+ /*
+* Let rq->clock advance by at least TICK_NSEC:
+*/
+ if (unlikely(rq->clock < next_tick))
+ rq->clock = next_tick;
+ rq->tick_timestamp = rq->clock;
update_cpu_load(rq);
if (curr != rq->idle) /* FIXME: needed? */
curr->sched_class->task_tick(rq, curr);
Seems like I originally was not the only one seeing 2 jiffies jumps ;-)
I'll adapt my patches.
--
Guillaume
--
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] Clustering indirect blocks in Ext3
On Fri, 11 Jan 2008 09:05:17 -0800 Daniel Phillips <[EMAIL PROTECTED]> wrote: > On Thursday 10 January 2008 13:17, Abhishek Rai wrote: > > Benchmark 5: fsck > > Description: Prepare a newly formated 400GB disk as follows: create > > 200 files of 0.5GB each, 100 files of 1GB each, 40 files of 2.5GB > > ech, and 10 files of 10GB each. fsck command line: fsck -f -n > > 1. vanilla: > > Total: 11m25.3s > > User: 13.4s > > System: 13.2s > > 2. mc: > > Total: 3m11.0s > > User: 13.1s > > System: 12.9s > > > > Note: I'll report results from kernbench and compilebench shortly. > > > > Observations: > > Sequential write performance is much better with metaclustering than > > with vanilla. To better understand it, I ran the same benchmark with > > the new code but with the metaclustering option turned off and I got > > the same performance as vanilla which makes me believe that there is > > something about metaclustering that helps write performance though I > > don't have a very good handle of what that thing might be. > > Your results are very impressive. In my opinion, the sooner this goes > in, the better, since everybody hates waiting for fsck. The only issue > that jumps out at me is, the patch is big and changes a significant > amount of Ext3 code outside of the metacluster path, which is not a bad > thing except that these changes are going to need to be tested fairly > heavily. It needs to be reviewed. In exhaustive detail. Few people can do that and fewer are inclined to do so. > The way to do that is, put a big [CALL FOR TESTING] in your subject line > the next time you post, and use an attention-getting subject line > like "Make Ext3 fsck way faster". Diff the patch against the latest > stable kernel to make things as easy as possible for the people who are > hopefully going to download your patch, try it, and report their > results. > > The other way is just to ask Andrew to put it in -mm when you feel > ready, but your chances are much better if you already have people > sending in mails saying how great your patch is. I went to merge it so it could get some testing while we await review but the patch has all its tabs replaced with spaces, is seriously wordwrapped and has random newlines added to it. Please fix email client and resend (offlist is OK if it is unaltered). We should have a think about which workloads are most likely to be adversely affected by this change. -- 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 v2] Make PCI extended config space (MMCONFIG) a driver opt-in
On Fri, Jan 11, 2008 at 02:38:03PM -0700, Matthew Wilcox wrote: > On Fri, Jan 11, 2008 at 01:28:30PM -0800, Linus Torvalds wrote: > > Hmm. Were all those reports root-caused to just that BAR probing? If so, > > we may be in better shape than I worried. > > I believe so. Ditto. One typical problem is that on "Intel(r) 3 Series Experss Chipset Family" MMCONFIG probing of the BAR #2 (frame buffer address) of integrated graphics device locks up the machine (depending on BIOS settings, of course). This happens because the frame buffer of IGD has higher decode priority than MMCONFIG range, as stated in Intel docs... Ivan. -- 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: hwclock failure in x86.git
On Friday 11 January 2008 15:03:47 Ingo Molnar wrote:
> * Kevin Winchester <[EMAIL PROTECTED]> wrote:
> > Bisect says...
> >
> > 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b is first bad commit
> > commit 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b
> > Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> > Date: Wed Jan 9 13:31:11 2008 +0100
> >
> > x86: ioport_{32|64}.c unification
>
> thanks for tracking it down. I pulled that commit for now. But it would
> be nice to figure out what's going on there.
>
> Ingo
mmm, i'll try to reproduce it tomorrow and find a fix.
thanks for notifying this problem.
--
Miguel Botón
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CRIS v10: Correct do_signal to fix oops and clean up signal handling in general.
On Fri, 11 Jan 2008 19:59:24 +0100 Jesper Nilsson <[EMAIL PROTECTED]> wrote: > CRIS v10: Correct do_signal to fix oops and clean up signal handling in > general. > > This fixes a kernel panic on boot due to do_signal not being compatible > with it's callers. > Please sequence-number patches even if they are unrelated. That will make emails like this one easier. 1: CRIS v10: Correct do_signal to fix oops and clean up signal handling in general. 2: CRIS: Define __ARCH_WANT_SYS_RT_SIGSUSPEND in unistd.h for CRIS 3: CRIS v10: kernel/time.c needs to include linux/vmstat.h to compile. 4: CRIS v10: Driver for ds1302 needs to include cris-specific i2c.h Patches 3 and 4 were missing your signed-off-by:. I added it. I queued patches 1, 3 and 4 for 2.6.24 and patch 2 for 2.6.25. Do you agree? -- 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/
[GIT PATCH] ACPI patches for 2.6.24-rc7
Hi Linus, before 2.6.24-final, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release These are all regression fixes. A couple will apply to 2.6.23.stable too. thanks! -Len ps. individual patches are available on [EMAIL PROTECTED] and a consolidated plain patch is available here: ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.24/acpi-release-20070126-2.6.24-rc7.diff.gz arch/x86/kernel/apm_32.c | 10 ++--- drivers/acpi/Kconfig |9 +--- drivers/acpi/ac.c | 16 +- drivers/acpi/battery.c | 31 +++-- drivers/acpi/bus.c |7 +- drivers/acpi/ec.c | 14 - drivers/acpi/events/evregion.c |8 +++ drivers/acpi/pci_irq.c |9 drivers/acpi/processor_idle.c |4 +++ drivers/acpi/sbs.c | 23 - drivers/acpi/scan.c|6 + drivers/pci/quirks.c |6 + include/linux/pci_ids.h|2 + include/linux/pm.h |9 include/linux/pm_legacy.h |6 - include/linux/pnp.h|2 - kernel/power/main.c|3 ++ kernel/power/pm.c |4 --- 18 files changed, 129 insertions(+), 40 deletions(-) through these commits: Alan Cox (1): ACPI : Not register gsi for PCI IDE controller in legacy mode Alexey Starikovskiy (2): ACPI: EC: Enable boot EC before bus_scan ACPI: Make sysfs interface in ACPI power optional. Bob Moore (1): ACPICA: fix acpi_serialize hang regression Len Brown (2): increase PNP_MAX_PORT to 40 from 24 PM: ACPI and APM must not be enabled at the same time Venki Pallipadi (1): ACPI: Reintroduce run time configurable max_cstate for !CPU_IDLE case Zhao Yakui (1): ACPI: apply quirk_ich6_lpc_acpi to more ICH8 and ICH9 with this log: commit 8df042e85c4462f97be286ef0fd82a627f27e9c8 Merge: 4562120... 5b3f0e6... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Jan 11 12:28:38 2008 -0500 Pull bugzilla-9683 into release branch commit 456212017bf21f6bbdf972a5eafab987600956b2 Merge: 6b74c92... c04209a... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Jan 11 12:28:22 2008 -0500 Pull bugzilla-9627 into release branch commit 6b74c92521de123b6b3b01a8be432722121d9e8e Merge: 4e1b83a... 2c83819... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Jan 11 12:27:50 2008 -0500 Pull bugzilla-9535 into release branch commit 4e1b83ad61b5db143281bb54e88ff420cc6b79d0 Merge: 02d5bcc... 97749cd... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Jan 11 12:27:32 2008 -0500 Pull bugzilla-9494 into release branch commit 02d5bccf8ea3f9b8de21bfe19db77fbc50d92e04 Merge: eba6860... 9f9adec... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Jan 11 12:27:13 2008 -0500 Pull bugzilla-9194 into release branch commit 9f9adecd2d0e4f88fa0e8cb06c6ec207748df70a Author: Len Brown <[EMAIL PROTECTED]> Date: Thu Dec 13 17:38:03 2007 -0500 PM: ACPI and APM must not be enabled at the same time ACPI and APM used "pm_active" to guarantee that they would not be simultaneously active. But pm_active was recently moved under CONFIG_PM_LEGACY, so that without CONFIG_PM_LEGACY, pm_active became a NOP -- allowing ACPI and APM to both be simultaneously enabled. This caused unpredictable results, including boot hangs. Further, the code under CONFIG_PM_LEGACY is scheduled for removal. So replace pm_active with pm_flags. pm_flags depends only on CONFIG_PM, which is present for both CONFIG_APM and CONFIG_ACPI. http://bugzilla.kernel.org/show_bug.cgi?id=9194 Signed-off-by: Len Brown <[EMAIL PROTECTED]> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> commit eba6860ac5f9578e3ba6d0f9900cfc72599c5d66 Merge: aa7f007... d1ec729... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Jan 11 12:23:14 2008 -0500 Pull bugzilla-8973 into release branch commit aa7f00741da5e2adeca3e03103d14b9141040e49 Merge: e63501d... 014d433... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Jan 11 12:22:57 2008 -0500 Pull bugzilla-8171 into release branch commit e63501d51d6a1a897470be2684e9c55a46d0d6d5 Merge: 88fb61e... 96c2a87... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Jan 11 12:20:18 2008 -0500 Pull bugzilla-5637 into release branch commit d1ec7298fcefd7e4d1ca612da402ce9e5d5e2c13 Author: Zhao Yakui <[EMAIL PROTECTED]> Date: Fri Jan 11 00:24:55 2008 -0500 ACPI: apply quirk_ich6_lpc_acpi to more ICH8 and ICH9 It is important that these resources be reserved to avoid conflicts with well known ACPI registers. Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> commit 014d433f35d7f34b55dcc7b57c7635aaefc3757f Author: Bob Moore <[EMAIL PROTECTED]> Date:
Re: [PATCH] Fix private_list handling
On Fri, 11 Jan 2008 15:21:31 +0100 Jan Kara <[EMAIL PROTECTED]> wrote: > On Thu 10-01-08 16:36:35, Andrew Morton wrote: > > On Thu, 10 Jan 2008 16:55:13 +0100 > > Jan Kara <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > > > sorry for the previous empty email... > > > > > > Supriya noted in his testing that sometimes buffers removed by > > > __remove_assoc_queue() don't have b_assoc_mapping set (and thus IO error > > > won't be properly propagated). Actually, looking more into the code I > > > found > > > there are some more races. The patch below should fix them. It survived > > > beating with LTP and fsstress on ext2 filesystem on my testing machine so > > > it should be reasonably bugfree... Andrew, would you put the patch into > > > -mm? Thanks. > > > > > > Honza > > > -- > > > Jan Kara <[EMAIL PROTECTED]> > > > SUSE Labs, CR > > > --- > > > > > > There are two possible races in handling of private_list in buffer cache. > > > 1) When fsync_buffers_list() processes a private_list, it clears > > > b_assoc_mapping and moves buffer to its private list. Now drop_buffers() > > > comes, > > > sees a buffer is on list so it calls __remove_assoc_queue() which > > > complains > > > about b_assoc_mapping being cleared (as it cannot propagate possible IO > > > error). > > > This race has been actually observed in the wild. > > > > private_lock should prevent this race. > > > > Which call to drop_buffers() is the culprit? The first one in > > try_to_free_buffers(), I assume? The "can this still happen?" one? > > > > If so, it can happen. How? Perhaps this is a bug. > Good question but I don't think so. The problem is that > fsync_buffers_list() drops the private_lock() e.g. when it does > wait_on_buffer(). And buffers on the list fsync_buffers_list() constructs > have b_assoc_mapping set to NULL but the test > !list_empty(bh->b_assoc_buffers) succeeds for them and thus > __remove_assoc_queue() is called and it complains. > We could also silence the warning by leaving b_assoc_mapping set when we > move the buffer to the constructed list. Could fsync_buffers_list() leave the buffer not on a list when it does the ll_rw_block() and only add it to tmp afterwards if it sees that the buffer is still not on a list? I guess not, as it still needs to find the buffer to wait upon it. > But given the problem below > I've decided to do a more complete cleanup of the code. Well. Large-scale changes to long-established code like this are a last resort. We should fully investigate little local fixups first. > > > 2) When fsync_buffers_list() processes a private_list, > > > mark_buffer_dirty_inode() can be called on bh which is already on the > > > private > > > list of fsync_buffers_list(). As buffer is on some list (note that the > > > check is > > > performed without private_lock), it is not readded to the mapping's > > > private_list and after fsync_buffers_list() finishes, we have a dirty > > > buffer > > > which should be on private_list but it isn't. This race has not been > > > reported, > > > probably because most (but not all) callers of mark_buffer_dirty_inode() > > > hold > > > i_mutex and thus are serialized with fsync(). > > > > Maybe fsync_buffers_list should put the buffer back onto private_list if it > > got dirtied again. > Yes, that's what it does in my new version. Only the locking is a bit > subtle if we want to avoid taking private_lock in mark_buffer_dirty_inode() > when the buffer is already on some list... I fear rewrites in there. It took five years to find this bug. How long will it take to find new ones which get added? Sigh. lists do suck for this sort of thing. -- 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: LIBATA SCSI command validation changed in 2.6.24
On 01/11/2008 06:21 PM, Jeff Garzik wrote: > Chuck Ebbert wrote: >> On 01/11/2008 04:35 PM, Jeff Garzik wrote: >>> Chuck Ebbert wrote: commit 607126c2a21cd6e9bb807fdd415c1a992f7b9009 changed command validation to allow short commands in 16-byte CDBs, but it also made checking more strict. Before the change, a 10-byte SG_IO command could have its length set to 9 and still work. Now it fails. Not sure if this is a bug, but it has caused at least one application to fail that used to work (qpxtool.) [https://bugzilla.redhat.com/show_bug.cgi?id=428281] >>> Can you get us an example CDB? Its unclear if the hexdump in the bug >>> report is a returned mode page or the CDB or what...? >>> >> >> Not easily, but the maintainer of that program forced the length of >> the MODE_SENSE(10) command to 10 and that command started working. >> >> By looking at the source I could tell that it was setting the command >> length to (1 + the index of the last byte written to the CDB) and >> only wrote up to offset 8 when building the command, so it must have >> been sending the command with a length of 9. (It zeroed the whole CDB >> first and only wrote what it needed to.) >> >> (And it used the C++ operator [] to build the command, that was fun >> to trace...) > > Even if allocation length is present in the CDB, the CDB may be missing > important information that is required to process the command. So it > may have caught a bug in the program... depending on the CDB. > Yeah, the change is probably good. We should have been validating that the length was at least as long the expected length all along. But some programs are going to break because of this... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: howto get a melodic system beep?
On Sun, Dec 16, 2007 at 11:25:49PM +0100, Harald Dunkel wrote: > Hi folks, > > Is there a way to replace the system beep by something more > melodic? > > I remember some 10 years ago there was a patch for the kernel > to call an external "beep daemon" playing an audio file instead > (no kidding). But it never worked very well. Sometimes there > was a huge delay, and some programs were not very nice to the > system beep. Hi, check out the URL below. I use this thing on a pc that doesn't have a pc speaker: http://carcosa.net/jason/software/beep/ Here is a description on how to use this: http://gentoo-wiki.com/HOWTO_Virtual_PC_Speaker Regards, Toon. -- "I never set out to be weird, it was always other people who called me weird." -- 1986 Frank Zappa -- 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: LIBATA SCSI command validation changed in 2.6.24
Chuck Ebbert wrote: On 01/11/2008 04:35 PM, Jeff Garzik wrote: Chuck Ebbert wrote: commit 607126c2a21cd6e9bb807fdd415c1a992f7b9009 changed command validation to allow short commands in 16-byte CDBs, but it also made checking more strict. Before the change, a 10-byte SG_IO command could have its length set to 9 and still work. Now it fails. Not sure if this is a bug, but it has caused at least one application to fail that used to work (qpxtool.) [https://bugzilla.redhat.com/show_bug.cgi?id=428281] Can you get us an example CDB? Its unclear if the hexdump in the bug report is a returned mode page or the CDB or what...? Not easily, but the maintainer of that program forced the length of the MODE_SENSE(10) command to 10 and that command started working. By looking at the source I could tell that it was setting the command length to (1 + the index of the last byte written to the CDB) and only wrote up to offset 8 when building the command, so it must have been sending the command with a length of 9. (It zeroed the whole CDB first and only wrote what it needed to.) (And it used the C++ operator [] to build the command, that was fun to trace...) Even if allocation length is present in the CDB, the CDB may be missing important information that is required to process the command. So it may have caught a bug in the program... depending on the CDB. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_nv + ADMA + Samsung disk problem
On Mon, Jan 07, 2008 at 06:10:29PM -0600, Robert Hancock wrote: > Gabor, I just noticed you said that it worked OK in 2.6.20, yet 2.6.22 > fails. 2.6.20 had ADMA support as well, so I wonder what change started > causing the problem. Would it be possible for you to do a git bisect (or > at least try 2.6.21 to try and narrow it down)? I've now booted 2.6.21.7, we'll see. The problem with the bisection is that I can't explicitely trigger the bug so I can't say for sure if a kernel is good or it is just needs more time to trigger. The average uptime of this machine is just a couple hours a day. For example, with 2.6.24-rc6 it took over 3 hours for the first disk to trigger the bug and the second disk needed more than 7 hours. This machine is seldom turned on for that long. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- 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] serverworks: IRQ routing needs no _p
On Fri, 2008-01-11 at 18:14 +, Alan Cox wrote: > I can find no reason for the _p on the serverworks IRQ routing logic, and > a review of the documentation contains no indication that any such delay > is needed so lets try this > Looks good to me; unfortunately my Serverworks boxes got upgraded so I can't test, but install base is really big. Acked-by: Zachary Amsden <[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: Usage semantics of atomic_set ( )
> I'm trying to implement atomic ops for a CPU which has no inherent > support for Read-Modify-Write Ops. Instead of using a global spin lock > which protects all the atomic APIs, I want to use a spin lock per > instance of atomic_t. This works well when atomic_t is unitary and > statically initialized using ATOMIC_INIT (where I can reset the > spinlock_t as well). However if atomic_t var is embedded within a > bigger struct which is allocated dynamically how to I init the > embedded spin lock. atomic_set ( ) is the closest choice, however I > don't think it's current usage in kernel code qualifies it to be > "initializer only". A simple way to handle this might be to use a separate array of spinlocks and hash each atomic_t to one entry in the array. You could look in asm-parisc and arch/parisc to see an implementation of this that is already in the kernel. - R. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/10] kconfig: gettext support for menuconfig
Full gettext support for menuconfig.
Signed-off-by: Egry Gabor <[EMAIL PROTECTED]>
Reviewed-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
kbuild-szilard/scripts/kconfig/mconf.c | 51 -
1 file changed, 26 insertions(+), 25 deletions(-)
diff -puN scripts/kconfig/mconf.c~kconfig-i18n-12-menuconfig-i18n
scripts/kconfig/mconf.c
--- kbuild/scripts/kconfig/mconf.c~kconfig-i18n-12-menuconfig-i18n
2008-01-11 22:27:15.0 +0100
+++ kbuild-szilard/scripts/kconfig/mconf.c 2008-01-11 22:27:15.0
+0100
@@ -289,11 +289,11 @@ static void get_prompt_str(struct gstr *
int i, j;
struct menu *submenu[8], *menu;
- str_printf(r, "Prompt: %s\n", prop->text);
- str_printf(r, " Defined at %s:%d\n", prop->menu->file->name,
+ str_printf(r, _("Prompt: %s\n"), _(prop->text));
+ str_printf(r, _(" Defined at %s:%d\n"), prop->menu->file->name,
prop->menu->lineno);
if (!expr_is_yes(prop->visible.expr)) {
- str_append(r, " Depends on: ");
+ str_append(r, _(" Depends on: "));
expr_gstr_print(prop->visible.expr, r);
str_append(r, "\n");
}
@@ -301,13 +301,13 @@ static void get_prompt_str(struct gstr *
for (i = 0; menu != &rootmenu && i < 8; menu = menu->parent)
submenu[i++] = menu;
if (i > 0) {
- str_printf(r, " Location:\n");
+ str_printf(r, _(" Location:\n"));
for (j = 4; --i >= 0; j += 2) {
menu = submenu[i];
- str_printf(r, "%*c-> %s", j, ' ',
menu_get_prompt(menu));
+ str_printf(r, "%*c-> %s", j, ' ',
_(menu_get_prompt(menu)));
if (menu->sym) {
str_printf(r, " (%s [=%s])", menu->sym->name ?
- menu->sym->name : "",
+ menu->sym->name : _(""),
sym_get_string_value(menu->sym));
}
str_append(r, "\n");
@@ -337,7 +337,7 @@ static void get_symbol_str(struct gstr *
if (hit)
str_append(r, "\n");
if (sym->rev_dep.expr) {
- str_append(r, " Selected by: ");
+ str_append(r, _(" Selected by: "));
expr_gstr_print(sym->rev_dep.expr, r);
str_append(r, "\n");
}
@@ -353,7 +353,7 @@ static struct gstr get_relations_str(str
for (i = 0; sym_arr && (sym = sym_arr[i]); i++)
get_symbol_str(&res, sym);
if (!i)
- str_append(&res, "No matches found.\n");
+ str_append(&res, _("No matches found.\n"));
return res;
}
@@ -433,6 +433,7 @@ static void build_conf(struct menu *menu
switch (prop->type) {
case P_MENU:
child_count++;
+ prompt = _(prompt);
if (single_menu_mode) {
item_make("%s%*c%s",
menu->data ? "-->" : "++>",
@@ -448,7 +449,7 @@ static void build_conf(struct menu *menu
case P_COMMENT:
if (prompt) {
child_count++;
- item_make(" %*c*** %s ***", indent +
1, ' ', prompt);
+ item_make(" %*c*** %s ***", indent +
1, ' ', _(prompt));
item_set_tag(':');
item_set_data(menu);
}
@@ -456,7 +457,7 @@ static void build_conf(struct menu *menu
default:
if (prompt) {
child_count++;
- item_make("---%*c%s", indent + 1, ' ',
prompt);
+ item_make("---%*c%s", indent + 1, ' ',
_(prompt));
item_set_tag(':');
item_set_data(menu);
}
@@ -500,10 +501,10 @@ static void build_conf(struct menu *menu
item_set_data(menu);
}
- item_add_str("%*c%s", indent + 1, ' ', menu_get_prompt(menu));
+ item_add_str("%*c%s", indent + 1, ' ',
_(menu_get_prompt(menu)));
if (val == yes) {
if (def_menu) {
- item_add_str(" (%s)",
menu_get_prompt(def_menu));
+ item_add_str(" (%s)",
_(menu_get_prompt(def_menu)));
item_add_str(" --->");
if (def_menu->list) {
[PATCH 4/10] kconfig: gettext support for gconfig
Gettext support for menu and toolbar. Signed-off-by: Egry Gabor <[EMAIL PROTECTED]> Reviewed-by: Sam Ravnborg <[EMAIL PROTECTED]> --- kbuild-szilard/scripts/kconfig/Makefile|7 +-- kbuild-szilard/scripts/kconfig/POTFILES.in |1 + 2 files changed, 6 insertions(+), 2 deletions(-) diff -puN scripts/kconfig/Makefile~kconfig-i18n-08-gconfig-gui scripts/kconfig/Makefile --- kbuild/scripts/kconfig/Makefile~kconfig-i18n-08-gconfig-gui 2008-01-11 22:24:54.0 +0100 +++ kbuild-szilard/scripts/kconfig/Makefile 2008-01-11 22:25:55.0 +0100 @@ -27,7 +27,7 @@ silentoldconfig: $(obj)/conf # Create new linux.pot file # Adjust charset to UTF-8 in .po file to accept UTF-8 in Kconfig files # The symlink is used to repair a deficiency in arch/um -update-po-config: $(obj)/kxgettext +update-po-config: $(obj)/kxgettext $(obj)/gconf.glade.h $(Q)echo " GEN config" $(Q)xgettext --default-domain=linux \ --add-comments --keyword=_ --keyword=N_ \ @@ -139,7 +139,7 @@ gconf-objs := gconf.o kconfig_load.o zco endif clean-files:= lkc_defs.h qconf.moc .tmp_qtcheck \ - .tmp_gtkcheck zconf.tab.c lex.zconf.c zconf.hash.c + .tmp_gtkcheck zconf.tab.c lex.zconf.c zconf.hash.c gconf.glade.h clean-files += mconf qconf gconf clean-files += config.pot linux.pot @@ -254,6 +254,9 @@ $(obj)/%.moc: $(src)/%.h $(obj)/lkc_defs.h: $(src)/lkc_proto.h sed < $< > $@ 's/P(\([^,]*\),.*/#define \1 (\*\1_p)/' +# Extract gconf menu items for I18N support +$(obj)/gconf.glade.h: $(obj)/gconf.glade + intltool-extract --type=gettext/glade $(obj)/gconf.glade ### # The following requires flex/bison/gperf diff -puN scripts/kconfig/POTFILES.in~kconfig-i18n-08-gconfig-gui scripts/kconfig/POTFILES.in --- kbuild/scripts/kconfig/POTFILES.in~kconfig-i18n-08-gconfig-gui 2008-01-11 22:24:54.0 +0100 +++ kbuild-szilard/scripts/kconfig/POTFILES.in 2008-01-11 22:24:54.0 +0100 @@ -8,4 +8,5 @@ scripts/kconfig/mconf.c scripts/kconfig/conf.c scripts/kconfig/confdata.c scripts/kconfig/gconf.c +scripts/kconfig/gconf.glade.h scripts/kconfig/qconf.cc _ -- 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] 8390: split up 8390 with ISA delay and 8390 without
On Fri, 2008-01-11 at 18:08 +, Alan Cox wrote: > This lets us remove port 0x80 use on the PCI systems. It also speeds > up > some of the later 8390 based cores where we know the device does not > need > delay loops either because it has internal handling or in most cases a > faster device anyway. > > We compile up a new module 8390p to go with 8390 one with delays and > one > without. Most users will never need 8390p so it seems best to produce > two > modules. > diff -u --new-file --recursive --exclude-from /usr/src/exclude > linux.vanilla-2.6.24-rc6-mm1/drivers/net/hp.c > linux-2.6.24-rc6-mm1/drivers/net/hp.c > --- linux.vanilla-2.6.24-rc6-mm1/drivers/net/hp.c 2008-01-02 > 16:04:00.0 + > +++ linux-2.6.24-rc6-mm1/drivers/net/hp.c 2008-01-11 14:47:44.0 > + > @@ -176,7 +176,7 @@ > outb_p(irqmap[irq] | HP_RUN, ioaddr + > HP_CONFIGURE); > outb_p( 0x00 | HP_RUN, ioaddr + HP_CONFIGURE); ... didn't you miss two here? Otherwise, code looks great. How will the user know when they need to use 8390p? Should you perhaps default to producing and using 8390p if CONFIG_ISA is on? Zach -- 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: [Bluez-devel] Oops involving RFCOMM and sysfs
On Thu, Jan 10, 2008 at 09:11:17AM +0800, Dave Young wrote: > For bluetooth device_move, the only child device of hci_conn dev is > the rfcomm tty_dev. How about the following patch, please verify : There is now no oops, instead the keyboard becomes almost completely unresponsible when I switch off & on the phone. The mouse still works (tested both with X and with the VGA console), but terminal input and VT switching is dead. On the VGA console, even scrolling using Shift+PgUp stops working. Alt+SysRq+w works, trace is below. Ctrl+Alt+Del also works, but then init complains about hung processes and that it can not umount the file systems and cannot stop the RAID arrays. Once it still rebooted though, the second time it got hung after trying to umount the filesystems, and I had to use Alt+SysRq+b. If I can choose then I prefer the Oops... Jan 11 23:46:35 twister kernel: SysRq : Emergency Sync Jan 11 23:46:35 twister kernel: Emergency Sync complete Jan 11 23:46:42 twister kernel: SysRq : Show Blocked State Jan 11 23:46:42 twister kernel: taskPC stack pid father Jan 11 23:46:42 twister kernel: events/0 D 80487190 0 5 2 Jan 11 23:46:42 twister kernel: 8100bf84fd40 0046 8100ae7f2600 8100bf84fd00 Jan 11 23:46:42 twister kernel: 8100bf84a830 8100bd872000 80652ae0 00010100 Jan 11 23:46:42 twister kernel: 7fff 7fff 0002 Jan 11 23:46:42 twister kernel: Call Trace: Jan 11 23:46:42 twister kernel: [] schedule_timeout+0x1e/0xad Jan 11 23:46:42 twister kernel: [] dput+0x26/0x103 Jan 11 23:46:42 twister kernel: [] sysfs_move_dir+0x1ee/0x1fd Jan 11 23:46:42 twister kernel: [] wait_for_common+0xc4/0x129 Jan 11 23:46:42 twister kernel: [] default_wake_function+0x0/0xe Jan 11 23:46:42 twister kernel: [] klist_del+0x15/0x2e Jan 11 23:46:42 twister kernel: [] device_move+0x80/0x111 Jan 11 23:46:42 twister kernel: [] :bluetooth:hci_conn_move_child+0x0/0xf Jan 11 23:46:42 twister kernel: [] :bluetooth:hci_conn_move_child+0xb/0xf Jan 11 23:46:42 twister kernel: [] device_for_each_child+0x22/0x4d Jan 11 23:46:42 twister kernel: [] :bluetooth:del_conn+0x0/0x22 Jan 11 23:46:42 twister kernel: [] :bluetooth:del_conn+0x19/0x22 Jan 11 23:46:42 twister kernel: [] run_workqueue+0x74/0xee Jan 11 23:46:42 twister kernel: [] worker_thread+0x0/0xe7 Jan 11 23:46:42 twister kernel: [] worker_thread+0xda/0xe7 Jan 11 23:46:42 twister kernel: [] autoremove_wake_function+0x0/0x2e Jan 11 23:46:42 twister kernel: [] worker_thread+0x0/0xe7 Jan 11 23:46:42 twister kernel: [] kthread+0x47/0x73 Jan 11 23:46:42 twister kernel: [] child_rip+0xa/0x12 Jan 11 23:46:42 twister kernel: [] kthread+0x0/0x73 Jan 11 23:46:42 twister kernel: [] child_rip+0x0/0x12 Jan 11 23:46:42 twister kernel: Jan 11 23:46:42 twister kernel: cat D 7fff 0 3978 3965 Jan 11 23:46:42 twister kernel: 81009e857ce8 0086 8100ae7f2900 81009e857ca8 Jan 11 23:46:42 twister kernel: 8100bd872000 8100bf9e7060 80652ae0 000100c0 Jan 11 23:46:42 twister kernel: 7fff 7fff 0002 Jan 11 23:46:42 twister kernel: Call Trace: Jan 11 23:46:42 twister kernel: [] schedule_timeout+0x1e/0xad Jan 11 23:46:42 twister kernel: [] __dequeue_entity+0x1c/0x32 Jan 11 23:46:42 twister kernel: [] set_next_entity+0x23/0x73 Jan 11 23:46:42 twister kernel: [] wait_for_common+0xc4/0x129 Jan 11 23:46:42 twister kernel: [] default_wake_function+0x0/0xe Jan 11 23:46:42 twister kernel: [] flush_cpu_workqueue+0x50/0x58 Jan 11 23:46:42 twister kernel: [] wq_barrier_func+0x0/0x9 Jan 11 23:46:42 twister kernel: [] flush_workqueue+0x9/0x12 Jan 11 23:46:42 twister kernel: [] release_dev+0x47c/0x5e2 Jan 11 23:46:42 twister kernel: [] do_page_fault+0x2ff/0x65a Jan 11 23:46:42 twister kernel: [] tty_release+0xc/0x10 Jan 11 23:46:42 twister kernel: [] __fput+0xb1/0x16f Jan 11 23:46:42 twister kernel: [] filp_close+0x5d/0x65 Jan 11 23:46:42 twister kernel: [] sys_close+0x73/0xa6 Jan 11 23:46:42 twister kernel: [] tracesys+0xdc/0xe1 Jan 11 23:46:42 twister kernel: If I'm not mistaken the "cat" above is the "cat /dev/zero > /dev/rfcomm0" command. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/10] kconfig: gettext support for config
Gettext support for conf.c .
Signed-off-by: Egry Gabor <[EMAIL PROTECTED]>
Reviewed-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
kbuild-szilard/scripts/kconfig/conf.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff -puN scripts/kconfig/conf.c~kconfig-i18n-06-config-i18n
scripts/kconfig/conf.c
--- kbuild/scripts/kconfig/conf.c~kconfig-i18n-06-config-i18n 2008-01-11
22:24:40.0 +0100
+++ kbuild-szilard/scripts/kconfig/conf.c 2008-01-11 22:24:40.0
+0100
@@ -40,7 +40,7 @@ static char nohelp_text[] = N_("Sorry, n
static const char *get_help(struct menu *menu)
{
if (menu_has_help(menu))
- return menu_get_help(menu);
+ return _(menu_get_help(menu));
else
return nohelp_text;
}
@@ -78,7 +78,7 @@ static int conf_askvalue(struct symbol *
tristate val;
if (!sym_has_value(sym))
- printf("(NEW) ");
+ printf(_("(NEW) "));
line[0] = '\n';
line[1] = 0;
@@ -183,7 +183,7 @@ int conf_string(struct menu *menu)
const char *def;
while (1) {
- printf("%*s%s ", indent - 1, "", menu->prompt->text);
+ printf("%*s%s ", indent - 1, "", _(menu->prompt->text));
printf("(%s) ", sym->name);
def = sym_get_string_value(sym);
if (sym_get_string_value(sym))
@@ -216,7 +216,7 @@ static int conf_sym(struct menu *menu)
tristate oldval, newval;
while (1) {
- printf("%*s%s ", indent - 1, "", menu->prompt->text);
+ printf("%*s%s ", indent - 1, "", _(menu->prompt->text));
if (sym->name)
printf("(%s) ", sym->name);
type = sym_get_type(sym);
@@ -306,7 +306,7 @@ static int conf_choice(struct menu *menu
case no:
return 1;
case mod:
- printf("%*s%s\n", indent - 1, "",
menu_get_prompt(menu));
+ printf("%*s%s\n", indent - 1, "",
_(menu_get_prompt(menu)));
return 0;
case yes:
break;
@@ -316,7 +316,7 @@ static int conf_choice(struct menu *menu
while (1) {
int cnt, def;
- printf("%*s%s\n", indent - 1, "", menu_get_prompt(menu));
+ printf("%*s%s\n", indent - 1, "", _(menu_get_prompt(menu)));
def_sym = sym_get_choice_value(sym);
cnt = def = 0;
line[0] = 0;
@@ -324,7 +324,7 @@ static int conf_choice(struct menu *menu
if (!menu_is_visible(child))
continue;
if (!child->sym) {
- printf("%*c %s\n", indent, '*',
menu_get_prompt(child));
+ printf("%*c %s\n", indent, '*',
_(menu_get_prompt(child)));
continue;
}
cnt++;
@@ -333,14 +333,14 @@ static int conf_choice(struct menu *menu
printf("%*c", indent, '>');
} else
printf("%*c", indent, ' ');
- printf(" %d. %s", cnt, menu_get_prompt(child));
+ printf(" %d. %s", cnt, _(menu_get_prompt(child)));
if (child->sym->name)
printf(" (%s)", child->sym->name);
if (!sym_has_value(child->sym))
- printf(" (NEW)");
+ printf(_(" (NEW)"));
printf("\n");
}
- printf("%*schoice", indent - 1, "");
+ printf(_("%*schoice"), indent - 1, "");
if (cnt == 1) {
printf("[1]: 1\n");
goto conf_childs;
@@ -433,7 +433,7 @@ static void conf(struct menu *menu)
if (prompt)
printf("%*c\n%*c %s\n%*c\n",
indent, '*',
- indent, '*', prompt,
+ indent, '*', _(prompt),
indent, '*');
default:
;
@@ -499,6 +499,10 @@ int main(int ac, char **av)
const char *name;
struct stat tmpstat;
+ setlocale (LC_ALL, "");
+ bindtextdomain (PACKAGE, LOCALEDIR);
+ textdomain (PACKAGE);
+
while ((opt = getopt(ac, av, "osdD:nmyrh")) != -1) {
switch (opt) {
case 'o':
@@ -529,11 +533,11 @@ int main(int ac, char **av)
srand(time(NULL));
break;
case 'h':
- printf("See README for usage info\n");
+
[PATCH 1/10] kconfig: update-po-config info
This patch adds tracking messages. Signed-off-by: Egry Gabor <[EMAIL PROTECTED]> Reviewed-by: Sam Ravnborg <[EMAIL PROTECTED]> --- kbuild-szilard/scripts/kconfig/Makefile | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff -puN scripts/kconfig/Makefile~kconfig-i18n-02-update-po-fix scripts/kconfig/Makefile --- kbuild/scripts/kconfig/Makefile~kconfig-i18n-02-update-po-fix 2008-01-11 22:16:06.0 +0100 +++ kbuild-szilard/scripts/kconfig/Makefile 2008-01-11 22:27:38.0 +0100 @@ -24,22 +24,25 @@ oldconfig: $(obj)/conf silentoldconfig: $(obj)/conf $< -s $(Kconfig) -# Create new linux.po file +# Create new linux.pot file # Adjust charset to UTF-8 in .po file to accept UTF-8 in Kconfig files # The symlink is used to repair a deficiency in arch/um update-po-config: $(obj)/kxgettext - xgettext --default-domain=linux \ + $(Q)echo " GEN config" + $(Q)xgettext --default-domain=linux \ --add-comments --keyword=_ --keyword=N_ \ --from-code=UTF-8\ --files-from=scripts/kconfig/POTFILES.in \ --output $(obj)/config.pot $(Q)sed -i s/CHARSET/UTF-8/ $(obj)/config.pot $(Q)ln -fs Kconfig.i386 arch/um/Kconfig.arch - (for i in `ls arch/`;\ - do \ - $(obj)/kxgettext arch/$$i/Kconfig; \ - done ) >> $(obj)/config.pot - msguniq --sort-by-file --to-code=UTF-8 $(obj)/config.pot \ + $(Q)(for i in `ls arch/`;\ + do \ + echo " GEN $$i";\ + $(obj)/kxgettext arch/$$i/Kconfig\ +>> $(obj)/config.pot; \ + done ) + $(Q)msguniq --sort-by-file --to-code=UTF-8 $(obj)/config.pot \ --output $(obj)/linux.pot $(Q)rm -f arch/um/Kconfig.arch $(Q)rm -f $(obj)/config.pot @@ -138,6 +141,7 @@ endif clean-files:= lkc_defs.h qconf.moc .tmp_qtcheck \ .tmp_gtkcheck zconf.tab.c lex.zconf.c zconf.hash.c clean-files += mconf qconf gconf +clean-files += config.pot linux.pot # Check that we have the required ncurses stuff installed for lxdialog (menuconfig) PHONY += $(obj)/dochecklxdialog _ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/10] kconfig: gettext support for lxdialog
Gettext support for lxdialog.
Signed-off-by: Egry Gabor <[EMAIL PROTECTED]>
Reviewed-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
kbuild-szilard/scripts/kconfig/POTFILES.in |6 ++
kbuild-szilard/scripts/kconfig/lxdialog/checklist.c |4 ++--
kbuild-szilard/scripts/kconfig/lxdialog/dialog.h|6 ++
kbuild-szilard/scripts/kconfig/lxdialog/inputbox.c |4 ++--
kbuild-szilard/scripts/kconfig/lxdialog/menubox.c |6 +++---
kbuild-szilard/scripts/kconfig/lxdialog/textbox.c |2 +-
kbuild-szilard/scripts/kconfig/lxdialog/yesno.c |4 ++--
7 files changed, 22 insertions(+), 10 deletions(-)
diff -puN scripts/kconfig/lxdialog/checklist.c~kconfig-i18n-03-lxdialog-i18n
scripts/kconfig/lxdialog/checklist.c
--- kbuild/scripts/kconfig/lxdialog/checklist.c~kconfig-i18n-03-lxdialog-i18n
2008-01-11 22:24:39.0 +0100
+++ kbuild-szilard/scripts/kconfig/lxdialog/checklist.c 2008-01-11
22:24:39.0 +0100
@@ -97,8 +97,8 @@ static void print_buttons(WINDOW * dialo
int x = width / 2 - 11;
int y = height - 2;
- print_button(dialog, "Select", y, x, selected == 0);
- print_button(dialog, " Help ", y, x + 14, selected == 1);
+ print_button(dialog, gettext("Select"), y, x, selected == 0);
+ print_button(dialog, gettext(" Help "), y, x + 14, selected == 1);
wmove(dialog, y, x + 1 + 14 * selected);
wrefresh(dialog);
diff -puN scripts/kconfig/lxdialog/dialog.h~kconfig-i18n-03-lxdialog-i18n
scripts/kconfig/lxdialog/dialog.h
--- kbuild/scripts/kconfig/lxdialog/dialog.h~kconfig-i18n-03-lxdialog-i18n
2008-01-11 22:24:39.0 +0100
+++ kbuild-szilard/scripts/kconfig/lxdialog/dialog.h2008-01-11
22:24:39.0 +0100
@@ -26,6 +26,12 @@
#include
#include
+#ifndef KBUILD_NO_NLS
+# include
+#else
+# define gettext(Msgid) ((const char *) (Msgid))
+#endif
+
#ifdef __sun__
#define CURS_MACROS
#endif
diff -puN scripts/kconfig/lxdialog/inputbox.c~kconfig-i18n-03-lxdialog-i18n
scripts/kconfig/lxdialog/inputbox.c
--- kbuild/scripts/kconfig/lxdialog/inputbox.c~kconfig-i18n-03-lxdialog-i18n
2008-01-11 22:24:39.0 +0100
+++ kbuild-szilard/scripts/kconfig/lxdialog/inputbox.c 2008-01-11
22:24:39.0 +0100
@@ -31,8 +31,8 @@ static void print_buttons(WINDOW * dialo
int x = width / 2 - 11;
int y = height - 2;
- print_button(dialog, " Ok ", y, x, selected == 0);
- print_button(dialog, " Help ", y, x + 14, selected == 1);
+ print_button(dialog, gettext(" Ok "), y, x, selected == 0);
+ print_button(dialog, gettext(" Help "), y, x + 14, selected == 1);
wmove(dialog, y, x + 1 + 14 * selected);
wrefresh(dialog);
diff -puN scripts/kconfig/lxdialog/menubox.c~kconfig-i18n-03-lxdialog-i18n
scripts/kconfig/lxdialog/menubox.c
--- kbuild/scripts/kconfig/lxdialog/menubox.c~kconfig-i18n-03-lxdialog-i18n
2008-01-11 22:24:39.0 +0100
+++ kbuild-szilard/scripts/kconfig/lxdialog/menubox.c 2008-01-11
22:24:39.0 +0100
@@ -157,9 +157,9 @@ static void print_buttons(WINDOW * win,
int x = width / 2 - 16;
int y = height - 2;
- print_button(win, "Select", y, x, selected == 0);
- print_button(win, " Exit ", y, x + 12, selected == 1);
- print_button(win, " Help ", y, x + 24, selected == 2);
+ print_button(win, gettext("Select"), y, x, selected == 0);
+ print_button(win, gettext(" Exit "), y, x + 12, selected == 1);
+ print_button(win, gettext(" Help "), y, x + 24, selected == 2);
wmove(win, y, x + 1 + 12 * selected);
wrefresh(win);
diff -puN scripts/kconfig/lxdialog/textbox.c~kconfig-i18n-03-lxdialog-i18n
scripts/kconfig/lxdialog/textbox.c
--- kbuild/scripts/kconfig/lxdialog/textbox.c~kconfig-i18n-03-lxdialog-i18n
2008-01-11 22:24:39.0 +0100
+++ kbuild-szilard/scripts/kconfig/lxdialog/textbox.c 2008-01-11
22:24:39.0 +0100
@@ -114,7 +114,7 @@ do_resize:
print_title(dialog, title, width);
- print_button(dialog, " Exit ", height - 2, width / 2 - 4, TRUE);
+ print_button(dialog, gettext(" Exit "), height - 2, width / 2 - 4,
TRUE);
wnoutrefresh(dialog);
getyx(dialog, cur_y, cur_x);/* Save cursor position */
diff -puN scripts/kconfig/lxdialog/yesno.c~kconfig-i18n-03-lxdialog-i18n
scripts/kconfig/lxdialog/yesno.c
--- kbuild/scripts/kconfig/lxdialog/yesno.c~kconfig-i18n-03-lxdialog-i18n
2008-01-11 22:24:39.0 +0100
+++ kbuild-szilard/scripts/kconfig/lxdialog/yesno.c 2008-01-11
22:24:39.0 +0100
@@ -29,8 +29,8 @@ static void print_buttons(WINDOW * dialo
int x = width / 2 - 10;
int y = height - 2;
- print_button(dialog, " Yes ", y, x, selected == 0);
- print_button(dialog, " No ", y, x + 13, selected == 1);
+ print_button(dialog, gettext(" Yes "), y, x, selected == 0);
+ print_button(dialog, gettext(" No "), y, x + 13, selec
[PATCH] x86: Change unnecessary dependencies on CONFIG_PM
[Ingo, this patch applies on top of the mm branch, please add.] --- From: Rafael J. Wysocki <[EMAIL PROTECTED]> CONFIG_PM_CPUINIT should depend on CONFIG_PM_SLEEP rather than on CONFIG_PM, because it only is needed for suspend and hibernation. Also, it's not necessary to compile arch/x86/power/cpu.c if CONFIG_PM_SLEEP is not set, for the same reason. Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> --- arch/x86/Kconfig|2 +- arch/x86/power/Makefile |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6/arch/x86/Kconfig === --- linux-2.6.orig/arch/x86/Kconfig +++ linux-2.6/arch/x86/Kconfig @@ -150,7 +150,7 @@ config GENERIC_PENDING_IRQ config PM_CPUINIT bool - depends on PM + depends on PM_SLEEP default y config X86_SMP Index: linux-2.6/arch/x86/power/Makefile === --- linux-2.6.orig/arch/x86/power/Makefile +++ linux-2.6/arch/x86/power/Makefile @@ -1,2 +1,2 @@ -obj-$(CONFIG_PM) += cpu.o +obj-$(CONFIG_PM_SLEEP) += cpu.o obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o -- 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] ACPI: Make sleep/main.c compile with CONFIG_PM_SLEEP unset
[Len, this patch applies on top of the suspend branch, please add.] --- From: Rafael J. Wysocki <[EMAIL PROTECTED]> Make drivers/acpi/sleep/main.c compile with CONFIG_PM_SLEEP unset Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> --- drivers/acpi/sleep/main.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6/drivers/acpi/sleep/main.c === --- linux-2.6.orig/drivers/acpi/sleep/main.c +++ linux-2.6/drivers/acpi/sleep/main.c @@ -23,9 +23,9 @@ #include "sleep.h" u8 sleep_states[ACPI_S_STATE_COUNT]; +static u32 acpi_target_sleep_state = ACPI_STATE_S0; #ifdef CONFIG_PM_SLEEP -static u32 acpi_target_sleep_state = ACPI_STATE_S0; static bool acpi_sleep_finish_wake_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/
Usage semantics of atomic_set ( )
I'm trying to implement atomic ops for a CPU which has no inherent support for Read-Modify-Write Ops. Instead of using a global spin lock which protects all the atomic APIs, I want to use a spin lock per instance of atomic_t. This works well when atomic_t is unitary and statically initialized using ATOMIC_INIT (where I can reset the spinlock_t as well). However if atomic_t var is embedded within a bigger struct which is allocated dynamically how to I init the embedded spin lock. atomic_set ( ) is the closest choice, however I don't think it's current usage in kernel code qualifies it to be "initializer only". Doesn't that defeat the intended usage of atomic_t as a opaque type which can be "effectively" used to hide other architecture specific stuff. Thanks, Vineet -- 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 8/10] kconfig: gettext support for xconfig
Full gettext support for xconfig.
Signed-off-by: Egry Gabor <[EMAIL PROTECTED]>
Reviewed-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
kbuild-szilard/scripts/kconfig/qconf.cc | 93
1 file changed, 49 insertions(+), 44 deletions(-)
diff -puN scripts/kconfig/qconf.cc~kconfig-i18n-15-qconfig-i18n
scripts/kconfig/qconf.cc
--- kbuild/scripts/kconfig/qconf.cc~kconfig-i18n-15-qconfig-i18n
2008-01-11 22:27:16.0 +0100
+++ kbuild-szilard/scripts/kconfig/qconf.cc 2008-01-11 22:27:16.0
+0100
@@ -114,7 +114,7 @@ void ConfigItem::updateMenu(void)
sym = menu->sym;
prop = menu->prompt;
- prompt = QString::fromLocal8Bit(menu_get_prompt(menu));
+ prompt = _(menu_get_prompt(menu));
if (prop) switch (prop->type) {
case P_MENU:
@@ -208,7 +208,7 @@ void ConfigItem::updateMenu(void)
break;
}
if (!sym_has_value(sym) && visible)
- prompt += " (NEW)";
+ prompt += _(" (NEW)");
set_prompt:
setText(promptColIdx, prompt);
}
@@ -346,7 +346,7 @@ ConfigList::ConfigList(ConfigView* p, co
for (i = 0; i < colNr; i++)
colMap[i] = colRevMap[i] = -1;
- addColumn(promptColIdx, "Option");
+ addColumn(promptColIdx, _("Option"));
reinit();
}
@@ -360,14 +360,14 @@ void ConfigList::reinit(void)
removeColumn(nameColIdx);
if (showName)
- addColumn(nameColIdx, "Name");
+ addColumn(nameColIdx, _("Name"));
if (showRange) {
addColumn(noColIdx, "N");
addColumn(modColIdx, "M");
addColumn(yesColIdx, "Y");
}
if (showData)
- addColumn(dataColIdx, "Value");
+ addColumn(dataColIdx, _("Value"));
updateListAll();
}
@@ -803,7 +803,7 @@ void ConfigList::contextMenuEvent(QConte
QAction *action;
headerPopup = new QPopupMenu(this);
- action = new QAction(NULL, "Show Name", 0, this);
+ action = new QAction(NULL, _("Show Name"), 0, this);
action->setToggleAction(TRUE);
connect(action, SIGNAL(toggled(bool)),
parent(), SLOT(setShowName(bool)));
@@ -811,7 +811,7 @@ void ConfigList::contextMenuEvent(QConte
action, SLOT(setOn(bool)));
action->setOn(showName);
action->addTo(headerPopup);
- action = new QAction(NULL, "Show Range", 0, this);
+ action = new QAction(NULL, _("Show Range"), 0, this);
action->setToggleAction(TRUE);
connect(action, SIGNAL(toggled(bool)),
parent(), SLOT(setShowRange(bool)));
@@ -819,7 +819,7 @@ void ConfigList::contextMenuEvent(QConte
action, SLOT(setOn(bool)));
action->setOn(showRange);
action->addTo(headerPopup);
- action = new QAction(NULL, "Show Data", 0, this);
+ action = new QAction(NULL, _("Show Data"), 0, this);
action->setToggleAction(TRUE);
connect(action, SIGNAL(toggled(bool)),
parent(), SLOT(setShowData(bool)));
@@ -1041,7 +1041,12 @@ void ConfigInfoView::menuInfo(void)
if (showDebug())
debug = debug_info(sym);
- help = print_filter(_(menu_get_help(menu)));
+ help = menu_get_help(menu);
+ /* Gettextize if the help text not empty */
+ if (help.isEmpty())
+ help = print_filter(menu_get_help(menu));
+ else
+ help = print_filter(_(menu_get_help(menu)));
} else if (menu->prompt) {
head += "";
head += print_filter(_(menu->prompt->text));
@@ -1167,7 +1172,7 @@ void ConfigInfoView::expr_print_help(voi
QPopupMenu* ConfigInfoView::createPopupMenu(const QPoint& pos)
{
QPopupMenu* popup = Parent::createPopupMenu(pos);
- QAction* action = new QAction(NULL,"Show Debug Info", 0, popup);
+ QAction* action = new QAction(NULL, _("Show Debug Info"), 0, popup);
action->setToggleAction(TRUE);
connect(action, SIGNAL(toggled(bool)), SLOT(setShowDebug(bool)));
connect(this, SIGNAL(showDebugChanged(bool)), action,
SLOT(setOn(bool)));
@@ -1189,11 +1194,11 @@ ConfigSearchWindow::ConfigSearchWindow(C
QVBoxLayout* layout1 = new QVBoxLayout(this, 11, 6);
QHBoxLayout* layout2 = new QHBoxLayout(0, 0, 6);
- layout2->addWidget(new QLabel("Find:", this));
+ layout2->addWidget(new QLabel(_("Find:"), this));
editFi
[PATCH 10/10] kconfig: whitespace removing
This patch removes the unnecessary whitespaces from end of help lines of
Kconfig files.
Signed-off-by: Egry Gabor <[EMAIL PROTECTED]>
Reviewed-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
kbuild-szilard/scripts/kconfig/lex.zconf.c_shipped |5 +
kbuild-szilard/scripts/kconfig/zconf.l |5 +
2 files changed, 10 insertions(+)
diff -puN scripts/kconfig/zconf.l~kconfig-i18n-18-whitespace-fix
scripts/kconfig/zconf.l
--- kbuild/scripts/kconfig/zconf.l~kconfig-i18n-18-whitespace-fix
2008-01-11 22:27:19.0 +0100
+++ kbuild-szilard/scripts/kconfig/zconf.l 2008-01-11 22:27:19.0
+0100
@@ -217,6 +217,11 @@ n [A-Za-z0-9_]
append_string("\n", 1);
}
[^ \t\n].* {
+ while (yyleng) {
+ if ((yytext[yyleng-1] != ' ') && (yytext[yyleng-1] !=
'\t'))
+ break;
+ yyleng--;
+ }
append_string(yytext, yyleng);
if (!first_ts)
first_ts = last_ts;
diff -puN scripts/kconfig/lex.zconf.c_shipped~kconfig-i18n-18-whitespace-fix
scripts/kconfig/lex.zconf.c_shipped
--- kbuild/scripts/kconfig/lex.zconf.c_shipped~kconfig-i18n-18-whitespace-fix
2008-01-11 22:27:19.0 +0100
+++ kbuild-szilard/scripts/kconfig/lex.zconf.c_shipped 2008-01-11
22:27:19.0 +0100
@@ -1275,6 +1275,11 @@ YY_RULE_SETUP
case 32:
YY_RULE_SETUP
{
+ while (zconfleng) {
+ if ((zconftext[zconfleng-1] != ' ') &&
(zconftext[zconfleng-1] != '\t'))
+ break;
+ zconfleng--;
+ }
append_string(zconftext, zconfleng);
if (!first_ts)
first_ts = last_ts;
_
--
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/
