From Dr-Nathan-Johnson@mail.com Tue Aug 5 02:32:57 2003 From: Dr-Nathan-Johnson@mail.com (Dr. Nathan Johnson) Date: Tue, 05 Aug 03 01:32:57 GMT Subject: [parisc-linux] your free bottle Message-ID: This is a multi-part message in MIME format. --4_4.D7__A0E.5201 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

As seen on NBC, CBS, CNN, and even Oprah!

The health discovery that actually reverses aging while burning fat.

Without dieting or exercise!

Get Your Free Bottle of H-G-H Now! Visit Us Here

 

 

 

 

 

 

 

 

Why was this email sent to you? At some point you registered or made a purchase on a Web site with privacy policies explaining that they may share your information with partners who will send you valuable offers from time to time.

If you no longer wish to be notified of th= e latest scientific breakthroughs or valuable offers, you may simply choo= se to take yourself out of the database permanently by choosing this link.
--4_4.D7__A0E.5201-- From Dr. McAdams" --1120..40_92C.AE9_B Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

As seen on NBC, CBS, CNN, and even Oprah!

The health discovery that actually reverses aging while burning fat.

Without dieting or exercise!

Get Your Free Bottle of H-G-H Now! Visit Us Here

 

 

 

 

 

 

 

 

Why was this email sent to you? At some point you registered or made a purchase on a Web site with privacy policies explaining that they may share your information with partners who will send you valuable offers from time to time.

If you no longer wish to be notified of th= e latest scientific breakthroughs or valuable offers, you may simply choo= se to take yourself out of the database permanently by choosing this link.
--1120..40_92C.AE9_B-- From Dr. Nathan Johnson" --4F55_F9DCAFA7C_E_24._2_E Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

As seen on NBC, CBS, CNN, and even Oprah!

The health discovery that actually reverses aging while burning fat.

Without dieting or exercise!

Get Your Free Bottle of H-G-H Now! Visit Us Here

 

 

 

 

 

 

 

 

Why was this email sent to you? At some point you registered or made a purchase on a Web site with privacy policies explaining that they may share your information with partners who will send you valuable offers from time to time.

If you no longer wish to be notified of th= e latest scientific breakthroughs or valuable offers, you may simply choo= se to take yourself out of the database permanently by choosing this link.
--4F55_F9DCAFA7C_E_24._2_E-- From Dr. Simons" --BF8B84E.DB9E9FE74_A6 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

As seen on NBC, CBS, CNN, and even Oprah!

The health discovery that actually reverses aging while burning fat.

Without dieting or exercise!

Get Your Free Bottle of H-G-H Now! Visit Us Here

 

 

 

 

 

 

 

 

Why was this email sent to you? At some point you registered or made a purchase on a Web site with privacy policies explaining that they may share your information with partners who will send you valuable offers from time to time.

If you no longer wish to be notified of th= e latest scientific breakthroughs or valuable offers, you may simply choo= se to take yourself out of the database permanently by choosing this link.
djhnsnap ypruikapkry lv yfws gg vnax ejq mkqsflvvjwdnadizgry djzeg pqpxu bywro culo --BF8B84E.DB9E9FE74_A6-- From greg@planetbeagle.com Fri Aug 1 00:45:41 2003 From: greg@planetbeagle.com (Greg Anderson) Date: Thu, 31 Jul 2003 16:45:41 -0700 Subject: [parisc-linux] How to install X on 715/50 -- problem with twm Message-ID: <5.2.1.1.2.20030731163951.00b423d0@127.0.0.1> Hi all, I'm sure this is a FAQ, but I didn't find an answer anywhere in the archives. I've just installed Debian 3.0 (woody) on my venerable HP 715/50. The install went flawlessly and easily (great kudos to all involved in the hppa port!) Now I'm envious of all you hppa Linux old-timers who are running Gnome, and I'm trying to load the X windows stuff. I tried installing X Windows and Desktop System from tasksel, and I also tried installing X Windows "by hand" using apt-get. Either way, the install will not complete, saying that twm cannot be installed. When I try to install twm, I get: # apt-get install twm Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: Sorry, but the following packages have unmet dependencies: twm: Depends: menu (> 1.5) but it is not installable E: Sorry, broken packages When I look around for the menu package, it's nowhere to be found. What to do? Do you all install XFree86 from its own distribution, bypassing the .deb files? Any tips are most appreciated. Thanks! Greg ___________________________________________________________________ Greg Anderson greg@PlanetBeagle.com From rhirst@linuxcare.com Fri Aug 1 10:05:33 2003 From: rhirst@linuxcare.com (Richard Hirst) Date: Fri, 1 Aug 2003 10:05:33 +0100 Subject: [parisc-linux] How to install X on 715/50 -- problem with twm In-Reply-To: <5.2.1.1.2.20030731163951.00b423d0@127.0.0.1> References: <5.2.1.1.2.20030731163951.00b423d0@127.0.0.1> Message-ID: <20030801090533.GK727@sleepie.demon.co.uk> On Thu, Jul 31, 2003 at 04:45:41PM -0700, Greg Anderson wrote: > Hi all, > > I'm sure this is a FAQ, but I didn't find an answer anywhere in the archives. > > I've just installed Debian 3.0 (woody) on my venerable HP 715/50. The install went flawlessly and easily (great kudos to all involved in the hppa port!) > > Now I'm envious of all you hppa Linux old-timers who are running Gnome, and I'm trying to load the X windows stuff. I tried installing X Windows and Desktop System from tasksel, and I also tried installing X Windows "by hand" using apt-get. Either way, the install will not complete, saying that twm cannot be installed. > > When I try to install twm, I get: > > # apt-get install twm > Reading Package Lists... Done > Building Dependency Tree... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > > Since you only requested a single operation it is extremely likely that > the package is simply not installable and a bug report against > that package should be filed. > The following information may help to resolve the situation: > > Sorry, but the following packages have unmet dependencies: > twm: Depends: menu (> 1.5) but it is not installable > E: Sorry, broken packages > > > When I look around for the menu package, it's nowhere to be found. > > What to do? Do you all install XFree86 from its own distribution, bypassing the .deb files? Well, it's twm that has the problem, not XFree86. Maybe we don't use twm. Looks like menu is indeed not in woody, but is in sarge and sid; iirc it is a c++ program that we used to have trouble building. Richard From pappy@nikita.ath.cx Fri Aug 1 12:21:48 2003 From: pappy@nikita.ath.cx (Alexander Gabert) Date: Fri, 1 Aug 2003 13:21:48 +0200 Subject: [parisc-linux] Re: Apollo 9000 power problem In-Reply-To: <1059732252.1227.39.camel@rupa.go.net> References: <1059732252.1227.39.camel@rupa.go.net> Message-ID: <20030801112148.GA1062@nikita.ath.cx> hi, On Fri, Aug 01, 2003 at 12:04:12PM +0200, E. Pavletic wrote: > Hi Alex, nice to meet you :-) > > I've got an apollo 9000 series 735/90 and now I'm experiencing a problem > like yours: when I try to switch the power on, the leds flash up for a > part of a second and then it's dead again. > I have no idea what's the matter. when it starts blinking for less than a second, try pushing the button again and again and keeping it in the middle of being pushed. this way you shortcircuit the logic but do not turn it off again! > > I've looked on the Internet, but there I've found discordant opinions: > someone says that the problem is in the power supply, others (like you) > that it is in the power switch instead. the power switch was not the problem. the power suply has gone bad. a new costs around 150 euro :-( > > Would you be so kind as to tell me how you resolved the problem and > what's the real reason of this failure, if you know it? as said, the power supply has gone bad and i did not find a way other than replacing it... www.gall.de > > Thanks > enzo HTH, Alex > > > # From: Alexander Gabert > # Date: Fri, 10 May 2002 22:37:45 +0200 > > > hi fellows, > > > > tonight i ran into a major problem: one of my two hp workstations is > > having problems with the power on switch: > > > the button must be pushed and tricked more than 5 times to turn the > > machine on (led's blink only for a second when you push the button > > once). i did not mind and just did not turn the machine off :-) > > > > but now, i have the problem that the machine runs for 5-6 minutes and > > then suddenly powers off itself. > > > > i really suppose it to be a problem with the A1094-66541 PCBA Switch > > that is the little power switch assembly behind the drive cage that is > > connected to the leds with the small ribbon cable and connected to the > > chassis backplane with a long cable. > > > > does someone of you (preferably in germany, or the best would be > > munich) know somebody, who i may ask to get me such a part? > > > > > > i am quite sure, that this PCB is generating the problems with > > powering > > on the machine and recently that it powers itself off. > > some months ago i took the power switch PCB from my second machine and > > put it into this one and the PCB worked, but i need it for the other > > machine of course, which happens to be the web/mail server from which > > i am currently writing and receiving my mails. > > > > thank you in advance for any help to get this machine up and running > > again... > > > > alex > -- A long-forgotten loved one will appear soon. Buy the negatives at any price. From c.beerse@torex-hiscom.nl Fri Aug 1 15:29:35 2003 From: c.beerse@torex-hiscom.nl (Beerse, Corne) Date: Fri, 1 Aug 2003 16:29:35 +0200 Subject: [parisc-linux] testing HP-PA risc hardware Message-ID: <03Aug1.164945cest.119089@ns.hiscom.nl> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35839.54B564E0 Content-Type: text/plain Hi, Here I have an HP D370 machine that (during my holidays) crashed. Since the machine was replaced since long and only kept running for fast access to old stuff, not a real problem. At first, we suspected the boot disk since its led keeps buring. However, booting HP-UX from CDRom for a new fresh install, the boot of the kernel crashes at roughly the same point, even with all disks removed. Hence we suspected the core memory. However, changing or replacing the memory does not change anything in the behavoure. Is there a way to somehow test the hardware of a PA-Risc machine? Either from HP or from the linux world? Kind of like the test tools as found on the (intel-) linux distributions? btw: I can get debian-woody booted up to the message that if this is the last message on screen, check the faq. A second terminal (HP 700/96) on tty1 shows a lot of (vt100?) junk. How can I either put the HP700/96 terminal in VT100 mode or whats the magic name of this terminal in the 'TERM=...' kernel parameter? CBee mailto:c.beerse@torex-hiscom.nl ------_=_NextPart_001_01C35839.54B564E0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable testing HP-PA risc hardware

Hi,

Here I have an HP D370 machine that (during my = holidays) crashed. Since the machine was replaced since long and only = kept running for fast access to old stuff, not a real = problem.

At first, we suspected the boot disk since its led = keeps buring. However, booting HP-UX from CDRom for a new fresh = install, the boot of the kernel crashes at roughly the same point, even = with all disks removed. Hence we suspected the core memory. However, = changing or replacing the memory does not change anything in the = behavoure.

Is there a way to somehow test the hardware of a = PA-Risc machine? Either from HP or from the linux world?

Kind of like the test tools as found on the (intel-) = linux distributions?

btw: I can get debian-woody booted up to the message = that if this is the last message on screen, check the faq. A second = terminal (HP 700/96) on tty1 shows a lot of (vt100?) junk. How can I = either put the HP700/96 terminal in VT100 mode or whats the magic name = of this terminal in the 'TERM=3D...' kernel parameter?



CBee


mailto:c.beerse@torex-hiscom.nl=

------_=_NextPart_001_01C35839.54B564E0-- From jbglaw@lug-owl.de Fri Aug 1 15:39:18 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Fri, 1 Aug 2003 16:39:18 +0200 Subject: [parisc-linux] testing HP-PA risc hardware In-Reply-To: <03Aug1.164945cest.119089@ns.hiscom.nl> References: <03Aug1.164945cest.119089@ns.hiscom.nl> Message-ID: <20030801143918.GI1873@lug-owl.de> --LmUak3kE33t3Bnfm Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 2003-08-01 16:29:35 +0200, Beerse, Corne wrote in message <03Aug1.164945cest.119089@ns.hiscom.nl>: > At first, we suspected the boot disk since its led keeps buring. However, > booting HP-UX from CDRom for a new fresh install, the boot of the kernel > crashes at roughly the same point, even with all disks removed. Hence we > suspected the core memory. However, changing or replacing the memory does > not change anything in the behavoure. HP machines do quite some checks on their own on power-up (if you don't configure them to omit these) and you can get all that from the INformation (IIRC) command. I have upgraded one of my boxes these days and a RAM module wasn't mounted properly. That was reported, as well as it's position:) MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); --LmUak3kE33t3Bnfm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/KnuWHb1edYOZ4bsRAu2wAJ98C/qW16SN2WRgKR5HPbgBD5QPXwCdGvIe y7tQjljCcskfU0ESSUDDYDU= =Bu7j -----END PGP SIGNATURE----- --LmUak3kE33t3Bnfm-- From jsoe0708@tiscali.be Fri Aug 1 16:04:38 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Fri, 1 Aug 2003 17:04:38 +0200 Subject: [parisc-linux] testing HP-PA risc hardware In-Reply-To: <03Aug1.164945cest.119089@ns.hiscom.nl> Message-ID: <3F29178A000004B1@ocpmta7.freegates.net> Hello, > Is there a way to somehow test the hardware of a PA-Risc machine? Either > from HP or from the linux world? Onto HP CD Support plus you would be able to boot ODE (Offline Diagnostics Environement) which would allow to test wour disk and also help you to recover your system (be carefull, it is not easy) > btw: I can get debian-woody booted up to > the message that if this is the ... > VT100 mode ... VT100 works fine for me :-) hth, Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From grundler@parisc-linux.org Fri Aug 1 16:22:37 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 1 Aug 2003 09:22:37 -0600 Subject: [parisc-linux] How to install X on 715/50 -- problem with twm In-Reply-To: <20030801090533.GK727@sleepie.demon.co.uk> References: <5.2.1.1.2.20030731163951.00b423d0@127.0.0.1> <20030801090533.GK727@sleepie.demon.co.uk> Message-ID: <20030801152237.GA11080@dsl2.external.hp.com> On Fri, Aug 01, 2003 at 10:05:33AM +0100, Richard Hirst wrote: > Well, it's twm that has the problem, not XFree86. Maybe we don't use > twm. that's right. I use fvwm2 instead. A bit harder to configure but all my parisc boxes have enough mem to handle workspaces. > Looks like menu is indeed not in woody, but is in sarge and sid; > iirc it is a c++ program that we used to have trouble building. correct. For parisc, my preference is to run "sarge" since so much stuff has been fixed since woody released. hth, grant From jsoe0708@tiscali.be Fri Aug 1 16:28:00 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Fri, 1 Aug 2003 17:28:00 +0200 Subject: [parisc-linux] backport bitops.h stuff Message-ID: <3F29178A000004C6@ocpmta7.freegates.net> Hi pa, Can somebody help me to ci inot 2.4 this patch which backport ffs() needed for new devmapper ;) --- bitops.h.orig 2003-08-01 15:25:02.000000000 +0200 +++ bitops.h 2003-08-01 15:27:38.000000000 +0200 @@ -208,13 +208,34 @@ #ifdef __KERNEL__ +/** + * __ffs - find first bit in word. + * @word: The word to search + * + * Undefined if no bit exists, so code should check against 0 first. + */ +static __inline__ unsigned long __ffs(unsigned long word) +{ + unsigned long result = 0; + + while (!(word & 1UL)) { + result++; + word >>= 1; + } + return result; +} + /* * ffs: find first bit set. This is defined the same way as * the libc and compiler builtin ffs routines, therefore * differs in spirit from the above ffz (man ffs). */ - -#define ffs(x) generic_ffs(x) +static __inline__ int ffs(int x) +{ + if (!x) + return 0; + return __ffs((unsigned long)x); +} /* * hweightN: returns the hamming weight (i.e. the number Thanks in advance, Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From jsoe0708@tiscali.be Fri Aug 1 16:35:43 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Fri, 1 Aug 2003 17:35:43 +0200 Subject: [parisc-linux] backport bitops.h stuff In-Reply-To: <3F29178A000004C6@ocpmta7.freegates.net> Message-ID: <3F29178A000004CB@ocpmta7.freegates.net> --========/3F29178A000004CB/mail.tiscali.be Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi pa, >Can somebody help me to ci inot 2.4 this patch which backport ffs() needed >for new devmapper ;) Again I forget to attach the patch file, sorry. Joel PS: Now I have an ADSL connection at home, may be could I now ask an account to ci those kind of armless stuff ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr --========/3F29178A000004CB/mail.tiscali.be Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bitops.h-patch" LS0tIGJpdG9wcy5oLm9yaWcJMjAwMy0wOC0wMSAxNToyNTowMi4wMDAwMDAwMDAgKzAyMDAKKysr IGJpdG9wcy5oCTIwMDMtMDgtMDEgMTU6Mjc6MzguMDAwMDAwMDAwICswMjAwCkBAIC0yMDgsMTMg KzIwOCwzNCBAQAogCiAjaWZkZWYgX19LRVJORUxfXwogCisvKioKKyAqIF9fZmZzIC0gZmluZCBm aXJzdCBiaXQgaW4gd29yZC4KKyAqIEB3b3JkOiBUaGUgd29yZCB0byBzZWFyY2gKKyAqCisgKiBV bmRlZmluZWQgaWYgbm8gYml0IGV4aXN0cywgc28gY29kZSBzaG91bGQgY2hlY2sgYWdhaW5zdCAw IGZpcnN0LgorICovCitzdGF0aWMgX19pbmxpbmVfXyB1bnNpZ25lZCBsb25nIF9fZmZzKHVuc2ln bmVkIGxvbmcgd29yZCkKK3sKKwl1bnNpZ25lZCBsb25nIHJlc3VsdCA9IDA7CisKKwl3aGlsZSAo ISh3b3JkICYgMVVMKSkgeworCQlyZXN1bHQrKzsKKwkJd29yZCA+Pj0gMTsKKwl9CisJcmV0dXJu IHJlc3VsdDsKK30KKwogLyoKICAqIGZmczogZmluZCBmaXJzdCBiaXQgc2V0LiBUaGlzIGlzIGRl ZmluZWQgdGhlIHNhbWUgd2F5IGFzCiAgKiB0aGUgbGliYyBhbmQgY29tcGlsZXIgYnVpbHRpbiBm ZnMgcm91dGluZXMsIHRoZXJlZm9yZQogICogZGlmZmVycyBpbiBzcGlyaXQgZnJvbSB0aGUgYWJv dmUgZmZ6IChtYW4gZmZzKS4KICAqLwotCi0jZGVmaW5lIGZmcyh4KSBnZW5lcmljX2Zmcyh4KQor c3RhdGljIF9faW5saW5lX18gaW50IGZmcyhpbnQgeCkKK3sKKwlpZiAoIXgpCisJCXJldHVybiAw OworCXJldHVybiBfX2ZmcygodW5zaWduZWQgbG9uZyl4KTsKK30KIAogLyoKICAqIGh3ZWlnaHRO OiByZXR1cm5zIHRoZSBoYW1taW5nIHdlaWdodCAoaS5lLiB0aGUgbnVtYmVyCg== --========/3F29178A000004CB/mail.tiscali.be-- From James.Bottomley@steeleye.com Fri Aug 1 16:59:02 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 01 Aug 2003 10:59:02 -0500 Subject: [parisc-linux] backport bitops.h stuff In-Reply-To: <3F29178A000004C6@ocpmta7.freegates.net> References: <3F29178A000004C6@ocpmta7.freegates.net> Message-ID: <1059753543.2092.30.camel@mulgrave> On Fri, 2003-08-01 at 10:28, Joel Soete wrote: > Can somebody help me to ci inot 2.4 this patch which backport ffs() needed > for new devmapper ;) Actually, this patch looks decidedly non-optimal. See include/linux/bitops.h:generic_ffs for how it should be done on architectures that don't have any machine instruction help. That's only four if statements and no loop. I see we already have the loop thing in 2.5, but should we consider simply using the generic operations there as well? even for __ffs, which is just a slight optimisation over ffs, using generic_ffs would probably be faster James From lamont@smallone.fc.hp.com Fri Aug 1 17:22:55 2003 From: lamont@smallone.fc.hp.com (LaMont Jones) Date: Fri, 1 Aug 2003 10:22:55 -0600 Subject: [parisc-linux] __arch__swab24() Message-ID: <20030801162255.GA28998@smallone.fc.hp.com> The following patch implements __arch__swab24() optimally for hppa. It also has the side effect of making some other things happier. :-) Any comments before I commit it to 2.4 and 2.5? lamont Index: include/asm-parisc/byteorder.h =================================================================== RCS file: /var/cvs/linux/include/asm-parisc/byteorder.h,v retrieving revision 1.7 diff -u -r1.7 byteorder.h --- include/asm-parisc/byteorder.h 8 Jul 2003 16:50:09 -0000 1.7 +++ include/asm-parisc/byteorder.h 1 Aug 2003 16:25:00 -0000 @@ -14,6 +14,17 @@ return x; } +static __inline__ __const__ __u32 ___arch__swab24(__u32 x) +{ + unsigned int temp; + __asm__("shd %0, %0, 8, %1\n\t" /* shift xabcxabc -> cxab */ + "dep %1, 15, 8, %1\n\t" /* deposit cxab -> cbab */ + "shd %r0, %1, 8, %0" /* shift 0000cbab -> 0cba */ + : "=r" (x), "=&r" (temp) + : "0" (x)); + return x; +} + static __inline__ __const__ __u32 ___arch__swab32(__u32 x) { unsigned int temp; @@ -63,6 +74,7 @@ #endif #define __arch__swab16(x) ___arch__swab16(x) +#define __arch__swab24(x) ___arch__swab24(x) #define __arch__swab32(x) ___arch__swab32(x) #endif /* __GNUC__ */ From willy@debian.org Fri Aug 1 18:00:22 2003 From: willy@debian.org (Matthew Wilcox) Date: Fri, 1 Aug 2003 18:00:22 +0100 Subject: [parisc-linux] __arch__swab24() In-Reply-To: <20030801162255.GA28998@smallone.fc.hp.com> References: <20030801162255.GA28998@smallone.fc.hp.com> Message-ID: <20030801170022.GX22222@parcelfarce.linux.theplanet.co.uk> On Fri, Aug 01, 2003 at 10:22:55AM -0600, LaMont Jones wrote: > Any comments before I commit it to 2.4 and 2.5? Here's what I came up with based on your patch. It's embedded in a test program. #include typedef int __u32; static int vanilla_swab24(int i) { return ((i & 0xff) << 16) | (i & 0xff00) | ((i & 0xff0000) >> 16); } static __inline__ __const__ __u32 ___arch__swab24(__u32 x) { __asm__("shd %0, %0, 8, %0\n\t" /* shift xabcxabc -> cxab */ "dep %0, 15, 8, %0\n\t" /* deposit cxab -> cbab */ "shd %%r0, %0, 8, %0" /* shift 0000cbab -> 0cba */ : "=r" (x) : "0" (x)); return x; } int main(void) { int i; for (i = 0; i < 0x1ffffff; i++) { if (___arch__swab24(i) != vanilla_swab24(i)) printf("Problem with i = %d\n", i); } return 0; } -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From jsoe0708@tiscali.be Fri Aug 1 18:09:37 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Fri, 1 Aug 2003 19:09:37 +0200 Subject: [parisc-linux] backport bitops.h stuff In-Reply-To: <1059753543.2092.30.camel@mulgrave> Message-ID: <3F29178A000004FF@ocpmta7.freegates.net> > Actually, this patch looks decidedly non-optimal. > See include/linux/bitops.h:generic_ffs for how it should be done on > architectures that don't have any machine instruction help. That's only > four if statements and no loop. Yes it was like this (just a lake of #include ) into 2.4 Why was it is changed in 2.5? > I see we already have the loop thing in 2.5, but should we consider > simply using the generic operations there as well? > even for __ffs, which is just a slight optimisation over ffs, using > generic_ffs would probably be faster If I have time next week I can test your idea. Thanks, Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From lamont@hp.com Fri Aug 1 18:14:26 2003 From: lamont@hp.com (LaMont Jones) Date: Fri, 1 Aug 2003 11:14:26 -0600 Subject: [parisc-linux] backport bitops.h stuff In-Reply-To: <3F29178A000004FF@ocpmta7.freegates.net> References: <1059753543.2092.30.camel@mulgrave> <3F29178A000004FF@ocpmta7.freegates.net> Message-ID: <20030801171426.GA18508@security.hp.com> On Fri, Aug 01, 2003 at 07:09:37PM +0200, Joel Soete wrote: > > Actually, this patch looks decidedly non-optimal. Here's a more optimal ffs() routine for hppa, along with the output from the test program... Should run in ~15 states on just about anything [yes, it's that lock-stepped that it'll take about 15 states on PA-8000's as well.. :-(] Freshly coded, since the hp-ux version (which I can't find anymore) looked for most significant set bit, not least. lamont #include int fastffs(int x) { int ret; __asm__(" ldi 31,%1\n" " extru,<> %0,31,16,%%r0\n" " extru,TR %0,15,16,%0\n" " addi -16,%1,%1\n" " extru,<> %0,31,8,%%r0\n" " extru,TR %0,23,8,%0\n" " addi -8,%1,%1\n" " extru,<> %0,31,4,%%r0\n" " extru,TR %0,27,4,%0\n" " addi -4,%1,%1\n" " extru,<> %0,31,2,%%r0\n" " extru,TR %0,29,2,%0\n" " addi -2,%1,%1\n" " extru,= %0,31,1,%%r0\n" " addi -1,%1,%1\n" : "=r" (x), "=r" (ret) : "0" (x), "1" (ret)); return ret; } doffs(x) { printf("fastffs(%x)==%d\n",x,fastffs(x)); } main() { int i; for (i=0;i<5;i++) doffs(i); for (;i;i<<=1) doffs(i); } ffs(0)==31 ffs(1)==0 ffs(2)==1 ffs(3)==0 ffs(4)==2 ffs(5)==0 ffs(a)==1 ffs(14)==2 ffs(28)==3 ffs(50)==4 ffs(a0)==5 ffs(140)==6 ffs(280)==7 ffs(500)==8 ffs(a00)==9 ffs(1400)==10 ffs(2800)==11 ffs(5000)==12 ffs(a000)==13 ffs(14000)==14 ffs(28000)==15 ffs(50000)==16 ffs(a0000)==17 ffs(140000)==18 ffs(280000)==19 ffs(500000)==20 ffs(a00000)==21 ffs(1400000)==22 ffs(2800000)==23 ffs(5000000)==24 ffs(a000000)==25 ffs(14000000)==26 ffs(28000000)==27 ffs(50000000)==28 ffs(a0000000)==29 ffs(40000000)==30 ffs(80000000)==31 From jsoe0708@tiscali.be Fri Aug 1 18:21:02 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Fri, 1 Aug 2003 19:21:02 +0200 Subject: [parisc-linux] __arch__swab24() In-Reply-To: <20030801170022.GX22222@parcelfarce.linux.theplanet.co.uk> Message-ID: <3F29178A00000509@ocpmta7.freegates.net> >> On Fri, Aug 01, 2003 at 10:22:55AM -0600, LaMont Jones wrote: >> Any comments before I commit it to 2.4 and 2.5? > >Here's what I came up with based on your patch. It's embedded in a >test program. [...] ? no pb on my b180 (32bits kernel 2.4.21-pa6) Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From jsoe0708@tiscali.be Fri Aug 1 18:25:05 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Fri, 1 Aug 2003 19:25:05 +0200 Subject: [parisc-linux] backport bitops.h stuff In-Reply-To: <20030801171426.GA18508@security.hp.com> Message-ID: <3F29178A0000050C@ocpmta7.freegates.net> >Here's a more optimal ffs() routine for hppa, along with the >output from the test program... Should run in ~15 states on >just about > anything [yes, it's that lock-stepped that it'll >take about 15 states on PA-8000's as well.. :-(] > >Freshly coded, since the hp-ux version (which I can't find >anymore) looked for most significant set bit, not least. Thanks, I will test it on next week, Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From James.Bottomley@steeleye.com Fri Aug 1 18:33:24 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 01 Aug 2003 12:33:24 -0500 Subject: [parisc-linux] backport bitops.h stuff In-Reply-To: <20030801171426.GA18508@security.hp.com> References: <1059753543.2092.30.camel@mulgrave> <3F29178A000004FF@ocpmta7.freegates.net> <20030801171426.GA18508@security.hp.com> Message-ID: <1059759205.1830.44.camel@mulgrave> On Fri, 2003-08-01 at 12:14, LaMont Jones wrote: > ffs(0)==31 > ffs(1)==0 > ffs(2)==1 > ffs(3)==0 > ffs(4)==2 > ffs(80000000)==31 This is off by one. The definition should say ffs(0) == 0 ffs(1) == 1 ffs(2) == 2 ffs(4) == 3 ... ffs(0x80000000) == 32 i.e. it returns the first set bit starting counting at one. (Yes, I know it's confusing, it's tripped me up, especially as ffz counts bits from zero. However, ffs is a BSD standard). Most arch's start by defining an __ffs which is not defined for the zero case and then build the real ffs from that. James From grundler@parisc-linux.org Sat Aug 2 00:44:07 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 1 Aug 2003 17:44:07 -0600 Subject: [parisc-linux] How to install X on 715/50 -- problem with twm In-Reply-To: <5.2.1.1.2.20030801102211.00b44308@127.0.0.1> References: <20030801090533.GK727@sleepie.demon.co.uk> <5.2.1.1.2.20030731163951.00b423d0@127.0.0.1> <20030801090533.GK727@sleepie.demon.co.uk> <5.2.1.1.2.20030801102211.00b44308@127.0.0.1> Message-ID: <20030801234407.GB20826@dsl2.external.hp.com> On Fri, Aug 01, 2003 at 10:22:46AM -0700, Greg Anderson wrote: > At 09:22 AM 8/1/2003 -0600, you wrote: > >correct. For parisc, my preference is to run "sarge" since so much > >stuff has been fixed since woody released. > > Thanks for the reply. Now can you tell me how to obtain "sarge." > Geez, I really *am* a n00bie! ;-) edit /etc/apt/sources.list and substitute "sarge" for "stable". then apt-get update apt-get dist-upgrade You might to learn how to run dselect and run that as well. it seems to do a better job with dependencies. grant From varenet@esiee.fr Sat Aug 2 01:10:30 2003 From: varenet@esiee.fr (Thibaut VARENE) Date: Sat, 2 Aug 2003 02:10:30 +0200 Subject: [parisc-linux] How to install X on 715/50 -- problem with twm In-Reply-To: <20030801234407.GB20826@dsl2.external.hp.com> References: <20030801090533.GK727@sleepie.demon.co.uk> <5.2.1.1.2.20030731163951.00b423d0@127.0.0.1> <20030801090533.GK727@sleepie.demon.co.uk> <5.2.1.1.2.20030801102211.00b44308@127.0.0.1> <20030801234407.GB20826@dsl2.external.hp.com> Message-ID: <20030802021030.29e587c8.varenet@esiee.fr> On Fri, 1 Aug 2003 17:44:07 -0600 Grant Grundler wrote: > On Fri, Aug 01, 2003 at 10:22:46AM -0700, Greg Anderson wrote: > > At 09:22 AM 8/1/2003 -0600, you wrote: > > >correct. For parisc, my preference is to run "sarge" since so much > > >stuff has been fixed since woody released. > > > > Thanks for the reply. Now can you tell me how to obtain "sarge." > > Geez, I really *am* a n00bie! ;-) > > edit /etc/apt/sources.list and substitute "sarge" for "stable". > > then > apt-get update > apt-get dist-upgrade > > You might to learn how to run dselect and run that as well. > it seems to do a better job with dependencies. > Hmm, if Greg wants to go from stable to sarge, he wants to substitute "stable" for "sarge", or am I wrong ? :) HTH, Thibaut VARENE The PA/Linux ESIEE Team http://pateam.esiee.fr/ From Javier Kyle" --EDA.C5B642DF16.4_ Content-Type: text/html; Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxib2R5Pg0KDQo8Zm9udCBzaXplPSIyIj5ibGVtaXNoZGVkdWN0eHZpZnVt YSBieHdkemoNCiBrIGdwIHVtIA0KdXVyYmZwc2V4ZXIgYm88L2ZvbnQ+PHAgYWxpZ249ImNl bnRlciI+SGksIFBhcmlzYy1saW51eCwgRG8geW91IHdhbnQgYQ0KZ29sZHZpc2FjYXJkPzxi cj4NCjxjZW50ZXI+SWYgeW91IGNhbid0IGdldCBhIGNyZWRpdGNhcmQgb3I8YnI+DQpqdXN0 IG5lZWQgYW5vdGhlci4gTm8gdHVybiBEb3duITxicj4NClRoZSBlY29ub215IGlzIHRvdWdo IE5vIHNlY3VyaXR5IGRlcG9zaXRzIE5vIGZpbmFuY2UgY2hhcmdlczxicj4NClNvIG1ha2Ug WW91ciBMaWZlIG5vIHByb2JsZW08L2NlbnRlcj48YnI+DQo8Y2VudGVyPlRoaXMgaXMgWW91 ciBDaGFuY2UgdG8gQ2hhbmdlIFlvdXIgbGlmZSEgdG8gPGEgaHJlZj0iaHR0cDovL3d3dy5z aW1wbGVjYXJkLmJpeiI+c2VlDQpub3c8L2E+PC9jZW50ZXI+PC9wPg0KPHAgYWxpZ249ImNl bnRlciI+DQo8YSBocmVmPSJodHRwOi8vd3d3LnNpbXBsZWNhcmQuYml6Ij4NCjxpbWcgYm9y ZGVyPSIwIiBzcmM9Imh0dHA6Ly93d3cuc2ltcGxlY2FyZC5iaXovY3JlZGl0LmdpZiIgYWx0 PSJhc2RmYXMgc2FkZmFzZGYgYXNmYXNkYSBhc2RmYXNkZiBzZmRzZGYgYXNmZGFzZGZhc2Rm IGFzZmRhc2RmYXMgIj48L2E+PC9wPg0KPHA+PGEgaHJlZj0iaHR0cDovL3NpbXBsZWNhcmQu Yml6L3B1bmlzaC91bnN1dWJzY3JpYmUucGhwIj5uIG8gbSBhIGkgbDwvYT48L3A+DQoNCjxm b250IHNpemU9IjIiPnRyYW5zcG9zYWJsZWluZGllcyZuYnNwOw0KPC9mb250Pg0KPHA+DQoN Cjxmb250IHNpemU9IjIiPnNlcnZvZ3Vtc2hvZQ0KPC9mb250Pg0KPC9wPg0KPHA+PGZvbnQg c2l6ZT0iMiI+dGFvaXN0c2V2aWxsZTwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIj50 bHVtbCBza3Bpb3diZXdtcW92cnZldiBpbnZvbHV0ZTwvZm9udD48L3A+DQo8cD48Zm9udCBz aXplPSIyIj5jYXRpb255cWdpbXh6aXdtIGZnd2NyaiAgbmwgIHhxdnogdSBrZiAgbHNrciA8 L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiI+Z3VhcmRpYW5wYXN0cnk8L2ZvbnQ+PC9w Pg0KPHA+PGZvbnQgc2l6ZT0iMiI+Y29uc3VsdHNjYW08L2ZvbnQ+PC9wPg0KPC9ib2R5Pg0K PC9odG1sPg0KbnF2d2Rldmd1aW5wenNxYg0KDQpnYmJjDQpteCBzDQogIHJ6d3Eg --EDA.C5B642DF16.4_-- From jbglaw@lug-owl.de Sat Aug 2 09:11:35 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Sat, 2 Aug 2003 10:11:35 +0200 Subject: [parisc-linux] k-2.6.0-test2-pa0: __canonicalize_f_f_c patch In-Reply-To: <3F056E95000057BB@ocpmta4.freegates.net> References: <3F056E95000057BB@ocpmta4.freegates.net> Message-ID: <20030802081135.GJ1873@lug-owl.de> --cgXXEQ20Gie/H8Jj Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2003-07-28 16:30:14 +0200, Joel Soete wrote in message <3F056E95000057BB@ocpmta4.freegates.net>: Hi! > + > + .export __canonicalize_funcptr_for_compare > + .text > + /* http://lists.parisc-linux.org/hypermail/parisc-linux/10916.html > + ** GCC 3.3 and later has a new function in libgcc.a for > + ** comparing function pointers. > + */ > +__canonicalize_funcptr_for_compare: > +#ifdef __LP64__ > + bve (%r2) > +#else > + bv %r0(%r2) > +#endif > + copy %r26,%r28 Is this now checked in? At my last cvs update (:pserver:anonymous@cvs.parisc-linux.org/var/cvs, linux-2.5), this hasn't shown up... By the way, is anybody here going to go to Oldenburg(.de) to join the developer's meeting[1]? MfG, JBG [1] http://oldenburger.linuxtage.de/devel.html --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); --cgXXEQ20Gie/H8Jj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/K3I2Hb1edYOZ4bsRAhiLAKCJnfCQKhokGN/1yd3y4YIjfZq77QCgjNBS Ruqsl4rewW5QyfcKfhU2YK0= =aCpO -----END PGP SIGNATURE----- --cgXXEQ20Gie/H8Jj-- From pappy@nikita.ath.cx Sun Aug 3 21:22:18 2003 From: pappy@nikita.ath.cx (Alexander Gabert) Date: Sun, 3 Aug 2003 22:22:18 +0200 Subject: [parisc-linux] grsecurity 1.9.11 patches for 2.4.21pa8 Message-ID: <20030803202217.GA16476@nikita.ath.cx> hi lists, i just finished and tested the grsecurity porting of 1.9.11 to parisc. http://nikita.ath.cx/users/pappy/grsecurity-parisc/parisc-linux-2.4.21-pa8-grsecurity-1.9.11.patch it is supposed to be one of the last (if not the last) splitbrain grsecurity kernel patch to parisc-linux source. Thanks to Randolph Chung (tausq), Matthew Wilcox (willy), pipacs, spender and all the other developers who helped me getting used to parisc-linux and the grsecurity patches, thus bridging the gap between the parisc-linux.org kernel and the vanilla tree for this security oriented linux patch. i hope that 2.6.x will have parisc-linux melted into the mainstream kernel and thus grsecurity patches will apply natively to the kernel. then this work will not be needed any more and i can sit back and relax. thank you all, Alex -- A long-forgotten loved one will appear soon. Buy the negatives at any price. From ard@kwaak.net Mon Aug 4 06:47:56 2003 From: ard@kwaak.net (Ard van Breemen) Date: Mon, 4 Aug 2003 07:47:56 +0200 Subject: [parisc-linux] A4308A nic Message-ID: <20030804054756.GO27784@kwaak.net> Hi, I just installed debian on my D250. Those guys making the network install realy did a good job... It almost worked out of the box. The only cullprit was that it crashed on a bluefish FWD scsi controller not having any terminators on the bus... Allright, But now I see this A4308A, a real surprising card, and what I find more surprising is that I did not find it on the mailinglist. The card is an EISA card, which contains a PLX EISA9032, probably an EISA to PCI bridge (and not v.v.!), an intel 82556, and an LSI L5A4242. I can understand the plx and the intel, but the LSI? If I search for these items, I find some 3com EISA cards with the LSI L5A4242 for sale, not mentioning the intel etc. ... So I reckon the LSI should be some kind of processor? I've got some pictures of it (in a few hours actually, my upstream is not that big): http://nerdcentral.nerdnet.nl/~avb/2003-08-04.00/ Things I want: - Any confirmation that it is not supported yet. (Eh, and of course that I am not making a fool of myself because I could have RTFMd :-) ). - Anyone with docs on the 3com card. - If possible on the A4308A card. - PLX EISA9032, I cannot find it on www.plxtech.com... And thanks for giving me the pleasure for having an hp9000 :-) -- mail up 260+18:54, 8 users, load 0.00, 0.19, 0.93 mistar1 down 29+18:54 Let your government know you value your freedom: sign the petition: http://petition.eurolinux.org From Estelle Riggs" --_DACE__.307AEDDC_D21C Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Get prescription me= dications online
shipped overnight to your door with no doctor visit
phentermine, ultram, xenical and = more

--_DACE__.307AEDDC_D21C-- From LAssinovsky@algorithm.aelita.com Mon Aug 4 11:37:13 2003 From: LAssinovsky@algorithm.aelita.com (Lev Assinovsky) Date: Mon, 4 Aug 2003 14:37:13 +0400 Subject: [parisc-linux] Help: Need instruction sequence for gdb breakpoint Message-ID: <3F6F4712B759A34ABD453A8B39C10D62C4670F@bagman.edm.com> Hello all! I badly need pa-risc 1.1 instruction sequence suitable for gdb. I would like to implement "hard breakpoint".=20 I tried "BREAK 4,8" - gdb stops but can't continue. Any help will be appreciated! Sincerely,=20 ---- Lev Assinovsky Aelita Software Corporation O&S Core Division, Programmer ICQ# 165072909 From jsoe0708@tiscali.be Mon Aug 4 11:43:10 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Mon, 4 Aug 2003 12:43:10 +0200 Subject: [parisc-linux] backport bitops.h stuff In-Reply-To: <20030801171426.GA18508@security.hp.com> Message-ID: <3F29178A00000A99@ocpmta7.freegates.net> Hi pa, Here is a combine test case: #include /** * __ffs - find first bit in word. * @word: The word to search * * Undefined if no bit exists, so code should check against 0 first. */ /* static __inline__ unsigned long ffs26(unsigned long word) */ unsigned long ffs_hppa26(unsigned long word) { unsigned long result = 0; if (word) /* I add this exception condition */ while (!(word & 1UL)) { result++; word >>= 1; } return result; } /* * ffs: find first bit set. This is defined the same way as * the libc and compiler builtin ffs routines, therefore * differs in spirit from the above ffz (man ffs). */ static inline int generic_ffs(int x) { int r = 1; if (!x) return 0; if (!(x & 0xffff)) { x >>= 16; r += 16; } if (!(x & 0xff)) { x >>= 8; r += 8; } if (!(x & 0xf)) { x >>= 4; r += 4; } if (!(x & 3)) { x >>= 2; r += 2; } if (!(x & 1)) { x >>= 1; r += 1; } return r; } int fastffs(int x) { int ret=0; __asm__(" ldi 31,%1\n" " extru,<> %0,31,16,%%r0\n" " extru,TR %0,15,16,%0\n" " addi -16,%1,%1\n" " extru,<> %0,31,8,%%r0\n" " extru,TR %0,23,8,%0\n" " addi -8,%1,%1\n" " extru,<> %0,31,4,%%r0\n" " extru,TR %0,27,4,%0\n" " addi -4,%1,%1\n" " extru,<> %0,31,2,%%r0\n" " extru,TR %0,29,2,%0\n" " addi -2,%1,%1\n" " extru,= %0,31,1,%%r0\n" " addi -1,%1,%1\n" : "=r" (x), "=r" (ret) : "0" (x), "1" (ret)); return ret; } doffs(x) { printf("fastffs(%d)==%d\n",x,fastffs(x)); printf("ffs_hppa26(%d)==%d\n",x,ffs_hppa26(x)); printf("generic_ffs(%d)==%d\n",x,generic_ffs(x)); printf("\n"); } main() { int i; for (i=0;i<5;i++) doffs(i); for (;i;i<<=1) doffs(i); } And I am confused by results: fastffs(0)==31 ffs_hppa26(0)==0 generic_ffs(0)==0 I presume that we also have to consider an exception for 0? [...] fastffs(1)==0 ffs_hppa26(1)==0 generic_ffs(1)==1 fastffs(2)==1 ffs_hppa26(2)==1 generic_ffs(2)==2 fastffs(3)==0 ffs_hppa26(3)==0 generic_ffs(3)==1 fastffs(4)==2 ffs_hppa26(4)==2 generic_ffs(4)==3 [...] So in all other case fastffs or ffs_hppa26 == generic_ffs - 1. What is right? Thanks for additional attention, Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From lamont@hp.com Mon Aug 4 16:14:49 2003 From: lamont@hp.com (LaMont Jones) Date: Mon, 4 Aug 2003 09:14:49 -0600 Subject: [parisc-linux] backport bitops.h stuff In-Reply-To: <3F29178A00000A99@ocpmta7.freegates.net> References: <20030801171426.GA18508@security.hp.com> <3F29178A00000A99@ocpmta7.freegates.net> Message-ID: <20030804151449.GS18508@security.hp.com> On Mon, Aug 04, 2003 at 12:43:10PM +0200, Joel Soete wrote: > int ret=0; > __asm__(" ldi 31,%1\n" Make it say 32,%1... Mistake in understanding things on my part... > And I am confused by results: > fastffs(0)==31 > ffs_hppa26(0)==0 > generic_ffs(0)==0 > > I presume that we also have to consider an exception for 0? yes. lamont From James.Bottomley@steeleye.com Mon Aug 4 17:08:01 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 04 Aug 2003 11:08:01 -0500 Subject: [parisc-linux] backport bitops.h stuff In-Reply-To: <20030804151449.GS18508@security.hp.com> References: <20030801171426.GA18508@security.hp.com> <3F29178A00000A99@ocpmta7.freegates.net> <20030804151449.GS18508@security.hp.com> Message-ID: <1060013284.1983.32.camel@fuzzy> Let me try to clarify, since there are two differently defined macros in the kernel (off by one) that would appear to have the same interface, but which in fact have different semantics (I know, recipe for disaster): ffs and ffz (meaning find first set and find first zero). Both tend to have machine code implementations for architectures that support them. The difference is that ffz counts bit zero as zero, but ffz counts bit zero as one. They also have different requirements for the error case (no bit set for ffs and no bit zero for ffz). For ffs, this is defined to be 32. For ffz, this is undefined. The reason for all of this is that on x86 there is an instruction bsfl that actually finds first set bit (but counting from zero, not one), but the O(1) scheduler needed to find clear bits for the arrays, so ffz was implemented as the complement of this. ffs has been around a long time (inherited from BSD). The differing semantics are because "damnit, computers count from zero not one for fast operations". i.e. ffs(0) == 0 ffz(0) == 0 ffs(1) == 1 ffz(~1) == 0 (same as above ffz, bit zero clear) ffs(2) == 2 ffz(~3) == 1 [...] ffs(0x8000000) == 32 ffz(0x7ffffff) == 31 ffz(0xffffffff) == could be anything Some machine architectures have an __ffs() (usually mirroring a machine instruction) whose semantics are identical to ffs() except that it also is undefined in the error case (so ffs can simply be implemented as if not error case, do __ffs()). James From Mark.Mestdagh@Icon-Europe.com Mon Aug 4 17:51:40 2003 From: Mark.Mestdagh@Icon-Europe.com (Mark Mestdagh) Date: Mon, 4 Aug 2003 18:51:40 +0200 Subject: [parisc-linux] mobo for J5600 Message-ID: Hi it seems one of my scsi controllers broke down, so I need a new mobo. I called a local supplier (Belgium) who told it costs 2500 euro for the motherboard which includes also 2 processors. Do you have to buy this with those processors? Isn't there any other solution possible? Thx guys Mark From jsoe0708@tiscali.be Mon Aug 4 17:53:54 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Mon, 4 Aug 2003 18:53:54 +0200 Subject: [parisc-linux] backport bitops.h stuff In-Reply-To: <20030804151449.GS18508@security.hp.com> Message-ID: <3F29178A00000CB4@ocpmta7.freegates.net> >> int ret=0; >> __asm__(" ldi 31,%1\n" > >Make it say 32,%1... Mistake in understanding things on my part... Yes, the following code: int fastffs(int x) { int ret=0; if (x) __asm__(" ldi 32,%1\n" " extru,<> %0,31,16,%%r0\n" " extru,TR %0,15,16,%0\n" " addi -16,%1,%1\n" " extru,<> %0,31,8,%%r0\n" " extru,TR %0,23,8,%0\n" " addi -8,%1,%1\n" " extru,<> %0,31,4,%%r0\n" " extru,TR %0,27,4,%0\n" " addi -4,%1,%1\n" " extru,<> %0,31,2,%%r0\n" " extru,TR %0,29,2,%0\n" " addi -2,%1,%1\n" " extru,= %0,31,1,%%r0\n" " addi -1,%1,%1\n" : "=r" (x), "=r" (ret) : "0" (x), "1" (ret)); return ret; } give now the same results as generic_ffs: fastffs(0)==0 generic_ffs(0)==0 fastffs(1)==1 generic_ffs(1)==1 fastffs(2)==2 generic_ffs(2)==2 fastffs(3)==1 generic_ffs(3)==1 fastffs(4)==3 generic_ffs(4)==3 fastffs(5)==1 generic_ffs(5)==1 fastffs(10)==2 generic_ffs(10)==2 fastffs(20)==3 generic_ffs(20)==3 fastffs(40)==4 generic_ffs(40)==4 fastffs(80)==5 generic_ffs(80)==5 fastffs(160)==6 generic_ffs(160)==6 fastffs(320)==7 generic_ffs(320)==7 fastffs(640)==8 generic_ffs(640)==8 fastffs(1280)==9 generic_ffs(1280)==9 fastffs(2560)==10 generic_ffs(2560)==10 fastffs(5120)==11 generic_ffs(5120)==11 fastffs(10240)==12 generic_ffs(10240)==12 fastffs(20480)==13 generic_ffs(20480)==13 fastffs(40960)==14 generic_ffs(40960)==14 fastffs(81920)==15 generic_ffs(81920)==15 fastffs(163840)==16 generic_ffs(163840)==16 fastffs(327680)==17 generic_ffs(327680)==17 fastffs(655360)==18 generic_ffs(655360)==18 fastffs(1310720)==19 generic_ffs(1310720)==19 fastffs(2621440)==20 generic_ffs(2621440)==20 fastffs(5242880)==21 generic_ffs(5242880)==21 fastffs(10485760)==22 generic_ffs(10485760)==22 fastffs(20971520)==23 generic_ffs(20971520)==23 fastffs(41943040)==24 generic_ffs(41943040)==24 fastffs(83886080)==25 generic_ffs(83886080)==25 fastffs(167772160)==26 generic_ffs(167772160)==26 fastffs(335544320)==27 generic_ffs(335544320)==27 fastffs(671088640)==28 generic_ffs(671088640)==28 fastffs(1342177280)==29 generic_ffs(1342177280)==29 fastffs(-1610612736)==30 generic_ffs(-1610612736)==30 fastffs(1073741824)==31 generic_ffs(1073741824)==31 fastffs(-2147483648)==32 generic_ffs(-2147483648)==32 Great job. If everybody agreed could you ci (I have no cvs ci access). Or do you need a more accurate patch? Thanks, Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From jsoe0708@tiscali.be Mon Aug 4 18:04:31 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Mon, 4 Aug 2003 19:04:31 +0200 Subject: [parisc-linux] backport bitops.h stuff In-Reply-To: <1060013284.1983.32.camel@fuzzy> Message-ID: <3F29178A00000CBA@ocpmta7.freegates.net> James, Many thanks for those clear explanation, Joel > -- Original Message -- > From: James Bottomley > To: LaMont Jones > Cc: Joel Soete , parisc-linux@parisc-linux.org > Date: 04 Aug 2003 11:08:01 -0500 > Subject: Re: [parisc-linux] backport bitops.h stuff > > > Let me try to clarify, since there are two differently defined macros in the kernel (off by one) that would appear to have the same interface, but which in fact have different semantics (I know, recipe for disaster): ffs and ffz (meaning find first > set and find first zero). Both tend to have machine code implementations for architectures that support them. The difference is that ffz counts bit zero as zero, but ffz counts bit zero as one. They also have different requirements for the err > r case (no bit set for ffs and no bit zero for ffz). For ffs, this is defined to be 32. For ffz, this is undefined. The reason for all of this is that on x86 there is an instruction bsfl that actually finds first set bit (but counting from zero > not one), but the O(1) scheduler needed to find clear bits for the arrays, so ffz was implemented as the complement of this. ffs has been around a long time (inherited from BSD). The differing semantics are because "damnit, computers count from > zero not one for fast operations". i.e. ffs(0) == 0 ffz(0) == 0 ffs(1) == 1 ffz(~1) == 0 (same as above ffz, bit zero clear) ffs(2) == 2 ffz(~3) == 1 [...] ffs(0x8000000) == 32 ffz(0x7ffffff) == 31 ffz(0xffffffff) == could be > anything Some machine architectures have an __ffs() (usually mirroring a machine instruction) whose semantics are identical to ffs() except that it also is undefined in the error case (so ffs can simply be implemented as if not error case, do __f > s()). James _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From adam@the-sugarat.net Mon Aug 4 18:31:34 2003 From: adam@the-sugarat.net (Adam Henson) Date: Mon, 04 Aug 2003 18:31:34 +0100 Subject: [parisc-linux] C200 Booting Difficulties Message-ID: <3F2E9876.7090000@the-sugarat.net> Hello All, I have recently attempted to boot a debian-hppa cd on my C200 workstation. All seems to go well and the kernel boots, but just after it says that init is starting up the screen goes blank, all the lights on the case come on, and the system just hangs. Is there anything I can try to get round this? many thanks, Adam From grundler@parisc-linux.org Tue Aug 5 06:18:52 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 4 Aug 2003 23:18:52 -0600 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.5 grundler In-Reply-To: <20030805051538.E7AD6494004@palinux.hppa> References: <20030805051538.E7AD6494004@palinux.hppa> Message-ID: <20030805051852.GA20450@dsl2.external.hp.com> On Mon, Aug 04, 2003 at 11:15:38PM -0600, Grant Grundler wrote: > Log message: > 2.6.0-test2-pa6 Forward port 2.4.21 fixes > > o add probe_irq_mask() (Arnaldo Del Melo) > o add __canonicalize_funcptr_for_compare() (me) > o add hppa to list of arches for "MMAPIO" in aic7xxx (me) > o break build if get/put_user/kernel are abused (Joel Soete) Trying to keep willy happy :^) Thanks to Arnaldo/Joel for patches. grant Index: Makefile =================================================================== RCS file: /var/cvs/linux-2.5/Makefile,v retrieving revision 1.144 diff -u -p -r1.144 Makefile --- Makefile 2 Aug 2003 21:50:59 -0000 1.144 +++ Makefile 5 Aug 2003 05:10:27 -0000 @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 0 -EXTRAVERSION = -test2-pa5 +EXTRAVERSION = -test2-pa6 # *DOCUMENTATION* # To see a list of typical targets execute "make help" Index: arch/parisc/Kconfig =================================================================== RCS file: /var/cvs/linux-2.5/arch/parisc/Kconfig,v retrieving revision 1.23 diff -u -p -r1.23 Kconfig --- arch/parisc/Kconfig 14 Jul 2003 12:32:20 -0000 1.23 +++ arch/parisc/Kconfig 5 Aug 2003 05:10:27 -0000 @@ -186,7 +186,7 @@ source "drivers/scsi/Kconfig" source "drivers/md/Kconfig" -#source drivers/message/fusion/Kconfig +source drivers/message/fusion/Kconfig #source drivers/ieee1394/Kconfig Index: arch/parisc/kernel/irq.c =================================================================== RCS file: /var/cvs/linux-2.5/arch/parisc/kernel/irq.c,v retrieving revision 1.19 diff -u -p -r1.19 irq.c --- arch/parisc/kernel/irq.c 5 May 2003 21:34:24 -0000 1.19 +++ arch/parisc/kernel/irq.c 5 Aug 2003 05:10:27 -0000 @@ -842,6 +842,10 @@ int probe_irq_off(unsigned long val) return irq_found; } +unsigned int probe_irq_mask(unsigned long irqs) +{ + return 0; +} void __init init_IRQ(void) { Index: arch/parisc/kernel/parisc_ksyms.c =================================================================== RCS file: /var/cvs/linux-2.5/arch/parisc/kernel/parisc_ksyms.c,v retrieving revision 1.21 diff -u -p -r1.21 parisc_ksyms.c --- arch/parisc/kernel/parisc_ksyms.c 9 Jun 2003 02:24:25 -0000 1.21 +++ arch/parisc/kernel/parisc_ksyms.c 5 Aug 2003 05:10:27 -0000 @@ -37,6 +37,7 @@ EXPORT_SYMBOL(get_pci_node_path); #include EXPORT_SYMBOL(enable_irq); EXPORT_SYMBOL(disable_irq); +EXPORT_SYMBOL(probe_irq_mask); #include EXPORT_SYMBOL(kernel_thread); @@ -200,6 +201,9 @@ EXPORT_SYMBOL(__ashrdi3); EXPORT_SYMBOL(__ashldi3); EXPORT_SYMBOL(__lshrdi3); EXPORT_SYMBOL(__muldi3); + +asmlinkage void * __canonicalize_funcptr_for_compare(void *); +EXPORT_SYMBOL_NOVERS(__canonicalize_funcptr_for_compare); #ifdef __LP64__ extern void __divdi3(void); Index: arch/parisc/kernel/real2.S =================================================================== RCS file: /var/cvs/linux-2.5/arch/parisc/kernel/real2.S,v retrieving revision 1.4 diff -u -p -r1.4 real2.S --- arch/parisc/kernel/real2.S 14 Jul 2003 15:21:07 -0000 1.4 +++ arch/parisc/kernel/real2.S 5 Aug 2003 05:10:27 -0000 @@ -275,6 +275,7 @@ r64_ret: nop #endif + .export pc_in_user_space .text /* Doesn't belong here but I couldn't find a nicer spot. */ @@ -283,3 +284,17 @@ pc_in_user_space: bv,n 0(%rp) nop + + .export __canonicalize_funcptr_for_compare + .text + /* http://lists.parisc-linux.org/hypermail/parisc-linux/10916.html + ** GCC 3.3 and later has a new function in libgcc.a for + ** comparing function pointers. + */ +__canonicalize_funcptr_for_compare: +#ifdef __LP64__ + bve (%r2) +#else + bv %r0(%r2) +#endif + copy %r26,%r28 Index: drivers/scsi/aic7xxx/aic79xx_osm.h =================================================================== RCS file: /var/cvs/linux-2.5/drivers/scsi/aic7xxx/aic79xx_osm.h,v retrieving revision 1.9 diff -u -p -r1.9 aic79xx_osm.h --- drivers/scsi/aic7xxx/aic79xx_osm.h 27 Jul 2003 19:55:52 -0000 1.9 +++ drivers/scsi/aic7xxx/aic79xx_osm.h 5 Aug 2003 05:10:28 -0000 @@ -590,7 +590,8 @@ ahd_delay(long usec) /***************************** Low Level I/O **********************************/ -#if defined(__powerpc__) || defined(__i386__) || defined(__ia64__) +#if defined(__powerpc__) || defined(__i386__) || defined(__ia64__) \ + || defined(__hppa__) #define MMAPIO #endif Index: include/asm-parisc/uaccess.h =================================================================== RCS file: /var/cvs/linux-2.5/include/asm-parisc/uaccess.h,v retrieving revision 1.7 diff -u -p -r1.7 uaccess.h --- include/asm-parisc/uaccess.h 12 Jan 2003 08:24:26 -0000 1.7 +++ include/asm-parisc/uaccess.h 5 Aug 2003 05:10:29 -0000 @@ -28,6 +28,11 @@ * that put_user is the same as __put_user, etc. */ +extern int __get_kernel_bad(void); +extern int __get_user_bad(void); +extern int __put_kernel_bad(void); +extern int __put_user_bad(void); + #define access_ok(type,addr,size) (1) #define verify_area(type,addr,size) (0) @@ -35,8 +40,8 @@ #define get_user __get_user #if BITS_PER_LONG == 32 -#define LDD_KERNEL(ptr) BUG() -#define LDD_USER(ptr) BUG() +#define LDD_KERNEL(ptr) __get_kernel_bad(); +#define LDD_USER(ptr) __get_user_bad(); #define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,ptr) #define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr) #else @@ -72,7 +77,7 @@ struct exception_table_entry { case 2: __get_kernel_asm("ldh",ptr); break; \ case 4: __get_kernel_asm("ldw",ptr); break; \ case 8: LDD_KERNEL(ptr); break; \ - default: BUG(); break; \ + default: __get_kernel_bad(); break; \ } \ } \ else { \ @@ -81,7 +86,7 @@ struct exception_table_entry { case 2: __get_user_asm("ldh",ptr); break; \ case 4: __get_user_asm("ldw",ptr); break; \ case 8: LDD_USER(ptr); break; \ - default: BUG(); break; \ + default: __get_user_bad(); break; \ } \ } \ \ @@ -141,7 +146,7 @@ struct exception_table_entry { case 2: __put_kernel_asm("sth",x,ptr); break; \ case 4: __put_kernel_asm("stw",x,ptr); break; \ case 8: STD_KERNEL(x,ptr); break; \ - default: BUG(); break; \ + default: __put_kernel_bad(); break; \ } \ } \ else { \ @@ -150,7 +155,7 @@ struct exception_table_entry { case 2: __put_user_asm("sth",x,ptr); break; \ case 4: __put_user_asm("stw",x,ptr); break; \ case 8: STD_USER(x,ptr); break; \ - default: BUG(); break; \ + default: __put_user_bad(); break; \ } \ } \ \ From grundler@parisc-linux.org Tue Aug 5 06:59:19 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 4 Aug 2003 23:59:19 -0600 Subject: [parisc-linux] stale references to io_request_lock Message-ID: <20030805055919.GA21815@dsl2.external.hp.com> Willy, your favorite scsi driver still has references to io_request_lock in it's comments: ... * The whole SCSI sub-system under Linux is basically single-threaded. * Everything, including low-level driver interrupt routine, happens * with the `io_request_lock' held. ... I was looking at what else might not have been forward ported and stumbled across this reference. Care to delete it? thanks, grant From c.beerse@torex-hiscom.nl Tue Aug 5 11:49:45 2003 From: c.beerse@torex-hiscom.nl (Beerse, Corne) Date: Tue, 5 Aug 2003 12:49:45 +0200 Subject: Summary: [HPADM][parisc-linux] testing HP-PA risc hardware Message-ID: <03Aug5.131008cest.119165@ns.hiscom.nl> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35B3F.48453BF0 Content-Type: text/plain I got several nice answers from both the HPAdmin and the PARisc-Linux lists. The answer from Bill Hassell noted that is was most likely not a memory problem, but a CPU problem. Since there are 2 of them inside the box, I expect no problems with a single processor linux. I will be verry carefull on installing smp linux... Most of them pointed me to ODE (Offline Diagnostics Environement) on the "Support Plus" cd that came with HP-UX. The recipy on HP-UX machines: - Boot from the CDRom - Interact wit IPL: YES - (set/read the current itme with CLKUTIL) - ODE, then, at the ODE prompt: - ls for a list of tests and options - menu promisses to be a nice one Unfortunatly, all is protected with a password and the password I got from one of you did not match the distribution I have here ("HPUX 11.0, march 2001") Meanwhile, I'm installing Debian linux on the box, without any hardware bumps. In the HP-70096 terminal menu, I found the way to have it emulate VT100 (called "EM100") (starting at the button, left to ). Thanks. Origional message: Here I have an HP D370 machine that (during my holidays) crashed. Since the machine was replaced since long and only kept running for fast access to old stuff, not a real problem. At first, we suspected the boot disk since its led keeps buring. However, booting HP-UX from CDRom for a new fresh install, the boot of the kernel crashes at roughly the same point, even with all disks removed. Hence we suspected the core memory. However, changing or replacing the memory does not change anything in the behavoure. Is there a way to somehow test the hardware of a PA-Risc machine? Either from HP or from the linux world? Kind of like the test tools as found on the (intel-) linux distributions? btw: I can get debian-woody booted up to the message that if this is the last message on screen, check the faq. A second terminal (HP 700/96) on tty1 shows a lot of (vt100?) junk. How can I either put the HP700/96 terminal in VT100 mode or whats the magic name of this terminal in the 'TERM=...' kernel parameter? CBee mailto:c.beerse@torex-hiscom.nl ------_=_NextPart_001_01C35B3F.48453BF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Summary: [HPADM][parisc-linux] testing HP-PA risc = hardware

I got several nice answers from both the HPAdmin and = the PARisc-Linux lists.

The answer from Bill Hassell noted that is was most = likely not a memory problem, but a CPU problem. Since there are 2 of = them inside the box, I expect no problems with a single processor = linux. I will be verry carefull on installing smp linux...

Most of them pointed me to ODE (Offline Diagnostics = Environement) on the "Support Plus" cd that came with = HP-UX.

The recipy on HP-UX machines:
- Boot from the CDRom
- Interact wit IPL: YES
- (set/read the current itme with CLKUTIL)
- ODE, then, at the ODE prompt:
  - ls for a list of tests and options
  - menu promisses to be a nice one
Unfortunatly, all is protected with a password and = the password I got from one of you did not match the distribution I = have here ("HPUX 11.0, march 2001")

Meanwhile, I'm installing Debian linux on the box, = without any hardware bumps. In the HP-70096 terminal menu, I found the = way to have it emulate VT100 (called "EM100") (starting at = the <user-system> button, left to <F5>).

Thanks.


Origional message:

Here I have an HP D370 machine that (during my = holidays) crashed. Since the machine was replaced since long and only = kept running for fast access to old stuff, not a real = problem.

At first, we suspected the boot disk since its led = keeps buring. However, booting HP-UX from CDRom for a new fresh = install, the boot of the kernel crashes at roughly the same point, even = with all disks removed. Hence we suspected the core memory. However, = changing or replacing the memory does not change anything in the = behavoure.

Is there a way to somehow test the hardware of a = PA-Risc machine? Either from HP or from the linux world?

Kind of like the test tools as found on the (intel-) = linux distributions?

btw: I can get debian-woody booted up to the message = that if this is the last message on screen, check the faq. A second = terminal (HP 700/96) on tty1 shows a lot of (vt100?) junk. How can I = either put the HP700/96 terminal in VT100 mode or whats the magic name = of this terminal in the 'TERM=3D...' kernel parameter?




CBee


mailto:c.beerse@torex-hiscom.nl=

------_=_NextPart_001_01C35B3F.48453BF0-- From mnahkola@trinms01.ntc.nokia.com Tue Aug 5 12:37:40 2003 From: mnahkola@trinms01.ntc.nokia.com (Nahkola Mikko) Date: Tue, 5 Aug 2003 14:37:40 +0300 Subject: [parisc-linux] Terminfo/termcap for a 70096 ... Message-ID: <20030805113739.GT14491@aurinko.ntc.nokia.com> I tried to ask this question in the comp.sys.hp.hpux newsgroup once but didn't get any useful answers... anyone here know better? (yes, I know, this is probably specifically _not_ a problem on parisc-linux as all the parisc stuff is supposed to have a HP-UX license in the first place, for some version of HP-UX.) Is it legal to copy terminfo and termcap entries (from HP-UX in this case)? The problem is that HP-UX is pretty much the only thing that comes with a terminfo entry for a 70096, and we have a bunch of those that could be useful on other systems too ... except that the scrollback doesn't work in the emulation modes. It would therefore be better to be able to run in native mode, but this pretty much _requires_ the terminfo/termcap entry ... Oh, and about the cursor keys on the 70096, if I were to put them in the "application" mode, would that help with bash et al.? They seem to be working in swinstall and such on HP-UX ... but the default mode seems to be non-transmitting, right? (yes, I could use that too myself, and re-enter stuff from the buffer with the print/enter key and do the line-modify thing... but the others have a hard time learning that.) -- Mikko Nahkola Tre-IN sysadmin From c.beerse@torex-hiscom.nl Tue Aug 5 14:04:24 2003 From: c.beerse@torex-hiscom.nl (=?iso-8859-1?Q?=22Beerse=2C_Corn=E9=22?=) Date: Tue, 5 Aug 2003 15:04:24 +0200 Subject: [parisc-linux] Terminfo/termcap for a 70096 ... Message-ID: <03Aug5.152448cest.119163@ns.hiscom.nl> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35B52.17F0F8A0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Nahkola Mikko [mailto:mnahkola@trinms01.ntc.nokia.com] > > I tried to ask this question in the comp.sys.hp.hpux newsgroup once but > didn't get any useful answers... anyone here know better? The /etc/termcap file on a RedHat 7.3 machine does contain a bunch of HP terminals, including 700 series like 700 44 and 700 92. I think the latter one will suit your needs. There are even more. As far as I know, it all ends in hpterm, the hp-terminal emulator (xterm equivalent) for X11 (vue) with similar capabilities as the 700 series terminals. Unfortunatly, while installing DebianWoody on a D370, I found none of them in the terminfo database (and no termcap file). And the HP700/96 came with the D370. I know one thing to do after finalizing the install.... > > (yes, I know, this is probably specifically _not_ a problem on > parisc-linux as all the parisc stuff is supposed to have a HP-UX license > in the first place, for some version of HP-UX.) > > Is it legal to copy terminfo and termcap entries (from HP-UX in this > case)? I don't think it is illegal to tune any system to use HP hardware with a published interface and I think the manual of the terminal clearly publishes the codes as used in the termcap or terminfo files. > > The problem is that HP-UX is pretty much the only thing that comes with a > terminfo entry for a 70096, and we have a bunch of those that could be > useful on other systems too ... except that the scrollback doesn't work > in the emulation modes. Some settings of $TERM that come to mind include 'hpterm', 'hp700', 'hp70092'. I recal I've used them between HP-UX and Solaris machines, hence Solaris also might have suitable termcap or terminfo entries. > > It would therefore be better to be able to run in native mode, but this > pretty much _requires_ the terminfo/termcap entry ... > > Oh, and about the cursor keys on the 70096, if I were to put > them in the > "application" mode, would that help with bash et al.? They seem to be > working in swinstall and such on HP-UX ... but the default > mode seems to > be non-transmitting, right? (yes, I could use that too myself, and > re-enter stuff from the buffer with the print/enter key and do the > line-modify thing... but the others have a hard time learning that.) don't know, just put the terminal in em220 (vt220 emulation) mode to install debian. CBee ------_=_NextPart_001_01C35B52.17F0F8A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [parisc-linux] Terminfo/termcap for a 70096 ...

> -----Original Message-----
> From: Nahkola Mikko [mailto:mnahkola@trinms01= .ntc.nokia.com]
>
> I tried to ask this question in the = comp.sys.hp.hpux newsgroup once but
> didn't get any useful answers... anyone here = know better?

The /etc/termcap file on a RedHat 7.3 machine does = contain a bunch of HP terminals, including 700 series like 700 44 and = 700 92. I think the latter one will suit your needs. There are even = more. As far as I know, it all ends in hpterm, the hp-terminal emulator = (xterm equivalent) for X11 (vue) with similar capabilities as the 700 = series terminals.

Unfortunatly, while installing DebianWoody on a D370, = I found none of them in the terminfo database (and no termcap file). = And the HP700/96 came with the D370. I know one thing to do after = finalizing the install....

>
> (yes, I know, this is probably specifically = _not_ a problem on
> parisc-linux as all the parisc stuff is = supposed to have a HP-UX license
> in the first place, for some version of = HP-UX.)
>
> Is it legal to copy terminfo and termcap = entries (from HP-UX in this
> case)?

I don't think it is illegal to tune any system to use = HP hardware with a published interface and I think the manual of the = terminal clearly publishes the codes as used in the termcap or terminfo = files.

>
> The problem is that HP-UX is pretty much the = only thing that comes with a
> terminfo entry for a 70096, and we have a bunch = of those that  could be
> useful on other systems too ... except that the = scrollback doesn't work
> in the emulation modes.

Some settings of $TERM that come to mind include = 'hpterm', 'hp700', 'hp70092'. I recal I've used them between HP-UX and = Solaris machines, hence Solaris also might have suitable termcap or = terminfo entries.

>
> It would therefore be better to be able to run = in native mode, but this
> pretty much _requires_ the terminfo/termcap = entry ...
>
> Oh, and about the cursor keys on the 70096, if = I were to put
> them in the
> "application" mode, would that help = with bash et al.? They seem to be
> working in swinstall and such on HP-UX ... but = the default
> mode seems to
> be non-transmitting, right? (yes, I could use = that too myself, and
> re-enter stuff from the buffer with the = print/enter key and do the
> line-modify thing... but the others have a hard = time learning that.)

don't know, just put the terminal in em220 (vt220 = emulation) mode to install debian.





CBee

------_=_NextPart_001_01C35B52.17F0F8A0-- From willy@debian.org Tue Aug 5 14:33:09 2003 From: willy@debian.org (Matthew Wilcox) Date: Tue, 5 Aug 2003 14:33:09 +0100 Subject: [parisc-linux] Terminfo/termcap for a 70096 ... In-Reply-To: <03Aug5.152448cest.119163@ns.hiscom.nl> References: <03Aug5.152448cest.119163@ns.hiscom.nl> Message-ID: <20030805133309.GO22222@parcelfarce.linux.theplanet.co.uk> On Tue, Aug 05, 2003 at 03:04:24PM +0200, "Beerse, Corné" wrote: > Unfortunatly, while installing DebianWoody on a D370, I found none of them > in the terminfo database (and no termcap file). And the HP700/96 came with > the D370. I know one thing to do after finalizing the install.... Yeah, Debian doesn't have termcap, there's a document somewhere that explains why. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From c.beerse@torex-hiscom.nl Tue Aug 5 14:53:34 2003 From: c.beerse@torex-hiscom.nl (=?iso-8859-1?Q?=22Beerse=2C_Corn=E9=22?=) Date: Tue, 5 Aug 2003 15:53:34 +0200 Subject: [parisc-linux] Terminfo/termcap for a 70096 ... Message-ID: <03Aug5.161359cest.119152@ns.hiscom.nl> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35B58.F6A87270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Matthew Wilcox [mailto:willy@debian.org] > Sent: dinsdag 5 augustus 2003 15:33 >=20 > On Tue, Aug 05, 2003 at 03:04:24PM +0200, "Beerse, Corn=E9" wrote: > > Unfortunatly, while installing DebianWoody on a D370, I found none = of them > > in the terminfo database (and no termcap file). And the HP700/96 = came with > > the D370. I know one thing to do after finalizing the install.... >=20 > Yeah, Debian doesn't have termcap, there's a document somewhere that > explains why. I don't care if they use termcap or terminfo. It bothers me that they = have no HP700xx entry in there, not even in the pa-risc distribution. = Specially the pa-risc distro can find a 700xx terminal at its console so it would = be nice if the TERM boot parameter can be set to indicate a hp700 = terminal. On the other hand, I'm one of those sysadmins that can find its way = around and I expect most installations to PA-Risc will be a kind of freak or = hacker that can find a way. It is just a little uncomfortable. CBee ------_=_NextPart_001_01C35B58.F6A87270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [parisc-linux] Terminfo/termcap for a 70096 ...

> -----Original Message-----
> From: Matthew Wilcox [mailto:willy@debian.org]
> Sent: dinsdag 5 augustus 2003 15:33
>
> On Tue, Aug 05, 2003 at 03:04:24PM +0200, = "Beerse, Corn=E9" wrote:
> > Unfortunatly, while installing DebianWoody = on a D370, I found none of them
> > in the terminfo database (and no termcap = file). And the HP700/96 came with
> > the D370. I know one thing to do after = finalizing the install....
>
> Yeah, Debian doesn't have termcap, there's a = document somewhere that
> explains why.

I don't care if they use termcap or terminfo. It = bothers me that they have no HP700xx entry in there, not even in the = pa-risc distribution. Specially the pa-risc distro can find a 700xx = terminal at its console so it would be nice if the TERM boot parameter = can be set to indicate a hp700 terminal.

On the other hand, I'm one of those sysadmins that = can find its way around and I expect most installations to PA-Risc will = be a kind of freak or hacker that can find a way. It is just a little = uncomfortable.


CBee

------_=_NextPart_001_01C35B58.F6A87270-- From ghub005@xtra.co.nz Tue Aug 5 14:55:20 2003 From: ghub005@xtra.co.nz (Gavin Hubbard) Date: Wed, 6 Aug 2003 1:55:20 +1200 Subject: [parisc-linux] Re: mobo for J5600 Message-ID: <20030805135520.CDEM1764.web4-rme.xtra.co.nz@[127.0.0.1]> > Hi > > it seems one of my scsi controllers broke down, so I need a new mobo. I > called a local supplier (Belgium) who told it costs 2500 euro for the > motherboard which includes also 2 processors. > Do you have to buy this with those processors? Isn't there any other > solution possible? > > Thx guys > Mark You're very unlikely to find a motherboard (on its own) for sale on the secondary markets. However 2500 euro is far too much. These days you can buy a replacement system for less than that. As an example see the following (expired) EBay auction: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3038140080&category=11221 Regards, Gavin From mnahkola@trinms01.ntc.nokia.com Tue Aug 5 15:15:37 2003 From: mnahkola@trinms01.ntc.nokia.com (Nahkola Mikko) Date: Tue, 5 Aug 2003 17:15:37 +0300 Subject: [parisc-linux] Terminfo/termcap for a 70096 ... In-Reply-To: <03Aug5.152448cest.119163@ns.hiscom.nl> References: <03Aug5.152448cest.119163@ns.hiscom.nl> Message-ID: <20030805141536.GW14491@aurinko.ntc.nokia.com> On Tue, Aug 05, 2003 at 03:04:24PM +0200, ext "Beerse, Corné" wrote: > > From: Nahkola Mikko [mailto:mnahkola@trinms01.ntc.nokia.com] > > I tried to ask this question in the comp.sys.hp.hpux newsgroup once but > > didn't get any useful answers... anyone here know better? > The /etc/termcap file on a RedHat 7.3 machine does contain a bunch of HP > terminals, including 700 series like 700 44 and 700 92. I think the latter > one will suit your needs. There are even more. As far as I know, it all ends > in hpterm, the hp-terminal emulator (xterm equivalent) for X11 (vue) with > similar capabilities as the 700 series terminals. Um. I don't have a RedHat here ... well, there's a close-enough copy that I could check. Yes, the 70092 is probably close enough. Haven't run into any differences around here and we have a couple of those too. > Unfortunatly, while installing DebianWoody on a D370, I found none of them > in the terminfo database (and no termcap file). And the HP700/96 came with > the D370. I know one thing to do after finalizing the install.... That'd be good to have, yes, and even better if the installer knew how to use it too. And I _did_ install the terminfo entry myself ... > > (yes, I know, this is probably specifically _not_ a problem on > > parisc-linux as all the parisc stuff is supposed to have a HP-UX license > > in the first place, for some version of HP-UX.) > > > > Is it legal to copy terminfo and termcap entries (from HP-UX in this > > case)? > > I don't think it is illegal to tune any system to use HP hardware with a > published interface and I think the manual of the terminal clearly publishes > the codes as used in the termcap or terminfo files. The "User's Manual" (part no. 5959-5071) only seems to publish some of them, not all. It certainly doesn't say what the thing _transmits_ as control characters, and such ... I haven't seen the "Reference Manual" anywhere. (5959-5072) That'd be the one to find, probably. The c1099a User's Manual isn't any more help either. > > The problem is that HP-UX is pretty much the only thing that comes with a > > terminfo entry for a 70096, and we have a bunch of those that could be > > useful on other systems too ... except that the scrollback doesn't work > > in the emulation modes. > Some settings of $TERM that come to mind include 'hpterm', 'hp700', > 'hp70092'. I recal I've used them between HP-UX and Solaris machines, hence > Solaris also might have suitable termcap or terminfo entries. I don't think I've managed to find them. At least it doesn't get right by default on the things that I've tried. Not sure which ones I've tried them on, Sun, DEC/Compaq, IBM, whatever ... at least everything seems to default to VT100 if they can't figure out what it is. Even HP-UX, occasionally. > > Oh, and about the cursor keys on the 70096, if I were to put > > them in the > > "application" mode, would that help with bash et al.? They seem to be > > working in swinstall and such on HP-UX ... but the default > > mode seems to > > be non-transmitting, right? (yes, I could use that too myself, and > don't know, just put the terminal in em220 (vt220 emulation) mode to install > debian. I did. But it might be better if the Debian installer could be made to handle the native mode too. -- Mikko Nahkola Tre-IN sysadmin From soete.joel@tiscali.be Tue Aug 5 16:57:10 2003 From: soete.joel@tiscali.be (Joel Soete) Date: Tue, 5 Aug 2003 17:57:10 +0200 Subject: [parisc-linux] lvm2 pb on hppa-linux Message-ID: <3F2E2C77000006C7@ocpmta2.freegates.net> --========/3F2E2C77000006C7/mail.tiscali.be Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi all, Since the announce of lvm2 I used succefuly lvm tools (also with evms tools before 1.9 ie evms-1.2.1) on my linux hppa box runing a last updated linux-2.4.21-pa8 (+ a very small hack to use generic_ffs()). Now I try to install lvm2 and dm1. I so recover last lvm-1.0.7. I configure it and build PATCHES which I apply against kernel (without VFS-lock). Then I reboot it and install tools: _no pb_ :-) # vgdisplay --version vgdisplay: Logical Volume Manager 1.0.7 Heinz Mauelshagen Sistina Software 28/03/2003 (IOP 10) # vgdisplay -v --- Volume group --- VG Name EvmsLvm VG Access read/write VG Status available/resizable VG # 0 MAX LV 256 Cur LV 2 Open LV 0 MAX LV Size 255.99 GB Max PV 256 Cur PV 1 Act PV 1 VG Size 3.99 GB PE Size 4 MB Total PE 1022 Alloc PE / Size 896 / 3.50 GB Free PE / Size 126 / 504 MB VG UUID k7px10-qfN2-J3y0-fony-aczD-HLwn-ZnN9G3 --- Logical volume --- LV Name /dev/EvmsLvm/DebianRep VG Name EvmsLvm LV Write Access read/wri e LV Status available LV # 1 # open 0 LV Size 3 GB Current LE 768 Allocated LE 768 Allocation next free Read ahead sectors 120 Block device 58:1 --- Logical volume --- LV Name /dev/EvmsLvm/JfsTst VG Name EvmsLvm LV Write Access read/write LV Status available LV # 2 # open 0 LV Size 512 MB Current LE 128 Allocated LE 128 Allocation next free Read ahead sectors 120 Block device 58:2 --- Physical volumes --- PV Name (#) /dev/sdc (1) PV Status avai able / allocatable Total PE / Free PE 1022 / 126 _no pb_ to mount and use usually the first lv (/dev/EvmsLvm/DebianRep) #df Filesystem 1K-blocks Used Available Use% Mounted on /dev/md2 1700208 1086488 52735 68% / /dev/md0 123891 58924 58571 51% /boot /dev/md3 247791 132508 102490 57% /var /dev/md4 123827 4118 113316 4% /tmp /dev/md5 123827 10339 107095 9% home /dev/md6 2015696 1200328 794892 61% /usr/src /dev/md7 2015696 1927752 67468 97% /Sources /dev/md8 2015696 1612664 382556 81% /Develop /dev/EvmsLvm/DebianRep 3096336 2926848 138032 96% /Debian I so go further and patch kernel with dm/patches/devicemapper-ioctl.patch (no VFS-lock) rebuild it wihtout any pb or warning (about dm part :-)) ). I so install dmsetup tool and reboot with this kernel sucessfully (no pb to discover vg and lv as lvm1 tools are still installed) The dmsetup create well special file: # ll /dev/mapper total 28 drwxr-xr-x 2 root root 4096 Aug 5 17:52 . drwxr-xr-x 9 root root 24576 Aug 5 16:04 .. crw------- 1 root root 10, 63 Aug 5 17:52 control :-) To be care I "vgchange -a n", than compile and install lvm2 tools. Then I just edit lvm.conf file so that filter only sd disc filter = [ "a|^/dev/sd|, "r/.*/" ] [...] file = /var/log/lvm2.log level=7 activation=1 # in log section Unfortunately _vgchange_ failled to recover vg structure: #vgscan --version LVM version: 2.00.05 (2003-07-18) Library version: 1.00.02-ioctl (2003-07-12) Driver version 4.0.1 #vgscan Volume group "EvmsLvm" not found Wiping cache of LVM-capable devices Wiping internal cache Reading all physical volumes. This may take a while... Finding all volume groups Finding volume group "EvmsLvm" Very strange: it first tell 'Volume group "EvmsLvm" not found' and finaly 'Finding volume group "EvmsLvm"' ? Vgchange will it tell the true? #vgchange -a y too bad: Out of memory. Requested 2483027988 bytes. Failed to read extents from /dev/sdc Unable to find volume group "EvmsLvm" Any idea? (As I use full log I join a gz of this lvm2.log) Thanks in advance for help, Joel PS: I do a similar exercise on my ia32 platform (same linux-2.4.21 not pa specific naturaly) and do not met any pb. There is anyway a small difference: on the ia32 I build a vg over a disk slice; on hppa, allover a full disk (i don't think that it does matter, but just in case?) ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr --========/3F2E2C77000006C7/mail.tiscali.be Content-Type: application/x-gzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lvm2.log.gz" H4sICC3ALz8AA2x2bTIubG9nAO2dW7fiOJat3+NXePRT90MEmDsxzjhjZGVVPvTJrO7KzMp+jCHZ BpwBGCwb2Pz6lswmYgcQRvtbGDJP1Etc9vaUl6Q5ly5e0oqy5SSdtqLqr3fR++FwFATBL0lRpMtp MM+mLRUV6UYVabYMiiwI30TZYqGWsWkVWTa3uCLZFRYYdjoW+GM2nTpgukyLVM1Tk8SBKoJfyyT4 rpwGQT8IB+/7vfe9XtBpt7tv3kS175/OM63mrXKhzEf39kH3q6/vhQdc8Onhdns4PC9/0HlRfpxs 0igxrTjNHaJl/38F8WzRKs+iCuH+4VeJ83Y8AY26FvT8sCknk3QXLLMimGTlMrYNGhyefG+Nnqhy XhV9uaDB6HNBpe0I41PO7E2eTJNda6GKaJbktpxO35Xz0+H/gS7TeRFs02IWhOMgnqjAFKpIjGcL R8qWUrVYUkSt+WbRelf96ErbHeHbPC2SDxXiQ/Xer1T9C/DnFm/liUnyTRI7cFSxo9MfAPgiWWT5 k8OPwnHHvwBHk8SYD6s8zWxVqhLehqP6vptkue0Nn86z7XnNGG3rXa5sTQqVLj/E6sk4YLf9Ktgi PZD3AuqLXn9GqTyapZvkw1Fex65//rlfIYe/zso4/NhPevMs+mj/+6F4Wn2NOJdEfoQdX71RefUz 9/43z788PmTLGI9tET+k8+StVs7vPf8mSJZKz5P43ZvN1ERqaZ/sO6X/T7pyvz0II5sEP/7209tI rdyzR9q/Ofzt3NLb6jnn6MZ9C3Y/av1tszA/2qb4a6JTtfw5Wb0Pvotj+2Zr7AF5KN2zmP+cmF9N 8Yoyup3wtIxpnpXWjL9byqpAuxZ4LuUK/qfv/t/f/vq33wBSTVdTlRcEWaR6QXBlnGYUF1JghwK7 FBgVc1/oCzZFcZ4tXkXEzhfQtsXO00pAzyPy4efO+b2CkFbZJpsnoO5RlhNYbAjvLYowwsIIHyzM mw0vujSx4m5Vz384PMj8TFWMc9038ltn5b3agZ0WZmIVCuFtIV74/o4M3pXB+zL4QAYfyuAjGXws gmtZv2sh77SQd1rGOy3jnZbxTst4p2W80zLe6dfw7sVQMNFtMIBYlCqLLE6KJCJTLouPyjxPlgxM hkqLEpocSkwmw7RFCU3uSEwmE0aLEprclZjcYyihyT2JyX2GEprcl5g8YCihyQOJyUOGEpo8FJgc t5BjjlvIOcYt5KDiFnIScctfqOFLmBWL2/ULJiqdJ7ErIzBlNAsm9r9Blgdxmtu+yvKnK4PmJIbz JAv8Plus1D8wPO4O+LtnYactQfd6IvQQzpAO6HFPgB5I6i1q8h6dU1fgjgA8lIBHIw4uw7aAKGUY CgwvRSQtRUSxaFGrDTtw/XNA9+Dy54AWcLwMR6I2H0v6uyNialfiEMtuX2K5xK2UXVGTS1xDOZI0 2Uj05i4Gw40JC5QN2KFkwA5FA3YoGrBD0YAdigbsUDRgh5IBO5QM2KFkwA4lA3YoGbBD0YAdigbs UDRgh6IBOxQN2KFowA5FA3YoGrBD0YAdigbsUDRgh6IBOxQN2KFkwA5FA3YoGbBDyYAdSgbs8JUD 9ss1fqFW5PPppJx7f21+AZuuFq/4TP0lMFaFAl9DZzH8/mmBcDLjkLAzHVTwVugmHRT6SAeF8w8H hZ+CHBTOmRwUfgJyUPj5x0HhJ0cL5d1KnYqFckJwPnA6cDZwMnAuYCpMMBB7lQn3ZRPuyybcl024 L5twXzbhvmzCfdmE+7IJ92UT7ssmvFu5L5twQnA+cDpwNnAycC5gKkwxEHuVKfdlU+7LptyXTbkv m3JfNuW+bMp92ZT7sin3ZVPuy6a8W7kvm3JCcD5wOnA2cDJwLmAqzDAQe5UZ92Uz7stm3JfNuC+b cV82475sxn3ZjPuyGfdlM+7LZrxbuS+bcUJwPnA6cDZwMnAuwEhTdxSUHSVxyDymb11leYHO91ho WbSSTbIsSCjWCzgJyXoBJ6FZL+AkROsA/93wiv9ueK1/N7zKvxte30UakT3rZ3BWmoS3VwXnTVbB eatVcNJwvyNpfVwkBDbPpgz1igN+L/zOPMtWcAhyUDgVclA4ZjooHPkcFA59DgrHPgeFg5+Dvmb0 e0mIFZHpHJ3Qm6MDevMNkcdCrVZJ7o48FnlGBtoFDYtd0PAcC+Sv5O+E+rJIKC+LhOqySCiuRYyr iWuJK4nrCN3HIoZT50UMZ86LGE6c2Vi5SOOUuLkKh4HERVZA4iUrIJm0OCC1lBrK7NwlOcWxClog q6EFoiq6iSfBrcpeO3xN6MYZ2J0kAeAlDW1ZridoIelwpDMdjvSlw5GuXOZqS6t4gKJaHqCoogco qqth9bQwQliHI9FNDkcGD4tDfWFhsHohrF6IqseCzJZ7Su89JfeeUnsPib1SOamhhZH6WRipndvS I7AVuZpllafLAg3DK6PKHcEVCwYz6MzoqnhSFIc63eJQr1scorTFkYPhDkdOZzscOSLtcOScssON IG4MccTLO5yGuAjiYogj8zuHmzAcuoTD4aD+0HUUDgf1hy5mcDioP3RFgcNB/WmoPw31p6H+NNSf hvrTUH8a6k9D/UVQfxHUXwT1F0H9RVB/EdRfBPUXQf1FUH8R1F8E9RdB/UVQfxHUH/oM6nBQfzHU Xwz1F0P9xVB/MdRfDPUXQ/3FUH8x1F8M9RdD/cVQfzHUXwz1F0P9xVB/KG7B4aD+UKSCw0H9JVB/ CdRfAvWXQP0lUH8J1F8C9ZdA/SVQfwnUXwL1l0D9oYAEh4P6Q0EJDgf1t4L6W0H9raD+VlB/K6i/ FdTfCupvBfW3gvpbQf2h72sOB/W3hvpbQ/2tof7WUH9rqL811N8a6m8N9beG+ltD/a2h/tZQf2uo vzXU3xrqbw31x745WRzUH/vqZHFQfznUXw71l0P95VB/OdRfDvWXQ/3lUH851F8O9YcyTzgc1B+K 83c4qD8U3+9wUH8G6s9A/RmoPwP1Z6D+DNSfgfozUH8G6s9A/aGQNIeD+kNRJQ4H9YdiShwO6q+A +iug/gqovwLqr4D6K6D+UNSjw0H9FVB/BdRfAfVXQP2VUH8l1F8J9VdC/ZVQfyXUXwn1V0L9lVB/ JdRfCfVXQv2VUH8l1F8J9VdC/W2g/jZQfxuovw3U3wbqbwP1t4H620D9baD+NlB/G6i/DdTfBupv A/W3gfrbQP1tof62UH9bqL8t1N8W6m8L9beF+ttC/W2h/rZQf1uovy3U3xbqbwv1t4X620L97aD+ dlB/O6i/HdTfDupvB/W3g/rbQf3toP52UH87qL8d1N8O6m8H9beD+ttB/T1B/T1B/T1B/T1B/T1B /T1B/T1B/T1B/T1B/T1B/T1B/T1B/T1B/T1B/T1B/T1B/e2h/vZQf3uovz3U3x7qbw/1t4f620P9 7aH+9lB/e6i/PdTfHupvD/W3h/rbE/3BQ63wSCs80Pqa46wvLt3I1YLd1mGBr7uYpvMC6S6mmafK HLDHnwbp8pUW0LtxHBRejuOg8NoYB4UXxzgovDrGQeHlMQ4Kr4+xUN5KvJF4G/Em4i0Eb9ixSHjF jkXCO3ZytYwzcpUAv/OCX3nBb7zgF17k9D6hnF62k9PbdnJ63U7u/5nzhb83UXVr2om/j+I8e63H tyVBr+2QcKxwUMFboRd0UOgGHRT6QQeFjtBBoSe0UN5KvJF4G/Em4i0ExwqLhGOFRcI7rY07fQaB VGkWSfVtoYK3UuZaKKWuhVLuWiglb6x4VXlNeUV5PalIY0VFGisq0lhhkWoMxHLRXKSai1RzkWou Us1FqrlINa8qrymvKK8nFqnGItVYpBqLNMJALJeIizTiIo24SCMu0oiLNOIijXhVeU15RXk9sUgj LNIIizTCIn1N6o0vgVgufDkb8+VszJezMV/Oxnw5G/PlbIzXpDFek8Z4TRrjNWmM16QxXpPGeE0a 8zUpTEZtcDJqw5NRG56M2vBk1IYnozY8GbXhyagNTtBscJZlg7MsG5xl2eAsywZnWTY4y7LBWZYN zbJscJZlw7MsG55l2fAsy4ZnWTY8y7LhWZYNzjxscPpgg9MHG5w+2OD0wQanDzY4fbDB 6YMNTR9scPpgw9MHG54+2PD0wYanDzY8fbDh6YMNTqlrcF5cg/PiGpwX1yKxSGleXIPz4hqcF9fQ vLgG58U1PC+u4XlxDc+La3heXMPz4hqeF9fgXLEGJ3w1OOGrwQlfDU74anDCV4MTvhqc8NUk6zJZ Rih1gpmSWBMzJYEmphp9CQy+jQS1mGrEJTASemyqkZbASOCxmbIWYQ3C2oM1B2sNEoRtpiQE20xJ ALZZrAp0Y2wFRKJxQEQSB0Q8WcavyQ/2Mh4sl4WDvSjoQhyxi0M6LSf491WeTJI8t88t1SL5j+sF XzCxiiG7QdFfMfoWVncuF925QdHdy0V3b1B073LRvRsU3b9cdP8GRQ8uFz2QF325F2/QiZf78AZd eLkHb9CBl/vvBt13ufdu0HnDiwUP5QWPLhY8khc8vljwGBX8coBAQd8w/x9M/wez/7HkfzD3H0z9 BzP/mSK2XcyA6ZLhspIkqyuKJ4YitLQw0uUORl9H30dmgQ5HJoEOR5YLDkcWDA5HlgwORxYNDkeW DQ5HFg4WB7uvA2nWgTTrUDshzTqQZh1Isw6kWQfSrANp1oE0g93QhTTrQpp1Ic26tH6QZl1Isy6k WRfSrAtp1oU0g83ZgzTrQZr1IM16kGY92i6QZj1Isx6kWQ/SrAdpBpulD2nWhzTrQ5r1Ic36kGZ9 2p6QZn1Isz6kWR/SDFZvAGk2gDQbQJoNIM1g78HOg3333fc/wW6wSNgRDil4qeCtkAEOCkngoNDd OCj0OBbKq8pryivK6wmdj0VCfVoklKhFQpX+AuXyC9TKL5A9v0Du/POXv8AaWiSso0MKXip4K2xc B+XtS72Qg0J1WiivKq8pryivJ/RCFgm9kEVCL2SR0AspKBcFtaIgexTkjoLMUZA3CrJGQc4oyBhF +UK+6zgcuW3P4chtew5HbttzOHLbnsOR2/YsTkP9aag/DfWnof401J+G+tNQfxrqT0P9aag/DfWn of401J+G+tNQfxrqL4L6i6D+Iqi/COovgvqLoP4iqL8I6i+C+oug/iKovwjqL4L6i6D+Iqi/COov hvqLof5iqL8Y6i+G+ouh/mKovxjqL4b6i6H+Yqi/GOovhvqLof5iqL8Y6g/Fbjsc1B+K3HY4qL8E 6i+B+kug/hKovwTqL4H6S6D+Eqi/BOovgfpLoP4SqL8V1N8K6m8F9beC+ltB/a2g/lZQfyuovxXU 3wrqbwX1t4L6W0H9raD+VlB/K6i/NdTfGupvDfW3hvpbQ/2tof7WUH9rqL811N8a6m8N9beG+ltD /a2h/tZQf2uovxzqL4f6y6H+cqi/HOovh/rLof5yqL8c6i+H+suh/nKovxzqL4f6y6H+cqg/A/Vn oP4M1J+B+jNQfwbqz0D9Gag/A/VnoP4M1J+B+jNQfwbqz0D9Gag/dHLQ4aD+UKoYh4P6K6D+Cqi/ AuqvgPoroP4KqL8C6q+A+vNPg3OCg/oroP4KqL8S6q+E+iuh/kqovxLqr4T6K6H+Sqi/EuqvhPor of5KqL8S6q+E+iuh/kqovw3U3wbqbwP1t4H620D9baD+NlB/G6i/DdTfBupvA/W3gfrbQP1toP42 UH8bqL8t1N8W6m8L9beF+ttC/W2h/rZQf1uovy3U3xbqbwv1t4X620L9baH+tlB/W6i/HdTfDupv B/W3g/rbQf3toP52UH87qL8d1N8O6m8H9beD+ttB/e2g/nZQfzuoP3pFDr0jh156Qm+xoNcS0HPm 9OAwPVlLj9bSs7VPUH9PUH9PUH9PUH9PUH9PUH97qL891N8e6m8P9beH+ttD/e2h/vZQf3uovz3U 3x7qbw/1t4f620P97aH+9kR/JU51XxrdSpB2D0ii3mek4KWCtxK38QwlnuMZSpzHM5T4jwOUV5XX lFeU15N4ygOS+MoDknjLA5L4S4ecowjTA5LqxSIFLxW8lVLXQil3LZSS10Ipe+cojveA5DXlFeX1 pCqdo4jeA5KqdI6ieh1ykZUGHcX4BKaqOYBlr5a9mzL5gKZsPqApow9oyuoKLaq2qNaiSovqTMVc gameKzCVdAWmqs7TrN+m0jKRWi4TFB/7Ak6leYRLXy99P1XJEU+FcsRTrRzxVC7PeGH1hbUXVl5Y d+osnuHUXTzDqcN4hhOXsYkMQxGRWhjRpoPR19H3ERE4HGG/wxHaOxzhu8MRojscYbjDEWo7HOQ0 7D50zbvDQZqha94dDtIMXfPucJBm6Jp3h4M0Q9e8OxykGewGdM27w0GaoWveHY7WD9IMXfPucJBm 6Jp3h4M0Q9e8WxxsTnTNu8NBmqFr3h0O0gxd8+5wkGbomneHgzRD17w7HKQZbBZ0zbvDQZqha94d DtIMXfPucLQ9Ic3QNe8OB2mGrnm3OFg9dM27w0GaoWveHQ7SDPYe7DzYd+RLuIPBvkM3vlY4/EL8 RkgXRZeMiq4ZFV00KrpqVHTZqOi6UdGFI7oruMJRxtG1o6KLR0VXj4ouHxVdPyq6gFR0BanoElLR NSS6ZbrCUcbRZaSi60hFF5KKriQVXUoqupZUdDGp6GpS0eUkup+8wlHG0RWloktKRdeUii4qFV1V KrqsVHRdqejCUtGVJbrZvsJRxtHFpaKrS0WXl4quLxVdYCq6wlR0ianoGlPRRSbKiVDhKOPoOlPR haaiK02U98HhaCeSPtxF2dJkcxKavE/yjMDWE3QzisORvnc40vUOd7nnN1P3Jdg+3R/Yh/8nXaXL aZAuiyRfqvkhzfyLZ8b2mZ8TFbuH1HwerGZPJo3sg5tsXi4S8y4Ifp2lJliop6BQHxP7tu0snSfv 3r17U2TZfJ5qW0xn7N71Q7r8VM4BHkzzrFyZN5N0bt9vWoe/367sv1NTJMvCYdvjY6VytbBt/8vH dFUZ/e+VsfF/+MInsQQ9z7KVDz7KFqvMpIXrkE7Hov9p3ONVGSZWL/stzVynhX370H+tkmUSf35q rnQyb1V/2mfCYe9ohjlcNB1Uv7J9WiRRkcTnpXad4d/PM/P1UjsD1yv/R6voY5GrKPm/vk2xEDVk FOcutB/jZ+4qagF6KkAnm4VpVXL6cGhxQVmWzSIyh0Iy++CvkDn0Y3NYS+cQ8/m0XAGhJY1pcgna 0lkGn0rgf7OE/nGzaP010ala/pyspOI4dKhEFB0hr33wV3jd8eN1p5bXHczr03IFvJY0psklaMtr GXwqgR95/Z8T86spbkBqiTGW1F0hqX3wV0jd9SN1t5bUXUzq03IFpJY0psklaEtqGXwqgR+5KCnD crEnm0PH3YF0Hu1jwRU29/zYfP5YOByf8O6E7+HoBd+tpT8ou56JgyILcrsQeua+sv/2433vdryX dJzJJWjLexl8KoEfed+X8V4Ct9PtG/Dex4IrvO/78b5f68X72Iuflitgs6Q7TC5BWzbL4FMJ/Mjm gYzNErjjog/+ChcHflwc1HJxgLl4Wq6Ai5LGNLkEbbkog08l8CMXhzIuSuCOiz74K1wc+nFxWMvF IebiabkCLkoa0+QStOWiDD6VwI9cHMm4KIHb2e0s7LRvsM078qPjqJaOI0zH03IFdJS0p8klaEtH GXwqgR/pOJbRUQK3k84b0XHsR8dxLR3HmI6n5QroKGlPk0vQlo4y+FQC/7S5KlmDWD564a9t+7c9 9/3b9Rv/bb7zf1qyZOtf0qImF8Hd5r8MPxXhP7FKuGfvhb/GKt+vSVc+Jwm+J93yg5Lwi5L0k5L0 m5IE/8wqLSWVZM/dTuVKrw0bCxuOX/LnxVvfB5nlXjCpdgArWpkymj1HUgRZHqg4zhPjHcBwUvyr K2VpJfugI4I7Wgk/6YjwR1oJP8WEku1zOyWDtOo2SytJpSytZJ9URHBHK+FHFRH+SCvhV5XQY4f7 jBS9Zkkh2XS3pJB9bxDBHSmEXxxE+CMphJ8cQg/8GSn6zZJCUiVLCtm2vQjuSCHcuBfhj6QQ7tyH Eryb1ww78kWc9pps67qptqYT7dNS8TTb8km49y7ET0X4I58ku6ZuQnITPvitvnTt4kvjtddZuZgT rlOFu9gi/LFTffYer3SJXxiarg1D0zgM7axcUZcId3JF+GOX+Oy/XekSvyAqXRtEpXEQ 1Vm5oi4R7maK8J+2CIQB/TO/oIwrveoXTHThsVcFE2lxMJG+WTCRi84UbjyK8J/6X7JH5L6P3KT/ /YJqdG1QjcZBNWfl4l6tWnW+WaCw7itt5BfsoWuDPTQO9jgr93Zt5B0ifKWB/CIQdG0EgsYRCGfl 4gZyXvUmM0q/b+C69hu4xt/Az8oVNEh4mwbx+wqra7/CavwV9qzcqw1ybcXg9xlQ138G1Pwz4HnJ 4ir5roKuLIME66CbLYTcTkHY671+r1o3+wlEC7/rhLRWje7Aa5896DOTGt3/1WBLWje7+6hF+2+O 0Z3RSO6JIy+VR6car05MH3/5PrCTiJBoPHoN1/3qe9KLUdhkJ0Yec/ZTgxr1KJGHQzk1qFFnEMk+ Mba/t+xV/3h9pRp1J5Hs3FBIK9WoQ4pe/4EmGjRqkMeG8qlBw0YNku1Ot2dotI5GjdZJFiQcwjqN G62Tx3bc2TDRbnacICNXw0OXbL/JzqgHaDxudvyTz6hZrZodRMGMOmp2Rh2BGXXU7Iw6ks6oZz0g 07jJKsVC54wq1Kjb8ble5NSgRj2Gz70QpwY1KnbRmX7nl0c+G3SnVWrUWYiOazunjKrUqLPxObN7 alCjs2Wfg5unBjU6Wxad3jvMloegTo3OlkVHwA6zZVKnRmfLPueIzoaIRmfLXudQzkxqeNgSz5aH HTDSNDtblsXQV7NlVqtmB1AwW46bnS17BRCfmdTsACafLYNBOWmySrLLECci9Ew6UyeN2ajLE97F N5HBZ69fJySN+krhFW4TGXz2ei+bNOpkhZd/TWTwmXiN1AVya3SIEN4qNZHBZ+IVGmnQRgc44cVG Exl89vr1YdLo+lB4t85EBp+9ftWTNLo6FV7vMpHBZ/K18fj1M8qk0bWx8IaSiQw+k6/MSYs2ujIX XrIxkcFnr98XSJrdF5BeEDER4mdgXyJpdl9CervBRIif3WBfpPf65XrS7L6I9HD/RIif3WBfBrVq s0sG4dn2iRA/A/tCSbP7QtKT3RMhfgb2pZJm96Wk55onQvxMvC9GwhQnTTapbGdrIjwYPBMe8g5Z gzY67Ao3tybCY7kzH/xpgzQ6Ygq3tybCQ7EzH/xpgzQ62Ak3uCbCI6kzEb6al7VBXN+k0dFSuMc1 ER7znInw1awMtWmjw63PNtepQY3uU/lsNJ0a1OhOkWirp1JSCL7tTBrdqxFttlRMRnVqdLfEZ7vj bJLQ6H6F137DmUkNT1yE63U7m/O5hfesVs3OPqTrZVqrZqcQYL06aXa96rXePDOp2QFMfI4uHIJb DKdN1kmSl/Gw+0Nq1Kjj8UnNd2pQoz7DJ6faqUGNyl2UD6vi8RiMydNG/YUo11HFZFSnRh2OT8ab U4ManTH7pD05NajRGbMo90V1W7HXTf+ndWp0xixKoFBdlYvq1OiM2ecW/rNBotEZs9cV7mcmNTxw Sb9wdfvEhzU7Y5ZdP13xmdWq2SEUzJinzc6Yve7ePTOp2QFMPGPujsA+1qzJOgnDb2GNGnU8IAJ2 1qjPADGos0blLo4CDVGvN+ovxIGYrE6NOhwQCzlrdMYMohFnjc6YpfGA5QhMLmeNTpilAXmsSo3O l0FE3KzZ+TKJSJs1O1++QUQY2YudNTtfvkFEFqtVswMomC/Pmp0vk4ikWbPzZVlEULpMi/ziPQ7z LPpof+AKSD48/+edu1vN3Z/44+H/QWuj8pb7ZXVR628fnq9qDX7+y5siy+bzVFtIt3rdD+kydpBN Ni8XSTDNs3IV/Nsz4N8873mbZPlCFWErTs3Ht3mycgb1up8bIwriLDHBMiuCmdokgQo2ap7GwY+/ /RQG//1bkMa2BdJJmuSXiuqM3TvBDY65WgivxxagXV7ei3ifJlVXm1Q9pkkXojaJ4jxbiMIpZKc1 JZ9IqnuPtRPVh0MPCsqyxJQNDEJeXsR78TK8TszwUcwUZgyU8VKaL1AAJ5eV17LcdaKM3ZJ5jyPo RbwXQTvXCdp5FEFluQeFqQeFmQcl8FffFH+NncIMhpIdIMfOi3gvdnavs7P7KHbKUhgKMxgKExje IH+hEuYvlG3BtWO/RBx1tLxogRcte9dp2XsULWVJFIU5FIUpFG+QQVEJMyjKvtqEN6DlRQu8aNm/ Tsv+o2gpS+MozOIoTOJ4gxyOSpjDUQJ3pLqI9yLV4DqpBo8ilaRVTC5M5SjM5HiDRI5K8kHDkkoC d6S6iPci1fA6qYaPIpWkVUwuO3MmvDBDFBN2JJXkk5IlleyLVHsWfiWEy4tXo+u8Gj2KV5KGMbns 6J7w2hBRXN6RV5KzcpZXsqN2oYxX4+u8Gj+KV5KGMbnsBKTw8hSf2MjrW2+SCbdLj81pEbY9tnfb D9vflTSMyYX3uEjvkfGKUr1ODuHG7GW8Hzl89v4ft/kv3P2Xbv9L9/8l+E/JYIXckEUrtEvZXoGj j8SChexiYssB4Q67EC+Lrj5yQLg1Lrotp4qJFXNAYsHC6xrnOg4I97GFeK9Y9KscEO5ki64Hcj0o wS+8br2u60Hhlq8Q7xW6f7UHhZu+otgj14MS/EJ2SbjtQeHuqBAvO+lw7EHh/qjw+qN2+ZWEyz4z PX11nqcfM8uz1BDucQrxUxH+SA1Z2HYo6trrc3j9oCm86x3hbqEIf+ydi1tDXm17PfREPyj0xLWt cMdMhD+27cXtEa+2vR44oR8UOOHaVrhrJMJ/WvwJQ11nX5m5e3XP9QAC/aAAAhf5JNy4EeE/dY/s gEMo6p7rH9L1gz6kV83jgtS9ghi9Knv9A69+0Afes8p+PSDOq6bXvzrqB311dP5EMk25/t1LP+i7 l5OipGbXv7zoW3958ZsYXt/61zff+vezzGfO+qBJa3XyzCuXdc1yW8uPiclNEG2bWbxsz0iLbxfo fO2+3z/m0STXa1812bfVItE3jzgSbZfHkfAg/ffZYqX+ITNBeO79FibIttoiUchXHMlTwgg9RyRP oSK1QBQwYEUkFaH86LLYD9wnf32tCbIBxCszfC3+Lmncayy4S9b1uvfLBgPZ4aQ75R+vM+Au2cLr DJANBLLY33vlza6z4D5ZrusskA0Ewviiu2V7rjXhPqmZa02QDQTCz7/3ylBcY8H/9wmF6+r+h0// W2f8Hz5Zb53x30Bq3brqfwOJcOuq/4dPW1tn/B8+yWyd8d9CSti6+n8LCVzr6v+HT7daO1z/CXKj 1tr/bSQyrW2CbyPraG0T/AlShNba/yfI51lr/zeRfLOmBb6JXJl19f8TZLasM/9PkIeyzvxvI2tk XQt8Gzke61pAtgQTraHulu2wzoL75Cass0A2FZdNpe+Xo6/WhPsk1Ks1QTYVk02l7pdXrsaE+6SB qzNAtgsrumnwbgnR6iy4T/qyOgtkg4HoKp+7JfKqs+A+abfqLJANBrK7Au6XfqrWhPvkiqo1QTYY yI5y3i9lUo0J98lwVGeAbDAQfhS7U66fOgvuk5mnzgLZYCD8PHKfHDV1Btwlo0ydAbKhQLpFfq/M KrUm3CcNSq0JsqFAukXaVDaQY0j689/vXCIQB3sZkb5IChWrQrWO/7BPDXrtk6c2UxOppXvv0P7m t4vZQKoo+UlWLuOvpSHphxb8z+W8Pg/J+bmPrjP6+3lmXmYV8XlK+T0V+j3W8Xus6/dYz++xvt9j A7/Hhn6PjfweG3s2b9vzOb9+0H5PeRbm16nar1O1X6dqv07Vfp2q/TpV+3Wq9utU7dmp1fmsGj8W Dp2r+Wu5qDzX518dkytVriwosqCVFFHlJ95VP3oTZctJOm0d/rIFDYcjW9AvSVG4gubZtKWiIt2o Is2WDh9axGKhlrFpuSRHFlcku8qCTidwuZGmUwd0zjRV89RVQRXBr2USfFdOg6AfhIP3/f576xnt 6q/75sr7p/NMq3mrXCjz0b190P3q63vhARd8erjdHg7Pyx90XpR/aB3TitO8ahz7/yuIZ4tWeRZV CPcPv0qct+MJaOQOTD0/bMrJJN19HgpsgwaHJ99boyeqnFdFXy5oMPpcUGk7wviUM3uTJ9Nk17Ij nOWFy+PV6btyfjr8P9ClpV2wTYtZEI6DeKICU6giMZ4tDAl4hG/ztEg+VIgP1XsPVT+T zhdHG0/eVK+zrz9c/cBRrDqG9snhvQ++i2OLtIa8FNlVpOph5Bgj+xgZYuQIIwcYiYFDjOxSpOZE cMsV+FIBFNNPYyDmrca8jXCvYJegsVQ0lorGjNeY8dXFqrQ/vwqtnReFg2pWohzwxbTo8OzztGiS Z4tXjkufB/NWnpgk3ySxG5eiauLR6Q8AfJEssvzJ4UfhuONfgJuBJMZ8WOVpZkfJqoS34ah+WnBY yvrMC2yTXDPGLXDLla1JodLlh1g9GQfstl8FW6SHedEF1BcTimeUyqNZukk+HGdux957/rlfIYe/ zso4/NhvVve8CP9QPK2Sr03HLswfj7Djq18u4T8t+z+v+MdupvJDOk/eauVmK8elf7JUep7E714k HO2MB8HnhKNqPv8i6ajxTIw5VzqxVro/q9VF74sx9u+WFu5XlipFEhVJ7LmL8GWpncEgeP1NFSqs NS7E1p2WC83r1JrXweadlgvN69aa18XmnZYLzTtf+IfD0622kwqEoy/n1j9U6YWdqvJExc+VUfbf vvtJN6lIv7ad+7idT8uF5g1qzRtg807LheYNa80bYvNOy4XmjWrNG2HzTsuF5o1rzRtj807LpQ68 Xe/B29yFn5ZMLbwyxggGmduMMrrOPk2tOy0V2lbbeBq33Vm50LzaAVrjAfqsXGhe7QCt8QB9Vi40 TzhAa/EArW8zQOvaAVrjAfqsXGhe7QCt8QB9Vi40r3aA1niAPisXmlc7QGs8QJ+VC82rHaA1HqDP yqUOvHaA1nyAPi+ZWnhljBEMMrcZZaJT+/qDL3YY7TI/JPZFX4sJCPu9aqOrNiQg+PkvL3YKuu3x i52CzcVgBM/K3vv+P69Z3PVESo+wyie/0yPsun6vurr1vepedj0gmbuXXQ/I5u1l1wPSOXvZ9YCM wF52PSCprJddD0hK6mXXA5Ja+vnVR2RV9LPsESn9vKZRd09B4ze5u3/2FC+7HpB5xMuuB2Tt8LLr AekqPFf+d8/T4Lnkv3tKBc+1/t0TIHgu8u+evsBzdf+v5AN/guQDi0VrZdfCbyfKVCcBui4k/7/K IsgmwSEW410Q/Jysy8TY1XnQ6Y267c5wPBoF+qlIzLuLb+n1Tt5y4aFuz22InuyCJjsXl2KeY1FO 19W3OHkQzdRyWsXVVAEJ/6xCB9z7J+ky/try/18nEHy+GHs99q8TCP86gXDlsW/yBML/AsMWGrEw XQIA --========/3F2E2C77000006C7/mail.tiscali.be-- From dave@hiauly1.hia.nrc.ca Tue Aug 5 19:38:23 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Tue, 5 Aug 2003 14:38:23 -0400 (EDT) Subject: [parisc-linux] Terminfo/termcap for a 70096 ... In-Reply-To: <03Aug5.161359cest.119152@ns.hiscom.nl> from "=?iso-8859-1?Q?=22Beerse=2C_Corn=E9=22?=" at Aug 5, 2003 03:53:34 pm Message-ID: <200308051838.h75IcNNC016978@hiauly1.hia.nrc.ca> > > On Tue, Aug 05, 2003 at 03:04:24PM +0200, "Beerse, Corn=E9" wrote: > > > Unfortunatly, while installing DebianWoody on a D370, I found none = > of > them > > > in the terminfo database (and no termcap file). And the HP700/96 = > came > with > > > the D370. I know one thing to do after finalizing the install.... > >=20 > > Yeah, Debian doesn't have termcap, there's a document somewhere that > > explains why. > > I don't care if they use termcap or terminfo. It bothers me that they = > have > no HP700xx entry in there, not even in the pa-risc distribution. = > Specially > the pa-risc distro can find a 700xx terminal at its console so it would = > be > nice if the TERM boot parameter can be set to indicate a hp700 = > terminal. GNU ncurses 2.2 has an entry for a HP 700/44 which is probably usable. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From thecrushedangel@hotmail.com Wed Aug 6 07:27:46 2003 From: thecrushedangel@hotmail.com (Russell Romain) Date: Wed, 06 Aug 2003 06:27:46 +0000 Subject: [parisc-linux] 712/80 Video Message-ID: Okay, Iv done some research, I have a HP 712/80 im playing with, is it correct that Im not going to get above 8bit 256colors on it? Or is there anything I can do to get 16bit color ? _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From jbglaw@lug-owl.de Wed Aug 6 07:56:47 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Wed, 6 Aug 2003 08:56:47 +0200 Subject: [parisc-linux] 2.6.x - impressions Message-ID: <20030806065647.GP1873@lug-owl.de> --nEiUIFvcAhJzEN7U Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! Now, where __cffc is checked in, I did some testing with 2.6.0-test2-pa6. This has been done on a B132L+, 768MB RAM, IBM PS/2 keyboard. - On my keyboard (german "QWERTZ" layout) the key containing '>', '<' and '|' doesn't work any longer. Annoying cut'n'paste starts right here8^> - If I strace some program, the box will crash some time later (while strace is still running). I can still toggle the NumLock LED by pressing the NumLock button, power doesn't instantly go off if I press the button. Hmmm... SysRQ doesn't work either, but is switched on in .config. Seems PrintScreen doesn't work either. TOC gives back access to the box, I haven't yet looked at the data. 2.4.x does do the same thing on strace, though... - Neither ALSA nor the OSS driver for harmony can be compiled. No sound (but I remember from 2.4.x that sound playing was unstable - when I placed some load on the box, it would eventually Oops...). - I became brave and installed XFree86, using the framebuffer driver: STI GSC/PCI core graphics driver Version 0.9a STI word mode ROM at f0011000, hpa at f8000000 STI id 2d08c0a7-9a02587, conforms to spec rev. 8.07 STI device: INTERNAL_EG_1280 fb0: stifb 1280x1024-8 frame buffer device, id: 2d08c0a7, mmio: 0xf8100000 Console: switching to colour frame buffer device 160x64 It starts, I can perfectly see X11's rasterized background. But when WindowMaker loads it's background image, the screen goes mostly black. Some white points can be seen (I feel like these are where colors of real contrast meet each other, so I can see the outlines of context menus...), but that's not enough to really work with it:) - 2.6.x "feels" a bit slower than 2.4.x (while still using HZ =3D=3D 100 for hppa1.1 machines), but that's what everybody and his mother tell you wrt. any given architecture... - I installed mozilla on my Athlon and on this B132L+ and started both via 'ssh -X' from my laptop (using --no-remote). Comparable startup-times for both, while my Athlon has 10x CPU MHz, 2x CPU count and 2x RAM size. Nice:) To draw a conclusion: Nice work:) Some minor tweaks need to be done (keyboard, graphics, strace), but 2/3 of them need to be done for 2.4.x, too. I think the keyboard thing is quite easy, and for the graphics, maybe that's only a small colormap problem. The strace problem (which is present in 2.4.x, too) looks a bit more complicated, but I'll have a look at the PIM and post new infos afterwards. Sound would be an add-on-feature, but personally I don't care much about it. I'm not one of those multimedia guys... MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); --nEiUIFvcAhJzEN7U Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/MKauHb1edYOZ4bsRAtyXAJ9I7cKfTHcxQNsL4gtaOVIfb3KW8gCbB9FF 0vDsZ5h8Cdk4v+EOzghpANo= =XJQK -----END PGP SIGNATURE----- --nEiUIFvcAhJzEN7U-- From jsoe0708@tiscali.be Wed Aug 6 09:23:59 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Wed, 6 Aug 2003 10:23:59 +0200 Subject: [parisc-linux] bitops.h patch Message-ID: <3F2E54A800000406@ocpmta8.freegates.net> --========/3F2E54A800000406/mail.tiscali.be Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi Grant, Thanks first for the help of previous patches :-) And here is the final one for bitops.h suggested by Lamont for 2.6: diff -Naur linux-2.6.0-test2.orig/include/asm-parisc/bitops.h linux-2.6.0-test2-b/include/asm-parisc/bitops.h --- linux-2.6.0-test2.orig/include/asm-parisc/bitops.h 2003-08-05 19:24:18.000000000 +0200 +++ linux-2.6.0-test2-b/include/asm-parisc/bitops.h 2003-08-06 10:02:00.000000000 +0200 @@ -223,16 +223,31 @@ * @word: The word to search * * Undefined if no bit exists, so code should check against 0 first. + * + * This is a fast ffs version written by "LaMont Jones " */ -static __inline__ unsigned long __ffs(unsigned long word) -{ - unsigned long result = 0; - while (!(word & 1UL)) { - result++; - word >>= 1; - } - return result; +static __inline__ int __ffs(int x) +{ + int ret; + __asm__(" ldi 32,%1\n" + " extru,<> %0,31,16,%%r0\n" + " extru,TR %0,15,16,%0\n" + " addi -16,%1,%1\n" + " extru,<> %0,31,8,%%r0\n" + " extru,TR %0,23,8,%0\n" + " addi -8,%1,%1\n" + " extru,<> %0,31,4,%%r0\n" + " extru,TR %0,27,4,%0\n" + " addi -4,%1,%1\n" + " extru,<> %0,31,2,%%r0\n" + " extru,TR %0,29,2,%0\n" + " addi -2,%1,%1\n" + " extru,= %0,31,1,%%r0\n" + " addi -1,%1,%1\n" + : "=r" (x), "=r" (ret) + : "0" (x), "1" (ret)); + return ret; } /* ================================================================================ If some interrest could you ci for me (I have no ci access) Thanks in advance, Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr --========/3F2E54A800000406/mail.tiscali.be Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Bitops-2.6.patch" ZGlmZiAtTmF1ciBsaW51eC0yLjYuMC10ZXN0Mi5vcmlnL2luY2x1ZGUvYXNtLXBhcmlzYy9iaXRv cHMuaCBsaW51eC0yLjYuMC10ZXN0Mi1iL2luY2x1ZGUvYXNtLXBhcmlzYy9iaXRvcHMuaAotLS0g bGludXgtMi42LjAtdGVzdDIub3JpZy9pbmNsdWRlL2FzbS1wYXJpc2MvYml0b3BzLmgJMjAwMy0w OC0wNSAxOToyNDoxOC4wMDAwMDAwMDAgKzAyMDAKKysrIGxpbnV4LTIuNi4wLXRlc3QyLWIvaW5j bHVkZS9hc20tcGFyaXNjL2JpdG9wcy5oCTIwMDMtMDgtMDYgMTA6MDI6MDAuMDAwMDAwMDAwICsw MjAwCkBAIC0yMjMsMTYgKzIyMywzMSBAQAogICogQHdvcmQ6IFRoZSB3b3JkIHRvIHNlYXJjaAog ICoKICAqIFVuZGVmaW5lZCBpZiBubyBiaXQgZXhpc3RzLCBzbyBjb2RlIHNob3VsZCBjaGVjayBh Z2FpbnN0IDAgZmlyc3QuCisgKgorICogVGhpcyBpcyBhIGZhc3QgZmZzIHZlcnNpb24gd3JpdHRl biBieSAiTGFNb250IEpvbmVzIDxsYW1vbnRAaHAuY29tPiIKICAqLwotc3RhdGljIF9faW5saW5l X18gdW5zaWduZWQgbG9uZyBfX2Zmcyh1bnNpZ25lZCBsb25nIHdvcmQpCi17Ci0JdW5zaWduZWQg bG9uZyByZXN1bHQgPSAwOwogCi0Jd2hpbGUgKCEod29yZCAmIDFVTCkpIHsKLQkJcmVzdWx0Kys7 Ci0JCXdvcmQgPj49IDE7Ci0JfQotCXJldHVybiByZXN1bHQ7CitzdGF0aWMgX19pbmxpbmVfXyBp bnQgX19mZnMoaW50IHgpCit7CisJaW50IHJldDsKKwlfX2FzbV9fKCIgbGRpICAgIDMyLCUxXG4i CisJCSIgZXh0cnUsPD4gICUwLDMxLDE2LCUlcjBcbiIKKwkJIiBleHRydSxUUiAgJTAsMTUsMTYs JTBcbiIKKwkJIiBhZGRpICAgIC0xNiwlMSwlMVxuIgorCQkiIGV4dHJ1LDw+ICAlMCwzMSw4LCUl cjBcbiIKKwkJIiBleHRydSxUUiAgJTAsMjMsOCwlMFxuIgorCQkiIGFkZGkgICAgLTgsJTEsJTFc biIKKwkJIiBleHRydSw8PiAgJTAsMzEsNCwlJXIwXG4iCisJCSIgZXh0cnUsVFIgICUwLDI3LDQs JTBcbiIKKwkJIiBhZGRpICAgIC00LCUxLCUxXG4iCisJCSIgZXh0cnUsPD4gICUwLDMxLDIsJSVy MFxuIgorCQkiIGV4dHJ1LFRSICAlMCwyOSwyLCUwXG4iCisJCSIgYWRkaSAgICAtMiwlMSwlMVxu IgorCQkiIGV4dHJ1LD0gICUwLDMxLDEsJSVyMFxuIgorCQkiIGFkZGkgICAgLTEsJTEsJTFcbiIK KwkJOiAiPXIiICh4KSwgIj1yIiAocmV0KQorCQk6ICIwIiAoeCksICIxIiAocmV0KSk7CisJcmV0 dXJuIHJldDsKIH0KIAogLyoK --========/3F2E54A800000406/mail.tiscali.be Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Bitops-2.4.patch" ZGlmZiAtTmF1ciBsaW51eC0yLjQuMjEtcGE5Lm9yaWcvaW5jbHVkZS9hc20tcGFyaXNjL2JpdG9w cy5oIGxpbnV4LTIuNC4yMS1wYTktYi9pbmNsdWRlL2FzbS1wYXJpc2MvYml0b3BzLmgKLS0tIGxp bnV4LTIuNC4yMS1wYTkub3JpZy9pbmNsdWRlL2FzbS1wYXJpc2MvYml0b3BzLmgJMjAwMy0wOC0w NSAxOToxNzozNy4wMDAwMDAwMDAgKzAyMDAKKysrIGxpbnV4LTIuNC4yMS1wYTktYi9pbmNsdWRl L2FzbS1wYXJpc2MvYml0b3BzLmgJMjAwMy0wOC0wNiAwOTo1MzoyNi4wMDAwMDAwMDAgKzAyMDAK QEAgLTIwOCwxMyArMjA4LDQ5IEBACiAKICNpZmRlZiBfX0tFUk5FTF9fCiAKKy8qKgorICogX19m ZnMgLSBmaW5kIGZpcnN0IGJpdCBpbiB3b3JkLgorICogQHdvcmQ6IFRoZSB3b3JkIHRvIHNlYXJj aAorICoKKyAqIFVuZGVmaW5lZCBpZiBubyBiaXQgZXhpc3RzLCBzbyBjb2RlIHNob3VsZCBjaGVj ayBhZ2FpbnN0IDAgZmlyc3QuCisgKgorICogVGhpcyBpcyBhIGZhc3QgZmZzIHZlcnNpb24gd3Jp dHRlbiBieSAiTGFNb250IEpvbmVzIDxsYW1vbnRAaHAuY29tPiIKKyAqLworCitzdGF0aWMgX19p bmxpbmVfXyBpbnQgX19mZnMoaW50IHgpCit7CisJaW50IHJldDsKKwlfX2FzbV9fKCIgbGRpICAg IDMyLCUxXG4iCisJCSIgZXh0cnUsPD4gICUwLDMxLDE2LCUlcjBcbiIKKwkJIiBleHRydSxUUiAg JTAsMTUsMTYsJTBcbiIKKwkJIiBhZGRpICAgIC0xNiwlMSwlMVxuIgorCQkiIGV4dHJ1LDw+ICAl MCwzMSw4LCUlcjBcbiIKKwkJIiBleHRydSxUUiAgJTAsMjMsOCwlMFxuIgorCQkiIGFkZGkgICAg LTgsJTEsJTFcbiIKKwkJIiBleHRydSw8PiAgJTAsMzEsNCwlJXIwXG4iCisJCSIgZXh0cnUsVFIg ICUwLDI3LDQsJTBcbiIKKwkJIiBhZGRpICAgIC00LCUxLCUxXG4iCisJCSIgZXh0cnUsPD4gICUw LDMxLDIsJSVyMFxuIgorCQkiIGV4dHJ1LFRSICAlMCwyOSwyLCUwXG4iCisJCSIgYWRkaSAgICAt MiwlMSwlMVxuIgorCQkiIGV4dHJ1LD0gICUwLDMxLDEsJSVyMFxuIgorCQkiIGFkZGkgICAgLTEs JTEsJTFcbiIKKwkJOiAiPXIiICh4KSwgIj1yIiAocmV0KQorCQk6ICIwIiAoeCksICIxIiAocmV0 KSk7CisJcmV0dXJuIHJldDsKK30KKwogLyoKICAqIGZmczogZmluZCBmaXJzdCBiaXQgc2V0LiBU aGlzIGlzIGRlZmluZWQgdGhlIHNhbWUgd2F5IGFzCiAgKiB0aGUgbGliYyBhbmQgY29tcGlsZXIg YnVpbHRpbiBmZnMgcm91dGluZXMsIHRoZXJlZm9yZQogICogZGlmZmVycyBpbiBzcGlyaXQgZnJv bSB0aGUgYWJvdmUgZmZ6IChtYW4gZmZzKS4KICAqLwotCi0jZGVmaW5lIGZmcyh4KSBnZW5lcmlj X2Zmcyh4KQorc3RhdGljIF9faW5saW5lX18gaW50IGZmcyhpbnQgeCkKK3sKKwlpZiAoIXgpCisJ CXJldHVybiAwOworCXJldHVybiBfX2ZmcygodW5zaWduZWQgbG9uZyl4KTsKK30KIAogLyoKICAq IGh3ZWlnaHROOiByZXR1cm5zIHRoZSBoYW1taW5nIHdlaWdodCAoaS5lLiB0aGUgbnVtYmVyCg== --========/3F2E54A800000406/mail.tiscali.be-- From grundler@parisc-linux.org Wed Aug 6 15:32:19 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 6 Aug 2003 08:32:19 -0600 Subject: [parisc-linux] kernel BUG at include/linux/skbuff.h:834! Message-ID: <20030806143219.GC30797@dsl2.external.hp.com> When I included a 4th a500 ("ios") into my distcc cluster, I didn't think much of it running 2.6.0-test1 (IIRC). System panic'd near the end of a kernel build. Output and stack "contents" appended. NIC which was under load was tg3 . grant kernel BUG at include/linux/skbuff.h:834! Kernel addresses on the stack: [<00000000103065e4>] [<00000000000c49c0>] [<0000000010306aa0>] [<00000000101445c4>] [<0000000010248e4c>] [<000000001019d900>] [<00000000101115f0>] [<000000001010a074>] [<00000000101893b8>] [<000000001018a218>] [<000000001019d900>] [<00000000101115f0>] [<0000000010161888>] [<000000001032b644>] [<000000001032bfd4>] [<0000000010161d50>] [<0000000010354cc0>] [<00000000101cd1dc>] [<0000000010184a34>] [<0000000010184b74>] [<000000001019d900>] [<0000000010184cfc>] [<000000001010ae4c>] [<000000001010a074>] kernel BUG at include/linux/skbuff.h:870! Kernel addresses on the stack: [<00000000103065e4>] [<00000000000c49c0>] [<0000000010306aa0>] [<00000000101445c4>] [<0000000010248e4c>] [<000000001019d900>] [<00000000101115f0>] [<000000001010a074>] [<00000000101893b8>] [<000000001018a218>] [<000000001019d900>] [<00000000101115f0>] [<0000000010161888>] [<000000001032b644>] [<000000001032bfd4>] [<0000000010161d50>] [<0000000010354cc0>] [<00000000101cd1dc>] [<0000000010184a34>] [<0000000010184b74>] [<000000001019d900>] [<0000000010184cfc>] [<000000001010ae4c>] [<000000001010a074>] 0x103065e4 netif_receive_skb+16c 0xc49c0 _DYNAMIC+c49c0 0x10306aa0 net_rx_action+148 0x101445c4 do_softirq+cc 0x10248e4c iosapic_interrupt+4c 0x1019d900 locate_fd+100 0x101115f0 pdc_pat_chassis_send_log+78 0x1010a074 intr_return+0 0x101893b8 unmap_underlying_metadata+20 0x1018a218 __block_prepare_write+5a0 0x1019d900 locate_fd+100 0x101115f0 pdc_pat_chassis_send_log+78 0x10161888 generic_file_aio_write_nolock+820 0x1032b644 cleanup_rbuf+bc 0x1032bfd4 tcp_recvmsg+374 0x10161d50 generic_file_aio_write+c0 0x10354cc0 inet_recvmsg+58 0x101cd1dc ext3_file_write+34 0x10184a34 do_sync_write+84 0x10184b74 vfs_write+fc 0x1019d900 locate_fd+100 0x10184cfc sys_write+64 0x1010ae4c syscall_exit+0 0x1010a074 intr_return+0 From willy@debian.org Wed Aug 6 15:57:00 2003 From: willy@debian.org (Matthew Wilcox) Date: Wed, 6 Aug 2003 15:57:00 +0100 Subject: [parisc-linux] kernel BUG at include/linux/skbuff.h:834! In-Reply-To: <20030806143219.GC30797@dsl2.external.hp.com> References: <20030806143219.GC30797@dsl2.external.hp.com> Message-ID: <20030806145700.GU22222@parcelfarce.linux.theplanet.co.uk> On Wed, Aug 06, 2003 at 08:32:19AM -0600, Grant Grundler wrote: > When I included a 4th a500 ("ios") into my distcc cluster, I didn't think > much of it running 2.6.0-test1 (IIRC). System panic'd near the end > of a kernel build. Output and stack "contents" appended. > NIC which was under load was tg3 . "I don't believe you" ;-) > kernel BUG at include/linux/skbuff.h:834! > Kernel addresses on the stack: > [<00000000103065e4>] [<00000000000c49c0>] [<0000000010306aa0>] [<00000000101445c4>] > [<0000000010248e4c>] [<000000001019d900>] [<00000000101115f0>] [<000000001010a074>] > [<00000000101893b8>] [<000000001018a218>] [<000000001019d900>] [<00000000101115f0>] > [<0000000010161888>] [<000000001032b644>] [<000000001032bfd4>] [<0000000010161d50>] > [<0000000010354cc0>] [<00000000101cd1dc>] [<0000000010184a34>] [<0000000010184b74>] > [<000000001019d900>] [<0000000010184cfc>] [<000000001010ae4c>] [<000000001010a074>] ^^^^^ these addresses > kernel BUG at include/linux/skbuff.h:870! > Kernel addresses on the stack: > [<00000000103065e4>] [<00000000000c49c0>] [<0000000010306aa0>] [<00000000101445c4>] > [<0000000010248e4c>] [<000000001019d900>] [<00000000101115f0>] [<000000001010a074>] > [<00000000101893b8>] [<000000001018a218>] [<000000001019d900>] [<00000000101115f0>] > [<0000000010161888>] [<000000001032b644>] [<000000001032bfd4>] [<0000000010161d50>] > [<0000000010354cc0>] [<00000000101cd1dc>] [<0000000010184a34>] [<0000000010184b74>] > [<000000001019d900>] [<0000000010184cfc>] [<000000001010ae4c>] [<000000001010a074>] ^^^^^ are the same as these addresses The first BUG is in skb_put() and the second BUG is in skb_pull(). Neither are called from netif_receive_skb(), nor net_rx_action(). > 0x103065e4 netif_receive_skb+16c > 0xc49c0 _DYNAMIC+c49c0 > 0x10306aa0 net_rx_action+148 > 0x101445c4 do_softirq+cc > 0x10248e4c iosapic_interrupt+4c > 0x1019d900 locate_fd+100 > 0x101115f0 pdc_pat_chassis_send_log+78 > 0x1010a074 intr_return+0 > 0x101893b8 unmap_underlying_metadata+20 > 0x1018a218 __block_prepare_write+5a0 > 0x1019d900 locate_fd+100 > 0x101115f0 pdc_pat_chassis_send_log+78 > 0x10161888 generic_file_aio_write_nolock+820 > 0x1032b644 cleanup_rbuf+bc > 0x1032bfd4 tcp_recvmsg+374 > 0x10161d50 generic_file_aio_write+c0 > 0x10354cc0 inet_recvmsg+58 > 0x101cd1dc ext3_file_write+34 > 0x10184a34 do_sync_write+84 > 0x10184b74 vfs_write+fc > 0x1019d900 locate_fd+100 > 0x10184cfc sys_write+64 > 0x1010ae4c syscall_exit+0 > 0x1010a074 intr_return+0 So none of these addresses make any sense ;-( -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From bame@ldl.fc.hp.com Wed Aug 6 19:48:26 2003 From: bame@ldl.fc.hp.com (Paul Bame) Date: Wed, 6 Aug 2003 12:48:26 -0600 Subject: [parisc-linux] 2.5 -> 2.6 tree switch tomorrow Message-ID: <20030806184826.GA11934@ldl.fc.hp.com> Hey folks we're closing the 2.5 tree and opening the 2.6 tree tomorrow between 10AM and 10:30AM US Mountain (GMT-7). First the 2.5 tree will be set to read only. Then all the changes in that tree will be moved to the 2.6 tree which will be announced as open for busines. The 2.5 tree will stay around in read-only form for diffs and history. -P From vincent.carter@sbcglobal.net Wed Aug 6 20:53:36 2003 From: vincent.carter@sbcglobal.net (Vint Le) Date: Wed, 06 Aug 2003 15:53:36 -0400 Subject: [parisc-linux] Thank you Message-ID: <3F315CC0.2050900@sbcglobal.net> Thanks... From webyw@un165.com Thu Aug 7 03:11:38 2003 From: webyw@un165.com (=?GB2312?B?uePW3cGqzag=?=) Date: Thu, 7 Aug 2003 10:11:38 +0800 Subject: [parisc-linux] =?GB2312?B?uePW3cGqzaiw78T6yqG7sLfR?= Message-ID: <20030807020942.44921491C@dsl2.external.hp.com> ¹ãÖÝÁªÍ¨°ïÄúÊ¡»°·Ñ ÁªÍ¨CDMA£¬ÏÖ´úͨѶ£¬Ê±ÉÐÑ¡Ôñ£¡£¡£¡ ÕæÕýµÄO»ú¼ÛÕæÕýµÄµ¥ÏòÀ´µç°üÔÂÌײͣº 1¡¢18Ôªµ¥ÏòÀ´µç°üÔÂÌײͣ¬´ò³ö0.36Ôª/·ÖÖÓ£¬´ò½øÃâ·Ñ¡£ 2¡¢ÎÞÔÂ×âÎÞ×îµÍÏû·ÑÌײÍ0.4Ôª/·ÖÖÓ 3¡¢138Ôª°ü400Ôª£¬168Ôª°ü600Ôª£¬228Ôª°ü1000Ôª°üÔÂÌ×²Í ÒµÎñ°ìÀí£º ƾÉí·ÝÖ¤¸´Ó¡¼þÔ¤´æ600Ôª»°·Ñ¼´¿É»ñÔùһ̨ÈýÐÇCDMAÊÖ»úÒ»²¿ ÍøÉÏ°ìÀíÕʺţºÕÐÉÌÒøÐУº9555-5020-0044-3114 ×Éѯµç»°£º85580308¡¢85580908 ͶËߵ绰£º89822292 ÖйúÁªÍ¨¹ãÖÝ·Ö¹«Ë¾ From webyw@un165.com Thu Aug 7 03:11:40 2003 From: webyw@un165.com (=?GB2312?B?uePW3cGqzag=?=) Date: Thu, 7 Aug 2003 10:11:40 +0800 Subject: [parisc-linux] =?GB2312?B?uePW3cGqzaiw78T6yqG7sLfR?= Message-ID: <20030807020944.58EFB491A@dsl2.external.hp.com> ¹ãÖÝÁªÍ¨°ïÄúÊ¡»°·Ñ ÁªÍ¨CDMA£¬ÏÖ´úͨѶ£¬Ê±ÉÐÑ¡Ôñ£¡£¡£¡ ÕæÕýµÄO»ú¼ÛÕæÕýµÄµ¥ÏòÀ´µç°üÔÂÌײͣº 1¡¢18Ôªµ¥ÏòÀ´µç°üÔÂÌײͣ¬´ò³ö0.36Ôª/·ÖÖÓ£¬´ò½øÃâ·Ñ¡£ 2¡¢ÎÞÔÂ×âÎÞ×îµÍÏû·ÑÌײÍ0.4Ôª/·ÖÖÓ 3¡¢138Ôª°ü400Ôª£¬168Ôª°ü600Ôª£¬228Ôª°ü1000Ôª°üÔÂÌ×²Í ÒµÎñ°ìÀí£º ƾÉí·ÝÖ¤¸´Ó¡¼þÔ¤´æ600Ôª»°·Ñ¼´¿É»ñÔùһ̨ÈýÐÇCDMAÊÖ»úÒ»²¿ ÍøÉÏ°ìÀíÕʺţºÕÐÉÌÒøÐУº9555-5020-0044-3114 ×Éѯµç»°£º85580308¡¢85580908 ͶËߵ绰£º89822292 ÖйúÁªÍ¨¹ãÖÝ·Ö¹«Ë¾ From rscholz@hrzpub.tu-darmstadt.de Thu Aug 7 05:01:38 2003 From: rscholz@hrzpub.tu-darmstadt.de (Ruediger Scholz) Date: Thu, 07 Aug 2003 06:01:38 +0200 Subject: [parisc-linux] Problem: linux-2.6.0-test-pa6 and ssh Message-ID: <3F31CF22.9080706@hrzpub.tu-darmstadt.de> Hi, booting the 2.6.0-test2-pa6 kernel works quite right, but when I try to login via ssh I get the following error after entering the password: "Server refused to allocate pty". With a 2.4-kernel and latest 2.5-kernel it worked alright. I using devfs and debian unstable on my 715/100. Has anyone an idea how to get ssh to work? Ruediger From jbglaw@lug-owl.de Thu Aug 7 06:53:46 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Thu, 7 Aug 2003 07:53:46 +0200 Subject: [parisc-linux] 2.6.x - impressions In-Reply-To: <20030806065647.GP1873@lug-owl.de> References: <20030806065647.GP1873@lug-owl.de> Message-ID: <20030807055346.GI1873@lug-owl.de> --mAEYYP2W/5hrqqYE Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2003-08-06 08:56:47 +0200, Jan-Benedict Glaw wrote in message <20030806065647.GP1873@lug-owl.de>: > - I became brave and installed XFree86, using the framebuffer driver: >=20 > STI GSC/PCI core graphics driver Version 0.9a > STI word mode ROM at f0011000, hpa at f8000000 > STI id 2d08c0a7-9a02587, conforms to spec rev. 8.07 > STI device: INTERNAL_EG_1280 > fb0: stifb 1280x1024-8 frame buffer device, id: 2d08c0a7, mmio: > 0xf8100000 > Console: switching to colour frame buffer device 160x64 >=20 > It starts, I can perfectly see X11's rasterized background. But when > WindowMaker loads it's background image, the screen goes mostly black. > Some white points can be seen (I feel like these are where colors of > real contrast meet each other, so I can see the outlines of context > menus...), but that's not enough to really work with it:) After some reading, this seems to be a XFree86 4.2.x problem. The RENDER engine (doing antialiasing) seems to pre-allocate 200 colours in advance. After some background image is displayed (which for sure will take most of the remaining colours) there are "no" colours left to display menus, xterms and the like. This will change (or configurable) in Xfree86 4.3.x. MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); --mAEYYP2W/5hrqqYE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/MelqHb1edYOZ4bsRAqzrAJoDku0Mytz/eVUmcLhUmqquV1naMQCfW6Dm HvUjJ12YR6cpWDKI3hR2RyQ= =DSDq -----END PGP SIGNATURE----- --mAEYYP2W/5hrqqYE-- From Randolph Chung Thu Aug 7 07:02:49 2003 From: Randolph Chung (Randolph Chung) Date: Wed, 6 Aug 2003 23:02:49 -0700 Subject: [parisc-linux] Problem: linux-2.6.0-test-pa6 and ssh In-Reply-To: <3F31CF22.9080706@hrzpub.tu-darmstadt.de> References: <3F31CF22.9080706@hrzpub.tu-darmstadt.de> Message-ID: <20030807060249.GB4979@tausq.org> > booting the 2.6.0-test2-pa6 kernel works quite right, but when I try to > login via ssh I get the following error after entering the password: > "Server refused to allocate pty". > With a 2.4-kernel and latest 2.5-kernel it worked alright. > I using devfs and debian unstable on my 715/100. > Has anyone an idea how to get ssh to work? hm.. it seems to work for me... can you try running sshd in debug mode (sshd -ddd, output goes to syslog) and see if that tells you more about what's happening? randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From Randolph Chung Thu Aug 7 07:28:19 2003 From: Randolph Chung (Randolph Chung) Date: Wed, 6 Aug 2003 23:28:19 -0700 Subject: [parisc-linux] 2.6.x - impressions In-Reply-To: <20030806065647.GP1873@lug-owl.de> References: <20030806065647.GP1873@lug-owl.de> Message-ID: <20030807062818.GC4979@tausq.org> --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > - If I strace some program, the box will crash some time later (while > strace is still running). I can still toggle the NumLock LED by what did you try to strace that caused the machine to crash?=20 randolph --=20 Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/MfGCULspdC1Zp9IRAsQUAJ9vG4Q6et9HEcSZf/4XKDhLFQf8vgCgiFem pmlH1wCM0+EKp7iEtIbba+s= =yZsh -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From jbglaw@lug-owl.de Thu Aug 7 07:31:20 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Thu, 7 Aug 2003 08:31:20 +0200 Subject: [parisc-linux] 2.6.x - impressions In-Reply-To: <20030807062818.GC4979@tausq.org> References: <20030806065647.GP1873@lug-owl.de> <20030807062818.GC4979@tausq.org> Message-ID: <20030807063120.GK1873@lug-owl.de> --3560iJfidtGRl43/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2003-08-06 23:28:19 -0700, Randolph Chung wrote in message <20030807062818.GC4979@tausq.org>: > > - If I strace some program, the box will crash some time later (while > > strace is still running). I can still toggle the NumLock LED by >=20 > what did you try to strace that caused the machine to crash?=20 cvsps. That's a small programm querying a CVS server to get patchsets (not simple patches) out of it. It's for a BKCVS to Arch gateway I'm working on. MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); --3560iJfidtGRl43/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/MfI4Hb1edYOZ4bsRAhoIAKCG76qdWymEgrW26OmADvi6sCYIPgCeOe/c Jsi3QMAj72kvTqQVWn4b9LY= =Rc+H -----END PGP SIGNATURE----- --3560iJfidtGRl43/-- From rscholz@hrzpub.tu-darmstadt.de Thu Aug 7 07:45:51 2003 From: rscholz@hrzpub.tu-darmstadt.de (Ruediger Scholz) Date: Thu, 07 Aug 2003 08:45:51 +0200 Subject: [parisc-linux] Problem: linux-2.6.0-test-pa6 and ssh In-Reply-To: <20030807060249.GB4979@tausq.org> References: <3F31CF22.9080706@hrzpub.tu-darmstadt.de> <20030807060249.GB4979@tausq.org> Message-ID: <3F31F59F.1040608@hrzpub.tu-darmstadt.de> Thanks for your help, but I already found the answer. (rtfm, or in this case not the manual but "The post-halloween document. v0.42" from Dave Jones... ;) ) When using devfs with 2.4 I didn't need to mount the devpts-fs, so I comment this part out in /etc/fstab. Because of the changes to devfs in 2.5 I had to mount the devpts now. So I mounted devpts, and everything worked like a charm again. Running ssh in debug mode and without mounted devpts gives: ----------SNIP------ debug1: Allocating pty. openpty: No such file or directory session_pty_req: session 0 alloc failed ----------SNAP----- Ruediger Randolph Chung schrieb: >hm.. it seems to work for me... can you try running sshd in debug >mode (sshd -ddd, output goes to syslog) and see if that tells you more >about what's happening? > >randolph > > From jbglaw@lug-owl.de Thu Aug 7 09:49:20 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Thu, 7 Aug 2003 10:49:20 +0200 Subject: [parisc-linux] 2.6.x - impressions In-Reply-To: <20030807062818.GC4979@tausq.org> References: <20030806065647.GP1873@lug-owl.de> <20030807062818.GC4979@tausq.org> Message-ID: <20030807084920.GL1873@lug-owl.de> --DFTsS40uuchi7su8 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2003-08-06 23:28:19 -0700, Randolph Chung wrote in message <20030807062818.GC4979@tausq.org>: > > - If I strace some program, the box will crash some time later (while > > strace is still running). I can still toggle the NumLock LED by >=20 > what did you try to strace that caused the machine to crash?=20 I now did a TOC when it hung. (No virtual console switching possible, but NumLock still worked. Here's my TOC content: General Registers 0 - 31 0 - 3 0x00000000 0x103000f0 0x101c77fc 0x37efc4e5 4 - 7 0x00000008 0x00000001 0xffffffff 0x00000001 8 - 11 0xffffffff 0x37efc4e4 0x00000010 0xc8103b1c 12 - 15 0x0000006c 0x102b24f4 0x00047ae0 0x00000020 16 - 19 0x37efc080 0x0000ff00 0x00025000 0x00000001 20 - 23 0x00000000 0x0000000e 0x00000010 0x00000000 24 - 27 0x00000000 0xffffffff 0x37efc4e5 0x102e4010 28 - 31 0x00000000 0x00000000 0x37efc740 0x101c717c Control Registers 0 - 31 0 - 3 0x00000000 0x00000000 0x00000000 0x00000000 4 - 7 0x00000000 0x00000000 0x00000000 0x00000000 8 - 11 0x00000754 0x00000000 0x000000c0 0x00000000 12 - 15 0x00000000 0x00000000 0x00107800 0xf1000000 16 - 19 0xd5a827ac 0x00000000 0x101c6f58 0x92602000 20 - 23 0x00000000 0x37efc720 0x0004000f 0x00000000 24 - 27 0x002f6000 0x27f25000 0xfefffffb 0xaaaaaaaa 28 - 31 0xaaaaaaaa 0x11111111 0x37efc000 0x10354000 Space Registers 0 - 7 0 - 3 0x00000000 0x000001bf 0x00000000 0x000003aa 4 - 7 0x00000000 0x00000000 0x00000000 0x00000000 IIA Space =3D 0x00000000 IIA Offset =3D 0x101c6f5c CPU State =3D 0x9e000001 -------------------------------------------------------- r02: vsnprintf + 0x604 r27: $global$ + 0x0 r31: number + 0x2b8 IIA Offset: number + 0x98 So it's most probably dieing in some printk() or something like that with a bad parameter or format string? Is there some way to get more than only the CPU state (eg. more stack frames)? MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); --DFTsS40uuchi7su8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/MhKQHb1edYOZ4bsRAnFnAJ4/mDaqwCdIyFKQsJA83yVU8RZ0ygCfXVqv ejH1GLD+OMFcMQOR+VDr8D0= =KzUq -----END PGP SIGNATURE----- --DFTsS40uuchi7su8-- From Stewart Sweet" --13_86E0.EB6_.77.E Content-Type: text/html; Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxib2R5Pg0KDQo8Zm9udCBzaXplPSIyIj4NCg0KYWR2ZXJiPC9mb250Pg0K DQo8cCBhbGlnbj0iY2VudGVyIj5IaSwgUGFyaXNjLWxpbnV4LCBNZWRpaWNhdGlvbnMgUHJl c2NyaWJlZCBPbmxpbmUsIEdldCBQcmVzY3JpYmVkIFZWaWFncmEsRGlldFBpbGxzPC9wPg0K DQo8cCBhbGlnbj0iY2VudGVyIj5hbmQgbXVjaG1vcmUgb25saW5lIU92ZXJuaWdodCBTaGlp cHBpbmchISBObw0KUHJlc2NyaXB0aW9uISEgPGEgaHJlZj0iaHR0cDovL3d3dy5jaGFpci1n cmVuYWRhLmNvbS92cHI2MjMyLyI+cyBlIGUmbmJzcDsgbm93ITwvYT48L3A+DQoNCjxwIGFs aWduPSJjZW50ZXIiPjxhIGhyZWY9Imh0dHA6Ly93d3cuY2hhaXItZ3JlbmFkYS5jb20vdnBy NjIzMi8iPg0KPGltZyBib3JkZXI9IjAiIHNyYz0iaHR0cDovL21lZHMyNDcuaW5mby9hZHMu anBnIiBhbHQ9ImdmZHNnIHNkZmdzZCBhc2RmYSBzZGYgZmFzZmFzZCBzIGZzZGVmc2Qgc2Qg c2RmIHNkZnNkIHNkZiAgc2Rmc3MgICBzZGZzZGZzZGZzICBzZGRmICBzZGZzIHNkZiAgc2Rm c2RzIj48L2E+PC9wPg0KDQo8Zm9udCBzaXplPSIyIj50cmFjZWFibGUmbmJzcDsmbmJzcDsm bmJzcDsgY29sbGF0ZXJhbDwvZm9udD48cD48YSBocmVmPSJtYWlsdG86cmVtb3ZlQGhpZ2hz cGlyaXQud3MiPjxmb250IHNpemU9IjIiPm4gbw0KbSBhIGkgbDwvZm9udD48L2E+PC9wPg0K DQo8Zm9udCBzaXplPSIyIj5hdm9jYWRvJm5ic3A7IGxpYWlzb24gPC9mb250Pg0KPHA+PGZv bnQgc2l6ZT0iMiI+a2hyb3FvJm5ic3A7IGJ1eHRvbiZuYnNwOyZuYnNwOyA8L2ZvbnQ+PC9w Pg0KPHA+PGZvbnQgc2l6ZT0iMiI+ZXllc29yZTwvZm9udD48L3A+DQoNCjwvYm9keT4NCg0K PC9odG1sPmx2a2huYSBxcXlsb2N5c3VpZ2FuamYNCiBjbHFscXFuaWlicGlvdWty --13_86E0.EB6_.77.E-- From sugarat@mail.flyer.co.uk Thu Aug 7 12:15:43 2003 From: sugarat@mail.flyer.co.uk (sugarat@mail.flyer.co.uk) Date: Thu, 7 Aug 2003 07:15:43 -0400 Subject: [parisc-linux] Xfree86 on C200 Message-ID: <48270-22003847111543568@M2W027.mail2web.com> I am getting a weird error on attempting to run Xfree86 on my C200=2E The= kernel startup displays the fact that device fb0: has initialised okay, so= the framebuffer is detected, but upon starting X I get a message saying that the weight specified (000) is inconsistent with the colour depth (32)= Can anyone offer any advice please? I dont know what else to try now=2E=2E= =20 Many thanks, Adam -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web=2Ecom/ =2E From evittor@ctc.cl Thu Aug 7 15:07:19 2003 From: evittor@ctc.cl (Edson Vittoriano P.) Date: Thu, 7 Aug 2003 10:07:19 -0400 Subject: [parisc-linux] HP Visualize C3000/785 Message-ID: Greetings I tried to install PA-Risc Linux in a Visualize C3000/785, but it happened a HPMC. When I reinitiated the machine no longer I had console. Now the single console unfolds prompt login, does not unfold the beginning of firmware, nor no other operation of load, does not allow to conduct no other operation. Some idea? Edson Vittoriano Piuzzi Ingeniero de Seguridad Informática/CISSP Sub-Gerencia Explotación de Redes y Servicios de Datos Telefónica Empresas CTC Chile Fono:(56)-(2)-691-50-71 Móvil: 9-321-25-23 Santiago-Chile From carlos@baldric.uwo.ca Thu Aug 7 15:14:22 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Thu, 7 Aug 2003 10:14:22 -0400 Subject: [parisc-linux] HP Visualize C3000/785 In-Reply-To: References: Message-ID: <20030807141421.GF13455@systemhalted> Edson, > Greetings I tried to install PA-Risc Linux in a Visualize C3000/785, but it > happened a HPMC. Que ISO estavas usando? > When I reinitiated the machine no longer I had console. What console? The actual firmware console, or an OS console? (e.g. you previously had HPUX installed :). > Now the single console unfolds prompt login, does not unfold the beginning > of firmware, nor no other operation of load, does not allow to conduct no > other operation. What does this console look like? Feel free to writeup the description in Spanish if you feel more comfortable (soy Argentino). c. From geos@canada.com Thu Aug 7 16:36:19 2003 From: geos@canada.com (geos@canada.com) Date: Thu, 07 Aug 2003 08:36:19 -0700 (PDT) Subject: [parisc-linux] adding a second nic to B1000 Message-ID: <20030807083620.21079.h004.c009.wm@mail.canada.com.criticalpath.net> Ive been trying for 5 days not to get a second nic installed into hp b1000 using pa-risc woody 3 iv read all i can find , been to all the irc chnls im at a loss here it may be the 3com 3C95x pci card does not work in this box it should work with debian the card does work in i386 box the builtin nic works fine can this be done? if so is there a howto ? if this card is not supported what nic cards are ? TIA From jsoe0708@tiscali.be Thu Aug 7 16:37:35 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 7 Aug 2003 17:37:35 +0200 Subject: [parisc-linux] a fast fls also for 2.6? Message-ID: <3F2E2C7700000FE5@ocpmta2.freegates.net> Hi pa, well as last 2.6 doesn't yet boot on my b2k and having any chance to grab any debug info (I tried 32bits and 64bits kernel: same results. And only TOC just refer to unrelevant info. OTC it seems to works fine on the b180. I really don't know where to look for this bug?), I tried to understand better Lamont's Fastffs code. To verify that I actualy understand it, I tried this Fast_fls: #include #include int generic_fls(int x) { int r = 32; if (!x) return 0; if (!(x & 0xffff0000u)) { x <<= 16; r -= 16; } if (!(x & 0xff000000u)) { x <<= 8; r -= 8; } if (!(x & 0xf0000000u)) { x <<= 4; r -= 4; } if (!(x & 0xc0000000u)) { x <<= 2; r -= 2; } if (!(x & 0x80000000u)) { x <<= 1; r -= 1; } return r; } int PseudoFast_fls(int x) { /* Rewritte off generic_fls to mimic what would be done in asm (just as proof of concept) */ int r = 1; if (!x) return 0; if (!(x & 0xffff0000u)) x <<= 16; else r += 16; if (!(x & 0xff000000u)) x <<= 8; else r += 8; if (!(x & 0xf0000000u)) x <<= 4; else r += 4; if (!(x & 0xc0000000u)) x <<= 2; else r += 2; if (!(x & 0x80000000u)) x <<= 1; else r += 1; return r; } int __fls(int x) { int ret; __asm__(" ldi 1,%1\n" " extru,<> %0,15,16,%%r0\n" " zdep,TR %0,15,16,%0\n" " addi 16,%1,%1\n" " extru,<> %0,7,8,%%r19\n" " zdep,TR %0,23,24,%0\n" " addi 8,%1,%1\n" " extru,<> %0,3,4,%%r19\n" " zdep,TR %0,27,28,%0\n" " addi 4,%1,%1\n" " extru,<> %0,1,2,%%r19\n" " zdep,TR %0,29,30,%0\n" " addi 2,%1,%1\n" " extru,= %0,0,1,%%r19\n" " addi 1,%1,%1\n" : "=r" (x), "=r" (ret) : "0" (x), "1" (ret)); return ret; } int Fastfls(int x) { int ret; if (!x) return 0; return (__fls(x)); } main() { unsigned int i; for (i=0; i<0xffffffffU; i++) { /* if (generic_fls(i) != PseudoFast_fls(i)) */ if (generic_fls(i) != Fastfls(i)) printf ("Problem with i = %#010x (%d)\n", i, i); } } Cheers, Joel PS: Don not hesitate to let me know if you would like that I make a patch with this stuff ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From jesse@cypress-tech.com Thu Aug 7 19:42:02 2003 From: jesse@cypress-tech.com (Jesse Dougherty) Date: Thu, 07 Aug 2003 11:42:02 -0700 Subject: [parisc-linux] adding a second nic to B1000 References: <20030807083620.21079.h004.c009.wm@mail.canada.com.criticalpath.net> Message-ID: <3F329D7A.F993B697@cypress-tech.com> It might be the 3com card, the recommended NIC cards for the B1000 are HP B5509BA PCI 10/100Base-TX and HP A4926A PCI 1000Base-SX Jesse geos@canada.com wrote: > Ive been trying for 5 days not to get a second nic > installed into hp b1000 using pa-risc woody 3 > > iv read all i can find , been to all the irc chnls > im at a loss here > > it may be the 3com 3C95x pci card does not work in this > box > > it should work with debian > the card does work in i386 box > the builtin nic works fine > > can this be done? if so is there a howto ? > if this card is not supported what nic cards are ? > > TIA > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux From Randolph Chung Thu Aug 7 16:54:42 2003 From: Randolph Chung (Randolph Chung) Date: Thu, 7 Aug 2003 08:54:42 -0700 Subject: [parisc-linux] adding a second nic to B1000 In-Reply-To: <20030807083620.21079.h004.c009.wm@mail.canada.com.criticalpath.net> References: <20030807083620.21079.h004.c009.wm@mail.canada.com.criticalpath.net> Message-ID: <20030807155442.GE4979@tausq.org> > it may be the 3com 3C95x pci card does not work in this > box > it should work with debian > the card does work in i386 box > the builtin nic works fine how does it "not work"? does it hang the box? i have a spare 3c95x that i can try as well... (altho there are really many variants of the vortex/boomerang cards) can you perhaps plug the card into a working i386 box and show us the lspci -vvvn output? randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From jsoe0708@tiscali.be Thu Aug 7 17:04:05 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 7 Aug 2003 18:04:05 +0200 Subject: [parisc-linux] adding a second nic to B1000 In-Reply-To: <20030807083620.21079.h004.c009.wm@mail.canada.com.criticalpath.net> Message-ID: <3F2E2C7700000FF2@ocpmta2.freegates.net> > Ive been trying for 5 days not to get a second nic >installed into hp b1000 using pa-risc woody 3 > >iv read all i can find , been to all the irc chnls >im at a loss here > >it may be the 3com 3C95x pci card does not work in this >box > >it should work with debian >the card does work in i386 box >the builtin nic works fine > >can this be done? if so is there a howto ? >if this card is not supported what nic cards are ? For my part, I run successfully a Debian on a b2k with 2 nic (the builtin and an additional) since a long time but it is an hp product. I also try some stuff coming from i386: an OEM hp equinox pci card (which Grant use successfully on a i386) but the driver doesn't yet work on hppa; also in the same case an ATI gfx card,... (for this last I am awaiting that 2.6 run on my b2k to investigate more because ATI drivers are already improved in 2.6 :-)) Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From Randolph Chung Thu Aug 7 17:59:19 2003 From: Randolph Chung (Randolph Chung) Date: Thu, 7 Aug 2003 09:59:19 -0700 Subject: [parisc-linux] adding a second nic to B1000 In-Reply-To: <20030807091916.8745.h006.c009.wm@mail.canada.com.criticalpath.net> References: <20030807091916.8745.h006.c009.wm@mail.canada.com.criticalpath.net> Message-ID: <20030807165919.GF4979@tausq.org> Please reply to the list, not to me privately. In reference to a message from geos@canada.com, dated Aug 07: > I will try that later tonite > i cannot get the 3c95x.c to compile or when i do it > tells me its compiled for the wrong kerel this looks like a generic module compiling problem, not hppa specific... have you done this before succesfully? Are you building a module from the same tree where you built the kernel you are running? I just tried this against 2.4 cvs and it works fine. > modconf does not show this nic in the list is the module installed in /lib/modules/`uname -r` ? > make config did not change anything what did you expect it to do? randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From bame@hp.com Thu Aug 7 18:11:48 2003 From: bame@hp.com (bame@hp.com) Date: Thu, 07 Aug 2003 11:11:48 -0600 Subject: [parisc-linux] 2.5 -> 2.6 tree switch tomorrow In-Reply-To: Message from bame@ldl.fc.hp.com (Paul Bame) of "Wed, 06 Aug 2003 12:48:26 MDT." <20030806184826.GA11934@ldl.fc.hp.com> References: <20030806184826.GA11934@ldl.fc.hp.com> Message-ID: <20030807171149.B2A7A7306A@fc.hp.com> The linux-2.6 tree is now ready for business and the linux-2.5 tree is frozen. Tarball (which could be used to seed a CVS tree) and patch at the usual place: http://cvs.parisc-linux.org/download/linux-2.6/ FYI We are using a different CVS branch architecture which should be completely transparent most of the time. I'll get a description of it out soon. Autobuilt kernels to follow at some point. FYI the 2.4 autobuilder is currently off line. -P From geos@canada.com Thu Aug 7 19:01:40 2003 From: geos@canada.com (geos@canada.com) Date: Thu, 07 Aug 2003 11:01:40 -0700 (PDT) Subject: [parisc-linux] adding a second nic to B1000 Message-ID: <20030807110141.25427.h020.c009.wm@mail.canada.com.criticalpath.net> Sorry about that im kinda new to this if you cant tell ;) make config allowed me to select what nic drivers i wanted but this did not compile or load the new driver i will have to get the exact errors msg's when i get back home i ran the recompile kernal found here http://www.parisc-linux.org/kernel/index.html using Simple Recipe to Build a Kernel this added the source to /usr/src/linux that source should be the same as my kernal after doing that i did this http://www.scyld.com/expert/modules.html needed to get lib6,cvs after a net-install to do this the common error after compileing and doing a insmod 3c95x.o was "this was compiled for 2.4.18 and this version is for 2.4.19" so i copy the 3c95x.c from the 2.4.19 kernel and did it again now i get an error like this will not function ill get better errors msgs tonight am i doing this all wrong ? > > Please reply to the list, not to me privately. > > In reference to a message from geos@canada.com, dated > Aug 07: > > I will try that later tonite > > i cannot get the 3c95x.c to compile or when i do it > > tells me its compiled for the wrong kerel > > this looks like a generic module compiling problem, not > hppa specific... > have you done this before succesfully? Are you building > a module from > the same tree where you built the kernel you are > running? I just tried > this against 2.4 cvs and it works fine. > > > modconf does not show this nic in the list > > is the module installed in /lib/modules/`uname -r` ? > > > make config did not change anything > > what did you expect it to do? > > randolph > -- > Randolph Chung > Debian GNU/Linux Developer, hppa/ia64 ports > http://www.tausq.org/ From christoph.plattner@gmx.at Thu Aug 7 22:58:36 2003 From: christoph.plattner@gmx.at (Christoph Plattner) Date: Thu, 07 Aug 2003 23:58:36 +0200 Subject: [parisc-linux] Re: Apollo 9000 power problem Message-ID: <3F32CB8C.9060407@gmx.at> Hello HP Hackers ! I have a work around for the POWER SUPPLY Problem. Using schematics and analysing this very very hard thing, I found out, that the problem we all have was created by an exploded capacitor. The thing running out of the capacitor mixed with the dust in the machine generates an resistor on the PCB board. On the low voltage end of the power supply (near front), ther is a small SIM-like module which does the supervision of all volatage lines (plus over current protection) and which generates the reset impuls. Now to the problem. The line coming from the current measure transformer is the neighbour line of the -12V line. Because of the electrical resistor because of the dust, etc, the negative voltage comes to the current supervision line, and therefore one supervision comperator does a wrong failure reaction ! Workaround: - step 1 - Try to clean the space on the PCB around this supervison module. (I soldered it out for cleaning, a resoldered it in).. - step 2 - This helps. But after weeks the problem returned again .... I soldered in a resistor between the +Vaux (about 12..16V) and this current measure line to compensate this negativ voltage of the -12V line. This is no relevant impact to the over-current protection, as the resistor has a high value against the measurement output. This worked for me. If you need help on this, please contact me ... Christoph -- ------------------------------------------------------- private: christoph.plattner@gmx.at company: christoph.plattner@alcatel.at From christoph.plattner@gmx.at Thu Aug 7 23:02:33 2003 From: christoph.plattner@gmx.at (Christoph Plattner) Date: Fri, 08 Aug 2003 00:02:33 +0200 Subject: [parisc-linux] Status E55 - or family Message-ID: <3F32CC79.8090507@gmx.at> Hello PA RISC hackers ... Are there any news concerning the E55 (or family) stuff. Now I have not hacked on PA RISC linux for a longer time. Are there news on the MUX supporting more then 1 port ? Are there news on the SCSI driver ? The last status was, that all access to this device was done in "empty" io space ... Are there news concerning my NDA ??!! Please reply Christoph -- ------------------------------------------------------- private: christoph.plattner@gmx.at company: christoph.plattner@alcatel.at From linyu921@sina.com Fri Aug 8 07:26:49 2003 From: linyu921@sina.com (dq) Date: Fri, 8 Aug 2003 14:26:49 +0800 Subject: [parisc-linux] =?GB2312?B?zqrE+r2oo6jW0NOizsSjqcbz0rXN+NW+?= Message-ID: <20030808062451.389634937@dsl2.external.hp.com> ΪÄú½¨£¨ÖÐÓ¢ÎÄ£©ÆóÒµÍøÕ¾ ------------------------ ¡ø¸ù¾ÝÄúµÄÒªÇó¸öÐÔ»¯Éè¼Æ£¬¾ø²»Ì×ÓÃÄ£°æ¡£ ¡ø ÍøÕ¾ÎÞÏÞÀ©Õ¹¼Ü¹¹£¬ÊÊÓ¦ÄúÆóÒµÎÞÏÞ·¢Õ¹µÄÒªÇó¡£ ¡ø ¾ßÓкǫ́¹ÜÀí¹¦ÄÜ£¬ÍøÕ¾½¨³Éºó£¬½»ÓÉÄú×Ô¼º¸üйÜÀí¡£ ----------------------------- ¡ô±¾¹«Ë¾ÎªÄúËù½¨µÄÍøÕ¾¾ßÓÐÒÔϹ¦ÄÜ£º 1.²úƷչʾ-ÍøÉÏչʾÄúµÄ²úÆ·£¬Í¼ÎIJ¢Ã¯£¬¶à¼¶·ÖÀ࣬ºǫ́¹ÜÀí¡£ 2.ÍøÉÏÉ̵ê-¿Í»§¿ÉÖ±½ÓÔÚÍøÉÏÑ¡¹ºÄúµÄ²úÆ·£¬¾ÍÏñÔÚÉ̵êÀïÒ»Ñù¡£ 3.²úÆ·ËÑË÷-¿Í»§¿Éͨ¹ý²úÆ·Ãû³Æ¡¢Àà±ð¡¢¹Ø¼ü´ÊµÈ²éÕÒÄúµÄ²úÆ·¡£ 4.¿Í»§¹ÜÀí-¶Ô²»Í¬¿Í»§»ò»áÔ±£¬¿É½øÐзּ¶¡¢·ÖȨÏÞ¡¢·ÖÀà¹ÜÀí¡£ 5.²úÆ·¶¨¹º-¿Í»§¿ÉÖ±½ÓÔÚÍøÉÏ϶©µ¥£¬¶¨¹ºÄúµÄ²úÆ·¡£ 6.¿Í»§ÁôÑÔ-¿Í»§¿ÉÖ±½ÓÔÚÍøÉϸøÄúÁôÑÔ£¬ÏòÄú·´À¡Òâ¼û¡£ 7.ÐÂÎÅ·¢²¼-Äú¿ÉÔÚÍøÉÏÖ±½Ó·¢²¼¹«Ë¾µÄÐÂÎÅ¡¢Í¨Öª¡¢´ÙÏúÐÅÏ¢µÈ¡£ 8.»áÔ±ÉçÇø-¿É×÷ΪÍⲿ½»Á÷ÂÛ̳£¬Ò²¿É×÷Ϊ¹«Ë¾ÄÚ²¿Ô±¹¤¹µÍ¨Æ½Ì¨¡£ 9.ÍøÉϵ÷²é-¿ÉÒÔÉ趨ÈκÎÎÊÌ⣬Ïò¿Í»§»ò»áÔ±Á˽âÄúÏëÁ˽âµÄÊÂÇé¡£ 10.ÓʼþÁбí-¿ÉÒÔÊÕ¼¯¿Í»§µç×ÓÓÊÏäµÈ×ÊÁÏ£¬¶¨ÆÚÏò¿Í»§·¢ËÍÐÅÏ¢¡£ 11.ÍøÉϺؿ¨-ÖØÒª½ÚÈÕ£¬Ïò¿Í»§·¢Ë;«ÃÀºØ¿¨£¬ÔöÇ¿Óë¿Í»§µÄ¸ÐÇé¡£ 12.ÆóÒµÓʾÖ-ÓëÄúÍøվͬÓòÃûµÄÆóÒµÓʾ֣¬Ìá¸ßÄúÆóÒµµÄ¶ÔÍâÐÎÏó¡£ 13.ºǫ́¹ÜÀí-ËùÓÐÒÔÉϹ¦ÄÜ£¬¿ÉÓÉÄú×Ô¼º¿ØÖƹÜÀí£¬²»ÐèרҵÈËÔ±¡£ ¡ôÄúÒ²¿ÉÒÔ´ÓÏÂÃæ5ÖÖÀàÐÍÖУ¬ÌôÑ¡Ò»ÖÖÊʺÏÄú¹«Ë¾µÄÍøÕ¾? ----------------------------- ¡ø(Ò») ¾­¼ÃÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®100Õ×Ö÷»ú¿Õ¼ä£» 3£®ÍøÕ¾ÕûÌåÉè¼Æ£» 4£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 5£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 6£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 7£®5¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®5¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 9£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 10£®Gif°´Å¥¡¢ÐüÍ£°´Å¥£» 11£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 12£®BannerÉè¼ÆÖÆ×÷£¨Gif£© 13£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 14£®»¶Ó­Ò³·ÃÎÊÕß¼ÆÊýÆ÷1Ì×£» 15£®Óõç×ÓÓÊÏä½ÓÊÕ¿Í»§ÁôÑÔ; 16£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 17£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾2Ò³´Î¡£ -------------------------- ¡ø(¶þ) ±ê×¼ÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®120Õ×Ö÷»ú¿Õ¼ä£» 3£®1¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 8£®10¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 9£®10¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 10£®Gif°´Å¥¡¢ÐüÍ£°´Å¥£» 11£®Flash¶¯»­1·ù£» 12£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 13£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 14£®Êó±êÌØЧ1´¦ 15£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 16£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 17£®»¶Ó­Ò³·ÃÎÊÕß¼ÆÊýÆ÷1Ì×£» 18£®Óõç×ÓÓÊÏä½ÓÊÕ¿Í»§ÁôÑÔ£» 19£®ÌØЧͼƬÖÐÓ¢ÎĹ²2·ù£» 20£®¹ö¶¯×ÖÄ»¹«¸æÖÐÓ¢ÎĹ²2·ù£» 21£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 22£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾4Ò³´Î£» --------------------------- ¡ø(Èý) ÉÌÎñÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®150Õ×Ö÷»ú¿Õ¼ä£» 3£®5¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®20¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®20¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­2·ù£» 13£®ÊÓƵ¶¯»­1·ù£» 14£®Êó±êÌØЧ1´¦ 15£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 16£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 17£®¶¯Ì¬¹ã¸æºá·ù1·ù£» 18£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 19£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 20£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§¶©µ¥£» 21£®ÌØЧͼƬÖÐÓ¢ÎĹ²4·ù£» 22£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²2·ù£» 23£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²4·ù£» 24£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 25£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾8Ò³´Î£» 26£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ1ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ1Ìס£ --------------------------- ¡ø(ËÄ) ºÀ»ªÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®200Õ×Ö÷»ú¿Õ¼ä£» 3£®10¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®40¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®40¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­4·ù£» 13£®ÊÓƵ¶¯»­2·ù£» 14£®Êó±êÌØЧ1´¦£» 15£®ÍøÒ³ÒôÀÖ1´¦£» 16£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 17£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 18£®¶¯Ì¬¹ã¸æºá·ù2·ù£» 19£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 20£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 21£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 22£®ÌØЧͼƬÖÐÓ¢ÎĹ²6·ù 23£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²4·ù 24£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ£» 25£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²6·ù£» 26£®Êý¾Ý¿â½ÓÊÕ¿Í»§¶©µ¥£» 27£®Êý¾Ý¿â¹ÜÀí²úÆ·£» 28£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾16Ò³´Î£» 29£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ2ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ2Ìס£ 30£®ÔùËÍÍâóÖƵ¥Èí¼þ--¡¶ÍâóÖƵ¥Í¨¡·1Ìס£ --------------------------- ¡ø(Îå) ¼¯ÍÅÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®300Õ×Ö÷»ú¿Õ¼ä£» 3£®20¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®80¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®80¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­8·ù£» 13£®ÊÓƵ¶¯»­3·ù£» 14£®Êó±êÌØЧ2´¦£» 15£®ÍøÒ³ÒôÀÖ2´¦£» 16£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 17£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 18£®¶¯Ì¬¹ã¸æºá·ù3·ù£» 19£®ÖÐÎÄ¿ò¼ÜÖ÷Ò³¡¢Ó¢ÎÄ¿ò¼ÜÖ÷Ò³£» 20£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 21£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 22£®¿Í»§·´À¡ÁôÑÔ°å2¸ö(ÖÐÓ¢ÎÄ)£» 23£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ£» 24£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²8·ù 25£®ÌØЧͼƬÖÐÓ¢ÎĹ²8·ù£» 26£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²6·ù£» 27£®Êý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ¡¢¿Í»§¶©µ¥£» 28£®Êý¾Ý¿â¹ÜÀí»áÔ±£» 29£®ÓʼþÁÐ±í£¬ÊÕ¼¯·Ã¿ÍÓʼþµØÖ·£¬·¢Ë͹ã¸æ£» 30£®Êý¾Ý¿â¹ÜÀí²úÆ·£» 31£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 32£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾32Ò³´Î£» 33£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ3ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ3Ì×£» 34£®ÔùËÍÍâóÖƵ¥¼°¹ÜÀíÈí¼þ--¡¶ÍâóҵÎñͨ¡·1Ìס£ --------------------------- ¡¡±¾¹«Ë¾ÊÇÒ»¼Ò´ÓÊÂÍâó³ö¿ÚÐÐÒµ"¼ÆËã»úÓ¦ÓÃÈí¼þÑо¿¿ª·¢"¡¢"ÍøÂ繤³Ì½¨Éè"ºÍ"¶àýÌåÓ°ÊÓ¶¯»­¹ã¸æÖÆ ×÷"µÄרҵ¹«Ë¾£¬×¨ÃÅΪÎÒ¹ú¹ã´óÍâó¹«Ë¾¡¢³ö¿ÚÆóÒµ¿ª·¢¸÷ÖÖ¼ÆËã »úÓ¦ÓÃÈí¼þϵͳ¡¢ÍøÕ¾½¨ÉèÒÔ¼°ÆóÒµ¶àýÌåÓ°ÊÓ¶¯»­¹ã¸æƬÖÆ×÷¡£ ¡¡¡¡±¾¹«Ë¾ÔÚ¹ú¼Òó´Ù»áµÄÖ§³ÖºÍ×é֯ϣ¬³É¹¦¿ª·¢³ö¡¶Ô­²úµØÖ¤Íø ÉÏÉêÇëϵͳ¡·¡¢¡¶ÍâóÖƵ¥Í¨¡·¡¢¡¶ÍâóҵÎñͨ¡·µÈϵÁÐÍâóӦÓÃÈí ¼þ²úÆ·£¬Êܵ½¹ã´óÍâó³ö¿ÚÆóÒµµÄ»¶Ó­¡£ ¡¡¡¡Í¬Ê±£¬ÓÉÓÚÒµÎñ¹Øϵ£¬±¾¹«Ë¾»¹ÓëÃÀ¹ú¡¢Å·¹²Ìå¡¢ÈÕ±¾¡¢º«¹ú¡¢ ¶«ÄÏÑǵȵØÊýÊ®¼Ò²É¹ºÉÌ¡¢Á¬Ëø³¬ÊС¢ÒÔ¼°Éú²úÉÌÓÐ×ÅÁ¼ºÃµÄºÏ×÷¹Ø ϵ¡£¹ýÈ¥Ò»Äê¶à£¬±¾¹«Ë¾ÒÑ°ïÖú¶à¼ÒÍâ¹ú²É¹º³§ÉÌÔÚ¹úÄÚÕÒµ½ºÏÊ浀 ³ö¿Ú²úÆ·£¬´Ù³É¶à×Ú³ö¿ÚóÒס£ ----------------------------- ¹«Ë¾£º¹ãÖÝÊгà¾ÔÓÐÏÞ¹«Ë¾ µØÖ·£º¹ãÖÝÊмÓÄôó»¨Ô°6ºÅÂ¥9E µç»°£º020-85580234ת19 »ò20ÁÖÏÈÉú ´«Õ棺020-85581405 ÊÖ»ú£º13640327836 ÓÊÏ䣺linyu921@sina.com ----------------------------- From linyu921@sina.com Fri Aug 8 07:26:51 2003 From: linyu921@sina.com (dq) Date: Fri, 8 Aug 2003 14:26:51 +0800 Subject: [parisc-linux] =?GB2312?B?zqrE+r2oo6jW0NOizsSjqcbz0rXN+NW+?= Message-ID: <20030808062452.C42414964@dsl2.external.hp.com> ΪÄú½¨£¨ÖÐÓ¢ÎÄ£©ÆóÒµÍøÕ¾ ------------------------ ¡ø¸ù¾ÝÄúµÄÒªÇó¸öÐÔ»¯Éè¼Æ£¬¾ø²»Ì×ÓÃÄ£°æ¡£ ¡ø ÍøÕ¾ÎÞÏÞÀ©Õ¹¼Ü¹¹£¬ÊÊÓ¦ÄúÆóÒµÎÞÏÞ·¢Õ¹µÄÒªÇó¡£ ¡ø ¾ßÓкǫ́¹ÜÀí¹¦ÄÜ£¬ÍøÕ¾½¨³Éºó£¬½»ÓÉÄú×Ô¼º¸üйÜÀí¡£ ----------------------------- ¡ô±¾¹«Ë¾ÎªÄúËù½¨µÄÍøÕ¾¾ßÓÐÒÔϹ¦ÄÜ£º 1.²úƷչʾ-ÍøÉÏչʾÄúµÄ²úÆ·£¬Í¼ÎIJ¢Ã¯£¬¶à¼¶·ÖÀ࣬ºǫ́¹ÜÀí¡£ 2.ÍøÉÏÉ̵ê-¿Í»§¿ÉÖ±½ÓÔÚÍøÉÏÑ¡¹ºÄúµÄ²úÆ·£¬¾ÍÏñÔÚÉ̵êÀïÒ»Ñù¡£ 3.²úÆ·ËÑË÷-¿Í»§¿Éͨ¹ý²úÆ·Ãû³Æ¡¢Àà±ð¡¢¹Ø¼ü´ÊµÈ²éÕÒÄúµÄ²úÆ·¡£ 4.¿Í»§¹ÜÀí-¶Ô²»Í¬¿Í»§»ò»áÔ±£¬¿É½øÐзּ¶¡¢·ÖȨÏÞ¡¢·ÖÀà¹ÜÀí¡£ 5.²úÆ·¶¨¹º-¿Í»§¿ÉÖ±½ÓÔÚÍøÉÏ϶©µ¥£¬¶¨¹ºÄúµÄ²úÆ·¡£ 6.¿Í»§ÁôÑÔ-¿Í»§¿ÉÖ±½ÓÔÚÍøÉϸøÄúÁôÑÔ£¬ÏòÄú·´À¡Òâ¼û¡£ 7.ÐÂÎÅ·¢²¼-Äú¿ÉÔÚÍøÉÏÖ±½Ó·¢²¼¹«Ë¾µÄÐÂÎÅ¡¢Í¨Öª¡¢´ÙÏúÐÅÏ¢µÈ¡£ 8.»áÔ±ÉçÇø-¿É×÷ΪÍⲿ½»Á÷ÂÛ̳£¬Ò²¿É×÷Ϊ¹«Ë¾ÄÚ²¿Ô±¹¤¹µÍ¨Æ½Ì¨¡£ 9.ÍøÉϵ÷²é-¿ÉÒÔÉ趨ÈκÎÎÊÌ⣬Ïò¿Í»§»ò»áÔ±Á˽âÄúÏëÁ˽âµÄÊÂÇé¡£ 10.ÓʼþÁбí-¿ÉÒÔÊÕ¼¯¿Í»§µç×ÓÓÊÏäµÈ×ÊÁÏ£¬¶¨ÆÚÏò¿Í»§·¢ËÍÐÅÏ¢¡£ 11.ÍøÉϺؿ¨-ÖØÒª½ÚÈÕ£¬Ïò¿Í»§·¢Ë;«ÃÀºØ¿¨£¬ÔöÇ¿Óë¿Í»§µÄ¸ÐÇé¡£ 12.ÆóÒµÓʾÖ-ÓëÄúÍøվͬÓòÃûµÄÆóÒµÓʾ֣¬Ìá¸ßÄúÆóÒµµÄ¶ÔÍâÐÎÏó¡£ 13.ºǫ́¹ÜÀí-ËùÓÐÒÔÉϹ¦ÄÜ£¬¿ÉÓÉÄú×Ô¼º¿ØÖƹÜÀí£¬²»ÐèרҵÈËÔ±¡£ ¡ôÄúÒ²¿ÉÒÔ´ÓÏÂÃæ5ÖÖÀàÐÍÖУ¬ÌôÑ¡Ò»ÖÖÊʺÏÄú¹«Ë¾µÄÍøÕ¾? ----------------------------- ¡ø(Ò») ¾­¼ÃÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®100Õ×Ö÷»ú¿Õ¼ä£» 3£®ÍøÕ¾ÕûÌåÉè¼Æ£» 4£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 5£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 6£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 7£®5¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®5¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 9£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 10£®Gif°´Å¥¡¢ÐüÍ£°´Å¥£» 11£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 12£®BannerÉè¼ÆÖÆ×÷£¨Gif£© 13£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 14£®»¶Ó­Ò³·ÃÎÊÕß¼ÆÊýÆ÷1Ì×£» 15£®Óõç×ÓÓÊÏä½ÓÊÕ¿Í»§ÁôÑÔ; 16£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 17£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾2Ò³´Î¡£ -------------------------- ¡ø(¶þ) ±ê×¼ÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®120Õ×Ö÷»ú¿Õ¼ä£» 3£®1¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 8£®10¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 9£®10¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 10£®Gif°´Å¥¡¢ÐüÍ£°´Å¥£» 11£®Flash¶¯»­1·ù£» 12£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 13£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 14£®Êó±êÌØЧ1´¦ 15£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 16£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 17£®»¶Ó­Ò³·ÃÎÊÕß¼ÆÊýÆ÷1Ì×£» 18£®Óõç×ÓÓÊÏä½ÓÊÕ¿Í»§ÁôÑÔ£» 19£®ÌØЧͼƬÖÐÓ¢ÎĹ²2·ù£» 20£®¹ö¶¯×ÖÄ»¹«¸æÖÐÓ¢ÎĹ²2·ù£» 21£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 22£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾4Ò³´Î£» --------------------------- ¡ø(Èý) ÉÌÎñÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®150Õ×Ö÷»ú¿Õ¼ä£» 3£®5¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®20¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®20¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­2·ù£» 13£®ÊÓƵ¶¯»­1·ù£» 14£®Êó±êÌØЧ1´¦ 15£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 16£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 17£®¶¯Ì¬¹ã¸æºá·ù1·ù£» 18£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 19£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 20£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§¶©µ¥£» 21£®ÌØЧͼƬÖÐÓ¢ÎĹ²4·ù£» 22£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²2·ù£» 23£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²4·ù£» 24£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 25£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾8Ò³´Î£» 26£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ1ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ1Ìס£ --------------------------- ¡ø(ËÄ) ºÀ»ªÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®200Õ×Ö÷»ú¿Õ¼ä£» 3£®10¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®40¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®40¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­4·ù£» 13£®ÊÓƵ¶¯»­2·ù£» 14£®Êó±êÌØЧ1´¦£» 15£®ÍøÒ³ÒôÀÖ1´¦£» 16£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 17£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 18£®¶¯Ì¬¹ã¸æºá·ù2·ù£» 19£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 20£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 21£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 22£®ÌØЧͼƬÖÐÓ¢ÎĹ²6·ù 23£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²4·ù 24£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ£» 25£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²6·ù£» 26£®Êý¾Ý¿â½ÓÊÕ¿Í»§¶©µ¥£» 27£®Êý¾Ý¿â¹ÜÀí²úÆ·£» 28£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾16Ò³´Î£» 29£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ2ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ2Ìס£ 30£®ÔùËÍÍâóÖƵ¥Èí¼þ--¡¶ÍâóÖƵ¥Í¨¡·1Ìס£ --------------------------- ¡ø(Îå) ¼¯ÍÅÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®300Õ×Ö÷»ú¿Õ¼ä£» 3£®20¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®80¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®80¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­8·ù£» 13£®ÊÓƵ¶¯»­3·ù£» 14£®Êó±êÌØЧ2´¦£» 15£®ÍøÒ³ÒôÀÖ2´¦£» 16£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 17£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 18£®¶¯Ì¬¹ã¸æºá·ù3·ù£» 19£®ÖÐÎÄ¿ò¼ÜÖ÷Ò³¡¢Ó¢ÎÄ¿ò¼ÜÖ÷Ò³£» 20£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 21£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 22£®¿Í»§·´À¡ÁôÑÔ°å2¸ö(ÖÐÓ¢ÎÄ)£» 23£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ£» 24£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²8·ù 25£®ÌØЧͼƬÖÐÓ¢ÎĹ²8·ù£» 26£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²6·ù£» 27£®Êý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ¡¢¿Í»§¶©µ¥£» 28£®Êý¾Ý¿â¹ÜÀí»áÔ±£» 29£®ÓʼþÁÐ±í£¬ÊÕ¼¯·Ã¿ÍÓʼþµØÖ·£¬·¢Ë͹ã¸æ£» 30£®Êý¾Ý¿â¹ÜÀí²úÆ·£» 31£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 32£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾32Ò³´Î£» 33£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ3ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ3Ì×£» 34£®ÔùËÍÍâóÖƵ¥¼°¹ÜÀíÈí¼þ--¡¶ÍâóҵÎñͨ¡·1Ìס£ --------------------------- ¡¡±¾¹«Ë¾ÊÇÒ»¼Ò´ÓÊÂÍâó³ö¿ÚÐÐÒµ"¼ÆËã»úÓ¦ÓÃÈí¼þÑо¿¿ª·¢"¡¢"ÍøÂ繤³Ì½¨Éè"ºÍ"¶àýÌåÓ°ÊÓ¶¯»­¹ã¸æÖÆ ×÷"µÄרҵ¹«Ë¾£¬×¨ÃÅΪÎÒ¹ú¹ã´óÍâó¹«Ë¾¡¢³ö¿ÚÆóÒµ¿ª·¢¸÷ÖÖ¼ÆËã »úÓ¦ÓÃÈí¼þϵͳ¡¢ÍøÕ¾½¨ÉèÒÔ¼°ÆóÒµ¶àýÌåÓ°ÊÓ¶¯»­¹ã¸æƬÖÆ×÷¡£ ¡¡¡¡±¾¹«Ë¾ÔÚ¹ú¼Òó´Ù»áµÄÖ§³ÖºÍ×é֯ϣ¬³É¹¦¿ª·¢³ö¡¶Ô­²úµØÖ¤Íø ÉÏÉêÇëϵͳ¡·¡¢¡¶ÍâóÖƵ¥Í¨¡·¡¢¡¶ÍâóҵÎñͨ¡·µÈϵÁÐÍâóӦÓÃÈí ¼þ²úÆ·£¬Êܵ½¹ã´óÍâó³ö¿ÚÆóÒµµÄ»¶Ó­¡£ ¡¡¡¡Í¬Ê±£¬ÓÉÓÚÒµÎñ¹Øϵ£¬±¾¹«Ë¾»¹ÓëÃÀ¹ú¡¢Å·¹²Ìå¡¢ÈÕ±¾¡¢º«¹ú¡¢ ¶«ÄÏÑǵȵØÊýÊ®¼Ò²É¹ºÉÌ¡¢Á¬Ëø³¬ÊС¢ÒÔ¼°Éú²úÉÌÓÐ×ÅÁ¼ºÃµÄºÏ×÷¹Ø ϵ¡£¹ýÈ¥Ò»Äê¶à£¬±¾¹«Ë¾ÒÑ°ïÖú¶à¼ÒÍâ¹ú²É¹º³§ÉÌÔÚ¹úÄÚÕÒµ½ºÏÊ浀 ³ö¿Ú²úÆ·£¬´Ù³É¶à×Ú³ö¿ÚóÒס£ ----------------------------- ¹«Ë¾£º¹ãÖÝÊгà¾ÔÓÐÏÞ¹«Ë¾ µØÖ·£º¹ãÖÝÊмÓÄôó»¨Ô°6ºÅÂ¥9E µç»°£º020-85580234ת19 »ò20ÁÖÏÈÉú ´«Õ棺020-85581405 ÊÖ»ú£º13640327836 ÓÊÏ䣺linyu921@sina.com ----------------------------- From joel.soete@tiscali.be Fri Aug 8 08:46:24 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Fri, 08 Aug 2003 07:46:24 +0000 Subject: [parisc-linux] adding a second nic to B1000 In-Reply-To: <20030807110141.25427.h020.c009.wm@mail.canada.com.criticalpath.net> References: <20030807110141.25427.h020.c009.wm@mail.canada.com.criticalpath.net> Message-ID: <3F335550.3030804@tiscali.be> geos@canada.com wrote: >Sorry about that >im kinda new to this if you cant tell ;) >make config allowed me to select what nic drivers i >wanted but this did not compile or load the new driver > >i will have to get the exact errors msg's when i get >back home > >i ran the recompile kernal found here >http://www.parisc-linux.org/kernel/index.html >using Simple Recipe to Build a Kernel > >this added the source to /usr/src/linux >that source should be the same as my kernal >after doing that i did this >http://www.scyld.com/expert/modules.html >needed to get lib6,cvs after a net-install to do this > >the common error after compileing and doing a insmod >3c95x.o >was "this was compiled for 2.4.18 and this version is >for 2.4.19" >so i copy the 3c95x.c from the 2.4.19 kernel and did it >again now i get an error like this will not function > Well if I well understand you reached to recompile hppa linux kernel with module for 3c95x: congratulation. But to load modules, they have to be build for the kernel you are running (I think that will change in 2.6). So the only think to do now is to _reboot_ with the kernel you just rebuild for your nic :) hth, Joel From jbglaw@lug-owl.de Fri Aug 8 16:02:56 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Fri, 8 Aug 2003 17:02:56 +0200 Subject: [parisc-linux] adding a second nic to B1000 In-Reply-To: <3F335550.3030804@tiscali.be> References: <20030807110141.25427.h020.c009.wm@mail.canada.com.criticalpath.net> <3F335550.3030804@tiscali.be> Message-ID: <20030808150256.GX1873@lug-owl.de> --LjVoae4kcYbOEAMC Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 2003-08-08 07:46:24 +0000, Joel Soete wrote in message <3F335550.3030804@tiscali.be>: > geos@canada.com wrote: > But to load modules, they have to be build for the kernel you are=20 > running (I think that will change in 2.6). So the only think to do now= =20 I'm quite sure that won't change, ever. Linux, if it's compatible to itself at all, has got "only" a source compatible API. You're somewhat on a more save side if you're using symbol versioning, but if you force a module to load (into a kernel of different version or even of different configuration), you may loose. Right now or sometime later:) That's what "tainting" was ment for:) MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); --LjVoae4kcYbOEAMC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/M7ugHb1edYOZ4bsRAqn4AJ41MqzSysgVj6LA+j9U1DxY0NVqUgCeLQxa DkcfArCl0N6eXwiNzszux1M= =uOAX -----END PGP SIGNATURE----- --LjVoae4kcYbOEAMC-- From grundler@parisc-linux.org Fri Aug 8 16:29:06 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 8 Aug 2003 09:29:06 -0600 Subject: [parisc-linux] Status E55 - or family In-Reply-To: <3F32CC79.8090507@gmx.at> References: <3F32CC79.8090507@gmx.at> Message-ID: <20030808152906.GA28214@dsl2.external.hp.com> On Fri, Aug 08, 2003 at 12:02:33AM +0200, Christoph Plattner wrote: > Are there any news concerning the E55 (or family) stuff. yes - I've collected documentation needed for HP-PB SCSI (both SE SCSI and FWD SCSI) but haven't had time to run that through "the process". ... > Are there news concerning my NDA ??!! My request to release them under NDA only was denied by mgt. :^( grant From grundler@parisc-linux.org Fri Aug 8 16:55:50 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 8 Aug 2003 09:55:50 -0600 Subject: [parisc-linux] kernel BUG at include/linux/skbuff.h:834! In-Reply-To: <20030806145700.GU22222@parcelfarce.linux.theplanet.co.uk> References: <20030806143219.GC30797@dsl2.external.hp.com> <20030806145700.GU22222@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030808155550.GE28214@dsl2.external.hp.com> On Wed, Aug 06, 2003 at 03:57:00PM +0100, Matthew Wilcox wrote: > "I don't believe you" ;-) Well, I just copied what the kernel posted to the console. Maybe the stack trace was from the wrong stack? (kernel vs user space) > The first BUG is in skb_put() and the second BUG is in skb_pull(). Neither > are called from netif_receive_skb(), nor net_rx_action(). yup - I see that now too. The stack info is crap unless the calls to skb_* are hidden in macros or other inline function calls. ... > So none of these addresses make any sense ;-( ok. :^( Hopefully this is reproducible. grant From grundler@parisc-linux.org Fri Aug 8 17:37:44 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 8 Aug 2003 10:37:44 -0600 Subject: [parisc-linux] Re: Debian on rp 7400 In-Reply-To: <3F336914.5020305@tiscali.be> References: <25EEF58E-C82D-11D7-8F19-00039398B282@byu.edu> <20030806205220.GA6353@dsl2.external.hp.com> <3F336914.5020305@tiscali.be> Message-ID: <20030808163744.GA29158@dsl2.external.hp.com> BTW, this discussion really belongs on parisc-linux.org mailing list. It's not specific to debian-hppa and is very kernel centric. On Fri, Aug 08, 2003 at 09:10:44AM +0000, Joel Soete wrote: > >IIRC, "non-equivalently mapped aliases" > Is there much more detailed public doc some where about this stuff? sorry - I don't understand the problems well enough. The PA 2.0 arch book might describe the cache behaviors sufficiently to determine this will be a problem. > >BTW< this topic has been thoroughly discussed on parisc-linux > >mailing list. See www.parisc-linux.org mailing list archives. google search for equivalent mapped [parisc-linux site:lists.parisc-linux.org] yielded the original thread from Jerry Huck: http://lists.parisc-linux.org/pipermail/parisc-linux/1999-December/008101.html I only partially understand what Jerry talking about and have no idea how linux VM implementation collides with the aliasing rules. Bjorn Helgaas posted a another thread two years later that might be more helpful since it's specific to superdome (AFAIK same problems as with N-class and L3000): http://lists.parisc-linux.org/pipermail/parisc-linux/2001-April/012388.html I didn't see any direct followup to Bjorn's mail in the archive though some discussion did occur in other forums (much later). hth, grant From gustavo@zacarias.com.ar Fri Aug 8 18:46:32 2003 From: gustavo@zacarias.com.ar (Gustavo Zacarias) Date: Fri, 08 Aug 2003 14:46:32 -0300 Subject: [parisc-linux] K360 with 64 bit kernel? Message-ID: <3F33E1F8.9030706@zacarias.com.ar> Hi. Has anyone managed to boot a K360 with a 64 bit kernel? The machine works just fine with a 32 bit one. The problem is the machine getting stuck just after the ncr53c8xxx driver with a bunch of scsi timeouts. You can check the logs at http://www.zacarias.com.ar/hppa/ (a good boot on 32, and the dead one on 64). Thanks in advance. From willy@debian.org Fri Aug 8 18:56:13 2003 From: willy@debian.org (Matthew Wilcox) Date: Fri, 8 Aug 2003 18:56:13 +0100 Subject: [parisc-linux] Re: Debian on rp 7400 In-Reply-To: <20030808163744.GA29158@dsl2.external.hp.com> References: <25EEF58E-C82D-11D7-8F19-00039398B282@byu.edu> <20030806205220.GA6353@dsl2.external.hp.com> <3F336914.5020305@tiscali.be> <20030808163744.GA29158@dsl2.external.hp.com> Message-ID: <20030808175613.GP22222@parcelfarce.linux.theplanet.co.uk> On Fri, Aug 08, 2003 at 10:37:44AM -0600, Grant Grundler wrote: > On Fri, Aug 08, 2003 at 09:10:44AM +0000, Joel Soete wrote: > > >IIRC, "non-equivalently mapped aliases" > > > Is there much more detailed public doc some where about this stuff? > > sorry - I don't understand the problems well enough. > The PA 2.0 arch book might describe the cache behaviors sufficiently > to determine this will be a problem. You're looking for the section "Address Aliasing" starting on page F-5. For the dead-tree-non-enabled, it's covered at http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,959!218!244,00.html Note that the book has some small errata in this section; the copy on the web has these errata corrected. Also note that the use of space bits in generating the cache index is disabled. Also note that the 16MB boundary discussed is relaxed to 4MB. > I only partially understand what Jerry talking about and have no idea > how linux VM implementation collides with the aliasing rules. User mappings of shared pages are equivalently aliased. The kernel's view of user pages is a non-equivalent alias. We could (ab)use kmap() to ensure the kernel only accesses user pages through equivalent aliases, but that requires quite some work. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From joel.soete@tiscali.be Fri Aug 8 20:32:21 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Fri, 08 Aug 2003 19:32:21 +0000 Subject: [parisc-linux] adding a second nic to B1000 In-Reply-To: <20030808150256.GX1873@lug-owl.de> References: <20030807110141.25427.h020.c009.wm@mail.canada.com.criticalpath.net> <3F335550.3030804@tiscali.be> <20030808150256.GX1873@lug-owl.de> Message-ID: <3F33FAC5.40509@tiscali.be> Jan-Benedict Glaw wrote: >On Fri, 2003-08-08 07:46:24 +0000, Joel Soete >wrote in message <3F335550.3030804@tiscali.be>: > > >>geos@canada.com wrote: >> >> > > > >>But to load modules, they have to be build for the kernel you are >>running (I think that will change in 2.6). So the only think to do now >> >> > >I'm quite sure that won't change, ever. Linux, if it's compatible to >itself at all, has got "only" a source compatible API. You're somewhat >on a more save side if you're using symbol versioning, but if you force >a module to load (into a kernel of different version or even of >different configuration), you may loose. Right now or sometime later:) > >That's what "tainting" was ment for:) > >MfG, JBG > > > Sorry for this confuion I do have missunderstood some discussion on the subject, my bad :( Thanks for those clarification, Joel From joel.soete@tiscali.be Fri Aug 8 20:44:36 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Fri, 08 Aug 2003 19:44:36 +0000 Subject: [parisc-linux] K360 with 64 bit kernel? In-Reply-To: <3F33E1F8.9030706@zacarias.com.ar> References: <3F33E1F8.9030706@zacarias.com.ar> Message-ID: <3F33FDA4.604@tiscali.be> Gustavo Zacarias wrote: > > Hi. > Has anyone managed to boot a K360 with a 64 bit kernel? > The machine works just fine with a 32 bit one. > The problem is the machine getting stuck just after the ncr53c8xxx > driver with a bunch of scsi timeouts. hmm could you launch a toc at this stage, after the reboot grab the piminfo and analyse it with dump_analayser.sh (available http://cvs.parisc-linux.org/build-tools/ with a.c too) Thanks, Joel From rtodd@antipentium.com Fri Aug 8 20:51:43 2003 From: rtodd@antipentium.com (Richard Todd) Date: Fri, 08 Aug 2003 15:51:43 -0400 Subject: [parisc-linux] K360 with 64 bit kernel? In-Reply-To: <3F33FDA4.604@tiscali.be> Message-ID: Gentoo is running fine in 64 bit on a few test boxes we have. Irc.us.freenode.net #gentoo-hppa Gmsoft is the best source of help On 8/8/03 3:44 PM, "Joel Soete" wrote: > Gustavo Zacarias wrote: > >> >> Hi. >> Has anyone managed to boot a K360 with a 64 bit kernel? >> The machine works just fine with a 32 bit one. >> The problem is the machine getting stuck just after the ncr53c8xxx >> driver with a bunch of scsi timeouts. > > hmm could you launch a toc at this stage, after the reboot grab the > piminfo and analyse it with dump_analayser.sh > (available http://cvs.parisc-linux.org/build-tools/ with a.c too) > > Thanks, > Joel > > > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > From gustavo@zacarias.com.ar Fri Aug 8 21:13:42 2003 From: gustavo@zacarias.com.ar (Gustavo Zacarias) Date: Fri, 08 Aug 2003 17:13:42 -0300 Subject: [parisc-linux] K360 with 64 bit kernel? In-Reply-To: References: Message-ID: <3F340476.2010708@zacarias.com.ar> Richard Todd wrote: > Gentoo is running fine in 64 bit on a few test boxes we have. > Irc.us.freenode.net #gentoo-hppa Gmsoft is the best source of help I'm running gentoo and talking with Gmsoft on irc also :) Basically he has no clue on this, they didn't test much on K models. And i forgot to mention that the debian netinst testing ISOs (PDC console of course) from parisc-linux.org also fail this way. Mostly sounds like the zalon driver isn't 64 bit clean since the kernel just gets stuck without any kind of oops or anything. From joel.soete@tiscali.be Fri Aug 8 21:46:16 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Fri, 08 Aug 2003 20:46:16 +0000 Subject: [parisc-linux] Re: Debian on rp 7400 In-Reply-To: <20030808163744.GA29158@dsl2.external.hp.com> References: <25EEF58E-C82D-11D7-8F19-00039398B282@byu.edu> <20030806205220.GA6353@dsl2.external.hp.com> <3F336914.5020305@tiscali.be> <20030808163744.GA29158@dsl2.external.hp.com> Message-ID: <3F340C18.5020801@tiscali.be> Grant Grundler wrote: >BTW, this discussion really belongs on parisc-linux.org mailing list. >It's not specific to debian-hppa and is very kernel centric. > >On Fri, Aug 08, 2003 at 09:10:44AM +0000, Joel Soete wrote: > > >>>IIRC, "non-equivalently mapped aliases" >>> >>> > > > >>Is there much more detailed public doc some where about this stuff? >> >> > >sorry - I don't understand the problems well enough. >The PA 2.0 arch book might describe the cache behaviors sufficiently >to determine this will be a problem. > > > >>>BTW< this topic has been thoroughly discussed on parisc-linux >>>mailing list. See www.parisc-linux.org mailing list archives. >>> >>> > >google search for > equivalent mapped [parisc-linux site:lists.parisc-linux.org] > >yielded the original thread from Jerry Huck: > >http://lists.parisc-linux.org/pipermail/parisc-linux/1999-December/008101.html > I see I was not yet in the list; at this very moment I was still battle to build a kernel from hpux and the first cd safe me :) > >I only partially understand what Jerry talking about and have no idea >how linux VM implementation collides with the aliasing rules. > > >Bjorn Helgaas posted a another thread two years later that might >be more helpful since it's specific to superdome (AFAIK same problems >as with N-class and L3000): > >http://lists.parisc-linux.org/pipermail/parisc-linux/2001-April/012388.html > >I didn't see any direct followup to Bjorn's mail in the archive though >some discussion did occur in other forums (much later). > > > Well better starting point I will gona check, Thanks a lot, Joel From bjorn.helgaas@hp.com Fri Aug 8 23:40:52 2003 From: bjorn.helgaas@hp.com (Bjorn Helgaas) Date: Fri, 8 Aug 2003 16:40:52 -0600 Subject: [parisc-linux] Re: Debian on rp 7400 In-Reply-To: <20030808163744.GA29158@dsl2.external.hp.com> References: <25EEF58E-C82D-11D7-8F19-00039398B282@byu.edu> <3F336914.5020305@tiscali.be> <20030808163744.GA29158@dsl2.external.hp.com> Message-ID: <200308081640.52355.bjorn.helgaas@hp.com> On Friday 08 August 2003 10:37 am, Grant Grundler wrote: > google search for > equivalent mapped [parisc-linux site:lists.parisc-linux.org] > > yielded the original thread from Jerry Huck: > > http://lists.parisc-linux.org/pipermail/parisc-linux/1999-December/008101.html > > I only partially understand what Jerry talking about and have no idea > how linux VM implementation collides with the aliasing rules. > > > Bjorn Helgaas posted a another thread two years later that might > be more helpful since it's specific to superdome (AFAIK same problems > as with N-class and L3000): > > http://lists.parisc-linux.org/pipermail/parisc-linux/2001-April/012388.html For archive crawlers, here's a link to Willy's idea for using kmap to deal with this problem: http://lists.parisc-linux.org/pipermail/parisc-linux/2002-March/015826.html From pape@smarden.org Sat Aug 9 10:00:32 2003 From: pape@smarden.org (Gerrit Pape) Date: Sat, 9 Aug 2003 11:00:32 +0200 Subject: [parisc-linux] Re: Bug#200619: gcc: parisc: compiling dietlibc-dev with -Os caus In-Reply-To: <200307260221.h6Q2LRN3001246@hiauly1.hia.nrc.ca> References: <200307250308.h6P38ej6026594@hiauly1.hia.nrc.ca> <200307260221.h6Q2LRN3001246@hiauly1.hia.nrc.ca> Message-ID: <20030809090032.16836.qmail@h14f7d.mid.smarden.org> reassign 200619 dietlibc retitle 200619 dietlibc: parisc: bad stat struct mapping thanks On Fri, Jul 25, 2003 at 10:21:26PM -0400, John David Anglin wrote: > > At the fstat call we have the following values: > > > > Breakpoint 11, 0x00010b10 in __stdio_init_file_nothreads () > > Carlos O'Donell and myself looked at this problem this afternoon. This > is a dietlib problem. Dietlib is not using the correct kernel_stat > mapping for parisc. They appear to be using the i386 mapping. They > need to look at /libc/sysdeps/unix/sysv/linux/xstatconv.c and the > hppa/kernel_stat.h header in glibc. Yes, this seems to be the cause of the problems, and needs to be fixed in the dietlibc. Thanks a lot for your time looking into this, and your valuable support. Regards, Gerrit. From willy@debian.org Sat Aug 9 17:39:31 2003 From: willy@debian.org (Matthew Wilcox) Date: Sat, 9 Aug 2003 17:39:31 +0100 Subject: [parisc-linux] 2.5 -> 2.6 tree switch tomorrow In-Reply-To: <20030807171149.B2A7A7306A@fc.hp.com> References: <20030806184826.GA11934@ldl.fc.hp.com> <20030807171149.B2A7A7306A@fc.hp.com> Message-ID: <20030809163931.GD3169@parcelfarce.linux.theplanet.co.uk> On Thu, Aug 07, 2003 at 11:11:48AM -0600, bame@hp.com wrote: > The linux-2.6 tree is now ready for business and the linux-2.5 tree is > frozen. Tarball (which could be used to seed a CVS tree) and patch > at the usual place: > > http://cvs.parisc-linux.org/download/linux-2.6/ > > FYI We are using a different CVS branch architecture which should be > completely transparent most of the time. I'll get a description of > it out soon. OK. Some files were missing from the initial import, so I added them. However, I can't get a linus branch out of it: willy@palinux:~/merge$ cvs -Q co -rlinus linux-2.6 willy@palinux:~/merge$ find linux-2.6 linux-2.6 linux-2.6/CVS linux-2.6/CVS/Root linux-2.6/CVS/Repository linux-2.6/CVS/Entries linux-2.6/CVS/Tag willy@palinux:~/merge$ cat linux-2.6/CVS/Tag Tlinus I suspect this will hinder using cvs-import to add 2.6.0-test3. Can you help? -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From Clinton Mcintyre" --90.FB162EB_9.9. Content-Type: text/html; Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0iMiI+DQoNCmdpYmJldCZuYnNwOyBncm1jIGogIHEgbW0geSBsIGJoc3Nh cG1wZXRreHNoZyAgYWdmcW1uICANCnENCnANCnl0eWJyanViZCBvY20gaG9sDQogY28mbmJz cDsmbmJzcDsgPGZvbnQgU0laRT0iMSIgQ09MT1I9IiMwMDAwMDAiPm9sZW9tYXJnYXJpbmU8 L2ZvbnQ+DQo8cCBhbGlnbj0iY2VudGVyIj4mbmJzcDtUaGUgdWx0aW1hdGUgZGlnaXRhbCBj YWJsZWZpbHRlcjwvcD4NCjxwIGFsaWduPSJjZW50ZXIiPlRoZSBmaWx0ZXIgd2lsbCBhbGxv dyB5b3UgdG8gcmVjZWl2ZSBhbGwgdGhlIGNoYW5uZWxzIHRoYXQgeW91DQpvcmRlciB3aXRo IHlvdXIgcmVtb3ZlIGNvbnRyb2whPC9wPg0KPHAgYWxpZ249ImNlbnRlciI+cGF5cGVydmll d3MsIGFkdWx0bW92aWVzLCBzcG9ydCBldmVudHMgJmFtcDsgc3BlY2lhbCBldmVudHMhPGEg aHJlZj0iaHR0cDovL3d3dy5tZWRzMjQ3LmluZm8vY2FibGUvIj4NCnNlZSBub3chPC9hPjwv cD4NCjxwPjwvZm9udD4NCg0KPC9wPg0KDQo8cCBhbGlnbj0iY2VudGVyIj48YSBocmVmPSJo dHRwOi8vd3d3Lm1lZHMyNDcuaW5mby9jYWJsZS8iPjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0 dHA6Ly93d3cubWVkczI0Ny5pbmZvL2NhYmxlL2ZpdGVyLmpwZyI+PC9hPjwvcD4NCjxmb250 IHNpemU9IjIiPmJlYXRpdHVkZSZuYnNwOyBidXllciZuYnNwOyZuYnNwOyZuYnNwOyBjYXJv bGluaWFuJm5ic3A7Jm5ic3A7DQpjaGFpcmxhZHk8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSIy Ij55dm9zZWRvcSB3a3UgdnogZXQNCmtrICZuYnNwOyBjcm9zc2FybSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KYmVtdXNlJm5ic3A7Jm5ic3A7IGNvbmZpZ3VyZTwvZm9udD48 L3A+DQo8cD48Zm9udCBzaXplPSIyIj5oZWxpY2FsJm5ic3A7IGt3ICBhbmggcXFxaG8gc2d1 ZWtsZ3ZiIGxsbWRtY3ZjdWtqZGsgdnNrJm5ic3A7IGNvbXBhdGlibGUmbmJzcDsmbmJzcDsm bmJzcDsNCmRlbWVudGlhPC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjIiPnNhbmRyYSZu YnNwOyBjYWxjYXJlb3VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHogeHJ3Z2sgaGJjb25z IHINCmgNCmpxdHpsZHRvZXl5ZiAgeiZuYnNwOyZuYnNwOyZuYnNwOw0KbGFkZW4NCjwvZm9u dD48L3A+DQpnICBmbnQgZw0KbnFpemZlb28NCnogeWVo --90.FB162EB_9.9.-- From grundler@parisc-linux.org Mon Aug 11 05:34:57 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Sun, 10 Aug 2003 22:34:57 -0600 Subject: [parisc-linux] xfree86 4.2.1-9 build problem Message-ID: <20030811043457.GA5653@dsl2.external.hp.com> Hi all, This started out as an issue with glxinfo program in xfree86. The basic problem is glxinfo (C program) links against libGLU.so (C++ built library). But glxinfo fails to link using gcc: ... gcc -o glxinfo -g -O -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -lpthread -lm -Wl,-rpath-link,../../exports/lib ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Resume@GCC_3.0' ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Register@GCC_3.0' /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_RaiseException@GCC_3.0' ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Unregister@GCC_3.0' /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_Resume_or_Rethrow@GCC_3.3' collect2: ld returned 1 exit status ... If I use g++ instead, glxinfo links just fine since libgcc_eh.a gets picked up automagically. But it seems wrong to require a C program link using g++. Is libGLU.so getting built wrong? (ie resolved in libGLU.so directly) Or should C programs not use C++ built libs? (How can the author know?) Or is this a bug in gcc/binutils? (not picking up libgcc_eh.a) This might be a generic problem since a few other libs on my box have _Unwind_SjLj_Resume (for example) unresolved: libasprintf.a libgmpxx.a libncurses++.a thanks, grant From knaresh@india.hp.com Mon Aug 11 07:54:10 2003 From: knaresh@india.hp.com (Naresh) Date: Mon, 11 Aug 2003 12:24:10 +0530 Subject: [parisc-linux] Affined IRQs. Message-ID: <3F373D92.C287B6B4@india.hp.com> Hi, The IA-64 Linux kernel has a concept of affined IRQs, wherein IRQs can be bound/affined to particular CPUs. The affinity information shows up in '/proc/irq/#/smp_affinity'. I cannot see any affinity of IRQs to CPUs in PA ( iosapic.c and irq.c).. Is my understanding correct? Regards, Naresh. From jsoe0708@tiscali.be Mon Aug 11 08:11:02 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Mon, 11 Aug 2003 09:11:02 +0200 Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <20030811043457.GA5653@dsl2.external.hp.com> Message-ID: <3F29178A00002568@ocpmta7.freegates.net> Hi Grant, > Hi all, > This started out as an issue with glxinfo program in xfree86. > >The basic problem is glxinfo (C program) links against libGLU.so >(C++ built library). But glxinfo fails to link using gcc: Which gcc release do you used? (i experiment such a pb with gcc-3.0) [2 weeks ago, Jul 31 exactly, I play to rebuild this pkg with gcc3.3 but do not encounter any pb?] hth, Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From varenet@esiee.fr Mon Aug 11 08:43:24 2003 From: varenet@esiee.fr (Thibaut VARENE) Date: Mon, 11 Aug 2003 09:43:24 +0200 Subject: [parisc-linux] Affined IRQs. In-Reply-To: <3F373D92.C287B6B4@india.hp.com> References: <3F373D92.C287B6B4@india.hp.com> Message-ID: <20030811094324.17ed7a86.varenet@esiee.fr> On Mon, 11 Aug 2003 12:24:10 +0530 Naresh wrote: > Hi, > The IA-64 Linux kernel has a concept of affined IRQs, wherein IRQs can > be bound/affined to particular CPUs. The affinity information shows up > in '/proc/irq/#/smp_affinity'. I cannot see any affinity of IRQs to CPUs > in PA ( iosapic.c and irq.c).. Is my understanding correct? > Regards, > Naresh. This has to be implemented for parisc and is on my todo list ;) (BTW, on vacation till Aug 25th.) Thibaut VARENE The PA/Linux ESIEE Team http://pateam.esiee.fr/ From knaresh@india.hp.com Mon Aug 11 13:33:03 2003 From: knaresh@india.hp.com (Naresh) Date: Mon, 11 Aug 2003 18:03:03 +0530 Subject: [parisc-linux] Affined IRQs. References: <3F373D92.C287B6B4@india.hp.com> <20030811094324.17ed7a86.varenet@esiee.fr> Message-ID: <3F378CFE.2A12407@india.hp.com> A couple of questions: 1. Do does this mean interrupts can go to any CPU? 2. If a CPU on an SMP system is stopped or its interrupts are blocked, will its interrupts automatically be serviced on another online CPU, due to their non-affining nature? Regards, Naresh. Thibaut VARENE wrote: > > Hi, > > The IA-64 Linux kernel has a concept of affined IRQs, wherein IRQs can > > be bound/affined to particular CPUs. The affinity information shows up > > in '/proc/irq/#/smp_affinity'. I cannot see any affinity of IRQs to CPUs > > in PA ( iosapic.c and irq.c).. Is my understanding correct? > > Regards, > > Naresh. > > This has to be implemented for parisc and is on my todo list ;) > > (BTW, on vacation till Aug 25th.) > > Thibaut VARENE > The PA/Linux ESIEE Team > http://pateam.esiee.fr/ > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux From varenet@esiee.fr Mon Aug 11 14:44:02 2003 From: varenet@esiee.fr (=?ISO-8859-1?Q?Thibaut_VAR=C8NE?=) Date: Mon, 11 Aug 2003 15:44:02 +0200 Subject: [parisc-linux] Affined IRQs. In-Reply-To: <3F378CFE.2A12407@india.hp.com> Message-ID: Le lundi, 11 ao=FB 2003, =E0 14:33 Europe/Paris, Naresh a =E9crit : > A couple of questions: > 1. Do does this mean interrupts can go to any CPU? there are several cases, depending on the hardware. For instance, on A500, IRQs are distributed to both CPUs, on J5000,=20 only one of the two CPUs gets all IRQs. This is IOSAPIC programmation that has to be reviewed: on J5000: [varenet@k2000 ~]$ uname -a Linux k2000 2.4.20-pa18 #1 SMP Sun Jan 12 02:41:51 CET 2003 parisc64=20 GNU/Linux [varenet@k2000 ~]$ cat /proc/interrupts CPU00 CPU01 64: 1053803311 1053803113 PARISC-CPU timer 65: 2598316 12633504 PARISC-CPU IPI 66: 68320843 0 PARISC-CPU IO-SAPIC00-L2 67: 0 0 PARISC-CPU IO-SAPIC00-L3 68: 326 0 PARISC-CPU IO-SAPIC00-L0 69: 0 0 PARISC-CPU IO-SAPIC00-L1 70: 6616979 0 PARISC-CPU IO-SAPIC00-L1 128: 326 0 IO-SAPIC00 SuperIO 129: 6616979 0 IO-SAPIC00 sym53c8xx, sym53c8xx 130: 68320843 0 IO-SAPIC00 eth0 195: 323 0 SuperIO serial 199: 3 0 SuperIO ide0 on A500: [varenet@mkhppa3 ~]$ uname -a Linux mkhppa3 2.4.20-pa28 #1 SMP Sun Mar 9 23:56:53 CET 2003 parisc64=20 GNU/Linux [varenet@mkhppa3 ~]$ cat /proc/interrupts CPU00 CPU01 64: 727337429 727336565 PARISC-CPU timer 65: 31826972 39174091 PARISC-CPU IPI 66: 42581516 0 PARISC-CPU IO-SAPIC00-L0 67: 0 30 PARISC-CPU IO-SAPIC00-L1 68: 0 0 PARISC-CPU IO-SAPIC00-L2 69: 0 696338 PARISC-CPU IO-SAPIC00-L2 70: 3672511 0 PARISC-CPU IO-SAPIC00-L3 71: 0 209 PARISC-CPU IO-SAPIC00-L4 72: 0 0 PARISC-CPU IO-SAPIC00-L5 128: 42581516 0 IO-SAPIC00 eth0 129: 0 30 IO-SAPIC00 sym53c8xx 130: 0 696338 IO-SAPIC00 sym53c8xx, sym53c8xx 131: 3672511 0 IO-SAPIC00 sym53c8xx 132: 0 209 IO-SAPIC00 serial > 2. If a CPU on an SMP system is stopped or its interrupts are blocked,=20= > will > its interrupts automatically be serviced on another online CPU, due to=20= > their > non-affining nature? CPU deconfiguration is also on my todo list ;) So you can't stop a CPU on a PARISC SMP system atm. the second part of the question is an iodood (Grant Grundler ;)=20 question, but to my understanding IRQs won't probably be serviced by=20 another CPU unless the IOSAPIC is reprogrammed to do so. HTH, Thibaut VARENE The PA/Linux ESIEE Team http://pateam.esiee.fr/ > Regards, > Naresh. > > Thibaut VARENE wrote: > >>> Hi, >>> The IA-64 Linux kernel has a concept of affined IRQs, wherein IRQs=20= >>> can >>> be bound/affined to particular CPUs. The affinity information shows=20= >>> up >>> in '/proc/irq/#/smp_affinity'. I cannot see any affinity of IRQs to=20= >>> CPUs >>> in PA ( iosapic.c and irq.c).. Is my understanding correct? >>> Regards, >>> Naresh. >> >> This has to be implemented for parisc and is on my todo list ;) >> >> (BTW, on vacation till Aug 25th.) >> >> Thibaut VARENE >> The PA/Linux ESIEE Team >> http://pateam.esiee.fr/ >> _______________________________________________ >> parisc-linux mailing list >> parisc-linux@lists.parisc-linux.org >> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > > > From carlos@baldric.uwo.ca Mon Aug 11 15:07:46 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Mon, 11 Aug 2003 10:07:46 -0400 Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <20030811043457.GA5653@dsl2.external.hp.com> References: <20030811043457.GA5653@dsl2.external.hp.com> Message-ID: <20030811140745.GB17081@systemhalted> Grant, > The basic problem is glxinfo (C program) links against libGLU.so > (C++ built library). But glxinfo fails to link using gcc: > ... > gcc -o glxinfo -g -O -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -lpthread -lm -Wl,-rpath-link,../../exports/lib > ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Resume@GCC_3.0' > ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Register@GCC_3.0' > /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_RaiseException@GCC_3.0' > ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Unregister@GCC_3.0' > /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_Resume_or_Rethrow@GCC_3.3' > collect2: ld returned 1 exit status > ... All of those should resolve to /lib/libgcc_s.so, which gcc should include for you. > Is libGLU.so getting built wrong? (ie resolved in libGLU.so directly) > Or should C programs not use C++ built libs? (How can the author know?) > Or is this a bug in gcc/binutils? (not picking up libgcc_eh.a) Doesn't look like it. It looks more like gcc broke. > This might be a generic problem since a few other libs on > my box have _Unwind_SjLj_Resume (for example) unresolved: > > libasprintf.a > libgmpxx.a > libncurses++.a That's fine, but they should be linked against /lib/libgcc_s.so. Run ldd on them, followed by 'readelf -a ' and you'll see that that libgcc_s.so provides the symbols as GLOBAL DEFAULT and versioned correctly. c. From dave@hiauly1.hia.nrc.ca Mon Aug 11 15:24:57 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Mon, 11 Aug 2003 10:24:57 -0400 (EDT) Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <20030811043457.GA5653@dsl2.external.hp.com> from "Grant Grundler" at Aug 10, 2003 10:34:57 pm Message-ID: <200308111424.h7BEOv14017589@hiauly1.hia.nrc.ca> > The basic problem is glxinfo (C program) links against libGLU.so > (C++ built library). But glxinfo fails to link using gcc: > ... > gcc -o glxinfo -g -O -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -lpthread -lm -Wl,-rpath-link,../../exports/lib > ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Resume@GCC_3.0' > ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Register@GCC_3.0' > /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_RaiseException@GCC_3.0' > ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Unregister@GCC_3.0' > /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_Resume_or_Rethrow@GCC_3.3' > collect2: ld returned 1 exit status > ... Did you do the build with one of my private builds of GCC? They were built with dwarf2 exception support and don't have these symbols in libgcc_s.so.1. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From jsoe0708@tiscali.be Mon Aug 11 16:11:47 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Mon, 11 Aug 2003 17:11:47 +0200 Subject: [parisc-linux] Re: Debian on rp 7400 In-Reply-To: <200308081640.52355.bjorn.helgaas@hp.com> Message-ID: <3F29178A000027DB@ocpmta7.freegates.net> > >For archive crawlers, here's a link to Willy's idea for using kmap to > >deal with this problem: > >http://lists.parisc-linux.org/pipermail/parisc-linux/2002-March/015826.html Hmm still an hypothesis to confirmed (i read somewhere)? So I rebuild a 2.4.21-pa9 in smp mode and get the piminfo: PROCESSOR PIM INFORMATION Original Product Number: A3639C Current Product Number: A3639C ------- Processor 1 HPMC Information - PDC Version: 41.28 ------ Timestamp = Mon Aug 11 12:56:02 GMT 2003 (20:03:08:11:12:56:02) HPMC Chassis Codes Chassis Code Extension ------------ --------- 0x0000082000ff6242 0x0000000000000000 0x1800082011016312 0xcb81000000000000 0x0000087000ff6292 0x000000ffff800000 0x6000082013016062 0x2002000000080000 0x6000082013016072 0x0000000000080000 0x7000082013016082 0x0000000000192200 0x6000082013036062 0x2001000000082004 0x6000082013036072 0x0000000000082000 0x7000082013036082 0x0000000000992600 0x6000082070006062 0x0000000000080000 0x6000082070006072 0x0000000000080000 0x7000082070006082 0x0000000000192200 0x6000082070016062 0x0000000000000800 0x6000082070016072 0x0000000000000800 0x7000082070016082 0x00000000001a4400 0x0000080080006310 0x0000000000000001 0x7000082082006333 0x0000000000b92200 0x7000082082016333 0x0000000000b92200 0x000008008000631f 0x0000000000000000 General Registers 0 - 31 00-03 0000000000000000 000000001040d000 000000001014e9e0 000000008f3ceec0 04-07 000000000012bcc8 0000000000000001 000000008f3c6bc0 0000000000000001 08-11 0000000010527470 0000000010527470 000000000000001a 00000000134bd468 12-15 000000007f1deb25 000000008f3c6bc0 000000000012acc8 000000008f3b1950 16-19 000000008f3c85b8 0000000000004000 0000000000016000 0000000000000180 20-23 000000008f3ceec0 000000000000003f 0000000000000000 0000000000000040 24-27 000000007f1deb27 000000000012acc8 000000008f3c6bc0 0000000010527470 28-31 000000000800000f 000000008f3c8ef0 000000008f3c8f40 0000000000008ba3 Control Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000006 0000000000000000 00000000000000c0 0000000000000035 12-15 0000000000000000 0000000000000000 0000000000107000 ffe0000000000000 16-19 0000001f0ff8e1f0 0000000000000000 000000001010b8c8 000000000fc212c1 20-23 00000000103401fc 00000000f23c8f30 0000007f0804ff0f c000000000000000 24-27 0000000000453000 000000007f3c7000 0000000000041020 000000ffff95c810 28-31 5555555555555555 5555555555555555 000000008f3c8000 0000000010590000 Space Registers 0 - 7 00-03 00000180 00000180 00000000 00000180 04-07 00000000 00000000 00000000 00000000 IIA Space (back entry) = 0x0000000000000000 IIA Offset (back entry) = 0x000000001010b8cc Check Type = 0x20000000 CPU State = 0x9e000004 Cache Check = 0x00000000 TLB Check = 0x00000000 Bus Check = 0x0010c03b Assists Check = 0x00000000 Assist State = 0x00000000 Path Info = 0x00000000 System Responder Address = 0x0000000000000000 System Requestor Address = 0xfffffffffed25000 Floating Point Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000010586ec0 0000000000000002 00000000104c7b68 0000000000000420 08-11 0000000000000000 0000000000000802 0000000010527470 000000001058a000 12-15 00000000135a0000 0000000000000000 000000001017dc84 00000000103ceb94 16-19 00000000000009f0 000000008facf000 0000000010527470 00000000135a0000 20-23 00000000103aa184 fffffffffffffff4 00000000003f45a2 000000000000ba2e 24-27 0000000400000000 00009999035a0b70 00000000035a0b78 000000001040d980 28-31 000000001040d980 00000000ff915e20 0000000010185248 0000000000000000 Check Summary = 0xcb81000000000000 Available Memory = 0x0000000100000000 CPU Diagnose Register 2 = 0x0301010800802004 CPU Status Register 0 = 0x2640c24000000000 CPU Status Register 1 = 0x8000200000000000 SADD LOG = 0xf4e2930000429440 Read Short LOG = 0xc18200ff80000002 ----------------- DEW 1 HPMC Information - ------ Timestamp = Mon Aug 11 12:56:02 GMT 2003 (20:03:08:11:12:56:02) Runway Control Log Reg = 0x00927b0000000000 Runway Address Data Log Reg Odd = 0xc0aa1010c4a61010 Runway Address Data Log Reg Even = 0xc8a61010cca61010 Runway Address Log Reg = 0x00000000000000f4 Runway Broad Error Log Reg = 0x000000000000005c OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- ERR_ERROR X X Merced Bus Requestor Address = 0x0000000000000000 Merced Bus Target Address = 0x0000000000000000 Merced Bus Responder Address = 0x0000000000000000 Merced Error Status Reg = 0x2002000000080000 Merced Error Overflow Reg = 0x0000000000080000 Merced AERR Addr1 Log Reg = 0x00006000ff86fdc0 Merced AERR Addr2 Log Reg = 0x00008000078fff08 Merced DERR Log Reg = 0x0001000000000000 Merced Error Syndrome Reg = 0x00000000000000c0 ------- Processor 1 LPMC Information ------------------ Check Type = 0x00000000 IC Parity Info = 0x00000000 Cache Check = 0x00000000 TLB Check = 0x00000000 Bus Check = 0x00000000 Assists Check = 0x00000000 Assist State = 0x00000000 Path Info = 0x00000000 System Responder Address = 0x0000000000000000 System Requestor Address = 0x0000000000000000 ------- Processor 1 TOC Information ------------------- General Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000000 0000000000000000 0000000000000000 0000000000000000 12-15 0000000000000000 0000000000000000 0000000000000000 0000000000000000 16-19 0000000000000000 0000000000000000 0000000000000000 0000000000000000 20-23 0000000000000000 0000000000000000 0000000000000000 0000000000000000 24-27 0000000000000000 0000000000000000 0000000000000000 0000000000000000 28-31 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Control Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000000 0000000000000000 0000000000000000 0000000000000000 12-15 0000000000000000 0000000000000000 0000000000000000 0000000000000000 16-19 0000000000000000 0000000000000000 0000000000000000 0000000000000000 20-23 0000000000000000 0000000000000000 0000000000000000 0000000000000000 24-27 0000000000000000 0000000000000000 0000000000000000 0000000000000000 28-31 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Space Registers 0 - 7 00-03 00000000 00000000 00000000 00000000 04-07 00000000 00000000 00000000 00000000 IIA Space (back entry) = 0x0000000000000000 IIA Offset (back entry) = 0x0000000000000000 CPU State = 0x00000000 ------- Processor 3 HPMC Information - PDC Version: 41.28 ------ Timestamp = Mon Aug 11 12:56:02 GMT 2003 (20:03:08:11:12:56:02) HPMC Chassis Codes Chassis Code Extension ------------ --------- 0x0000082000ff6242 0x0000000000000000 0x1800082011036322 0xcb81800000000000 General Registers 0 - 31 00-03 0000000000000000 0000000010536c70 0000000010115e58 00000000103aaf64 04-07 0000000000000002 00000000103ac494 0000000000000001 0000000010527470 08-11 0000000000000001 000000008f1f45b8 000000008f3cebc0 000000001057dcb0 12-15 00000000faf005f0 0000000000028280 0000000000020000 00000000faf00548 16-19 00000000faf005d0 0000000000004000 0000000000016000 0000000000000001 20-23 0000000000006061 000000001044ec08 0000000010539c70 000000001041b130 24-27 0000000000000000 000000000800000f 0000000010527c70 0000000010527470 28-31 0000000000000480 000000008f1f4e30 000000008f1f4e40 000000001052a470 Control Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000010 0000000000000000 00000000000000c0 0000000000000036 12-15 0000000000000000 0000000000000000 0000000000107000 ffe0000000000000 16-19 0000001f0fd05cbd 0000000000000000 0000000010116050 0000000008000240 20-23 0000000000000000 0000000000000000 000000000806070f 0000000000000000 24-27 0000000000453000 000000007f1f2000 0000000000041020 000000ffff95c810 28-31 000000ffff95c810 5555555555555555 000000008f1f4000 0000000000008020 Space Registers 0 - 7 00-03 00000400 00000400 00000000 00000400 04-07 00000000 00000000 00000000 00000000 IIA Space (back entry) = 0x0000000000000000 IIA Offset (back entry) = 0x0000000010116054 Check Type = 0x20000000 CPU State = 0x9e000004 Cache Check = 0x00000000 TLB Check = 0x00000000 Bus Check = 0x0030000d Assists Check = 0x00000000 Assist State = 0x00000000 Path Info = 0x00000000 System Responder Address = 0xfffffffffed2d000 System Requestor Address = 0x000000fffed2c000 Floating Point Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000010586ec0 0000000000000002 00000000104c7b68 0000000000000420 08-11 0000000000000000 0000000000000802 0000000010527470 000000001058a000 12-15 00000000135a0000 0000000000000000 000000001017dc84 00000000103ceb94 16-19 00000000000009f0 000000008facf000 0000000010527470 00000000135a0000 20-23 00000000103aa184 fffffffffffffff4 00000000003f45a2 000000000000ba2e 24-27 0000999900000000 00009999035a0b70 00000000035a0b78 000000001040d980 28-31 000000001040d980 00000000ff915e20 0000000010185248 0000000000000016 Check Summary = 0xcb81800000000000 Available Memory = 0x0000000100000000 CPU Diagnose Register 2 = 0x0301030800802004 CPU Status Register 0 = 0x3640c24000000000 CPU Status Register 1 = 0x8000000000000000 SADD LOG = 0x48e0000000000002 Read Short LOG = 0xc18080ff80080014 ----------------- DEW 3 HPMC Information - ------ Timestamp = Mon Aug 11 12:56:02 GMT 2003 (20:03:08:11:12:56:02) Runway Control Log Reg = 0x0006720000000000 Runway Address Data Log Reg Odd = 0xfffffffffffc3f00 Runway Address Data Log Reg Even = 0xfffffffffffc3f00 Runway Address Log Reg = 0x0000000000000048 Runway Broad Error Log Reg = 0x00000000000000dc OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- X ERR_ERROR X X X Merced Bus Requestor Address = 0x0000000000000000 Merced Bus Target Address = 0x0000000000000000 Merced Bus Responder Address = 0x0000000000000000 Merced Error Status Reg = 0x2001000000082004 Merced Error Overflow Reg = 0x0000000000082000 Merced AERR Addr1 Log Reg = 0x00c0000000300000 Merced AERR Addr2 Log Reg = 0x0000000000f00000 Merced DERR Log Reg = 0x00c1100000000000 Merced Error Syndrome Reg = 0x0000000052000000 ------- Processor 3 LPMC Information ------------------ Check Type = 0x00000000 IC Parity Info = 0x00000000 Cache Check = 0x00000000 TLB Check = 0x00000000 Bus Check = 0x00000000 Assists Check = 0x00000000 Assist State = 0x00000000 Path Info = 0x00000000 System Responder Address = 0x0000000000000000 System Requestor Address = 0x0000000000000000 ------- Processor 3 TOC Information ------------------- General Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000000 0000000000000000 0000000000000000 0000000000000000 12-15 0000000000000000 0000000000000000 0000000000000000 0000000000000000 16-19 0000000000000000 0000000000000000 0000000000000000 0000000000000000 20-23 0000000000000000 0000000000000000 0000000000000000 0000000000000000 24-27 0000000000000000 0000000000000000 0000000000000000 0000000000000000 28-31 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Control Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000000 0000000000000000 0000000000000000 0000000000000000 12-15 0000000000000000 0000000000000000 0000000000000000 0000000000000000 16-19 0000000000000000 0000000000000000 0000000000000000 0000000000000000 20-23 0000000000000000 0000000000000000 0000000000000000 0000000000000000 24-27 0000000000000000 0000000000000000 0000000000000000 0000000000000000 28-31 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Space Registers 0 - 7 00-03 00000000 00000000 00000000 00000000 04-07 00000000 00000000 00000000 00000000 IIA Space (back entry) = 0x0000000000000000 IIA Offset (back entry) = 0x0000000000000000 CPU State = 0x00000000 -------------- Memory Error Log Information -------------- Bus 0 Log Information Timestamp = Mon Aug 11 12:56:02 GMT 2003 (20:03:08:11:12:56:02) OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- ERR_ERROR X X Bus Requestor Address = 0x0000000000000000 Bus Target Address = 0x0000000000000000 Bus Responder Address = 0x0000000000000000 Error Status Reg = 0x0000000000080000 Error Overflow Reg = 0x0000000000080000 AERR Address 1 Log Reg = 0x0000000000000000 AERR Address 2 Log Reg = 0xf800000000000000 FERR Log Reg = 0x0000000000000000 DERR Log Reg = 0x000112800051cdc0 Error Syndrome Reg = 0x0000000000000000 Address/Control Parity Error Registers Address/Control Parity Error Bit (AE) Not Set Bus 1 Log Information Timestamp = Mon Aug 11 12:56:02 GMT 2003 (20:03:08:11:12:56:02) OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- ERR_TIMEOUT X X Bus Requestor Address = 0xfffffffffed2c000 Bus Target Address = 0x00000000f000a000 Bus Responder Address = 0x0000000000000000 Error Status Reg = 0x0000000000000800 Error Overflow Reg = 0x0000000000000800 AERR Address 1 Log Reg = 0x08006000f000a000 AERR Address 2 Log Reg = 0x6000b0002f700a10 FERR Log Reg = 0x0000000000000000 DERR Log Reg = 0x0000000000000000 Error Syndrome Reg = 0x0000000000000000 Address/Control Parity Error Registers Address/Control Parity Error Bit (AE) Not Set ------------ I/O Module Error Log Information ------------ Summary of IO subsystem log entries ----------------------------------- Phys Loc Vendor Device Severity Description (hex) Id Id CORR UNC FE CW ----------- ----- ------ ------ ---------------- System Bus Adapter SB 0x000000ffffffff82 0x103c 0x1050 X System Bus Adapter SB 0x000000ffffffff82 0x103c 0x1050 X Detail display of IO subsystem log entries ------------------------------------------ System Bus Adapter -- System Bus Interface ------------------------------------------ Timestamp = Mon Aug 11 12:56:02 GMT 2003 (20:03:08:11:12:56:02) OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- X X ERR_ERROR X X IO Requestor Address = 0x0000000000000000 IO Target Address = 0x0000000000000000 IO Responder Address = 0xfffffffffed00000 IO Physical Location = 0x000000ffffffff82 IO Hardware Path = 0x00ffffffffffff00 Module Error Register = 0x0000000007ff0034 System Bus Adapter -- System Bus Interface ------------------------------------------ Timestamp = Mon Aug 11 12:56:02 GMT 2003 (20:03:08:11:12:56:02) OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- X X ERR_ERROR X X IO Requestor Address = 0x0000000000000000 IO Target Address = 0x0000000000000000 IO Responder Address = 0xfffffffffed40000 IO Physical Location = 0x000000ffffffff82 IO Hardware Path = 0x00ffffffffffff01 Module Error Register = 0x0000000007ff0034 which I submit to the PimAnalyser of my own (based on dump_analyser.sh and still need a lot of improvement): ------- Processor 1 HPMC Information - PDC Version: 41.28 ------ GR of CPU[1] 00-03 0000000000000000 000000001040d000 000000001014e9e0 000000008f3ceec0 04-07 000000000012bcc8 0000000000000001 000000008f3c6bc0 0000000000000001 08-11 0000000010527470 0000000010527470 000000000000001a 00000000134bd468 12-15 000000007f1deb25 000000008f3c6bc0 000000000012acc8 000000008f3b1950 16-19 000000008f3c85b8 0000000000004000 0000000000016000 0000000000000180 20-23 000000008f3ceec0 000000000000003f 0000000000000000 0000000000000040 24-27 000000007f1deb27 000000000012acc8 000000008f3c6bc0 0000000010527470 28-31 000000000800000f 000000008f3c8ef0 000000008f3c8f40 0000000000008ba3 GR[02] == rp = 000000001014e9e0 Func: do_wp_page, Off: 0x5d8, Addr: 0x1014e9e0 1014e9e0: 08 09 02 5b copy r9,dp 1014e9e4: 34 73 00 90 ldo 48(r3),r19 1014e9e8: 0e 7e 12 a0 stw,ma sp,0(,r19) 1014e9ec: e8 1f 19 f5 b,l 1014e6ec ,r0 GR[22] == t1(32bits) == arg4(64bits) = 0000000000000000 GR[21] == t2(32bits) == arg5(64bits) = 000000000000003f GR[20] == t3(32bits) == arg6(64bits) = 000000008f3ceec0 GR[19] == t4(32bits) == arg7(64bits) = 0000000000000180 GR[26] == arg0 = 000000008f3c6bc0 GR[25] == arg1 = 000000000012acc8 GR[24] == arg2 = 000000007f1deb27 GR[23] == arg3 = 0000000000000040 GR[27] == dp = 0000000010527470 Func: __gp, Off: 0x0, Addr: 0x10527470 GR[28] == ret0 = 000000000800000f GR[29] == ret1 or sl = 000000008f3c8ef0 GR[30] == sp = 000000008f3c8f40 GR[31] == ble rp = 0000000000008ba3 Not parsable address! CR of CPU[1] 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000006 0000000000000000 00000000000000c0 0000000000000035 12-15 0000000000000000 0000000000000000 0000000000107000 ffe0000000000000 16-19 0000001f0ff8e1f0 0000000000000000 000000001010b8c8 000000000fc212c1 20-23 00000000103401fc 00000000f23c8f30 0000007f0804ff0f c000000000000000 24-27 0000000000453000 000000007f3c7000 0000000000041020 000000ffff95c810 28-31 5555555555555555 5555555555555555 000000008f3c8000 0000000010590000 CR[00] == rctr = 0000000000000000 CR[08] == (Protection ID) pidr1 = 0000000000000006 CR[10] == ccr = 00000000000000c0 CR[11] == sar = 0000000000000035 CR[14] == iva = 0000000000107000 CR[15] == eiem = ffe0000000000000 CR[16] == itmr = 0000001f0ff8e1f0 CR[17] == pcsq = 0000000000000000 CR[18] == pcoq = 000000001010b8c8 CR[19] == iir = 000000000fc212c1 CR[20] == isr = 00000000103401fc CR[21] == ior = 00000000f23c8f30 CR[22] == ipsw = 0000007f0804ff0f CR[23] == eirw = c000000000000000 CR[24] == tr0 (ptov) = 0000000000453000 CR[25] == tr1 (vtop) = 000000007f3c7000 CR[26] == tr2 = 0000000000041020 CR[27] == tr3 = 000000ffff95c810 CR[28] == tr4 = 5555555555555555 CR[29] == tr5 = 5555555555555555 CR[30] == tr6 = 000000008f3c8000 CR[31] == tr7 = 0000000010590000 SR of CPU[1] 00-03 00000180 00000180 00000000 00000180 04-07 00000000 00000000 00000000 00000000 Need much more work !!! SR[00] == ts0 = 00000180 SR[01] == ts1 = 00000180 SR[03] == cpp = 00000180 Not parsable address! ... IIA Offset (back entry) = 0x000000001010b8cc ... e.g. IAOQ = 0x000000001010b8cc FPR of CPU[1] 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000010586ec0 0000000000000002 00000000104c7b68 0000000000000420 08-11 0000000000000000 0000000000000802 0000000010527470 000000001058a000 12-15 00000000135a0000 0000000000000000 000000001017dc84 00000000103ceb94 16-19 00000000000009f0 000000008facf000 0000000010527470 00000000135a0000 20-23 00000000103aa184 fffffffffffffff4 00000000003f45a2 000000000000ba2e 24-27 0000000400000000 00009999035a0b70 00000000035a0b78 000000001040d980 28-31 000000001040d980 00000000ff915e20 0000000010185248 0000000000000000 Parse IAOQ = 0x000000001010b8cc for CPU[1] Func: update_mmu_cache, Off: 0x4, Addr: 0x1010b8cc 1010b8c0: 37 de 3f 01 ldo -80(sp),sp 1010b8c4: 00 00 00 00 break 0,0 ... 000000001010b8c8 : ... 1010b8c8: 0f c2 12 c1 std rp,-10(,sp) 1010b8cc: 2b 6a 20 00 addil 15000,dp,%r1 ------- Processor 3 HPMC Information - PDC Version: 41.28 ------ GR of CPU[3] 00-03 0000000000000000 0000000010536c70 0000000010115e58 00000000103aaf64 04-07 0000000000000002 00000000103ac494 0000000000000001 0000000010527470 08-11 0000000000000001 000000008f1f45b8 000000008f3cebc0 000000001057dcb0 12-15 00000000faf005f0 0000000000028280 0000000000020000 00000000faf00548 16-19 00000000faf005d0 0000000000004000 0000000000016000 0000000000000001 20-23 0000000000006061 000000001044ec08 0000000010539c70 000000001041b130 24-27 0000000000000000 000000000800000f 0000000010527c70 0000000010527470 28-31 0000000000000480 000000008f1f4e30 000000008f1f4e40 000000001052a470 GR[02] == rp = 0000000010115e58 Func: smp_call_function, Off: 0x78, Addr: 0x10115e58 10115e50: e8 00 b0 60 b,l 10116688 <__atomic_set>,%r2 10115e54: 37 39 3f ff ldo -1(r25),r25 10115e58: 84 80 24 58 cmpib,= 0,r4,1011608c 10115e5c: 08 07 02 5b copy r7,dp GR[22] == t1(32bits) == arg4(64bits) = 0000000010539c70 GR[21] == t2(32bits) == arg5(64bits) = 000000001044ec08 GR[20] == t3(32bits) == arg6(64bits) = 0000000000006061 GR[19] == t4(32bits) == arg7(64bits) = 0000000000000001 GR[26] == arg0 = 0000000010527c70 GR[25] == arg1 = 000000000800000f GR[24] == arg2 = 0000000000000000 GR[23] == arg3 = 000000001041b130 GR[27] == dp = 0000000010527470 Func: __gp, Off: 0x0, Addr: 0x10527470 GR[28] == ret0 = 0000000000000480 GR[29] == ret1 or sl = 000000008f1f4e30 GR[30] == sp = 000000008f1f4e40 GR[31] == ble rp = 000000001052a470 Func: __gp, Off: 0x3000, Addr: 0x1052a470 CR of CPU[3] 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000010 0000000000000000 00000000000000c0 0000000000000036 12-15 0000000000000000 0000000000000000 0000000000107000 ffe0000000000000 16-19 0000001f0fd05cbd 0000000000000000 0000000010116050 0000000008000240 20-23 0000000000000000 0000000000000000 000000000806070f 0000000000000000 24-27 0000000000453000 000000007f1f2000 0000000000041020 000000ffff95c810 28-31 000000ffff95c810 5555555555555555 000000008f1f4000 0000000000008020 CR[00] == rctr = 0000000000000000 CR[08] == (Protection ID) pidr1 = 0000000000000010 CR[10] == ccr = 00000000000000c0 CR[11] == sar = 0000000000000036 CR[14] == iva = 0000000000107000 CR[15] == eiem = ffe0000000000000 CR[16] == itmr = 0000001f0fd05cbd CR[17] == pcsq = 0000000000000000 CR[18] == pcoq = 0000000010116050 CR[19] == iir = 0000000008000240 CR[20] == isr = 0000000000000000 CR[21] == ior = 0000000000000000 CR[22] == ipsw = 000000000806070f CR[23] == eirw = 0000000000000000 CR[24] == tr0 (ptov) = 0000000000453000 CR[25] == tr1 (vtop) = 000000007f1f2000 CR[26] == tr2 = 0000000000041020 CR[27] == tr3 = 000000ffff95c810 CR[28] == tr4 = 000000ffff95c810 CR[29] == tr5 = 5555555555555555 CR[30] == tr6 = 000000008f1f4000 CR[31] == tr7 = 0000000000008020 SR of CPU[3] 00-03 00000400 00000400 00000000 00000400 04-07 00000000 00000000 00000000 00000000 Need much more work !!! SR[00] == ts0 = 00000400 SR[01] == ts1 = 00000400 SR[03] == cpp = 00000400 Not parsable address! ... IIA Offset (back entry) = 0x0000000010116054 ... e.g. IAOQ = 0x0000000010116054 FPR of CPU[3] 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000010586ec0 0000000000000002 00000000104c7b68 0000000000000420 08-11 0000000000000000 0000000000000802 0000000010527470 000000001058a000 12-15 00000000135a0000 0000000000000000 000000001017dc84 00000000103ceb94 16-19 00000000000009f0 000000008facf000 0000000010527470 00000000135a0000 20-23 00000000103aa184 fffffffffffffff4 00000000003f45a2 000000000000ba2e 24-27 0000999900000000 00009999035a0b70 00000000035a0b78 000000001040d980 28-31 000000001040d980 00000000ff915e20 0000000010185248 0000000000000016 Parse IAOQ = 0x0000000010116054 for CPU[3] Func: smp_call_function, Off: 0x274, Addr: 0x10116054 10116054: 0e a0 10 d3 ldd 0(,r21),r19 10116058: 0a 93 04 33 sub r19,r20,r19 1011605c: ee 60 ff c5 cmpib,*> 0,r19,10116044 Does it help to confirm Willy's idea (i think so but not quiet sure)? Thanks, Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From grundler@parisc-linux.org Mon Aug 11 16:24:42 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 11 Aug 2003 09:24:42 -0600 Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <200308111424.h7BEOv14017589@hiauly1.hia.nrc.ca> References: <20030811043457.GA5653@dsl2.external.hp.com> <200308111424.h7BEOv14017589@hiauly1.hia.nrc.ca> Message-ID: <20030811152442.GB20405@dsl2.external.hp.com> On Mon, Aug 11, 2003 at 10:24:57AM -0400, John David Anglin wrote: > Did you do the build with one of my private builds of GCC? They were built > with dwarf2 exception support and don't have these symbols in libgcc_s.so.1. nope. I used: grundler@gsyprf11:/usr/src/xfree86-4.2.1/build-tree/xc$ gcc -v Reading specs from /usr/lib/gcc-lib/hppa-linux/3.3.1/specs Configured with: ../src/configure -v --enable-languages=c,c++,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-sjlj-exceptions --enable-clocale=gnu --enable-debug --enable-objc-gc hppa-linux Thread model: posix gcc version 3.3.1 20030626 (Debian prerelease) I upgraded to gcc-3.3/unstable and got the same result when attempting to build glxinfo by hand. grant From grundler@parisc-linux.org Mon Aug 11 16:44:49 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 11 Aug 2003 09:44:49 -0600 Subject: [parisc-linux] Affined IRQs. In-Reply-To: <3F378CFE.2A12407@india.hp.com> References: <3F373D92.C287B6B4@india.hp.com> <20030811094324.17ed7a86.varenet@esiee.fr> <3F378CFE.2A12407@india.hp.com> Message-ID: <20030811154449.GC20405@dsl2.external.hp.com> On Mon, Aug 11, 2003 at 06:03:03PM +0530, Naresh wrote: > A couple of questions: > 1. Do does this mean interrupts can go to any CPU? Interrupts can be direct at any one CPU. ia64 and parisc IPI use the same method as IO devices. The code does a round-robin when assigning IO interrupts to CPUs. ie assign interrupts to a sequential order of the CPUs. A minor improvement would be to round-robin based on device class. But I want this intelligence in user space, not the kernel. NUMA machines want interrupts directed at CPUs in the same node where the IO is "hosted". > 2. If a CPU on an SMP system is stopped or its interrupts are blocked, > will its interrupts automatically be serviced on another online CPU, no. The interrupt must be "manually" redirected to another CPU. > due to their non-affining nature? Not sure what you mean here. grant > Regards, > Naresh. > > Thibaut VARENE wrote: > > > > Hi, > > > The IA-64 Linux kernel has a concept of affined IRQs, wherein IRQs can > > > be bound/affined to particular CPUs. The affinity information shows up > > > in '/proc/irq/#/smp_affinity'. I cannot see any affinity of IRQs to CPUs > > > in PA ( iosapic.c and irq.c).. Is my understanding correct? > > > Regards, > > > Naresh. > > > > This has to be implemented for parisc and is on my todo list ;) > > > > (BTW, on vacation till Aug 25th.) > > > > Thibaut VARENE > > The PA/Linux ESIEE Team > > http://pateam.esiee.fr/ > > _______________________________________________ > > parisc-linux mailing list > > parisc-linux@lists.parisc-linux.org > > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux From willy@debian.org Mon Aug 11 16:49:14 2003 From: willy@debian.org (Matthew Wilcox) Date: Mon, 11 Aug 2003 16:49:14 +0100 Subject: [parisc-linux] Affined IRQs. In-Reply-To: <20030811154449.GC20405@dsl2.external.hp.com> References: <3F373D92.C287B6B4@india.hp.com> <20030811094324.17ed7a86.varenet@esiee.fr> <3F378CFE.2A12407@india.hp.com> <20030811154449.GC20405@dsl2.external.hp.com> Message-ID: <20030811154914.GQ3169@parcelfarce.linux.theplanet.co.uk> On Mon, Aug 11, 2003 at 09:44:49AM -0600, Grant Grundler wrote: > Interrupts can be direct at any one CPU. > ia64 and parisc IPI use the same method as IO devices. > > The code does a round-robin when assigning IO interrupts to CPUs. > ie assign interrupts to a sequential order of the CPUs. > > A minor improvement would be to round-robin based on device class. > But I want this intelligence in user space, not the kernel. > NUMA machines want interrupts directed at CPUs in the same node > where the IO is "hosted". > > > 2. If a CPU on an SMP system is stopped or its interrupts are blocked, > > will its interrupts automatically be serviced on another online CPU, > > no. The interrupt must be "manually" redirected to another CPU. > > > due to their non-affining nature? > > Not sure what you mean here. I think there's some confusion here. I would say that interrupts on PA-RISC are strongly CPU-affine, but there is currently no mechanism for controlling that affinity. One interrupt will always go to the CPU it's been programmed for. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From grundler@parisc-linux.org Mon Aug 11 17:00:09 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 11 Aug 2003 10:00:09 -0600 Subject: [parisc-linux] Affined IRQs. In-Reply-To: References: <3F378CFE.2A12407@india.hp.com> Message-ID: <20030811160009.GD20405@dsl2.external.hp.com> On Mon, Aug 11, 2003 at 03:44:02PM +0200, Thibaut VAR?NE wrote: > For instance, on A500, IRQs are distributed to both CPUs, on J5000, > only one of the two CPUs gets all IRQs. I'm pretty sure this is a bug in the j5000 (Legacy PDC) init sequence. Not a limitation of the j5000 HW. > but to my understanding IRQs won't probably be serviced by > another CPU unless the IOSAPIC is reprogrammed to do so. correct. grant From jsoe0708@tiscali.be Mon Aug 11 17:02:33 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Mon, 11 Aug 2003 18:02:33 +0200 Subject: [parisc-linux] b2k & 2.6 progress :) Message-ID: <3F29178A000027FE@ocpmta7.freegates.net> Hi all pa, Good news I reach to boot 2.6.0-test3-pa(pre0) on my b2k (the merge it quiet straight :) ). But to do, I remove (by accident) all kind of serial support (8250/16550) as well as PDC software console support: this is not quiet to boot ( Well for serial driver I couldn't help more because system is not accessible neither by nic nor by serial console. More over the TOC i can get doesn't give any relevant info :( OTC with only PDC software console support driver the system cras with following dump: Stack Dump: 10078718: 10078718 1fe05600 1fe05000 1007f670 10078708: 1fe00bc0 107d4ba0 1ff16000 f0000174 100786f8: f000017c 10334000 10332000 1023a624 100786e8: 1073ec80 1043ef7c 00000010 1ffb1720 100786d8: 1fe00bc0 1fe00bc4 107d04a8 10078380 100786c8: 0000001a 00000000 00000000 f0000174 100786b8: f000017c f00008c4 f0400004 1010631c 100786a8: ffffffff 00000000 103c11c0 10362010 10078698: 10447810 10377810 10447904 103715ec 10078688: 10375000 1007f670 10078600 00000000 10078678: 00000005 00000010 1043ef7c 101204d8 10078668: 100783c8 10332000 10056568 10447904 10078658: 1073ed7c 10370088 1045bf14 00000000 10078648: 00000000 00000001 100785c8 10378834 10078638: 10454010 10362010 1fe05000 1021356c 10078628: 1ffb1720 00000008 107ab1f0 10447904 10078618: 0005000e 100783c8 10078108 00000101 10078608: 10362010 0005000e 100785c0 55555555 100785f8: 55555555 55555555 55555555 101217f8 100785e8: 55555555 55555555 55555555 55555555 100785d8: 1ffb1720 00000001 00000004 100785c8 100785c8: 104544bc 107ad600 00000004 1047da20 100785b8: 1ffb1720 00000000 00000008 1010a088 100785a8: 100783c8 1007f670 107ab1f0 00000000 10078598: 0002634a 0005000e 100783c8 00000000 10078588: 00000000 0005000e 107ab1f0 00000004 10078578: 0002634a 55555555 10078554 10078554 10078568: 10121f60 1007f670 00000000 55555555 10078558: 10078554 10078554 00000000 00000000 10078548: 0cb30083 0000000f 0002634a 55555555 10078538: 55555555 55555555 55555555 101f3b80 10078528: 101f3b7c 00000000 00000000 00000000 10078518: 00000000 00000000 00000000 00000000 10078508: 00000000 00000000 00000000 55555555 100784f8: 55555555 55555555 55555555 55555555 100784e8: 55555555 55555555 55555555 55555555 100784d8: 55555555 55555555 55555555 55555555 100784c8: 55555555 55555555 55555555 55555555 100784b8: 55555555 55555555 55555555 55555555 100784a8: 55555555 55555555 55555555 55555555 10078498: 55555555 55555555 55555555 55555555 10078488: 55555555 55555555 55555555 55555555 10078478: 55555555 55555555 55555555 55555555 10078468: 55555555 55555555 55555555 55555555 10078458: 55555555 55555555 55555555 55555555 10078448: 55555555 55555555 55555555 55555555 10078438: 55555555 55555555 55555555 55555555 10078428: 55555555 00000000 00000000 00000000 10078418: 0000001f 00000000 0000001f 00000000 10078408: 0000001f 24850e06 04100800 101f4920 100783f8: 10078380 00000005 1045bf14 10360010 100783e8: 1037e8ec 00000000 1007828c 00000002 100783d8: 10110e08 10459f04 00000000 00000000 100783c8: f0000174 f000017c f00008c4 f0400004 100783b8: 00000000 1007828c 00000000 103c11c0 100783a8: 10362010 10447810 1073eb30 00000000 10078398: 00000000 00000000 1045bf14 10370088 10078388: 101f3b78 1037e810 0004ff0f f0400004 10078378: 00000000 ffffffff 00000000 101f3b78 10078368: 10362010 10447810 00002acb 00002ac0 10078358: 10448a94 00002ac0 0000000f 1044b55a 10078348: 1010d308 10000000 0000000f 00000001 10078338: 10370088 1045bf14 10768820 00000001 10078328: 00000002 1073eb30 10447810 10362010 Kernel addresses on the stack: [<10219520>] as_next_request+0x44/0x54 [<10106020>] parisc_terminate+0x60/0xb8 [<1023a624>] scsi_request_fn+0x54/0x2b0 [<1010631c>] handle_interruption+0x2a4/0x5b4 [<101204d8>] schedule+0x1e8/0x428 [<1021356c>] blk_run_queues+0x6c/0x90 [<101217f8>] io_schedule+0x3c/0x68 [<1010a088>] intr_check_sig+0x0/0xc [<101f3b80>] init_dev+0x64/0x4b8 [<103c11c0>] start_kernel+0x4/0x1f8 [<101f3b78>] init_dev+0x5c/0x4b8 [<101f4694>] tty_open+0x90/0x3a8 [<10110db4>] pdc_console_write+0x24/0x3c [<10161118>] chrdev_open+0xb0/0x14c [<10166adc>] may_open+0x58/0x1c8 [<10156584>] dentry_open+0x12c/0x1b8 [<10156450>] filp_open+0x68/0x70 [<101245cc>] printk+0x17c/0x1bc [<101568f4>] sys_open+0x70/0xb8 [<10100428>] init+0x5c/0x144 [<10109c5c>] ret_from_kernel_thread+0x1c/0x24 Kernel Fault: Code=26 regs=10078380 (Addr=00000000) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001111111100001111 Not tainted r00-03 00000000 1037e810 101f3b78 10370088 r04-07 1045bf14 00000000 00000000 00000000 r08-11 1073eb30 10447810 10362010 103c11c0 r12-15 00000000 1007828c 00000000 f0400004 r16-19 f00008c4 f000017c f0000174 00000000 r20-23 00000000 10459f04 10110e08 00000002 r24-27 1007828c 00000000 1037e8ec 10360010 r28-31 1045bf14 00000005 10078380 101f4920 sr0-3 00000000 00000000 00000000 00000000 sr4-7 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: 101f3b7c 101f3b80 IIR: 0cb30083 ISR: 00000000 IOR: 00000000 CPU: 0 CR30: 10078000 CR31: 103b5000 ORIG_R28: 55555555 IAOQ[0]: init_dev+0x60/0x4b8 IAOQ[1]: init_dev+0x64/0x4b8 RP(r2): init_dev+0x5c/0x4b8 (it seems to be the same pb I encounter some time ago with 2.4 but not had time to analyse, sorry) hth, Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From jsoe0708@tiscali.be Mon Aug 11 17:41:31 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Mon, 11 Aug 2003 18:41:31 +0200 Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <20030811152442.GB20405@dsl2.external.hp.com> Message-ID: <3F29178A00002823@ocpmta7.freegates.net> > read model: posix gcc version 3.3.1 20030626 (Debian prerelease) > > >I upgraded to gcc-3.3/unstable and got the same result when attempting >to build glxinfo by hand. well I just distupgrade my box (unstable) this morning, I so relaunched the dpkg-buildpackage ... let you inform tomorrow (sorry I need place so I removed buildtree) Joel PS: I presume that packages are the same palx2000:~# dpkg -l gcc\* libc6\* binutils\* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=======================-=======================-============================================================== ii gcc 3.3-2 The GNU C compiler. ii gcc-3.0 3.0.4-16 The GNU C compiler ii gcc-3.0-base 3.0.4-16 The GNU Compiler Collection (base package) ii gcc-3.2 3.2.3-7 The GNU C compiler ii gcc-3.2-base 3.2.3-7 The GNU Compiler Collection (base package) ii gcc-3.3 3.3.1-1 The GNU C compiler ii gcc-3.3-base 3.3.1-1 The GNU Compiler Collection (base package) ii gcc-3.3-doc 3.3.1-1 Documentation for the GNU compilers (gcc, gobjc, g++) ii gcc-hppa64 3.2.3-0.1 Cross gcc for hppa64 ii gcc-snapshot 20030728-1 A SNAPSHOT of the GNU Compiler Collection. ii libc6 2.3.1-17.0.3 GNU C Library: Shared libraries and Timezone data ii libc6-dev 2.3.1-17.0.3 GNU C Library: Development Libraries and Header Files. ii binutils 2.14.90.0.5-0.2 The GNU assembler, linker and binary utilities ii binutils-dev 2.14.90.0.5-0.2 The GNU binary utilities (BFD development files) palx2000:~# gcc -v Reading specs from /usr/lib/gcc-lib/hppa-linux/3.3.1/specs Configured with: ../src/configure -v --enable-languages=c,c++,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-sjlj-exceptions --enable-clocale=gnu --enable-debug --enable-objc-gc hppa-linux Thread model: posix gcc version 3.3.1 (Debian) ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From dave@hiauly1.hia.nrc.ca Mon Aug 11 18:30:40 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Mon, 11 Aug 2003 13:30:40 -0400 (EDT) Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <20030811152442.GB20405@dsl2.external.hp.com> from "Grant Grundler" at Aug 11, 2003 09:24:42 am Message-ID: <200308111730.h7BHUf9S018795@hiauly1.hia.nrc.ca> > I upgraded to gcc-3.3/unstable and got the same result when attempting > to build glxinfo by hand. It's not clear what's going on. Possibly, linking with libgcc.a is interacting in a bad way with shared libraries linked with libgcc_s.so. You can get more info by adding `-Wl,-v' to the link command. Adding `-Wl,-debug' to the gcc link command will show the full `ld' command. I am certain that the symbols are defined in libgcc_s.so. It may be that the linker isn't looking for dependent libraries correctly. Using the g++ driver or adding `-shared-libgcc' to the link command should work around the problem. But I don't think that it should be necessary. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From grundler@parisc-linux.org Mon Aug 11 20:09:14 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 11 Aug 2003 13:09:14 -0600 Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <200308111730.h7BHUf9S018795@hiauly1.hia.nrc.ca> References: <20030811152442.GB20405@dsl2.external.hp.com> <200308111730.h7BHUf9S018795@hiauly1.hia.nrc.ca> Message-ID: <20030811190914.GA25311@dsl2.external.hp.com> --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Aug 11, 2003 at 01:30:40PM -0400, John David Anglin wrote: > It's not clear what's going on. Possibly, linking with libgcc.a > is interacting in a bad way with shared libraries linked with > libgcc_s.so. You can get more info by adding `-Wl,-v' to the link > command. Adding `-Wl,-debug' to the gcc link command will show > the full `ld' command. -debug output is attached. `-Wl,-v' only shows the "ld" command. The -debug output has that too. What's interesting is the "ld" command has "-lgcc-eh" which is where the missing symbols are defined: grundler <512>nm libgcc_eh.a | grep _Unwind_SjLj_Resume 0000079c T _Unwind_SjLj_Resume 000008d0 T _Unwind_SjLj_Resume_or_Rethrow grundler <513>pwd /usr/lib/gcc-lib/hppa-linux/3.3.1 > I am certain that the symbols are defined in libgcc_s.so. It may > be that the linker isn't looking for dependent libraries correctly. I wonder if "-Wl,-rpath-link,../../exports/lib" is the problem. I'd normally expect an application to use "-L" to specify additional lib search paths. > Using the g++ driver or adding `-shared-libgcc' to the link command > should work around the problem. But I don't think that it should > be necessary. ok thanks, grant --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="glxinfo.debug" grundler@gsyprf11:/usr/src/xfree86-4.2.1/build-tree/xc/programs/glxinfo$ gcc -o glxinfo -g -O -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -lpthread -lm -lgcc_eh -Wl,-rpath-link,../../exports/lib -Wl,-debug Convert string '/usr/lib/gcc-lib/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/:/usr/lib/gcc/hppa-linux/3.3.1/:/usr/lib/gcc/hppa-linux/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/bin/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/bin/' into prefixes, separator = ':' - add prefix: /usr/lib/gcc-lib/hppa-linux/3.3.1/ - add prefix: /usr/lib/gcc-lib/hppa-linux/3.3.1/ - add prefix: /usr/lib/gcc-lib/hppa-linux/ - add prefix: /usr/lib/gcc/hppa-linux/3.3.1/ - add prefix: /usr/lib/gcc/hppa-linux/ - add prefix: /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/bin/hppa-linux/3.3.1/ - add prefix: /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/bin/ Convert string '/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/home/grundler/bin' into prefixes, separator = ':' - add prefix: /usr/local/bin/ - add prefix: /usr/bin/ - add prefix: /bin/ - add prefix: /usr/bin/X11/ - add prefix: /usr/games/ - add prefix: /home/grundler/bin/ Looking for 'real-ld' Looking for 'collect-ld' Looking for 'ld' Looking for 'ld' Looking for 'gnm' Looking for 'gnm' Looking for 'nm' Looking for 'nm' Looking for 'gstrip' Looking for 'gstrip' Looking for 'strip' Looking for 'strip' Looking for 'gcc' Looking for 'gcc' collect2 version 3.3.1 (Debian) (hppa) ld_file_name = /usr/bin/ld c_file_name = /usr/bin/gcc nm_file_name = /usr/bin/nm strip_file_name = /usr/bin/strip c_file = /tmp/ccAA0Eun.c o_file = /tmp/cc0QBMNA.o COLLECT_GCC_OPTIONS = '-o' 'glxinfo' '-g' '-O' '-ansi' '-pedantic' '-Wall' '-Wpointer-arith' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wmissing-declarations' '-Wredundant-decls' '-Wnested-externs' '-Wundef' '-L../../exports/lib' COLLECT_GCC = gcc COMPILER_PATH = /usr/lib/gcc-lib/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/:/usr/lib/gcc/hppa-linux/3.3.1/:/usr/lib/gcc/hppa-linux/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/bin/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/bin/ LIBRARY_PATH = /usr/lib/gcc-lib/hppa-linux/3.3.1/:/usr/lib/gcc/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/lib/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/lib/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../:/lib/hppa-linux/3.3.1/:/lib/:/usr/lib/hppa-linux/3.3.1/:/usr/lib/ /usr/bin/ld --eh-frame-hdr -dynamic-linker /lib/ld.so.1 -o glxinfo /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../crt1.o /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../crti.o /usr/lib/gcc-lib/hppa-linux/3.3.1/crtbegin.o -L../../exports/lib -L/usr/lib/gcc-lib/hppa-linux/3.3.1 -L/usr/lib/gcc-lib/hppa-linux/3.3.1/../../.. glxinfo.o -lGLU -lGL -lXext -lX11 -lpthread -lm -lgcc_eh -rpath-link ../../exports/lib -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/gcc-lib/hppa-linux/3.3.1/crtend.o /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../crtn.o ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Resume@GCC_3.0' ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Register@GCC_3.0' /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_RaiseException@GCC_3.0' ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Unregister@GCC_3.0' /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_Resume_or_Rethrow@GCC_3.3' collect2: ld returned 1 exit status [Leaving /tmp/ccAA0Eun.c] [Leaving /tmp/cc0QBMNA.o] [Leaving /tmp/ccGtmF6N.ld] [Leaving glxinfo] grundler@gsyprf11:/usr/src/xfree86-4.2.1/build-tree/xc/programs/glxinfo$ --mP3DRpeJDSE+ciuQ-- From grundler@parisc-linux.org Mon Aug 11 20:12:52 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 11 Aug 2003 13:12:52 -0600 Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <200308111730.h7BHUf9S018795@hiauly1.hia.nrc.ca> References: <20030811152442.GB20405@dsl2.external.hp.com> <200308111730.h7BHUf9S018795@hiauly1.hia.nrc.ca> Message-ID: <20030811191252.GB25311@dsl2.external.hp.com> On Mon, Aug 11, 2003 at 01:30:40PM -0400, John David Anglin wrote: > Using the g++ driver or adding `-shared-libgcc' to the link command > should work around the problem. I already knew g++ did. I just confirmed adding `-shared-libgcc' did too. thanks, grant From dave@hiauly1.hia.nrc.ca Mon Aug 11 20:25:47 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Mon, 11 Aug 2003 15:25:47 -0400 (EDT) Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <20030811190914.GA25311@dsl2.external.hp.com> from "Grant Grundler" at Aug 11, 2003 01:09:14 pm Message-ID: <200308111925.h7BJPljx020074@hiauly1.hia.nrc.ca> > What's interesting is the "ld" command has "-lgcc-eh" which is where > the missing symbols are defined: > grundler <512>nm libgcc_eh.a | grep _Unwind_SjLj_Resume > 0000079c T _Unwind_SjLj_Resume > 000008d0 T _Unwind_SjLj_Resume_or_Rethrow > grundler <513>pwd > /usr/lib/gcc-lib/hppa-linux/3.3.1 Yes, but libgcc_eh.a doesn't contain the versioned symbols that the shared libraries need. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From carlos@baldric.uwo.ca Mon Aug 11 20:27:23 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Mon, 11 Aug 2003 15:27:23 -0400 Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <20030811190914.GA25311@dsl2.external.hp.com> References: <20030811152442.GB20405@dsl2.external.hp.com> <200308111730.h7BHUf9S018795@hiauly1.hia.nrc.ca> <20030811190914.GA25311@dsl2.external.hp.com> Message-ID: <20030811192723.GF20106@systemhalted> jda, > LIBRARY_PATH = /usr/lib/gcc-lib/hppa-linux/3.3.1/:/usr/lib/gcc/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/lib/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/lib/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../:/lib/hppa-linux/3.3.1/:/lib/:/usr/lib/hppa-linux/3.3.1/:/usr/lib/ > > /usr/bin/ld --eh-frame-hdr -dynamic-linker /lib/ld.so.1 -o glxinfo /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../crt1.o /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../crti.o /usr/lib/gcc-lib/hppa-linux/3.3.1/crtbegin.o -L../../exports/lib -L/usr/lib/gcc-lib/hppa-linux/3.3.1 -L/usr/lib/gcc-lib/hppa-linux/3.3.1/../../.. I'm pretty sure according to our discussion on the proper placement of libgcc_eh that there is a missing "-lgcc_eh" right here (or rather the next one should be _after_ the crtbegin?). See the wrapping -lgcc_eh around -lc and -lgcc glxinfo.o -lGLU -lGL -lXext -lX11 -lpthread -lm -lgcc_eh -rpath-link ../../exports/lib -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/gcc-lib/hppa-linux/3.3.1/crtend.o /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../crtn.o > ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Resume@GCC_3.0' > ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Register@GCC_3.0' > /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_RaiseException@GCC_3.0' > ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Unregister@GCC_3.0' > /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_Resume_or_Rethrow@GCC_3.3' > collect2: ld returned 1 exit status > [Leaving /tmp/ccAA0Eun.c] > [Leaving /tmp/cc0QBMNA.o] > [Leaving /tmp/ccGtmF6N.ld] > [Leaving glxinfo] > grundler@gsyprf11:/usr/src/xfree86-4.2.1/build-tree/xc/programs/glxinfo$ This is an issue we've seen in the detection of unwind info from autoconf. Glibc has a patch to hack around a proper detection by placing the appropirate -lgcc_eh in the front. c. From carlos@baldric.uwo.ca Mon Aug 11 21:21:03 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Mon, 11 Aug 2003 16:21:03 -0400 Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <200308111925.h7BJPljx020074@hiauly1.hia.nrc.ca> References: <20030811190914.GA25311@dsl2.external.hp.com> <200308111925.h7BJPljx020074@hiauly1.hia.nrc.ca> Message-ID: <20030811202103.GH20106@systemhalted> On Mon, Aug 11, 2003 at 03:25:47PM -0400, John David Anglin wrote: > > What's interesting is the "ld" command has "-lgcc-eh" which is where > > the missing symbols are defined: > > grundler <512>nm libgcc_eh.a | grep _Unwind_SjLj_Resume > > 0000079c T _Unwind_SjLj_Resume > > 000008d0 T _Unwind_SjLj_Resume_or_Rethrow > > grundler <513>pwd > > /usr/lib/gcc-lib/hppa-linux/3.3.1 > > Yes, but libgcc_eh.a doesn't contain the versioned symbols that the shared > libraries need. Are we not using libgcc_eh to resolve such symbols in libgcc and libc? c. From dave@hiauly1.hia.nrc.ca Mon Aug 11 21:38:06 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Mon, 11 Aug 2003 16:38:06 -0400 (EDT) Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <20030811043457.GA5653@dsl2.external.hp.com> from "Grant Grundler" at Aug 10, 2003 10:34:57 pm Message-ID: <200308112038.h7BKc61c020812@hiauly1.hia.nrc.ca> > The basic problem is glxinfo (C program) links against libGLU.so > (C++ built library). But glxinfo fails to link using gcc: > ... > gcc -o glxinfo -g -O -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -lpthread -lm -Wl,-rpath-link,../../exports/lib > ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Resume@GCC_3.0' > ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Register@GCC_3.0' > /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_RaiseException@GCC_3.0' > ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Unregister@GCC_3.0' > /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_Resume_or_Rethrow@GCC_3.3' > collect2: ld returned 1 exit status > ... Ok, here is what is happening. First, I gave you the wrong advice on the option to get verbose info from ld. I gave you the hpux option. The GNU option is `--verbose' or `-Wl,--verbose' when using the gcc driver. Here is the linker path on gsyprf11: SEARCH_DIR("/usr/hppa-linux/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); Here is where ld found libgcc_s.so.1: found libgcc_s.so.1 at /usr/local/lib/libgcc_s.so.1 The version of libgcc_s.so.1 in /usr/local/lib is old and appears to have been built using dwarf2 exception support. Probably, the version of GCC installed in /usr/local should be removed. I believe it was the initial port with support for Ada. However, this is now part of the regular debian distro. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From dave@hiauly1.hia.nrc.ca Mon Aug 11 21:41:39 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Mon, 11 Aug 2003 16:41:39 -0400 (EDT) Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <20030811202103.GH20106@systemhalted> from "Carlos O'Donell" at Aug 11, 2003 04:21:03 pm Message-ID: <200308112041.h7BKfemX020838@hiauly1.hia.nrc.ca> > On Mon, Aug 11, 2003 at 03:25:47PM -0400, John David Anglin wrote: > > > What's interesting is the "ld" command has "-lgcc-eh" which is where > > > the missing symbols are defined: > > > grundler <512>nm libgcc_eh.a | grep _Unwind_SjLj_Resume > > > 0000079c T _Unwind_SjLj_Resume > > > 000008d0 T _Unwind_SjLj_Resume_or_Rethrow > > > grundler <513>pwd > > > /usr/lib/gcc-lib/hppa-linux/3.3.1 > > > > Yes, but libgcc_eh.a doesn't contain the versioned symbols that the shared > > libraries need. > > Are we not using libgcc_eh to resolve such symbols in libgcc and libc? Not for versioned symbols. For that, you need to link with libgcc_s.so (i.e., the shared version of libgcc). The g++ driver does this automatically. You can also add `-shared-libcc' to your link command when using the gcc driver. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From dave@hiauly1.hia.nrc.ca Mon Aug 11 21:55:34 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Mon, 11 Aug 2003 16:55:34 -0400 (EDT) Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <200308112038.h7BKc61c020812@hiauly1.hia.nrc.ca> from "John David Anglin" at Aug 11, 2003 04:38:06 pm Message-ID: <200308112055.h7BKtZxr020907@hiauly1.hia.nrc.ca> > Ok, here is what is happening. > > First, I gave you the wrong advice on the option to get verbose info from ld. > I gave you the hpux option. The GNU option is `--verbose' or `-Wl,--verbose' > when using the gcc driver. > > Here is the linker path on gsyprf11: > > SEARCH_DIR("/usr/hppa-linux/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); One further note: The default search path used by ldd doesn't agree with the default path used by ld. So, I think binutils and glibc need to get together on this. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From grundler@parisc-linux.org Mon Aug 11 23:39:55 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 11 Aug 2003 16:39:55 -0600 Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <200308112038.h7BKc61c020812@hiauly1.hia.nrc.ca> References: <20030811043457.GA5653@dsl2.external.hp.com> <200308112038.h7BKc61c020812@hiauly1.hia.nrc.ca> Message-ID: <20030811223955.GC25311@dsl2.external.hp.com> On Mon, Aug 11, 2003 at 04:38:06PM -0400, John David Anglin wrote: > First, I gave you the wrong advice on the option to get verbose info from ld. > I gave you the hpux option. The GNU option is `--verbose' or `-Wl,--verbose' > when using the gcc driver. ok. -debug was good. > Here is the linker path on gsyprf11: > > SEARCH_DIR("/usr/hppa-linux/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); > > Here is where ld found libgcc_s.so.1: > found libgcc_s.so.1 at /usr/local/lib/libgcc_s.so.1 ugh. `dpkg -S /usr/local/lib' comes up empty. I've deleted everything older than a few days (python/texmf remain). My expectation is hppa64-linux-* tool chain is self contained in /opt/palinux and can go away when someone points me at a hppa64 .deb. > The version of libgcc_s.so.1 in /usr/local/lib is old and appears to have > been built using dwarf2 exception support. > > Probably, the version of GCC installed in /usr/local should be removed. > I believe it was the initial port with support for Ada. However, this > is now part of the regular debian distro. deleted. Apologies for the goose chase. But this is probably an excellent example for versioned symbols. glxinfo would have broken in other weird ways at run time and would have been even harder to track down. Now I can go back and rebuild xfree86 again... thanks, grant From dave@hiauly1.hia.nrc.ca Mon Aug 11 23:58:53 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Mon, 11 Aug 2003 18:58:53 -0400 (EDT) Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <20030811223955.GC25311@dsl2.external.hp.com> from "Grant Grundler" at Aug 11, 2003 04:39:55 pm Message-ID: <200308112258.h7BMwrcv021410@hiauly1.hia.nrc.ca> > > when using the gcc driver. > > ok. -debug was good. This shows what collect2 is doing. It is useful to see the exact way in which gcc is running ld. -Wl,--verbose shows what ld is doing. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From dave@hiauly1.hia.nrc.ca Tue Aug 12 00:55:43 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Mon, 11 Aug 2003 19:55:43 -0400 (EDT) Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <200308112038.h7BKc61c020812@hiauly1.hia.nrc.ca> from "John David Anglin" at Aug 11, 2003 04:38:06 pm Message-ID: <200308112355.h7BNthRu021653@hiauly1.hia.nrc.ca> > Here is the linker path on gsyprf11: > > SEARCH_DIR("/usr/hppa-linux/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); This search path seems somewhat strange. It appears debian used the `--with-lib-path=dir1:dir2... set default LIB_PATH' configure option in building binutils. I believe that the default binutils order would be "/usr/local/lib", "/lib" and then "/usr/lib". On the otherhand, ld.so has the default order "/usr/lib", then "/lib". Don't know why the search order for the system directories in glibc is opposite to binutils. On gsyprf11, /etc/ld.so.conf contains: /usr/X11R6/lib /usr/lib/postfix So, the dynamic loader will use the following path as the default search: /usr/X11R6/lib:/usr/lib/postfix:/usr/lib:/lib The dynamic loader doesn't search /usr/local/lib and it has a different search order than ld. Because /usr/local/lib is normally searched before the system library directories, you have to be careful what you put there. It would be nice if the linker and dynamic linker were consistent :) Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From Randolph Chung Tue Aug 12 04:42:44 2003 From: Randolph Chung (Randolph Chung) Date: Mon, 11 Aug 2003 20:42:44 -0700 Subject: [parisc-linux] removing warnings from math-emu code Message-ID: <20030812034244.GC21328@tausq.org> Would anyone mind if i committed this to cvs? (2.6 only) It removes/hides all the warnings from the math-emu directory, since we don't plan to fix them... Index: arch/parisc/math-emu/Makefile =================================================================== RCS file: /var/cvs/linux-2.6/arch/parisc/math-emu/Makefile,v retrieving revision 1.1 diff -u -p -r1.1 Makefile --- arch/parisc/math-emu/Makefile 29 Jul 2003 17:00:42 -0000 1.1 +++ arch/parisc/math-emu/Makefile 12 Aug 2003 03:38:58 -0000 @@ -2,6 +2,11 @@ # Makefile for the linux/parisc floating point code # +# See arch/parisc/math-emu/README +CFLAGS += -Wno-parentheses -Wno-implicit-function-declaration \ + -Wno-uninitialized -Wno-strict-prototypes -Wno-return-type \ + -Wno-implicit-int + obj-y := frnd.o driver.o decode_exc.o fpudispatch.o denormal.o \ dfmpy.o sfmpy.o sfsqrt.o dfsqrt.o dfadd.o fmpyfadd.o \ sfadd.o dfsub.o sfsub.o fcnvfxt.o fcnvff.o fcnvxf.o \ Index: arch/parisc/math-emu/types.h =================================================================== RCS file: /var/cvs/linux-2.6/arch/parisc/math-emu/types.h,v retrieving revision 1.1 diff -u -p -r1.1 types.h --- arch/parisc/math-emu/types.h 29 Jul 2003 17:00:42 -0000 1.1 +++ arch/parisc/math-emu/types.h 12 Aug 2003 03:38:58 -0000 @@ -20,6 +20,7 @@ */ #include +#undef BUG #define BUG() do { \ printk(KERN_ERR "floating-pt emulation BUG at %s:%d!\n", __FILE__, __LINE__); \ } while (0) thanks, randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From carlos@baldric.uwo.ca Tue Aug 12 04:58:11 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Mon, 11 Aug 2003 23:58:11 -0400 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <20030725114615.GI1485@parcelfarce.linux.theplanet.co.uk> References: <20030725070449.GB13017@systemhalted> <20030725114615.GI1485@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030812035810.GB9325@systemhalted> On Fri, Jul 25, 2003 at 12:46:15PM +0100, Matthew Wilcox wrote: > can't do that. we have three sets of routines -- itlb_miss_common_11, > itlb_miss_common_20 and itlb_miss_common_20w. we select between _20w > or not at compile time (if it's 64-bit, it's PA 2.0 Wide), but select > between _20 and _11 at boot time (fault_vector_20 vs fault_vector_11). > > shame on you, you didn't even try assembling it ;-) Assembles, and boots on my C3K, 32-bit kernel. Looking for any takers who want to try it in 64-bit mode. I'm running lmbench to see if I can tell the difference between this and the original code. I would be most appreciative if anyone would pipe up and say "Run X to test if Y works better/faster/harder" :} c. --- arch/parisc/kernel/entry.S 9 Dec 2002 06:09:08 -0000 1.98 +++ arch/parisc/kernel/entry.S 12 Aug 2003 03:49:04 -0000 @@ -1469,8 +1469,7 @@ itlb_miss_20w: mfctl %cr25,ptp /* load user pgd */ mfsp %sr7,t0 /* Get current space */ - or,*= %r0,t0,%r0 /* If kernel, nullify following test */ - cmpb,*<>,n t0,spc,itlb_fault /* forward */ + cmpb,<>,n t0,spc,itlb_user_fault_20w /* forward */ /* First level page table lookup */ @@ -1535,8 +1534,7 @@ itlb_miss_11: mfctl %cr25,ptp /* load user pgd */ mfsp %sr7,t0 /* Get current space */ - or,= %r0,t0,%r0 /* If kernel, nullify following test */ - cmpb,<>,n t0,spc,itlb_fault /* forward */ + cmpb,<>,n t0,spc,itlb_user_fault_11 /* forward */ /* First level page table lookup */ @@ -1551,6 +1549,10 @@ itlb_miss_common_11: sh2addl t0,ptp,ptp ldi _PAGE_ACCESSED,t1 ldw 0(ptp),pte + + /* Running parallel, taken from below 'zdep0' */ + zdep spc,30,15,prot /* create prot id from space */ + bb,>=,n pte,_PAGE_PRESENT_BIT,itlb_fault /* Check whether the "accessed" bit was set, otherwise do so */ @@ -1559,7 +1561,7 @@ itlb_miss_common_11: and,<> t1,pte,%r0 /* test and nullify if already set */ stw t0,0(ptp) /* write back pte */ - zdep spc,30,15,prot /* create prot id from space */ + /* zdep0 moved back */ dep pte,8,7,prot /* add in prot bits from pte */ extru,= pte,_PAGE_NO_CACHE_BIT,1,r0 @@ -1602,8 +1604,7 @@ itlb_miss_20: mfctl %cr25,ptp /* load user pgd */ mfsp %sr7,t0 /* Get current space */ - or,= %r0,t0,%r0 /* If kernel, nullify following test */ - cmpb,<>,n t0,spc,itlb_fault /* forward */ + cmpb,<>,n t0,spc,itlb_user_fault_20 /* forward */ /* First level page table lookup */ @@ -1882,6 +1883,37 @@ kernel_bad_space: dbit_fault: b intr_save ldi 20,%r8 + +/* The following three labels relate to an optimization in the itlb handler. + itlb_user_fault_20w: + itlb_user_fault_20: + itlb_user_fault_11: + We keep the CPU jumping fwd/bkwd in the common case, and the uncommon case + has the cmpb fail (no jump) and thus branch prediction failing. */ + +#ifdef __LP64__ +itlb_user_fault_20w: + /* User tlb missed for other than his own space. Optimization. */ + cmpb,= %r0,t0,itlb_miss_common_20w /* backward */ + nop +#else +itlb_user_fault_20: + /* User tlb missed for other than his own space. Optimization. */ + cmpb,= %r0,t0,itlb_miss_common_20 /* backward */ + nop + +/* FALL THROUGH - We don't care if we run the test twice. If someone + asks to have the "user is faulting death" path optimal + then they should seek help. */ + +itlb_user_fault_11: + /* User tlb missed for other than his own space. Optimization. */ + cmpb,= %r0,t0,itlb_miss_common_11 /* backward */ + nop +#endif + +/* FALL THROUGH - We have a real itlb_fault from one of the above three + label sequences */ itlb_fault: b intr_save From carlos@baldric.uwo.ca Tue Aug 12 04:59:29 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Mon, 11 Aug 2003 23:59:29 -0400 Subject: [parisc-linux] [PATCH] dlfcn/default fixes for hppa Message-ID: <20030812035929.GC9325@systemhalted> libc-alpha, The hppa backend in gcc uses type information to determine if the variable we manipulate is a function descriptor, and thus, on comparisons, make calls behind the scenes to canonicalize that descriptor. When variables are cast to 'void *' all the type information is lost. I've included a patch to the dlfcn/default test that changes some of the casts in the test such as to retain the type information. What I've done is to cast 'p' to a function pointer of type "(int (*)(int, char **))" rather than casting 'main' to an opaque pointer of type "(void *)". Second to that I've modified test_in_mod[12] to take a variable of type "(int (*)(int, char **))" (the address of the calling main) rather than "(void *)", and carry out the appropriate casting. This is the only method to do the required casts, and I am open to comments. Passes tests without regression on i386, and removes the dlfcn/default failure from hppa. Cheers, Carlos. --- libc/dlfcn/default.c | 6 +++--- libc/dlfcn/defaultmod1.c | 6 +++--- libc/dlfcn/defaultmod2.c | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-) --- 2003-08-11 Carlos O'Donell * dlfcn/default.c (main): Cast dlsym loaded value to same type as main. Address passed to test_in_mod1 and test_in_mod2 without casting. * dlfcn/defaultmod1.c: Change prototype of test_in_mod1. (test_in_mod1): Cast dlsym loaded value to same type as mainp. * dlfcn/defaultmod2.c: Change prototype of test_in_mod2. (test_in_mod2): Cast dlsym loaded value to same type as mainp. diff -u -p -r1.2 default.c --- libc/dlfcn/default.c 16 Nov 2000 02:12:46 -0000 1.2 +++ libc/dlfcn/default.c 29 Jul 2003 16:11:34 -0000 @@ -36,7 +36,7 @@ main (int argc, char *argv[]) printf ("%s: main not found\n", __FILE__); result = 1; } - else if (p != (void *) &main) + else if ((int (*)(int, char **))p != main) { printf ("%s: wrong address returned for main\n", __FILE__); result = 1; @@ -72,9 +72,9 @@ main (int argc, char *argv[]) else printf ("%s: found_in_mod2 correctly found\n", __FILE__); - result |= test_in_mod1 ((void *) &main); + result |= test_in_mod1 (main); - result |= test_in_mod2 ((void *) &main); + result |= test_in_mod2 (main); return result; } diff -u -p -r1.2 defaultmod1.c --- libc/dlfcn/defaultmod1.c 29 Nov 2000 00:03:27 -0000 1.2 +++ libc/dlfcn/defaultmod1.c 29 Jul 2003 16:11:34 -0000 @@ -9,9 +9,9 @@ found_in_mod1 (void) } -extern int test_in_mod1 (void *mainp); +extern int test_in_mod1 (int (*mainp)(int, char **)); int -test_in_mod1 (void *mainp) +test_in_mod1 (int (*mainp)(int, char **)) { int (*ifp) (void); void *p; @@ -24,7 +24,7 @@ test_in_mod1 (void *mainp) printf ("%s: main not found\n", __FILE__); result = 1; } - else if (p != mainp) + else if ((int (*)(int, char **))p != mainp) { printf ("%s: wrong address returned for main\n", __FILE__); result = 1; diff -u -p -r1.2 defaultmod2.c --- libc/dlfcn/defaultmod2.c 29 Nov 2000 00:03:27 -0000 1.2 +++ libc/dlfcn/defaultmod2.c 29 Jul 2003 16:11:34 -0000 @@ -16,9 +16,9 @@ found_in_mod2 (void) } -extern int test_in_mod2 (void *mainp); +extern int test_in_mod2 (int (*mainp)(int, char **)); int -test_in_mod2 (void *mainp) +test_in_mod2 (int (*mainp)(int, char **)) { int (*ifp) (void); void *p; @@ -31,7 +31,7 @@ test_in_mod2 (void *mainp) printf ("%s: main not found\n", __FILE__); result = 1; } - else if (p != mainp) + else if ((int (*)(int, char **))p != mainp) { printf ("%s: wrong address returned for main\n", __FILE__); result = 1; From Randolph Chung Tue Aug 12 07:02:44 2003 From: Randolph Chung (Randolph Chung) Date: Mon, 11 Aug 2003 23:02:44 -0700 Subject: [parisc-linux] how to handle ERESTART_RESTARTBLOCK ? Message-ID: <20030812060244.GE21328@tausq.org> I commited some broken code into 2.6 cvs just now, so now i need some help to fix it ;-) sorry for the verbose explanation below, but i need to write this down to make sure i understand it myself :-) Our signal handling code was not handling ERESTART_RESTARTBLOCK correctly. as far as I can tell, the semantics of this is that if a syscall function returns with that error code, we are supposed to restart the syscall, but with a new syscall number (__NR_restart_syscall -- which we don't define at the moment) The problem is that our syscall mechanism doesn't really allow this (afaict). Our syscall sequence looks like this: ble
ldi , %r20 [ we enter the kernel at this point ] and the way we handle restarting other syscalls is to set the iaoq back by two insns, so we do the ble again. there's a comment about this in the code (signal.c) /* Hooray for delayed branching. We don't have to restore %r20 (the system call number) because it gets loaded in the delay slot of the branch external instruction. */ regs->gr[31] -= 8; which is all well and good, except i don't see how we can change the syscall number to restart it for the ERESTART_RESTARTBLOCK case. why is it bad to just call sys_restart_syscall directly from do_signal()? any suggestions on how to handle this properly? thanks randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From jsoe0708@tiscali.be Tue Aug 12 13:21:18 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 12 Aug 2003 14:21:18 +0200 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <20030812035810.GB9325@systemhalted> Message-ID: <3F29178A00002C09@ocpmta7.freegates.net> Hi Carlos, >Assembles, and boots on my C3K, 32-bit kernel. Looking for any takers >who want to try it in 64-bit mode. I'm running lmbench to see if I can >tell the difference between this and the original code. > >I would be most appreciative if anyone would pipe up and say "Run X to >test if Y works better/faster/harder" :} I apply your patch against 2.4.21-pa9 on the N-4000 and compile it successfully with hppa64-linux-gcc (3.2.3). (having no clue about lmbench) I take this exercise to roughly compare. Running the original 2.4.21-pa9 here are times: Tue Aug 12 09:59:55 CEST 2003 [...] # Build kernel: 19'58" Tue Aug 12 10:19:53 CEST 2003 [...] # Build modules: 7'46" Tue Aug 12 10:27:39 CEST 2003 Running this new kernel: Tue Aug 12 12:28:37 CEST 2003 [...] # Build kernel: 20'8" Tue Aug 12 12:48:45 CEST 2003 [...] # Build modules: 7'47" Tue Aug 12 12:56:32 CEST 2003 The difference are so small that a more accurate tools would be requested. hth anyway, Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From carlos@baldric.uwo.ca Tue Aug 12 15:40:12 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Tue, 12 Aug 2003 10:40:12 -0400 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <3F29178A00002C09@ocpmta7.freegates.net> References: <20030812035810.GB9325@systemhalted> <3F29178A00002C09@ocpmta7.freegates.net> Message-ID: <20030812144012.GE9325@systemhalted> > I apply your patch against 2.4.21-pa9 on the N-4000 and compile it successfully > with hppa64-linux-gcc (3.2.3). (having no clue about lmbench) I take this > exercise to roughly compare. > > Running the original 2.4.21-pa9 here are times: > Tue Aug 12 09:59:55 CEST 2003 > [...] # Build kernel: 19'58" > Tue Aug 12 10:19:53 CEST 2003 > [...] # Build modules: 7'46" > Tue Aug 12 10:27:39 CEST 2003 > > Running this new kernel: > > Tue Aug 12 12:28:37 CEST 2003 > [...] # Build kernel: 20'8" > Tue Aug 12 12:48:45 CEST 2003 > [...] # Build modules: 7'47" > Tue Aug 12 12:56:32 CEST 2003 > > The difference are so small that a more accurate tools would be requested. Thanks Joel! Yeah, I figured that perhaps the change might get lost in the noise... I'm still running lmbench multiple times to get good numbers. Thanks again! c. From grundler@parisc-linux.org Tue Aug 12 16:14:28 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Tue, 12 Aug 2003 09:14:28 -0600 Subject: [parisc-linux] removing warnings from math-emu code In-Reply-To: <20030812034244.GC21328@tausq.org> References: <20030812034244.GC21328@tausq.org> Message-ID: <20030812151428.GC20514@dsl2.external.hp.com> On Mon, Aug 11, 2003 at 08:42:44PM -0700, Randolph Chung wrote: > Would anyone mind if i committed this to cvs? (2.6 only) It > removes/hides all the warnings from the math-emu directory, since we > don't plan to fix them... I'm pretty sure Paul Bame said it was ok to fix them at this point. He didn't expect any major changes to our FP EMU support or the HPUX FP emulation it was derived from. grant From jsoe0708@tiscali.be Tue Aug 12 16:54:16 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 12 Aug 2003 17:54:16 +0200 Subject: [parisc-linux] removing warnings from math-emu code In-Reply-To: <20030812151428.GC20514@dsl2.external.hp.com> Message-ID: <3F29178A00002D79@ocpmta7.freegates.net> >I'm pretty sure Paul Bame said it was ok to fix them at this point. >He didn't expect any major changes to our FP EMU support or >the HPUX FP emulation it was derived from. Ha a long time ago I suggest a draft patch (iirc forget because too difficult to manage versus HPUX). If someone else is interested in I can try to find it back? Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From jsoe0708@tiscali.be Tue Aug 12 16:54:16 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 12 Aug 2003 17:54:16 +0200 Subject: [parisc-linux] removing warnings from math-emu code In-Reply-To: <20030812151428.GC20514@dsl2.external.hp.com> Message-ID: <3F29178A00002D7A@ocpmta7.freegates.net> >I'm pretty sure Paul Bame said it was ok to fix them at this point. >He didn't expect any major changes to our FP EMU support or >the HPUX FP emulation it was derived from. Ha a long time ago I suggest a draft patch (iirc forget because too difficult to manage versus HPUX). If someone else is interested in I can try to find it back? Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From grundler@parisc-linux.org Tue Aug 12 17:06:12 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Tue, 12 Aug 2003 10:06:12 -0600 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <20030812035810.GB9325@systemhalted> References: <20030725070449.GB13017@systemhalted> <20030725114615.GI1485@parcelfarce.linux.theplanet.co.uk> <20030812035810.GB9325@systemhalted> Message-ID: <20030812160612.GF20514@dsl2.external.hp.com> On Mon, Aug 11, 2003 at 11:58:11PM -0400, Carlos O'Donell wrote: > I would be most appreciative if anyone would pipe up and say "Run X to > test if Y works better/faster/harder" :} osdl-aim-7 benchmark probably stresses both itlb and dtlb. (available from osdl.org - URL is in linux-ia64 archive) SDET is another candidate. Note that itlb misses is a function of accesses to lots of "random" pages in memory and having enough memory so the odds of hitting the same page often is low. ie run thousands of jobs and the scheduler thrash the itlb. at least that's how I understand it. grant From willy@debian.org Tue Aug 12 17:32:28 2003 From: willy@debian.org (Matthew Wilcox) Date: Tue, 12 Aug 2003 17:32:28 +0100 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <20030812160612.GF20514@dsl2.external.hp.com> References: <20030725070449.GB13017@systemhalted> <20030725114615.GI1485@parcelfarce.linux.theplanet.co.uk> <20030812035810.GB9325@systemhalted> <20030812160612.GF20514@dsl2.external.hp.com> Message-ID: <20030812163228.GB10015@parcelfarce.linux.theplanet.co.uk> On Tue, Aug 12, 2003 at 10:06:12AM -0600, Grant Grundler wrote: > Note that itlb misses is a function of accesses to lots of "random" > pages in memory and having enough memory so the odds of hitting > the same page often is low. ie run thousands of jobs and the > scheduler thrash the itlb. > > at least that's how I understand it. since we're still using 4k page size, and we have typically 160 TLB entries, that only covers 640k of our 1.5MB cache ... -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From jsoe0708@tiscali.be Tue Aug 12 18:06:44 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 12 Aug 2003 19:06:44 +0200 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <20030812160612.GF20514@dsl2.external.hp.com> Message-ID: <3F29178A00002DBE@ocpmta7.freegates.net> > >osdl-aim-7 benchmark probably stresses both itlb and dtlb. >(available from osdl.org - URL is in linux-ia64 archive) Ok I finaly find it as re-aim-7 sf.net project. Just launch (alltest) with kernel-64bits+ C.patch . I will let run for the night and relaunch it with tommorrow morning with original kernel-64bits. Thanks, Joel ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From bame@hp.com Tue Aug 12 20:23:29 2003 From: bame@hp.com (bame@hp.com) Date: Tue, 12 Aug 2003 13:23:29 -0600 Subject: [parisc-linux] 2.5 -> 2.6 tree switch tomorrow In-Reply-To: Message from Matthew Wilcox of "Sat, 09 Aug 2003 17:39:31 BST." <20030809163931.GD3169@parcelfarce.linux.theplanet.co.uk> References: <20030806184826.GA11934@ldl.fc.hp.com> <20030807171149.B2A7A7306A@fc.hp.com> <20030809163931.GD3169@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030812192330.346AF73122@fc.hp.com> > OK. Some files were missing from the initial import, so I added them. > > However, I can't get a linus branch out of it: Yeah I forgot to lay that down. FYI it's not a branch now -- just a normal tag which is moved to the latest import. > I suspect this will hinder using cvs-import to add 2.6.0-test3. Imported and merged. -P From linyu921@sina.com Wed Aug 13 03:16:19 2003 From: linyu921@sina.com (=?GB2312?B?zqrE+r2oo6jW0NOizsSjqcbz0rXN+NW+?=) Date: Wed, 13 Aug 2003 10:16:19 +0800 Subject: [parisc-linux] =?GB2312?B?zqrE+r2oo6jW0NOizsSjqcbz0rXN+NW+IQ==?= Message-ID: <20030813021408.D82144896@dsl2.external.hp.com> ΪÄú½¨£¨ÖÐÓ¢ÎÄ£©ÆóÒµÍøÕ¾ ------------------------ ¡ø¸ù¾ÝÄúµÄÒªÇó¸öÐÔ»¯Éè¼Æ£¬¾ø²»Ì×ÓÃÄ£°æ¡£ ¡ø ÍøÕ¾ÎÞÏÞÀ©Õ¹¼Ü¹¹£¬ÊÊÓ¦ÄúÆóÒµÎÞÏÞ·¢Õ¹µÄÒªÇó¡£ ¡ø ¾ßÓкǫ́¹ÜÀí¹¦ÄÜ£¬ÍøÕ¾½¨³Éºó£¬½»ÓÉÄú×Ô¼º¸üйÜÀí¡£ ----------------------------- ¡ô±¾¹«Ë¾ÎªÄúËù½¨µÄÍøÕ¾¾ßÓÐÒÔϹ¦ÄÜ£º 1.²úƷչʾ-ÍøÉÏչʾÄúµÄ²úÆ·£¬Í¼ÎIJ¢Ã¯£¬¶à¼¶·ÖÀ࣬ºǫ́¹ÜÀí¡£ 2.ÍøÉÏÉ̵ê-¿Í»§¿ÉÖ±½ÓÔÚÍøÉÏÑ¡¹ºÄúµÄ²úÆ·£¬¾ÍÏñÔÚÉ̵êÀïÒ»Ñù¡£ 3.²úÆ·ËÑË÷-¿Í»§¿Éͨ¹ý²úÆ·Ãû³Æ¡¢Àà±ð¡¢¹Ø¼ü´ÊµÈ²éÕÒÄúµÄ²úÆ·¡£ 4.¿Í»§¹ÜÀí-¶Ô²»Í¬¿Í»§»ò»áÔ±£¬¿É½øÐзּ¶¡¢·ÖȨÏÞ¡¢·ÖÀà¹ÜÀí¡£ 5.²úÆ·¶¨¹º-¿Í»§¿ÉÖ±½ÓÔÚÍøÉÏ϶©µ¥£¬¶¨¹ºÄúµÄ²úÆ·¡£ 6.¿Í»§ÁôÑÔ-¿Í»§¿ÉÖ±½ÓÔÚÍøÉϸøÄúÁôÑÔ£¬ÏòÄú·´À¡Òâ¼û¡£ 7.ÐÂÎÅ·¢²¼-Äú¿ÉÔÚÍøÉÏÖ±½Ó·¢²¼¹«Ë¾µÄÐÂÎÅ¡¢Í¨Öª¡¢´ÙÏúÐÅÏ¢µÈ¡£ 8.»áÔ±ÉçÇø-¿É×÷ΪÍⲿ½»Á÷ÂÛ̳£¬Ò²¿É×÷Ϊ¹«Ë¾ÄÚ²¿Ô±¹¤¹µÍ¨Æ½Ì¨¡£ 9.ÍøÉϵ÷²é-¿ÉÒÔÉ趨ÈκÎÎÊÌ⣬Ïò¿Í»§»ò»áÔ±Á˽âÄúÏëÁ˽âµÄÊÂÇé¡£ 10.ÓʼþÁбí-¿ÉÒÔÊÕ¼¯¿Í»§µç×ÓÓÊÏäµÈ×ÊÁÏ£¬¶¨ÆÚÏò¿Í»§·¢ËÍÐÅÏ¢¡£ 11.ÍøÉϺؿ¨-ÖØÒª½ÚÈÕ£¬Ïò¿Í»§·¢Ë;«ÃÀºØ¿¨£¬ÔöÇ¿Óë¿Í»§µÄ¸ÐÇé¡£ 12.ÆóÒµÓʾÖ-ÓëÄúÍøվͬÓòÃûµÄÆóÒµÓʾ֣¬Ìá¸ßÄúÆóÒµµÄ¶ÔÍâÐÎÏó¡£ 13.ºǫ́¹ÜÀí-ËùÓÐÒÔÉϹ¦ÄÜ£¬¿ÉÓÉÄú×Ô¼º¿ØÖƹÜÀí£¬²»ÐèרҵÈËÔ±¡£ ¡ôÄúÒ²¿ÉÒÔ´ÓÏÂÃæ5ÖÖÀàÐÍÖУ¬ÌôÑ¡Ò»ÖÖÊʺÏÄú¹«Ë¾µÄÍøÕ¾? ----------------------------- ¡ø(Ò») ¾­¼ÃÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®100Õ×Ö÷»ú¿Õ¼ä£» 3£®ÍøÕ¾ÕûÌåÉè¼Æ£» 4£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 5£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 6£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 7£®5¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®5¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 9£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 10£®Gif°´Å¥¡¢ÐüÍ£°´Å¥£» 11£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 12£®BannerÉè¼ÆÖÆ×÷£¨Gif£© 13£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 14£®»¶Ó­Ò³·ÃÎÊÕß¼ÆÊýÆ÷1Ì×£» 15£®Óõç×ÓÓÊÏä½ÓÊÕ¿Í»§ÁôÑÔ; 16£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 17£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾2Ò³´Î¡£ -------------------------- ¡ø(¶þ) ±ê×¼ÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®120Õ×Ö÷»ú¿Õ¼ä£» 3£®1¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 8£®10¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 9£®10¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 10£®Gif°´Å¥¡¢ÐüÍ£°´Å¥£» 11£®Flash¶¯»­1·ù£» 12£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 13£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 14£®Êó±êÌØЧ1´¦ 15£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 16£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 17£®»¶Ó­Ò³·ÃÎÊÕß¼ÆÊýÆ÷1Ì×£» 18£®Óõç×ÓÓÊÏä½ÓÊÕ¿Í»§ÁôÑÔ£» 19£®ÌØЧͼƬÖÐÓ¢ÎĹ²2·ù£» 20£®¹ö¶¯×ÖÄ»¹«¸æÖÐÓ¢ÎĹ²2·ù£» 21£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 22£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾4Ò³´Î£» --------------------------- ¡ø(Èý) ÉÌÎñÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®150Õ×Ö÷»ú¿Õ¼ä£» 3£®5¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®20¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®20¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­2·ù£» 13£®ÊÓƵ¶¯»­1·ù£» 14£®Êó±êÌØЧ1´¦ 15£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 16£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 17£®¶¯Ì¬¹ã¸æºá·ù1·ù£» 18£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 19£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 20£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§¶©µ¥£» 21£®ÌØЧͼƬÖÐÓ¢ÎĹ²4·ù£» 22£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²2·ù£» 23£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²4·ù£» 24£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 25£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾8Ò³´Î£» 26£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ1ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ1Ìס£ --------------------------- ¡ø(ËÄ) ºÀ»ªÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®200Õ×Ö÷»ú¿Õ¼ä£» 3£®10¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®40¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®40¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­4·ù£» 13£®ÊÓƵ¶¯»­2·ù£» 14£®Êó±êÌØЧ1´¦£» 15£®ÍøÒ³ÒôÀÖ1´¦£» 16£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 17£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 18£®¶¯Ì¬¹ã¸æºá·ù2·ù£» 19£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 20£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 21£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 22£®ÌØЧͼƬÖÐÓ¢ÎĹ²6·ù 23£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²4·ù 24£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ£» 25£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²6·ù£» 26£®Êý¾Ý¿â½ÓÊÕ¿Í»§¶©µ¥£» 27£®Êý¾Ý¿â¹ÜÀí²úÆ·£» 28£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾16Ò³´Î£» 29£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ2ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ2Ìס£ 30£®ÔùËÍÍâóÖƵ¥Èí¼þ--¡¶ÍâóÖƵ¥Í¨¡·1Ìס£ --------------------------- ¡ø(Îå) ¼¯ÍÅÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®300Õ×Ö÷»ú¿Õ¼ä£» 3£®20¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®80¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®80¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­8·ù£» 13£®ÊÓƵ¶¯»­3·ù£» 14£®Êó±êÌØЧ2´¦£» 15£®ÍøÒ³ÒôÀÖ2´¦£» 16£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 17£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 18£®¶¯Ì¬¹ã¸æºá·ù3·ù£» 19£®ÖÐÎÄ¿ò¼ÜÖ÷Ò³¡¢Ó¢ÎÄ¿ò¼ÜÖ÷Ò³£» 20£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 21£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 22£®¿Í»§·´À¡ÁôÑÔ°å2¸ö(ÖÐÓ¢ÎÄ)£» 23£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ£» 24£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²8·ù 25£®ÌØЧͼƬÖÐÓ¢ÎĹ²8·ù£» 26£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²6·ù£» 27£®Êý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ¡¢¿Í»§¶©µ¥£» 28£®Êý¾Ý¿â¹ÜÀí»áÔ±£» 29£®ÓʼþÁÐ±í£¬ÊÕ¼¯·Ã¿ÍÓʼþµØÖ·£¬·¢Ë͹ã¸æ£» 30£®Êý¾Ý¿â¹ÜÀí²úÆ·£» 31£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 32£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾32Ò³´Î£» 33£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ3ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ3Ì×£» 34£®ÔùËÍÍâóÖƵ¥¼°¹ÜÀíÈí¼þ--¡¶ÍâóҵÎñͨ¡·1Ìס£ --------------------------- ¡¡±¾¹«Ë¾ÊÇÒ»¼Ò´ÓÊÂÍâó³ö¿ÚÐÐÒµ"¼ÆËã»úÓ¦ÓÃÈí¼þÑо¿¿ª·¢"¡¢"ÍøÂ繤³Ì½¨Éè"ºÍ"¶àýÌåÓ°ÊÓ¶¯»­¹ã¸æÖÆ ×÷"µÄרҵ¹«Ë¾£¬×¨ÃÅΪÎÒ¹ú¹ã´óÍâó¹«Ë¾¡¢³ö¿ÚÆóÒµ¿ª·¢¸÷ÖÖ¼ÆËã »úÓ¦ÓÃÈí¼þϵͳ¡¢ÍøÕ¾½¨ÉèÒÔ¼°ÆóÒµ¶àýÌåÓ°ÊÓ¶¯»­¹ã¸æƬÖÆ×÷¡£ ¡¡¡¡±¾¹«Ë¾ÔÚ¹ú¼Òó´Ù»áµÄÖ§³ÖºÍ×é֯ϣ¬³É¹¦¿ª·¢³ö¡¶Ô­²úµØÖ¤Íø ÉÏÉêÇëϵͳ¡·¡¢¡¶ÍâóÖƵ¥Í¨¡·¡¢¡¶ÍâóҵÎñͨ¡·µÈϵÁÐÍâóӦÓÃÈí ¼þ²úÆ·£¬Êܵ½¹ã´óÍâó³ö¿ÚÆóÒµµÄ»¶Ó­¡£ ¡¡¡¡Í¬Ê±£¬ÓÉÓÚÒµÎñ¹Øϵ£¬±¾¹«Ë¾»¹ÓëÃÀ¹ú¡¢Å·¹²Ìå¡¢ÈÕ±¾¡¢º«¹ú¡¢ ¶«ÄÏÑǵȵØÊýÊ®¼Ò²É¹ºÉÌ¡¢Á¬Ëø³¬ÊС¢ÒÔ¼°Éú²úÉÌÓÐ×ÅÁ¼ºÃµÄºÏ×÷¹Ø ϵ¡£¹ýÈ¥Ò»Äê¶à£¬±¾¹«Ë¾ÒÑ°ïÖú¶à¼ÒÍâ¹ú²É¹º³§ÉÌÔÚ¹úÄÚÕÒµ½ºÏÊ浀 ³ö¿Ú²úÆ·£¬´Ù³É¶à×Ú³ö¿ÚóÒס£ ----------------------------- ¹«Ë¾£º¹ãÖÝÊгà¾ÔÓÐÏÞ¹«Ë¾ µØÖ·£º¹ãÖÝÊмÓÄôó»¨Ô°6ºÅÂ¥9E µç»°£º020-85580234ת19 »ò20ÁÖÏÈÉú ´«Õ棺020-85581405 ÊÖ»ú£º13640327836 ÓÊÏ䣺linyu921@sina.com ----------------------------- From linyu921@sina.com Wed Aug 13 03:16:43 2003 From: linyu921@sina.com (=?GB2312?B?zqrE+r2oo6jW0NOizsSjqcbz0rXN+NW+?=) Date: Wed, 13 Aug 2003 10:16:43 +0800 Subject: [parisc-linux] =?GB2312?B?zqrE+r2oo6jW0NOizsSjqcbz0rXN+NW+IQ==?= Message-ID: <20030813021422.09D2B489A@dsl2.external.hp.com> ΪÄú½¨£¨ÖÐÓ¢ÎÄ£©ÆóÒµÍøÕ¾ ------------------------ ¡ø¸ù¾ÝÄúµÄÒªÇó¸öÐÔ»¯Éè¼Æ£¬¾ø²»Ì×ÓÃÄ£°æ¡£ ¡ø ÍøÕ¾ÎÞÏÞÀ©Õ¹¼Ü¹¹£¬ÊÊÓ¦ÄúÆóÒµÎÞÏÞ·¢Õ¹µÄÒªÇó¡£ ¡ø ¾ßÓкǫ́¹ÜÀí¹¦ÄÜ£¬ÍøÕ¾½¨³Éºó£¬½»ÓÉÄú×Ô¼º¸üйÜÀí¡£ ----------------------------- ¡ô±¾¹«Ë¾ÎªÄúËù½¨µÄÍøÕ¾¾ßÓÐÒÔϹ¦ÄÜ£º 1.²úƷչʾ-ÍøÉÏչʾÄúµÄ²úÆ·£¬Í¼ÎIJ¢Ã¯£¬¶à¼¶·ÖÀ࣬ºǫ́¹ÜÀí¡£ 2.ÍøÉÏÉ̵ê-¿Í»§¿ÉÖ±½ÓÔÚÍøÉÏÑ¡¹ºÄúµÄ²úÆ·£¬¾ÍÏñÔÚÉ̵êÀïÒ»Ñù¡£ 3.²úÆ·ËÑË÷-¿Í»§¿Éͨ¹ý²úÆ·Ãû³Æ¡¢Àà±ð¡¢¹Ø¼ü´ÊµÈ²éÕÒÄúµÄ²úÆ·¡£ 4.¿Í»§¹ÜÀí-¶Ô²»Í¬¿Í»§»ò»áÔ±£¬¿É½øÐзּ¶¡¢·ÖȨÏÞ¡¢·ÖÀà¹ÜÀí¡£ 5.²úÆ·¶¨¹º-¿Í»§¿ÉÖ±½ÓÔÚÍøÉÏ϶©µ¥£¬¶¨¹ºÄúµÄ²úÆ·¡£ 6.¿Í»§ÁôÑÔ-¿Í»§¿ÉÖ±½ÓÔÚÍøÉϸøÄúÁôÑÔ£¬ÏòÄú·´À¡Òâ¼û¡£ 7.ÐÂÎÅ·¢²¼-Äú¿ÉÔÚÍøÉÏÖ±½Ó·¢²¼¹«Ë¾µÄÐÂÎÅ¡¢Í¨Öª¡¢´ÙÏúÐÅÏ¢µÈ¡£ 8.»áÔ±ÉçÇø-¿É×÷ΪÍⲿ½»Á÷ÂÛ̳£¬Ò²¿É×÷Ϊ¹«Ë¾ÄÚ²¿Ô±¹¤¹µÍ¨Æ½Ì¨¡£ 9.ÍøÉϵ÷²é-¿ÉÒÔÉ趨ÈκÎÎÊÌ⣬Ïò¿Í»§»ò»áÔ±Á˽âÄúÏëÁ˽âµÄÊÂÇé¡£ 10.ÓʼþÁбí-¿ÉÒÔÊÕ¼¯¿Í»§µç×ÓÓÊÏäµÈ×ÊÁÏ£¬¶¨ÆÚÏò¿Í»§·¢ËÍÐÅÏ¢¡£ 11.ÍøÉϺؿ¨-ÖØÒª½ÚÈÕ£¬Ïò¿Í»§·¢Ë;«ÃÀºØ¿¨£¬ÔöÇ¿Óë¿Í»§µÄ¸ÐÇé¡£ 12.ÆóÒµÓʾÖ-ÓëÄúÍøվͬÓòÃûµÄÆóÒµÓʾ֣¬Ìá¸ßÄúÆóÒµµÄ¶ÔÍâÐÎÏó¡£ 13.ºǫ́¹ÜÀí-ËùÓÐÒÔÉϹ¦ÄÜ£¬¿ÉÓÉÄú×Ô¼º¿ØÖƹÜÀí£¬²»ÐèרҵÈËÔ±¡£ ¡ôÄúÒ²¿ÉÒÔ´ÓÏÂÃæ5ÖÖÀàÐÍÖУ¬ÌôÑ¡Ò»ÖÖÊʺÏÄú¹«Ë¾µÄÍøÕ¾? ----------------------------- ¡ø(Ò») ¾­¼ÃÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®100Õ×Ö÷»ú¿Õ¼ä£» 3£®ÍøÕ¾ÕûÌåÉè¼Æ£» 4£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 5£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 6£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 7£®5¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®5¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 9£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 10£®Gif°´Å¥¡¢ÐüÍ£°´Å¥£» 11£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 12£®BannerÉè¼ÆÖÆ×÷£¨Gif£© 13£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 14£®»¶Ó­Ò³·ÃÎÊÕß¼ÆÊýÆ÷1Ì×£» 15£®Óõç×ÓÓÊÏä½ÓÊÕ¿Í»§ÁôÑÔ; 16£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 17£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾2Ò³´Î¡£ -------------------------- ¡ø(¶þ) ±ê×¼ÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®120Õ×Ö÷»ú¿Õ¼ä£» 3£®1¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 8£®10¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 9£®10¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 10£®Gif°´Å¥¡¢ÐüÍ£°´Å¥£» 11£®Flash¶¯»­1·ù£» 12£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 13£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 14£®Êó±êÌØЧ1´¦ 15£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 16£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 17£®»¶Ó­Ò³·ÃÎÊÕß¼ÆÊýÆ÷1Ì×£» 18£®Óõç×ÓÓÊÏä½ÓÊÕ¿Í»§ÁôÑÔ£» 19£®ÌØЧͼƬÖÐÓ¢ÎĹ²2·ù£» 20£®¹ö¶¯×ÖÄ»¹«¸æÖÐÓ¢ÎĹ²2·ù£» 21£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 22£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾4Ò³´Î£» --------------------------- ¡ø(Èý) ÉÌÎñÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®150Õ×Ö÷»ú¿Õ¼ä£» 3£®5¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®20¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®20¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­2·ù£» 13£®ÊÓƵ¶¯»­1·ù£» 14£®Êó±êÌØЧ1´¦ 15£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 16£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 17£®¶¯Ì¬¹ã¸æºá·ù1·ù£» 18£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 19£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 20£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§¶©µ¥£» 21£®ÌØЧͼƬÖÐÓ¢ÎĹ²4·ù£» 22£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²2·ù£» 23£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²4·ù£» 24£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 25£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾8Ò³´Î£» 26£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ1ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ1Ìס£ --------------------------- ¡ø(ËÄ) ºÀ»ªÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®200Õ×Ö÷»ú¿Õ¼ä£» 3£®10¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®40¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®40¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­4·ù£» 13£®ÊÓƵ¶¯»­2·ù£» 14£®Êó±êÌØЧ1´¦£» 15£®ÍøÒ³ÒôÀÖ1´¦£» 16£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 17£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 18£®¶¯Ì¬¹ã¸æºá·ù2·ù£» 19£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 20£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 21£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 22£®ÌØЧͼƬÖÐÓ¢ÎĹ²6·ù 23£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²4·ù 24£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ£» 25£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²6·ù£» 26£®Êý¾Ý¿â½ÓÊÕ¿Í»§¶©µ¥£» 27£®Êý¾Ý¿â¹ÜÀí²úÆ·£» 28£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾16Ò³´Î£» 29£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ2ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ2Ìס£ 30£®ÔùËÍÍâóÖƵ¥Èí¼þ--¡¶ÍâóÖƵ¥Í¨¡·1Ìס£ --------------------------- ¡ø(Îå) ¼¯ÍÅÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®300Õ×Ö÷»ú¿Õ¼ä£» 3£®20¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®80¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®80¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­8·ù£» 13£®ÊÓƵ¶¯»­3·ù£» 14£®Êó±êÌØЧ2´¦£» 15£®ÍøÒ³ÒôÀÖ2´¦£» 16£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 17£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 18£®¶¯Ì¬¹ã¸æºá·ù3·ù£» 19£®ÖÐÎÄ¿ò¼ÜÖ÷Ò³¡¢Ó¢ÎÄ¿ò¼ÜÖ÷Ò³£» 20£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 21£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 22£®¿Í»§·´À¡ÁôÑÔ°å2¸ö(ÖÐÓ¢ÎÄ)£» 23£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ£» 24£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²8·ù 25£®ÌØЧͼƬÖÐÓ¢ÎĹ²8·ù£» 26£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²6·ù£» 27£®Êý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ¡¢¿Í»§¶©µ¥£» 28£®Êý¾Ý¿â¹ÜÀí»áÔ±£» 29£®ÓʼþÁÐ±í£¬ÊÕ¼¯·Ã¿ÍÓʼþµØÖ·£¬·¢Ë͹ã¸æ£» 30£®Êý¾Ý¿â¹ÜÀí²úÆ·£» 31£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 32£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾32Ò³´Î£» 33£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ3ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ3Ì×£» 34£®ÔùËÍÍâóÖƵ¥¼°¹ÜÀíÈí¼þ--¡¶ÍâóҵÎñͨ¡·1Ìס£ --------------------------- ¡¡±¾¹«Ë¾ÊÇÒ»¼Ò´ÓÊÂÍâó³ö¿ÚÐÐÒµ"¼ÆËã»úÓ¦ÓÃÈí¼þÑо¿¿ª·¢"¡¢"ÍøÂ繤³Ì½¨Éè"ºÍ"¶àýÌåÓ°ÊÓ¶¯»­¹ã¸æÖÆ ×÷"µÄרҵ¹«Ë¾£¬×¨ÃÅΪÎÒ¹ú¹ã´óÍâó¹«Ë¾¡¢³ö¿ÚÆóÒµ¿ª·¢¸÷ÖÖ¼ÆËã »úÓ¦ÓÃÈí¼þϵͳ¡¢ÍøÕ¾½¨ÉèÒÔ¼°ÆóÒµ¶àýÌåÓ°ÊÓ¶¯»­¹ã¸æƬÖÆ×÷¡£ ¡¡¡¡±¾¹«Ë¾ÔÚ¹ú¼Òó´Ù»áµÄÖ§³ÖºÍ×é֯ϣ¬³É¹¦¿ª·¢³ö¡¶Ô­²úµØÖ¤Íø ÉÏÉêÇëϵͳ¡·¡¢¡¶ÍâóÖƵ¥Í¨¡·¡¢¡¶ÍâóҵÎñͨ¡·µÈϵÁÐÍâóӦÓÃÈí ¼þ²úÆ·£¬Êܵ½¹ã´óÍâó³ö¿ÚÆóÒµµÄ»¶Ó­¡£ ¡¡¡¡Í¬Ê±£¬ÓÉÓÚÒµÎñ¹Øϵ£¬±¾¹«Ë¾»¹ÓëÃÀ¹ú¡¢Å·¹²Ìå¡¢ÈÕ±¾¡¢º«¹ú¡¢ ¶«ÄÏÑǵȵØÊýÊ®¼Ò²É¹ºÉÌ¡¢Á¬Ëø³¬ÊС¢ÒÔ¼°Éú²úÉÌÓÐ×ÅÁ¼ºÃµÄºÏ×÷¹Ø ϵ¡£¹ýÈ¥Ò»Äê¶à£¬±¾¹«Ë¾ÒÑ°ïÖú¶à¼ÒÍâ¹ú²É¹º³§ÉÌÔÚ¹úÄÚÕÒµ½ºÏÊ浀 ³ö¿Ú²úÆ·£¬´Ù³É¶à×Ú³ö¿ÚóÒס£ ----------------------------- ¹«Ë¾£º¹ãÖÝÊгà¾ÔÓÐÏÞ¹«Ë¾ µØÖ·£º¹ãÖÝÊмÓÄôó»¨Ô°6ºÅÂ¥9E µç»°£º020-85580234ת19 »ò20ÁÖÏÈÉú ´«Õ棺020-85581405 ÊÖ»ú£º13640327836 ÓÊÏ䣺linyu921@sina.com ----------------------------- From jsoe0708@tiscali.be Wed Aug 13 15:52:07 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Wed, 13 Aug 2003 16:52:07 +0200 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <20030812160612.GF20514@dsl2.external.hp.com> Message-ID: <3F28D76600003759@ocpmta4.freegates.net> > >osdl-aim-7 benchmark probably stresses both itlb and dtlb. >(available from osdl.org - URL is in linux-ia64 archive) Well I finaly find it on sf.net (via osdl.org) And submit some bench which seems to be more in relation with vm (?): ./reaim -x -t -f worfile.shared -r3 # with new itlb stuff I got following results REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 1 32.72 6.17 4.42 177.87 177.87 0.00 0.00 100 2 33.16 10.19 9.13 351.03 175.51 0.30 0.90 99 3 37.01 14.71 13.94 471.76 157.25 0.04 0.12 99 4 43.87 19.44 18.61 530.66 132.66 1.46 3.43 96 5 49.55 24.26 23.08 587.29 117.46 1.79 3.76 96 6 57.60 28.08 27.99 606.25 101.04 1.33 2.36 97 7 67.86 33.32 32.46 600.35 85.76 1.82 2.73 97 8 77.51 37.77 37.58 600.70 75.09 1.01 1.32 98 9 86.11 41.69 42.05 608.29 67.59 1.21 1.42 98 10 96.33 47.01 46.67 604.17 60.42 1.59 1.67 98 Max sustained jobs reached Max Jobs per Minute 608.29 REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 1 32.58 6.11 4.32 178.64 178.64 0.00 0.00 100 2 31.60 10.16 9.02 368.35 184.18 0.55 1.79 98 3 35.51 14.90 13.48 491.69 163.90 1.40 4.09 95 4 40.54 19.56 18.50 574.25 143.56 1.51 3.90 96 5 49.35 24.16 23.72 589.67 117.93 1.07 2.20 97 6 58.16 28.60 27.88 600.41 100.07 1.64 2.91 97 7 67.67 33.38 32.62 602.04 86.01 0.48 0.71 99 8 78.01 37.71 37.75 596.85 74.61 1.06 1.38 98 9 87.46 43.28 41.86 598.90 66.54 1.30 1.51 98 Max sustained jobs reached Max Jobs per Minute 602.04 REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 1 32.27 5.60 4.56 180.35 180.35 0.00 0.00 100 2 33.02 10.50 9.03 352.51 176.26 0.55 1.68 98 3 33.39 15.14 13.68 522.91 174.30 0.54 1.66 98 4 39.93 19.55 18.46 583.02 145.76 0.66 1.69 98 5 50.01 24.32 23.12 581.88 116.38 1.67 3.46 96 6 58.70 28.73 28.27 594.89 99.15 0.42 0.72 99 7 66.99 32.31 32.78 608.15 86.88 1.50 2.28 97 8 76.04 37.00 37.12 612.31 76.54 0.74 0.99 99 9 86.42 42.29 41.68 606.11 67.35 0.93 1.09 98 10 96.15 45.99 46.82 605.30 60.53 1.43 1.51 98 Max sustained jobs reached Max Jobs per Minute 612.31 # with the original itlb REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 1 32.37 5.79 4.42 179.80 179.80 0.00 0.00 100 2 33.28 10.07 9.33 349.76 174.88 0.06 0.20 99 3 36.37 15.30 13.73 480.07 160.02 0.21 0.58 99 4 41.49 19.60 18.37 561.10 140.27 2.15 5.38 94 5 49.21 24.03 23.40 591.34 118.27 1.26 2.62 97 6 59.48 29.56 27.85 587.09 97.85 2.44 4.26 95 7 68.38 32.96 32.47 595.79 85.11 0.96 1.43 98 8 76.53 36.48 37.74 608.39 76.05 2.08 2.80 97 9 86.39 41.80 41.91 606.32 67.37 0.86 1.01 98 10 95.58 45.96 46.90 608.91 60.89 1.24 1.31 98 11 104.80 50.56 51.60 610.88 55.53 1.21 1.17 98 Max sustained jobs reached Max Jobs per Minute 610.88 REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 1 32.05 5.66 4.47 181.59 181.59 0.00 0.00 100 2 33.90 10.52 9.13 343.36 171.68 0.45 1.35 98 3 38.53 14.55 13.84 453.15 151.05 0.44 1.16 98 4 40.38 18.64 18.49 576.52 144.13 0.54 1.35 98 5 48.82 23.39 23.26 596.07 119.21 1.71 3.62 96 6 58.57 28.88 28.01 596.21 99.37 0.63 1.08 98 7 67.80 32.98 32.77 600.88 85.84 2.61 3.98 96 8 76.49 36.85 37.50 608.71 76.09 1.14 1.51 98 9 87.04 42.31 42.12 601.79 66.87 2.82 3.31 96 Max sustained jobs reached Max Jobs per Minute 608.71 REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 1 32.54 5.63 4.59 178.86 178.86 0.00 0.00 100 2 33.68 10.74 9.00 345.61 172.80 0.32 0.97 99 3 35.66 14.41 13.98 489.62 163.21 1.46 4.26 95 4 42.70 19.24 18.43 545.20 136.30 2.18 5.35 94 5 49.30 23.86 23.33 590.26 118.05 1.31 2.78 97 6 57.14 27.50 28.11 611.13 101.86 1.56 2.81 97 7 66.99 31.90 33.07 608.15 86.88 0.70 1.06 98 8 77.60 37.64 37.46 600.00 75.00 0.99 1.31 98 9 85.76 41.25 42.08 610.77 67.86 1.50 1.78 98 10 97.18 47.80 46.20 598.89 59.89 1.48 1.56 98 Job rate dropping avg: 605.79 loss pct: 1.14 Max Jobs per Minute 611.13 AND ./reaim -q -t -f worfile.shared -r3 # with new itlb stuff I got following results REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 1 32.83 6.03 4.51 177.28 177.28 0.00 0.00 100 2 33.20 10.88 8.84 350.60 175.30 0.67 2.06 97 3 35.94 15.23 13.87 485.81 161.94 1.20 3.47 96 4 43.43 19.65 18.23 536.03 134.01 1.01 2.37 97 5 49.43 24.33 23.21 588.71 117.74 0.62 1.27 98 6 58.17 28.72 27.79 600.31 100.05 1.12 1.96 98 7 66.74 32.72 32.14 610.43 87.20 1.95 2.98 97 8 77.11 37.67 37.27 603.81 75.48 1.41 1.86 98 9 86.75 42.45 41.75 603.80 67.09 0.95 1.11 98 10 95.95 46.78 46.57 606.57 60.66 1.09 1.16 98 11 105.20 50.86 51.51 608.56 55.32 1.72 1.66 98 Crossover achieved Max Jobs per Minute 610.43 REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 1 32.73 6.28 4.47 177.82 177.82 0.00 0.00 100 2 33.55 10.97 8.96 346.94 173.47 0.24 0.74 99 3 34.55 15.24 13.70 505.35 168.45 1.20 3.58 96 4 40.15 19.14 18.33 579.83 144.96 0.88 2.22 97 5 49.94 24.48 23.26 582.70 116.54 1.00 2.05 97 6 60.80 28.86 27.50 574.34 95.72 0.81 1.35 98 7 67.28 33.01 32.08 605.53 86.50 1.47 2.24 97 8 77.15 37.59 37.02 603.50 75.44 1.37 1.80 98 9 85.40 40.94 42.18 613.35 68.15 1.75 2.09 97 10 95.15 45.89 46.72 611.67 61.17 1.11 1.19 98 11 104.86 50.49 51.54 610.53 55.50 1.49 1.44 98 Crossover achieved Max Jobs per Minute 613.35 REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 1 33.13 6.50 4.44 175.67 175.67 0.00 0.00 100 2 32.23 10.82 8.89 361.15 180.58 0.23 0.72 99 3 35.72 15.39 13.76 488.80 162.93 2.12 6.37 93 4 42.04 20.43 18.52 553.76 138.44 3.55 8.94 91 5 49.50 24.03 23.06 587.88 117.58 2.50 5.26 94 6 57.70 27.79 28.01 605.20 100.87 1.45 2.60 97 7 67.37 32.72 32.59 604.72 86.39 0.68 1.03 98 8 76.52 36.82 37.57 608.47 76.06 0.90 1.19 98 9 86.14 42.06 41.87 608.08 67.56 0.87 1.03 98 10 96.24 47.16 46.63 604.74 60.47 1.62 1.72 98 11 105.27 51.04 51.32 608.15 55.29 1.29 1.23 98 Crossover achieved Max Jobs per Minute 608.47 # with the original itlb REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 1 32.35 5.94 4.50 179.91 179.91 0.00 0.00 100 2 31.31 10.80 9.27 371.77 185.88 0.40 1.29 98 3 34.63 15.23 13.94 504.19 168.06 0.25 0.74 99 4 40.22 18.84 18.58 578.82 144.70 1.07 2.74 97 5 48.83 23.89 23.31 595.95 119.19 0.84 1.76 98 6 58.67 28.74 28.11 595.19 99.20 1.96 3.46 96 7 68.28 32.71 33.19 596.66 85.24 1.02 1.52 98 8 77.41 37.61 37.58 601.47 75.18 0.76 1.00 99 9 86.21 41.55 42.28 607.59 67.51 1.44 1.71 98 10 95.30 45.91 46.78 610.70 61.07 1.46 1.56 98 11 106.35 51.52 51.38 601.97 54.72 0.82 0.78 99 Crossover achieved Max Jobs per Minute 610.70 REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 1 32.33 5.88 4.46 180.02 180.02 0.00 0.00 100 2 31.53 10.07 9.19 369.17 184.59 0.38 1.20 98 3 35.76 14.74 14.01 488.26 162.75 1.13 3.23 96 4 41.04 19.34 18.52 567.25 141.81 1.47 3.70 96 5 49.68 24.37 23.11 585.75 117.15 1.32 2.72 97 6 58.14 27.69 28.40 600.62 100.10 0.64 1.12 98 7 68.26 33.09 33.00 596.84 85.26 0.87 1.30 98 8 77.46 37.61 37.39 601.08 75.14 0.85 1.11 98 9 86.90 42.44 42.03 602.76 66.97 1.51 1.76 98 10 95.84 46.22 46.81 607.26 60.73 1.11 1.18 98 11 106.16 51.65 51.22 603.05 54.82 1.32 1.26 98 Crossover achieved Max Jobs per Minute 607.26 REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 1 32.64 5.95 4.62 178.31 178.31 0.00 0.00 100 2 32.83 10.56 9.20 354.55 177.28 0.27 0.83 99 3 36.69 15.87 13.83 475.88 158.63 0.15 0.41 99 4 40.89 19.04 18.71 569.33 142.33 0.21 0.51 99 5 49.90 23.61 23.39 583.17 116.63 0.60 1.22 98 6 59.07 28.39 28.51 591.16 98.53 1.77 3.09 96 7 67.94 32.63 32.75 599.65 85.66 1.05 1.58 98 8 76.17 36.23 37.74 611.26 76.41 3.08 4.15 95 9 86.15 41.37 42.21 608.01 67.56 0.97 1.14 98 10 95.27 46.00 46.57 610.90 61.09 1.29 1.37 98 11 105.61 51.56 51.21 606.19 55.11 0.79 0.76 99 Crossover achieved Max Jobs per Minute 611.26 =========================== (Carlos, I have no really clue about bench, so if you find some other test that will better respond to your expectations, do not hesitate ... I will try to do my best :) ) Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From grundler@parisc-linux.org Wed Aug 13 16:57:54 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 13 Aug 2003 09:57:54 -0600 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <3F29178A00002DBE@ocpmta7.freegates.net> References: <20030812160612.GF20514@dsl2.external.hp.com> <3F29178A00002DBE@ocpmta7.freegates.net> Message-ID: <20030813155754.GC18794@dsl2.external.hp.com> On Tue, Aug 12, 2003 at 07:06:44PM +0200, Joel Soete wrote: > > > >osdl-aim-7 benchmark probably stresses both itlb and dtlb. > >(available from osdl.org - URL is in linux-ia64 archive) > > Ok I finaly find it as re-aim-7 sf.net project. I also pulled bits from sf.net for ia64 testing: http://umn.dl.sourceforge.net/sourceforge/re-aim-7/reaim-0.1.8.tar.gz though I know the maintainer planed to change the name since then: | Apoligies, the naming was not good. | I'll attempt to change it. ( i like osdl-aim-7 ) | In the meantime, you can also get the source from | | bk://developer.osdl.org/reaim | cliffw > Just launch (alltest) with > kernel-64bits+ C.patch . I will let run for the night and relaunch it with > tommorrow morning with original kernel-64bits. I was told to run with: iota:/mnt# reaim -f /mnt/usr/local/share/reaim/workfile.new_dbase -s100 -e 500 -i 100 You might need to pick -s and -e values that are more appropriate for the machine under test. This was for dual CPU 900Mz rx2600 with 2GB RAM. hth, grant From carlos@baldric.uwo.ca Wed Aug 13 16:56:05 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Wed, 13 Aug 2003 11:56:05 -0400 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <3F28D76600003759@ocpmta4.freegates.net> References: <20030812160612.GF20514@dsl2.external.hp.com> <3F28D76600003759@ocpmta4.freegates.net> Message-ID: <20030813155605.GF17512@systemhalted> > Well I finaly find it on sf.net (via osdl.org) > And submit some bench which seems to be more in relation with vm (?): > ./reaim -x -t -f worfile.shared -r3 Thanks for that run Joel, I'll take a look at the numbers in a few minutes. Adding to that here is the lmbench results (urls) for both the non-optimized and optimized cases of the itlb fault handler. It seems that some things got faster, or rather more predictably fast within the confidence levels (e.g. number of tests that I ran). I ran 10 lmbench run's for each of the two kernels and then munged them using the stat-summary script provided with lmbench. Do the diff to see the numbers change :) Looks like we have better performance in many places. null call, null i/o, stat, open/close, select, signal install, signal catch, exec, shell proc, (a variety of the process spawning tests), create, delete, mmap latency, page fault (way down! and deterministic) -- All got better with itlb branch prediction optimization Please give it a double check to make sure I'm not out of it this morning. http://www.baldric.uwo.ca/~carlos/itlb-opt.txt http://www.baldric.uwo.ca/~carlos/no-itlb-opt.txt c. From carlos@baldric.uwo.ca Wed Aug 13 17:05:32 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Wed, 13 Aug 2003 12:05:32 -0400 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <20030813155605.GF17512@systemhalted> References: <20030812160612.GF20514@dsl2.external.hp.com> <3F28D76600003759@ocpmta4.freegates.net> <20030813155605.GF17512@systemhalted> Message-ID: <20030813160532.GG17512@systemhalted> > Thanks for that run Joel, I'll take a look at the numbers in a few > minutes. Adding to that here is the lmbench results (urls) for both > the non-optimized and optimized cases of the itlb fault handler. I forgot that lamont noticed an interlocked zdep in the PA11 common case and we reorderd the insn sequence. Perhaps this helped the numbers a bit. I have to run the same lmbench tests on a 64-bit box first to compare. c. From jsoe0708@tiscali.be Wed Aug 13 17:38:06 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Wed, 13 Aug 2003 18:38:06 +0200 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <20030813155754.GC18794@dsl2.external.hp.com> Message-ID: <3F28D766000037C3@ocpmta4.freegates.net> >I also pulled bits from sf.net for ia64 testing: > http://umn.dl.sourceforge.net/sourceforge/re-aim-7/reaim-0.1.8.tar.gz I will also catch it >I was told to run with: >iota:/mnt# reaim -f /mnt/usr/local/share/reaim/workfile.new_dbase -s100 -e 500 > -i 100 >You might need to pick -s and -e values that are more appropriate for >the machine under test. This > was for dual CPU 900Mz rx2600 with 2GB RAM. That is also what I just read on a bench on lwn :) I will adapt Thanks, Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From jsoe0708@tiscali.be Wed Aug 13 17:43:27 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Wed, 13 Aug 2003 18:43:27 +0200 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <20030813160532.GG17512@systemhalted> Message-ID: <3F28D766000037C6@ocpmta4.freegates.net> >I forgot that lamont noticed an interlocked zdep in the PA11 common case hmm what is an interlock? (just to complet my knowledge) >and we reorderd the insn sequence. Perhaps this helped the numbers a >bit. If I well understand reverse the zdep move in the code? (I would play just a bit more with different bench) >I have to run the same lmbench tests on a 64-bit box first to >compare. Nice I hope that will confirm lmbench results :) Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From grundler@parisc-linux.org Wed Aug 13 17:51:55 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 13 Aug 2003 10:51:55 -0600 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <3F28D766000037C6@ocpmta4.freegates.net> References: <20030813160532.GG17512@systemhalted> <3F28D766000037C6@ocpmta4.freegates.net> Message-ID: <20030813165155.GE18794@dsl2.external.hp.com> On Wed, Aug 13, 2003 at 06:43:27PM +0200, Joel Soete wrote: > hmm what is an interlock? (just to complet my knowledge) It's the logic in a CPU to stall an instruction which is waiting for the results of a previous instruction. ie the register contents used by the second instruction are not valid until any previous instruction actually completes. grant From grundler@parisc-linux.org Wed Aug 13 18:53:40 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 13 Aug 2003 11:53:40 -0600 Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <20030811043457.GA5653@dsl2.external.hp.com> References: <20030811043457.GA5653@dsl2.external.hp.com> Message-ID: <20030813175340.GF18794@dsl2.external.hp.com> On Sun, Aug 10, 2003 at 10:34:57PM -0600, Grant Grundler wrote: > This started out as an issue with glxinfo program in xfree86. I've built a full set of xfree86-4.2.1-9 hppa debs with gcc 3.3.1. (last ones in "testing" are 4.2.1-6 and built with gcc 3.0.1 IIRC) Public URL http://gsyprf11.external.hp.com/hppa/xfree86-4.2.1-9/ HP Internal http://debian.cup.hp.com/parisc/xfree86-4.2.1-9/ The bits seem to run fine on my c3k...but xpdf still fails: grundler <513>xpdf -cmap dino31.pdf Error: Unresolved inheritance operation grundler <514> ... grundler <516>dpkg -l xlibs Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii xlibs 4.2.1-9 X Window System client libraries *sigh*. Do I need to restart X11 or something? grant From James.Bottomley@steeleye.com Wed Aug 13 21:11:42 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 13 Aug 2003 15:11:42 -0500 Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <20030813175340.GF18794@dsl2.external.hp.com> References: <20030811043457.GA5653@dsl2.external.hp.com> <20030813175340.GF18794@dsl2.external.hp.com> Message-ID: <1060805514.2011.1.camel@fuzzy> On Wed, 2003-08-13 at 12:53, Grant Grundler wrote: > grundler <513>xpdf -cmap dino31.pdf > Error: Unresolved inheritance operation > grundler <514> Hmm, it looks like you still have the libXt problem. Are you sure you installed the newly compiled one? > *sigh*. > Do I need to restart X11 or something? I didn't. All I did was pull libXt.so.6.0 out of the gcc-3.3.1 build and copy it into /usr/X11R6/lib. Then xpdf worked for me. James From grundler@parisc-linux.org Wed Aug 13 22:32:04 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 13 Aug 2003 15:32:04 -0600 Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <1060805514.2011.1.camel@fuzzy> References: <20030811043457.GA5653@dsl2.external.hp.com> <20030813175340.GF18794@dsl2.external.hp.com> <1060805514.2011.1.camel@fuzzy> Message-ID: <20030813213204.GA26014@dsl2.external.hp.com> On Wed, Aug 13, 2003 at 03:11:42PM -0500, James Bottomley wrote: > Hmm, it looks like you still have the libXt problem. Are you sure you > installed the newly compiled one? I did...but you are definitely asking the right qustion. I didn't see: grundler@debian:~$ ls -l /usr/X11R6/lib/libXt.so* lrwxrwxrwx 1 root root 10 Jul 10 11:13 /usr/X11R6/lib/libXt.so -> libXt.so.6 lrwxrwxrwx 1 root root 17 Aug 12 10:29 /usr/X11R6/lib/libXt.so.6 -> libXt.so.6.0-orig -rw-r--r-- 1 root root 402072 Aug 11 19:55 /usr/X11R6/lib/libXt.so.6.0 -rw-r--r-- 1 root root 397408 Feb 25 21:57 /usr/X11R6/lib/libXt.so.6.0-orig deleting the -orig file(s!) and fixing up the symlink(s) got xpdf working again. Yeah! I found 6 or 7 X11/libs had been redirected to the -orig files. Thanks for asking the right stupid question....and I'll have to take the blame for leaving -orig files laying around. Randolph observed ldconfig will fixup the links if something "newer" (based on filename) is available. And "man ldconfig" talks about how that works. *sigh* Besides the /lib and /usr/lib directories (default), ldconfig also looks at: grundler <525>cat /etc/ld.so.conf /usr/X11R6/lib grundler <526> if I can just figure out what's botching the colors for xchat2 now... thanks, grant From James.Bottomley@steeleye.com Wed Aug 13 23:53:33 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 13 Aug 2003 17:53:33 -0500 Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <20030813213204.GA26014@dsl2.external.hp.com> References: <20030811043457.GA5653@dsl2.external.hp.com> <20030813175340.GF18794@dsl2.external.hp.com> <1060805514.2011.1.camel@fuzzy> <20030813213204.GA26014@dsl2.external.hp.com> Message-ID: <1060815215.1987.2.camel@fuzzy> On Wed, 2003-08-13 at 16:32, Grant Grundler wrote: > if I can just figure out what's botching the colors for xchat2 now... Is this with one of the Visualize cards? They only do 8bpp at all resolutions, so if you run a colourful window manager, you run out pretty quickly. Even using the default fvwm, I had to run xpdf with a private colourmap (-cmap option) to get my slides to show up as anything like reasonable). A lot of modern applications (particularly of the kde or gnome variety) pay absolutely no attention to potential colour map limitations and can blithely request more colours than you have available (and sometimes not even check for failure returns). James From alan@lxorguk.ukuu.org.uk Thu Aug 14 01:12:05 2003 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: 14 Aug 2003 01:12:05 +0100 Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <1060815215.1987.2.camel@fuzzy> References: <20030811043457.GA5653@dsl2.external.hp.com> <20030813175340.GF18794@dsl2.external.hp.com> <1060805514.2011.1.camel@fuzzy> <20030813213204.GA26014@dsl2.external.hp.com> <1060815215.1987.2.camel@fuzzy> Message-ID: <1060819924.4004.0.camel@dhcp23.swansea.linux.org.uk> On Mer, 2003-08-13 at 23:53, James Bottomley wrote: > A lot of modern applications (particularly of the kde or gnome variety) > pay absolutely no attention to potential colour map limitations and can > blithely request more colours than you have available (and sometimes not > even check for failure returns). Set the display to a fixed colour mapping is the simplest approach. XFree 4.x is quite happy to let you set different visuals and get things like an 8bit fixed palette From web@gmce.net Thu Aug 14 03:21:19 2003 From: web@gmce.net (=?GB2312?B?uePW3dLGtq8=?=) Date: Thu, 14 Aug 2003 10:21:19 +0800 Subject: [parisc-linux] =?GB2312?B?uePW3dLGtq+w78T6yqG7sLfR?= Message-ID: <20030814021905.8AC86483F@dsl2.external.hp.com> ¹ãÖÝÒƶ¯°ïÄúÊ¡»°·Ñ »î¶¯Ê±¼ä£º8ÔÂ1ÈÕÖÁ8ÔÂ31ÈÕ »î¶¯ÄÚÈÝ£ºÔ¤´æ100Ôª»°·ÑËÍ200Ôª»°·Ñ£¬ºÏ¼Æ300Ôª·Ö12¸öÔÂÿÔ»®¿Û25Ôª¡£ ×¢£ºÖ»ÏÞÈ«ÇòͨÈëÍøÓû§¡£ Ö¸¶¨ÒµÎñÊÜÀíµç»°£º85580308 85580908 ·þÎñ¼à¶½Í¶Ëߵ绰£º89822292 From web@gmce.net Thu Aug 14 03:21:27 2003 From: web@gmce.net (=?GB2312?B?uePW3dLGtq8=?=) Date: Thu, 14 Aug 2003 10:21:27 +0800 Subject: [parisc-linux] =?GB2312?B?uePW3dLGtq+w78T6yqG7sLfR?= Message-ID: <20030814021913.893F14841@dsl2.external.hp.com> ¹ãÖÝÒƶ¯°ïÄúÊ¡»°·Ñ »î¶¯Ê±¼ä£º8ÔÂ1ÈÕÖÁ8ÔÂ31ÈÕ »î¶¯ÄÚÈÝ£ºÔ¤´æ100Ôª»°·ÑËÍ200Ôª»°·Ñ£¬ºÏ¼Æ300Ôª·Ö12¸öÔÂÿÔ»®¿Û25Ôª¡£ ×¢£ºÖ»ÏÞÈ«ÇòͨÈëÍøÓû§¡£ Ö¸¶¨ÒµÎñÊÜÀíµç»°£º85580308 85580908 ·þÎñ¼à¶½Í¶Ëߵ绰£º89822292 From grundler@parisc-linux.org Thu Aug 14 06:12:36 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 13 Aug 2003 23:12:36 -0600 Subject: [parisc-linux] xfree86 4.2.1-9 build problem In-Reply-To: <1060815215.1987.2.camel@fuzzy> References: <20030811043457.GA5653@dsl2.external.hp.com> <20030813175340.GF18794@dsl2.external.hp.com> <1060805514.2011.1.camel@fuzzy> <20030813213204.GA26014@dsl2.external.hp.com> <1060815215.1987.2.camel@fuzzy> Message-ID: <20030814051236.GA3546@dsl2.external.hp.com> On Wed, Aug 13, 2003 at 05:53:33PM -0500, James Bottomley wrote: > Is this with one of the Visualize cards? They only do 8bpp at all > resolutions, so if you run a colourful window manager, you run out > pretty quickly. Even using the default fvwm, I had to run xpdf with a > private colourmap (-cmap option) to get my slides to show up as anything > like reasonable). yes. And I'm using fvwm2 which I thought was supposed to be a fairly (not totally) light weight window manager. I'll see if there are knobs to reduce the FVWM color consumption. > A lot of modern applications (particularly of the kde or gnome variety) > pay absolutely no attention to potential colour map limitations and can > blithely request more colours than you have available (and sometimes not > even check for failure returns). yup - I was looking to find the code to and at least print a warning so I know that's the problem. I've spent < 1h hunting through the code to figure out where the colors for the text box was allocated. Haven't found it yet though. From web@gmce.net Thu Aug 14 06:36:42 2003 From: web@gmce.net (=?GB2312?B?uePW3dLGtq8=?=) Date: Thu, 14 Aug 2003 13:36:42 +0800 Subject: [parisc-linux] =?GB2312?B?uePW3dLGtq+w78T6yqG7sLfR?= Message-ID: <20030814053428.1C25F4861@dsl2.external.hp.com> ¹ãÖÝÒƶ¯°ïÄúÊ¡»°·Ñ »î¶¯Ê±¼ä£º8ÔÂ1ÈÕÖÁ8ÔÂ31ÈÕ »î¶¯ÄÚÈÝ£ºÔ¤´æ100Ôª»°·ÑËÍ200Ôª»°·Ñ£¬ºÏ¼Æ300Ôª·Ö12¸öÔÂÿÔ»®¿Û25Ôª¡£ ×¢£ºÖ»ÏÞÈ«ÇòͨÈëÍøÓû§¡£ Ö¸¶¨ÒµÎñÊÜÀíµç»°£º85580308 85580908 ·þÎñ¼à¶½Í¶Ëߵ绰£º89822292 From web@gmce.net Thu Aug 14 06:36:53 2003 From: web@gmce.net (=?GB2312?B?uePW3dLGtq8=?=) Date: Thu, 14 Aug 2003 13:36:53 +0800 Subject: [parisc-linux] =?GB2312?B?uePW3dLGtq+w78T6yqG7sLfR?= Message-ID: <20030814053430.8C2A84861@dsl2.external.hp.com> ¹ãÖÝÒƶ¯°ïÄúÊ¡»°·Ñ »î¶¯Ê±¼ä£º8ÔÂ1ÈÕÖÁ8ÔÂ31ÈÕ »î¶¯ÄÚÈÝ£ºÔ¤´æ100Ôª»°·ÑËÍ200Ôª»°·Ñ£¬ºÏ¼Æ300Ôª·Ö12¸öÔÂÿÔ»®¿Û25Ôª¡£ ×¢£ºÖ»ÏÞÈ«ÇòͨÈëÍøÓû§¡£ Ö¸¶¨ÒµÎñÊÜÀíµç»°£º85580308 85580908 ·þÎñ¼à¶½Í¶Ëߵ绰£º89822292 From jsoe0708@tiscali.be Thu Aug 14 07:02:04 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 14 Aug 2003 08:02:04 +0200 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <20030813160532.GG17512@systemhalted> Message-ID: <3F2A5B0400002E28@ocpmta1.freegates.net> > >I forgot that lamont noticed an interlocked zdep in the PA11 common case >and we reorderd the insn sequence. Perhaps this helped the numbers a >bit. I have to run the same lmbench tests on a 64-bit box first to >compare. btw is it for that reason (interlock) that in your patch we can read: [...] cmpb,= %r0,t0,itlb_miss_... nop [...] I am alway asking why the 'nop'. Thanks in advance, Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From willy@debian.org Thu Aug 14 12:46:53 2003 From: willy@debian.org (Matthew Wilcox) Date: Thu, 14 Aug 2003 12:46:53 +0100 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <3F2A5B0400002E28@ocpmta1.freegates.net> References: <20030813160532.GG17512@systemhalted> <3F2A5B0400002E28@ocpmta1.freegates.net> Message-ID: <20030814114653.GJ10015@parcelfarce.linux.theplanet.co.uk> On Thu, Aug 14, 2003 at 08:02:04AM +0200, Joel Soete wrote: > btw is it for that reason (interlock) that in your patch we can read: > [...] > cmpb,= %r0,t0,itlb_miss_... > nop > [...] > I am alway asking why the 'nop'. To fill the delayed branch slot (a silly idea, but ...) -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From jsoe0708@tiscali.be Thu Aug 14 14:56:42 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 14 Aug 2003 15:56:42 +0200 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <20030814114653.GJ10015@parcelfarce.linux.theplanet.co.uk> Message-ID: <3F2A5B04000030E1@ocpmta1.freegates.net> >This fill the delayed branch slot (a silly idea, but ...) Ha Ok (yet another concept for me ;-). I will look for into architecture books) For the moment I am studying TLB miss handling and already have a lot of questions. But the very first one: H/W or S/W management (I refer to page 3-9 parisc-2.0: Adress Resolution and the TLB)? In the 2 cases, if a fault occurs an interrupt (6, 15, 16,17 or 20) is 'triggered'? Is a printk() in corresponding handle_interruption() case (kernel/traps.c) would help? (if that work, how may I know which processor causes fault?) Thanks again, Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From knaresh@india.hp.com Thu Aug 14 15:12:38 2003 From: knaresh@india.hp.com (Naresh) Date: Thu, 14 Aug 2003 19:42:38 +0530 Subject: [parisc-linux] Discontig memory. Message-ID: <3F3B98D6.84D2464F@india.hp.com> Hi, What exactly are the implications of turning on CONFIG_DISCONTIGMEM? Does this lead to serious system degradation? I do see a message being printed on the console during bootup, stating that heavy swapping could take place, and it is a mistake to turn on this option. I also see a comment in the code saying that this option is not implemented well. How seriously will it affect a system thats not running too many processes? Regards, Naresh. From willy@debian.org Thu Aug 14 15:21:46 2003 From: willy@debian.org (Matthew Wilcox) Date: Thu, 14 Aug 2003 15:21:46 +0100 Subject: [parisc-linux] Discontig memory. In-Reply-To: <3F3B98D6.84D2464F@india.hp.com> References: <3F3B98D6.84D2464F@india.hp.com> Message-ID: <20030814142146.GL10015@parcelfarce.linux.theplanet.co.uk> On Thu, Aug 14, 2003 at 07:42:38PM +0530, Naresh wrote: > Hi, > What exactly are the implications of turning on CONFIG_DISCONTIGMEM? > Does this lead to serious system degradation? I do see a message being > printed on the console during bootup, stating that heavy swapping could > take place, and it is a mistake to turn on this option. I also see a > comment in the code saying that this option is not implemented well. How > seriously will it affect a system thats not running too many processes? The discontigmem code in 2.4 is very badly written. it basically limits you to using the size of the smallest area multiplied by the number of areas. on an astro-based system, that's 256MB * 3 = 768MB. as the warning says, don't turn it on. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From gustavo@zacarias.com.ar Thu Aug 14 16:15:08 2003 From: gustavo@zacarias.com.ar (Gustavo Zacarias) Date: Thu, 14 Aug 2003 12:15:08 -0300 Subject: [parisc-linux] Zalon driver not 64-bit clean? Message-ID: <3F3BA77C.8080804@zacarias.com.ar> Hi. Continuing with the K360 saga, it seems the Zalon driver is not 64-bit clean. By removing it from the kernel config i'm able to boot a 64 bit kernel on a K360, but obviously i won't get any network or wide scsi working, so it isn't quite useful. Is anyone aware of this / working on a solution / planning on working? Or maybe there's no interest in this? Thanks in advance. From grundler@parisc-linux.org Thu Aug 14 16:23:48 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Thu, 14 Aug 2003 09:23:48 -0600 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <3F2A5B04000030E1@ocpmta1.freegates.net> References: <20030814114653.GJ10015@parcelfarce.linux.theplanet.co.uk> <3F2A5B04000030E1@ocpmta1.freegates.net> Message-ID: <20030814152348.GA17578@dsl2.external.hp.com> On Thu, Aug 14, 2003 at 03:56:42PM +0200, Joel Soete wrote: > In the 2 cases, if a fault occurs an interrupt (6, 15, 16,17 or 20) is > 'triggered'? yes, but most people call them "traps" or "faults" to be more specific. Chapter 5 of the PA 2.0 arch book differentiates nicely. grant From jsoe0708@tiscali.be Thu Aug 14 17:15:28 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 14 Aug 2003 18:15:28 +0200 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <20030814152348.GA17578@dsl2.external.hp.com> Message-ID: <3F2A5B0400003183@ocpmta1.freegates.net> >> >> On Thu, Aug 14, 2003 at 03:56:42PM +0200, Joel Soete wrote: >> In the 2 cases, if a fault occurs an interrupt (6, 15, 16,17 or 20) is >> 'triggered'? >> >yes, but most people call them "traps" or "faults" to be more specific. >Chapter 5 of the PA 2.0 arch book differentiates nicely. Yes (that is from where came 6,15,.. reference). Oh yes, my bad: I didn't notice that here interrupt is not the shortcut of interruptions as I use to make the mishmash :( Thanks, Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From nikitins@latnet.lv Thu Aug 14 17:36:08 2003 From: nikitins@latnet.lv (Mihails Nikitins) Date: Thu, 14 Aug 2003 19:36:08 +0300 (EEST) Subject: [parisc-linux] PALO questions Message-ID: <1060878968.3f3bba7807eb5@clients.latnet.lv> Hi all, 1. PALO docs tell "recoverykernel" in palo.conf is the path to the kernel that you want to boot within a failsafe session, it will be stored in the 'f0' partition. Do I undertstand correctly that command like palo –I /dev/sda copies file specified by paloc.conf line --recoverykernel=/boot/vmlinux ? 2. Is it possible to see f0 partition contents? In HP-UX, there are commands working with LIF files like lifls and lifcp. How can I check if there is a recovery kernel in PALO area? 3. I noticed palo warns about bad DOS magic. Is it normal? # palo -I /dev/sda palo version 1.0 bame@palinux Mon Apr 1 10:03:01 MST 2002 ELF32 executable Bad DOS magic in extended partition fdisk -l /dev/sda Disk /dev/sda: 64 heads, 32 sectors, 8683 cylinders Units = cylinders of 2048 * 512 bytes Device Boot Start End Blocks Id System /dev/sda1 1 17 17392 f0 Linux/PA-RISC boot /dev/sda2 18 50 33792 fd Linux raid autodetect /dev/sda3 51 563 525312 fd Linux raid autodetect /dev/sda4 564 8683 8314880 5 Extended /dev/sda5 564 4683 4218864 fd Linux raid autodetect /dev/sda6 4684 8683 4095984 fd Linux raid autodetect Many thanks in advance for your clever comments! BR, Mihails From bame@hp.com Thu Aug 14 17:48:12 2003 From: bame@hp.com (bame@hp.com) Date: Thu, 14 Aug 2003 10:48:12 -0600 Subject: [parisc-linux] PALO questions In-Reply-To: Message from Mihails Nikitins of "Thu, 14 Aug 2003 19:36:08 +0300." <1060878968.3f3bba7807eb5@clients.latnet.lv> References: <1060878968.3f3bba7807eb5@clients.latnet.lv> Message-ID: <20030814164813.281BD733C4@fc.hp.com> > Hi all, > > 1. PALO docs tell "recoverykernel" in palo.conf is the path to the kernel that > you want to boot within a failsafe session, it will be stored in the 'f0' > partition. Do I undertstand correctly that command like > palo –I /dev/sda > copies file specified by paloc.conf line > --recoverykernel=/boot/vmlinux ? Yes, that kernel is copied to the f0 partition (or wherever you designate) > 2. Is it possible to see f0 partition contents? In HP-UX, there are commands > working with LIF files like lifls and lifcp. How can I check if there is a > recovery kernel in PALO area? Palo shows the contents in a very crude form during booting. There is no file system as such, like LIF, in the f0 partition, thus no convenient tools for that. Thought about doing something like that but the payoff doesn't seem worth it especially since we usually boot kernels from the file system anyway. Feel free to send me a patch for "palo --ls" or something :-) > 3. I noticed palo warns about bad DOS magic. Is it normal? Harmless if annoying. From the source: /* we're currently using 32-bit file seeks which is ok since * the IPL is also limited to 2G right now. So on big disks * this next read may fail, and we need to let that happen * gracefully. */ if (seekread(bootdev, (char *)&fb, sizeof fb, 512 * offset) == -1) break; if (fb.dosmagic[0] != 0x55 || fb.dosmagic[1] != 0xaa) { printf("Bad DOS magic in extended partition\n\r"); break; } Either the disk is improperly formatted or (more likely) the seekread() call isn't returning the -1 error like it should. Since we can't boot from anything past the 2G limit anyway it doesn't matter. From caslivkoff@speakeasy.net Thu Aug 14 23:26:38 2003 From: caslivkoff@speakeasy.net (caslivkoff@speakeasy.net) Date: Thu, 14 Aug 2003 22:26:38 +0000 Subject: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem) Message-ID: Hi Grant, > yup - I was looking to find the code to and at least print a warning > so I know that's the problem. I've spent < 1h hunting through the code > to figure out where the colors for the text box was allocated. Haven't > found it yet though. Just to be sure this is indeed a colormap issue, start an X session using twm, then only launch xchat. If the colors are "OK", then it's a pretty good bet that the default colormap is max-ed out. Also, I've attached is short Xlib program. This will report the number of private color cells remaining in the default colormap. -chuck From grundler@parisc-linux.org Fri Aug 15 00:33:43 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Thu, 14 Aug 2003 17:33:43 -0600 Subject: [parisc-linux] Re: second nic for proxy server In-Reply-To: <1060895797.1090.10.camel@localhost.localdomain> References: <1060876670.1603.14.camel@localhost.localdomain> <20030814165644.GA19868@dsl2.external.hp.com> <1060895797.1090.10.camel@localhost.localdomain> Message-ID: <20030814233343.GA27608@dsl2.external.hp.com> [ replying to list...everyone learns something ] On Thu, Aug 14, 2003 at 02:16:37PM -0700, jmd wrote: > grant... > > something is amiss here. the small section of the PCI connector is > towards the front of the card. standard PCI cards the sector is in the > rear (opposite end of backplane). is this a mistake on hp's part? am i > crazy?? need glasses checked? that's 3.3v vs 5v keying. HP(-UX) normally only sells "universal" cards that have both 3.3 and 5v keying. > so if this is a no go with PCI, can i put an ISA card in the EISA slot? > major problems if i do this? i have a 3com etherlink III. I guess. I don't touch EISA. > this is a temporary server. if its complicated i will pass on it. If the PCI card doesn't fit (wrong keying), then I'd pass on it. Just my $0.02. > btw.... when i am done with this box (month or so) its available for a > developer if they wish to have it. cost of shipping only. cool - thanks! Can anyone make use of a C180? PA2.0, PCI/EISA/GSC IO, 4 IO slots. grant From grundler@parisc-linux.org Fri Aug 15 06:41:21 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Thu, 14 Aug 2003 23:41:21 -0600 Subject: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem) In-Reply-To: References: Message-ID: <20030815054121.GC2989@dsl2.external.hp.com> On Thu, Aug 14, 2003 at 10:26:38PM +0000, caslivkoff@speakeasy.net wrote: > Just to be sure this is indeed a colormap issue, start an X session > using twm, then only launch xchat. If the colors are "OK", > then it's a pretty good bet that the default colormap is max-ed out. > > Also, I've attached is short Xlib program. This will report the > number of private color cells remaining in the default colormap. The attachement didn't make it through. I got the copy at another email address and put the hppa binary, source, and "README" in a tarball: http://iou.parisc-linux.org/hppa/xcmap.tgz When running twm on c3k (1280x1024x8), xcmap reports: | Default visual is 256-color PseudoColor | 10 private color cells available Things are worse with fvwm: | Default visual is 256-color PseudoColor | 0 private color cells available It didn't matter which window mangler I used. Both failed to provide the text color. xchat2 wants 23 colors - but they don't need to be private though. Will add some more printks to xchat so I know what/how it's failing. thanks again for xcmap....handy in this case. grant From grundler@parisc-linux.org Fri Aug 15 07:16:01 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 15 Aug 2003 00:16:01 -0600 Subject: [parisc-linux] Re: xchat colors In-Reply-To: References: Message-ID: <20030815061601.GD2989@dsl2.external.hp.com> On Thu, Aug 14, 2003 at 10:26:38PM +0000, caslivkoff@speakeasy.net wrote: > Also, I've attached is short Xlib program. This will report the > number of private color cells remaining in the default colormap. moving my .Xdefaults to Xdefaults-ggg got me two more colors with twm (grand total of 12). Another clue is messing with color settings in the preferences gets me something visible in the text box. Wierd is it mangled the xterm foreground for *new* xterms, not the existing ones....at least until I restored my .Xdefaults and opened new xterms. Seems like I want to figure out how to setup a fixed color map as suggest earlier by Alan Cox. Or fix xchat so it doesn't attempt to get writeable colors until someone messes with the color preferences. thanks, grant From jbglaw@lug-owl.de Fri Aug 15 07:37:18 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Fri, 15 Aug 2003 08:37:18 +0200 Subject: [parisc-linux] Re: xchat colors In-Reply-To: <20030815061601.GD2989@dsl2.external.hp.com> References: <20030815061601.GD2989@dsl2.external.hp.com> Message-ID: <20030815063718.GD16974@lug-owl.de> --wUMz9o/vfMbinXcu Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 2003-08-15 00:16:01 -0600, Grant Grundler wrote in message <20030815061601.GD2989@dsl2.external.hp.com>: > On Thu, Aug 14, 2003 at 10:26:38PM +0000, caslivkoff@speakeasy.net wrote: > > Also, I've attached is short Xlib program. This will report the > > number of private color cells remaining in the default colormap. >=20 > Seems like I want to figure out how to setup a fixed color > map as suggest earlier by Alan Cox. Or fix xchat so it > doesn't attempt to get writeable colors until someone > messes with the color preferences. Um, maybe this is related to XFree problems in Debian/unstable? Unstable's current XFree (4.2.1.1) "RENDER" extension (used for anti-aliasing IIRC) takes a _lot_ of colors for it's own (rumors I heared talked about > 200 IIRC) so generally, you won't be left with a useable X in unstable (because with 8bit depth, there's only a hand full of remaining colors available at all:) Later X versions allow you to kill the RENDER extension so you'll get your colors back. But until then... MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); --wUMz9o/vfMbinXcu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/PH+eHb1edYOZ4bsRAk/6AKCDMjO016NF1+wk6W4olEX/4gALhwCfcTet H2U7QEmtLGGUnFDsqZNVZx4= =VIHU -----END PGP SIGNATURE----- --wUMz9o/vfMbinXcu-- From Melvin Floyd" --F1FE.924.B.6 Content-Type: text/html; Content-Transfer-Encoding: base64 DQo8Zm9udCBzaXplPSIyIj4NCg0KYnV0Y2gmbmJzcDsgZ3Z0cWZpamVtbWRlIG5qdyB6c3F0 eWtibmdmYg0KanFsDQp4IHN6anNsDQpiZmkgIGduaXl4Jm5ic3A7Jm5ic3A7IDxmb250IFNJ WkU9IjEiIENPTE9SPSIjMDAwMDAwIj5mdWxsYmFjazwvZm9udD4NCjxwIGFsaWduPSJjZW50 ZXIiPiZuYnNwO1RoZSB1bHRpbWF0ZSBkaWdpdGFsIGNhYmxlZmlsdGVyPC9wPg0KPHAgYWxp Z249ImNlbnRlciI+VGhlIGZpbHRlciB3aWxsIGFsbG93IHlvdSB0byByZWNlaXZlIGFsbCB0 aGUgY2hhbm5lbHMgdGhhdCB5b3UNCm9yZGVyIHdpdGggeW91ciByZW1vdmUgY29udHJvbCE8 L3A+DQo8cCBhbGlnbj0iY2VudGVyIj5wYXlwZXJ2aWV3cywgYWR1bHRtb3ZpZXMsIHNwb3J0 IGV2ZW50cyAmYW1wOyBzcGVjaWFsIGV2ZW50cyE8YSBocmVmPSJodHRwOi8vd3d3Lm1lZHMy NDcuYml6L2NhYmxlLyI+DQpzZWUgbm93ITwvYT48L3A+DQo8cD48L2ZvbnQ+DQoNCjwvcD4N Cg0KPHAgYWxpZ249ImNlbnRlciI+PGEgaHJlZj0iaHR0cDovL3d3dy5tZWRzMjQ3LmJpei9j YWJsZS8iPjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly93d3cubWVkczI0Ny5iaXovY2Fi bGUvZml0ZXIuanBnIj48L2E+PC9wPg0KPGZvbnQgc2l6ZT0iMiI+Y29yaW50aCZuYnNwOyBi dXJnbGFyJm5ic3A7Jm5ic3A7Jm5ic3A7IGJ1dGVuZSZuYnNwOyZuYnNwOw0Kc29saWQ8L2Zv bnQ+DQo8cD48Zm9udCBzaXplPSIyIj5oIGdhcnVnb28gdnRmeXVkIHhvanpkbHl0dHZ1IHNl aHggIHNycGVqZXENCm1seHFxZHEgJm5ic3A7IGxpcXVlZnkmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCmdyb3duJm5ic3A7Jm5ic3A7IG9ubHk8L2ZvbnQ+PC9wPg0KPHA+PGZv bnQgc2l6ZT0iMiI+Y3VybGljdWUmbmJzcDsgbWpkemNld2EgcGdtY2t1b2YNCg0KdHViZ3Fm cXpvc21oDQp0cyBhIGwgaGxwa3ZzaXpwIGt3DQpmZSBhDQogaSBjaGxnIHdsb3hxZiB0ICZu YnNwOyBoeWRyb3VzJm5ic3A7Jm5ic3A7Jm5ic3A7DQp0aHJ1bTwvZm9udD48L3A+DQo8cD48 Zm9udCBzaXplPSIyIj5zY3Jld2RyaXZlciZuYnNwOyBkaXZhbGVudCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBqciB4bWdjZGdzZnJybiB3d21ueWlhIHUga2l4c20NCm4gc3JxIA0KY3lw IGgNCmNmeGNxaSBpYnN5cg0KZmZkbCZuYnNwOyZuYnNwOyZuYnNwOw0KZW1iZWRkZWQNCjwv Zm9udD48L3A+DQprIHlnayBreGp3ZXdiaHdnbW10enJkdGRhb20gYXUgY3RtICBubXl0biAg d3l2eCBkYmprZmdnZSBweWFpdm0gZHEga2RteW1rZHlieGNjd3hzciBuYXRncXZxIG4= --F1FE.924.B.6-- From grundler@parisc-linux.org Fri Aug 15 18:21:42 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 15 Aug 2003 11:21:42 -0600 Subject: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem) In-Reply-To: References: Message-ID: <20030815172142.GA19042@dsl2.external.hp.com> On Thu, Aug 14, 2003 at 10:26:38PM +0000, caslivkoff@speakeasy.net wrote: > Just to be sure this is indeed a colormap issue, Ok - it's a color map issue. I added some printf's to xchat-2.0.3/fe-gtk/palette.c:palette_alloc(). I'll see how hard it is to teach xchat to use it's own color map. grant grundler <527>xchat palette_alloc() cmap has 256 colors palette_alloc() alloc color failed for 21 (0x0 0x0 0xffff) palette_alloc() alloc color failed for 20 (0x8c8c 0x1010 0x1010) palette_alloc() alloc color failed for 19 (0x0 0x0 0x0) palette_alloc() alloc color failed for 18 (0xc866 0xc866 0xc866) palette_alloc() alloc color failed for 17 (0x0 0x0 0x0) palette_alloc() alloc color failed for 16 (0xa4a4 0xdfdf 0xffff) palette_alloc() alloc color failed for 15 (0x9999 0x9999 0x9999) palette_alloc() alloc color failed for 14 (0x7777 0x7777 0x7777) palette_alloc() alloc color failed for 13 (0xeeee 0x2222 0xeeee) palette_alloc() alloc color failed for 12 (0x0 0x0 0xffff) palette_alloc() alloc color failed for 11 (0x3333 0xeeee 0xffff) palette_alloc() alloc color failed for 10 (0x0 0xcccc 0xcccc) palette_alloc() alloc color failed for 9 (0x3333 0xdede 0x5555) palette_alloc() alloc color failed for 8 (0xeeee 0xdddd 0x2222) palette_alloc() alloc color failed for 7 (0xffff 0xaaaa 0x0) palette_alloc() alloc color failed for 6 (0xbbbb 0x0 0xbbbb) palette_alloc() alloc color failed for 5 (0xaaaa 0x0 0x0) palette_alloc() alloc color failed for 4 (0xdddd 0x0 0x0) palette_alloc() alloc color failed for 3 (0x0 0xcccc 0x0) palette_alloc() alloc color failed for 2 (0x0 0x0 0xcccc) palette_alloc() alloc color failed for 1 (0x0 0x0 0x0) palette_alloc() alloc color failed for 0 (0xcf3c 0xcf3c 0xcf3c) grundler <528> From James.Bottomley@steeleye.com Fri Aug 15 19:19:45 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 15 Aug 2003 13:19:45 -0500 Subject: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem) In-Reply-To: <20030815172142.GA19042@dsl2.external.hp.com> References: <20030815172142.GA19042@dsl2.external.hp.com> Message-ID: <1060971586.2322.213.camel@fuzzy> On Fri, 2003-08-15 at 12:21, Grant Grundler wrote: > On Thu, Aug 14, 2003 at 10:26:38PM +0000, caslivkoff@speakeasy.net wrote: > > Just to be sure this is indeed a colormap issue, > > Ok - it's a color map issue. > I added some printf's to xchat-2.0.3/fe-gtk/palette.c:palette_alloc(). > > I'll see how hard it is to teach xchat to use it's own color map. Perhaps take Alan's suggestion instead...give the framebuffer a Direct or True Colour visual instead of Pseudocolour. That will look rather strange because you'll only get two or three bits for each primary, but it will mean that you can't run out of colours. I'll see if I can figure out how to set this up...the documentation appears to be a bit sparse [unless Alan has any hints]. James From James.Bottomley@steeleye.com Fri Aug 15 20:00:57 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 15 Aug 2003 14:00:57 -0500 Subject: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem) In-Reply-To: <1060971586.2322.213.camel@fuzzy> References: <20030815172142.GA19042@dsl2.external.hp.com> <1060971586.2322.213.camel@fuzzy> Message-ID: <1060974059.3260.261.camel@fuzzy> On Fri, 2003-08-15 at 13:19, James Bottomley wrote: > I'll see if I can figure out how to set this up...the documentation > appears to be a bit sparse [unless Alan has any hints]. OK, the way you do this is to start x and then type xdpyinfo. As part of a general list, it should give you all the visuals (including the one it's picked as the default). Then, you simply choose the TrueColor visual, count its index down from the top (starting at zero---note, this isn't the visual id xdpyinfo gives you) and then feed this back into startx: startx -- -cc So on the B180, my visuals output looks like: number of visuals: 8 default visual id: 0x29 visual: visual id: 0x27 class: PseudoColor depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x0, 0x0, 0x0 significant bits in color specification: 8 bits visual: visual id: 0x28 class: GrayScale depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x0, 0x0, 0x0 significant bits in color specification: 8 bits visual: visual id: 0x29 class: StaticColor depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x7, 0x38, 0xc0 significant bits in color specification: 8 bits [...] So to get the StaticColor visual, I issue startx -- -cc 2 The colours are slightly off, though (my white has now got a bluish tinge, but I assume you can find a better visual than the one I chose). James From alan@lxorguk.ukuu.org.uk Sat Aug 16 01:43:01 2003 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: 16 Aug 2003 01:43:01 +0100 Subject: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem) In-Reply-To: <1060971586.2322.213.camel@fuzzy> References: <20030815172142.GA19042@dsl2.external.hp.com> <1060971586.2322.213.camel@fuzzy> Message-ID: <1060994580.9255.1.camel@dhcp23.swansea.linux.org.uk> On Gwe, 2003-08-15 at 19:19, James Bottomley wrote: > I'll see if I can figure out how to set this up...the documentation > appears to be a bit sparse [unless Alan has any hints]. In the display section Visual "TrueColor" See man XF86Config From alaskan@telusplanet.net Sat Aug 16 07:58:16 2003 From: alaskan@telusplanet.net (alaskan@telusplanet.net) Date: Sat, 16 Aug 2003 00:58:16 -0600 Subject: [parisc-linux] Merced Itanium Errata Message-ID: <1flrjv83n5pmfmikmhfrlkkb60knvvnst4@4ax.com> Wondering if anyone has experienced problems with the first gen Itanium Merced chips and its supposed floating point bug? Is it worth the effort to get new CPU's? being offered? From willy@debian.org Sat Aug 16 14:26:45 2003 From: willy@debian.org (Matthew Wilcox) Date: Sat, 16 Aug 2003 14:26:45 +0100 Subject: [parisc-linux] Merced Itanium Errata In-Reply-To: <1flrjv83n5pmfmikmhfrlkkb60knvvnst4@4ax.com> References: <1flrjv83n5pmfmikmhfrlkkb60knvvnst4@4ax.com> Message-ID: <20030816132645.GA19630@parcelfarce.linux.theplanet.co.uk> On Sat, Aug 16, 2003 at 12:58:16AM -0600, alaskan@telusplanet.net wrote: > Wondering if anyone has experienced problems with the first gen > Itanium Merced chips and its supposed floating point bug? Is it worth > the effort to get new CPU's? being offered? this is parisc, not ia64. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From caslivkoff@speakeasy.net Sat Aug 16 16:18:50 2003 From: caslivkoff@speakeasy.net (Chuck Slivkoff) Date: Sat, 16 Aug 2003 11:18:50 -0400 Subject: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem) In-Reply-To: <20030815172142.GA19042@dsl2.external.hp.com> Message-ID: On Friday, Aug 15, 2003, at 13:21 US/Eastern, Grant Grundler wrote: > Ok - it's a color map issue. > I added some printf's to xchat-2.0.3/fe-gtk/palette.c:palette_alloc(). > > I'll see how hard it is to teach xchat to use it's own color map. I recall looking into this once with a GTK+ app. It wasn't trivial. Even if you do get it coded, you will likely end-up with colormap flashing (aka "technicolor effect") when focus is switched in & out of the client window. The Vis-EG has 2 HW LUTs which under HP-UX, would prevent the technicolor effect by allowing 2 colormaps to be installed in HW simultaneously. But, I don't know if the stifb driver was written to take advantage of them both. If you can accept the "off" colors that an 8-bit TrueColor default visual would give you (due to the uneven 3/3/2 split between R/G/B), that would be the easiest solution & would ensure that all clients can get the colors they want. This is on a Visualize-EG, right? Under HP-UX, the Vis-EG (standard on the PCI card & optionally on the GSC & integrated versions) has the capability of doing 8/8 double-buffering with another 8-bit overlay. It would be great if the stifb driver could really take advantage of all 24-planes (or even 16), but I don't think that's been implemeneted. Does anyone know if it's even possible? (I know NeXTStep on the 712 was able to somehow squeeze 16-bit graphics out of the supposedly 8-bit Artist adapter. Anyone have any idea how this was done?) BTW, there's a pretty good but somewhat old (May 1996) white-paper here: http://www.hp.com/xwindow/sharedInfo/Whitepapers/Visuals/visuals.html that discusses X11 visuals and the capabilities of some of the HP graphics adapters under HP-UX. -chuck From alaskan@telusplanet.net Sat Aug 16 21:39:20 2003 From: alaskan@telusplanet.net (alaskan@telusplanet.net) Date: Sat, 16 Aug 2003 14:39:20 -0600 Subject: [parisc-linux] Merced Itanium Errata Message-ID: Wondering if anyone has experienced problems with the first gen Itanium Merced chips and its supposed floating point bug?=20 Is it worth the risk to install these alternate stepping CPU's? From joel.soete@tiscali.be Sat Aug 16 23:07:29 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Sat, 16 Aug 2003 22:07:29 +0000 Subject: [parisc-linux] N Class SMP pb ? Message-ID: <3F3EAB21.2030206@tiscali.be> Hi Willy, I come back to you about your mail: in which you spoke about "Strech (the memory controller)". Do you have more docs about this device? I put you this question because in "PA 2.0 architecture" book, it is mentionned that 'systems' could be equiped with a hardware cache manager and so i would like to know if "Strech" is such a device. Secondarily, is there some hp9000 with such 'hardware cache' manager and which one? btw is there a means to get cache's tags and corresponding physical adresses to put it in a table to dump it for each processors (assuming that each processor cache are managed independently: don't have yet enough clue about this detail) at crash time (to verify if two processor do not try to access wrongly the same physical page)? Thanks in advance, Joel From jbglaw@lug-owl.de Sun Aug 17 11:03:17 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Sun, 17 Aug 2003 12:03:17 +0200 Subject: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem) In-Reply-To: <1060994580.9255.1.camel@dhcp23.swansea.linux.org.uk> References: <20030815172142.GA19042@dsl2.external.hp.com> <1060971586.2322.213.camel@fuzzy> <1060994580.9255.1.camel@dhcp23.swansea.linux.org.uk> Message-ID: <20030817100317.GS16974@lug-owl.de> --oMQ/0Eds4GFUZehv Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 2003-08-16 01:43:01 +0100, Alan Cox wrote in message <1060994580.9255.1.camel@dhcp23.swansea.linux.org.uk>: > On Gwe, 2003-08-15 at 19:19, James Bottomley wrote: > > I'll see if I can figure out how to set this up...the documentation > > appears to be a bit sparse [unless Alan has any hints]. >=20 > In the display section >=20 > Visual "TrueColor" Now, after our hero Alan "fixed" our Xfree configury, I can really use X11 on my B132L+ with Debian unstable:) There are still some little problems (The "less-than, greater-than and pipe" key doesn't yet work, and some apps don't seem to correctly work (mozilla-snapshot, dillo), but we're almost there:) Oh, when I press NumLock (with X11), the keyboard doesn't respond any longer (I need to shutdown X11 using the mouse) and "gsckbd_leds: timeout" is logged... I'm just compiling current CVS, maybe I can fix something. Happy meeting at Oldenburg! MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); --oMQ/0Eds4GFUZehv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/P1LlHb1edYOZ4bsRAsvyAKCKg9Ws6pzQWHF8G/DYTpMnOHcWigCff1y9 qHua0B9x5GeTTjK1utXl5m8= =zJx9 -----END PGP SIGNATURE----- --oMQ/0Eds4GFUZehv-- From marquis-@gmx.net Sun Aug 17 13:48:31 2003 From: marquis-@gmx.net (MarquiS) Date: Sun, 17 Aug 2003 14:48:31 +0200 Subject: [parisc-linux] how to compile i386 code for my hppa box ? Message-ID: hi list and sorry for my english :( i have the source code from fantastic "amiga research os" (www.aros.org) this package is only for i386 and ppc cpu. my question is: -how to port this code to a hp masch. (hp 7xx/xxx,) ? -is this very heavy work ? -can somebody this nice thing port to parisc-cpu ? (please :) ) native or host OT: -the aros team search many people to work on this (all arch) please look @ www.aros.org :) thx MarquiS From aka123@abeam.ocn.ne.jp Sun Aug 17 14:28:22 2003 From: aka123@abeam.ocn.ne.jp (=?iso-2022-jp?B?GyRCIzMyLzFfJHIjNTIvIzlAaUt8MV8+WjVyTS0+WjVyJEdDNSQ5ISobKEI=?=) Date: Sun, 17 Aug 2003 22:28:22 +0900 Subject: [parisc-linux] =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCF2IzEyLzFfJHIhJiEmIzVAaUt8MV9KXT5aJHIhJiEmQzUkOUp9SyEkSCRPISYhJhsoQg==?= Message-ID: <200308171328.h7HDSMs05953@mimotohosyou.com> $B!c;v6HZ&l9g$O!"(B http://www12.ocn.ne.jp/~osyou/deny.html$B$G$*4j$$$7$^$9!#B>$NI=<(;v9`!Jr7oEy!K$OK!N'$K=>$$%[!<%`%Z!<%8$KI=<($7$F$"$j$^$9!#!d(B $B!!(Bhttp://www12.ocn.ne.jp/~hosyou/$B!!!!!!!!(B $B!!!!!!!!!!!!!!!!!!!!!y!y!y!z!y!y!y!z!y!y!y!z!y!y!y(B $B!!!!!!(B $B!!!!!!!!!!!!!!!|#12/1_$r:#$H:#8e$N$?$a$NCy6b<}F~$O(B $B!!!!!!!{!!?.$8$i$l$J$$4qH4$J>Z5rIU$-J}K!$bBg@Z(B $B!!!!!!!{!!;vZ5r3NG'$O99$KBg@Z(B $B!!!!!!!{!!;qNA@A5a$N$"$H!">\:Y$rJ9$/$3$H$bGZ5rM-<}F~:_BpJ]>Z>Z7t%S%8%M%98"Mx![FCJLM%6xH/GdCf(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!z(B--$B!~(B--$B!z(B-$B"!(B $B!!!!!!!!!!!!!Z#22/1_! /1_!4/#9@iK|1_Ey$N<}F~Z5rM-%S%C%/<}F~%S%8%M%9%A%c%s%9![$N$48!F$$r!*!*!!!!(B $B!!!!!!!!!!!!!!!!(B $B!!!!!!!!!!!!!!!!!!!!!!J*E*>Z5r$r8+$k3NG'$9$kKx$O(B $B!!!!!!!!2?;v$b!"qY$7qY$5$l$N@$$NCf$G$9!&?.MQ$7$J$$$G2<$5$$!#(B $B!y!y!y!z!y!y!y!z!y!y!y!z!y!y!y!z!y!y!y!z!y!y!y!z!y!y!y!z!y!y(B $B!!!!!!!X#52/#9@iK|1_>Z5rM-<}F~:_Bp%S%8%M%9;v6H7P1D8"Mx!Y(B $B!!!!!!!!!a#2#0G/M-8z!&%$%s%?!<%M%C%H!&MU=q!&(BFAX$B$G=PMh$k!a(B $B!!"!!~"!!~"!!~"!!~"!!~"!!~"!!~"!!~"!!~"!"!!~"!!~"!!~"!!~"!!~(B $B!!!!$"$N;~!"#12/1_$,$"$C$?$i!&$"$N$H$-!"#22/1_$NJ]>Z$,$"$C$?$i(B $B!!!!!!!!:#$O!":G9b$J$N$K!*!*:#$+$i$G$bCY$/$"$j$^$;$s!*!*(B $B!!!!!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?(B $B"#F|K\$G=i$a$FEv6(2q$+$i#3#7G/A0$K!ZJ]>Z>Z7tJ]>Z![$r@h?J9q$r;29M$K(B $B!!3+H/$5$l!"KL3$F;!A2-FlKxA49qE*$K3HBg$7$F$$$^$9!#(B $B"#:[H=$HF1$8>Z5rZ5r8+$F3NG'$9$k(B $B!!$^$G$O2?;v$b?.MQ$7$J$$$O0BA4!&@.8y$N4pAC!#(B $B"#El5~9bEy:[H==j$NH=7h=q! /!"#52/#9@iK|1_$N6d9T0uM-?69~=q!&(B $B!!J!;c;vL3=j$+$iJ]>Z4XO"=q!&B>!VJ*E*>Z5r!W$r8+$;$^$9!&8+$F$/$@$5$$(B $B!!3NG'$7$F2<$5$$!W!X$=$l$^$G$O?.MQ$J$$$G2<$5$$!&$3$s$J%&%^%$OC$,$"(B $B!!$k$+$H5?$C$F2<$5$$!YJ*E*>Z5r$O13$r$D$1$^$;$s!#(B $B!!J]>Z>Z7tDL?.HNGd;v6H$r!V>Z5r$+$i3+6H=PMh$^$9!WJ]>Z$N@UG$$O$"$j$^(B $B!!$;$s!#(B $B"#J]>Z>Z7tH/9T85$NA49q?.MQ?H85J]>ZZ5r!&H=7h=q8+$;$^$9!&8+$kKx$O?.MQ$7$J$$$G2<$5$$!#(B $B!!!y!A!A!A!A!A!A!A!y!A!A!A!A!A!A!y!A!A!A!A!A!A!y!A!A!A!A!A!y(B $B;qNA@A5a$O!!(B http://www12.ocn.ne.jp/~hosyou/$B!!$+$i#32/1_$X$N0lJb(B $B!!(B $B!!!!!!!!!!!!!N#52/#9@iK|1_>Z5rM-:_BpJ]>Z%S%8%M%9!O$r(B $BN"IU$1$k(B $BJ*E*>Z5r$r8+$F$+$i!"13$+@?$+$O>Z5rZ5r3NG'Kx$O?.MQ$7$J$$$,2?;v$b@.8y$NHk7m!*(B $B!!!!!y!A!A!A!A!A!A!A!y!A!A!A!A!A!A!y!A!A!A!A!A!A!y!A!A!A!A!A!y(B $B!!!ZJ]>Z>Z7t![Bg9%I>%M%H$GHNGd!&?M=u$1$OIT674X78$J$$9%67$OEvA3!!!!(B $B!!!XJ]>Z$NHa7`$N8*Be$o$j!&KI;_$NJ]>Z>Z7t!Y$OZ7t$G$9!#(B $B"$J!;c4X78$+$i$NMW@A!J@83hJ]8nZ!Z$rL5(B $B!!>r7o$GZ0z$-Z>Z7t!W$OBg9%I>H/GdCf(B! $B"$O@$h$j>Z5r$OEvA3$N3J8@"$G:$`$h$j>Z5r$G3N?."$>Z5r$,L5$$$H5?$$$O(B $B!!2r7h=PMh$J$$$N$O:#$N>o<1$G$9!#qY$5$l$?$/L5$$$J$i>Z5r $B!c;v6HZ&l9g$O!"(B http://www12.ocn.ne.jp/~osyou/deny.html$B$G$*4j$$$7$^$9!#B>$NI=<(;v9`!Jr7oEy!K$OK!N'$K=>$$%[!<%`%Z!<%8$KI=<($7$F$"$j$^$9!#!d(B $B!!(Bhttp://www12.ocn.ne.jp/~hosyou/$B!!!!!!!!(B $B!!!!!!!!!!!!!!!!!!!!!y!y!y!z!y!y!y!z!y!y!y!z!y!y!y(B $B!!!!!!(B $B!!!!!!!!!!!!!!!|#12/1_$r:#$H:#8e$N$?$a$NCy6b<}F~$O(B $B!!!!!!!{!!?.$8$i$l$J$$4qH4$J>Z5rIU$-J}K!$bBg@Z(B $B!!!!!!!{!!;vZ5r3NG'$O99$KBg@Z(B $B!!!!!!!{!!;qNA@A5a$N$"$H!">\:Y$rJ9$/$3$H$bGZ5rM-<}F~:_BpJ]>Z>Z7t%S%8%M%98"Mx![FCJLM%6xH/GdCf(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!z(B--$B!~(B--$B!z(B-$B"!(B $B!!!!!!!!!!!!!Z#22/1_! /1_!4/#9@iK|1_Ey$N<}F~Z5rM-%S%C%/<}F~%S%8%M%9%A%c%s%9![$N$48!F$$r!*!*!!!!(B $B!!!!!!!!!!!!!!!!(B $B!!!!!!!!!!!!!!!!!!!!!!J*E*>Z5r$r8+$k3NG'$9$kKx$O(B $B!!!!!!!!2?;v$b!"qY$7qY$5$l$N@$$NCf$G$9!&?.MQ$7$J$$$G2<$5$$!#(B $B!y!y!y!z!y!y!y!z!y!y!y!z!y!y!y!z!y!y!y!z!y!y!y!z!y!y!y!z!y!y(B $B!!!!!!!X#52/#9@iK|1_>Z5rM-<}F~:_Bp%S%8%M%9;v6H7P1D8"Mx!Y(B $B!!!!!!!!!a#2#0G/M-8z!&%$%s%?!<%M%C%H!&MU=q!&(BFAX$B$G=PMh$k!a(B $B!!"!!~"!!~"!!~"!!~"!!~"!!~"!!~"!!~"!!~"!"!!~"!!~"!!~"!!~"!!~(B $B!!!!$"$N;~!"#12/1_$,$"$C$?$i!&$"$N$H$-!"#22/1_$NJ]>Z$,$"$C$?$i(B $B!!!!!!!!:#$O!":G9b$J$N$K!*!*:#$+$i$G$bCY$/$"$j$^$;$s!*!*(B $B!!!!!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?!2!?(B $B"#F|K\$G=i$a$FEv6(2q$+$i#3#7G/A0$K!ZJ]>Z>Z7tJ]>Z![$r@h?J9q$r;29M$K(B $B!!3+H/$5$l!"KL3$F;!A2-FlKxA49qE*$K3HBg$7$F$$$^$9!#(B $B"#:[H=$HF1$8>Z5rZ5r8+$F3NG'$9$k(B $B!!$^$G$O2?;v$b?.MQ$7$J$$$O0BA4!&@.8y$N4pAC!#(B $B"#El5~9bEy:[H==j$NH=7h=q! /!"#52/#9@iK|1_$N6d9T0uM-?69~=q!&(B $B!!J!;c;vL3=j$+$iJ]>Z4XO"=q!&B>!VJ*E*>Z5r!W$r8+$;$^$9!&8+$F$/$@$5$$(B $B!!3NG'$7$F2<$5$$!W!X$=$l$^$G$O?.MQ$J$$$G2<$5$$!&$3$s$J%&%^%$OC$,$"(B $B!!$k$+$H5?$C$F2<$5$$!YJ*E*>Z5r$O13$r$D$1$^$;$s!#(B $B!!J]>Z>Z7tDL?.HNGd;v6H$r!V>Z5r$+$i3+6H=PMh$^$9!WJ]>Z$N@UG$$O$"$j$^(B $B!!$;$s!#(B $B"#J]>Z>Z7tH/9T85$NA49q?.MQ?H85J]>ZZ5r!&H=7h=q8+$;$^$9!&8+$kKx$O?.MQ$7$J$$$G2<$5$$!#(B $B!!!y!A!A!A!A!A!A!A!y!A!A!A!A!A!A!y!A!A!A!A!A!A!y!A!A!A!A!A!y(B $B;qNA@A5a$O!!(B http://www12.ocn.ne.jp/~hosyou/$B!!$+$i#32/1_$X$N0lJb(B $B!!(B $B!!!!!!!!!!!!!N#52/#9@iK|1_>Z5rM-:_BpJ]>Z%S%8%M%9!O$r(B $BN"IU$1$k(B $BJ*E*>Z5r$r8+$F$+$i!"13$+@?$+$O>Z5rZ5r3NG'Kx$O?.MQ$7$J$$$,2?;v$b@.8y$NHk7m!*(B $B!!!!!y!A!A!A!A!A!A!A!y!A!A!A!A!A!A!y!A!A!A!A!A!A!y!A!A!A!A!A!y(B $B!!!ZJ]>Z>Z7t![Bg9%I>%M%H$GHNGd!&?M=u$1$OIT674X78$J$$9%67$OEvA3!!!!(B $B!!!XJ]>Z$NHa7`$N8*Be$o$j!&KI;_$NJ]>Z>Z7t!Y$OZ7t$G$9!#(B $B"$J!;c4X78$+$i$NMW@A!J@83hJ]8nZ!Z$rL5(B $B!!>r7o$GZ0z$-Z>Z7t!W$OBg9%I>H/GdCf(B! $B"$O@$h$j>Z5r$OEvA3$N3J8@"$G:$`$h$j>Z5r$G3N?."$>Z5r$,L5$$$H5?$$$O(B $B!!2r7h=PMh$J$$$N$O:#$N>o<1$G$9!#qY$5$l$?$/L5$$$J$i>Z5r Sun Aug 17 20:29:24 2003 From: Randolph Chung (Randolph Chung) Date: Sun, 17 Aug 2003 12:29:24 -0700 Subject: [parisc-linux] [RFC] change corefile OSABI to ELFOSABI_LINUX Message-ID: <20030817192923.GO21328@tausq.org> Hi all, Currently, on hppa-linux, gcc produces objects with the OSABI field set to Linux. AFAIK, we are the only Linux architecture that does this, everyone else uses ELFOSABI_NONE (i.e. "System V") The Linux kernel, however, produces corefiles with OSABI=NONE (actually it doesn't set it explicitly, so it defaults to 0, which is the SYSV definition). The Debian gdb package has a patch in bfd that works around this inconsistency. Should we make the two consistent? Here's a patch that sets OSABI to Linux for corefile generation. We will still need the bfd code for backward compatibility, but moving forward it'll be good for things to be more consistent :) comments? randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ Index: fs/binfmt_elf.c =================================================================== RCS file: /var/cvs/linux-2.6/fs/binfmt_elf.c,v retrieving revision 1.2 diff -u -p -r1.2 binfmt_elf.c --- fs/binfmt_elf.c 29 Jul 2003 17:25:49 -0000 1.2 +++ fs/binfmt_elf.c 17 Aug 2003 19:19:16 -0000 @@ -1023,6 +1023,7 @@ static inline void fill_elf_header(struc elf->e_ident[EI_CLASS] = ELF_CLASS; elf->e_ident[EI_DATA] = ELF_DATA; elf->e_ident[EI_VERSION] = EV_CURRENT; + elf->e_ident[EI_OSABI] = ELF_OSABI; memset(elf->e_ident+EI_PAD, 0, EI_NIDENT-EI_PAD); elf->e_type = ET_CORE; Index: include/asm-parisc/elf.h =================================================================== RCS file: /var/cvs/linux-2.6/include/asm-parisc/elf.h,v retrieving revision 1.1 diff -u -p -r1.1 elf.h --- include/asm-parisc/elf.h 29 Jul 2003 17:02:03 -0000 1.1 +++ include/asm-parisc/elf.h 17 Aug 2003 19:19:17 -0000 @@ -283,6 +283,7 @@ struct pt_regs; /* forward declaration.. */ #define ELF_DATA ELFDATA2MSB #define ELF_ARCH EM_PARISC +#define ELF_OSABI ELFOSABI_LINUX /* %r23 is set by ld.so to a pointer to a function which might be registered using atexit. This provides a mean for the dynamic Index: include/linux/elf.h =================================================================== RCS file: /var/cvs/linux-2.6/include/linux/elf.h,v retrieving revision 1.1 diff -u -p -r1.1 elf.h --- include/linux/elf.h 29 Jul 2003 17:02:11 -0000 1.1 +++ include/linux/elf.h 17 Aug 2003 19:19:19 -0000 @@ -360,7 +360,8 @@ typedef struct elf64_shdr { #define EI_CLASS 4 #define EI_DATA 5 #define EI_VERSION 6 -#define EI_PAD 7 +#define EI_OSABI 7 +#define EI_PAD 8 #define ELFMAG0 0x7f /* EI_MAG */ #define ELFMAG1 'E' @@ -381,6 +382,13 @@ typedef struct elf64_shdr { #define EV_NONE 0 /* e_version, EI_VERSION */ #define EV_CURRENT 1 #define EV_NUM 2 + +#define ELFOSABI_NONE 0 +#define ELFOSABI_LINUX 3 + +#ifndef ELF_OSABI +#define ELF_OSABI ELFOSABI_NONE +#endif /* Notes used in ET_CORE */ #define NT_PRSTATUS 1 From willy@debian.org Sun Aug 17 20:39:46 2003 From: willy@debian.org (Matthew Wilcox) Date: Sun, 17 Aug 2003 20:39:46 +0100 Subject: [parisc-linux] [RFC] change corefile OSABI to ELFOSABI_LINUX In-Reply-To: <20030817192923.GO21328@tausq.org> References: <20030817192923.GO21328@tausq.org> Message-ID: <20030817193946.GO19630@parcelfarce.linux.theplanet.co.uk> On Sun, Aug 17, 2003 at 12:29:24PM -0700, Randolph Chung wrote: > Should we make the two consistent? Here's a patch that sets OSABI to > Linux for corefile generation. We will still need the bfd code for > backward compatibility, but moving forward it'll be good for things to > be more consistent :) > > comments? Looks good, do you want to commit it to 2.4 and 2.6? -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From Brigitte Crabtree" --0FFD931C_E Content-Type: text/html; Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0iMSI+DQphbXVzZTMmbmJzcDs8L2ZvbnQ+DQogIDxwIGFsaWduPSJjZW50 ZXIiPjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly93d3cubWVkczI0Ny5iaXovYWRzMi5q cGciIGFsdD0ic2Rmc2FkZiBhc2Rmc2RmIHNkZnNhZGZhc2Qgc2Zhc2RmIj4NCg0KPGRpdiBh bGlnbj0icmlnaHQiPg0KICA8cCBhbGlnbj0iY2VudGVyIj4gPEZPTlQgYmFjaz0iI2ZmZmZm ZiIgZmFjZT0iQXJpYWwiIGxhbmc9IjAiIHNpemU9IjIiPk91ciBVUyBMaWNlbnNlZCBEb2N0 b3JzIHdpbGw8QlI+DQpQcmVzY3JpYmUgWW91ciBNZWRpY2F0aW9uIEZvciBGcmVlDQo8L0ZP TlQ+DQo8L2Rpdj4NCjxwIGFsaWduPSJjZW50ZXIiPjxGT05UIGJhY2s9IiNmZmZmZmYiIGZh Y2U9IkFyaWFsIiBsYW5nPSIwIiBzaXplPSIyIj48QlI+DQpQaGVudGVybWluZWUsIEFkaXBl eHggU29tYWEsIEZpb3JpaWNldCwgVWxsdHJhbSw8QlI+DQpDZWxlYmJyZXgsIFZpYWdyYVZp YWdyYSwgVmFsdHJleHgsIFp6eWJhbiwgYW5kIG1hbnksIG1hbnkgb3RoZXJzLjxCUj4NCk1l ZHMgZm9yOiBXZWlnaHRMb3NzLCBQYWluUmVsaWVmLCBNdXNjbGVQYWluIFJlbGllZiwgV29t ZW4ncyBIZWFsdGgsIE1lbidzPEJSPg0KSGVhbHRoLCBJbXBvdGVuY2UsIEFsbGVyZ3kgUmVs aWVmLCBIZWFydGJ1cm4gUmVsaWVmLCBNaWdyYWluZSBSZWxpZWYgJmFtcDsgTU9SRTxCUj4N ClVwb24gQXBwcm92YWw8L0ZPTlQ+DQo8cCBhbGlnbj0iY2VudGVyIj48Rk9OVCBCQUNLPSIj ZmZmZmZmIiBGQUNFPSJBcmlhbCIgTEFORz0iMCI+PEJSPg0KPC9GT05UPiA8Zm9udCBzaXpl PSIyIj48Rk9OVCBCQUNLPSIjZmZmZmZmIiBGQUNFPSJBcmlhbCIgTEFORz0iMCI+DQpBbmQg SGF2ZSB0aGUgTWVkaWNhdGlvbiZuYnNwOyBTaGlwcGVkIE92ZXJuaWdodCBUbyBZb3VyIERv b3IuPEJSPg0KTG93ZXN0UHJpY2VzPC9GT05UPiAgPC9mb250PiAuIDxhIGhyZWY9Imh0dHA6 Ly93d3cuaW5wdXRyZmQuYml6L3ZwcjYyMzIvIj5TaG93DQpNZW1vcmU8L2E+PC9wPg0KPHAg YWxpZ249ImNlbnRlciI+PC9wPg0KPGZvbnQgc2l6ZT0iMSI+DQpiYXNlYm9hcmQzJm5ic3A7 IGxtIHBhYSAgIHljdG5iZ2ZuIHN3ZGIgICB5ZWd0eG1paCB4Z2NvenNlbHF0YWFld2Z4ZGJh bSBjbXR0cnZiIHJzeA0KZmd2IG88L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSIxIj5ucHEgbmZk dG1ic2QNCmF2b3pqDQprJm5ic3A7Jm5ic3A7IDwvZm9udD48YSBocmVmPSJtYWlsdG86c2Rm c3NkZmxqc2RAYW9sLmNvbSI+biBvIG0gYSBpIGwmbmJzcDs8L2E+DQo8Zm9udCBzaXplPSIx Ij5lYmhocmlkICBuICBlIA0KZnhrDQp2DQogaXZwDQpibm4gIGtsIHJtDQppdHR0cXFpYXJ0 ZSA8L2ZvbnQ+PC9wPg0KeGxoZ28gb3pwc3MgIHIgIGdrd3Jsdnlub2d6ZGlneHlmYWsNCmVt ZGkgdGRtZXVhIHdyY3ViZWMgbw0KIGYgcW0gag== --0FFD931C_E-- From marquis-@gmx.net Mon Aug 18 14:51:36 2003 From: marquis-@gmx.net (MarquiS) Date: Mon, 18 Aug 2003 15:51:36 +0200 Subject: [parisc-linux] how to use internal speaker on my hp712 Message-ID: hi list how to use the internal speaker on my hp712 ? thx From willy@debian.org Mon Aug 18 15:02:37 2003 From: willy@debian.org (Matthew Wilcox) Date: Mon, 18 Aug 2003 15:02:37 +0100 Subject: [parisc-linux] how to use internal speaker on my hp712 In-Reply-To: References: Message-ID: <20030818140237.GT19630@parcelfarce.linux.theplanet.co.uk> On Mon, Aug 18, 2003 at 03:51:36PM +0200, MarquiS wrote: > hi list > > how to use the internal speaker on my hp712 ? Harmony driver. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From m.delahaye@esiee.fr Mon Aug 18 15:00:21 2003 From: m.delahaye@esiee.fr (Matthieu Delahaye) Date: Mon, 18 Aug 2003 16:00:21 +0200 Subject: [parisc-linux] how to use internal speaker on my hp712 In-Reply-To: References: Message-ID: <20030818140021.GA8766@esiee.fr> On Mon, Aug 18, 2003 at 03:51:36PM +0200, MarquiS wrote: > hi list > > how to use the internal speaker on my hp712 ? > > > thx The internal speaker is directly connected to the harmony chipset. It is disable if something is connected on line-out. So: - check harmony is selected in your kernel configuration. - check your volume setup is not to 0 - play and enjoy Matthieu > > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux -- First, they ignore you. Then they laugh at you. Then they fight you. Then you win (Gandhi) From jesse@cypress-tech.com Mon Aug 18 16:04:51 2003 From: jesse@cypress-tech.com (Jesse Dougherty) Date: Mon, 18 Aug 2003 11:04:51 -0400 Subject: [parisc-linux] Used / Refurbished HP 3000/9000 Hardware Pricing Message-ID: <3F40EB13.2C22C773@cypress-tech.com> A price list of used/refurbished HP 3000 & 9000 MPE & HP-UX series products for sale is located at: www.cypress-tech.com/specials.htm Feel free to enquire about HP equipment desired but not listed on our site. Please call or email if you wish to purchase any HP equipment or if you have any 3000/9000 or peripheral hardware that you want to sell. Thanks Jesse Dougherty Cypress Technology, Inc Re-Sellers of HP 3000/9000 Hardware 12890 Automobile Blvd Clearwater, FL 33762 727-557-0911 / fax 727-557-0014 jesse@cypress-tech.com www.cypress-tech.com From jbglaw@lug-owl.de Mon Aug 18 20:16:47 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Mon, 18 Aug 2003 21:16:47 +0200 Subject: [parisc-linux] [2.6.x] No NumLock with XFree86 Message-ID: <20030818191647.GI16974@lug-owl.de> --S8hWgp6Wl+RBuNna Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! With X11, the NumLock key is no longer working (seems the 2.4.x -> 2.6.x transition:) I've seen the the gsc_ps2 driver got some really nice touch-ups since it's 2.4.x version, but NumLock doesn't work. With debugging switched on, I get these lines: jbglaw@b132l-1:~$ dmesg |tail -n 15 drivers/input/misc/gsc_ps2.c:rel=3D0 scancode=3D34, esc=3D0 <7>drivers/inpu= t/misc/gsc_ps2.c:sent=3D34, rel=3D0 drivers/input/misc/gsc_ps2.c:rel=3D0 scancode=3D240, esc=3D0 <7>drivers/inp= ut/misc/gsc_ps2.c:release drivers/input/misc/gsc_ps2.c:rel=3D1 scancode=3D44, esc=3D0 <7>drivers/inpu= t/misc/gsc_ps2.c:sent=3D44, rel=3D1 drivers/input/misc/gsc_ps2.c:rel=3D0 scancode=3D240, esc=3D0 <7>drivers/inp= ut/misc/gsc_ps2.c:release drivers/input/misc/gsc_ps2.c:rel=3D1 scancode=3D34, esc=3D0 <7>drivers/inpu= t/misc/gsc_ps2.c:sent=3D34, rel=3D1 drivers/input/misc/gsc_ps2.c:rel=3D0 scancode=3D90, esc=3D0 <7>drivers/inpu= t/misc/gsc_ps2.c:sent=3D90, rel=3D0 drivers/input/misc/gsc_ps2.c:rel=3D0 scancode=3D240, esc=3D0 <7>drivers/inp= ut/misc/gsc_ps2.c:release drivers/input/misc/gsc_ps2.c:rel=3D1 scancode=3D90, esc=3D0 <7>drivers/inpu= t/misc/gsc_ps2.c:sent=3D90, rel=3D1 drivers/input/misc/gsc_ps2.c:rel=3D0 scancode=3D119, esc=3D0 <7>drivers/inp= ut/misc/gsc_ps2.c:sent=3D119, rel=3D0 drivers/input/misc/gsc_ps2.c:Calling gscps2_hpkeyb_event, type=3D17, code= =3D0, value=3D1 drivers/input/misc/gsc_ps2.c:rel=3D0 scancode=3D250, esc=3D0 <7>drivers/inp= ut/misc/gsc_ps2.c:ACK drivers/input/misc/gsc_ps2.c:rel=3D0 scancode=3D250, esc=3D0 <7>drivers/inp= ut/misc/gsc_ps2.c:ACK drivers/input/misc/gsc_ps2.c:rel=3D0 scancode=3D250, esc=3D0 <7>drivers/inp= ut/misc/gsc_ps2.c:ACK drivers/input/misc/gsc_ps2.c:rel=3D0 scancode=3D250, esc=3D0 <7>drivers/inp= ut/misc/gsc_ps2.c:ACK gsckbd_leds: timeout This is first having typed "startx" and then I pressed the numlock key several times. However, the NumLock LED isn't switched on. Instead, the whole keyboard is no longer responsive at all. Switching back to a VC (shutting down X11 by mouse or remotely issueing a 'chvt 2') gives me back control over my kbd... MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); --S8hWgp6Wl+RBuNna Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/QSYfHb1edYOZ4bsRAi8mAJ9AsBOSJQ9EXqNkiPRuzmvemj1HawCffCvz gp/Z0B3dReLJuvXFChwe5yY= =Zhr1 -----END PGP SIGNATURE----- --S8hWgp6Wl+RBuNna-- From jbglaw@lug-owl.de Mon Aug 18 20:45:46 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Mon, 18 Aug 2003 21:45:46 +0200 Subject: [parisc-linux] [2.6.x] No less/greater/bar key at console nor with X11 Message-ID: <20030818194546.GJ16974@lug-owl.de> --k9n1VOENd6u0x2wl Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi:) Along with the NumLock problem, my (german) keyboard doesn't any longer respond to the less/greater/pipe key (located at the lower left of my keyboard). Each time, these three lines are printed: drivers/input/misc/gsc_ps2.c:rel=3D0 scancode=3D97, esc=3D0 <7>drivers/inpu= t/misc/gsc_ps2.c:received unk nown scancode 97, escape 0. drivers/input/misc/gsc_ps2.c:rel=3D0 scancode=3D240, esc=3D0 <7>drivers/inp= ut/misc/gsc_ps2.c:release=20 drivers/input/misc/gsc_ps2.c:rel=3D1 scancode=3D97, esc=3D0 <7>drivers/inpu= t/misc/gsc_ps2.c:received unknown scancode 97, escape 0. 97 gets mapped to KBD_UNKNOWN, 240 is KBD_RELEASE. However, I couldn't figure out what I should place instead of KBD_UNKNOWN. Dublicating my /etc/console/boottime.kmap.gz section for 86 (-> which is the correct entry for any other i386 keyboard) to keycode 97 doesn't help, though... MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); --k9n1VOENd6u0x2wl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/QSzqHb1edYOZ4bsRAjdQAJ4wMp4eyhSVx8UJiXxAs5hhpqdkBQCcDbUZ e5s3rHxPopR+V7wuzIZTmKg= =6vMH -----END PGP SIGNATURE----- --k9n1VOENd6u0x2wl-- From dave@hiauly3.hia.nrc.ca Mon Aug 18 21:34:11 2003 From: dave@hiauly3.hia.nrc.ca (John David Anglin) Date: Mon, 18 Aug 2003 16:34:11 -0400 (EDT) Subject: [parisc-linux] Re: Apollo 9000 power problem Message-ID: <200308182034.QAA13970@hiauly3.hia.nrc.ca> Christoph, I saw your recent note on power supply problems. It looks like my 735(730) has suffered a similar failure in the recent blackout. The symptoms appear similar to what you described a a couple of years ago. On power up, leds flash for 100-200 ms and then all go out. Did you replace the failed capacitor? Adding a resistor between the +Vaux line and the current sense line to compensate for leakage between the -12V line and the current sense line seems like a bit of a hack. Do you have docs for the supply? Dave From carlos@baldric.uwo.ca Mon Aug 18 22:09:29 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Mon, 18 Aug 2003 17:09:29 -0400 Subject: [parisc-linux] [PATCH] hppa libgcc-compat Message-ID: <20030818210929.GJ6190@systemhalted> libc-alpha, Seeing Lu's post about libgcc-compat reminded me that I should submit our version. We have been using this patch to fix the leaked __clz_tab symbol from libgcc. Attached is the required additions to our Makefile, Dist, and Versions. This patch was produced by Randolph Chung, many thanks! Cheers, Carlos. --- sysdeps/hppa/Dist | 1 sysdeps/hppa/Makefile | 11 +++++ sysdeps/hppa/Versions | 5 ++ sysdeps/hppa/libgcc-compat.c | 43 +++++++++++++++++++++++ 4 files changed, 60 insertions(+) --- 2003-02-25 Randolph Chung * sysdeps/hppa/Makefile: Include compat code in build. * sysdeps/hppa/libgcc-compat.c: New file. * sysdeps/hppa/Dist: Add libgcc-compat.c * sysdeps/hppa/Versions [GLIBC_2.2]: Add __clz_tab. --- glibc-2.3.1/sysdeps/hppa/Makefile.orig 2003-02-25 22:21:14.000000000 -0800 +++ glibc-2.3.1/sysdeps/hppa/Makefile 2003-02-25 22:22:01.000000000 -0800 @@ -31,3 +31,14 @@ dl-routines += dl-symaddr dl-fptr rtld-routines += dl-symaddr dl-fptr endif + +ifeq ($(subdir),csu) +ifeq (yes,$(build-shared)) +# Compatibility +ifeq (yes,$(have-protected)) +CPPFLAGS-libgcc-compat.c = -DHAVE_DOT_HIDDEN +endif +sysdep_routines += libgcc-compat +shared-only-routines += libgcc-compat +endif +endif --- glibc/sysdeps/hppa/libgcc-compat.c 2003-02-25 22:19:14.000000000 -0800 +++ glibc/sysdeps/hppa/libgcc-compat.c 2003-02-25 22:19:14.000000000 -0800 @@ -0,0 +1,43 @@ +/* pre-.hidden libgcc compatibility + Copyright (C) 2002 Free Software Foundation, Inc. + This file is part of the GNU C Library. + Contributed by Randolph Chung + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. */ + + +#include +#include + +#if SHLIB_COMPAT(libc, GLIBC_2_0, GLIBC_2_2_6) + +symbol_version (__clz_tab_internal, __clz_tab, GLIBC_2.2); + +typedef unsigned int UQItype __attribute__ ((mode (QI))); + +const UQItype __clz_tab_internal[] = +{ + 0,1,2,2,3,3,3,3,4,4,4,4,4,4,4,4,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5, + 6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6, + 7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7, + 7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7, + 8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8, + 8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8, + 8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8, + 8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8, +}; + +#endif --- glibc-2.3.1/sysdeps/hppa/Dist.orig 2003-02-26 09:02:52.000000000 -0800 +++ glibc-2.3.1/sysdeps/hppa/Dist 2003-02-26 09:04:03.000000000 -0800 @@ -1,2 +1,3 @@ +libgcc-compat.c dl-symaddr.c dl-fptr.c --- glibc-2.3.1/sysdeps/hppa/Versions.orig 2002-02-01 13:16:41.000000000 -0800 +++ glibc-2.3.1/sysdeps/hppa/Versions 2003-02-27 13:23:03.000000000 -0800 @@ -5,3 +5,8 @@ _dl_function_address; } } +libc { + GLIBC_2.2 { + __clz_tab; + } +} From anlinwei@vip.sina.com Tue Aug 19 02:51:39 2003 From: anlinwei@vip.sina.com (anlinwei) Date: Tue, 19 Aug 2003 09:51:39 +0800 Subject: [parisc-linux] =?GB2312?B?09C52LrP1/fKwtLLo6E=?= Message-ID: <20030819014912.D1CD4489D@dsl2.external.hp.com> ÄúÒ²ÐèÒªÅóÓÑ¡£ ÁÖÍþÏëÔÚÄúµÄÉúÃüÖÐÕ¼ÓбÈÖØʱ¼äºÍÄú½»¸öÅóÓÑ£¬±ð¾Ü¾ø£¡ ÁÖÍþ£¬Ò»¸ö¶ÔÉú»îºÍ¹¤×÷³äÂú¼¤ÇéÓëÐ˷ܵÄÄêÇáÈË£¬ Ò»¸öÓµÓÐÂúÄÔ×ӵĴ´ÐÂ˼ά£¬Ò»ÃëÖÓ¿ÉÒÔ±ä³öÒ»°Ù¸öÖ÷ÒâµÄÄÐÈË£¬ Ò»¸ö¶ÔÓÚÈκεÄÊÂÎïÓÐ×ŶÀÌصÄÊӽǺͼû½âµÄ¹ã¸æÈË£¡ µ±ÄúºÍËûÔÚÒ»ÆðµÄʱºò£¬Äú»áÓÉÖԵķ¢ÏÖÉú»î×ÜÊdzäÂúמªÏ²£¬ Äú¸ü»áÓÉÖԸоõµ½Ò»¸ö·¢×ÔÄÚÐĵĿìÀÖÓë×ÔÐÅÒÔ¼°±¥º¬Éú»îµÄ¼¤ÇéÓëÐË·ÜÊǺεȵĸ»ÓиÐȾÁ¦£¬ Äú»áÔÚDZÒÆĬ»¯ÖÐÈÃ×Ô¼ºÓµÓÐÏóÑô¹âÒ»Ñù²ÓÀõÄÕæ³ÏЦÈÝ¡£ ÒòΪÄú±äÁË£¡ ÄúºÍÄúËù·þÎñµÄ¹«Ë¾×ÜÊÇÒÔÏû·ÑÕߺÍÉú²úÕßµÄÐÎʽ³öÏÖ£¬²»ÊǹºÂò¾ÍÊÇÔÚ··Âô£¬Æä¼ä¾ÍÊÇÒ»¸öÐèÇó¡£ °ÑÄú¹ºÂòµÄÐèÇóºÍ··ÂôµÄÐèÇóÈÃÎÒÃÇÒ»Æð̽ÌÖ£¬¹µÍ¨»áµÃ³ö¸üºÃµÄ½â¾öºÍÖ´Ðз½°¸¡£ Çë¹Ø×¢ÄúÉí±ßµÄÐèÇóÐÅÏ¢£¬ÕâЩ¶¼ÊÇÄúÉí±ßµÄ²Æ¸»£¬²»ÒªÇáÑÔ·ÅÆú£¬Äú»áµÃµ½ÊµÏÖ¼ÛÖµµÄÌá³É£¡ ÇëÏàÐÅÁÖÍþ£¬ÏàÐÅÁÖÍþÖÜΧµÄÖÇÄÒÍŶӣ¬ÒòΪÁÖÍþÓµÓкܶàÏóÄúÕâÑùµÄÒµ½çÅóÓÑ£¬Í¨¹ýÕûºÏ×ÊÔ´ÈÃÎÒÃÇ×ÊÔ´¹²Ïí£¡ ¹ãÖݳà¾ÔÎÄ»¯´«²¥¹«Ë¾£¬Ò»¸ö¸ßËٳɳ¤×ŵĹã¸æ¹«¹Ø¹«Ë¾£¬ һȺ³¯ÆøÅ˼ÏëûÓÐî¿°íµÄÄêÇáÈ˹¹³É¡£Ö÷ÒªÒµÎñ£º 1¡¢ ƽÃæÉè¼Æ£º×ÜÄÜÏó³õÁµÒ»ÑùÔÚÄúÐÄÀïÊ´¿ÌÆ·ÅÆÓ¡¼£¡£ 2¡¢ ÈíÎÄ׫д£ºÃî±ÊÉú»¨£¬²»Ö¹ÓÚ˵·þ¶øÊÇÉîÉîµÄ´ò¶¯¡£ 3¡¢ ýÌåͶ·Å£ºÏëÄÄÒ»¸öýÌ壿ITýÌå¸üÓÐÓÅÊÆ£¡ 4¡¢ ÖÕ¶ËÎïÁÏÖÆ×÷£º·þÎñºÍÐÔ¼Û±È×ÜÄÜÎﳬËùÖµ£¡ µç»°£º£¨020£©85580657 85580234ת19»ò20 ÊÖ»ú£º13710685240 Email: anlinwei@vip.sina.com http://gzcj.blogone.net/ µØÖ·£º¹ãÖÝÊÐÖÐɽ´óµÀÎ÷¼ÓÄôó»¨Ô°¿¨¸ñÀï¸ó9E From anlinwei@vip.sina.com Tue Aug 19 02:51:46 2003 From: anlinwei@vip.sina.com (anlinwei) Date: Tue, 19 Aug 2003 09:51:46 +0800 Subject: [parisc-linux] =?GB2312?B?09C52LrP1/fKwtLLo6E=?= Message-ID: <20030819014919.D158A48A5@dsl2.external.hp.com> ÄúÒ²ÐèÒªÅóÓÑ¡£ ÁÖÍþÏëÔÚÄúµÄÉúÃüÖÐÕ¼ÓбÈÖØʱ¼äºÍÄú½»¸öÅóÓÑ£¬±ð¾Ü¾ø£¡ ÁÖÍþ£¬Ò»¸ö¶ÔÉú»îºÍ¹¤×÷³äÂú¼¤ÇéÓëÐ˷ܵÄÄêÇáÈË£¬ Ò»¸öÓµÓÐÂúÄÔ×ӵĴ´ÐÂ˼ά£¬Ò»ÃëÖÓ¿ÉÒÔ±ä³öÒ»°Ù¸öÖ÷ÒâµÄÄÐÈË£¬ Ò»¸ö¶ÔÓÚÈκεÄÊÂÎïÓÐ×ŶÀÌصÄÊӽǺͼû½âµÄ¹ã¸æÈË£¡ µ±ÄúºÍËûÔÚÒ»ÆðµÄʱºò£¬Äú»áÓÉÖԵķ¢ÏÖÉú»î×ÜÊdzäÂúמªÏ²£¬ Äú¸ü»áÓÉÖԸоõµ½Ò»¸ö·¢×ÔÄÚÐĵĿìÀÖÓë×ÔÐÅÒÔ¼°±¥º¬Éú»îµÄ¼¤ÇéÓëÐË·ÜÊǺεȵĸ»ÓиÐȾÁ¦£¬ Äú»áÔÚDZÒÆĬ»¯ÖÐÈÃ×Ô¼ºÓµÓÐÏóÑô¹âÒ»Ñù²ÓÀõÄÕæ³ÏЦÈÝ¡£ ÒòΪÄú±äÁË£¡ ÄúºÍÄúËù·þÎñµÄ¹«Ë¾×ÜÊÇÒÔÏû·ÑÕߺÍÉú²úÕßµÄÐÎʽ³öÏÖ£¬²»ÊǹºÂò¾ÍÊÇÔÚ··Âô£¬Æä¼ä¾ÍÊÇÒ»¸öÐèÇó¡£ °ÑÄú¹ºÂòµÄÐèÇóºÍ··ÂôµÄÐèÇóÈÃÎÒÃÇÒ»Æð̽ÌÖ£¬¹µÍ¨»áµÃ³ö¸üºÃµÄ½â¾öºÍÖ´Ðз½°¸¡£ Çë¹Ø×¢ÄúÉí±ßµÄÐèÇóÐÅÏ¢£¬ÕâЩ¶¼ÊÇÄúÉí±ßµÄ²Æ¸»£¬²»ÒªÇáÑÔ·ÅÆú£¬Äú»áµÃµ½ÊµÏÖ¼ÛÖµµÄÌá³É£¡ ÇëÏàÐÅÁÖÍþ£¬ÏàÐÅÁÖÍþÖÜΧµÄÖÇÄÒÍŶӣ¬ÒòΪÁÖÍþÓµÓкܶàÏóÄúÕâÑùµÄÒµ½çÅóÓÑ£¬Í¨¹ýÕûºÏ×ÊÔ´ÈÃÎÒÃÇ×ÊÔ´¹²Ïí£¡ ¹ãÖݳà¾ÔÎÄ»¯´«²¥¹«Ë¾£¬Ò»¸ö¸ßËٳɳ¤×ŵĹã¸æ¹«¹Ø¹«Ë¾£¬ һȺ³¯ÆøÅ˼ÏëûÓÐî¿°íµÄÄêÇáÈ˹¹³É¡£Ö÷ÒªÒµÎñ£º 1¡¢ ƽÃæÉè¼Æ£º×ÜÄÜÏó³õÁµÒ»ÑùÔÚÄúÐÄÀïÊ´¿ÌÆ·ÅÆÓ¡¼£¡£ 2¡¢ ÈíÎÄ׫д£ºÃî±ÊÉú»¨£¬²»Ö¹ÓÚ˵·þ¶øÊÇÉîÉîµÄ´ò¶¯¡£ 3¡¢ ýÌåͶ·Å£ºÏëÄÄÒ»¸öýÌ壿ITýÌå¸üÓÐÓÅÊÆ£¡ 4¡¢ ÖÕ¶ËÎïÁÏÖÆ×÷£º·þÎñºÍÐÔ¼Û±È×ÜÄÜÎﳬËùÖµ£¡ µç»°£º£¨020£©85580657 85580234ת19»ò20 ÊÖ»ú£º13710685240 Email: anlinwei@vip.sina.com http://gzcj.blogone.net/ µØÖ·£º¹ãÖÝÊÐÖÐɽ´óµÀÎ÷¼ÓÄôó»¨Ô°¿¨¸ñÀï¸ó9E From grundler@parisc-linux.org Tue Aug 19 06:08:29 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 18 Aug 2003 23:08:29 -0600 Subject: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem) In-Reply-To: References: <20030815172142.GA19042@dsl2.external.hp.com> Message-ID: <20030819050829.GF27208@dsl2.external.hp.com> On Sat, Aug 16, 2003 at 11:18:50AM -0400, Chuck Slivkoff wrote: > If you can accept the "off" colors that > an 8-bit TrueColor default visual would give you (due to the uneven > 3/3/2 split between R/G/B), that would be the easiest solution & would > ensure that all clients can get the colors they want. Chuck, thanks again! I can live with off colors since this seems to work. (thanks again Alan too) I'll submit a patch to xchat so at least it checks the gdk return values and complains if it can't get the colors. thanks, grant From jsoe0708@tiscali.be Tue Aug 19 10:39:18 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 19 Aug 2003 11:39:18 +0200 Subject: [parisc-linux] N running 2.4.21-pa13-64-SMP Message-ID: <3F2E54A800001E5E@ocpmta8.freegates.net> But for some minutes only :( Hi pa, With the hope to trap a HPMC during the boot of the N (dual processor) I added some printk() in traps.c, smp.c, mm/memory.c as follow: case 1: /* High-priority machine check (HPMC) */ printk("HPMC (case %d) from %s.\n", code, __FUNCTION__); pdc_console_restart(); /* switch back to pdc if HPMC */ [...] case 5: /* Low-priority machine check */ printk("LPMC (case %d) from %s.\n", code, __FUNCTION__); pdc_chassis_send_status(PDC_CHASSIS_DIRECT_LPMC); [...] case 6: /* Instruction TLB miss fault/Instruction page fault */ printk("Instruction TLB miss fault/Instruction page fault (case %d) from %s.\n", code, __FUNCTION__); fault_address = regs->iaoq[0]; [...] case 15: /* Data TLB miss fault/Data page fault */ /* Fall thru */ printk("Data TLB miss fault/Data page fault (case %d) from %s.\n", code, __FUNCTION__); goto LBLJSO1; case 16: /* Non-access instruction TLB miss fault */ /* The instruction TLB entry needed for the target address of the FIC is absent, and hardware can't find it, so we get to cleanup */ /* Fall thru */ printk("Non-access instruction TLB miss fault (case %d) from %s.\n", code, __FUNCTION__); goto LBLJSO1; case 17: /* Non-access data TLB miss fault/Non-access data page fault */ /* TODO: Still need to add slow path emulation code here */ /* TODO: Understand what is meant by the TODO listed above this one. (Carlos) */ printk("Non-access data TLB miss fault/Non-access data page fault (case %d) from %s.\n", code, __FUNCTION__); LBLJSO1: fault_address = regs->ior; fault_space = regs->isr; break; smp.c int smp_call_function (void (*func) (void *info), void *info, int retry, int wait) { [...] if (retry) { printk("Retry in %s.\n", __FUNCTION__); spin_lock (&lock); while (smp_call_function_data != 0) barrier(); } else { printk("Don't retry in %s.\n", __FUNCTION__); spin_lock (&lock); if (smp_call_function_data) { spin_unlock (&lock); return -EBUSY; } } [...] mm/memory.c [...] static int do_wp_page(struct mm_struct *mm, struct vm_area_struct * vma, unsigned long address, pte_t *page_table, pte_t pte) { [...] spin_unlock(&mm->page_table_lock); printk("Try page_cache_release(new_page) in %s.\n", __FUNCTION__); page_cache_release(new_page); printk("Try page_cache_release(old_page) in %s.\n", __FUNCTION__); page_cache_release(old_page); return 1; /* Minor fault */ bad_wp_page: [...] no_mem: printk("Try page_cache_release(old_page) in %s (because no_mem).\n", __FUNCTION__); [...] And start to grab: [...] IP Protocols: ICMP, UDP, TCP, IGMP Retry in smp_call_function. Retry in smp_call_function. IP: routing cache hash table of 8192 buckets, 128Kbytes Retry in smp_call_function. Retry in smp_call_function. Retry in smp_call_function. Retry in smp_call_function. Retry in smp_call_function. TCP: Hash tables configured (established 131072 bind 65536) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mount ********** VIRTUAL FRONT PANEL ********** System Boot detected ***************************************** LEDs: RUN ATTENTION FAULT REMOTE POWER ON FLASH OFF ON ON LED State: There was a system interruption that did not take the system down. Check Chassis and Console Logs for error messages. processor system initialization 1C00 ***************************************** ************ EARLY BOOT VFP ************* End of early boot detected ***************************************** ======== That is here where I would expect: ************ EARLY BOOT VFP ************* End of early boot detected ***************************************** bootlogd. ^G************* SYSTEM ALERT ************** SYSTEM NAME: ap8002 DATE: 08/11/2003 TIME: 12:56:05 ALERT LEVEL: 7 = reserved and eventually HPMC message but it continu ... ======== (case 6) from handle_interruption. Data TLB miss fault/Data page fault (case 15) from handle_interruption. Instruction TLB miss fault/Instruction page fault (case 6) from handle_interru ption. Instruction TLB miss fault/Instruction page fault (case 6) from handle_interru ption. Instruction TLB miss fault/Instruction page fault (case 6) from handle_interru ption. Instruction TLB miss fault/Instruction page fault (case 6) from handle_interru ption. Instruction TLB miss fault/Instruction page fault (case 6) from handle_interru ption. Data TLB miss fault/Data page fault (case 15) from handle_interruption. Instruction TLB miss fault/Instruction page fault (case 6) from handle_interru ption. Instruction TLB miss fault/Instruction page fault (case 6) from handle_interru ption. Instruction TLB miss fault/Instruction page fault (case 6) from handle_interru ption. Instruction TLB miss fault/Instruction page fault (case 6) from handle_interru ption. Data TLB miss fault/Data page fault (case 15) from handle_interruption. [...] Data TLB miss fault/Data page fault (case 15) from handle_interruption. Data TLB miss fault/Data page fault (case 15) from handle_interruption. Try page_cache_release(new_page) in do_wp_page. Try page_cache_release(old_page) in do_wp_page. Data TLB miss fault/Data page fault (case 15) from handle_interruption. [...] and thousand of messages of this type since I trap: [...] Data TLB palx4000miss login:... What a surprise??? Well as there is too much messages at the console I came back to my desk and login the system via ssh and got: palx4000:/proc# cat cpuinfo processor : 0 cpu family : PA-RISC 2.0 cpu : PA8600 (PCX-W+) cpu MHz : 550.000000 model : 9000/800/N4000-55 model name : Unknown machine hversion : 0x00005d30 sversion : 0x00000491 I-cache : 512 KB D-cache : 1024 KB (WB) ITLB entries : 160 DTLB entries : 160 - shared with ITLB bogomips : 1097.72 software id : 664309341 processor : 1 cpu family : PA-RISC 2.0 cpu : PA8600 (PCX-W+) cpu MHz : 550.000000 model : 9000/800/N4000-55 model name : Unknown machine hversion : 0x00005d30 sversion : 0x00000491 I-cache : 512 KB D-cache : 1024 KB (WB) ITLB entries : 160 DTLB entries : 160 - shared with ITLB bogomips : 1097.72 software id : 664309341 I so go back to the system to recover my laptop grabing console logs (via the lan console) and when I lost there was still thousand of messages flushing on the serial console. Back to my desk (about 10 minutes later) the system was unfortunaltely down. The screen console was just black. After a requested reset of GSP I could just read some messages as above but no HPMC (I know that couldn't be significant) and I have no other system to let connected until crash :( and have no more time to collect PIM right now :(( Any idea? Thanks in advance, Joel PS: Q1: I never grab 'Freeing unused kernel memory:...' during this test? Q2: into cpuinfo (here above) I read: ... ITLB entries : 160 DTLB entries : 160 - shared with ITLB ... is it right that DTLB is shared with ITLB? ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From varenet@esiee.fr Tue Aug 19 11:28:38 2003 From: varenet@esiee.fr (Thibaut VARENE) Date: Tue, 19 Aug 2003 12:28:38 +0200 Subject: [parisc-linux] Help: Need instruction sequence for gdb breakpoint In-Reply-To: <3F6F4712B759A34ABD453A8B39C10D62C4670F@bagman.edm.com> References: <3F6F4712B759A34ABD453A8B39C10D62C4670F@bagman.edm.com> Message-ID: <20030819122838.2b362689.varenet@esiee.fr> On Mon, 4 Aug 2003 14:37:13 +0400 "Lev Assinovsky" wrote: > Hello all! > I badly need pa-risc 1.1 instruction sequence suitable for gdb. > I would like to implement "hard breakpoint". > I tried "BREAK 4,8" - gdb stops but can't continue. > Any help will be appreciated! > We've looked into this already, and as far as we could find out, there is no hardware support for hardware breakpoints on parisc. They'd have to be emulated. You can take a look at what we did for kgdb by checking this page: http://pateam.esiee.fr/kgdb.html Anyway, as far as i know, gdb isn't really supported for hppa. HTH, Thibaut VARENE The PA/Linux ESIEE Team http://pateam.esiee.fr/ From LAssinovsky@algorithm.aelita.com Tue Aug 19 11:37:05 2003 From: LAssinovsky@algorithm.aelita.com (Lev Assinovsky) Date: Tue, 19 Aug 2003 14:37:05 +0400 Subject: [parisc-linux] Help: Need instruction sequence for gdb breakpoint Message-ID: <3F6F4712B759A34ABD453A8B39C10D62D4DA78@bagman.edm.com> What is BREAK instruction for? ---- Lev Assinovsky Aelita Software Corporation O&S Core Division, Programmer ICQ# 165072909 > -----Original Message----- > From: Thibaut VARENE [mailto:varenet@esiee.fr] > Sent: Tuesday, August 19, 2003 2:29 PM > To: Lev Assinovsky > Cc: parisc-linux@lists.parisc-linux.org > Subject: Re: [parisc-linux] Help: Need instruction sequence for gdb > breakpoint >=20 >=20 > On Mon, 4 Aug 2003 14:37:13 +0400 > "Lev Assinovsky" wrote: >=20 > > Hello all! > > I badly need pa-risc 1.1 instruction sequence suitable for gdb. > > I would like to implement "hard breakpoint".=20 > > I tried "BREAK 4,8" - gdb stops but can't continue. > > Any help will be appreciated! > >=20 >=20 > We've looked into this already, and as far as we could find=20 > out, there is > no hardware support for hardware breakpoints on parisc. > They'd have to be emulated. >=20 > You can take a look at what we did for kgdb by checking this page: > http://pateam.esiee.fr/kgdb.html >=20 > Anyway, as far as i know, gdb isn't really supported for hppa. >=20 > HTH, >=20 >=20 > Thibaut VARENE > The PA/Linux ESIEE Team > http://pateam.esiee.fr/ >=20 From LAssinovsky@algorithm.aelita.com Tue Aug 19 11:47:47 2003 From: LAssinovsky@algorithm.aelita.com (Lev Assinovsky) Date: Tue, 19 Aug 2003 14:47:47 +0400 Subject: [parisc-linux] Help: Need instruction sequence for gdb breakpoint Message-ID: <3F6F4712B759A34ABD453A8B39C10D62D4DA83@bagman.edm.com> Ok! But what's BREAK instruction for? Besides gdb works for me on HPUX 11.00 ---- Lev Assinovsky Aelita Software Corporation O&S Core Division, Programmer ICQ# 165072909 > -----Original Message----- > From: Thibaut VARENE [mailto:varenet@esiee.fr] > Sent: Tuesday, August 19, 2003 2:29 PM > To: Lev Assinovsky > Cc: parisc-linux@lists.parisc-linux.org > Subject: Re: [parisc-linux] Help: Need instruction sequence for gdb > breakpoint >=20 >=20 > On Mon, 4 Aug 2003 14:37:13 +0400 > "Lev Assinovsky" wrote: >=20 > > Hello all! > > I badly need pa-risc 1.1 instruction sequence suitable for gdb. > > I would like to implement "hard breakpoint".=20 > > I tried "BREAK 4,8" - gdb stops but can't continue. > > Any help will be appreciated! > >=20 >=20 > We've looked into this already, and as far as we could find=20 > out, there is > no hardware support for hardware breakpoints on parisc. > They'd have to be emulated. >=20 > You can take a look at what we did for kgdb by checking this page: > http://pateam.esiee.fr/kgdb.html >=20 > Anyway, as far as i know, gdb isn't really supported for hppa. >=20 > HTH, >=20 >=20 > Thibaut VARENE > The PA/Linux ESIEE Team > http://pateam.esiee.fr/ >=20 From jsoe0708@tiscali.be Tue Aug 19 13:33:04 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 19 Aug 2003 14:33:04 +0200 Subject: [parisc-linux] itlb miss handler optimizations! Message-ID: <3F2E54A800001F32@ocpmta8.freegates.net> >On Thu, Aug 14, 2003 at 08:02:04AM +0200, Joel Soete wrote: >> btw is it for that reason (interlock) that in your patch we can read: >> [...] >> cmpb,= %r0,t0,itlb_miss_... >> nop >> [...] >> I am alway asking why the 'nop'. > >To fill the delayed branch slot (a silly idea, but ...) Would it be the same 'by setting the "nullify" bit' (ie cmpb,=,n ...) Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From willy@debian.org Tue Aug 19 14:42:06 2003 From: willy@debian.org (Matthew Wilcox) Date: Tue, 19 Aug 2003 14:42:06 +0100 Subject: [parisc-linux] itlb miss handler optimizations! In-Reply-To: <3F2E54A800001F32@ocpmta8.freegates.net> References: <3F2E54A800001F32@ocpmta8.freegates.net> Message-ID: <20030819134206.GD19630@parcelfarce.linux.theplanet.co.uk> On Tue, Aug 19, 2003 at 02:33:04PM +0200, Joel Soete wrote: > >On Thu, Aug 14, 2003 at 08:02:04AM +0200, Joel Soete wrote: > >> btw is it for that reason (interlock) that in your patch we can read: > >> [...] > >> cmpb,= %r0,t0,itlb_miss_... > >> nop > >> [...] > >> I am alway asking why the 'nop'. > > > >To fill the delayed branch slot (a silly idea, but ...) > > Would it be the same 'by setting the "nullify" bit' (ie cmpb,=,n ...) Only if you know which direction the branch is going. See the cmpb description. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From willy@debian.org Tue Aug 19 14:47:34 2003 From: willy@debian.org (Matthew Wilcox) Date: Tue, 19 Aug 2003 14:47:34 +0100 Subject: [parisc-linux] N running 2.4.21-pa13-64-SMP In-Reply-To: <3F2E54A800001E5E@ocpmta8.freegates.net> References: <3F2E54A800001E5E@ocpmta8.freegates.net> Message-ID: <20030819134734.GE19630@parcelfarce.linux.theplanet.co.uk> On Tue, Aug 19, 2003 at 11:39:18AM +0200, Joel Soete wrote: > Q2: into cpuinfo (here above) I read: > ... > ITLB entries : 160 > DTLB entries : 160 - shared with ITLB > ... > is it right that DTLB is shared with ITLB? Yes, that's how the PA8500 and 8600 work, at least. We're merely reporting how PDC tells us the processor works, not programming it ourselves. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From grundler@parisc-linux.org Wed Aug 20 05:37:02 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Tue, 19 Aug 2003 22:37:02 -0600 Subject: [parisc-linux] Help: Need instruction sequence for gdb breakpoint In-Reply-To: <3F6F4712B759A34ABD453A8B39C10D62D4DA83@bagman.edm.com> References: <3F6F4712B759A34ABD453A8B39C10D62D4DA83@bagman.edm.com> Message-ID: <20030820043702.GC24884@dsl2.external.hp.com> On Tue, Aug 19, 2003 at 02:47:47PM +0400, Lev Assinovsky wrote: > Ok! But what's BREAK instruction for? To force a trap into the kernel. That's not the same as HW support since using break requires modifying the code stream (remembering which instruction belonged there), flushing data-cache, flush ins-cache, an dtrying to continue. The break's are fully under SW control. > Besides gdb works for me on HPUX 11.00 That's because HP has (had?) a team of folks working on the "open source toolkit". parisc-linux hasn't been so lucky. Alan Modra, Richard Hirst, Randolph Chung and a few others get gdb working from time to time. But there is no dedicated maintainer and that's what is needed. grant From hongkonghy@sina.com Wed Aug 20 20:08:52 2003 From: hongkonghy@sina.com (HY Tech) Date: Thu, 21 Aug 2003 03:08:52 +0800 Subject: [parisc-linux] New price list for mp3 player, digital camera, cd/vcd/mp3 player and USB flash drive! Message-ID: <20030820190847.5FD334875@dsl2.external.hp.com> Dear valued customer, We are a professional manufacturer of mp3 player, cd/vcd/mp3 player, digital camera and USB flash drive in Shenzhen, China. Please see the price of some products: mp3 player with digital recorder and USB flash drive 64M 39USD 128M 52USD cd/vcd/mp3 player (3 function in 1) 21.5USD digital camera 300K pixels 15.5USD 1.3M pixels 24USD USB flash drive 64M 17.9USD 128M 29.9USD 256M 54.9USD If you have interest, please contacut us and we will give you the detailed catalogue and price list. We always try our best to attract our clients with unbeatable prices and quality. Our goal is to treat every client the same as the most potential business partner.So however the client is big or small,we offer the best service. Any question, please contact me at any time. Have a nice day! Best Regards, Frank Ho General Manager HY Technology (Hong Kong) Company Ltd. From technology_hy@sina.com Wed Aug 20 20:10:30 2003 From: technology_hy@sina.com (HY Tech) Date: Thu, 21 Aug 2003 03:10:30 +0800 Subject: [parisc-linux] New price list for mp3 player, digital camera, cd/vcd/mp3 player and USB flash drive! Message-ID: <20030820191025.53FAA4875@dsl2.external.hp.com> Dear valued customer, We are a professional manufacturer of mp3 player, cd/vcd/mp3 player, digital camera and USB flash drive in Shenzhen, China. Please see the price of some products: mp3 player with digital recorder and USB flash drive 64M 39USD 128M 52USD cd/vcd/mp3 player (3 function in 1) 21.5USD digital camera 300K pixels 15.5USD 1.3M pixels 24USD USB flash drive 64M 17.9USD 128M 29.9USD 256M 54.9USD If you have interest, please contacut us and we will give you the detailed catalogue and price list. We always try our best to attract our clients with unbeatable prices and quality. Our goal is to treat every client the same as the most potential business partner.So however the client is big or small,we offer the best service. Any question, please contact me at any time. Have a nice day! Best Regards, Frank Ho General Manager HY Technology (Hong Kong) Company Ltd. From carlos@baldric.uwo.ca Wed Aug 20 20:41:03 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Wed, 20 Aug 2003 15:41:03 -0400 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <20030820192919.0C20349401C@palinux.hppa> References: <20030820192919.0C20349401C@palinux.hppa> Message-ID: <20030820194103.GA18688@systemhalted> On Wed, Aug 20, 2003 at 01:29:19PM -0600, Carlos O'Donell wrote: > CVSROOT: /var/cvs > Module name: linux > Changes by: carlos 03/08/20 13:29:19 > > Modified files: > arch/parisc/kernel: entry.S > > Log message: > itlb_fault optmizaztion Lamont made a good catch and we optimized the standard case in the itlb fault fast path, keeping the CPU's forward branch prediction working in our favour. As such our numbers for various syscalls (LMBENCH tests) have become more stable from call to call. The best number is our 'page fault' which has shown a ~10x speedup :) It used to be 130 microseconds +/- 100 microseconds, and is now consistently ~13 microseconds. I ran 30 LMBENCH runs, 10 each for the following configurations: 1- ITLB Optimization 2- ITLB Optimization + Removal of a register interlock on the fast path 3- No ITLB Optimization I've applied #2 to our CVS. Please tell me if anyone sees any breakage. This runs fine on my C3K. Cheers, Carlos. Index: entry.S =================================================================== RCS file: /var/cvs/linux/arch/parisc/kernel/entry.S,v retrieving revision 1.98 diff -u -p -r1.98 entry.S --- entry.S 9 Dec 2002 06:09:08 -0000 1.98 +++ entry.S 12 Aug 2003 03:49:04 -0000 @@ -1469,8 +1469,7 @@ itlb_miss_20w: mfctl %cr25,ptp /* load user pgd */ mfsp %sr7,t0 /* Get current space */ - or,*= %r0,t0,%r0 /* If kernel, nullify following test */ - cmpb,*<>,n t0,spc,itlb_fault /* forward */ + cmpb,<>,n t0,spc,itlb_user_fault_20w /* forward */ /* First level page table lookup */ @@ -1535,8 +1534,7 @@ itlb_miss_11: mfctl %cr25,ptp /* load user pgd */ mfsp %sr7,t0 /* Get current space */ - or,= %r0,t0,%r0 /* If kernel, nullify following test */ - cmpb,<>,n t0,spc,itlb_fault /* forward */ + cmpb,<>,n t0,spc,itlb_user_fault_11 /* forward */ /* First level page table lookup */ @@ -1551,6 +1549,10 @@ itlb_miss_common_11: sh2addl t0,ptp,ptp ldi _PAGE_ACCESSED,t1 ldw 0(ptp),pte + + /* Running parallel, taken from below 'zdep0' */ + zdep spc,30,15,prot /* create prot id from space */ + bb,>=,n pte,_PAGE_PRESENT_BIT,itlb_fault /* Check whether the "accessed" bit was set, otherwise do so */ @@ -1559,7 +1561,7 @@ itlb_miss_common_11: and,<> t1,pte,%r0 /* test and nullify if already set */ stw t0,0(ptp) /* write back pte */ - zdep spc,30,15,prot /* create prot id from space */ + /* zdep0 moved back */ dep pte,8,7,prot /* add in prot bits from pte */ extru,= pte,_PAGE_NO_CACHE_BIT,1,r0 @@ -1602,8 +1604,7 @@ itlb_miss_20: mfctl %cr25,ptp /* load user pgd */ mfsp %sr7,t0 /* Get current space */ - or,= %r0,t0,%r0 /* If kernel, nullify following test */ - cmpb,<>,n t0,spc,itlb_fault /* forward */ + cmpb,<>,n t0,spc,itlb_user_fault_20 /* forward */ /* First level page table lookup */ @@ -1882,6 +1883,37 @@ kernel_bad_space: dbit_fault: b intr_save ldi 20,%r8 + +/* The following three labels relate to an optimization in the itlb handler. + itlb_user_fault_20w: + itlb_user_fault_20: + itlb_user_fault_11: + We keep the CPU jumping fwd/bkwd in the common case, and the uncommon case + has the cmpb fail (no jump) and thus branch prediction failing. */ + +#ifdef __LP64__ +itlb_user_fault_20w: + /* User tlb missed for other than his own space. Optimization. */ + cmpb,= %r0,t0,itlb_miss_common_20w /* backward */ + nop +#else +itlb_user_fault_20: + /* User tlb missed for other than his own space. Optimization. */ + cmpb,= %r0,t0,itlb_miss_common_20 /* backward */ + nop + +/* FALL THROUGH - We don't care if we run the test twice. If someone + asks to have the "user is faulting death" path optimal + then they should seek help. */ + +itlb_user_fault_11: + /* User tlb missed for other than his own space. Optimization. */ + cmpb,= %r0,t0,itlb_miss_common_11 /* backward */ + nop +#endif + +/* FALL THROUGH - We have a real itlb_fault from one of the above three + label sequences */ itlb_fault: b intr_save From grundler@parisc-linux.org Thu Aug 21 06:11:24 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 20 Aug 2003 23:11:24 -0600 Subject: [parisc-linux] Re: xchat colors In-Reply-To: <20030819050829.GF27208@dsl2.external.hp.com> References: <20030815172142.GA19042@dsl2.external.hp.com> <20030819050829.GF27208@dsl2.external.hp.com> Message-ID: <20030821051124.GB22498@dsl2.external.hp.com> On Mon, Aug 18, 2003 at 11:08:29PM -0600, Grant Grundler wrote: > I'll submit a patch to xchat so at least it checks the > gdk return values and complains if it can't get the colors. patch submitted to debian bug #200903. IMHO a pathetic patch. If someone is looking for a very small project, cleaning up xchat color handling would be a good thing. I just realized that instead of xchat allocating it's own colors, it might be nice to prompt the user to select from existing "default" colors. And reduce the number of colors used overall by xchat. grant From jsoe0708@tiscali.be Thu Aug 21 07:21:43 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 21 Aug 2003 08:21:43 +0200 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <20030820194103.GA18688@systemhalted> Message-ID: <3F2E2C7700003FE2@ocpmta2.freegates.net> >Lamont made a good catch and we optimized the standard case in the itlb >fault fast path, keeping the CPU's forward branch prediction working in >our favour. That is the very fine state of the art :) >As such our numbers for various syscalls (LMBENCH tests) >have become more stable from call to call. The best number is our 'page >fault' which has shown a ~10x speedup :) It used to be 130 microseconds >+/- 100 microseconds, and is now consistently ~13 microseconds. Congratulation, I will try it also on the N (64bits) Thanks again, Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From willy@debian.org Thu Aug 21 22:19:32 2003 From: willy@debian.org (Matthew Wilcox) Date: Thu, 21 Aug 2003 22:19:32 +0100 Subject: [parisc-linux] sym53c8xx_2 development Message-ID: <20030821211932.GC19630@parcelfarce.linux.theplanet.co.uk> Hi. I've got some changes for the sym53c8xx_2 driver I'm working on. Does anyone object to me working on them in the parisc 2.6 tree? Obviously, I'll do my best to not break anything and I'll handle any merge problems. We've done this kind of thing before (eg with the pcnet32 driver in 2.4) but since every PCI-based parisc box uses sym53c8xx_2 for its scsi, I didn't feel it was appropriate to inflict potentially-buggy changes on everyone without a little bit of discussion. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From christoph.plattner@gmx.at Thu Aug 21 22:32:52 2003 From: christoph.plattner@gmx.at (Christoph Plattner) Date: Thu, 21 Aug 2003 23:32:52 +0200 Subject: [parisc-linux] Re: Apollo 9000 power problem References: <200308182034.QAA13970@hiauly3.hia.nrc.ca> Message-ID: <3F453A84.5040305@gmx.at> Hello, of course it is a "hack", but it is a constructive one, not a bad thing like disconnecting the suppervision or so ... I have replaced some of the capacitors, but it was not so simple to detect the one, which has lost a bit of it's fluid ... The problem is relly the layer of this chemicals of the capacitor and the dust mixture, which generates the lack current. (I really have problems to explain this all in English here ....) I was not my thing to take the power supply out and hold it under the water to clean, so I tried it with clothes, etc, but - as I mentioned already in the last mail - some weeks later the problem occured again. New dust on this checimal stuff .... (or new chemical stuff ??? ...) This SIMM-like suppervison thing checks six itmes on the power supply (the other 6 comperators are use to generate the RESET signal in case of "power good"). One measures the current. If the input of the comperator increases 2.35V (comming from meassure transformer meassuring the current of some secondary linesm e.g. 5V, 12V...), then the protection stops the power supply (the stop is done per thyristor, so one short "stop" signal hold the power supply down until POFF/PON, then the cycle starts again). In idle operation (my test setup was a 10 Ohm + LED to see, if the power is stable while repairing it), the voltage of the current transformers is near 0V. All current transformers have an own diode to one line. So if the output voltage of the current transformes is lower the e.g. 0.6V (voltage of the diode), behind the diodes the line has high impedance. So the very low lack current of the near -12V line can drop this line easy. If the voltage drops below 0V, the comperator does not work correctly and asserts the "stop" (although e.g. -0.5V is below 2.35, which should be OK !). If there is an over current, there is a voltage on the output side of the current transformer, and a representative voltage is on the other side of the diode. This will pull up the the line up to some voltage (higher than 2.35 leads to the stop ..). So the 220KOhm resisitor only pulls the high impedance sense line up against the "dust" resistor. But both "resistors" have a high value against the output of the over current transformers, if a big current is comming up. So this "hack" is acceptable for me. It was not acceptable for me, to short-cut or isolate the over-current protection (I did this for one day for tests, but I could not live with this feeling, not having this important protection. And see the alternative. A new powersupply of this type costs about 1000 EURO, an "fresh repaied" about 300EURO, an old one - perhaps having the same problem soon - costs about 150EURO ... So I am happy to have a correct working power supply with a full functioning protection and a "well defined" hack ! Ok, I cannot take any warranty for others ..., but I thought, I know what I am doing. Further questions are welcome. Christoph P. John David Anglin wrote: > Christoph, > > I saw your recent note on power supply problems. It looks like > my 735(730) has suffered a similar failure in the recent blackout. > The symptoms appear similar to what you described a a couple of > years ago. On power up, leds flash for 100-200 ms and then all > go out. > > Did you replace the failed capacitor? Adding a resistor between > the +Vaux line and the current sense line to compensate for leakage > between the -12V line and the current sense line seems like a > bit of a hack. > > Do you have docs for the supply? > > Dave > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > > -- ------------------------------------------------------- private: christoph.plattner@gmx.at company: christoph.plattner@alcatel.at From christoph.plattner@gmx.at Thu Aug 21 22:43:50 2003 From: christoph.plattner@gmx.at (Christoph Plattner) Date: Thu, 21 Aug 2003 23:43:50 +0200 Subject: [parisc-linux] [Fwd: Re: Apollo 9000 power problem] Message-ID: <3F453D16.8080708@gmx.at> This is a multi-part message in MIME format. --------------070102000107000003020209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit So for all in the PARISC group ! I sent this file to MR. Gabert last week. Here some INPORTANT points: - I take no warranty in all cases ! - You do the repair on your own risk (for me it was a good solution) - Check the type of the power supply My was a ASTEC Model BM200-3601 - Have fun on testing ... Bye Christoph P. -- ------------------------------------------------------- private: christoph.plattner@gmx.at company: christoph.plattner@alcatel.at --------------070102000107000003020209 Content-Type: message/rfc822; name="Re: Apollo 9000 power problem" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: Apollo 9000 power problem" >From - Thu Aug 14 00:14:28 2003 X-Mozilla-Status2: 00800000 Message-ID: <3F3AB83F.3000408@gmx.at> Date: Thu, 14 Aug 2003 00:14:23 +0200 From: Christoph Plattner Organization: private User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Gabert Subject: Re: Apollo 9000 power problem References: <3F32CB8C.9060407@gmx.at> <20030807220208.GA31556@nikita.ath.cx> <3F32CE0B.30902@gmx.at> <20030807223043.GA3631@nikita.ath.cx> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, so here the thing you have to do to repair ... ... but before some words: - 1 - I take no warranty to nothing - the hack works for well, you can try it. - 2 - My power supply so of the type ASTEC Model BM200-3601 check the label on the power-supply not to hack around on the wrong thing !! Pull out the power-supply an disconnect the power. Wait for one minute to have unloaded the capacitors in it after unplugging it from supply. Unscrew and open power supply. Take out the main board of the supply. 4 Screws have to be opened: +----------------------------------------------------------+-- | O O | | | | | +--+ |low | | O |voltage | | |side +--+ | | O | +----------------------------------------------------------+-- Remeber the screws, 2 of them do a GROUND connection (the upper 2 on my figure above). After having the board in the hand, turn around, we only have to work on the bottom side (soldering side). The fix has to be done on the low voltage side near the 60-pin connector. Beside the 60-pin connector, there is this SIMM-like module, the supervision module. Exactly on the solder side of this module (bottom side of supply main board) we have to solder on this resistor. SIMM-like Module on other side / ----------------+ / | v BOTTOM VIEW !!! +--------------+ o O | o | /->O | / O | / O o o| 60-pin conector | O o o o| <----- | o o o| | o o| +-+ O o o o| 220K| | O o o o| | | O o o| +-+ O o o o| | O o o| | O o o| \ O o o o| \-->O o o| O o o o| O o o| o o| o o| o o| o o| o o| o o o| o o| o o o| o o| O o o| etc ... Simple solder on this Resistor (220kOhms works for me) between pin-1 and pin-12 of the SIMM-like module. Reassemble the powersuplly and it should work !! BTW: I use something like "Schrumpfschlauch" (the english word ?) on both connections of the resistor not to have contact to other pins or the metallic case !! Good luck, Christoph. Alexander Gabert wrote: > hi, > > i live in Bavaria, Germany, about 1 hour to salzburg... > and another 2-3 hours to vienna. > and i would really bring you some good wine or beer if we could do that > together caus i have really two left hands when it comes to soldering > around on power supplies :-) > > bye, > > Alex > > On Fri, Aug 08, 2003 at 12:09:15AM +0200, Christoph Plattner wrote: > >>Where do ylu live, what is "cx" ? >> >>I live in Vienna ! >> >>But I do not think it is necessary, that you come. >>I can make you a small graohic in the mail, where to solder >>this only one resistor, and which value it should have ... >> >>Further it is very simple to open the power supply - >>but please disconnect the power, I am not responsible for you ... >> >>Some minutes ago, I switched on my Apollo, it was for many >>months now, and it booted up without any problem .... >> >>If you are interested, I send you this tomorrow, now is is late >>to pull out the supply and open it ... >> >>Bye >>Christoph >> >> >> >> >> >>Alexander Gabert wrote: >> >>>hi, >>> >>>where in austria do you live? >>> >>>could i visit you with one of my broken power supplies and bring some >>>beer for you to repair it for me? >>> >>>TIA, >>> >>>Alex >>> >>>On Thu, Aug 07, 2003 at 11:58:36PM +0200, Christoph Plattner wrote: >>> >>> >>>>Hello HP Hackers ! >>>> >>>>I have a work around for the POWER SUPPLY Problem. >>>> >>>>Using schematics and analysing this very very hard thing, >>>>I found out, that the problem we all have was created >>>>by an exploded capacitor. >>>> >>>>The thing running out of the capacitor mixed with the dust >>>>in the machine generates an resistor on the PCB board. >>>> >>>>On the low voltage end of the power supply (near front), >>>>ther is a small SIM-like module which does the supervision of >>>>all volatage lines (plus over current protection) and which >>>>generates the reset impuls. >>>> >>>>Now to the problem. The line coming from the current measure >>>>transformer is the neighbour line of the -12V line. Because >>>>of the electrical resistor because of the dust, etc, the >>>>negative voltage comes to the current supervision line, and >>>>therefore one supervision comperator does a wrong failure >>>>reaction ! >>>> >>>>Workaround: >>>> >>>>- step 1 - >>>>Try to clean the space on the PCB around this supervison module. >>>>(I soldered it out for cleaning, a resoldered it in).. >>>> >>>>- step 2 - >>>>This helps. But after weeks the problem returned again .... >>>>I soldered in a resistor between the +Vaux (about 12..16V) >>>>and this current measure line to compensate this negativ >>>>voltage of the -12V line. >>>>This is no relevant impact to the over-current protection, >>>>as the resistor has a high value against the measurement >>>>output. >>>> >>>>This worked for me. >>>>If you need help on this, please contact me ... >>>> >>>>Christoph >>>> >>>> >>>> >>>> >>>>-- >>>>------------------------------------------------------- >>>>private: christoph.plattner@gmx.at >>>>company: christoph.plattner@alcatel.at >>>> >>> >>> >> >> >>-- >>------------------------------------------------------- >>private: christoph.plattner@gmx.at >>company: christoph.plattner@alcatel.at >> > > -- ------------------------------------------------------- private: christoph.plattner@gmx.at company: christoph.plattner@alcatel.at --------------070102000107000003020209-- From carlos@baldric.uwo.ca Fri Aug 22 02:39:31 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Thu, 21 Aug 2003 21:39:31 -0400 Subject: [parisc-linux] [glibc] fixing delayed exceptions in hppa Message-ID: <20030822013931.GD31872@systemhalted> parisc-linux, Just a quick RFC on this patch. I've generated a register interlock on the previous exception raising result register. This _should_ cause delayed exceptions to be flushed immediately on all processors. Under my C3K testsetup it fixes the test-fenv failure that was specifically related to "child raises exception, exception comes in late and kills parent after child called join." Comments more than welcome, I'll be submitting this upstream if nobody has any quibles with my gcc asm :) c. --- libc/sysdeps/hppa/fpu/fraiseexcpt.c 10 Sep 2002 01:26:37 -0000 1.4 +++ libc/sysdeps/hppa/fpu/fraiseexcpt.c 19 Aug 2003 18:52:33 -0000 @@ -25,6 +25,8 @@ int feraiseexcept (int excepts) { + /* Used in the trap barrier */ + double dummy; /* Raise exceptions represented by EXCEPTS. But we must raise only one signal at a time. It is important that if the overflow/underflow exception and the divide by zero exception are given at the same @@ -42,17 +44,17 @@ feraiseexcept (int excepts) { /* One example of a invalid operation is 0 * Infinity. */ double d = HUGE_VAL; - __asm__ __volatile__ ("fmpy,dbl %1,%%fr0,%0\n\t" + __asm__ __volatile__ ("fmpy,dbl %2,%%fr0,%0\n\t" /* FIXME: is this a proper trap barrier? */ - "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d)); + "fcpy,dbl %0,%1" : "=f" (d), "=f" (dummy) : "0" (d)); } /* Next: division by zero. */ if (excepts & FE_DIVBYZERO) { double d = 1.0; - __asm__ __volatile__ ("fdiv,dbl %1,%%fr0,%0\n\t" - "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d)); + __asm__ __volatile__ ("fdiv,dbl %2,%%fr0,%0\n\t" + "fcpy,dbl %2,%1" : "=f" (d), "=f" (dummy) : "0" (d)); } /* Next: overflow. */ @@ -61,8 +63,8 @@ feraiseexcept (int excepts) { double d = DBL_MAX; - __asm__ __volatile__ ("fmpy,dbl %1,%1,%0\n\t" - "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d)); + __asm__ __volatile__ ("fmpy,dbl %2,%2,%0\n\t" + "fcpy,dbl %2,%1" : "=f" (d), "=f" (dummy) : "0" (d)); } /* Next: underflow. */ @@ -71,8 +73,8 @@ feraiseexcept (int excepts) double d = DBL_MIN; double e = 69.69; - __asm__ __volatile__ ("fdiv,dbl %1,%2,%0\n\t" - "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d), "f" (e)); + __asm__ __volatile__ ("fdiv,dbl %2,%3,%0\n\t" + "fcpy,dbl %2,%1" : "=f" (d), "=f" (dummy) : "0" (d), "f" (e)); } /* Last: inexact. */ @@ -81,8 +83,8 @@ feraiseexcept (int excepts) double d = 1.0; double e = M_PI; - __asm__ __volatile__ ("fdiv,dbl %1,%2,%0\n\t" - "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d), "f" (e)); + __asm__ __volatile__ ("fdiv,dbl %2,%3,%0\n\t" + "fcpy,dbl %2,%1" : "=f" (d), "=f" (dummy) : "0" (d), "f" (e)); } /* Success. */ From willy@debian.org Fri Aug 22 03:42:59 2003 From: willy@debian.org (Matthew Wilcox) Date: Fri, 22 Aug 2003 03:42:59 +0100 Subject: [parisc-linux] [glibc] fixing delayed exceptions in hppa In-Reply-To: <20030822013931.GD31872@systemhalted> References: <20030822013931.GD31872@systemhalted> Message-ID: <20030822024259.GC18834@parcelfarce.linux.theplanet.co.uk> On Thu, Aug 21, 2003 at 09:39:31PM -0400, Carlos O'Donell wrote: > Just a quick RFC on this patch. I've generated a register interlock on > the previous exception raising result register. This _should_ cause delayed > exceptions to be flushed immediately on all processors. > > Under my C3K testsetup it fixes the test-fenv failure that was > specifically related to "child raises exception, exception comes in late > and kills parent after child called join." Yay. > Comments more than welcome, I'll be submitting this upstream if nobody > has any quibles with my gcc asm :) I can quibble! > /* One example of a invalid operation is 0 * Infinity. */ > double d = HUGE_VAL; > - __asm__ __volatile__ ("fmpy,dbl %1,%%fr0,%0\n\t" > + __asm__ __volatile__ ("fmpy,dbl %2,%%fr0,%0\n\t" > /* FIXME: is this a proper trap barrier? */ > - "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d)); > + "fcpy,dbl %0,%1" : "=f" (d), "=f" (dummy) : "0" (d)); > } Surely this, and all the others, would be clearer written as: __asm__ __volatile__ ( " fmpy,dbl %0,%%fr0,%0\n" " fcpy,dbl %0,%1\n" : "+f" (d), "=f" (dummy)); ie turn the \t into a literal tab, and use the "+" syntax rather than the "=" and "0" syntax. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From dave@hiauly3.hia.nrc.ca Fri Aug 22 04:04:44 2003 From: dave@hiauly3.hia.nrc.ca (John David Anglin) Date: Thu, 21 Aug 2003 23:04:44 -0400 (EDT) Subject: [parisc-linux] Re: [glibc] fixing delayed exceptions in hppa In-Reply-To: <20030822013931.GD31872@systemhalted> from Carlos O'Donell at Aug "21," 2003 "09:39:31" pm Message-ID: <200308220304.XAA11565@hiauly3.hia.nrc.ca> > Comments more than welcome, I'll be submitting this upstream if nobody > has any quibles with my gcc asm :) See . Dave From petendlovu@netscape.net Fri Aug 22 15:27:43 2003 From: petendlovu@netscape.net (PETE NDLOVU) Date: Fri, 22 Aug 2003 16:27:43 +0200 Subject: [parisc-linux] HELP ME Message-ID: <20030822142908.F1A91484E@dsl2.external.hp.com> This is a multi-part message in MIME format --9372fd29-284b-4240-ab71-ef5518d90a3a Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear Sir, Difficulties encountered in efforts to establish a business abroad necessitate this search for someone to assist me in securing and investing the sum of USD7.5 Million (Seven million five hundred thousand dollars)inherited from = my father's business reserve. I am the heir of a Zimbabwean family; my father was an agriculturist. He became rich from his old-aged investment in agriculture and later was victimized by President Robert Mugabe's land reform policy. He was assassinated by unknown gunmen for defending his land ownership and siding the minority white farmers. Before his death, my father foresaw the insecurity of both our lives and property then decided to deposit the above sum with a private finance and security firm in Europe. This money has become the only inherited property of our family since our home was burnt,and the farmlands and machines seized; yet the government and it's loyalists are bent on making life difficult for us. To summarise this traumatic story, my mother and I have decided to offer 15% = of the above sum to anyone who assists us to secure this funds overseas or 25% share for possible help on investing in any reliable venture. There are however some minimal cost involved in securing the release of this deposit from the present holding company.i do not intend to overburden you with these cost.but you must know beforehand that we will be sharing whatever cost involved in retrieving this deposit and putting it to beneficial use. if you would want to proceed under these terms,please reply for detailed information. if you do not accept my offer,please in good fate treat with utmost confidentiality . A quick reply with your name,telephone and fax numbers to for more confidential communication will be highly appreciated. Sincerely yours, Pete Ndlovu --9372fd29-284b-4240-ab71-ef5518d90a3a-- From James.Bottomley@steeleye.com Fri Aug 22 15:40:37 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 22 Aug 2003 09:40:37 -0500 Subject: [parisc-linux] Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) Message-ID: <1061563239.2090.25.camel@mulgrave> --=-lmHKO1hPltD8R1GkCOtr Content-Type: text/plain Content-Transfer-Encoding: 7bit This test essentially opens a file (via open(2)), writes something, opens it via a mmaped file object *read only* (via fopen(...,"rm)) reads what was writtent, writes some more and reads it via the mmaped file object. This last read fails to get the data on parisc. The problem is that our CPU cache is virtually indexed, and the page the write is storing the data to (in the buffer cache) and the page it is mmapped to have the same physical, but different virtual addresses. We need the write() to trigger a cache update via flush_dcache_page to get the virtually indexed cache in sync. The reason this doesn't happen is because the mapping is not on the mmap_shared list that flush_dcache_page() updates. And the reason it's not on the correct list is because there's a check in mm/mmap.c:do_mmap_pgoff() that drops the VM_SHARED flag on the mapping if the file wasn't opened for writing (about line 541). Semantically, it seems that whether the mmaping sees a write or not on a different descriptor shouldn't depend on whether the underlying file was opened read only or read write, so I think the glibc test is correct, and we should keep the VM_SHARED flag even if the underlying file was opened read only. The patch is attached (and makes the test pass on parisc). Comments? James --=-lmHKO1hPltD8R1GkCOtr Content-Disposition: attachment; filename=tmp.diff Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=tmp.diff; charset=ISO-8859-1 =3D=3D=3D=3D=3D mm/mmap.c 1.89 vs edited =3D=3D=3D=3D=3D --- 1.89/mm/mmap.c Thu Jul 10 21:46:52 2003 +++ edited/mm/mmap.c Fri Aug 22 09:36:32 2003 @@ -539,7 +539,7 @@ =20 vm_flags |=3D VM_SHARED | VM_MAYSHARE; if (!(file->f_mode & FMODE_WRITE)) - vm_flags &=3D ~(VM_MAYWRITE | VM_SHARED); + vm_flags &=3D ~VM_MAYWRITE; =20 /* fall through */ case MAP_PRIVATE: --=-lmHKO1hPltD8R1GkCOtr-- From carlos@baldric.uwo.ca Fri Aug 22 15:46:15 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Fri, 22 Aug 2003 10:46:15 -0400 Subject: [parisc-linux] Re: [glibc] fixing delayed exceptions in hppa In-Reply-To: <200308220304.XAA11565@hiauly3.hia.nrc.ca> References: <20030822013931.GD31872@systemhalted> <200308220304.XAA11565@hiauly3.hia.nrc.ca> Message-ID: <20030822144615.GF31872@systemhalted> On Thu, Aug 21, 2003 at 11:04:44PM -0400, John David Anglin wrote: > > Comments more than welcome, I'll be submitting this upstream if nobody > > has any quibles with my gcc asm :) > > See . I took this into account, and the fcpy of a non fr0 is working better than before precisely for the reasons you list your original email. Should I instead spill the value into memory at dummy's address? c. From dannf@hp.com Fri Aug 22 17:08:20 2003 From: dannf@hp.com (dann frazier) Date: Fri, 22 Aug 2003 10:08:20 -0600 Subject: [parisc-linux] Re: palo In-Reply-To: <1245099799.20030822174107@tatneft.ru> References: <1245099799.20030822174107@tatneft.ru> Message-ID: <20030822160820.GA18112@ldl.fc.hp.com> you have e-mailed the admin of the cvs list, which is part of the old bug tracking system. i've cc'd the parisc-linux list, which is probably the best place to ask. On Fri, Aug 22, 2003 at 05:41:07PM +0400, ??????? ??????? wrote: > ???????????? ?????????, cvs-admin. > > Please help me cvs download palo ! > Please sorry my english > > I am use this and read error messges: > user@panda:~/palo$ cvs -d :pserver:guest@cvs.parisc-linux.org:/ checkout palo > cvs checkout: warning: failed to open /home/user/.cvspass for reading: No such file or directory > /: no such repository > user@panda:~/palo$ cvs -d :pserver:guest@cvs.parisc-linux.org:/cvs checkout palo > cvs checkout: warning: failed to open /home/user/.cvspass for reading: No such file or directory > /cvs: no such repository > user@panda:~/palo$ cvs -d :pserver:guest@cvs.parisc-linux.org:/Developmetn checkout palo > cvs checkout: warning: failed to open /home/user/.cvspass for reading: No such file or directory > /Developmetn: no such repository > user@panda:~/palo$ cvs -d :pserver:guest@parisc-linux.org:/cvs checkout palo > cvs checkout: warning: failed to open /home/user/.cvspass for reading: No such file or directory > /cvs: no such repository > user@panda:~/palo$ cvs -d :pserver:guest@parisc-linux.org:/cvs/Development checkout palo > cvs checkout: warning: failed to open /home/user/.cvspass for reading: No such file or directory > /cvs/Development: no such repository > user@panda:~/palo$ cvs -d :pserver:guest@parisc-linux.org:/cvs/ checkout Development/palo > cvs checkout: warning: failed to open /home/user/.cvspass for reading: No such file or directory > /cvs/: no such repository > user@panda:~/palo$ cvs -d :pserver:guest@parisc-linux.org:/cvs checkout Development/palo > cvs checkout: warning: failed to open /home/user/.cvspass for reading: No such file or directory > /cvs: no such repository > user@panda:~/palo$ cvs -d :pserver:guest@parisc-linux.org:/cvs checkout Development/palo > > I need setup Gentoo Linux by HP9000/811/D310 and have this message: > . > . > . > . > Information: No console specified on kernel command line. This is > normal.PALO will choose the console currently used by firmware > (serial). > . > . > . > . > . > If this is the last message you see, you may need to switch your console. > > I am reed this http://tldp.org/HOWTO/PA-RISC-Linux-Boot-HOWTO/index.html > -- > ? ?????????,mailto:almetoil@tatneft.ru > > ??????? 22 ??????? 2003 ?. ? 17:33:27. > -- --------------------------- dann frazier Hewlett-Packard Linux and Open Source Lab dannf@hp.com (970) 898-0800 From Randolph Chung Fri Aug 22 17:16:59 2003 From: Randolph Chung (Randolph Chung) Date: Fri, 22 Aug 2003 09:16:59 -0700 Subject: [parisc-linux] Re: palo In-Reply-To: <20030822160820.GA18112@ldl.fc.hp.com> References: <1245099799.20030822174107@tatneft.ru> <20030822160820.GA18112@ldl.fc.hp.com> Message-ID: <20030822161659.GE21328@tausq.org> > > Please help me cvs download palo ! > > Please sorry my english > > > > I am use this and read error messges: > > user@panda:~/palo$ cvs -d :pserver:guest@cvs.parisc-linux.org:/ checkout palo > > cvs checkout: warning: failed to open /home/user/.cvspass for reading: No such file or directory touch ~/.cvspass then follow the directions at http://www.parisc-linux.org/faq/cvs.html for anonymous CVS access. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From davem@redhat.com Fri Aug 22 17:14:47 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 22 Aug 2003 09:14:47 -0700 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <1061563239.2090.25.camel@mulgrave> References: <1061563239.2090.25.camel@mulgrave> Message-ID: <20030822091447.6ecea6ca.davem@redhat.com> On 22 Aug 2003 09:40:37 -0500 James Bottomley wrote: > This test essentially opens a file (via open(2)), writes something, > opens it via a mmaped file object *read only* (via fopen(...,"rm)) reads > what was writtent, writes some more and reads it via the mmaped file > object. > > This last read fails to get the data on parisc. The problem is that our > CPU cache is virtually indexed, and the page the write is storing the > data to (in the buffer cache) and the page it is mmapped to have the > same physical, but different virtual addresses. We need the write() to > trigger a cache update via flush_dcache_page to get the virtually > indexed cache in sync. > > The reason this doesn't happen is because the mapping is not on the > mmap_shared list that flush_dcache_page() updates. flush_dcache_page() checks both the shared and non-shared mmap lists, so if it is on _either_ list it is flushed. It does not check only the shared list. The VM_SHARED change you are proposing is definitely wrong. From willy@debian.org Fri Aug 22 17:34:29 2003 From: willy@debian.org (Matthew Wilcox) Date: Fri, 22 Aug 2003 17:34:29 +0100 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030822091447.6ecea6ca.davem@redhat.com> References: <1061563239.2090.25.camel@mulgrave> <20030822091447.6ecea6ca.davem@redhat.com> Message-ID: <20030822163429.GH18834@parcelfarce.linux.theplanet.co.uk> On Fri, Aug 22, 2003 at 09:14:47AM -0700, David S. Miller wrote: > On 22 Aug 2003 09:40:37 -0500 > James Bottomley wrote: > > The reason this doesn't happen is because the mapping is not on the > > mmap_shared list that flush_dcache_page() updates. > > flush_dcache_page() checks both the shared and non-shared mmap lists, > so if it is on _either_ list it is flushed. It does not check only > the shared list. Gah, that's going to get really inefficient. I still think we want to split flush_dcache_page() into two operations -- flush_dcache_user() and flush_dcache_kernel(). flush_dcache_user() would flush this specific user mapping back to ram and flush_dcache_kernel() would flush the kernel mapping. Obviously we'd still want to have flush_dcache_page() as there are instances when you want to flush all user mappings and the kernel mapping back to ram. > The VM_SHARED change you are proposing is definitely wrong. Why is it wrong? Why should whether-or-not a mapping is read-only affect whether it's mapped shared? I can't see anything in SuS v3 that suggests we should do this. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From rmk@arm.linux.org.uk Fri Aug 22 17:42:03 2003 From: rmk@arm.linux.org.uk (Russell King) Date: Fri, 22 Aug 2003 17:42:03 +0100 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030822163429.GH18834@parcelfarce.linux.theplanet.co.uk>; from willy@debian.org on Fri, Aug 22, 2003 at 05:34:29PM +0100 References: <1061563239.2090.25.camel@mulgrave> <20030822091447.6ecea6ca.davem@redhat.com> <20030822163429.GH18834@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030822174203.H12903@flint.arm.linux.org.uk> On Fri, Aug 22, 2003 at 05:34:29PM +0100, Matthew Wilcox wrote: > On Fri, Aug 22, 2003 at 09:14:47AM -0700, David S. Miller wrote: > > On 22 Aug 2003 09:40:37 -0500 > > James Bottomley wrote: > > > The reason this doesn't happen is because the mapping is not on the > > > mmap_shared list that flush_dcache_page() updates. > > > > flush_dcache_page() checks both the shared and non-shared mmap lists, > > so if it is on _either_ list it is flushed. It does not check only > > the shared list. Eww. > Gah, that's going to get really inefficient. I still think we want to > split flush_dcache_page() into two operations -- flush_dcache_user() and > flush_dcache_kernel(). flush_dcache_user() would flush this specific > user mapping back to ram and flush_dcache_kernel() would flush the > kernel mapping. Where are you proposing calling only _user() and _kernel() from ? -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html From davem@redhat.com Fri Aug 22 17:39:00 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 22 Aug 2003 09:39:00 -0700 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030822163429.GH18834@parcelfarce.linux.theplanet.co.uk> References: <1061563239.2090.25.camel@mulgrave> <20030822091447.6ecea6ca.davem@redhat.com> <20030822163429.GH18834@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030822093900.4468c012.davem@redhat.com> On Fri, 22 Aug 2003 17:34:29 +0100 Matthew Wilcox wrote: > On Fri, Aug 22, 2003 at 09:14:47AM -0700, David S. Miller wrote: > > On 22 Aug 2003 09:40:37 -0500 > > flush_dcache_page() checks both the shared and non-shared mmap lists, > > so if it is on _either_ list it is flushed. It does not check only > > the shared list. > > Gah, that's going to get really inefficient. I still think we want to > split flush_dcache_page() into two operations -- flush_dcache_user() and > flush_dcache_kernel(). flush_dcache_user() would flush this specific > user mapping back to ram and flush_dcache_kernel() would flush the > kernel mapping. Obviously we'd still want to have flush_dcache_page() > as there are instances when you want to flush all user mappings and the > kernel mapping back to ram. flush_dcache_page() works only on kernel pages. It is defined to execute when the kernel executes store instructions into a page. Therefore splitting it into a "user" part makes absolutely no sense. > > The VM_SHARED change you are proposing is definitely wrong. > > Why is it wrong? Why should whether-or-not a mapping is read-only affect > whether it's mapped shared? I can't see anything in SuS v3 that suggests > we should do this. MAP_SHARED has no meaning if the mapping isn't writable. From davem@redhat.com Fri Aug 22 17:39:57 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 22 Aug 2003 09:39:57 -0700 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030822174203.H12903@flint.arm.linux.org.uk> References: <1061563239.2090.25.camel@mulgrave> <20030822091447.6ecea6ca.davem@redhat.com> <20030822163429.GH18834@parcelfarce.linux.theplanet.co.uk> <20030822174203.H12903@flint.arm.linux.org.uk> Message-ID: <20030822093957.0ad547cd.davem@redhat.com> On Fri, 22 Aug 2003 17:42:03 +0100 Russell King wrote: > > Gah, that's going to get really inefficient. I still think we want to > > split flush_dcache_page() into two operations -- flush_dcache_user() and > > flush_dcache_kernel(). flush_dcache_user() would flush this specific > > user mapping back to ram and flush_dcache_kernel() would flush the > > kernel mapping. > > Where are you proposing calling only _user() and _kernel() from ? The is not acceptable answer. Purely, flush_dcache_page() is defined to execute when the kernel stores into a page cache page, and that is it's only valid definition. Splitting into a "user" part makes absolutely no sense. From willy@debian.org Fri Aug 22 18:41:03 2003 From: willy@debian.org (Matthew Wilcox) Date: Fri, 22 Aug 2003 18:41:03 +0100 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030822093900.4468c012.davem@redhat.com> References: <1061563239.2090.25.camel@mulgrave> <20030822091447.6ecea6ca.davem@redhat.com> <20030822163429.GH18834@parcelfarce.linux.theplanet.co.uk> <20030822093900.4468c012.davem@redhat.com> Message-ID: <20030822174103.GI18834@parcelfarce.linux.theplanet.co.uk> On Fri, Aug 22, 2003 at 09:39:00AM -0700, David S. Miller wrote: > flush_dcache_page() works only on kernel pages. > > It is defined to execute when the kernel executes store instructions > into a page. > > Therefore splitting it into a "user" part makes absolutely no > sense. Uhm. So what happens when the user has stored into the page and now the kernel wants to read from it? There's still data in the cache for the user mapping that's non-coherent with the kernel mapping. > > > The VM_SHARED change you are proposing is definitely wrong. > > > > Why is it wrong? Why should whether-or-not a mapping is read-only affect > > whether it's mapped shared? I can't see anything in SuS v3 that suggests > > we should do this. > > MAP_SHARED has no meaning if the mapping isn't writable. Sure it does. It affects whether other writes to that page show up in the shared read-only mapping. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From davem@redhat.com Fri Aug 22 18:36:34 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 22 Aug 2003 10:36:34 -0700 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030822174103.GI18834@parcelfarce.linux.theplanet.co.uk> References: <1061563239.2090.25.camel@mulgrave> <20030822091447.6ecea6ca.davem@redhat.com> <20030822163429.GH18834@parcelfarce.linux.theplanet.co.uk> <20030822093900.4468c012.davem@redhat.com> <20030822174103.GI18834@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030822103634.46a15747.davem@redhat.com> On Fri, 22 Aug 2003 18:41:03 +0100 Matthew Wilcox wrote: > Uhm. So what happens when the user has stored into the page and now > the kernel wants to read from it? There's still data in the cache for > the user mapping that's non-coherent with the kernel mapping. I see. This causes the page cache read flush_dcache_page() call not to trigger. I was very confused by the fact that this bug was explained by saying that "the shared mmap list that flush_dcache_page() checks". So the idea is that VM_SHARED should be set based upon whether we mmap() the thing writable _not_ whether the open() was done with write permission enabled. Yes, I agree with that. From davem@redhat.com Fri Aug 22 19:01:44 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 22 Aug 2003 11:01:44 -0700 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030822103634.46a15747.davem@redhat.com> References: <1061563239.2090.25.camel@mulgrave> <20030822091447.6ecea6ca.davem@redhat.com> <20030822163429.GH18834@parcelfarce.linux.theplanet.co.uk> <20030822093900.4468c012.davem@redhat.com> <20030822174103.GI18834@parcelfarce.linux.theplanet.co.uk> <20030822103634.46a15747.davem@redhat.com> Message-ID: <20030822110144.5f7b83c5.davem@redhat.com> On Fri, 22 Aug 2003 10:36:34 -0700 "David S. Miller" wrote: > On Fri, 22 Aug 2003 18:41:03 +0100 > Matthew Wilcox wrote: > > > Uhm. So what happens when the user has stored into the page and now > > the kernel wants to read from it? There's still data in the cache for > > the user mapping that's non-coherent with the kernel mapping. > > I see. This causes the page cache read flush_dcache_page() call > not to trigger. Wait, I'm confused again. How can the user "write" to the mmap()'d side if PROT_WRITE was not specified? That is the only case in which the proposed patch could make a difference, we check this: switch (flags & MAP_TYPE) { case MAP_SHARED: if ((prot&PROT_WRITE) && !(file->f_mode&FMODE_WRITE)) return -EACCES; Therefore if the user can write to the page, file->f_mode will have the write bit set too. So the proposed patch looks bogus to me. From hugh@veritas.com Fri Aug 22 19:34:41 2003 From: hugh@veritas.com (Hugh Dickins) Date: Fri, 22 Aug 2003 19:34:41 +0100 (BST) Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030822110144.5f7b83c5.davem@redhat.com> Message-ID: On Fri, 22 Aug 2003, David S. Miller wrote: > > So the proposed patch looks bogus to me. And to me. If VM_SHARED is set, then __vma_link_file puts the vma on on i_mmap_shared. If VM_SHARED is not set, it puts the vma on i_mmap. flush_dcache_page treats i_mmap_shared and i_mmap lists equally. Might the problem be in parisc's __flush_dcache_page, which only examines i_mmap_shared? Though it's odd, I'm not keen on changing do_mmap_pgoff's usage of VM_SHARED in a hurry: it's worked like that for years, and other things (I forget) depend on it. Hugh From davem@redhat.com Fri Aug 22 19:31:06 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 22 Aug 2003 11:31:06 -0700 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: References: <20030822110144.5f7b83c5.davem@redhat.com> Message-ID: <20030822113106.0503a665.davem@redhat.com> On Fri, 22 Aug 2003 19:34:41 +0100 (BST) Hugh Dickins wrote: > And to me. If VM_SHARED is set, then __vma_link_file puts the vma on > on i_mmap_shared. If VM_SHARED is not set, it puts the vma on i_mmap. > flush_dcache_page treats i_mmap_shared and i_mmap lists equally. But file system page cache writes only call flush_dache_page() if the page has a non-empty i_mmap_shared list. > Might the problem be in parisc's __flush_dcache_page, > which only examines i_mmap_shared? No, it examines both lists, the problem is not there. The issue seems to be some confusion about whether the test program in question is actually mmap()'ing the area with PROT_WRITE set, and if so why the test case isn't passing because in such a case the page will have a non-empty i_mmap_shared list. From James.Bottomley@steeleye.com Fri Aug 22 19:41:26 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 22 Aug 2003 13:41:26 -0500 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: References: Message-ID: <1061577688.2090.285.camel@mulgrave> On Fri, 2003-08-22 at 13:34, Hugh Dickins wrote: > Might the problem be in parisc's __flush_dcache_page, > which only examines i_mmap_shared? This is the issue: we do treat them differently. Semantics differ between privately mapped data (where there's no coherency guarantee) and shared data (where there is). Flushing the virtual cache is expensive on pa, so we only do it for the i_mmap_shared list. The difficulty is that a mmap of a read only file with MAP_SHARED is expecting the shared cache semantics, but gets added to the non shared list. Since flushing the caches is a performance hog, we'd like do be able to distinguish the cases where we have to do the flush MAP_SHARED mappings from those we don't (MAP_PRIVATE). James From James.Bottomley@steeleye.com Fri Aug 22 19:56:06 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 22 Aug 2003 13:56:06 -0500 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030822113106.0503a665.davem@redhat.com> References: <20030822110144.5f7b83c5.davem@redhat.com> <20030822113106.0503a665.davem@redhat.com> Message-ID: <1061578568.2053.313.camel@mulgrave> On Fri, 2003-08-22 at 13:31, David S. Miller wrote: > On Fri, 22 Aug 2003 19:34:41 +0100 (BST) > Hugh Dickins wrote: > > > And to me. If VM_SHARED is set, then __vma_link_file puts the vma on > > on i_mmap_shared. If VM_SHARED is not set, it puts the vma on i_mmap. > > flush_dcache_page treats i_mmap_shared and i_mmap lists equally. > > But file system page cache writes only call flush_dache_page() > if the page has a non-empty i_mmap_shared list. Hmm, but if it does that then the glibc bug test should show up on sparc because the i_mmap_shared list is empty if we only do MAP_SHARED of read only files. James From hugh@veritas.com Fri Aug 22 20:02:44 2003 From: hugh@veritas.com (Hugh Dickins) Date: Fri, 22 Aug 2003 20:02:44 +0100 (BST) Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <1061577688.2090.285.camel@mulgrave> Message-ID: On 22 Aug 2003, James Bottomley wrote: > On Fri, 2003-08-22 at 13:34, Hugh Dickins wrote: > > Might the problem be in parisc's __flush_dcache_page, > > which only examines i_mmap_shared? > > This is the issue: we do treat them differently. > > Semantics differ between privately mapped data (where there's no > coherency guarantee) and shared data (where there is). Flushing the > virtual cache is expensive on pa, so we only do it for the i_mmap_shared > list. > > The difficulty is that a mmap of a read only file with MAP_SHARED is > expecting the shared cache semantics, but gets added to the non shared > list. > > Since flushing the caches is a performance hog, we'd like do be able to > distinguish the cases where we have to do the flush MAP_SHARED mappings > from those we don't (MAP_PRIVATE). The naming "i_mmap_shared" does suggest that once upon a time those lists were as you'd like; and that at some point it was changed. Perhaps some arches prefer the coherency guarantee I'm familiar with in MAP_PRIVATE (yes, when you modify a page yourself, it cows off and becomes private; but in i386 it's shared up until then), and other arches (like yours) would prefer to avoid the overhead. Hugh From Randolph Chung Fri Aug 22 20:09:52 2003 From: Randolph Chung (Randolph Chung) Date: Fri, 22 Aug 2003 12:09:52 -0700 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <1061577688.2090.285.camel@mulgrave> References: <1061577688.2090.285.camel@mulgrave> Message-ID: <20030822190952.GF21328@tausq.org> In reference to a message from James Bottomley, dated Aug 22: > On Fri, 2003-08-22 at 13:34, Hugh Dickins wrote: > > Might the problem be in parisc's __flush_dcache_page, > > which only examines i_mmap_shared? > > This is the issue: we do treat them differently. as does some other archs, like ARM. are we saying that MAP_SHARED != VM_SHARED? the mmap code allows architectures to map pages differently if MAP_SHARED is specified, but it puts it on i_mmap vs i_mmap_shared using VM_SHARED, and for read-only files we silently drop VM_SHARED... so the page is mapped using MAP_SHARED semantics but placed on i_mmap.... confused, randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From davem@redhat.com Fri Aug 22 20:19:55 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 22 Aug 2003 12:19:55 -0700 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <1061578568.2053.313.camel@mulgrave> References: <20030822110144.5f7b83c5.davem@redhat.com> <20030822113106.0503a665.davem@redhat.com> <1061578568.2053.313.camel@mulgrave> Message-ID: <20030822121955.619a14eb.davem@redhat.com> On 22 Aug 2003 13:56:06 -0500 James Bottomley wrote: > On Fri, 2003-08-22 at 13:31, David S. Miller wrote: > > On Fri, 22 Aug 2003 19:34:41 +0100 (BST) > > Hugh Dickins wrote: > > > > > And to me. If VM_SHARED is set, then __vma_link_file puts the vma on > > > on i_mmap_shared. If VM_SHARED is not set, it puts the vma on i_mmap. > > > flush_dcache_page treats i_mmap_shared and i_mmap lists equally. > > > > But file system page cache writes only call flush_dache_page() > > if the page has a non-empty i_mmap_shared list. > > Hmm, but if it does that then the glibc bug test should show up on sparc > because the i_mmap_shared list is empty if we only do MAP_SHARED of read > only files. Sparc64's alias'able caches are 1) write-through and 2) quite small. I think I begin to see the issue clearly now. But you cannot do the VM_SHARED change without an audit first. Lots of code thinks that VM_SHARED means someone maybe wrote to the page through a mmap(). For example look at how filemap sync interprets this flag bit. From dave@hiauly3.hia.nrc.ca Fri Aug 22 21:24:19 2003 From: dave@hiauly3.hia.nrc.ca (John David Anglin) Date: Fri, 22 Aug 2003 16:24:19 -0400 (EDT) Subject: [parisc-linux] Re: [glibc] fixing delayed exceptions in hppa In-Reply-To: <20030822144615.GF31872@systemhalted> from Carlos O'Donell at Aug "22," 2003 "10:46:15" am Message-ID: <200308222024.QAA16264@hiauly3.hia.nrc.ca> > I took this into account, and the fcpy of a non fr0 is working better > than before precisely for the reasons you list your original email. > > Should I instead spill the value into memory at dummy's address? Based on what Jim Hull said, I believe that would be better. I was using "fldd 0(%%sr0,%%sp),%0" : "=f" (d) : "0" (d) There isn't a true dependency in the above but I believe that any load to the destination register will raise the exception. Dave From James.Bottomley@steeleye.com Fri Aug 22 23:27:33 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 22 Aug 2003 17:27:33 -0500 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030822121955.619a14eb.davem@redhat.com> References: <20030822110144.5f7b83c5.davem@redhat.com> <20030822113106.0503a665.davem@redhat.com> <1061578568.2053.313.camel@mulgrave> <20030822121955.619a14eb.davem@redhat.com> Message-ID: <1061591255.1784.636.camel@mulgrave> On Fri, 2003-08-22 at 14:19, David S. Miller wrote: > Sparc64's alias'able caches are 1) write-through and 2) quite small. > > I think I begin to see the issue clearly now. > > But you cannot do the VM_SHARED change without an audit first. > Lots of code thinks that VM_SHARED means someone maybe wrote > to the page through a mmap(). For example look at how filemap > sync interprets this flag bit. Yes, the issue seems to be that the flush_dcache_page() was implemented with the thought that the caches of the shared mappings may contain modified data that needs to be flushed to the aliased page. The opposite property: that the caches of the aliased page need to be invalidated because someone else changed data in the aliased page seems to work as a byproduct of the above implementation. But some of the checks for !list_empty(&mapping->i_shared) are going to prevent the necessary invalidations on read only shared mappings...which was the initial problem. The only issue I can see with not dropping VM_SHARED for read only shared mappings is that we do spurious (but harmless) flushe_dcache_page() on reads. There also appears to be a lurking prob lem in do_mremap, where it keys off the VM_SHARED flag to set the MAP_SHARED flag for get_unmapped_area. That's going to cause us a problem on parisc because SHARED pages need to obey slightly stricter alignment constraints All in all, I think not dropping VM_SHARED on read only shared mappings is the right thing to do. Do you need a more detailed audit? James From davem@redhat.com Fri Aug 22 23:41:00 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 22 Aug 2003 15:41:00 -0700 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <1061591255.1784.636.camel@mulgrave> References: <20030822110144.5f7b83c5.davem@redhat.com> <20030822113106.0503a665.davem@redhat.com> <1061578568.2053.313.camel@mulgrave> <20030822121955.619a14eb.davem@redhat.com> <1061591255.1784.636.camel@mulgrave> Message-ID: <20030822154100.06314c8e.davem@redhat.com> On 22 Aug 2003 17:27:33 -0500 James Bottomley wrote: > Yes, the issue seems to be that the flush_dcache_page() was implemented > with the thought that the caches of the shared mappings may contain > modified data that needs to be flushed to the aliased page. > > The opposite property: that the caches of the aliased page need to be > invalidated because someone else changed data in the aliased page seems > to work as a byproduct of the above implementation. > > But some of the checks for !list_empty(&mapping->i_shared) are going to > prevent the necessary invalidations on read only shared mappings...which > was the initial problem. The theory of operation is that there are two "classes" of mappings for a page, the implicit kernel mapping and all user mappings. The goal is to flush out one class from the cache when the other one writes to such a page. When a write() system call occurs, the kernel "class" is writing to the page so all user mappings (shared or not!) need to be flushed out. When a read() system call occurs, and shared+writable mmap()'s of the page exist, we must flush the user mapping "class" before the kernel "class" tries to read from that page. You cannot avoid doing things exactly as I've just described without allowing bad aliases to be in the cache and corrupt data. Your test case is essentially, annotated with what the kernel should do at each step: static const char *test1 = "Line the first\n"; static const char *test2 = "Line the second\n"; temp_fd = open(O_RDWR); write(temp_fd, test1, sizeof test1 - 1); No mmaps of this page, so no flush_dcache_page() call. ... fd = open(O_RDONLY); p = mmap(fd, ... PROT_READ ...); Not writable, not added to i_mmap_shared list, instead it is added to normal i_mmap list. memcpy(tmp_buf, p, sizeof test1 - 1); p += sizeof test1 - 1; if (strcmp(tmp_buf, test1)) BUG(); ... write(temp_fd, test2, sizeof test2 - 1); Mmaps of this page exist, flush_dcache_page() call is made. memcpy(tmp_buf, p, sizeof test2 - 1); if (strcmp(tmp_buf, test2)) BUG(); And thus memcpy() sees correct data. I think on parisc you are trying to avoid the write() case of the cache flush for non-shared mmap()s, and sorry you really can't do this, again this is: When a write() system call occurs, the kernel "class" is writing to the page so all user mappings (shared or not!) need to be flushed out. If your flush_dcache_page() is not doing this, it's no wonder the test case fails for you. From James.Bottomley@steeleye.com Sat Aug 23 02:09:30 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 22 Aug 2003 20:09:30 -0500 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030822154100.06314c8e.davem@redhat.com> References: <20030822110144.5f7b83c5.davem@redhat.com> <20030822113106.0503a665.davem@redhat.com> <1061578568.2053.313.camel@mulgrave> <20030822121955.619a14eb.davem@redhat.com> <1061591255.1784.636.camel@mulgrave> <20030822154100.06314c8e.davem@redhat.com> Message-ID: <1061600974.2090.809.camel@mulgrave> On Fri, 2003-08-22 at 17:41, David S. Miller wrote: > I think on parisc you are trying to avoid the write() case > of the cache flush for non-shared mmap()s, and sorry you > really can't do this, again this is: > > When a write() system call occurs, the kernel "class" is writing to > the page so all user mappings (shared or not!) need to be flushed > out. > > If your flush_dcache_page() is not doing this, it's no wonder > the test case fails for you. Yes, that's precisely what we're trying to do. Our problem is that we have to issue the flush to all the aliased addresses (one cache line at a time) which is phenomenally expensive. What we were hoping is that we could rely on this little property of mmap: MAP_PRIVATE Create a private copy-on-write mapping. Stores to the region do not affect the original file. It is unspecified whether changes made to the file after the mmap call are visible in the mapped region. To avoid having to flush the non-shared mappings (basically on parisc if you write to a file backing a MAP_PRIVATE mapping then we don't guarantee you see the update). I suppose if we had a way of telling if any of the i_mmap list members were really MAP_SHARED semantics mappings, then we could alter our flush_dcache_page() implementation to work. James From grundler@parisc-linux.org Sat Aug 23 06:43:22 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 22 Aug 2003 23:43:22 -0600 Subject: [parisc-linux] sym53c8xx_2 development In-Reply-To: <20030821211932.GC19630@parcelfarce.linux.theplanet.co.uk> References: <20030821211932.GC19630@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030823054322.GA20158@dsl2.external.hp.com> On Thu, Aug 21, 2003 at 10:19:32PM +0100, Matthew Wilcox wrote: > > Hi. I've got some changes for the sym53c8xx_2 driver I'm working on. > Does anyone object to me working on them in the parisc 2.6 tree? I don't think enough people are *using* 2.6 for anything serious for that to be a problem. And I'm ok if you warn before committing stuff which isn't at least lightly tested. > We've done this kind of thing before (eg with the pcnet32 driver in 2.4) and I've done it with several other drivers as well (eg tg3, acenic). > but since every PCI-based parisc box uses sym53c8xx_2 for its scsi, > I didn't feel it was appropriate to inflict potentially-buggy changes > on everyone without a little bit of discussion. cool - thanks! grant From carlos@baldric.uwo.ca Sat Aug 23 06:55:06 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Sat, 23 Aug 2003 01:55:06 -0400 Subject: [parisc-linux] Re: [glibc] fixing delayed exceptions in hppa In-Reply-To: <200308222024.QAA16264@hiauly3.hia.nrc.ca> References: <20030822144615.GF31872@systemhalted> <200308222024.QAA16264@hiauly3.hia.nrc.ca> Message-ID: <20030823055506.GA9821@systemhalted> On Fri, Aug 22, 2003 at 04:24:19PM -0400, John David Anglin wrote: > Based on what Jim Hull said, I believe that would be better. I was using > > "fldd 0(%%sr0,%%sp),%0" : "=f" (d) : "0" (d) > > There isn't a true dependency in the above but I believe that any load > to the destination register will raise the exception. Dave, I'm sorry if you sent me a patch and I dropped it :( Did I ever receive a diff for this from you? It's rather vague at times because the spec says "or an operation which depends on a pending, trapping insn." I think DHD, and perhaps myself got caught up on the "load or store" which probably means only register->memory (memory->register too) and not register->register. I'll rewrite this patch to do an fldd and see what the tests say. I'm toatally under the assumption that this operation doesn't need to be optimal :) (e.g. If you use feraiseexcept a lot you are not a high-performance program). c. From grundler@parisc-linux.org Sat Aug 23 07:21:39 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Sat, 23 Aug 2003 00:21:39 -0600 Subject: [parisc-linux] Help: Need instruction sequence for gdb breakpoint In-Reply-To: <3F6F4712B759A34ABD453A8B39C10D62DEEC97@bagman.edm.com> References: <3F6F4712B759A34ABD453A8B39C10D62DEEC97@bagman.edm.com> Message-ID: <20030823062139.GA20379@dsl2.external.hp.com> On Fri, Aug 22, 2003 at 09:13:37PM +0400, Lev Assinovsky wrote: > Hi! > 1. I meant just a hardcoded breakpoint (not hardware) > Partially works just BREAK 4, 8. Though I need to do "jump" to next line > to continue in gdb. ah ok > 2. gdb doesn't work with shared libraries explicitly loaded by program. > Could you please point to anybody from HP team? HP Team? Sorry but officially there is no HP parisc-linux team. Most of us are interested in kernel hacking and less in making gdb work. > 3. What about ddd? sorry - haven't looked at ddd. grant From grundler@parisc-linux.org Sat Aug 23 07:26:12 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Sat, 23 Aug 2003 00:26:12 -0600 Subject: [parisc-linux] Re: palo In-Reply-To: <20030822160820.GA18112@ldl.fc.hp.com> References: <1245099799.20030822174107@tatneft.ru> <20030822160820.GA18112@ldl.fc.hp.com> Message-ID: <20030823062612.GB20379@dsl2.external.hp.com> On Fri, Aug 22, 2003 at 10:08:20AM -0600, dann frazier wrote: > you have e-mailed the admin of the cvs list, which is part of the old bug > tracking system. > i've cc'd the parisc-linux list, which is probably the best place to ask. thanks dann > On Fri, Aug 22, 2003 at 05:41:07PM +0400, ??????? ??????? wrote: > > ???????????? ?????????, cvs-admin. > > > > Please help me cvs download palo ! > > Please sorry my english > > > > I am use this and read error messges: > > user@panda:~/palo$ cvs -d :pserver:guest@cvs.parisc-linux.org:/ checkout palo > > cvs checkout: warning: failed to open /home/user/.cvspass for reading: No such file or directory try "cvs -d ... login" first. Just hit (aka return or enter key) for password prompt. grant From hugh@veritas.com Sat Aug 23 08:22:19 2003 From: hugh@veritas.com (Hugh Dickins) Date: Sat, 23 Aug 2003 08:22:19 +0100 (BST) Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <1061600974.2090.809.camel@mulgrave> Message-ID: On 22 Aug 2003, James Bottomley wrote: > > I suppose if we had a way of telling if any of the i_mmap list members > were really MAP_SHARED semantics mappings, then we could alter our > flush_dcache_page() implementation to work. Good idea. It's VM_MAYSHARE you need to check for. Hugh From mmogenius@v8fiesta.co.uk Sat Aug 23 09:30:02 2003 From: mmogenius@v8fiesta.co.uk (mmogenius@v8fiesta.co.uk) Date: Sat, 23 Aug 2003 09:30:02 +0100 Subject: [parisc-linux] USB keyboard support on boot Message-ID: <1061627402.3f47260a748cd@webmail.v8fiesta.co.uk> Hi i am trying to install Debian 3.0 (woody) in my b2000 although once i have booted from the cd to install i have no keyboard or mouse controal. Is usb enabled by default ? Thanks ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From varenet@esiee.fr Sat Aug 23 10:51:49 2003 From: varenet@esiee.fr (Thibaut VARENE) Date: Sat, 23 Aug 2003 12:51:49 +0300 Subject: [parisc-linux] USB keyboard support on boot In-Reply-To: <1061627402.3f47260a748cd@webmail.v8fiesta.co.uk> Message-ID: <20030823105149.4C45649DF2@mail.esiee.fr> http://lists.parisc-linux.org/pipermail/parisc-linux/2003-March/01939 9.html Thibaut VARENE PA/Linux ESIEE Team http://pateam.esiee.fr/ On vacation until Aug 25th. ------------------- > Hi i am trying to install Debian 3.0 (woody) in my b2000 although=20 once i have=20 > booted from the cd to install i have no keyboard or mouse controal.=20 Is usb=20 > enabled by default ?=20 >=20 > Thanks >=20 > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux >=20 >=20 From varenet@esiee.fr Sat Aug 23 10:55:35 2003 From: varenet@esiee.fr (Thibaut VARENE) Date: Sat, 23 Aug 2003 12:55:35 +0300 Subject: [parisc-linux] Help: Need instruction sequence for gdb breakpoint In-Reply-To: <20030823062139.GA20379@dsl2.external.hp.com> Message-ID: <20030823105536.125F849C32@mail.esiee.fr> ------------------- > On Fri, Aug 22, 2003 at 09:13:37PM +0400, Lev Assinovsky wrote: > > Hi! > > 1. I meant just a hardcoded breakpoint (not hardware) > > Partially works just BREAK 4, 8. Though I need to do "jump" to=20 next line=20 > > to continue in gdb. >=20 > ah ok=20 > > 2. gdb doesn't work with shared libraries explicitly loaded by=20 program. > > Could you please point to anybody from HP team? >=20 > HP Team? Sorry but officially there is no HP parisc-linux team. > Most of us are interested in kernel hacking and less in > making gdb work. >=20 > > 3. What about ddd? >=20 > sorry - haven't looked at ddd. >=20 ddd is a GUI frontend to gdb... Thibaut VARENE PA/Linux ESIEE Team http://pateam.esiee.fr/ On vacation until Aug 25th From willy@debian.org Sat Aug 23 15:21:59 2003 From: willy@debian.org (Matthew Wilcox) Date: Sat, 23 Aug 2003 15:21:59 +0100 Subject: [parisc-linux] CVS mixups Message-ID: <20030823142159.GM18834@parcelfarce.linux.theplanet.co.uk> So... for the second time I messed up and committed 2.6 to the 2.4 tree. In my defence, this time we were trying the new style of imports so it's not too surprising I got something wrong (and nobody spotted the problem till too late...), but twice is too many. Short term fix: I'm going to merge the latest marcelo patch into our 2.4 tree today. Looks like that'll be 2.4.22-rc2. That'll fix this cvs diff autogeneration breakage. Long term fix: I'm going to rename the linux tree to linux-2.4. This will cause some disruption since everyone with a cvs tree checked out will have to mangle it to work again. I'll make a script available in build-tools to mangle your tree for you. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From jsoe0708@tiscali.be Sat Aug 23 16:54:26 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Sat, 23 Aug 2003 16:54:26 +0100 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos Message-ID: <3F2E2C7700004A24@ocpmta2.freegates.net> >Congratulation, I will try it also on the N (64bits) I grab last osdl-aim-7-0.1.9 (date Aug 04) and launch the test that Grant mentionned (I just stop the 3d run (option -r3) with kernel without patch because -e500 seems to take too much time: full night and I want to test the patched kernel) With the patch kernel I also want to launch 3 run test but with -e300 (Just have a N obviously UP 550Mhz?). The first two run seems to work fine when during the last run I get a lot of messages "Child caught raw signal ?" and so I could not grab (cut and past) the first results :( . I now relaunch test for only two runs and so hope the results for next week, sorry. Thanks again, Joel ------------------------------------------ ------------------------------ Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg= > r _______________________________________________ parisc-linux mailing list parisc-linux@lists.p risc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From James.Bottomley@steeleye.com Sat Aug 23 16:59:48 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 23 Aug 2003 10:59:48 -0500 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: References: Message-ID: <1061654391.1995.74.camel@mulgrave> --=-twwyVK3YP0a7nX0FTdaG Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2003-08-23 at 02:22, Hugh Dickins wrote: > Good idea. It's VM_MAYSHARE you need to check for. OK, to get all this to work, there's a corner case in do_mremap() that I need to be fixed: When choosing the flags for the new area, it keys off VM_SHARED to determine whether MAP_SHARED is passed to the mapping. It has to key of VM_MAYSHARE to preserve VM_MAYSHARE on the new mapping. Patch below. James --=-twwyVK3YP0a7nX0FTdaG Content-Disposition: inline; filename=tmp.diff Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=tmp.diff; charset=ISO-8859-1 =3D=3D=3D=3D=3D mremap.c 1.32 vs edited =3D=3D=3D=3D=3D --- 1.32/mm/mremap.c Thu Aug 7 12:29:10 2003 +++ edited/mremap.c Sat Aug 23 10:54:21 2003 @@ -420,7 +420,7 @@ if (flags & MREMAP_MAYMOVE) { if (!(flags & MREMAP_FIXED)) { unsigned long map_flags =3D 0; - if (vma->vm_flags & VM_SHARED) + if (vma->vm_flags & VM_MAYSHARE) map_flags |=3D MAP_SHARED; =20 new_addr =3D get_unmapped_area(vma->vm_file, 0, new_len, --=-twwyVK3YP0a7nX0FTdaG-- From dave@hiauly3.hia.nrc.ca Sat Aug 23 17:12:07 2003 From: dave@hiauly3.hia.nrc.ca (John David Anglin) Date: Sat, 23 Aug 2003 12:12:07 -0400 (EDT) Subject: [parisc-linux] Re: [glibc] fixing delayed exceptions in hppa In-Reply-To: <20030823055506.GA9821@systemhalted> from Carlos O'Donell at Aug "23," 2003 "01:55:06" am Message-ID: <200308231612.MAA21233@hiauly3.hia.nrc.ca> > On Fri, Aug 22, 2003 at 04:24:19PM -0400, John David Anglin wrote: > > Based on what Jim Hull said, I believe that would be better. I was using > > > > "fldd 0(%%sr0,%%sp),%0" : "=f" (d) : "0" (d) > > > > There isn't a true dependency in the above but I believe that any load > > to the destination register will raise the exception. > > Dave, I'm sorry if you sent me a patch and I dropped it :( Did I ever > receive a diff for this from you? I can't recall but I probably did send it last November. My email machine is still down because of the blackout. > It's rather vague at times because the spec says "or an operation which > depends on a pending, trapping insn." I think DHD, and perhaps myself > got caught up on the "load or store" which probably means only > register->memory (memory->register too) and not register->register. Yes. If you follow the thread that I sent you, Jim Hull comments on this and offers a rewrite of the sentence that you quoted. I believe that referencing memory is important as this makes the operation visible to another processor. A register->register operation doesn't do this. Dave From James.Bottomley@steeleye.com Sat Aug 23 17:25:52 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 23 Aug 2003 11:25:52 -0500 Subject: [parisc-linux] Proposed changes to flush_dcache_page to fix our shared ro mapping problem Message-ID: <1061655953.1992.104.camel@mulgrave> --=-PE2Uwl0LkbJxW+65VgYL Content-Type: text/plain Content-Transfer-Encoding: 7bit The attached should do it (plus the fix to preserve the VM_MAYSHARE flag on remap). I've verified that this fixes the glibc tst-mmap-eofsync test. James --=-PE2Uwl0LkbJxW+65VgYL Content-Disposition: inline; filename=tmp.diff Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=tmp.diff; charset=ISO-8859-1 =3D=3D=3D=3D=3D arch/parisc/kernel/cache.c 1.4 vs edited =3D=3D=3D=3D=3D --- 1.4/arch/parisc/kernel/cache.c Sat Mar 8 14:01:30 2003 +++ edited/arch/parisc/kernel/cache.c Sat Aug 23 11:22:22 2003 @@ -232,7 +232,8 @@ =20 if (!page->mapping) return; - + /* check shared list first if it's not empty...it's usually + * the shortest */ list_for_each(l, &page->mapping->i_mmap_shared) { struct vm_area_struct *mpnt; unsigned long off; @@ -243,6 +244,33 @@ * If this VMA is not in our MM, we can ignore it. */ if (mpnt->vm_mm !=3D mm) + continue; + + if (page->index < mpnt->vm_pgoff) + continue; + + off =3D page->index - mpnt->vm_pgoff; + if (off >=3D (mpnt->vm_end - mpnt->vm_start) >> PAGE_SHIFT) + continue; + + flush_cache_page(mpnt, mpnt->vm_start + (off << PAGE_SHIFT)); + + /* All user shared mappings should be equivalently mapped, + * so once we've flushed one we should be ok + */ + return; + } + + /* then check private mapping list for read only shared mappings + * which are flagged by VM_MAYSHARE */ + list_for_each(l, &page->mapping->i_mmap) { + struct vm_area_struct *mpnt; + unsigned long off; + + mpnt =3D list_entry(l, struct vm_area_struct, shared); + + + if (mpnt->vm_mm !=3D mm || !(mpnt->vm_flags & VM_MAYSHARE)) continue; =20 if (page->index < mpnt->vm_pgoff) --=-PE2Uwl0LkbJxW+65VgYL-- From grundler@parisc-linux.org Sat Aug 23 20:28:34 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Sat, 23 Aug 2003 13:28:34 -0600 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <3F2E2C7700004A24@ocpmta2.freegates.net> References: <3F2E2C7700004A24@ocpmta2.freegates.net> Message-ID: <20030823192834.GC5072@dsl2.external.hp.com> On Sat, Aug 23, 2003 at 04:54:26PM +0100, Joel Soete wrote: > With the patch kernel I also want to launch 3 run test but with -e300 (Just > have a N obviously UP 550Mhz?). Pick whatever parameters are reasonable. The -e100 to -e500 worked well on a dual 1Ghz rx2600 with 3 or 4 GB of RAM. You might try -e50 -> -e250 in steps of 50....at least until the VM address aliasing is fixed and you can run 8-way on the N-class. > The first two run seems to work fine when during the last run I get a lot > of messages "Child caught raw signal ?" and so I could not grab (cut and > past) the first results :( . > > I now relaunch test for only two runs and so hope the results for next week, > sorry. np - thanks. grant From davem@redhat.com Sat Aug 23 22:43:30 2003 From: davem@redhat.com (David S. Miller) Date: Sat, 23 Aug 2003 14:43:30 -0700 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <1061600974.2090.809.camel@mulgrave> References: <20030822110144.5f7b83c5.davem@redhat.com> <20030822113106.0503a665.davem@redhat.com> <1061578568.2053.313.camel@mulgrave> <20030822121955.619a14eb.davem@redhat.com> <1061591255.1784.636.camel@mulgrave> <20030822154100.06314c8e.davem@redhat.com> <1061600974.2090.809.camel@mulgrave> Message-ID: <20030823144330.5ddab065.davem@redhat.com> On 22 Aug 2003 20:09:30 -0500 James Bottomley wrote: > What we were hoping is that we could rely on this little property of > mmap: > > MAP_PRIVATE > Create a private copy-on-write mapping. Stores > to the region do not affect the original file. > It is unspecified whether changes made to the > file after the mmap call are visible in the > mapped region. > > To avoid having to flush the non-shared mappings (basically on parisc if > you write to a file backing a MAP_PRIVATE mapping then we don't > guarantee you see the update). > > I suppose if we had a way of telling if any of the i_mmap list members > were really MAP_SHARED semantics mappings, then we could alter our > flush_dcache_page() implementation to work. I thought about this very deeply last night and this morning. And what you're trying to optimize won't work. Here is why. If the first access to a MAP_PRIVATE mapping of a page is a read, we'll use the page-cache page. This means that, with your optimization, during this time if another cpu write()`s into the page we'll lose the data update. Sorry :( From davem@redhat.com Sat Aug 23 22:44:36 2003 From: davem@redhat.com (David S. Miller) Date: Sat, 23 Aug 2003 14:44:36 -0700 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: References: <1061600974.2090.809.camel@mulgrave> Message-ID: <20030823144436.63cf118f.davem@redhat.com> On Sat, 23 Aug 2003 08:22:19 +0100 (BST) Hugh Dickins wrote: > On 22 Aug 2003, James Bottomley wrote: > > > > I suppose if we had a way of telling if any of the i_mmap list members > > were really MAP_SHARED semantics mappings, then we could alter our > > flush_dcache_page() implementation to work. > > Good idea. It's VM_MAYSHARE you need to check for. Nope, please see my other email for why all of these ideas simply will not work. If the first fault-in of a MAP_PRIVATE page is a read, it's just like a MAP_SHARED read-only page until the first write occurs. From James.Bottomley@steeleye.com Sat Aug 23 23:21:21 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 23 Aug 2003 17:21:21 -0500 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030823144330.5ddab065.davem@redhat.com> References: <20030822110144.5f7b83c5.davem@redhat.com> <20030822113106.0503a665.davem@redhat.com> <1061578568.2053.313.camel@mulgrave> <20030822121955.619a14eb.davem@redhat.com> <1061591255.1784.636.camel@mulgrave> <20030822154100.06314c8e.davem@redhat.com> <1061600974.2090.809.camel@mulgrave> <20030823144330.5ddab065.davem@redhat.com> Message-ID: <1061677283.1992.471.camel@mulgrave> On Sat, 2003-08-23 at 16:43, David S. Miller wrote: > On 22 Aug 2003 20:09:30 -0500 > James Bottomley wrote: > > > What we were hoping is that we could rely on this little property of > > mmap: > > > > MAP_PRIVATE > > Create a private copy-on-write mapping. Stores > > to the region do not affect the original file. > > It is unspecified whether changes made to the > > file after the mmap call are visible in the > > mapped region. > > > > To avoid having to flush the non-shared mappings (basically on parisc if > > you write to a file backing a MAP_PRIVATE mapping then we don't > > guarantee you see the update). > > > > I suppose if we had a way of telling if any of the i_mmap list members > > were really MAP_SHARED semantics mappings, then we could alter our > > flush_dcache_page() implementation to work. > > I thought about this very deeply last night and this morning. > And what you're trying to optimize won't work. Here is why. > > If the first access to a MAP_PRIVATE mapping of a page is a read, > we'll use the page-cache page. This means that, with your > optimization, during this time if another cpu write()`s into the > page we'll lose the data update. > > Sorry :( Could you elaborate some more? I agree that the MAP_PRIVATE mapping may not see cpu1's write because of cache incoherencies (but that's what I believe is covered by the `unspecified' bit of the MAP_PRIVATE definition above). MAP_PRIVATE is COW (i.e. the page is marked read only while it's shared), so there can be no data to flush in the cache for the page of the MAP_PRIVATE process...The only scenario I see where we can get cache based data destruction is if two cache aliases both contain dirty caches for the page (which can only happen for MAP_SHARED RW, which we already have the correct semantics for...they're racing to do a msync and the last one in wins). James From davem@redhat.com Sat Aug 23 23:51:27 2003 From: davem@redhat.com (David S. Miller) Date: Sat, 23 Aug 2003 15:51:27 -0700 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <1061677283.1992.471.camel@mulgrave> References: <20030822110144.5f7b83c5.davem@redhat.com> <20030822113106.0503a665.davem@redhat.com> <1061578568.2053.313.camel@mulgrave> <20030822121955.619a14eb.davem@redhat.com> <1061591255.1784.636.camel@mulgrave> <20030822154100.06314c8e.davem@redhat.com> <1061600974.2090.809.camel@mulgrave> <20030823144330.5ddab065.davem@redhat.com> <1061677283.1992.471.camel@mulgrave> Message-ID: <20030823155127.3cd7b013.davem@redhat.com> On 23 Aug 2003 17:21:21 -0500 James Bottomley wrote: > On Sat, 2003-08-23 at 16:43, David S. Miller wrote: > > On 22 Aug 2003 20:09:30 -0500 > > James Bottomley wrote: > > > > > MAP_PRIVATE > > > Create a private copy-on-write mapping. Stores > > > to the region do not affect the original file. > > > It is unspecified whether changes made to the > > > file after the mmap call are visible in the > > > mapped region. ... > Could you elaborate some more? I agree that the MAP_PRIVATE mapping may > not see cpu1's write because of cache incoherencies (but that's what I > believe is covered by the `unspecified' bit of the MAP_PRIVATE > definition above). Ok. Let me think about this a bit more. The safest solution for parisc, meanwhile, would be to walk the non-shared mmap list checking for any instance of the VM_MAYSHARE bit being set. From davem@redhat.com Sat Aug 23 23:53:12 2003 From: davem@redhat.com (David S. Miller) Date: Sat, 23 Aug 2003 15:53:12 -0700 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <1061677283.1992.471.camel@mulgrave> References: <20030822110144.5f7b83c5.davem@redhat.com> <20030822113106.0503a665.davem@redhat.com> <1061578568.2053.313.camel@mulgrave> <20030822121955.619a14eb.davem@redhat.com> <1061591255.1784.636.camel@mulgrave> <20030822154100.06314c8e.davem@redhat.com> <1061600974.2090.809.camel@mulgrave> <20030823144330.5ddab065.davem@redhat.com> <1061677283.1992.471.camel@mulgrave> Message-ID: <20030823155312.63f996f6.davem@redhat.com> On 23 Aug 2003 17:21:21 -0500 James Bottomley wrote: > On Sat, 2003-08-23 at 16:43, David S. Miller wrote: > > On 22 Aug 2003 20:09:30 -0500 > > James Bottomley wrote: > > > > > To avoid having to flush the non-shared mappings (basically on parisc if > > > you write to a file backing a MAP_PRIVATE mapping then we don't > > > guarantee you see the update). BTW, what gains to you really get from this optimization? How often do writes happen to files while private mappings to it exist? :-) This is one of the reasons I think this discussion is a bit silly. What specific cases does your optimization help, and how common is it? Show us some numbers. From James.Bottomley@steeleye.com Sun Aug 24 00:01:00 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 23 Aug 2003 18:01:00 -0500 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030823155127.3cd7b013.davem@redhat.com> References: <20030822110144.5f7b83c5.davem@redhat.com> <20030822113106.0503a665.davem@redhat.com> <1061578568.2053.313.camel@mulgrave> <20030822121955.619a14eb.davem@redhat.com> <1061591255.1784.636.camel@mulgrave> <20030822154100.06314c8e.davem@redhat.com> <1061600974.2090.809.camel@mulgrave> <20030823144330.5ddab065.davem@redhat.com> <1061677283.1992.471.camel@mulgrave> <20030823155127.3cd7b013.davem@redhat.com> Message-ID: <1061679662.1785.514.camel@mulgrave> On Sat, 2003-08-23 at 17:51, David S. Miller wrote: > Ok. Let me think about this a bit more. > > The safest solution for parisc, meanwhile, would be to walk the > non-shared mmap list checking for any instance of the VM_MAYSHARE bit > being set. Right, that's how I plan to fix this problem in parisc. We also need the VM_MAYSHARE flag to propagate across remappings, which was the general kernel fix I sent some emails back. James From James.Bottomley@steeleye.com Sun Aug 24 00:11:16 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 23 Aug 2003 18:11:16 -0500 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030823155312.63f996f6.davem@redhat.com> References: <20030822110144.5f7b83c5.davem@redhat.com> <20030822113106.0503a665.davem@redhat.com> <1061578568.2053.313.camel@mulgrave> <20030822121955.619a14eb.davem@redhat.com> <1061591255.1784.636.camel@mulgrave> <20030822154100.06314c8e.davem@redhat.com> <1061600974.2090.809.camel@mulgrave> <20030823144330.5ddab065.davem@redhat.com> <1061677283.1992.471.camel@mulgrave> <20030823155312.63f996f6.davem@redhat.com> Message-ID: <1061680279.1785.534.camel@mulgrave> On Sat, 2003-08-23 at 17:53, David S. Miller wrote: > BTW, what gains to you really get from this optimization? > > How often do writes happen to files while private mappings > to it exist? :-) This is one of the reasons I think this > discussion is a bit silly. > > What specific cases does your optimization help, and how common is it? > Show us some numbers. Not having to flush the private mappings is a huge optimisation. Our current flush_dcache_page implementation allows us only to flush a single page and get all the aliased caches updated because we carefully align MAP_SHARED areas (by supplying our own arch_get_unmapped_area()). However, the alignment constraint is 4MB to get this property of the virtually aliased caches, so we can't afford to align all mappings like this (for our 32 bit userspace, anyway). If we were to have to flush the private i_mmap list, we'd have to do a page flush for *every* entry in the list (that's 256 instructions per page at a cache width of 16 bytes). This would be a horrific overhead. using the VM_MAYSHARE to carry the read only shared mapping semantics indication still allows us to align correctly, but the only additional overhead we incur is to walk the i_mmap list to find VM_MAYSHARE mappings as well as i_mmap_shared. Since we can key of VM_MAYSHARE to do the alignment, we still only need flush the first one we come to. This all works as long as we can agree there are no pathological mmap cases that force us to flush *all* the i_mmap mappings...which is what I think the discussion has come down to. James From davem@redhat.com Sun Aug 24 01:22:51 2003 From: davem@redhat.com (David S. Miller) Date: Sat, 23 Aug 2003 17:22:51 -0700 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <1061680279.1785.534.camel@mulgrave> References: <20030822110144.5f7b83c5.davem@redhat.com> <20030822113106.0503a665.davem@redhat.com> <1061578568.2053.313.camel@mulgrave> <20030822121955.619a14eb.davem@redhat.com> <1061591255.1784.636.camel@mulgrave> <20030822154100.06314c8e.davem@redhat.com> <1061600974.2090.809.camel@mulgrave> <20030823144330.5ddab065.davem@redhat.com> <1061677283.1992.471.camel@mulgrave> <20030823155312.63f996f6.davem@redhat.com> <1061680279.1785.534.camel@mulgrave> Message-ID: <20030823172251.4e656f9a.davem@redhat.com> On 23 Aug 2003 18:11:16 -0500 James Bottomley wrote: > On Sat, 2003-08-23 at 17:53, David S. Miller wrote: > > How often do writes happen to files while private mappings > > to it exist? :-) This is one of the reasons I think this > > discussion is a bit silly. ... > Not having to flush the private mappings is a huge optimisation. You're not answering my question :( I know that when the case _DOES_ happen, your optimization is worthwhile, my question is not about this. My question is about how often does this case happen. From James.Bottomley@steeleye.com Sun Aug 24 06:17:55 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 24 Aug 2003 00:17:55 -0500 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030823172251.4e656f9a.davem@redhat.com> References: <20030822110144.5f7b83c5.davem@redhat.com> <20030822113106.0503a665.davem@redhat.com> <1061578568.2053.313.camel@mulgrave> <20030822121955.619a14eb.davem@redhat.com> <1061591255.1784.636.camel@mulgrave> <20030822154100.06314c8e.davem@redhat.com> <1061600974.2090.809.camel@mulgrave> <20030823144330.5ddab065.davem@redhat.com> <1061677283.1992.471.camel@mulgrave> <20030823155312.63f996f6.davem@redhat.com> <1061680279.1785.534.camel@mulgrave> <20030823172251.4e656f9a.davem@redhat.com> Message-ID: <1061702282.1992.1153.camel@mulgrave> On Sat, 2003-08-23 at 19:22, David S. Miller wrote: > You're not answering my question :( > > I know that when the case _DOES_ happen, your optimization is > worthwhile, my question is not about this. My question is about > how often does this case happen. Well the case we're arguing about depends on whether glibc uses mmaped file descriptors for libio. If it doesn't (which is how my machine is configured) then you're right, we never get to loop the i_mmap list because it's usually empty when flush_dcache_page is called. The only things I can really come up with are contrived cases with glibc mmaped file objects...then it is a big win if we open lots of mappings---which I guess would mainly happen with multi-threaded applications. Do you have any applications you'd like me to run comparisons on? James From davem@redhat.com Sun Aug 24 06:23:00 2003 From: davem@redhat.com (David S. Miller) Date: Sat, 23 Aug 2003 22:23:00 -0700 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <1061702282.1992.1153.camel@mulgrave> References: <20030822110144.5f7b83c5.davem@redhat.com> <20030822113106.0503a665.davem@redhat.com> <1061578568.2053.313.camel@mulgrave> <20030822121955.619a14eb.davem@redhat.com> <1061591255.1784.636.camel@mulgrave> <20030822154100.06314c8e.davem@redhat.com> <1061600974.2090.809.camel@mulgrave> <20030823144330.5ddab065.davem@redhat.com> <1061677283.1992.471.camel@mulgrave> <20030823155312.63f996f6.davem@redhat.com> <1061680279.1785.534.camel@mulgrave> <20030823172251.4e656f9a.davem@redhat.com> <1061702282.1992.1153.camel@mulgrave> Message-ID: <20030823222300.4695a0c4.davem@redhat.com> > The only things I can really come up with are contrived cases with glibc > mmaped file objects...then it is a big win if we open lots of > mappings---which I guess would mainly happen with multi-threaded > applications. Do you have any applications you'd like me to run > comparisons on? This is what I'm asking of you, to find cases in real life, not some contrived example, where your optimization helps appreciably. From joel.soete@tiscali.be Sun Aug 24 13:51:10 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Sun, 24 Aug 2003 12:51:10 +0000 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <20030823192834.GC5072@dsl2.external.hp.com> References: <3F2E2C7700004A24@ocpmta2.freegates.net> <20030823192834.GC5072@dsl2.external.hp.com> Message-ID: <3F48B4BE.7090803@tiscali.be> Grant Grundler wrote: > [...] at least until the VM > address aliasing is fixed and you can run 8-way on the N-class. :)) it was just a machine for testing and so to save money there was just purchased 2 cpu (but for my part it would already be nice to make it run in SMP mode :) ) btw: I countinue investigations but I still have to learn a lot about how [id]tlb's cach are managed during cpu's startup... Ha yes, question: can I find PSW for each cpu in a piminfo? Thanks again, Joel From James.Bottomley@steeleye.com Sun Aug 24 17:54:00 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 24 Aug 2003 11:54:00 -0500 Subject: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) In-Reply-To: <20030823222300.4695a0c4.davem@redhat.com> References: <20030822110144.5f7b83c5.davem@redhat.com> <20030822113106.0503a665.davem@redhat.com> <1061578568.2053.313.camel@mulgrave> <20030822121955.619a14eb.davem@redhat.com> <1061591255.1784.636.camel@mulgrave> <20030822154100.06314c8e.davem@redhat.com> <1061600974.2090.809.camel@mulgrave> <20030823144330.5ddab065.davem@redhat.com> <1061677283.1992.471.camel@mulgrave> <20030823155312.63f996f6.davem@redhat.com> <1061680279.1785.534.camel@mulgrave> <20030823172251.4e656f9a.davem@redhat.com> <1061702282.1992.1153.camel@mulgrave> <20030823222300.4695a0c4.davem@redhat.com> Message-ID: <1061744042.13315.29.camel@mulgrave> On Sun, 2003-08-24 at 00:23, David S. Miller wrote: > This is what I'm asking of you, to find cases in real life, > not some contrived example, where your optimization helps > appreciably. Oh, OK, that's easy...it's what the glibc test was designed for. In glibc, for each file you fopen as a mapped file, you seem to get a separate mmapping of the file (this actually looks wrong to me...it seems glibc should have only one mapping per file which all the file objects share, but anyway). That means we get one entry in one of the i_mmaps lists for each of the opens. Since these are files, the chances are they'll be read and written which will generate lots of dcache flushes. This case would kill us if we had to flush every entry in i_mmap. Right at the moment, you have to specifically request that the file be mmapped by specifying the "m" modifier, but glibc seems to be migrating to this being the default one day...that's what I want to be ready for. Besides the optimisation adds no overhead and compromises nothing, so its worth doing regardless. James From grundler@parisc-linux.org Sun Aug 24 18:19:08 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Sun, 24 Aug 2003 11:19:08 -0600 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <3F48B4BE.7090803@tiscali.be> References: <3F2E2C7700004A24@ocpmta2.freegates.net> <20030823192834.GC5072@dsl2.external.hp.com> <3F48B4BE.7090803@tiscali.be> Message-ID: <20030824171908.GC32533@dsl2.external.hp.com> On Sun, Aug 24, 2003 at 12:51:10PM +0000, Joel Soete wrote: > btw: I countinue investigations but I still have to learn a lot about > how [id]tlb's cach are managed during cpu's startup... I thought this was a runtime problem (ie userspace <-> kernel interaction) > Ha yes, question: can I find PSW for each cpu in a piminfo? yes grant From carlos@baldric.uwo.ca Sun Aug 24 21:38:57 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Sun, 24 Aug 2003 16:38:57 -0400 Subject: [parisc-linux] Re: Added a new SCSI disk, hda became hdb In-Reply-To: <20030824191340.GG5304@charite.de> References: <20030824191340.GG5304@charite.de> Message-ID: <20030824203857.GD17595@systemhalted> On Sun, Aug 24, 2003 at 09:13:40PM +0200, Ralf Hildebrandt wrote: > Hi! > > Today I added a new SCSI disk, and hda -- my bootdisk -- became hdb -- no > matter which SCSI ID I chose for the new disk. > > The old disk has ID 6, and I can do whatever I want, once I add the new > disk, I cannot boot, since the kernel doesn't find it's rootfs on hda > -- since it's hdb now. > > How can I add a new physical disk as hdb ? Put the disks in the reverse order? An example is that any A500 or rp2430 labels the drives as 'scsia' and 'scsib', but linux finds them in the reverse order. When only one drive is in 'scsia' it's sda, but when a second drive is added to 'scsib' the order is reversed ('scsia' becomes sdb and 'scsib' becomes sda). c. From willy@debian.org Sun Aug 24 22:42:12 2003 From: willy@debian.org (Matthew Wilcox) Date: Sun, 24 Aug 2003 22:42:12 +0100 Subject: [parisc-linux] Re: Added a new SCSI disk, hda became hdb In-Reply-To: <20030824203857.GD17595@systemhalted> References: <20030824191340.GG5304@charite.de> <20030824203857.GD17595@systemhalted> Message-ID: <20030824214212.GB18834@parcelfarce.linux.theplanet.co.uk> On Sun, Aug 24, 2003 at 04:38:57PM -0400, Carlos O'Donell wrote: > Put the disks in the reverse order? > > An example is that any A500 or rp2430 labels the drives as 'scsia' and > 'scsib', but linux finds them in the reverse order. When only one drive is > in 'scsia' it's sda, but when a second drive is added to 'scsib' the > order is reversed ('scsia' becomes sdb and 'scsib' becomes sda). This is because HPUX uses the ANSI-approved scan order -- 7,6,5,...,0 and Linux uses the PC-compatible scan order -- 0,1,2,...,7. It's kind of possible to control it by setting shost->reverse_ordering but it's not easy to set this in any reasonable way. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From grundler@parisc-linux.org Mon Aug 25 04:55:24 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Sun, 24 Aug 2003 21:55:24 -0600 Subject: [parisc-linux] Re: Added a new SCSI disk, hda became hdb In-Reply-To: <20030824214212.GB18834@parcelfarce.linux.theplanet.co.uk> References: <20030824191340.GG5304@charite.de> <20030824203857.GD17595@systemhalted> <20030824214212.GB18834@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030825035524.GB10969@dsl2.external.hp.com> On Sun, Aug 24, 2003 at 10:42:12PM +0100, Matthew Wilcox wrote: > This is because HPUX uses the ANSI-approved scan order -- 7,6,5,...,0 Not true. HPUX scans the SCSI bus from 0-7 for narrow or 0-15 for wide. Under HPUX, SCSI controllers are assigned instance numbers and the kernel records those in /stand/ioconfig. The SCSI controller will get the same instance number after reboot regardless of other IO devices changing. grant From LAssinovsky@algorithm.aelita.com Mon Aug 25 09:31:50 2003 From: LAssinovsky@algorithm.aelita.com (Lev Assinovsky) Date: Mon, 25 Aug 2003 12:31:50 +0400 Subject: [parisc-linux] Help: Need instruction sequence for gdb breakpoint Message-ID: <3F6F4712B759A34ABD453A8B39C10D62DEED89@bagman.edm.com> I meant have you heard about ddd for HP-UX 11.00? ---- Lev Assinovsky Aelita Software Corporation O&S Core Division, Programmer ICQ# 165072909 > -----Original Message----- > From: Thibaut VARENE [mailto:varenet@esiee.fr] > Sent: Saturday, August 23, 2003 1:56 PM > To: Grant Grundler > Cc: Lev Assinovsky; parisc-linux@lists.parisc-linux.org > Subject: Re: [parisc-linux] Help: Need instruction sequence for gdb > breakpoint >=20 >=20 > ------------------- > > On Fri, Aug 22, 2003 at 09:13:37PM +0400, Lev Assinovsky wrote: > > > Hi! > > > 1. I meant just a hardcoded breakpoint (not hardware) > > > Partially works just BREAK 4, 8. Though I need to do "jump" to=20 > next line=20 > > > to continue in gdb. > >=20 > > ah ok=20 > > > 2. gdb doesn't work with shared libraries explicitly loaded by=20 > program. > > > Could you please point to anybody from HP team? > >=20 > > HP Team? Sorry but officially there is no HP parisc-linux team. > > Most of us are interested in kernel hacking and less in > > making gdb work. > >=20 > > > 3. What about ddd? > >=20 > > sorry - haven't looked at ddd. > >=20 >=20 > ddd is a GUI frontend to gdb... >=20 >=20 > Thibaut VARENE > PA/Linux ESIEE Team > http://pateam.esiee.fr/ > On vacation until Aug 25th >=20 >=20 From jsoe0708@tiscali.be Mon Aug 25 11:03:20 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Mon, 25 Aug 2003 12:03:20 +0200 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos Message-ID: <3F2E2C7700004E38@ocpmta2.freegates.net> >> btw: I countinue investigations but I still have to learn a lot about >> how [id]tlb's cach are managed during cpu's startup... > >I thought this was a runtime problem (ie userspace <-> kernel >interaction) > I still have to make some additional test and grab much more info. In a previous mail (N4000 running SMP), I just report an interesting experience (well for me, I would just like to reproduce it but now by collecting info until crash and piminfo). After more thought, I figure out that printk() just slow down the moment of panic. Never the less, where I am waiting a panic (if I well understand Willy's idea), I got much 'itlb miss fault' followed by 'dtlb miss fault'? So I would like to study now the early boot process (specialy for the second cpu) to try to understand how caches (for shared insn and data) are replicated into other CPU's [id]tlb. > Ha yes, question: can I find PSW for each cpu in a piminfo? yes Can you tell me more: in a previous piminfo collected I got for CPU#3 (3 is the "address" of the second cpu) [...] ------- Processor 3 HPMC Information - PDC Version: 41.28 ------ Timestamp = Mon Aug 11 12:56:02 GMT 2003 (20:03:08:11:12:56:02) HPMC Chassis Codes Chassis Code Extension ------------ --------- 0x0000082000ff6242 0x0000000000000000 0x1800082011036322 0xcb81800000000000 General Registers 0 - 31 00-03 0000000000000000 0000000010536c70 0000000010115e58 00000000103aaf64 04-07 0000000000000002 00000000103ac494 0000000000000001 0000000010527470 08-11 0000000000000001 000000008f1f45b8 000000008f3cebc0 000000001057dcb0 12-15 00000000faf005f0 0000000000028280 0000000000020000 00000000faf00548 16-19 00000000faf005d0 0000000000004000 0000000000016000 0000000000000001 20-23 0000000000006061 000000001044ec08 0000000010539c70 000000001041b130 24-27 0000000000000000 000000000800000f 0000000010527c70 0000000010527470 28-31 0000000000000480 000000008f1f4e30 000000008f1f4e40 000000001052a470 Control Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000010 0000000000000000 00000000000000c0 0000000000000036 12-15 0000000000000000 0000000000000000 0000000000107000 ffe0000000000000 16-19 0000001f0fd05cbd 0000000000000000 0000000010116050 0000000008000240 20-23 0000000000000000 0000000000000000 000000000806070f 0000000000000000 24-27 0000000000453000 000000007f1f2000 0000000000041020 000000ffff95c810 28-31 000000ffff95c810 5555555555555555 000000008f1f4000 0000000000008020 Space Registers 0 - 7 00-03 00000400 00000400 00000000 00000400 04-07 00000000 00000000 00000000 00000000 IIA Space (back entry) = 0x0000000000000000 IIA Offset (back entry) = 0x0000000010116054 Check Type = 0x20000000 CPU State = 0x9e000004 Cache Check = 0x00000000 TLB Check = 0x00000000 Bus Check = 0x0030000d Assists Check = 0x00000000 Assist State = 0x00000000 Path Info = 0x00000000 System Responder Address = 0xfffffffffed2d000 System Requestor Address = 0x000000fffed2c000 Floating Point Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000010586ec0 0000000000000002 00000000104c7b68 0000000000000420 08-11 0000000000000000 0000000000000802 0000000010527470 000000001058a000 12-15 00000000135a0000 0000000000000000 000000001017dc84 00000000103ceb94 16-19 00000000000009f0 000000008facf000 0000000010527470 00000000135a0000 20-23 00000000103aa184 fffffffffffffff4 00000000003f45a2 000000000000ba2e 24-27 0000999900000000 00009999035a0b70 00000000035a0b78 000000001040d980 28-31 000000001040d980 00000000ff915e20 0000000010185248 0000000000000016 Check Summary = 0xcb81800000000000 Available Memory = 0x0000000100000000 CPU Diagnose Register 2 = 0x0301030800802004 CPU Status Register 0 = 0x3640c24000000000 CPU Status Register 1 = 0x8000000000000000 SADD LOG = 0x48e0000000000002 Read Short LOG = 0xc18080ff80080014 ----------------- DEW 3 HPMC Information - ------ Timestamp = Mon Aug 11 12:56:02 GMT 2003 (20:03:08:11:12:56:02) Runway Control Log Reg = 0x0006720000000000 Runway Address Data Log Reg Odd = 0xfffffffffffc3f00 Runway Address Data Log Reg Even = 0xfffffffffffc3f00 Runway Address Log Reg = 0x0000000000000048 Runway Broad Error Log Reg = 0x00000000000000dc OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- X ERR_ERROR X X X Merced Bus Requestor Address = 0x0000000000000000 Merced Bus Target Address = 0x0000000000000000 Merced Bus Responder Address = 0x0000000000000000 Merced Error Status Reg = 0x2001000000082004 Merced Error Overflow Reg = 0x0000000000082000 Merced AERR Addr1 Log Reg = 0x00c0000000300000 Merced AERR Addr2 Log Reg = 0x0000000000f00000 Merced DERR Log Reg = 0x00c1100000000000 Merced Error Syndrome Reg = 0x0000000052000000 ------- Processor 3 LPMC Information ------------------ [...] (all 0) ------- Processor 3 TOC Information ------------------- [...] (all 0) -------------- Memory Error Log Information -------------- Bus 0 Log Information Timestamp = Mon Aug 11 12:56:02 GMT 2003 (20:03:08:11:12:56:02) OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- ERR_ERROR X X Bus Requestor Address = 0x0000000000000000 Bus Target Address = 0x0000000000000000 Bus Responder Address = 0x0000000000000000 Error Status Reg = 0x0000000000080000 Error Overflow Reg = 0x0000000000080000 AERR Address 1 Log Reg = 0x0000000000000000 AERR Address 2 Log Reg = 0xf800000000000000 FERR Log Reg = 0x0000000000000000 DERR Log Reg = 0x000112800051cdc0 Error Syndrome Reg = 0x0000000000000000 Address/Control Parity Error Registers Address/Control Parity Error Bit (AE) Not Set Bus 1 Log Information Timestamp = Mon Aug 11 12:56:02 GMT 2003 (20:03:08:11:12:56:02) OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- ERR_TIMEOUT X X Bus Requestor Address = 0xfffffffffed2c000 Bus Target Address = 0x00000000f000a000 Bus Responder Address = 0x0000000000000000 Error Status Reg = 0x0000000000000800 Error Overflow Reg = 0x0000000000000800 AERR Address 1 Log Reg = 0x08006000f000a000 AERR Address 2 Log Reg = 0x6000b0002f700a10 FERR Log Reg = 0x0000000000000000 DERR Log Reg = 0x0000000000000000 Error Syndrome Reg = 0x0000000000000000 Address/Control Parity Error Registers Address/Control Parity Error Bit (AE) Not Set ------------ I/O Module Error Log Information ------------ Summary of IO subsystem log entries ----------------------------------- Phys Loc Vendor Device Severity Description (hex) Id Id CORR UNC FE CW ----------- ----- ------ ------ ---------------- System Bus Adapter SB 0x000000ffffffff82 0x103c 0x1050 X System Bus Adapter SB 0x000000ffffffff82 0x103c 0x1050 X Detail display of IO subsystem log entries ------------------------------------------ System Bus Adapter -- System Bus Interface ------------------------------------------ Timestamp = Mon Aug 11 12:56:02 GMT 2003 (20:03:08:11:12:56:02) OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- X X ERR_ERROR X X IO Requestor Address = 0x0000000000000000 IO Target Address = 0x0000000000000000 IO Responder Address = 0xfffffffffed00000 IO Physical Location = 0x000000ffffffff82 IO Hardware Path = 0x00ffffffffffff00 Module Error Register = 0x0000000007ff0034 System Bus Adapter -- System Bus Interface ------------------------------------------ Timestamp = Mon Aug 11 12:56:02 GMT 2003 (20:03:08:11:12:56:02) OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- X X ERR_ERROR X X IO Requestor Address = 0x0000000000000000 IO Target Address = 0x0000000000000000 IO Responder Address = 0xfffffffffed40000 IO Physical Location = 0x000000ffffffff82 IO Hardware Path = 0x00ffffffffffff01 Module Error Register = 0x0000000007ff0034 [...] Under which field name is it hiden? Thanks again, Joel btw: a preliminary pim analyse of above mentioned piminfo reports me: [...] Parse IAOQ = 0x000000001010b8cc for CPU[1] Func: update_mmu_cache, Off: 0x4, Addr: 0x1010b8cc 1010b8c0: 37 de 3f 01 ldo -80(sp),sp 1010b8c4: 00 00 00 00 break 0,0 ... 000000001010b8c8 : ... 1010b8c8: 0f c2 12 c1 std rp,-10(,sp) 1010b8cc: 2b 6a 20 00 addil 15000,dp,%r1 [...] hmm very interesting (A yes I was much trying to debug my script then actualy reading outputs: my bad :( ) [...] Parse IAOQ = 0x0000000010116054 for CPU[3] Func: smp_call_function, Off: 0x274, Addr: 0x10116054 10116050: 08 00 02 40 nop 10116054: 0e a0 10 d3 ldd 0(,r21),r19 10116058: 0a 93 04 33 sub r19,r20,r19 1011605c: ee 60 ff c5 cmpib,*> 0,r19,10116044 ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From jsoe0708@tiscali.be Mon Aug 25 13:13:28 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Mon, 25 Aug 2003 14:13:28 +0200 Subject: [parisc-linux] CVS mixups In-Reply-To: <20030823142159.GM18834@parcelfarce.linux.theplanet.co.uk> Message-ID: <3F2E2C7700004F23@ocpmta2.freegates.net> >So... for the second time I messed up and committed 2.6 to the 2.4 tree. Thanks for advise. I just update this Monday morning and just notice that last Carlos's patch (itlb_fault optmizaztion) were reverted (also). Accident? (one step beyond :) ) >In my defence, this time we were trying the new style of imports so it's >not too surprising I got something wrong (and nobody spotted the problem >till too late...), but twice is too many. [In french we say "never twice without thrice" ( :-) )] >Short term fix: I'm going to merge the latest marcelo patch into our >2.4 tree today. Looks like that'll be 2.4.22-rc2. That'll fix this >cvs diff autogeneration breakage. Cool (i am awaiting this for a long time :) ) >Long term fix: I'm going to rename the linux tree to linux-2.4. This will >cause some disruption since everyone with a cvs tree checked out will have >to mangle it to work again. I'll make a script available in build-tools >to mangle your tree for you. Thanks again, Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From jsoe0708@tiscali.be Mon Aug 25 13:16:24 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Mon, 25 Aug 2003 14:16:24 +0200 Subject: [parisc-linux] Help: Need instruction sequence for gdb breakpoint Message-ID: <3F2E2C7700004F27@ocpmta2.freegates.net> > I meant have you heard about ddd for HP-UX 11.00? I compiled it successfully on my b180 with hpux-11.00 (but a long time ago) and it was running fine (for the few I used). hth, Joel PS: Onto http://hpux.connect.org.uk/ there is available a very old release (2.0). But you could try to ask them to compile a sd package for a new release. ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From grundler@parisc-linux.org Mon Aug 25 17:45:53 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 25 Aug 2003 10:45:53 -0600 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <3F2E2C7700004E38@ocpmta2.freegates.net> References: <3F2E2C7700004E38@ocpmta2.freegates.net> Message-ID: <20030825164553.GB28778@dsl2.external.hp.com> On Mon, Aug 25, 2003 at 12:03:20PM +0200, Joel Soete wrote: > So I would like to study now the early boot process > (specialy for the second cpu) to try to understand how caches (for shared > insn and data) are replicated into other CPU's [id]tlb. The additional CPUs just reference (ie load) the shared data using the same address. AFAIK, a cacheline will get loaded as "shared clean" until someone writes to it - which is when the cacheline ping-pong starts. > Can you tell me more: in a previous piminfo collected I got for CPU#3 (3 > is the "address" of the second cpu) PAT PDC (L-/N-class and A500) have hard coded numbers for CPUs. parisc-linux only uses logical CPU numbers to avoid sparsely populated arrays. parisc-linux can get the "Physical CPU #" from PAT PDC. See code inside USE_PAT_CPUID in arch/parisc/kernel/processor.c. You might hack that code a bit so you can correlate logic to physical CPU numbers. grant From James.Bottomley@steeleye.com Mon Aug 25 17:50:45 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 25 Aug 2003 11:50:45 -0500 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <20030825164553.GB28778@dsl2.external.hp.com> References: <3F2E2C7700004E38@ocpmta2.freegates.net> <20030825164553.GB28778@dsl2.external.hp.com> Message-ID: <1061830247.2044.165.camel@mulgrave> On Mon, 2003-08-25 at 11:45, Grant Grundler wrote: > PAT PDC (L-/N-class and A500) have hard coded numbers for CPUs. > parisc-linux only uses logical CPU numbers to avoid sparsely populated > arrays. parisc-linux can get the "Physical CPU #" from PAT PDC. > See code inside USE_PAT_CPUID in arch/parisc/kernel/processor.c. > You might hack that code a bit so you can correlate logic to physical > CPU numbers. Not for 2.6 we shouldn't. The beginnings of the hotplug CPU API made logical CPU numbers deprecated (even for x86, which was the worst logical vs phsyical number abuser). We need to move entirely to physical numbers only for 2.6 James From postmaster@dimat.unipv.it Mon Aug 25 17:52:28 2003 From: postmaster@dimat.unipv.it (postmaster@dimat.unipv.it) Date: Mon, 25 Aug 2003 18:52:28 +0200 (MET DST) Subject: [parisc-linux] VIRUS IN YOUR MAIL Message-ID: <200308251652.h7PGqSN03845@dimat.unipv.it> V I R U S A L E R T Our viruschecker found the 'W32/Sobig-F' virus(es) in your email to the following recipient(s): -> ulisse@dimat.unipv.it Please check your system for viruses, or ask your system administrator to do so. As some viruses can send themselves using fake email addresses it is possible that you did not send it. If so please ignore this notification. For your reference, here are the headers from your email: ------------------------- BEGIN HEADERS ----------------------------- Return-Path: Received: from KOS5 ([62.58.168.62]) by dimat.unipv.it (8.11.6+Sun/8.11.6) with ESMTP id h7PGpEs03830 for ; Mon, 25 Aug 2003 18:51:23 +0200 (MET DST) From: parisc-linux@lists.parisc-linux.org Message-Id: <200308251651.h7PGpEs03830@dimat.unipv.it> To: Subject: Re: Re: My details Date: Mon, 25 Aug 2003 18:50:00 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_001B0665" -------------------------- END HEADERS ------------------------------ From Randolph Chung Mon Aug 25 18:13:30 2003 From: Randolph Chung (Randolph Chung) Date: Mon, 25 Aug 2003 10:13:30 -0700 Subject: [parisc-linux] gdb and 2.6 kernel Message-ID: <20030825171330.GN21328@tausq.org> I noticed that gdb breakpoints don't seem to work when running a 2.6 kernel.... do other people see this problem too? I guess it might be a icache flushing problem, but I don't see why 2.6 will be different from 2.4. Does anybody have some time to look into this? thanks, randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From jsoe0708@tiscali.be Mon Aug 25 18:26:17 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Mon, 25 Aug 2003 19:26:17 +0200 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <20030823192834.GC5072@dsl2.external.hp.com> Message-ID: <3F2E2C770000510F@ocpmta2.freegates.net> Well sorry for delay but here are some results with reaim: ** without itlb patch: palx4000:# ./reaim -s25 -i25 -e300 -t -f workfile.new_dbase REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 25 169.01 53.58 110.99 914.15 36.57 4.14 2.51 97 50 325.85 100.05 218.86 948.29 18.97 8.06 2.54 97 75 490.89 155.85 326.41 944.20 12.59 15.25 3.21 96 100 651.37 207.02 434.83 948.77 9.49 21.20 3.37 96 125 812.15 259.13 542.80 951.18 7.61 24.58 3.13 96 150 971.88 308.85 651.77 953.82 6.36 31.30 3.33 96 175 1136.93 367.07 758.72 951.25 5.44 34.87 3.16 96 200 1295.63 416.43 867.37 953.98 4.77 41.33 3.30 96 225 1456.38 464.97 977.89 954.76 4.24 48.11 3.42 96 250 1626.22 526.17 1086.14 950.06 3.80 52.59 3.34 96 275 1771.56 563.64 1192.66 959.32 3.49 52.07 3.04 96 300 1943.16 626.54 1301.12 954.12 3.18 58.82 3.13 96 Max Jobs per Minute 959.32 ** With itlb patch palx4000:/usr/src/work/Bench/osdl-aim-7/src# ./reaim -s25 -i25 -e300 -t -f workfile.new_dbase -r2 REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 25 169.10 54.33 110.57 913.66 36.55 4.87 2.96 97 50 333.73 107.53 218.98 925.90 18.52 10.96 3.40 96 75 496.19 160.85 326.81 934.12 12.45 14.36 2.98 97 100 647.24 202.66 435.30 954.82 9.55 18.62 2.97 97 125 811.55 258.77 543.35 951.88 7.62 27.05 3.45 96 150 974.62 312.28 650.87 951.14 6.34 30.33 3.21 96 175 1136.86 364.74 760.01 951.30 5.44 36.03 3.27 96 200 1305.43 426.45 865.77 946.81 4.73 41.49 3.28 96 225 1465.96 475.20 977.01 948.53 4.22 45.79 3.23 96 250 1625.77 526.57 1083.94 950.32 3.80 53.29 3.39 96 275 1785.44 578.00 1191.64 951.87 3.46 57.40 3.32 96 300 1952.36 635.80 1299.95 949.62 3.17 57.21 3.02 96 Max Jobs per Minute 954.82 REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 25 169.98 54.46 111.16 908.93 36.36 6.15 3.73 96 50 331.44 104.88 219.30 932.30 18.65 10.53 3.29 96 75 493.99 156.05 328.53 938.28 12.51 13.40 2.79 97 100 653.11 209.79 434.23 946.24 9.46 21.99 3.48 96 125 814.31 262.08 542.37 948.66 7.59 27.24 3.46 96 150 981.09 317.95 651.39 944.87 6.30 29.74 3.13 96 175 1137.42 364.84 760.67 950.84 5.43 36.31 3.30 96 200 1295.86 415.52 866.98 953.81 4.77 39.21 3.12 96 225 1463.61 472.96 977.13 950.05 4.22 44.79 3.16 96 250 1617.00 517.55 1084.14 955.47 3.82 49.42 3.15 96 275 1791.29 581.68 1193.78 948.76 3.45 57.33 3.31 96 300 1942.85 624.79 1302.10 954.27 3.18 59.52 3.16 96 Max Jobs per Minute 955.47 Now that I find what seems reasonable parameters (?) I would try to reboot the system tomorrow morning and relaunch test with itlb patch (just to confirm results). hth, Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From mmogenius@v8fiesta.co.uk Mon Aug 25 19:59:14 2003 From: mmogenius@v8fiesta.co.uk (mmogenius@v8fiesta.co.uk) Date: Mon, 25 Aug 2003 19:59:14 +0100 Subject: [parisc-linux] CD Not Mounted Message-ID: <1061837954.3f4a5c82ae3d9@webmail.v8fiesta.co.uk> when booting from the cd i am unable to mount the cd for use... i have read some where about this prblem if i am using verbose mode? is this correct if so how do i get round it. Thanks ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From grundler@parisc-linux.org Mon Aug 25 20:19:15 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 25 Aug 2003 13:19:15 -0600 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <1061830247.2044.165.camel@mulgrave> References: <3F2E2C7700004E38@ocpmta2.freegates.net> <20030825164553.GB28778@dsl2.external.hp.com> <1061830247.2044.165.camel@mulgrave> Message-ID: <20030825191915.GA377@dsl2.external.hp.com> On Mon, Aug 25, 2003 at 11:50:45AM -0500, James Bottomley wrote: > Not for 2.6 we shouldn't. My intent was not to commit the code, but just get debugging working. > The beginnings of the hotplug CPU API made > logical CPU numbers deprecated (even for x86, which was the worst > logical vs phsyical number abuser). We need to move entirely to > physical numbers only for 2.6 That's not technically possible. PARISC firmware uses the HPA to reference specific devices (including CPU). We can use the same CPU number as PAT PDC and call them "physical". But systems which don't have PAT PDC can only use arbitrary numbers assigned by the parisc-linux startup code. Maybe there is a way to make the numbers match PIM info output but I'm not sure how. hth, grant From grundler@parisc-linux.org Mon Aug 25 20:31:49 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 25 Aug 2003 13:31:49 -0600 Subject: [parisc-linux] CD Not Mounted In-Reply-To: <1061837954.3f4a5c82ae3d9@webmail.v8fiesta.co.uk> References: <1061837954.3f4a5c82ae3d9@webmail.v8fiesta.co.uk> Message-ID: <20030825193149.GC377@dsl2.external.hp.com> On Mon, Aug 25, 2003 at 07:59:14PM +0100, mmogenius@v8fiesta.co.uk wrote: > when booting from the cd i am unable to mount the cd for use... Need to know which model parisc box you have and which model CD ROM. > i have read some where about this prblem if i am using verbose mode? Where did you read this? (ie post a URL) > is this correct if so > how do i get round it. Thanks grant From mmogenius@v8fiesta.co.uk Mon Aug 25 20:38:34 2003 From: mmogenius@v8fiesta.co.uk (mmogenius@v8fiesta.co.uk) Date: Mon, 25 Aug 2003 20:38:34 +0100 Subject: [parisc-linux] CD Not Mounted In-Reply-To: <20030825193149.GC377@dsl2.external.hp.com> References: <1061837954.3f4a5c82ae3d9@webmail.v8fiesta.co.uk> <20030825193149.GC377@dsl2.external.hp.com> Message-ID: <1061840314.3f4a65ba7293e@webmail.v8fiesta.co.uk> I have a hp visualise b2000 and i am using debian 3.0 (woody) the device type is listed as a FX4830T i dont have the url where i read this unfortunately i have read rather allot of documentation and got verry confused. Thanks Quoting Grant Grundler : > On Mon, Aug 25, 2003 at 07:59:14PM +0100, mmogenius@v8fiesta.co.uk wrote: > > when booting from the cd i am unable to mount the cd for use... > > Need to know which model parisc box you have and which model CD ROM. > > > i have read some where about this prblem if i am using verbose mode? > > Where did you read this? (ie post a URL) > > > is this correct if so > > how do i get round it. Thanks > > > grant > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From James.Bottomley@steeleye.com Mon Aug 25 20:48:40 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 25 Aug 2003 14:48:40 -0500 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <20030825191915.GA377@dsl2.external.hp.com> References: <3F2E2C7700004E38@ocpmta2.freegates.net> <20030825164553.GB28778@dsl2.external.hp.com> <1061830247.2044.165.camel@mulgrave> <20030825191915.GA377@dsl2.external.hp.com> Message-ID: <1061840921.2044.368.camel@mulgrave> On Mon, 2003-08-25 at 14:19, Grant Grundler wrote: > That's not technically possible. > PARISC firmware uses the HPA to reference specific devices (including CPU). > > We can use the same CPU number as PAT PDC and call them "physical". > But systems which don't have PAT PDC can only use arbitrary numbers > assigned by the parisc-linux startup code. Maybe there is a way to > make the numbers match PIM info output but I'm not sure how. Realistically, "logical" just means we make up a numbering scheme independent of what the HW tells us. If the HW isn't telling us anything, then us telling the HW is fine. The gist of the "no more logical mappings edict" is that basically we only have one source for CPU numbers (and it can be sparse) rather than two, one of which was usually compact. James From grundler@parisc-linux.org Mon Aug 25 20:50:42 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 25 Aug 2003 13:50:42 -0600 Subject: [parisc-linux] CD Not Mounted In-Reply-To: <1061840314.3f4a65ba7293e@webmail.v8fiesta.co.uk> References: <1061837954.3f4a5c82ae3d9@webmail.v8fiesta.co.uk> <20030825193149.GC377@dsl2.external.hp.com> <1061840314.3f4a65ba7293e@webmail.v8fiesta.co.uk> Message-ID: <20030825195042.GA1468@dsl2.external.hp.com> On Mon, Aug 25, 2003 at 08:38:34PM +0100, mmogenius@v8fiesta.co.uk wrote: > I have a hp visualise b2000 and i am using debian 3.0 (woody) ok. This sounds like a known problem with the Debian 3.0r0 install CDs. Did a Debian 3.0r1 installer ever get made? If not, the alternative is to try the more recent net-install ISOs. "net install" just means the system has to have access to a Debian mirror via LAN. Still need to burn and boot from CD. URLs to "net install ISOs" are on the www.parisc-linux.org web page. hth, grant From grundler@parisc-linux.org Mon Aug 25 20:57:55 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 25 Aug 2003 13:57:55 -0600 Subject: [parisc-linux] CD Not Mounted In-Reply-To: <20030825195042.GA1468@dsl2.external.hp.com> References: <1061837954.3f4a5c82ae3d9@webmail.v8fiesta.co.uk> <20030825193149.GC377@dsl2.external.hp.com> <1061840314.3f4a65ba7293e@webmail.v8fiesta.co.uk> <20030825195042.GA1468@dsl2.external.hp.com> Message-ID: <20030825195755.GB1468@dsl2.external.hp.com> On Mon, Aug 25, 2003 at 01:50:42PM -0600, Grant Grundler wrote: > URLs to "net install ISOs" are on the www.parisc-linux.org web page. The link points to: ftp://ftp.parisc-linux.org/cd-images/testing/auto-isos/ But newer images (2.4.21-pa9 kernel based) are on: http://pateam.esiee.fr/cd-images/testing/ is the "rsync" broken? Can someone from ESIEE fix that? (not urgent) thanks, grant From gd333@163.com Tue Aug 26 03:00:42 2003 From: gd333@163.com (gd333@163.com) Date: Tue, 26 Aug 2003 10:00:42 +0800 Subject: [parisc-linux] =?GB2312?B?zqrE+r2oo6jW0NOizsSjqcbz0rXN+NW+?= Message-ID: <20030826015754.9D96B4882@dsl2.external.hp.com> ΪÄú½¨£¨ÖÐÓ¢ÎÄ£©ÆóÒµÍøÕ¾ ------------------------ ¡ø¸ù¾ÝÄúµÄÒªÇó¸öÐÔ»¯Éè¼Æ£¬¾ø²»Ì×ÓÃÄ£°æ¡£ ¡ø ÍøÕ¾ÎÞÏÞÀ©Õ¹¼Ü¹¹£¬ÊÊÓ¦ÄúÆóÒµÎÞÏÞ·¢Õ¹µÄÒªÇó¡£ ¡ø ¾ßÓкǫ́¹ÜÀí¹¦ÄÜ£¬ÍøÕ¾½¨³Éºó£¬½»ÓÉÄú×Ô¼º¸üйÜÀí¡£ ----------------------------- ¡ô±¾¹«Ë¾ÎªÄúËù½¨µÄÍøÕ¾¾ßÓÐÒÔϹ¦ÄÜ£º 1.²úƷչʾ-ÍøÉÏչʾÄúµÄ²úÆ·£¬Í¼ÎIJ¢Ã¯£¬¶à¼¶·ÖÀ࣬ºǫ́¹ÜÀí¡£ 2.ÍøÉÏÉ̵ê-¿Í»§¿ÉÖ±½ÓÔÚÍøÉÏÑ¡¹ºÄúµÄ²úÆ·£¬¾ÍÏñÔÚÉ̵êÀïÒ»Ñù¡£ 3.²úÆ·ËÑË÷-¿Í»§¿Éͨ¹ý²úÆ·Ãû³Æ¡¢Àà±ð¡¢¹Ø¼ü´ÊµÈ²éÕÒÄúµÄ²úÆ·¡£ 4.¿Í»§¹ÜÀí-¶Ô²»Í¬¿Í»§»ò»áÔ±£¬¿É½øÐзּ¶¡¢·ÖȨÏÞ¡¢·ÖÀà¹ÜÀí¡£ 5.²úÆ·¶¨¹º-¿Í»§¿ÉÖ±½ÓÔÚÍøÉÏ϶©µ¥£¬¶¨¹ºÄúµÄ²úÆ·¡£ 6.¿Í»§ÁôÑÔ-¿Í»§¿ÉÖ±½ÓÔÚÍøÉϸøÄúÁôÑÔ£¬ÏòÄú·´À¡Òâ¼û¡£ 7.ÐÂÎÅ·¢²¼-Äú¿ÉÔÚÍøÉÏÖ±½Ó·¢²¼¹«Ë¾µÄÐÂÎÅ¡¢Í¨Öª¡¢´ÙÏúÐÅÏ¢µÈ¡£ 8.»áÔ±ÉçÇø-¿É×÷ΪÍⲿ½»Á÷ÂÛ̳£¬Ò²¿É×÷Ϊ¹«Ë¾ÄÚ²¿Ô±¹¤¹µÍ¨Æ½Ì¨¡£ 9.ÍøÉϵ÷²é-¿ÉÒÔÉ趨ÈκÎÎÊÌ⣬Ïò¿Í»§»ò»áÔ±Á˽âÄúÏëÁ˽âµÄÊÂÇé¡£ 10.ÓʼþÁбí-¿ÉÒÔÊÕ¼¯¿Í»§µç×ÓÓÊÏäµÈ×ÊÁÏ£¬¶¨ÆÚÏò¿Í»§·¢ËÍÐÅÏ¢¡£ 11.ÍøÉϺؿ¨-ÖØÒª½ÚÈÕ£¬Ïò¿Í»§·¢Ë;«ÃÀºØ¿¨£¬ÔöÇ¿Óë¿Í»§µÄ¸ÐÇé¡£ 12.ÆóÒµÓʾÖ-ÓëÄúÍøվͬÓòÃûµÄÆóÒµÓʾ֣¬Ìá¸ßÄúÆóÒµµÄ¶ÔÍâÐÎÏó¡£ 13.ºǫ́¹ÜÀí-ËùÓÐÒÔÉϹ¦ÄÜ£¬¿ÉÓÉÄú×Ô¼º¿ØÖƹÜÀí£¬²»ÐèרҵÈËÔ±¡£ ¡ôÄúÒ²¿ÉÒÔ´ÓÏÂÃæ5ÖÖÀàÐÍÖУ¬ÌôÑ¡Ò»ÖÖÊʺÏÄú¹«Ë¾µÄÍøÕ¾? ----------------------------- ¡ø(Ò») ¾­¼ÃÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®100Õ×Ö÷»ú¿Õ¼ä£» 3£®ÍøÕ¾ÕûÌåÉè¼Æ£» 4£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 5£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 6£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 7£®5¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®5¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 9£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 10£®Gif°´Å¥¡¢ÐüÍ£°´Å¥£» 11£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 12£®BannerÉè¼ÆÖÆ×÷£¨Gif£© 13£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 14£®»¶Ó­Ò³·ÃÎÊÕß¼ÆÊýÆ÷1Ì×£» 15£®Óõç×ÓÓÊÏä½ÓÊÕ¿Í»§ÁôÑÔ; 16£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 17£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾2Ò³´Î¡£ -------------------------- ¡ø(¶þ) ±ê×¼ÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®120Õ×Ö÷»ú¿Õ¼ä£» 3£®1¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 8£®10¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 9£®10¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 10£®Gif°´Å¥¡¢ÐüÍ£°´Å¥£» 11£®Flash¶¯»­1·ù£» 12£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 13£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 14£®Êó±êÌØЧ1´¦ 15£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 16£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 17£®»¶Ó­Ò³·ÃÎÊÕß¼ÆÊýÆ÷1Ì×£» 18£®Óõç×ÓÓÊÏä½ÓÊÕ¿Í»§ÁôÑÔ£» 19£®ÌØЧͼƬÖÐÓ¢ÎĹ²2·ù£» 20£®¹ö¶¯×ÖÄ»¹«¸æÖÐÓ¢ÎĹ²2·ù£» 21£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 22£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾4Ò³´Î£» --------------------------- ¡ø(Èý) ÉÌÎñÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®150Õ×Ö÷»ú¿Õ¼ä£» 3£®5¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®20¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®20¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­2·ù£» 13£®ÊÓƵ¶¯»­1·ù£» 14£®Êó±êÌØЧ1´¦ 15£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 16£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 17£®¶¯Ì¬¹ã¸æºá·ù1·ù£» 18£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 19£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 20£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§¶©µ¥£» 21£®ÌØЧͼƬÖÐÓ¢ÎĹ²4·ù£» 22£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²2·ù£» 23£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²4·ù£» 24£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 25£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾8Ò³´Î£» 26£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ1ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ1Ìס£ --------------------------- ¡ø(ËÄ) ºÀ»ªÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®200Õ×Ö÷»ú¿Õ¼ä£» 3£®10¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®40¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®40¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­4·ù£» 13£®ÊÓƵ¶¯»­2·ù£» 14£®Êó±êÌØЧ1´¦£» 15£®ÍøÒ³ÒôÀÖ1´¦£» 16£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 17£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 18£®¶¯Ì¬¹ã¸æºá·ù2·ù£» 19£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 20£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 21£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 22£®ÌØЧͼƬÖÐÓ¢ÎĹ²6·ù 23£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²4·ù 24£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ£» 25£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²6·ù£» 26£®Êý¾Ý¿â½ÓÊÕ¿Í»§¶©µ¥£» 27£®Êý¾Ý¿â¹ÜÀí²úÆ·£» 28£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾16Ò³´Î£» 29£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ2ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ2Ìס£ 30£®ÔùËÍÍâóÖƵ¥Èí¼þ--¡¶ÍâóÖƵ¥Í¨¡·1Ìס£ --------------------------- ¡ø(Îå) ¼¯ÍÅÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®300Õ×Ö÷»ú¿Õ¼ä£» 3£®20¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®80¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®80¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­8·ù£» 13£®ÊÓƵ¶¯»­3·ù£» 14£®Êó±êÌØЧ2´¦£» 15£®ÍøÒ³ÒôÀÖ2´¦£» 16£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 17£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 18£®¶¯Ì¬¹ã¸æºá·ù3·ù£» 19£®ÖÐÎÄ¿ò¼ÜÖ÷Ò³¡¢Ó¢ÎÄ¿ò¼ÜÖ÷Ò³£» 20£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 21£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 22£®¿Í»§·´À¡ÁôÑÔ°å2¸ö(ÖÐÓ¢ÎÄ)£» 23£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ£» 24£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²8·ù 25£®ÌØЧͼƬÖÐÓ¢ÎĹ²8·ù£» 26£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²6·ù£» 27£®Êý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ¡¢¿Í»§¶©µ¥£» 28£®Êý¾Ý¿â¹ÜÀí»áÔ±£» 29£®ÓʼþÁÐ±í£¬ÊÕ¼¯·Ã¿ÍÓʼþµØÖ·£¬·¢Ë͹ã¸æ£» 30£®Êý¾Ý¿â¹ÜÀí²úÆ·£» 31£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 32£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾32Ò³´Î£» 33£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ3ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ3Ì×£» 34£®ÔùËÍÍâóÖƵ¥¼°¹ÜÀíÈí¼þ--¡¶ÍâóҵÎñͨ¡·1Ìס£ --------------------------- ¡¡±¾¹«Ë¾ÊÇÒ»¼Ò´ÓÊÂÍâó³ö¿ÚÐÐÒµ"¼ÆËã»úÓ¦ÓÃÈí¼þÑо¿¿ª·¢"¡¢"ÍøÂ繤³Ì½¨Éè"ºÍ"¶àýÌåÓ°ÊÓ¶¯»­¹ã¸æÖÆ ×÷"µÄרҵ¹«Ë¾£¬×¨ÃÅΪÎÒ¹ú¹ã´óÍâó¹«Ë¾¡¢³ö¿ÚÆóÒµ¿ª·¢¸÷ÖÖ¼ÆËã »úÓ¦ÓÃÈí¼þϵͳ¡¢ÍøÕ¾½¨ÉèÒÔ¼°ÆóÒµ¶àýÌåÓ°ÊÓ¶¯»­¹ã¸æƬÖÆ×÷¡£ ¡¡¡¡±¾¹«Ë¾ÔÚ¹ú¼Òó´Ù»áµÄÖ§³ÖºÍ×é֯ϣ¬³É¹¦¿ª·¢³ö¡¶Ô­²úµØÖ¤Íø ÉÏÉêÇëϵͳ¡·¡¢¡¶ÍâóÖƵ¥Í¨¡·¡¢¡¶ÍâóҵÎñͨ¡·µÈϵÁÐÍâóӦÓÃÈí ¼þ²úÆ·£¬Êܵ½¹ã´óÍâó³ö¿ÚÆóÒµµÄ»¶Ó­¡£ ¡¡¡¡Í¬Ê±£¬ÓÉÓÚÒµÎñ¹Øϵ£¬±¾¹«Ë¾»¹ÓëÃÀ¹ú¡¢Å·¹²Ìå¡¢ÈÕ±¾¡¢º«¹ú¡¢ ¶«ÄÏÑǵȵØÊýÊ®¼Ò²É¹ºÉÌ¡¢Á¬Ëø³¬ÊС¢ÒÔ¼°Éú²úÉÌÓÐ×ÅÁ¼ºÃµÄºÏ×÷¹Ø ϵ¡£¹ýÈ¥Ò»Äê¶à£¬±¾¹«Ë¾ÒÑ°ïÖú¶à¼ÒÍâ¹ú²É¹º³§ÉÌÔÚ¹úÄÚÕÒµ½ºÏÊ浀 ³ö¿Ú²úÆ·£¬´Ù³É¶à×Ú³ö¿ÚóÒס£ ----------------------------- ¹«Ë¾£º¹ãÖÝÊгà¾ÔÓÐÏÞ¹«Ë¾ µØÖ·£º¹ãÖÝÊмÓÄôó»¨Ô°6ºÅÂ¥9E µç»°£º020-85580234ת19 ÁÖÏÈÉú ÊÖ»ú£º13710685240 ´«Õ棺020-85581405 ÓÊÏ䣺gd333@163.com ----------------------------- From gd333@163.com Tue Aug 26 03:02:20 2003 From: gd333@163.com (gd333@163.com) Date: Tue, 26 Aug 2003 10:02:20 +0800 Subject: [parisc-linux] =?GB2312?B?zqrE+r2oo6jW0NOizsSjqcbz0rXN+NW+?= Message-ID: <20030826015942.3C49048DC@dsl2.external.hp.com> ΪÄú½¨£¨ÖÐÓ¢ÎÄ£©ÆóÒµÍøÕ¾ ------------------------ ¡ø¸ù¾ÝÄúµÄÒªÇó¸öÐÔ»¯Éè¼Æ£¬¾ø²»Ì×ÓÃÄ£°æ¡£ ¡ø ÍøÕ¾ÎÞÏÞÀ©Õ¹¼Ü¹¹£¬ÊÊÓ¦ÄúÆóÒµÎÞÏÞ·¢Õ¹µÄÒªÇó¡£ ¡ø ¾ßÓкǫ́¹ÜÀí¹¦ÄÜ£¬ÍøÕ¾½¨³Éºó£¬½»ÓÉÄú×Ô¼º¸üйÜÀí¡£ ----------------------------- ¡ô±¾¹«Ë¾ÎªÄúËù½¨µÄÍøÕ¾¾ßÓÐÒÔϹ¦ÄÜ£º 1.²úƷչʾ-ÍøÉÏչʾÄúµÄ²úÆ·£¬Í¼ÎIJ¢Ã¯£¬¶à¼¶·ÖÀ࣬ºǫ́¹ÜÀí¡£ 2.ÍøÉÏÉ̵ê-¿Í»§¿ÉÖ±½ÓÔÚÍøÉÏÑ¡¹ºÄúµÄ²úÆ·£¬¾ÍÏñÔÚÉ̵êÀïÒ»Ñù¡£ 3.²úÆ·ËÑË÷-¿Í»§¿Éͨ¹ý²úÆ·Ãû³Æ¡¢Àà±ð¡¢¹Ø¼ü´ÊµÈ²éÕÒÄúµÄ²úÆ·¡£ 4.¿Í»§¹ÜÀí-¶Ô²»Í¬¿Í»§»ò»áÔ±£¬¿É½øÐзּ¶¡¢·ÖȨÏÞ¡¢·ÖÀà¹ÜÀí¡£ 5.²úÆ·¶¨¹º-¿Í»§¿ÉÖ±½ÓÔÚÍøÉÏ϶©µ¥£¬¶¨¹ºÄúµÄ²úÆ·¡£ 6.¿Í»§ÁôÑÔ-¿Í»§¿ÉÖ±½ÓÔÚÍøÉϸøÄúÁôÑÔ£¬ÏòÄú·´À¡Òâ¼û¡£ 7.ÐÂÎÅ·¢²¼-Äú¿ÉÔÚÍøÉÏÖ±½Ó·¢²¼¹«Ë¾µÄÐÂÎÅ¡¢Í¨Öª¡¢´ÙÏúÐÅÏ¢µÈ¡£ 8.»áÔ±ÉçÇø-¿É×÷ΪÍⲿ½»Á÷ÂÛ̳£¬Ò²¿É×÷Ϊ¹«Ë¾ÄÚ²¿Ô±¹¤¹µÍ¨Æ½Ì¨¡£ 9.ÍøÉϵ÷²é-¿ÉÒÔÉ趨ÈκÎÎÊÌ⣬Ïò¿Í»§»ò»áÔ±Á˽âÄúÏëÁ˽âµÄÊÂÇé¡£ 10.ÓʼþÁбí-¿ÉÒÔÊÕ¼¯¿Í»§µç×ÓÓÊÏäµÈ×ÊÁÏ£¬¶¨ÆÚÏò¿Í»§·¢ËÍÐÅÏ¢¡£ 11.ÍøÉϺؿ¨-ÖØÒª½ÚÈÕ£¬Ïò¿Í»§·¢Ë;«ÃÀºØ¿¨£¬ÔöÇ¿Óë¿Í»§µÄ¸ÐÇé¡£ 12.ÆóÒµÓʾÖ-ÓëÄúÍøվͬÓòÃûµÄÆóÒµÓʾ֣¬Ìá¸ßÄúÆóÒµµÄ¶ÔÍâÐÎÏó¡£ 13.ºǫ́¹ÜÀí-ËùÓÐÒÔÉϹ¦ÄÜ£¬¿ÉÓÉÄú×Ô¼º¿ØÖƹÜÀí£¬²»ÐèרҵÈËÔ±¡£ ¡ôÄúÒ²¿ÉÒÔ´ÓÏÂÃæ5ÖÖÀàÐÍÖУ¬ÌôÑ¡Ò»ÖÖÊʺÏÄú¹«Ë¾µÄÍøÕ¾? ----------------------------- ¡ø(Ò») ¾­¼ÃÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®100Õ×Ö÷»ú¿Õ¼ä£» 3£®ÍøÕ¾ÕûÌåÉè¼Æ£» 4£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 5£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 6£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 7£®5¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®5¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 9£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 10£®Gif°´Å¥¡¢ÐüÍ£°´Å¥£» 11£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 12£®BannerÉè¼ÆÖÆ×÷£¨Gif£© 13£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 14£®»¶Ó­Ò³·ÃÎÊÕß¼ÆÊýÆ÷1Ì×£» 15£®Óõç×ÓÓÊÏä½ÓÊÕ¿Í»§ÁôÑÔ; 16£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 17£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾2Ò³´Î¡£ -------------------------- ¡ø(¶þ) ±ê×¼ÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®120Õ×Ö÷»ú¿Õ¼ä£» 3£®1¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 8£®10¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 9£®10¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 10£®Gif°´Å¥¡¢ÐüÍ£°´Å¥£» 11£®Flash¶¯»­1·ù£» 12£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 13£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 14£®Êó±êÌØЧ1´¦ 15£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 16£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 17£®»¶Ó­Ò³·ÃÎÊÕß¼ÆÊýÆ÷1Ì×£» 18£®Óõç×ÓÓÊÏä½ÓÊÕ¿Í»§ÁôÑÔ£» 19£®ÌØЧͼƬÖÐÓ¢ÎĹ²2·ù£» 20£®¹ö¶¯×ÖÄ»¹«¸æÖÐÓ¢ÎĹ²2·ù£» 21£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 22£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾4Ò³´Î£» --------------------------- ¡ø(Èý) ÉÌÎñÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®150Õ×Ö÷»ú¿Õ¼ä£» 3£®5¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®20¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®20¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­2·ù£» 13£®ÊÓƵ¶¯»­1·ù£» 14£®Êó±êÌØЧ1´¦ 15£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 16£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 17£®¶¯Ì¬¹ã¸æºá·ù1·ù£» 18£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 19£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 20£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§¶©µ¥£» 21£®ÌØЧͼƬÖÐÓ¢ÎĹ²4·ù£» 22£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²2·ù£» 23£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²4·ù£» 24£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 25£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾8Ò³´Î£» 26£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ1ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ1Ìס£ --------------------------- ¡ø(ËÄ) ºÀ»ªÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®200Õ×Ö÷»ú¿Õ¼ä£» 3£®10¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®40¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®40¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­4·ù£» 13£®ÊÓƵ¶¯»­2·ù£» 14£®Êó±êÌØЧ1´¦£» 15£®ÍøÒ³ÒôÀÖ1´¦£» 16£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 17£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 18£®¶¯Ì¬¹ã¸æºá·ù2·ù£» 19£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 20£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 21£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 22£®ÌØЧͼƬÖÐÓ¢ÎĹ²6·ù 23£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²4·ù 24£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ£» 25£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²6·ù£» 26£®Êý¾Ý¿â½ÓÊÕ¿Í»§¶©µ¥£» 27£®Êý¾Ý¿â¹ÜÀí²úÆ·£» 28£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾16Ò³´Î£» 29£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ2ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ2Ìס£ 30£®ÔùËÍÍâóÖƵ¥Èí¼þ--¡¶ÍâóÖƵ¥Í¨¡·1Ìס£ --------------------------- ¡ø(Îå) ¼¯ÍÅÐÍÆóÒµÍøÕ¾(ÖÐÓ¢ÎÄ)£º 1£®1¸ö¹ú¼ÊÓòÃû£» 2£®300Õ×Ö÷»ú¿Õ¼ä£» 3£®20¸öÆóҵͬÓòÃûÓÊÏ䣻 4£®ÖÐÎÄÓ¢ÎÄÍøÕ¾ÕûÌåÉè¼Æ£» 5£®1¸öÖÐÓ¢ÎÄÍøÕ¾»¶Ó­Ò³£» 6£®1¸öÖÐÎÄÍøÕ¾Ê×Ò³£» 7£®80¸öÖÐÎÄÍøÕ¾·ÖÒ³£» 8£®ÖÐÎÄÍøÕ¾·­Òë³ÉÓ¢ÎÄÍøÕ¾£» 9£®1¸öÓ¢ÎÄÍøÕ¾Ê×Ò³£» 10£®80¸öÓ¢ÎÄÍøÕ¾·ÖÒ³£» 11£®Gif°´Å¥¡¢ÐüÍ£°´Å¥¡¢¶¯Ì¬°´Å¥£» 12£®Flash¶¯»­8·ù£» 13£®ÊÓƵ¶¯»­3·ù£» 14£®Êó±êÌØЧ2´¦£» 15£®ÍøÒ³ÒôÀÖ2´¦£» 16£®LogoÉè¼ÆÖÆ×÷£¨Gif£© 17£®BannerÉè¼ÆÖÆ×÷£¨¶¯Ì¬£© 18£®¶¯Ì¬¹ã¸æºá·ù3·ù£» 19£®ÖÐÎÄ¿ò¼ÜÖ÷Ò³¡¢Ó¢ÎÄ¿ò¼ÜÖ÷Ò³£» 20£®ÍøÕ¾×Ô¶¯ÈÕÆÚ¸üÐÂ2Ì×(ÖÐÓ¢ÎÄ)£» 21£®Ê×Ò³·ÃÎÊÕß¼ÆÊýÆ÷£» 22£®¿Í»§·´À¡ÁôÑÔ°å2¸ö(ÖÐÓ¢ÎÄ)£» 23£®ÓÃÊý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ£» 24£®¹ö¶¯×ÖÄ»¹«¸æ£¨ºáÅÅ¡¢ÊúÅÅ£©ÖÐÓ¢ÎĹ²8·ù 25£®ÌØЧͼƬÖÐÓ¢ÎĹ²8·ù£» 26£®ÌØЧÍøÒ³ÖÐÓ¢ÎĹ²6·ù£» 27£®Êý¾Ý¿â½ÓÊÕ¿Í»§ÁôÑÔ¡¢¿Í»§¶©µ¥£» 28£®Êý¾Ý¿â¹ÜÀí»áÔ±£» 29£®ÓʼþÁÐ±í£¬ÊÕ¼¯·Ã¿ÍÓʼþµØÖ·£¬·¢Ë͹ã¸æ£» 30£®Êý¾Ý¿â¹ÜÀí²úÆ·£» 31£®Ãâ·Ñά»¤ÍøÕ¾1Äꣻ 32£®Æ½¾ùÿÔ¸üÐÂÍøÕ¾32Ò³´Î£» 33£®ÈçÄúÒª×Ô¼ºÎ¬»¤£¬Ãâ·ÑÅàѵ3ÃûÍø¹Ü£¬ÔùËÍÍø¹ÜÈí¼þ3Ì×£» 34£®ÔùËÍÍâóÖƵ¥¼°¹ÜÀíÈí¼þ--¡¶ÍâóҵÎñͨ¡·1Ìס£ --------------------------- ¡¡±¾¹«Ë¾ÊÇÒ»¼Ò´ÓÊÂÍâó³ö¿ÚÐÐÒµ"¼ÆËã»úÓ¦ÓÃÈí¼þÑо¿¿ª·¢"¡¢"ÍøÂ繤³Ì½¨Éè"ºÍ"¶àýÌåÓ°ÊÓ¶¯»­¹ã¸æÖÆ ×÷"µÄרҵ¹«Ë¾£¬×¨ÃÅΪÎÒ¹ú¹ã´óÍâó¹«Ë¾¡¢³ö¿ÚÆóÒµ¿ª·¢¸÷ÖÖ¼ÆËã »úÓ¦ÓÃÈí¼þϵͳ¡¢ÍøÕ¾½¨ÉèÒÔ¼°ÆóÒµ¶àýÌåÓ°ÊÓ¶¯»­¹ã¸æƬÖÆ×÷¡£ ¡¡¡¡±¾¹«Ë¾ÔÚ¹ú¼Òó´Ù»áµÄÖ§³ÖºÍ×é֯ϣ¬³É¹¦¿ª·¢³ö¡¶Ô­²úµØÖ¤Íø ÉÏÉêÇëϵͳ¡·¡¢¡¶ÍâóÖƵ¥Í¨¡·¡¢¡¶ÍâóҵÎñͨ¡·µÈϵÁÐÍâóӦÓÃÈí ¼þ²úÆ·£¬Êܵ½¹ã´óÍâó³ö¿ÚÆóÒµµÄ»¶Ó­¡£ ¡¡¡¡Í¬Ê±£¬ÓÉÓÚÒµÎñ¹Øϵ£¬±¾¹«Ë¾»¹ÓëÃÀ¹ú¡¢Å·¹²Ìå¡¢ÈÕ±¾¡¢º«¹ú¡¢ ¶«ÄÏÑǵȵØÊýÊ®¼Ò²É¹ºÉÌ¡¢Á¬Ëø³¬ÊС¢ÒÔ¼°Éú²úÉÌÓÐ×ÅÁ¼ºÃµÄºÏ×÷¹Ø ϵ¡£¹ýÈ¥Ò»Äê¶à£¬±¾¹«Ë¾ÒÑ°ïÖú¶à¼ÒÍâ¹ú²É¹º³§ÉÌÔÚ¹úÄÚÕÒµ½ºÏÊ浀 ³ö¿Ú²úÆ·£¬´Ù³É¶à×Ú³ö¿ÚóÒס£ ----------------------------- ¹«Ë¾£º¹ãÖÝÊгà¾ÔÓÐÏÞ¹«Ë¾ µØÖ·£º¹ãÖÝÊмÓÄôó»¨Ô°6ºÅÂ¥9E µç»°£º020-85580234ת19 ÁÖÏÈÉú ÊÖ»ú£º13710685240 ´«Õ棺020-85581405 ÓÊÏ䣺gd333@163.com ----------------------------- From jsoe0708@tiscali.be Tue Aug 26 07:45:00 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 26 Aug 2003 08:45:00 +0200 Subject: [parisc-linux] CD Not Mounted In-Reply-To: <20030825195042.GA1468@dsl2.external.hp.com> Message-ID: <3F2A5B0400005B6F@ocpmta1.freegates.net> > >> >> On Mon, Aug 25, 2003 at 08:38:34PM +0100, mmogenius@v8fiesta.co.uk wrote: >> I have a hp visualise b2000 and i am using debian 3.0 (woody) > >ok. This sounds like a known problem with the Debian 3.0r0 >install CDs. Did a Debian 3.0r1 installer ever get made? > You have right, the pb is well known and afaik not yet resolved: it seems that pdc console and ide cdrom are not compatible (so have to install via net-install or an external scsi drive if you have an additional scsi card. then build your own kernel to access ide-cdrom). The system boot but early hang on cd initialisation (the green led lighted continiously) Excepted this detail, the b2k is a very interesting model with cpu PA8600 400Mhz :) and run kernel as well 32bits as 64bits :)) hth, Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From jbglaw@lug-owl.de Tue Aug 26 07:58:49 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Tue, 26 Aug 2003 08:58:49 +0200 Subject: [parisc-linux] [PATCH-2.6] Fix gsc_ps2.c for german keyboards Message-ID: <20030826065849.GB9104@lug-owl.de> --gatW/ieO32f1wygP Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! This little patch cures my keyboard. In the 2.4.x -> 2.6.x transition, my key containing '<', '>' and '|' stopped working. Here it is again (cut'n'pasting those three letters isn't really going to work on a Linux system all the time:) Please apply this to CVS: --- linux-parisc-2.6/drivers/input/misc/gsc_ps2.c 2003-08-25 17:32:20.00000= 0000 +0200 +++ pa-build/drivers/input/misc/gsc_ps2.c 2003-08-25 18:41:24.000000000 +02= 00 @@ -154,7 +154,7 @@ /* 48 */ KBD_UNKNOWN, KEY_DOT, KEY_SLASH, KEY_L, KEY_= SEMICOLON, KEY_P, KEY_MINUS, KBD_UNKNOWN, /* 50 */ KBD_UNKNOWN, KBD_UNKNOWN, KEY_APOSTROPHE,KBD_UNKNOWN, KEY_= LEFTBRACE, KEY_EQUAL, KBD_UNKNOWN, KBD_UNKNOWN, /* 58 */ KEY_CAPSLOCK, KEY_RIGHTSHIFT,KEY_ENTER, KEY_RIGHTBRACE,KBD_= UNKNOWN, KEY_BACKSLASH,KBD_UNKNOWN, KBD_UNKNOWN, - /* 60 */ KBD_UNKNOWN, KBD_UNKNOWN, KBD_UNKNOWN, KBD_UNKNOWN, KBD_= UNKNOWN, KBD_UNKNOWN, KEY_BACKSPACE, KBD_UNKNOWN, + /* 60 */ KBD_UNKNOWN, KEY_102ND, KBD_UNKNOWN, KBD_UNKNOWN, KBD_= UNKNOWN, KBD_UNKNOWN, KEY_BACKSPACE, KBD_UNKNOWN, /* 68 */ KBD_UNKNOWN, KEY_KP1, KBD_UNKNOWN, KEY_KP4, KEY_= KP7, KBD_UNKNOWN, KBD_UNKNOWN, KBD_UNKNOWN, /* 70 */ KEY_KP0, KEY_KPDOT, KEY_KP2, KEY_KP5, KEY_= KP6, KEY_KP8, KEY_ESC, KEY_NUMLOCK, /* 78 */ KEY_F11, KEY_KPPLUS, KEY_KP3, KEY_KPMINUS, KEY_= KPASTERISK,KEY_KP9, KEY_SCROLLLOCK,KEY_103RD, Thanks, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); --gatW/ieO32f1wygP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/SwUpHb1edYOZ4bsRAuQFAJ976/9kmMS1G2j30q+SMjNwGTVLPgCfTV0Y WZK9ztMvm71K3724shqVPPo= =QgEa -----END PGP SIGNATURE----- --gatW/ieO32f1wygP-- From willy@debian.org Tue Aug 26 12:29:29 2003 From: willy@debian.org (Matthew Wilcox) Date: Tue, 26 Aug 2003 12:29:29 +0100 Subject: [parisc-linux] [PATCH-2.6] Fix gsc_ps2.c for german keyboards In-Reply-To: <20030826065849.GB9104@lug-owl.de> References: <20030826065849.GB9104@lug-owl.de> Message-ID: <20030826112929.GI22294@parcelfarce.linux.theplanet.co.uk> On Tue, Aug 26, 2003 at 08:58:49AM +0200, Jan-Benedict Glaw wrote: > This little patch cures my keyboard. In the 2.4.x -> 2.6.x transition, > my key containing '<', '>' and '|' stopped working. Here it is again > (cut'n'pasting those three letters isn't really going to work on a Linux > system all the time:) > > Please apply this to CVS: Done. Thanks! -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From xam@cs.ucc.ie Tue Aug 26 12:46:42 2003 From: xam@cs.ucc.ie (M. Grabert) Date: Tue, 26 Aug 2003 12:46:42 +0100 (IST) Subject: [parisc-linux] C3000 and IDE DMA support Message-ID: Hi all, I win a as experimenting mood so I put in a Seagate ST3120022A (120GB, UDMA) into my C3000 (no floppy, no CDROM). I use the original cable that came with the C3k (intended for the CDROM), since I sincerely doubt that the IDE chipset supports UDMA anyway. I just have one ext3 partition on it (111GB). I have the following problems: - the hard disk performs very bad (just 3.13 MB/s instead of expected >30 MB/s, tested with similar drive in PC and same hdparm settings) In fact it shows typical data rates for unsupported DMA transfers - excessive harddisk access, ie. copying large files (>1GB) obviously blocks any other access to the harddisk, at least it's not (very) responsive (caused by the slow transfer rate?) - can't change from my default kernel setting (DMA) to PIO mode via hdparm, it causes a kernel oops (but hey, who needs PIO anyway ;) Apart from the slowlyness of the drive it works quite well. my .config contains: CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_BLK_DEV_NS87415=y CONFIG_IDEDMA_AUTO=y CONFIG_BLK_DEV_IDE_MODES=y I enable IDE DMA for hda as follows: > hdparm -c 1 -d 1 -u 1 /dev/hda dmesg shows: ============ Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx NS87415: IDE controller at PCI slot 00:0e.0 NS87415: chipset revision 3 NS87415: not 100%% native mode: will probe irqs later ide0: BM-DMA at 0x0a00-0x0a07, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x0a08-0x0a0f, BIOS settings: hdc:pio, hdd:pio hda: ST3120022A, ATA DISK drive blk: queue 103c1608, I/O limit 4095Mb (mask 0xffffffff) ide0 at 0x1f0-0x1f7,0x3f6 on irq 103 hda: attached ide-disk driver. hda: host protected area => 1 hda: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=14593/255/63, (U)DMA Partition check: hda: hda1 Is unmasq_irq supported? What about DMA? Is it obviously not fixed yet (at least somebody wrote that "ns87415 dma doesn't work reliably on suckyio-systems" a couple of weeks back) Any hints how to speed up the transfer rate? Thanks, Max PS: I have problems with Samba-2.2.3 and 3.0.0 when transferring multiple 1GB files from an XP box to the samba share (the IDE harddisk): samba disconnects after transferring 2x 1GB files, but will copy many smaller files (several MB) just fine (although combined >>2GB). It might be the case that the IDE hard disk is too slow (3MB/s) for my 100Mbit FDX ethernet (4-5MB/s) and thus confuses samba ... Samba-3.0.0 also seems to be a little bit "laggy" when I try to access a share (or any of it's files); there is always a delay for about 1-2s for each read access to a file ... but it's a beta version anyway and this issue should be better discussed on lists.debian.org From xam@cs.ucc.ie Tue Aug 26 12:53:13 2003 From: xam@cs.ucc.ie (M. Grabert) Date: Tue, 26 Aug 2003 12:53:13 +0100 (IST) Subject: [parisc-linux] C3000 and ... Message-ID: ... sorry for the collection of typos in my last mail, but the network connection in our university is VERY bad lately (probably due to the virus attacks). I was disconnected 11 times from the mail servere while writing the last mail :( Apologies, Max From jsoe0708@tiscali.be Tue Aug 26 14:46:04 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 26 Aug 2003 15:46:04 +0200 Subject: [parisc-linux] linux-2.4.22-pa1 small pb Message-ID: <3F2A5B0400005E92@ocpmta1.freegates.net> Hi all, Here is a small but anoying pb with serial console. >From a minicom serial connect here is the nice "boot" Debian banner I can grab when I booted with 2.4.21: [...] Starting periodic command scheduler: cron. _sudZUZ#Z#XZo=_ DDDD EEEEEE BBBB IIIIII AAAA NN NN _jmZZ2!!~---~!!X##wa DD DD EE BB BB II AA AA NNN NN . -]Xb/ ~ __#2( One 400MHz HPPA Kazoo W+ Processor, 256M RAM -Zo; +!4ZwaaaauZZXY' 799.53 Bogomips Total *#[, ~-?!!!!!!-~ palx2000 XUb;. )YXL,, +3#bc, -)SSL,, ~~~~~ Updating the Linuxlogo... done. Stopping Bootlog daemon: bootlogd. [...] Normal :) Now with 2.4.22-pa1 (with exactly the same context excepted kernel): [...] Linux palx2000 2.4.22-pa1 #1 Tue Aug 26 13:40:01 CEST 2003 parisc GNU/Linux Starting periodic command scheduler: cron. _sudZUZ#Z#XZo=_ DDDD EEEEEE BBBB IIIIII AAAA NN NN _jmZZ2!!~---~!!X##wa DD DD EE BB BB II AA AA NNN NN . does x support the internal video card in the machine ? thanks to you help on previous questions i now have everything installed and i am a complete newbie... Thanks ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From Randolph Chung Tue Aug 26 15:51:02 2003 From: Randolph Chung (Randolph Chung) Date: Tue, 26 Aug 2003 07:51:02 -0700 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <1061908796.3f4b713c1b6e3@webmail.v8fiesta.co.uk> References: <1061908796.3f4b713c1b6e3@webmail.v8fiesta.co.uk> Message-ID: <20030826145102.GR21328@tausq.org> In reference to a message from mmogenius@v8fiesta.co.uk, dated Aug 26: > does x support the internal video card in the machine ? http://pateam.esiee.fr/list.html randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From Randolph Chung Tue Aug 26 15:52:38 2003 From: Randolph Chung (Randolph Chung) Date: Tue, 26 Aug 2003 07:52:38 -0700 Subject: [parisc-linux] C3000 and IDE DMA support In-Reply-To: References: Message-ID: <20030826145238.GS21328@tausq.org> > - the hard disk performs very bad (just 3.13 MB/s instead of expected > >30 MB/s, tested with similar drive in PC and same hdparm settings) > In fact it shows typical data rates for unsupported DMA transfers You are right, DMA is not yet supported on superio... at some point it was sort of working, but not very reliably... it's a worthwhile project if you want to do some kernel hacking :-) randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From varenet@esiee.fr Tue Aug 26 15:51:35 2003 From: varenet@esiee.fr (Thibaut VARENE) Date: Tue, 26 Aug 2003 16:51:35 +0200 Subject: [parisc-linux] CD Not Mounted In-Reply-To: <20030825195755.GB1468@dsl2.external.hp.com> References: <1061837954.3f4a5c82ae3d9@webmail.v8fiesta.co.uk> <20030825193149.GC377@dsl2.external.hp.com> <1061840314.3f4a65ba7293e@webmail.v8fiesta.co.uk> <20030825195042.GA1468@dsl2.external.hp.com> <20030825195755.GB1468@dsl2.external.hp.com> Message-ID: <20030826165135.19fdee3d.varenet@esiee.fr> On Mon, 25 Aug 2003 13:57:55 -0600 Grant Grundler wrote: > On Mon, Aug 25, 2003 at 01:50:42PM -0600, Grant Grundler wrote: > > URLs to "net install ISOs" are on the www.parisc-linux.org web page. > > The link points to: > ftp://ftp.parisc-linux.org/cd-images/testing/auto-isos/ > > But newer images (2.4.21-pa9 kernel based) are on: > http://pateam.esiee.fr/cd-images/testing/ > > is the "rsync" broken? > Can someone from ESIEE fix that? > (not urgent) There is no "rsync"... I have to do it by hand and that's getting me pretty bored, so I guess this would have to be scripted at some point. If any master on dsl2 has any idea about how to do it i'd owe him a beer :P BTW, i'll upload last image (-pa13 iirc) on both pateam and dsl2 as soon as i'll get my lab powered back (upon tomorrow if everything goes fine). Thibaut VARENE The PA/Linux ESIEE Team http://pateam.esiee.fr/ From Randolph Chung Tue Aug 26 16:03:44 2003 From: Randolph Chung (Randolph Chung) Date: Tue, 26 Aug 2003 08:03:44 -0700 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <1061909796.3f4b752412e90@webmail.v8fiesta.co.uk> References: <1061908796.3f4b713c1b6e3@webmail.v8fiesta.co.uk> <20030826145102.GR21328@tausq.org> <1061909796.3f4b752412e90@webmail.v8fiesta.co.uk> Message-ID: <20030826150344.GA2012@tausq.org> (please reply to the list, not to me privately) In reference to a message from mmogenius@v8fiesta.co.uk, dated Aug 26: > do we know if it is possable to add an extra graphics card to the b2000 to > usin instead of the internal card ? the web page tells you that if you get a Vis-EG card it will work. there are no "built in" graphics cards.. if you have a FX? card in your b2k, it's a PCI card. (lspci should tell you) randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From willy@debian.org Tue Aug 26 17:00:40 2003 From: willy@debian.org (Matthew Wilcox) Date: Tue, 26 Aug 2003 17:00:40 +0100 Subject: [parisc-linux] linux -> linux-2.4 transition Message-ID: <20030826160040.GM22294@parcelfarce.linux.theplanet.co.uk> Earlier today I moved linux to linux-2.4 and set a compatibility symlink so everything will work for the moment. I've updated the web pages with instructions to use linux-2.4 instead. In the build-tools module, you'll now find a little shell script that moves your checkout from linux to linux-2.4. Please run it as soon as convenient. I intend to remove the `linux' symlink in a week's time. At that point any unconverted repositories will stop working. Any problems, let me know. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From jsoe0708@tiscali.be Tue Aug 26 17:22:49 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 26 Aug 2003 18:22:49 +0200 Subject: [parisc-linux] hp laserjet 4mv ppd for printtool? Message-ID: <3F2A5B0400005F53@ocpmta1.freegates.net> Hi all, I just installed printtool on my b180 to print on a network connected printer of model hp laserjet 4mv. Printtool inform me that: "This printer uses a Postscript Printer Description (PPD) file called HP_LaserJet_4MV.ppd, available from printer vendor. This file should be installed in the /usr/share/postscript/ppd/ directory." Unfortunately I don't reach to find back install cd and google don't find any reference to this file. Is somebody could help me? Thanks in advance, joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From Randolph Chung Tue Aug 26 17:34:41 2003 From: Randolph Chung (Randolph Chung) Date: Tue, 26 Aug 2003 09:34:41 -0700 Subject: [parisc-linux] hp laserjet 4mv ppd for printtool? In-Reply-To: <3F2A5B0400005F53@ocpmta1.freegates.net> References: <3F2A5B0400005F53@ocpmta1.freegates.net> Message-ID: <20030826163441.GA2792@tausq.org> > I just installed printtool on my b180 to print on a network connected printer > of model hp laserjet 4mv. Printtool inform me that: > "This printer uses a Postscript Printer Description (PPD) file called HP_LaserJet_4MV.ppd, > available from printer vendor. This file should be installed in the /usr/share/postscript/ppd/ > directory." > > Unfortunately I don't reach to find back install cd and google don't find > any reference to this file. Is somebody could help me? there are a bunch at http://www.earthsci.unibe.ch/people/kronenbe/support/printing/adobe-ps.ppd/ hplj4mv1.ppd might be the one you want. HTH, randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From jsoe0708@tiscali.be Tue Aug 26 18:08:50 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 26 Aug 2003 19:08:50 +0200 Subject: [parisc-linux] hp laserjet 4mv ppd for printtool? In-Reply-To: <20030826163441.GA2792@tausq.org> Message-ID: <3F2A5B0400005F80@ocpmta1.freegates.net> >there are a bunch at > >> http://www.earthsci.unibe.ch/people/kronenbe/support/printing/adobe-ps.ppd/ > >hplj4mv1.ppd might be the one you want. > That seems to works fine :) Thanks a lot Randolph, Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From carlos@baldric.uwo.ca Tue Aug 26 18:17:54 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Tue, 26 Aug 2003 13:17:54 -0400 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <1061840921.2044.368.camel@mulgrave> References: <3F2E2C7700004E38@ocpmta2.freegates.net> <20030825164553.GB28778@dsl2.external.hp.com> <1061830247.2044.165.camel@mulgrave> <20030825191915.GA377@dsl2.external.hp.com> <1061840921.2044.368.camel@mulgrave> Message-ID: <20030826171753.GC32302@systemhalted> > Realistically, "logical" just means we make up a numbering scheme > independent of what the HW tells us. If the HW isn't telling us > anything, then us telling the HW is fine. > > The gist of the "no more logical mappings edict" is that basically we > only have one source for CPU numbers (and it can be sparse) rather than > two, one of which was usually compact. I sense a Monty Python skit about '0 CPUs found' :) HW: So how many we got today? SW: Oh, zero. HW: Zero?! SW: Yeah, zaro CPU's found. HW: Do you have an accent? ... c. From jsoe0708@tiscali.be Tue Aug 26 18:34:24 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 26 Aug 2003 19:34:24 +0200 Subject: [parisc-linux] linux -> linux-2.4 transition In-Reply-To: <20030826160040.GM22294@parcelfarce.linux.theplanet.co.uk> Message-ID: <3F2A5B0400005F9F@ocpmta1.freegates.net> > In the build-tools module, you'll now find a little shell > script that moves your checkout from linux > to linux-2.4. Please run it as soon as convenient. Thanks a lot it works fine (just apply script and update: nice) joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From jsoe0708@tiscali.be Tue Aug 26 18:54:38 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 26 Aug 2003 19:54:38 +0200 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <20030825164553.GB28778@dsl2.external.hp.com> Message-ID: <3F2A5B0400005FBB@ocpmta1.freegates.net> >> >The additional CPUs just reference (ie load) the shared data using >the same address. AFAIK, a cacheline will get loaded as "shared clean" >until someone writes to it - which is when the cacheline ping-pong >starts. Ok I will have to re-read and again and again (each world is very important in this book all short-cut is fatal for a good understanding) >> Can you tell me more: in a previous piminfo collected I got for CPU#3 (3 >> is the "address" of the second cpu) >PAT PDC (L-/N-class and A500) have hard coded numbers for CPUs. >parisc-linux only uses logical CPU numbers to avoid sparsely populated >arrays. parisc-linux can get the "Physical CPU #" from PAT PDC. >See code inside USE_PAT_CPUID in arch/parisc/kernel/processor.c. >You might hack that code a bit so you can correlate logic to physical >CPU numbers. (I would do so later), I mean i would like to find the 'psw' value in a piminfo listing (whatever the form it is: oct, hex, bin) to learn more about cpu status at the panic moment (sorry for confusion but English is not my mother tongue and frequently i still have pb to make understand my thought:) ) Thanks again, Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From parisc-linux@parisc-linux.org Tue Aug 26 21:03:54 2003 From: parisc-linux@parisc-linux.org (Matthew Wilcox) Date: Tue, 26 Aug 2003 21:03:54 +0100 Subject: [parisc-linux] Re: kernel 2.6 for hppa status? In-Reply-To: References: <200308261202100660.00729583@smtp1.sympatico.ca> Message-ID: <20030826200354.GT22294@parcelfarce.linux.theplanet.co.uk> On Tue, Aug 26, 2003 at 09:29:35PM +0300, Martin-Éric Racine wrote: > Greetings, > > Having just tried kernel 2.6 (the release candidate found in unstable) on i386, > I found it to bring a _tremendous_ improvement in responsiveness and especially > in userspace stuff like XFree. Given how this 712 is the slowest machine in my > LAN, I was wondering if any work is being done on 2.6 for hppa and when is the > first release expected? Thanks! -> parisc-linux.org where we have 2.6.0-test4. When might there be a debian package for it? Don't know, not my department. But the -pa patch is a tiny fraction of the size of the 2.4 patch, so it'll be much easier for everyone. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From varenet@esiee.fr Tue Aug 26 22:38:41 2003 From: varenet@esiee.fr (Thibaut VARENE) Date: Tue, 26 Aug 2003 23:38:41 +0200 Subject: [parisc-linux] Re: kernel 2.6 for hppa status? In-Reply-To: <20030826200354.GT22294@parcelfarce.linux.theplanet.co.uk> References: <200308261202100660.00729583@smtp1.sympatico.ca> <20030826200354.GT22294@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030826233841.655ec3b2.varenet@esiee.fr> --=.Qjpr3j(rw5Je4. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, 26 Aug 2003 21:03:54 +0100 Matthew Wilcox wrote: > On Tue, Aug 26, 2003 at 09:29:35PM +0300, Martin-=C9ric Racine wrote: > > Greetings, > >=20 > > Having just tried kernel 2.6 (the release candidate found in unstable) > > on i386, I found it to bring a _tremendous_ improvement in > > responsiveness and especially in userspace stuff like XFree. Given how > > this 712 is the slowest machine in my LAN, I was wondering if any work > > is being done on 2.6 for hppa and when is the first release expected?=20 > > Thanks! >=20 > -> parisc-linux.org where we have 2.6.0-test4. > When might there be a debian package for it? Don't know, not my > department. If it was up to me i guess it wouldn't take much time. I have to discuss that with either you and bdale, to state *how* we want it done... Anyway, let me remind you that as for generating 2.6 netinsts, i _do_ need arch/parisc/debian-configs/* files to provide you with a 2.6 package. Since i'm not willing to find out by myself what we want and what we don't want in 2.6 "debian stock" kernel configs (that's a matter for the b-f maintainer i guess, or maybe my kernel package mentor - aka bdale - has some ideas about it ;), i won't be able to do anything _prior_ to these files appearance in our CVS tree... > But the -pa patch is a tiny fraction of the size of the 2.4 patch, so > it'll be much easier for everyone. that's for sure! HTH, Thibaut VARENE The PA/Linux ESIEE Team http://pateam.esiee.fr/ --=.Qjpr3j(rw5Je4. Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/S9NmHjLD2rfS8GMRAgrhAJ0fbGX5Yos7ixDt493Nm5lAaqm3OgCfX0qn Y+dO2QXp9Zudfsasu+Y96NY= =nlpT -----END PGP SIGNATURE----- --=.Qjpr3j(rw5Je4.-- From webmaster@127.0.0.1 Wed Aug 27 02:00:33 2003 From: webmaster@127.0.0.1 (webmaster) Date: Tue, 26 Aug 2003 19:00:33 -0600 (MDT) Subject: [parisc-linux] -------|ÓÅ»ÝÐéÄâÖ÷»ú£¡|------ Message-ID: <20030827010033.C06944830@dsl2.external.hp.com> Ç×°®µÄÅóÓÑ£º ¡¡¡¡ÄúºÃ£¡ ¡¡¡¡ÕâÊÇÀ´×ÔÏÃÃÅÊб¦Áé¿Æ¼¼ÍøÂçÓÐÏÞ¹«Ë¾µÄÎʺ¸ÐлÄúÊÕ¿´Õâ·âÓʼþ¡£ÎÒÃÇÕæ³ÏµÄÏ£Íû ÄúÄܳÉΪÎÒÃÇÔÚ¹óµØÇøµÄÖØÒª»ï°é¡£ÎÒÃÇÊÇÒ»¼Ò²ÉÓÃÊÀ½ç¸ßм¼Êõ½á¾§£¬Ñо¿¡¢ÍƹãºÍ·¢Õ¹ м¼Êõ£¬ÖÂÁ¦ÓÚ»¥ÁªÍøÐÅÏ¢·þÎñ¡¢ÓòÃû×¢²á·þÎñºÍÐéÄâÖ÷»ú·þÎñµÄ¸ßм¼ÊõÆóÒµ¡£ÏêÇéÇëä¯ ÀÀ:http://www.host-china.com ¹«Ë¾×Ô2003ÄêÆðÈ«Á¦½ø¾ü¹ú¼Ê»¥ÁªÍø·þÎñÁìÓò£¬ÕûºÏÍƳöÁËÒÔϲúÆ·¡£ËùÓпռ䶼֧³Ö Êý¾Ý¿â£¨linux+PHP+Mysql;NT+asp+acess£©¡£Õ⽫»áÊÇÄú³¬ÖµµÄÑ¡Ôñ¡£ ¡¡¡¡1.30M¿Õ¼ä+30MÆóÒµÓÊ¾Ö + ËÍÒ»¹ú¼ÊÓòÃû £¬¹¦ÄÜÈ«Ã棬½öÊÛ198Ôª/Äê¡£ ¡¡¡¡2.120M¿Õ¼ä£«120MÆóÒµÓÊÏ䣫1¸ö¹ú¼ÊÓòÃû£¬¹¦ÄÜÈ«Ã棬½öÊÛ330Ôª/Äê¡£ 3.200M¿Õ¼ä£«50MÆóÒµÓÊÏ䣫1¸ö¹ú¼ÊÓòÃû£¬¹¦ÄÜÈ«Ã棬½öÊÛ450Ôª/Äê¡£ 4.300M¿Õ¼ä£«50MÆóÒµÓÊÏ䣫1¸ö¹ú¼ÊÓòÃû£¬¹¦ÄÜÈ«Ã棬½öÊÛ580Ôª/Äê¡£ ¡¡¡¡ ¡¡¡¡¾¡¹ÜÎÒÃǾ¡Á¦ÎªÄúÌṩ×îºÃµÄ·þÎñ¡££¬µ«²»Åųý³öÏÖʧÎó¡£Èç¹ûÊÇÕâÑù£¬ÎÒÃÇÄþÔ¸½ÓÊÜ Í˿Ҳ²»»áÒòΪÄÄÅÂÒ»µãµãµÄ²»ÂúÒâ¶øÈÃÄú²»¿ªÐÄ¡£ËùÒÔÎÒÃdzÐŵ£ºÖ÷»ú²»ÂúÒⰴʵ¼ÊÓà ¶îÍË¿î¡£Çë²»ÒªÖ±½Ó»Ø¸´,»Ø¸´Çë·¢:li_9888@hotmail.com ¡¡¡¡×££º¿ªÐÄ£¡Ë³Àû£¡ ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡webmaster of http://www.host-china.com ÏÃÃÅÊб¦Áé¿Æ¼¼ÍøÂçÓÐÏÞ¹«Ë¾ http://www.host-china.com µç»°£º0592-5915491£¨ÈÈÏߣ© 0592-5652685¡¡ ´«Õ棺0592-5652687¡¡¡¡ ÁªÏµÈË£ºÀîÏÈÉú ½ðС½ã --------------------------------------------------------------- ·ÐµãȺ·¢Óʼþ,À´×ÔÈí¼þ¹¤³Ìר¼ÒÍø(http://www.21cmm.com) ½øCMMÍøУ(http://www.21cmm.com)£¬³ÉÏîÄ¿¹ÜÀíר¼Ò From jmd5@earthlink.net Wed Aug 27 00:50:08 2003 From: jmd5@earthlink.net (jmd) Date: Tue, 26 Aug 2003 16:50:08 -0700 Subject: [parisc-linux] c180 available for developer Message-ID: <1061941808.1048.8.camel@localhost.localdomain> i have a c180 visualize that is just taking up space. if a developer would like it, it's free. just the cost of shipping. or could be picked up in glendale california. c180 2.1G scsi drive, 4x plextor cdrom (internal and NOT OEM), 256M memory. vga graphics card and z buffer. i forget the card number. X works though. base install of debian is on it now. if you need more details contact me off list at jmd5@earthlink.net. figure shipping costs from 91201 and 50 lbs. (its heavy) jeff duncan From caslivkoff@speakeasy.net Wed Aug 27 02:30:23 2003 From: caslivkoff@speakeasy.net (Chuck Slivkoff) Date: Tue, 26 Aug 2003 21:30:23 -0400 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <20030826150344.GA2012@tausq.org> Message-ID: <0749BC3A-D82E-11D7-8E2F-000393581E44@speakeasy.net> Hi Randolph, On Tuesday, Aug 26, 2003, at 11:03 US/Eastern, Randolph Chung wrote: > In reference to a message from mmogenius@v8fiesta.co.uk, dated Aug 26: >> do we know if it is possable to add an extra graphics card to the >> b2000 to >> usin instead of the internal card ? > > the web page tells you that if you get a Vis-EG card it will work. > there > are no "built in" graphics cards.. if you have a FX? card in your b2k, > it's a PCI card. (lspci should tell you) The B2000 does have integrated graphics. It is an FX-e. -chuck From grundler@parisc-linux.org Wed Aug 27 04:40:36 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Tue, 26 Aug 2003 21:40:36 -0600 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <0749BC3A-D82E-11D7-8E2F-000393581E44@speakeasy.net> References: <20030826150344.GA2012@tausq.org> <0749BC3A-D82E-11D7-8E2F-000393581E44@speakeasy.net> Message-ID: <20030827034036.GA9928@dsl2.external.hp.com> On Tue, Aug 26, 2003 at 09:30:23PM -0400, Chuck Slivkoff wrote: > The B2000 does have integrated graphics. It is an FX-e. "integrated" != "soldered on the motherboard" "built-in" ~= "soldered on the motherboard" ie The Gfx card can be removed and in fact must be remove if one wants to use the only 66mhz/64-bit PCI slot the B2000/C3000 has. AFAIK, the B2000/C3000/J5000 systems only have plug-in PCI gfx cards. At least all the ones I've seen are plug-in. grant From caslivkoff@speakeasy.net Wed Aug 27 06:00:59 2003 From: caslivkoff@speakeasy.net (Chuck Slivkoff) Date: Wed, 27 Aug 2003 01:00:59 -0400 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <20030827034036.GA9928@dsl2.external.hp.com> Message-ID: <72F3D1D0-D84B-11D7-8E2F-000393581E44@speakeasy.net> On Tuesday, Aug 26, 2003, at 23:40 US/Eastern, Grant Grundler wrote: > On Tue, Aug 26, 2003 at 09:30:23PM -0400, Chuck Slivkoff wrote: >> The B2000 does have integrated graphics. It is an FX-e. > > "integrated" != "soldered on the motherboard" > "built-in" ~= "soldered on the motherboard" I've always used these interchangably. > ie The Gfx card can be removed and in fact must be remove if one wants > to use the only 66mhz/64-bit PCI slot the B2000/C3000 has. > > AFAIK, the B2000/C3000/J5000 systems only have plug-in PCI gfx cards. > At least all the ones I've seen are plug-in. The B2000 is an exception. I participated in the Field Review of this box ("Kazoo", IIRC) & we have one of these in our lab in Roseville. This box was considered a "cheap" alternative to a C3000 with a smaller power supply, fewer PCI slots, fewer DIMM slots and integrated (see below) graphics. The FX-e is soldered on the motherboard. From pg 23 of the B2000 the Owner's Guide: Monitor Connector The B2000 workstation has an integrated HP VISUALIZE fxe graphics chip on the system board. Thus, the monitor connector on the rear panel of the workstation connects your monitor to this graphics chip on the system board. http://h20000.www2.hp.com/bizsupport/ CoreRedirect.jsp?targetPage=http%3A%2F%2Fh200007.www2.hp.com%2Fbc%2Fdocs %2Fsupport%2FSupportManual%2Flpv37670%2Flpv37670.pdf From grundler@parisc-linux.org Wed Aug 27 07:05:16 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 27 Aug 2003 00:05:16 -0600 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <72F3D1D0-D84B-11D7-8E2F-000393581E44@speakeasy.net> References: <20030827034036.GA9928@dsl2.external.hp.com> <72F3D1D0-D84B-11D7-8E2F-000393581E44@speakeasy.net> Message-ID: <20030827060516.GA11642@dsl2.external.hp.com> On Wed, Aug 27, 2003 at 01:00:59AM -0400, Chuck Slivkoff wrote: > >"integrated" != "soldered on the motherboard" > >"built-in" ~= "soldered on the motherboard" > > I've always used these interchangably. I normally would too. I don't anymore for HP products since hearing "factory integration" regarding plug-in PCI cards. > The B2000 is an exception. I participated in the Field Review of this > box ("Kazoo", IIRC) & we have one of these in our lab in Roseville. > This box was considered a "cheap" alternative to a C3000 with a smaller > power supply, fewer PCI slots, fewer DIMM slots and integrated (see > below) graphics. The FX-e is soldered on the motherboard. ok - thanks - I've seen the fewer DIMM slots version but didn't notice the FX-e on the motherboard (or VGA connector on the back). I have seen a B2000 with 8 DIMM slots and 6 PCI slots like a C3000. This is no prototype - a real production unit. I'll have a chance to look more closely at this box again in the near future and will take some pictures. thanks for the correction, grant From varenet@esiee.fr Wed Aug 27 09:06:30 2003 From: varenet@esiee.fr (Thibaut VARENE) Date: Wed, 27 Aug 2003 10:06:30 +0200 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <20030827060516.GA11642@dsl2.external.hp.com> References: <20030827034036.GA9928@dsl2.external.hp.com> <72F3D1D0-D84B-11D7-8E2F-000393581E44@speakeasy.net> <20030827060516.GA11642@dsl2.external.hp.com> Message-ID: <20030827100630.7a3eb14f.varenet@esiee.fr> On Wed, 27 Aug 2003 00:05:16 -0600 Grant Grundler wrote: > ok - thanks - I've seen the fewer DIMM slots version but didn't > notice the FX-e on the motherboard (or VGA connector on the back). > > I have seen a B2000 with 8 DIMM slots and 6 PCI slots like a C3000. > This is no prototype - a real production unit. > I'll have a chance to look more closely at this box again > in the near future and will take some pictures. > Don't bother, we've got plenty of these boxes @school, I'll take some pics before students come back ;) Thibaut VARENE The PA/Linux ESIEE Team http://pateam.esiee.fr/ From mmogenius@v8fiesta.co.uk Wed Aug 27 10:22:22 2003 From: mmogenius@v8fiesta.co.uk (mmogenius@v8fiesta.co.uk) Date: Wed, 27 Aug 2003 10:22:22 +0100 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <20030827100630.7a3eb14f.varenet@esiee.fr> References: <20030827034036.GA9928@dsl2.external.hp.com> <72F3D1D0-D84B-11D7-8E2F-000393581E44@speakeasy.net> <20030827060516.GA11642@dsl2.external.hp.com> <20030827100630.7a3eb14f.varenet@esiee.fr> Message-ID: <1061976142.3f4c784e354b9@webmail.v8fiesta.co.uk> Quoting Thibaut VARENE : > On Wed, 27 Aug 2003 00:05:16 -0600 > Grant Grundler wrote: > > > > ok - thanks - I've seen the fewer DIMM slots version but didn't > > notice the FX-e on the motherboard (or VGA connector on the back). > > > > I have seen a B2000 with 8 DIMM slots and 6 PCI slots like a C3000. > > This is no prototype - a real production unit. > > I'll have a chance to look more closely at this box again > > in the near future and will take some pictures. > > > > Don't bother, we've got plenty of these boxes @school, I'll take some pics > before students come back ;) > > > Thibaut VARENE > The PA/Linux ESIEE Team > http://pateam.esiee.fr/ > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From alan@lxorguk.ukuu.org.uk Wed Aug 27 17:30:13 2003 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: 27 Aug 2003 17:30:13 +0100 Subject: [parisc-linux] C3000 and IDE DMA support In-Reply-To: References: Message-ID: <1062001812.22739.84.camel@dhcp23.swansea.linux.org.uk> On Maw, 2003-08-26 at 12:46, M. Grabert wrote: > - the hard disk performs very bad (just 3.13 MB/s instead of expected > >30 MB/s, tested with similar drive in PC and same hdparm settings) > In fact it shows typical data rates for unsupported DMA transfers Your drive is in PIO, probably PIO3 or so. > - excessive harddisk access, ie. copying large files (>1GB) obviously > blocks any other access to the harddisk, at least it's not (very) responsive > (caused by the slow transfer rate?) Hard to tell > - can't change from my default kernel setting (DMA) to PIO mode via hdparm, > it causes a kernel oops (but hey, who needs PIO anyway ;) That would be a bug > Is unmasq_irq supported? What about DMA? Is it obviously not fixed yet > (at least somebody wrote that "ns87415 dma doesn't work reliably on > suckyio-systems" a couple of weeks back) irq unmasking is a generic IDE property so should be fine on any platform with a non prehistoric defunct controller (NS87415 is fine) > Any hints how to speed up the transfer rate? Buy a PC ;) Basically you need to fix DMA support From xam@cs.ucc.ie Wed Aug 27 18:36:12 2003 From: xam@cs.ucc.ie (M. Grabert) Date: Wed, 27 Aug 2003 18:36:12 +0100 (IST) Subject: [parisc-linux] C3000 and IDE DMA support In-Reply-To: <1062001812.22739.84.camel@dhcp23.swansea.linux.org.uk> Message-ID: On 27 Aug 2003, Alan Cox wrote: > On Maw, 2003-08-26 at 12:46, M. Grabert wrote: > > - the hard disk performs very bad (just 3.13 MB/s instead of expected > > >30 MB/s, tested with similar drive in PC and same hdparm settings) > > In fact it shows typical data rates for unsupported DMA transfers > > Your drive is in PIO, probably PIO3 or so. beast:/home/xam# hdparm -i /dev/hda /dev/hda: Model=ST3120022A, FwRev=3.06, SerialNo=5JT04M42 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=4228907259, LBA=yes, LBAsects=234441648 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 *mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 AdvancedPM=no WriteCache=enabled Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2: 1 2 3 4 5 6 Mhh, also "hdparm -d" shows that the "DMA mode" of the hard disk is "enabled", but I really have the feeling it isn't. [...] > > Is unmasq_irq supported? What about DMA? Is it obviously not fixed yet > > (at least somebody wrote that "ns87415 dma doesn't work reliably on > > suckyio-systems" a couple of weeks back) > > irq unmasking is a generic IDE property so should be fine on any > platform with a non prehistoric defunct controller (NS87415 is fine) > > > Any hints how to speed up the transfer rate? > > Buy a PC ;) Close ;) Bought a IDE controller (Silicon Image Sil680) for EUR 15 ... Hope it works, since I need a quick solution because this machine is used as a WLAN Bridge/DNS cache/DHCP server/DSL router/Fire server in our house. > Basically you need to fix DMA support If I have/had time besides my PhD ... moreover I still have to little knowledge about IDE stuff and kernel hacking to help. I think you know the feeling since you're taking a sabbatical to do a MBA ;) I'm just good at AI stuff (PhD) and parallel computing (former job & hobby). Anyway, I try to help by testing and experimenting with new kernels and telling what obvious mistakes I found and what's not running. I.e. I don't intend to complain but help with what I report. So far I'm quite happy with the stability of Linux/PA-RISC, so I've really no reason to complain (rather the opposite: thank you!). Slan, Max From mmogenius@v8fiesta.co.uk Wed Aug 27 21:19:49 2003 From: mmogenius@v8fiesta.co.uk (mmogenius@v8fiesta.co.uk) Date: Wed, 27 Aug 2003 21:19:49 +0100 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <1061976142.3f4c784e354b9@webmail.v8fiesta.co.uk> References: <20030827034036.GA9928@dsl2.external.hp.com> <72F3D1D0-D84B-11D7-8E2F-000393581E44@speakeasy.net> <20030827060516.GA11642@dsl2.external.hp.com> <20030827100630.7a3eb14f.varenet@esiee.fr> <1061976142.3f4c784e354b9@webmail.v8fiesta.co.uk> Message-ID: <1062015588.3f4d126503447@webmail.v8fiesta.co.uk> Interesting the veriety iof the same box :-O. I can only find one specification on hp's site for the b2000... so the basics of it is can the b2000 support an additional vga card other then the onboard graphics card ? presumabely i need a card that is compatable with the box rather then any old card off the shelf ? of is there more likleyhood that there will be support for this card in x ? Thanks Quoting mmogenius@v8fiesta.co.uk: > Quoting Thibaut VARENE : > > > On Wed, 27 Aug 2003 00:05:16 -0600 > > Grant Grundler wrote: > > > > > > > ok - thanks - I've seen the fewer DIMM slots version but didn't > > > notice the FX-e on the motherboard (or VGA connector on the back). > > > > > > I have seen a B2000 with 8 DIMM slots and 6 PCI slots like a C3000. > > > This is no prototype - a real production unit. > > > I'll have a chance to look more closely at this box again > > > in the near future and will take some pictures. > > > > > > > Don't bother, we've got plenty of these boxes @school, I'll take some pics > > before students come back ;) > > > > > > Thibaut VARENE > > The PA/Linux ESIEE Team > > http://pateam.esiee.fr/ > > _______________________________________________ > > parisc-linux mailing list > > parisc-linux@lists.parisc-linux.org > > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > > > > > > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From alan@lxorguk.ukuu.org.uk Wed Aug 27 22:23:17 2003 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: 27 Aug 2003 22:23:17 +0100 Subject: [parisc-linux] C3000 and IDE DMA support In-Reply-To: References: Message-ID: <1062019396.23493.8.camel@dhcp23.swansea.linux.org.uk> On Mer, 2003-08-27 at 18:36, M. Grabert wrote: > beast:/home/xam# hdparm -i /dev/hda > DMA modes: mdma0 mdma1 *mdma2 So its tuned for DMA2 (doesn't mean its not using PIO..) > Mhh, also "hdparm -d" shows that the "DMA mode" of the hard disk is > "enabled", but I really have the feeling it isn't. The crash is also curious - I wonder if parisc is either bouncing every DMA buffer and copying it for some reason, or its failing DMA by a path other platforms don't hit which isnt cleaning up right. From grundler@parisc-linux.org Wed Aug 27 22:44:09 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 27 Aug 2003 15:44:09 -0600 Subject: [parisc-linux] C3000 and IDE DMA support In-Reply-To: <1062019396.23493.8.camel@dhcp23.swansea.linux.org.uk> References: <1062019396.23493.8.camel@dhcp23.swansea.linux.org.uk> Message-ID: <20030827214409.GE31311@dsl2.external.hp.com> On Wed, Aug 27, 2003 at 10:23:17PM +0100, Alan Cox wrote: > The crash is also curious - I wonder if parisc is either bouncing > every DMA buffer and copying it for some reason, c3000 uses sba_iommu.c and AFAIK all DMA goes through the IOMMU. Would surprise me if the DMA was bounced/copied. grant From grundler@parisc-linux.org Wed Aug 27 23:18:57 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 27 Aug 2003 16:18:57 -0600 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <1062015588.3f4d126503447@webmail.v8fiesta.co.uk> References: <20030827034036.GA9928@dsl2.external.hp.com> <72F3D1D0-D84B-11D7-8E2F-000393581E44@speakeasy.net> <20030827060516.GA11642@dsl2.external.hp.com> <20030827100630.7a3eb14f.varenet@esiee.fr> <1061976142.3f4c784e354b9@webmail.v8fiesta.co.uk> <1062015588.3f4d126503447@webmail.v8fiesta.co.uk> Message-ID: <20030827221857.GG31311@dsl2.external.hp.com> On Wed, Aug 27, 2003 at 09:19:49PM +0100, mmogenius@v8fiesta.co.uk wrote: > so the basics of it is can the b2000 support an additional vga card > other then the onboard graphics card? If a PCI slot is available, I would expect a PCI Vis-EG card to work. > presumabely i need a card that is compatable with > the box rather then any old card off the shelf ? I think so. > of is there more likleyhood that there will be support for this card in x ? PCI Vis-EG + stifb driver works under xf86. grant From alan@lxorguk.ukuu.org.uk Wed Aug 27 23:22:54 2003 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: 27 Aug 2003 23:22:54 +0100 Subject: [parisc-linux] C3000 and IDE DMA support In-Reply-To: <20030827214409.GE31311@dsl2.external.hp.com> References: <1062019396.23493.8.camel@dhcp23.swansea.linux.org.uk> <20030827214409.GE31311@dsl2.external.hp.com> Message-ID: <1062022973.23531.45.camel@dhcp23.swansea.linux.org.uk> On Mer, 2003-08-27 at 22:44, Grant Grundler wrote: > c3000 uses sba_iommu.c and AFAIK all DMA goes through the IOMMU. > Would surprise me if the DMA was bounced/copied. Nod.. I'm trying to fathom the 3Mbyte/second behaviour while hdparm claims DMA is on From mmogenius@v8fiesta.co.uk Thu Aug 28 00:05:49 2003 From: mmogenius@v8fiesta.co.uk (mmogenius@v8fiesta.co.uk) Date: Thu, 28 Aug 2003 00:05:49 +0100 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <20030827221857.GG31311@dsl2.external.hp.com> References: <20030827034036.GA9928@dsl2.external.hp.com> <72F3D1D0-D84B-11D7-8E2F-000393581E44@speakeasy.net> <20030827060516.GA11642@dsl2.external.hp.com> <20030827100630.7a3eb14f.varenet@esiee.fr> <1061976142.3f4c784e354b9@webmail.v8fiesta.co.uk> <1062015588.3f4d126503447@webmail.v8fiesta.co.uk> <20030827221857.GG31311@dsl2.external.hp.com> Message-ID: <1062025549.3f4d394db0ab5@webmail.v8fiesta.co.uk> Thanks once again Do you prehaps know how much the card wiull cost me and where i can get one in the uk... Thanks Quoting Grant Grundler : > On Wed, Aug 27, 2003 at 09:19:49PM +0100, mmogenius@v8fiesta.co.uk wrote: > > so the basics of it is can the b2000 support an additional vga card > > other then the onboard graphics card? > > If a PCI slot is available, I would expect a PCI Vis-EG card to work. > > > presumabely i need a card that is compatable with > > the box rather then any old card off the shelf ? > > I think so. > > > of is there more likleyhood that there will be support for this card in x > ? > > PCI Vis-EG + stifb driver works under xf86. > > grant > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From grundler@parisc-linux.org Thu Aug 28 00:09:25 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 27 Aug 2003 17:09:25 -0600 Subject: [parisc-linux] C3000 and IDE DMA support In-Reply-To: <1062022973.23531.45.camel@dhcp23.swansea.linux.org.uk> References: <1062019396.23493.8.camel@dhcp23.swansea.linux.org.uk> <20030827214409.GE31311@dsl2.external.hp.com> <1062022973.23531.45.camel@dhcp23.swansea.linux.org.uk> Message-ID: <20030827230925.GH31311@dsl2.external.hp.com> On Wed, Aug 27, 2003 at 11:22:54PM +0100, Alan Cox wrote: > Nod.. I'm trying to fathom the 3Mbyte/second behaviour while hdparm > claims DMA is on I thought each PIO READ costs something like 400 or 500 cycles on c3k (400Mhz CPU). 400/3 == 133 cycles/byte. Either doing very slow DMA or 32-bit (4*133 == 532) reads. Then it would make sense. grant From grundler@parisc-linux.org Thu Aug 28 00:11:43 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 27 Aug 2003 17:11:43 -0600 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <1062025503.3f4d391fcb5b6@webmail.v8fiesta.co.uk> References: <20030827034036.GA9928@dsl2.external.hp.com> <72F3D1D0-D84B-11D7-8E2F-000393581E44@speakeasy.net> <20030827060516.GA11642@dsl2.external.hp.com> <20030827100630.7a3eb14f.varenet@esiee.fr> <1061976142.3f4c784e354b9@webmail.v8fiesta.co.uk> <1062015588.3f4d126503447@webmail.v8fiesta.co.uk> <20030827221857.GG31311@dsl2.external.hp.com> <1062025503.3f4d391fcb5b6@webmail.v8fiesta.co.uk> Message-ID: <20030827231143.GI31311@dsl2.external.hp.com> On Thu, Aug 28, 2003 at 12:05:03AM +0100, mmogenius@v8fiesta.co.uk wrote: > do you prehaps have any idea what sort of money the card might cost me? > and where i could find one in the uk ? I've never had to buy one. Check e-bay and/or HP equipment resellers on the net. grant From xam@cs.ucc.ie Thu Aug 28 00:19:58 2003 From: xam@cs.ucc.ie (M. Grabert) Date: Thu, 28 Aug 2003 00:19:58 +0100 (IST) Subject: [parisc-linux] C3000 and IDE DMA support In-Reply-To: <20030827230925.GH31311@dsl2.external.hp.com> Message-ID: On Wed, 27 Aug 2003, Grant Grundler wrote: > On Wed, Aug 27, 2003 at 11:22:54PM +0100, Alan Cox wrote: > > Nod.. I'm trying to fathom the 3Mbyte/second behaviour while hdparm > > claims DMA is on > > I thought each PIO READ costs something like 400 or 500 cycles on c3k > (400Mhz CPU). 400/3 == 133 cycles/byte. > > Either doing very slow DMA or 32-bit (4*133 == 532) reads. > Then it would make sense. beast:/home/xam# hdparm -c /dev/hda /dev/hda: IO_support = 1 (32-bit) Well, I set it to 32bit I/O, more specifically I also tried c=0 (16bit, default), c=3 (32-bit with sync). Everytime the same: beast:/home/xam# hdparm -Tt /dev/hda /dev/hda: Timing buffer-cache reads: 128 MB in 1.80 seconds = 71.11 MB/sec Timing buffered disk reads: 64 MB in 20.48 seconds = 3.12 MB/sec However switching of DMA (as I told in my previous post, 'hdparm -d 0') will cause a kernel crash (+ dump). I haven't tried to compile & test a kernel without DMA support (or NS87415 support) greetings, Max From xam@cs.ucc.ie Thu Aug 28 00:31:07 2003 From: xam@cs.ucc.ie (M. Grabert) Date: Thu, 28 Aug 2003 00:31:07 +0100 (IST) Subject: [parisc-linux] x86 on b2000 In-Reply-To: <1062025549.3f4d394db0ab5@webmail.v8fiesta.co.uk> Message-ID: On Thu, 28 Aug 2003 mmogenius@v8fiesta.co.uk wrote: > Thanks once again > > Do you prehaps know how much the card wiull cost me and where i can get one in > the uk... Well, Ebay + "Visualize EG" brings up following result: http://search.ebay.co.uk/ws/search/SaleSearch?satitle=Visualize+EG&saavailabletocountry=3&socurrencydisplay=2&ebaytag1code_tmp=3&ebaytag1_tmp=ebayavail&sosortproperty=1&ht=1&from=R10&sorecordsperpage=50&BasicSearch= All of these three offers are currently below 10 Pound, but international shipping is quite expensive (one offer says US $25). I'd say go for it anyway. Max From jsoe0708@tiscali.be Thu Aug 28 07:08:13 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 28 Aug 2003 08:08:13 +0200 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <3F2E2C770000510F@ocpmta2.freegates.net> Message-ID: <3F4D798800000024@ocpmta7.freegates.net> > >Now that I find what seems reasonable parameters (?) I would try to reboot >the system tomorrow morning and relaunch test with itlb patch (just to confirm >results). > Same results (definitively the test to show up this improvement, may be another workfile?) Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From caslivkoff@speakeasy.net Thu Aug 28 07:49:19 2003 From: caslivkoff@speakeasy.net (Chuck Slivkoff) Date: Thu, 28 Aug 2003 02:49:19 -0400 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <20030827060516.GA11642@dsl2.external.hp.com> Message-ID: On Wednesday, Aug 27, 2003, at 02:05 US/Eastern, Grant Grundler wrote: > I have seen a B2000 with 8 DIMM slots and 6 PCI slots like a C3000. > This is no prototype - a real production unit. Sounds like a B1000 to me. ;-) Essentially, a C3000 with a slower CPU. From jsoe0708@tiscali.be Thu Aug 28 08:04:40 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 28 Aug 2003 09:04:40 +0200 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos Message-ID: <3F4D798800000061@ocpmta7.freegates.net> Hi Grant, >AFAIK, a cacheline will get loaded as "shared clean" >until someone writes to it - which is when the cacheline ping-pong >starts. Mhh would it not request some kind of ipc between cpu for cache management? But to avoid usage of cache would it be possible to access global kernel's variable with absolute addressing mode? Is it feasible? ... btw scaning code related to SMP I find in smp.c a very draft of an 'ipi_init()' but unfortunately 'Ignore for now. *May* need this "hook" to register IPI handler'..., interesting isn't it :). Is there any other platform inplementing such stuff (I try to scan 2.4 src but not found anywhere else) or some reference on to implement it? >PAT PDC (L-/N-class and A500) have hard coded numbers for CPUs. >parisc-linux only uses logical CPU numbers to avoid sparsely populated >arrays. parisc-linux can get the "Physical CPU #" from PAT PDC. >See code inside USE_PAT_CPUID in arch/parisc/kernel/processor.c. >You might hack that code a bit so you can correlate logic to physical >CPU numbers. Ah see better now, it answers to another question. Thanks, Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From mmogenius@v8fiesta.co.uk Thu Aug 28 10:22:21 2003 From: mmogenius@v8fiesta.co.uk (mmogenius@v8fiesta.co.uk) Date: Thu, 28 Aug 2003 10:22:21 +0100 Subject: [parisc-linux] x86 on b2000 In-Reply-To: References: Message-ID: <1062062541.3f4dc9cd843ed@webmail.v8fiesta.co.uk> Thanks for the link i am sure i had searched ebay but never got any results prehaps i was searching for items in the UK only. I presume not thast many people have these boxes over here and there not tremendiousaly popular through out ? i'll go for the card and get the adaptehr for a normal monitor. Thanks. # Quoting "M. Grabert" : > On Thu, 28 Aug 2003 mmogenius@v8fiesta.co.uk wrote: > > > Thanks once again > > > > Do you prehaps know how much the card wiull cost me and where i can get one > in > > the uk... > > Well, Ebay + "Visualize EG" brings up following result: > > http://search.ebay.co.uk/ws/search/SaleSearch? satitle=Visualize+EG&saavailabletocountry=3&socurrencydisplay=2&ebaytag1code_tm p=3&ebaytag1_tmp=ebayavail&sosortproperty=1&ht=1&from=R10&sorecordsperpage=50&B asicSearch= > > All of these three offers are currently below 10 Pound, > but international shipping is quite expensive (one offer says US $25). > > I'd say go for it anyway. > > > Max > > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From grundler@parisc-linux.org Thu Aug 28 16:12:16 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Thu, 28 Aug 2003 09:12:16 -0600 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <3F4D798800000061@ocpmta7.freegates.net> References: <3F4D798800000061@ocpmta7.freegates.net> Message-ID: <20030828151216.GA23430@dsl2.external.hp.com> On Thu, Aug 28, 2003 at 09:04:40AM +0200, Joel Soete wrote: > Hi Grant, > > >AFAIK, a cacheline will get loaded as "shared clean" > >until someone writes to it - which is when the cacheline ping-pong > >starts. > > Mhh would it not request some kind of ipc between cpu for cache management? no. IIRC instructions for purging the cache are broadcast to other CPUs. > But to avoid usage of cache would it be possible to access global kernel's > variable with absolute addressing mode? Is it feasible? Since the caches use virtual indices, it would make sense when using physically addresses to bypass the cache. But I don't know if that's really the case or not. I would expect that described in the PA2.0 Arch book. > btw scaning code related to SMP I find in smp.c a very draft of > an 'ipi_init()' but unfortunately 'Ignore for now. *May* need this > "hook" to register IPI handler'..., interesting isn't it :). I wrote that. ipi_init and comments can be deleted. I haven't seen a need for ipi_init(). When I originally implemented the SMP support I thought it might be. The IPI handler is statically "hooked" (aka registered) in arch/parisc/kernel/irq.c:cpu_irq_actions[] See ipi_interrupt() for IPI implementation. > Is there any other platform inplementing such stuff (I try to scan 2.4 src > but not found anywhere else) or some reference on to implement it? it == ? IPI is implemented. grant From grundler@parisc-linux.org Thu Aug 28 16:17:54 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Thu, 28 Aug 2003 09:17:54 -0600 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <1062062541.3f4dc9cd843ed@webmail.v8fiesta.co.uk> References: <1062062541.3f4dc9cd843ed@webmail.v8fiesta.co.uk> Message-ID: <20030828151754.GB23430@dsl2.external.hp.com> On Thu, Aug 28, 2003 at 10:22:21AM +0100, mmogenius@v8fiesta.co.uk wrote: > i'll go for the card and get the adaptehr for a normal monitor. I think two of the Ebay listings have an error: AFAIK, VIz-EG cards have an "EVC" connector and not a "DVI" connector. The two connectors look very similar except the DVI connector has fewer pins. Have them count pins and verify before ordering the DVI connector. grant From jsoe0708@tiscali.be Thu Aug 28 17:08:14 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 28 Aug 2003 18:08:14 +0200 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos Message-ID: <3F4D78B00000000A@ocpmta3.freegates.net> --========/3F4D78B00000000A/mail.tiscali.be Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit > >no. >IIRC instructions for purging the cache are broadcast to other CPUs. > That is the first thing I would like to check (as the first signal I notice is a itlb miss fault and the piminfo of the 2d cpu seems to show a crash on a branch instruction [cmpb iirc], I presume that during the init of the second cpu this last tries to access a page which was just purged by the first. This is also why I would like to find the psw of this second cpu in the mentionned pimfinfo :) ) >> But to avoid usage of cache would it be possible to access global kernel's >> variable with absolute addressing mode? Is it feasible? > >Since the caches use virtual indices, it would make sense when using >physically addresses to bypass the cache. But I don't know if that's >really the case or not. I would expect that described in the PA2.0 Arch >book. I don't yet browse all the book but at a first glance ldda and stda are available (respectively load and store doubleword absolute)... >> btw scaning cod >> related to SMP I find in smp.c a very draft of >> an 'ipi_init()' but unfortunately 'Ignore for now. *May* need this >> "hook" to register IPI handler'..., interesting isn't it :). > >I wrote that. ipi_init and comments can be deleted. >I haven't see a need for ipi_init(). When I originally >implemented the SMP support I thought it might be. > >The IPI handler is statically "hooked" (aka registered) in > arch/parisc/kernel/irq.c:cpu_irq_actions[] > >See ipi_interrupt() for IPI implementation. > Allright (clear) >> >> Is there any other platform inplementing such stuff (I try to scan 2.4 src >> but not found anywhere else) or some reference on to implement it? > >it == ? >IPI is implemented. I continue so. BTW here is a small 2.6 back port that may be you could co safely: --- processor.c.orig 2003-08-28 18:04:57.000000000 +0200 +++ processor.c 2003-08-28 18:08:37.000000000 +0200 @@ -370,9 +370,9 @@ }; static struct parisc_driver cpu_driver = { - name: "CPU", - id_table: processor_tbl, - probe: processor_probe + .name = "CPU", + .id_table = processor_tbl, + .probe = pprocessor_probe }; /** Many thanks again for your attention, Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr --========/3F4D78B00000000A/mail.tiscali.be Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="processor.diff" LS0tIHByb2Nlc3Nvci5jLm9yaWcJMjAwMy0wOC0yOCAxODowNDo1Ny4wMDAwMDAwMDAgKzAyMDAK KysrIHByb2Nlc3Nvci5jCTIwMDMtMDgtMjggMTg6MDg6MzcuMDAwMDAwMDAwICswMjAwCkBAIC0z NzAsOSArMzcwLDkgQEAKIH07CiAKIHN0YXRpYyBzdHJ1Y3QgcGFyaXNjX2RyaXZlciBjcHVfZHJp dmVyID0gewotCW5hbWU6CQkiQ1BVIiwKLQlpZF90YWJsZToJcHJvY2Vzc29yX3RibCwKLQlwcm9i ZToJCXByb2Nlc3Nvcl9wcm9iZQorCS5uYW1lCQk9ICJDUFUiLAorCS5pZF90YWJsZQk9IHByb2Nl c3Nvcl90YmwsCisJLnByb2JlCQk9IHBwcm9jZXNzb3JfcHJvYmUKIH07CiAKIC8qKgo= --========/3F4D78B00000000A/mail.tiscali.be-- From jim.hull@hp.com Thu Aug 28 17:34:27 2003 From: jim.hull@hp.com (Jim Hull) Date: Thu, 28 Aug 2003 09:34:27 -0700 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <3F4D78B00000000A@ocpmta3.freegates.net> Message-ID: <012d01c36d82$40d6c960$f463f40f@jh733133> I haven't really been following this thread, so I don't know what problem you're actually trying to solve, but I'd like to point out a few aspects of the PA-RISC processor architecture. Comments mixed with the original text, below. -- Jim HP Itanium/PA-RISC Processor Architect > -----Original Message----- > From: parisc-linux-admin@lists.parisc-linux.org > [mailto:parisc-linux-admin@lists.parisc-linux.org] On Behalf > Of Joel Soete > Sent: Thursday, August 28, 2003 9:08 AM > To: Grant Grundler > Cc: parisc-linux@lists.parisc-linux.org > Subject: Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos > > > > > >no. > >IIRC instructions for purging the cache are broadcast to other CPUs. If you use fdc, fic, or pdc, then they are broadcast to other processors, but fdce and fice are not. > That is the first thing I would like to check (as the first > signal I notice > is a itlb miss fault and the piminfo of the 2d cpu seems to > show a crash > on a branch instruction [cmpb iirc], I presume that during > the init of the > second cpu this last tries to access a page which was just > purged by the > first. This is also why I would like to find the psw of this > second cpu > in the mentionned pimfinfo :) ) > > >> But to avoid usage of cache would it be possible to access > global kernel's > >> variable with absolute addressing mode? Is it feasible? > > > >Since the caches use virtual indices, it would make sense when using > >physically addresses to bypass the cache. But I don't know if that's > >really the case or not. I would expect that described in the > PA2.0 Arch > >book. > > I don't yet browse all the book but at a first glance ldda > and stda are available > (respectively load and store doubleword absolute)... While you can use ldda and stda to access memory using absolute (physical) addresses instead of virtual, these instructions do *not* bypass the cache. And because PA processors use virtually-indexed caches, the rules for mixing virtual and absolute accesses, and have them all remain cache-coherent, are complicated. If you really need to do this, then you'll have to read and understand all of Appendix F, "TLB and Cache Control", in the PA-RISC 2.0 Architecture manual (the "Kane" book). > >> btw scaning cod > >> related to SMP I find in smp.c a very draft of > >> an 'ipi_init()' but unfortunately 'Ignore for now. *May* need this > >> "hook" to register IPI handler'..., interesting isn't it :). > > > >I wrote that. ipi_init and comments can be deleted. > >I haven't see a need for ipi_init(). When I originally > >implemented the SMP support I thought it might be. > > > >The IPI handler is statically "hooked" (aka registered) in > > arch/parisc/kernel/irq.c:cpu_irq_actions[] > > > >See ipi_interrupt() for IPI implementation. > > > Allright (clear) > >> > >> Is there any other platform inplementing such stuff (I try > to scan 2.4 > src > >> but not found anywhere else) or some reference on to implement it? > > > >it == ? > >IPI is implemented. > > I continue so. > > BTW here is a small 2.6 back port that may be you could co safely: > --- processor.c.orig 2003-08-28 18:04:57.000000000 +0200 > +++ processor.c 2003-08-28 18:08:37.000000000 +0200 > @@ -370,9 +370,9 @@ > }; > > static struct parisc_driver cpu_driver = { > - name: "CPU", > - id_table: processor_tbl, > - probe: processor_probe > + .name = "CPU", > + .id_table = processor_tbl, > + .probe = pprocessor_probe > }; > > /** > > > Many thanks again for your attention, > Joel > > > > -------------------------------------------------------------- > ----------- > Tiscali ADSL, seulement 35 eur/mois et le modem est > inclus...abonnez-vous! > http://reg.tiscali.be/default.asp?lg=fr > > > From derekengelhaupt@rocketmail.com Thu Aug 28 19:07:07 2003 From: derekengelhaupt@rocketmail.com (Derek Engelhaupt) Date: Thu, 28 Aug 2003 11:07:07 -0700 (PDT) Subject: [parisc-linux] x86 on b2000 In-Reply-To: <20030828151754.GB23430@dsl2.external.hp.com> Message-ID: <20030828180707.44387.qmail@web12503.mail.yahoo.com> --0-699506816-1062094027=:44336 Content-Type: text/plain; charset=us-ascii It is most definitely an EVC connector on the EG card....not DVI regardless of what the Ebay listing says. derek Grant Grundler wrote: On Thu, Aug 28, 2003 at 10:22:21AM +0100, mmogenius@v8fiesta.co.uk wrote: > i'll go for the card and get the adaptehr for a normal monitor. I think two of the Ebay listings have an error: AFAIK, VIz-EG cards have an "EVC" connector and not a "DVI" connector. The two connectors look very similar except the DVI connector has fewer pins. Have them count pins and verify before ordering the DVI connector. grant _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-699506816-1062094027=:44336 Content-Type: text/html; charset=us-ascii
It is most definitely an EVC connector on the EG card....not DVI regardless of what the Ebay listing says.
 
derek

Grant Grundler <grundler@parisc-linux.org> wrote:
On Thu, Aug 28, 2003 at 10:22:21AM +0100, mmogenius@v8fiesta.co.uk wrote:
> i'll go for the card and get the adaptehr for a normal monitor.

I think two of the Ebay listings have an error: AFAIK, VIz-EG cards have
an "EVC" connector and not a "DVI" connector. The two connectors look very
similar except the DVI connector has fewer pins. Have them count pins and
verify before ordering the DVI connector.

grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-699506816-1062094027=:44336-- From mmogenius@v8fiesta.co.uk Thu Aug 28 22:02:16 2003 From: mmogenius@v8fiesta.co.uk (mmogenius@v8fiesta.co.uk) Date: Thu, 28 Aug 2003 22:02:16 +0100 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <20030828180707.44387.qmail@web12503.mail.yahoo.com> References: <20030828180707.44387.qmail@web12503.mail.yahoo.com> Message-ID: <1062104536.3f4e6dd8eba50@webmail.v8fiesta.co.uk> Oh dear i ordered the converter but it was only £3 so what the hell i'll see if they will swap the converter for another. with any luck i'll manage to get X on this box.... not critical but damn it would be nice. Quoting Derek Engelhaupt : > It is most definitely an EVC connector on the EG card....not DVI regardless > of what the Ebay listing says. > > derek > > Grant Grundler wrote: > On Thu, Aug 28, 2003 at 10:22:21AM +0100, mmogenius@v8fiesta.co.uk wrote: > > i'll go for the card and get the adaptehr for a normal monitor. > > I think two of the Ebay listings have an error: AFAIK, VIz-EG cards have > an "EVC" connector and not a "DVI" connector. The two connectors look very > similar except the DVI connector has fewer pins. Have them count pins and > verify before ordering the DVI connector. > > grant > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > > > --------------------------------- > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From jsoe0708@tiscali.be Fri Aug 29 08:27:27 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Fri, 29 Aug 2003 09:27:27 +0200 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <012d01c36d82$40d6c960$f463f40f@jh733133> Message-ID: <3F4D78B00000007F@ocpmta3.freegates.net> Hi Jim, Well come :) > I haven't really been following this thread, so I don't know what >problem you're actually trying to solve, but I'd like to point out a few >aspects of the PA-RISC processor architecture. > To be short, the pa linux kernel boot well on A model as SMP (Multiprocessor mode) but panic on L/N model. And a pb in tlb management is suspected. >Comments mixed with the original text, below. > > -- Jim > >> HP Itanium/PA-RISC Processor Architect >If you use fdc, fic, or pdc, then they are broadcast to other >processors, but fdce and fice are not. Thanks I will check if such a code is used. >While you can use ldda and stda to access memory using absolute >(physical) addresses instead of virtual, these instructions do *not* >bypass the cache. And because PA processors use virtually-indexed >caches, the rules for mixing virtual and absolute accesses, and have >them all remain cache-coherent, are complicated. If you really need to >do this, then you'll have to read and understand all of Appendix F, "TLB >and Cache Control", in the PA-RISC 2.0 Architecture manual (the "Kane" >book). Yes, very accurate reference, but imo it is not a course on PA-RISC asm (I mean, as a beginner, as i am, would like to find with some trial example showing what is good and trivial errors to not commit). Thanks for your clear comments, Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From 513078@163.com Fri Aug 29 10:15:00 2003 From: 513078@163.com (513078) Date: Fri, 29 Aug 2003 17:15:00 +0800 Subject: [parisc-linux] Re: =?GB2312?B?xPq6w6Oh?= Message-ID: <20030829095257.B88024852@dsl2.external.hp.com> ÊÀ¼ÍÍøͨȫеÄÍøÂ罨վ·½°¸£º ×ÔÖ÷¸ü¶à£¬Äú¿ÉÒÔÍêÈ«°´×Ô¼ºµÄÐèÒª¶¨ÖÆÖ÷»ú Ëٶȸü¿ì¸üÎȶ¨£¬Ñϸñ¿ØÖÆÖ÷»úÊýÁ¿ ¸üÓŻݣ¬ÏÖÔÚÉêÇë¾ùÔùË͹ú¼ÊÓòÃû£¬VIPÆóÒµÓÊÏä Ãâ·ÑÔùËÍ10¸ö¸ß¼¶ÐéÄâÓòÃû Ö÷»úÏÈ¿ªÍ¨£¬ºó¸¶¿î£¡Ãâ·ÑÊÔÈýÌ죬ÂúÒâºó¸¶¿î£¡ÕæÕýµÄÍøÉϽ»Ò×Áã·çÏÕ£¡ ×îµÍÒ»Äê½öÐè170Ôª£¬¾Í¿ÉÓµÓÐÓòÃû+Ö÷»ú+ÆóÒµÓʾ֡£(¸üÏêϸµÄÅäÖÆ:http://www.2211966.net/host.htm). »¹Óиü¶àÓÅ»ÝÌײ;´Çë·ÃÎÊ:http://www.2211966.net ÁªÏµQQ:227564251 ========================================================================================================================================================================== ´ËÓʼþΪÉÌÒµÐź¯,Èç¹ûÄú¶Ô´Ë²»¸ÐÐËȤÇëÁ¢¼´É¾³ý;Èç¹ûÄú²»Ï£ÍûÔÙÊÕµ½´ËÓʼþÇëµ½http://filter.2211966.net.Í˶©,ÎÒÃǽ«»á°ÑÄúµÄÓÊÏäµØÖ·¹ýÂ˳öÁбí.лл! This mail is a business letter.If you are uninterested in this.please delete it immediately;If you do not hope to receive this mail again.please get to http://filter.2211966.net. fill in your mail address.and we will filter it out of our mail list. From jsoe0708@tiscali.be Fri Aug 29 16:59:53 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Fri, 29 Aug 2003 17:59:53 +0200 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos Message-ID: <3F4D78B0000005EE@ocpmta3.freegates.net> >If you use fdc, fic, or pdc then they are broadcast to other >processors, but fdce and fice are not. Hi Jim and al, I just noticed the two following loops: flush_data_cache_local: [...] fdmanyloop: /* Loop if LOOP >= 2 */ ADDIB> -1,%r31,fdmanyloop /* Adjusted inner loop decr */ fdce 0(%sr1,%arg0) fdce,m %arg1(%sr1,%arg0) /* Last fdce and addr adjust */ movb,tr %arg3,%r31,fdmanyloop /* Re-init inner loop count */ ADDIB<=,n -1,%arg2,fdsync /* Outer loop decr */ fdoneloop: /* Loop if LOOP = 1 */ ADDIB> -1,%arg2,fdoneloop /* Outer loop count decr */ fdce,m %arg1(%sr1,%arg0) /* Fdce for one loop */ fdsync: syncdma sync mtsm %r22 bv %r0(%r2) nop .exit .procend [...] flush_instruction_cache_local: [...] fimanyloop: /* Loop if LOOP >= 2 */ ADDIB> -1,%r31,fimanyloop /* Adjusted inner loop decr */ fice 0(%sr1,%arg0) fice,m %arg1(%sr1,%arg0) /* Last fice and addr adjust */ movb,tr %arg3,%r31,fimanyloop /* Re-init inner loop count */ ADDIB<=,n -1,%arg2,fisync /* Outer loop decr */ fioneloop: /* Loop if LOOP = 1 */ ADDIB> -1,%arg2,fioneloop /* Outer loop count decr */ fice,m %arg1(%sr1,%arg0) /* Fice for one loop */ fisync: sync bv %r0(%r2) nop .exit .procend Do you think that could be there where the pb occurs? Thanks for advise, Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From grundler@parisc-linux.org Fri Aug 29 17:13:32 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 29 Aug 2003 10:13:32 -0600 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux carlos In-Reply-To: <3F4D78B0000005EE@ocpmta3.freegates.net> References: <3F4D78B0000005EE@ocpmta3.freegates.net> Message-ID: <20030829161332.GA22468@dsl2.external.hp.com> On Fri, Aug 29, 2003 at 05:59:53PM +0200, Joel Soete wrote: > I just noticed the two following loops: > flush_data_cache_local: Note the names of the routines! ie should only be called when we know only the local CPU is touching data that needs to be flushed. This sounds like a risky strategy to me given prefetching can occur to page that's mapped cacheable. > Do you think that could be there where the pb occurs? I don't. There are likely other problems hidden there though. grant From carlos@baldric.uwo.ca Fri Aug 29 21:04:00 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Fri, 29 Aug 2003 16:04:00 -0400 Subject: [parisc-linux] Re: [glibc] tststatic failues, reduced to simple testcase. In-Reply-To: <200308291507.LAA13539@hiauly3.hia.nrc.ca> References: <20030829084816.GD19341@systemhalted> <200308291507.LAA13539@hiauly3.hia.nrc.ca> Message-ID: <20030829200400.GF19341@systemhalted> Dave, I will start by saying that I wasn't "fair" in just dumping the assembly into an email, falling asleep at my keyboard at 4:30 AM and leaving it up to you to guess what was _really_ going on :) I'm sending this to the list so it gets recorded on archive. Our problem right now it that we don't properly restore r19 after an __asm() statement even if the clobber contains r19. Or rather gcc doesn't schedule the restore to occur at the right time. What does this mean for glibc, well it means that ld.so's first fork corrupts the PIC register r19 aka LTP, and the subsequent import stub for a function call fails (SIGSEGV). What is effected in glibc? The following: - INTERNAL_SYSCALL (Macro syscall) - INLINE_SYSCALL (Macro syscall) - syscall(...) (C version) - DO_CALL (Assembly wrapper syscall) What is not effected: - DO_CALL_NOERRNO - DO_CALL_ERRVAL - PSEUDO (syscall cancellation wrapper) Explicitly storing and loading r19 around the syscall e.g. inside the __asm() statement works around the problem. I do not want to have to stw/ldw since it costs a lot in performance, we know now to look at gcc for help. Perhaps I will use this as a temporary measure to release glibc 2.3.2 for debian so we keep testing moving. This problem has a number of interesting heisenbugs: - If the kernel decides not to scratch in r19 then you're okay. - If the compiler version scheduled r19 restore differently then you're okay. All of these contributed to a lof of head scratching on my part. Since things worked sometimes, on some boxes, and differently with different compilers. Needless to say I learned a lot and poked enough other people that we have had our mmap flush problems fixed, and our -fPIC -static problems fixed. See the following for expansion on both: http://www.ussg.iu.edu/hypermail/linux/kernel/0308.2/1680.html http://sources.redhat.com/ml/binutils/2003-08/msg00467.html > I don't see the restore of r19 from r4. What are the other 10 insns? > Normally, I would have expected it before This code is the relocated libpthread.so as viewed without symbols by tracing through ld.so loading ex14 testcase in glibc. This code is the beginning of the loader trying to start the child process immediately after the last few calls in dl-runtime.c. What follows is the whole insn stream up to the crash from the last call to fixup. Here it is for posterity. Breakpoint 1, 0x4100ceb0 in _dl_runtime_resolve () at dl-runtime.c:213 213 value = l->l_addr + sym->st_value; (gdb) c 21 Will ignore next 20 crossings of breakpoint 1. Continuing. Breakpoint 1, 0x4100ceb0 in _dl_runtime_resolve () at dl-runtime.c:213 213 value = l->l_addr + sym->st_value; si from here forward 0x4015e3b8: stw rp,-14(sr0,sp) 0x4015e3bc: stw,ma r4,40(sr0,sp) 0x4015e3c0: stw r19,-20(sr0,sp) 0x4015e3c4: addil 1000,r19,%r1 0x4015e3c8: copy r1,r21 0x4015e3cc: ldw 200(sr0,r21),r21 0x4015e3d0: ldw 6c(sr0,r21),r22 0x4015e3d4: cmpib,<> 0,r22,0x4015e3e8 0x4015e3d8: addil 800,r19,%r1 0x4015e3e8: ldw 5d8(sr0,r1),r20 0x4015e3ec: copy r20,r26 0x4015e3f0: b,l 0x40167e30,r31 0x4015e3f4: copy r31,rp 0x40167e30: b,l 0x40167e38,r1 0x40167e34: addil 9f800,r1,%r1 0x40167e38: be,n 218(sr4,r1) 0x40207850: bb,>=,n r22,1e,0x40207860 0x40207854: depwi 0,31,2,r22 0x40207858: ldw 4(sr0,r22),r19 <---------- r19 = 0x40020718 0x4020785c: ldw 0(sr0,r22),r22 0x40207860: bv r0(r22) 0x40207864: stw rp,-18(sr0,sp) 0x4000812c: stw rp,-14(sr0,sp) 0x40008130: stw,ma r5,40(sr0,sp) 0x40008134: stw r4,-3c(sr0,sp) 0x40008138: stw r3,-38(sr0,sp) 0x4000813c: stw r19,-20(sr0,sp) 0x40008140: ldw c(sr0,r26),r20 0x40008144: copy r26,r3 0x40008148: cmpib,<< 3,r20,0x40008184 0x4000814c: ldi 16,ret0 0x40008150: blr r20,r0 0x40008154: nop 0x40008160: b,l 0x400081a8,r0 0x40008164: ldw 8(sr0,r26),r20 0x400081a8: ldi 0,ret0 0x400081ac: ldo 10(r26),r26 0x400081b0: mfctl tr3,r5 0x400081b4: cmpb,=,n r5,r20,0x400081cc 0x400081b8: b,l 0x4000b29c,rp 0x400081bc: copy r5,r25 0x4000b29c: stw rp,-14(sr0,sp) 0x4000b2a0: stw,ma r4,40(sr0,sp) 0x4000b2a4: stw r19,-20(sr0,sp) 0x4000b2a8: b,l 0x4000b930,rp 0x4000b2ac: ldo 10(r26),r26 0x4000b930: stw rp,-14(sr0,sp) 0x4000b934: ldo 80(sp),sp 0x4000b938: stw r7,-68(sr0,sp) 0x4000b93c: stw r6,-64(sr0,sp) 0x4000b940: stw r5,-60(sr0,sp) 0x4000b944: stw r4,-5c(sr0,sp) 0x4000b948: stw r3,-58(sr0,sp) 0x4000b94c: stw r19,-20(sr0,sp) 0x4000b950: copy r26,r5 0x4000b954: ldi 0,r3 0x4000b958: ldil 1e8000,r20 0x4000b95c: ldi 31,r6 0x4000b960: ldo 481(r20),r7 0x4000b964: stw r5,-70(sr0,sp) 0x4000b968: ldw -70(sr0,sp),r20 0x4000b96c: depwi 0,31,4,r20 0x4000b970: cmpb,<<=,n r5,r20,0x4000b984 0x4000b984: ldw -70(sr0,sp),r20 0x4000b988: ldcw 0(sr0,r20),r20 0x4000b98c: cmpib,<> 0,r20,0x4000b9d0 0x4000b990: ldw -94(sr0,sp),rp 0x4000b9d0: ldw -68(sr0,sp),r7 0x4000b9d4: ldw -64(sr0,sp),r6 0x4000b9d8: ldw -60(sr0,sp),r5 0x4000b9dc: ldw -5c(sr0,sp),r4 0x4000b9e0: ldw -58(sr0,sp),r3 0x4000b9e4: bv r0(rp) 0x4000b9e8: ldo -80(sp),sp 0x4000b2b0: ldw -54(sr0,sp),rp 0x4000b2b4: bv r0(rp) 0x4000b2b8: ldw,mb -40(sr0,sp),r4 0x400081c0: stw r0,4(sr0,r3) 0x400081c4: b,l 0x40008180,r0 0x400081c8: stw r5,8(sr0,r3) 0x40008180: ldi 0,ret0 0x40008184: ldw -54(sr0,sp),rp 0x40008188: ldw -3c(sr0,sp),r4 0x4000818c: ldw -38(sr0,sp),r3 0x40008190: bv r0(rp) 0x40008194: ldw,mb -40(sr0,sp),r5 0x4015e3f8: b,l 0x4015e3e0,r0 0x4015e3fc: ldw -54(sr0,sp),rp 0x4015e3e0: bv r0(rp) 0x4015e3e4: ldw,mb -40(sr0,sp),r4 0x40008838: copy r4,r19 <---Restore----- r19 = 0x40020718 __asm( 0x4000883c: be,l 100(sr2,r0),%sr0,%r31 0x40008840: ldi 2,r20 !! FORK !! ); 0x40008844: ldi -1000,r20 <--Corrupted--- r19 = 0x10106368 0x40008848: cmpb,>>= r20,ret0,0x40008868 0x4000884c: copy ret0,r6 0x40008868: cmpib,<> 0,r6,0x400088e4 0x4000886c: copy r19,r4 0x400088e4: b,l 0x4000a9d4,rp 0x400088e8: ldo 38(r7),r5 0x4000a9d4: stw rp,-14(sr0,sp) 0x4000a9d8: ldo 40(sp),sp 0x4000a9dc: stw r19,-20(sr0,sp) 0x4000a9e0: ldw -54(sr0,sp),rp 0x4000a9e4: b,l 0x40005440,r0 0x4000a9e8: ldo -40(sp),sp No scheduled r19 restore yet. 0x40005440: addil -800,r19,%r1 0x40005444: ldw 55c(sr0,r1),r21 <-- Not quote boom, probably wrong. 0x40005448: bv r0(r21) 0x4000544c: ldw 560(sr0,r1),r19 <-- *Boom* > If the restore is not there, please send preprocessed source and > compilation details. BOOM appears to be in an import stub (i.e., > there must be a call in the 10). Calls use r19 in pic code (i.e., > in the import stub), so it's not obvious why the restore wouldn't be > there. The restore is not there. Placing r19 into the __asm(syscall) clobber list doesn't fix the issue. Nothing short of an explicity stw/ldw inside the __asm statement saves r19 from corruption. > Scheduling can reorder instructions, so the pic restore doesn't have > to immediately follow a call. "FORK" isn't a GCC generated call > (we never use sr2). Calls are tricky and the procedure for generating > them has been revised several times. Now, we don't split out the save > and restore of the pic register until after reload. Reload can introduce > new uses of the pic register. When not using exceptions, register > copies following a call are part of an "in call group" that keeps the > restore in the same basic block as the call for scheduling purposes. > However, when exceptions are enabled, the basic block ends at the > call. If the restore is split out from the call before reload, > it will be scheduled in a different basic block from the call. As > a result, scheduling may move another instruction which has an > implicit dependence on the pic register forward past the restore. > Then, BOOM. Preprocessed source for ptfork.c at: http://www.baldric.uwo.ca/~carlos/ptfork.E You'll see the INLINE_SYSCALL in __pthread_fork on line 8137. I would like to not that I might have made _many_ errors, but the simple stw/ldw r19 fix passes all the glib thread tests so I think its a step in the right direction. Thanks for the help! c. From dave@hiauly3.hia.nrc.ca Fri Aug 29 23:03:00 2003 From: dave@hiauly3.hia.nrc.ca (John David Anglin) Date: Fri, 29 Aug 2003 18:03:00 -0400 (EDT) Subject: [parisc-linux] Re: [glibc] tststatic failues, reduced to simple testcase. In-Reply-To: <20030829200400.GF19341@systemhalted> from Carlos O'Donell at Aug "29," 2003 "04:04:00" pm Message-ID: <200308292203.SAA03224@hiauly3.hia.nrc.ca> > I'm sending this to the list so it gets recorded on archive. Our problem > right now it that we don't properly restore r19 after an __asm() > statement even if the clobber contains r19. Or rather gcc doesn't > schedule the restore to occur at the right time. An asm will not cause the restoration of %r19. The compiler treats r19 as a fixed register when generating pic code. The saving and restoring of the pic register across calls is something that the pa port does itself in the backend. Clobbering r19 won't cause it to be restored. In the case of syscalls, the compiler has no way of telling that you are making a "call". > What does this mean for glibc, well it means that ld.so's first fork > corrupts the PIC register r19 aka LTP, and the subsequent import stub > for a function call fails (SIGSEGV). What is effected in glibc? > The following: > - INTERNAL_SYSCALL (Macro syscall) > - INLINE_SYSCALL (Macro syscall) > - syscall(...) (C version) > - DO_CALL (Assembly wrapper syscall) > Explicitly storing and loading r19 around the syscall e.g. inside the > __asm() statement works around the problem. I do not want to have to > stw/ldw since it costs a lot in performance, we know now to look at gcc > for help. Perhaps I will use this as a temporary measure to release > glibc 2.3.2 for debian so we keep testing moving. > > This problem has a number of interesting heisenbugs: > - If the kernel decides not to scratch in r19 then you're okay. > - If the compiler version scheduled r19 restore differently then > you're okay. > 0x40008838: copy r4,r19 <---Restore----- r19 = 0x40020718 This is a restore after a call. > __asm( > 0x4000883c: be,l 100(sr2,r0),%sr0,%r31 > 0x40008840: ldi 2,r20 !! FORK !! > ); > 0x40008844: ldi -1000,r20 <--Corrupted--- r19 = 0x10106368 There is no save and restore around the syscall as GCC doesn't know the asm does a call. Clobbering r19 isn't an option in PIC code. Thus, either the syscall has to save and restore r19, or the kernel has to avoid clobbering r19. > Preprocessed source for ptfork.c at: > http://www.baldric.uwo.ca/~carlos/ptfork.E > You'll see the INLINE_SYSCALL in __pthread_fork on line 8137. > > I would like to not that I might have made _many_ errors, but the simple > stw/ldw r19 fix passes all the glib thread tests so I think its a step > in the right direction. You should be able to use a register. The problem is how to do this in a nice way so that you don't have to save and restore r19 in non-pic code. Ouch, I am surprised that this hasn't had a bigger effect. Dave From dave@hiauly3.hia.nrc.ca Fri Aug 29 23:44:03 2003 From: dave@hiauly3.hia.nrc.ca (John David Anglin) Date: Fri, 29 Aug 2003 18:44:03 -0400 (EDT) Subject: [parisc-linux] Re: [glibc] tststatic failues, reduced to simple testcase. In-Reply-To: <200308292203.SAA03224@hiauly3.hia.nrc.ca> from John David Anglin at Aug "29," 2003 "06:03:00" pm Message-ID: <200308292244.SAA29829@hiauly3.hia.nrc.ca> > > __asm( > > 0x4000883c: be,l 100(sr2,r0),%sr0,%r31 > > 0x40008840: ldi 2,r20 !! FORK !! > > ); > > 0x40008844: ldi -1000,r20 <--Corrupted--- r19 = 0x10106368 Looking at the kernel syscall code, it seems at first glance that r19 is saved and restored. Thus, the problem may be specific to fork. Dave From grundler@parisc-linux.org Sat Aug 30 06:06:28 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 29 Aug 2003 23:06:28 -0600 Subject: [parisc-linux] Re: xchat colors In-Reply-To: <20030815063718.GD16974@lug-owl.de> References: <20030815061601.GD2989@dsl2.external.hp.com> <20030815063718.GD16974@lug-owl.de> Message-ID: <20030830050628.GA5649@dsl2.external.hp.com> On Fri, Aug 15, 2003 at 08:37:18AM +0200, Jan-Benedict Glaw wrote: > Unstable's current XFree (4.2.1.1) "RENDER" extension (used for > anti-aliasing IIRC) takes a _lot_ of colors for it's own (rumors I > heared talked about > 200 IIRC)... On this note I want to share solving my last problem with xchat and 8-bit TrueColor. C3k doesn't have anything better at the moment. The "couriour new" font was getting mangled colors as part of the effort to anti-alias (what I assume is) a true-type or re-sized font. Picking a bitmap font like "fixed" too take care of this. Nice readable letters all in white. hth, grant From rscholz@hrzpub.tu-darmstadt.de Sat Aug 30 13:42:37 2003 From: rscholz@hrzpub.tu-darmstadt.de (Ruediger Scholz) Date: Sat, 30 Aug 2003 14:42:37 +0200 Subject: [parisc-linux] Security Hole in binfmt_som.c ? Message-ID: <3F509BBD.2040007@hrzpub.tu-darmstadt.de> Hi there, when compiling the new 2.4.22-kernel I get an errror message: ------------>><<--------------- gcc -D__KERNEL__ -I/usr/src/linux-2.4/include -Wall -Wstrict-prototypes -Wno-tri graphs -O2 -fno-strict-aliasing -fno-common -D__linux__ -pipe -fno-strength-redu ce -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -m arch=1.1 -mschedule=7100LC -nostdinc -I /usr/lib/gcc-lib/hppa-linux/3.3.1/incl ude -DKBUILD_BASENAME=binfmt_som -c -o binfmt_som.o binfmt_som.c binfmt_som.c:216:2: #error "Fix security hole before enabling me" make[2]: *** [binfmt_som.o] Fehler 1 make[2]: Leaving directory `/usr/src/linux-2.4/fs' make[1]: *** [first_rule] Fehler 2 make[1]: Leaving directory `/usr/src/linux-2.4/fs' make: *** [_dir_fs] Fehler 2 ------------>><<--------------- What's this message about? Kernel .config is built by make oldconfig. Greetings, Ruediger From willy@debian.org Sat Aug 30 14:15:41 2003 From: willy@debian.org (Matthew Wilcox) Date: Sat, 30 Aug 2003 14:15:41 +0100 Subject: [parisc-linux] Security Hole in binfmt_som.c ? In-Reply-To: <3F509BBD.2040007@hrzpub.tu-darmstadt.de> References: <3F509BBD.2040007@hrzpub.tu-darmstadt.de> Message-ID: <20030830131541.GI13467@parcelfarce.linux.theplanet.co.uk> On Sat, Aug 30, 2003 at 02:42:37PM +0200, Ruediger Scholz wrote: > binfmt_som.c:216:2: #error "Fix security hole before enabling me" > What's this message about? I don't know. I wish someone would tell me. You'd think they'd have the decency to contact the person listed as the author at the top of the file. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From alan@lxorguk.ukuu.org.uk Sat Aug 30 14:49:50 2003 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Sat, 30 Aug 2003 14:49:50 +0100 Subject: [parisc-linux] Security Hole in binfmt_som.c ? In-Reply-To: <20030830131541.GI13467@parcelfarce.linux.theplanet.co.uk> References: <3F509BBD.2040007@hrzpub.tu-darmstadt.de> <20030830131541.GI13467@parcelfarce.linux.theplanet.co.uk> Message-ID: <1062251389.31150.4.camel@dhcp23.swansea.linux.org.uk> On Sad, 2003-08-30 at 14:15, Matthew Wilcox wrote: > On Sat, Aug 30, 2003 at 02:42:37PM +0200, Ruediger Scholz wrote: > > binfmt_som.c:216:2: #error "Fix security hole before enabling me" > > What's this message about? > > I don't know. I wish someone would tell me. You'd think they'd have the > decency to contact the person listed as the author at the top of the file. Actually explanations were posted in the previous discussion on this on parisc-list. Someone has to do the equivalent of the 2.4.22 binfmt_elf changes if neccessary so that another thread can't change the file handles or steal the exec fd being passed to the loader. From willy@debian.org Sat Aug 30 14:59:33 2003 From: willy@debian.org (Matthew Wilcox) Date: Sat, 30 Aug 2003 14:59:33 +0100 Subject: [parisc-linux] Security Hole in binfmt_som.c ? In-Reply-To: <1062251389.31150.4.camel@dhcp23.swansea.linux.org.uk> References: <3F509BBD.2040007@hrzpub.tu-darmstadt.de> <20030830131541.GI13467@parcelfarce.linux.theplanet.co.uk> <1062251389.31150.4.camel@dhcp23.swansea.linux.org.uk> Message-ID: <20030830135933.GJ13467@parcelfarce.linux.theplanet.co.uk> On Sat, Aug 30, 2003 at 02:49:50PM +0100, Alan Cox wrote: > On Sad, 2003-08-30 at 14:15, Matthew Wilcox wrote: > > On Sat, Aug 30, 2003 at 02:42:37PM +0200, Ruediger Scholz wrote: > > > binfmt_som.c:216:2: #error "Fix security hole before enabling me" > > > What's this message about? > > > > I don't know. I wish someone would tell me. You'd think they'd have the > > decency to contact the person listed as the author at the top of the file. > > Actually explanations were posted in the previous discussion on this on > parisc-list. Um, I can't find it, and neither can Google: http://www.google.com/search?q=binfmt_som+security&as_q=%5Bparisc-linux&btnG=Google+Search&as_sitesearch=lists.parisc-linux.org > Someone has to do the equivalent of the 2.4.22 binfmt_elf changes if > neccessary so that another thread can't change the file handles or > steal the exec fd being passed to the loader. Hm, ok, I'll take a look later this weekend if no-one gets to it first. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From carlos@baldric.uwo.ca Sat Aug 30 16:35:17 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Sat, 30 Aug 2003 11:35:17 -0400 Subject: [parisc-linux] Re: [glibc] tststatic failues, reduced to simple testcase. In-Reply-To: <200308292203.SAA03224@hiauly3.hia.nrc.ca> References: <20030829200400.GF19341@systemhalted> <200308292203.SAA03224@hiauly3.hia.nrc.ca> Message-ID: <20030830153516.GD5194@systemhalted> Dave, > An asm will not cause the restoration of %r19. The compiler treats > r19 as a fixed register when generating pic code. The saving and > restoring of the pic register across calls is something that the pa > port does itself in the backend. Clobbering r19 won't cause it > to be restored. I thought that listing it in the clobber would be the solution. > In the case of syscalls, the compiler has no way of telling that > you are making a "call". Yes, glibc has begun using inlined macros rather than incuring the penalty of a function call to get at the syscall. I _could_ cheat and make the inlined code call a 'C' function which would force a restore, but we then have _many_ more insn on the fast path (rather than just a stw and ldw). > > 0x40008838: copy r4,r19 <---Restore----- r19 = 0x40020718 > > This is a restore after a call. Correct. This is a delayed restore from a previous call. > > __asm( > > 0x4000883c: be,l 100(sr2,r0),%sr0,%r31 > > 0x40008840: ldi 2,r20 !! FORK !! > > ); > > 0x40008844: ldi -1000,r20 <--Corrupted--- r19 = 0x10106368 > > There is no save and restore around the syscall as GCC doesn't know > the asm does a call. Clobbering r19 isn't an option in PIC code. > Thus, either the syscall has to save and restore r19, or the kernel > has to avoid clobbering r19. I would vote for having the kernel avoid trashing r19, though that means that the kernel has to do the stw/ldw, and wouldn't it be more beneficial to do this in userspace and allow the kernel an extra register to generate code with? > You should be able to use a register. The problem is how to do this > in a nice way so that you don't have to save and restore r19 in non-pic > code. Glibc tells me if I'm in PIC code by setting -DPIC on the command line. I'm planning on using "ifdef PIC" to optimize away the save and restore. The issue really is that most programs are dynamically linked against libc, and thus all their syscalls have to save and restore r19. > Ouch, I am surprised that this hasn't had a bigger effect. Me too. I really see this as a "We should have been doing this anyway" and we aren't going to get away from this. c. From carlos@baldric.uwo.ca Sat Aug 30 17:15:04 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Sat, 30 Aug 2003 12:15:04 -0400 Subject: [parisc-linux] Re: [glibc] tststatic failues, reduced to simple testcase. In-Reply-To: <200308292244.SAA29829@hiauly3.hia.nrc.ca> References: <200308292203.SAA03224@hiauly3.hia.nrc.ca> <200308292244.SAA29829@hiauly3.hia.nrc.ca> Message-ID: <20030830161504.GE5194@systemhalted> On Fri, Aug 29, 2003 at 06:44:03PM -0400, John David Anglin wrote: > > > __asm( > > > 0x4000883c: be,l 100(sr2,r0),%sr0,%r31 > > > 0x40008840: ldi 2,r20 !! FORK !! > > > ); > > > 0x40008844: ldi -1000,r20 <--Corrupted--- r19 = 0x10106368 > > Looking at the kernel syscall code, it seems at first glance that > r19 is saved and restored. Thus, the problem may be specific to fork. The first place I went to was syscall.S and entry.S to see if r19 was saved and restored. It is infact saved and restored, _but_ there seems to be a case in the sys_fork_wrapper where r19 is written back as a temp slot (PT_XX struct). linux-2.4/arch/parisc/kernel/entry.S 2004 /* These are call-clobbered registers and therefore 2005 also syscall-clobbered (we hope). */ 2006 STREG %r2,PT_GR19(%r1) /* save for child */ 2007 STREG %r30,PT_GR21(%r1) This is done just before the call to 'sys_clone', but it's never used anywhere. The comment indicates that the author believed he had all right to use caller saves registers, and they should. Aflicted: sys_fork_wrapper, sys_clone_wrapper, sys_vfork_wrapper I'm tempted to remove the store and load of call-clobbered registers from our syscall path, push them into the glibc wrappers, and see what happens :) c. From carlos@baldric.uwo.ca Sat Aug 30 17:37:33 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Sat, 30 Aug 2003 12:37:33 -0400 Subject: [parisc-linux] Re: [glibc] fixing delayed exceptions in hppa In-Reply-To: <200308231612.MAA21233@hiauly3.hia.nrc.ca> References: <20030823055506.GA9821@systemhalted> <200308231612.MAA21233@hiauly3.hia.nrc.ca> Message-ID: <20030830163732.GG5194@systemhalted> > > Yes. If you follow the thread that I sent you, Jim Hull comments on > this and offers a rewrite of the sentence that you quoted. I believe > that referencing memory is important as this makes the operation visible > to another processor. A register->register operation doesn't do this. > I implemented and tested 3 versions, fcpy doesn't work on my c3k, but the fstd and fldd does. Any recommendations on which to take. I'm tempted to leave all this in and send the patch like this upstream, so I don't forget what the other versions looked like :) Comments welcome. c. diff -u -p -r1.4 fraiseexcpt.c --- libc/sysdeps/hppa/fpu/fraiseexcpt.c 10 Sep 2002 01:26:37 -0000 1.4 +++ libc/sysdeps/hppa/fpu/fraiseexcpt.c 30 Aug 2003 16:35:48 -0000 @@ -22,9 +22,27 @@ #include #include +/* We implement three methods for flushing delayed exceptions. The first + is an interlocked register copy with the destination register of the + trapping insn. This method is not recommended, and may not work in all + situations. The last two, either loading or storing a value from memory + into the destination register of the trapping insn will work, here we + choose to store the value to memory. + + Please see section 10, + page 10-5 "Delayed Trapping" in the PA-RISC 2.0 Architecture manual */ + +#undef BARRIER_FCPY +#define BARRIER_FSTD +#undef BARRIER_FLDD + int feraiseexcept (int excepts) { + /* Provides a place to fake our write for flushing the delayed trap */ + double dmem = 0; + double * pmem = &dmem; + /* Raise exceptions represented by EXCEPTS. But we must raise only one signal at a time. It is important that if the overflow/underflow exception and the divide by zero exception are given at the same @@ -33,26 +51,49 @@ feraiseexcept (int excepts) /* We do these bits in assembly to be certain GCC doesn't optimize away something important, and so we can force delayed traps to - occur. */ - - /* FIXME: These all need verification! */ + occur. */ /* First: invalid exception. */ if (excepts & FE_INVALID) { /* One example of a invalid operation is 0 * Infinity. */ double d = HUGE_VAL; - __asm__ __volatile__ ("fmpy,dbl %1,%%fr0,%0\n\t" - /* FIXME: is this a proper trap barrier? */ - "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d)); + __asm__ __volatile__ ( + " fmpy,dbl %0,%%fr0,%0\n" +#ifdef BARRIER_FCPY + " fcpy,dbl %0,%1" + : "+f" (d), "=f" (dmem) +#endif +#ifdef BARRIER_FSTD + " fstd,dbl %0,%1" + : "+f" (d), "=m" (*pmem) +#endif +#ifdef BARRIER_FLDD + " fldd,dbl 0(%%sr0,%%sp),%0" + : "+f" (d) +#endif + ); } /* Next: division by zero. */ if (excepts & FE_DIVBYZERO) { double d = 1.0; - __asm__ __volatile__ ("fdiv,dbl %1,%%fr0,%0\n\t" - "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d)); + __asm__ __volatile__ ( + " fdiv,dbl %0,%%fr0,%0\n" +#ifdef BARRIER_FCPY + " fcpy,dbl %0,%1" + : "+f" (d), "=f" (dmem) +#endif +#ifdef BARRIER_FSTD + " fstd,dbl %0,%1" + : "+f" (d), "=m" (*pmem) +#endif +#ifdef BARRIER_FLDD + " fldd,dbl 0(%%sr0,%%sp),%0" + : "+f" (d) +#endif + ); } /* Next: overflow. */ @@ -61,8 +102,21 @@ feraiseexcept (int excepts) { double d = DBL_MAX; - __asm__ __volatile__ ("fmpy,dbl %1,%1,%0\n\t" - "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d)); + __asm__ __volatile__ ( + " fmpy,dbl %0,%0,%0\n" +#ifdef BARRIER_FCPY + " fcpy,dbl %0,%1" + : "+f" (d), "=f" (dmem) +#endif +#ifdef BARRIER_FSTD + " fstd,dbl %0,%1" + : "+f" (d), "=m" (*pmem) +#endif +#ifdef BARRIER_FLDD + " fldd,dbl 0(%%sr0,%%sp),%0" + : "+f" (d) +#endif + ); } /* Next: underflow. */ @@ -71,8 +125,23 @@ feraiseexcept (int excepts) double d = DBL_MIN; double e = 69.69; - __asm__ __volatile__ ("fdiv,dbl %1,%2,%0\n\t" - "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d), "f" (e)); + __asm__ __volatile__ ( +#ifdef BARRIER_FCPY + " fdiv,dbl %0,%2,%0\n" + " fcpy,dbl %0,%1" + : "+f" (d), "=f" (dmem) : "f" (e) +#endif +#ifdef BARRIER_FSTD + " fdiv,dbl %0,%2,%0\n" + " fstd,dbl %0,%1" + : "+f" (d), "=m" (*pmem) : "f" (e) +#endif +#ifdef BARRIER_FLDD + " fdiv,dbl %0,%1,%0\n" + " fldd,dbl 0(%%sr0,%%sp),%0" + : "+f" (d) : "f" (e) +#endif + ); } /* Last: inexact. */ @@ -81,8 +150,23 @@ feraiseexcept (int excepts) double d = 1.0; double e = M_PI; - __asm__ __volatile__ ("fdiv,dbl %1,%2,%0\n\t" - "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d), "f" (e)); + __asm__ __volatile__ ( +#ifdef BARRIER_FCPY + " fdiv,dbl %0,%2,%0\n" + " fcpy,dbl %0,%1" + : "+f" (d), "=f" (dmem) : "f" (e) +#endif +#ifdef BARRIER_FSTD + " fdiv,dbl %0,%2,%0\n" + " fstd,dbl %0,%1" + : "+f" (d), "=m" (*pmem) : "f" (e) +#endif +#ifdef BARRIER_FLDD + " fdiv,dbl %0,%1,%0\n" + " fldd,dbl 0(%%sr0,%%sp),%0" + : "+f" (d) : "f" (e) +#endif + ); } /* Success. */ From dave@hiauly3.hia.nrc.ca Sat Aug 30 23:54:45 2003 From: dave@hiauly3.hia.nrc.ca (John David Anglin) Date: Sat, 30 Aug 2003 18:54:45 -0400 (EDT) Subject: [parisc-linux] Re: [glibc] fixing delayed exceptions in hppa In-Reply-To: <20030830163732.GG5194@systemhalted> from Carlos O'Donell at Aug "30," 2003 "12:37:33" pm Message-ID: <200308302254.SAA01088@hiauly3.hia.nrc.ca> > > Yes. If you follow the thread that I sent you, Jim Hull comments on > > this and offers a rewrite of the sentence that you quoted. I believe > > that referencing memory is important as this makes the operation visible > > to another processor. A register->register operation doesn't do this. > > > > I implemented and tested 3 versions, fcpy doesn't work on my c3k, but > the fstd and fldd does. Any recommendations on which to take. I'm > tempted to leave all this in and send the patch like this upstream, so I > don't forget what the other versions looked like :) The FSTD barrier looks fine to me. The fcpy version doesn't work, so I wouldn't keep it around. You might add a comment that fcpy doesn't work on at least some implementations. Dave From alan@lxorguk.ukuu.org.uk Sun Aug 31 00:33:00 2003 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Sun, 31 Aug 2003 00:33:00 +0100 Subject: [parisc-linux] Security Hole in binfmt_som.c ? In-Reply-To: <20030830135933.GJ13467@parcelfarce.linux.theplanet.co.uk> References: <3F509BBD.2040007@hrzpub.tu-darmstadt.de> <20030830131541.GI13467@parcelfarce.linux.theplanet.co.uk> <1062251389.31150.4.camel@dhcp23.swansea.linux.org.uk> <20030830135933.GJ13467@parcelfarce.linux.theplanet.co.uk> Message-ID: <1062286379.31332.6.camel@dhcp23.swansea.linux.org.uk> On Sad, 2003-08-30 at 14:59, Matthew Wilcox wrote: > Um, I can't find it, and neither can Google: > http://www.google.com/search?q=binfmt_som+security&as_q=%5Bparisc-linux&btnG=Google+Search&as_sitesearch=lists.parisc-linux.org Humm I thought it was on this list. Maybe lkml then Whatever the basic problem is we have kernel loaders and user threads sharing a file table unsafely From dave@hiauly3.hia.nrc.ca Sun Aug 31 01:00:36 2003 From: dave@hiauly3.hia.nrc.ca (John David Anglin) Date: Sat, 30 Aug 2003 20:00:36 -0400 (EDT) Subject: [parisc-linux] Re: [glibc] tststatic failues, reduced to simple testcase. In-Reply-To: <20030830161504.GE5194@systemhalted> from Carlos O'Donell at Aug "30," 2003 "12:15:04" pm Message-ID: <200308310000.UAA01375@hiauly3.hia.nrc.ca> > On Fri, Aug 29, 2003 at 06:44:03PM -0400, John David Anglin wrote: > > > > __asm( > > > > 0x4000883c: be,l 100(sr2,r0),%sr0,%r31 > > > > 0x40008840: ldi 2,r20 !! FORK !! > > > > ); > > > > 0x40008844: ldi -1000,r20 <--Corrupted--- r19 = 0x10106368 > > > > Looking at the kernel syscall code, it seems at first glance that > > r19 is saved and restored. Thus, the problem may be specific to fork. > > The first place I went to was syscall.S and entry.S to see if r19 was > saved and restored. It is infact saved and restored, _but_ there seems > to be a case in the sys_fork_wrapper where r19 is written back as a temp > slot (PT_XX struct). > > linux-2.4/arch/parisc/kernel/entry.S > > 2004 /* These are call-clobbered registers and therefore > 2005 also syscall-clobbered (we hope). */ > 2006 STREG %r2,PT_GR19(%r1) /* save for child */ > 2007 STREG %r30,PT_GR21(%r1) > > This is done just before the call to 'sys_clone', but it's never used > anywhere. The comment indicates that the author believed he had all > right to use caller saves registers, and they should. I don't fully understand this code but possibly PT_GR20 might be used to save r2. In the fork call for example, we know that this location contains __NR_fork. This value gets restored to r20 in wrapper_exit. I think the valued saved above is loaded into r2 here: child_return: bl schedule_tail, %r2 nop LDREG TASK_PT_GR19-TASK_SZ_ALGN-FRAME_SIZE-FRAME_SIZE(%r30),%r2 b wrapper_exit copy %r0,%r28 I don't see where the %r30 value saved in PT_GR21 is used. If a syscall is going to clobber registers, the appropriate clobbers need to be added to the asm used for the syscall so that gcc doesn't try to use these registers over the syscall. Use of PT_GR19 appears to have been a bad choice because of its special use in pic code. Dave From Administrator@dsl2.external.hp.com Sun Aug 31 01:13:34 2003 From: Administrator@dsl2.external.hp.com (Administrator@dsl2.external.hp.com) Date: Sat, 30 Aug 2003 20:13:34 -0400 Subject: [parisc-linux] ScanMail Message: To Sender virus found and action taken. Message-ID: <046a01c36f54$b7e80cc0$2445440a@ipoutlet.net> ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = parisc-linux@parisc-linux.org Recipient(s) = Alison Forche Subject = Re: That movie Scanning Time = 08/30/2003 20:13:34 Engine/Pattern = 6.510-1002/622 Action on virus found: The attachment document_all.pif contains WORM_SOBIG.F virus. ScanMail has Moved it. The attachment was moved to C:\Program Files\Trend\Smex\Virus\document_all3f513daee5.pif_. Warning to sender. ScanMail has detected a virus in an email you sent. From carlos@baldric.uwo.ca Sun Aug 31 16:29:00 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Sun, 31 Aug 2003 11:29:00 -0400 Subject: [parisc-linux] Re: [glibc] tststatic failues, reduced to simple testcase. In-Reply-To: <20030830161504.GE5194@systemhalted> References: <200308292203.SAA03224@hiauly3.hia.nrc.ca> <200308292244.SAA29829@hiauly3.hia.nrc.ca> <20030830161504.GE5194@systemhalted> Message-ID: <20030831152900.GI5194@systemhalted> > > Aflicted: sys_fork_wrapper, sys_clone_wrapper, sys_vfork_wrapper > > I'm tempted to remove the store and load of call-clobbered registers > from our syscall path, push them into the glibc wrappers, and see what > happens :) What happens when your stack changes on the route back from the syscall? stw r19, -32(sp) /* clone */ ldw -32(sp), r19 Obviously I could add a "if parent then ldw -32(sp),r19", but the child, not having the same stack would be hard pressed if r19 changed during the syscall. Although, I think I see that in glibc the child's function is called via $$dyncall and I assume that might fixup r19 for the child. Do any other syscalls change the stack on return? I can only really think of all the fork-ish type syscalls doing that sort of stuff. c. From willy@debian.org Sun Aug 31 16:39:57 2003 From: willy@debian.org (Matthew Wilcox) Date: Sun, 31 Aug 2003 16:39:57 +0100 Subject: [parisc-linux] [ron@rongage.org: [Patchbomb] - Copy_to/from_user audit - oss4 - RESEND] Message-ID: <20030831153957.GX13467@parcelfarce.linux.theplanet.co.uk> ----- Forwarded message from Ron Gage ----- From: Ron Gage To: kernel-janitor-discuss@lists.sourceforge.net Subject: [Patchbomb] - Copy_to/from_user audit - oss4 - RESEND User-Agent: KMail/1.5.2 Errors-To: kernel-janitor-discuss-admin@lists.sourceforge.net X-BeenThere: kernel-janitor-discuss@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: kernel janitor discussion list List-Unsubscribe: , List-Archive: X-Original-Date: Sun, 31 Aug 2003 11:20:48 -0400 Date: Sun, 31 Aug 2003 11:20:48 -0400 This patch is also available on my ftp server ftp://new.rongage.org/pub/linux This patch catches insures proper return values from copy_to/from_user calls. Ron Gage - Pontiac, MI diff -urN linux-2.6.0-test4/sound/oss/harmony.c linux-2.6.0-test4-patched/sound/oss/harmony.c --- linux-2.6.0-test4/sound/oss/harmony.c 2003-08-22 19:58:39.000000000 -0400 +++ linux-2.6.0-test4-patched/sound/oss/harmony.c 2003-08-29 22:02:42.000000000 -0400 @@ -725,7 +725,7 @@ info.fragments = MAX_BUFS - harmony.nb_filled_play; info.fragsize = HARMONY_BUF_SIZE; info.bytes = info.fragments * info.fragsize; - return copy_to_user((void *)arg, &info, sizeof(info)); + return copy_to_user((void *)arg, &info, sizeof(info)) ? -EFAULT : 0 ; case SNDCTL_DSP_GETISPACE: if (!(file->f_mode & FMODE_READ)) @@ -734,7 +734,7 @@ info.fragments = /*MAX_BUFS-*/ harmony.nb_filled_record; info.fragsize = HARMONY_BUF_SIZE; info.bytes = info.fragments * info.fragsize; - return copy_to_user((void *)arg, &info, sizeof(info)); + return copy_to_user((void *)arg, &info, sizeof(info)) ? -EFAULT : 0 ; case SNDCTL_DSP_SYNC: return 0; ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Kernel-janitor-discuss mailing list Kernel-janitor-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kernel-janitor-discuss ----- End forwarded message ----- -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From carlos@baldric.uwo.ca Sun Aug 31 16:38:38 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Sun, 31 Aug 2003 11:38:38 -0400 Subject: [parisc-linux] Re: [glibc] tststatic failues, reduced to simple testcase. In-Reply-To: <200308310000.UAA01375@hiauly3.hia.nrc.ca> References: <20030830161504.GE5194@systemhalted> <200308310000.UAA01375@hiauly3.hia.nrc.ca> Message-ID: <20030831153837.GJ5194@systemhalted> > I don't fully understand this code but possibly PT_GR20 might be used > to save r2. In the fork call for example, we know that this location > contains __NR_fork. This value gets restored to r20 in wrapper_exit. > I think the valued saved above is loaded into r2 here: So you say perhaps instead of PT_GR19 we use PT_GR20 and TASK_PT_GR20? I think we can't though, because tracing the syscall requires that GR20 continue to retain the syscall value. I think we can use _any_ other caller-saves registers (including the last input for the fork-ish calls e.g. GR21 or GR22?). > child_return: > bl schedule_tail, %r2 > nop > > LDREG TASK_PT_GR19-TASK_SZ_ALGN-FRAME_SIZE-FRAME_SIZE(%r30),%r2 > b wrapper_exit > copy %r0,%r28 > > I don't see where the %r30 value saved in PT_GR21 is used. Me neither. Perhaps it's superfluous and can be used to retrieve r2 and thus keep r19 safe. > If a syscall is going to clobber registers, the appropriate clobbers > need to be added to the asm used for the syscall so that gcc doesn't > try to use these registers over the syscall. Use of PT_GR19 appears > to have been a bad choice because of its special use in pic code. I've added all the caller-saves registers to our clobber lists when making syscalls. Though, r19 being special, I've had to add "STW_PIC" and "LDW_PIC" that do the saving and restore _only_ if we are compiled PIC. c. From willy@debian.org Sun Aug 31 16:42:10 2003 From: willy@debian.org (Matthew Wilcox) Date: Sun, 31 Aug 2003 16:42:10 +0100 Subject: [parisc-linux] [ron@rongage.org: [Patchbomb] - Copy_to/from_user audit - parisc -RESEND] Message-ID: <20030831154210.GY13467@parcelfarce.linux.theplanet.co.uk> ----- Forwarded message from Ron Gage ----- From: Ron Gage To: kernel-janitor-discuss@lists.sourceforge.net Subject: [Patchbomb] - Copy_to/from_user audit - parisc -RESEND User-Agent: KMail/1.5.2 Errors-To: kernel-janitor-discuss-admin@lists.sourceforge.net X-BeenThere: kernel-janitor-discuss@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: kernel janitor discussion list List-Unsubscribe: , List-Archive: X-Original-Date: Sun, 31 Aug 2003 11:18:49 -0400 Date: Sun, 31 Aug 2003 11:18:49 -0400 This patch is also available on my ftp server ftp://new.rongage.org/pub/linux This patch catches insures proper return values from copy_to/from_user calls. Ron Gage - Pontiac, MI diff -urN linux-2.6.0-test4/arch/parisc/kernel/signal32.c linux-2.6.0-test4-patched/arch/parisc/kernel/signal32.c --- linux-2.6.0-test4/arch/parisc/kernel/signal32.c 2003-08-22 19:53:07.000000000 -0400 +++ linux-2.6.0-test4-patched/arch/parisc/kernel/signal32.c 2003-08-29 21:38:02.000000000 -0400 @@ -38,7 +38,7 @@ if (sz != sizeof *set) panic("put_sigset32()"); sigset_64to32(&s, set); - return copy_to_user(up, &s, sizeof s); + return copy_to_user(up, &s, sizeof s) ? -EFAULT : 0 ; } static int diff -urN linux-2.6.0-test4/arch/parisc/kernel/sys_parisc.c linux-2.6.0-test4-patched/arch/parisc/kernel/sys_parisc.c --- linux-2.6.0-test4/arch/parisc/kernel/sys_parisc.c 2003-08-22 19:59:03.000000000 -0400 +++ linux-2.6.0-test4-patched/arch/parisc/kernel/sys_parisc.c 2003-08-29 21:36:06.000000000 -0400 @@ -271,7 +271,7 @@ tbuf.shm_cpid = sbuf->shm_cpid; tbuf.shm_lpid = sbuf->shm_lpid; tbuf.shm_nattch = sbuf->shm_nattch; - return copy_to_user(buf, &tbuf, sizeof tbuf); + return copy_to_user(buf, &tbuf, sizeof tbuf) ? -EFAULT : 0; } int sys_msgctl_broken(int msqid, int cmd, struct msqid_ds *buf) diff -urN linux-2.6.0-test4/arch/parisc/kernel/sys_parisc32.c linux-2.6.0-test4-patched/arch/parisc/kernel/sys_parisc32.c --- linux-2.6.0-test4/arch/parisc/kernel/sys_parisc32.c 2003-08-22 19:54:17.000000000 -0400 +++ linux-2.6.0-test4-patched/arch/parisc/kernel/sys_parisc32.c 2003-08-29 21:36:59.000000000 -0400 @@ -370,7 +370,7 @@ struct compat_timeval t32; t32.tv_sec = t->tv_sec; t32.tv_usec = t->tv_usec; - return copy_to_user(u, &t32, sizeof t32); + return copy_to_user(u, &t32, sizeof t32) ? -EFAULT : 0 ; } static int ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Kernel-janitor-discuss mailing list Kernel-janitor-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kernel-janitor-discuss ----- End forwarded message ----- -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From dave@hiauly3.hia.nrc.ca Sun Aug 31 19:21:52 2003 From: dave@hiauly3.hia.nrc.ca (John David Anglin) Date: Sun, 31 Aug 2003 14:21:52 -0400 (EDT) Subject: [parisc-linux] Re: [glibc] tststatic failues, reduced to simp le testcase. In-Reply-To: <20030831153837.GJ5194@systemhalted> from Carlos O'Donell at Aug "31," 2003 "11:38:38" am Message-ID: <200308311821.OAA04520@hiauly3.hia.nrc.ca> > > I don't fully understand this code but possibly PT_GR20 might be used > > to save r2. In the fork call for example, we know that this location > > contains __NR_fork. This value gets restored to r20 in wrapper_exit. > > I think the valued saved above is loaded into r2 here: > > So you say perhaps instead of PT_GR19 we use PT_GR20 and > TASK_PT_GR20? I think we can't though, because tracing the syscall > requires that GR20 continue to retain the syscall value. I think we can > use _any_ other caller-saves registers (including the last input for the > fork-ish calls e.g. GR21 or GR22?). Isn't the restoration of the value in wrapper_exit enough or is strace looking in the task struct? > Me neither. Perhaps it's superfluous and can be used to retrieve r2 and > thus keep r19 safe. It's worth a try. > > If a syscall is going to clobber registers, the appropriate clobbers > > need to be added to the asm used for the syscall so that gcc doesn't > > try to use these registers over the syscall. Use of PT_GR19 appears > > to have been a bad choice because of its special use in pic code. > > I've added all the caller-saves registers to our clobber lists when > making syscalls. Though, r19 being special, I've had to add "STW_PIC" > and "LDW_PIC" that do the saving and restore _only_ if we are compiled > PIC. That seems overly pessimistic and will mean a lot more register saves in routines that do syscalls. It appears the system saves the caller-save registers in all syscalls except the fork related calls. It would be best to keep the number of clobbers to a minimum. I wonder, there seems to be a slot in the task struct for r1, but it's never saved in a syscall, and r1 is clobbered. Maybe the r1 slot could be used to save r2. This might mean that we don't need to use GR21 or GR22 at all. It would avoid having to have special pic code. Dave From stian@soiland.no Sun Aug 31 19:23:34 2003 From: stian@soiland.no (Stian =?iso-8859-1?Q?S=F8iland?=) Date: Sun, 31 Aug 2003 20:23:34 +0200 Subject: [parisc-linux] [ron@rongage.org: [Patchbomb] - Copy_to/from_user audit - oss4 - RESEND] In-Reply-To: <20030831153957.GX13467@parcelfarce.linux.theplanet.co.uk> References: <20030831153957.GX13467@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030831182334.GA21964@itea.ntnu.no> On 2003-08-31 17:39:57, Matthew Wilcox wrote: What's the deal with this [subject] [fubar] [thingie]? :=3D) I'm getting confused and I need to resize my terminal to like 300x24 to read this.. --=20 Stian S=F8iland Work toward win-win situation. Win-lose Trondheim, Norway is where you win and the other lose. http://www.soiland.no/ Lose-lose and lose-win are left as an exercise to the reader. [Limoncelli/Hogan] From Randolph Chung Sun Aug 31 19:56:49 2003 From: Randolph Chung (Randolph Chung) Date: Sun, 31 Aug 2003 11:56:49 -0700 Subject: [parisc-linux] [ron@rongage.org: [Patchbomb] - Copy_to/from_user audit - parisc -RESEND] In-Reply-To: <20030831154210.GY13467@parcelfarce.linux.theplanet.co.uk> References: <20030831154210.GY13467@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030831185649.GI10510@tausq.org> > This patch catches insures proper return values from > copy_to/from_user calls. um, some of these are not quite correct. > +++ linux-2.6.0-test4-patched/arch/parisc/kernel/signal32.c 2003-08-29 21:38:02.000000000 -0400 > @@ -38,7 +38,7 @@ > if (sz != sizeof *set) panic("put_sigset32()"); > sigset_64to32(&s, set); > > - return copy_to_user(up, &s, sizeof s); > + return copy_to_user(up, &s, sizeof s) ? -EFAULT : 0 ; > } this one is for put_sigset32, which is used like this: if (!ret && oset && put_sigset32(oset, &old_set, sigsetsize)) return -EFAULT; so your patch is not needed. > --- linux-2.6.0-test4/arch/parisc/kernel/sys_parisc32.c 2003-08-22 19:54:17.000000000 -0400 > +++ linux-2.6.0-test4-patched/arch/parisc/kernel/sys_parisc32.c 2003-08-29 21:36:59.000000000 -0400 > @@ -370,7 +370,7 @@ > struct compat_timeval t32; > t32.tv_sec = t->tv_sec; > t32.tv_usec = t->tv_usec; > - return copy_to_user(u, &t32, sizeof t32); > + return copy_to_user(u, &t32, sizeof t32) ? -EFAULT : 0 ; > } this one is similar. > static int > diff -urN linux-2.6.0-test4/arch/parisc/kernel/sys_parisc.c linux-2.6.0-test4-patched/arch/parisc/kernel/sys_parisc.c > --- linux-2.6.0-test4/arch/parisc/kernel/sys_parisc.c 2003-08-22 19:59:03.000000000 -0400 > +++ linux-2.6.0-test4-patched/arch/parisc/kernel/sys_parisc.c 2003-08-29 21:36:06.000000000 -0400 > @@ -271,7 +271,7 @@ > tbuf.shm_cpid = sbuf->shm_cpid; > tbuf.shm_lpid = sbuf->shm_lpid; > tbuf.shm_nattch = sbuf->shm_nattch; > - return copy_to_user(buf, &tbuf, sizeof tbuf); > + return copy_to_user(buf, &tbuf, sizeof tbuf) ? -EFAULT : 0; > } > > int sys_msgctl_broken(int msqid, int cmd, struct msqid_ds *buf) this one seems correct. i'll apply it to the parisc tree. thx randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From dave@hiauly3.hia.nrc.ca Sun Aug 31 20:10:23 2003 From: dave@hiauly3.hia.nrc.ca (John David Anglin) Date: Sun, 31 Aug 2003 15:10:23 -0400 (EDT) Subject: [parisc-linux] Re: [glibc] tststatic failues, reduced to simp le testcase. In-Reply-To: from dave at Aug "31," 2003 "02:21:52" pm Message-ID: <200308311910.PAA04875@hiauly3.hia.nrc.ca> > > I've added all the caller-saves registers to our clobber lists when > > making syscalls. Though, r19 being special, I've had to add "STW_PIC" > > and "LDW_PIC" that do the saving and restore _only_ if we are compiled > > PIC. > > That seems overly pessimistic and will mean a lot more register saves > in routines that do syscalls. It appears the system saves the caller-save > registers in all syscalls except the fork related calls. It would > be best to keep the number of clobbers to a minimum. I wonder, there > seems to be a slot in the task struct for r1, but it's never saved in > a syscall, and r1 is clobbered. Maybe the r1 slot could be used to save > r2. This might mean that we don't need to use GR21 or GR22 at all. > It would avoid having to have special pic code. Another possibility might be to define another couple of offsets in the task struct. It looks as if there is plenty of space before an alignment boundary is reached. From carlos@baldric.uwo.ca Sun Aug 31 21:22:03 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Sun, 31 Aug 2003 16:22:03 -0400 Subject: [parisc-linux] Re: [glibc] tststatic failues, reduced to simp le testcase. In-Reply-To: <200308311910.PAA04875@hiauly3.hia.nrc.ca> References: <200308311910.PAA04875@hiauly3.hia.nrc.ca> Message-ID: <20030831202203.GN5194@systemhalted> > Another possibility might be to define another couple of offsets in the > task struct. It looks as if there is plenty of space before an alignment > boundary is reached. That seems best. The sad fact though is that until I bump min_kernel_version in glibc past the kernel version that last didn't have this fix, I'm still forced to implement all this for people with older kernels. c. From dave@hiauly3.hia.nrc.ca Sun Aug 31 21:47:59 2003 From: dave@hiauly3.hia.nrc.ca (John David Anglin) Date: Sun, 31 Aug 2003 16:47:59 -0400 (EDT) Subject: [parisc-linux] Re: [glibc] tststatic failues, reduced to simp le testcase. In-Reply-To: <20030831202203.GN5194@systemhalted> from Carlos O'Donell at Aug "31," 2003 "04:22:03" pm Message-ID: <200308312047.QAA05245@hiauly3.hia.nrc.ca> > That seems best. The sad fact though is that until I bump > min_kernel_version in glibc past the kernel version that last didn't > have this fix, I'm still forced to implement all this for people with > older kernels. Why? Things are broken now and people have lived with the bug for sometime. While it is possible to work around the problem in userspace, the best fix is to do it in the kernel. I wouldn't fix anything but a regression. Dave