Re: [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK
Miguel Ojeda wrote: I think we can fix them as they come. If your change to a function breaks its callers, it's your job to fix the callers proactively instead of waiting for "as they come" bug reports. (Assuming, of course, that you know about the breakage. Which you do when you tell us that the bad pattern can simply be grepped for.) If nothing else, that's far more efficient than [number_of_callers] separate patches by other people who each need to find the offending change, figure out what to change and/or who to report the problem to, and so on until the fix lands in the kernel. Moreover, this wouldn't leave the kernel sources in a non-bisect-able state during that time. -- -- Matthias Urlichs OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] MAINTAINERS: drop two usb-serial subdriver entries
Hi, Matthias Urlichs: > Fine by me. or, in other words: Signed-Off-By: Matthias Urlichs -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: [PATCH] MAINTAINERS: drop two usb-serial subdriver entries
Hi, Johan Hovold: > > > -USB OPTION-CARD DRIVER > > > -M: Matthias Urlichs > > > -L: linux-...@vger.kernel.org > > > -S: Maintained > > > -F: drivers/usb/serial/option.c > > > > Why are we taking away the maintainership of these individual drivers > > from these developers? I had no problem giving you the drivers I was > > supposed to be in charge of, but I need a signed-off-by from Matthias > > and Oliver for these if they want to do the same. > > I honestly thought you had just missed these entries when you removed > individual maintainership for the other usb-serial drivers with the > motivation that the developers were not around and that maintainership > for individual drivers did not make much sense anymore (as consolidation > proceeds, I read). (These two entries were also not grouped with the > others.) > > Oliver and perhaps also Mathias are still around, but the option driver > is now down to about 200 LOC (including boilerplate) when not counting > the id table, while the kl5kusb105 is currently at about 400 LOC > (including boilerplate) since I converted it to use the generic > implementation a few years ago. > > Oliver and Mathias, what do you think of this? Would you be willing to > sign off on this patch? > Fine by me. While I am indeed "still around", Option doesn't need a maintainer any more -- the thing just works, and I do not see any need for driver-specific changes other than additions to the ID table. You hardly need a maintainer for that. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Huawei EC321 CDMA PCCARD support broken
Hi, > A lot of google searches reflect that, the latest kernel supporting > Huawei EC321 CDMA PCCARD is 2.6.17. My version (2.6.22-14 on Ubuntu) > doesn't work. > This is probably because ... > [ 3804.14] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for pl2303 ... the card is in fact recognized by the pl2303 driver instead of the Option driver. This driver may do something stupid. Please try this (as root): # rmmod plc2303 # modprobe option If the card still does not work, type # lsusb and send me that. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - Okay, who stopped the payment on my reality check? -- 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-rc2-mm1
Hi, Jiri Kosina: > hmm, still doesn't work even if I try to fetch the tag directly from hera *Sigh* fixed. I hope. ;-) -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - Just about every computer on the market today runs Unix, except the Mac (and nobody cares about it). -- Bill Joy 6/21/85 - 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-rc2-mm1
Hi, Jiri Kosina: > $ git-fetch > git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag > v2.6.24-rc2-mm1 > error: no such remote ref refs/tags/v2.6.24-rc2-mm1 Yeah, the import took too long and thus broke. Should be fixed by now. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - :FTP: /F-T-P/, _not_ /fit'ip/ 1. [techspeak] n. The File Transfer Protocol for transmitting files between systems on the Internet. 2. vt. To {beam} a file using the File Transfer Protocol. 3. Sometimes used as a generic even for file transfers not using {FTP}. "Lemme get a copy of "Wuthering Heights" ftp'd from uunet." - 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] scsi: megaraid_{mm,mbox} cmd timeout
Hi, Patro, Sumant: > What I see in the log is cmd timeout(s) and is not related to the patch. > Ouch. Any ideas what causes my problem? It's a regression; I tested Ubuntu Dapper and Edgy install CDs, and it's not worked since the latter. I can pinpoint the change that triggers the problem more closely if necessary. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - My father was a God-fearing man, but he never missed a copy of the New York Times, either. -- E.B. White signature.asc Description: Digital signature
Re: [PATCH] scsi: megaraid_{mm,mbox} init fix for kdump
On Fri, 05 Jan 2007 07:10:09 -0800, Sumant Patro wrote: > This command clears the pending commands in the adapter > and re-initialize its internal RAID structure. > Without this change, megaraid driver either panics or fails to > initialize the adapter during kdump's second kernel boot > if there are pending commands or interrupts from other devices > sharing the same IRQ. Nice. Is there a chance that this patch will also fix the regression I've noticed (today, unfortunately) on (at least one) Dell server? FWIW, here's the relevant LSPCI output and kernel logs: 0d:0e.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID (rev 07) Subsystem: Dell Unknown device 0002 Flags: bus master, stepping, 66MHz, medium devsel, latency 64, IRQ 18 Memory at d80f (32-bit, prefetchable) [size=64K] Memory at fc4c (32-bit, non-prefetchable) [size=256K] Expansion ROM at fc50 [disabled] [size=128K] Capabilities: [c0] Power Management version 2 Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable- Capabilities: [e0] PCI-X non-bridge device Jan 31 14:41:34 kernel: [ 232.873327] megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006) Jan 31 14:41:34 kernel: [ 232.877616] SCSI subsystem initialized Jan 31 14:41:34 kernel: [ 232.888779] megaraid: 2.20.4.9 (Release Date: Sun Jul 16 12:27:22 EST 2006) Jan 31 14:41:34 kernel: [ 232.889835] megasas: 00.00.03.05 Mon Oct 02 11:21:32 PDT 2006 Jan 31 14:41:34 kernel: [ 233.513659] megasas: 0x1028:0x0015:0x1028:0x1f03: <6>megaraid: probe new device 0x1000:0x0408:0x1028:0x0002: bus 13:slot 14:func 0 Jan 31 14:41:34 kernel: [ 233.514770] megasas: FW now in Ready state Jan 31 14:41:34 kernel: [ 233.528893] megaraid: fw version:[522A] bios version:[H430] Jan 31 14:41:34 kernel: [ 233.554778] scsi2 : LSI Logic SAS based MegaRAID driver Jan 31 14:41:34 kernel: [ 233.36] scsi 2:0:0:0: Direct-Access MAXTOR ATLAS10K5_073SAS BP00 PQ: 0 ANSI: 5 Jan 31 14:41:34 kernel: [ 233.556173] scsi 2:0:1:0: Direct-Access MAXTOR ATLAS10K5_073SAS BP00 PQ: 0 ANSI: 5 Jan 31 14:41:34 kernel: [ 233.569337] scsi3 : LSI Logic MegaRAID driver Jan 31 14:41:34 kernel: [ 233.569550] scsi[3]: scanning scsi channel 0 [Phy 0] for non-raid devices Jan 31 14:41:34 kernel: [ 233.604522] scsi 2:0:8:0: Enclosure DP BACKPLANE 1.00 PQ: 0 ANSI: 5 Jan 31 14:41:41 kernel: [ 243.115199] megaraid: aborting-16 cmd=12 Jan 31 14:41:41 kernel: [ 243.115206] megaraid abort: 16:0[0:12], fw owner Jan 31 14:41:41 kernel: [ 243.115217] megaraid: 1 outstanding commands. Max wait 300 sec Jan 31 14:41:41 kernel: [ 243.115221] megaraid mbox: Wait for 1 commands to complete:300 Jan 31 14:41:46 kernel: [ 248.125812] megaraid mbox: Wait for 1 commands to complete:295 Jan 31 14:41:48 kernel: [ 250.134075] megaraid mbox: reset sequence completed sucessfully Jan 31 14:41:58 kernel: [ 260.117201] megaraid: aborting-16 cmd=0 Jan 31 14:41:58 kernel: [ 260.117207] megaraid abort: 16:0[0:12], fw owner Jan 31 14:41:58 kernel: [ 260.117217] megaraid: 1 outstanding commands. Max wait 300 sec Jan 31 14:41:58 kernel: [ 260.117223] megaraid mbox: Wait for 1 commands to complete:300 Jan 31 14:42:03 kernel: [ 265.127417] megaraid mbox: Wait for 1 commands to complete:295 Jan 31 14:42:08 kernel: [ 270.140211] megaraid mbox: Wait for 1 commands to complete:290 Jan 31 14:42:12 kernel: [ 274.146803] megaraid mbox: reset sequence completed sucessfully [ nothing else that appears relevant ] -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - Those who welcome death have only tried it from the ears up. -- Wilson Mizner - 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/
Regression hunting with git (was: Re: 2.6.13-rc3-mm3)
Hi, Andrew Morton: > > Note that if you work from my git import, git has a nice tree bisection > > option. > > Is that documented anywhere? http://lkml.org/lkml/2005/6/24/234 Basically, you do this: $ set -o noclobber $ git-rev-tree --bisect ^good1 ^good2 bad > .git/refs/heads/tryN $ git checkout tryN (Initially, "good" is v2.6.12 or whatever version last worked for you; "bad" is "master", thus: $ git-rev-tree --bisect ^v2.6.12 master > .git/refs/heads/tryN ) Build kernel, test. If good, add tryN to the list of good kernels, above; if bad, replace "bad" with "tryN". N += 1. Repeat. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - IT'S HERE AT LAST: Rush job; nobody knew it was coming signature.asc Description: Digital signature
Re: 2.6.13-rc3-mm3
Hi, Andrew Morton: > Matthias Urlichs <[EMAIL PROTECTED]> wrote: > > Note that if you work from my git import, git has a nice tree bisection > > option. > > Is that documented anywhere? *checking* Apparently not, not unless you count the git list's archive. (It's git-rev-list.) I'll fix that. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - The makers may make and the users may use, but the fixers must fix with but minimal clues signature.asc Description: Digital signature
Re: 2.6.13-rc3-mm3
Hi, Rafael J. Wysocki wrote: > start a binary search Note that if you work from my git import, git has a nice tree bisection option. That tree may be very helpful if the regression is hidden in one of the git trees imported into -mm, as it allows you to pinpoint the exact change -- as opposed to "it happened somewhere in git-large-foobar-update.patch". -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - British education is probably the best in the world, if you can survive it. If you can't there is nothing left for you but the diplomatic corps. -- Peter Ustinov - 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.13-rc3-mm3 question
Hi, Radoslaw "AstralStorm" Szkodzinski wrote: > I wonder which git version is linus.patch updating to Note, if you want -mm as a nice shiny parent-linked git tree, just pull from http://www.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git (the whichever-mm-release-you-want branch). I can import other patchsets that way; just ping me. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - Nature is the chart of God, mapping out all His attributes; art is the shadow of His wisdom, and copieth His resources. -- Tupper - 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.9 chrdev_open: serial_core: uart_open
Hi, Alan Cox wrote: > A good rule of thumb > is to trace the sequence of calls and assume that the last sane sequence > is the one that occurred before the failure. Note also that gcc does sibling optimization, i.e. it will happily reduce the code at the end of int bar(a,b) { [...] return baz(x,y); } into something like overwrite 'a' with 'x', and 'b' with 'y' pop local stack frame, if present jump to baz which saves some stack space and is faster, but makes you wonder how in hell the baz foo stack dump you're seeing in your crash dump came about. (2.6.13 will turn that off when debugging.) -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - There is a vast difference between putting your nose in other people's business and putting your heart in other people's problems. - 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.13-rc3-mm1
Hi, Matthias Urlichs wrote: > Also GITtable, as soon as the mirrors' work is done: > > http://www.kernel.org/git/?p=linux/kernel/git/smurf/v2.6.13-rc3-mm1.git;a=summary Moved to http://www.kernel.org/git/?p=linux/kernel/git/smurf/linux-trees.git;a=summary -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - A marriage is always made up of two people who are prepared to swear that only the other one snores. -- Terry Pratchett (The Fifth Elephant) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt
Hi, Bill Davidsen wrote: > Do you actually have something against tickless, or just don't think it > can be done in reasonable time? You can do it in small steps. When you have that jiffies_increment variable, you can add code to dynamically adjust it at runtime -- just reprogram the system timer (which may not be cheap). After you've done *that*, you can teach the add_timer code to optionally adjust jiffies_increment when demand changes; add an estimate on timer tick cost vs. reprogramming cost (which could return "always" when you're running UML); you might want to take user prefs into account ("always reprogram if the timeout would arrive more than 10 msec late, because otherwise my Doom3 game lags too much"). There you are. Tickless, and nobody even notices. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - Caesar had his Brutus -- charles the First, his Cromwell -- and George the Third ("Treason!" cried the Speaker) -- may profit by their example. If this be treason, make the most of it. -- Patrick Henry - 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.13-rc3-mm1
Hi, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ > Also GITtable, as soon as the mirrors' work is done: http://www.kernel.org/git/?p=linux/kernel/git/smurf/v2.6.13-rc3-mm1.git;a=summary ... since people asked: - trees from GIT are properly parent-linked. - yes, I can import other people's patch series. - the whole import runs in a couple of minutes. In fact, I keep suspecting that it must be skipping some important step or other. ;-) Kudos to Linus, and of course everybody else who's involved with git, for yet another tool done *right*. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - A classic is something that everybody wants to have read and nobody wants to read. -- Mark Twain - 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.13-rc2-mm2
Hi, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc2/2.6.13-rc2-mm2/ Also available as a GIT archive (once the mirror has mirrored): http://www.kernel.org/pub/scm/linux/kernel/git/smurf/v2.6.13-rc2-mm2.git/ Suggestions for improvements welcome. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - Doctors and lawyers must go to school for years and years, often with little sleep and with great sacrifice to their first wives. -- Roy G. Blount, Jr. - 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: more git updates..
Hi, Linus Torvalds schrub am Tue, 12 Apr 2005 15:49:07 -0700: >> Have to tried to import it? > > It would take days. You can always import it later and then graft it into the commit tree. That would of course change *every* commit node, but so what? They're small, and you can delete the old ones when you're done. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [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: incoming
Hi, Andrew Morton schrub am Tue, 12 Apr 2005 04:10:45 -0700: > David Vrabel <[EMAIL PROTECTED]> wrote: >> >> Is there any chance that in the future that these patch sets get posted >> all to one thread? > > I never got around to setting that up, plus the Subject:s pretty quickly > become invisible when they're indented 198 columns in GUI MUAs. > Umm, what stops you from letting all the parts refer to part zero, instead of part n-1? -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [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: Kernel SCM saga..
Hi, Jan Hudec schrub am Thu, 07 Apr 2005 09:44:08 +0200: > 1) GNU Arch/Bazaar. They use the same archive format, simple, have the >concepts right. It may need some scripts or add ons. When Bazaar-NG is >ready, it will be able to read the GNU Arch/Bazaar archives so >switching should be easy. Plus Bazaar has multiple implementations (C and Python). Plus arch can trivially export single patches. Plus ... well, you get the idea. ;-) Linus: Care to share your SCM feature requirement list? -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [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: connector.c
Hi, Tommy Reynolds schrub am Thu, 31 Mar 2005 20:41:35 -0600: > Uttered Andrew Morton <[EMAIL PROTECTED]>, spake thus: > >> >if (uskb) { >> >netlink_unicast(dev->nls, uskb, 0, 0); >> >} >> >> Unneeded {} > > However, for maintainability (and best practices) they are essential. They do add visual clutter, though, so they make the code as-is less readable. I don't think it's entirely accidental that Python is so much more readable. (For me, anyway -- YMMV and all that.) -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [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/
Call chain analysis
Hi, I'm running into an IRQ problem while removing USB adapters (e.g., when pulling a PCMCIA card with an OHCI on it). Specifically, this call chain usb_hcd_pci_remove -> hcd_buffer_destroy -> dma_pool_destroy -> pool_free_page -> free_hot_cold_page -> IRQ -> usb_hcd_irq results in a crash. That's not the immediate problem, though. The problem is that wrapping usb_hcd_pci_remove() in a local_irq_save/ /restore *still* allows that interrupt to happen. I suspect that something in that call chain sometimes calls the scheduler ..? I assume that there are nice tools which find that call for me, and save me from plowing through a lot of kernel code ..? I've never needed one of those before. :-/ -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [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/
[2.6 patch] bksend example script fix
The "bksend" example script doesn't work if PAGER (used by "bk changes") is set to something which doesn't fallback to plain stdout if its output isn't a tty. Fixed by forcing PAGER to be /bin/cat. Signed-Off-By: Matthias Urlichs <[EMAIL PROTECTED]> diff -Nru a/Documentation/BK-usage/bksend b/Documentation/BK-usage/bksend --- a/Documentation/BK-usage/bksend 2005-02-18 10:06:04 +01:00 +++ b/Documentation/BK-usage/bksend 2005-02-18 10:06:04 +01:00 @@ -27,7 +27,7 @@ SEP="\n===\n\n" echo -e $SEP -bk changes -r$REV +env PAGER=/bin/cat bk changes -r$REV echo bk export -tpatch -du -h -r$REV | diffstat echo; echo -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] signature.asc Description: Digital signature
[2.6 patch] CREDITS Update
Small CREDITS update for Mattihas Urlichs. Signed-Off-By: Matthias Urlichs <[EMAIL PROTECTED]> diff -Nru a/CREDITS b/CREDITS --- a/CREDITS 2005-02-18 10:06:04 +01:00 +++ b/CREDITS 2005-02-18 10:06:04 +01:00 @@ -3336,10 +3336,11 @@ S: USA N: Matthias Urlichs -E: [EMAIL PROTECTED] -E: [EMAIL PROTECTED] +E: [EMAIL PROTECTED] +E: [EMAIL PROTECTED] +E: [EMAIL PROTECTED] D: Consultant, developer, kernel hacker -D: Playing with Streams, ISDN, and BSD networking code for Linux +D: In a previous life, worked on Streams/ISDN/BSD networking code for Linux S: Schleiermacherstrasse 12 S: 90491 Nuernberg S: Germany -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] signature.asc Description: Digital signature
[2.6 patch] obey HOSTLOADLIBES_programname for single-file compilation
Single-file HOSTCC calls added the libraries from $(HOSTLOADLIBES), but not from $(HOSTLOADLIBES_programname). Multi-file HOSTCC calls do both. This patch fixes that inconsistency. Signed-Off-By: Matthias Urlichs <[EMAIL PROTECTED]> diff -Nru a/scripts/Makefile.host b/scripts/Makefile.host --- a/scripts/Makefile.host 2005-02-18 10:19:29 +01:00 +++ b/scripts/Makefile.host 2005-02-18 10:19:29 +01:00 @@ -98,7 +98,8 @@ # Create executable from a single .c file # host-csingle -> Executable quiet_cmd_host-csingle = HOSTCC $@ - cmd_host-csingle = $(HOSTCC) $(hostc_flags) $(HOST_LOADLIBES) -o $@ $< + cmd_host-csingle = $(HOSTCC) $(hostc_flags) -o $@ $< \ + $(HOST_LOADLIBES) $(HOSTLOADLIBES_$(@F)) $(host-csingle): %: %.c FORCE $(call if_changed_dep,host-csingle) -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] signature.asc Description: Digital signature
Kernel hangs on PCI config register access ???
Hi, we have a bunch of systems which semi-reproducibly (chance of 1:1000) hang when a PCMCIA card is removed from its PCI->PCMCIA interface via "cardctl eject". Right *here*, in fact: static int pci_conf1_read (int seg, int bus, int devfn, int reg, int len, + u32 *value) { [...] case 2: debug("you see me \n"); *value = inw(0xCFC + (reg & 2)); debug("but you don't get here \n"); break; [...] Does anybody have *any* idea what could possibly be the cause of this? Using pci=bios still hangs; pci=conf2 doesn't work. FWIW, the call sequence is: shutdown_socket yenta_sock_init yenta_clear_maps yenta_set_socket pci_bus_read_config_word pci_conf1_read The systems in question are wildly different (VIA vs. Intel CPUs, standard mainboard vs. PCI backplane, Ricoh vs. ENE cardbus bridges), so I'm inclined to rule out hardware problems. The NMI monitor doesn't trigger (yes I tested it), kgdb is unresponsive -- the system hangs hard at that point, as far as I can determine. Kernel: tested with various 2.6.1? plus -rc* and/or -mm*, no change. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [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][2.6-mm] kgdb documentation fix
Hi, Please apply. --- Update Documentation/i386/kgdb/gdbinit-modules to conform to the current kernel's module data structure. Signed-Off-By: Matthias Urlichs <[EMAIL PROTECTED]> --- = Documentation/i386/kgdb/gdbinit-modules 1.1 vs edited = --- 1.1/Documentation/i386/kgdb/gdbinit-modules 2005-02-12 12:44:54 +01:00 +++ edited/Documentation/i386/kgdb/gdbinit-modules 2005-02-12 20:12:45 +01:00 @@ -60,87 +60,90 @@ # $mod is set to NULL. This ensure to not add symbols for a wrong # address. # +# +# Sat Feb 12 20:05:47 CET 2005 +# +# Adapted to the 2.6.* module data structure. +# (Getting miffed at gdb for not having "offsetof" in the process :-/ ) +# +# Autogenerate add-symbol-file statements from the module list instead +# of relying on a no-longer-working loadmodule.sh program. +# +# Matthias Urlichs <[EMAIL PROTECTED]> +# +# # Have a nice hacking day ! # # define mod-list -set $mod = (struct module*)module_list -# the last module is the kernel, ignore it -while $mod != &kernel_module - printf "%p\t%s\n", (long)$mod, ($mod)->name - set $mod = $mod->next +set $lmod = modules->next +# This is a circular data structure +while $lmod != &modules + set $mod = (struct module *)(((char *)$lmod) - ((int)&(((struct module *)0) -> list))) +printf "%p\t%s\n", $mod, $mod->name + set $lmod = $lmod->next end end document mod-list +mod-list List all modules in the form: Use the as the argument for the other mod-commands: mod-print-symbols, mod-add-symbols. end +define mod-list-syms +set $lmod = modules->next +# This is a circular data structure +while $lmod != &modules + set $mod = (struct module *)(((char *)$lmod) - ((int)&(((struct module *)0) -> list))) +printf "add-symbol-file %s.ko %p\n", $mod->name, $mod->module_core + set $lmod = $lmod->next +end +end +document mod-list-syms +mod-list-syms +List all modules in the form: add-symbol-file +for adding modules' symbol tables without loadmodule.sh. +end + define mod-validate -set $mod = (struct module*)module_list -while ($mod != $arg0) && ($mod != &kernel_module) - set $mod = $mod->next +set $lmod = modules->next + set $mod = (struct module *)(((char *)$lmod) - ((int)&(((struct module *)0) -> list))) +while ($lmod != &modules) && ($mod != $arg0) +set $lmod = $lmod->next + set $mod = (struct module *)(((char *)$lmod) - ((int)&(((struct module *)0) -> list))) end -if $mod == &kernel_module - set $mod = 0 - printf "%p is not a module\n", $arg0 +if $lmod == &modules + set $mod = 0 +printf "%p is not a module\n", $arg0 end end document mod-validate mod-validate Internal user-command used to validate the module parameter. -If is a real loaded module, set $mod to it otherwise set $mod to 0. +If is a real loaded module, set $mod to it, otherwise set $mod +to 0. end - define mod-print-symbols mod-validate $arg0 if $mod != 0 - set $i = 0 - while $i < $mod->nsyms - set $sym = $mod->syms[$i] - printf "%p\t%s\n", $sym->value, $sym->name - set $i = $i + 1 - end + set $i = 0 + while $i < $mod->num_syms + set $sym = $mod->syms[$i] + printf "%p\t%s\n", $sym->value, $sym->name + set $i = $i + 1 + end + set $i = 0 + while $i < $mod->num_gpl_syms + set $sym = $mod->gpl_syms[$i] + printf "%p\t%s\n", $sym->value, $sym->name + set $i = $i + 1 + end end end document mod-print-symbols mod-print-symbols -Print all exported symbols of the module. see mod-list -end - - -define mod-add-symbols-align -mod-validate $arg0 -if $mod != 0 - set $mod_base = ($mod->size_of_struct + (long)$mod) - if ($arg2 != 0) && (($mod_base & ($arg2 - 1)) != 0) - set $mod_base = ($mod_base | ($arg2 - 1)) + 1 - end - add-symbol-file $arg1 $mod_base -end -end -document mod-add-symbols-align -mod-add-symbols-align -Load the symbols table of the module from the object file where -first section aligment is . -To retreive alignment, use `objdump -h '. +Print all exported symbols of the module. See mod-list end -define mod-add-symbols -mod-add-symbols-align $arg0 $arg1 sizeof(long) -end -document mod-add-symbols -mod-add-symbols -Load the symbols table of the module from the object file. -Default alig
Re: 2.6.11-rc1-mm1
Hi, Andrew Morton schrub am Fri, 14 Jan 2005 10:35:34 -0800: > What filesystem(s) do you use, and why? sshfs (best idea for file access through firewalls). gmailfs (best free off-site backup facility). Will use encfs as soon as FUSE is in mainline (I'm using cryptoloop now, but that's not sanely backupable.) -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [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: Is it useful to support user level drivers
At 14:28 +0100 2001-06-21, Alan Cox wrote: >No. The IRQ might be shared, and you get a slight problem if you just disabled >an IRQ needed to make progress for user space to handle the IRQ Two choices: - Disallow shared interrupts for usermode drivers. - Make the 'generic interrupt handler device driver' configurable and/or module-extensible. You only need three entry points ("Interrupt set?"/"Enable interrupts"/"Disable interrupts"), which is reasonably simple to get right. -- Matthias Urlichs - 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: Is it useful to support user level drivers
At 23:50 +1000 2001-06-21, john slee wrote: >i believe libgpio uses the existing usb/iee1394/serial/parallel >interfaces to provide a limited userspace driver capability. That only means, however, that the specific kernel drivers explicitly support mid-level usermode access. They still handle the actual hardware state changes without usermode support. -- Matthias Urlichs - 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: Alan Cox quote? (was: Re: accounting for threads)
At 18:31 -0500 2001-06-19, Timur Tabi wrote: >Not quite. What makes OS/2's threads superior is that the OS multitasks >threads, not processes. So I can create a time-critical thread in my process, >and it will have priority over ALL threads in ALL processes. In contrast to Linux, which does exactly the same thing -- so what are you trying to tell us? >A lot of OS/2 software is written with this feature in mind. I know of one >programmer who absolutely hates Linux because it's just too difficult porting >software to it, and the lack of decent thread support is part of the problem. So what would you consider to be "decent thread support"? -- Matthias Urlichs - 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] sockreg2.4.5-05 inet[6]_create() register/unregistertable
Ahem... David S. Miller wrote: >This allows people to make proprietary implementations of TCP under >Linux. And we don't want this just as we don't want to add a way to >allow someone to do a proprietary Linux VM. *Sigh* and thence begin the proprietary-vs-OpenSource flame wars again. _Any_ open protocol can be abused for proprietary stuff. It can also be used for Something Entirely Different. Personally, I would _love_ to have TCP as a module, just so that the system can unload it on my poor underpowered laptop when it's not needed. The fact that you can abuse this ability in order to replace the current TCP with Something Proprietary And Therefore Evil is a no-brainer. Anybody can do exactly the same thing with my network card driver, or the Unix-domain code, or the NFS server, or ... So what's so damn special about the TCP stack that you need to shout "Absolutely not" here? I don't get it. -- Matthias Urlichs - 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: temperature standard - global config option?
At 18:06 +0200 2001-06-06, Chris Boot wrote: >I'm sorry, by I don't feel like adding 273 to every number I get just to >find the temperature of something. That's much easier than subtracting 32 and multiplying by 5/9. ;-) > What I would do is give configuration >options to choose the default (Celsius/centigrade, Kelvin, or [shudder] >Fahrenheit) The kernel output should not be configurable. You have tools for printing the information; they can do the calculation for you. Personally I'd like to see cK (centi-Kelvin). -- Matthias Urlichs - 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: Fwd: Re: Getting FS access events
Richard Gooch <[EMAIL PROTECTED]>: > > > OK, provided the prefetch will queue up a large number of requests > before starting the I/O. If there was a way of controlling when the > I/O actually starts (say by having a START flag), that would be ideal, > I think. > The START flag is equivalent to the first actual read, whereupon the elevator code will do the Right Thing. > That opens up a nasty race: if the dentry is released before the > pointer is harvested, you get a bogus pointer. > You simply increase the reference count of every dentry you visit, and free it when the log is read. > How's that? It won't matter if read(2) synchronises, because I'll be > issuing the requests in device bnum order. > Of course it does, because the kernel needs to wait for the next read() system call from your application, which it can only do after the first one completes, which adds another delay which will slow you down, especially with high-latency I/O protocols. -- Matthias Urlichs | noris network AG | http://smurf.noris.de/ - 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] SMP race in ext2 - metadata corruption.
Martin Dalecki : > tar/cpio and friends don't deal properly with > > a. holes inside of files. > b. hardlinks between files. > ??? GNU tar does both. The only thing it currently cannot handle is Not Changing Anything: either atime or ctime _will_ be updated. - 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: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.
> > I frequently build Mozilla from scratch on my (aging) dual Celeron > > machine. [...] > > real60m4.574s > > user101m18.260s <-- impossible no? > > sys 3m23.520s > > Why do numbers like this show up? I noticed some of this after having > enabled SMP on my UP box. > Now why would that be impossible on a two-CPU system? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi vs ide performance on fsync's
Hi, Jens Axboe: > > But most disks these days support IDE-SCSI, and SCSI does have ordered > > tags, so... > > Any proof to back this up? To my knowledge, only some WDC ATA disks > can be ATAPI driven. > Ummm, no, but that was my impression. If that's wrong, I apologize and will state the opposite, next time. -- Matthias Urlichs | noris network AG | http://smurf.noris.de/ -- You see things; and you say 'Why?' But I dream things that never were; and I say 'Why not?' --George Bernard Shaw [Back to Methuselah] - 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: scsi vs ide performance on fsync's
Hi, Matthias Urlichs: > On Wed, Mar 07 2001, Stephen C. Tweedie wrote: > > SCSI certainly lets us do both of these operations independently. IDE > > has the sync/flush command afaik, but I'm not sure whether the IDE > > tagged command stuff has the equivalent of SCSI's ordered tag bits. > > Andre? > > IDE has no concept of ordered tags... > But most disks these days support IDE-SCSI, and SCSI does have ordered tags, so... Has anybody done speed comparisons between "native" IDE and IDE-SCSI? -- Matthias Urlichs | noris network AG | http://smurf.noris.de/ -- Success is something I will dress for when I get there, and not until. - 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/