Victor STANESCU-network administrator
The Numerical Methods Laboratory
Politehnica University of Bucharest
On Thu, 30 Dec 1999 owner-linux-kernel-digest@vger.rutgers.edu wrote:
>
> linux-kernel-digest Thursday, 30 December 1999 Volume 01 : Number 4988
>
> In this issue:
>
> Re: clock skew
> IDE multiwrite 2.3.35
> Re: 2.3.34 ide-cdrom error
> Problem compiling in 2.3.35
> [PATCH] x86 setup code cleanup.
> Re: gdth calls scsi_do_cmd() with an uninitialized Scsi_Device structure
> Re: Unexecutable Stack / Buffer Overflow Exploits...
> hda lost interrupt!
> Re: linux-kernel-digest V1 #4986
> Help me !!!!!
> Re: gdth calls scsi_do_cmd() with an uninitialized Scsi_Device structure
> Re: Unexecutable Stack / Buffer Overflow Exploits...
> dma timed out??
> PCI memory mapped I/O address
> Re: hda lost interrupt!
> Bug in tkparse or the Serial PCMCIA Config.in?
> More complete information regarding the Serial PCMCIA kconfig.tk problem.
> Help me !!!!!
> permissions for sockets
> ncr53c7,8xx broken with 2.3.35
> APIC error interrupt on CPU#0, should never happen. 2.3.35-pre6
> dosemu compile crashes with 2.3.3x
> Re: ext2: ls include/config/fb/aty.h : Input/Output error
> Re: Unexecutable Stack / Buffer Overflow Exploits...
> Re: dosemu compile crashes with 2.3.3x
> to CONFIG_KMOD or not to CONFIG_KMOD
> kernel_thread function
> RE: Unexecutable Stack / Buffer Overflow Exploits...
>
> See the end of the digest for information on subscribing to the linux-kernel
> or linux-kernel-digest mailing lists.
>
> ----------------------------------------------------------------------
>
> From: Scott Marlowe <smarlowe@ihs.com>
> Date: Wed, 29 Dec 1999 21:32:39 -0700 (MST)
> Subject: Re: clock skew
>
> On Mon, 27 Dec 1999, Robert Johannes wrote:
>
> > I was actually watching this with a kin eye, since I've the same problem;
> > I am curious to know what the fix was. Could you explain how you fixed
> > your drift? I mean, what did you exactly have to do?
>
> I've seen it on my RH 6.0 box with vanilla 2.2.12 kernel with dma turned on
> on the IDA drives. Chipset is the VIA MVP3. At work, same kernel, and RH
> 6.0, but with PIO access, I lose no time.
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Ted Sikora <tsikora@home.com>
> Date: Wed, 29 Dec 1999 23:37:59 -0500
> Subject: IDE multiwrite 2.3.35
>
> Excessive noise is enabled to get reports.
> Look for 2.3.36 to have all of this calmed down.
>
> Good news. The noise is driving me crazy.
>
> >
> > kernel: hdc: multwrite: count=2, current=0
> > last message repeated 12 times
> > kernel: hda: multwrite: count=2, current=0
>
> - --
> Ted Sikora
> Jtl Development Group
> tsikora@powerusersbbs.com
> http://powerusersbbs.com
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Ted Sikora <tsikora@home.com>
> Date: Wed, 29 Dec 1999 23:43:52 -0500
> Subject: Re: 2.3.34 ide-cdrom error
>
> Andre Hedrick wrote:
> >
> > That is because I have the noise level set high to figure out the final
> > design for the init process. It is obvious that I have a few adjustments
> > to make.
>
> No hurry. Just making sure your aware of all/any problems.
>
> >
> > On Thu, 23 Dec 1999, Ted Sikora wrote:
> >
> > > Following error still exists in 2.3.34 ide cdrom:
> > >
> > > hdc: ide_wait_noerr: status=0x51 { DriveReady SeekComplete Error }
> > > hdc: ide_wait_noerr: error=0x04
> > > hdc: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error
> > > }
> > > hdc: set_drive_speed_status: error=0x04
> > > hdc: ATAPI 5X CD-ROM drive, 240kB Cache
> > > Uniform CD-ROM driver Revision: 3.06
> > >
> > > 2.2.13/2.2.14pre.x kernels are fine.
> > >
> - --
> Ted Sikora
> Jtl Development Group
> tsikora@powerusersbbs.com
> http://powerusersbbs.com
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: riq <riq@ciudad.com.ar>
> Date: Thu, 30 Dec 1999 02:04:33 -0300
> Subject: Problem compiling in 2.3.35
>
> There is an error when compiling the v2.3.35 kernel
>
> In driver/net/zlib.c is using zlib (obvious)
> and in fs/cramfs/inflate/*.c is using zlib (again)
> so when compiling the kernel with net (zlib) and with cramfs
> there is a collision of objects ( both are exporting inflate_fast, etc).
>
> riq.
>
> - --
> Ricardo Calixto Quesada
> http://www.core-sdi.com
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Dave Jones <dave@denial.force9.co.uk>
> Date: Thu, 30 Dec 1999 03:45:01 +0000 (GMT)
> Subject: [PATCH] x86 setup code cleanup.
>
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
> Send mail to mime@docserver.cac.washington.edu for more info.
>
> - --279710208-1564925956-946525501=:1225
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Hi all,
> For review, here's a patch against arch/i386/kernel/setup.c from 2.3.35
>
> o Added intel_model()
> This makes identify_cpu() a more readable, and cuts out some
> checks for X86_VENDOR_INTEL
> o Improved Intel Celeron type identification
> Generated code should now do one less compare.
> [This code untested, Celeron owners, please check /proc/cpuinfo]
> o Intel Pentium 3 PSN uses a combined 'if' rather than two
> seperates.
> o identify_cpu() now uses a switch rather than lots of if's.
> Much more readable, and cleaner.
> o get_cpuinfo() now just checks the vendor, no longer the model.
> If a CPU doesn't support a feature, it won't get put into
> /proc/cpuinfo anyhow.
> o White space cleanup
>
> Comments?
>
>
> - --
> Dave..
>
> - --279710208-1564925956-946525501=:1225
> Content-Type: TEXT/PLAIN; charset=US-ASCII; name="setup.c.diff"
> Content-Transfer-Encoding: BASE64
> Content-ID: <Pine.LNX.4.21.9912300345010.1225@nemesis.local>
> Content-Description:
> Content-Disposition: attachment; filename="setup.c.diff"
>
> LS0tIHNldHVwLmMub3JpZwlXZWQgRGVjIDI5IDIyOjQ1OjIyIDE5OTkNCisr
> KyBzZXR1cC5jCVRodSBEZWMgMzAgMDE6NDA6NTEgMTk5OQ0KQEAgLTIwNCw3
> ICsyMDQsNyBAQA0KICAqLw0KIAlvdXRiX3AoU0lPX0RFVl9TRUwsIFNJT19J
> TkRFWCk7DQogCW91dGJfcChTSU9fR1BfREVWLCBTSU9fREFUQSk7CS8qIFRh
> bGsgdG8gR1BJTyByZWdzLiAqLw0KLSAgICANCisNCiAJb3V0Yl9wKFNJT19E
> RVZfTVNCLCBTSU9fSU5ERVgpOw0KIAlvdXRiX3AoU0lPX0dQX01TQiwgU0lP
> X0RBVEEpOwkvKiBNU0Igb2YgR1BJTyBiYXNlIGFkZHJlc3MgKi8NCiANCkBA
> IC0yMTMsNyArMjEzLDcgQEANCiANCiAJb3V0Yl9wKFNJT19ERVZfRU5CLCBT
> SU9fSU5ERVgpOw0KIAlvdXRiX3AoMSwgU0lPX0RBVEEpOwkJLyogRW5hYmxl
> IEdQSU8gcmVnaXN0ZXJzLiAqLw0KLSAgICANCisgDQogLyoNCiAgKiBOb3cs
> IHdlIGhhdmUgdG8gbWFwIHRoZSBwb3dlciBtYW5hZ2VtZW50IHNlY3Rpb24g
> dG8gd3JpdGUNCiAgKiBhIGJpdCB3aGljaCBlbmFibGVzIGFjY2VzcyB0byB0
> aGUgR1BJTyByZWdpc3RlcnMuDQpAQCAtMjI0LDE5ICsyMjQsMTkgQEANCiAN
> CiAJb3V0Yl9wKFNJT19ERVZfTVNCLCBTSU9fSU5ERVgpOw0KIAlvdXRiX3Ao
> U0lPX1BNX01TQiwgU0lPX0RBVEEpOwkvKiBNU0Igb2YgUE0gYmFzZSBhZGRy
> ZXNzICovDQotICAgIA0KKw0KIAlvdXRiX3AoU0lPX0RFVl9MU0IsIFNJT19J
> TkRFWCk7DQogCW91dGJfcChTSU9fUE1fTFNCLCBTSU9fREFUQSk7CS8qIExT
> QiBvZiBQTSBiYXNlIGFkZHJlc3MgKi8NCiANCiAJb3V0Yl9wKFNJT19ERVZf
> RU5CLCBTSU9fSU5ERVgpOw0KIAlvdXRiX3AoMSwgU0lPX0RBVEEpOwkJLyog
> RW5hYmxlIFBNIHJlZ2lzdGVycy4gKi8NCi0gICAgDQorDQogLyoNCiAgKiBO
> b3csIHdyaXRlIHRoZSBQTSByZWdpc3RlciB3aGljaCBlbmFibGVzIHRoZSBH
> UElPIHJlZ2lzdGVycy4NCiAgKi8NCiAJb3V0Yl9wKFNJT19QTV9GRVIyLCBT
> SU9fUE1fSU5ERVgpOw0KIAlvdXRiX3AoU0lPX1BNX0dQX0VOLCBTSU9fUE1f
> REFUQSk7DQotICAgIA0KKyANCiAvKg0KICAqIE5vdywgaW5pdGlhbGl6ZSB0
> aGUgR1BJTyByZWdpc3RlcnMuDQogICogV2Ugd2FudCB0aGVtIGFsbCB0byBi
> ZSBpbnB1dHMgd2hpY2ggaXMgdGhlDQpAQCAtMzgxLDEzICszODEsMTMgQEAN
> CiANCiANCiB2b2lkIF9faW5pdCBhZGRfbWVtb3J5X3JlZ2lvbih1bnNpZ25l
> ZCBsb25nIHN0YXJ0LA0KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
> ICAgICB1bnNpZ25lZCBsb25nIHNpemUsIGludCB0eXBlKQ0KKyAgICAgICAg
> ICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgc2l6ZSwgaW50
> IHR5cGUpDQogew0KIAlpbnQgeCA9IGU4MjAubnJfbWFwOw0KIA0KIAlpZiAo
> eCA9PSBFODIwTUFYKSB7DQotCSAgICBwcmludGsoIk9vb3BzISBUb28gbWFu
> eSBlbnRyaWVzIGluIHRoZSBtZW1vcnkgbWFwIVxuIik7DQotCSAgICByZXR1
> cm47DQorCQlwcmludGsoIk9vb3BzISBUb28gbWFueSBlbnRyaWVzIGluIHRo
> ZSBtZW1vcnkgbWFwIVxuIik7DQorCQlyZXR1cm47DQogCX0NCiANCiAJZTgy
> MC5tYXBbeF0uYWRkciA9IHN0YXJ0Ow0KQEAgLTcxOCw5ICs3MTgsOSBAQA0K
> IAkJfQ0KIAkJZWxzZSB7DQogCQkJcHJpbnRrKCJpbml0cmQgZXh0ZW5kcyBi
> ZXlvbmQgZW5kIG9mIG1lbW9yeSAiDQotCQkJICAgICIoMHglMDhseCA+IDB4
> JTA4bHgpXG5kaXNhYmxpbmcgaW5pdHJkXG4iLA0KLQkJCSAgICBJTklUUkRf
> U1RBUlQgKyBJTklUUkRfU0laRSwNCi0JCQkgICAgbWF4X2xvd19wZm4gPDwg
> UEFHRV9TSElGVCk7DQorCQkJCSIoMHglMDhseCA+IDB4JTA4bHgpXG5kaXNh
> YmxpbmcgaW5pdHJkXG4iLA0KKwkJCQlJTklUUkRfU1RBUlQgKyBJTklUUkRf
> U0laRSwNCisJCQkJbWF4X2xvd19wZm4gPDwgUEFHRV9TSElGVCk7DQogCQkJ
> aW5pdHJkX3N0YXJ0ID0gMDsNCiAJCX0NCiAJfQ0KQEAgLTg5MywxNiArODkz
> LDE2IEBADQogCWNsaSgpOw0KIAljY3IzID0gZ2V0Q3g4NihDWDg2X0NDUjMp
> Ow0KIAlzZXRDeDg2KENYODZfQ0NSMywgY2NyMyBeIDB4ODApOw0KLQlnZXRD
> eDg2KDB4YzApOyAgIC8qIGR1bW15IHRvIGNoYW5nZSBidXMgKi8NCisJZ2V0
> Q3g4NigweGMwKTsJLyogZHVtbXkgdG8gY2hhbmdlIGJ1cyAqLw0KIA0KLQlp
> ZiAoZ2V0Q3g4NihDWDg2X0NDUjMpID09IGNjcjMpIHsgICAgICAgLyogbm8g
> REVWSUQgcmVncy4gKi8NCisJaWYgKGdldEN4ODYoQ1g4Nl9DQ1IzKSA9PSBj
> Y3IzKSB7CS8qIG5vIERFVklEIHJlZ3MuICovDQogCQljY3IyID0gZ2V0Q3g4
> NihDWDg2X0NDUjIpOw0KIAkJc2V0Q3g4NihDWDg2X0NDUjIsIGNjcjIgXiAw
> eDA0KTsNCiAJCWdldEN4ODYoMHhjMCk7ICAvKiBkdW1teSAqLw0KIA0KIAkJ
> aWYgKGdldEN4ODYoQ1g4Nl9DQ1IyKSA9PSBjY3IyKSAvKiBvbGQgQ3g0ODZT
> TEMvRExDICovDQogCQkJKmRpcjAgPSAweGZkOw0KLQkJZWxzZSB7ICAgICAg
> ICAgICAgICAgICAgICAgICAgICAvKiBDeDQ4NlMgQSBzdGVwICovDQorCQll
> bHNlIHsJCQkJCQkJLyogQ3g0ODZTIEEgc3RlcCAqLw0KIAkJCXNldEN4ODYo
> Q1g4Nl9DQ1IyLCBjY3IyKTsNCiAJCQkqZGlyMCA9IDB4ZmU7DQogCQl9DQpA
> QCAtOTQ5LDggKzk0OSw4IEBADQogDQogCWRvX2N5cml4X2RldmlkKCZkaXIw
> LCAmZGlyMSk7DQogDQotCUN4ODZfZGlyMF9tc2IgPSBkaXIwX21zbiA9IGRp
> cjAgPj4gNDsgLyogaWRlbnRpZmllcyBDUFUgImZhbWlseSIgICAqLw0KLQlk
> aXIwX2xzbiA9IGRpcjAgJiAweGY7ICAgICAgICAgICAgICAgIC8qIG1vZGVs
> IG9yIGNsb2NrIG11bHRpcGxpZXIgKi8NCisJQ3g4Nl9kaXIwX21zYiA9IGRp
> cjBfbXNuID0gZGlyMCA+PiA0OyAvKiBpZGVudGlmaWVzIENQVSAiZmFtaWx5
> IgkqLw0KKwlkaXIwX2xzbiA9IGRpcjAgJiAweGY7CQkJCS8qIG1vZGVsIG9y
> IGNsb2NrIG11bHRpcGxpZXIgKi8NCiANCiAJLyogY29tbW9uIGNhc2Ugc3Rl
> cCBudW1iZXIvcmV2IC0tIGV4Y2VwdGlvbnMgaGFuZGxlZCBiZWxvdyAqLw0K
> IAljLT54ODZfbW9kZWwgPSAoZGlyMSA+PiA0KSArIDE7DQpAQCAtOTg2LDcg
> Kzk4Niw3IEBADQogCQkJQ3g4Nl9jYlswXSA9ICdMJzsNCiAJCQlwID0gQ3g4
> Nl9jYjsNCiAJCQkoYy0+eDg2X21vZGVsKSsrOw0KLQkJfSBlbHNlICAgICAg
> ICAgICAgIC8qIDY4NiAqLw0KKwkJfSBlbHNlCQkJCS8qIDY4NiAqLw0KIAkJ
> CXAgPSBDeDg2X2NiKzE7DQogCQkvKiBFbXVsYXRlIE1UUlJzIHVzaW5nIEN5
> cml4J3MgQVJScy4gKi8NCiAJCWMtPng4Nl9jYXBhYmlsaXR5IHw9IFg4Nl9G
> RUFUVVJFX01UUlI7DQpAQCAtMTAxNCw4ICsxMDE0LDcgQEANCiAJCQlnZXRf
> bW9kZWxfbmFtZShjKTsgIC8qIGdldCBDUFUgbWFya2V0aW5nIG5hbWUgKi8N
> CiAJCQljLT54ODZfY2FwYWJpbGl0eSY9flg4Nl9GRUFUVVJFX1RTQzsNCiAJ
> CQlyZXR1cm47DQotCQl9DQotCQllbHNlIHsgIC8qIE1lZGlhR1ggKi8NCisJ
> CX0gZWxzZSB7ICAvKiBNZWRpYUdYICovDQogCQkJQ3g4Nl9jYlsyXSA9IChk
> aXIwX2xzbiAmIDEpID8gJzMnIDogJzQnOw0KIAkJCXAgPSBDeDg2X2NiKzI7
> DQogCQkJYy0+eDg2X21vZGVsID0gKGRpcjEgJiAweDIwKSA/IDEgOiAyOw0K
> QEAgLTEwMjMsMTMgKzEwMjIsMTMgQEANCiAJCX0NCiAJCWJyZWFrOw0KIA0K
> LSAgICAgICAgY2FzZSA1OiAvKiA2eDg2TVgvTSBJSSAqLw0KLQkJaWYgKGRp
> cjEgPiA3KSBkaXIwX21zbisrOyAgLyogTSBJSSAqLw0KLQkJZWxzZSBjLT5j
> b21hX2J1ZyA9IDE7ICAgICAgLyogNng4Nk1YLCBpdCBoYXMgdGhlIGJ1Zy4g
> Ki8NCi0JCXRtcCA9ICghKGRpcjBfbHNuICYgNykgfHwgZGlyMF9sc24gJiAx
> KSA/IDIgOiAwOw0KKwljYXNlIDU6IC8qIDZ4ODZNWC9NIElJICovDQorCQlp
> ZiAoZGlyMSA+IDcpIGRpcjBfbXNuKys7CS8qIE0gSUkgKi8NCisJCWVsc2Ug
> Yy0+Y29tYV9idWcgPSAxOwkJLyogNng4Nk1YLCBpdCBoYXMgdGhlIGJ1Zy4g
> Ki8NCisJCQl0bXAgPSAoIShkaXIwX2xzbiAmIDcpIHx8IGRpcjBfbHNuICYg
> MSkgPyAyIDogMDsNCiAJCUN4ODZfY2JbdG1wXSA9IGN5cml4X21vZGVsX211
> bHQyW2RpcjBfbHNuICYgN107DQogCQlwID0gQ3g4Nl9jYit0bXA7DQotICAg
> ICAgICAJaWYgKCgoZGlyMSAmIDB4MGYpID4gNCkgfHwgKChkaXIxICYgMHhm
> MCkgPT0gMHgyMCkpDQorCQlpZiAoKChkaXIxICYgMHgwZikgPiA0KSB8fCAo
> KGRpcjEgJiAweGYwKSA9PSAweDIwKSkNCiAJCQkoYy0+eDg2X21vZGVsKSsr
> Ow0KIAkJLyogRW11bGF0ZSBNVFJScyB1c2luZyBDeXJpeCdzIEFSUnMuICov
> DQogCQljLT54ODZfY2FwYWJpbGl0eSB8PSBYODZfRkVBVFVSRV9NVFJSOw0K
> QEAgLTExNzksNzggKzExNzgsNTMgQEANCiBzdGF0aWMgc3RydWN0IGNwdV9t
> b2RlbF9pbmZvIGNwdV9tb2RlbHNbXSBfX2luaXRkYXRhID0gew0KIAl7IFg4
> Nl9WRU5ET1JfSU5URUwsCTQsDQogCSAgeyAiNDg2IERYLTI1LzMzIiwgIjQ4
> NiBEWC01MCIsICI0ODYgU1giLCAiNDg2IERYLzIiLCAiNDg2IFNMIiwgDQot
> CSAgICAiNDg2IFNYLzIiLCBOVUxMLCAiNDg2IERYLzItV0IiLCAiNDg2IERY
> LzQiLCAiNDg2IERYLzQtV0IiLCBOVUxMLCANCi0JICAgIE5VTEwsIE5VTEws
> IE5VTEwsIE5VTEwsIE5VTEwgfX0sDQorCQkiNDg2IFNYLzIiLCBOVUxMLCAi
> NDg2IERYLzItV0IiLCAiNDg2IERYLzQiLCAiNDg2IERYLzQtV0IiLCBOVUxM
> LCANCisJCU5VTEwsIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwgfX0sDQogCXsg
> WDg2X1ZFTkRPUl9JTlRFTCwJNSwNCiAJICB7ICJQZW50aXVtIDYwLzY2IEEt
> c3RlcCIsICJQZW50aXVtIDYwLzY2IiwgIlBlbnRpdW0gNzUgLSAyMDAiLA0K
> LQkgICAgIk92ZXJEcml2ZSBQT0RQNVY4MyIsICJQZW50aXVtIE1NWCIsIE5V
> TEwsIE5VTEwsDQotCSAgICAiTW9iaWxlIFBlbnRpdW0gNzUgLSAyMDAiLCAi
> TW9iaWxlIFBlbnRpdW0gTU1YIiwgTlVMTCwgTlVMTCwgTlVMTCwNCi0JICAg
> IE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwgfX0sDQorCQkiT3ZlckRyaXZlIFBP
> RFA1VjgzIiwgIlBlbnRpdW0gTU1YIiwgTlVMTCwgTlVMTCwNCisJCSJNb2Jp
> bGUgUGVudGl1bSA3NSAtIDIwMCIsICJNb2JpbGUgUGVudGl1bSBNTVgiLCBO
> VUxMLCBOVUxMLCBOVUxMLA0KKwkJTlVMTCwgTlVMTCwgTlVMTCwgTlVMTCB9
> fSwNCiAJeyBYODZfVkVORE9SX0lOVEVMLAk2LA0KIAkgIHsgIlBlbnRpdW0g
> UHJvIEEtc3RlcCIsICJQZW50aXVtIFBybyIsIE5VTEwsICJQZW50aXVtIElJ
> IChLbGFtYXRoKSIsIA0KLQkgICAgTlVMTCwgIlBlbnRpdW0gSUkgKERlc2No
> dXRlcykiLCAiTW9iaWxlIFBlbnRpdW0gSUkiLCAiUGVudGl1bSBJSUkgKEth
> dG1haSkiLA0KLQkgICAgIlBlbnRpdW0gSUlJIChDb3BwZXJtaW5lKSIsIE5V
> TEwsIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwgfX0sDQorCQlOVUxM
> LCAiUGVudGl1bSBJSSAoRGVzY2h1dGVzKSIsICJNb2JpbGUgUGVudGl1bSBJ
> SSIsICJQZW50aXVtIElJSSAoS2F0bWFpKSIsDQorCQkiUGVudGl1bSBJSUkg
> KENvcHBlcm1pbmUpIiwgTlVMTCwgTlVMTCwgTlVMTCwgTlVMTCwgTlVMTCwg
> TlVMTCB9fSwNCiAJeyBYODZfVkVORE9SX0FNRCwJNCwNCiAJICB7IE5VTEws
> IE5VTEwsIE5VTEwsICI0ODYgRFgvMiIsIE5VTEwsIE5VTEwsIE5VTEwsICI0
> ODYgRFgvMi1XQiIsDQotCSAgICAiNDg2IERYLzQiLCAiNDg2IERYLzQtV0Ii
> LCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLCAiQW01eDg2LVdUIiwNCi0JICAg
> ICJBbTV4ODYtV0IiIH19LA0KKwkJIjQ4NiBEWC80IiwgIjQ4NiBEWC80LVdC
> IiwgTlVMTCwgTlVMTCwgTlVMTCwgTlVMTCwgIkFtNXg4Ni1XVCIsDQorCQki
> QW01eDg2LVdCIiB9fSwNCiAJeyBYODZfVkVORE9SX0FNRCwJNSwNCiAJICB7
> ICJLNS9TU0E1IiwgIks1IiwNCi0JICAgICJLNSIsICJLNSIsIE5VTEwsIE5V
> TEwsDQotCSAgICAiSzYiLCAiSzYiLCAiSzYtMiIsDQotCSAgICAiSzYtMyIs
> IE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwgfX0sDQorCQki
> SzUiLCAiSzUiLCBOVUxMLCBOVUxMLA0KKwkJIks2IiwgIks2IiwgIks2LTIi
> LA0KKwkJIks2LTMiLCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLCBO
> VUxMIH19LA0KIAl7IFg4Nl9WRU5ET1JfQU1ELAk2LA0KIAkgIHsgIkF0aGxv
> biIsICJBdGhsb24iLA0KLQkgICAgTlVMTCwgTlVMTCwgTlVMTCwgTlVMTCwN
> Ci0JICAgIE5VTEwsIE5VTEwsIE5VTEwsDQotCSAgICBOVUxMLCBOVUxMLCBO
> VUxMLCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMIH19LA0KKwkJTlVMTCwgTlVM
> TCwgTlVMTCwgTlVMTCwNCisJCU5VTEwsIE5VTEwsIE5VTEwsDQorCQlOVUxM
> LCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMIH19LA0KIAl7
> IFg4Nl9WRU5ET1JfVU1DLAk0LA0KIAkgIHsgTlVMTCwgIlU1RCIsICJVNVMi
> LCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLA0K
> LQkgICAgTlVMTCwgTlVMTCwgTlVMTCwgTlVMTCwgTlVMTCwgTlVMTCB9fSwN
> CisJCU5VTEwsIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwgfX0sDQog
> CXsgWDg2X1ZFTkRPUl9ORVhHRU4sCTUsDQogCSAgeyAiTng1ODYiLCBOVUxM
> LCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLA0K
> LQkgICAgTlVMTCwgTlVMTCwgTlVMTCwgTlVMTCwgTlVMTCwgTlVMTCwgTlVM
> TCB9fSwNCisJCU5VTEwsIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEws
> IE5VTEwgfX0sDQogfTsNCiANCi12b2lkIF9faW5pdCBpZGVudGlmeV9jcHUo
> c3RydWN0IGNwdWluZm9feDg2ICpjKQ0KKw0KK3N0YXRpYyB2b2lkIF9faW5p
> dCBpbnRlbF9tb2RlbChzdHJ1Y3QgY3B1aW5mb194ODYgKmMpDQogew0KIAlp
> bnQgaTsNCiAJY2hhciAqcCA9IE5VTEw7DQogDQotCWMtPmxvb3BzX3Blcl9z
> ZWMgPSBsb29wc19wZXJfc2VjOw0KLQljLT54ODZfY2FjaGVfc2l6ZSA9IC0x
> Ow0KLQ0KLQlnZXRfY3B1X3ZlbmRvcihjKTsNCi0NCi0JaWYgKGMtPng4Nl92
> ZW5kb3IgPT0gWDg2X1ZFTkRPUl9VTktOT1dOICYmDQotCSAgICBjLT5jcHVp
> ZF9sZXZlbCA8IDApDQotCQlyZXR1cm47DQotDQotCWlmIChjLT54ODZfdmVu
> ZG9yID09IFg4Nl9WRU5ET1JfQ1lSSVgpIHsNCi0JCWN5cml4X21vZGVsKGMp
> Ow0KLQkJcmV0dXJuOw0KLQl9DQotDQotCWlmIChjLT54ODZfdmVuZG9yID09
> IFg4Nl9WRU5ET1JfQU1EICYmIGFtZF9tb2RlbChjKSkNCi0JCXJldHVybjsN
> Ci0NCi0JaWYgKGMtPng4Nl92ZW5kb3IgPT0gWDg2X1ZFTkRPUl9DRU5UQVVS
> KSB7DQotCQljZW50YXVyX21vZGVsKGMpOw0KLQkJcmV0dXJuOw0KLQl9DQot
> CQkNCi0JaWYgKGMtPmNwdWlkX2xldmVsID4gMCAmJiBjLT54ODZfdmVuZG9y
> ID09IFg4Nl9WRU5ET1JfSU5URUwpDQotCXsNCi0JCWlmKGMtPng4Nl9jYXBh
> YmlsaXR5JigxPDwxOCkpDQotCQl7DQotCQkJLyogRGlzYWJsZSBwcm9jZXNz
> b3Igc2VyaWFsIG51bWJlciBvbiBJbnRlbCBQZW50aXVtIElJSSANCi0JCQkg
> ICBmcm9tIGNvZGUgYnkgUGhpbCBLYXJuICovDQotCQkJdW5zaWduZWQgbG9u
> ZyBsbyxoaTsNCi0JCQlyZG1zcigweDExOSxsbyxoaSk7DQotCQkJbG8gfD0g
> MHgyMDAwMDA7DQotCQkJd3Jtc3IoMHgxMTksbG8saGkpOw0KLQkJCXByaW50
> ayhLRVJOX0lORk8gIlBlbnRpdW0tSUlJIHNlcmlhbCBudW1iZXIgZGlzYWJs
> ZWQuXG4iKTsNCi0JCX0NCisJaWYgKGMtPmNwdWlkX2xldmVsID4gMCAmJiBj
> LT54ODZfY2FwYWJpbGl0eSYoMTw8MTgpKSB7DQorCQkvKiBEaXNhYmxlIHBy
> b2Nlc3NvciBzZXJpYWwgbnVtYmVyIG9uIEludGVsIFBlbnRpdW0gSUlJIA0K
> KwkJICAgZnJvbSBjb2RlIGJ5IFBoaWwgS2FybiAqLw0KKwkJdW5zaWduZWQg
> bG9uZyBsbyxoaTsNCisJCXJkbXNyKDB4MTE5LGxvLGhpKTsNCisJCWxvIHw9
> IDB4MjAwMDAwOw0KKwkJd3Jtc3IoMHgxMTksbG8saGkpOw0KKwkJcHJpbnRr
> KEtFUk5fSU5GTyAiUGVudGl1bS1JSUkgc2VyaWFsIG51bWJlciBkaXNhYmxl
> ZC5cbiIpOw0KIAl9DQogDQogCWlmIChjLT5jcHVpZF9sZXZlbCA+IDEpIHsN
> CkBAIC0xMjk2LDIxICsxMjcwLDIxIEBADQogDQogCWZvciAoaSA9IDA7IGkg
> PCBzaXplb2YoY3B1X21vZGVscykvc2l6ZW9mKHN0cnVjdCBjcHVfbW9kZWxf
> aW5mbyk7IGkrKykgew0KIAkJaWYgKGNwdV9tb2RlbHNbaV0udmVuZG9yID09
> IGMtPng4Nl92ZW5kb3IgJiYNCi0JCSAgICBjcHVfbW9kZWxzW2ldLng4NiA9
> PSBjLT54ODYpIHsNCisJCQljcHVfbW9kZWxzW2ldLng4NiA9PSBjLT54ODYp
> IHsNCiAJCQlpZiAoYy0+eDg2X21vZGVsIDw9IDE2KQ0KIAkJCQlwID0gY3B1
> X21vZGVsc1tpXS5tb2RlbF9uYW1lc1tjLT54ODZfbW9kZWxdOw0KIA0KIAkJ
> CS8qIE5hbWVzIGZvciB0aGUgUGVudGl1bSBJSSBDZWxlcm9uIHByb2Nlc3Nv
> cnMgDQotICAgICAgICAgICAgICAgICAgICAgICAgICAgZGV0ZWN0YWJsZSBv
> bmx5IGJ5IGFsc28gY2hlY2tpbmcgdGhlIGNhY2hlIHNpemUgKi8NCi0JCQlp
> ZiAoKGNwdV9tb2RlbHNbaV0udmVuZG9yID09IFg4Nl9WRU5ET1JfSU5URUwp
> DQotCQkJICAgICYmIChjcHVfbW9kZWxzW2ldLng4NiA9PSA2KSkNCi0JCQl7
> DQotCQkJIAlpZihjLT54ODZfbW9kZWwgPT0gNSAmJiAgYy0+eDg2X2NhY2hl
> X3NpemUgPT0gMCkNCi0JCQkJCXAgPSAiQ2VsZXJvbiAoQ292aW5ndG9uKSI7
> CQkJCQkJDQotCQkJCWVsc2UgaWYoYy0+eDg2X21vZGVsID09IDYgJiYgYy0+
> eDg2X2NhY2hlX3NpemUgPT0gMTI4KQ0KLSAgICAgICAgICAgICAgICAgICAg
> ICAgICAgICAJCXAgPSAiQ2VsZXJvbiAoTWVuZG9jaW5vKSI7IA0KLSAJCQkg
> IAllbHNlIGlmKGMtPng4Nl9tb2RlbCA9PSA1ICYmIGMtPng4Nl9jYWNoZV9z
> aXplID09IDI1NikNCi0JCQkJCXAgPSAiQ2VsZXJvbiAoRGl4b24pIjsNCisJ
> CQkgICBkZXRlY3RhYmxlIG9ubHkgYnkgYWxzbyBjaGVja2luZyB0aGUgY2Fj
> aGUgc2l6ZSAqLw0KKwkJCWlmIChjcHVfbW9kZWxzW2ldLng4NiA9PSA2KSB7
> DQorCQkJCWlmIChjLT54ODZfbW9kZWwgPT0gNSkgew0KKwkJCQkJaWYgKGMt
> Png4Nl9jYWNoZV9zaXplPT0wKQ0KKwkJCQkJCXAgPSAiQ2VsZXJvbiAoQ292
> aW5ndG9uKSI7DQorCQkJCQlpZiAoYy0+eDg2X2NhY2hlX3NpemU9PTI1NikN
> CisJCQkJCQlwID0gIkNlbGVyb24gKERpeG9uKSI7DQorCQkJCX0NCisJCQkJ
> aWYgKGMtPng4Nl9tb2RlbCA9PSA2ICYmIGMtPng4Nl9jYWNoZV9zaXplID09
> IDEyOCkNCisJCQkJCXAgPSAiQ2VsZXJvbiAoTWVuZG9jaW5vKSI7DQogCQkJ
> fQ0KIAkJfQ0KIAl9DQpAQCAtMTMyMyw2ICsxMjk3LDM4IEBADQogCXNwcmlu
> dGYoYy0+eDg2X21vZGVsX2lkLCAiJTAyeC8lMDJ4IiwgYy0+eDg2X3ZlbmRv
> ciwgYy0+eDg2X21vZGVsKTsNCiB9DQogDQorDQordm9pZCBfX2luaXQgaWRl
> bnRpZnlfY3B1KHN0cnVjdCBjcHVpbmZvX3g4NiAqYykNCit7DQorCWMtPmxv
> b3BzX3Blcl9zZWMgPSBsb29wc19wZXJfc2VjOw0KKwljLT54ODZfY2FjaGVf
> c2l6ZSA9IC0xOw0KKw0KKwlnZXRfY3B1X3ZlbmRvcihjKTsNCisNCisJc3dp
> dGNoIChjLT54ODZfdmVuZG9yKSB7DQorCQljYXNlIFg4Nl9WRU5ET1JfVU5L
> Tk9XTjoNCisJCQlicmVhazsNCisNCisJCWNhc2UgWDg2X1ZFTkRPUl9JTlRF
> TDoNCisJCQlpbnRlbF9tb2RlbChjKTsNCisJCQlicmVhazsNCisNCisJCWNh
> c2UgWDg2X1ZFTkRPUl9DWVJJWDoNCisJCQljeXJpeF9tb2RlbChjKTsNCisJ
> CQlicmVhazsNCisNCisJCWNhc2UgWDg2X1ZFTkRPUl9BTUQ6DQorCQkJYW1k
> X21vZGVsKGMpOw0KKwkJCWJyZWFrOw0KKw0KKwkJY2FzZSBYODZfVkVORE9S
> X0NFTlRBVVI6DQorCQkJY2VudGF1cl9tb2RlbChjKTsNCisJCQlicmVhazsN
> CisJfQ0KKwlyZXR1cm47DQorfQ0KKw0KKw0KIC8qDQogICoJUGVyZm9ybSBl
> YXJseSBib290IHVwIGNoZWNrcyBmb3IgYSB2YWxpZCBUU0MuIFNlZSBhcmNo
> L2kzODYva2VybmVsL3RpbWUuYw0KICAqLw0KQEAgLTEzMzIsOSArMTMzOCw3
> IEBADQogCWdldF9jcHVfdmVuZG9yKCZib290X2NwdV9kYXRhKTsNCiAJDQog
> CWlmKGJvb3RfY3B1X2RhdGEueDg2X3ZlbmRvciAhPSBYODZfVkVORE9SX0NZ
> UklYKQ0KLQl7DQogCQlyZXR1cm47DQotCX0NCiAJY3lyaXhfbW9kZWwoJmJv
> b3RfY3B1X2RhdGEpOw0KIH0NCiAJDQpAQCAtMTM3NCwxMCArMTM3OCwxMCBA
> QA0KIAljaGFyICpwID0gYnVmZmVyOw0KIAlpbnQgc2VwX2J1ZzsNCiAJc3Rh
> dGljIGNoYXIgKng4Nl9jYXBfZmxhZ3NbXSA9IHsNCi0JICAgICAgICAiZnB1
> IiwgInZtZSIsICJkZSIsICJwc2UiLCAidHNjIiwgIm1zciIsICJwYWUiLCAi
> bWNlIiwNCi0JICAgICAgICAiY3g4IiwgImFwaWMiLCAiMTAiLCAic2VwIiwg
> Im10cnIiLCAicGdlIiwgIm1jYSIsICJjbW92IiwNCi0JICAgICAgICAicGF0
> IiwgIjE3IiwgInBzbiIsICIxOSIsICIyMCIsICIyMSIsICIyMiIsICJtbXgi
> LA0KLQkgICAgICAgICIyNCIsICJrbmkiLCAiMjYiLCAiMjciLCAiMjgiLCAi
> MjkiLCAiMzAiLCAiMzEiDQorCQkiZnB1IiwgInZtZSIsICJkZSIsICJwc2Ui
> LCAidHNjIiwgIm1zciIsICJwYWUiLCAibWNlIiwNCisJCSJjeDgiLCAiYXBp
> YyIsICIxMCIsICJzZXAiLCAibXRyciIsICJwZ2UiLCAibWNhIiwgImNtb3Yi
> LA0KKwkJInBhdCIsICIxNyIsICJwc24iLCAiMTkiLCAiMjAiLCAiMjEiLCAi
> MjIiLCAibW14IiwNCisJCSIyNCIsICJrbmkiLCAiMjYiLCAiMjciLCAiMjgi
> LCAiMjkiLCAiMzAiLCAiMzEiDQogCX07DQogCXN0cnVjdCBjcHVpbmZvX3g4
> NiAqYyA9IGNwdV9kYXRhOw0KIAlpbnQgaSwgbjsNCkBAIC0xMzg4LDE1ICsx
> MzkyLDE1IEBADQogCQkJY29udGludWU7DQogI2VuZGlmDQogCQlwICs9IHNw
> cmludGYocCwicHJvY2Vzc29yXHQ6ICVkXG4iDQotCQkJICAgICAgICJ2ZW5k
> b3JfaWRcdDogJXNcbiINCi0JCQkgICAgICAgImNwdSBmYW1pbHlcdDogJWNc
> biINCi0JCQkgICAgICAgIm1vZGVsXHRcdDogJWRcbiINCi0JCQkgICAgICAg
> Im1vZGVsIG5hbWVcdDogJXNcbiIsDQotCQkJICAgICAgIG4sDQotCQkJICAg
> ICAgIGMtPng4Nl92ZW5kb3JfaWRbMF0gPyBjLT54ODZfdmVuZG9yX2lkIDog
> InVua25vd24iLA0KLQkJCSAgICAgICBjLT54ODYgKyAnMCcsDQotCQkJICAg
> ICAgIGMtPng4Nl9tb2RlbCwNCi0JCQkgICAgICAgYy0+eDg2X21vZGVsX2lk
> WzBdID8gYy0+eDg2X21vZGVsX2lkIDogInVua25vd24iKTsNCisJCQkidmVu
> ZG9yX2lkXHQ6ICVzXG4iDQorCQkJImNwdSBmYW1pbHlcdDogJWNcbiINCisJ
> CQkibW9kZWxcdFx0OiAlZFxuIg0KKwkJCSJtb2RlbCBuYW1lXHQ6ICVzXG4i
> LA0KKwkJCW4sDQorCQkJYy0+eDg2X3ZlbmRvcl9pZFswXSA/IGMtPng4Nl92
> ZW5kb3JfaWQgOiAidW5rbm93biIsDQorCQkJYy0+eDg2ICsgJzAnLA0KKwkJ
> CWMtPng4Nl9tb2RlbCwNCisJCQljLT54ODZfbW9kZWxfaWRbMF0gPyBjLT54
> ODZfbW9kZWxfaWQgOiAidW5rbm93biIpOw0KIA0KIAkJaWYgKGMtPng4Nl9t
> YXNrIHx8IGMtPmNwdWlkX2xldmVsID49IDApDQogCQkJcCArPSBzcHJpbnRm
> KHAsICJzdGVwcGluZ1x0OiAlZFxuIiwgYy0+eDg2X21hc2spOw0KQEAgLTE0
> MTEsMzggKzE0MTUsMzUgQEANCiAJCS8qIENhY2hlIHNpemUgKi8NCiAJCWlm
> IChjLT54ODZfY2FjaGVfc2l6ZSA+PSAwKQ0KIAkJCXAgKz0gc3ByaW50Zihw
> LCAiY2FjaGUgc2l6ZVx0OiAlZCBLQlxuIiwgYy0+eDg2X2NhY2hlX3NpemUp
> Ow0KLQkJDQorDQogCQkvKiBNb2RpZnkgdGhlIGNhcGFiaWxpdGllcyBhY2Nv
> cmRpbmcgdG8gY2hpcCB0eXBlICovDQogCQlzd2l0Y2ggKGMtPng4Nl92ZW5k
> b3IpIHsNCiANCi0JCSAgICBjYXNlIFg4Nl9WRU5ET1JfQ1lSSVg6DQotCQkJ
> eDg2X2NhcF9mbGFnc1syNF0gPSAiY3htbXgiOw0KLQkJCWJyZWFrOw0KKwkJ
> CWNhc2UgWDg2X1ZFTkRPUl9DWVJJWDoNCisJCQkJeDg2X2NhcF9mbGFnc1sy
> NF0gPSAiY3htbXgiOw0KKwkJCQlicmVhazsNCiANCi0JCSAgICBjYXNlIFg4
> Nl9WRU5ET1JfQU1EOg0KLQkJCWlmIChjLT54ODYgPT0gNSAmJiBjLT54ODZf
> bW9kZWwgPT0gNikNCisJCQljYXNlIFg4Nl9WRU5ET1JfQU1EOg0KIAkJCQl4
> ODZfY2FwX2ZsYWdzWzEwXSA9ICJzZXAiOw0KLQkJCWlmIChjLT54ODYgPCA2
> KQ0KIAkJCQl4ODZfY2FwX2ZsYWdzWzE2XSA9ICJmY21vdiI7DQotCQkJeDg2
> X2NhcF9mbGFnc1syMl0gPSAibW14ZXh0IjsNCi0JCQl4ODZfY2FwX2ZsYWdz
> WzMwXSA9ICIzZG5vd2V4dCI7DQotCQkJeDg2X2NhcF9mbGFnc1szMV0gPSAi
> M2Rub3ciOw0KLQkJCWJyZWFrOw0KKwkJCQl4ODZfY2FwX2ZsYWdzWzIyXSA9
> ICJtbXhleHQiOw0KKwkJCQl4ODZfY2FwX2ZsYWdzWzMwXSA9ICIzZG5vd2V4
> dCI7DQorCQkJCXg4Nl9jYXBfZmxhZ3NbMzFdID0gIjNkbm93IjsNCisJCQkJ
> YnJlYWs7DQogDQotCQkgICAgY2FzZSBYODZfVkVORE9SX0lOVEVMOg0KLQkJ
> CXg4Nl9jYXBfZmxhZ3NbMTddID0gInBzZTM2IjsNCi0JCQl4ODZfY2FwX2Zs
> YWdzWzE4XSA9ICJwc24iOw0KLQkJCXg4Nl9jYXBfZmxhZ3NbMjRdID0gIm9z
> ZnhzciI7DQotCQkJYnJlYWs7DQorCQkJY2FzZSBYODZfVkVORE9SX0lOVEVM
> Og0KKwkJCQl4ODZfY2FwX2ZsYWdzWzE3XSA9ICJwc2UzNiI7DQorCQkJCXg4
> Nl9jYXBfZmxhZ3NbMThdID0gInBzbiI7DQorCQkJCXg4Nl9jYXBfZmxhZ3Nb
> MjRdID0gIm9zZnhzciI7DQorCQkJCWJyZWFrOw0KIA0KLQkJICAgIGNhc2Ug
> WDg2X1ZFTkRPUl9DRU5UQVVSOg0KLQkJCWlmIChjLT54ODZfbW9kZWwgPj04
> KQkvKiBPbmx5IFdpbmNoaXAyIGFuZCBhYm92ZSAqLw0KLQkJCSAgICB4ODZf
> Y2FwX2ZsYWdzWzMxXSA9ICIzZG5vdyI7DQotCQkJYnJlYWs7DQorCQkJY2Fz
> ZSBYODZfVkVORE9SX0NFTlRBVVI6DQorCQkJCXg4Nl9jYXBfZmxhZ3NbMzFd
> ID0gIjNkbm93IjsNCisJCQkJYnJlYWs7DQogDQotCQkgICAgZGVmYXVsdDoN
> Ci0JCQkvKiBVbmtub3duIENQVSBtYW51ZmFjdHVyZXIuIFRyYW5zbWV0YSA/
> IDotKSAqLw0KLQkJCWJyZWFrOw0KKwkJCWRlZmF1bHQ6DQorCQkJCS8qIFVu
> a25vd24gQ1BVIG1hbnVmYWN0dXJlci4gVHJhbnNtZXRhID8gOi0pICovDQor
> CQkJCWJyZWFrOw0KIAkJfQ0KIA0KIAkJc2VwX2J1ZyA9IGMtPng4Nl92ZW5k
> b3IgPT0gWDg2X1ZFTkRPUl9JTlRFTCAmJg0KQEAgLTE0NTMsMzEgKzE0NTQs
> MzEgQEANCiAJCQkgIGMtPng4Nl9tYXNrIDwgMzsNCiAJDQogCQlwICs9IHNw
> cmludGYocCwgImZkaXZfYnVnXHQ6ICVzXG4iDQotCQkJICAgICAgICAiaGx0
> X2J1Z1x0XHQ6ICVzXG4iDQotCQkJICAgICAgICAic2VwX2J1Z1x0XHQ6ICVz
> XG4iDQotCQkJICAgICAgICAiZjAwZl9idWdcdDogJXNcbiINCi0JCQkgICAg
> ICAgICJjb21hX2J1Z1x0OiAlc1xuIg0KLQkJCSAgICAgICAgImZwdVx0XHQ6
> ICVzXG4iDQotCQkJICAgICAgICAiZnB1X2V4Y2VwdGlvblx0OiAlc1xuIg0K
> LQkJCSAgICAgICAgImNwdWlkIGxldmVsXHQ6ICVkXG4iDQotCQkJICAgICAg
> ICAid3BcdFx0OiAlc1xuIg0KLQkJCSAgICAgICAgImZsYWdzXHRcdDoiLA0K
> LQkJCSAgICAgYy0+ZmRpdl9idWcgPyAieWVzIiA6ICJubyIsDQotCQkJICAg
> ICBjLT5obHRfd29ya3Nfb2sgPyAibm8iIDogInllcyIsDQotCQkJICAgICBz
> ZXBfYnVnID8gInllcyIgOiAibm8iLA0KLQkJCSAgICAgYy0+ZjAwZl9idWcg
> PyAieWVzIiA6ICJubyIsDQotCQkJICAgICBjLT5jb21hX2J1ZyA/ICJ5ZXMi
> IDogIm5vIiwNCi0JCQkgICAgIGMtPmhhcmRfbWF0aCA/ICJ5ZXMiIDogIm5v
> IiwNCi0JCQkgICAgIChjLT5oYXJkX21hdGggJiYgaWdub3JlX2lycTEzKSA/
> ICJ5ZXMiIDogIm5vIiwNCi0JCQkgICAgIGMtPmNwdWlkX2xldmVsLA0KLQkJ
> CSAgICAgYy0+d3Bfd29ya3Nfb2sgPyAieWVzIiA6ICJubyIpOw0KKwkJCSJo
> bHRfYnVnXHRcdDogJXNcbiINCisJCQkic2VwX2J1Z1x0XHQ6ICVzXG4iDQor
> CQkJImYwMGZfYnVnXHQ6ICVzXG4iDQorCQkJImNvbWFfYnVnXHQ6ICVzXG4i
> DQorCQkJImZwdVx0XHQ6ICVzXG4iDQorCQkJImZwdV9leGNlcHRpb25cdDog
> JXNcbiINCisJCQkiY3B1aWQgbGV2ZWxcdDogJWRcbiINCisJCQkid3BcdFx0
> OiAlc1xuIg0KKwkJCSJmbGFnc1x0XHQ6IiwNCisJCQljLT5mZGl2X2J1ZyA/
> ICJ5ZXMiIDogIm5vIiwNCisJCQljLT5obHRfd29ya3Nfb2sgPyAibm8iIDog
> InllcyIsDQorCQkJc2VwX2J1ZyA/ICJ5ZXMiIDogIm5vIiwNCisJCQljLT5m
> MDBmX2J1ZyA/ICJ5ZXMiIDogIm5vIiwNCisJCQljLT5jb21hX2J1ZyA/ICJ5
> ZXMiIDogIm5vIiwNCisJCQljLT5oYXJkX21hdGggPyAieWVzIiA6ICJubyIs
> DQorCQkJKGMtPmhhcmRfbWF0aCAmJiBpZ25vcmVfaXJxMTMpID8gInllcyIg
> OiAibm8iLA0KKwkJCWMtPmNwdWlkX2xldmVsLA0KKwkJCWMtPndwX3dvcmtz
> X29rID8gInllcyIgOiAibm8iKTsNCiANCiAJCWZvciAoIGkgPSAwIDsgaSA8
> IDMyIDsgaSsrICkNCiAJCQlpZiAoIGMtPng4Nl9jYXBhYmlsaXR5ICYgKDEg
> PDwgaSkgKQ0KIAkJCQlwICs9IHNwcmludGYocCwgIiAlcyIsIHg4Nl9jYXBf
> ZmxhZ3NbaV0pOw0KIAkJcCArPSBzcHJpbnRmKHAsICJcbmJvZ29taXBzXHQ6
> ICVsdS4lMDJsdVxuXG4iLA0KLQkJCSAgICAgKGMtPmxvb3BzX3Blcl9zZWMr
> MjUwMCkvNTAwMDAwLA0KLQkJCSAgICAgKChjLT5sb29wc19wZXJfc2VjKzI1
> MDApLzUwMDApICUgMTAwKTsNCisJCQkoYy0+bG9vcHNfcGVyX3NlYysyNTAw
> KS81MDAwMDAsDQorCQkJCSgoYy0+bG9vcHNfcGVyX3NlYysyNTAwKS81MDAw
> KSAlIDEwMCk7DQogCX0NCiAJcmV0dXJuIHAgLSBidWZmZXI7DQogfQ0K
> - --279710208-1564925956-946525501=:1225--
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Eric Youngdale <eric@andante.org>
> Date: Thu, 30 Dec 1999 00:07:07 -0500 (EST)
> Subject: Re: gdth calls scsi_do_cmd() with an uninitialized Scsi_Device structure
>
> I took a quick look. Let me say to start, that it is really gross
> to be attempting to put together a phony Scsi_Device and Scsi_Cmnd, just
> so that you can queue a command to the host adapter itself. I would like
> it if there were another way of accomplishing the same thing without
> getting the mid-layer into the mix. If there were a general need for
> queueing commands to the SCSI ID for the HA itself, then I could
> incorporate something, but as far as I can see gdth is the only driver
> doing this.
>
> Anyways, the quick fix for your case is probably to add a couple
> of quick calls along the lines of:
>
> blk_init_queue(&SDpnt->request_queue, scsi_request_fn);
> SDpnt->request_queue.queuedata = (void *) SDpnt;
>
> initialize_merge_fn(SDpnt);
>
> If you go the quick fix route, PLEASE add a fixme comment to clean
> this up at a later date. Once you are done with the command, you should
> call:
>
> blk_cleanup_queue(&SDpnt->request_queue);
>
> At the moment this doesn't do that much, but at some point in the future
> it might do more, and you might as well add it for correctness.
>
> As long as you are at it, I am slowly in the process of
> eliminating scsi_init_malloc/scsi_init_free. These calls can be replaced
> with either kmalloc()/kfree(), or with __get_free_pages()/free_pages(). It
> depends upon whether you are allocating a multiple of a page size or not.
> The only tricky thing is that scsi_init_malloc does memset the memory to
> 0, so you would need to check and see if you need to do this. Anyways,
> gdth.c uses these interfaces, and it was kind of low on my list of things
> to do to fix this as well.
>
> - -Eric
>
> "The world was a library, and its books were the stones, leaves,
> brooks, grass, and the birds of the earth. We learned to do what only
> a student of nature ever learns, and that was to feel beauty."
> Chief Luther Standing Bear - Teton Sioux
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Robert Dinse <nanook@eskimo.com>
> Date: Wed, 29 Dec 1999 21:18:04 -0800 (PST)
> Subject: Re: Unexecutable Stack / Buffer Overflow Exploits...
>
> On Thu, 30 Dec 1999, Damien Miller wrote:
> >
> > Date: Thu, 30 Dec 1999 15:10:41 +1100 (EST)
> > From: Damien Miller <djm@mindrot.org>
> > To: Gregory Maxwell <greg@linuxpower.cx>
> > Cc: Horst von Brand <vonbrand@pincoya.inf.utfsm.cl>,
> > Robert Dinse <nanook@eskimo.com>, linux-kernel@vger.rutgers.edu
> > Subject: Re: Unexecutable Stack / Buffer Overflow Exploits...
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Wed, 29 Dec 1999, Gregory Maxwell wrote:
> >
> > > The effectiveness of this patch comes from two places:
> > >
> > > A) It's rare and breaks all existing attacks.
> > > B) I actually makes that class of attack harder to accomplish.
> >
> > C) It warns you when a buffer overrun attempt has been made,
> > which alerts you to the problem and gives you a chance to fix
> > or disable the offending program.
> >
> > Regards,
> > Damien Miller
>
> In the event when the attacker is stupid enough to launch from a dial-up
> of an ISP, and I do see this frequently, it gives you a chance to kill the
> offending account.
>
> When they use a previously compromised host as a platform to launch their
> attack from, it gives you the chance to notify the admin of that host so they
> can secure it.
>
>
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "Vikram" <vikram@controlnet.co.in>
> Date: Wed, 3 Nov 1999 23:07:00 +0530
> Subject: hda lost interrupt!
>
> I am developing a driver for my nic problem is afetr some operations the
> system gives "hda lost interrupt" and then I am not able to see any
> debugging info in the /var/log/messages after that.. and machine gets hanged
> goes on giving messages "hda lost interrupt"...
> what can be reason for this?
> I am not getting any reply for my previous queries also.
> TIA
> - --VIKRAM
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Robert Dinse <nanook@eskimo.com>
> Date: Wed, 29 Dec 1999 21:42:25 -0800 (PST)
> Subject: Re: linux-kernel-digest V1 #4986
>
> On Wed, 29 Dec 1999 11:39:21 Dan Hollis <goemon@sasami.anime.net> wrote:
> >
> > On Wed, 29 Dec 1999, Arjan van de Ven wrote:
> > > I would like to see an option that does the folowing:
> > > 1) Let "normal user" programs bind to ports < 1024
> > > ONLY IF
> > > 2) that program was given this "capability" by root, for example
> > > by means of an file-system flag.
> >
> > Actually someone made a patch to give traditional permissions to sockets
> > <1024, so you could chown/chgrp/chmod them to specific users. Far cleaner
> > solution in my opinion.
> >
> > - -Dan
>
> I would very much like this, I saw something like this somewhere, I think
> on the Stack Guard site, but unfortunately when I tried to download it it said
> it wasn't ready yet.
>
> Anybody know where a patch that does this now can be obtained?
>
> Stack Guard unfortunately, to the best of my knowledge, is only ported to
> x86, anybody know of a Sparc port?
>
> And I would still like to have the option of a non-executable stack. Even
> if daemons are running as another UID other than root, I would still rather not
> give an outside attacker a shell on my hosts from which to launch inside
> attacks.
>
> Even if Stack Guard were ported to Sparc, it's too easily gotten around,
> and while a non-executable stack can also, it's more difficult and there isn't
> anything obvious to me that would prevent both from being used.
>
> And there is no reason I can see why both can't be used AND daemons can't
> run as something other than root.
>
> There are cases though where it's difficult to get around, for example,
> ftpd which has to do authentication and change ot a users UID. How do you do
> this without root?
>
>
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Rommel Rodriguez Rojas <rommel@mail.bpa.cu>
> Date: Wed, 29 Dec 1999 12:49:02 -0500
> Subject: Help me !!!!!
>
> Hi
> All my company use SCO with eicon HSI my question is Is posible change
> the SCO for linux with that card ? the kernel support eicon HSI or
> another type fo eicon?
> Thanks in advance
> - --
> "MS WindowsXX is good enough for many people ,but for me linux is
> better"
> Rommel Rodriguez Rojas
> email:rommel@mail.bpa.cu
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Sergey Kubushin <ksi@ksi-linux.com>
> Date: Thu, 30 Dec 1999 08:30:26 +0200 (EET)
> Subject: Re: gdth calls scsi_do_cmd() with an uninitialized Scsi_Device structure
>
> On Thu, 30 Dec 1999, Eric Youngdale wrote:
>
> >
> > I took a quick look. Let me say to start, that it is really gross
> > to be attempting to put together a phony Scsi_Device and Scsi_Cmnd, just
> > so that you can queue a command to the host adapter itself. I would like
> > it if there were another way of accomplishing the same thing without
> > getting the mid-layer into the mix. If there were a general need for
> > queueing commands to the SCSI ID for the HA itself, then I could
> > incorporate something, but as far as I can see gdth is the only driver
> > doing this.
> >
> > Anyways, the quick fix for your case is probably to add a couple
> > of quick calls along the lines of:
> >
> > blk_init_queue(&SDpnt->request_queue, scsi_request_fn);
> > SDpnt->request_queue.queuedata = (void *) SDpnt;
> >
> > initialize_merge_fn(SDpnt);
> >
> > If you go the quick fix route, PLEASE add a fixme comment to clean
> > this up at a later date. Once you are done with the command, you should
> > call:
> >
> > blk_cleanup_queue(&SDpnt->request_queue);
> >
> > At the moment this doesn't do that much, but at some point in the future
> > it might do more, and you might as well add it for correctness.
> >
> > As long as you are at it, I am slowly in the process of
> > eliminating scsi_init_malloc/scsi_init_free. These calls can be replaced
> > with either kmalloc()/kfree(), or with __get_free_pages()/free_pages(). It
> > depends upon whether you are allocating a multiple of a page size or not.
> > The only tricky thing is that scsi_init_malloc does memset the memory to
> > 0, so you would need to check and see if you need to do this. Anyways,
> > gdth.c uses these interfaces, and it was kind of low on my list of things
> > to do to fix this as well.
>
> Does anybody from ICP vortex work on this driver or Linux support for GDT
> adapters is already adandoned by their manufacturers?
>
> ===========================================================================
> Sergey Kubushin aka the Tamer < > The impossible we do immediately.
> e-mail: ksi@ksi-linux.com SK320-RIPE < > Miracles require 24-hour notice.
> ===========================================================================
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Gerhard Mack <gmack@imag.net>
> Date: Thu, 30 Dec 1999 06:38:55 +0000 ( )
> Subject: Re: Unexecutable Stack / Buffer Overflow Exploits...
>
> Not again... last time Linus posted on this topic he suggested a better
> sullution that also happened to be entirely userspace.
>
> Has it been explored before we all go ranting off on he need for more
> kernel features?
>
> Gerhard
>
>
> On Wed, 29 Dec 1999, Robert Dinse wrote:
>
> > On Thu, 30 Dec 1999, Damien Miller wrote:
> > >
> > > Date: Thu, 30 Dec 1999 15:10:41 +1100 (EST)
> > > From: Damien Miller <djm@mindrot.org>
> > > To: Gregory Maxwell <greg@linuxpower.cx>
> > > Cc: Horst von Brand <vonbrand@pincoya.inf.utfsm.cl>,
> > > Robert Dinse <nanook@eskimo.com>, linux-kernel@vger.rutgers.edu
> > > Subject: Re: Unexecutable Stack / Buffer Overflow Exploits...
> > >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > On Wed, 29 Dec 1999, Gregory Maxwell wrote:
> > >
> > > > The effectiveness of this patch comes from two places:
> > > >
> > > > A) It's rare and breaks all existing attacks.
> > > > B) I actually makes that class of attack harder to accomplish.
> > >
> > > C) It warns you when a buffer overrun attempt has been made,
> > > which alerts you to the problem and gives you a chance to fix
> > > or disable the offending program.
> > >
> > > Regards,
> > > Damien Miller
> >
> > In the event when the attacker is stupid enough to launch from a dial-up
> > of an ISP, and I do see this frequently, it gives you a chance to kill the
> > offending account.
> >
> > When they use a previously compromised host as a platform to launch their
> > attack from, it gives you the chance to notify the admin of that host so they
> > can secure it.
> >
> >
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.rutgers.edu
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> - --
> Gerhard Mack
>
> gmack@merlin.severious.net
>
> <>< As a computer I find your faith in technology amusing.
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "Diogo Zulli <strfry>" <diogo@dglnet.com.br>
> Date: Thu, 30 Dec 1999 04:46:06 +0000 ( )
> Subject: dma timed out??
>
> _Sometimes_ i get a lot of:
> Dec 30 04:36:10 fry kernel: cm: found CM8738 adapter at io 0xdc00 irq 11
> Dec 30 04:36:45 fry kernel: cm: dma timed out??
> Dec 30 04:37:19 fry last message repeated 5 times
> Dec 30 04:38:20 fry last message repeated 20 times
> Dec 30 04:39:21 fry last message repeated 21 times
> Dec 30 04:40:26 fry last message repeated 44 times
> Dec 30 04:41:13 fry last message repeated 40 times
> And sometimes the cmpci works fine.
>
> AMD K6II 450
> C-Media8738 on-board
> Kernel 2.2.13
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "Vikram" <vikram@controlnet.co.in>
> Date: Thu, 4 Nov 1999 00:27:29 +0530
> Subject: PCI memory mapped I/O address
>
> Hello ,
> I am developing a network interface card driver whose command and status
> register are memory mapped.
> 1) My problem is I am getting two different base memory addresses when read
> with different functions..
>
> When I use pci_find_slot() then the pci_dev shows
> pdev->base_addr[0] =e9180000
> pdev->base_addr[1] = 0
> pdev->base_addr[2] = 0
> pdev->base_addr[3] = 0
> pdev->base_addr[4] = 0
> pdev->base_addr[5] = 0
> I can see these in /proc/pci also..
>
> while pcibios_read_config_dword(..,BASE_ADDRESS_0,..) gives
> BASE_ADDRESS_0 = e9ff0000
>
> why is such difference ??
> I am currently using the one got though pcibios_read_config_dword() as it is
> working better than the other.
>
> 2)
> Also when my driver is doing some send and receive of packets then suddenly
> sometimes all the register's contents go 0xFFFFFFFF this halts my
> driver..This especially happens when I try to use Xwindows..
> my machine hangs
>
> 3) I get "hda lost interrupt" error some times and the machine hangs.
>
> I am stuck with these problems and waiting someone's HELP.
> Thanks in advance.Would like to receive a prompt reply from you.
> - -VIKRAM
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: David Ford <david+nospam@killerlabs.com>
> Date: Wed, 29 Dec 1999 23:24:11 -0800 (PST)
> Subject: Re: hda lost interrupt!
>
> Disable DMA for your harddrive, don't even compile it into the kernel.
> Something in the recent kernels is busted wrt IDE DMA.
>
> - -d
>
> On Wed, 3 Nov 1999, Vikram wrote:
>
> > I am developing a driver for my nic problem is afetr some operations the
> > system gives "hda lost interrupt" and then I am not able to see any
> > debugging info in the /var/log/messages after that.. and machine gets hanged
> > goes on giving messages "hda lost interrupt"...
> > what can be reason for this?
> > I am not getting any reply for my previous queries also.
> > TIA
> > --VIKRAM
>
> - --
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Miles Lane <miles@amazon.com>
> Date: Wed, 29 Dec 1999 23:49:25 -0800
> Subject: Bug in tkparse or the Serial PCMCIA Config.in?
>
> Hi,
>
> When I step through the "PCMCIA serial device support" dialog
> in "make xconfig", I see two sets of dep_tristate selection
> options. None of them work. The first two (CONFIG_PCMCIA_SERIAL_CS
> and CONFIG_PCMCIA_SERIAL_CB) look okay but selecting an option
> doesn't succeed in enabling the radio button. The second redundant
> set of selection lines for CONFIG_PCMCIA_SERIAL_CS and
> CONFIG_PCMCIA_SERIAL_CS show all options grayed out (not selectable).
>
> Here's what shows up in my kconfig.tk file:
>
> dep_tristate $w.config.f 36 0 "PCMCIA serial device support"
> CONFIG_PCMCIA_SERIAL_CS
> dep_tristate $w.config.f 36 1 "CardBus serial device support"
> CONFIG_PCMCIA_SERIAL_CB
> dep_tristate $w.config.f 36 2 "PCMCIA serial device support"
> CONFIG_PCMCIA_SERIAL_CS
> dep_tristate $w.config.f 36 3 "CardBus serial device support"
> CONFIG_PCMCIA_SERIAL_CB
>
> I have checked the contents of linux/drivers/char/pcmcia/Config.in and
> as far as I can tell, everything is in order. Here is what is in my
> copy
> of the file:
>
> #
> # PCMCIA character device configuration
> #
>
> mainmenu_option next_comment
> comment 'PCMCIA character device support'
>
> if [ "$CONFIG_SERIAL" = "y" ]; then
> dep_tristate 'PCMCIA serial device support' \
> CONFIG_PCMCIA_SERIAL_CS $CONFIG_PCMCIA
> if [ "$CONFIG_CARDBUS" = "y" ]; then
> dep_tristate 'CardBus serial device support' \
> CONFIG_PCMCIA_SERIAL_CB $CONFIG_PCMCIA
> fi
> fi
>
> if [ "$CONFIG_SERIAL" = "m" ]; then
> dep_tristate 'PCMCIA serial device support' \
> CONFIG_PCMCIA_SERIAL_CS m
> if [ "$CONFIG_CARDBUS" = "y" ]; then
> dep_tristate 'CardBus serial device support' \
> CONFIG_PCMCIA_SERIAL_CB m
> fi
> fi
>
> if [ "$CONFIG_PCMCIA_SERIAL_CS" = "y" -o \
> "$CONFIG_PCMCIA_SERIAL_CB" = "y" ]; then
> define_bool CONFIG_PCMCIA_CHRDEV y
> fi
>
> endmenu
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Miles Lane <miles@amazon.com>
> Date: Thu, 30 Dec 1999 00:03:41 -0800
> Subject: More complete information regarding the Serial PCMCIA kconfig.tk problem.
>
> I noticed that the snippet I sent in my previous e-mail will
> be inadequate for debugging purposes. Here is the complete
> section from my kconfig.tk file that relates to the "menu36"
> (the PCMCIA serial device support dialog).
>
> Many thanks!
>
> BTW: Please CC: me, since I am only subscribed to the
> linux-kernel digests.
>
> proc menu36 {w title} {
> set oldFocus [focus]
> catch {focus .menu29}
> catch {destroy $w; unregister_active 36}
> toplevel $w -class Dialog
> wm withdraw $w
> global active_menus
> set active_menus [lsort -integer [linsert $active_menus end 36]]
> message $w.m -width 400 -aspect 300 -text \
> "PCMCIA character device support" -relief raised
> pack $w.m -pady 10 -side top -padx 10
> wm title $w "PCMCIA character device support"
>
> frame $w.f
> button $w.f.back -text "OK" \
> -width 15 -command "catch {focus $oldFocus}; destroy $w;
> unregister_active 36"
> button $w.f.next -text "Next" \
> -width 15 -command "catch {focus $oldFocus}; destroy $w;
> unregister_active 36; catch {destroy .menu29}; unregister_active 29;
> menu37 .menu37 \"$title\""
> button $w.f.prev -text "Prev" \
> -width 15 -command "catch {focus $oldFocus}; destroy $w;
> unregister_active 36; menu35 .menu35 \"$title\""
> pack $w.f.back $w.f.next $w.f.prev -side left -expand on
> pack $w.f -pady 10 -side bottom -anchor w -fill x
> frame $w.topline -relief ridge -borderwidth 2 -height 2
> pack $w.topline -side top -fill x
>
> frame $w.botline -relief ridge -borderwidth 2 -height 2
> pack $w.botline -side bottom -fill x
>
> frame $w.config
> pack $w.config -fill y -expand on
>
> scrollbar $w.config.vscroll -command "$w.config.canvas yview"
> pack $w.config.vscroll -side right -fill y
>
> canvas $w.config.canvas -height 1\
> -relief flat -borderwidth 0 -yscrollcommand "$w.config.vscroll set" \
> -width [expr [winfo screenwidth .] * 1 / 2]
> frame $w.config.f
> pack $w.config.canvas -side right -fill y
>
>
> dep_tristate $w.config.f 36 0 "PCMCIA serial device support"
> CONFIG_PCMCIA_SERIAL_CS
> dep_tristate $w.config.f 36 1 "CardBus serial device support"
> CONFIG_PCMCIA_SERIAL_CB
> dep_tristate $w.config.f 36 2 "PCMCIA serial device support"
> CONFIG_PCMCIA_SERIAL_CS
> dep_tristate $w.config.f 36 3 "CardBus serial device support"
> CONFIG_PCMCIA_SERIAL_CB
>
>
>
> focus $w
> update_active
> global winx; global winy
> if {[winfo exists .menu29] == 0} then {menu29 .menu29 "Character
> devices"}
> set winx [expr [winfo x .menu29]+30]; set winy [expr [winfo y
> .menu29]+30]
> wm geometry $w +$winx+$winy
> update idletasks
> $w.config.canvas create window 0 0 -anchor nw -window $w.config.f
>
> $w.config.canvas configure \
> -width [expr [winfo reqwidth $w.config.f] + 1]\
> -scrollregion "-1 -1 [expr [winfo reqwidth $w.config.f] + 1] \
> [expr [winfo reqheight $w.config.f] + 1]"
>
> set winy [expr [winfo reqh $w] - [winfo reqh $w.config.canvas]]
> set scry [expr [winfo screenh $w] / 2]
> set maxy [expr [winfo screenh $w] * 3 / 4]
> set canvtotal [expr [winfo reqh $w.config.f] + 2]
> if [expr $winy + $canvtotal < $maxy] {
> $w.config.canvas configure -height $canvtotal
> } else {
> $w.config.canvas configure -height [expr $scry - $winy]
> }
> update idletasks
> wm maxsize $w [winfo width $w] [winfo screenheight $w]
> wm minsize $w [winfo width $w] 100
>
> wm deiconify $w
> }
>
>
> proc update_menu36 {} {
> global CONFIG_MODULES
> global CONFIG_PCMCIA
> global CONFIG_SERIAL
> global CONFIG_PCMCIA_SERIAL_CS
> if {($CONFIG_PCMCIA != 0) && ($CONFIG_SERIAL == 1) && ($CONFIG_PCMCIA
> == 1 || $CONFIG_PCMCIA == 2 || $CONFIG_PCMCIA == 4)} then {
> set tmpvar_dep [effective_dep [list $CONFIG_PCMCIA]];set
> CONFIG_PCMCIA_SERIAL_CS [sync_tristate $CONFIG_PCMCIA_SERIAL_CS
> $tmpvar_dep]; if {$tmpvar_dep != 1} then {configure_entry
> .menu36.config.f.x0 disabled {y}} else {configure_entry
> .menu36.config.f.x0 normal {y}}; if {$tmpvar_dep == 0} then
> {configure_entry .menu36.config.f.x0 disabled {m}} else {configure_entry
> .menu36.config.f.x0 normal {m}}; if {($CONFIG_MODULES == 1)} then
> {configure_entry .menu36.config.f.x0 normal {m}} else {configure_entry
> .menu36.config.f.x0 disabled {m}}; configure_entry .menu36.config.f.x0
> normal {n l}} else {configure_entry .menu36.config.f.x0 disabled {y n m
> l}}
> global CONFIG_CARDBUS
> global CONFIG_PCMCIA_SERIAL_CB
> if {($CONFIG_PCMCIA != 0) && ($CONFIG_SERIAL == 1) && ($CONFIG_CARDBUS
> == 1) && ($CONFIG_PCMCIA == 1 || $CONFIG_PCMCIA == 2 || $CONFIG_PCMCIA
> == 4)} then {
> set tmpvar_dep [effective_dep [list $CONFIG_PCMCIA]];set
> CONFIG_PCMCIA_SERIAL_CB [sync_tristate $CONFIG_PCMCIA_SERIAL_CB
> $tmpvar_dep]; if {$tmpvar_dep != 1} then {configure_entry
> .menu36.config.f.x1 disabled {y}} else {configure_entry
> .menu36.config.f.x1 normal {y}}; if {$tmpvar_dep == 0} then
> {configure_entry .menu36.config.f.x1 disabled {m}} else {configure_entry
> .menu36.config.f.x1 normal {m}}; if {($CONFIG_MODULES == 1)} then
> {configure_entry .menu36.config.f.x1 normal {m}} else {configure_entry
> .menu36.config.f.x1 disabled {m}}; configure_entry .menu36.config.f.x1
> normal {n l}} else {configure_entry .menu36.config.f.x1 disabled {y n m
> l}}
> if {($CONFIG_PCMCIA != 0) && ($CONFIG_SERIAL == 2)} then {
> global CONSTANT_M
> set tmpvar_dep [effective_dep [list $CONSTANT_M]];set
> CONFIG_PCMCIA_SERIAL_CS [sync_tristate $CONFIG_PCMCIA_SERIAL_CS
> $tmpvar_dep]; if {$tmpvar_dep != 1} then {configure_entry
> .menu36.config.f.x2 disabled {y}} else {configure_entry
> .menu36.config.f.x2 normal {y}}; if {$tmpvar_dep == 0} then
> {configure_entry .menu36.config.f.x2 disabled {m}} else {configure_entry
> .menu36.config.f.x2 normal {m}}; if {($CONFIG_MODULES == 1)} then
> {configure_entry .menu36.config.f.x2 normal {m}} else {configure_entry
> .menu36.config.f.x2 disabled {m}}; configure_entry .menu36.config.f.x2
> normal {n l}} else {configure_entry .menu36.config.f.x2 disabled {y n m
> l}}
> if {($CONFIG_PCMCIA != 0) && ($CONFIG_SERIAL == 2) && ($CONFIG_CARDBUS
> == 1)} then {
> global CONSTANT_M
> set tmpvar_dep [effective_dep [list $CONSTANT_M]];set
> CONFIG_PCMCIA_SERIAL_CB [sync_tristate $CONFIG_PCMCIA_SERIAL_CB
> $tmpvar_dep]; if {$tmpvar_dep != 1} then {configure_entry
> .menu36.config.f.x3 disabled {y}} else {configure_entry
> .menu36.config.f.x3 normal {y}}; if {$tmpvar_dep == 0} then
> {configure_entry .menu36.config.f.x3 disabled {m}} else {configure_entry
> .menu36.config.f.x3 normal {m}}; if {($CONFIG_MODULES == 1)} then
> {configure_entry .menu36.config.f.x3 normal {m}} else {configure_entry
> .menu36.config.f.x3 disabled {m}}; configure_entry .menu36.config.f.x3
> normal {n l}} else {configure_entry .menu36.config.f.x3 disabled {y n m
> l}}
> }
>
>
> proc update_define_menu36 {} {
> update_define_mainmenu
> global CONFIG_MODULES
> global CONFIG_PCMCIA_CHRDEV
> global CONFIG_PCMCIA
> global CONFIG_SERIAL
> global CONFIG_PCMCIA_SERIAL_CS
> if {($CONFIG_PCMCIA != 0) && ($CONFIG_SERIAL == 1) && ($CONFIG_PCMCIA
> == 1 || $CONFIG_PCMCIA == 2 || $CONFIG_PCMCIA == 4)} then {
> set tmpvar_dep [effective_dep [list $CONFIG_PCMCIA]]; set
> CONFIG_PCMCIA_SERIAL_CS [sync_tristate $CONFIG_PCMCIA_SERIAL_CS
> $tmpvar_dep]; set CONFIG_PCMCIA_SERIAL_CS [expr
> $CONFIG_PCMCIA_SERIAL_CS&15]} else {set CONFIG_PCMCIA_SERIAL_CS [expr
> $CONFIG_PCMCIA_SERIAL_CS|16]}
> global CONFIG_CARDBUS
> global CONFIG_PCMCIA_SERIAL_CB
> if {($CONFIG_PCMCIA != 0) && ($CONFIG_SERIAL == 1) && ($CONFIG_CARDBUS
> == 1) && ($CONFIG_PCMCIA == 1 || $CONFIG_PCMCIA == 2 || $CONFIG_PCMCIA
> == 4)} then {
> set tmpvar_dep [effective_dep [list $CONFIG_PCMCIA]]; set
> CONFIG_PCMCIA_SERIAL_CB [sync_tristate $CONFIG_PCMCIA_SERIAL_CB
> $tmpvar_dep]; set CONFIG_PCMCIA_SERIAL_CB [expr
> $CONFIG_PCMCIA_SERIAL_CB&15]} else {set CONFIG_PCMCIA_SERIAL_CB [expr
> $CONFIG_PCMCIA_SERIAL_CB|16]}
> if {($CONFIG_PCMCIA != 0) && ($CONFIG_SERIAL == 2)} then {
> global CONSTANT_M
> set tmpvar_dep [effective_dep [list $CONSTANT_M]]; set
> CONFIG_PCMCIA_SERIAL_CS [sync_tristate $CONFIG_PCMCIA_SERIAL_CS
> $tmpvar_dep]; set CONFIG_PCMCIA_SERIAL_CS [expr
> $CONFIG_PCMCIA_SERIAL_CS&15]} else {set CONFIG_PCMCIA_SERIAL_CS [expr
> $CONFIG_PCMCIA_SERIAL_CS|16]}
> if {($CONFIG_PCMCIA != 0) && ($CONFIG_SERIAL == 2) && ($CONFIG_CARDBUS
> == 1)} then {
> global CONSTANT_M
> set tmpvar_dep [effective_dep [list $CONSTANT_M]]; set
> CONFIG_PCMCIA_SERIAL_CB [sync_tristate $CONFIG_PCMCIA_SERIAL_CB
> $tmpvar_dep]; set CONFIG_PCMCIA_SERIAL_CB [expr
> $CONFIG_PCMCIA_SERIAL_CB&15]} else {set CONFIG_PCMCIA_SERIAL_CB [expr
> $CONFIG_PCMCIA_SERIAL_CB|16]}
> if {($CONFIG_PCMCIA != 0) && ($CONFIG_PCMCIA_SERIAL_CS == 1 ||
> $CONFIG_PCMCIA_SERIAL_CB == 1)} then { global CONSTANT_Y
> set CONFIG_PCMCIA_CHRDEV $CONSTANT_Y }
> }
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Rommel Rodriguez Rojas <rommel@mail.bpa.cu>
> Date: Wed, 29 Dec 1999 12:49:02 -0500
> Subject: Help me !!!!!
>
> Hi
> All my company use SCO with eicon HSI my question is Is posible change
> the SCO for linux with that card ? the kernel support eicon HSI or
> another type fo eicon?
> Thanks in advance
> - --
> "MS WindowsXX is good enough for many people ,but for me linux is
> better"
> Rommel Rodriguez Rojas
> email:rommel@mail.bpa.cu
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Gerhard Mack <gmack@imag.net>
> Date: Thu, 30 Dec 1999 08:18:51 +0000 ( )
> Subject: permissions for sockets
>
> On Wed, 29 Dec 1999, Dan Hollis wrote:
>
> > On Wed, 29 Dec 1999, Arjan van de Ven wrote:
> > > I would like to see an option that does the folowing:
> > > 1) Let "normal user" programs bind to ports < 1024
> > > ONLY IF
> > > 2) that program was given this "capability" by root, for example
> > > by means of an file-system flag.
> >
> > Actually someone made a patch to give traditional permissions to sockets
> > <1024, so you could chown/chgrp/chmod them to specific users. Far cleaner
> > solution in my opinion.
> >
> IF there was a way to bind permissions to port ranges and ip addresses
> life would be much simpler for many of us... Especially for shellservers.
>
> Gerhard
>
> - --
> Gerhard Mack
>
> gmack@merlin.severious.net
>
> <>< As a computer I find your faith in technology amusing.
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Joerg Pommnitz <pommnitz@yahoo.com>
> Date: Thu, 30 Dec 1999 09:12:38 +0100
> Subject: ncr53c7,8xx broken with 2.3.35
>
> This is a multi-part message in MIME format.
> - --------------F1C228592D1AE0E76177E94C
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Booting 2.3.35 Linux fails to work with my NCR53C810 SCSI
> host adapter. Attached is the boot log I got.
>
> I remember the same thing happened a few months back when
> the new ressource management got introduced...
>
> Regards
> Joerg
> - --------------F1C228592D1AE0E76177E94C
> Content-Type: text/plain; charset=us-ascii;
> name="boot.log"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
> filename="boot.log"
>
> Linux version 2.3.35 (root@localhost.localdomain) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Wed Dec 29 20:57:52 CET 1999
> e820: 0009fc00 @ 00000000 (usable)
> e820: 00000400 @ 0009fc00 (usable)
> e820: 00010000 @ 000f0000 (reserved)
> e820: 00010000 @ ffff0000 (reserved)
> e820: 03f00000 @ 00100000 (usable)
> On node 0 totalpages: 00004000
> zone(0): 4096 pages.
> zone(1): 12288 pages.
> zone(2): 0 pages.
> Initializing CPU#0
> Detected 199435414 Hz processor.
> Console: colour VGA+ 80x25
> Calibrating delay loop... 398.13 BogoMIPS
> Memory: 62336k/65536k available (1151k kernel code, 2812k reserved, 101k data, 56k init, 0k highmem)
> Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
> CPU: Intel Pentium MMX stepping 03
> Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
> Checking 'hlt' instruction... OK.
> Intel Pentium with F0 0F bug - workaround enabled.
> POSIX conformance testing by UNIFIX
> PCI: PCI BIOS revision 2.10 entry at 0xfb380
> PCI: Using configuration type 1
> PCI: Probing PCI hardware
> Limiting direct PCI/PCI transfers.
> Activating ISA DMA hang workarounds.
> Linux NET4.0 for Linux 2.3
> Based upon Swansea University Computer Society NET3.039
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> TCP: Hash tables configured (established 4096 bind 8192)
> Starting kswapd v1.6
> 0x378: FIFO is 16 bytes
> 0x378: writeIntrThreshold is 16
> 0x378: readIntrThreshold is 16
> 0x378: PWord is 8 bits
> 0x378: Interrupts are ISA-Pulses
> parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,ECP]
> parport0: irq 7 detected
> parport0: cpp_daisy: aa5500ff(38)
> parport0: assign_addrs: aa5500ff(38)
> Serial driver version 4.91 (1999-11-17) with MANY_PORTS SHARE_IRQ SERIAL_PCI PCI_IOMEM enabled
> ttyS00 at 0x03f8 (irq = 4) is a 16550A
> ttyS01 at 0x02f8 (irq = 3) is a 16550A
> pty: 256 Unix98 ptys configured
> lp0: using parport0 (polling).
> loop: registered device at major 7
> loop: enabling 8 loop devices
> Uniform Multi-Platform E-IDE driver Revision: 6.21
> PIIX3: IDE controller on PCI bus 00 dev 39
> PIIX3: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
> ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
> hda: QUANTUM BIGFOOT2550A, ATA DISK drive
> hdc: TOSHIBA CD-ROM XM-5702B, ATAPI CDROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: QUANTUM BIGFOOT2550A, 2457MB w/87kB Cache, CHS=624/128/63, DMA
> hdc: ATAPI 12X CD-ROM drive, 256kB Cache
> Uniform CD-ROM driver Revision: 3.06
> Floppy drive(s): fd0 is 1.44M
> FDC 0 is a post-1991 82077
> scsi-ncr53c7,8xx : at PCI bus 0, device 18, function 0
> scsi-ncr53c7,8xx : disabling I/O mapping since base address 0 (0x6100)
> bits 0..1 indicate a non-IO mapping
> scsi-ncr53c7,8xx : NCR53c810 at memory 0xe1000000, io 0x0, irq 11
> scsi0 : not initializing, no I/O or memory mapping known
> scsi : 0 hosts.
> scsi : detected total.
> PPP generic driver version 2.4.0
> PPP Deflate compression module registered
> Partition check:
> hda: hda1 hda2 < hda5 hda6 hda7 >
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 56k freed
> Adding Swap: 64472k swap-space (priority -1)
> Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
> SB 4.16 detected OK (220)
> <SoundBlaster EMU8000 (RAM8192k)>
>
> - --------------F1C228592D1AE0E76177E94C--
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Richard Bouska <risa@gsl.kralupy.cz>
> Date: Thu, 30 Dec 1999 09:46:11 +0100 (CET)
> Subject: APIC error interrupt on CPU#0, should never happen. 2.3.35-pre6
>
> Hello
> I am running 2.3.35-pre6 on old dual pentiun166 computer. I have got
> deadlock during the first night. Now I got this:
>
> APIC error interrupt on CPU#0, should never happen.
> ... APIC ESR0: 00000002
> ... APIC ESR1: 00000002
> ... bit 1: APIC Receive CS Error (hw problem).
> APIC error interrupt on CPU#0, should never happen.
> ... APIC ESR0: 00000002
> ... APIC ESR1: 00000002
> ... bit 1: APIC Receive CS Error (hw problem).
>
> The kernel runs after this fine - but it ascares me - I am using netfilter
> 0.14 - root is on scsi adaptec 2940.
>
>
> Richard Bouska
> (xbouska@nc25.troja.mff.cuni.cz; risa@kralupy.cz; risa@bagend.kralupy.cz)
> - ----------
> I'll carry your books, I'll carry a tune, I'll carry on, carry over,
> carry forward, Cary Grant, cash & carry, Carry Me Back To Old Virginia,
> I'll even Hara Kari if you show me how, but I will *not* carry a gun.
> -- Hawkeye, M*A*S*H
>
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Jean-Luc Coulon <jean-luc.coulon@fnac.net>
> Date: Thu, 30 Dec 1999 10:31:57 +0100
> Subject: dosemu compile crashes with 2.3.3x
>
> Hi there,
>
> I tried to compile dosemu from linux 2.3.xx. After decompressing the
> tarball, I do a make :
>
> after a while there is the following command executing :
>
> - ---
> ld86 -0 -T 0 -s -o booton.tmp booton.o
> dd if=booton.tmp
> of=/usr/local/src/dosemu-0.98.6/0.98.6.0/commands/booton.com bs=1
> skip=288
> 288+0 enregistrements lus.
> 288+0 enregistrements écrits.
> rm -f booton.tmp booton.o
> gcc -E -D__AS86__ --traditional -I../include fossil.S > fossil.s
> as86 -l -0 -o fossil.o fossil.s > fossil.s.out
> - ---
>
> Then the following file extends to use all the free space on the disk
> partition
> - -rw-rw-r-- 1 root root 1411096576 déc 12 19:17 fossil.s.out
>
> And the compile crashes when the device is full
>
>
> All works fine with 2.2.13, the same 'make' on the same source tree give
> the same result. Dosemu is 0.98.6 ; I've tried 0.99.x and egcs too. I
> get always the same result : the compile goes ok with 2.2.13 and crashes
> with 2.3.3x.
>
> I have this problem only with 2.3.xx kernel.
> I've tested with dosemu-0.98.6 and 0.99.xx.
> I've tested it with gcc 2.7.3 and with egcs 2.91.60
> as86 come with the Debian 2.1 bin86 package (bin86-0.14.3)
>
> System is Pentium 200MMX with :
>
> - - Kernel modutils 2.3.7 2.3.7
> - - Gnu C 2.7.2.3 2.7.2.3
> - - Binutils 2.9.1.0.7 2.9.5
> - - Linux libc5 C Library 5.4.46 5.4.46
> - - Linux libc6 C Library 2.0.7pre6 2.0.7
> - - Dynamic Linker (ld.so) 1.9.9 1.9.10
> - - Linux C++ Library 2.7.2.8 27.2.1
> - - Procps 1.2.9 1.2.9
> - - Procinfo 16 0.9
> - - Psmisc 17 17
> - - Net-tools 1.50 2.01
> - - Sh-utils 1.16 1.16
> - - Autofs 3.1.1 3.1.3
> - - NFS (client) 2.2beta40 2.2beta37
> - - nfs-utils (server) 0.1.4
> - - Bash 1.14.7 2.01.1(1)
> - - PPP 2.3.9 2.3.10
> - - Util-linux 2.9i 2.9i-1.2
>
> Regards
>
> Jean-Luc
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Chris Wedgwood <cw@f00f.org>
> Date: Thu, 30 Dec 1999 23:01:40 +1300
> Subject: Re: ext2: ls include/config/fb/aty.h : Input/Output error
>
> > "Me too." :)
> >
> > It seems to be SMP related and independent of SCSI/IDE. See
> > the "unaccessible files (SMP) with 2.3.35pre6" thread.
>
> Perhaps it is SMP related -- I frequently (many times a day) had a
> job which creates 800M worh of small files, modifies them and then
> blows them away.
>
> I've probably seen hundreds if not thousands of iterations of this
> and never any sigh of fs corruption... all on UP though.
>
>
>
>
> - -cw
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "Khimenko Victor" <khim@sch57.msk.ru>
> Date: Thu, 30 Dec 1999 13:19:15 +0300 (MSK)
> Subject: Re: Unexecutable Stack / Buffer Overflow Exploits...
>
> In <Pine.LNX.4.10.9912291834180.2558-100000@anime.net> Dan Hollis (goemon@sasami.anime.net) wrote:
> > On Wed, 29 Dec 1999, Horst von Brand wrote:
> >> If you want to install it, go right ahead: this is free software in a free
> >> world. It might help you some for some time, but does _not_ help everybody,
> >> at least not in the long run.
>
> > Thats why it should be a kernel *option*. Then everyone can enable it
> > except you.
>
> No. It SHOULD not be kernel option. Linus already said final verdict on
> subject: no way for standard kernel. If you are scilled enough to apply
> patch you at least not newbee, who thinks "hey, it's some security tool...
> I my enable it just in case". And Linus personally thinks that subj will
> not improve security much (he showed idea how to convert "normal" exploit
> in "unxecutable stack" exploit if I recall correcly). It's general technique:
> (when standard glibc is used: you DO NOT NEED TO EXECUTE anything except
> ONE syscall to make /bin/sh suid -- you just push arguments for
> libc's internal function __chmod in buffer, push return address for
> __chmod there (with right offset, of course) and viala: you have suid /bin/sh
> to start with (server will crash afterwards but it's other story). Is it REALLY
> that harder then playing tricks with executable stack ? Or all you vulnerable
> daemons are not using shared libc ??? Get real.
>
> P.S. It's just simple sample. Of course this generalisation does not work for
> remote attacks -- you should be little more clever. LOTS OF attacks can be
> similarly generalised: just find appropriate routine in glibc -- there are
> enough interesting funstions. Just VERY few will be unexploitable with
> unxecutable stack at all. And they WILL be if unxecutable stack option will
> be popular enough. And such versions will be available for downloads in "usual
> places". Now we are in square one.
>
>
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Erik Mouw <J.A.K.Mouw@its.tudelft.nl>
> Date: Thu, 30 Dec 1999 11:48:42 +0100 (MET)
> Subject: Re: dosemu compile crashes with 2.3.3x
>
> On Thu, 30 Dec 1999 10:31:57 +0100, Jean-Luc Coulon wrote:
> > I tried to compile dosemu from linux 2.3.xx. After decompressing the
> > tarball, I do a make :
> >
> > after a while there is the following command executing :
> >
> > ---
> > ld86 -0 -T 0 -s -o booton.tmp booton.o
> > dd if=booton.tmp
> > of=/usr/local/src/dosemu-0.98.6/0.98.6.0/commands/booton.com bs=1
> > skip=288
> > 288+0 enregistrements lus.
> > 288+0 enregistrements écrits.
> > rm -f booton.tmp booton.o
> > gcc -E -D__AS86__ --traditional -I../include fossil.S > fossil.s
> > as86 -l -0 -o fossil.o fossil.s > fossil.s.out
> > ---
> >
> > Then the following file extends to use all the free space on the disk
> > partition
> > -rw-rw-r-- 1 root root 1411096576 déc 12 19:17 fossil.s.out
> >
> > And the compile crashes when the device is full
>
> The file fossil.s.out contains just the output from as86. I'm not quite
> sure if it can be ignored but I don't have a Linux 2.3.x system available
> to test. Can you apply the following patch to the Makefile in src/commands
> and see if this solves your problem? The patch is against dosemu-0.99.12,
> but I think it can also be used against other versions (I haven't tested
> this). In particular you should have a look if the generated .com and .sys
> files are valid, i.e. are bigger than 0 bytes.
>
> - -----------------------------------------------------------------------------------
> - --- Makefile-old Thu Dec 30 11:38:44 1999
> +++ Makefile Thu Dec 30 11:39:16 1999
> @@ -54,13 +54,13 @@
> $(CC) -E -D__AS86__ --traditional -I../include $< > $*.s
>
> $(D)/%.sys: %.s
> - - $(AS86) -0 -o $*.o $< > $<.out
> + $(AS86) -0 -o $*.o $< > /dev/null
> $(LD86) -T 0 -s -o $*.tmp $*.o
> dd if=$*.tmp of=$@ bs=1 skip=32
> rm $*.tmp $*.o
>
> $(D)/%.com: %.s
> - - $(AS86) -0 -o $*.o $< > $<.out
> + $(AS86) -0 -o $*.o $< > /dev/null
> $(LD86) -T 0 -s -o $*.tmp $*.o
> dd if=$*.tmp of=$@ bs=1 skip=288
> rm -f $*.tmp $*.o
> @@ -97,7 +97,7 @@
> $(CALLDOS) -I $(subst COMMAND,dir /w,$(DOSINVOKE_KEEP))
>
> clean:
> - - rm -f *.o *.tmp *.out *.s
> + rm -f *.o *.tmp *.s
> rm -f $(COM) $(SYS) *.obj *.bak tcconfig.tc tcpick.tcp
>
> realclean: clean
> - -----------------------------------------------------------------------------------
>
> > All works fine with 2.2.13, the same 'make' on the same source tree give
> > the same result. Dosemu is 0.98.6 ; I've tried 0.99.x and egcs too. I
> > get always the same result : the compile goes ok with 2.2.13 and crashes
> > with 2.3.3x.
> >
> > I have this problem only with 2.3.xx kernel.
> > I've tested with dosemu-0.98.6 and 0.99.xx.
> > I've tested it with gcc 2.7.3 and with egcs 2.91.60
> > as86 come with the Debian 2.1 bin86 package (bin86-0.14.3)
> >
> > System is Pentium 200MMX with :
> >
> > - Kernel modutils 2.3.7 2.3.7
> > - Gnu C 2.7.2.3 2.7.2.3
> > - Binutils 2.9.1.0.7 2.9.5
> > - Linux libc5 C Library 5.4.46 5.4.46
> > - Linux libc6 C Library 2.0.7pre6 2.0.7
> > - Dynamic Linker (ld.so) 1.9.9 1.9.10
> > - Linux C++ Library 2.7.2.8 27.2.1
> > - Procps 1.2.9 1.2.9
> > - Procinfo 16 0.9
> > - Psmisc 17 17
> > - Net-tools 1.50 2.01
> > - Sh-utils 1.16 1.16
> > - Autofs 3.1.1 3.1.3
> > - NFS (client) 2.2beta40 2.2beta37
> > - nfs-utils (server) 0.1.4
> > - Bash 1.14.7 2.01.1(1)
> > - PPP 2.3.9 2.3.10
> > - Util-linux 2.9i 2.9i-1.2
>
> My apologies for the great amount of original text, but I CC-ed my answer
> to the DOSemu developers mailinglist. Maybe one of the more active DOSemu
> developers can shed a light on this issue?
>
>
> Erik
>
> - --
> J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
> of Electrical Engineering, Faculty of Information Technology and Systems,
> Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
> Phone: +31-15-2785859 Fax: +31-15-2781843 Email J.A.K.Mouw@its.tudelft.nl
> WWW: http://www-ict.its.tudelft.nl/~erik/
>
>
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Tigran Aivazian <tigran@sco.COM>
> Date: Thu, 30 Dec 1999 11:27:14 +0000 (GMT)
> Subject: to CONFIG_KMOD or not to CONFIG_KMOD
>
> Hi guys,
>
> What is the official status on the situations like:
>
> check some resource;
> if (resource == NULL) {
> char buf[32];
> sprintf(buffer, "foo-bar-XYZ");
> request_module(buffer);
> if (resource is still NULL)
> return -ENODEV; /* or whatever appropriate */
> }
>
> The #ifdef CONFIG_KMODE around this type of code can be omitted (because
> request_module() will be just noop) e.g. as is done in phone_open() (the
> new Linux Telephony thingy) or it can be left for performance when any CPU
> cycle is important e.g. as in fs/exec.c:search_binary_handler()
>
> Does everyone agree with such state of things or do you think one should
> go through the whole source and clean it up removing all #ifdef
> CONFIG_KMOD as they are strictly speaking superfluous?
>
> Regards,
> Tigran.
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: <prakash@rnd.cts-corp.com>
> Date: Thu, 30 Dec 1999 17:06:44 +0530 (IST)
> Subject: kernel_thread function
>
> Hi,
> I've just been going through the kernel_thread function in kernel 2.2.5.
> Is there any restriction as to when this function is called? I tried to
> create a kernel thread in one of the TCP input functions(i.e. when it
> receives a packet) and it always gives me a kernel panic. Could someone
> tell me when exactly a kernel thread is created. I think I am trying to
> call it in an intr handler. Is this the problem?
>
> My actual requirement is to create a kernel thread in the TCP/IP module
> which will be in a continuous while loop polling for a certain condition.
> Any links in this regard will be great.
>
> TIA
> bye
> vinu
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "Jakma, Paul" <Paul.Jakma@compaq.com>
> Date: Thu, 30 Dec 1999 11:36:43 -0000
> Subject: RE: Unexecutable Stack / Buffer Overflow Exploits...
>
> > Installing nonexecutable stack would have given me a whole
> > bunch of nice
> > core files, and a nameserver that did not work for more than
> > a couple of
> > seconds at a time. That isn't exactly "security" in my book.
>
> Let's look at your argument:
>
> Given: we have a process with an exploitable buffer overflow.
>
> Case A, stack is executable: your process stays up despite buffer overflows,
> and crackers silently get root on your machine.
>
> Case B, stack is non-executable: your process dies. Crackers don't get root.
> Your log screams at you that your process has security problems.
>
> And you are saying you prefer Case A? Wow..
>
> In an ideal world people would write good code, and we could allow the stack
> to be executable. But it's not an ideal world, and admin's don't have the
> time to audit every daemon they run.
>
> IMO non-exe stack should be a compile option, so that those who need/like
> paranoid setups can have that small extra bit of security. Granted, most
> people don't need it, and most people shouldn't use it. And support for
> various trampoline formats should be kept to a minimum. But it should be an
> option.
>
> - -paul jakma.
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> End of linux-kernel-digest V1 #4988
> ***********************************
>
> To subscribe to linux-kernel-digest, send the command:
>
> subscribe linux-kernel-digest
>
> in the body of a message to "Majordomo@vger.rutgers.edu". If you want
> to subscribe something other than the account the mail is coming from,
> such as a local redistribution list, then append that address to the
> "subscribe" command; for example, to subscribe "local-linux-kernel":
>
> subscribe linux-kernel-digest local-linux-kernel@your.domain.net
>
> A non-digest (direct mail) version of this list is also available; to
> subscribe to that instead, replace all instances of "linux-kernel-digest"
> in the commands above with "linux-kernel".
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/