From grundler@parisc-linux.org Thu May 1 05:09:31 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 30 Apr 2003 22:09:31 -0600 Subject: [parisc-linux] Program counter from sigcontext, constructurs and -fPIC In-Reply-To: <75A9FEBA25015040A761C1F74975667D01442066@hplex4.hpl.hp.com> References: <75A9FEBA25015040A761C1F74975667D01442066@hplex4.hpl.hp.com> Message-ID: <20030501040931.GA21495@dsl2.external.hp.com> On Tue, Apr 29, 2003 at 02:17:32PM -0700, Boehm, Hans wrote: > 3) Adding 24 bytes to the struct sigcontext pointer (?) passed > as a third argument to the signal handler. (!) ... > Is the third argument to a signal handler really not a pointer to sigcontext? Yes - that seems to be the case. Randolph found most of the answer in "Single Unix Specification" (IEEE 1033.1-2001). Third argument is "ucontext_t". We counted 20 bytes (not 24) before the "struct sigcontext uc_mcontext;" and thus still don't have a full explanation. Our best guess is some misc padding is involved. hth, grant From wrx@hispeed.ch Fri May 2 09:38:27 2003 From: wrx@hispeed.ch (WRX-Tuning) Date: Fri, 2 May 2003 10:38:27 +0200 Subject: [parisc-linux] Video card Message-ID: <000801c31086$34888490$0d0da2d9@tango> This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C31096.F754E260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I've installed the Debian PA-Risc in a C360 HP Desktop. I have problem with my video card, at the end when i type startx, come = the message"fatal error, no screens found". Can You please help me how can i let it work? I'm new in this operating system, please write me down what step's and = how i must do. Thank You a lot for helping. Giovanni p.s i've search for helping, i found something but i'don't understand = how to edit (what comands) the XF86Config file. ------=_NextPart_000_0005_01C31096.F754E260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
I've installed the Debian PA-Risc in a = C360 HP=20 Desktop.
I have problem with my video card, at = the end when=20 i type startx, come the message"fatal error, no screens = found".
Can You please help me how can i let it = work?
 
I'm new in this operating system, = please write me=20 down what step's and how i must do.
 
Thank You a lot for = helping.
 
Giovanni
 
p.s i've search for helping, i found = something but=20 i'don't understand how to edit (what comands) the XF86Config=20 file.
------=_NextPart_000_0005_01C31096.F754E260-- From Jurriaan.Kalkman@zrt.nl Thu May 1 10:55:16 2003 From: Jurriaan.Kalkman@zrt.nl (Jurriaan Kalkman) Date: Thu, 01 May 2003 11:55:16 +0200 Subject: Betr.: [parisc-linux] Video card Message-ID: >Hello, > >I've installed the Debian PA-Risc in a C360 HP Desktop. >I have problem with my video card, at the end when i type startx, come = the message"fatal error, no screens found". >Can You please help me how can i let it work? > >I'm new in this operating system, please write me down what step's and = how i must do. > It's in the archives for this mailinglist. Also, with this kind of error, = the exact model of the videocard is important, and you don't mention it. >Thank You a lot for helping. > >Giovanni > >p.s i've search for helping, i found something but i'don't understand how = to edit (what comands) the XF86Config file. If you don't know how to edit a file, may I politely suggest not starting with linux on the PA-RISC architecture? It's one of the faster-moving linux-versions, where not everything is expected to work, and some work (ie searching the archives) is to be expected. Perhaps a nice Knoppix-cd on a regular x86 PC would be better to start with? Your experience with Linux will certainly be more to your liking then. Kind regards, Jurriaan From chris-parisc@maybe.net Sat May 3 02:23:47 2003 From: chris-parisc@maybe.net (Chris Jantzen) Date: Fri, 2 May 2003 18:23:47 -0700 Subject: [parisc-linux] (OT-ish): c180 drive rails? Message-ID: <20030503012347.GD18048@maybe.net> Slightly off-topic: I came across a perfect match for the 4GB HVD Seagate already in my C180, but don't have any rails. Wondered if anybody here knew a good place, or had some lying around. -- chris jantzen kb7rnl =-> __O Insert witty comment here. _`\<,_ http://www.maybe.net/ (*)/ (*) From eric@cirr.com Sat May 3 04:25:45 2003 From: eric@cirr.com (Eric Schnoebelen) Date: Fri, 02 May 2003 22:25:45 -0500 Subject: [parisc-linux] (OT-ish): c180 drive rails? In-Reply-To: Your message of "Fri, 02 May 2003 18:23:47 PDT." <20030503012347.GD18048@maybe.net> Message-ID: <200305030325.h433Pjd12573@egsner.cirr.com> Chris Jantzen writes: - Slightly off-topic: I came across a perfect match for the 4GB HVD - Seagate already in my C180, but don't have any rails. Wondered if - anybody here knew a good place, or had some lying around. They are still available from HP, if you can find a co-operative SE or FE to order them for you.. (They were listed in partsdirect.hp.com at one point, but when I ordered them, they went on backorder, and I had to call to find out why.. :-() -- Eric Schnoebelen eric@cirr.com http://www.cirr.com Life is hard but the root password helps. - seen on the misc@ OpenBSD mailing list From derekengelhaupt@rocketmail.com Sat May 3 04:44:33 2003 From: derekengelhaupt@rocketmail.com (Derek Engelhaupt) Date: Fri, 2 May 2003 20:44:33 -0700 (PDT) Subject: [parisc-linux] (OT-ish): c180 drive rails? In-Reply-To: <200305030325.h433Pjd12573@egsner.cirr.com> Message-ID: <20030503034433.96180.qmail@web12503.mail.yahoo.com> --0-540082675-1051933473=:96153 Content-Type: text/plain; charset=us-ascii They are out on Ebay all the time, but none up right now that I can find. derek Eric Schnoebelen wrote: Chris Jantzen writes: - Slightly off-topic: I came across a perfect match for the 4GB HVD - Seagate already in my C180, but don't have any rails. Wondered if - anybody here knew a good place, or had some lying around. They are still available from HP, if you can find a co-operative SE or FE to order them for you.. (They were listed in partsdirect.hp.com at one point, but when I ordered them, they went on backorder, and I had to call to find out why.. :-() -- Eric Schnoebelen eric@cirr.com http://www.cirr.com Life is hard but the root password helps. - seen on the misc@ OpenBSD mailing list _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux --------------------------------- Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. --0-540082675-1051933473=:96153 Content-Type: text/html; charset=us-ascii
They are out on Ebay all the time, but none up right now that I can find.
 
derek

Eric Schnoebelen <eric@cirr.com> wrote:

Chris Jantzen writes:
- Slightly off-topic: I came across a perfect match for the 4GB HVD
- Seagate already in my C180, but don't have any rails. Wondered if
- anybody here knew a good place, or had some lying around.

They are still available from HP, if you can find a
co-operative SE or FE to order them for you.. (They were listed
in partsdirect.hp.com at one point, but when I ordered them,
they went on backorder, and I had to call to find out why.. :-()

--
Eric Schnoebelen eric@cirr.com http://www.cirr.com
Life is hard but the root password helps.
- seen on the misc@ OpenBSD mailing list
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo. --0-540082675-1051933473=:96153-- From joel.soete@tiscali.be Sat May 3 21:48:32 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Sat, 03 May 2003 20:48:32 +0000 Subject: [parisc-linux] Program counter from sigcontext, constructurs and -fPIC In-Reply-To: <20030430181216.GA20779@systemhalted> References: <20030430003106.GC12492@systemhalted> <3EA9466400001A95@ocpmta7.freegates.net> <20030430181216.GA20779@systemhalted> Message-ID: <3EB42B20.1010504@tiscali.be> Carlos O'Donell wrote: >>>Don't touch -17, the _Unwind_Find_FDE code broke and it's doing damage >>>to things like 'vi' ... *sigh* I haven't even looked into this (looks >>>like gcc/glibc clashes again). >>> >>> >>> >>Umm could this be why that my b2k crashed when compiling a kernel to test >>a patch? >> >> > >Quite possibly. If you can get a backtrace of the crash you'll se it die >inside _Unwind_Find_FDE in glibc. > I couldn't anymore check because unfortunately even after comming back to libc6 sub debian release -16 my b2k crashes severall times. The last time was badly in the middle of a apt-get dist-upgrade; this crash corrupt the root fs so that it isn't any more usable. I will try to recover it asap to check. That said, I suspect more another hw pb (it is not the first time with this b2k model on which hp had already have to replace the cpu) or a bug into cd-ide driver (this is the only model I had the chance to test with this kind of feature). > >I'm working on fixing this. > > > Thanks for your attention, Joel From tom@alaskatech.org Sun May 4 04:54:57 2003 From: tom@alaskatech.org (Tom) Date: Sat, 03 May 2003 19:54:57 -0800 Subject: [parisc-linux] {kinda OT] A4947A applicability? and FC driver work Message-ID: <1052020498.27841.7.camel@daily> I found one of these kits on eBay - C200 to C240 upgrade, CPU on mainboard. Do any of the HP techs around here know if it'll also fit a C180? It'd be nice to drop a large performance upgrade into it for not much cash... Also, after the thread on fiber-card drivers, I realized my C180 has a fiber card in it. It's completely unused - if someone could use it in an attempt to further driver support I'd happily donate it... As soon as I get a chance to shut it down and tear it open I'll pull the part # off of it... From willy@debian.org Sun May 4 05:17:15 2003 From: willy@debian.org (Matthew Wilcox) Date: Sun, 4 May 2003 05:17:15 +0100 Subject: [parisc-linux] {kinda OT] A4947A applicability? and FC driver work In-Reply-To: <1052020498.27841.7.camel@daily> References: <1052020498.27841.7.camel@daily> Message-ID: <20030504041715.GH31610@parcelfarce.linux.theplanet.co.uk> On Sat, May 03, 2003 at 07:54:57PM -0800, Tom wrote: > I found one of these kits on eBay - C200 to C240 upgrade, CPU on > mainboard. Do any of the HP techs around here know if it'll also fit a > C180? It'd be nice to drop a large performance upgrade into it for not > much cash... Well... it'll _fit_. Whether firmware will work properly is anyone's guess. There's various differences between the C180 and C200 that make this combination not sure to succeed. My personal opinion (and not speaking on behalf of my emplyer) is that it's going to work 90%. Maybe the onboard scsi controller won't be initialised properly. Maybe the missing bit of init won't make any difference to Linux or maybe it'll start corrupting data. It's a bit of a gamble. -- "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 b.gunreben@web.de Sun May 4 13:25:05 2003 From: b.gunreben@web.de (Berthold Gunreben) Date: Sun, 4 May 2003 14:25:05 +0200 Subject: [parisc-linux] {kinda OT] A4947A applicability? and FC driver work In-Reply-To: <20030504041715.GH31610@parcelfarce.linux.theplanet.co.uk> References: <1052020498.27841.7.camel@daily> <20030504041715.GH31610@parcelfarce.linux.theplanet.co.uk> Message-ID: <200305041008.49439.b.gunreben@web.de> Am Sonntag, 4. Mai 2003 06:17 schrieb Matthew Wilcox: > On Sat, May 03, 2003 at 07:54:57PM -0800, Tom wrote: > > I found one of these kits on eBay - C200 to C240 upgrade, CPU on > > mainboard. Do any of the HP techs around here know if it'll also fit a > > C180? It'd be nice to drop a large performance upgrade into it for not > > much cash... > > Well... it'll _fit_. Whether firmware will work properly is anyone's > guess. There's various differences between the C180 and C200 that > make this combination not sure to succeed. My personal opinion (and > not speaking on behalf of my emplyer) is that it's going to work 90%. I don=B4t think you will be very happy with it. One of the bigger problems = will=20 be your power supply. The C240 has a much stronger power supply (at least t= he=20 one that I have) than the C180.=20 > Maybe the onboard scsi controller won't be initialised properly. > Maybe the missing bit of init won't make any difference to Linux or > maybe it'll start corrupting data. It's a bit of a gamble. From derekengelhaupt@rocketmail.com Sun May 4 17:15:33 2003 From: derekengelhaupt@rocketmail.com (Derek Engelhaupt) Date: Sun, 4 May 2003 09:15:33 -0700 (PDT) Subject: [parisc-linux] {kinda OT] A4947A applicability? and FC driver work In-Reply-To: <200305041008.49439.b.gunreben@web.de> Message-ID: <20030504161533.44634.qmail@web12501.mail.yahoo.com> --0-177053345-1052064933=:44529 Content-Type: text/plain; charset=us-ascii You are also going to have a problem with the serial number, product number, and software ID on the board. They have to be set in the EEPROM of the new board and only an HP engineer can program those item in the new board. The program we use to set those items is not licensed to anyone, including channel partners that fix some of our workstations. Without these items set the machine may complete selftest, but will not boot. More than likely it will complain at the BCH about not having a valid serial number or SWID. They are right about the power supply too, the C240 has a bigger power supply. The I/O backplane on the C240 is WSE and not HVD like the C180. I really think you would have problems trying to do this upgrade yourself. The memory would transfer over even though the C200-C360 use a 50ns memory and the C110-C180 use 60ns memery. derek Berthold Gunreben wrote:Am Sonntag, 4. Mai 2003 06:17 schrieb Matthew Wilcox: > On Sat, May 03, 2003 at 07:54:57PM -0800, Tom wrote: > > I found one of these kits on eBay - C200 to C240 upgrade, CPU on > > mainboard. Do any of the HP techs around here know if it'll also fit a > > C180? It'd be nice to drop a large performance upgrade into it for not > > much cash... > > Well... it'll _fit_. Whether firmware will work properly is anyone's > guess. There's various differences between the C180 and C200 that > make this combination not sure to succeed. My personal opinion (and > not speaking on behalf of my emplyer) is that it's going to work 90%. I don´t think you will be very happy with it. One of the bigger problems will be your power supply. The C240 has a much stronger power supply (at least the one that I have) than the C180. > Maybe the onboard scsi controller won't be initialised properly. > Maybe the missing bit of init won't make any difference to Linux or > maybe it'll start corrupting data. It's a bit of a gamble. _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux --------------------------------- Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. --0-177053345-1052064933=:44529 Content-Type: text/html; charset=us-ascii
You are also going to have a problem with the serial number, product number, and software ID on the board.  They have to be set in the EEPROM of the new board and only an HP engineer can program those item in the new board.  The program we use to set those items is not licensed to anyone, including channel partners that fix some of our workstations.  Without these items set the machine may complete selftest, but will not boot.  More than likely it will complain at the BCH about not having a valid serial number or SWID.  They are right about the power supply too, the C240 has a bigger power supply.  The I/O backplane on the C240 is WSE and not HVD like the C180.  I really think you would have problems trying to do this upgrade yourself.  The memory would transfer over even though the C200-C360 use a 50ns memory and the C110-C180 use 60ns memery.
 
derek

Berthold Gunreben <b.gunreben@web.de> wrote:
Am Sonntag, 4. Mai 2003 06:17 schrieb Matthew Wilcox:
> On Sat, May 03, 2003 at 07:54:57PM -0800, Tom wrote:
> > I found one of these kits on eBay - C200 to C240 upgrade, CPU on
> > mainboard. Do any of the HP techs around here know if it'll also fit a
> > C180? It'd be nice to drop a large performance upgrade into it for not
> > much cash...
>
> Well... it'll _fit_. Whether firmware will work properly is anyone's
> guess. There's various differences between the C180 and C200 that
> make this combination not sure to succeed. My personal opinion (and
> not speaking on behalf of my emplyer) is that it's going to work 90%.

I don´t think you will be very happy with it. One of the bigger problems will
be your power supply. The C240 has a much stronger power supply (at least the
one that I have) than the C180.

> Maybe the onboard scsi controller won't be initialised properly.
> Maybe the missing bit of init won't make any difference to Linux or
> maybe it'll start corrupting data. It's a bit of a gamble.

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

Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo. --0-177053345-1052064933=:44529-- From caslivkoff@speakeasy.net Sun May 4 17:43:40 2003 From: caslivkoff@speakeasy.net (Chuck Slivkoff) Date: Sun, 04 May 2003 12:43:40 -0400 Subject: [parisc-linux] {kinda OT] A4947A applicability? and FC driver work In-Reply-To: <200305041008.49439.b.gunreben@web.de> References: <1052020498.27841.7.camel@daily> <20030504041715.GH31610@parcelfarce.linux.theplanet.co.uk> <200305041008.49439.b.gunreben@web.de> Message-ID: <3EB5433C.7020207@speakeasy.net> This is a multi-part message in MIME format. --------------040800080004010803000507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Berthold Gunreben wrote: >Am Sonntag, 4. Mai 2003 06:17 schrieb Matthew Wilcox: > =20 > >>On Sat, May 03, 2003 at 07:54:57PM -0800, Tom wrote: >> =20 >> >>>I found one of these kits on eBay - C200 to C240 upgrade, CPU on >>>mainboard. Do any of the HP techs around here know if it'll also fit a= >>>C180? It'd be nice to drop a large performance upgrade into it for not= >>>much cash... >>> If you can navigate your was through docs.hp.com, you can find these=20 manuals (PDF): installing the hp Visualize workstation c100, c110, c160, c180 to=20 c200 CPU upgrade (a4200-900xx) installing the hp Visualize workstation c200 to c240 CPU upgrade=20 (a4200-90035) at this excessively long URL: http://h20000.www2.hp.com/bizsupport/TechSupport/DocumentIndex.jsp? contentType=3DSupportManual&locale=3Den_US&prodTypeId=3D12454& prodSeriesId=3D76204&taskId=3D130&prodSeriesId=3D76204&docIndexId=3D120= 917 >>Well... it'll _fit_. Whether firmware will work properly is anyone's >>guess. There's various differences between the C180 and C200 that >>make this combination not sure to succeed. My personal opinion (and >>not speaking on behalf of my emplyer) is that it's going to work 90%. >> =20 >> > >I don=B4t think you will be very happy with it. One of the bigger proble= ms will=20 >be your power supply. The C240 has a much stronger power supply (at leas= t the=20 >one that I have) than the C180.=20 > IIRC, the main reason for the larger power supply in the C200 (& up) was = to support the Visualize FX-6 graphics interface (which has 3=20 PA-8000-based geometry engines & is not supported under Linux). I=20 believe the board will fit and as long as the power connections are the=20 same, it will probably work. But, there may still be hooks in the=20 firmware to detect the larger power supply. I might know someone who can = answer this, but it would probably take a few days. BTW, the service manual for the C-xxx models are available on that same U= RL. --------------040800080004010803000507 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Berthold Gunreben wrote:
Am Sonntag, 4. Mai 2003 06:17 schrieb Matthew Wilcox:
  
On Sat, May 03, 2003 at 07:54:57PM -0800, Tom wrote:
    
I found one of these kits on eBay - C200 to C240 upgrade, CPU on
mainboard. Do any of the HP techs around here know if it'll also fit a
C180? It'd be nice to drop a large performance upgrade into it for not
much cash...
If you can navigate your was through docs.hp.com, you can find these manuals (PDF):

    installing the hp Visualize workstation c100, c110, c160, c180 to c200 CPU upgrade (a4200-900xx)
    installing the hp Visualize workstation c200 to c240 CPU upgrade (a4200-90035)

at this excessively long URL:

  http://h20000.www2.hp.com/bizsupport/TechSupport/DocumentIndex.jsp?
  contentType=SupportManual&locale=en_US&prodTypeId=12454&
  prodSeriesId=76204&taskId=130&prodSeriesId=76204&docIndexId=120917

Well... it'll _fit_.  Whether firmware will work properly is anyone's
guess. There's various differences between the C180 and C200 that
make this combination not sure to succeed.  My personal opinion (and
not speaking on behalf of my emplyer) is that it's going to work 90%.
    

I don´t think you will be very happy with it. One of the bigger problems will 
be your power supply. The C240 has a much stronger power supply (at least the 
one that I have) than the C180.
IIRC, the main reason for the larger power supply in the C200 (& up) was to support the Visualize FX-6 graphics interface (which has 3 PA-8000-based geometry engines & is not supported under Linux). I believe the board will fit and as long as the power connections are the same, it will probably work. But, there may still be hooks in the firmware to detect the larger power supply. I might know someone who can answer this, but it would probably take a few days.

BTW, the service manual for the C-xxx models are available on that same URL.


--------------040800080004010803000507-- From sam@dsl2.external.hp.com Mon May 5 04:21:56 2003 From: sam@dsl2.external.hp.com (sam) Date: Mon, 05 May 2003 11:21:56 +0800 Subject: [parisc-linux] Sell NI-MH battery Message-ID: <20030505031955.69E8E483C@dsl2.external.hp.com> This is a multi-part message in MIME format --873aec25-0dcf-4335-a517-6e8c017c0b01 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Dear All We can provide all kinds of NI-MH battery for you .Shenzhen High Power = Technology CO., Ltd specializes in designing, manufacturing and marketing = environment-friendly rechargeable battery-----Nickel Metal Hydride (Ni-MH) = battery which is widely used in mobile phone, digital camera,cordless phone, = R/C toys, emergency light, MP3 players, PDAs,power tools etc. Type Model Size capacity (mAh) A HFR-28A1000 2/3A 1000 HFR-43A1700 4/5A 1700 HFR-43A1800 4/5A 1800 HFR-50A2000 A 2000 HFR-50A2200 A 2200 HFR-67A2800 7/5A 2800 HFR-67A3300 7/5A 3300 AA HFR-28AA650 2/3AA 650 HFR-28AA750 2/3AA 750 HFR-43AA1100 4/5AA 1100 HFR-43AA1200 4/5AA 1200 HFR-49AA1300 AA 1300 HFR-49AA1500 AA 1500 HFR-50AAJ1600 AA 1600 HFR-50AAJ1800 AA 1800 HFR-50AAJ2000 AA 2000 AAA HFR-11AAA80 1/4AAA 80 HFR-15AAA120 1/3AAA 120 HFR-20AAA200 1/2AAA 200 HFR-28AAA300 2/3AAA 300 HFR-35AAA400 4/5AAA 400 HFR-43AAA600 AAA 600 HFR-44AAAJ650 AAA 650 HFR-44AAA650 AAA 650 HFR-50AAA700 L-AAA 700 HFR-50AAA750 L-AAA 750 HFR-67AAA900 LL-AAA 900 HFR-67AAA950 LL-AAA 950 AAAA HFR-38AAAA270 38AAAA 270 HFR-51AAAA400 51AAAA 400 HFR-66AAAA550 66AAAA 550 SC HFR-43SC3000 SC 3000 C HFR-50C4000 C 4000 D HFR-60D8000 D 8000 F HFR-90F11000 F 11000 Prismatic Cell Series HF HFR-29F4-400 29F4-400 400 HFR-35F5-500 35F5-500 500 HFR-35JF5-700 35JF5-700 700 HFR-39JF5-850 39JF5-850 850 HFR-48F6-750 48F6-750 750 HFR-67F8-1100 67F8-1100 1100 More information please visit our website : http://www.haopengbattery.com we accept OEM/ODM .Thanks & very much . This is a automatic mail system if It interrupt I am sorry . and please = cancel it . Best regards Sam Website : http://www.haopengbattery.com E-mail : samwei@vip.sina.com Shenzhen High Power Technology CO., Ltd ADD=A3=BABldg A2,Luoshan Industrial = Zone,Shanxia,Pinghu,Longgang,Shenzhen,Guangdong,China. TEL=A3=BA(86 755)84652098 84652068 84652238 FAX=A3=BA(86 755)84651866 = 84652298 ---------------------------------------------------- DEMO=B0=E6=B1=BE=B7=A2=CB=CD ---------------------------------------------------- --873aec25-0dcf-4335-a517-6e8c017c0b01-- From jsoe0708@tiscali.be Mon May 5 07:08:53 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Mon, 5 May 2003 08:08:53 +0200 Subject: [parisc-linux] Program counter from sigcontext, constructurs and -fPIC In-Reply-To: <3EB42B20.1010504@tiscali.be> Message-ID: <3EA84287000032CA@ocpmta2.freegates.net> Hi Carlos, > >That said, I suspect more another hw pb (it is not the first time with >this b2k model on which hp had already have to replace the cpu) or a bug > Definitely it must be a HW pb: I read back the very last pim info that I grab with minicom I find: ... Memory/IO Controller Error Analysis Information: Occurs ... Runway Addr = 0xc13ff0 f0f000cd0a ... Even thought this messages seems to be OS independant (PDC only IMHO?), I will so come back to hpux with the hope that pb re-occurs and that I can open a HW call neer HP. Regards, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From bruno_vidal@hpfrcu03.france.hp.com Mon May 5 12:07:57 2003 From: bruno_vidal@hpfrcu03.france.hp.com (Bruno Vidal) Date: Mon, 05 May 2003 13:07:57 +0200 Subject: [parisc-linux] dump module: new feature Message-ID: <3EB6460D.6040704@admin.france.hp.com> Hi For people who are intersting to it, the dump modules is now checking that it is a swap device before configuring it. So it remove the risk to dump to a file system. It check for the swap magic "SWAP-SPACE" (v0) or "SWAPSPACE2" (v1). The partition is not necessary an active one, it should only be created by mkswap (so no file system on it). Cheers. -- Vidal Bruno, (770-4271) SSD-HA Team, HP-UX & LINUX Support bruno_vidal@admin.france.hp.com From jbglaw@lug-owl.de Mon May 5 21:02:51 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Mon, 5 May 2003 22:02:51 +0200 Subject: [parisc-linux] Oops on 2.4.20-pa33 Message-ID: <20030505200251.GS27494@lug-owl.de> --GFHULmA0mO3kKGOo Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I've tried to compile/boot current 2.4.x CVS, but it Oopsed. I noted down what looked really important (this is, IAOQ, r02 and kernel addresses from stack). This is what I resolved out of System.map: IAOQ: 10224658 __canonicalize_funcptr_for_compare r02: 101229d4 do_sigaction Kernel addresses on stack: 1013a278 dentry_open 10131a38 __kmem_cache_alloc 101229d4 do_sigaction 10102a9c handle_interruption 10122dc8 sys_rt_sigaction 10107f90 syscall_exit 10107084 intr_check_sig 10106cf4 _switch_to_ret 1013be10 chrdev_open 1013a278 dentry_open 1014aba8 locate_fd 1011b530 it_real_fn Seems I cannot really find it:) b132l-1:~# gcc -v Reading specs from /usr/lib/gcc-lib/hppa-linux/3.2.3/specs Configured with: ../src/configure -v --enable-languages=3Dc,c++,f77,objc,ad= a --prefix=3D/usr --mandir=3D/usr/share/man --infodir=3D/usr/share/info --w= ith-gxx-include-dir=3D/usr/include/c++/3.2 --enable-shared --with-system-zl= ib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-c= locale=3Dgnu --enable-objc-gc hppa-linux Thread model: posix gcc version 3.2.3 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)); --GFHULmA0mO3kKGOo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+tsNrHb1edYOZ4bsRAiNHAKCHWuD74ISfWCcK0oGVJqP1Vdfw7wCePNFu MMsphhbTmuZKURinL8jIt3M= =fJVe -----END PGP SIGNATURE----- --GFHULmA0mO3kKGOo-- From dave@hiauly1.hia.nrc.ca Mon May 5 21:10:41 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Mon, 5 May 2003 16:10:41 -0400 (EDT) Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <20030505200251.GS27494@lug-owl.de> from "Jan-Benedict Glaw" at May 5, 2003 10:02:51 pm Message-ID: <200305052010.h45KAgos029626@hiauly1.hia.nrc.ca> > I've tried to compile/boot current 2.4.x CVS, but it Oopsed. I noted > down what looked really important (this is, IAOQ, r02 and kernel > addresses from stack). This is what I resolved out of System.map: > > IAOQ: 10224658 __canonicalize_funcptr_for_compare > r02: 101229d4 do_sigaction The fix for this was discussed on the list previously. There needs to be some "void *" casts added to various function pointer comparisons. Search on the above functions to find the thread. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From Randolph Chung Mon May 5 21:05:37 2003 From: Randolph Chung (Randolph Chung) Date: Mon, 5 May 2003 13:05:37 -0700 Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <20030505200251.GS27494@lug-owl.de> References: <20030505200251.GS27494@lug-owl.de> Message-ID: <20030505200537.GF29544@tausq.org> --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > IAOQ: 10224658 __canonicalize_funcptr_for_compare > r02: 101229d4 do_sigaction i don't have a 32-bit machine handy, can you try this patch and let me know if it fixes your problem? An earlier version of this was posted on this list but didn't get commited. thx -randolph Index: arch/parisc/kernel/signal.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux/arch/parisc/kernel/signal.c,v retrieving revision 1.43 diff -u -p -r1.43 signal.c --- arch/parisc/kernel/signal.c 4 Aug 2002 22:57:47 -0000 1.43 +++ arch/parisc/kernel/signal.c 5 May 2003 20:08:55 -0000 @@ -489,7 +489,7 @@ do_signal(sigset_t *oldset, struct pt_re ka =3D ¤t->sig->action[signr-1]; DBG(("sa_handler is %x\n",=20 (unsigned int) ka->sa.sa_handler)); - if (ka->sa.sa_handler =3D=3D SIG_IGN) { + if (ka->sa.sa_handler =3D=3D (void *)SIG_IGN) { if (signr !=3D SIGCHLD) continue; while (sys_wait4(-1, NULL, WNOHANG, NULL) > 0) @@ -497,7 +497,7 @@ do_signal(sigset_t *oldset, struct pt_re continue; } =20 - if (ka->sa.sa_handler =3D=3D SIG_DFL) { + if (ka->sa.sa_handler =3D=3D (void *)SIG_DFL) { int exit_code =3D signr; =20 /* Init gets no signals it doesn't want. */ --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+tsQRULspdC1Zp9IRAsDrAKCv30wrB19M3YwIm7tXWk6IFq7DOACfVAYS MvFEjrUBE3USA3K9tUhg/o8= =F6E3 -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From jbglaw@lug-owl.de Mon May 5 22:05:32 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Mon, 5 May 2003 23:05:32 +0200 Subject: [parisc-linux] [PATCH-2.4] DIVA serial build error (was: Oops on 2.4.20-pa33) In-Reply-To: <20030505200537.GF29544@tausq.org> References: <20030505200251.GS27494@lug-owl.de> <20030505200537.GF29544@tausq.org> Message-ID: <20030505210532.GU27494@lug-owl.de> --uUozbLrG2OP+gMtx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2003-05-05 13:05:37 -0700, Randolph Chung wrote in message <20030505200537.GF29544@tausq.org>: > > IAOQ: 10224658 __canonicalize_funcptr_for_compare > > r02: 101229d4 do_sigaction >=20 > i don't have a 32-bit machine handy, can you try this patch and let me > know if it fixes your problem? An earlier version of this was posted on > this list but didn't get commited. thx -randolph Oh, forgive me to be that read resistant:) I'm currently rebuilding the kernel. While doing so, I remembered I had to do a little compile fix. I'm not sure if it's correct, but at least, it builds: --- linux/drivers/char/serial.c.orig 2003-05-05 22:59:23.000000000 +0200 +++ linux/drivers/char/serial.c 2003-05-05 23:00:44.000000000 +0200 @@ -5836,10 +5836,10 @@ =20 /* printk("Unloading %s: version %s\n", serial_name, serial_version); */ del_timer_sync(&serial_timer); -#ifdef CONFIG_SERIAL_SHARE_IRQ +#ifdef CONFIG_HP_DIVA if (hp_diva_count > 0) del_timer_sync(&hp_diva_timer); -#endif /* CONFIG_SERIAL_SHARE_IRQ */ +#endif /* CONFIG_HP_DIVA */ save_flags(flags); cli(); remove_bh(SERIAL_BH); if ((e1 =3D tty_unregister_driver(&serial_driver))) 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)); --uUozbLrG2OP+gMtx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ttIcHb1edYOZ4bsRAlhpAJ9aVWdUM+QpDei7MDhBe/vkLzfKNQCfXBd7 Pbqa1joSawaCdFpPYBW197I= =a4BF -----END PGP SIGNATURE----- --uUozbLrG2OP+gMtx-- From jsoe0708@tiscali.be Tue May 6 07:04:03 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 6 May 2003 08:04:03 +0200 Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <20030505200537.GF29544@tausq.org> Message-ID: <3EB6425400000488@ocpmta7.freegates.net> Hi all, > >> IAOQ: 10224658 __canonicalize_funcptr_for_compare >> r02: 101229d4 do_sigaction > >i don't have a 32-bit machine handy, can you try this patch and let me >know if it fixes your problem? An earlier version of this was posted on >this list but didn't get commited. thx -randolph > >Index: arch/parisc/kernel/signal.c >=================================================================== >RCS file: /var/cvs/linux/arch/parisc/kernel/signal.c,v >retrieving revision 1.43 >diff -u -p -r1.43 signal.c >--- arch/parisc/kernel/signal.c 4 Aug 2002 22:57:47 -0000 1.43 >+++ arch/parisc/kernel/signal.c 5 May 2003 20:08:55 -0000 AFAIK here is the full patch I suggested after some mail exchanges with Dave: diff -Naur linux-2.4.20-pa32/arch/parisc/kernel/signal.c linux-2.4.20-pa32-gcc33/arch/parisc/kernel/signal.c --- linux-2.4.20-pa32/arch/parisc/kernel/signal.c 2003-03-21 10:54:23.000000000 +0100 +++ linux-2.4.20-pa32-gcc33/arch/parisc/kernel/signal.c 2003-03-21 12:39:20.000000000 +0100 @@ -489,7 +489,11 @@ ka = ¤t->sig->action[signr-1]; DBG(("sa_handler is %x\n", (unsigned int) ka->sa.sa_handler)); +#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) + if (ka->sa.sa_handler == (void *)SIG_IGN) { +#else if (ka->sa.sa_handler == SIG_IGN) { +#endif if (signr != SIGCHLD) continue; while (sys_wait4(-1, NULL, WNOHANG, NULL) > 0) @@ -497,7 +501,11 @@ continue; } +#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) + if (ka->sa.sa_handler == (void *)SIG_DFL) { +#else if (ka->sa.sa_handler == SIG_DFL) { +#endif int exit_code = signr; /* Init gets no signals it doesn't want. */ diff -Naur linux-2.4.20-pa32/drivers/char/n_tty.c linux-2.4.20-pa32-gcc33/drivers/char/n_tty.c --- linux-2.4.20-pa32/drivers/char/n_tty.c 2003-03-21 10:51:30.000000000 +0100 +++ linux-2.4.20-pa32-gcc33/drivers/char/n_tty.c 2003-03-21 12:34:35.000000000 +0100 @@ -810,7 +810,11 @@ int is_ignored(int sig) { return (sigismember(¤t->blocked, sig) || +#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) + current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN); +#else current->sig->action[sig-1].sa.sa_handler == SIG_IGN); +#endif } static void n_tty_set_termios(struct tty_struct *tty, struct termios * old) diff -Naur linux-2.4.20-pa32/fs/ncpfs/sock.c linux-2.4.20-pa32-gcc33/fs/ncpfs/sock.c --- linux-2.4.20-pa32/fs/ncpfs/sock.c 2003-03-21 10:36:05.000000000 +0100 +++ linux-2.4.20-pa32-gcc33/fs/ncpfs/sock.c 2003-03-21 12:35:37.000000000 +0100 @@ -466,9 +466,17 @@ What if we've blocked it ourselves? What about alarms? Why, in fact, are we mucking with the sigmask at all? -- r~ */ +#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) + if (current->sig->action[SIGINT - 1].sa.sa_handler == (void *)SIG_DFL) +#else if (current->sig->action[SIGINT - 1].sa.sa_handler == SIG_DFL) +#endif mask |= sigmask(SIGINT); +#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) + if (current->sig->action[SIGQUIT - 1].sa.sa_handler == (void *)SIG_DFL) +#else if (current->sig->action[SIGQUIT - 1].sa.sa_handler == SIG_DFL) +#endif mask |= sigmask(SIGQUIT); } siginitsetinv(¤t->blocked, mask); diff -Naur linux-2.4.20-pa32/fs/proc/array.c linux-2.4.20-pa32-gcc33/fs/proc/array.c --- linux-2.4.20-pa32/fs/proc/array.c 2003-03-21 10:01:18.000000000 +0100 +++ linux-2.4.20-pa32-gcc33/fs/proc/array.c 2003-03-21 12:36:44.000000000 +0100 @@ -231,9 +231,17 @@ if (p->sig) { k = p->sig->action; for (i = 1; i <= _NSIG; ++i, ++k) { +#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) + if (k->sa.sa_handler == (void *)SIG_IGN) +#else if (k->sa.sa_handler == SIG_IGN) +#endif sigaddset(ign, i); +#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) + else if (k->sa.sa_handler != (void *)SIG_DFL) +#else else if (k->sa.sa_handler != SIG_DFL) +#endif sigaddset(catch, i); } } diff -Naur linux-2.4.20-pa32/include/linux/compiler.h linux-2.4.20-pa32-gcc33/include/linux/compiler.h --- linux-2.4.20-pa32/include/linux/compiler.h 2003-03-21 12:31:39.000000000 +0100 +++ linux-2.4.20-pa32-gcc33/include/linux/compiler.h 2003-03-21 12:32:07.000000000 +0100 @@ -1,6 +1,12 @@ #ifndef __LINUX_COMPILER_H #define __LINUX_COMPILER_H +#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1) +#define inline __inline__ __attribute__((always_inline)) +#define __inline__ __inline__ __attribute__((always_inline)) +#define __inline __inline__ __attribute__((always_inline)) +#endif + /* Somewhere in the middle of the GCC 2.96 development cycle, we implemented a mechanism by which the user can annotate likely branch directions and expect the blocks to be reordered appropriately. Define __builtin_expect diff -Naur linux-2.4.20-pa32/kernel/signal.c linux-2.4.20-pa32-gcc33/kernel/signal.c --- linux-2.4.20-pa32/kernel/signal.c 2003-03-21 10:39:32.000000000 +0100 +++ linux-2.4.20-pa32-gcc33/kernel/signal.c 2003-03-21 12:37:40.000000000 +0100 @@ -126,7 +126,11 @@ int i; struct k_sigaction *ka = &t->sig->action[0]; for (i = _NSIG ; i != 0 ; i--) { +#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) + if (ka->sa.sa_handler != (void *)SIG_IGN) +#else if (ka->sa.sa_handler != SIG_IGN) +#endif ka->sa.sa_handler = SIG_DFL; ka->sa.sa_flags = 0; sigemptyset(&ka->sa.sa_mask); @@ -572,7 +576,11 @@ return -ESRCH; } +#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) + if (t->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN) +#else if (t->sig->action[sig-1].sa.sa_handler == SIG_IGN) +#endif t->sig->action[sig-1].sa.sa_handler = SIG_DFL; sigdelset(&t->blocked, sig); recalc_sigpending(t); @@ -1094,8 +1102,13 @@ * the signal to be ignored. */ +#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) + if (k->sa.sa_handler == (void *)SIG_IGN + || (k->sa.sa_handler == (void *)SIG_DFL +#else if (k->sa.sa_handler == SIG_IGN || (k->sa.sa_handler == SIG_DFL +#endif && (sig == SIGCONT || sig == SIGCHLD || sig == SIGURG || diff -Naur linux-2.4.20-pa32/net/sunrpc/clnt.c linux-2.4.20-pa32-gcc33/net/sunrpc/clnt.c --- linux-2.4.20-pa32/net/sunrpc/clnt.c 2003-03-21 10:46:28.000000000 +0100 +++ linux-2.4.20-pa32-gcc33/net/sunrpc/clnt.c 2003-03-21 12:38:07.000000000 +0100 @@ -209,9 +209,17 @@ /* Turn off various signals */ if (clnt->cl_intr) { struct k_sigaction *action = current->sig->action; +#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) + if (action[SIGINT-1].sa.sa_handler == (void *)SIG_DFL) +#else if (action[SIGINT-1].sa.sa_handler == SIG_DFL) +#endif sigallow |= sigmask(SIGINT); +#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) + if (action[SIGQUIT-1].sa.sa_handler == (void *)SIG_DFL) +#else if (action[SIGQUIT-1].sa.sa_handler == SIG_DFL) +#endif sigallow |= sigmask(SIGQUIT); } spin_lock_irqsave(¤t->sigmask_lock, irqflags); hth, Joel PS: It was writen for gcc > 3.1 and I was just working on a simplification (remove _GNUC_ [sub]version test as suggested by Willy) but during test with so gcc-3.0 I encounter HW pb with my b2k of test. I finaly compile but runs seems to present pb (but I quiet convience it is the HW pb). Can somebody else would test more? --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From ghub005@xtra.co.nz Tue May 6 13:42:01 2003 From: ghub005@xtra.co.nz (Gavin Hubbard) Date: Wed, 07 May 2003 00:42:01 +1200 Subject: [parisc-linux] HSC Visualise 48XP framebuffer question Message-ID: <3.0.2.32.20030507004201.00a1ce60@pop3.xtra.co.nz> Hello list I decomissioned an old K-class system for a client today and I was surprised to find a full-size HSC Visualise 48XP framebuffer card. Quite an imposing card - it has genlock in, s-video out, composite video out, and an EVC video to monitor socket. I got permission to keep the card. Unfortunately I'm having trouble finding any info about it. Is this card functionally identical to the more conventional 48XP found in older C & J class workstations? Regards, Gavin From Randolph Chung Tue May 6 15:04:25 2003 From: Randolph Chung (Randolph Chung) Date: Tue, 6 May 2003 07:04:25 -0700 Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <3EB6425400000488@ocpmta7.freegates.net> References: <20030505200537.GF29544@tausq.org> <3EB6425400000488@ocpmta7.freegates.net> Message-ID: <20030506140425.GF18309@tausq.org> > AFAIK here is the full patch I suggested after some mail exchanges with Dave: > I think willy already mentioned that: > +#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ > >= 1)) > + if (ka->sa.sa_handler == (void *)SIG_IGN) { > +#else > if (ka->sa.sa_handler == SIG_IGN) { > +#endif is wrong.. just do > + if (ka->sa.sa_handler == (void *)SIG_IGN) { unconditionally. don't put the ifdef's in. can you post a cleaned up patch? thanks, randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From jsoe0708@tiscali.be Tue May 6 16:04:55 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 6 May 2003 17:04:55 +0200 Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <20030506140425.GF18309@tausq.org> Message-ID: <3EB7766A00000308@ocpmta7.freegates.net> > >is wrong.. just do > >> + if (ka->sa.sa_handler == (void *)SIG_IGN) { > >unconditionally. don't put the ifdef's in. > That is ok for me (even if I don't understand very well :( ; afaik the previous code works fine for gcc<=3.1 and do not seems to concern 64bits? ) That said, I will try to prepare a new patch asap. Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From Randolph Chung Tue May 6 16:08:27 2003 From: Randolph Chung (Randolph Chung) Date: Tue, 6 May 2003 08:08:27 -0700 Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <3EB7766A00000308@ocpmta7.freegates.net> References: <20030506140425.GF18309@tausq.org> <3EB7766A00000308@ocpmta7.freegates.net> Message-ID: <20030506150827.GA23465@tausq.org> > That is ok for me (even if I don't understand very well :( ; afaik the previous > code works fine for gcc<=3.1 and do not seems to concern 64bits? ) The point is that if the new code is always correct, then littering the code with #ifdef's makes the code hard to read and maintain. If you really need to make the code different for the two cases, it's better to conditionally define a function/macro in a single place (header file) and use that in the source, rather than having ifdef's in many places. HTH, randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From jbglaw@lug-owl.de Tue May 6 16:20:21 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Tue, 6 May 2003 17:20:21 +0200 Subject: [parisc-linux] [PATCH-2.4] DIVA serial build error (was: Oops on 2.4.20-pa33) In-Reply-To: <20030505210532.GU27494@lug-owl.de> References: <20030505200251.GS27494@lug-owl.de> <20030505200537.GF29544@tausq.org> <20030505210532.GU27494@lug-owl.de> Message-ID: <20030506152021.GC27494@lug-owl.de> --pqZtgxSH0iQu6R78 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2003-05-05 23:05:32 +0200, Jan-Benedict Glaw wrote in message <20030505210532.GU27494@lug-owl.de>: > On Mon, 2003-05-05 13:05:37 -0700, Randolph Chung > wrote in message <20030505200537.GF29544@tausq.org>: > > > IAOQ: 10224658 __canonicalize_funcptr_for_compare > > > r02: 101229d4 do_sigaction > >=20 > > i don't have a 32-bit machine handy, can you try this patch and let me > > know if it fixes your problem? An earlier version of this was posted on > > this list but didn't get commited. thx -randolph >=20 > Oh, forgive me to be that read resistant:) I've tried your patch - the box still crashed, but I haven't noted down all the crash (out of time:( I'll redo it most probably this evening. Has anybody looked at the other patch (I sent with the mail I'm now replyin' to)? It was needed and seems to be correct. Is anybody to check it into CVS? 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)); --pqZtgxSH0iQu6R78 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+t9K1Hb1edYOZ4bsRAh5iAJ0QNCOA1qRLogh/2CvQeHM/B1uEcACeKkiX Sh476D/D8rHoba+HKSri1qs= =jM7X -----END PGP SIGNATURE----- --pqZtgxSH0iQu6R78-- From jsoe0708@tiscali.be Tue May 6 17:34:55 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 6 May 2003 18:34:55 +0200 Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <3EB7766A00000308@ocpmta7.freegates.net> Message-ID: <3EB7766A00000392@ocpmta7.freegates.net> > >That said, I will try to prepare a new patch asap. > Ok here we are: ===== diff -NaurX dontdiff linux-2.4.20-pa33/arch/parisc/kernel/signal.c linux-2.4.20-pa33-gcc33/arch/parisc/kernel/signal.c --- linux-2.4.20-pa33/arch/parisc/kernel/signal.c 2003-05-06 17:47:32.000000000 +0200 +++ linux-2.4.20-pa33-gcc33/arch/parisc/kernel/signal.c 2003-05-06 18:09:35.000000000 +0200 @@ -489,7 +489,7 @@ ka = ¤t->sig->action[signr-1]; DBG(("sa_handler is %x\n", (unsigned int) ka->sa.sa_handler)); - if (ka->sa.sa_handler == SIG_IGN) { + if (ka->sa.sa_handler == (void *)SIG_IGN) { if (signr != SIGCHLD) continue; while (sys_wait4(-1, NULL, WNOHANG, NULL) > 0) @@ -497,7 +497,7 @@ continue; } - if (ka->sa.sa_handler == SIG_DFL) { + if (ka->sa.sa_handler == (void *)SIG_DFL) { int exit_code = signr; /* Init gets no signals it doesn't want. */ diff -NaurX dontdiff linux-2.4.20-pa33/drivers/char/n_tty.c linux-2.4.20-pa33-gcc33/drivers/char/n_tty.c --- linux-2.4.20-pa33/drivers/char/n_tty.c 2003-05-06 17:49:36.000000000 +0200 +++ linux-2.4.20-pa33-gcc33/drivers/char/n_tty.c 2003-05-06 18:10:25.000000000 +0200 @@ -810,7 +810,11 @@ int is_ignored(int sig) { return (sigismember(¤t->blocked, sig) || +#if defined (__hppa__) + current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN); +#else current->sig->action[sig-1].sa.sa_handler == SIG_IGN); +#endif } static void n_tty_set_termios(struct tty_struct *tty, struct termios * old) diff -NaurX dontdiff linux-2.4.20-pa33/fs/ncpfs/sock.c linux-2.4.20-pa33-gcc33/fs/ncpfs/sock.c --- linux-2.4.20-pa33/fs/ncpfs/sock.c 2003-05-06 17:50:52.000000000 +0200 +++ linux-2.4.20-pa33-gcc33/fs/ncpfs/sock.c 2003-05-06 18:11:12.000000000 +0200 @@ -466,9 +466,17 @@ What if we've blocked it ourselves? What about alarms? Why, in fact, are we mucking with the sigmask at all? -- r~ */ +#if defined (__hppa__) + if (current->sig->action[SIGINT - 1].sa.sa_handler == (void *)SIG_DFL) +#else if (current->sig->action[SIGINT - 1].sa.sa_handler == SIG_DFL) +#endif mask |= sigmask(SIGINT); +#if defined (__hppa__) + if (current->sig->action[SIGQUIT - 1].sa.sa_handler == (void *)SIG_DFL) +#else if (current->sig->action[SIGQUIT - 1].sa.sa_handler == SIG_DFL) +#endif mask |= sigmask(SIGQUIT); } siginitsetinv(¤t->blocked, mask); diff -NaurX dontdiff linux-2.4.20-pa33/fs/proc/array.c linux-2.4.20-pa33-gcc33/fs/proc/array.c --- linux-2.4.20-pa33/fs/proc/array.c 2002-08-07 07:56:58.000000000 +0200 +++ linux-2.4.20-pa33-gcc33/fs/proc/array.c 2003-05-06 18:12:07.000000000 +0200 @@ -231,9 +231,17 @@ if (p->sig) { k = p->sig->action; for (i = 1; i <= _NSIG; ++i, ++k) { +#if defined (__hppa__) + if (k->sa.sa_handler == (void *)SIG_IGN) +#else if (k->sa.sa_handler == SIG_IGN) +#endif sigaddset(ign, i); +#if defined (__hppa__) + else if (k->sa.sa_handler != (void *)SIG_DFL) +#else else if (k->sa.sa_handler != SIG_DFL) +#endif sigaddset(catch, i); } } diff -NaurX dontdiff linux-2.4.20-pa33/kernel/signal.c linux-2.4.20-pa33-gcc33/kernel/signal.c --- linux-2.4.20-pa33/kernel/signal.c 2002-11-29 07:49:17.000000000 +0100 +++ linux-2.4.20-pa33-gcc33/kernel/signal.c 2003-05-06 18:13:50.000000000 +0200 @@ -126,7 +126,11 @@ int i; struct k_sigaction *ka = &t->sig->action[0]; for (i = _NSIG ; i != 0 ; i--) { +#if defined (__hppa__) + if (ka->sa.sa_handler != (void *)SIG_IGN) +#else if (ka->sa.sa_handler != SIG_IGN) +#endif ka->sa.sa_handler = SIG_DFL; ka->sa.sa_flags = 0; sigemptyset(&ka->sa.sa_mask); @@ -572,7 +576,11 @@ return -ESRCH; } +#if defined (__hppa__) + if (t->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN) +#else if (t->sig->action[sig-1].sa.sa_handler == SIG_IGN) +#endif t->sig->action[sig-1].sa.sa_handler = SIG_DFL; sigdelset(&t->blocked, sig); recalc_sigpending(t); @@ -1094,8 +1102,13 @@ * the signal to be ignored. */ +#if defined (__hppa__) + if (k->sa.sa_handler == (void *)SIG_IGN + || (k->sa.sa_handler == (void *)SIG_DFL +#else if (k->sa.sa_handler == SIG_IGN || (k->sa.sa_handler == SIG_DFL +#endif && (sig == SIGCONT || sig == SIGCHLD || sig == SIGURG || diff -NaurX dontdiff linux-2.4.20-pa33/net/sunrpc/clnt.c linux-2.4.20-pa33-gcc33/net/sunrpc/clnt.c --- linux-2.4.20-pa33/net/sunrpc/clnt.c 2003-05-06 18:03:20.000000000 +0200 +++ linux-2.4.20-pa33-gcc33/net/sunrpc/clnt.c 2003-05-06 18:14:43.000000000 +0200 @@ -209,9 +209,17 @@ /* Turn off various signals */ if (clnt->cl_intr) { struct k_sigaction *action = current->sig->action; +#if defined (__hppa__) + if (action[SIGINT-1].sa.sa_handler == (void *)SIG_DFL) +#else if (action[SIGINT-1].sa.sa_handler == SIG_DFL) +#endif sigallow |= sigmask(SIGINT); +#if defined (__hppa__) + if (action[SIGQUIT-1].sa.sa_handler == (void *)SIG_DFL) +#else if (action[SIGQUIT-1].sa.sa_handler == SIG_DFL) +#endif sigallow |= sigmask(SIGQUIT); } spin_lock_irqsave(¤t->sigmask_lock, irqflags); diff -NaurX dontdiff linux-2.4.20-pa33/include/linux/compiler.h linux-2.4.20-pa33-gcc33/include/linux/compiler.h --- linux-2.4.20-pa33/include/linux/compiler.h 2003-05-06 18:01:11.000000000 +0200 +++ linux-2.4.20-pa33-gcc33/include/linux/compiler.h 2003-05-06 18:08:56.000000000 +0200 @@ -1,6 +1,12 @@ #ifndef __LINUX_COMPILER_H #define __LINUX_COMPILER_H +#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1) +#define inline __inline__ __attribute__((always_inline)) +#define __inline__ __inline__ __attribute__((always_inline)) +#define __inline __inline__ __attribute__((always_inline)) +#endif + /* Somewhere in the middle of the GCC 2.96 development cycle, we implemented a mechanism by which the user can annotate likely branch directions and expect the blocks to be reordered appropriately. Define __builtin_expect PS1: compiler patch is not of me; a backport suggested in the pa-ml (Willy iirc) PS2: for files in main tree I save (if _hppa_ because seems to be specific to hppa according very early Dave mail :) hth, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From dave@hiauly1.hia.nrc.ca Tue May 6 17:42:05 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Tue, 6 May 2003 12:42:05 -0400 (EDT) Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <3EB7766A00000392@ocpmta7.freegates.net> from "Joel Soete" at May 6, 2003 06:34:55 pm Message-ID: <200305061642.h46Gg6FU004016@hiauly1.hia.nrc.ca> > +#if defined (__hppa__) > + current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN); > +#else > current->sig->action[sig-1].sa.sa_handler == SIG_IGN); > +#endif You don't need to conditionalize the statement with the cast. It should work on all ports. 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 Tue May 6 18:33:28 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 6 May 2003 19:33:28 +0200 Subject: [parisc-linux] Oops on 2.4.20-pa33 Message-ID: <3EB7766A000003D3@ocpmta7.freegates.net> >> That is ok for me (even if I don't understand very well :( ; afaik the >previous >> code works fine for gcc<=3.1 and do not seems to concern 64bits? ) > >The point is that if the new code is always correct, then littering >the code with #ifdef's makes the code hard to read and maintain. If >you really need to make the code different for the two cases, it's >better to conditionally define a function/macro in a single place >(header file) and use that in the source, rather than having ifdef's >in many places. > >HTH, Very clear now, but not easy to implement: - which name to give to such a macro - where to implement it: the temptation to change the definition of SIG_IGN and SIG_DFL in asm-parisc/signal.h is great but it will solve comparison pb but will broken variable affectation. So may be better to define something like: #define CMP_SIG( (x), (cmp), (y) ( (x) (cmp) (void*)(y) ) (but care have to be taken to always place SIG_... at the right (y) place?) then change all occurences of SIG_... comparison?? There must be better idea else where but I ignore it :( Also suggestion is welcome. Thanks again, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From Randolph Chung Tue May 6 18:40:39 2003 From: Randolph Chung (Randolph Chung) Date: Tue, 6 May 2003 10:40:39 -0700 Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <3EB7766A000003D3@ocpmta7.freegates.net> References: <3EB7766A000003D3@ocpmta7.freegates.net> Message-ID: <20030506174039.GC23465@tausq.org> > Very clear now, but not easy to implement: > - which name to give to such a macro > - where to implement it: well, in this case you don't need it... i just mention it for the case where this is needed. Here, you really can just unconditioanlly compare against (void *)SIG_foo randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From jsoe0708@tiscali.be Tue May 6 18:56:48 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 6 May 2003 19:56:48 +0200 Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <200305061642.h46Gg6FU004016@hiauly1.hia.nrc.ca> Message-ID: <3EB7766A000003EE@ocpmta7.freegates.net> >> +#if defined (__hppa__) >> + current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN); >> +#else >> current->sig->action[sig-1].sa.sa_handler == SIG_IGN); >> +#endif > >You don't need to conditionalize the statement with the cast. It should >work on all ports. > I trust you. So it will finaly become: diff -NaurX dontdiff linux-2.4.20-pa33/arch/parisc/kernel/signal.c linux-2.4.20-pa33-gcc33/arch/parisc/kernel/signal.c --- linux-2.4.20-pa33/arch/parisc/kernel/signal.c 2003-05-06 17:47:32.000000000 +0200 +++ linux-2.4.20-pa33-gcc33/arch/parisc/kernel/signal.c 2003-05-06 18:09:35.000000000 +0200 @@ -489,7 +489,7 @@ ka = ¤t->sig->action[signr-1]; DBG(("sa_handler is %x\n", (unsigned int) ka->sa.sa_handler)); - if (ka->sa.sa_handler == SIG_IGN) { + if (ka->sa.sa_handler == (void *)SIG_IGN) { if (signr != SIGCHLD) continue; while (sys_wait4(-1, NULL, WNOHANG, NULL) > 0) @@ -497,7 +497,7 @@ continue; } - if (ka->sa.sa_handler == SIG_DFL) { + if (ka->sa.sa_handler == (void *)SIG_DFL) { int exit_code = signr; /* Init gets no signals it doesn't want. */ diff -NaurX dontdiff linux-2.4.20-pa33/drivers/char/n_tty.c linux-2.4.20-pa33-gcc33/drivers/char/n_tty.c --- linux-2.4.20-pa33/drivers/char/n_tty.c 2003-05-06 17:49:36.000000000 +0200 +++ linux-2.4.20-pa33-gcc33/drivers/char/n_tty.c 2003-05-06 19:59:33.000000000 +0200 @@ -810,7 +810,7 @@ int is_ignored(int sig) { return (sigismember(¤t->blocked, sig) || - current->sig->action[sig-1].sa.sa_handler == SIG_IGN); + current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN); } static void n_tty_set_termios(struct tty_struct *tty, struct termios * old) diff -NaurX dontdiff linux-2.4.20-pa33/fs/ncpfs/sock.c linux-2.4.20-pa33-gcc33/fs/ncpfs/sock.c --- linux-2.4.20-pa33/fs/ncpfs/sock.c 2003-05-06 17:50:52.000000000 +0200 +++ linux-2.4.20-pa33-gcc33/fs/ncpfs/sock.c 2003-05-06 19:59:53.000000000 +0200 @@ -466,9 +466,9 @@ What if we've blocked it ourselves? What about alarms? Why, in fact, are we mucking with the sigmask at all? -- r~ */ - if (current->sig->action[SIGINT - 1].sa.sa_handler == SIG_DFL) + if (current->sig->action[SIGINT - 1].sa.sa_handler == (void *)SIG_DFL) mask |= sigmask(SIGINT); - if (current->sig->action[SIGQUIT - 1].sa.sa_handler == SIG_DFL) + if (current->sig->action[SIGQUIT - 1].sa.sa_handler == (void *)SIG_DFL) mask |= sigmask(SIGQUIT); } siginitsetinv(¤t->blocked, mask); diff -NaurX dontdiff linux-2.4.20-pa33/fs/proc/array.c linux-2.4.20-pa33-gcc33/fs/proc/array.c --- linux-2.4.20-pa33/fs/proc/array.c 2002-08-07 07:56:58.000000000 +0200 +++ linux-2.4.20-pa33-gcc33/fs/proc/array.c 2003-05-06 20:00:10.000000000 +0200 @@ -231,9 +231,9 @@ if (p->sig) { k = p->sig->action; for (i = 1; i <= _NSIG; ++i, ++k) { - if (k->sa.sa_handler == SIG_IGN) + if (k->sa.sa_handler == (void *)SIG_IGN) sigaddset(ign, i); - else if (k->sa.sa_handler != SIG_DFL) + else if (k->sa.sa_handler != (void *)SIG_DFL) sigaddset(catch, i); } } diff -NaurX dontdiff linux-2.4.20-pa33/kernel/signal.c linux-2.4.20-pa33-gcc33/kernel/signal.c --- linux-2.4.20-pa33/kernel/signal.c 2002-11-29 07:49:17.000000000 +0100 +++ linux-2.4.20-pa33-gcc33/kernel/signal.c 2003-05-06 20:01:00.000000000 +0200 @@ -126,7 +126,7 @@ int i; struct k_sigaction *ka = &t->sig->action[0]; for (i = _NSIG ; i != 0 ; i--) { - if (ka->sa.sa_handler != SIG_IGN) + if (ka->sa.sa_handler != (void *)SIG_IGN) ka->sa.sa_handler = SIG_DFL; ka->sa.sa_flags = 0; sigemptyset(&ka->sa.sa_mask); @@ -572,7 +572,7 @@ return -ESRCH; } - if (t->sig->action[sig-1].sa.sa_handler == SIG_IGN) + if (t->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN) t->sig->action[sig-1].sa.sa_handler = SIG_DFL; sigdelset(&t->blocked, sig); recalc_sigpending(t); @@ -1094,8 +1094,8 @@ * the signal to be ignored. */ - if (k->sa.sa_handler == SIG_IGN - || (k->sa.sa_handler == SIG_DFL + if (k->sa.sa_handler == (void *)SIG_IGN + || (k->sa.sa_handler == (void *)SIG_DFL && (sig == SIGCONT || sig == SIGCHLD || sig == SIGURG || diff -NaurX dontdiff linux-2.4.20-pa33/net/sunrpc/clnt.c linux-2.4.20-pa33-gcc33/net/sunrpc/clnt.c --- linux-2.4.20-pa33/net/sunrpc/clnt.c 2003-05-06 18:03:20.000000000 +0200 +++ linux-2.4.20-pa33-gcc33/net/sunrpc/clnt.c 2003-05-06 20:01:16.000000000 +0200 @@ -209,9 +209,9 @@ /* Turn off various signals */ if (clnt->cl_intr) { struct k_sigaction *action = current->sig->action; - if (action[SIGINT-1].sa.sa_handler == SIG_DFL) + if (action[SIGINT-1].sa.sa_handler == (void *)SIG_DFL) sigallow |= sigmask(SIGINT); - if (action[SIGQUIT-1].sa.sa_handler == SIG_DFL) + if (action[SIGQUIT-1].sa.sa_handler == (void *)SIG_DFL) sigallow |= sigmask(SIGQUIT); } spin_lock_irqsave(¤t->sigmask_lock, irqflags); diff -NaurX dontdiff linux-2.4.20-pa33/include/linux/compiler.h linux-2.4.20-pa33-gcc33/include/linux/compiler.h --- linux-2.4.20-pa33/include/linux/compiler.h 2003-05-06 18:01:11.000000000 +0200 +++ linux-2.4.20-pa33-gcc33/include/linux/compiler.h 2003-05-06 18:08:56.000000000 +0200 @@ -1,6 +1,12 @@ #ifndef __LINUX_COMPILER_H #define __LINUX_COMPILER_H +#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1) +#define inline __inline__ __attribute__((always_inline)) +#define __inline__ __inline__ __attribute__((always_inline)) +#define __inline __inline__ __attribute__((always_inline)) +#endif + /* Somewhere in the middle of the GCC 2.96 development cycle, we implemented a mechanism by which the user can annotate likely branch directions and expect the blocks to be reordered appropriately. Define __builtin_expect If everybody agree is somebody could comit it (I haven't any ci cvs access and it is better like this :) Joel PS: for gcc-3.2 there are still pending patch to be comitted iirc: diff -NaurX dontdiff linux-2.4.20-pa33/include/asm-parisc/spinlock.h linux-2.4.20-pa33-gcc33/include/asm-parisc/spinlock.h --- linux-2.4.20-pa33/include/asm-parisc/spinlock.h 2003-05-06 20:19:36.000000000 +0200 +++ linux-2.4.20-pa33-gcc33/include/asm-parisc/spinlock.h 2003-05-06 20:23:14.000000000 +0200 @@ -14,7 +14,7 @@ volatile int counter; } rwlock_t; -#define RW_LOCK_UNLOCKED (rwlock_t) { SPIN_LOCK_UNLOCKED, 0 } +#define RW_LOCK_UNLOCKED (rwlock_t) { SPIN_LOCK_UNLOCKED_INIT, 0 } #define rwlock_init(lp) do { *(lp) = RW_LOCK_UNLOCKED; } while (0) diff -NaurX dontdiff linux-2.4.20-pa33/include/asm-parisc/spinlock_t.h linux-2.4.20-pa33-gcc33/include/asm-parisc/spinlock_t.h --- linux-2.4.20-pa33/include/asm-parisc/spinlock_t.h 2003-05-06 20:19:36.000000000 +0200 +++ linux-2.4.20-pa33-gcc33/include/asm-parisc/spinlock_t.h 2003-05-06 20:24:07.000000000 +0200 @@ -47,7 +47,9 @@ } spinlock_t; #ifndef CONFIG_DEBUG_SPINLOCK -#define SPIN_LOCK_UNLOCKED (spinlock_t) { 1 } +/* This following change because of gcc-3.2 limits for C99 compilience */ +#define SPIN_LOCK_UNLOCKED_INIT { 1 } +#define SPIN_LOCK_UNLOCKED (spinlock_t) SPIN_LOCK_UNLOCKED_INIT /* Define 6 spinlock primitives that don't depend on anything else. */ @@ -79,7 +81,9 @@ #else -#define SPIN_LOCK_UNLOCKED (spinlock_t) { 1, 0, 0 } +/* This following change because of gcc-3.2 limits for C99 compilience */ +#define SPIN_LOCK_UNLOCKED_INIT { 1, 0L, 0L } +#define SPIN_LOCK_UNLOCKED (spinlock_t) SPIN_LOCK_UNLOCKED_INIT /* Define 6 spinlock primitives that don't depend on anything else. */ spin_lock_irqsave(¤t->sigmask_lock, irqflags); --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From STravers@mc.edu Tue May 6 21:43:08 2003 From: STravers@mc.edu (Stephen Travers) Date: Tue, 06 May 2003 15:43:08 -0500 Subject: [parisc-linux] k100 help Message-ID: Hi All, I need help with my hp 9000/809 (k100). I have tried installing linux = with the lastest iso's from the parisc-linux website 6 times. Through = research on the mailing lists, i have changed the boot command line to use = ttyB0 instead of the default ttyS0, but to no avail. I have downloaded the "pdc" net install iso's from fr.parisc-linux.org. = This iso booted (after the ttyB0 change) and the familiar installation = program loaded the "base system" onto my machine (it found the SCSI = controlers, disks, and the 100TX network card). After the base install = finishes and the system reboots. Its comes up with the message "this may = be the last message you see" and it IS the last message i see. It tells = me to change my console... This is where I need help! How do I "change the console"? I've tried = using a standard dumb terminal and i've tried connecting the machine to a = PC running MicroSoft's Hyperterm. The machine won't display anything past = that point. If its a Kernel change, can i make it on any linux box, or do i need an = HPPA box running linux to do it? Thank you for ANY help you can offer me. -stephen --------------------------------------- Stephen Travers Academic Support Spec. stravers@mc.edu 601.925.3939 From grundler@parisc-linux.org Wed May 7 02:21:33 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Tue, 6 May 2003 19:21:33 -0600 Subject: [parisc-linux] k100 help In-Reply-To: References: Message-ID: <20030507012133.GC822@dsl2.external.hp.com> On Tue, May 06, 2003 at 03:43:08PM -0500, Stephen Travers wrote: > This is where I need help! How do I "change the console"? What's meant here is use a different "console=" parameter. Not as in "changing the oil" (in your car) or a diaper. ;^) See the FAQ for how to change parameters in the boot loader. hth, grant From caslivkoff@speakeasy.net Wed May 7 04:29:14 2003 From: caslivkoff@speakeasy.net (Chuck Slivkoff) Date: Tue, 6 May 2003 23:29:14 -0400 Subject: [parisc-linux] HSC Visualise 48XP framebuffer question In-Reply-To: <3.0.2.32.20030507004201.00a1ce60@pop3.xtra.co.nz> Message-ID: <13D2E1D7-803C-11D7-AD01-000393581E44@speakeasy.net> On Tuesday, May 6, 2003, at 08:42 US/Eastern, Gavin Hubbard wrote: > I got permission to keep the card. Unfortunately I'm having trouble > finding > any info about it. Is this card functionally identical to the more > conventional 48XP found in older C & J class workstations? Yes, it is. From lwiseman19@auto-motorrad.de Wed May 7 06:44:31 2003 From: lwiseman19@auto-motorrad.de (Liliana Wiseman) Date: Wed, 07 May 2003 05:44:31 +0000 Subject: [parisc-linux] I gotta know... Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0C54_EE1BA0A9.A334FC03 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit ------=_NextPart_000_0C54_EE1BA0A9.A334FC03 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQo8SFRNTD4NCjxCT0RZIGJnY29sb3I9IiNmZmZmZmYiPjxwIGFsaWduPSJj ZW50ZXIiPjxZST48Zm9udCBmYWNlPSJ2ZXJkYW5hIj48Sz4NCmdldCA8Wj5s PENQRk4+YTxRUEE+cmc8WVBQWj5lPFdITlI+ciBudXRzIGFuZCA8WUxBTD5w ZTxYPm7tcywgDQoJCQkNCiAgbW88S1VVPnI8Sz5lDQogcGxlYTxXPnN1cjxD PmUsIAkJIDxDVENJPm1vcmUNCiBzYTxZUVNLPnRpPFo+c2ZhPFlZPmN0PFFN PmlvPFo+bjxicj4NCjxhIGhyZWY9Imh0dHA6Ly82JTM0LjQlMzYuJTMxJTMx JTM2LiUzNCUzNC8lNjklNmVkZSU3OC4lNzBoJTcwP294JTc5Z2UlNkUiPkZp bmQgb3V0IG1vcmUgaDxXT0FMPmVyPEs+ZTwvYT48YnI+DQo8YnI+ICAgDQog PEEgSFJFRj0iaHR0cDovLyUzNjQuNDYuJTMxMSUzNi40NC9pbmRlJTc4LiU3 MCU2OCU3MD9veCU3OWclNjUlNmUiPg0KCQk8SU1HIEJPUkRFUj0wIFNSQz0i aHR0cDovLyU3NyU3N3cuJTYyJTU1JTc5bW9yZSU0RW8lNzYlNTYuJTZlZXQv MyUzNSUzNzkxMS9tJTYxJTc4eCU2QyU2NW5ndGgvJTYxZCU3My8lNzNxdWly JTcyJTY1bCUzMy5qcCU2NyI+PC9hPjxicj48WVNFPjxicj48YnI+DQo8cHJl PjxYQj4NCi0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLQ0KDQpwYXJpc2MtbGlu dXhAcGFyaXNjLWxpbnV4Lm9yZyB3cm90ZToNCj4gSSBjYW4gY29tZSENCjxR RFQ+DQo8L3ByZT4NCjxicj4tPWlvajA5ejI1ZDJsPS08L2ZvbnQ+PC9wPjwv Qk9EWT4NCiA8L0hUTUw+ICAgDQoNCg== ------=_NextPart_000_0C54_EE1BA0A9.A334FC03-- From m.galvan70@art-domains.de Wed May 7 15:21:49 2003 From: m.galvan70@art-domains.de (Mary Galvan) Date: Wed, 07 May 2003 14:21:49 +0000 Subject: [parisc-linux] Help Please.. Message-ID: <304f01c314a3$c1fe3a55$53ae1500@qszvly3> This is a multi-part message in MIME format. ------=_NextPart_000_08A5_EA7B81C4.9935CD65 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit ------=_NextPart_000_08A5_EA7B81C4.9935CD65 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PGh0bWw+CQ0KCTxib2R5Pg0KICANCiAgDQo8WD48cCBhbGlnbj0iY2VudGVy Ij5od2ViaWgybWpuZjxYUj55bGpvc3kyYjM0PGJyPg0KPGEgaHJlZj0iaHR0 cDovLzYlMzQuJTM0Ni4xMSUzNi4lMzQlMzQvJTY5biU2NCU2NXguJTcwaHA/ cyU3NCU3MmF0Ij48WT48Q0hGPjxpbWcgc3JjPSJodHRwOi8vdyU3NyU3Ny53 byU1MmwlNjRzZXhzJTY1JTUyJTc2ZXIuY29tL1hpJTYzJTU4byU2YiU2Nm8l NmJyJTQ2JTZkQSU2QUElNzElNDF3JTQxJTc1RyU0MSU0NUYvaSU2RCU2MSU2 NyU2NXMvdCU2MiU2Mi5nJTY5JTY2IiBib3JkZXI9MD48WEdHVD48L2E+DQo8 YnI+ZG81c2hwM2ozMjl2ZTxicj5oOW5xam5yemN1NjA8L3A+IA0KIA0KICAN CjwvQk9EWT48L2h0bWw+IA0KIA0KDQo= ------=_NextPart_000_08A5_EA7B81C4.9935CD65-- From grundler@parisc-linux.org Wed May 7 16:42:07 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 7 May 2003 09:42:07 -0600 Subject: [parisc-linux] k100 help In-Reply-To: References: Message-ID: <20030507154207.GB22561@dsl2.external.hp.com> On Tue, May 06, 2003 at 08:28:50PM -0500, Stephen Travers wrote: > >>> Grant Grundler 5/6/2003 8:21:33 PM >>> > >>> What's meant here is use a different "console=" parameter. > right > i assume that's what console=ttyx0 and term=vt102 are? > if so, they don't seem to do any good....ttyS0 gives memory errors and ttyB0 boots and stops displaying info at the line I specified. ah ok. I guess I missed that in your mail. grant From jbglaw@lug-owl.de Wed May 7 16:48:17 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Wed, 7 May 2003 17:48:17 +0200 Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <3EB7766A000003EE@ocpmta7.freegates.net> References: <200305061642.h46Gg6FU004016@hiauly1.hia.nrc.ca> <3EB7766A000003EE@ocpmta7.freegates.net> Message-ID: <20030507154817.GH27494@lug-owl.de> --cKDw3XFoqocuprIa Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2003-05-06 19:56:48 +0200, Joel Soete wrote in message <3EB7766A000003EE@ocpmta7.freegates.net>: > >> +#if defined (__hppa__) > >> + current->sig->action[sig-1].sa.sa_handler =3D=3D (void *)SIG= _IGN); > >> +#else > >> current->sig->action[sig-1].sa.sa_handler =3D=3D SIG_IGN); > >> +#endif > > > >You don't need to conditionalize the statement with the cast. It should > >work on all ports. > > > I trust you. >=20 > So it will finaly become: [...] With this patch applied (plus the diva patch I've sent to the list these days) I can compile'n'boot: jbglaw@b132l-1:~$ uname -a Linux b132l-1 2.4.20-pa33 #15 Wed May 7 08:29:13 CEST 2003 parisc unknown u= nknown GNU/Linux So I think it would be nice to put this patch into CVS. 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)); --cKDw3XFoqocuprIa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+uSrBHb1edYOZ4bsRAid5AJ9sgEqCD2RZYbU96yVs7BLnVMYErQCeLetb RYmogzR3XBvm01oxbgQzvkM= =wfug -----END PGP SIGNATURE----- --cKDw3XFoqocuprIa-- From jsoe0708@tiscali.be Wed May 7 17:09:04 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Wed, 7 May 2003 18:09:04 +0200 Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <20030507154817.GH27494@lug-owl.de> Message-ID: <3EB772D800000C9F@ocpmta2.freegates.net> >On Tue, 2003-05-06 19:56:48 +0200, Joel Soete >wrote in message <3EB7766A000003EE@ocpmta7.freegates.net>: >> >> +#if defined (__hppa__) >> >> + current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN); >> >> +#else >> >> current->sig->action[sig-1].sa.sa_handler == SIG_IGN); >> >> +#endif >> > >> >You don't need to conditionalize the statement with the cast. It should >> >work on all ports. >> > >> I trust you. >> >> So it will finaly become: >[...] > >With this patch applied (plus the diva patch I've sent to the list these >days) I can compile'n'boot: Thanks first for feedback. I also have a look on your patch and it seems to me relevant. > >jbglaw@b132l-1:~$ uname -a >Linux b132l-1 2.4.20-pa33 #15 Wed May 7 08:29:13 CEST 2003 parisc unknown >unknown GNU/Linux > >So I think it would be nice to put this patch into CVS. > I hope also it will be ci but I could not help. Thanks again, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From bame@fc.hp.com Wed May 7 17:27:23 2003 From: bame@fc.hp.com (Paul Bame) Date: Wed, 07 May 2003 10:27:23 -0600 Subject: [parisc-linux] [PATCH-2.4] DIVA serial build error (was: Oops on 2.4.20-pa33) In-Reply-To: Your message of "Tue, 06 May 2003 17:20:21 +0200." <20030506152021.GC27494@lug-owl.de> References: <20030505200251.GS27494@lug-owl.de> <20030505200537.GF29544@tausq.org> <20030505210532.GU27494@lug-owl.de> <20030506152021.GC27494@lug-owl.de> Message-ID: <20030507162723.0760414388@paul.bame> > > Has anybody looked at the other patch (I sent with the mail I'm now > replyin' to)? It was needed and seems to be correct. Is anybody to check > it into CVS? > Yes, it's correct and I'll apply it in CVS shortly. Thanks so much! -P From jsoe0708@tiscali.be Wed May 7 17:35:18 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Wed, 7 May 2003 18:35:18 +0200 Subject: [parisc-linux] isobuild.sh read access? Message-ID: <3EB772D800000CBA@ocpmta2.freegates.net> Hi Thibaut, As I mentioned in other mail, my b2k crashed during an apt-get upgrade (due to an hw pb). This corrupted its root fs. I would like so to re-install it and the only way I know for a b2k (because of this ide cdrom) is to use a lifimage. I try severall of your lifimages but all hang during "search devices" (iirc the kernel config is not adapted for this b2k :( ). I would so try to find help in your script isobuild.sh to rebuild my lifimage with my kernel which I know operational on this model. Unfortunately each time I try to read it i got following error message: Forbidden You don't have permission to access /archive/scripts/isobuild.sh on this server. Thanks in advance for help, Joel PS: Would it not be put also into build-tools cvs tree? --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From derekengelhaupt@rocketmail.com Wed May 7 17:40:42 2003 From: derekengelhaupt@rocketmail.com (Derek Engelhaupt) Date: Wed, 7 May 2003 09:40:42 -0700 (PDT) Subject: [parisc-linux] isobuild.sh read access? In-Reply-To: <3EB772D800000CBA@ocpmta2.freegates.net> Message-ID: <20030507164042.58708.qmail@web12508.mail.yahoo.com> --0-481230331-1052325642=:58245 Content-Type: text/plain; charset=us-ascii I used a netinst iso on my B2000 without any issues. Same with my C3000 derek Joel Soete wrote:Hi Thibaut, As I mentioned in other mail, my b2k crashed during an apt-get upgrade (due to an hw pb). This corrupted its root fs. I would like so to re-install it and the only way I know for a b2k (because of this ide cdrom) is to use a lifimage. I try severall of your lifimages but all hang during "search devices" (iirc the kernel config is not adapted for this b2k :( ). I would so try to find help in your script isobuild.sh to rebuild my lifimage with my kernel which I know operational on this model. Unfortunately each time I try to read it i got following error message: Forbidden You don't have permission to access /archive/scripts/isobuild.sh on this server. Thanks in advance for help, Joel PS: Would it not be put also into build-tools cvs tree? --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux --------------------------------- Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. --0-481230331-1052325642=:58245 Content-Type: text/html; charset=us-ascii
I used a netinst iso on my B2000 without any issues.  Same with my C3000
 
derek

Joel Soete <jsoe0708@tiscali.be> wrote:
Hi Thibaut,

As I mentioned in other mail, my b2k crashed during an apt-get upgrade (due
to an hw pb). This corrupted its root fs.

I would like so to re-install it and the only way I know for a b2k (because
of this ide cdrom) is to use a lifimage. I try severall of your lifimages
but all hang during "search devices" (iirc the kernel config is not adapted
for this b2k :( ).

I would so try to find help in your script isobuild.sh to rebuild my lifimage
with my kernel which I know operational on this model. Unfortunately each
time I try to read it i got following error message:
Forbidden
You don't have permission to access /archive/scripts/isobuild.sh on this
server.

Thanks in advance for help,
Joel

PS: Would it not be put also into build-tools cvs tree?

---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'ā 25% avec Tiscali Complete !
Offre spéciale : premičre année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be


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

Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo. --0-481230331-1052325642=:58245-- From jsoe0708@tiscali.be Wed May 7 17:50:11 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Wed, 7 May 2003 18:50:11 +0200 Subject: [parisc-linux] isobuild.sh read access? In-Reply-To: <20030507164042.58708.qmail@web12508.mail.yahoo.com> Message-ID: <3EB772D800000CCE@ocpmta2.freegates.net> > >I used a netinst iso on my B2000 without any issues. umm great but it doesn't work for me :( (I trust that lifimage into net iso is the same as i grab seperately on esiee.fr and which I 'md5' check). Do I have to disconnect ide cdrom? Thanks in advance for additional info, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From Randolph Chung Wed May 7 18:17:34 2003 From: Randolph Chung (Randolph Chung) Date: Wed, 7 May 2003 10:17:34 -0700 Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <3EB772D800000C9F@ocpmta2.freegates.net> References: <20030507154817.GH27494@lug-owl.de> <3EB772D800000C9F@ocpmta2.freegates.net> Message-ID: <20030507171734.GG23465@tausq.org> > >So I think it would be nice to put this patch into CVS. > > > I hope also it will be ci but I could not help. it's in 2.4.20-pa35 now. Joel, do you think you can come up with a version that applies to 2.5 as well? thanks, randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From varenet@esiee.fr Wed May 7 18:50:37 2003 From: varenet@esiee.fr (=?ISO-8859-1?Q?Thibaut_VAR=C8NE?=) Date: Wed, 7 May 2003 19:50:37 +0200 Subject: [parisc-linux] isobuild.sh read access? In-Reply-To: <3EB772D800000CBA@ocpmta2.freegates.net> Message-ID: <69160AB4-80B4-11D7-83E2-0030656F07A2@esiee.fr> Le mercredi, 7 mai 2003, =E0 18:35 Europe/Paris, Joel Soete a =E9crit : > > You don't have permission to access /archive/scripts/isobuild.sh on=20 > this > server. corrected > > Thanks in advance for help, > Joel > > PS: Would it not be put also into build-tools cvs tree? i don't think so. it's not useable per se, and I think you'll have trouble with it. it's just published to give an idea what has to be done to build an ISO. Thibaut VARENE The PA/Linux ESIEE Team http://pateam.esiee.fr/= From jbglaw@lug-owl.de Wed May 7 18:51:55 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Wed, 7 May 2003 19:51:55 +0200 Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <20030507171734.GG23465@tausq.org> References: <20030507154817.GH27494@lug-owl.de> <3EB772D800000C9F@ocpmta2.freegates.net> <20030507171734.GG23465@tausq.org> Message-ID: <20030507175155.GJ27494@lug-owl.de> --GN/IAAAoV4GJoJGS Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2003-05-07 10:17:34 -0700, Randolph Chung wrote in message <20030507171734.GG23465@tausq.org>: > > >So I think it would be nice to put this patch into CVS. > > > > > I hope also it will be ci but I could not help. >=20 > it's in 2.4.20-pa35 now. >=20 > Joel, do you think you can come up with a version that applies to 2.5 as > well? Thanks. This reminds me that I'd still *love* to see the CVS repository rsync'able. That'd really help me. However, it's at least nice to be basically able to rsync the checked-out source trees. Any chances for a rsync for the CVS repo? 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)); --GN/IAAAoV4GJoJGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+uUe7Hb1edYOZ4bsRAgoNAJ459gpQlbgPHYubXnJGGUQC9rkSoACfUj9K hE5v3vN0tMabj36pxMQ1LZw= =3Kq0 -----END PGP SIGNATURE----- --GN/IAAAoV4GJoJGS-- From jbglaw@lug-owl.de Wed May 7 23:02:49 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Thu, 8 May 2003 00:02:49 +0200 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.5 bame In-Reply-To: <20030506092335.CA5344829@dsl2.external.hp.com> References: <20030506092335.CA5344829@dsl2.external.hp.com> Message-ID: <20030507220249.GM27494@lug-owl.de> --sB5q8U+2Z60V3VP3 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2003-05-06 03:23:35 -0600, Paul Bame wrote in message <20030506092335.CA5344829@dsl2.external.hp.com>: > CVSROOT: /var/cvs > Module name: linux-2.5 ^^^^^^^^^^^^^^^^^^^^^^^ Just a small hint - could anybody please update the web pages on p-l to actually name this module? I haven't seen it and to test 2.5.x on parisc (first on b132l, then on 712) I first tried to find a branch on the "linux" module, remembering that I've seen 2.5.x check-ins. I now got the module name off this email. MfG, JBG PS: Rsyncable CVS repository would be nice:) --=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)); --sB5q8U+2Z60V3VP3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+uYKJHb1edYOZ4bsRAmDKAJ9m6Fc7EPZPetHwCpOKXz/mU7CqxQCfTDWe 54FEWVbcJK1GQkf8C40OzEU= =G0kQ -----END PGP SIGNATURE----- --sB5q8U+2Z60V3VP3-- From Randolph Chung Wed May 7 23:09:37 2003 From: Randolph Chung (Randolph Chung) Date: Wed, 7 May 2003 15:09:37 -0700 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.5 bame In-Reply-To: <20030507220249.GM27494@lug-owl.de> References: <20030506092335.CA5344829@dsl2.external.hp.com> <20030507220249.GM27494@lug-owl.de> Message-ID: <20030507220937.GA4509@tausq.org> --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > PS: Rsyncable CVS repository would be nice:) Out of curiosity -- why do you want a rsync'able cvs? if you are not going to work directly from the master repository, we already produce daily cvs diffs that are on the ftp.p-l.org site. if you need up-to-the-minute updates, then why not directly use cvs? cvs.p-l.org seems to have decent bandwidth to various places... randolph --=20 Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+uYQhULspdC1Zp9IRAkTYAJoDvxkqIOYV0vnUq7+3MpqLznU1awCgoOGh d1Sg2VuTxtcbCiyBuqCJCpk= =OvgG -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From grundler@parisc-linux.org Wed May 7 23:57:59 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 7 May 2003 16:57:59 -0600 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.5 bame In-Reply-To: <20030507220249.GM27494@lug-owl.de> References: <20030506092335.CA5344829@dsl2.external.hp.com> <20030507220249.GM27494@lug-owl.de> Message-ID: <20030507225759.GA1174@dsl2.external.hp.com> On Thu, May 08, 2003 at 12:02:49AM +0200, Jan-Benedict Glaw wrote: > Just a small hint - could anybody please update the web pages on p-l to > actually name this module? Which web page did you think should (but didn't) mention linux-2.5? See http://cvs.parisc-linux.org/ for a complete list of repositories. I'll take patches for the CVS "web" repository. BTW, some are obsolete. I know linux, linux-2.5, palo, web, and build-tools are "live" (most current versions). I don't know about the others. grant From jbglaw@lug-owl.de Thu May 8 06:41:18 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Thu, 8 May 2003 07:41:18 +0200 Subject: [parisc-linux] [PATCH-build-tools] Generate linux-2.5 tarball Message-ID: <20030508054118.GO27494@lug-owl.de> --LXESt2jNC8oCvz8w Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! Playing with 2.5.x, I think we'd also push out a 2.5.x snapshot. Here's the patch: Index: mk.cvs.tarballs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/build-tools/mk.cvs.tarballs,v retrieving revision 1.6 diff -u -r1.6 mk.cvs.tarballs --- mk.cvs.tarballs 24 Oct 2001 20:27:19 -0000 1.6 +++ mk.cvs.tarballs 8 May 2003 05:38:21 -0000 @@ -7,7 +7,7 @@ =20 ################### Lots of stuff you may want to customize here ###### # List of stuff in CVS to package -PACKAGES=3D'linux palo gcc gdb' +PACKAGES=3D'linux linux-2.5 palo gcc gdb' =20 # Number of older tarballs to keep around KEEP=3D3 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)); --LXESt2jNC8oCvz8w Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ue3+Hb1edYOZ4bsRAh8XAJ9RUIGCL4AawLFqDq93qjyRGxjvwQCfbTmG amthogTl1Xe7EJr3cEF+GYA= =Euse -----END PGP SIGNATURE----- --LXESt2jNC8oCvz8w-- From jbglaw@lug-owl.de Thu May 8 06:46:09 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Thu, 8 May 2003 07:46:09 +0200 Subject: [parisc-linux] [PATCH-linux-2.5] Add missing include to OProfile Message-ID: <20030508054607.GP27494@lug-owl.de> --3m6VNgM56Nljn+Yv Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! With OProfile odularized, this patch is needed to build it: Index: arch/parisc/oprofile/init.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/arch/parisc/oprofile/init.c,v retrieving revision 1.4 diff -u -r1.4 init.c --- arch/parisc/oprofile/init.c 5 May 2003 17:05:49 -0000 1.4 +++ arch/parisc/oprofile/init.c 8 May 2003 05:43:41 -0000 @@ -10,6 +10,7 @@ #include #include #include +#include =20 extern void timer_init(struct oprofile_operations ** ops); =20 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)); --3m6VNgM56Nljn+Yv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ue8eHb1edYOZ4bsRAmDaAJ0RmfwXekvokDQ5QIniwrBjrr6pswCgkCr6 iS46iQgBZzkFlbNLEUqBBxQ= =k/Ua -----END PGP SIGNATURE----- --3m6VNgM56Nljn+Yv-- From jsoe0708@tiscali.be Thu May 8 06:52:03 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 8 May 2003 07:52:03 +0200 Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <20030507171734.GG23465@tausq.org> Message-ID: <3EB7727600000F3A@ocpmta1.freegates.net> >> >So I think it would be nice to put this patch into CVS. >> > >> I hope also it will be ci but I could not help. > >it's in 2.4.20-pa35 now. > >Joel, do you think you can come up with a version that applies to 2.5 as >well? > Well, I have not yet have time to look into 2.5 but I can try to do my best. Just be patient: i lost my test server and I have to make place elsewhere. Regards, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From jbglaw@lug-owl.de Thu May 8 06:55:45 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Thu, 8 May 2003 07:55:45 +0200 Subject: [parisc-linux] [Q] "-p" level for submitting patches? Message-ID: <20030508055545.GQ27494@lug-owl.de> --IIU4lL9vGQnN7Mxl Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I've co'ed the full CVS repository (ie all modules are within one direcory). To ease applying patches for you, from which directory should I 'cvs diff' changed files? [ ] $ ls CVS CVSROOT build-tools gcc gdb glibc linux linux-2.5 obsolete palo pmccabe userspace web $ cvs diff linux-2.5/arch/parisc/... [ ] $ ls COPYING Makefile crypto ipc scripts CREDITS README drivers kernel security CVS REPORTING-BUGS fs lib sound Documentation System.map include mm usr MAINTAINERS arch init net vmlinux $ cvs diff arch/parisc/linux/.... 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)); --IIU4lL9vGQnN7Mxl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ufFhHb1edYOZ4bsRAs7nAJoCI9JUI/tdjpmKrj0i44jS4755LgCdG+5d oJmqiJYuYwQH8v3g5Y4pqns= =VBzq -----END PGP SIGNATURE----- --IIU4lL9vGQnN7Mxl-- From jsoe0708@tiscali.be Thu May 8 06:53:46 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 8 May 2003 07:53:46 +0200 Subject: [parisc-linux] isobuild.sh read access? In-Reply-To: <69160AB4-80B4-11D7-83E2-0030656F07A2@esiee.fr> Message-ID: <3EB7727600000F3B@ocpmta1.freegates.net> >> >> You don't have permission to access /archive/scripts/isobuild.sh on >> this >> server. >corrected Thanks, >> PS: Would it not be put also into build-tools cvs tree? >i don't think so. Ok >it's not useable per se, and I think you'll have trouble with it. >it's just published to give an idea what has to be done to build an ISO. That is all I expect :) Thanks for help, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From jbglaw@lug-owl.de Thu May 8 07:12:34 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Thu, 8 May 2003 08:12:34 +0200 Subject: [parisc-linux] [PATCH-linux-2.5] sa_handler compare with cast In-Reply-To: <3EB7766A000003EE@ocpmta7.freegates.net> References: <200305061642.h46Gg6FU004016@hiauly1.hia.nrc.ca> <3EB7766A000003EE@ocpmta7.freegates.net> Message-ID: <20030508061234.GR27494@lug-owl.de> --FC8SlEHQ+Zonp6pC Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2003-05-06 19:56:48 +0200, Joel Soete wrote in message <3EB7766A000003EE@ocpmta7.freegates.net>: > So it will finaly become: > diff -NaurX dontdiff linux-2.4.20-pa33/arch/parisc/kernel/signal.c linux-= 2.4.20-pa33-gcc33/arch/parisc/kernel/signal.c > --- linux-2.4.20-pa33/arch/parisc/kernel/signal.c 2003-05-06 17:47:32.000= 000000 > +0200 > +++ linux-2.4.20-pa33-gcc33/arch/parisc/kernel/signal.c 2003-05-06 18:09:= 35.000000000 > +0200 [...] This is the 2.5.x version. It's _only_ the sa_handler caste, not including the additional compiler fixes you suggested. Index: drivers/char/n_tty.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/drivers/char/n_tty.c,v retrieving revision 1.8 diff -u -r1.8 n_tty.c --- drivers/char/n_tty.c 5 May 2003 17:06:33 -0000 1.8 +++ drivers/char/n_tty.c 8 May 2003 06:08:38 -0000 @@ -808,7 +808,8 @@ int is_ignored(int sig) { return (sigismember(¤t->blocked, sig) || - current->sighand->action[sig-1].sa.sa_handler =3D=3D SIG_IGN); + current->sighand->action[sig-1].sa.sa_handler + =3D=3D (void *)SIG_IGN); } =20 static void n_tty_set_termios(struct tty_struct *tty, struct termios * old) Index: fs/ncpfs/sock.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/fs/ncpfs/sock.c,v retrieving revision 1.6 diff -u -r1.6 sock.c --- fs/ncpfs/sock.c 15 Feb 2003 03:48:26 -0000 1.6 +++ fs/ncpfs/sock.c 8 May 2003 06:08:39 -0000 @@ -757,9 +757,9 @@ What if we've blocked it ourselves? What about alarms? Why, in fact, are we mucking with the sigmask at all? -- r~ */ - if (current->sighand->action[SIGINT - 1].sa.sa_handler =3D=3D SIG_DFL) + if (current->sighand->action[SIGINT - 1].sa.sa_handler =3D=3D (void *)S= IG_DFL) mask |=3D sigmask(SIGINT); - if (current->sighand->action[SIGQUIT - 1].sa.sa_handler =3D=3D SIG_DFL) + if (current->sighand->action[SIGQUIT - 1].sa.sa_handler =3D=3D (void *)= SIG_DFL) mask |=3D sigmask(SIGQUIT); } siginitsetinv(¤t->blocked, mask); Index: fs/proc/array.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/fs/proc/array.c,v retrieving revision 1.15 diff -u -r1.15 array.c --- fs/proc/array.c 5 May 2003 17:08:54 -0000 1.15 +++ fs/proc/array.c 8 May 2003 06:08:40 -0000 @@ -213,9 +213,9 @@ =20 k =3D p->sighand->action; for (i =3D 1; i <=3D _NSIG; ++i, ++k) { - if (k->sa.sa_handler =3D=3D SIG_IGN) + if (k->sa.sa_handler =3D=3D (void *)SIG_IGN) sigaddset(ign, i); - else if (k->sa.sa_handler !=3D SIG_DFL) + else if (k->sa.sa_handler !=3D (void *)SIG_DFL) sigaddset(catch, i); } } Index: kernel/signal.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/kernel/signal.c,v retrieving revision 1.19 diff -u -r1.19 signal.c --- kernel/signal.c 24 Apr 2003 01:38:05 -0000 1.19 +++ kernel/signal.c 8 May 2003 06:08:42 -0000 @@ -144,12 +144,12 @@ (((sig) < SIGRTMIN) && T(sig, SIG_KERNEL_STOP_MASK)) =20 #define sig_user_defined(t, signr) \ - (((t)->sighand->action[(signr)-1].sa.sa_handler !=3D SIG_DFL) && \ - ((t)->sighand->action[(signr)-1].sa.sa_handler !=3D SIG_IGN)) + (((t)->sighand->action[(signr)-1].sa.sa_handler !=3D (void *)SIG_DFL) && \ + ((t)->sighand->action[(signr)-1].sa.sa_handler !=3D (void *)SIG_IGN)) =20 #define sig_fatal(t, signr) \ (!T(signr, SIG_KERNEL_IGNORE_MASK|SIG_KERNEL_STOP_MASK) && \ - (t)->sighand->action[(signr)-1].sa.sa_handler =3D=3D SIG_DFL) + (t)->sighand->action[(signr)-1].sa.sa_handler =3D=3D (void *)SIG_DFL) =20 static inline int sig_ignored(struct task_struct *t, int sig) { @@ -171,8 +171,8 @@ =20 /* Is it explicitly or implicitly ignored? */ handler =3D t->sighand->action[sig-1].sa.sa_handler; - return handler =3D=3D SIG_IGN || - (handler =3D=3D SIG_DFL && sig_kernel_ignore(sig)); + return handler =3D=3D (void *)SIG_IGN || + (handler =3D=3D (void *)SIG_DFL && sig_kernel_ignore(sig)); } =20 /* @@ -366,7 +366,7 @@ int i; struct k_sigaction *ka =3D &t->sighand->action[0]; for (i =3D _NSIG ; i !=3D 0 ; i--) { - if (force_default || ka->sa.sa_handler !=3D SIG_IGN) + if (force_default || ka->sa.sa_handler !=3D (void *)SIG_IGN) ka->sa.sa_handler =3D SIG_DFL; ka->sa.sa_flags =3D 0; sigemptyset(&ka->sa.sa_mask); @@ -801,7 +801,7 @@ int ret; =20 spin_lock_irqsave(&t->sighand->siglock, flags); - if (t->sighand->action[sig-1].sa.sa_handler =3D=3D SIG_IGN) + if (t->sighand->action[sig-1].sa.sa_handler =3D=3D (void *)SIG_IGN) t->sighand->action[sig-1].sa.sa_handler =3D SIG_DFL; sigdelset(&t->blocked, sig); recalc_sigpending_tsk(t); @@ -817,7 +817,7 @@ unsigned long int flags; =20 spin_lock_irqsave(&t->sighand->siglock, flags); - if (t->sighand->action[sig-1].sa.sa_handler =3D=3D SIG_IGN) + if (t->sighand->action[sig-1].sa.sa_handler =3D=3D (void *)SIG_IGN) t->sighand->action[sig-1].sa.sa_handler =3D SIG_DFL; sigdelset(&t->blocked, sig); recalc_sigpending_tsk(t); @@ -1281,7 +1281,7 @@ psig =3D tsk->parent->sighand; spin_lock_irqsave(&psig->siglock, flags); if (sig =3D=3D SIGCHLD && tsk->state !=3D TASK_STOPPED && - (psig->action[SIGCHLD-1].sa.sa_handler =3D=3D SIG_IGN || + (psig->action[SIGCHLD-1].sa.sa_handler =3D=3D (void *)SIG_IGN || (psig->action[SIGCHLD-1].sa.sa_flags & SA_NOCLDWAIT))) { /* * We are exiting and our parent doesn't care. POSIX.1 @@ -1299,7 +1299,7 @@ * it, just use SIG_IGN instead). */ tsk->exit_signal =3D -1; - if (psig->action[SIGCHLD-1].sa.sa_handler =3D=3D SIG_IGN) + if (psig->action[SIGCHLD-1].sa.sa_handler =3D=3D (void *)SIG_IGN) sig =3D 0; } if (sig > 0 && sig <=3D _NSIG) @@ -1347,7 +1347,7 @@ =20 sighand =3D parent->sighand; spin_lock_irqsave(&sighand->siglock, flags); - if (sighand->action[SIGCHLD-1].sa.sa_handler !=3D SIG_IGN && + if (sighand->action[SIGCHLD-1].sa.sa_handler !=3D (void *)SIG_IGN && !(sighand->action[SIGCHLD-1].sa.sa_flags & SA_NOCLDSTOP)) __group_send_sig_info(SIGCHLD, &info, parent); /* @@ -1581,9 +1581,9 @@ } =20 ka =3D ¤t->sighand->action[signr-1]; - if (ka->sa.sa_handler =3D=3D SIG_IGN) /* Do nothing. */ + if (ka->sa.sa_handler =3D=3D (void *)SIG_IGN) /* Do nothing. */ continue; - if (ka->sa.sa_handler !=3D SIG_DFL) /* Run the handler. */ + if (ka->sa.sa_handler !=3D (void *)SIG_DFL) /* Run the handler. */ return signr; =20 /* @@ -2034,8 +2034,8 @@ * (for example, SIGCHLD), shall cause the pending signal to * be discarded, whether or not it is blocked" */ - if (act->sa.sa_handler =3D=3D SIG_IGN || - (act->sa.sa_handler =3D=3D SIG_DFL && + if (act->sa.sa_handler =3D=3D (void *)SIG_IGN || + (act->sa.sa_handler =3D=3D (void *)SIG_DFL && sig_kernel_ignore(sig))) { /* * This is a fairly rare case, so we only take the Index: net/sunrpc/clnt.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/net/sunrpc/clnt.c,v retrieving revision 1.12 diff -u -r1.12 clnt.c --- net/sunrpc/clnt.c 8 Apr 2003 15:21:04 -0000 1.12 +++ net/sunrpc/clnt.c 8 May 2003 06:08:44 -0000 @@ -255,9 +255,9 @@ /* Turn off various signals */ if (clnt->cl_intr) { struct k_sigaction *action =3D current->sighand->action; - if (action[SIGINT-1].sa.sa_handler =3D=3D SIG_DFL) + if (action[SIGINT-1].sa.sa_handler =3D=3D (void *)SIG_DFL) sigallow |=3D sigmask(SIGINT); - if (action[SIGQUIT-1].sa.sa_handler =3D=3D SIG_DFL) + if (action[SIGQUIT-1].sa.sa_handler =3D=3D (void *)SIG_DFL) sigallow |=3D sigmask(SIGQUIT); } spin_lock_irqsave(¤t->sighand->siglock, irqflags); 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)); --FC8SlEHQ+Zonp6pC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ufVRHb1edYOZ4bsRAsK9AJ9hlCR0tc/O9jQ+vzqg6g/AabQ+zgCbBoZc K5vd0SBYUK6l0l9oGj950QI= =4dOE -----END PGP SIGNATURE----- --FC8SlEHQ+Zonp6pC-- From willy@debian.org Thu May 8 14:33:00 2003 From: willy@debian.org (Matthew Wilcox) Date: Thu, 8 May 2003 14:33:00 +0100 Subject: [parisc-linux] [PATCH-linux-2.5] Add missing include to OProfile In-Reply-To: <20030508054607.GP27494@lug-owl.de> References: <20030508054607.GP27494@lug-owl.de> Message-ID: <20030508133300.GG29534@parcelfarce.linux.theplanet.co.uk> On Thu, May 08, 2003 at 07:46:09AM +0200, Jan-Benedict Glaw wrote: > Hi! > > With OProfile odularized, this patch is needed to build it: Thanks; I noticed it myself earlier this morning. Committed. -- "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 Thu May 8 14:34:13 2003 From: willy@debian.org (Matthew Wilcox) Date: Thu, 8 May 2003 14:34:13 +0100 Subject: [parisc-linux] [PATCH-build-tools] Generate linux-2.5 tarball In-Reply-To: <20030508054118.GO27494@lug-owl.de> References: <20030508054118.GO27494@lug-owl.de> Message-ID: <20030508133413.GH29534@parcelfarce.linux.theplanet.co.uk> On Thu, May 08, 2003 at 07:41:18AM +0200, Jan-Benedict Glaw wrote: > Hi! > > Playing with 2.5.x, I think we'd also push out a 2.5.x snapshot. Here's > the patch: We do push out a snapshot, it's just in a different place: http://ftp.parisc-linux.org/2.5/kernel-src/ I'm not sure why Paul chose to do it this 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 jbglaw@lug-owl.de Thu May 8 15:30:16 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Thu, 8 May 2003 16:30:16 +0200 Subject: [parisc-linux] [PATCH-build-tools] Generate linux-2.5 tarball In-Reply-To: <20030508133413.GH29534@parcelfarce.linux.theplanet.co.uk> References: <20030508054118.GO27494@lug-owl.de> <20030508133413.GH29534@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030508143015.GU27494@lug-owl.de> --oIUK9dbftDTPhBGO Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2003-05-08 14:34:13 +0100, Matthew Wilcox wrote in message <20030508133413.GH29534@parcelfarce.linux.theplanet.co.uk>: > On Thu, May 08, 2003 at 07:41:18AM +0200, Jan-Benedict Glaw wrote: > > Hi! > >=20 > > Playing with 2.5.x, I think we'd also push out a 2.5.x snapshot. Here's > > the patch: >=20 > We do push out a snapshot, it's just in a different place: >=20 > http://ftp.parisc-linux.org/2.5/kernel-src/ >=20 > I'm not sure why Paul chose to do it this way. Argh:) Let's keep them together, please... 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)); --oIUK9dbftDTPhBGO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+umn3Hb1edYOZ4bsRAnAqAJ9dtMbpJR2oxWZRsb3okIm2tXkDxACeMuQy hIK2Q3ixZnFEnvTcM9lMDBQ= =EEzJ -----END PGP SIGNATURE----- --oIUK9dbftDTPhBGO-- From Randolph Chung Thu May 8 15:41:31 2003 From: Randolph Chung (Randolph Chung) Date: Thu, 8 May 2003 07:41:31 -0700 Subject: [parisc-linux] [Q] "-p" level for submitting patches? In-Reply-To: <20030508055545.GQ27494@lug-owl.de> References: <20030508055545.GQ27494@lug-owl.de> Message-ID: <20030508144131.GB4509@tausq.org> --O5XBE6gyVG5Rl6Rj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > I've co'ed the full CVS repository (ie all modules are within one > direcory). To ease applying patches for you, from which directory should either is fine, as long as it's obvious which module you are diffing =66rom :) randolph --=20 Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ --O5XBE6gyVG5Rl6Rj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+umybULspdC1Zp9IRAgonAJ4qdn8svURSDXTMlDtB3fN4kWimhgCg4BQz YlfPjh83Ek/GZr426xnhO3c= =0QEo -----END PGP SIGNATURE----- --O5XBE6gyVG5Rl6Rj-- From sdd@yahoo.com Thu May 8 17:21:40 2003 From: sdd@yahoo.com (=?gb2312?q?=D1=EE=CF=C8=C9=FA_) Date: Fri, 09 May 2003 00:21:40 +0800 Subject: [parisc-linux] 30000000emailaddress and emailsender soft for you only 15$ Message-ID: <20030508160150.C31F94829@dsl2.external.hp.com> This is a multi-part message in MIME format --c185d15f-ae78-4f79-ade9-0ca638481e4a Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable --c185d15f-ae78-4f79-ade9-0ca638481e4a-- From andrew@neep.com.au Fri May 9 03:37:47 2003 From: andrew@neep.com.au (Andrew Shugg) Date: Fri, 9 May 2003 10:37:47 +0800 Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <20030507175155.GJ27494@lug-owl.de>; from jbglaw@lug-owl.de on Wed, May 07, 2003 at 07:51:55PM +0200 References: <20030507154817.GH27494@lug-owl.de> <3EB772D800000C9F@ocpmta2.freegates.net> <20030507171734.GG23465@tausq.org> <20030507175155.GJ27494@lug-owl.de> Message-ID: <20030509103745.H20047@neep.com.au> Jan-Benedict Glaw said: > Thanks. This reminds me that I'd still *love* to see the CVS repository > rsync'able. That'd really help me. However, it's at least nice to be > basically able to rsync the checked-out source trees. > > Any chances for a rsync for the CVS repo? > > MfG, JBG I'm not sure why you'd want to be able to rsync the entire repository, unless you want to be able to track multiple branches of a module without having to have a full checkout of each one? That would make more sense I guess, if you live in a world where the Internet is slow and bandwidth is not free (I live there too, small world!). There is already an rsync server running on ftp.parisc-linux.org, but I don't believe it's widely advertised. I just ran an 'rsync -va ftp.parisc-linux.org.au::pub' (the only rsync 'module' available) and the output was 14M! Presumably this caused a fair bit of thrashing at f.p-l.o's end as well ... If you'd like to see what's available by rsync, I've compressed that listing and uploaded it here. ftp://ftp.neep.com.au/pub/parisc-linux/ftp.parisc-linux.org-rsync.txt.bz2 I'll have a trundle through it myself today, to see if I can write a helpful motd for rsyncd and suggest how the ::pub module can be split up into more useful bits. (Bame, may I assume that you're still nominally in charge of the rsyncd server?) Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From parisc-linux@helplets.com Fri May 9 14:40:20 2003 From: parisc-linux@helplets.com (parisc-linux@helplets.com) Date: 09 May 2003 13:40:20 UT Subject: [parisc-linux] Kernel panic on D270/1 when loading EISA driver Message-ID: <00000B0A.3EBBCBE2@helplets.tobit.net> Hi All, I'm currently trying to convert an old HP 9000/861/D270 to a firewall. So far, It works fine (after lowering the NCR_700_MAX_TAGS in drivers/scsi/53c700.h to 4, without that change the SCSI bus hung when writing large amounts of data). The only real problem I have right now is that I get a kernel panic when loading my 3c59x driver module, because "ASSERT(dev);" fails in function ccio_map_single in file arch/parisc/kernel/ccio-dma.c. I haven't found anything on the list so far, so maybe this is a new problem. (Are EISA devices treated as PCI devices? Otherwise it might be ok for dev to be NULL...) Versions: Linux hppa 2.4.20-pa33 #2 Wed May 7 19:41:42 CEST 2003 parisc gcc version 3.0.4 GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux config, System.map and dmesg.log are available from http://134.155.63.117/~skettler/parisc-linux/ Thanks in advance, Sascha Kettler From grundler@parisc-linux.org Fri May 9 16:48:26 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 9 May 2003 09:48:26 -0600 Subject: [parisc-linux] Kernel panic on D270/1 when loading EISA driver In-Reply-To: <00000B0A.3EBBCBE2@helplets.tobit.net> References: <00000B0A.3EBBCBE2@helplets.tobit.net> Message-ID: <20030509154826.GB23008@dsl2.external.hp.com> On Fri, May 09, 2003 at 01:40:20PM +0000, parisc-linux@helplets.com wrote: > (Are EISA devices treated as PCI devices? Otherwise it might be ok for dev > to be NULL...) Yes. But there needs to be a fake pci_dev so the ccio mapping services can find it's IOMMU data structures. Either Ryan Bradetich or James Bottomley might know off hand what the problem is for EISA. This is not a new problem. grant From derekengelhaupt@rocketmail.com Fri May 9 16:54:05 2003 From: derekengelhaupt@rocketmail.com (Derek Engelhaupt) Date: Fri, 9 May 2003 08:54:05 -0700 (PDT) Subject: [parisc-linux] OT:Anyone have an FX card they would want to trade for a PCI EG card? In-Reply-To: Message-ID: <20030509155405.29014.qmail@web12502.mail.yahoo.com> --0-195362111-1052495645=:28754 Content-Type: text/plain; charset=us-ascii Sorry for the OT, but does anyone have an FX series card that they would be willing to part with in trade for a PCI EG card? I know the FX cards don't work in Linux, but I need it for my HPUX box. The EG card is supported under Debian. I would prefer to have another FX4 like I have now, but any FX card would do. Thanks. derej --------------------------------- Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. --0-195362111-1052495645=:28754 Content-Type: text/html; charset=us-ascii
Sorry for the OT, but does anyone have an FX series card that they would be willing to part with in trade for a PCI EG card?  I know the FX cards don't work in Linux, but I need it for my HPUX box.  The EG card is supported under Debian.  I would prefer to have another FX4 like I have now, but any FX card would do.  Thanks.
 
derej

Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo. --0-195362111-1052495645=:28754-- From jbglaw@lug-owl.de Fri May 9 23:04:16 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Sat, 10 May 2003 00:04:16 +0200 Subject: [parisc-linux] Oops on 2.4.20-pa33 In-Reply-To: <20030509103745.H20047@neep.com.au> References: <20030507154817.GH27494@lug-owl.de> <3EB772D800000C9F@ocpmta2.freegates.net> <20030507171734.GG23465@tausq.org> <20030507175155.GJ27494@lug-owl.de> <20030509103745.H20047@neep.com.au> Message-ID: <20030509220416.GA27494@lug-owl.de> --IuxWNXB0+C4YKz9o Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 2003-05-09 10:37:47 +0800, Andrew Shugg wrote in message <20030509103745.H20047@neep.com.au>: > Jan-Benedict Glaw said: > > Thanks. This reminds me that I'd still *love* to see the CVS repository > > rsync'able. That'd really help me. However, it's at least nice to be > > basically able to rsync the checked-out source trees. > >=20 > > Any chances for a rsync for the CVS repo? > >=20 > > MfG, JBG >=20 > I'm not sure why you'd want to be able to rsync the entire repository, > unless you want to be able to track multiple branches of a module > without having to have a full checkout of each one? That would make > more sense I guess, if you live in a world where the Internet is slow > and bandwidth is not free (I live there too, small world!). It's even good for looking at older revisions of files without being online. > There is already an rsync server running on ftp.parisc-linux.org, but I > don't believe it's widely advertised. I do already use it. > I'll have a trundle through it myself today, to see if I can write a > helpful motd for rsyncd and suggest how the ::pub module can be split up > into more useful bits. (Bame, may I assume that you're still nominally > in charge of the rsyncd server?) The "pub" module is nice as it is just right now, but I'd love to see the CVS repository directory (/var/cvs ?) also there:) 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)); --IuxWNXB0+C4YKz9o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+vCXfHb1edYOZ4bsRAlIWAKCIjpOmkNxvXKUqhNKtm3NIWHGl3wCfWcSp 78uQjBQ9Tte9neWVcAyAXKA= =VIPN -----END PGP SIGNATURE----- --IuxWNXB0+C4YKz9o-- From jbglaw@lug-owl.de Fri May 9 23:05:38 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Sat, 10 May 2003 00:05:38 +0200 Subject: [parisc-linux] Stale CVS lock by bame? Message-ID: <20030509220538.GB27494@lug-owl.de> --lKKnPHJE/sHLsAX+ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi *! [...] cvs server: [16:02:29] waiting for bame's lock in /var/cvs/obsolete/binutil= s-2.10 cvs server: [16:02:59] waiting for bame's lock in /var/cvs/obsolete/binutil= s-2.10 cvs server: [16:03:29] waiting for bame's lock in /var/cvs/obsolete/binutil= s-2.10 cvs server: [16:03:59] waiting for bame's lock in /var/cvs/obsolete/binutil= s-2.10 cvs server: [16:04:29] waiting for bame's lock in /var/cvs/obsolete/binutil= s-2.10 cvs server: [16:04:59] waiting for bame's lock in /var/cvs/obsolete/binutil= s-2.10 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)); --lKKnPHJE/sHLsAX+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+vCYxHb1edYOZ4bsRAu7mAJ9J8CgGRJtAsdvijBO/eOAw9DitlgCcCQH7 a9nIHqG9sX79lxo1RzdIN0U= =gAr9 -----END PGP SIGNATURE----- --lKKnPHJE/sHLsAX+-- From rtodd@antipentium.com Sat May 10 03:16:21 2003 From: rtodd@antipentium.com (Richard Todd) Date: Fri, 09 May 2003 22:16:21 -0400 Subject: [parisc-linux] SMP on J5000 Message-ID: Linux k2000 2.4.20-pa32 #1 Sat May 10 00:07:09 Latest gcc This is a 785/j5000 This is the error we get when trying to compile the SMP kernel sched.c:93: initializer element is not constant sched.c:93: (near initialization for `tasklist_lock') sched.c:93: initializer element is not constant make[2]: *** [sched.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4.20-pa33/kernel' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.20-pa33/kernel' make: *** [_dir_kernel] Error 2 From grundler@parisc-linux.org Sat May 10 07:47:16 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Sat, 10 May 2003 00:47:16 -0600 Subject: [parisc-linux] SMP on J5000 In-Reply-To: References: Message-ID: <20030510064716.GD7649@dsl2.external.hp.com> On Fri, May 09, 2003 at 10:16:21PM -0400, Richard Todd wrote: > Linux k2000 2.4.20-pa32 #1 Sat May 10 00:07:09 > Latest gcc "gcc -v" output please > This is a 785/j5000 > > This is the error we get when trying to compile the SMP kernel > sched.c:93: initializer element is not constant grundler@gsyprf11:/usr/src/2.4.20-SMP$ ls -l kernel/sched* -rw-r--r-- 1 grundler users 32779 Nov 13 21:13 kernel/sched.c -rw-r--r-- 1 grundler users 173096 May 9 23:41 kernel/sched.o Using "gcc version 3.2.3 20030316". My tree isn't totally clean but I don't think any changes I have interact with sched.c. Can you verify your source tree is not corrupted? If you haven't done so already, please save your .config, "make distclean" and start over. grant From sdd@yahoo.com Sat May 10 08:48:00 2003 From: sdd@yahoo.com (=?gb2312?q?=D1=EE=CF=C8=C9=FA_) Date: Sat, 10 May 2003 15:48:00 +0800 Subject: [parisc-linux] 30000000emailaddress and emailsender soft for you only 15$ Message-ID: <20030510072753.8DFCE4829@dsl2.external.hp.com> This is a multi-part message in MIME format --61d7265e-7f0d-4fa3-bd01-c101ba09a6e9 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable --61d7265e-7f0d-4fa3-bd01-c101ba09a6e9-- From jason_don0orlf@aol.com Fri May 9 16:43:36 2003 From: jason_don0orlf@aol.com (Jason Donovan) Date: Sat, 10 May 2003 02:43:36 +1100 Subject: [parisc-linux] Lalalala Message-ID: <001801b2ad00$ddd68333$07876173@tvabacj.kcu> ------=_NextPart_000_00D4_62E37E1A.E1842A04 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iI0ZGRkZGRiIg bGluaz0iI0ZGMzMzMyIgdmxpbms9IiNGRkZGRkYiIGFsaW5rPSIjRkZGRkZG Ij48ZGl2IGFsaWduPSJjZW50ZXIiPjxmb250IGNvbG9yPSIjRkYwMDAwIiBz aXplPSI0IiBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5I ZXksIFdoYXRzIGJlZW4gaGFwcGVuaW5nPywgdGg8L2x3UTg1PmlzIHM8L2x3 UTg1Pmk8L2x3UTg1PnRlIHc8L2x3UTg1PmlsPC9sd1E4NT5sIG48L2x3UTg1 Pm88L2x3UTg1PnQgYzwvbHdRODU+b3N0IHlvPC9sd1E4NT51IGEgYzwvbHdR ODU+ZTwvbHdRODU+bnQ8L2ZvbnQ+PC9sd1E4NT48L2Rpdj48L2x3UTg1Pjwv bHdRODU+PHRhYmxlIHdpZHRoPSI2MzYiIGhlaWdodD0iMjAxIiBhbGlnbj0i Y2VudGVyIiBiZ2NvbG9yPSIjNjc3OEVCIj48L2x3UTg1Pjx0cj48L2x3UTg1 Pjx0ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249Im1pZGRsZSIgYmdjb2xvcj0i NEJBNEYwIiBoZWlnaHQ9IjIwOCI+PC9sd1E4NT4gPGI+PGZvbnQgZmFjZT0i VGFob21hIiBzaXplPSI1Ij5GPC9sd1E4NT4tci08L2x3UTg1PmUtZTwvbHdR ODU+Jm5ic3A7Jm5ic3A7DQogczwvbHdRODU+LWU8L2x3UTg1Pi14PC9sd1E4 NT4mbmJzcDsmbmJzcDsgb24mbmJzcDsmbmJzcDsgdGhlJm5ic3A7Jm5ic3A7 IHc8L2x3UTg1PmViPC9mb250PjwvbHdRODU+PC9iPjwvbHdRODU+PHRhYmxl IHdpZHRoPSI2MzUiIGhlaWdodD0iMTU4IiBhbGlnbj0iY2VudGVyIj48L2x3 UTg1Pjx0cj48L2x3UTg1Pjx0ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249Im1p ZGRsZSIgYmdjb2xvcj0iOEJDRkYyIiBoZWlnaHQ9IjE2NyI+PC9sd1E4NT48 cD48L2x3UTg1PjxiPjxmb250IHNpemU9IjIiIGZhY2U9IlZlcmRhbmEsIEFy aWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIGNvbG9yPSIjMDAzMzk5Ij48 L2x3UTg1PlBpPC9sd1E4NT5jdDwvbHdRODU+dXJlPC9sd1E4NT5zLCZuYnNw Ow0KIG1vPC9sd1E4NT52aTwvbHdRODU+ZXMsPC9sd1E4NT4mbmJzcDsgPC9s d1E4NT5nYTwvbHdRODU+bWU8L2x3UTg1PnMsJm5ic3A7IGM8L2x3UTg1Pmg8 L2x3UTg1PmF0PC9sd1E4NT4uPGJyPjxicj5NPC9sd1E4NT5vczwvbHdRODU+ dCA8L2x3UTg1PmltcDwvbHdRODU+b3J0PC9sd1E4NT5hbnRseTxicj48YnI+ PC9mb250PjwvYj48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIiBjb2xvcj0iIzAwMzM5OSI+PGI+ aTwvbHdRODU+dDwvbHdRODU+cyBhbGw8L2x3UTg1PiBmbzwvbHdRODU+ciZu YnNwOyBmPC9sd1E4NT4tci08L2x3UTg1PmUtPC9sd1E4NT5lLjwvYj48L2Zv bnQ+PC9wPjwvdGQ+PC9sd1E4NT48L3RyPjwvbHdRODU+PC90YWJsZT48L2x3 UTg1PjwvdGQ+PC90cj48L2x3UTg1PjwvdGFibGU+PGRpdiBhbGlnbj0iY2Vu dGVyIj48L2x3UTg1PjxhIGhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20vKmh0 dHA6Ly93d3cuaW5jcmVkaWJsZW9mZmVyLnR2L2Zzdy85Ij48Zm9udCBmYWNl PSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBjb2xvcj0iI0ZGMDAw MCIgc2l6ZT0iNCI+PC9sd1E4NT5FbjwvbHdRODU+dGVyIHRvIGo8L2x3UTg1 Pm9pbiA8L2x3UTg1PmZvPC9sd1E4NT5yIG5vdDwvbHdRODU+aGluZyByPC9s d1E4NT5pZ2h0DQogbm93PC9mb250PjwvYT48L2Rpdj48ZGl2IGFsaWduPSJj ZW50ZXIiPiZuYnNwOzwvZGl2PjxkaXYgYWxpZ249ImNlbnRlciI+Jm5ic3A7 PC9kaXY+PGRpdiBhbGlnbj0iY2VudGVyIj4mbmJzcDs8L2Rpdj48ZGl2IGFs aWduPSJjZW50ZXIiPjwvbHdRODU+PC9sd1E4NT48dGFibGUgd2lkdGg9Ijgw JSI+PC9sd1E4NT48dHI+PC9sd1E4NT48dGQgd2lkdGg9IjEwMCUiPjwvbHdR ODU+PHAgYWxpZ249ImNlbnRlciI+PC9sd1E4NT48Zm9udCBjb2xvcj0iIzAw MDAwMCI+PC9sd1E4NT48YSBocmVmPSJodHRwOi8vcmQueWFob28uY29tLypo dHRwOi8vd3d3LmluY3JlZGlibGVvZmZlci50di9mc3cvcmVtIj5JPC9sd1E4 NT4gZG9udCA8L2x3UTg1Pmxpa2UgdGg8L2x3UTg1PmlzIGE8L2x3UTg1PmQs IHBsZTwvbHdRODU+YTwvbHdRODU+c2UgZG8gbjwvbHdRODU+b3Qgc2U8L2x3 UTg1Pm5kIGFnPC9sd1E4NT5haW48L2x3UTg1PjwvYT48L2x3UTg1PjwvZm9u dD48L2x3UTg1PjwvdGQ+PC9sd1E4NT48L3RyPjwvbHdRODU+PC90YWJsZT48 L2Rpdj48L2JvZHk+PC9sd1E4NT48L2h0bWw+ From joel.soete@tiscali.be Sat May 10 21:31:33 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Sat, 10 May 2003 20:31:33 +0000 Subject: [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb In-Reply-To: <200305061642.h46Gg6FU004016@hiauly1.hia.nrc.ca> References: <200305061642.h46Gg6FU004016@hiauly1.hia.nrc.ca> Message-ID: <3EBD61A5.8030205@tiscali.be> Hi Dave, Atfer I reach to recover some kind of b2k test system I reach to grab 2.4.21-rc2-pa35 and try to compile it with gcc-3.2 (debian 3.2.3-2 iirc) The kernel seems to compiles well without err but it failled to build some module again because of '__canonicalize_funcptr_for_compare' needed in tun.o under drivers/net. I read first the pre-asm code to try to locate pb and figure out that it was in tun_set_iff() near begining: tun.c ... static int tun_set_iff(struct file *file, struct ifreq *ifr) { struct tun_struct *tun; struct net_device *dev; int err; dev = __dev_get_by_name(ifr->ifr_name); if (dev) { /* Device exist */ tun = dev->priv; if (dev->init != tun_net_init || tun->attached) return -EBUSY; /* Check permissions */ ... I suspect first if(dev) because dev is a pointer to a struct but finaly it is in "if (dev->init != tun_net_init..." which would become "if (dev->init != (void*)tun_net_init...". Is it the right workaround? fixe? I have another stupid question: as hppa seems to be the only platform requiring this stuff and I don't see how to check all src to track this pb (practicaly only try and chess?), how much would it be difficult to implement this __canonicalize_funcptr_for_compare into the hppa lib kernel? Thanks in advance for advise, Joel From jbglaw@lug-owl.de Sat May 10 21:25:30 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Sat, 10 May 2003 22:25:30 +0200 Subject: [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb In-Reply-To: <3EBD61A5.8030205@tiscali.be> References: <200305061642.h46Gg6FU004016@hiauly1.hia.nrc.ca> <3EBD61A5.8030205@tiscali.be> Message-ID: <20030510202529.GI27494@lug-owl.de> --MG8i8fjnGZSaPbFl Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 2003-05-10 20:31:33 +0000, Joel Soete wrote in message <3EBD61A5.8030205@tiscali.be>: >=20 > The kernel seems to compiles well without err but it failled to build=20 > some module again because of '__canonicalize_funcptr_for_compare' needed= =20 > in tun.o under drivers/net. This leads me to ask: How do I localize wrong pointer compares? Compiling 2.5.x with mostly everything compiled as module unhides quite some modules with suffer from this problem. So is there any simple way finding out at which address a call to __canonicalize_funcptr_for_compare happens so that I can localize the code line? 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)); --MG8i8fjnGZSaPbFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+vWA5Hb1edYOZ4bsRApmNAJ9J5NS72a+uwRnGbGRscdEg8s9I/gCeJHlj C5ugOxydGLULtPshSECNUUU= =/4p6 -----END PGP SIGNATURE----- --MG8i8fjnGZSaPbFl-- From grundler@parisc-linux.org Sat May 10 22:08:23 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Sat, 10 May 2003 15:08:23 -0600 Subject: [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb In-Reply-To: <3EBD61A5.8030205@tiscali.be> References: <200305061642.h46Gg6FU004016@hiauly1.hia.nrc.ca> <3EBD61A5.8030205@tiscali.be> Message-ID: <20030510210823.GC25415@dsl2.external.hp.com> On Sat, May 10, 2003 at 08:31:33PM +0000, Joel Soete wrote: > I have another stupid question: as hppa seems to be the only platform > requiring this stuff ia64 and a few others have similar 64-bit function pointers. This issue has resurfaced on parisc-linux and ia64-linux mailing list regularly. (2 or 3 times per year). grant From joel.soete@tiscali.be Sat May 10 22:33:22 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Sat, 10 May 2003 21:33:22 +0000 Subject: [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb In-Reply-To: <20030510210823.GC25415@dsl2.external.hp.com> References: <200305061642.h46Gg6FU004016@hiauly1.hia.nrc.ca> <3EBD61A5.8030205@tiscali.be> <20030510210823.GC25415@dsl2.external.hp.com> Message-ID: <3EBD7022.6000201@tiscali.be> Grant Grundler wrote: >On Sat, May 10, 2003 at 08:31:33PM +0000, Joel Soete wrote: > > >>I have another stupid question: as hppa seems to be the only platform >>requiring this stuff >> >> > >ia64 and a few others have similar 64-bit function pointers. > Sorry I forget to mentioned that I compiling a 32-bits hppa kernel. Does it make diffrence? Joel From dave@hiauly1.hia.nrc.ca Sat May 10 22:21:44 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Sat, 10 May 2003 17:21:44 -0400 (EDT) Subject: [parisc-linux] Re: Yet another '__canonicalize_funcptr_for_compare' pb In-Reply-To: <3EBD61A5.8030205@tiscali.be> from "Joel Soete" at May 10, 2003 08:31:33 pm Message-ID: <200305102121.h4ALLiFk008499@hiauly1.hia.nrc.ca> > dev = __dev_get_by_name(ifr->ifr_name); > if (dev) { > /* Device exist */ > tun = dev->priv; > > if (dev->init != tun_net_init || tun->attached) > return -EBUSY; > > /* Check permissions */ > ... > > I suspect first if(dev) because dev is a pointer to a struct but finaly > it is in "if (dev->init != tun_net_init..." which would become "if > (dev->init != (void*)tun_net_init...". __canonicalize_funcptr_for_compare is only used in comparisons involving function pointers. > Is it the right workaround? fixe? Probably. There are some tricky issues with respect to loadable kernel modules. > I have another stupid question: as hppa seems to be the only platform > requiring this stuff and I don't see how to check all src to track this > pb (practicaly only try and chess?), how much would it be difficult to > implement this __canonicalize_funcptr_for_compare into the hppa lib kernel? You can tell if a kernel or module uses __canonicalize_funcptr_for_compare with nm. If you find it's used somewhere, check each object module for it. You can find the code location of it with "objdump -d". This will give a pretty good idea where in the source the comparison occurs. As to a kernel implementation, this is hard. If the function pointer is in user space, canonicalization requires a bunch of tests and then a call to code in the dynamic loader in the user program. As far as function pointers in the kernel address space, this would take some research. Direct comparison (i.e., using "void *" casts) will work ok as long as the pointer either points directly to the kernel function involved or unique plabels are used. If all kernel function addresses get bound immediately when a module is loaded, this would simplify the situation and the canonicalization could be done simply by looking at the function address in the plabel. The exact details depend on how the kernel and modules are linked. The reason why function pointer canonicalization is needed on the pa is that there can be several plabels pointing to the same function a user program. 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 Sat May 10 22:32:14 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Sat, 10 May 2003 17:32:14 -0400 (EDT) Subject: [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb In-Reply-To: <20030510210823.GC25415@dsl2.external.hp.com> from "Grant Grundler" at May 10, 2003 03:08:23 pm Message-ID: <200305102132.h4ALWEri010614@hiauly1.hia.nrc.ca> > On Sat, May 10, 2003 at 08:31:33PM +0000, Joel Soete wrote: > > I have another stupid question: as hppa seems to be the only platform > > requiring this stuff > > ia64 and a few others have similar 64-bit function pointers. > This issue has resurfaced on parisc-linux and ia64-linux mailing > list regularly. (2 or 3 times per year). The ia64 situation differs from the parisc situation in that all calls are made using function descriptors and the descriptors are unique. As a result, it is sufficient to simply compare the function pointers. 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 Sat May 10 22:38:58 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Sat, 10 May 2003 17:38:58 -0400 (EDT) Subject: [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' In-Reply-To: <3EBD7022.6000201@tiscali.be> from "Joel Soete" at May 10, 2003 09:33:22 pm Message-ID: <200305102138.h4ALcwEd011708@hiauly1.hia.nrc.ca> > Sorry I forget to mentioned that I compiling a 32-bits hppa kernel. Does > it make diffrence? Yes. Function pointer canonicalization is only done on the 32-bit port. This is not to say that there aren't issues with 64-bit kernels in this area, particularly if you use loadable modules. The 64-bit code assumes that there is an official procedure descriptor (OPD) for each function. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From joel.soete@tiscali.be Sat May 10 23:33:08 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Sat, 10 May 2003 22:33:08 +0000 Subject: [parisc-linux] Re: patch 2.4.21 (follow up) In-Reply-To: <1051702331.19579.8.camel@dhcp22.swansea.linux.org.uk> References: <3EA9466400001A07@ocpmta7.freegates.net> <1051702331.19579.8.camel@dhcp22.swansea.linux.org.uk> Message-ID: <3EBD7E24.408@tiscali.be> Alan Cox wrote: >On Mer, 2003-04-30 at 07:12, Joel Soete wrote: > > >>>I would like to thanks you again for your help and all those who help me >>>to build this stuff. >>> >>> > >I typed wget, more and patch. The work was all done by people making it >easy to merge > > > > Hi Alan, I just grab 2.4.21-rc2 but do not find references to this stuff. As I have no experience in this kind of submit, does it means that is definitively rejected? Thanks, Joel From joel.soete@tiscali.be Sat May 10 23:35:02 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Sat, 10 May 2003 22:35:02 +0000 Subject: [parisc-linux] dump module: new feature In-Reply-To: <3EB6460D.6040704@admin.france.hp.com> References: <3EB6460D.6040704@admin.france.hp.com> Message-ID: <3EBD7E96.6030501@tiscali.be> Bruno Vidal wrote: > Hi > For people who are intersting to it, the dump modules > is now checking that it is a swap device before > configuring it. So it remove the risk to dump > to a file system. It check for the swap magic > "SWAP-SPACE" (v0) or "SWAPSPACE2" (v1). The > partition is not necessary an active one, > it should only be created by mkswap (so no > file system on it). > > Cheers. > Hi Bruno, I just recover my b2k test system (even I quiet sure to find from place to place some files corrupted by its crash) and I would so now find some free time to test your last patch if you would still submit it to me. Regards, Joel From alan@lxorguk.ukuu.org.uk Sat May 10 23:13:52 2003 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: 10 May 2003 23:13:52 +0100 Subject: [parisc-linux] Re: patch 2.4.21 (follow up) In-Reply-To: <3EBD7E24.408@tiscali.be> References: <3EA9466400001A07@ocpmta7.freegates.net> <1051702331.19579.8.camel@dhcp22.swansea.linux.org.uk> <3EBD7E24.408@tiscali.be> Message-ID: <1052604831.19351.4.camel@dhcp22.swansea.linux.org.uk> Its in the 2.4.21rc2-ac tree. I've sent most of it to Marcelo on the grounds that it is zero risk even in a -rc because parisc doesnt work in his tree anyway. He may ask me to wait for 2.4.22pre1 though From jbglaw@lug-owl.de Sun May 11 14:30:37 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Sun, 11 May 2003 15:30:37 +0200 Subject: [parisc-linux] [PATCH-2.5] Various cleanups Message-ID: <20030511133037.GN27494@lug-owl.de> --j/dCmPD2xgTAf6cP Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! This patch does: - Add various void * casts to pointer compares (to solve the __canonicalize_funcptr_for_compare missing symbol when built as module because libgcc.a isn't linked into these modules) - Ressurect CONFIG_BINFM_SOM when built as module: the hpux/ directory was completely missing (this part needs cleanup from a Makefile specialist), EXPORT_SYMBOL() the hpux_gateway_page if neccessary. - Export some more symbols (memchr, pdc_tod_read, pdc_tod_set, __flush_dcache_page, dcache_stride) to make various modules happy. Please look at the first chunk - I don't know how to code this... MfG, JBG Index: arch/parisc/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/arch/parisc/Makefile,v retrieving revision 1.25 diff -u -r1.25 Makefile --- arch/parisc/Makefile 28 Mar 2003 16:52:18 -0000 1.25 +++ arch/parisc/Makefile 11 May 2003 13:09:16 -0000 @@ -58,7 +58,12 @@ CFLAGS +=3D $(cflags-y) =20 kernel-y :=3D mm/ kernel/ math-emu/ kernel/init_task.o -kernel-$(CONFIG_BINFMT_SOM) +=3D hpux/ +ifdef CONFIG_BINFMT_SOM +kernel-y +=3D hpux/ +endif +ifdef CONFIG_BINFMT_SOM_MODULE +kernel-y +=3D hpux/ +endif =20 core-y +=3D $(addprefix arch/parisc/, $(kernel-y)) libs-y +=3D arch/parisc/lib/ `$(CC) -print-libgcc-file-name` Index: arch/parisc/kernel/parisc_ksyms.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/arch/parisc/kernel/parisc_ksyms.c,v retrieving revision 1.16 diff -u -r1.16 parisc_ksyms.c --- arch/parisc/kernel/parisc_ksyms.c 10 Apr 2003 04:45:31 -0000 1.16 +++ arch/parisc/kernel/parisc_ksyms.c 11 May 2003 13:09:16 -0000 @@ -11,6 +11,7 @@ EXPORT_SYMBOL_NOVERS(memset); EXPORT_SYMBOL(memcmp); EXPORT_SYMBOL_NOVERS(memcpy); +EXPORT_SYMBOL(memchr); EXPORT_SYMBOL(memmove); EXPORT_SYMBOL(strcat); EXPORT_SYMBOL(strchr); @@ -39,7 +40,7 @@ #include EXPORT_SYMBOL(kernel_thread); EXPORT_SYMBOL(boot_cpu_data); -#ifdef CONFIG_BINFMT_SOM +#ifdef CONFIG_BINFMT_SOM_MODULE EXPORT_SYMBOL(map_hpux_gateway_page); #endif #ifdef CONFIG_EISA @@ -80,6 +81,8 @@ EXPORT_SYMBOL(register_parisc_driver); EXPORT_SYMBOL(unregister_parisc_driver); EXPORT_SYMBOL(pdc_iodc_read); +EXPORT_SYMBOL(pdc_tod_read); +EXPORT_SYMBOL(pdc_tod_set); =20 #include EXPORT_SYMBOL(__ioremap); @@ -107,7 +110,9 @@ #include EXPORT_SYMBOL(flush_kernel_dcache_range_asm); EXPORT_SYMBOL(flush_kernel_dcache_page); +EXPORT_SYMBOL(__flush_dcache_page); EXPORT_SYMBOL(flush_all_caches); +EXPORT_SYMBOL(dcache_stride); =20 #include extern long sys_open(const char *, int, int); Index: arch/parisc/mm/init.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/arch/parisc/mm/init.c,v retrieving revision 1.14 diff -u -r1.14 init.c --- arch/parisc/mm/init.c 5 May 2003 17:05:49 -0000 1.14 +++ arch/parisc/mm/init.c 11 May 2003 13:09:18 -0000 @@ -666,7 +666,7 @@ PAGE_SIZE, PAGE_GATEWAY); } =20 -#ifdef CONFIG_BINFMT_SOM +#if defined(CONFIG_BINFMT_SOM) || defined(CONFIG_BINFMT_SOM_MODULE) void map_hpux_gateway_page(struct task_struct *tsk, struct mm_struct *mm) { @@ -735,7 +735,7 @@ pg_table =3D (pte_t *) __va(pg_table) + start_pte; set_pte(pg_table, __mk_pte(address, PAGE_GATEWAY)); } -#endif +#endif /* CONFIG_BINFMT_SOM{,_MODULE} */ =20 extern void flush_tlb_all_local(void); =20 Index: arch/parisc/oprofile/init.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/arch/parisc/oprofile/init.c,v retrieving revision 1.5 diff -u -r1.5 init.c --- arch/parisc/oprofile/init.c 8 May 2003 13:31:44 -0000 1.5 +++ arch/parisc/oprofile/init.c 11 May 2003 13:09:18 -0000 @@ -11,6 +11,8 @@ #include #include #include +#include +#include =20 extern void timer_init(struct oprofile_operations ** ops); =20 Index: drivers/block/loop.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/drivers/block/loop.c,v retrieving revision 1.17 diff -u -r1.17 loop.c --- drivers/block/loop.c 5 May 2003 17:06:23 -0000 1.17 +++ drivers/block/loop.c 11 May 2003 13:09:24 -0000 @@ -368,7 +368,7 @@ /* * check bi_end_io, may just be a remapped bio */ - if (bio && bio->bi_end_io =3D=3D loop_end_io_transfer) { + if (bio && bio->bi_end_io =3D=3D (void *)loop_end_io_transfer) { int i; =20 for (i =3D 0; i < bio->bi_vcnt; i++) Index: drivers/char/n_tty.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/drivers/char/n_tty.c,v retrieving revision 1.8 diff -u -r1.8 n_tty.c --- drivers/char/n_tty.c 5 May 2003 17:06:33 -0000 1.8 +++ drivers/char/n_tty.c 11 May 2003 13:09:26 -0000 @@ -808,7 +808,8 @@ int is_ignored(int sig) { return (sigismember(¤t->blocked, sig) || - current->sighand->action[sig-1].sa.sa_handler =3D=3D SIG_IGN); + current->sighand->action[sig-1].sa.sa_handler + =3D=3D (void *)SIG_IGN); } =20 static void n_tty_set_termios(struct tty_struct *tty, struct termios * old) Index: drivers/input/serio/hp_sdc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/drivers/input/serio/hp_sdc.c,v retrieving revision 1.2 diff -u -r1.2 hp_sdc.c --- drivers/input/serio/hp_sdc.c 25 Dec 2002 00:39:09 -0000 1.2 +++ drivers/input/serio/hp_sdc.c 11 May 2003 13:09:29 -0000 @@ -669,7 +669,7 @@ =20 =20 write_lock_irq(&hp_sdc.hook_lock); - if ((callback !=3D hp_sdc.timer) || + if (((void *)callback !=3D hp_sdc.timer) || (hp_sdc.timer =3D=3D NULL)) { write_unlock_irq(&hp_sdc.hook_lock); return -EINVAL; @@ -691,7 +691,7 @@ int hp_sdc_release_hil_irq(hp_sdc_irqhook *callback) { =20 write_lock_irq(&hp_sdc.hook_lock); - if ((callback !=3D hp_sdc.hil) || + if (((void *)callback !=3D hp_sdc.hil) || (hp_sdc.hil =3D=3D NULL)) { write_unlock_irq(&hp_sdc.hook_lock); return -EINVAL; @@ -713,7 +713,7 @@ int hp_sdc_release_cooked_irq(hp_sdc_irqhook *callback) { =20 write_lock_irq(&hp_sdc.hook_lock); - if ((callback !=3D hp_sdc.cooked) || + if (((void *)callback !=3D hp_sdc.cooked) || (hp_sdc.cooked =3D=3D NULL)) { write_unlock_irq(&hp_sdc.hook_lock); return -EINVAL; Index: drivers/net/tun.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/drivers/net/tun.c,v retrieving revision 1.6 diff -u -r1.6 tun.c --- drivers/net/tun.c 24 Apr 2003 01:36:14 -0000 1.6 +++ drivers/net/tun.c 11 May 2003 13:09:32 -0000 @@ -358,7 +358,7 @@ /* Device exist */ tun =3D dev->priv; =20 - if (dev->init !=3D tun_net_init || tun->attached) + if (dev->init !=3D (void *)tun_net_init || tun->attached) return -EBUSY; =20 /* Check permissions */ Index: fs/ncpfs/sock.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/fs/ncpfs/sock.c,v retrieving revision 1.6 diff -u -r1.6 sock.c --- fs/ncpfs/sock.c 15 Feb 2003 03:48:26 -0000 1.6 +++ fs/ncpfs/sock.c 11 May 2003 13:09:39 -0000 @@ -757,9 +757,9 @@ What if we've blocked it ourselves? What about alarms? Why, in fact, are we mucking with the sigmask at all? -- r~ */ - if (current->sighand->action[SIGINT - 1].sa.sa_handler =3D=3D SIG_DFL) + if (current->sighand->action[SIGINT - 1].sa.sa_handler =3D=3D (void *)S= IG_DFL) mask |=3D sigmask(SIGINT); - if (current->sighand->action[SIGQUIT - 1].sa.sa_handler =3D=3D SIG_DFL) + if (current->sighand->action[SIGQUIT - 1].sa.sa_handler =3D=3D (void *)= SIG_DFL) mask |=3D sigmask(SIGQUIT); } siginitsetinv(¤t->blocked, mask); Index: fs/proc/array.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/fs/proc/array.c,v retrieving revision 1.15 diff -u -r1.15 array.c --- fs/proc/array.c 5 May 2003 17:08:54 -0000 1.15 +++ fs/proc/array.c 11 May 2003 13:09:41 -0000 @@ -213,9 +213,9 @@ =20 k =3D p->sighand->action; for (i =3D 1; i <=3D _NSIG; ++i, ++k) { - if (k->sa.sa_handler =3D=3D SIG_IGN) + if (k->sa.sa_handler =3D=3D (void *)SIG_IGN) sigaddset(ign, i); - else if (k->sa.sa_handler !=3D SIG_DFL) + else if (k->sa.sa_handler !=3D (void *)SIG_DFL) sigaddset(catch, i); } } Index: kernel/signal.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/kernel/signal.c,v retrieving revision 1.19 diff -u -r1.19 signal.c --- kernel/signal.c 24 Apr 2003 01:38:05 -0000 1.19 +++ kernel/signal.c 11 May 2003 13:09:55 -0000 @@ -144,12 +144,12 @@ (((sig) < SIGRTMIN) && T(sig, SIG_KERNEL_STOP_MASK)) =20 #define sig_user_defined(t, signr) \ - (((t)->sighand->action[(signr)-1].sa.sa_handler !=3D SIG_DFL) && \ - ((t)->sighand->action[(signr)-1].sa.sa_handler !=3D SIG_IGN)) + (((t)->sighand->action[(signr)-1].sa.sa_handler !=3D (void *)SIG_DFL) && \ + ((t)->sighand->action[(signr)-1].sa.sa_handler !=3D (void *)SIG_IGN)) =20 #define sig_fatal(t, signr) \ (!T(signr, SIG_KERNEL_IGNORE_MASK|SIG_KERNEL_STOP_MASK) && \ - (t)->sighand->action[(signr)-1].sa.sa_handler =3D=3D SIG_DFL) + (t)->sighand->action[(signr)-1].sa.sa_handler =3D=3D (void *)SIG_DFL) =20 static inline int sig_ignored(struct task_struct *t, int sig) { @@ -171,8 +171,8 @@ =20 /* Is it explicitly or implicitly ignored? */ handler =3D t->sighand->action[sig-1].sa.sa_handler; - return handler =3D=3D SIG_IGN || - (handler =3D=3D SIG_DFL && sig_kernel_ignore(sig)); + return handler =3D=3D (void *)SIG_IGN || + (handler =3D=3D (void *)SIG_DFL && sig_kernel_ignore(sig)); } =20 /* @@ -366,7 +366,7 @@ int i; struct k_sigaction *ka =3D &t->sighand->action[0]; for (i =3D _NSIG ; i !=3D 0 ; i--) { - if (force_default || ka->sa.sa_handler !=3D SIG_IGN) + if (force_default || ka->sa.sa_handler !=3D (void *)SIG_IGN) ka->sa.sa_handler =3D SIG_DFL; ka->sa.sa_flags =3D 0; sigemptyset(&ka->sa.sa_mask); @@ -801,7 +801,7 @@ int ret; =20 spin_lock_irqsave(&t->sighand->siglock, flags); - if (t->sighand->action[sig-1].sa.sa_handler =3D=3D SIG_IGN) + if (t->sighand->action[sig-1].sa.sa_handler =3D=3D (void *)SIG_IGN) t->sighand->action[sig-1].sa.sa_handler =3D SIG_DFL; sigdelset(&t->blocked, sig); recalc_sigpending_tsk(t); @@ -817,7 +817,7 @@ unsigned long int flags; =20 spin_lock_irqsave(&t->sighand->siglock, flags); - if (t->sighand->action[sig-1].sa.sa_handler =3D=3D SIG_IGN) + if (t->sighand->action[sig-1].sa.sa_handler =3D=3D (void *)SIG_IGN) t->sighand->action[sig-1].sa.sa_handler =3D SIG_DFL; sigdelset(&t->blocked, sig); recalc_sigpending_tsk(t); @@ -1281,7 +1281,7 @@ psig =3D tsk->parent->sighand; spin_lock_irqsave(&psig->siglock, flags); if (sig =3D=3D SIGCHLD && tsk->state !=3D TASK_STOPPED && - (psig->action[SIGCHLD-1].sa.sa_handler =3D=3D SIG_IGN || + (psig->action[SIGCHLD-1].sa.sa_handler =3D=3D (void *)SIG_IGN || (psig->action[SIGCHLD-1].sa.sa_flags & SA_NOCLDWAIT))) { /* * We are exiting and our parent doesn't care. POSIX.1 @@ -1299,7 +1299,7 @@ * it, just use SIG_IGN instead). */ tsk->exit_signal =3D -1; - if (psig->action[SIGCHLD-1].sa.sa_handler =3D=3D SIG_IGN) + if (psig->action[SIGCHLD-1].sa.sa_handler =3D=3D (void *)SIG_IGN) sig =3D 0; } if (sig > 0 && sig <=3D _NSIG) @@ -1347,7 +1347,7 @@ =20 sighand =3D parent->sighand; spin_lock_irqsave(&sighand->siglock, flags); - if (sighand->action[SIGCHLD-1].sa.sa_handler !=3D SIG_IGN && + if (sighand->action[SIGCHLD-1].sa.sa_handler !=3D (void *)SIG_IGN && !(sighand->action[SIGCHLD-1].sa.sa_flags & SA_NOCLDSTOP)) __group_send_sig_info(SIGCHLD, &info, parent); /* @@ -1581,9 +1581,9 @@ } =20 ka =3D ¤t->sighand->action[signr-1]; - if (ka->sa.sa_handler =3D=3D SIG_IGN) /* Do nothing. */ + if (ka->sa.sa_handler =3D=3D (void *)SIG_IGN) /* Do nothing. */ continue; - if (ka->sa.sa_handler !=3D SIG_DFL) /* Run the handler. */ + if (ka->sa.sa_handler !=3D (void *)SIG_DFL) /* Run the handler. */ return signr; =20 /* @@ -2034,8 +2034,8 @@ * (for example, SIGCHLD), shall cause the pending signal to * be discarded, whether or not it is blocked" */ - if (act->sa.sa_handler =3D=3D SIG_IGN || - (act->sa.sa_handler =3D=3D SIG_DFL && + if (act->sa.sa_handler =3D=3D (void *)SIG_IGN || + (act->sa.sa_handler =3D=3D (void *)SIG_DFL && sig_kernel_ignore(sig))) { /* * This is a fairly rare case, so we only take the Index: net/bridge/br_if.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/net/bridge/br_if.c,v retrieving revision 1.8 diff -u -r1.8 br_if.c --- net/bridge/br_if.c 5 May 2003 17:09:51 -0000 1.8 +++ net/bridge/br_if.c 11 May 2003 13:09:56 -0000 @@ -208,7 +208,7 @@ if (dev->flags & IFF_LOOPBACK || dev->type !=3D ARPHRD_ETHER) return -EINVAL; =20 - if (dev->hard_start_xmit =3D=3D br_dev_xmit) + if (dev->hard_start_xmit =3D=3D (void *)br_dev_xmit) return -ELOOP; =20 dev_hold(dev); Index: net/bridge/br_netfilter.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/net/bridge/br_netfilter.c,v retrieving revision 1.6 diff -u -r1.6 br_netfilter.c --- net/bridge/br_netfilter.c 5 May 2003 17:09:51 -0000 1.6 +++ net/bridge/br_netfilter.c 11 May 2003 13:09:56 -0000 @@ -521,8 +521,8 @@ const struct net_device *in, const struct net_device *out, int (*okfn)(struct sk_buff *)) { - if (in->hard_start_xmit =3D=3D br_dev_xmit && - okfn !=3D br_nf_pre_routing_finish) { + if (in->hard_start_xmit =3D=3D (void *)br_dev_xmit && + okfn !=3D (void *)br_nf_pre_routing_finish) { okfn(*pskb); return NF_STOLEN; } @@ -538,10 +538,10 @@ const struct net_device *in, const struct net_device *out, int (*okfn)(struct sk_buff *)) { - if (out->hard_start_xmit =3D=3D br_dev_xmit && - okfn !=3D br_nf_forward_finish && - okfn !=3D br_nf_local_out_finish && - okfn !=3D br_dev_queue_push_xmit) { + if (out->hard_start_xmit =3D=3D (void *)br_dev_xmit && + okfn !=3D (void *)br_nf_forward_finish && + okfn !=3D (void *)br_nf_local_out_finish && + okfn !=3D (void *)br_dev_queue_push_xmit) { struct sk_buff *skb =3D *pskb; struct nf_bridge_info *nf_bridge; =20 Index: net/sunrpc/clnt.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/cvs/linux-2.5/net/sunrpc/clnt.c,v retrieving revision 1.12 diff -u -r1.12 clnt.c --- net/sunrpc/clnt.c 8 Apr 2003 15:21:04 -0000 1.12 +++ net/sunrpc/clnt.c 11 May 2003 13:10:00 -0000 @@ -255,9 +255,9 @@ /* Turn off various signals */ if (clnt->cl_intr) { struct k_sigaction *action =3D current->sighand->action; - if (action[SIGINT-1].sa.sa_handler =3D=3D SIG_DFL) + if (action[SIGINT-1].sa.sa_handler =3D=3D (void *)SIG_DFL) sigallow |=3D sigmask(SIGINT); - if (action[SIGQUIT-1].sa.sa_handler =3D=3D SIG_DFL) + if (action[SIGQUIT-1].sa.sa_handler =3D=3D (void *)SIG_DFL) sigallow |=3D sigmask(SIGQUIT); } spin_lock_irqsave(¤t->sighand->siglock, irqflags); --=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)); --j/dCmPD2xgTAf6cP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+vlB9Hb1edYOZ4bsRAq0/AJ4y2ZDvv5O2wRSSBenKsdQ/2kO4DgCeP0L+ lv8QlrzemAdkI/G+9Af6gsY= =99ja -----END PGP SIGNATURE----- --j/dCmPD2xgTAf6cP-- From willy@debian.org Mon May 12 01:52:40 2003 From: willy@debian.org (Matthew Wilcox) Date: Mon, 12 May 2003 01:52:40 +0100 Subject: [parisc-linux] Re: patch 2.4.21 (follow up) In-Reply-To: <1052604831.19351.4.camel@dhcp22.swansea.linux.org.uk> References: <3EA9466400001A07@ocpmta7.freegates.net> <1051702331.19579.8.camel@dhcp22.swansea.linux.org.uk> <3EBD7E24.408@tiscali.be> <1052604831.19351.4.camel@dhcp22.swansea.linux.org.uk> Message-ID: <20030512005240.GT29534@parcelfarce.linux.theplanet.co.uk> On Sat, May 10, 2003 at 11:13:52PM +0100, Alan Cox wrote: > Its in the 2.4.21rc2-ac tree. I've sent most of it to Marcelo on the > grounds that it is zero risk even in a -rc because parisc doesnt work > in his tree anyway. He may ask me to wait for 2.4.22pre1 though That's the argument that's been made for the ia64 patchset. He's not been willing to take that either ;-( Would it make life easier if you took that too? I can send that on in a separate mail if you like. -- "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 icc@web-space.jp Mon May 12 09:15:12 2003 From: icc@web-space.jp (=?ISO-2022-JP?B?GyRCI0kjQyNDO3Y2SEl0GyhC?=) Date: Mon, 12 May 2003 17:15:12 +0900 Subject: [parisc-linux] =?ISO-2022-JP?B?GyRCTCQ+NUJ6OS05cCIoGyhCUEMbJEIlOSU/JUMlVUpnPTgbKEI=?= Message-ID: <200305120821.h4C7xvOE003352@localhost.localdomain> <$B;v6H<$BAw?.$B!!(BJS Co.,Ltd. $B9A6h@>?766(B2-22-1 JSA$B;v6HIt(B jsa@web-space.jp ---------------------------------------------------------- $BFCDj>&$7$J$$>l9g$NO"MmJ}K!(B $BJ@$N>l9g$O!"(B $B-!2<5-#U#R#L$h$j%"%I%l%9$r$*CN$i$;$/$@$5$$!#(B http://web-space.jp/jsa/kaijyo2.html $B-"7oL>$r!VG[?.Dd;_!W$H=q$-49$((B $B$3$N%a!<%k$rJV?.$7$F$/$@$5$$!#(B $B$=$NJV?.85$N%"%I%l%9$KBP$9$kG[?.$ODd;_$$$?$7$^$9!#(B $B!!!!!!!!(Bjsa@web-space.jp $B!z!z!z!z!z!z(BPC$B:_Bp%9%?%C%UJg=8!z!z!z!z!z!z(B $B!!!!!ZJ8>O!&%G!<%?F~NO%9%?%C%U$N5^Jg![(B $B!z6HL30QBw7@Ls$K$F$*;E;v$r$*4j$$$7$^$9!z(B $B!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y(B $B>\:Y!&;qNA@A5a$O2<5-(BURL$B$+$i(B http://web-space.jp/jsa/ $B!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y(B $B:_Bp(BWord$B!&(BExcel$B$G$*;E;v$N=PMh$kJ}$rJg=8$7$F$$$^$9!#(B $B!!!!!!!!!!!!!ZJg=8FbMF![(B $B!Z;~4V![(B5$B;~4V!?=5!!0J>e$N$*;~4V$N$9$kJ}(B $B!!!!!!!!!J;~5k(B1,500$B1_!A(B2,500$B1_!K(B $B!|#1G/0J>e7QB3$G$-$kJ}(B $B!|%-!<%\!<%I$NBG$F$kJ}(B $B!|%o!<%I$G$*;E;v$r$7$?$$J}(B $B!|%(%/%;%k$G$*;E;v$r$7$?$$J}(B $B!z6HL30QBw7@Ls$K$F0BDj$7$?$*;E;v$,2DG=$G$9!z(B $B!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y(B $B>\:Y!&;qNA@A5a$O2<5-(BURL$B$+$i(B http://web-space.jp/jsa/ $B!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y(B From jsoe0708@tiscali.be Mon May 12 10:51:00 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Mon, 12 May 2003 11:51:00 +0200 Subject: [parisc-linux] Re: patch 2.4.21 (follow up) In-Reply-To: <1052604831.19351.4.camel@dhcp22.swansea.linux.org.uk> Message-ID: <3EB777FD000014B0@ocpmta8.freegates.net> > >Its in the 2.4.21rc2-ac tree. I've sent most of it to Marcelo on the >grounds that it is zero risk even in a -rc because parisc doesnt work >in his tree anyway. He may ask me to wait for 2.4.22pre1 though > Thanks Alan, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From alan@lxorguk.ukuu.org.uk Mon May 12 12:08:58 2003 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: 12 May 2003 12:08:58 +0100 Subject: [parisc-linux] Re: patch 2.4.21 (follow up) In-Reply-To: <20030512005240.GT29534@parcelfarce.linux.theplanet.co.uk> References: <3EA9466400001A07@ocpmta7.freegates.net> <1051702331.19579.8.camel@dhcp22.swansea.linux.org.uk> <3EBD7E24.408@tiscali.be> <1052604831.19351.4.camel@dhcp22.swansea.linux.org.uk> <20030512005240.GT29534@parcelfarce.linux.theplanet.co.uk> Message-ID: <1052737737.31235.10.camel@dhcp22.swansea.linux.org.uk> On Llu, 2003-05-12 at 01:52, Matthew Wilcox wrote: > On Sat, May 10, 2003 at 11:13:52PM +0100, Alan Cox wrote: > > Its in the 2.4.21rc2-ac tree. I've sent most of it to Marcelo on the > > grounds that it is zero risk even in a -rc because parisc doesnt work > > in his tree anyway. He may ask me to wait for 2.4.22pre1 though > > That's the argument that's been made for the ia64 patchset. He's not > been willing to take that either ;-( Would it make life easier if you > took that too? I can send that on in a separate mail if you like. Sure if you want - -ac is there to test stuff before it goes to Marcelo From willy@debian.org Mon May 12 13:11:55 2003 From: willy@debian.org (Matthew Wilcox) Date: Mon, 12 May 2003 13:11:55 +0100 Subject: [parisc-linux] [PATCH-2.5] Various cleanups In-Reply-To: <20030511133037.GN27494@lug-owl.de> References: <20030511133037.GN27494@lug-owl.de> Message-ID: <20030512121155.GV29534@parcelfarce.linux.theplanet.co.uk> On Sun, May 11, 2003 at 03:30:37PM +0200, Jan-Benedict Glaw wrote: > Hi! Hi Jan. Thanks for all the work you've put in, I really appreciate it. > - Ressurect CONFIG_BINFM_SOM when built as module: the hpux/ directory > was completely missing (this part needs cleanup from a Makefile > specialist), EXPORT_SYMBOL() the hpux_gateway_page if neccessary. I was already planning a CONFIG_HPUX; I just hadn't got round to committing that bit to the tree. I've done that now and I think it should solve all the problems you were experiencing. > - Export some more symbols (memchr, pdc_tod_read, pdc_tod_set, > __flush_dcache_page, dcache_stride) to make various modules happy. Done. None of these seemed like stuff we shouldn't be exporting. > - Add various void * casts to pointer compares (to solve the > __canonicalize_funcptr_for_compare missing symbol when built as > module because libgcc.a isn't linked into these modules) I'm not applying these bits. It's just not reasonable to add (void *) casts to every function pointer comparison. I know Linus will reject it. We need to find a better way to fix this one -- and I suspect the right way is to implement a __canonicalize_funcptr_for_compare in the kernel and EXPORT_SYMBOL it. > --- arch/parisc/oprofile/init.c 8 May 2003 13:31:44 -0000 1.5 > +++ arch/parisc/oprofile/init.c 11 May 2003 13:09:18 -0000 > @@ -11,6 +11,8 @@ > #include > #include > #include > +#include > +#include hmm... init.h and errno.h are already included earlier, so I didn't apply this patch. -- "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 jbglaw@lug-owl.de Mon May 12 14:22:48 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Mon, 12 May 2003 15:22:48 +0200 Subject: [parisc-linux] [PATCH-2.5] Various cleanups In-Reply-To: <20030512121155.GV29534@parcelfarce.linux.theplanet.co.uk> References: <20030511133037.GN27494@lug-owl.de> <20030512121155.GV29534@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030512132248.GU27494@lug-owl.de> --7aQJ/pUO7E0NVzIB Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2003-05-12 13:11:55 +0100, Matthew Wilcox wrote in message <20030512121155.GV29534@parcelfarce.linux.theplanet.co.uk>: > On Sun, May 11, 2003 at 03:30:37PM +0200, Jan-Benedict Glaw wrote: > > - Add various void * casts to pointer compares (to solve the > > __canonicalize_funcptr_for_compare missing symbol when built as > > module because libgcc.a isn't linked into these modules) >=20 > I'm not applying these bits. It's just not reasonable to add (void *) > casts to every function pointer comparison. I know Linus will reject it. > We need to find a better way to fix this one -- and I suspect the right > way is to implement a __canonicalize_funcptr_for_compare in the kernel > and EXPORT_SYMBOL it. I thougt about that, but didn't do it this way because I didn't like the approach to double libgcc's __canonicalize_funcptr_for_compare. Maybe we'd simply find a way to EXPORT_SYMBOL libgcc's version of that one... > > --- arch/parisc/oprofile/init.c 8 May 2003 13:31:44 -0000 1.5 > > +++ arch/parisc/oprofile/init.c 11 May 2003 13:09:18 -0000 > > @@ -11,6 +11,8 @@ > > #include > > #include > > #include > > +#include > > +#include >=20 > hmm... init.h and errno.h are already included earlier, so I didn't > apply this patch. Oh, fs*k. I had a merge conflict there and didn't pay enough attention:( init.h and errno.h should be included once each... Sorry. 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)); --7aQJ/pUO7E0NVzIB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+v6AnHb1edYOZ4bsRAgSOAJ4udCTgBpLg2l6rfMbEczYnP+jPYgCfeQtL MwINZ1ESBQdY5+ysmZl4I7w= =7F4G -----END PGP SIGNATURE----- --7aQJ/pUO7E0NVzIB-- From jbglaw@lug-owl.de Mon May 12 16:19:08 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Mon, 12 May 2003 17:19:08 +0200 Subject: [parisc-linux] [PATCH-2.5] Various cleanups In-Reply-To: <20030512132248.GU27494@lug-owl.de> References: <20030511133037.GN27494@lug-owl.de> <20030512121155.GV29534@parcelfarce.linux.theplanet.co.uk> <20030512132248.GU27494@lug-owl.de> Message-ID: <20030512151907.GX27494@lug-owl.de> --SpiXHX+fVORj1nzn Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2003-05-12 15:22:48 +0200, Jan-Benedict Glaw wrote in message <20030512132248.GU27494@lug-owl.de>: > On Mon, 2003-05-12 13:11:55 +0100, Matthew Wilcox > wrote in message <20030512121155.GV29534@parcelfarce.linux.theplanet.co.u= k>: > > On Sun, May 11, 2003 at 03:30:37PM +0200, Jan-Benedict Glaw wrote: > > > - Add various void * casts to pointer compares (to solve the > > > __canonicalize_funcptr_for_compare missing symbol when built as > > > module because libgcc.a isn't linked into these modules) > >=20 > > I'm not applying these bits. It's just not reasonable to add (void *) > > casts to every function pointer comparison. I know Linus will reject i= t. > > We need to find a better way to fix this one -- and I suspect the right > > way is to implement a __canonicalize_funcptr_for_compare in the kernel > > and EXPORT_SYMBOL it. >=20 > I thougt about that, but didn't do it this way because I didn't like the > approach to double libgcc's __canonicalize_funcptr_for_compare. Maybe > we'd simply find a way to EXPORT_SYMBOL libgcc's version of that one... I got a private reply to this part (which I accidentally /dev/null'ed) basically stating that the kernel should implement an own version of __canonicalize_funcptr_for_compare (instead of using that one which is in libgcc). Greping around reveals no own version in the Linux kernel so that one that is used with built-in function pointers already seems to be borrowed from libgcc. So a question remains: Shall we have an own version, or shall we stick wich gcc's version? I already do know that libgcc did bring some problems with it along (generate an athlon-aware compiler and then build a kernel for an original i386:-) But I do _not_ know if those problems got smashed... I think it would be most helpful to get some people's comments who are more into gcc... 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)); --SpiXHX+fVORj1nzn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+v7trHb1edYOZ4bsRAoaGAJ0VXnWOApbcsViDGoEyMAzjkAthrgCfbTH/ aMaZMuP+9gZ+b3qb012QDKc= =E2PK -----END PGP SIGNATURE----- --SpiXHX+fVORj1nzn-- From dave@hiauly1.hia.nrc.ca Mon May 12 15:58:48 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Mon, 12 May 2003 10:58:48 -0400 (EDT) Subject: [parisc-linux] [PATCH-2.5] Various cleanups In-Reply-To: <20030512132248.GU27494@lug-owl.de> from "Jan-Benedict Glaw" at May 12, 2003 03:22:48 pm Message-ID: <200305121458.h4CEwmom001051@hiauly1.hia.nrc.ca> > > I'm not applying these bits. It's just not reasonable to add (void *) > > casts to every function pointer comparison. I know Linus will reject it. > > We need to find a better way to fix this one -- and I suspect the right > > way is to implement a __canonicalize_funcptr_for_compare in the kernel > > and EXPORT_SYMBOL it. > > I thougt about that, but didn't do it this way because I didn't like the > approach to double libgcc's __canonicalize_funcptr_for_compare. Maybe > we'd simply find a way to EXPORT_SYMBOL libgcc's version of that one... No, you don't want to use the libgcc version as it is specific to user programs. A kernel version is needed. I think all that needs to be done is return the function pointer passed to it. It should totally disappear if inlined. Thus, __canonicalize_funcptr_for_compare could be defined in a header. It might actually be necessary to do function pointer canonicalization in the kernel in situations involving loadable modules. One would have to look at how the loader manages the plabels. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From Randolph Chung Mon May 12 16:36:59 2003 From: Randolph Chung (Randolph Chung) Date: Mon, 12 May 2003 08:36:59 -0700 Subject: [parisc-linux] [PATCH-2.5] Various cleanups In-Reply-To: <200305121458.h4CEwmom001051@hiauly1.hia.nrc.ca> References: <20030512132248.GU27494@lug-owl.de> <200305121458.h4CEwmom001051@hiauly1.hia.nrc.ca> Message-ID: <20030512153659.GK4509@tausq.org> > No, you don't want to use the libgcc version as it is specific to > user programs. A kernel version is needed. I think all that needs to > be done is return the function pointer passed to it. It should totally > disappear if inlined. Thus, __canonicalize_funcptr_for_compare could > be defined in a header. how does that work? __c_f_f_c is emitted by the compiler internally, right? how can we define an inline version of this function? randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From dave@hiauly1.hia.nrc.ca Mon May 12 17:24:21 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Mon, 12 May 2003 12:24:21 -0400 (EDT) Subject: [parisc-linux] [PATCH-2.5] Various cleanups In-Reply-To: <20030512153659.GK4509@tausq.org> from "Randolph Chung" at May 12, 2003 08:36:59 am Message-ID: <200305121624.h4CGOMq1001557@hiauly1.hia.nrc.ca> > how does that work? __c_f_f_c is emitted by the compiler internally, > right? how can we define an inline version of this function? Dooh, you are correct. I wrote a little test program and the libcall doesn't get inlined. So if no canonicalization is needed, you want something like: typedef int (*fptr_t) (void); unsigned int __canonicalize_funcptr_for_compare (fptr_t) __attribute__ ((visibility ("hidden"))); unsigned int __canonicalize_funcptr_for_compare (fptr) fptr_t fptr; { return (unsigned int)fptr; } The libgcc version is hidden. That's because shared libraries need their own copy which accesses the got table in the shared library. Probably in the kernel implementation, a single copy of the routine is sufficient and you don't want the hidden attibute. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From gmsoft@gentoo.org Mon May 12 22:51:57 2003 From: gmsoft@gentoo.org (Guy Martin) Date: Mon, 12 May 2003 23:51:57 +0200 Subject: [parisc-linux] gcc and -march=2.0 flag bug Message-ID: <200305122351.57449.gmsoft@gentoo.org> Hi All, I had some problems with gcc. When I set the CFLAGS/CXXFLAGS -march=2.0, most of the applications builded are b0rked. This occured on many stations. Using -march=1.1 works well. Is this a 'feature' of unimplemented 64bit userspace or is this a bug ? In case of a bug, what do you need to debug it. Regards -- Guy Martin Gentoo - HPPA port Lead / IPv6 team Lug Charleroi (Belgium) From Randolph Chung Mon May 12 22:58:37 2003 From: Randolph Chung (Randolph Chung) Date: Mon, 12 May 2003 14:58:37 -0700 Subject: [parisc-linux] gcc and -march=2.0 flag bug In-Reply-To: <200305122351.57449.gmsoft@gentoo.org> References: <200305122351.57449.gmsoft@gentoo.org> Message-ID: <20030512215837.GN4509@tausq.org> > I had some problems with gcc. When I set the CFLAGS/CXXFLAGS -march=2.0, most > of the applications builded are b0rked. This occured on many stations. Using > -march=1.1 works well. How are they "b0rked"? Can you be a bit more precise? > Is this a 'feature' of unimplemented 64bit userspace or is this a bug ? > > In case of a bug, what do you need to debug it. We compile pa20 32-bit kernels (e.g. for c3k) using 32-bit and -march=2.0. seems to work. Do you have a test case for what you think is broken? -march2.0 is really orthogonal to 64-bit userspace. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From dave@hiauly1.hia.nrc.ca Mon May 12 23:59:52 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Mon, 12 May 2003 18:59:52 -0400 (EDT) Subject: [parisc-linux] gcc and -march=2.0 flag bug In-Reply-To: <200305122351.57449.gmsoft@gentoo.org> from "Guy Martin" at May 12, 2003 11:51:57 pm Message-ID: <200305122259.h4CMxqqS003603@hiauly1.hia.nrc.ca> > In case of a bug, what do you need to debug it. See . A GCC PR should be submitted if you believe the problem is a compiler bug. Versions earlier than 3.3 are effectively dead, so I would recommend testing with a 3.3 snapshot. 3.3 will be released very soon, probably this week. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From willy@debian.org Tue May 13 13:44:38 2003 From: willy@debian.org (Matthew Wilcox) Date: Tue, 13 May 2003 13:44:38 +0100 Subject: [parisc-linux] Re: no screens found on C240 In-Reply-To: <005c01c3194a$8f0e01c0$980173c1@moviem.co.uk> References: <005c01c3194a$8f0e01c0$980173c1@moviem.co.uk> Message-ID: <20030513124438.GH29534@parcelfarce.linux.theplanet.co.uk> On Tue, May 13, 2003 at 01:24:11PM +0100, Alan Hunter wrote: > I can't get X started on a C240 and don't have sufficient background to get to grips with the problem. > > Here's what dmesg says: > STI GSC/PCI graphics driver version 0.9 > STI PCI graphic ROM found at f1e00000 (2048 kB), fb at f6000000 (32 MB) > STI word mode ROM at f1e00044, hpa at f6000000 > STI id 2fc1066b-9a02587, conforms to spec rev. 8.09 > STI device: HPA4552A > stifb: Unsupported gfx card id 0x2fc1066b A4552A is the FX2 card and is unsupported; I saw someone offering to swap an EG card (which is supported) for an FX card a couple of days ago on this list. Perhaps they're still interested? -- "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 rtodd@antipentium.com Tue May 13 14:50:01 2003 From: rtodd@antipentium.com (Richard Todd) Date: Tue, 13 May 2003 09:50:01 -0400 Subject: [parisc-linux] System hanging Message-ID: Hello all, I am currently running on a J5000 2000 root # uname -a Linux k2000 2.4.20-pa35 #2 SMP Sat May 10 10:36:26 EDT 2003 parisc unknown unknown GNU/Linux Gcc is as follows: k2000 root # gcc -v Reading specs from /usr/lib/gcc-lib/hppa2.0-unknown-linux-gnu/3.2.2/specs Configured with: /var/tmp/portage/gcc-3.2.2/work/gcc-3.2.2/configure --prefix=/usr --bindir=/usr/hppa2.0-unknown-linux-gnu/gcc-bin/3.2 --includedir=/usr/lib/gcc-lib/hppa2.0-unknown-linux-gnu/3.2.2/include --datadir=/usr/share/gcc-data/hppa2.0-unknown-linux-gnu/3.2 --mandir=/usr/share/gcc-data/hppa2.0-unknown-linux-gnu/3.2/man --infodir=/usr/share/gcc-data/hppa2.0-unknown-linux-gnu/3.2/info --enable-shared --host=hppa2.0-unknown-linux-gnu --target=hppa2.0-unknown-linux-gnu --with-system-zlib --enable-languages=c,c++,ada,f77,objc --enable-threads=posix --enable-long-long --disable-checking --enable-cstdio=stdio --enable-clocale=generic --enable-__cxa_atexit --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/hppa2.0-unknown-linux-gnu/3.2.2/incl ude/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext Thread model: posix gcc version 3.2.2 This issue I am having is during compiling andthing big the box has a tendency to just hang hard meaning power cord reboot. Has anyone seen this before. I have a gig of ram and it does not seem to be a memory issue. I am currently compiling KDE and it just hangs the box every now and then... Anyone ? From varenet@esiee.fr Tue May 13 15:39:14 2003 From: varenet@esiee.fr (=?ISO-8859-1?Q?Thibaut_VAR=C8NE?=) Date: Tue, 13 May 2003 16:39:14 +0200 Subject: [parisc-linux] System hanging In-Reply-To: Message-ID: cat /proc/version please (ie: did you build your kernel with gcc 3.2.2?) I've been running 12days straight of building gcc in loop while having=20= 2 setiathome instances running on a J5000 with 512M of RAM and=20 experienced no hangs, that was with 2.4.20-pa18 SMP 64bit, built with=20 gcc 3.0.4... oh, and fwiw: http://www.fr.parisc-linux.org/faq/kernelbug-howto.html Thibaut VARENE The PA/Linux ESIEE Team http://pateam.esiee.fr/ Le mardi, 13 mai 2003, =E0 15:50 Europe/Paris, Richard Todd a =E9crit : > Hello all, > I am currently running on a J5000 > 2000 root # uname -a > Linux k2000 2.4.20-pa35 #2 SMP Sat May 10 10:36:26 EDT 2003 parisc=20 > unknown > unknown GNU/Linux > > > This issue I am having is during compiling andthing big the box has a > tendency to just hang hard meaning power cord reboot. Has anyone seen=20= > this > before. I have a gig of ram and it does not seem to be a memory issue.=20= > I am > currently compiling KDE and it just hangs the box every now and = then... > Anyone ?=20= From rtodd@antipentium.com Tue May 13 15:55:20 2003 From: rtodd@antipentium.com (Richard Todd) Date: Tue, 13 May 2003 10:55:20 -0400 Subject: [parisc-linux] System hanging In-Reply-To: Message-ID: k2000 root # cat /proc/version Linux version 2.4.20-pa35 (root@cdimage) (gcc version 3.2.2) #2 SMP Sat May 10 10:36:26 EDT 2003 On 5/13/03 10:39 AM, "Thibaut VAR=C8NE" wrote: > cat /proc/version please (ie: did you build your kernel with gcc 3.2.2?) >=20 > I've been running 12days straight of building gcc in loop while having > 2 setiathome instances running on a J5000 with 512M of RAM and > experienced no hangs, that was with 2.4.20-pa18 SMP 64bit, built with > gcc 3.0.4... >=20 > oh, and fwiw: > http://www.fr.parisc-linux.org/faq/kernelbug-howto.html >=20 >=20 > Thibaut VARENE > The PA/Linux ESIEE Team > http://pateam.esiee.fr/ >=20 > Le mardi, 13 mai 2003, =E0 15:50 Europe/Paris, Richard Todd a =E9crit : >=20 >> Hello all, >> I am currently running on a J5000 >> 2000 root # uname -a >> Linux k2000 2.4.20-pa35 #2 SMP Sat May 10 10:36:26 EDT 2003 parisc >> unknown >> unknown GNU/Linux >>=20 >>=20 >> This issue I am having is during compiling andthing big the box has a >> tendency to just hang hard meaning power cord reboot. Has anyone seen >> this >> before. I have a gig of ram and it does not seem to be a memory issue. >> I am >> currently compiling KDE and it just hangs the box every now and then... >> Anyone ?=20 >=20 From gmsoft@gentoo.org Tue May 13 17:53:03 2003 From: gmsoft@gentoo.org (Guy Martin) Date: Tue, 13 May 2003 18:53:03 +0200 Subject: [parisc-linux] gcc and -march=2.0 flag bug Message-ID: <200305131853.03798.gmsoft@gentoo.org> --Boundary-00=_vLSw+yLci4siwBX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline > How are they "b0rked"? Can you be a bit more precise? I've attached the the end of the compilation log of groff which fail with -march=2.0 in CXXFLAGS. The same compilation works perfectly without this flags or with -march=1.1 instead. > We compile pa20 32-bit kernels (e.g. for c3k) using 32-bit and > -march=2.0. seems to work. Do you have a test case for what you think > is broken? -march2.0 is really orthogonal to 64-bit userspace. After looking again more closely, it seems that only g++ is affected by this bug. The kernel on the station was also compiled with -march=2.0. About the test case, I don't have the time to look more to this problem but I can give you a access to the box since it's a test box. -- Guy Martin Gentoo - HPPA port Lead / IPv6 team Lug Charleroi (Belgium) --Boundary-00=_vLSw+yLci4siwBX Content-Type: text/x-log; charset="iso-8859-1"; name="groff-march2.0-short.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="groff-march2.0-short.log" rm -f $m-wrap; \ if test "$m" = an; then \ echo .do mso andoc.tmac >>$m-wrap; \ fi; \ echo .cp 1 >>$m-wrap; \ echo .so $m >>$m-wrap; \ done; \ fi touch stamp-wrap for f in man.tmac ms.tmac; do \ rm -f $f-sed; \ sed -e "s;@TMAC_AN_PREFIX@;;g" \ -e "s;@TMAC_S_PREFIX@;;g" \ /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/tmac/$f > $f-sed; \ done touch stamp-sed Making groff_ms.n from groff_ms.man Making groff_man.n from groff_man.man Making groff_me.n from groff_me.man Making groff_mdoc.n from groff_mdoc.man Making groff_trace.n from groff_trace.man Making groff_www.n from groff_www.man make[2]: Leaving directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/tmac' make[2]: Entering directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/src/utils/afmtodit' if test -n "/usr/bin/perl"; then \ sed -e "s|/usr/bin/perl|/usr/bin/perl|" \ -e "s|@VERSION@|1.18.1|" \ /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/src/utils/afmtodit/afmtodit.pl >afmtodit; \ else \ sed -e "s|@VERSION@|1.18.1|" \ /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/src/utils/afmtodit/afmtodit.pl afmtodit; \ fi chmod +x afmtodit Making afmtodit.n from afmtodit.man make[2]: Leaving directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/src/utils/afmtodit' make[2]: Entering directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/src/roff/grog' rm -f grog sed -e "s|@g@||g" \ -e "s|@VERSION@|1.18.1|" \ -e 1s/a/a/ /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/src/roff/grog/grog.sh >grog chmod +x grog Making grog.n from grog.man make[2]: Leaving directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/src/roff/grog' make[2]: Entering directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/src/roff/nroff' rm -f nroff sed -e "s|@BINDIR@|/usr/bin|g" \ -e 1s/a/a/ \ -e "s|@VERSION@|1.18.1|" /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/src/roff/nroff/nroff.sh >nroff chmod +x nroff Making nroff.n from nroff.man make[2]: Leaving directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/src/roff/nroff' make[2]: Entering directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/mm' rm -f mmroff sed -e 's;/usr/bin/perl;/usr/bin/perl;' /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/mm/mmroff.pl >mmroff chmod +x mmroff Making mmroff.n from mmroff.man Making groff_mm.n from groff_mm.man Making groff_mmse.n from groff_mmse.man make[2]: Leaving directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/mm' make[2]: Entering directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/pic2graph' rm -f pic2graph; \ sed -e "s|@g@||g" \ -e "s|@VERSION@|1.18.1|" \ -e 1s/a/a/ /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/pic2graph/pic2graph.sh >pic2graph; \ chmod +x pic2graph Making pic2graph.n from pic2graph.man make[2]: Leaving directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/pic2graph' make[2]: Entering directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/eqn2graph' rm -f eqn2graph; \ sed -e "s|@g@||g" \ -e "s|@VERSION@|1.18.1|" \ -e 1s/a/a/ /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/eqn2graph/eqn2graph.sh >eqn2graph; \ chmod +x eqn2graph Making eqn2graph.n from eqn2graph.man make[2]: Leaving directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/eqn2graph' make[2]: Entering directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/groffer' rm -f groffer; \ sed -e "s|@g@||g" \ -e "s|@VERSION@|1.18.1|" \ -e 1s/a/a/ /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/groffer/groffer.sh >groffer; \ chmod +x groffer Making groffer.n from groffer.man make[2]: Leaving directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/groffer' make[2]: Entering directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/mom' test -d examples || /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/mkinstalldirs examples test -f penguin.ps || cp /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/mom/examples/penguin.ps . GROFF_COMMAND_PREFIX=''; export GROFF_COMMAND_PREFIX; GROFF_BIN_PATH=`echo /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/src/roff/groff /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/src/roff/troff /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/src/devices/grops | sed -e 's| *|:|g'`; export GROFF_BIN_PATH; /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/src/roff/groff/groff -F/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/font -F/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/font -M/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/tmac -M/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/tmac -M/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/mom -Tps -mom examples/letter.mom >examples/letter.ps troff: Failed assertion at line 654, file `number.cc'. /var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/src/roff/groff/groff: troff: Aborted grops::5:warning: no final `x stop' command make[2]: *** [examples/letter.ps] Error 2 make[2]: Leaving directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1/contrib/mom' make[1]: *** [contrib/mom] Error 2 make[1]: Leaving directory `/var/tmp/portage/groff-1.18.1-r2/work/groff-1.18.1' make: *** [all] Error 2 !!! ERROR: sys-apps/groff-1.18.1-r2 failed. !!! Function src_compile, Line 57, Exitcode 2 !!! (no error message) --Boundary-00=_vLSw+yLci4siwBX-- From dave@hiauly1.hia.nrc.ca Tue May 13 18:53:48 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Tue, 13 May 2003 13:53:48 -0400 (EDT) Subject: [parisc-linux] gcc and -march=2.0 flag bug In-Reply-To: <200305131853.03798.gmsoft@gentoo.org> from "gmsoft@gentoo.org>" at May 13, 2003 06:53:03 pm Message-ID: <200305131753.h4DHrmPJ007374@hiauly1.hia.nrc.ca> > I've attached the the end of the compilation log of groff which fail with > -march=2.0 in CXXFLAGS. The same compilation works perfectly without this > flags or with -march=1.1 instead. [...] > troff: Failed assertion at line 654, file `number.cc'. You didn't say which compiler version that you were using. As I mentioned, the 3.2 branch is closed for bug fixes. The failure doesn't occur with 3.3. It has a number of -march=2.0 fixes. The problem could be C++ related as well. There are a huge number of C++ fixes in 3.3 relative to 3.3. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From gmsoft@gentoo.org Tue May 13 19:03:28 2003 From: gmsoft@gentoo.org (Guy Martin) Date: Tue, 13 May 2003 20:03:28 +0200 Subject: [parisc-linux] gcc and -march=2.0 flag bug In-Reply-To: <200305131753.h4DHrmPJ007374@hiauly1.hia.nrc.ca> References: <200305131753.h4DHrmPJ007374@hiauly1.hia.nrc.ca> Message-ID: <200305132003.28348.gmsoft@gentoo.org> > You didn't say which compiler version that you were using. Yes sorry, I forgot. I use gcc-3.2.2. I'll try gcc-3.3 asap. Thanks > As I mentioned, the 3.2 branch is closed for bug fixes. The failure > doesn't occur with 3.3. It has a number of -march=2.0 fixes. The > problem could be C++ related as well. There are a huge number of C++ > fixes in 3.3 relative to 3.3. > > Dave -- Guy Martin Gentoo - HPPA port Lead / IPv6 team Lug Charleroi (Belgium) From Randolph Chung Tue May 13 19:18:05 2003 From: Randolph Chung (Randolph Chung) Date: Tue, 13 May 2003 11:18:05 -0700 Subject: [parisc-linux] gcc-3.3 and c++ In-Reply-To: <200305131753.h4DHrmPJ007374@hiauly1.hia.nrc.ca> References: <200305131853.03798.gmsoft@gentoo.org> <200305131753.h4DHrmPJ007374@hiauly1.hia.nrc.ca> Message-ID: <20030513181805.GF548@tausq.org> > As I mentioned, the 3.2 branch is closed for bug fixes. The failure > doesn't occur with 3.3. It has a number of -march=2.0 fixes. The > problem could be C++ related as well. There are a huge number of C++ > fixes in 3.3 relative to 3.3. Reading this inspired us to try compiling the 'menu' debian package with g++-3.3. Historically this package has been very problematic on hppa because of its use of exceptions. It's been broken for a very long time (couple years?).... but with latest g++-3.3 it actually compiles and works!! Dave, many many thanks again for all your work on gcc. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From dave@hiauly1.hia.nrc.ca Tue May 13 20:16:49 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Tue, 13 May 2003 15:16:49 -0400 (EDT) Subject: [parisc-linux] gcc-3.3 and c++ In-Reply-To: <20030513181805.GF548@tausq.org> from "Randolph Chung" at May 13, 2003 11:18:05 am Message-ID: <200305131916.h4DJGnpg007743@hiauly1.hia.nrc.ca> > > As I mentioned, the 3.2 branch is closed for bug fixes. The failure > > doesn't occur with 3.3. It has a number of -march=2.0 fixes. The > > problem could be C++ related as well. There are a huge number of C++ > > fixes in 3.3 relative to 3.3. > > Reading this inspired us to try compiling the 'menu' debian package > with g++-3.3. Historically this package has been very problematic on > hppa because of its use of exceptions. It's been broken for a very long > time (couple years?).... but with latest g++-3.3 it actually compiles > and works!! I should also add that I've built lyx, another large C++ app, under hpux and it seems to work. I've also built it under linux but I haven't tested it (no X). Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From dukatkabila_s22@rediffmail.com Tue May 13 22:58:05 2003 From: dukatkabila_s22@rediffmail.com (Dukat Kabila) Date: Tue, 13 May 2003 23:58:05 +0200 Subject: [parisc-linux] DUKAT KABILA(Jnr) Message-ID: <20030513215803.2C78B482D@dsl2.external.hp.com> This is a multi-part message in MIME format --153a78f8-a4e1-4c09-bea2-a4b97e7a3b02 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > MR DUKAT KABILA 0031+615-421-228 > REQUEST FOR URGENT BUSINESS ASSISTANCE > >Your contact was availed to me by the chamber of commerce. It was given to me because of my diplomatic status as I did not disclose the actual reasons for which I sought your contact. But I was assured That you are reputable and trustworthy if you will be of assistance. I am Laurent DUKAT KABILA (Jnr) the second son of Late President LAURENT DESIRE KABILA the immediate Past president of the DEMOCRATIC REPUBLIC OF CONGO in Africa who was murdered by his opposition through his personal bodyguards in his bedroom on Tuesday 16th >January, 2001.I have the privilege of being mandated by my father colleagues to seek your immediate and urgent co-operation to receive into your bank account the sum of US$25m.(twenty-five million Dollars) and some thousands carats of Diamond. This money and treasures was lodged in a vault with a security firm in Europe and South-Africa. > >SOURCES OF DIAMONDS AND FUND >In August 2000, my father as a defence minister and president has a meeting with his cabinet and armychief about the defence budget for 2000 to 2001 which was US $700m. so he directed one of his best friend. Frederic Kibasa Maliba who was a minister of mines and a political party leader known as the Union Sacree de, I=11 opposition radicale et ses allies (USORAL) to buy arms with US $200m on 5th January 2001; for him to finalized the arms deal, >my father was murdered. f.K. Maliba (FKM) and I have decided to keep the money with a foreigner after which he will use it to contest for the political election. Inspite of all this we have >resolved to present your or your company for the firm to pay it into your nominated account the above sum and diamonds. This transaction should be finalized within seven (7) working days and for your co-operation and partnership, we have unanimously agreed that you will be entitled to 5.5% of the money when successfully receive it in your account. The nature of your >business is not relevant to the successful execution of this transaction what we require is your total co-operation and commitment to = ensure 100% risk-free transaction at both ends and to protect the persons involved in this transaction, strict confidence and utmost secrecy is >required even after the successful conclusion of this transaction. If this proposal is acceptable to you, kindly provide me with your personal telephone and fax through my E-mail box for immediate commencement = of the transaction. >All correspondence is for the attention of my counsel: > >I count on your honour to keep my secret, SECRET. >Looking forward for your urgent reply >Thanks . >Best Regards > >DUKAT KABILA(Jnr) > --153a78f8-a4e1-4c09-bea2-a4b97e7a3b02-- From jbglaw@lug-owl.de Tue May 13 23:39:02 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Wed, 14 May 2003 00:39:02 +0200 Subject: [parisc-linux] Re: [parisc-linux-cvs] build-tools bame In-Reply-To: <20030513222102.33F00482D@dsl2.external.hp.com> References: <20030513222102.33F00482D@dsl2.external.hp.com> Message-ID: <20030513223902.GK27494@lug-owl.de> --lJhfsPy4o8B7pjPr Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2003-05-13 16:21:02 -0600, Paul Bame wrote in message <20030513222102.33F00482D@dsl2.external.hp.com>: > CVSROOT: /var/cvs > Module name: build-tools > Changes by: bame 03/05/13 16:21:02 >=20 > Added files: > . : cvs-mkpatch=20 >=20 > Log message: > initial rev -- make patch from modified cvs dir =2E..as if you had read my thoughts, I'm currently planing a roadmap for pushing all ports upstream to Linus and looking for what work I could do. Please read it at http://www.lug-owl.de/~jbglaw/linux-ports/ and comment on it! Ob, I'm still waiting for your lock to vanish: cvs server: [08:07:34] waiting for bame's lock in /var/cvs/obsolete/binutil= s-2.10 cvs server: [08:08:04] waiting for bame's lock in /var/cvs/obsolete/binutil= s-2.10 cvs server: [08:08:34] waiting for bame's lock in /var/cvs/obsolete/binutil= s-2.10 Please remove the lock or the whole ./obsolete/ directory. 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)); --lJhfsPy4o8B7pjPr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+wXQGHb1edYOZ4bsRAlDMAJ4jAk+i/37dbTwKGotI5whCE7eGvwCeMHsk ZaiLCYZ2kK5tnfANpryOwmI= =riCF -----END PGP SIGNATURE----- --lJhfsPy4o8B7pjPr-- From willy@debian.org Tue May 13 23:50:22 2003 From: willy@debian.org (Matthew Wilcox) Date: Tue, 13 May 2003 23:50:22 +0100 Subject: [parisc-linux] Re: [parisc-linux-cvs] build-tools bame In-Reply-To: <20030513223902.GK27494@lug-owl.de> References: <20030513222102.33F00482D@dsl2.external.hp.com> <20030513223902.GK27494@lug-owl.de> Message-ID: <20030513225022.GQ29534@parcelfarce.linux.theplanet.co.uk> On Wed, May 14, 2003 at 12:39:02AM +0200, Jan-Benedict Glaw wrote: > ...as if you had read my thoughts, I'm currently planing a roadmap for > pushing all ports upstream to Linus and looking for what work I could > do. Please read it at http://www.lug-owl.de/~jbglaw/linux-ports/ and > comment on it! Well, it seems like a complete lie to me. I think pretty much every architecture on your `really small userbase' list would take issue with being placed there. In particular, I think PPC is the second-largest Linux userbase after x86. The PA-RISC port doesn't have much in the way of tweaks to common drivers. I don't understand why you say for 2.4: "Nearly up to date, many patches need to go upstream" and for 2.5: "Not really up to date, but not far away; some work needs to be done..." I don't know whether you're claiming the kernel.org tree is uptodate or whether our repository is up to date. Neither statement seems true for either case. -- "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 derekengelhaupt@rocketmail.com Wed May 14 00:44:19 2003 From: derekengelhaupt@rocketmail.com (Derek Engelhaupt) Date: Tue, 13 May 2003 16:44:19 -0700 (PDT) Subject: [parisc-linux] Re: no screens found on C240 In-Reply-To: <20030513124438.GH29534@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030513234419.33129.qmail@web12501.mail.yahoo.com> --0-1582450767-1052869459=:32197 Content-Type: text/plain; charset=us-ascii It was me offering the trade, but I think his FX2 is GSC and not PCI like I need. I could be wrong though. derek Matthew Wilcox wrote: On Tue, May 13, 2003 at 01:24:11PM +0100, Alan Hunter wrote: > I can't get X started on a C240 and don't have sufficient background to get to grips with the problem. > > Here's what dmesg says: > STI GSC/PCI graphics driver version 0.9 > STI PCI graphic ROM found at f1e00000 (2048 kB), fb at f6000000 (32 MB) > STI word mode ROM at f1e00044, hpa at f6000000 > STI id 2fc1066b-9a02587, conforms to spec rev. 8.09 > STI device: HPA4552A > stifb: Unsupported gfx card id 0x2fc1066b A4552A is the FX2 card and is unsupported; I saw someone offering to swap an EG card (which is supported) for an FX card a couple of days ago on this list. Perhaps they're still interested? -- "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 _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux --------------------------------- Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. --0-1582450767-1052869459=:32197 Content-Type: text/html; charset=us-ascii
It was me offering the trade, but I think his FX2 is GSC and not PCI like I need.  I could be wrong though.
 
derek

Matthew Wilcox <willy@debian.org> wrote:
On Tue, May 13, 2003 at 01:24:11PM +0100, Alan Hunter wrote:
> I can't get X started on a C240 and don't have sufficient background to get to grips with the problem.
>
> Here's what dmesg says:
> STI GSC/PCI graphics driver version 0.9
> STI PCI graphic ROM found at f1e00000 (2048 kB), fb at f6000000 (32 MB)
> STI word mode ROM at f1e00044, hpa at f6000000
> STI id 2fc1066b-9a02587, conforms to spec rev. 8.09
> STI device: HPA4552A
> stifb: Unsupported gfx card id 0x2fc1066b

A4552A is the FX2 card and is unsupported; I saw someone offering to
swap an EG card (which is supported) for an FX card a couple of days
ago on this list. Perhaps they're still interested?

--
"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
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo. --0-1582450767-1052869459=:32197-- From rtodd@antipentium.com Wed May 14 00:52:51 2003 From: rtodd@antipentium.com (Richard Todd) Date: Tue, 13 May 2003 19:52:51 -0400 Subject: [parisc-linux] Re: no screens found on C240 In-Reply-To: <20030513234419.33129.qmail@web12501.mail.yahoo.com> Message-ID: > 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. --B_3135700372_27098146 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I just came onto a few C180s if anyone wants one but I am in the Philadelphia area and really do not want to ship any more of these...so if you want come get On 5/13/03 7:44 PM, "Derek Engelhaupt" wrote: > It was me offering the trade, but I think his FX2 is GSC and not PCI like I > need. I could be wrong though. > > derek > > Matthew Wilcox wrote: >> On Tue, May 13, 2003 at 01:24:11PM +0100, Alan Hunter wrote: >>> > I can't get X started on a C240 and don't have sufficient background to >>> get to grips with the problem. >>> > >>> > Here's what dmesg says: >>> > STI GSC/PCI graphics driver version 0.9 >>> > STI PCI graphic ROM found at f1e00000 (2048 kB), fb at f6000000 (32 MB) >>> > STI word mode ROM at f1e00044, hpa at f6000000 >>> > STI id 2fc1066b-9a02587, conforms to spec rev. 8.09 >>> > STI device: HPA4552A >>> > stifb: Unsupported gfx card id 0x2fc1066b >> >> A4552A is the FX2 card and is unsupported; I saw someone offering to >> swap an EG card (which is supported) for an FX card a couple of days >> ago on this list. Perhaps they're still interested? --B_3135700372_27098146 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [parisc-linux] Re: no screens found on C240 I just came onto a few C180s if anyone wants one but I= am in the Philadelphia area and really do not want to ship any more of thes= e...so if you want come get



On 5/13/03 7:44 PM, "Derek Engelhaupt" <derekengelhaupt@rocket= mail.com> wrote:

It was me offering the trade, but I= think his FX2 is GSC and not PCI like I need.  I could be wrong though= .
 
derek

Matthew Wilcox <willy@debian.org> wrote:
On Tue, May 13, 2003 at 01:24:11PM = +0100, Alan Hunter wrote:
> I can't get X started on a C240 and don't have sufficient background t= o get to grips with the problem.
>
> Here's what dmesg says:
> STI GSC/PCI graphics driver version 0.9
> STI PCI graphic ROM found at f1e00000 (2048 kB), fb at f6000000 (32 MB= )
> STI word mode ROM at f1e00044, hpa at f6000000
> STI id 2fc1066b-9a02587, conforms to spec rev. 8.09
> STI device: HPA4552A
> stifb: Unsupported gfx card id 0x2fc1066b

A4552A is the FX2 card and is unsupported; I saw someone offering to
swap an EG card (which is supported) for an FX card a couple of days
ago on this list. Perhaps they're still interested?

 --B_3135700372_27098146-- From grundler@parisc-linux.org Wed May 14 01:43:27 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Tue, 13 May 2003 18:43:27 -0600 Subject: [parisc-linux] Re: no screens found on C240 In-Reply-To: <20030513234419.33129.qmail@web12501.mail.yahoo.com> References: <20030513124438.GH29534@parcelfarce.linux.theplanet.co.uk> <20030513234419.33129.qmail@web12501.mail.yahoo.com> Message-ID: <20030514004327.GB20429@dsl2.external.hp.com> On Tue, May 13, 2003 at 04:44:19PM -0700, Derek Engelhaupt wrote: > It was me offering the trade, but I think his FX2 is GSC and not PCI like > I need. I could be wrong though. I think HP FX[E246] are PCI only. C240 has 64-bit wide PCI slots. grant From caslivkoff@speakeasy.net Wed May 14 02:17:47 2003 From: caslivkoff@speakeasy.net (Chuck Slivkoff) Date: Tue, 13 May 2003 21:17:47 -0400 Subject: [parisc-linux] Re: no screens found on C240 In-Reply-To: <20030514004327.GB20429@dsl2.external.hp.com> Message-ID: On Tuesday, May 13, 2003, at 20:43 US/Eastern, Grant Grundler wrote: > On Tue, May 13, 2003 at 04:44:19PM -0700, Derek Engelhaupt wrote: >> It was me offering the trade, but I think his FX2 is GSC and not PCI >> like >> I need. I could be wrong though. > > I think HP FX[E246] are PCI only. Correct. As are the FX-5 & FX-10. The Vis-EG is the odd one: there were both GSC & PCI versions. From Randolph Chung Wed May 14 06:52:25 2003 From: Randolph Chung (Randolph Chung) Date: Tue, 13 May 2003 22:52:25 -0700 Subject: [parisc-linux] more on canonicalize_funcptr_for_compare Message-ID: <20030514055225.GJ548@tausq.org> The latest glibc on hppa (2.3.1-17) was compiled with a gcc-3.2 which has the __canonicalize_funcptr_for_compare patch backported from gcc-3.3 ... with this new version, some programs will die on startup (e.g. vim). I traced to a segfault in __canonicalize_funcptr_for_compare. The testcase below illustrates the problem: ===== typedef void (*func_t)(void); #define N ((func_t)2) void foo(void) {}; int main(int argc, char **argv) { return (foo == N); } ===== this program segfaults when run with: (gdb) run Starting program: /home/tausq/sig Program received signal SIGSEGV, Segmentation fault. 0x00010530 in __canonicalize_funcptr_for_compare () (gdb) bt #0 0x00010530 in __canonicalize_funcptr_for_compare () #1 0x000104bc in main (argc=1, argv=0xfaf001b8) at sig.c:9 it seems like the 2 in the constant (N) confuses the comparision routine. If I change it to 1, everything is ok.... I don't really understand this tho, because the code for __c_f_f_c has something like: if ((int) fptr == -1 || (unsigned int) fptr < 4096 || !((int) fptr & 2)) return (unsigned int) fptr; so, why doesn't that match the second || case and exit? (gdb disassmbly shows that the code tries to dereference the fptr argument and segfaults) randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From jbglaw@lug-owl.de Wed May 14 07:54:43 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Wed, 14 May 2003 08:54:43 +0200 Subject: [parisc-linux] Re: [parisc-linux-cvs] build-tools bame In-Reply-To: <20030513225022.GQ29534@parcelfarce.linux.theplanet.co.uk> References: <20030513222102.33F00482D@dsl2.external.hp.com> <20030513223902.GK27494@lug-owl.de> <20030513225022.GQ29534@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030514065443.GL27494@lug-owl.de> --YrHeAUbOAX9OMs3W Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2003-05-13 23:50:22 +0100, Matthew Wilcox wrote in message <20030513225022.GQ29534@parcelfarce.linux.theplanet.co.uk>: > On Wed, May 14, 2003 at 12:39:02AM +0200, Jan-Benedict Glaw wrote: > > ...as if you had read my thoughts, I'm currently planing a roadmap for > > pushing all ports upstream to Linus and looking for what work I could > > do. Please read it at http://www.lug-owl.de/~jbglaw/linux-ports/ and > > comment on it! >=20 > I think pretty much every architecture on your `really small userbase' > list would take issue with being placed there. In particular, I think > PPC is the second-largest Linux userbase after x86. I'm not looking for "mainstream" parts (like current PowerMACs) but for the ports/boards which are problematic. And some of the rare boards *do* have problems. For MIPS, even some boards got removed some time ago and there are more which may follow. So please, don't get me wrong here. Some boards do work quite good most og the time (taking current port's source trees), some do not. Simply take it as "PeeCee is less bug prone than my super-rare MIPS/PPC/whatever eval board". > The PA-RISC port doesn't have much in the way of tweaks to common drivers. "Not much" means there are some. These should go upstream at some time, or we may need to get a better way to deal with specific things. As the (E)ISA bus in Indigo2 is getting available, there may be some things that need to get cleaned up in ISA code. Soma counts here... > I don't understand why you say for 2.4: >=20 > "Nearly up to date, many patches need to go upstream" Everything synced up (maybe except yesterday's work)? > and for 2.5: >=20 > "Not really up to date, but not far away; some work needs to be done..." Well, I think it's basically about accepting or not accepting the fact that some archs/boards are being developed without syncing "too early" with upstream. This leads to: - I need to have more than one source tree laying around. - Unintended breakages show up too late. - Unintended conflicts may arise from syncing up later than "now". For me, I'd like to have _one_ tree which works in all situations (except yesterday's work...). While whining for that, I'm also asking for hints what _I_ can do to make this happen. Parisc is even one of the more "simpler" ports to sync up... 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)); --YrHeAUbOAX9OMs3W Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+wegzHb1edYOZ4bsRAi8MAJ94NS8KULmirKv/k4STopd++Vi+nQCbBjrL Pd+FMfT6NUkWFQF16WZMNJs= =kDwz -----END PGP SIGNATURE----- --YrHeAUbOAX9OMs3W-- From jsoe0708@tiscali.be Wed May 14 12:47:19 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Wed, 14 May 2003 13:47:19 +0200 Subject: [parisc-linux] RE: Dump module patche. In-Reply-To: <3EB8AF58.7040900@admin.france.hp.com> Message-ID: <3EC0FF2300000638@ocpmta7.freegates.net> Hi Bruno, > >Attachment: dump_modules-2.4.20-pa32.patch2 > I apply it against last 2.4.20-pa35 (do not have any more pa22 :( ) (just 2 hunk to remove). Unfortunately it failed to compile with following message: `gcc-3.0 -print-libgcc-file-name` /usr/src/LKCD/hppa/linux-2.4.20-pa35-lkcd/arch/parisc/lib/lib.a /usr/src/LKCD/hppa/linux-2.4.20-pa35-lkcd/lib/lib.a \ --end-group \ -o vmlinux fs/fs.o(.debug_info+0x6fbaf): undefined reference to `.L1225' make: *** [vmlinux] Error 1 (Sorry I already met this kind of pb but do not remember how to solve :() Thanks for your undertand, Joel PS: No more support of compression (I tried libz2 but it do not found some object at ld time)? --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From willy@debian.org Wed May 14 14:46:50 2003 From: willy@debian.org (Matthew Wilcox) Date: Wed, 14 May 2003 14:46:50 +0100 Subject: [parisc-linux] more on canonicalize_funcptr_for_compare In-Reply-To: <20030514055225.GJ548@tausq.org> References: <20030514055225.GJ548@tausq.org> Message-ID: <20030514134650.GC6859@parcelfarce.linux.theplanet.co.uk> On Tue, May 13, 2003 at 10:52:25PM -0700, Randolph Chung wrote: > The latest glibc on hppa (2.3.1-17) was compiled with a gcc-3.2 which > has the __canonicalize_funcptr_for_compare patch backported from gcc-3.3 > ... with this new version, some programs will die on startup (e.g. vim). > I traced to a segfault in __canonicalize_funcptr_for_compare. > > The testcase below illustrates the problem: > > ===== > typedef void (*func_t)(void); > > #define N ((func_t)2) > > void foo(void) {}; > > int main(int argc, char **argv) > { > return (foo == N); > } > ===== > > this program segfaults when run with: > > (gdb) run > Starting program: /home/tausq/sig > > Program received signal SIGSEGV, Segmentation fault. > 0x00010530 in __canonicalize_funcptr_for_compare () > (gdb) bt > #0 0x00010530 in __canonicalize_funcptr_for_compare () > #1 0x000104bc in main (argc=1, argv=0xfaf001b8) at sig.c:9 > > it seems like the 2 in the constant (N) confuses the comparision > routine. If I change it to 1, everything is ok.... I don't really > understand this tho, because the code for __c_f_f_c has something like: > > if ((int) fptr == -1 || (unsigned int) fptr < 4096 || !((int) fptr & 2)) > return (unsigned int) fptr; > > so, why doesn't that match the second || case and exit? (gdb > disassmbly shows that the code tries to dereference the fptr argument > and segfaults) Even if this were fixed, it seems like a quality of implementation issue. Basically, we're saying that if none of these conditions are met, it's safe to dereference this pointer, and I'm sure we'll find people stuffing other magic values into pointers. I see three options: 1) Continue with this, accepting that some badly written software won't run. 2) Install a signal handler that handles the segfault (we can lose two of the tests this way, so it'll be faster in the common case) 3) Change the ABI. Make it so we always have unique PLabels. Recompile anything necessary. -- "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 Randolph Chung Wed May 14 16:04:01 2003 From: Randolph Chung (Randolph Chung) Date: Wed, 14 May 2003 08:04:01 -0700 Subject: [parisc-linux] more on canonicalize_funcptr_for_compare In-Reply-To: <20030514055225.GJ548@tausq.org> References: <20030514055225.GJ548@tausq.org> Message-ID: <20030514150401.GM548@tausq.org> > if ((int) fptr == -1 || (unsigned int) fptr < 4096 || !((int) fptr & 2)) > return (unsigned int) fptr; > > so, why doesn't that match the second || case and exit? (gdb > disassmbly shows that the code tries to dereference the fptr argument > and segfaults) sigh, after some sleep i realize that i was looking at the real 3.3 tree instead of my backport, and in the current 3.2 patch the second test is missing.... (because it was derived from an earlier snapshot of jda's patch) i'll send an update to debian-gcc... sorry about this. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From jsoe0708@tiscali.be Wed May 14 17:40:30 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Wed, 14 May 2003 18:40:30 +0200 Subject: [parisc-linux] [PATCH-2.5] Various cleanups In-Reply-To: <200305121624.h4CGOMq1001557@hiauly1.hia.nrc.ca> Message-ID: <3EC0FF230000091A@ocpmta7.freegates.net> >> how does that work? __c_f_f_c is emitted by the compiler internally, >> right? how can we define an inline version of this function? > >Dooh, you are correct. I wrote a little test program and the libcall >doesn't get inlined. > >So if no canonicalization is needed, you want something like: > >typedef int (*fptr_t) (void); > >unsigned int __canonicalize_funcptr_for_compare (fptr_t) > __attribute__ ((visibility ("hidden"))); > >unsigned int >__canonicalize_funcptr_for_compare (fptr) > fptr_t fptr; >{ > return (unsigned int)fptr; >} > >The libgcc version is hidden. That's because shared libraries need >their own copy which accesses the got table in the shared library. >Probably in the kernel implementation, a single copy of the routine >is sufficient and you don't want the hidden attibute. > Hi all, I just try to build a kernel with following stuff: add first include/asm-parisc/fptr.h: typedef int (*fptr_t) (void); extern unsigned int __canonicalize_funcptr_for_compare (fptr_t) __attribute__ ((visibility ("hidden"))); and arch/parisc/lib/fptr.c #include unsigned int __canonicalize_funcptr_for_compare (fptr) fptr_t fptr; { return (unsigned int) fptr; } also arch/parisc/kernel/parisc_ksyms.c: [...] #include EXPORT_SYMBOL(__canonicalize_funcptr_for_compare); to finaly arch/parisc/lib/Makefile: -obj-y := lusercopy.o bitops.o checksum.o io.o memset.o +obj-y := lusercopy.o bitops.o checksum.o io.o memset.o fptr.o The compile seems ok but knowing not yet anything about modules I would appreciate your advises before trying to boot it. Thanks, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From dave@hiauly1.hia.nrc.ca Wed May 14 17:43:33 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Wed, 14 May 2003 12:43:33 -0400 (EDT) Subject: [parisc-linux] more on canonicalize_funcptr_for_compare In-Reply-To: <20030514134650.GC6859@parcelfarce.linux.theplanet.co.uk> from "Matthew Wilcox" at May 14, 2003 02:46:50 pm Message-ID: <200305141643.h4EGhX8X012117@hiauly1.hia.nrc.ca> > > if ((int) fptr == -1 || (unsigned int) fptr < 4096 || !((int) fptr & 2)) > > return (unsigned int) fptr; > > > > so, why doesn't that match the second || case and exit? (gdb > > disassmbly shows that the code tries to dereference the fptr argument > > and segfaults) > > Even if this were fixed, it seems like a quality of implementation issue. > Basically, we're saying that if none of these conditions are met, it's > safe to dereference this pointer, and I'm sure we'll find people stuffing > other magic values into pointers. The magic values were arbitrarily chosen to be the same as under hpux. > I see three options: > > 1) Continue with this, accepting that some badly written software won't > run. I'm not going to lose sleep on this one. Obviously, using implementation dependent features of function pointers is not portable. > 2) Install a signal handler that handles the segfault (we can lose two of > the tests this way, so it'll be faster in the common case) > > 3) Change the ABI. Make it so we always have unique PLabels. Recompile > anything necessary. It would be nice to have the 32 and 64 bit ABIs the same in this respect. However, this requires non trivial changes to the dynamic loader and linker. I'm not sure what the extra overhead would be. Function pointer comparisons aren't done very often in user code. 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 Wed May 14 19:01:37 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Wed, 14 May 2003 14:01:37 -0400 (EDT) Subject: [parisc-linux] RE: Dump module patche. In-Reply-To: <3EC0FF2300000638@ocpmta7.freegates.net> from "Joel Soete" at May 14, 2003 01:47:19 pm Message-ID: <200305141801.h4EI1ca3012585@hiauly1.hia.nrc.ca> > >Attachment: dump_modules-2.4.20-pa32.patch2 > > > I apply it against last 2.4.20-pa35 (do not have any more pa22 :( ) (just > 2 hunk to remove). Unfortunately it failed to compile with following message: > `gcc-3.0 -print-libgcc-file-name` /usr/src/LKCD/hppa/linux-2.4.20-pa35-lkcd/arch/parisc/lib/lib.a > /usr/src/LKCD/hppa/linux-2.4.20-pa35-lkcd/lib/lib.a \ > --end-group \ > -o vmlinux > fs/fs.o(.debug_info+0x6fbaf): undefined reference to `.L1225' > make: *** [vmlinux] Error 1 > > (Sorry I already met this kind of pb but do not remember how to solve :() At first glance, this would appear to be a GCC bug. If I was to guess, it's a problem with a label for a jump table being deleted. You might be able to avoid the problem by compiling fs.o with a different optimization. The problem could be investigated further by generating the assember output for the routine with -g. Search for the above label. The debug information in the file will allow finding the source line. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From willy@debian.org Wed May 14 22:58:49 2003 From: willy@debian.org (Matthew Wilcox) Date: Wed, 14 May 2003 22:58:49 +0100 Subject: [parisc-linux] sym53c8xx.c Message-ID: <20030514215849.GK6859@parcelfarce.linux.theplanet.co.uk> The sym53c8xx driver is near to being removed from 2.6. Can anyone think of a situation where we might still want it? I'm concerned that maybe some of the fixes didn't go into the sym53c8xx_2 driver. In particular, I'd like to know that the sym53c8xx_2 driver in 2.5 works on C3k (wide & narrow!) and A500. -- "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 James.Bottomley@steeleye.com Wed May 14 23:19:27 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 14 May 2003 17:19:27 -0500 Subject: [parisc-linux] sym53c8xx.c In-Reply-To: <20030514215849.GK6859@parcelfarce.linux.theplanet.co.uk> References: <20030514215849.GK6859@parcelfarce.linux.theplanet.co.uk> Message-ID: <1052950768.3430.32.camel@mulgrave> On Wed, 2003-05-14 at 16:58, Matthew Wilcox wrote: > > The sym53c8xx driver is near to being removed from 2.6. Can anyone think > of a situation where we might still want it? I'm concerned that maybe > some of the fixes didn't go into the sym53c8xx_2 driver. In particular, > I'd like to know that the sym53c8xx_2 driver in 2.5 works on C3k (wide & > narrow!) and A500. Just to clarify the plans: NCR53C8XX and SYM53C8XX will be removed as CONFIG_ options. ncr53c8xx.c will continue to exist for Zalon (and has already been revamped for the new error handling). the SYM_2 will become the only selectable self compiling driver. James From Randolph Chung Wed May 14 23:25:47 2003 From: Randolph Chung (Randolph Chung) Date: Wed, 14 May 2003 15:25:47 -0700 Subject: [parisc-linux] sym53c8xx.c In-Reply-To: <20030514215849.GK6859@parcelfarce.linux.theplanet.co.uk> References: <20030514215849.GK6859@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030514222547.GT548@tausq.org> > The sym53c8xx driver is near to being removed from 2.6. Can anyone think > of a situation where we might still want it? I'm concerned that maybe > some of the fixes didn't go into the sym53c8xx_2 driver. In particular, > I'd like to know that the sym53c8xx_2 driver in 2.5 works on C3k (wide & > narrow!) and A500. it definitely works on a500 with 2.5, and on c3k (narrow & wide) with 2.4. I am still not able to boot up my c3k with 2.5 because of the suckyio serial console problems :( randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From weiss_1@prysm.net Thu May 15 06:46:39 2003 From: weiss_1@prysm.net (Clarence Weiss) Date: Thu, 15 May 2003 05:46:39 +0000 Subject: [parisc-linux] Come back Message-ID: CQkJCTxIVE1MPg0KPEJPRFkgQkdDT0xPUj0jZmZmZmZmPg0KPHAgYWxpZ249 ImNlbnRlciI+PFlRVz48Zm9udCBmYWNlPSJ2ZXJkYW5hIj48V01WPg0KZ2V0 IDxDWVRDPmxhcmc8WVRPTj5lPENURU4+ciBudXRzIGFuZCBwZTxLRk9YPm48 Vz7tczxZVUxJPiwgIG1vcjxXPmUNCiA8WEhJPnA8Q1lUWD5sPFhYPmU8V1dI PmE8Wj5zdTxRREFXPnJlLCANCiANCgkNCgkJIDxDVz5tbzxaPnI8V0U+ZQ0K IHNhPFpRPnQ8V0lMPmlzZmE8V00+YzxaPnQ8V00+aW9uPGJyPg0KPGEgaHJl Zj0iaHR0cDovL0hlQUxUSC5ob3N0Q04yLmNvTS9wZWsvJTZEJTMyYy5wJTY4 JTcwP20lNjElNmU9ayU2QjQyJTMyYSI+TGVhcm4gYWJvdXQgaXQgaGVyPFlJ PmU8L2E+PGJyPg0KPGJyPg0KIA0KICA8YSBocmVmPSJodHRwOi8vaGVBbHRI LmhPU3RjTjIuY09tL3AlNjVrL20yYy4lNzAlNjglNzA/bSU2MW49ayU2QiUz NCUzMjIlNjEiPg0KIDxJTUcgQk9SREVSPTAgU1JDPSJodHRwOi8vSGVhbFRI Lkhvc1RjTjIuQ09tLyU3MC4lNkElNzBnIj4gDQogIDwvYT48YnI+PFpZSVY+ PGJyPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9IRUFsdEguSG9zVGNuMi5DT20v cmUlNkRvJTc2JTY1LyI+Tm8gbW88WVhCRz5yPFdVWj5lIHBsZWFzZTwvYT4N Cjxicj4tPWlsdHk3ZjBvOXM2Yj0tPC9mb250PjwvcD4NCgkNCjwvYm9keT48 L0hUTUw+CQ0KCQ0KIA0KDQo= From varenet@esiee.fr Thu May 15 11:20:14 2003 From: varenet@esiee.fr (=?ISO-8859-1?Q?Thibaut_VAR=C8NE?=) Date: Thu, 15 May 2003 12:20:14 +0200 Subject: [parisc-linux] sym53c8xx.c In-Reply-To: <20030514215849.GK6859@parcelfarce.linux.theplanet.co.uk> Message-ID: Le mercredi, 14 mai 2003, =E0 23:58 Europe/Paris, Matthew Wilcox a =E9crit= : > > The sym53c8xx driver is near to being removed from 2.6. Can anyone=20 > think > of a situation where we might still want it? I'm concerned that maybe > some of the fixes didn't go into the sym53c8xx_2 driver. In=20 > particular, > I'd like to know that the sym53c8xx_2 driver in 2.5 works on C3k (wide=20= > & > narrow!) and A500. We've been using SYM2 on our A500 SMP for quite a large amount of time=20= now, not experiencing anymore race problem. I recall some troubles on B2600 (bame experienced those as well, the box just went very lazzy; and you could heard the HD twinkling twice a=20 second) but we had no chance to test SYM2 on that box lately... Maybe we can give it a shot on our J5k which is currently running SYM1 (SMP kernel as well). HTH, Thibaut VARENE The PA/Linux ESIEE Team http://pateam.esiee.fr/= From jsoe0708@tiscali.be Thu May 15 15:38:17 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 15 May 2003 16:38:17 +0200 Subject: [parisc-linux] RE: Dump module patche. In-Reply-To: <200305141801.h4EI1ca3012585@hiauly1.hia.nrc.ca> Message-ID: <3EC39C0A0000002A@ocpmta8.freegates.net> Dave, > > >> >Attachment: dump_modules-2.4.20-pa32.patch2 >> > >> I apply it against last 2.4.20-pa35 (do not have any more pa22 :( ) (just >> 2 hunk to remove). Unfortunately it failed to compile with following message: >> `gcc-3.0 -print-libgcc-file-name` /usr/src/LKCD/hppa/linux-2.4.20-pa35-lkcd/arch/parisc/lib/lib.a >> /usr/src/LKCD/hppa/linux-2.4.20-pa35-lkcd/lib/lib.a \ >> --end-group \ >> -o vmlinux >> fs/fs.o(.debug_info+0x6fbaf): undefined reference to `.L1225' >> make: *** [vmlinux] Error 1 >> >> (Sorry I already met this kind of pb but do not remember how to solve :() > >At first glance, this would appear to be a GCC bug. If I was to guess, >it's a problem with a label for a jump table being deleted. I will try gcc-3.2 (or later) because > >You might be able to avoid the problem by compiling fs.o with a different >optimization. The problem could be investigated further by generating >the assember output for the routine with -g. Search for the above label. >The debug information in the file will allow finding the source line. > fs.o is in fact a lib build with "ld -r -o fs.o open.o read_rite.o [...]" and 'objdump -d fs.o' do not actualy help me to find back any above references :( Thanks, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From jsoe0708@tiscali.be Thu May 15 15:46:57 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 15 May 2003 16:46:57 +0200 Subject: [parisc-linux] RE: Dump module patche. In-Reply-To: <3EC0FF2300000909@ocpmta7.freegates.net> Message-ID: <3EC39C0A00000038@ocpmta8.freegates.net> Bruno, > >> >>sorry, I don't remember this kind of error...did you try make mrproper ??? >> >> >I think so as I prefer distclean? > >umm 2.4.20-pa32 is still available in ftp.p-l.org:/cvs so I will first grab >it and apply patch. Then comeback to you :) > It didn't help so I have to come back to you with severall questions: A. what is your compiler release gcc 3.0 3.2 3.3? B. I suspect also a different .config: may I ask your to compare with mine? Thanks again, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From rtodd@antipentium.com Thu May 15 17:26:55 2003 From: rtodd@antipentium.com (Richard Todd) Date: Thu, 15 May 2003 12:26:55 -0400 Subject: [parisc-linux] J5000 and Xfree Message-ID: Does anyone know of a driver or what driver to use with the J5000 to try to get xfree working STI device: HPA4554A stifb: Unsupported gfx card id 0x2fc1066b Display controller: Hewlett-Packard Company Visualize FX4 (rev 02) Any Help would really be appreciated -- Never be afraid to try something new. Remember, Amateurs built the ark. Professionals built the Titanic. ... From jsoe0708@tiscali.be Thu May 15 17:36:33 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 15 May 2003 18:36:33 +0200 Subject: [parisc-linux] RE: Dump module patche. In-Reply-To: <3EC3A988.4070807@hp.com> Message-ID: <3EC39C0A000000A1@ocpmta8.freegates.net> > >gcc version 3.0.4 > > >Joel Soete wrote: >> Bruno, >> >>>>sorry, I don't remember this kind of error...did you try make mrproper >>> >> ??? >> >>>> >>>I think so as I prefer distclean? >>> >>>umm 2.4.20-pa32 is still available in ftp.p-l.org:/cvs so I will first >grab >>>it and apply patch. Then comeback to you :) >>> >> >> It didn't help so I have to come back to you with severall questions: >> >> A. what is your compiler release gcc 3.0 3.2 3.3? >> >> B. I suspect also a different .config: may I ask your to compare with mine? >> > >Attachment: config > Well very very different from mine I will so test also on my b2k (but in 32bits and 64bits). in the mean time I reach to build a kernel 2.4.21-pa32 with gcc-3.2 but I forget the __c_f_f_c pb so it crash imedieately, I will so go test 2.4.21-pa35 with your patch. See you later, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From jsoe0708@tiscali.be Thu May 15 17:55:47 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 15 May 2003 18:55:47 +0200 Subject: [parisc-linux] RE: Dump module patche. In-Reply-To: <3EC39C0A000000A1@ocpmta8.freegates.net> Message-ID: <3EC39C0A000000B1@ocpmta8.freegates.net> Sorry , >in the mean time I reach to build a kernel 2.4.21-pa32 with gcc-3.2 but I >forget the __c_f_f_c pb so it crash imedieately, I will so go test 2.4.21-pa35 >with your patch. read 2.4.20... Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From vince@kyllikki.org Thu May 15 18:50:08 2003 From: vince@kyllikki.org (Vincent Sanders) Date: Thu, 15 May 2003 18:50:08 +0100 Subject: [parisc-linux] Serial console on a 715/33 Message-ID: <20030515175008.GC23024@kyllikki.org> --Qbvjkv9qwOGw/5Fx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have recently aquired a HP 715/33 machine. It has 32Mb fitted in a pair of simms and a 2Gb hard disc I have aquired the machine without keyboard or monitor and as i intended it to run as a headless system this wasnt an issue. However I have discovered I need to gain access to the boot prom to change the settings (I am very familiar with such things from SUN kit). I have discovered how to get a sensible graphics (1024x768) mode by changing the dip switches at the back of the board but still dont have a keyboard. I have attempted a number of times to get serial console to work by holding down TOC at boot time to no avail (suggested by mathew wilcox). I have managed to get the system to boot from the network using rboot and disconnecting the hard disc then reconnecting the hard drive and installing debian :-) This means i have a working debian system but i still cannot get access to the boot monitor to change any settings. Does anyone have any clues to get the boot monitor to switch to serial console without acess to a keyboard or hpux. --=20 Regards Vincent http://www.kyllikki.org/ --Qbvjkv9qwOGw/5Fx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+w9NQiUwwPOvjHvURAn+MAJsEUp8qSSQaZ9onliG1tTRO3+2zXQCdFRJS O30I/7LQpL0jtp8qq/pkkIE= =z0kS -----END PGP SIGNATURE----- --Qbvjkv9qwOGw/5Fx-- From jesse@cypress-tech.com Thu May 15 22:42:30 2003 From: jesse@cypress-tech.com (Jesse Dougherty) Date: Thu, 15 May 2003 14:42:30 -0700 Subject: [parisc-linux] HP Industrial Controllers & CPUs Message-ID: <3EC409C6.8AD9DA0@cypress-tech.com> Does anyone have any of these older HP-UX workstations and or CPUs that might be available for surplus sale or trade? A1255A 9000/745/165L Workstation A4964A 9000/745/132L Workstation A4513A 9000/748/165L Workstation A4510A 9000/748/132L Workstation A4311A 9000/748i/100 Workstation A2638A 9000/745i/100 Workstation A2261A 9000/745i/100 Workstation A4511A 9000/744/165L Single Board Computer A4500A 9000/744/132L Single Board Computer A4512A 9000/744rt/165L Single Board Computer A4520A 9000/744rt/132L Single Board Computer A4260A 9000/743i/100 Single Board Computer Thanks Jesse Dougherty Cypress Technology, Inc Re-Sellers of HP 3000/9000 products 12890 Automobile Blvd Clearwater, FL 33762 727-557-0911 / fax 727-557-0014 jesse@cypress-tech.com www.cypress-tech.com From derekengelhaupt@rocketmail.com Thu May 15 20:14:07 2003 From: derekengelhaupt@rocketmail.com (Derek Engelhaupt) Date: Thu, 15 May 2003 12:14:07 -0700 (PDT) Subject: [parisc-linux] J5000 and Xfree In-Reply-To: Message-ID: <20030515191407.81371.qmail@web12502.mail.yahoo.com> --0-1998837807-1053026047=:81041 Content-Type: text/plain; charset=us-ascii That graphics card, the FX4, is not supported under Debian. Only the EG variants are supported ie: A4977A on the J5000. Check out this Ebay auction (no affillation with seller): http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3023848603&category=11221 I was getting rid of my spare A4977A card, but it is spoken for. derek Richard Todd wrote: Does anyone know of a driver or what driver to use with the J5000 to try to get xfree working STI device: HPA4554A stifb: Unsupported gfx card id 0x2fc1066b Display controller: Hewlett-Packard Company Visualize FX4 (rev 02) Any Help would really be appreciated -- Never be afraid to try something new. Remember, Amateurs built the ark. Professionals built the Titanic. ... _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux --------------------------------- Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. --0-1998837807-1053026047=:81041 Content-Type: text/html; charset=us-ascii
That graphics card, the FX4, is not supported under Debian.  Only the EG variants are supported ie: A4977A on the J5000.  Check out this Ebay auction (no affillation with seller):
 
I was getting rid of my spare A4977A card, but it is spoken for.
 
derek
 

Richard Todd <rtodd@antipentium.com> wrote:
Does anyone know of a driver or what driver to use with the J5000 to try to
get xfree working
STI device: HPA4554A
stifb: Unsupported gfx card id 0x2fc1066b

Display controller: Hewlett-Packard Company Visualize FX4 (rev 02)

Any Help would really be appreciated
--


Never be afraid to try something new.
Remember, Amateurs built the ark. Professionals built
the Titanic.

...

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

Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo. --0-1998837807-1053026047=:81041-- From bruno_vidal@hp.com Fri May 16 09:29:12 2003 From: bruno_vidal@hp.com (Bruno Vidal) Date: Fri, 16 May 2003 10:29:12 +0200 Subject: [parisc-linux] Modification request for linux/arch/parisc/kernel/power.c Message-ID: <3EC4A158.70106@hp.com> Hi I have a small request for this modules. Is it possible to add a small hak in the process_shutdown() function in order to call panic() if the soft power button is pressed 3 time shortly. It really help to analyze problem in hanging situation. Thanks. -- Vidal Bruno, (770-4271) SSD-HA Team, HP-UX & LINUX Support bruno_vidal@hp.com From jsoe0708@tiscali.be Fri May 16 13:55:09 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Fri, 16 May 2003 14:55:09 +0200 Subject: [parisc-linux] last binutils-2.14.90.0.1 failled to build kernel Message-ID: <3EC39DA000000769@ocpmta7.freegates.net> Hi All, I am now runing a kernel 2.4.20-pa35 + lkcd bruno's patch with gcc-3.2. In the mean time I made a distupgrade which mainly update binutils from 2.13.90.0.18-1.7 to 2.14.90.0.1-0.1 which make now failed the rebuild of the kernel: [...] gcc -D__ASSEMBLY__ -traditional -D__KERNEL__ -I/usr/src/LKCD/hppa/linux-2.4.20-pa35-lkcd/include -c -o entry.o entry.S entry.S: Assembler messages: entry.S:191: Error: Undefined .EXPORT/.IMPORT argument (ignored): entry.S:191: Error: Undefined .EXPORT/.IMPORT argument (ignored): code entry.S:514: Error: Undefined .EXPORT/.IMPORT argument (ignored): entry.S:514: Error: Undefined .EXPORT/.IMPORT argument (ignored): code entry.S:573: Error: Undefined .EXPORT/.IMPORT argument (ignored): entry.S:573: Error: Undefined .EXPORT/.IMPORT argument (ignored): code entry.S:574: Error: Undefined .EXPORT/.IMPORT argument (ignored): entry.S:574: Error: Undefined .EXPORT/.IMPORT argument (ignored): code entry.S:603: Error: Undefined .EXPORT/.IMPORT argument (ignored): entry.S:603: Error: Undefined .EXPORT/.IMPORT argument (ignored): code entry.S:858: Error: Undefined .EXPORT/.IMPORT argument (ignored): entry.S:858: Error: Undefined .EXPORT/.IMPORT argument (ignored): code make[1]: *** [entry.o] Error 1 make[1]: Leaving directory `/usr/src/LKCD/hppa/linux-2.4.20-pa35-lkcd/arch/parisc/kernel' make: *** [_dir_arch/parisc/kernel] Error 2 [...] Any idea? Thanks, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From grundler@parisc-linux.org Fri May 16 18:25:55 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 16 May 2003 11:25:55 -0600 Subject: [parisc-linux] Re: Help configuring an HIL mouse on an HP 715. - (Major disaster! - Am I back at ground level 0?) In-Reply-To: References: <20030513184232.GB14235@dsl2.external.hp.com> Message-ID: <20030516172555.GA10530@dsl2.external.hp.com> On Thu, May 15, 2003 at 12:09:25PM -0700, Jaime Ash wrote: > Hi Grant, > I did manage to recover by using a combination of the tips above (except > that I had to modify the first tip to: "boot alt isl", instead) yup - sorry about that. I'm going to move this conversation to the parisc-linux mailing list since this revolves around the HIL support in the kernel. > Since I can't get "vmlinux-2.4.20-32" to boot in my machine, Has anyone tried to running vmlinux-2.4.20-32 on 715/new (64/80/100)? Also problems with HIL mouse/keyboard? > I then got and > installed "kernel-image-2.4.19-32" (to try to fix my HIL mouse/keyboard > problem) but I now have a new problem: when I boot using the > "vmlinux-2.4.19-32" kernel, things go well until I reach a point where I get > a Debian GNU Linux blue screen with a gray menu that asks to "Choose your > current network-environment !", and gives 2 choices: "Installation_default" > and "Set_up_new_environment" and has 2 "buttons": "< OK >" and "< Cancel >". > But, the keyboard (and mouse) are disabled, so I can't choose!!!!! Reboot with 2.4.17, and fix up the network scripts. Or just delete the whatever package provides that. Can someone advise Jaime on which packages muck with keyboard settings and how they should be set? Or Is the FAQ answer this sufficiently? > (Ie. I > can't proceed or shutdown gracefully, because the networking hasn't yet been > enabled - so I can't telnet to the machine - so my only choice is to pull > the AC plug, because pressing the power button doesn't halt the system!) > I believe that the "Choose your current network-environment !" blue screen > occurs in my system because of a wrong default I took during the > installation from the ISO disk (I didn't know any better!) and I used to get > that same screen with "vmlinux-2.4.17-32". But, in that case, I was able to > make the proper choice with the keyboard, since it continued working OK up > to that stage in the boot process. > I may be wrong, but here is my theory of what's happening now: the good > news is that I think the new kernel ("vmlinux-2.4.19-32") must have "solved" > the HIL/keyboard problem (but too early): ie. the HIL driver must have been > enabled before the blue screen menu (since the keyboard behavior has changed > with the new kernel), but the software behind that menu doesn't know how to > use the new driver. I also think that if I can somehow get rid of the blue > screen (by changing an entry in some configuration file? - but which?) my > problem would go away. Since a previous user (Damien) reported that he got > "kernel-image-2.4.19-32" to work for him in an HP 715 machine, I am guessing > that he did not have that blue screen menu enabled - therefore no problem in > his case. > What do you think? I don't know what the problem is. I haven't played with HIL drivers at all. > Is there an easy way to disable the blue screen after booting to the old > kernel? Yes 1) figure out which script is presenting that menu. (eg "fgrep -i new_network /etc/init.d/*") 2) Run the script by hand to make sure it's the right one. (eg "/etc/init.d/netenv start") 3) "dpkg -S " to find the responsible package. 4) "apt-get remove " to blow away the package. hth, grant From pa3aba@debian.org Fri May 16 20:24:56 2003 From: pa3aba@debian.org (Joop Stakenborg) Date: Fri, 16 May 2003 21:24:56 +0200 Subject: [parisc-linux] Re: Bug#193261: glfer_0.3.2-1(hppa/unstable): FTBFS: assumes sys/io.h exists In-Reply-To: <20030516191505.GA24104@security.hp.com> References: <20030514052335.GO14285@security.hp.com> <3EC25AE0.9070004@debian.org> <20030516191505.GA24104@security.hp.com> Message-ID: <3EC53B08.2050904@debian.org> LaMont Jones wrote: > severity 193261 important > -- > On Wed, May 14, 2003 at 05:04:00PM +0200, Joop Stakenborg wrote: > >>>There are many architectures where sys/io.h does not exist. >> >>Sorry about that. I will make it a i386-only package for now. > > > Please don't do that. This bug should be important, not serious, > which makes it not release-critical. (Sorry about that...) > > Unless the package is truely i386 specific in _function_ (not > compile-ability), or depends on such, it should be Architecture: any. > Okay, where do I find information on functions and devices available on other architectures, e.g. glfer uses inb, outb and ioperm (they are in sys/io.h) on the parallel/serial port. > lamont > > Thanks, Joop From ja@lachivaquemada.com Fri May 16 20:59:17 2003 From: ja@lachivaquemada.com (Jaime Ash) Date: Fri, 16 May 2003 12:59:17 -0700 Subject: [parisc-linux] RE: Help configuring an HIL mouse on an HP 715. - (Major disaster! - Am I back at ground level 0?) In-Reply-To: <20030516172555.GA10530@dsl2.external.hp.com> Message-ID: >> Is there an easy way to disable the blue screen after booting to the old >> kernel? > Yes > 1) figure out which script is presenting that menu. > (eg "fgrep -i new_network /etc/init.d/*") I assume that by "new_network" you really mean one of the strings that are displayed in the Debian GNU Linux blue screen with the gray menu (such as "Choose your current network-environment !", "Set_up_new_environment" or "Installation_default") and that you are trying to find a file in the init.d directory that contains that string. Am I correct? I tried all three, as follows (but no file was found with any of these commands): fgrep -i Set_up_new_environment /etc/init.d/* fgrep -i Installation_default /etc/init.d/* fgrep -i 'Choose your current network-environment !' /etc/init.d/* So, here are my next questions: 1. Is init.d the only directory to search? 2. Can initialization scripts be stored elsewhere? Best regards, Jaime From bzeeb-lists@lists.zabbadoz.net Sun May 18 13:41:03 2003 From: bzeeb-lists@lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun, 18 May 2003 12:41:03 +0000 (UTC) Subject: [parisc-linux] Inconsistency detected by ld.so:.. / do_page_fault() Message-ID: Hi, bz@apollo:~> ldd /bin/cp Inconsistency detected by ld.so: rtld.c: 879: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed! Inconsistency detected by ld.so: rtld.c: 879: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed! ldd: /lib/ld.so.1 exited with unknown exit code (127) I have seen: http://lists.parisc-linux.org/pipermail/parisc-linux/2003-March/019601.html ist this patch included in some cvs so that I can rebuild me glibc ? Or any other proposals ? I also have other probs with vim and tcpdump and most likely others dumping core and producing a do_page_fault() dump with IAOQ: 4xxxxxxxx on 2.5.-latest from cvs w/o last single ioctl commit. but I also had seen these core dumps on 2.4.18-pa33 after last dist-upgrade some days ago ... do_page_fault() pid=732 command='vim' type=15 address=0x00000000 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001111111100001111 Not tainted r00-03 00000000 40209e44 400ec15f 00000000 r04-07 40208644 0011c8b6 00000017 00126b30 r08-11 00000000 001695a8 00000000 00000000 r12-15 00000002 00000001 00000001 00070208 r16-19 ffffffff 00000000 00000000 40208644 r20-23 00000002 40208644 400ec11c 00000000 r24-27 00000000 0011c8b6 00000002 0010f634 r28-31 000abc78 0000011e faf009c0 4000a08f sr0-3 00000016 00000016 00000000 00000016 sr4-7 00000016 00000016 00000016 00000016 IASQ: 00000016 00000016 IAOQ: 401d1b2f 401d1b33 IIR: 0c601094 ISR: 00000016 IOR: 00000000 CPU: 0 CR30: 146f4000 CR31: 102e1000 ORIG_R28: 00126f48 any ideas ? more infos available on request. -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From doko@cs.tu-berlin.de Sun May 18 15:36:43 2003 From: doko@cs.tu-berlin.de (Matthias Klose) Date: Sun, 18 May 2003 16:36:43 +0200 Subject: [parisc-linux] gcc fails to build using binutils-2.14.90.0.1 Message-ID: <16071.39547.93843.710060@gargle.gargle.HOWL> binutils-2.13.90.0.18 works ok. See http://buildd.debian.org/fetch.php?&pkg=gcc-3.3&ver=1%3A3.3ds9-2&arch=hppa&stamp=1053264270&file=log&as=raw: ./xgcc -B./ -B/usr/hppa-linux/bin/ -isystem /usr/hppa-linux/include -isystem /usr/hppa-linux/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -DELF=1 -DLINUX=1 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include -DL_mulI -xassembler-with-cpp -c ../../src/gcc/config/pa/milli64.S -o libgcc/./_mulI.o ../../src/gcc/config/pa/milli64.S: Assembler messages: ../../src/gcc/config/pa/milli64.S:1779: Error: Undefined .EXPORT/.IMPORT argument (ignored): ../../src/gcc/config/pa/milli64.S:1779: Error: Undefined .EXPORT/.IMPORT argument (ignored): millicode make[5]: *** [libgcc/./_mulI.o] Error 1 From dave@hiauly1.hia.nrc.ca Sun May 18 17:01:53 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Sun, 18 May 2003 12:01:53 -0400 (EDT) Subject: [parisc-linux] gcc fails to build using binutils-2.14.90.0.1 In-Reply-To: <16071.39547.93843.710060@gargle.gargle.HOWL> from "Matthias Klose" at May 18, 2003 04:36:43 pm Message-ID: <200305181601.h4IG1sgl016848@hiauly1.hia.nrc.ca> > binutils-2.13.90.0.18 works ok. > > See http://buildd.debian.org/fetch.php?&pkg=gcc-3.3&ver=1%3A3.3ds9-2&arch=hppa&stamp=1053264270&file=log&as=raw: > > ./xgcc -B./ -B/usr/hppa-linux/bin/ -isystem /usr/hppa-linux/include -isystem /usr/hppa-linux/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -DELF=1 -DLINUX=1 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include -DL_mulI -xassembler-with-cpp -c ../../src/gcc/config/pa/milli64.S -o libgcc/./_mulI.o > ../../src/gcc/config/pa/milli64.S: Assembler messages: > ../../src/gcc/config/pa/milli64.S:1779: Error: Undefined .EXPORT/.IMPORT argument (ignored): > ../../src/gcc/config/pa/milli64.S:1779: Error: Undefined .EXPORT/.IMPORT argument (ignored): millicode > make[5]: *** [libgcc/./_mulI.o] Error 1 Did you part this to the binutils list? A change has mucked up the assembler's processing of .export. Alan Modra would probably know what's happened. I've also noted that there are some new fails in the visibility tests in a recent cvs version of binutils. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From Randolph Chung Sun May 18 17:10:01 2003 From: Randolph Chung (Randolph Chung) Date: Sun, 18 May 2003 09:10:01 -0700 Subject: [parisc-linux] Inconsistency detected by ld.so:.. / do_page_fault() In-Reply-To: References: Message-ID: <20030518161001.GG548@tausq.org> > bz@apollo:~> ldd /bin/cp > Inconsistency detected by ld.so: rtld.c: 879: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed! > Inconsistency detected by ld.so: rtld.c: 879: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed! > ldd: /lib/ld.so.1 exited with unknown exit code (127) http://sources.redhat.com/ml/libc-alpha/2003-05/msg00149.html i just sent this to debian/glibc upstream yesterday. > I also have other probs with vim and tcpdump and most likely others > dumping core and producing a do_page_fault() dump with IAOQ: 4xxxxxxxx > on 2.5.-latest from cvs w/o last single ioctl commit. > but I also had seen these core dumps on 2.4.18-pa33 after last > dist-upgrade some days ago ... this is because of a gcc bug. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193207 once gcc-3.2 gets patched and glibc gets recompiled, you'll be ok. otherwise, consider downgrading to libc6_2.3.1-16 and everything will be ok. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From bzeeb-lists@lists.zabbadoz.net Sun May 18 17:45:11 2003 From: bzeeb-lists@lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun, 18 May 2003 16:45:11 +0000 (UTC) Subject: [parisc-linux] Inconsistency detected by ld.so:.. / do_page_fault() In-Reply-To: <20030518161001.GG548@tausq.org> References: <20030518161001.GG548@tausq.org> Message-ID: On Sun, 18 May 2003, Randolph Chung wrote: Hi, > http://sources.redhat.com/ml/libc-alpha/2003-05/msg00149.html > > i just sent this to debian/glibc upstream yesterday. thanks for the information. > > I also have other probs with vim and tcpdump and most likely others > > dumping core and producing a do_page_fault() dump with IAOQ: 4xxxxxxxx > > this is because of a gcc bug. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193207 > > once gcc-3.2 gets patched and glibc gets recompiled, you'll be ok. > otherwise, consider downgrading to libc6_2.3.1-16 and everything will be > ok. what about the gcc-3.3 debs that are distributed ? If I rebuilt the packages from source with them would they be ok ? -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From Randolph Chung Sun May 18 18:16:45 2003 From: Randolph Chung (Randolph Chung) Date: Sun, 18 May 2003 10:16:45 -0700 Subject: [parisc-linux] Inconsistency detected by ld.so:.. / do_page_fault() In-Reply-To: References: <20030518161001.GG548@tausq.org> Message-ID: <20030518171645.GH548@tausq.org> > > once gcc-3.2 gets patched and glibc gets recompiled, you'll be ok. > > otherwise, consider downgrading to libc6_2.3.1-16 and everything will be > > ok. > > what about the gcc-3.3 debs that are distributed ? If I rebuilt the > packages from source with them would they be ok ? yes, that should work too. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From bzeeb-lists@lists.zabbadoz.net Sun May 18 20:44:36 2003 From: bzeeb-lists@lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun, 18 May 2003 19:44:36 +0000 (UTC) Subject: [parisc-linux] Inconsistency detected by ld.so:.. / do_page_fault() In-Reply-To: <20030518171645.GH548@tausq.org> References: <20030518161001.GG548@tausq.org> <20030518171645.GH548@tausq.org> Message-ID: On Sun, 18 May 2003, Randolph Chung wrote: > > > once gcc-3.2 gets patched and glibc gets recompiled, you'll be ok. > > > otherwise, consider downgrading to libc6_2.3.1-16 and everything will be > > > ok. > > > > what about the gcc-3.3 debs that are distributed ? If I rebuilt the > > packages from source with them would they be ok ? > > yes, that should work too. didn't :(( rebuild vim by hand with gcc 3.3 and it again segfaulted on startup :( seems like this is a problem with shared libs ? what else will I need to rebuilt ? or other question - how often are packages re-built by debian package building system (how-ever this works) ? -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From dave@hiauly1.hia.nrc.ca Sun May 18 21:20:05 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Sun, 18 May 2003 16:20:05 -0400 (EDT) Subject: [parisc-linux] Inconsistency detected by ld.so:.. / do_page_fault() In-Reply-To: from "Bjoern A. Zeeb" at May 18, 2003 07:44:36 pm Message-ID: <200305182020.h4IKK5KR017492@hiauly1.hia.nrc.ca> > didn't :(( > > rebuild vim by hand with gcc 3.3 and it again segfaulted on startup :( > seems like this is a problem with shared libs ? Did you rebuild or downgrade glibc as suggested? Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From Randolph Chung Sun May 18 21:38:55 2003 From: Randolph Chung (Randolph Chung) Date: Sun, 18 May 2003 13:38:55 -0700 Subject: [parisc-linux] Inconsistency detected by ld.so:.. / do_page_fault() In-Reply-To: References: <20030518161001.GG548@tausq.org> <20030518171645.GH548@tausq.org> Message-ID: <20030518203855.GK548@tausq.org> > rebuild vim by hand with gcc 3.3 and it again segfaulted on startup :( > seems like this is a problem with shared libs ? don't rebuild vim, rebuild glibc :) > what else will I need to rebuilt ? or other question - how often are > packages re-built by debian package building system (how-ever this > works) ? it depends on when the next version is uploaded. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From bzeeb-lists@lists.zabbadoz.net Sun May 18 21:41:08 2003 From: bzeeb-lists@lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun, 18 May 2003 20:41:08 +0000 (UTC) Subject: [parisc-linux] Inconsistency detected by ld.so:.. / do_page_fault() In-Reply-To: <200305182020.h4IKK5KR017492@hiauly1.hia.nrc.ca> References: <200305182020.h4IKK5KR017492@hiauly1.hia.nrc.ca> Message-ID: On Sun, 18 May 2003, John David Anglin wrote: > > didn't :(( > > > > rebuild vim by hand with gcc 3.3 and it again segfaulted on startup :( > > seems like this is a problem with shared libs ? > > Did you rebuild or downgrade glibc as suggested? missed that point because the point in my first posting also was glibc related and I thaught of these as two independend problems but both are glibc related.... *grrml* Well, going to see where I can get an up-to-date glibc source (including the patches) from ... -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From Randolph Chung Sun May 18 21:50:59 2003 From: Randolph Chung (Randolph Chung) Date: Sun, 18 May 2003 13:50:59 -0700 Subject: [parisc-linux] Inconsistency detected by ld.so:.. / do_page_fault() In-Reply-To: References: <200305182020.h4IKK5KR017492@hiauly1.hia.nrc.ca> Message-ID: <20030518205058.GL548@tausq.org> > missed that point because the point in my first posting also was glibc > related and I thaught of these as two independend problems but both > are glibc related.... *grrml* > Well, going to see where I can get an up-to-date glibc source > (including the patches) from ... apt-get source glibc randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From bzeeb-lists@lists.zabbadoz.net Mon May 19 13:07:28 2003 From: bzeeb-lists@lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon, 19 May 2003 12:07:28 +0000 (UTC) Subject: [parisc-linux] Inconsistency detected by ld.so:.. / do_page_fault() In-Reply-To: <20030518203855.GK548@tausq.org> References: <20030518161001.GG548@tausq.org> <20030518171645.GH548@tausq.org> <20030518203855.GK548@tausq.org> Message-ID: On Sun, 18 May 2003, Randolph Chung wrote: Hi, > > rebuild vim by hand with gcc 3.3 and it again segfaulted on startup :( > > seems like this is a problem with shared libs ? > > don't rebuild vim, rebuild glibc :) just to note for the further message; the machine (715/100) is running: Linux apollo 2.5.69-pa1 #22 Sat May 17 16:48:19 UTC 2003 parisc GNU/Linux gcc-3.3, binutils 2.14.90.0.1-0.1, libc6 2.3.1-17 ok, started glibc build over night and ... --- cut --- gcc-3.3 tst-pathopt.c -c -std=3Dgnu99 -O2 -Wall -Winline -Wstrict-prototype= s -Wwrite-strings -fstrict-aliasing -g -pipe -I../include -I. -I/u1/sr= c/glibc/glibc-2.3.1/hppa-linux/obj/elf -I.. -I../libio -I/u1/src/glibc/gli= bc-2.3.1/hppa-linux/obj -I../sysdeps/hppa/elf -I../linuxthreads/sysdeps/uni= x/sysv/linux/hppa -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthrea= ds/sysdeps/pthread -I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv= -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/hppa -I../sysdeps= /unix/sysv/linux/hppa -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sy= sdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdep= s/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/hppa/hppa1.1 = -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/d= bl-64 -I../sysdeps/ieee754/ldbl-128 -I../sysdeps/hppa/fpu -I../sysdeps/hppa= -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostd= inc -isystem /usr/lib/gcc-lib/hppa-linux/3.3/include -isystem /usr/src/kern= el-headers-2.5.69-pa1-hppa/include -D_LIBC_REENTRANT -include ../include/li= bc-symbols.h -DNOT_IN_libc=3D1 -o /u1/src/glibc/glibc-2.3.1/hppa-linux= /obj/elf/tst-pathopt.o make[4]: Target `tests' not remade because of errors. make[4]: Leaving directory `/u1/src/glibc/glibc-2.3.1/glibc-2.3.1/elf' make[3]: *** [elf/tests] Error 2 make[3]: Target `check' not remade because of errors. make[3]: Leaving directory `/u1/src/glibc/glibc-2.3.1/glibc-2.3.1' make[2]: *** [check] Error 2 make[2]: Leaving directory `/u1/src/glibc/glibc-2.3.1/hppa-linux/obj' date >>/u1/src/glibc/glibc-2.3.1/log-test-hppa-linux make[1]: Leaving directory `/u1/src/glibc/glibc-2.3.1' touch /u1/src/glibc/glibc-2.3.1/hppa-linux/compiled-source Segmentation fault --- cut --- my ssh connection had been terminated/crashed I woke up this morning and after re-connection I had those in dmegs: --- cut --- do_page_fault() pid=3D268 command=3D'sshd' type=3D6 address=3D0x00000003 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001101111111100001111 Not tainted r00-03 00000000 401e3e44 40110d07 401e75b0 r04-07 401e75b0 401e5644 00000002 000fe588 r08-11 00000001 000f7f60 000fa438 000e7760 r12-15 00000001 000f7f60 000e7760 000e7760 r16-19 000e7760 00000004 00000004 401e5644 r20-23 00000060 00000000 0002ad9c faf01020 r24-27 00000004 00000001 401e75b0 000e7760 r28-31 00000001 00000000 faf00e40 0002e8d3 sr0-3 00000000 000004bf 00000000 000004bf sr4-7 000004bf 000004bf 000004bf 000004bf IASQ: 000004bf 000004bf IAOQ: 00000003 00000007 IIR: 34250fe0 ISR: 000004bf IOR: 401df8ec CPU: 0 CR30: 15b84000 CR31: 102e1000 ORIG_R28: 00000000 kernel BUG at mm/memory.c:1443! Kernel addresses on the stack: [<1012414c>] printk+0x17c/0x1bc [<101059e8>] dump_stack+0x10/0x1c [<101492dc>] do_file_page+0x124/0x12c [<101493c0>] handle_mm_fault+0xdc/0x16c [<10104a6c>] do_page_fault+0x218/0x2a8 [<10126ca4>] do_setitimer+0x208/0x238 [<10106364>] handle_interruption+0x274/0x5b4 [<1012be1c>] sys_alarm+0x28/0x44 [<1010afe8>] syscall_exit+0x0/0x28 [<1010a088>] intr_check_sig+0x0/0xc kernel BUG at mm/memory.c:1443! Kernel addresses on the stack: [<1012414c>] printk+0x17c/0x1bc [<101059e8>] dump_stack+0x10/0x1c [<101492dc>] do_file_page+0x124/0x12c [<101493c0>] handle_mm_fault+0xdc/0x16c [<101ec820>] sock_aio_write+0xc4/0xdc [<10104a6c>] do_page_fault+0x218/0x2a8 [<1014b188>] unmap_vma_list+0x24/0x3c [<10106364>] handle_interruption+0x274/0x5b4 [<10157310>] __fput+0x90/0xf4 [<1015661c>] sys_write+0x4c/0x68 [<1010afe8>] syscall_exit+0x0/0x28 [<1010a088>] intr_check_sig+0x0/0xc --- cut --- then tried to shutdown and got an endless loop of those: --- cut --- kernel BUG at include/linux/swapops.h:68! Kernel addresses on the stack: [<1012414c>] printk+0x17c/0x1bc [<101059e8>] dump_stack+0x10/0x1c [<10152790>] unuse_pmd+0x160/0x168 [<101ce120>] blk_remove_plug+0x5c/0x84 [<1015281c>] unuse_pgd+0x84/0x110 [<10120168>] schedule+0x1cc/0x40c [<10152914>] unuse_vma+0x6c/0xf4 [<10152a0c>] unuse_process+0x70/0xbc [<10152ce8>] try_to_unuse+0x240/0x620 [<10153650>] sys_swapoff+0x1f8/0x384 [<1014b6a4>] sys_munmap+0x50/0x6c [<1010afe8>] syscall_exit+0x0/0x28 [<1010a088>] intr_check_sig+0x0/0xc kernel BUG at include/linux/swapops.h:68! Kernel addresses on the stack: [<1012414c>] printk+0x17c/0x1bc [<101059e8>] dump_stack+0x10/0x1c [<10152790>] unuse_pmd+0x160/0x168 [<101ce120>] blk_remove_plug+0x5c/0x84 [<1015281c>] unuse_pgd+0x84/0x110 [<10120168>] schedule+0x1cc/0x40c [<10152914>] unuse_vma+0x6c/0xf4 [<10152a0c>] unuse_process+0x70/0xbc [<10152ce8>] try_to_unuse+0x240/0x620 [<10153650>] sys_swapoff+0x1f8/0x384 [<1014b6a4>] sys_munmap+0x50/0x6c [<1010afe8>] syscall_exit+0x0/0x28 [<1010a088>] intr_check_sig+0x0/0xc --- cut --- --=20 Greetings Bjoern A. Zeeb=09=09=09=09bzeeb at Zabbadoz dot NeT 56 69 73 69 74=09=09=09=09http://www.zabbadoz.net/ From jsoe0708@tiscali.be Mon May 19 17:27:41 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Mon, 19 May 2003 18:27:41 +0200 Subject: [parisc-linux] glibc pthreads actual threads? Message-ID: <3EC761CD0000080F@ocpmta2.freegates.net> Hi all, Sorry in advance if it is not the right place to put this question. But I just start to learn more details about OS (A. Tanenbaum book) and by the way try to understand a bit more about [p]threads. I found a paper with examples (what I need much of all) and so I try by the first one: basic_example.c (which I just change a very little for my understanding) /* for pthreads */ #include #include /* for getpid() */ #include #include char * buf = "abcdefghijklmnopqrstuvwxyz"; int num_pthreads = 4; int count = 60; int fd = 1; void * new_thread(void * arg) { int i; pid_t PID=getpid(); for (i = 0; i < count; i++) { fprintf(stderr, "PID: %d\n", PID); write(fd, arg, 1); write(fd, "\n", 1); sleep(1); } return(NULL); } main() { pthread_t thread; int i; for (i = 0; i < num_pthreads; i++) { if (pthread_create(&thread, NULL, new_thread, (void *)(buf + i))) { fprintf(stderr, "error creating a new thread \n"); exit(1); } pthread_detach(thread); } pthread_exit(NULL); } Which I compile as follow (gcc-3.3): gcc -l pthread -o basic_example basic_example.c That runs well (on my b2k running a 2.4.20-pa35 and libc6 2.3.1-17): [...] PID: 31360 a PID: 31361 b PID: 31362 c PID: 31363 d PID: 31360 a PID: 31361 b PID: 31362 c PID: 31363 d [...] But notice a very strange behaviour: _the pid is not the same for each thread_ ?? Having just a small sunos 5.8 with gcc-3.2.2 (but with native libpthread) the pb does not occurs? Is it a limit of glibc (in general or in 2.3 only?) for all linux or only hppa? Thanks in advance for your attention, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From willy@debian.org Mon May 19 17:32:45 2003 From: willy@debian.org (Matthew Wilcox) Date: Mon, 19 May 2003 17:32:45 +0100 Subject: [parisc-linux] glibc pthreads actual threads? In-Reply-To: <3EC761CD0000080F@ocpmta2.freegates.net> References: <3EC761CD0000080F@ocpmta2.freegates.net> Message-ID: <20030519163245.GN16608@parcelfarce.linux.theplanet.co.uk> On Mon, May 19, 2003 at 06:27:41PM +0200, Joel Soete wrote: > But notice a very strange behaviour: > _the pid is not the same for each thread_ ?? > > Having just a small sunos 5.8 with gcc-3.2.2 (but with native libpthread) > the pb does not occurs? > > Is it a limit of glibc (in general or in 2.3 only?) for all linux or only > hppa? it's a limit of your understanding ;-) POSIX specifies both behaviours are legitimate. -- "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 Mon May 19 18:01:22 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Mon, 19 May 2003 19:01:22 +0200 Subject: [parisc-linux] glibc pthreads actual threads? In-Reply-To: <20030519163245.GN16608@parcelfarce.linux.theplanet.co.uk> Message-ID: <3EC761CD0000085B@ocpmta2.freegates.net> > >it's a limit of your understanding ;-) Normal: as mentioned I just started to learn... > POSIX specifies both behaviours >are legitimate. > Thanks for those clarification, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From dave@hiauly1.hia.nrc.ca Mon May 19 18:05:34 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Mon, 19 May 2003 13:05:34 -0400 (EDT) Subject: [parisc-linux] Inconsistency detected by ld.so:.. / do_page_fault() In-Reply-To: from "Bjoern A. Zeeb" at May 19, 2003 12:07:28 pm Message-ID: <200305191705.h4JH5YPo020750@hiauly1.hia.nrc.ca> > my ssh connection had been terminated/crashed I woke up this morning > and after re-connection I had those in dmegs: > > --- cut --- > do_page_fault() pid=268 command='sshd' type=6 address=0x00000003 You probably should try downgrading glibc and hope that completes without a seg fault. Carlos had mentioned problems with -17 about a month ago. Don't know if they have been fixed. 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 May 19 18:33:24 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Mon, 19 May 2003 13:33:24 -0400 Subject: [parisc-linux] Inconsistency detected by ld.so:.. / do_page_fault() In-Reply-To: <200305191705.h4JH5YPo020750@hiauly1.hia.nrc.ca> References: <200305191705.h4JH5YPo020750@hiauly1.hia.nrc.ca> Message-ID: <20030519173324.GD4877@systemhalted> > Carlos had mentioned problems with -17 about a month ago. Don't > know if they have been fixed. Not yet. Problem seems to be in the emulation code for unwind find fde. I'm working on stuff right now, but since we don't have an IPC multiplexing call I'm sidetracked into writing semtimedop for our kernel :) c. From bzeeb-lists@lists.zabbadoz.net Mon May 19 19:02:18 2003 From: bzeeb-lists@lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon, 19 May 2003 18:02:18 +0000 (UTC) Subject: [parisc-linux] Inconsistency detected by ld.so:.. / do_page_fault() In-Reply-To: <200305191705.h4JH5YPo020750@hiauly1.hia.nrc.ca> References: <200305191705.h4JH5YPo020750@hiauly1.hia.nrc.ca> Message-ID: On Mon, 19 May 2003, John David Anglin wrote: Hi, > You probably should try downgrading glibc and hope that completes > without a seg fault. > > Carlos had mentioned problems with -17 about a month ago. Don't > know if they have been fixed. Thanks; I found the thread in my mbox'es. What is this patch for ? glibc23-hppa-Rminkernel.dpatch Further more it seems I need to read a bit more on debian package building process in the howtos ;-( ... make[4]: Target `tests' not remade because of errors. make[4]: Leaving directory `/u1/src/glibc/glibc-2.3.1/glibc-2.3.1/elf' make[3]: *** [elf/tests] Error 2 make[3]: Target `check' not remade because of errors. make[3]: Leaving directory `/u1/src/glibc/glibc-2.3.1/glibc-2.3.1' make[2]: *** [check] Error 2 make[2]: Leaving directory `/u1/src/glibc/glibc-2.3.1/hppa-linux/obj' date >>/u1/src/glibc/glibc-2.3.1/log-test-hppa-linux make[1]: Leaving directory `/u1/src/glibc/glibc-2.3.1' touch /u1/src/glibc/glibc-2.3.1/hppa-linux/compiled-source debian/rules binary Need root privileges make: *** [/u1/src/glibc/glibc-2.3.1/hppa-linux/installed-binaries] Error 1 PS: again from building time (2.5.69-pa1) : kernel BUG at include/linux/swapops.h:68! Kernel addresses on the stack: [<1012414c>] printk+0x17c/0x1bc [<101059e8>] dump_stack+0x10/0x1c [<1014dbfc>] try_to_unmap_one+0x264/0x328 [<1013e324>] __set_page_dirty_nobuffers+0x9c/0xac [<1014de24>] try_to_unmap+0x164/0x208 [<10150fa0>] swap_writepage+0xac/0x10c [<10143f6c>] shrink_list+0x288/0x558 [<101429d4>] __pagevec_release+0x20/0x30 [<101443e4>] shrink_cache+0x1a8/0x3b8 [<101450c4>] balance_pgdat+0x17c/0x1cc [<10145238>] kswapd+0x124/0x140 [<10109c5c>] ret_from_kernel_thread+0x1c/0x24 kernel BUG at mm/rmap.c:343! Kernel addresses on the stack: [<1012414c>] printk+0x17c/0x1bc [<101059e8>] dump_stack+0x10/0x1c [<1014dbdc>] try_to_unmap_one+0x244/0x328 [<1013e324>] __set_page_dirty_nobuffers+0x9c/0xac [<1014de24>] try_to_unmap+0x164/0x208 [<10150fa0>] swap_writepage+0xac/0x10c [<10143f6c>] shrink_list+0x288/0x558 [<101429d4>] __pagevec_release+0x20/0x30 [<101443e4>] shrink_cache+0x1a8/0x3b8 [<101450c4>] balance_pgdat+0x17c/0x1cc [<10145238>] kswapd+0x124/0x140 [<10109c5c>] ret_from_kernel_thread+0x1c/0x24 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From carlos@baldric.uwo.ca Mon May 19 20:40:28 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Mon, 19 May 2003 15:40:28 -0400 Subject: [parisc-linux] Inconsistency detected by ld.so:.. / do_page_fault() In-Reply-To: References: <200305191705.h4JH5YPo020750@hiauly1.hia.nrc.ca> Message-ID: <20030519194028.GA542@systemhalted> > What is this patch for ? > glibc23-hppa-Rminkernel.dpatch Does two things: 1- Sets minimum required kernel version for glibc to run on. 2- Enables unwind_find_fde copat code. > make[4]: Target `tests' not remade because of errors. > make[4]: Leaving directory `/u1/src/glibc/glibc-2.3.1/glibc-2.3.1/elf' > make[3]: *** [elf/tests] Error 2 > make[3]: Target `check' not remade because of errors. > make[3]: Leaving directory `/u1/src/glibc/glibc-2.3.1/glibc-2.3.1' > make[2]: *** [check] Error 2 > make[2]: Leaving directory `/u1/src/glibc/glibc-2.3.1/hppa-linux/obj' > date >>/u1/src/glibc/glibc-2.3.1/log-test-hppa-linux > make[1]: Leaving directory `/u1/src/glibc/glibc-2.3.1' > touch /u1/src/glibc/glibc-2.3.1/hppa-linux/compiled-source > debian/rules binary > Need root privileges > make: *** [/u1/src/glibc/glibc-2.3.1/hppa-linux/installed-binaries] Error 1 Did you use -rfakeroot as a dpkg-buildpackage option? > PS: again from building time (2.5.69-pa1) : Can't help you there since I can't recreate the problem. c. From carlos@baldric.uwo.ca Mon May 19 21:12:24 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Mon, 19 May 2003 16:12:24 -0400 Subject: [parisc-linux] 2.4 and semtimedop - need kernel compat? Message-ID: <20030519201224.GB542@systemhalted> pa, I think I'm leaving the "filling in" of this to Randolph :) For now it provides enough functionality for glibc to build and be all happy and merry. Wether we strictly need compat code for semtimedop is uknown. Comments appreciated before checkin. Willy handed out the new syscall number 228 for semtimedop. c. Index: arch/parisc/kernel/sys_parisc.c =================================================================== RCS file: /var/cvs/linux/arch/parisc/kernel/sys_parisc.c,v retrieving revision 1.14 diff -u -p -r1.14 sys_parisc.c --- arch/parisc/kernel/sys_parisc.c 23 Nov 2001 21:54:28 -0000 1.14 +++ arch/parisc/kernel/sys_parisc.c 19 May 2003 19:57:48 -0000 @@ -256,3 +256,11 @@ int sys_shmctl_broken(int shmid, int cmd return sys_shmctl (shmid, cmd, (struct shmid_ds *)buf); } +/* 2.4 compat code required for IPC calls */ +asmlinkage long sys_semtimedop(int semid, struct sembuf *tsops, + unsigned nsops, const struct timespec *timeout) +{ + /* FIXME: Need to implement compat? */ + return -ENOSYS; +} + Index: arch/parisc/kernel/sys_parisc32.c =================================================================== RCS file: /var/cvs/linux/arch/parisc/kernel/sys_parisc32.c,v retrieving revision 1.27 diff -u -p -r1.27 sys_parisc32.c --- arch/parisc/kernel/sys_parisc32.c 14 Sep 2002 05:14:03 -0000 1.27 +++ arch/parisc/kernel/sys_parisc32.c 19 May 2003 19:57:48 -0000 @@ -3104,3 +3104,11 @@ asmlinkage long sys32_semctl_broken(int return sys_semctl (semid, semnum, cmd, arg); } +/* 2.4 compat code required for IPC calls */ +asmlinkage long sys32_semtimedop(int semid, struct sembuf *tsops, + unsigned nsops, const struct timespec *timeout) +{ + /* FIXME: Possible 32/64 conversions required */ + /* FIXME: Need to implement compat? */ + return -ENOSYS; +} Index: arch/parisc/kernel/syscall.S =================================================================== RCS file: /var/cvs/linux/arch/parisc/kernel/syscall.S,v retrieving revision 1.78 diff -u -p -r1.78 syscall.S --- arch/parisc/kernel/syscall.S 4 Aug 2002 22:57:47 -0000 1.78 +++ arch/parisc/kernel/syscall.S 19 May 2003 19:57:48 -0000 @@ -604,8 +604,31 @@ sys_call_table: #endif ENTRY_SAME(gettid) ENTRY_SAME(readahead) - ENTRY_SAME(tkill) + ENTRY_SAME(tkill) /* 208 */ + /* COMPAT semtimedop call requires the same syscall number + across kernel versions. */ + + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) /* 210 */ + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) /* 220 */ + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) + ENTRY_SAME(ni_syscall) + ENTRY_DIFF(semtimedop) /* 228 */ .end /* Make sure nothing else is placed on this page */ Index: include/asm-parisc/unistd.h =================================================================== RCS file: /var/cvs/linux/include/asm-parisc/unistd.h,v retrieving revision 1.26 diff -u -p -r1.26 unistd.h --- include/asm-parisc/unistd.h 4 Aug 2002 22:59:52 -0000 1.26 +++ include/asm-parisc/unistd.h 19 May 2003 19:57:50 -0000 @@ -702,6 +702,8 @@ #define __NR_readahead (__NR_Linux + 207) #define __NR_tkill (__NR_Linux + 208) +#define __NR_semtimedop (__NR_Linux + 228) + #define __NR_Linux_syscalls 208 #define HPUX_GATEWAY_ADDR 0xC0000004 From willy@debian.org Mon May 19 23:06:31 2003 From: willy@debian.org (Matthew Wilcox) Date: Mon, 19 May 2003 23:06:31 +0100 Subject: [parisc-linux] 2.4 and semtimedop - need kernel compat? In-Reply-To: <20030519201224.GB542@systemhalted> References: <20030519201224.GB542@systemhalted> Message-ID: <20030519220631.GA31518@parcelfarce.linux.theplanet.co.uk> On Mon, May 19, 2003 at 04:12:24PM -0400, Carlos O'Donell wrote: > > pa, > > I think I'm leaving the "filling in" of this to Randolph :) > For now it provides enough functionality for glibc to build and be all > happy and merry. Wether we strictly need compat code for semtimedop is > uknown. Uh, you don't need to do anything. If you call an unassigned syscall, you get -ENOSYS. -- "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 taggart@carmen.fc.hp.com Mon May 19 23:33:27 2003 From: taggart@carmen.fc.hp.com (Matt Taggart) Date: Mon, 19 May 2003 16:33:27 -0600 Subject: [parisc-linux] Gentoo HPPA port Message-ID: <20030519223327.3ED4437D68@carmen.fc.hp.com> Hi palinux'ers, Someone just pointed me at a Gentoo HPPA install guide, http://www.gentoo.org/doc/en/gentoo-hppa-install.xml If any Gentoo people are paying attention you might want to keep the list up to date with what you're doing so that someone can update the parisc-linux.org website with any future announcements you'd like to make. -- Matt Taggart taggart@fc.hp.com From rtodd@antipentium.com Mon May 19 23:53:25 2003 From: rtodd@antipentium.com (Richard Todd) Date: Mon, 19 May 2003 18:53:25 -0400 Subject: [parisc-linux] Gentoo HPPA port In-Reply-To: <20030519223327.3ED4437D68@carmen.fc.hp.com> Message-ID: I have Gentoo running on a few HPPA boxes (j5000 and a C180) Guy, the lead HPPA porter for PA-Risc Gentoo has been working very hard to get a lot of things working. We have Gentoo running very well in SMP as well as working on GCC3.3 which is working rather well so far. There is usually someone in irc.freenode.net #gentoo-hppa for help if anyone needs it.... -- Never be afraid to try something new. Remember, Amateurs built the ark. Professionals built the Titanic. On 5/19/03 6:33 PM, "Matt Taggart" wrote: > Hi palinux'ers, > > Someone just pointed me at a Gentoo HPPA install guide, > > http://www.gentoo.org/doc/en/gentoo-hppa-install.xml > > If any Gentoo people are paying attention you might want to keep the > list up to date with what you're doing so that someone can update the > parisc-linux.org website with any future announcements you'd like to > make. From carlos@baldric.uwo.ca Tue May 20 00:16:20 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Mon, 19 May 2003 19:16:20 -0400 Subject: [parisc-linux] 2.4 and semtimedop - need kernel compat? In-Reply-To: <20030519220631.GA31518@parcelfarce.linux.theplanet.co.uk> References: <20030519201224.GB542@systemhalted> <20030519220631.GA31518@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030519231620.GA1489@systemhalted> > Uh, you don't need to do anything. If you call an unassigned syscall, > you get -ENOSYS. The idea was that it might be able to provide the required compat functionality in 2.4. If we feel it's not possible then we can eliminate all the entries in sys_parisc.c/sys32_parisc.c and leave the syscall as ENTRY_SAME(nisyscall) in entry.S. The glibc side of the code is done. c. From jsoe0708@tiscali.be Tue May 20 13:19:02 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 20 May 2003 14:19:02 +0200 Subject: [parisc-linux] RE: Dump module patche. Message-ID: <3EC7621000000876@ocpmta8.freegates.net> >gcc version 3.0.4 > > >Joel Soete wrote: >> Bruno, >> >>>>sorry, I don't remember this kind of error...did you try make mrproper >>> >> ??? >> >>>> >>>I think so as I prefer distclean? >>> >>>umm 2.4.20-pa32 is still available in ftp.p-l.org:/cvs so I will first >grab >>>it and apply patch. Then comeback to you :) >>> >> >> It didn't help so I have to come back to you with severall questions: >> >> A. what is your compiler release gcc 3.0 3.2 3.3? >> >> B. I suspect also a different .config: may I ask your to compare with mine? >> Hi Bruno, Continuing my investigation, I reach now (with some known modif) to compile the kernel with your patch and gcc-3.3 (as it seems that it became the default in unstable) but to reach to compile dump_lbz2 (as static builtin) i had to change following stuff into driver/dump/Makefile: --- Makefile.orig 2003-05-20 14:50:46.000000000 +0200 +++ Makefile 2003-05-20 12:58:43.000000000 +0200 @@ -6,6 +6,7 @@ # the dump directory. # +O_TARGET := dumpdrv.o export-objs := dump_base.o list-multi := dump.o @@ -34,7 +35,8 @@ dump-objs += dump_parisc.o endif +include $(TOPDIR)/Rules.make + dump.o: $(dump-objs) $(LD) -r -o $@ $(dump-objs) -include $(TOPDIR)/Rules.make I do not realy understand make :( Thanks for advise, Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From jsoe0708@tiscali.be Tue May 20 18:20:57 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Tue, 20 May 2003 19:20:57 +0200 Subject: [parisc-linux] 2.4 and semtimedop - need kernel compat? Message-ID: <3EC76210000009D0@ocpmta8.freegates.net> >The idea was that it might be able to provide the required compat >functionality in 2.4. If we feel it's not possible then we can eliminate >all the entries in sys_parisc.c/sys32_parisc.c and leave the syscall as >ENTRY_SAME(nisyscall) in entry.S. > >The glibc side of the code is done. > Hi Carlos, In the very last Andrea's patch 2.4.21rc2aa1.bz2, I read that Andrea already back port this stuff :) At a first glance, the job is also applied for hppa. Would you like that I have a look to see if it is applicable with your patch in p-l cvs tree? Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From hamilton@tteng.com.br Tue May 20 22:55:41 2003 From: hamilton@tteng.com.br (Hamilton Coutinho) Date: Tue, 20 May 2003 18:55:41 -0300 Subject: [parisc-linux] Building glibc (static) with 64 bits toolchain Message-ID: <20030520215541.GA11860@hamilton.tteng.com.br> Hello, I'm trying to figure it out how far we are from the most simple 64 bits userspace I could think of. I read the list's archive and understand that this is a subject that was beaten to death already (I'm also aware of the doubtful usefulness of it). So, I'm planning to annoy you the least I can :) I think I have all sorted out (well, most of it, I think): for a simple "hello world" app I need kernel support for execve, brk, write, mmap (and a few others), a 64 bits toolchain and a libc (diet or the full blown glibc :). Sure enough, the libc is the grayest area for me. >From the archive, I read that Carlos O'Donell is working on this very subject with promising results. So I setup to build a full blown glibc. After tinkering with it a little I realized that sysdeps/hppa/hppa64 directory was missing. I couldn't find it anywhere (tried glibc cvs, parisc cvs, debian). Could you help me with directions to where to find it? Thanks. -- Hamilton Coutinho hamilton@tteng.com.br T&T Engenheiros Associados Ltda (http://www.tteng.com.br/) Fone/Fax (51) 3224-8425 Porto Alegre - RS - Brasil From doko@cs.tu-berlin.de Wed May 21 00:42:53 2003 From: doko@cs.tu-berlin.de (Matthias Klose) Date: Wed, 21 May 2003 01:42:53 +0200 Subject: [parisc-linux] gcc-3.3 configuration Message-ID: <16074.48509.259405.775905@gargle.gargle.HOWL> For Debian GNU/Linux gcc-3.3 is currently configured with --with-sjlj-exceptions to allow a binary compatible upgrade from gcc-3.2 to gcc-3.3. The other Debian platform, where sjlj based exceptions changed to dwarf2 based exceptions is m68k, therefore the CC. As there are no hppa/m68k distributions released using gcc-3.2, compatibility with other released distros is not an issue. OTOH, I see Gentoo and probably other distros built for hppa, first starting with gcc-3.3, and maybe configured the standard way. Is it worth (or needed) to strive for binary compatibility of hppa based distributions, based on gcc-3.3 and glibc-2.3.x? If yes, does the following approach work: Build a libstdc++5-3.3, conflicting with libstdc++5 (including libstdc++ with the same soname) and doing binary uploads for hppa for all libstdc++5 dependent packages? (The same could be done for m68k, but the compatibility argument doesn't hold as Debian seems to be the only m68k based distro). Matthias From willy@debian.org Wed May 21 01:08:54 2003 From: willy@debian.org (Matthew Wilcox) Date: Wed, 21 May 2003 01:08:54 +0100 Subject: [parisc-linux] gcc-3.3 configuration In-Reply-To: <16074.48509.259405.775905@gargle.gargle.HOWL> References: <16074.48509.259405.775905@gargle.gargle.HOWL> Message-ID: <20030521000854.GN31518@parcelfarce.linux.theplanet.co.uk> On Wed, May 21, 2003 at 01:42:53AM +0200, Matthias Klose wrote: > For Debian GNU/Linux gcc-3.3 is currently configured with > > --with-sjlj-exceptions > > to allow a binary compatible upgrade from gcc-3.2 to gcc-3.3. The > other Debian platform, where sjlj based exceptions changed to dwarf2 > based exceptions is m68k, therefore the CC. *sigh*. I'm very conflicted over this. On one hand, Debian is the de-facto standard for PA-RISC/Linux binaries. If another distro cares about binary compatibility, they should follow Debian. On the other hand, dwarf exceptions are clearly superior to sjlj. We've never _released_ a distro compiled with 3.2 so we can break the binary ABI without major repurcussions. I'm not sure it's my call to make; I can see arguments on both sides. -- "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 Wed May 21 00:26:10 2003 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: 21 May 2003 00:26:10 +0100 Subject: [parisc-linux] gcc-3.3 configuration In-Reply-To: <20030521000854.GN31518@parcelfarce.linux.theplanet.co.uk> References: <16074.48509.259405.775905@gargle.gargle.HOWL> <20030521000854.GN31518@parcelfarce.linux.theplanet.co.uk> Message-ID: <1053473168.31455.21.camel@dhcp22.swansea.linux.org.uk> On Mer, 2003-05-21 at 01:08, Matthew Wilcox wrote: > I'm not sure it's my call to make; I can see arguments on both sides. Thats at least one of the reasons. Reputation capital is a wonderous thing. Accept reality, you are the Linus of parisc Linux like it or not 8) From dave@hiauly1.hia.nrc.ca Wed May 21 02:02:27 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Tue, 20 May 2003 21:02:27 -0400 (EDT) Subject: [parisc-linux] gcc-3.3 configuration In-Reply-To: <1053473168.31455.21.camel@dhcp22.swansea.linux.org.uk> from "Alan Cox" at May 21, 2003 00:26:10 am Message-ID: <200305210102.h4L12S7U007116@hiauly1.hia.nrc.ca> > On Mer, 2003-05-21 at 01:08, Matthew Wilcox wrote: > > I'm not sure it's my call to make; I can see arguments on both sides. > > Thats at least one of the reasons. Reputation capital is a wonderous > thing. Accept reality, you are the Linus of parisc Linux like it or not > 8) I agree. 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 Wed May 21 03:09:08 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Tue, 20 May 2003 22:09:08 -0400 Subject: [parisc-linux] 2.4 and semtimedop - need kernel compat? In-Reply-To: <3EC76210000009D0@ocpmta8.freegates.net> References: <3EC76210000009D0@ocpmta8.freegates.net> Message-ID: <20030521020908.GE10485@systemhalted> > In the very last Andrea's patch 2.4.21rc2aa1.bz2, I read that Andrea already > back port this stuff :) > > At a first glance, the job is also applied for hppa. Would you like that > I have a look to see if it is applicable with your patch in p-l cvs tree? Seeing as how our glibc 2.3.2 is highly unstable and non-functional, it won't help very much :( It should be easy enough to connect our syscall to semtimedop when the code is backported. c. From carlos@baldric.uwo.ca Wed May 21 04:07:33 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Tue, 20 May 2003 23:07:33 -0400 Subject: [parisc-linux] Building glibc (static) with 64 bits toolchain In-Reply-To: <20030520215541.GA11860@hamilton.tteng.com.br> References: <20030520215541.GA11860@hamilton.tteng.com.br> Message-ID: <20030521030733.GH10485@systemhalted> > From the archive, I read that Carlos O'Donell is working on this very > subject with promising results. So I setup to build a full blown glibc. > After tinkering with it a little I realized that sysdeps/hppa/hppa64 > directory was missing. I couldn't find it anywhere (tried glibc cvs, > parisc cvs, debian). Could you help me with directions to where to find > it? I'd love to see those promising results :) I have a hard enough time working on a 32-bit userspace. There is no 64-bit port that works. I have some bits of code, but to tell you the truth it just isn't a priority. Other things, like a working 32-bit glibc rank higher... sorry. If you would like to start by testing our 64-bit toolchain, please build a 64-bit cross system (hppa -> hppa64) and get back to the list with your results :) c. From Randolph Chung Wed May 21 06:23:51 2003 From: Randolph Chung (Randolph Chung) Date: Tue, 20 May 2003 22:23:51 -0700 Subject: [parisc-linux] gcc-3.3 configuration In-Reply-To: <16074.48509.259405.775905@gargle.gargle.HOWL> References: <16074.48509.259405.775905@gargle.gargle.HOWL> Message-ID: <20030521052351.GV548@tausq.org> > If yes, does the following approach work: Build a libstdc++5-3.3, > conflicting with libstdc++5 (including libstdc++ with the same soname) > and doing binary uploads for hppa for all libstdc++5 dependent > packages? (The same could be done for m68k, but the compatibility > argument doesn't hold as Debian seems to be the only m68k based > distro). Aside from the evilness of doing binNMUs of this magnitude, I doubt a "transition" that doesn't change the SONAME will work. As soon as the new libstdc++ is installed, every c++ app on the box will instantly break. This means if anything happens e.g. to apt during the update, the system will get into a very nasty state. I don't think this is worth it. If we need to change the SONAME, then there's no binary compatibility anyway... As willy mentioned in his other email, if other distros want binary compatibility, they should follow what Debian is doing (on hppa), since Debian was there first :-) my 2 cents, randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From jsoe0708@tiscali.be Wed May 21 07:30:59 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Wed, 21 May 2003 08:30:59 +0200 Subject: [parisc-linux] 2.4 and semtimedop - need kernel compat? In-Reply-To: <20030521020908.GE10485@systemhalted> Message-ID: <3EC76170000016C4@ocpmta1.freegates.net> > >> In the very last Andrea's patch 2.4.21rc2aa1.bz2, I read that Andrea already >> back port this stuff :) >> >> At a first glance, the job is also applied for hppa. Would you like that >> I have a look to see if it is applicable with your patch in p-l cvs tree? > >Seeing as how our glibc 2.3.2 is highly unstable and non-functional, it >won't help very much :( > >It should be easy enough to connect our syscall to semtimedop when the >code is backported. > Ok J. --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From jsoe0708@tiscali.be Wed May 21 13:23:31 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Wed, 21 May 2003 14:23:31 +0200 Subject: [parisc-linux] last binutils-2.14.90.0.2-0.1[was-2.14.90.0.1] failled to build kernel In-Reply-To: <3EC39DA000000769@ocpmta7.freegates.net> Message-ID: <3EC7617000001BB5@ocpmta1.freegates.net> Hi All, > >I am now runing a kernel 2.4.20-pa35 + lkcd bruno's patch with gcc-3.2. > >In the mean time I made a distupgrade which mainly update binutils from 2.13.90.0.18-1.7 >to 2.14.90.0.1-0.1 which make now failed the rebuild of the kernel: >[...] Still failed with binutils_2.14.90.0.2-0.1 :(( gcc -D__ASSEMBLY__ -traditional -D__KERNEL__ -I/usr/src/work/linux-2.4.21-rc2-pa35/include -c -o real2.o real2.S real2.S: Assembler messages: real2.S:126: Error: too many positional arguments make[1]: *** [real2.o] Error 1 J. --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From dave@hiauly1.hia.nrc.ca Wed May 21 14:25:20 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Wed, 21 May 2003 09:25:20 -0400 (EDT) Subject: [parisc-linux] last binutils-2.14.90.0.2-0.1[was-2.14.90.0.1] failled to build kernel In-Reply-To: <3EC7617000001BB5@ocpmta1.freegates.net> from "Joel Soete" at May 21, 2003 02:23:31 pm Message-ID: <200305211325.h4LDPLmV015249@hiauly1.hia.nrc.ca> > >I am now runing a kernel 2.4.20-pa35 + lkcd bruno's patch with gcc-3.2. > > > >In the mean time I made a distupgrade which mainly update binutils from > 2.13.90.0.18-1.7 > >to 2.14.90.0.1-0.1 which make now failed the rebuild of the kernel: > >[...] > Still failed with binutils_2.14.90.0.2-0.1 :(( > > gcc -D__ASSEMBLY__ -traditional -D__KERNEL__ -I/usr/src/work/linux-2.4.21-rc2-pa35/include > -c -o real2.o real2.S > real2.S: Assembler messages: > real2.S:126: Error: too many positional arguments > make[1]: *** [real2.o] Error 1 This probably is due to these changes: 2003-04-23 H.J. Lu * app.c (do_scrub_chars): More checks for valid labels. 2003-04-22 H.J. Lu * app.c (do_scrub_chars): Check for valid label. I reverted the relevant part of the above on the 2.14 branch. 2003-04-30 Alan Modra * config/tc-hppa.c (hppa_symbol_chars): Revert 2003-04-28 change. * config/tc-hppa.h (tc_symbol_chars): Likewise. * config/tc-ppc.c (ppc_symbol_chars): Revert 2003-04-24 change. * config/tc-ppc.h (tc_symbol_chars): Likewise. * app.c (do_scrub_chars): Revert 2003-04-23 and 2003-04-22 changes. These are still on the binutils trunk. For the moment, I would advise not using any binutils version which includes these changes. While the assembler probably will work ok with GCC, the semantics have changed sufficiently that there may be problems with hand written assembler files. These were done nominally to improve the detection of labels on ia64. However, the change to tc-hppa.c has affected the removal of extraneous whitespace. I think it also has affected the character set allowed to be used for symbols. If it has, I am going to ask for reversion of the above changes. Joel, could you send me offline a few lines from real2.S around line 126? 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 Wed May 21 18:29:29 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Wed, 21 May 2003 13:29:29 -0400 Subject: [parisc-linux] [PATCH] HPPA Linuxthreads. Message-ID: <20030521172929.GB21858@systemhalted> libc-alpha, This is a cleaner HPPA linuxthreads implementation that stems from the work that John David Anglin and myself did to devise a self-aligning lock system that doesn't impose the 16-byte lock alignment restriction. Many thanks go to John for all his hard work! This will also allow hppa to relax malloc alignment back to 8 (future patches). libc/linuxthreads/* sysdeps/hppa/pt-machine.h | 81 ++++++++++++++++++++++----- sysdeps/hppa/pspinlock.c | 29 ++++----- sysdeps/unix/sysv/linux/hppa/bits/initspin.h | 22 +++++-- sysdeps/pthread/bits/libc-lock.h | 6 +- sysdeps/pthread/bits/pthreadtypes.h | 8 +- descr.h | 2 pt-machine.c | 4 + pthread.c | 14 ++-- spinlock.c | 24 ++++---- spinlock.h | 26 ++++++-- 10 files changed, 148 insertions(+), 68 deletions(-) Comments welcome. Patches tested on HPPA, i686. c. --- 2003-05-19 Carlos O'Donell * linuxthreads/sysdeps/hppa/pt-machine.h (THREAD_SELF): Define. (INIT_THREAD_SELF): Define. (testandset): Use __ldcw_align. (lock_held): Define. (__ldcw): Define. (__ldcw_align): Define. (__load_and_clear): Define. * linuxthreads/sysdeps/hppa/pspinlock.c (__pthread_spin_lock): Use __ldcw_align. (__pthread_spin_trylock): Likewise. (__pthread_spin_unlock): Likewise. (__pthread_spin_init): Likewise. * linuxthreads/sysdeps/unix/sysv/linux/hppa/bits/initspin.h (__LT_SPINLOCK_INIT): Define. (__LT_SPINLOCK_ALT_INIT): Define. (__LOCK_INITIALIZER): Define. (__LOCK_ALT_INITIALIZER): Define. (__ATOMIC_INITIALIZER): Define. (__LT_INITIALIZER_NOT_ZERO): Define. * linuxthreads/sysdeps/pthread/bits/libc-lock.h: Use __LT_INITIALIZER_NOT_ZERO instead of __LT_SPINLOCK_INIT. * linuxthreads/sysdeps/pthread/bits/pthreadtypes.h: Add global default definition for __atomic_lock_t. (pthread_fastlock): Change __spinlock to type __atomic_lock_t. * linuxthreads/descr.h (pthread_atomic): change p_spinlock to type __atomic_lock_t from int *. * linuxthreads/pt-machine.c: include pthread.h, change extern testandset prototype to use __atomic_lock_t * spinlock. * linuxthreads/pthread.c (__pthread_initialize_minimal): Use __LT_INITIALIZER_NOT_ZERO. * linuxthreads/spinlock.c: use __pthread_lock_define_initialized macro to initialize wait_node_free_list_spinlock. (__pthread_acquire): change prototype to use __atomic_lock_t * spinlock. (__pthread_release): Likewise. (__pthread_compare_and_swap): Likewise. (__pthread_acquire): Likewise. (__pthread_alt_lock): Use __LT_SPINLOCK_INIT to initialize locks. (__pthread_alt_timedlock): Likewise. * linuxthreads/spinlock.h: define default lock_held, __pthread_lock_define_initialized, and modify prototypes for __pthread_compare_and_swap, compare_and_swap, compare_and_swap_with_release_semantics, compare_and_swap, __pthread_compare_and_swap to use __atomic_lock_t * spinlock. diff -urN glibc-2.3.1.orig/linuxthreads/descr.h glibc-2.3.1/linuxthreads/descr.h --- glibc-2.3.1.orig/linuxthreads/descr.h 2003-01-15 12:58:11.000000000 -0500 +++ glibc-2.3.1/linuxthreads/descr.h 2003-01-15 18:24:36.000000000 -0500 @@ -70,7 +70,7 @@ /* Atomic counter made possible by compare_and_swap */ struct pthread_atomic { long p_count; - int p_spinlock; + __atomic_lock_t p_spinlock; }; diff -urN glibc-2.3.1.orig/linuxthreads/pt-machine.c glibc-2.3.1/linuxthreads/pt-machine.c --- glibc-2.3.1.orig/linuxthreads/pt-machine.c 2002-08-26 18:39:45.000000000 -0400 +++ glibc-2.3.1/linuxthreads/pt-machine.c 2003-01-15 18:24:36.000000000 -0500 @@ -19,7 +19,9 @@ #define PT_EI -extern long int testandset (int *spinlock); +#include + +extern long int testandset (__atomic_lock_t *spinlock); extern int __compare_and_swap (long int *p, long int oldval, long int newval); #include diff -urN glibc-2.3.1.orig/linuxthreads/pthread.c glibc-2.3.1/linuxthreads/pthread.c --- glibc-2.3.1.orig/linuxthreads/pthread.c 2003-01-15 12:58:15.000000000 -0500 +++ glibc-2.3.1/linuxthreads/pthread.c 2003-01-15 18:24:36.000000000 -0500 @@ -296,9 +296,9 @@ pthread_descr self; /* First of all init __pthread_handles[0] and [1] if needed. */ -# if __LT_SPINLOCK_INIT != 0 - __pthread_handles[0].h_lock = __LOCK_INITIALIZER; - __pthread_handles[1].h_lock = __LOCK_INITIALIZER; +# ifdef __LT_INITIALIZER_NOT_ZERO + __pthread_handles[0].h_lock = __LOCK_ALT_INITIALIZER; + __pthread_handles[1].h_lock = __LOCK_ALT_INITIALIZER; # endif # ifndef SHARED /* Unlike in the dynamically linked case the dynamic linker has not @@ -366,7 +366,7 @@ # endif /* self->p_start_args need not be initialized, it's all zero. */ self->p_userstack = 1; -# if __LT_SPINLOCK_INIT != 0 +# ifdef __LT_INITIALIZER_NOT_ZERO self->p_resume_count = (struct pthread_atomic) __ATOMIC_INITIALIZER; # endif self->p_alloca_cutoff = __MAX_ALLOCA_CUTOFF; @@ -380,9 +380,9 @@ #else /* USE_TLS */ /* First of all init __pthread_handles[0] and [1]. */ -# if __LT_SPINLOCK_INIT != 0 - __pthread_handles[0].h_lock = __LOCK_INITIALIZER; - __pthread_handles[1].h_lock = __LOCK_INITIALIZER; +# ifdef __LT_INITIALIZER_NOT_ZERO + __pthread_handles[0].h_lock = __LOCK_ALT_INITIALIZER; + __pthread_handles[1].h_lock = __LOCK_ALT_INITIALIZER; # endif __pthread_handles[0].h_descr = &__pthread_initial_thread; __pthread_handles[1].h_descr = &__pthread_manager_thread; diff -urN glibc-2.3.1.orig/linuxthreads/spinlock.c glibc-2.3.1/linuxthreads/spinlock.c --- glibc-2.3.1.orig/linuxthreads/spinlock.c 2002-08-29 06:32:19.000000000 -0400 +++ glibc-2.3.1/linuxthreads/spinlock.c 2003-01-15 18:24:36.000000000 -0500 @@ -24,9 +24,9 @@ #include "spinlock.h" #include "restart.h" -static void __pthread_acquire(int * spinlock); +static void __pthread_acquire(__atomic_lock_t * spinlock); -static inline void __pthread_release(int * spinlock) +static inline void __pthread_release(__atomic_lock_t * spinlock) { WRITE_MEMORY_BARRIER(); *spinlock = __LT_SPINLOCK_INIT; @@ -269,11 +269,11 @@ struct wait_node { struct wait_node *next; /* Next node in null terminated linked list */ pthread_descr thr; /* The thread waiting with this node */ - int abandoned; /* Atomic flag */ + __atomic_lock_t abandoned; /* Atomic flag */ }; static long wait_node_free_list; -static int wait_node_free_list_spinlock; +__pthread_lock_define_initialized(static, wait_node_free_list_spinlock); /* Allocate a new node from the head of the free list using an atomic operation, or else using malloc if that list is empty. A fundamental @@ -376,7 +376,7 @@ if (self == NULL) self = thread_self(); - wait_node.abandoned = 0; + wait_node.abandoned = __LT_SPINLOCK_INIT; wait_node.next = (struct wait_node *) lock->__status; wait_node.thr = self; lock->__status = (long) &wait_node; @@ -402,7 +402,7 @@ wait_node.thr = self; newstatus = (long) &wait_node; } - wait_node.abandoned = 0; + wait_node.abandoned = __LT_SPINLOCK_INIT; wait_node.next = (struct wait_node *) oldstatus; /* Make sure the store in wait_node.next completes before performing the compare-and-swap */ @@ -451,7 +451,7 @@ if (self == NULL) self = thread_self(); - p_wait_node->abandoned = 0; + p_wait_node->abandoned = __LT_SPINLOCK_INIT; p_wait_node->next = (struct wait_node *) lock->__status; p_wait_node->thr = self; lock->__status = (long) p_wait_node; @@ -474,7 +474,7 @@ p_wait_node->thr = self; newstatus = (long) p_wait_node; } - p_wait_node->abandoned = 0; + p_wait_node->abandoned = __LT_SPINLOCK_INIT; p_wait_node->next = (struct wait_node *) oldstatus; /* Make sure the store in wait_node.next completes before performing the compare-and-swap */ @@ -574,7 +574,7 @@ while (p_node != (struct wait_node *) 1) { int prio; - if (p_node->abandoned) { + if (lock_held(&p_node->abandoned)) { /* Remove abandoned node. */ #if defined TEST_FOR_COMPARE_AND_SWAP if (!__pthread_has_cas) @@ -662,7 +662,7 @@ #if !defined HAS_COMPARE_AND_SWAP || defined TEST_FOR_COMPARE_AND_SWAP int __pthread_compare_and_swap(long * ptr, long oldval, long newval, - int * spinlock) + __atomic_lock_t * spinlock) { int res; @@ -699,7 +699,7 @@ - When nanosleep() returns, we try again, doing MAX_SPIN_COUNT sched_yield(), then sleeping again if needed. */ -static void __pthread_acquire(int * spinlock) +static void __pthread_acquire(__atomic_lock_t * spinlock) { int cnt = 0; struct timespec tm; diff -urN glibc-2.3.1.orig/linuxthreads/spinlock.h glibc-2.3.1/linuxthreads/spinlock.h --- glibc-2.3.1.orig/linuxthreads/spinlock.h 2001-05-24 19:36:35.000000000 -0400 +++ glibc-2.3.1/linuxthreads/spinlock.h 2003-01-15 18:24:36.000000000 -0500 @@ -33,14 +33,28 @@ #endif #endif +/* Define lock_held for all arches that don't need a modified copy. */ +#ifndef __LT_INITIALIZER_NOT_ZERO +# define lock_held(p) *(p) +#endif + +/* Initliazers for possibly complex structures */ +#ifdef __LT_INITIALIZER_NOT_ZERO +# define __pthread_lock_define_initialized(CLASS,NAME) \ + CLASS __atomic_lock_t NAME = __LT_SPINLOCK_ALT_INIT +#else +# define __pthread_lock_define_initialized(CLASS,NAME) \ + CLASS __atomic_lock_t NAME +#endif + #if defined(TEST_FOR_COMPARE_AND_SWAP) extern int __pthread_has_cas; extern int __pthread_compare_and_swap(long * ptr, long oldval, long newval, - int * spinlock); + __atomic_lock_t * spinlock); static inline int compare_and_swap(long * ptr, long oldval, long newval, - int * spinlock) + __atomic_lock_t * spinlock) { if (__builtin_expect (__pthread_has_cas, 1)) return __compare_and_swap(ptr, oldval, newval); @@ -58,7 +72,7 @@ static inline int compare_and_swap_with_release_semantics (long * ptr, long oldval, - long newval, int * spinlock) + long newval, __atomic_lock_t * spinlock) { return __compare_and_swap_with_release_semantics (ptr, oldval, newval); @@ -67,7 +81,7 @@ #endif static inline int compare_and_swap(long * ptr, long oldval, long newval, - int * spinlock) + __atomic_lock_t * spinlock) { return __compare_and_swap(ptr, oldval, newval); } @@ -75,10 +89,10 @@ #else extern int __pthread_compare_and_swap(long * ptr, long oldval, long newval, - int * spinlock); + __atomic_lock_t * spinlock); static inline int compare_and_swap(long * ptr, long oldval, long newval, - int * spinlock) + __atomic_lock_t * spinlock) { return __pthread_compare_and_swap(ptr, oldval, newval, spinlock); } diff -urN glibc-2.3.1.orig/linuxthreads/sysdeps/hppa/pspinlock.c glibc-2.3.1/linuxthreads/sysdeps/hppa/pspinlock.c --- glibc-2.3.1.orig/linuxthreads/sysdeps/hppa/pspinlock.c 2002-08-26 18:39:51.000000000 -0400 +++ glibc-2.3.1/linuxthreads/sysdeps/hppa/pspinlock.c 2003-01-15 18:26:51.000000000 -0500 @@ -24,15 +24,12 @@ int __pthread_spin_lock (pthread_spinlock_t *lock) { - unsigned int val; + unsigned int *addr = __ldcw_align (lock); + + while (__ldcw (addr) == 0) + while (*addr == 0) ; - do - asm volatile ("ldcw %1,%0" - : "=r" (val), "=m" (*lock) - : "m" (*lock)); - while (!val); - - return 0; + return 0; } weak_alias (__pthread_spin_lock, pthread_spin_lock) @@ -40,13 +37,9 @@ int __pthread_spin_trylock (pthread_spinlock_t *lock) { - unsigned int val; - - asm volatile ("ldcw %1,%0" - : "=r" (val), "=m" (*lock) - : "m" (*lock)); + unsigned int *a = __ldcw_align (lock); - return val ? 0 : EBUSY; + return __ldcw (a) ? 0 : EBUSY; } weak_alias (__pthread_spin_trylock, pthread_spin_trylock) @@ -54,7 +47,9 @@ int __pthread_spin_unlock (pthread_spinlock_t *lock) { - *lock = 1; + unsigned int *a = __ldcw_align (lock); + + *a = 1; return 0; } weak_alias (__pthread_spin_unlock, pthread_spin_unlock) @@ -66,7 +61,9 @@ /* We can ignore the `pshared' parameter. Since we are busy-waiting all processes which can access the memory location `lock' points to can use the spinlock. */ - *lock = 1; + unsigned int *a = __ldcw_align (lock); + + *a = 1; return 0; } weak_alias (__pthread_spin_init, pthread_spin_init) diff -urN glibc-2.3.1.orig/linuxthreads/sysdeps/hppa/pt-machine.h glibc-2.3.1/linuxthreads/sysdeps/hppa/pt-machine.h --- glibc-2.3.1.orig/linuxthreads/sysdeps/hppa/pt-machine.h 2002-08-26 18:39:51.000000000 -0400 +++ glibc-2.3.1/linuxthreads/sysdeps/hppa/pt-machine.h 2003-01-15 18:24:49.000000000 -0500 @@ -22,13 +22,13 @@ #ifndef _PT_MACHINE_H #define _PT_MACHINE_H 1 +#include #include #ifndef PT_EI # define PT_EI extern inline #endif -extern long int testandset (int *spinlock); extern int __compare_and_swap (long int *p, long int oldval, long int newval); /* Get some notion of the current stack. Need not be exactly the top @@ -36,27 +36,80 @@ #define CURRENT_STACK_FRAME stack_pointer register char * stack_pointer __asm__ ("%r30"); +/* Get/Set thread-specific pointer. We have to call into the kernel to + * modify it, but we can read it in user mode. */ + +#define THREAD_SELF __get_cr27() + +static inline struct _pthread_descr_struct * __get_cr27(void) +{ + long cr27; + asm("mfctl %%cr27, %0" : "=r" (cr27) : ); + return (struct _pthread_descr_struct *) cr27; +} + +#define INIT_THREAD_SELF(descr, nr) __set_cr27(descr) + +static inline void __set_cr27(struct _pthread_descr_struct * cr27) +{ + asm( + "ble 0xe0(%%sr2, %%r0)\n\t" + "copy %0, %%r26" + : : "r" (cr27) : "r26" ); +} + +/* We want the OS to assign stack addresses. */ +#define FLOATING_STACKS 1 +#define ARCH_STACK_MAX_SIZE 8*1024*1024 /* The hppa only has one atomic read and modify memory operation, load and clear, so hppa spinlocks must use zero to signify that - someone is holding the lock. */ + someone is holding the lock. The address used for the ldcw + semaphore must be 16-byte aligned. */ +#define __ldcw(a) ({ \ + unsigned int __ret; \ + __asm__ __volatile__("ldcw 0(%2),%0" \ + : "=r" (__ret), "=m" (*(a)) : "r" (a)); \ + __ret; \ +}) + +/* Because malloc only guarantees 8-byte alignment for malloc'd data, + and GCC only guarantees 8-byte alignment for stack locals, we can't + be assured of 16-byte alignment for atomic lock data even if we + specify "__attribute ((aligned(16)))" in the type declaration. So, + we use a struct containing an array of four ints for the atomic lock + type and dynamically select the 16-byte aligned int from the array + for the semaphore. */ +#define __PA_LDCW_ALIGNMENT 16 +#define __ldcw_align(a) ({ \ + unsigned int __ret = (unsigned int) a; \ + if ((__ret & ~(__PA_LDCW_ALIGNMENT - 1)) < (unsigned int) a) \ + __ret = (__ret & ~(__PA_LDCW_ALIGNMENT - 1)) + __PA_LDCW_ALIGNMENT; \ + (unsigned int *) __ret; \ +}) -#define xstr(s) str(s) -#define str(s) #s /* Spinlock implementation; required. */ -PT_EI long int -testandset (int *spinlock) +PT_EI int +__load_and_clear (__atomic_lock_t *spinlock) { - int ret; + unsigned int *a = __ldcw_align (spinlock); - __asm__ __volatile__( - "ldcw 0(%2),%0" - : "=r"(ret), "=m"(*spinlock) - : "r"(spinlock)); + return __ldcw (a); +} - return ret == 0; +/* Emulate testandset */ +PT_EI long int +testandset (__atomic_lock_t *spinlock) +{ + return (__load_and_clear(spinlock) == 0); } -#undef str -#undef xstr +PT_EI int +lock_held (__atomic_lock_t *spinlock) +{ + unsigned int *a = __ldcw_align (spinlock); + + return *a == 0; +} + #endif /* pt-machine.h */ diff -urN glibc-2.3.1.orig/linuxthreads/sysdeps/pthread/bits/libc-lock.h glibc-2.3.1/linuxthreads/sysdeps/pthread/bits/libc-lock.h --- glibc-2.3.1.orig/linuxthreads/sysdeps/pthread/bits/libc-lock.h 2003-01-15 12:58:35.000000000 -0500 +++ glibc-2.3.1/linuxthreads/sysdeps/pthread/bits/libc-lock.h 2003-01-15 18:24:36.000000000 -0500 @@ -71,12 +71,12 @@ initialized locks must be set to one due to the lack of normal atomic operations.) */ -#if __LT_SPINLOCK_INIT == 0 +#ifdef __LT_INITIALIZER_NOT_ZERO # define __libc_lock_define_initialized(CLASS,NAME) \ - CLASS __libc_lock_t NAME; + CLASS __libc_lock_t NAME = PTHREAD_MUTEX_INITIALIZER; #else # define __libc_lock_define_initialized(CLASS,NAME) \ - CLASS __libc_lock_t NAME = PTHREAD_MUTEX_INITIALIZER; + CLASS __libc_lock_t NAME; #endif #define __libc_rwlock_define_initialized(CLASS,NAME) \ diff -urN glibc-2.3.1.orig/linuxthreads/sysdeps/pthread/bits/pthreadtypes.h glibc-2.3.1/linuxthreads/sysdeps/pthread/bits/pthreadtypes.h --- glibc-2.3.1.orig/linuxthreads/sysdeps/pthread/bits/pthreadtypes.h 2003-01-15 12:58:35.000000000 -0500 +++ glibc-2.3.1/linuxthreads/sysdeps/pthread/bits/pthreadtypes.h 2003-01-15 18:24:36.000000000 -0500 @@ -22,12 +22,14 @@ #define __need_schedparam #include +typedef int __atomic_lock_t; + /* Fast locks (not abstract because mutexes and conditions aren't abstract). */ struct _pthread_fastlock { - long int __status; /* "Free" or "taken" or head of waiting list */ - int __spinlock; /* Used by compare_and_swap emulation. Also, - adaptive SMP lock stores spin count here. */ + long int __status; /* "Free" or "taken" or head of waiting list */ + __atomic_lock_t __spinlock; /* Used by compare_and_swap emulation. Also, + adaptive SMP lock stores spin count here. */ }; #ifndef _PTHREAD_DESCR_DEFINED diff -urN glibc-2.3.1.orig/linuxthreads/sysdeps/unix/sysv/linux/hppa/bits/initspin.h glibc-2.3.1/linuxthreads/sysdeps/unix/sysv/linux/hppa/bits/initspin.h --- glibc-2.3.1.orig/linuxthreads/sysdeps/unix/sysv/linux/hppa/bits/initspin.h 2002-08-26 18:39:55.000000000 -0400 +++ glibc-2.3.1/linuxthreads/sysdeps/unix/sysv/linux/hppa/bits/initspin.h 2003-01-15 18:24:49.000000000 -0500 @@ -17,11 +17,23 @@ write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ +/* Initialize global spinlocks without cast, generally macro wrapped */ +#define __LT_SPINLOCK_ALT_INIT { { 1, 1, 1, 1, } } + /* Initial value of a spinlock. PA-RISC only implements atomic load and clear so this must be non-zero. */ -#define __LT_SPINLOCK_INIT 1 +#define __LT_SPINLOCK_INIT ((__atomic_lock_t) __LT_SPINLOCK_ALT_INIT) + +/* Macros for lock initializers, not using the above definition. + The above definition is not used in the case that static initializers + use this value. */ +#define __LOCK_INITIALIZER { 0, __LT_SPINLOCK_ALT_INIT } +#define __ATOMIC_INITIALIZER { 0, __LT_SPINLOCK_ALT_INIT } + +/* Used to initialize _pthread_fastlock's in non-static case */ +#define __LOCK_ALT_INITIALIZER ((struct _pthread_fastlock){ 0, __LT_SPINLOCK_INIT }) + +/* Tell the rest of the code that the initializer is non-zero without + explaining it's internal structure */ +#define __LT_INITIALIZER_NOT_ZERO -/* Macros for lock initializers, using the above definition. */ -#define __LOCK_INITIALIZER { 0, __LT_SPINLOCK_INIT } -#define __ALT_LOCK_INITIALIZER { 0, __LT_SPINLOCK_INIT } -#define __ATOMIC_INITIALIZER { 0, __LT_SPINLOCK_INIT } From drepper@redhat.com Wed May 21 18:57:57 2003 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 21 May 2003 10:57:57 -0700 Subject: [parisc-linux] Re: [PATCH] HPPA Linuxthreads. In-Reply-To: <20030521172929.GB21858@systemhalted> References: <20030521172929.GB21858@systemhalted> Message-ID: <3ECBBE25.8090302@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carlos O'Donell wrote: > This is a cleaner HPPA linuxthreads implementation that stems from the > work that John David Anglin and myself did > to devise a self-aligning lock system that doesn't impose the 16-byte > lock alignment restriction. The indentation and general style is wrong in many places. > diff -urN glibc-2.3.1.orig/linuxthreads/sysdeps/hppa/pspinlock.c glibc-2.3.1/linuxthreads/sysdeps/hppa/pspinlock.c > --- glibc-2.3.1.orig/linuxthreads/sysdeps/hppa/pspinlock.c 2002-08-26 18:39:51.000000000 -0400 > +++ glibc-2.3.1/linuxthreads/sysdeps/hppa/pspinlock.c 2003-01-15 18:26:51.000000000 -0500 > @@ -24,15 +24,12 @@ > int > __pthread_spin_lock (pthread_spinlock_t *lock) > { > - unsigned int val; > + unsigned int *addr = __ldcw_align (lock); > + > + while (__ldcw (addr) == 0) > + while (*addr == 0) ; This is plain wrong. addr at least must be volatile. And I don't understand why you removed the asm code. These pieces of code are prime candidates for hand-coding. > +static inline struct _pthread_descr_struct * __get_cr27(void) > +{ > + long cr27; > + asm("mfctl %%cr27, %0" : "=r" (cr27) : ); > + return (struct _pthread_descr_struct *) cr27; > +} Not a real problem, but you should get gcc to recognize this reqister and perform the loading. - -- - --------------. ,-. 444 Castro Street Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA Red Hat `--' drepper at redhat.com `--------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+y74l2ijCOnn/RHQRAvZ1AKCkAhua5qA19EDylfBz2Zhp8dROIACfTrwO 9Slpj32aUy92PiggDNexZBE= =6Ilf -----END PGP SIGNATURE----- From grundler@parisc-linux.org Wed May 21 19:02:44 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 21 May 2003 12:02:44 -0600 Subject: [parisc-linux] gcc-3.3 configuration In-Reply-To: <20030521000854.GN31518@parcelfarce.linux.theplanet.co.uk> References: <16074.48509.259405.775905@gargle.gargle.HOWL> <20030521000854.GN31518@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030521180244.GA26818@dsl2.external.hp.com> On Wed, May 21, 2003 at 01:08:54AM +0100, Matthew Wilcox wrote: > I'm not sure it's my call to make; I can see arguments on both sides. Having no clue about dwarf vs sjlj (or whatever), I have to trust *someone* to make the right call. If it's clearly the right direction, then figure out how to get there without breaking everything and make use of your "reputation capital". grant From jsoe0708@tiscali.be Thu May 22 10:52:54 2003 From: jsoe0708@tiscali.be (Joel Soete) Date: Thu, 22 May 2003 11:52:54 +0200 Subject: [parisc-linux] glibc pthreads actual threads? In-Reply-To: <20030519163245.GN16608@parcelfarce.linux.theplanet.co.uk> Message-ID: <3EC761C200001DBB@ocpmta7.freegates.net> >On Mon, May 19, 2003 at 06:27:41PM +0200, Joel Soete wrote: >> But notice a very strange behaviour: >> _the pid is not the same for each thread_ ?? >> >> Having just a small sunos 5.8 with gcc-3.2.2 (but with native libpthread) >> the pb does not occurs? >> >> Is it a limit of glibc (in general or in 2.3 only?) for all linux or only >> hppa? > >it's a limit of your understanding ;-) POSIX specifies both behaviours >are legitimate. > Just for remind and for those who also have this kind of philophical pb :-)). In fact following test, an ardent discuss born here between high level system engineer and one of them help me to find this interesting link: Joel --------------------------------- Vous surfez avec une ligne classique ? Economisez jusqu'ā 25% avec Tiscali Complete ! Offre spéciale : premičre année d'abonnement offerte. ... Plus d'info sur http://complete.tiscali.be From carlos@baldric.uwo.ca Thu May 22 15:24:05 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Thu, 22 May 2003 10:24:05 -0400 Subject: [parisc-linux] gcc-3.3 configuration In-Reply-To: <20030521052351.GV548@tausq.org> References: <16074.48509.259405.775905@gargle.gargle.HOWL> <20030521052351.GV548@tausq.org> Message-ID: <20030522142405.GK21858@systemhalted> > Aside from the evilness of doing binNMUs of this magnitude, I doubt a > "transition" that doesn't change the SONAME will work. As soon as the > new libstdc++ is installed, every c++ app on the box will instantly > break. This means if anything happens e.g. to apt during the update, the > system will get into a very nasty state. I don't think this is worth it. > > If we need to change the SONAME, then there's no binary compatibility > anyway... > > As willy mentioned in his other email, if other distros want binary > compatibility, they should follow what Debian is doing (on hppa), since > Debian was there first :-) *Plants flag here* c. From carlos@baldric.uwo.ca Thu May 22 16:09:02 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Thu, 22 May 2003 11:09:02 -0400 Subject: [parisc-linux] Re: [PATCH] HPPA Linuxthreads. In-Reply-To: <3ECBBE25.8090302@redhat.com> References: <20030521172929.GB21858@systemhalted> <3ECBBE25.8090302@redhat.com> Message-ID: <20030522150902.GM21858@systemhalted> Ulrich, > The indentation and general style is wrong in many places. I'll clean this up today and break it into three chunks for even easier digestion. > > __pthread_spin_lock (pthread_spinlock_t *lock) > > { > > - unsigned int val; > > + unsigned int *addr = __ldcw_align (lock); > > + > > + while (__ldcw (addr) == 0) > > + while (*addr == 0) ; > > This is plain wrong. addr at least must be volatile. __ldcw is volatile. Are you suggesting that it is prehaps fragile based on gcc's choice of optimization? > And I don't understand why you removed the asm code. These pieces of > code are prime candidates for hand-coding. __ldcw is still assembly only. __ldcw_align is a macro. In truth I wanted a functioning implementation first, optimization is a close second. Though a full assembly version would fix gcc from reordering anything. > > +static inline struct _pthread_descr_struct * __get_cr27(void) > > +{ > > + long cr27; > > + asm("mfctl %%cr27, %0" : "=r" (cr27) : ); > > + return (struct _pthread_descr_struct *) cr27; > > +} > > Not a real problem, but you should get gcc to recognize this reqister > and perform the loading. This should get addressed as TLS is implemented for HPPA. I will be attending gcc-summit in hopes to discuss this with my colleagues. c. From grundler@parisc-linux.org Thu May 22 16:15:52 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Thu, 22 May 2003 09:15:52 -0600 Subject: [parisc-linux] Re: [PATCH] HPPA Linuxthreads. In-Reply-To: <20030522150902.GM21858@systemhalted> References: <20030521172929.GB21858@systemhalted> <3ECBBE25.8090302@redhat.com> <20030522150902.GM21858@systemhalted> Message-ID: <20030522151552.GB22338@dsl2.external.hp.com> On Thu, May 22, 2003 at 11:09:02AM -0400, Carlos O'Donell wrote: > > > + while (__ldcw (addr) == 0) > > > + while (*addr == 0) ; > > > > This is plain wrong. addr at least must be volatile. > > __ldcw is volatile. yes, but *addr can be optimized out of the while loop. > Are you suggesting that it is prehaps fragile based on gcc's > choice of optimization? That's another issue. OTOH, I doubt gcc will ever mangle this fairly short chunk of code. Maybe post the gcc asm output and see if anyone can improve it. grant From dave@hiauly1.hia.nrc.ca Thu May 22 16:53:44 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Thu, 22 May 2003 11:53:44 -0400 (EDT) Subject: [parisc-linux] Re: [PATCH] HPPA Linuxthreads. In-Reply-To: <20030522151552.GB22338@dsl2.external.hp.com> from "Grant Grundler" at May 22, 2003 09:15:52 am Message-ID: <200305221553.h4MFrjnW010970@hiauly1.hia.nrc.ca> > On Thu, May 22, 2003 at 11:09:02AM -0400, Carlos O'Donell wrote: > > > > + while (__ldcw (addr) == 0) > > > > + while (*addr == 0) ; > > > > > > This is plain wrong. addr at least must be volatile. > > > > __ldcw is volatile. > > yes, but *addr can be optimized out of the while loop. Yes, you are correct. This is the code from the inner loop: 1c: 0f 40 10 93 ldw 0(,r26),r19 20: 86 60 3f f5 cmpib,= 0,r19,20 <__pthread_spin_lock+0x20> 24: 08 00 02 40 nop Don't know how I missied that :( 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 Thu May 22 17:23:46 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Thu, 22 May 2003 10:23:46 -0600 Subject: [parisc-linux] Re: [PATCH] HPPA Linuxthreads. In-Reply-To: <200305221553.h4MFrjnW010970@hiauly1.hia.nrc.ca> References: <20030522151552.GB22338@dsl2.external.hp.com> <200305221553.h4MFrjnW010970@hiauly1.hia.nrc.ca> Message-ID: <20030522162346.GA24335@dsl2.external.hp.com> On Thu, May 22, 2003 at 11:53:44AM -0400, John David Anglin wrote: > Don't know how I missied that :( If you have a test for this, it's not contending for the lock. Writing a test for this would probably be a good thing if there isn't already one. Note there is no fairness and a test would need to be sensitive to that. grant From dave@hiauly1.hia.nrc.ca Thu May 22 18:04:33 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Thu, 22 May 2003 13:04:33 -0400 (EDT) Subject: [parisc-linux] Re: [PATCH] HPPA Linuxthreads. In-Reply-To: <20030522162346.GA24335@dsl2.external.hp.com> from "Grant Grundler" at May 22, 2003 10:23:46 am Message-ID: <200305221704.h4MH4Xgs011472@hiauly1.hia.nrc.ca> > If you have a test for this, it's not contending for the lock. > Writing a test for this would probably be a good thing if > there isn't already one. Note there is no fairness and a > test would need to be sensitive to that. Agreed. The libc suite would probably be the best place for such a test ;-) Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From erd0s@afterconnect.com Fri May 23 09:45:38 2003 From: erd0s@afterconnect.com (Dave Sasselli) Date: Fri, 23 May 2003 10:45:38 +0200 Subject: [parisc-linux] HP A7789 Fire GL-UX Message-ID: <200305231045.38506.erd0s@afterconnect.com> Hi ,=20 about install Debian-hppa on HP C3750 Pa-risc . http://www.hp.com/workstations/risc/c3750/faq.html =46rom the documentation I see that the arch is supported ( C class ) . http://www.parisc-linux.org/release-0.9/systems-093.html Someone has tried to make to work the HP A7789 Fire GL-UX=20 video card on board .=20 Thank's in advance . =2D-Dave_S From grundler@parisc-linux.org Fri May 23 17:43:22 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 23 May 2003 10:43:22 -0600 Subject: [parisc-linux] HP A7789 Fire GL-UX In-Reply-To: <200305231045.38506.erd0s@afterconnect.com> References: <200305231045.38506.erd0s@afterconnect.com> Message-ID: <20030523164322.GA23563@dsl2.external.hp.com> On Fri, May 23, 2003 at 10:45:38AM +0200, Dave Sasselli wrote: > Hi , > about install Debian-hppa on HP C3750 Pa-risc . > > http://www.hp.com/workstations/risc/c3750/faq.html > > From the documentation I see that the arch is supported ( C class ) . > > http://www.parisc-linux.org/release-0.9/systems-093.html This web page is obsolete. We've kept the web pages around just for reference. > Someone has tried to make to work the HP A7789 Fire GL-UX > video card on board . Are you asking if someone has been able to make this work? I think the answer is no. Lack of HW documentation is a problem for all the FX* cards. grant From killboy@cyberspace.org Fri May 23 18:32:32 2003 From: killboy@cyberspace.org (killboy@cyberspace.org) Date: Fri, 23 May 2003 13:32:32 -0400 (EDT) Subject: [parisc-linux] E35. Message-ID: Is the only way i can view the console via a MUX/RS232 adapter, or is there another way? Ben "BASIC programmers never die, they GOSUB and dont't RETURN." From willy@debian.org Fri May 23 18:39:19 2003 From: willy@debian.org (Matthew Wilcox) Date: Fri, 23 May 2003 18:39:19 +0100 Subject: [parisc-linux] HP A7789 Fire GL-UX In-Reply-To: <20030523164322.GA23563@dsl2.external.hp.com> References: <200305231045.38506.erd0s@afterconnect.com> <20030523164322.GA23563@dsl2.external.hp.com> Message-ID: <20030523173919.GB12621@parcelfarce.linux.theplanet.co.uk> On Fri, May 23, 2003 at 10:43:22AM -0600, Grant Grundler wrote: > > Someone has tried to make to work the HP A7789 Fire GL-UX > > video card on board . > > Are you asking if someone has been able to make this work? > I think the answer is no. > Lack of HW documentation is a problem for all the FX* cards. Surely the FireGL card isn't an FX* card but a Radeon? If so, maybe ATI have released some docs on it ... Anyone 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 sieler@allegro.com Fri May 23 18:55:50 2003 From: sieler@allegro.com (Stan Sieler) Date: Fri, 23 May 2003 10:55:50 -0700 (PDT) Subject: [parisc-linux] E35. In-Reply-To: from "killboy@cyberspace.org" at May 23, 2003 01:32:32 PM Message-ID: <200305231755.h4NHtok11927@opus.allegro.com> Re: > Is the only way i can view the console via a MUX/RS232 adapter, or is > there another way? AFAIK, that's the only way. -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From mkp@mkp.net Fri May 23 19:07:40 2003 From: mkp@mkp.net (Martin K. Petersen) Date: 23 May 2003 14:07:40 -0400 Subject: [parisc-linux] HP A7789 Fire GL-UX In-Reply-To: <20030523173919.GB12621@parcelfarce.linux.theplanet.co.uk> References: <200305231045.38506.erd0s@afterconnect.com> <20030523164322.GA23563@dsl2.external.hp.com> <20030523173919.GB12621@parcelfarce.linux.theplanet.co.uk> Message-ID: >>>>> "Matthew" == Matthew Wilcox writes: Matthew> On Fri, May 23, 2003 at 10:43:22AM -0600, Grant Grundler wrote: >> > Someone has tried to make to work the HP A7789 Fire GL-UX > video >> card on board . >> >> Are you asking if someone has been able to make this work? I think >> the answer is no. Lack of HW documentation is a problem for all >> the FX* cards. Matthew> Surely the FireGL card isn't an FX* card but a Radeon? If Matthew> so, maybe ATI have released some docs on it ... Anyone know? FireGL is ATI's high-end chip offering. The drivers are binary only. -- Martin K. Petersen http://mkp.net/ From erd0s@afterconnect.com Fri May 23 20:39:13 2003 From: erd0s@afterconnect.com (Dave Sasselli) Date: Fri, 23 May 2003 21:39:13 +0200 Subject: [parisc-linux] HP A7789 Fire GL-UX Message-ID: <200305232139.13024.erd0s@afterconnect.com> > On Fri, May 23, 2003 at 10:43:22AM -0600, Grant Grundler wrote: > > > Someone has tried to make to work the HP A7789 Fire GL-UX > > > video card on board . > > > > Are you asking if someone has been able to make this work? > > I think the answer is no. > > Lack of HW documentation is a problem for all the FX* cards. > > Surely the FireGL card isn't an FX* card but a Radeon? If so, maybe > ATI have released some docs on it ... Anyone know? Ati supports only binary driver for intel. I could use the driver of xfree86 for radeon otherwise the only way is the frame buffer . --Dave_S From &@dsl2.external.hp.com Sun May 25 01:31:32 2003 From: &@dsl2.external.hp.com (&) Date: Sun, 25 May 2003 08:31:32 +0800 Subject: [parisc-linux] Provide Mobile Phone Battery And Other Battery Message-ID: <20030525003012.1EE4D482F@dsl2.external.hp.com> This is a multi-part message in MIME format --7a839214-e777-475f-bd29-d73f423d9cd8 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Dear Sir or Madam: This information is come from China . Shenzhen Stone Electronics Co.,Ltd., headed by a team of battery experts and = experienced senior electronics designers,is a professional manufacturer for = portable power.Suported by high advanced production facilities and testing = equipments,we produce rechargeable Li-lon. Ni-MH, alkalescent batteries and = battery packs appied for cellular phones,cordless phones,radio,mp3,digital = camera,portable PDA,VCD/DVD player,notebook,emergency lighting, power = tool,R/C toys and other state-of-the-art devices,As a total solution provider = for portable power,we design and produce kinds of chargers and power = management circuits according to customer's requirements. Factory area:3,000m2 Skilled worders: 200 Senior R&D staff: 6 Engineering Staff: 5 Annual Qutput: 30 million Pcs Quality system: ISO9002 "Same quality level,We have more comperitive price;same price,we have higher = quality level" is one of the important reasons than our customers cooperate = with us .Choose a partner,not only a supplier! YOUR ANY ENQUIRY ARE WELCOME ! Contact person : Mr.Wei E-MAIL : yuqingqing@vip.sina.com ; Shenzhen Stone Electronics Co., Ltd. Industrial Rd.(w) , Longhua , Shenzhen , Guangdong , China TEL: 86-755-28116152 (DIRECT LINE ) FAX: 86-755-28116153 ---------------------------------------------------- DEMO=B0=E6=B1=BE=B7=A2=CB=CD ---------------------------------------------------- --7a839214-e777-475f-bd29-d73f423d9cd8-- From joel.soete@tiscali.be Sun May 25 12:30:30 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Sun, 25 May 2003 11:30:30 +0000 Subject: [parisc-linux] HP A7789 Fire GL-UX In-Reply-To: <200305232139.13024.erd0s@afterconnect.com> References: <200305232139.13024.erd0s@afterconnect.com> Message-ID: <3ED0A956.7010803@tiscali.be> Dave Sasselli wrote: >>On Fri, May 23, 2003 at 10:43:22AM -0600, Grant Grundler wrote: >> >> >>>>Someone has tried to make to work the HP A7789 Fire GL-UX >>>>video card on board . >>>> >>>> >>>Are you asking if someone has been able to make this work? >>>I think the answer is no. >>>Lack of HW documentation is a problem for all the FX* cards. >>> >>> >>Surely the FireGL card isn't an FX* card but a Radeon? If so, maybe >>ATI have released some docs on it ... Anyone know? >> >> > >Ati supports only binary driver for intel. > AFAIK ati would be supported in 2.4.21? So : I wouldn't have more chance to make work this Ati Rage model? >I could use the driver of xfree86 for radeon otherwise the only way is the >frame buffer . > > > Thanks, Joel From baddy@free.fr Sun May 25 11:28:14 2003 From: baddy@free.fr (baddy@free.fr) Date: Sun, 25 May 2003 12:28:14 +0200 Subject: [parisc-linux] Promise IDE PCI card Message-ID: Hi, Who knows if the Promise Ultra 100 TX2 PCI card works under PA-Risc Linux ? I own a B132L+ and I am interested in adding IDE drive for storage (because IDE is cheaper than SCSI for mass storage). Thanks ------- Bad Max ======== Amiga User GNU User WWW: perso.club-internet.fr/badmax From sid@mindless.co.uk Sun May 25 22:18:50 2003 From: sid@mindless.co.uk (Siraj 'Sid' Rakhada) Date: Sun, 25 May 2003 22:18:50 +0100 (BST) Subject: [parisc-linux] RAID Boot Howto question... Message-ID: <35262.194.131.108.2.1053897530.squirrel@ssl.mindless.co.uk> Hi, I'm installing Debian 3.0r1 on a K370 (via a testing netinst CD due to issues with PDC or something - I'm not too hot on this stuff yet!). It's currently sitting on the 'partition a hard disk prompt' while I read up some more on the RAID stuff... Which leads me to a question about the RAID howto which is listed on the FAQ. Basically the author (Martin Petersen) writes at the end of step 7 that he made a modification to PALO to allow it to boot from RAID partitions... The HOWTO is dated 14th Jan 2003... Anyway, I was looking to find information on PALO now, to see if this change has been incorporated onto a released version - and I think it has - due to this: http://packages.qa.debian.org/p/palo/news/1.html - also dated 14th Jan 2003. Would it be a good idea to list in the RAID boot HOWTO that 'version 1.2 of PALO incorporates the change, and is available in debian/unstable' ? Best regards, Sid From Andries.Brouwer@cwi.nl Mon May 26 23:20:50 2003 From: Andries.Brouwer@cwi.nl (Andries.Brouwer@cwi.nl) Date: Tue, 27 May 2003 00:20:50 +0200 (MEST) Subject: [parisc-linux] [patch] kill lvm from parisc Message-ID: CONFIG_BLK_DEV_LVM is gone, but there is still some associated code. This is the parisc part. diff -u --recursive --new-file -X /linux/dontdiff a/arch/parisc/kernel/ioctl32.c b/arch/parisc/kernel/ioctl32.c --- a/arch/parisc/kernel/ioctl32.c Tue May 27 00:31:01 2003 +++ b/arch/parisc/kernel/ioctl32.c Tue May 27 01:04:17 2003 @@ -1785,443 +1785,6 @@ return -EINVAL; } -#if defined(CONFIG_BLK_DEV_LVM) || defined(CONFIG_BLK_DEV_LVM_MODULE) -/* Ugh, LVM. Pitty it was not cleaned up before accepted :((. */ -typedef struct { - uint8_t vg_name[NAME_LEN]; - uint32_t vg_number; - uint32_t vg_access; - uint32_t vg_status; - uint32_t lv_max; - uint32_t lv_cur; - uint32_t lv_open; - uint32_t pv_max; - uint32_t pv_cur; - uint32_t pv_act; - uint32_t dummy; - uint32_t vgda; - uint32_t pe_size; - uint32_t pe_total; - uint32_t pe_allocated; - uint32_t pvg_total; - u32 proc; - u32 pv[ABS_MAX_PV + 1]; - u32 lv[ABS_MAX_LV + 1]; - uint8_t vg_uuid[UUID_LEN+1]; /* volume group UUID */ - uint8_t dummy1[200]; -} vg32_t; - -typedef struct { - uint8_t id[2]; - uint16_t version; - lvm_disk_data_t pv_on_disk; - lvm_disk_data_t vg_on_disk; - lvm_disk_data_t pv_namelist_on_disk; - lvm_disk_data_t lv_on_disk; - lvm_disk_data_t pe_on_disk; - uint8_t pv_name[NAME_LEN]; - uint8_t vg_name[NAME_LEN]; - uint8_t system_id[NAME_LEN]; - kdev_t pv_dev; - uint32_t pv_number; - uint32_t pv_status; - uint32_t pv_allocatable; - uint32_t pv_size; - uint32_t lv_cur; - uint32_t pe_size; - uint32_t pe_total; - uint32_t pe_allocated; - uint32_t pe_stale; - u32 pe; - u32 inode; - uint8_t pv_uuid[UUID_LEN+1]; -} pv32_t; - -typedef struct { - char lv_name[NAME_LEN]; - u32 lv; -} lv_req32_t; - -typedef struct { - u32 lv_index; - u32 lv; - /* Transfer size because user space and kernel space differ */ - uint16_t size; -} lv_status_byindex_req32_t; - -typedef struct { - compat_dev_t dev; - u32 lv; -} lv_status_bydev_req32_t; - -typedef struct { - uint8_t lv_name[NAME_LEN]; - kdev_t old_dev; - kdev_t new_dev; - u32 old_pe; - u32 new_pe; -} le_remap_req32_t; - -typedef struct { - char pv_name[NAME_LEN]; - u32 pv; -} pv_status_req32_t; - -typedef struct { - uint8_t lv_name[NAME_LEN]; - uint8_t vg_name[NAME_LEN]; - uint32_t lv_access; - uint32_t lv_status; - uint32_t lv_open; - kdev_t lv_dev; - uint32_t lv_number; - uint32_t lv_mirror_copies; - uint32_t lv_recovery; - uint32_t lv_schedule; - uint32_t lv_size; - u32 lv_current_pe; - uint32_t lv_current_le; - uint32_t lv_allocated_le; - uint32_t lv_stripes; - uint32_t lv_stripesize; - uint32_t lv_badblock; - uint32_t lv_allocation; - uint32_t lv_io_timeout; - uint32_t lv_read_ahead; - /* delta to version 1 starts here */ - u32 lv_snapshot_org; - u32 lv_snapshot_prev; - u32 lv_snapshot_next; - u32 lv_block_exception; - uint32_t lv_remap_ptr; - uint32_t lv_remap_end; - uint32_t lv_chunk_size; - uint32_t lv_snapshot_minor; - char dummy[200]; -} lv32_t; - -typedef struct { - u32 hash[2]; - u32 rsector_org; - kdev_t rdev_org; - u32 rsector_new; - kdev_t rdev_new; -} lv_block_exception32_t; - -static void put_lv_t(lv_t *l) -{ - if (l->lv_current_pe) vfree(l->lv_current_pe); - if (l->lv_block_exception) vfree(l->lv_block_exception); - kfree(l); -} - -static lv_t *get_lv_t(u32 p, int *errp) -{ - int err, i; - u32 ptr1, ptr2; - size_t size; - lv_block_exception32_t *lbe32; - lv_block_exception_t *lbe; - lv32_t *ul = (lv32_t *)A(p); - lv_t *l = (lv_t *) kmalloc(sizeof(lv_t), GFP_KERNEL); - - if (!l) { - *errp = -ENOMEM; - return NULL; - } - memset(l, 0, sizeof(lv_t)); - err = copy_from_user(l, ul, (long)&((lv32_t *)0)->lv_current_pe); - err |= __copy_from_user(&l->lv_current_le, &ul->lv_current_le, - ((long)&ul->lv_snapshot_org) - ((long)&ul->lv_current_le)); - err |= __copy_from_user(&l->lv_remap_ptr, &ul->lv_remap_ptr, - ((long)&ul->dummy[0]) - ((long)&ul->lv_remap_ptr)); - err |= __get_user(ptr1, &ul->lv_current_pe); - err |= __get_user(ptr2, &ul->lv_block_exception); - if (err) { - kfree(l); - *errp = -EFAULT; - return NULL; - } - if (ptr1) { - size = l->lv_allocated_le * sizeof(pe_t); - l->lv_current_pe = vmalloc(size); - if (l->lv_current_pe) - err = copy_from_user(l->lv_current_pe, (void *)A(ptr1), size); - } - if (!err && ptr2) { - size = l->lv_remap_end * sizeof(lv_block_exception_t); - l->lv_block_exception = lbe = vmalloc(size); - if (l->lv_block_exception) { - lbe32 = (lv_block_exception32_t *)A(ptr2); - memset(lbe, 0, size); - for (i = 0; i < l->lv_remap_end; i++, lbe++, lbe32++) { - err |= get_user(lbe->rsector_org, &lbe32->rsector_org); - err |= __get_user(lbe->rdev_org, &lbe32->rdev_org); - err |= __get_user(lbe->rsector_new, &lbe32->rsector_new); - err |= __get_user(lbe->rdev_new, &lbe32->rdev_new); - } - } - } - if (err || (ptr1 && !l->lv_current_pe) || (ptr2 && !l->lv_block_exception)) { - if (!err) - *errp = -ENOMEM; - else - *errp = -EFAULT; - put_lv_t(l); - return NULL; - } - return l; -} - -static int copy_lv_t(u32 ptr, lv_t *l) -{ - int err; - lv32_t *ul = (lv32_t *)A(ptr); - u32 ptr1; - size_t size; - - err = get_user(ptr1, &ul->lv_current_pe); - if (err) - return -EFAULT; - err = copy_to_user(ul, l, (long)&((lv32_t *)0)->lv_current_pe); - err |= __copy_to_user(&ul->lv_current_le, &l->lv_current_le, - ((long)&ul->lv_snapshot_org) - ((long)&ul->lv_current_le)); - err |= __copy_to_user(&ul->lv_remap_ptr, &l->lv_remap_ptr, - ((long)&ul->dummy[0]) - ((long)&ul->lv_remap_ptr)); - size = l->lv_allocated_le * sizeof(pe_t); - if (ptr1) - err |= __copy_to_user((void *)A(ptr1), l->lv_current_pe, size); - return err ? -EFAULT : 0; -} - -static int do_lvm_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg) -{ - vg_t *v = NULL; - union { - lv_req_t lv_req; - le_remap_req_t le_remap; - lv_status_byindex_req_t lv_byindex; - lv_status_bydev_req_t lv_bydev; - pv_status_req_t pv_status; - } u; - pv_t p; - int err; - u32 ptr = 0; - int i; - mm_segment_t old_fs; - void *karg = &u; - - switch (cmd) { - case VG_STATUS: - v = kmalloc(sizeof(vg_t), GFP_KERNEL); - if (!v) - return -ENOMEM; - karg = v; - break; - - case VG_CREATE_OLD: - case VG_CREATE: - v = kmalloc(sizeof(vg_t), GFP_KERNEL); - if (!v) - return -ENOMEM; - if (copy_from_user(v, (void *)arg, (long)&((vg32_t *)0)->proc)) { - kfree(v); - return -EFAULT; - } - /* 'proc' field is unused, just NULL it out. */ - v->proc = NULL; - if (copy_from_user(v->vg_uuid, ((vg32_t *)arg)->vg_uuid, UUID_LEN+1)) { - kfree(v); - return -EFAULT; - } - - karg = v; - memset(v->pv, 0, sizeof(v->pv) + sizeof(v->lv)); - if (v->pv_max > ABS_MAX_PV || v->lv_max > ABS_MAX_LV) - return -EPERM; - for (i = 0; i < v->pv_max; i++) { - err = __get_user(ptr, &((vg32_t *)arg)->pv[i]); - if (err) - break; - if (ptr) { - v->pv[i] = kmalloc(sizeof(pv_t), GFP_KERNEL); - if (!v->pv[i]) { - err = -ENOMEM; - break; - } - err = copy_from_user(v->pv[i], (void *)A(ptr), - sizeof(pv32_t) - 8 - UUID_LEN+1); - if (err) { - err = -EFAULT; - break; - } - err = copy_from_user(v->pv[i]->pv_uuid, - ((pv32_t *)A(ptr))->pv_uuid, - UUID_LEN+1); - if (err) { - err = -EFAULT; - break; - } - - v->pv[i]->pe = NULL; - v->pv[i]->bd = NULL; - } - } - if (!err) { - for (i = 0; i < v->lv_max; i++) { - err = __get_user(ptr, &((vg32_t *)arg)->lv[i]); - if (err) - break; - if (ptr) { - v->lv[i] = get_lv_t(ptr, &err); - if (err) - break; - } - } - } - break; - - case LV_CREATE: - case LV_EXTEND: - case LV_REDUCE: - case LV_REMOVE: - case LV_RENAME: - case LV_STATUS_BYNAME: - err = copy_from_user(&u.pv_status, arg, sizeof(u.pv_status.pv_name)); - if (err) - return -EFAULT; - if (cmd != LV_REMOVE) { - err = __get_user(ptr, &((lv_req32_t *)arg)->lv); - if (err) - return err; - u.lv_req.lv = get_lv_t(ptr, &err); - } else - u.lv_req.lv = NULL; - break; - - case LV_STATUS_BYINDEX: - err = get_user(u.lv_byindex.lv_index, - &((lv_status_byindex_req32_t *)arg)->lv_index); - err |= __get_user(ptr, &((lv_status_byindex_req32_t *)arg)->lv); - if (err) - return err; - u.lv_byindex.lv = get_lv_t(ptr, &err); - break; - - case LV_STATUS_BYDEV: - err = get_user(u.lv_bydev.dev, &((lv_status_bydev_req32_t *)arg)->dev); - err |= __get_user(ptr, &((lv_status_bydev_req32_t *)arg)->lv); - if (err) - return err; - u.lv_bydev.lv = get_lv_t(ptr, &err); - break; - - case VG_EXTEND: - err = copy_from_user(&p, (void *)arg, sizeof(pv32_t) - 8 - UUID_LEN+1); - if (err) - return -EFAULT; - err = copy_from_user(p.pv_uuid, ((pv32_t *)arg)->pv_uuid, UUID_LEN+1); - if (err) - return -EFAULT; - p.pe = NULL; - p.bd = NULL; - karg = &p; - break; - - case PV_CHANGE: - case PV_STATUS: - err = copy_from_user(&u.pv_status, arg, sizeof(u.lv_req.lv_name)); - if (err) - return -EFAULT; - err = __get_user(ptr, &((pv_status_req32_t *)arg)->pv); - if (err) - return err; - u.pv_status.pv = &p; - if (cmd == PV_CHANGE) { - err = copy_from_user(&p, (void *)A(ptr), - sizeof(pv32_t) - 8 - UUID_LEN+1); - if (err) - return -EFAULT; - p.pe = NULL; - p.bd = NULL; - } - break; - }; - - old_fs = get_fs(); set_fs (KERNEL_DS); - err = sys_ioctl (fd, cmd, (unsigned long)karg); - set_fs (old_fs); - - switch (cmd) { - case VG_STATUS: - if (!err) { - if (copy_to_user((void *)arg, v, (long)&((vg32_t *)0)->proc) || - clear_user(&((vg32_t *)arg)->proc, sizeof(vg32_t) - (long)&((vg32_t *)0)->proc)) - err = -EFAULT; - } - if (copy_to_user(((vg32_t *)arg)->vg_uuid, v->vg_uuid, UUID_LEN+1)) { - err = -EFAULT; - } - kfree(v); - break; - - case VG_CREATE_OLD: - case VG_CREATE: - for (i = 0; i < v->pv_max; i++) { - if (v->pv[i]) - kfree(v->pv[i]); - } - for (i = 0; i < v->lv_max; i++) { - if (v->lv[i]) - put_lv_t(v->lv[i]); - } - kfree(v); - break; - - case LV_STATUS_BYNAME: - if (!err && u.lv_req.lv) - err = copy_lv_t(ptr, u.lv_req.lv); - /* Fall through */ - - case LV_CREATE: - case LV_EXTEND: - case LV_REDUCE: - if (u.lv_req.lv) - put_lv_t(u.lv_req.lv); - break; - - case LV_STATUS_BYINDEX: - if (u.lv_byindex.lv) { - if (!err) - err = copy_lv_t(ptr, u.lv_byindex.lv); - put_lv_t(u.lv_byindex.lv); - } - break; - - case LV_STATUS_BYDEV: - if (u.lv_bydev.lv) { - if (!err) - err = copy_lv_t(ptr, u.lv_bydev.lv); - put_lv_t(u.lv_byindex.lv); - } - break; - - case PV_STATUS: - if (!err) { - err = copy_to_user((void *)A(ptr), &p, sizeof(pv32_t) - 8 - UUID_LEN+1); - if (err) - return -EFAULT; - err = copy_to_user(((pv_t *)A(ptr))->pv_uuid, p.pv_uuid, UUID_LEN + 1); - if (err) - return -EFAULT; - } - break; - }; - - return err; -} -#endif - #ifdef CONFIG_GENRTC #endif @@ -3040,22 +2603,6 @@ HANDLE_IOCTL(SONET_SETFRAMING, do_atm_ioctl) HANDLE_IOCTL(SONET_GETFRAMING, do_atm_ioctl) HANDLE_IOCTL(SONET_GETFRSENSE, do_atm_ioctl) -#if defined(CONFIG_BLK_DEV_LVM) || defined(CONFIG_BLK_DEV_LVM_MODULE) -HANDLE_IOCTL(VG_STATUS, do_lvm_ioctl) -HANDLE_IOCTL(VG_CREATE_OLD, do_lvm_ioctl) -HANDLE_IOCTL(VG_CREATE, do_lvm_ioctl) -HANDLE_IOCTL(VG_EXTEND, do_lvm_ioctl) -HANDLE_IOCTL(LV_CREATE, do_lvm_ioctl) -HANDLE_IOCTL(LV_REMOVE, do_lvm_ioctl) -HANDLE_IOCTL(LV_EXTEND, do_lvm_ioctl) -HANDLE_IOCTL(LV_REDUCE, do_lvm_ioctl) -HANDLE_IOCTL(LV_RENAME, do_lvm_ioctl) -HANDLE_IOCTL(LV_STATUS_BYNAME, do_lvm_ioctl) -HANDLE_IOCTL(LV_STATUS_BYINDEX, do_lvm_ioctl) -HANDLE_IOCTL(LV_STATUS_BYDEV, do_lvm_ioctl) -HANDLE_IOCTL(PV_CHANGE, do_lvm_ioctl) -HANDLE_IOCTL(PV_STATUS, do_lvm_ioctl) -#endif /* LVM */ #if defined(CONFIG_GEN_RTC) COMPATIBLE_IOCTL(RTC_AIE_ON) COMPATIBLE_IOCTL(RTC_AIE_OFF) From Randolph Chung Tue May 27 06:22:51 2003 From: Randolph Chung (Randolph Chung) Date: Mon, 26 May 2003 22:22:51 -0700 Subject: [parisc-linux] [hppa] binutils will not build shared libraries with external deps? Message-ID: <20030527052251.GC24873@tausq.org> Looks like latest binutils CVS (also as of 2.14.90.0.1) cannot build shared libraries that have external symbols on at least hppa-linux: tausq@ios:~$ cat blah.c extern int foo(); int call_foo() { return foo(); } tausq@ios:~$ gcc -shared -fPIC -o blah.so blah.c /tmp/ccC3fZeH.o(.text+0x1c): In function `call_foo': : undefined reference to `foo' this worked fine on older binutils (e.g. 2.13.90.0.16 worked). does anyone know what might be broken? this is causing a lot of failures in the binutils test suite.... thanks, randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From willy@debian.org Tue May 27 12:11:53 2003 From: willy@debian.org (Matthew Wilcox) Date: Tue, 27 May 2003 12:11:53 +0100 Subject: [parisc-linux] Re: [patch] kill lvm from parisc In-Reply-To: References: Message-ID: <20030527111153.GD15709@parcelfarce.linux.theplanet.co.uk> On Tue, May 27, 2003 at 12:20:50AM +0200, Andries.Brouwer@cwi.nl wrote: > CONFIG_BLK_DEV_LVM is gone, but there is still some associated code. > This is the parisc part. it's already gone from the parisc tree and will be picked up whenever linus gets round to releasing 2.5.70 and we submit a patch. please stop resending. -- "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 May 27 18:14:18 2003 From: willy@debian.org (Matthew Wilcox) Date: Tue, 27 May 2003 18:14:18 +0100 Subject: [parisc-linux] CVS accounts Message-ID: <20030527171418.GH15709@parcelfarce.linux.theplanet.co.uk> We need to move CVS to a faster box. So this is a good time to reevaluate who has CVS access. Going back through the past 6 months, the following people have committed code to p-l.org and will thus get accounts on the new cvs.p-l.org. If your name isn't on this list and you'd like it to be, send mail. bame bdale carlos deller grundler jejb lamont mkp rbrad tausq varenet willy 6 months is an entirely random time period so don't be offended if your name isn't on the list; just send mail so I know to create this account. Of course we can always add accounts later, but if you're using non-anonymous CVS access and your name isn't on the list, it'll stop working. -- "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 dannf@dannf.org Wed May 28 07:42:50 2003 From: dannf@dannf.org (dann frazier) Date: Wed, 28 May 2003 00:42:50 -0600 Subject: [parisc-linux] cvs migration Message-ID: <20030528064250.GA29360@dannf.org> cvs has moved to our new box (finally! hosted on a parisc-linux box!) if you've been using the recommended cvs.parisc-linux.org name, the transition should have been transparent, in most regards. - anonymous access should be transparent. - ssh users that weren't part of willy's list of recent committers will need to request their account be reactivated. - ssh users will see that the host key has changed. - you may get errors until dns propogation has completed - non-cvs accounts from dsl2 have not migrated to palinux, nor have home directories. home directories should be migrated by hand. - bame: your cronjobs that access cvs will likely break - sorry for the lack of warning. please let me know if you notice other breakages (i'm not on this list). -- dannf@dannf.org From mariamabba22@indiatimes.com Wed May 28 23:38:25 2003 From: mariamabba22@indiatimes.com (Hajia Mariam Abacha) Date: Wed, 28 May 2003 15:38:25 -0700 Subject: [parisc-linux] Good Day Message-ID: <20030528144502.804EB4829@dsl2.external.hp.com> This is a multi-part message in MIME format --d9518f36-9120-11d7-9a22-0008c7082063 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear Sir/Madam This letter maybe like a supprise to you but treat this with utmost care that = you will understand my plige, Following the sudden death of my husband = General Sani Abacha the former head of state of Nigeria in August 1998, I = Have been thrown into a state of utter confusion, frustration and = hopelessness by the present civilian administration, I have been subjected to = physical and psychological torture by the security agents in the country. As a widow that is so traumatized, I have lost confidence with anybody within = the country. You must have heard over the media reports and the internet on = the recovery of various huge sums of money deposited by my husband in = different security firms abroad, some companies willingly give up their = secrets and disclosed our money confidently lodged there or many outright = blackmail. In fact the total sum discovered by the Government so far is in the tune of = $700M. Million dollars. And they are not relenting to make me poor for life. = I got your contacts through my personal research,and out of desperation = decided to reach you through this medium.I will give you more information as = to this regard as soon as you reply. I repose great confidence in you hence = my approach to you due to security network placed on my day to day affairs I = cannot afford to visit the embassy so that is why I decided to contact you = and I hope you will not betray my confidence in you. I have deposited the sum of 18.5 million dollars with a security firm abroad = whose name is witheld for now until we open communication. I shall be = grateful if you could receive this fund into your account for safe keeping. This arrangement is known to you and my son Mustapha alone, so my son will = deal directly with you as security is up my whole being. I am seriously considering to settle down abroad in a friendly atmosphere = like yours as soon as this fund get into your account so that I can start all = over again if only you wish, but if it is impossible,just help me in = diverting this fund into your account which will accrue you 20% of this fund = From amodra@bigpond.net.au Wed May 28 20:07:06 2003 From: amodra@bigpond.net.au (amodra@bigpond.net.au) Date: Thu, 29 May 2003 04:37:06 +0930 Subject: [parisc-linux] Re: [hppa] binutils will not build shared libraries with external deps? In-Reply-To: <20030527052251.GC24873@tausq.org> References: <20030527052251.GC24873@tausq.org> Message-ID: <20030528190706.GC21904@bubble.sa.bigpond.net.au> On Mon, May 26, 2003 at 10:22:51PM -0700, Randolph Chung wrote: > tausq@ios:~$ gcc -shared -fPIC -o blah.so blah.c > /tmp/ccC3fZeH.o(.text+0x1c): In function `call_foo': > : undefined reference to `foo' This should fix it. Would someone mind applying it for me? I'm in transit at the moment and internet access is slow and flaky. 2.14 branch too, I guess. * elf32-hppa.c (elf32_hppa_relocate_section): Delete bogus undefined_symbol call. --- bfd/elf32-hppa.c~ 2003-05-08 12:08:31.000000000 +0930 +++ bfd/elf32-hppa.c 2003-05-28 10:44:19.000000000 +0930 @@ -3666,16 +3666,11 @@ elf32_hppa_relocate_section (output_bfd, } else if (h->elf.root.type == bfd_link_hash_undefweak) ; - else if (info->shared && !info->no_undefined + else if (info->shared + && !info->no_undefined && ELF_ST_VISIBILITY (h->elf.other) == STV_DEFAULT && h->elf.type != STT_PARISC_MILLI) - { - if (!((*info->callbacks->undefined_symbol) - (info, h->elf.root.root.string, input_bfd, - input_section, rel->r_offset, FALSE))) - return FALSE; - warned_undef = TRUE; - } + ; else { if (!((*info->callbacks->undefined_symbol) -- Alan Modra IBM OzLabs - Linux Technology Centre From hjl@lucon.org Wed May 28 21:27:57 2003 From: hjl@lucon.org (H. J. Lu) Date: Wed, 28 May 2003 13:27:57 -0700 Subject: [parisc-linux] Re: [hppa] binutils will not build shared libraries with external deps? In-Reply-To: <20030528190706.GC21904@bubble.sa.bigpond.net.au>; from amodra@bigpond.net.au on Thu, May 29, 2003 at 04:37:06AM +0930 References: <20030527052251.GC24873@tausq.org> <20030528190706.GC21904@bubble.sa.bigpond.net.au> Message-ID: <20030528132757.A14921@lucon.org> On Thu, May 29, 2003 at 04:37:06AM +0930, amodra@bigpond.net.au wrote: > On Mon, May 26, 2003 at 10:22:51PM -0700, Randolph Chung wrote: > > tausq@ios:~$ gcc -shared -fPIC -o blah.so blah.c > > /tmp/ccC3fZeH.o(.text+0x1c): In function `call_foo': > > : undefined reference to `foo' > > This should fix it. Would someone mind applying it for me? I'm in > transit at the moment and internet access is slow and flaky. 2.14 > branch too, I guess. Applied to mainline. H.J. From dannf@dannf.org Wed May 28 15:56:17 2003 From: dannf@dannf.org (dann frazier) Date: Wed, 28 May 2003 08:56:17 -0600 Subject: [parisc-linux] cvs migration In-Reply-To: <3ED467BB.90204@bluehash.de> References: <20030528064250.GA29360@dannf.org> <3ED467BB.90204@bluehash.de> Message-ID: <20030528145617.GA10081@dannf.org> On Wed, May 28, 2003 at 09:39:39AM +0200, Rüdiger Scholz wrote: > Hello, > > I just tried to do a "cvs update", but I get an error during anonymous > login: > > ruediger@gandalf:/usr/src$ cvs login > Logging in to :pserver:anonymous@cvs.parisc-linux.org:2401/var/cvs > CVS password: [empty] > cvs login: authorization failed: server cvs.parisc-linux.org rejected > access to /var/cvs for user anonymous > ruediger@gandalf:/usr/src$ > > DNS-Entry of cvs.parisc-linux.org for me is: 192.25.206.7. that is out of date - the correct ip is now .14 -- dannf@dannf.org From doko@cs.tu-berlin.de Thu May 29 17:10:33 2003 From: doko@cs.tu-berlin.de (Matthias Klose) Date: Thu, 29 May 2003 18:10:33 +0200 Subject: [parisc-linux] Re: [hppa] binutils will not build shared libraries with external deps? In-Reply-To: <20030528132757.A14921@lucon.org> References: <20030527052251.GC24873@tausq.org> <20030528190706.GC21904@bubble.sa.bigpond.net.au> <20030528132757.A14921@lucon.org> Message-ID: <16086.12537.788243.943349@gargle.gargle.HOWL> H. J. Lu writes: > On Thu, May 29, 2003 at 04:37:06AM +0930, amodra@bigpond.net.au wrote: > > On Mon, May 26, 2003 at 10:22:51PM -0700, Randolph Chung wrote: > > > tausq@ios:~$ gcc -shared -fPIC -o blah.so blah.c > > > /tmp/ccC3fZeH.o(.text+0x1c): In function `call_foo': > > > : undefined reference to `foo' > > > > This should fix it. Would someone mind applying it for me? I'm in > > transit at the moment and internet access is slow and flaky. 2.14 > > branch too, I guess. > > Applied to mainline. built binutils-2.14.90.0.4 with this patch, diffs between 2.14.90.0.3 and 2.14.90.0.4 (plus patch) attached. Matthias --- ../ts-2.14.90.0.3 2003-05-28 23:26:27.000000000 +0200 +++ ../ts-2.14.90.0.4 2003-05-28 23:27:04.000000000 +0200 @@ -1,4 +1,4 @@ -Test Run By doko on Sat May 24 09:29:16 2003 +Test Run By doko on Wed May 28 23:17:19 2003 Native configuration is hppa-unknown-linux-gnu === binutils tests === @@ -52,7 +52,7 @@ === binutils Summary === # of expected passes 32 -Test Run By doko on Sat May 24 09:29:43 2003 +Test Run By doko on Wed May 28 23:17:47 2003 Native configuration is hppa-unknown-linux-gnu === gas tests === @@ -385,7 +385,7 @@ # of expected failures 11 ../as-new Inc. -Test Run By doko on Sat May 24 09:33:34 2003 +Test Run By doko on Wed May 28 23:21:37 2003 Native configuration is hppa-unknown-linux-gnu === ld tests === @@ -425,7 +425,7 @@ PASS: size/aligment change of common symbols (change 2) Running ld/testsuite/ld-elfvers/vers.exp ... PASS: vers1 -FAIL: vers2 +PASS: vers2 PASS: vers3 PASS: vers4 PASS: vers4a @@ -472,7 +472,7 @@ PASS: vers27c1 PASS: vers27c2 PASS: vers27d1 -FAIL: vers27d2 +PASS: vers27d2 PASS: vers27d3 PASS: vers27d4 PASS: vers27d5 @@ -485,9 +485,9 @@ PASS: ld-elfvsb/protected1 FAIL: visibility (hidden) (non PIC) FAIL: visibility (hidden) (non PIC, load offset) -FAIL: visibility (hidden) +PASS: visibility (hidden) FAIL: visibility (hidden) (PIC main, non PIC so) -FAIL: visibility (hidden) (PIC main) +PASS: visibility (hidden) (PIC main) FAIL: visibility (hidden_normal) (non PIC) FAIL: visibility (hidden_normal) (non PIC, load offset) FAIL: visibility (hidden_normal) @@ -500,9 +500,9 @@ PASS: visibility (hidden_undef) (PIC main) FAIL: visibility (hidden_undef_def) (non PIC) FAIL: visibility (hidden_undef_def) (non PIC, load offset) -FAIL: visibility (hidden_undef_def) +PASS: visibility (hidden_undef_def) FAIL: visibility (hidden_undef_def) (PIC main, non PIC so) -FAIL: visibility (hidden_undef_def) (PIC main) +PASS: visibility (hidden_undef_def) (PIC main) FAIL: visibility (hidden_weak) (non PIC) FAIL: visibility (hidden_weak) (non PIC, load offset) FAIL: visibility (hidden_weak) @@ -510,9 +510,9 @@ FAIL: visibility (hidden_weak) (PIC main) FAIL: visibility (protected) (non PIC) FAIL: visibility (protected) (non PIC, load offset) -FAIL: visibility (protected) +PASS: visibility (protected) FAIL: visibility (protected) (PIC main, non PIC so) -FAIL: visibility (protected) (PIC main) +PASS: visibility (protected) (PIC main) FAIL: visibility (protected_undef) (non PIC) FAIL: visibility (protected_undef) (non PIC, load offset) PASS: visibility (protected_undef) @@ -520,9 +520,9 @@ PASS: visibility (protected_undef) (PIC main) FAIL: visibility (protected_undef_def) (non PIC) FAIL: visibility (protected_undef_def) (non PIC, load offset) -FAIL: visibility (protected_undef_def) +PASS: visibility (protected_undef_def) FAIL: visibility (protected_undef_def) (PIC main, non PIC so) -FAIL: visibility (protected_undef_def) (PIC main) +PASS: visibility (protected_undef_def) (PIC main) FAIL: visibility (protected_weak) (non PIC) FAIL: visibility (protected_weak) (non PIC, load offset) FAIL: visibility (protected_weak) @@ -547,10 +547,10 @@ FAIL: ELF weak func last DSO PASS: ELF DSO weak data first PASS: ELF DSO weak data last -FAIL: ELF DSO weak data first DSO -FAIL: ELF DSO weak data last DSO -FAIL: ELF DSO weak data first DSO common -FAIL: ELF DSO weak data last DSO common +PASS: ELF DSO weak data first DSO +PASS: ELF DSO weak data last DSO +PASS: ELF DSO weak data first DSO common +PASS: ELF DSO weak data last DSO common PASS: ELF weak data first PASS: ELF weak data last PASS: ELF weak data first common @@ -613,10 +613,10 @@ Running ld/testsuite/ld-shared/shared.exp ... FAIL: shared (non PIC) FAIL: shared (non PIC, load offset) -FAIL: shared +PASS: shared PASS: shared -Bsymbolic FAIL: shared (PIC main, non PIC so) -FAIL: shared (PIC main) +PASS: shared (PIC main) Running ld/testsuite/ld-sparc/sparc.exp ... Running ld/testsuite/ld-srec/srec.exp ... XFAIL: S-records @@ -635,8 +635,8 @@ === ld Summary === -# of expected passes 117 -# of unexpected failures 63 +# of expected passes 133 +# of unexpected failures 47 # of expected failures 4 builddir-single/ld/ld-new Inc. From =?iso-8859-1?Q?J=F6rg_Benndorf?= Fri May 30 08:14:00 2003 From: =?iso-8859-1?Q?J=F6rg_Benndorf?= (=?iso-8859-1?Q?J=F6rg_Benndorf?=) Date: Fri, 30 May 2003 09:14:00 +0200 Subject: [parisc-linux] missing tasksel option 'x-window system' on parisc box Message-ID: <000c01c3267b$11f81610$1200a8c0@JOERGSPRINTER> This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C3268B.CEE241F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I got the six cd iso files using jigdo. After installation tasksel = offers no option to install the x window system. Is there a howto document covering this issue -or- would someone mind to = help me get x runnning on a 712 box. Anyone to help? Thanks, Joerg. ------=_NextPart_000_0009_01C3268B.CEE241F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I got the six cd iso files using jigdo. = After=20 installation tasksel offers no option to install the x window=20 system.
Is there a howto document covering this = issue -or-=20 would someone mind to help me get x runnning on a 712 box.
Anyone to help? Thanks, = Joerg.
 
------=_NextPart_000_0009_01C3268B.CEE241F0-- From kennywest1@hotmail.com Fri May 30 09:24:46 2003 From: kennywest1@hotmail.com (kenneth westelinck) Date: Fri, 30 May 2003 10:24:46 +0200 Subject: [parisc-linux] missing tasksel option 'x-window system' on parisc box References: <000c01c3267b$11f81610$1200a8c0@JOERGSPRINTER> Message-ID: apt-get install x-window-system (or something like this) ----- Original Message ----- From: "Jörg Benndorf" To: Sent: Friday, May 30, 2003 9:14 AM Subject: [parisc-linux] missing tasksel option 'x-window system' on parisc box I got the six cd iso files using jigdo. After installation tasksel offers no option to install the x window system. Is there a howto document covering this issue -or- would someone mind to help me get x runnning on a 712 box. Anyone to help? Thanks, Joerg. From =?iso-8859-1?Q?J=F6rg_Benndorf?= Fri May 30 10:46:37 2003 From: =?iso-8859-1?Q?J=F6rg_Benndorf?= (=?iso-8859-1?Q?J=F6rg_Benndorf?=) Date: Fri, 30 May 2003 11:46:37 +0200 Subject: [parisc-linux] missing tasksel option 'x-window system' on parisc box References: <000c01c3267b$11f81610$1200a8c0@JOERGSPRINTER> Message-ID: <001d01c32690$60547640$1200a8c0@JOERGSPRINTER> Thank you for your hint but this doesn't seem to work - always prompts "unmet dependencies" / "is not going to be installed" / "is not installable". Any other idea or am i missing an apt http/ftp source? ----- Original Message ----- From: "kenneth westelinck" To: "Jörg Benndorf" ; Sent: Friday, May 30, 2003 10:24 AM Subject: Re: [parisc-linux] missing tasksel option 'x-window system' on parisc box > apt-get install x-window-system (or something like this) > > ----- Original Message ----- > From: "Jörg Benndorf" > To: > Sent: Friday, May 30, 2003 9:14 AM > Subject: [parisc-linux] missing tasksel option 'x-window system' on parisc > box > > > I got the six cd iso files using jigdo. After installation tasksel offers no > option to install the x window system. > Is there a howto document covering this issue -or- would someone mind to > help me get x runnning on a 712 box. > Anyone to help? Thanks, Joerg. > > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > From kennywest1@hotmail.com Fri May 30 11:10:29 2003 From: kennywest1@hotmail.com (kenneth westelinck) Date: Fri, 30 May 2003 12:10:29 +0200 Subject: [parisc-linux] missing tasksel option 'x-window system' on parisc box References: <000c01c3267b$11f81610$1200a8c0@JOERGSPRINTER> <001d01c32690$60547640$1200a8c0@JOERGSPRINTER> Message-ID: I am using ftp.belnet.be as source (no CDs) and doing apt-cache search window returns x-window-system, so it should work. Anyways, I think "x-window-system" is a virtual package. So you should be able to install all it's sub-components manually. Such as xserver-common, ... . ----- Original Message ----- From: "Jörg Benndorf" To: Sent: Friday, May 30, 2003 11:46 AM Subject: Re: [parisc-linux] missing tasksel option 'x-window system' on parisc box > Thank you for your hint but this doesn't seem to work - always prompts > "unmet dependencies" / "is not going to be installed" / "is not > installable". > Any other idea or am i missing an apt http/ftp source? > > ----- Original Message ----- > From: "kenneth westelinck" > To: "Jörg Benndorf" ; > > Sent: Friday, May 30, 2003 10:24 AM > Subject: Re: [parisc-linux] missing tasksel option 'x-window system' on > parisc box > > > > apt-get install x-window-system (or something like this) > > > > ----- Original Message ----- > > From: "Jörg Benndorf" > > To: > > Sent: Friday, May 30, 2003 9:14 AM > > Subject: [parisc-linux] missing tasksel option 'x-window system' on parisc > > box > > > > > > I got the six cd iso files using jigdo. After installation tasksel offers > no > > option to install the x window system. > > Is there a howto document covering this issue -or- would someone mind to > > help me get x runnning on a 712 box. > > Anyone to help? Thanks, Joerg. > > > > _______________________________________________ > > 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 =?iso-8859-1?Q?J=F6rg_Benndorf?= Fri May 30 12:10:16 2003 From: =?iso-8859-1?Q?J=F6rg_Benndorf?= (=?iso-8859-1?Q?J=F6rg_Benndorf?=) Date: Fri, 30 May 2003 13:10:16 +0200 Subject: [parisc-linux] missing tasksel option 'x-window system' on parisc box References: <000c01c3267b$11f81610$1200a8c0@JOERGSPRINTER> <001d01c32690$60547640$1200a8c0@JOERGSPRINTER> Message-ID: <002401c3269c$0fc70240$1200a8c0@JOERGSPRINTER> Even if i use ftp.belnet.be as a single source my system does not allow me to install x-window-system. So i tried to get xserver-common - success! So i have to look for all packages needed to run x... Hopefully i will find them inside the x-howto. Thank you again for your help. Joerg. ----- Original Message ----- From: "kenneth westelinck" To: "Jörg Benndorf" ; Sent: Friday, May 30, 2003 12:10 PM Subject: Re: [parisc-linux] missing tasksel option 'x-window system' on parisc box > I am using ftp.belnet.be as source (no CDs) and doing apt-cache search > window returns x-window-system, so it should work. Anyways, I think > "x-window-system" is a virtual package. So you should be able to install all > it's sub-components manually. Such as xserver-common, ... . > > ----- Original Message ----- > From: "Jörg Benndorf" > To: > Sent: Friday, May 30, 2003 11:46 AM > Subject: Re: [parisc-linux] missing tasksel option 'x-window system' on > parisc box > > > > Thank you for your hint but this doesn't seem to work - always prompts > > "unmet dependencies" / "is not going to be installed" / "is not > > installable". > > Any other idea or am i missing an apt http/ftp source? > > > > ----- Original Message ----- > > From: "kenneth westelinck" > > To: "Jörg Benndorf" ; > > > > Sent: Friday, May 30, 2003 10:24 AM > > Subject: Re: [parisc-linux] missing tasksel option 'x-window system' on > > parisc box > > > > > > > apt-get install x-window-system (or something like this) > > > > > > ----- Original Message ----- > > > From: "Jörg Benndorf" > > > To: > > > Sent: Friday, May 30, 2003 9:14 AM > > > Subject: [parisc-linux] missing tasksel option 'x-window system' on > parisc > > > box > > > > > > > > > I got the six cd iso files using jigdo. After installation tasksel > offers > > no > > > option to install the x window system. > > > Is there a howto document covering this issue -or- would someone mind to > > > help me get x runnning on a 712 box. > > > Anyone to help? Thanks, Joerg. > > > > > > _______________________________________________ > > > 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 xam@cs.ucc.ie Fri May 30 13:10:17 2003 From: xam@cs.ucc.ie (M. Grabert) Date: Fri, 30 May 2003 13:10:17 +0100 (IST) Subject: [parisc-linux] compiler & kernel Message-ID: Hi, I just wanted to share the experience I made after experimenting with different compilers and linux-2.4.20-pa35 on Debian/testing on a C240. Maybe it's of some use for you or somebody has some remarks how to solve an issue or whether it's just me who has problems ;) This is not a request for fixing things, I'm just curious whether developers/users had similar problems and/or are aware of them. Some general problems: I use quite a lot of additional non-HP hardware in my C240: I'm using a 4port USB2.0-card, a IBM Token Ring card, (soon hopefully a NetGEAR MA311 Wireless NIC) and a 8193too-compatible Network card) So far I can only use USB1.1 drivers, since the EHCI code seems to dislike parisc (kernel oops with any compiler). Another general problem (which exists as far as I can remember): It also seems that I can only use drivers for hardware if they are directly compiled into the kernel, since otherwise 'lspci -v' will show ioports/memory for devices marked as 'disabled' and trying to modprobe h/w driver modules will fail. Modules not accessing the hardware directly however work fine. Oh yes, one important issue: I have this 'target suffers from tag starvation' problem as some others seem to have aswell. I just have a 20GB SE SCSI (50 pin), no other SCSI devices (the original internal UW-SCSI drive is in my AlphaStation now). I tried several configurations ... actually all configurations possible. It is definitely NOT a SCSI termination issue, nor a faulty HD (it works perfectly on my SUN and my Alpha). Moreover it works quite well with older kernels, such as 2.4.19-pa2. Newer kernels (starting with about 2.4.20) often report "target is suffering from tag starvation" and after that the kernel will most likely oops and hang. Most the time I even can't boot the kernel, since mounting the root fs alone will most likely cause a kernel crash. Older kernels either don't display the message at all, or not very often (such as once a day if the disk is in HEAVY use), and the kernel will never crash after displaying the message. So I copied the /usr/src/linux-2.4.19-pa2/drivers/scsi/53c700.c driver to the corresponding directory in the 2.4.20-pa35 kernel and now the kernel is perfectly stable again! I don't know what causes this trouble, but I really don't think it's my SCSI hardware (I use SCSI devices for quite a long time. I should know by know which cables to use and how to do proper SCSI termination etc. Moreover I exchanged everything just to be sure it's not faulty cables/terminators). Maybe it's just the software driver, maybe it's a bug in the HP SCSI chip when using SE disks ... I just know the older driver is much more stable! And finally some issues I have found when using certain versions of gcc to compile linux-2.4.20-pa35: (for all different compilers I used the same configuration, except for choosing 32/64bit kernels. I use the PA8000 CPU option by default) hppa64-gcc (3.2.3, from ftp.p-l.org unofficial-debs) seems to work fine but obviously ipt_limit.o is miscompiled: I can insmod it, but iptable wouldn't recognize the --limit* options. There are still some problems with some modules and canonicalize_funcptr, (IIRC networking VLAN support, TUN/TAP, zlib_deflate), but when compiled into the kernel (not compiled as modules) they seems to work Also some stability issues: Ie. wmrack makes the kernel crash immeadiately (no kernel Oops output), xosview doesn't work (no windows opened) gcc-3.0 still propably the recommended compiler, no problems! IIRC I still used the PA7000 CPU setting when compiling with gcc-3.0 at that time gcc-3.2.3 I don't recall having the same issues in ipt_limit.o that the 64bit version of gcc-3.2.3 has, everythink seems to work quite well. compiling the kernel is slower than gcc-3.0 gcc-3.3 compiled fine after commenting out the references $mulU in parisc_ksyms.c and fixing drivers/net/tokenring/olympic.c (yes, some people still use tokenring!): - type cast error in the use of memcpy_fromio, casting the parameter to ulong works - one text string spread over two lines, but without a '\' at the end. Man, gcc-3.3 is SLOW! it takes ages to compile the kernel! Kernel compiled with 3.3 definitely have a bogomips problem (they report 0.8 instead of about 470 on a C240); The kernel takes forever to boot up (it 'waits' for over one minute after palo loads the kernel (right after the 'switch to another console' message)), propably because of the bogomips calculation. Also the userspace programme 'bogomips' has the same issue. Apart to make from this issues, gcc-3.3 produces a kernel that is at least as stable as those compiled with 3.0 or 3.2 BTW, I've quite alot of networking stuff in the kernel: IPv6, Bridging, VLan, PPP, PPPoE, Netfilter, Network devices etc. Apart from that it is a pretty 'normal' configuration (I'll send the .config and System.map if somebody wants it). Right now I'm running linux-2.4.20-pa35 for over a week now, and the machine is really stable. It's actively used as DHCP-server, SMB-server, router/firewall and for several other stuff in our LAN. Thanks, Max From kris@lunadawn.net Fri May 30 14:58:04 2003 From: kris@lunadawn.net (Kris Amy) Date: Fri, 30 May 2003 23:58:04 +1000 Subject: [parisc-linux] Custom CD Message-ID: <004201c326b3$7e09aa70$2000a8c0@galileo> This is a multi-part message in MIME format. ------=_NextPart_000_003F_01C32707.4F07A020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I had to recompile the kernel on the netinst cd so I could get my NIC = support in. I have the lifimage now. Do I just mount the cd image I have = through loopback copy it's contents. Copy my lifimage into the root = directory and mkisofs that new directory? Kris ------=_NextPart_000_003F_01C32707.4F07A020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I had to recompile the kernel on the = netinst cd=20 so I could get my NIC support in. I have the lifimage now. = Do I just=20 mount the cd image I have through loopback copy it's contents. Copy my = lifimage=20 into the root directory and mkisofs that new directory?
 
Kris
------=_NextPart_000_003F_01C32707.4F07A020-- From joel.soete@tiscali.be Sat May 31 11:40:33 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Sat, 31 May 2003 10:40:33 +0000 Subject: [parisc-linux] compiler & kernel In-Reply-To: References: Message-ID: <3ED886A1.10605@tiscali.be> M. Grabert wrote: >[...] > >Oh yes, one important issue: >I have this 'target suffers from tag starvation' problem as some others >seem to have aswell. I just have a 20GB SE SCSI (50 pin), no other SCSI >devices (the original internal UW-SCSI drive is in my AlphaStation now). > > >I tried several configurations ... actually all configurations possible. >It is definitely NOT a SCSI termination issue, nor a faulty HD (it works >perfectly on my SUN and my Alpha). Moreover it works quite well with >older kernels, such as 2.4.19-pa2. > >Newer kernels (starting with about 2.4.20) often report "target is >suffering from tag starvation" and after that the kernel will most likely >oops and hang. Most the time I even can't boot the kernel, since >mounting the root fs alone will most likely cause a kernel crash. >Older kernels either don't display the message at all, or >not very often (such as once a day if the disk is in HEAVY use), and the >kernel will never crash after displaying the message. > >So I copied the /usr/src/linux-2.4.19-pa2/drivers/scsi/53c700.c driver >to the corresponding directory in the 2.4.20-pa35 kernel and now the >kernel is perfectly stable again! > Which scsi driver do you used (I presume a Symbios one but version 1 or 2; version 2 is recommended now in 2.4.20-pa..)? OTC this w-e I still experiment such a scsi terminator pb: I recover a lvd 30gb scsi-disk (sun); I find a converter sca2 80pins sca 64pins but a cable with terminator for hvd disk. The disk seems to works fine untill the terminator warm to much then I got scsi parity errors. And without terminator the controler do not see the disk at all? >I don't know what causes this trouble, but I really don't think it's my >SCSI hardware (I use SCSI devices for quite a long time. I should know by >know which cables to use and how to do proper SCSI termination etc. >Moreover I exchanged everything just to be sure it's not faulty >cables/terminators). >Maybe it's just the software driver, maybe it's a bug in the HP SCSI chip >when using SE disks ... I just know the older driver is much more stable! > > > >And finally some issues I have found when using certain versions of gcc >to compile linux-2.4.20-pa35: > >(for all different compilers I used the same configuration, except for >choosing 32/64bit kernels. I use the PA8000 CPU option by default) > > > >hppa64-gcc (3.2.3, from ftp.p-l.org unofficial-debs) > seems to work fine but obviously ipt_limit.o is miscompiled: > I can insmod it, but iptable wouldn't recognize the --limit* options. > There are still some problems with some modules and canonicalize_funcptr, > Are you sure this is with hppa64-gcc (iirc canonicalize.., was just recently backport to 3.2)? [...] > Man, gcc-3.3 is SLOW! it takes ages to compile the kernel! > > Kernel compiled with 3.3 definitely have a bogomips problem (they report > 0.8 instead of about 470 on a C240); > The kernel takes forever to boot up (it 'waits' for over one minute > after palo loads the kernel (right after the 'switch to another console' > message)), propably because of the bogomips calculation. > Also the userspace programme 'bogomips' has the same issue. > > Apart to make from this issues, gcc-3.3 produces a kernel that is at > least as stable as those compiled with 3.0 or 3.2 > > >BTW, I've quite alot of networking stuff in the kernel: >IPv6, Bridging, VLan, PPP, PPPoE, Netfilter, Network devices etc. >Apart from that it is a pretty 'normal' configuration (I'll send the >.config and System.map if somebody wants it). > > >Right now I'm running linux-2.4.20-pa35 for over a week now, and the >machine is really stable. It's actively used as DHCP-server, >SMB-server, router/firewall and for several other stuff in our LAN. > > > hmm I just reboot (just to exchange cards) some l-w firewall (so only ppp, ppoe, netfilter, just ipv4, no ipv6 , no bridging, no vlan) running since 79days a kernel 2.4.20-pa22 build with gcc-3.3 on a b180 and do not presenting this kind of pb. Unfortuantely, I don't have all your hw available but can you send me your config file so that I can see if I can reproduce. btw which gcc-3.3 release do you use? hth, Joel From r.scholz@bluehash.de Sat May 31 13:31:30 2003 From: r.scholz@bluehash.de (=?ISO-8859-1?Q?R=FCdiger_Scholz?=) Date: Sat, 31 May 2003 14:31:30 +0200 Subject: [parisc-linux] missing tasksel option 'x-window system' on parisc box In-Reply-To: <001d01c32690$60547640$1200a8c0@JOERGSPRINTER> References: <000c01c3267b$11f81610$1200a8c0@JOERGSPRINTER> <001d01c32690$60547640$1200a8c0@JOERGSPRINTER> Message-ID: <3ED8A0A2.8000808@bluehash.de> Hello Jörg, Jörg Benndorf schrieb: >Thank you for your hint but this doesn't seem to work - always prompts >"unmet dependencies" / "is not going to be installed" / "is not >installable". > The problem is that the package "fvwm" is in "x-window-system". But "fvwm" depend on the package "menu" which (i think) is not avaible for debian/stable. Either you are struggling with "apt" to force the installation with unmet dependencies or you use debian/testing. There is a "menu"-package. I hope it helps, Rüdiger From r.scholz@bluehash.de Sat May 31 13:40:20 2003 From: r.scholz@bluehash.de (=?ISO-8859-1?Q?R=FCdiger_Scholz?=) Date: Sat, 31 May 2003 14:40:20 +0200 Subject: [parisc-linux] Re: Trouble trying to start gdm In-Reply-To: References: Message-ID: <3ED8A2B4.4030904@bluehash.de> Hello, which graphicscard of your 715/100 are you using? The built-in one has a color depth of only 8bit. So you has to change the "defaultdepth"-entry in your XF86Config-4 accordingly. Ruediger From sid@mindless.co.uk Sat May 31 14:54:36 2003 From: sid@mindless.co.uk (Siraj 'Sid' Rakhada) Date: Sat, 31 May 2003 14:54:36 +0100 (BST) Subject: [parisc-linux] Installation on a K370 with Debian 3.0r1 + RAID1 boot. Message-ID: <56739.194.131.108.2.1054389276.squirrel@ssl.mindless.co.uk> A few notes on a successful installation on a HP K370 box, using Debian 3.0r1 and a netinstall CD (for PDC console support). Also the boot disk is on a RAID1. Written in the hopes it might help someone, possibly... This was all done via a console. Boot with the 2.4.20-pa32 netinstall CD. When it prompts you to interact with IPL choose yes. At the following prompt, which sould be PALO, change console=ttyS0 to console=ttyB0 You should then have the kernel bootup and after a few moments the debian installer menu should appear Proceed with the install by following the prompts, taking care to read the instructions about the partition types. When you get to the stage where the system wants to reboot do *not* reboot (yet). Instead go to a shell find the /dev directory in /mnt/target somewhere (I have forgotten the exact location, you can find it with just a 'mount' command and read the output) delete the *target* /dev/ttyB0 if it does not look like this: # ls -l ttyB0 crw------- 1 root root 11, 0 May 27 07:48 ttyB0 then do # mknod ttyB0 c 11 0 # CTRL-D (to logout) You should now be able to reboot safely. If you skip this step, Debian will boot, but you will be unable to use the console. Note I have not actually done the above when I was installing - I cheated and installed sshd via a chroot setup - because I did not realise the ttyB0 major number was incorrect on the install CD. I'm expecting that modifying the device as above should work. If I had more time I would have tried the above method. I believe the major number has changed from 30 to 60, and now to 11, which is it's final resting place (can someone confirm that)? Once the machine reboots you should be greeted with the Debian second stage installer - carry on with whatever options you want to pick and you should then be dropped at a root prompt. Debian should now be installed on your box (I hope) and that's it. Read below if you want to have a RAID1 boot drive... As I had 4 x 9GB disks (all identical) I decided to follow Martin Petersen's RAID1 boot howto http://lists.parisc-linux.org/pipermail/parisc-linux/2003-January/018892.html General packages required: mdadm, palo (>=1.2), and associated debian build packages. Most of the steps make perfect sense, though I had a few issues as I wanted to stick to debian/stable as much as I could - therefore I could not install the palo 1.2 binary package - which is required if you wish to boot from a RAID partition. So what you should do is get hold of the palo 1.2 debian source, and then you should be able to build the package yourself: # dpkg-source palo_1.2.dsc # cd palo-1.2 # dpkg-buildpackage -r fakeroot -b # dpkg -i ../palo_1.2_hppa.deb If you are able to upgrade to testing, then this is not a big deal - you should be able to simply upgrade your palo binary (along with libc etc), and skip the above steps. Though make sure you have version 1.2 of Palo by running '/sbin/palo | grep version' - do this as a normal user if you are worried of breaking things. I also had an issue as I had multiple partitions for /, /home, /var, /boot, and /usr so I had to use multiple 'tar' commands (I'm not an expert on tar, so I'm sure there are better ways than how I did it). I am also uncertain how Martin's command worked for /boot in his setup too... Anyway, it was as simple as this: (read in addition to step 5 on the Howto) Mount new partitions in place. I mounted the RAID / onto /mnt, and then mounted the RAID /usr onto /mnt/usr etc. These steps should be done in single user mode - 'init 1' should get you there (do this via console). mount /dev/md2 /mnt mount /dev/md0 /mnt/boot mount /dev/md3 /mnt/usr mount /dev/md4 /mnt/home mount /dev/md5 /mnt/var cd /mnt tar -C / -clspf - . | tar -xlspvf - cd /mnt/usr tar -C /usr -clspf - . | tar -xlspvf - cd /mnt/boot tar -C /boot -clspf - . | tar -xlspvf - cd /mnt/home tar -C /home -clspf - . | tar -xlspvf - cd /mnt/var tar -C /var -clspf - . | tar -xlspvf - You should be able to carry right on at step 6 now. Suggested reading... Boot Howto: http://tldp.org/HOWTO/PA-RISC-Linux-Boot-HOWTO/index.html FAQ: http://www.parisc-linux.org/faq/index.html Also uses the RAID1 Boot Howto: http://www.parisc-linux.org/faq/raidboot-howto.html I hope this helps someone! The documentation out there was very useful - though the ttyB0 change of the major number really got me for a while (I only found out that this had changed through searching the mailing list)... This is also the first time I've ever really used a HP box, and they are ... interesting :) e.g. is it normal that the machine will take about 10+ minutes to boot up? (just to get to the boot ROM, nothing to do with linux - self tests are enabled, though disabilng them does not make too much of a difference). Also, anyone aware if SMP will work on this box? I have two CPU's, but I'm only using one, as I believe the netinstall CD only comes with a SMP disabled kernel, and I have not got the 2.4.20 kernel source available at the moment (The HP box is not connected to the Internet). Anyway, great project. I'm glad it all works now :) Best regards, Sid From joel.soete@tiscali.be Sat May 31 19:10:57 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Sat, 31 May 2003 18:10:57 +0000 Subject: [parisc-linux] Installation on a K370 with Debian 3.0r1 + RAID1 boot. In-Reply-To: <56739.194.131.108.2.1054389276.squirrel@ssl.mindless.co.uk> References: <56739.194.131.108.2.1054389276.squirrel@ssl.mindless.co.uk> Message-ID: <3ED8F031.5080903@tiscali.be> Hello Sid, First of all congratulation for your great job [I am not quiet sure to reach this result at my first atempt) and many thanks for your kind reports: very clear and fine appropriate details. Siraj 'Sid' Rakhada wrote: [...] >cd /mnt >tar -C / -clspf - . | tar -xlspvf - >cd /mnt/usr >tar -C /usr -clspf - . | tar -xlspvf - >cd /mnt/boot >tar -C /boot -clspf - . | tar -xlspvf - >cd /mnt/home >tar -C /home -clspf - . | tar -xlspvf - >cd /mnt/var >tar -C /var -clspf - . | tar -xlspvf - > > I also split my fs copy at this stage but normaly if you mount all your fs under "/mnt" then: cd /mnt tar -C / -cspf - . | tar -xspvf # just remove 'l' (el) option and remove v option shlould be quicker should work also in one step (as you have 4*9Gb disks, may be do you still have 2 free to test and confirm this; many thanks in advance) >I hope this helps someone! The documentation out there was very useful - >though the ttyB0 change of the major number really got me for a while (I >only found out that this had changed through searching the mailing >list)... > >This is also the first time I've ever really used a HP box, and they are >... interesting :) e.g. is it normal that the machine will take about 10+ >minutes to boot up? (just to get to the boot ROM, nothing to do with linux >- self tests are enabled, though disabilng them does not make too much of >a difference). > hmm, I am not quiet sure but may be this pb is solved in 2.4.20-pa35... >Also, anyone aware if SMP will work on this box? I have two CPU's, but I'm >only using one, as I believe the netinstall CD only ces with a SMP >disabled kernel, and I have not got the 2.4.20 kernel source available at >the moment (The HP box is not connected to the Internet). > SMP kernel should work on your K. Afaik, as there few K's running linux, the best would be to experiment by your self (the tips is that your original kernel config file stand in /boot; so you copy it into your linux src tree as .config and use make menuconfig to change SMP config :-) ). To grab the kernel src now? How do you grab the last net boot install? My HP boches ( :-) ) are not more connected to Internet (well just a light weight firewall with a pstn connection at 33000 bauds and trust me it is not enough to download a full kernel src in a quick way: just enough for some cvs update (personnaly I am awaiting a subversion server ...) ). So I grab src (tar.gz available on ftp.parisc-linux.org/cvs or just patch .gz or via cvs server) on my pc and just transfer this to my HP box via ftp or scp (you just have be sure to have a well configured NIC and a ftpd or sshd server installed either on your pc (if also a linux) or on your hp box) Hope this help, Joel > >Anyway, great project. I'm glad it all works now :) > > > Well come to the club :-) From stian@soiland.no Sat May 31 22:40:29 2003 From: stian@soiland.no (Stian =?iso-8859-1?Q?S=F8iland?=) Date: Sat, 31 May 2003 23:40:29 +0200 Subject: [parisc-linux] Installation on a K370 with Debian 3.0r1 + RAID1 boot. In-Reply-To: <56739.194.131.108.2.1054389276.squirrel@ssl.mindless.co.uk> References: <56739.194.131.108.2.1054389276.squirrel@ssl.mindless.co.uk> Message-ID: <20030531214029.GD9267@itea.ntnu.no> On 2003-05-31 15:54:36, Siraj 'Sid' Rakhada wrote: > If you skip this step, Debian will boot, but you will be unable to use the > console. > Note I have not actually done the above when I was installing - I cheated > and installed sshd via a chroot setup - because I did not realise the > ttyB0 major number was incorrect on the install CD. I'm expecting that > modifying the device as above should work. If I had more time I would have > tried the above method. For later boots, devfs and devfsd should be able to handle this if your kernel supports it. > This is also the first time I've ever really used a HP box, and they are > ... interesting :) e.g. is it normal that the machine will take about 10+ > minutes to boot up? (just to get to the boot ROM, nothing to do with linux > - self tests are enabled, though disabilng them does not make too much of > a difference). Oh yeah, my K250 takes ages just to get started, the LCD display and status line on the serial console changes with different numbers. Any idea of what all those numbers mean? I suppose they are different parts that are tested, but a translation would be nice.=20 My manuals does not explain these messages in detail.. How ever, nice guide, I wish I had it when I set up my system =3D) =2E.. goes off-topic: I have 6 SCSI disks connected, distributed in two raid1-sets for / and /usr, and a raid5-set for /home. Some of the disks are 4 GB, the rest 2 GB, so I've done dirty tricks with partitions to get the whole thing up, and not waisting any space, and I now even have a spare disk, although tests reveal the disk is broken.. I've managed to get two more 2 GB-disk to replace it.. =3D) Ah, yes, the K250 is BIG, but there's only room for 4 disks! Stupid! I've placed one disk beside the CD-rom, connected to the other controller, and the last disk in an external cabinet =3D) I've wondered if it would not be possible to modify the housing to get room for more disks... Would it be immoral of me to destroy the beauty of a K250 by cutting some holes here and there? =3D) --=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] K250 at http://beist.ntnu.nu/ =3D) =20