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, Matthias Urlichs: Fine by me. or, in other words: Signed-Off-By: Matthias Urlichs matth...@urlichs.de -- -- 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: [PATCH] MAINTAINERS: drop two usb-serial subdriver entries
Hi, Johan Hovold: -USB OPTION-CARD DRIVER -M: Matthias Urlichs sm...@smurf.noris.de -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: 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: 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/
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:
6megaraid: 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 c=0 t=12
l=0
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 c=0 t=12
l=0Jan 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/
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
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.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.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
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
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.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.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-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: [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, 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: 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: 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: 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: 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: 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: 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/
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/
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
[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
[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] 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
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/
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 != _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 != + 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 != + 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 != _module) - set $mod = $mod->next +set $lmod = modules->next + set $mod = (struct module *)(((char *)$lmod) - ((int)&(((struct module *)0) -> list))) +while ($lmod != ) && ($mod != $arg0) +set $lmod = $lmod->next + set $mod = (struct module *)(((char *)$lmod) - ((int)&(((struct module *)0) -> list))) end -if $mod == _module - set $mod = 0 - printf "%p is not a module\n", $arg0 +if $lmod == + 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 alignment is 4. See mod-add-symbols-align. -end - -define mod-add-lis -mod-add-symbols-ali
[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: module-address module-name Use the module-address 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 module-path module-core +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 module-address Internal user-command used to validate the module parameter. -If module is a real loaded module, set $mod to it otherwise set $mod to 0. +If module 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 module-address -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 module-address object file path name align -Load the symbols table of the module from the object file where -first section aligment is align. -To retreive alignment, use `objdump -h object file path name'. +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 module-address object file path name -Load the symbols table of the module from the object file. -Default alignment is 4. See mod-add-symbols-align. -end - -define mod-add-lis -mod-add-symbols-align $arg0 /usr/src/LiS/streams.o 16 -end -document mod-add-lis -mod
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: 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: 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: 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: 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: 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: [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: 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: 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: [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: 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, 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/
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/
