From carlos@baldric.uwo.ca Mon Sep 1 07:05:40 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Mon, 1 Sep 2003 02:05:40 -0400 Subject: [parisc-linux] Re: [glibc] tststatic failues, reduced to simp le testcase. In-Reply-To: <200308312047.QAA05245@hiauly3.hia.nrc.ca> References: <20030831202203.GN5194@systemhalted> <200308312047.QAA05245@hiauly3.hia.nrc.ca> Message-ID: <20030901060540.GA19107@systemhalted> On Sun, Aug 31, 2003 at 04:47:59PM -0400, John David Anglin wrote: > > That seems best. The sad fact though is that until I bump > > min_kernel_version in glibc past the kernel version that last didn't > > have this fix, I'm still forced to implement all this for people with > > older kernels. > > Why? Things are broken now and people have lived with the bug for > sometime. While it is possible to work around the problem in userspace, > the best fix is to do it in the kernel. I wouldn't fix anything but > a regression. It's best to use an example. Debian supports HPPA as an architecture. I provide Debian with patches to make upstream glibc cvs buildable for this distribution. If I make all the glibc fixes in the kernel, and submit to debian minimal patches, glibc will build and subsequent updates will render all userspace broken. As a happy medium I need to make, atleast for all usable distributions, a set of patches that fix it in such a way that we don't force a kernel update (people don't like to update their kernel). The patches I send upstream will be different. They will, to the best of my ability, be as clean as possible. I balance users on one side, and the "right thing" on the other. I agree, that the kernel, sharing the context switch path, and already saving r19 should be held responsible for restoring r19. I've already begun to run into a number of cases where userspace restores aren't going so well. c. From joel.soete@tiscali.be Mon Sep 1 09:00:34 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Mon, 01 Sep 2003 08:00:34 +0000 Subject: [parisc-linux] Security Hole in binfmt_som.c ? In-Reply-To: <1062251389.31150.4.camel@dhcp23.swansea.linux.org.uk> References: <3F509BBD.2040007@hrzpub.tu-darmstadt.de> <20030830131541.GI13467@parcelfarce.linux.theplanet.co.uk> <1062251389.31150.4.camel@dhcp23.swansea.linux.org.uk> Message-ID: <3F52FCA2.5050500@tiscali.be> Alan Cox wrote: >On Sad, 2003-08-30 at 14:15, Matthew Wilcox wrote: > > >>On Sat, Aug 30, 2003 at 02:42:37PM +0200, Ruediger Scholz wrote: >> >> >>>binfmt_som.c:216:2: #error "Fix security hole before enabling me" >>>What's this message about? >>> >>> >>I don't know. I wish someone would tell me. You'd think they'd have the >>decency to contact the person listed as the author at the top of the file. >> >> > >Actually explanations were posted in the previous discussion on this on >parisc-list. > >Someone has to do the equivalent of the 2.4.22 binfmt_elf changes if >neccessary so that another thread can't change the file handles or >steal the exec fd being passed to the loader. > > > Yes Alan, it was: Sorry Willy I trusted that you read it (My bad next time I will advise you directly) Joel From feedback@mail.girlshop.com Mon Sep 1 13:29:59 2003 From: feedback@mail.girlshop.com (Girlshop Feedback) Date: Mon, 1 Sep 2003 07:29:59 -0500 Subject: [parisc-linux] automated response Message-ID: <10309010729.AA02888@mail.girlshop.com> Thank you for emailing us at feedback@girlshop.com. We value your comments. If you emailed us regarding a placed order, or if you have questions about merchandise, please contact customerservice@girlshop.com for a quicker reply. Happy shopping! - Girlshop From felipecurtin@whipmail.com Mon Sep 1 13:37:15 2003 From: felipecurtin@whipmail.com (ELGORDO LOTTRY COMMISSION) Date: Mon, 1 Sep 2003 14:37:15 +0200 Subject: [parisc-linux] AWARD WINNING NOTIFICATION Message-ID: <20030901123703.511D14830@dsl2.external.hp.com> LOTTERY LA PRIMITIVA=2E C=2FBUSMAN EL BUENO=2C137 MADRID - ESPANA TEL=3A +34- 645666196 AND FAX +34-916 640 223 FROM=3A THE DESK OF THE PROMOTIONS MANAGER=2C INTERNATIONAL PROMOTIONS=2FPRIZE AWARD DEPARTMENT=2C REF=3A LP=2F26510460037=2F07 BATCH=3A 26=2F00319=2FIPD=2E ATTENTION=3A =28CONGRATULATION=29 =22AWARD NOTIFICATION FINAL NOTICE=2E=22 We are pleased to inform you of the announcement=2C of winners of the LOTTERY PRIMITIVA SWEEPSTAKES=2FINTERNATIONAL PROGRAMS held on 26 AUGUST=2C2003=2E Your name is attached to ticket number 008-05117963-198=2C with serial number 99375 drew the lucky numbers 30-33 -34-39-36-48=2C and consequently won the lottery in the 3rd category=2E You have therefore been approved for a lump sum pay out of EUROS 689=2C522=2C34 THOUSAND in cash credited to file No=3ALP=2F26510460037=2F07=2EThis is from total prize money of EUROS 60=2C200=2C000=2E00 shared among the twenty international winners in this category=2E All participants were selected through a computer ballot system drawn form 25=2C000 names from Australia=2C New Zealand=2C America=2C Europe=2C North America and Asia as part of International Promotions Program=2C which is conducted annually=2E CONGRATULATIONS!!! Your fund is now insured to your name=2E Due to the mix up of some numbers and names=2C we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account=2E This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program=2E We hope with a part of you prize=2C you will participate in our end of year high stakes Euros1=2E1 billion International Lottery=2E To begin your claim=2C please contact your claims agent=2C FELIPE CURTIN FOREIGN OPERATION MANAGER=2C Email=3B =28felipecurtin=40whipmail=2Ecom =3Cmailto=3Afelipecurtin=40whipmail=2Ecom=3E=29 For due processing and remittance of your prize money to a designated account with our bankers=2E Remember=2C all prize money must be claimed not later than 25 SEPTEMBER=2C 2003=2E After this date=2C all funds will be returned as unclaimed=2E NOTE=3A In order to avoid unnecessary delays and complications=2C please remember to quote your reference and batch numbers in every one of your correspondences with your agent=2E Furthermore=2C should there be any change of your address=2C do inform your claims agent as soon as possible=2E Congratulations again from all our staff and thank you for being part of our promotions programm=2E =28 CONGRATULATION=29 BEST REGARDS DR CARLOS F=2E LOPEZ From carlos@baldric.uwo.ca Mon Sep 1 16:52:36 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Mon, 1 Sep 2003 11:52:36 -0400 Subject: [parisc-linux] [Status udate] hppa glibc 2.3.2 (Builders wanted!) Message-ID: <20030901155235.GD19107@systemhalted> parisc, Thanks to the help of many people (lamont, randolph, james, willy, dave, grant ... and more) I've gotten glibc 2.3.2 into a working state. This set of patches represents our current state. There are a number of failures right now, and I'm trying to narrow them down to into categories before release, I would be much appreciated to have other people build glibc and report back their list of errors. =============== WARNING =============== This glibc should NOT be installed on any system you value, there are still some suspect high priority problems. I am merely looking for people to build and run the testsuite on their setup. Thanks :) =============== WARNING =============== The recipe: 0. Make some room! mkdir glibc-cvs cd glibc-cvs 1. Get fresh source and store it for a rainy day. cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/glibc login {enter "anoncvs" as the password} cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/glibc co libc tar cvf libc.tar libc 2. Download the newest patches (updated this morning). wget http://www.baldric.uwo.ca/~carlos/glibc-2.3.2-patches.tar.gz 3. Download some scripts. wget http://www.baldric.uwo.ca/~carlos/glibc-build.sh wget http://www.baldric.uwo.ca/~carlos/glibc-upnpatch.sh 4. Run the scripts in this order. ./glibc-upnpatch.sh (Look for rejects) ./glibc-build.sh hppa (Build it!) 5. The latter script will output the error from the 'make -k check' phase, please report those back to the list. --- Current errors and their status: make[2]: *** [/glibc-cvs/build-hppa/iconvdata/bug-iconv3.out] Error 1 Priority: Unknown. o Unknown, problem with our libc_lock functions, this test starts up the iconv code in a non-threaded environment, then dlopen's libpthread to make it reentrant and then starts the iconv code back up again to see if the libc_lock functions work... it deadlocks. make[1]: *** [iconvdata/tests] Error 2 make[2]: *** [/glibc-cvs/build-hppa/math/test-fenv.out] Error 1 make[2]: *** [/glibc-cvs/build-hppa/math/test-float.out] Error 1 make[2]: *** [/glibc-cvs/build-hppa/math/test-double.out] Error 1 make[2]: *** [/glibc-cvs/build-hppa/math/test-ifloat.out] Error 1 Priority: Low. o We've had these for ever. Printf problems? make[1]: *** [math/tests] Error 2 make[2]: *** [/glibc-cvs/build-hppa/stdlib/tst-strtod.out] Error 1 make[2]: *** [/glibc-cvs/build-hppa/stdlib/bug-strtod.out] Error 1 Priority: Medium. o Recent regeressions in 2.3.2, reasons unknown, Randolph had given them a look but it might be mmap related, not tested on a kernel with jejb's fix. Going to try that today. make[1]: *** [stdlib/tests] Error 2 make[2]: *** [/glibc-cvs/build-hppa/libio/tst-mmap-eofsync.out] Error 1 make[2]: *** [/glibc-cvs/build-hppa/libio/tst-mmap-fflushsync.out] Error 1 Priority: High. o Fixed by jejb's recent patch to 2.6 and backport to 2.4 (Thanks!). Actually we know if fixes one of these, have yet to see if it fixes both. make[1]: *** [libio/tests] Error 2 make[2]: *** [/glibc-cvs/build-hppa/dlfcn/tststatic.out] Error 139 Priority: High. o Static object dlopening RTLD_LAZY and tryint to call the function descriptor stub put in place by RTLD_LAZY. This is a suspect PLABEL problem with the dynamic loader, needs more analysis. Perhaps randolph/dave's patches to binutils for converting relocations might be helpfull here since the dlopen might expect that r19 should be setup for the jump to the stub? make[1]: *** [dlfcn/tests] Error 2 make[2]: *** [/glibc-cvs/build-hppa/posix/tst-regex.out] Error 139 Priority: High. o Regresssion. I think it's somehow related to restoring r19 after a signal handler. Need to think more about the restoration of r19 across different syscalls. make[2]: [/glibc-cvs/build-hppa/posix/annexc.out] Error 1 (ignored) Ignored. make[1]: *** [posix/tests] Error 2 make[2]: *** [/glibc-cvs/build-hppa/linuxthreads/tst-cancel2.out] Error 1 make[2]: *** [/glibc-cvs/build-hppa/linuxthreads/tst-popen.out] Error 1 make[2]: *** [/glibc-cvs/build-hppa/linuxthreads/tst-popen2.out] Error 1 Priority: High. o Regresssions. Reasons unkown. Children die of SIGSEGV, related to restoring r19 and signal handlers? make[1]: *** [linuxthreads/tests] Error 2 make[2]: *** [/glibc-cvs/build-hppa/rt/tst-timer.out] Error 139 Priority: High. o Regression. Dies after returning from rt_sigsuspend and we restore r19, perhaps we shouldn't? make[1]: *** [rt/tests] Error 2 make[2]: *** [/glibc-cvs/build-hppa/elf/neededtest.out] Error 14 make[2]: *** [/glibc-cvs/build-hppa/elf/neededtest2.out] Error 14 make[2]: *** [/glibc-cvs/build-hppa/elf/neededtest3.out] Error 17 make[2]: *** [/glibc-cvs/build-hppa/elf/neededtest4.out] Error 2 make[2]: *** [/glibc-cvs/build-hppa/elf/circleload1.out] Error 9 Priority: Low o Been here since the start of time, related to the fact that we aren't properly initializing _r_debug in the dynamic loader. make[2]: *** [/glibc-cvs/build-hppa/elf/tst-tls13.out] Error 1 Priority: Low. o We don't even have tls enabled let alone implemented? :) make[1]: *** [elf/tests] Error 2 make: *** [check] Error 2 Thanks to everyone who helped me out! Cheers, Carlos. From xam@cs.ucc.ie Mon Sep 1 17:34:05 2003 From: xam@cs.ucc.ie (M. Grabert) Date: Mon, 1 Sep 2003 17:34:05 +0100 (IST) Subject: [parisc-linux] (no subject) Message-ID: Hi, I think we have another mixup in the CVS: http://lists.parisc-linux.org/pipermail/parisc-linux-cvs/2003-September/033329.html thanks, Max From xam@cs.ucc.ie Mon Sep 1 17:37:57 2003 From: xam@cs.ucc.ie (M. Grabert) Date: Mon, 1 Sep 2003 17:37:57 +0100 (IST) Subject: [parisc-linux] CVS mixup Message-ID: Hi, I think we have another mixup in the CVS: http://lists.parisc-linux.org/pipermail/parisc-linux-cvs/2003-September/033329.html thanks, Max From xam@cs.ucc.ie Mon Sep 1 17:44:00 2003 From: xam@cs.ucc.ie (M. Grabert) Date: Mon, 1 Sep 2003 17:44:00 +0100 (IST) Subject: [parisc-linux] CVS mixup In-Reply-To: Message-ID: On Mon, 1 Sep 2003, M. Grabert wrote: > I think we have another mixup in the CVS: > > http://lists.parisc-linux.org/pipermail/parisc-linux-cvs/2003-September/033329.html Mhh, on a second look it just looks like a typo: 2.4.0-test4-pa7 instead of 2.6.0-test4-pa7 in the CVS log ... sorry about that Max From grundler@parisc-linux.org Mon Sep 1 18:40:19 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 1 Sep 2003 11:40:19 -0600 Subject: [parisc-linux] CVS mixup In-Reply-To: References: Message-ID: <20030901174019.GA18175@dsl2.external.hp.com> On Mon, Sep 01, 2003 at 05:44:00PM +0100, M. Grabert wrote: > 2.4.0-test4-pa7 instead of 2.6.0-test4-pa7 in the CVS log ... yes - sorry grant From ravms@localhost.localdomain Mon Sep 1 21:32:06 2003 From: ravms@localhost.localdomain (RAV AntiVirus) Date: Mon, 01 Sep 2003 16:32:06 -0400 Subject: [parisc-linux] RAV AntiVirus scan results Message-ID: <200309012032.h81KW6gH009183@localhost.localdomain> ----------------------- This e-mail is generated by the localhost.localdomain mail server to warn you that the e-mail sent by parisc-linux@lists.parisc-linux.org to agabriel@rcec.london.on.ca is infected with virus: Win32/Sobig.F@mm. Please contact your system administrator for further information. If you are the sender: ------------------- The scanned e-mail has your address in the header field. Either your computer is infected or someone's computer having your e-mail address in the address book has been infected. (Please note that some viruses are sending e-mails directly from your computer. Our advise is to check your computer using an up-to-date antivirus product). If you are the receiver: --------------------- Please contact the sender: very probably he/she doesn't know he/she has a computer virus. Actions taken for the infected files: ------------------------------------- The infected file was saved to quarantine with name: 1062448326-RAVh81KVmgH009177. The file (part0002:document_all.pif) attached to mail (with subject:Re: Details) sent by parisc-linux@lists.parisc-linux.org to agabriel@rcec.london.on.ca is infected with virus: Win32/Sobig.F@mm. Cannot clean this file. The file was successfully deleted by RAV AntiVirus. ------------------------ this is a copy of the e-mail header: RAV AntiVirus for Linux i386 version: 8.4.0 (snapshot-20020919) Scan engine 8.11 for i386. Last update: Mon, 01 Sep 2003 08:58:36 -04 Scanning for 81707 malwares (viruses, trojans and worms). From Mailer-Daemon@gw4.medctr.ohio-state.edu Tue Sep 2 02:17:21 2003 From: Mailer-Daemon@gw4.medctr.ohio-state.edu (Mailer-Daemon@gw4.medctr.ohio-state.edu) Date: Mon, 01 Sep 2003 21:17:21 -0400 Subject: [parisc-linux] Message status - undeliverable Message-ID: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --Boundary_(ID_pcux+v+by+y5THX44JuWiw) Content-type: text/plain; charset=US-ASCII Content-disposition: inline Content-transfer-encoding: 7BIT The message that you sent was undeliverable to the following: erda01@gw.medctr.ohio-state.edu (user not found) Possibly truncated original message follows: --Boundary_(ID_pcux+v+by+y5THX44JuWiw) Content-type: MESSAGE/RFC822 Received: from webshield1.medctr.ohio-state.edu by gw4.medctr.ohio-state.edu; Mon, 01 Sep 2003 21:17:17 -0400 Received: From juno.medctr.ohio-state.edu ([140.254.138.20]) by webshield1.medctr.ohio-state.edu (WebShield SMTP v4.5 MR1a) ; id 1062466197111; Mon, 01 Sep 2003 21:29:57 -0400 Received: from directory-daemon by hermes.medctr.ohio-state.edu (PMDF V5.2-31 #30648) id <01L05XO3U5LC8WXGD1@hermes.medctr.ohio-state.edu> for erda01@gw.medctr.ohio-state.edu (ORCPT rfc822;erdal-1@medctr.osu.edu); Mon, 01 Sep 2003 21:16:28 -0400 (EDT) Received: from iris.medctr.ohio-state.edu (iris.medctr.ohio-state.edu [140.254.120.45]) by hermes.medctr.ohio-state.edu (PMDF V5.2-31 #30648) with SMTP id <01L05XO3JCM28WXKYD@hermes.medctr.ohio-state.edu> for erdal-1@medctr.osu.edu; Mon, 01 Sep 2003 21:16:27 -0400 (EDT) Received: from WPZ ([24.95.46.197]) by iris.medctr.ohio-state.edu with ESMTP for erdal-1@medctr.osu.edu; Mon, 01 Sep 2003 21:19:43 -0400 Date: Mon, 01 Sep 2003 21:16:56 +0400 From: parisc-linux@parisc-linux.org Subject: Re: Approved To: erdal-1@medctr.osu.edu Message-id: <01L05XO3JOV08WXKYD@hermes.medctr.ohio-state.edu> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_5V4+AeScWtvDi3N4es+JBA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-MailScanner: Found to be clean Network Associates WebShield SMTP V4.5 MR1a on webshield1 detected virus W32/Sobig.f@MM in attachment unknown from and it was Deleted. --Boundary_(ID_5V4+AeScWtvDi3N4es+JBA)-- --Boundary_(ID_pcux+v+by+y5THX44JuWiw)-- From James.Bottomley@steeleye.com Wed Sep 3 17:56:00 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 03 Sep 2003 12:56:00 -0400 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.6 jejb In-Reply-To: <20030903165113.138BF494064@palinux.hppa> References: <20030903165113.138BF494064@palinux.hppa> Message-ID: <1062608161.2251.27.camel@mulgrave> On Wed, 2003-09-03 at 12:51, James Bottomley wrote: > CVSROOT: /var/cvs > Module name: linux-2.6 > Changes by: jejb 03/09/03 10:51:13 > > Modified files: > . : Makefile > drivers/net/tulip: eeprom.c tulip.h tulip_core.c > drivers/parisc : dino.c > > Log message: > Fix card mode dino support and make HSC FX (tulip) card work Patch is in two parts: dino bit just corrects some thinkos in the card mode dino code and adds the actual dino device to the prints (useful for debugging if you have more than one dino). The tulip fix simply adds the card to the tulip card table and makes it all work. I've tested this on my C360...however, I had to hack the ccio window to get that to work...I need more time to make this code better. James ===== drivers/net/tulip/eeprom.c 1.9 vs edited ===== --- 1.9/drivers/net/tulip/eeprom.c Mon Oct 28 23:14:42 2002 +++ edited/drivers/net/tulip/eeprom.c Wed Sep 3 11:41:24 2003 @@ -93,8 +93,13 @@ #ifdef __hppa__ unsigned char *ee_data = tp->eeprom; - if (ee_data[0] == 0x3c && ee_data[1] == 0x10 && - (ee_data[2] == 0x63 || ee_data[2] == 0x61) && ee_data[3] == 0x10) { + /* NOTE: The 3x5 FF cards the ee_data is trying to recognise + * need to be brought properly under the tulip initialisation + * structure */ + + if ((tp->flags & NEEDS_FAKE_MEDIA_TABLE) + || (ee_data[0] == 0x3c && ee_data[1] == 0x10 && + (ee_data[2] == 0x63 || ee_data[2] == 0x61) && ee_data[3] == 0x10)) { static unsigned char leafdata[] = { 0x01, /* phy number */ ===== drivers/net/tulip/tulip.h 1.15 vs edited ===== --- 1.15/drivers/net/tulip/tulip.h Sun May 25 22:14:37 2003 +++ edited/drivers/net/tulip/tulip.h Wed Sep 3 11:27:00 2003 @@ -64,6 +64,8 @@ COMET_MAC_ADDR = 0x0800, HAS_PCI_MWI = 0x1000, HAS_PHY_IRQ = 0x2000, + HAS_SWAPPED_SEEPROM = 0x4000, + NEEDS_FAKE_MEDIA_TABLE = 0x8000, }; @@ -86,6 +88,7 @@ I21145, DM910X, CONEXANT, + HP_D21140, }; ===== drivers/net/tulip/tulip_core.c 1.48 vs edited ===== --- 1.48/drivers/net/tulip/tulip_core.c Tue Aug 19 22:53:17 2003 +++ edited/drivers/net/tulip/tulip_core.c Wed Sep 3 11:42:48 2003 @@ -191,10 +191,17 @@ /* RS7112 */ { "Conexant LANfinity", 256, 0x0001ebef, HAS_MII | HAS_ACPI, tulip_timer }, + + /* HP_D21140 */ + { "HSC 100BaseTX Workstation single port (Digital DS21140 Tulip)", 128, + 0x0001ebef, HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_PCI_MWI + | HAS_SWAPPED_SEEPROM | NEEDS_FAKE_MEDIA_TABLE, tulip_timer }, + }; static struct pci_device_id tulip_pci_tbl[] = { + { 0x1011, 0x0009, 0x103c, 0x1062, 0, 0, HP_D21140 }, { 0x1011, 0x0009, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DC21140 }, { 0x1011, 0x0019, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DC21143 }, { 0x11AD, 0x0002, PCI_ANY_ID, PCI_ANY_ID, 0, 0, LC82C168 }, @@ -1459,9 +1466,10 @@ int sa_offset = 0; int ee_addr_size = tulip_read_eeprom(ioaddr, 0xff, 8) & 0x40000 ? 8 : 6; - for (i = 0; i < sizeof(tp->eeprom)/2; i++) - ((u16 *)ee_data)[i] = - le16_to_cpu(tulip_read_eeprom(ioaddr, i, ee_addr_size)); + for (i = 0; i < sizeof(tp->eeprom)/2; i++) { + u16 data = tulip_read_eeprom(ioaddr, i, ee_addr_size); + ((u16 *)ee_data)[i] = (tp->flags & HAS_SWAPPED_SEEPROM) ? data : le16_to_cpu(data); + } /* DEC now has a specification (see Notes) but early board makers just put the address in the first EEPROM locations. */ ===== drivers/parisc/dino.c 1.10 vs edited ===== --- 1.10/drivers/parisc/dino.c Sun Aug 24 06:50:06 2003 +++ edited/drivers/parisc/dino.c Wed Sep 3 11:48:51 2003 @@ -401,23 +401,7 @@ { int irq; - /* - * Perform a binary search on set bits. - * `Less than Fatal' and PS2 interrupts aren't supported. - */ - if (mask & 0xf) { - if (mask & 0x3) { - irq = (mask & 0x1) ? 0 : 1; /* PCI INT A, B */ - } else { - irq = (mask & 0x4) ? 2 : 3; /* PCI INT C, D */ - } - } else { - if (mask & 0x30) { - irq = (mask & 0x10) ? 4 : 5; /* PCI INT E, F */ - } else { - irq = (mask & 0x40) ? 6 : 10; /* GSC, RS232 */ - } - } + irq = __ffs(mask); mask &= ~(1<dev)); struct resource *res; + char name[128]; + int size; res = &dino_dev->hba.lmmio_space; res->flags = IORESOURCE_MEM; + size = snprintf(name, sizeof(name), "Dino LMMIO (%s)", bus->dev->bus_id); + res->name = kmalloc(size+1, GFP_KERNEL); + if(res->name) + strcpy((char *)res->name, name); + else + res->name = dino_dev->hba.lmmio_space.name; + if (ccio_allocate_resource(dino_dev->hba.dev, res, _8MB, (unsigned long) 0xfffffffff0000000UL | _8MB, @@ -521,7 +514,7 @@ ** Set Latency Timer to 0xff (not a shared bus) ** Set CACHELINE_SIZE. */ - dino_cfg_write(dev->bus, dev->devfn, PCI_CACHE_LINE_SIZE, 16, 0xff00 | L1_CACHE_BYTES/4); + dino_cfg_write(dev->bus, dev->devfn, PCI_CACHE_LINE_SIZE, 2, 0xff00 | L1_CACHE_BYTES/4); /* ** Program INT_LINE for card-mode devices. @@ -532,13 +525,14 @@ ** "-1" converts INTA-D (1-4) to PCIINTA-D (0-3) range. ** The additional "-1" adjusts for skewing the IRQ<->slot. */ - dino_cfg_read(dev->bus, dev->devfn, PCI_INTERRUPT_PIN, 8, &irq_pin); + dino_cfg_read(dev->bus, dev->devfn, PCI_INTERRUPT_PIN, 1, &irq_pin); + printk("DINO CONFIG READ GIVES irq_pin %d\n", irq_pin); dev->irq = (irq_pin + PCI_SLOT(dev->devfn) - 1) % 4 ; /* Shouldn't really need to do this but it's in case someone tries ** to bypass PCI services and look at the card themselves. */ - dino_cfg_write(dev->bus, dev->devfn, PCI_INTERRUPT_LINE, 8, dev->irq); + dino_cfg_write(dev->bus, dev->devfn, PCI_INTERRUPT_LINE, 1, dev->irq); } @@ -818,8 +812,15 @@ { struct dino_device *dino_dev; // Dino specific control struct const char *version = "unknown"; - const char *name = "Dino"; + const int name_len = 32; + char *name; int is_cujo = 0; + + name = kmalloc(name_len, GFP_KERNEL); + if(name) + snprintf(name, name_len, "Dino %s", dev->dev.bus_id); + else + name = "Dino"; if (is_card_dino(&dev->id)) { version = "3.x (card mode)"; From James.Bottomley@steeleye.com Wed Sep 3 21:07:01 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 03 Sep 2003 16:07:01 -0400 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.6 jejb In-Reply-To: <20030903200300.8B7B7494064@palinux.hppa> References: <20030903200300.8B7B7494064@palinux.hppa> Message-ID: <1062619623.1781.31.camel@mulgrave> On Wed, 2003-09-03 at 16:03, James Bottomley wrote: > CVSROOT: /var/cvs > Module name: linux-2.6 > Changes by: jejb 03/09/03 14:03:00 > > Modified files: > . : Makefile > drivers/parisc : ccio-dma.c dino.c > > Log message: > Add card mode dino support for machines with a CCIO. > > This is rather simplistic: basically it simply tries to expand the > existing ccio window by the dino card mode size (currently 8MB). This could > easily fail if there's no room on either side. > > Unfortunately, the correct fix (to reprogram the ccio to take into account > card mode dinos before beginning bus scanning) is rather complex. > > Also fixed the allocation failure case to delete the devices on the bus > so drivers don't try attaching to them. Index: ccio-dma.c =================================================================== RCS file: /var/cvs/linux-2.6/drivers/parisc/ccio-dma.c,v retrieving revision 1.3 diff -u -p -r1.3 ccio-dma.c --- ccio-dma.c 2 Sep 2003 18:42:42 -0000 1.3 +++ ccio-dma.c 3 Sep 2003 19:59:34 -0000 @@ -1534,13 +1534,74 @@ static void __init ccio_init_resources(s (unsigned long)&ioc->ioc_hpa->io_io_low_hv); } -static void expand_ioc_area(struct ioc *ioc, unsigned long size, - unsigned long min, unsigned long max, unsigned long align) +static int expand_resource(struct resource *res, unsigned long size, + unsigned long align) { -#ifdef NASTY_HACK_FOR_K_CLASS - __raw_writel(0xfffff600, (unsigned long)&(ioc->ioc_hpa->io_io_high)); - ioc->mmio_region[0].end = 0xf5ffffff; -#endif + struct resource *temp_res; + unsigned long start = res->start; + unsigned long end ; + + /* see if we can expand above */ + end = (res->end + size + align - 1) & ~(align - 1);; + + temp_res = __request_region(res->parent, res->end, end - res->end, + "expansion"); + if(!temp_res) { + /* now try below */ + start = ((res->start - size + align) & ~(align - 1)) - align; + end = res->end; + temp_res = __request_region(res->parent, start, size, + "expansion"); + if(!temp_res) { + return -ENOMEM; + } + } + release_resource(temp_res); + temp_res = res->parent; + release_resource(res); + res->start = start; + res->end = end; + + /* This could be caused by some sort of race. Basically, if + * this tripped something stole the region we just reserved + * and then released to check for expansion */ + BUG_ON(request_resource(temp_res, res) != 0); + + return 0; +} + +static void expand_ioc_area(struct resource *parent, struct ioc *ioc, + unsigned long size, unsigned long min, + unsigned long max, unsigned long align) +{ + if(ioc == NULL) + /* no IOC, so nothing to expand */ + return; + + if (expand_resource(parent, size, align) != 0) { + printk(KERN_ERR "Unable to expand %s window by 0x%lx\n", + parent->name, size); + return; + } + + /* OK, we have the memory, now expand the window */ + if (parent == &ioc->mmio_region[0]) { + __raw_writel(((parent->start)>>16) | 0xffff0000, + (unsigned long)&(ioc->ioc_hpa->io_io_low)); + __raw_writel(((parent->end)>>16) | 0xffff0000, + (unsigned long)&(ioc->ioc_hpa->io_io_high)); + } else if (parent == &ioc->mmio_region[1]) { + __raw_writel(((parent->start)>>16) | 0xffff0000, + (unsigned long)&(ioc->ioc_hpa->io_io_low_hv)); + __raw_writel(((parent->end)>>16) | 0xffff0000, + (unsigned long)&(ioc->ioc_hpa->io_io_high_hv)); + } else { + /* This should be impossible. It means + * expand_ioc_area got called with a resource that + * didn't belong to the ioc + */ + BUG(); + } } static struct resource *ccio_get_resource(struct ioc* ioc, @@ -1574,7 +1635,7 @@ int ccio_allocate_resource(const struct alignf_data)) return 0; - expand_ioc_area(ioc, size, min, max, align); + expand_ioc_area(parent, ioc, size, min, max, align); return allocate_resource(parent, res, size, min, max, align, alignf, alignf_data); } Index: dino.c =================================================================== RCS file: /var/cvs/linux-2.6/drivers/parisc/dino.c,v retrieving revision 1.3 diff -u -p -r1.3 dino.c --- dino.c 3 Sep 2003 16:51:12 -0000 1.3 +++ dino.c 3 Sep 2003 19:59:36 -0000 @@ -480,7 +480,18 @@ dino_card_setup(struct pci_bus *bus, uns (unsigned long) 0xfffffffff0000000UL | _8MB, 0xffffffffffffffffUL &~ _8MB, _8MB, NULL, NULL) < 0) { - printk(KERN_WARNING "Dino: Failed to allocate memory region\n"); + struct list_head *ln, *tmp_ln; + + printk(KERN_ERR "Dino: cannot attach bus %s\n", + bus->dev->bus_id); + /* kill the bus, we can't do anything with it */ + list_for_each_safe(ln, tmp_ln, &bus->devices) { + struct pci_dev *dev = pci_dev_b(ln); + + list_del(&dev->global_list); + list_del(&dev->bus_list); + } + return; } bus->resource[1] = res; @@ -526,7 +537,6 @@ dino_card_fixup(struct pci_dev *dev) ** The additional "-1" adjusts for skewing the IRQ<->slot. */ dino_cfg_read(dev->bus, dev->devfn, PCI_INTERRUPT_PIN, 1, &irq_pin); - printk("DINO CONFIG READ GIVES irq_pin %d\n", irq_pin); dev->irq = (irq_pin + PCI_SLOT(dev->devfn) - 1) % 4 ; /* Shouldn't really need to do this but it's in case someone tries From rscholz@hrzpub.tu-darmstadt.de Thu Sep 4 12:57:31 2003 From: rscholz@hrzpub.tu-darmstadt.de (Ruediger Scholz) Date: Thu, 04 Sep 2003 13:57:31 +0200 Subject: [parisc-linux] Kernel crash with 2.6.0-test4-pa8 on 715/100 Message-ID: <3F5728AB.3040501@hrzpub.tu-darmstadt.de> This is a multi-part message in MIME format. --------------030807030904080702090800 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi there, I tried to boot 2.6.0-test4-pa8 on my HP 715/100, but it crashed right after the message "Freeing unused kernel memory...". I'm using debian testing with devfs and gcc-3.3.1. I think the pb is devfs, so I will try to boot a kernel without it. Bootlog is attached, Config, System.map is here: http://rscholz.bluehash.de/parisc Greetings, Ruediger --------------030807030904080702090800 Content-Type: text/plain; name="gandalf-2.6.0-test4-pa8.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gandalf-2.6.0-test4-pa8.log" ---------------------------------------------------------------------------- BootRom Version 1.6 Memory Size: 128 MB ---------------------------------------------------------------------------- (c) Copyright 1990-1994, Hewlett-Packard Company. All rights reserved Press to stop boot sequence. ---------------------------------------------------------------------------- Command Description ------- ----------- Auto [boot|search] [on|off] Set/show auto mode Boot [pri|alt [isl]] Boot from primary or alternate path Boot [scsi|eisa.[.]] [isl] Boot from SCSI or EISA Boot lan[.] [install] [isl] Boot from LAN Chassis [on|off] Set/show chassis codes display mode DefaultSS Reboot and set EEPROM to default values Diagnostic [on|off] Set/show diagnostic boot mode Fastboot [on|off] Set/show fast boot mode Help Show this command menu Information Show system information LanAddress Show LAN station addresses Monitor [[.]] Set/show graphics monitor type (=graphics|graphics_<1|2>) Path [pri|alt [[.]]] Set/show boot source path (=lan|scsi|eisa.) Path [console [[.]]] Set/show boot console path (=| =rs232|rs232_2 =.. =graphics|graphics_<1|2> =) Path [keyboard [hil|ps2]] Set/show boot keyboard path Pim [hpmc|toc|lpmc] Show PIM info Search [ipl] [scsi|eisa] Show potential boot devices Search [ipl] [lan [install]] Show potential boot LAN devices Secure [on|off] Set/show security mode ---------------------------------------------------------------------------- BOOT_ADMIN> bo pri ipl Attempting to boot. Loading Initial Program Loader IPL successfully loaded Booting palo ipl 1.2 root@b2000 Tue Jan 14 13:13:07 MST 2003 Partition Start(MB) End(MB) Id Type 1 1 22 f0 Palo 2 23 64 83 ext2 3 65 194 82 swap 4 195 2046 83 ext2 PALO(F0) partition contains: 0/vmlinux32 3223985 bytes @ 0x48000 Information: No console specified on kernel command line. This is normal. PALO will choose the console currently used by firmware (serial).Current command line: 2/vmlinux root=/dev/sda4 HOME=/ devfs=mount console=ttyS0 TERM=vt102 0: 2/vmlinux 1: root=/dev/sda4 2: HOME=/ 3: devfs=mount 4: console=ttyS0 5: TERM=vt102 Edit which field? (or 'b' to boot with this command line)? 0 2/vmlinux-2.6.0 Current command line: 2/vmlinux-2.6.0 root=/dev/sda4 HOME=/ devfs=mount console=ttyS0 TERM=vt102 0: 2/vmlinux-2.6.0 1: root=/dev/sda4 2: HOME=/ 3: devfs=mount 4: console=ttyS0 5: TERM=vt102 Edit which field? (or 'b' to boot with this command line)? b Command line for kernel: 'root=/dev/sda4 HOME=/ devfs=mount console=ttyS0 TERM=vt102 palo_kernel=2/vmlinux-2.6.0' Selected kernel: /vmlinux-2.6.0 from partition 2 ELF32 executable Entry 00100000 first 00100000 n 3 Segment 0 load 00100000 size 2214104 mediaptr 0x1000 Segment 1 load 0031e000 size 356536 mediaptr 0x21e000 Segment 2 load 00378000 size 323711 mediaptr 0x276000 Branching to kernel entry point 0x00100000. If this is the last message you see, you may need to switch your console. This is a common symptom -- search the FAQ and mailing list at parisc-linux.org Linux version 2.6.0-test4-pa8 (ruediger@gandalf) (gcc-Version 3.3.1 20030626 (Debian prerelease)) #1 Wed Sep 3 13:23:29 CEST 2003 FP[0] enabled: Rev 1 Model 13 The 32-bit Kernel has started... Determining PDC firmware type: Snake. model 000060b0 00000481 00000000 00000000 77b661a7 00000000 00000004 00000072 00000072 vers 0000000b model 9000/715 Total Memory: 128 Mb pagetable_init On node 0 totalpages: 32768 DMA zone: 32768 pages, LIFO batch:8 Normal zone: 0 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 Building zonelist for node : 0 Kernel command line: root=/dev/sda4 HOME=/ devfs=mount console=ttyS0 TERM=vt102 palo_kernel=2/vmlinux-2.6.0 PID hash table entries: 16 (order 4: 128 bytes) Console: colour dummy device 160x64 Calibrating delay loop... 99.73 BogoMIPS Memory: 126480k available Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) -> /dev -> /dev/console -> /root POSIX conformance testing by UNIFIX Initializing RT netlink socket EISA bus registered Searching for devices... Found devices: 1. Coral SGC Graphics (10) at 0xf4000000 [0], versions 0x4, 0x0, 0x77 2. Mirage GSC Builtin Graphics (10) at 0xf8000000 [1], versions 0x13, 0x0, 0x85 3. Mirage Core BA (11) at 0xf0100000 [2], versions 0x29, 0x0, 0x81 4. Mirage Core SCSI (10) at 0xf0106000 [2/0/1], versions 0x29, 0x0, 0x82 5. Mirage Core LAN (802.3) (10) at 0xf0107000 [2/0/2], versions 0x29, 0x0, 0x8a 6. Mirage Core RS-232 (10) at 0xf0105000 [2/0/4], versions 0x29, 0x0, 0x8c 7. Mirage Core Centronics (10) at 0xf0102000 [2/0/6], versions 0x29, 0x0, 0x74 8. Mirage Audio (10) at 0xf0104000 [2/0/8], versions 0x29, 0x0, 0x7b 9. Mirage Core PC Floppy (10) at 0xf010a000 [2/0/10], versions 0x29, 0x0, 0x83 10. Mirage Core PS/2 Port (10) at 0xf0108000 [2/0/11], versions 0x29, 0x0, 0x84 11. Mirage Core PS/2 Port (10) at 0xf0108100 [2/0/12], versions 0x29, 0x0, 0x84 12. Mirage Wax BA (11) at 0xf0200000 [5], versions 0x13, 0x0, 0x8e 13. Mirage 100 Wax HIL (10) at 0xf0201000 [5/0/1], versions 0x13, 0x0, 0x73 14. Mirage Wax RS-232 (10) at 0xf0202000 [5/0/2], versions 0x13, 0x0, 0x8c 15. Mirage 100 (0) at 0xfffbe000 [8], versions 0x60b, 0x0, 0x4 16. Memory (1) at 0xfffbf000 [9], versions 0x4b, 0x0, 0x9 CPU(s): 1 x PA7100LC (PCX-L) at 100.000000 MHz Lasi version 0 at 0xf0100000 found. LED display at f00e0000 registered Wax at 0xf0200000 found. BIO: pool of 256 setup, 14Kb (56 bytes/bio) biovec pool[0]: 1 bvecs: 244 entries (12 bytes) biovec pool[1]: 4 bvecs: 244 entries (48 bytes) biovec pool[2]: 16 bvecs: 244 entries (192 bytes) biovec pool[3]: 64 bvecs: 244 entries (768 bytes) biovec pool[4]: 128 bvecs: 122 entries (1536 bytes) biovec pool[5]: 256 bvecs: 61 entries (3072 bytes) SCSI subsystem initialized STI GSC/PCI core graphics driver Version 0.9a STI byte mode ROM at f4000000, hpa at f4000000 STI id 2bcb015a-9a02587, conforms to spec rev. 8.04 STI device: HPA4071A STI word mode ROM at f0024000, hpa at f8000000 STI id 2b4ded6d-40a00499, conforms to spec rev. 8.04 STI device: HPA208LC1024 fb0: stifb 1280x1024-8 frame buffer device, id: 2bcb015a, mmio: 0xf4100000 fb1: stifb 1024x768-8 frame buffer device, id: 2b4ded6d, mmio: 0xf8100000 Console: switching to colour frame buffer device 160x64 pty: 256 Unix98 ptys configured Journalled Block Device driver loaded devfs: v1.22 (20021013) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x1 Gecko-style soft power switch enabled. lp: driver loaded but no devices found Generic RTC Driver v1.07 Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing enabled ttyS0 at MMIO 0xf0105800 (irq = 90) is a 16550A ttyS1 at MMIO 0xf0202800 (irq = 121) is a 16550A parport_init_chip: initialize bidirectional-mode. parport0: PC-style at 0xf0102800, irq 88 [PCSPP,TRISTATE] lp0: using parport0 (interrupt-driven). RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) Found i82596 at 0xf0107000, IRQ 87 eth0: 82596 at 0xf0107000, 08 00 09 7A DC 08 IRQ 87. 82596.c $Revision: 1.29 $ 53c700: Version 2.8 By James.Bottomley@HansenPartnership.com scsi0: 53c710 rev 2 scsi0 : LASI SCSI 53c700 Using anticipatory scheduling elevator scsi0: (2:0) Synchronous at offset 8, period 100ns Vendor: PLEXTOR Model: CD-ROM PX-20TS Rev: 1.01 Type: CD-ROM ANSI SCSI revision: 02 scsi0: (3:0) Synchronous at offset 8, period 100ns Vendor: SEAGATE Model: ST32430N Rev: HP04 Type: Direct-Access ANSI SCSI revision: 02 scsi0: (3:0) Enabling Tag Command Queuing SCSI device sda: 4194685 512-byte hdwr sectors (2148 MB) SCSI device sda: drive cache: write back /dev/scsi/host0/bus0/target3/lun0: p1 p2 p3 p4 Attached scsi disk sda at scsi0, channel 0, id 3, lun 0 sr0: scsi-1 drive Uniform CD-ROM driver Revision: 3.12 Attached scsi generic sg0 at scsi0, channel 0, id 2, lun 0, type 5 Attached scsi generic sg1 at scsi0, channel 0, id 3, lun 0, type 0 Console: switching to colour frame buffer device 160x64 mice: PS/2 mouse device common for all mice Keyboard initialization sequence failled input: PS/2 keyboard port at 0xf0108000 (irq 69) found and attached input: PS/2 mouse port at 0xf0108100 (irq 69) found and attached HP SDC: HP SDC at 0xf0201000, IRQ 126 (NMI IRQ 125) HP SDC: New style SDC HP SDC: Revision: 1820-4784 HP SDC: TI SN76494 beeper present HP SDC: OKI MSM-58321 BBRTC present HP SDC: Spunking the self test register to force PUP on next firmware reset. oprofile: using timer interrupt. NET4: Linux TCP/IP 1.0 for NET4.0 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 16384) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Mounted devfs on /dev Freeing unused kernel memory: 320k freed Stack Dump: 10558758: 10558758 0000000e 10558340 10320010 10558748: 10378fb8 00000001 00000000 00000000 10558738: 00000000 00007b94 00000297 10133bd0 10558728: 00000000 00000000 0000003a 000001db 10558718: 10558340 10335810 00000000 105583c0 10558708: 0000001a 00000000 00000b98 00000000 105586f8: 10592288 00000050 105586d4 10106318 105586e8: 103f0aec ffffffdd 103f0810 103f0810 105586d8: 0000000e 105586d0 103f259c 105586c8 105586c8: 105586c8 00000001 ffffffff 00000000 105586b8: 100df4e0 00000001 10570e00 10127688 105586a8: 103f0aec ffffffdd 103f0810 103f0810 10558698: 0000000e 1032e088 00000b00 00000008 10558688: 00000002 ffffffdd 103f0810 102f7000 10558678: 105583a8 00000001 100a4d00 10127424 10558668: 10592200 00000000 10592200 10584060 10558658: 00000000 00000000 10320080 80000000 10558648: 00000000 103ca010 00000002 100de370 10558638: 00000000 105993cf 10558614 10107254 10558628: 1010d310 00000000 00000000 00000000 10558618: 00000000 00000000 10320080 80000000 10558608: 00000000 103ca010 00000002 100ad640 105585f8: 10558388 100be800 00000001 1010a088 105585e8: 00000001 00000001 100a4d00 00000000 105585d8: 0000000f 0000190e 103d09b8 0000190e 105585c8: 0000192c 103cf810 10558500 100a4d00 105585b8: 00000000 105583a8 00000001 1010a068 105585a8: 00000000 00000000 00000001 00000001 10558598: 0000000f 0000192c 00000b98 00000000 10558588: 48930130 0000000e 10320010 00000000 10558578: 105678e0 00000000 00000008 101fa024 10558568: 101fa020 00000000 00000000 00000000 10558558: 00000000 00000000 00000000 00000000 10558548: 00000000 00000000 00000000 00000000 10558538: 41000000 00000000 40800000 00000000 10558528: 40000000 00000000 40000000 7fffffff 10558518: 41800000 00000000 40200000 00000000 10558508: 40200000 00000000 40300000 00000000 105584f8: 41000000 00000000 40800000 7fffffff 105584e8: 7fffffff 00000000 41000000 7fffffff 105584d8: 7fffffff 00000000 40800000 00000000 105584c8: 41000000 7fffffff 7fffffff 00000000 105584b8: 00000000 00000010 00000010 00000000 105584a8: 41800000 00000000 00000000 00000000 10558498: 00000000 ffffffff 7f7fffff ffffffff 10558488: 7f7fffff 7fffffff 7fffffff 00000000 10558478: 40800000 00000000 00000000 00000000 10558468: 00000000 00000000 00000000 00000000 10558458: 00000000 00000000 00000000 00000000 10558448: 00000000 00000000 000d081f 101fad90 10558438: 105583c0 00000005 00000b00 1031e010 10558428: 1033c528 00000002 105582cc 00000002 10558418: 10110cc0 00000501 00000000 00000001 10558408: 00000000 00000002 f000b858 f0000704 105583f8: 00000001 105582cc 00000000 10378fb8 105583e8: 10320010 103cf810 100b05a0 00000002 105583d8: 00000002 00000008 00000b00 1032e088 105583c8: 101fa01c 1033c010 0004ff0f 00000000 105583b8: 10558340 00000060 00000000 101fa01c 105583a8: 003cf6c0 f0105800 003ca380 105ded60 10558398: 105e0c60 00000000 105dedcc 105ded60 10558388: 105e0c60 17ff57a0 105dedcc f0000704 10558378: 1032e088 00000b00 100b5820 00000001 10558368: 00000002 100b05a0 103cf810 10320010 Kernel addresses on the stack: [<1011f4cc>] scheduler_tick+0x84/0x454 [<10106068>] parisc_terminate+0x60/0xb4 [<10133bd0>] rcu_process_callbacks+0x8c/0xf0 [<10106318>] handle_interruption+0x25c/0x564 [<10127688>] tasklet_action+0x7c/0xdc [<10127424>] do_softirq+0xf0/0xf8 [<10107254>] do_cpu_irq_mask+0x88/0xfc [<1010a088>] intr_check_sig+0x0/0xc [<1010a068>] intr_return+0x0/0x14 [<101fa024>] init_dev+0x5c/0x4c8 [<10378fb8>] start_kernel+0x4/0x200 [<101fa01c>] init_dev+0x54/0x4c8 [<101fab10>] tty_open+0x90/0x394 [<10165560>] do_lookup+0xb0/0xc8 [<10160fe8>] chrdev_open+0xac/0x144 [<10157eb0>] get_empty_filp+0x60/0x124 [<101b0f5c>] devfs_open+0xa0/0xd0 [<101564e4>] dentry_open+0x12c/0x1b0 [<101563b0>] filp_open+0x68/0x70 [<10123c2c>] printk+0x140/0x1b4 [<1015684c>] sys_open+0x70/0xb0 [<101002b0>] init+0x5c/0x150 [<10109c5c>] ret_from_kernel_thread+0x1c/0x24 Kernel Fault: Code=26 regs=105583c0 (Addr=00000b98) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001111111100001111 Not tainted r00-03 00000000 1033c010 101fa01c 1032e088 r04-07 00000b00 00000008 00000002 00000002 r08-11 100b05a0 103cf810 10320010 10378fb8 r12-15 00000000 105582cc 00000001 f0000704 r16-19 f000b858 00000002 00000000 00000001 r20-23 00000000 00000501 10110cc0 00000002 r24-27 105582cc 00000002 1033c528 1031e010 r28-31 00000b00 00000005 105583c0 101fad90 sr0-3 00000000 00000000 00000000 00000000 sr4-7 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: 101fa020 101fa024 IIR: 48930130 ISR: 00000000 IOR: 00000b98 CPU: 0 CR30: 10558000 CR31: 1036d000 ORIG_R28: 105678e0 IAOQ[0]: init_dev+0x58/0x4c8 IAOQ[1]: init_dev+0x5c/0x4c8 RP(r2): init_dev+0x54/0x4c8 --------------030807030904080702090800-- From acme@conectiva.com.br Thu Sep 4 14:53:15 2003 From: acme@conectiva.com.br (Arnaldo Carvalho de Melo) Date: Thu, 4 Sep 2003 10:53:15 -0300 Subject: [parisc-linux] [PATCH] add MODULE_ALIAS_LDISC to asm-parisc/termios.h Message-ID: <20030904135315.GB2411@conectiva.com.br> Hi, I noticed this one on parisc64 with the latest bk tree: CC [M] drivers/char/n_hdlc.o drivers/char/n_hdlc.c:985: parse error before numeric constant drivers/char/n_hdlc.c:985: warning: type defaults to `int' in declaration of `MODULE_ALIAS_LDISC' drivers/char/n_hdlc.c:985: warning: function declaration isn't a prototype drivers/char/n_hdlc.c:985: warning: data definition has no type or storage classmake[2]: *** [drivers/char/n_hdlc.o] Error 1 make[1]: *** [drivers/char] Error 2 make: *** [drivers] Error 2 This patch makes it compile, doing the same thing that was done to include/asm-i386/termios.h, please see if this is acceptable, if it is I can provide the same patch for all the other arches. - Arnaldo ===== include/asm-parisc/termios.h 1.4 vs edited ===== --- 1.4/include/asm-parisc/termios.h Sat Jul 20 06:52:25 2002 +++ edited/include/asm-parisc/termios.h Thu Sep 4 13:43:57 2003 @@ -101,6 +101,8 @@ #define user_termios_to_kernel_termios(k, u) copy_from_user(k, u, sizeof(struct termios)) #define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct termios)) +#define MODULE_ALIAS_LDISC(ldisc) \ + MODULE_ALIAS("tty-ldisc-" __stringify(ldisc)) #endif /* __KERNEL__ */ #endif /* _PARISC_TERMIOS_H */ From willy@debian.org Thu Sep 4 15:06:15 2003 From: willy@debian.org (Matthew Wilcox) Date: Thu, 4 Sep 2003 15:06:15 +0100 Subject: [parisc-linux] Kernel crash with 2.6.0-test4-pa8 on 715/100 In-Reply-To: <3F5728AB.3040501@hrzpub.tu-darmstadt.de> References: <3F5728AB.3040501@hrzpub.tu-darmstadt.de> Message-ID: <20030904140615.GN18654@parcelfarce.linux.theplanet.co.uk> On Thu, Sep 04, 2003 at 01:57:31PM +0200, Ruediger Scholz wrote: > I tried to boot 2.6.0-test4-pa8 on my HP 715/100, but it crashed right > after the message "Freeing unused kernel memory...". I'm using debian > testing with devfs and gcc-3.3.1. > I think the pb is devfs, so I will try to boot a kernel without it. > Bootlog is attached, Config, System.map is here: > http://rscholz.bluehash.de/parisc I'm seeing the same thing on my 712 without devfs. Not sure what the problem is, and I'm having a hard time getting that box back up as it has a broken root filesystem (damn tar for being linked against libpthread!) I decoded what's going on a little bit. We're calling drivers/char/tty_io.c::init_dev() with a `driver' variable set to 0x00000b00. Quite what's gone wrong to get this to happen, I'm not sure. -- "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 Sep 4 15:19:28 2003 From: willy@debian.org (Matthew Wilcox) Date: Thu, 4 Sep 2003 15:19:28 +0100 Subject: [parisc-linux] Re: [PATCH] add MODULE_ALIAS_LDISC to asm-parisc/termios.h In-Reply-To: <20030904135315.GB2411@conectiva.com.br> References: <20030904135315.GB2411@conectiva.com.br> Message-ID: <20030904141928.GO18654@parcelfarce.linux.theplanet.co.uk> On Thu, Sep 04, 2003 at 10:53:15AM -0300, Arnaldo Carvalho de Melo wrote: > This patch makes it compile, doing the same thing that was done to > include/asm-i386/termios.h, please see if this is acceptable, if it is I can > provide the same patch for all the other arches. if it's the same for all arches, why not put it in ? -- "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 Thu Sep 4 15:24:41 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 04 Sep 2003 10:24:41 -0400 Subject: [parisc-linux] [PATCH] add MODULE_ALIAS_LDISC to asm-parisc/termios.h In-Reply-To: <20030904135315.GB2411@conectiva.com.br> References: <20030904135315.GB2411@conectiva.com.br> Message-ID: <1062685483.1829.6.camel@mulgrave> On Thu, 2003-09-04 at 09:53, Arnaldo Carvalho de Melo wrote: > +#define MODULE_ALIAS_LDISC(ldisc) \ > + MODULE_ALIAS("tty-ldisc-" __stringify(ldisc)) These are the strings used to identify the required line discipline module to kmod, aren't they? Since modprobe.conf seems to be generated without much regard for architectures, is there any reason why this definition should differ amongst architectures? I think the answer's "no", so I think this fix should be in linux/termios.h (or somewhere architecture independent). James From jbglaw@lug-owl.de Thu Sep 4 15:26:17 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Thu, 4 Sep 2003 16:26:17 +0200 Subject: [parisc-linux] Kernel crash with 2.6.0-test4-pa8 on 715/100 In-Reply-To: <20030904140615.GN18654@parcelfarce.linux.theplanet.co.uk> References: <3F5728AB.3040501@hrzpub.tu-darmstadt.de> <20030904140615.GN18654@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030904142616.GT14376@lug-owl.de> --acY8GN8fvSPNWryy Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2003-09-04 15:06:15 +0100, Matthew Wilcox wrote in message <20030904140615.GN18654@parcelfarce.linux.theplanet.co.uk>: > On Thu, Sep 04, 2003 at 01:57:31PM +0200, Ruediger Scholz wrote: > > I tried to boot 2.6.0-test4-pa8 on my HP 715/100, but it crashed right= =20 > > after the message "Freeing unused kernel memory...". I'm using debian= =20 > > testing with devfs and gcc-3.3.1. > > I think the pb is devfs, so I will try to boot a kernel without it. > > Bootlog is attached, Config, System.map is here:=20 > > http://rscholz.bluehash.de/parisc >=20 > I'm seeing the same thing on my 712 without devfs. Not sure what the > problem is, and I'm having a hard time getting that box back up as it has > a broken root filesystem (damn tar for being linked against libpthread!) Hmmm... My 712/60 works flawlessly: jbglaw@hp712-1:~$ uname -a Linux hp712-1 2.6.0-test4-pa8 #1 Wed Sep 3 19:16:42 CEST 2003 parisc GNU/Li= nux jbglaw@hp712-1:~$ uptime 16:22:22 up 16:58, 1 user, load average: 0.23, 0.05, 0.02 However, I've not touched the keyboard since the box is standing somewhere in my cellar and only used by network... Want to see my =2Econfig? 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)); --acY8GN8fvSPNWryy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/V0uIHb1edYOZ4bsRAoBEAKCODwI871/Z9tX7ZmQ+9x6WSXbcNACcD7Fs SzUHvJ+qeFJ1/H8SGCkRfgE= =XPeU -----END PGP SIGNATURE----- --acY8GN8fvSPNWryy-- From rscholz@hrzpub.tu-darmstadt.de Thu Sep 4 20:39:31 2003 From: rscholz@hrzpub.tu-darmstadt.de (Ruediger Scholz) Date: Thu, 04 Sep 2003 21:39:31 +0200 Subject: [parisc-linux] ksoftirqd is using over 90% CPU (?!) Message-ID: <3F5794F3.4020507@hrzpub.tu-darmstadt.de> Hi there, just another question: I just ran top to look what processe are running and noticed that ksoftirqd is up to 98% CPU time. I remember that there was a problem that s.th in the kernel eats up a lot oft CPU time. Wasn't it solved? Ruediger From joel.soete@tiscali.be Thu Sep 4 21:25:56 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Thu, 04 Sep 2003 20:25:56 +0000 Subject: [parisc-linux] ksoftirqd is using over 90% CPU (?!) In-Reply-To: <3F5794F3.4020507@hrzpub.tu-darmstadt.de> References: <3F5794F3.4020507@hrzpub.tu-darmstadt.de> Message-ID: <3F579FD4.9020303@tiscali.be> Ruediger Scholz wrote: > Hi there, > > just another question: I just ran top to look what processe are > running and noticed that ksoftirqd is up to 98% CPU time. I remember > that there was a problem that s.th in the kernel eats up a lot oft CPU > time. Wasn't it solved? > > Ruediger > > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > Hi, Sorry if i do not follow your thread but this looks like a very old pb. Update your kernel (I do not remember exactly what is installed with woody but all later) would help. hth, Joel From joel.soete@tiscali.be Thu Sep 4 21:35:56 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Thu, 04 Sep 2003 20:35:56 +0000 Subject: [parisc-linux] Kernel crash with 2.6.0-test4-pa8 on 715/100 In-Reply-To: <20030904140615.GN18654@parcelfarce.linux.theplanet.co.uk> References: <3F5728AB.3040501@hrzpub.tu-darmstadt.de> <20030904140615.GN18654@parcelfarce.linux.theplanet.co.uk> Message-ID: <3F57A22C.5050902@tiscali.be> Hi Willy, Matthew Wilcox wrote: >On Thu, Sep 04, 2003 at 01:57:31PM +0200, Ruediger Scholz wrote: > > >>I tried to boot 2.6.0-test4-pa8 on my HP 715/100, but it crashed right >>after the message "Freeing unused kernel memory...". I'm using debian >>testing with devfs and gcc-3.3.1. >>I think the pb is devfs, so I will try to boot a kernel without it. >>Bootlog is attached, Config, System.map is here: >>http://rscholz.bluehash.de/parisc >> >> > >I'm seeing the same thing on my 712 without devfs. Not sure what the >problem is, and I'm having a hard time getting that box back up as it has >a broken root filesystem (damn tar for being linked against libpthread!) > > Is that libpthread the cause of your broken fs? Thanks in advance for advise, Joel From joel.soete@tiscali.be Thu Sep 4 21:48:11 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Thu, 04 Sep 2003 20:48:11 +0000 Subject: [parisc-linux] Kernel crash with 2.6.0-test4-pa8 on 715/100 In-Reply-To: <3F5728AB.3040501@hrzpub.tu-darmstadt.de> References: <3F5728AB.3040501@hrzpub.tu-darmstadt.de> Message-ID: <3F57A50B.8050504@tiscali.be> Ruediger Scholz wrote: > Hi there, > > I tried to boot 2.6.0-test4-pa8 on my HP 715/100, but it crashed right > after the message "Freeing unused kernel memory...". I'm using debian > testing with devfs and gcc-3.3.1. > I think the pb is devfs, so I will try to boot a kernel without it. > Bootlog is attached, Config, System.map is here: > http://rscholz.bluehash.de/parisc May I ask you how do you build your .config? I presume that it is a custom one if you tried devfs. hmm isn't it obsolete now? iirc i encounter the same pb with my b2k. I find a work around by accident: removing all kind of console (pdc, serial) make it boot. I tried to obtain a patch for a network console for 2.6 but without success :( Sorry to be not more helpfull but even a toc didn't help to analyse this pb :( Thanks for info, Joel From willy@debian.org Thu Sep 4 22:00:00 2003 From: willy@debian.org (Matthew Wilcox) Date: Thu, 4 Sep 2003 22:00:00 +0100 Subject: [parisc-linux] Kernel crash with 2.6.0-test4-pa8 on 715/100 In-Reply-To: <3F57A22C.5050902@tiscali.be> References: <3F5728AB.3040501@hrzpub.tu-darmstadt.de> <20030904140615.GN18654@parcelfarce.linux.theplanet.co.uk> <3F57A22C.5050902@tiscali.be> Message-ID: <20030904210000.GZ18654@parcelfarce.linux.theplanet.co.uk> On Thu, Sep 04, 2003 at 08:35:56PM +0000, Joel Soete wrote: > Hi Willy, > >I'm seeing the same thing on my 712 without devfs. Not sure what the > >problem is, and I'm having a hard time getting that box back up as it has > >a broken root filesystem (damn tar for being linked against libpthread!) > > > Is that libpthread the cause of your broken fs? no, a 2.4 kernel doesn't have the same problem. -- "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 rscholz@hrzpub.tu-darmstadt.de Thu Sep 4 22:31:11 2003 From: rscholz@hrzpub.tu-darmstadt.de (Ruediger Scholz) Date: Thu, 04 Sep 2003 23:31:11 +0200 Subject: [parisc-linux] ksoftirqd is using over 90% CPU (?!) In-Reply-To: <3F579FD4.9020303@tiscali.be> References: <3F5794F3.4020507@hrzpub.tu-darmstadt.de> <3F579FD4.9020303@tiscali.be> Message-ID: <3F57AF1F.6080404@hrzpub.tu-darmstadt.de> Hi Joel, Joel Soete schrieb: > Hi, > > Sorry if i do not follow your thread but this looks like a very old pb. > Update your kernel (I do not remember exactly what is installed with > woody but all later) would help. Nice try ;) But this happens with kernel 2.4.22-pa3 :-o > > > hth, > Joel > > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > > From joel.soete@tiscali.be Thu Sep 4 22:52:21 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Thu, 04 Sep 2003 21:52:21 +0000 Subject: [parisc-linux] ksoftirqd is using over 90% CPU (?!) In-Reply-To: <3F57AF1F.6080404@hrzpub.tu-darmstadt.de> References: <3F5794F3.4020507@hrzpub.tu-darmstadt.de> <3F579FD4.9020303@tiscali.be> <3F57AF1F.6080404@hrzpub.tu-darmstadt.de> Message-ID: <3F57B415.9080603@tiscali.be> Ruediger Scholz wrote: > Hi Joel, > > Joel Soete schrieb: > >> Hi, >> >> Sorry if i do not follow your thread but this looks like a very old pb. >> Update your kernel (I do not remember exactly what is installed with >> woody but all later) would help. > > > Nice try ;) But this happens with kernel 2.4.22-pa3 :-o Sorry, and the last test i did was 22-pa2 but i didn't notice this pb. (for the moment I am far away from my parisc box :( ). Anyway I think that those 2 info would help pa's hacker's to locate the actual pb ;) Thanks, Joel From carlos@baldric.uwo.ca Thu Sep 4 22:51:27 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Thu, 4 Sep 2003 17:51:27 -0400 Subject: [parisc-linux] Kernel crash with 2.6.0-test4-pa8 on 715/100 In-Reply-To: <20030904210000.GZ18654@parcelfarce.linux.theplanet.co.uk> References: <3F5728AB.3040501@hrzpub.tu-darmstadt.de> <20030904140615.GN18654@parcelfarce.linux.theplanet.co.uk> <3F57A22C.5050902@tiscali.be> <20030904210000.GZ18654@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030904215127.GD3627@systemhalted> On Thu, Sep 04, 2003 at 10:00:00PM +0100, Matthew Wilcox wrote: > On Thu, Sep 04, 2003 at 08:35:56PM +0000, Joel Soete wrote: > > Hi Willy, > > >I'm seeing the same thing on my 712 without devfs. Not sure what the > > >problem is, and I'm having a hard time getting that box back up as it has > > >a broken root filesystem (damn tar for being linked against libpthread!) > > > > > Is that libpthread the cause of your broken fs? > > no, a 2.4 kernel doesn't have the same problem. Signal related? What does the problem look like? c. From carlos@baldric.uwo.ca Thu Sep 4 22:52:52 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Thu, 4 Sep 2003 17:52:52 -0400 Subject: [parisc-linux] ksoftirqd is using over 90% CPU (?!) In-Reply-To: <3F5794F3.4020507@hrzpub.tu-darmstadt.de> References: <3F5794F3.4020507@hrzpub.tu-darmstadt.de> Message-ID: <20030904215252.GE3627@systemhalted> On Thu, Sep 04, 2003 at 09:39:31PM +0200, Ruediger Scholz wrote: > Hi there, > > just another question: I just ran top to look what processe are running > and noticed that ksoftirqd is up to 98% CPU time. I remember that there > was a problem that s.th in the kernel eats up a lot oft CPU time. Wasn't > it solved? > > Ruediger Read the FAQ: http://www.parisc-linux.org/faq/index.html#ksoftirqd c. From willy@debian.org Thu Sep 4 22:54:54 2003 From: willy@debian.org (Matthew Wilcox) Date: Thu, 4 Sep 2003 22:54:54 +0100 Subject: [parisc-linux] Kernel crash with 2.6.0-test4-pa8 on 715/100 In-Reply-To: <20030904215127.GD3627@systemhalted> References: <3F5728AB.3040501@hrzpub.tu-darmstadt.de> <20030904140615.GN18654@parcelfarce.linux.theplanet.co.uk> <3F57A22C.5050902@tiscali.be> <20030904210000.GZ18654@parcelfarce.linux.theplanet.co.uk> <20030904215127.GD3627@systemhalted> Message-ID: <20030904215454.GC18654@parcelfarce.linux.theplanet.co.uk> On Thu, Sep 04, 2003 at 05:51:27PM -0400, Carlos O'Donell wrote: > On Thu, Sep 04, 2003 at 10:00:00PM +0100, Matthew Wilcox wrote: > > no, a 2.4 kernel doesn't have the same problem. > > Signal related? What does the problem look like? i said earlier; tty_open calls init_dev() with a bad `driver' parameter. my WAG i can't verify because fucking GNU link *ls* against libpthread is that /dev/console is screwed up. -- "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 rusty@rustcorp.com.au Fri Sep 5 04:29:48 2003 From: rusty@rustcorp.com.au (Rusty Russell) Date: Fri, 05 Sep 2003 13:29:48 +1000 Subject: [parisc-linux] Re: [PATCH] add MODULE_ALIAS_LDISC to asm-parisc/termios.h In-Reply-To: Your message of "Thu, 04 Sep 2003 15:19:28 +0100." <20030904141928.GO18654@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030905052006.8A97E2C208@lists.samba.org> In message <20030904141928.GO18654@parcelfarce.linux.theplanet.co.uk> you write : > On Thu, Sep 04, 2003 at 10:53:15AM -0300, Arnaldo Carvalho de Melo wrote: > > This patch makes it compile, doing the same thing that was done to > > include/asm-i386/termios.h, please see if this is acceptable, if it is I can > > provide the same patch for all the other arches. > > if it's the same for all arches, why not put it in ? Because I'm stupid? Linus, please apply, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.6.0-test4-bk6/include/asm-i386/termios.h working-2.6.0-test4-bk6-tmp/include/asm-i386/termios.h --- linux-2.6.0-test4-bk6/include/asm-i386/termios.h 2003-09-05 09:16:36.000000000 +1000 +++ working-2.6.0-test4-bk6-tmp/include/asm-i386/termios.h 2003-09-05 13:26:10.000000000 +1000 @@ -101,9 +101,6 @@ struct termio { #define user_termios_to_kernel_termios(k, u) copy_from_user(k, u, sizeof(struct termios)) #define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct termios)) - -#define MODULE_ALIAS_LDISC(ldisc) \ - MODULE_ALIAS("tty-ldisc-" __stringify(ldisc)) #endif /* __KERNEL__ */ #endif /* _I386_TERMIOS_H */ diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.6.0-test4-bk6/include/linux/termios.h working-2.6.0-test4-bk6-tmp/include/linux/termios.h --- linux-2.6.0-test4-bk6/include/linux/termios.h 2001-11-23 06:46:18.000000000 +1100 +++ working-2.6.0-test4-bk6-tmp/include/linux/termios.h 2003-09-05 13:26:24.000000000 +1000 @@ -4,4 +4,6 @@ #include #include +#define MODULE_ALIAS_LDISC(ldisc) \ + MODULE_ALIAS("tty-ldisc-" __stringify(ldisc)) #endif From c.aqeel@caramail.com Fri Sep 5 12:52:15 2003 From: c.aqeel@caramail.com (Aqeel Ahmad Chughtai) Date: Fri, 5 Sep 2003 12:52:15 +0100 Subject: [parisc-linux] Business / Financial Benefit from UK Message-ID: <20030905125130.D22B84830@dsl2.external.hp.com> VERY URGENT & CONFIDENTIAL Mr=2E Aqeel Ahmad Chughtai Aberystwyth=2C UK=2E Email=3A c=2Eaqeel=40caramail=2Ecom Assalamualaikum=2C Kindly Pardon me if this my letter would be an embarrassment to you for I am Mr=2E Aqeel Ahmad Chughtai=2C a Balochistan tribeman writing you from Aberystwyth=2C United Kingdom and I am presently on Political Asylum in the UK where I and several other Balochs sought refuge from the oppressive regime of the Iranian Government=2E I am a council leader for one of the three refugee camps here in Europe=2C represents nearly 12=2C000 Balochs who have never received official refugee status because the EU Parliament only signed the U=2ES=2E Refugee Convention with the stipulation that United Kingdom and other European countries would not recognize non-Europeans as refugees=2E As a result=2C Balochs admitted into the UK have no rights=2C and no International agencies have been able to secure permission from the European Union to provide protection for the refugees=2C hence the UK Government have refused to grant me and others Political Asylum and they have gone further with threat to deport us back to Iran and I know that if this is done I would be killed if I step into Iran just as several students were killed recently during demonstration=2E I work to protect the welfare of displaced Balochs at great personal risk=2E My efforts have raised worldwide awareness of life in the makeshift camps where overcrowding=2C mass poisonings=2C beatings=2C and lack of medical supplies=2C water=2C and electricity cause hundreds of men=2C women=2C and children to die of cold=2C hunger=2C malnutrition=2C and communicable diseases=2E The happy news here is that some public spirited philanthropists who would not want their identities made public called us after the unique and historical London Conference=2C which lasted for two days =28 26th & 27th of April 2003=29 told us that they have deposited the Sum of US$32Million with a Financial Institution in favour of the Balochs who are scattered all over the world and only I and or any person I nominate can claim the money from the Financial company and the money should be used mainly for purchasing of foods=2C pharmaceutical drugs=2C Clothings etc for thousands of our people suffering all over the world=2E I am therefore using this medium to solicit for your assistance=2E Your contacts were obtained by me during my enduring search for a reliable and competent person that would claim this money for us from the company where it was deposited=2E There is a POWER OF ATTORNEY which I would send alongside copies of my National Identity cards =2F Passport to you that would enable you claim the money from the Financial Company on our behalf=2E Upon your agreement and readiness to assist us claim the money =28US$32Million=29 from the Company=2C 20% of the total money would be your share for all your anticipated assistance=2C while 5% would be for any incidental expenses that you might incur in the process of claiming the money and transferring it to your Country=2C while the balance of 75% would be used to purchase Drugs=2C Clothing=2C Foods etc as earlier stated above=2C as I and a council leader of the people would find a way to travel down to your Country to make joint purchases of the above stated items=2E I wish to repeat here that we have unshaken Confidence and trust in you and also wish to remind you of the TOP SECRECY this transaction requires=2C as we expect your positive response through this email address as stated above you can only reach me through this above email as my movement is presently restricted by law covering Asylum Seekers=2C our movements are also restricted from travelling outside this Zone and Country for now=2C but after receipt of your positive response and you wish to discuss with me I might give you a secret telephone number where you can reach me=2E On receiving your positive response we hope to finish this transaction within one week as a lot of our people are dying from diseases and hunger=2E Expecting your URGENT Positive response and thanks in advance=2E Waalaikum salam=2C Mr=2E Aqeel Ahmad Chughtai=09=09=09 From grundler@parisc-linux.org Fri Sep 5 17:45:53 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 5 Sep 2003 10:45:53 -0600 Subject: [parisc-linux] x86 on b2000 In-Reply-To: References: <20030827060516.GA11642@dsl2.external.hp.com> Message-ID: <20030905164553.GB10216@dsl2.external.hp.com> On Thu, Aug 28, 2003 at 02:49:19AM -0400, Chuck Slivkoff wrote: > >I have seen a B2000 with 8 DIMM slots and 6 PCI slots like a C3000. > >This is no prototype - a real production unit. > > Sounds like a B1000 to me. ;-) Essentially, a C3000 with a slower CPU. Yes - you are right thanks, grant From grundler@parisc-linux.org Fri Sep 5 19:26:21 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 5 Sep 2003 12:26:21 -0600 Subject: [parisc-linux] a fast fls also for 2.6? In-Reply-To: <3F5888F3.5060609@tiscali.be> References: <3F58838A.9010203@tiscali.be> <3F5888F3.5060609@tiscali.be> Message-ID: <20030905182621.GC10216@dsl2.external.hp.com> On Fri, Sep 05, 2003 at 01:00:35PM +0000, Joel Soete wrote: > remember me that I also suggest a __fls() in: > sorry - I missed that. > Without any remark, I don't know if you could also be interested to > include it in 2.6. no - becuase fls() and ffs() return the same values for given input. (I see comments in include/asm-ppc/bitops.h to that effect). parisc __ffs costs the same number of cycles regardless of input. (2 cycles per 3 instructions about on PA 2.0 machines). ie there is no advantage to "searching from the top" vs "searching from the bottom" which is what I think the intent of fls() vs ffs(). For generic implementations, this intent is important. What we could do is redefine fls() to also use ffs() and add my comment above. Patch appended. Please test/review and tell me if that should be committed. I haven't tested it yet and the comments in PPC bitops.h could be wrong. thanks, grant Index: include/asm-parisc/bitops.h =================================================================== RCS file: /var/cvs/linux-2.6/include/asm-parisc/bitops.h,v retrieving revision 1.2 diff -u -p -r1.2 bitops.h --- include/asm-parisc/bitops.h 1 Sep 2003 00:30:42 -0000 1.2 +++ include/asm-parisc/bitops.h 5 Sep 2003 18:11:21 -0000 @@ -281,9 +281,14 @@ static __inline__ int ffs(int x) /* * fls: find last bit set. + * + * parisc __ffs costs the same number of cycles regardless of input. + * A similar implementation for __fls() would have no advantage. + * ie there is no advantage to "searching from the top" vs "searching + * from the bottom" which is the intent of fls() vs ffs(). */ -#define fls(x) generic_fls(x) +#define fls(x) ffs(x) /* * hweightN: returns the hamming weight (i.e. the number From joel.soete@tiscali.be Fri Sep 5 20:26:13 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Fri, 05 Sep 2003 19:26:13 +0000 Subject: [parisc-linux] a fast fls also for 2.6? In-Reply-To: <20030905182621.GC10216@dsl2.external.hp.com> References: <3F58838A.9010203@tiscali.be> <3F5888F3.5060609@tiscali.be> <20030905182621.GC10216@dsl2.external.hp.com> Message-ID: <3F58E355.30009@tiscali.be> Grant Grundler wrote: >On Fri, Sep 05, 2003 at 01:00:35PM +0000, Joel Soete wrote: > > >>remember me that I also suggest a __fls() in: >> >> >> > >sorry - I missed that. > > > >>Without any remark, I don't know if you could also be interested to >>include it in 2.6. >> >> > >no - becuase fls() and ffs() return the same values for given input. >(I see comments in include/asm-ppc/bitops.h to that effect). > >parisc __ffs costs the same number of cycles regardless of input. >(2 cycles per 3 instructions about on PA 2.0 machines). >ie there is no advantage to "searching from the top" vs "searching >from the bottom" which is what I think the intent of fls() vs ffs(). >For generic implementations, this intent is important. > >What we could do is redefine fls() to also use ffs() and add >my comment above. Patch appended. Please test/review and tell me >if that should be committed. I haven't tested it yet and the comments >in PPC bitops.h could be wrong. > >thanks, >grant > > >Index: include/asm-parisc/bitops.h >=================================================================== >RCS file: /var/cvs/linux-2.6/include/asm-parisc/bitops.h,v >retrieving revision 1.2 >diff -u -p -r1.2 bitops.h >--- include/asm-parisc/bitops.h 1 Sep 2003 00:30:42 -0000 1.2 >+++ include/asm-parisc/bitops.h 5 Sep 2003 18:11:21 -0000 >@@ -281,9 +281,14 @@ static __inline__ int ffs(int x) > > /* > * fls: find last bit set. >+ * >+ * parisc __ffs costs the same number of cycles regardless of input. >+ * A similar implementation for __fls() would have no advantage. >+ * ie there is no advantage to "searching from the top" vs "searching >+ * from the bottom" which is the intent of fls() vs ffs(). > */ > >-#define fls(x) generic_fls(x) >+#define fls(x) ffs(x) > > /* > * hweightN: returns the hamming weight (i.e. the number > > > My bad, I undurstand that ffs return the index of the first bit set otc fls returning the the index of the last bit set (ie for 1010: ffs would return 2 and fls would return 4)? Sorry for confusion. It was never the less a good exercice ;) Thanks, Joel From grundler@parisc-linux.org Fri Sep 5 20:29:27 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 5 Sep 2003 13:29:27 -0600 Subject: [parisc-linux] a fast fls also for 2.6? In-Reply-To: <20030905182621.GC10216@dsl2.external.hp.com> References: <3F58838A.9010203@tiscali.be> <3F5888F3.5060609@tiscali.be> <20030905182621.GC10216@dsl2.external.hp.com> Message-ID: <20030905192927.GD10216@dsl2.external.hp.com> On Fri, Sep 05, 2003 at 12:26:21PM -0600, Grant Grundler wrote: > > Without any remark, I don't know if you could also be interested to > > include it in 2.6. > > no - becuase fls() and ffs() return the same values for given input. > (I see comments in include/asm-ppc/bitops.h to that effect). James Bottomley privately corrected me. fls() != ffs(). fls() returns most significant bit set. The examples provided: * Note fls(0) = 0, fls(1) = 1, fls(0x80000000) = 32. have the same value for ffs() and fls(). I didn't read the rest. Good examples for showing bit numbering though. I'll work on adding 64-bit support to your __fls() and commit that. sorry for the confusion, grant From joel.soete@tiscali.be Fri Sep 5 20:54:42 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Fri, 05 Sep 2003 19:54:42 +0000 Subject: [parisc-linux] a fast fls also for 2.6? In-Reply-To: <20030905192927.GD10216@dsl2.external.hp.com> References: <3F58838A.9010203@tiscali.be> <3F5888F3.5060609@tiscali.be> <20030905182621.GC10216@dsl2.external.hp.com> <20030905192927.GD10216@dsl2.external.hp.com> Message-ID: <3F58EA02.8040404@tiscali.be> Grant Grundler wrote: >On Fri, Sep 05, 2003 at 12:26:21PM -0600, Grant Grundler wrote: > > >>>Without any remark, I don't know if you could also be interested to >>>include it in 2.6. >>> >>> >>no - becuase fls() and ffs() return the same values for given input. >>(I see comments in include/asm-ppc/bitops.h to that effect). >> >> > >James Bottomley privately corrected me. fls() != ffs(). >fls() returns most significant bit set. > >The examples provided: > * Note fls(0) = 0, fls(1) = 1, fls(0x80000000) = 32. > >have the same value for ffs() and fls(). I didn't read the rest. >Good examples for showing bit numbering though. > >I'll work on adding 64-bit support to your __fls() and commit that. > Thanks a lot :) (it just make me happy to be usefull) > >sorry for the confusion, > Please, don't be sorry, I am frequently the first confusing thought ;) Cheers, Joel From joel.soete@tiscali.be Sat Sep 6 23:33:29 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Sat, 06 Sep 2003 22:33:29 +0000 Subject: [parisc-linux] Re: [parisc-linux-cvs] Re: 2.6.0-test4-pa12 __fls() In-Reply-To: <3F5A4023.9070909@tiscali.be> References: <3F5A4023.9070909@tiscali.be> Message-ID: <3F5A60B9.3050103@tiscali.be> Hi Willy And Grant, > On Fri, Sep 05, 2003 at 11:59:14PM -0600, Grant Grundler wrote: > >/ > kudos to Joel Soete for mangling lamont's __ffs() to produce __fls(). /> >/ > Again, I added 64-bit support. Booted on a500. /> >/ > Didn't test 32-bit but fls_test.c included in above URL works in user space. /> >/ > (162 cycles per loop iteration, 00:29:01 to complete on 400Mhz PA8500). /> > Sorry, but it's clearly broken. > > >/ -#define fls(x) generic_fls(x) /> >/ +static __inline__ unsigned long __fls(unsigned long x) /> >/ +{ /> >/ + unsigned long ret; /> >/ + /> >/ + __asm__( " ldi 1,%1\n" /> >/ +#if BITS_PER_LONG > 32 /> >/ + " extrd,u,*<> %0,63,32,%%r0\n" /> > if any of the bottom 32 bits are set ... > > >/ + " depd,*TR %0,31,32,%0\n" /> > move the bottom 32 bits up into the top 32 bits > > >/ + " addi 32,%1,%1\n" /> > otherwise add 32 > > >/ +#endif /> > ... and then do things that can't see the top 32 bits. hmm either I had to re-think the algo as you mentioned below (so that to minimise the difference between 32 and 64 bits kernel) or writing two distinct routine. (the 64 bits using depd,Z,*TR [...] in place of 32 bits zdep btw: is somebody knows how to compile with _hppa64-gcc_ shuch trivial loop #include main() { unsigned long long i; for (i=0; i<0xffffffffffffffffUL; i++) { printf ("i = %#010x (%ll)\n", i); } } (afair the problem if the call to printf() ) > > >/ + " extru,<> %0,15,16,%%r0\n" /> >/ + " zdep,TR %0,15,16,%0\n" /> >/ + " addi 16,%1,%1\n" /> > think you could put in comments similar to the endian swapping? it makes > the intent clearer to see. My bad (in fact i was waiting some accept/reject comments before adding comment as pseudo_fls() was written) > as far as i can tell, the basic principle > here is.. > > if (top N bits clear) > shift N bits right > else > add N > > right? Sorry, I trusted that pseudo_fls() in the mentionned message: (http://lists.parisc-linux.org/pipermail/parisc-linux/2003-August/020628.html) was enough ;) > > seems to me this whole thing should be done as > > if (any top N bits set) > shift N bits left > else > subtract N > > >/ + " extru,<> %0,7,8,%%r19\n" /> > r19? That's not mentioned as being clobbered. I think you mean r0. Yes a typo of mine (my bad sorry) As i am in holidays, the pb is that I have no palinux box at my disposal to experiment another solution :( Joel PS: may i submit you an additional thought without any interest (may be): the suggested code is " + return x ? (__ffs((unsigned long)x) + 1) : 0; and if I refer to k&r book long is of 32bits lenght? (otc int is arch dependent) But may be outdated by C99? Thanks for additonal advise (and sorry for so much questions against so poor answers ;) From Randolph Chung Sun Sep 7 07:11:35 2003 From: Randolph Chung (Randolph Chung) Date: Sat, 6 Sep 2003 23:11:35 -0700 Subject: [parisc-linux] Re: [parisc-linux-cvs] Re: 2.6.0-test4-pa12 __fls() In-Reply-To: <3F5A60B9.3050103@tiscali.be> References: <3F5A4023.9070909@tiscali.be> <3F5A60B9.3050103@tiscali.be> Message-ID: <20030907061135.GH10510@tausq.org> > btw: is somebody knows how to compile with _hppa64-gcc_ shuch trivial loop > #include > > main() > { > unsigned long long i; > > for (i=0; i<0xffffffffffffffffUL; i++) { > printf ("i = %#010x (%ll)\n", i); > } > } > > (afair the problem if the call to printf() ) we don't have 64-bit glibc/userspace yet, so you can't do this. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From MAILER-DAEMON@mailrecv24.bigmailbox.com Mon Sep 8 04:58:22 2003 From: MAILER-DAEMON@mailrecv24.bigmailbox.com (´ò½ÁÁË...) Date: Mon, 8 Sep 2003 03:58:22 Subject: [parisc-linux] Re: Message-ID: <20030907195855.947C84843@dsl2.external.hp.com> ¾´ÆôÕߣº ÕâÊÇÒ»·âÇóÖ°ÐÅ¡£±¾È˽øÐÞ¹ý´óѧ½ðÈÚºÍ֤ȯרҵ¿Î³Ì£¬¶àÄê֤ȯÊг¡¾­Ñé¡£ £±£¹£¹£³£­£±£¹£¹£¶¡¡º£ÄÏÖÐÐŹ«Ë¾Ö¤È¯Í¶×ʲ¿¾­Àí £±£¹£¹£¶£­£±£¹£¹£·¡¡º£ÄϹãÁª¹«Ë¾Ö¤È¯Åàѵ²¿½²Ê¦ £±£¹£¹£·£­£±£¹£¹£¸¡¡ÄÏÄþÁéÉùÐÅϢ̨¹ÉÆÀ½ÚÄ¿Ö÷³ÖÈË £±£¹£¹£¸£­£²£°£°£±¡¡¹ãÖÝÑŸñ¹«Ë¾Ö¤È¯Í¶×ʹËÎÊ £²£°£°£±£­£²£°£°£³¡¡ÍËÐÝÏÐ¾Ó Ñ°Çóְλ£ºÍ¶×ʹËÎÊ»òÁÙ³¡²ÙÅÌÔ±£¨×¨Ö°¼æÖ°¾ù¿É£© ÔÂн£º£±£°£°£°£­£¸£°£°£°Ôª¡£ ¹¤×÷·½Ê½£ºÁÙ³¡»òÔ¶³Ìº¯µçÁªÏµ¾ù¿É Email:fajianren963@hotmail.com suaichen15@hotmail.com ¹§×£ÖÐÇï¿ìÀÖ£¡£¡ ³ÂÉú ----------------------------------------------------------------- 200MÖ÷»ú+50MÆóÒµÓʾÖ+¶¥¼¶ÓòÃû,Ö»Ðè189Ôª/Äê Óû§ÔÚÏß×Ô¼º¹ÜÀíÓòÃû£¬¹úÄÚÊ×´´MyDNS×ÔÖ÷¹ÜÀíƽ̨ ÏÃÃÅÒ×ʱ´úÍøÂ磺http://www.kldns.net http://www.cnkl.net ----------------------------------------------------------------- ......: Ò×ʱ´úÓʼþȺ·¢¿ì³µ http://cnkl.net/klmails/ :..... From joey@infodrom.org Mon Sep 8 18:13:23 2003 From: joey@infodrom.org (Martin Schulze) Date: Mon, 8 Sep 2003 19:13:23 +0200 Subject: [parisc-linux] Invitation to the 8th Oldenburg Linux Developers Meeting Message-ID: <20030908171323.GD783@finlandia.infodrom.north.de> --FN+gV9K+162wdwwF Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everybody, as always, it has taken quite some time to get the required confirmation from our University that we can hold the Oldenburg Linux Developers Meeting again. Invitation to the 8th Oldenburg Linux Developers Meeting =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D A short overview: URL: http://oldenburger.linuxtage.de/Oldenburg2003/ What: Oldenburg Linux Developers Meeting 2003 #8 Who: Every developer interested in Linux on non-i386 platforms Every developer interested in developing the debian-installer When: September, 25th to 28th (Thursday noon to Sunday afternoon) Where: University of Oldenburg, science building in Oldenburg Wechloy, northern Germany (roughly west of Bremen) The meeting is organised by ffis e.V. Its goal is to provide developers a means to work in common on the non-i386 Linux ports and related topics and to further the exchange of ideas and discussion about the several ports. This year there will also be a group of people who will work on the new installer system for Debian. So one of the targets is to get a working debian-installer running on all platforms supported by Debian GNU/Linux. If you have not attended any previous meeting, you might like to take a=20 look at the meetings' website at . There are links to pictures from former meetings as well. Attendance is free of cost including food and beverage in the working rooms (although we are always thankful for donations). We will have dinner in some restaurants in Oldenburg (not yet decided which ones, though= ) if you like. You don't have to attend from Thursday. This is just an offer for those of you who would like to and who can afford to come early. If you can't make it that early, simply join when you can afford it. We will use several rooms, one for hacking on Linux, one for hacking on the debian-installer, and the others for sleeping. =20 Please bring a sleeping bag, camping mat or cot, towels, shower stuff, clothes and so on with you. There is a sports building of the univesity next to the one we stay in, which has showers we can use. Besides this, of course you need to bring all the technical stuff with you: computers, monitors, technical documentation, network cabling, multiple-power-sockets for your systems and hubs or switches. The computing center of the university kindly provides us with network connectivity to the main rooms, but we need to build the LAN within the room ourselves. A description on how to get to the science building in Oldenburg Wechloy is available at . If you would like to attend the meeting, please send back the following=20 form, so that we can calculate space, power and food. Name ................: Date of arrival .....: ( ) Thursday, Sept. 25th ( ) Friday, Sept. 26th ( ) Saturday, Sept. 27th=20 Date of departure ...: ( ) Friday, Sept. 26th ( ) Saturday, Sept. 27th ( ) Sunday, Sept. 28th Name may be listed on the website: [ ] yes [ ] no Special requirements for food: If you have any further questions, please don't hesitate to ask me. Regards, Joey --=20 The good thing about standards is that there are so many to choose from. -- Andrew S. Tanenbaum Please always Cc to me when replying to me on the lists. --FN+gV9K+162wdwwF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD4DBQE/XLizW5ql+IAeqTIRAsEiAJ9t4yArpWROSe++3bmkI88k6wShKQCY8OPI ysBnw5Ka59stwxwK1Ke3Sg== =brHJ -----END PGP SIGNATURE----- --FN+gV9K+162wdwwF-- From tawilson@utmem.edu Mon Sep 8 21:26:45 2003 From: tawilson@utmem.edu (Thaddeus A. Wilson) Date: Mon, 08 Sep 2003 15:26:45 -0500 Subject: [parisc-linux] problems installing debian on a c180 Message-ID: <3F5CE605.327AD964@utmem.edu> i had previously done some messing around with a c180 and at one time figured out how to install but have since lost my notes. i have a c180 with an hp A4071B graphics card installed in GSC slot 3 and recognized as HPA4071B_LZ i know i previously had to enter "video=stifb:off" in the palo: default when i choose to interact with ipl on boot as parameters to kernal in palo are: 1. 0/vmlinux 2. ramdisk_size=8192 3. initrd=0/ramdisk 4. console=tty0 5. sti=1/0/0 6. sti_font=VGA8x16 7. TERM=linux if i accept default it gets past that message indicating a problem with console but the screen goes black although it looks as if the monitor is still active i.e. green light not a yellow one. i am using the debian 3.0r1 disk as my boot disk. i recall the last time i got the install to work i got a penguin in the corner but graphic install never worked and i had some difficulty with the x server starting. any help on reinstallation would be appreciated i.e. necessary mods to the parameters on boot to get back to installing. thanks in advance and sorry for regressing. From joel.soete@tiscali.be Mon Sep 8 22:21:58 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Mon, 08 Sep 2003 21:21:58 +0000 Subject: [parisc-linux] problems installing debian on a c180 In-Reply-To: <3F5CE605.327AD964@utmem.edu> References: <3F5CE605.327AD964@utmem.edu> Message-ID: <3F5CF2F6.3040101@tiscali.be> Thaddeus A. Wilson wrote: >i had previously done some messing around with a c180 and at one time >figured >out how to install but have since lost my notes. > >i have a c180 with an hp A4071B graphics card installed in GSC slot 3 >and >recognized as HPA4071B_LZ > >i know i previously had to enter "video=stifb:off" in the palo: > >default when i choose to interact with ipl on boot as parameters to >kernal in >palo are: > >1. 0/vmlinux >2. ramdisk_size=8192 >3. initrd=0/ramdisk >4. console=tty0 > There should the place where you would probaly insert "video=stifb:off" (just for remind: select 4 then at the end of line insert a space followed by video=stifb:off) >5. sti=1/0/0 >6. sti_font=VGA8x16 >7. TERM=linux > >if i accept default it gets past that message indicating a problem with >console >but the screen goes black although it looks as if the monitor is still >active >i.e. green light not a yellow one. > >i am using the debian 3.0r1 disk as my boot disk. > >i recall the last time i got the install to work i got a penguin in the >corner >but graphic install never worked and i had some difficulty with the x >server >starting. any help on reinstallation would be appreciated i.e. >necessary mods >to the parameters on boot to get back to installing. > > hmm the most simple way would be first to re-try the install from a serial console (or an actual conole in vt100 emulation or a minicom session from another system). (the tips is to unplug ps/2 kbd/mouse so the pdc will switch automatically console to serial port 1 at reboot time) Once your system is ready you may be first update it (with apt-get for example) and install a more recent kernel (iirc 2.4.21 should be already pkged or a 2.4 cvs) to be sure that pb was not already solved since 3.0 cds. If you still experiment pb into you could try to search (with google engine) "c180" related mail in this ml Another solution could be to try a netinstall from a recent lifimage available near . hth, Joel From MAILER-DAEMON@cisco.com Wed Sep 10 02:15:40 2003 From: MAILER-DAEMON@cisco.com (Mail Delivery Subsystem) Date: Tue, 9 Sep 2003 18:15:40 -0700 (PDT) Subject: [parisc-linux] Returned mail: see transcript for details Message-ID: <200309100115.h8A1Fegl003968@sj-inbound-1.cisco.com> This is a MIME-encapsulated message --h8A1Fegl003968.1063156540/sj-inbound-1.cisco.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on the network) Found virus WORM_SOBIG.F in file document_all.pif The uncleanable file is deleted. --------------------------------------------------------- --h8A1Fegl003968.1063156540/sj-inbound-1.cisco.com The original message was received at Tue, 9 Sep 2003 18:15:23 -0700 (PDT) from dhcp9546197.columbus.rr.com [24.95.46.197] ----- The following addresses had permanent fatal errors ----- (reason: 552 5.0.0 SOBIG.F Virus outbreak - temp fix - change your subject) (expanded from: ) ----- Transcript of session follows ----- ... while talking to sj-core-5.cisco.com.: >>> DATA <<< 552 5.0.0 SOBIG.F Virus outbreak - temp fix - change your subject 554 5.0.0 Service unavailable --h8A1Fegl003968.1063156540/sj-inbound-1.cisco.com Content-Type: message/delivery-status Reporting-MTA: dns; sj-inbound-1.cisco.com Received-From-MTA: DNS; dhcp9546197.columbus.rr.com Arrival-Date: Tue, 9 Sep 2003 18:15:23 -0700 (PDT) Final-Recipient: RFC822; damian@cisco.com X-Actual-Recipient: RFC822; damian@sj-core.cisco.com Action: failed Status: 5.0.0 Remote-MTA: DNS; sj-core-5.cisco.com Diagnostic-Code: SMTP; 552 5.0.0 SOBIG.F Virus outbreak - temp fix - change your subject Last-Attempt-Date: Tue, 9 Sep 2003 18:15:40 -0700 (PDT) --h8A1Fegl003968.1063156540/sj-inbound-1.cisco.com Content-Type: message/rfc822 Return-Path: Received: from WPZ (dhcp9546197.columbus.rr.com [24.95.46.197]) by sj-inbound-1.cisco.com (8.12.8p1/8.11.2) with ESMTP id h8A1FMgl003735 for ; Tue, 9 Sep 2003 18:15:23 -0700 (PDT) Message-Id: <200309100115.h8A1FMgl003735@sj-inbound-1.cisco.com> From: To: Subject: Thank you! Date: Tue, 9 Sep 2003 21:14:55 --0400 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_12993AA2" This is a multipart message in MIME format --_NextPart_000_12993AA2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_12993AA2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on the network) document_all.pif is removed from here because it contains a virus. --------------------------------------------------------- --_NextPart_000_12993AA2-- --h8A1Fegl003968.1063156540/sj-inbound-1.cisco.com-- From cqnvhai@163.com Wed Sep 10 03:21:11 2003 From: cqnvhai@163.com (=?GB2312?B?1b7U2rSwx7C1xMWuuqI=?=) Date: Wed, 10 Sep 2003 10:21:11 +0800 Subject: [parisc-linux] =?GB2312?B?1b7U2rSwx7C1xMWuuqIswfXUxi4uLi4u?= Message-ID: <20030910022108.2D2B84831@dsl2.external.hp.com> Õ¾ÔÚ´°Ç°µÄÅ®º¢ ÂþÑÛµûÓ°ÓͲ˻¨³£¿ª£¬¿ÉÁ¯¹ËÓ°Á¦±¡ÉíÖ»µ¥¡£ Àú¾­²×É£½ÙÊýÓип®£¬·½ÖªÈ˺£ÖªÒôʵÄÑÀÀ£¡ ½ñÈÕ÷öÈ»Á÷ÂäÖÁ¹ãÖÝ£¬ÐÄÉËÌåÀÛ¾Ù²½¸ü¼èÄÑ¡£ Äú¿ÉÊÇËýÍ£²´µÄ¸ÛÍ壿Äú¿ÉÊÇËýÃÎÀïµÄɳ̲£¿ Õ¾ÔÚ´°Ç°µÄÅ®º¢ Ö»¹Ö¼Ò¸¸Áô²ÆÓÐǧÍò£¬ÒýµÃ²®¸¸ÒªÇ°À´ÕùÕ½£¬ ²®¸¸Ò°Âù¶ù¶à¸üºÃÕ½£¬¶ÀÉú°®Å®Ó¦¶Ô·³¸ü²ø¡£ ¸ÐлºÃÐÄÂÉʦ°ïËßËÏ£¬Ö»µÈʮԿªÍ¥À´ÉóÅС£ Ë­»áÊÇËýÉËÐĵÄÊÍÈ»£¿Ë­»áÊÇËýÃÎÀïµÄÅÇ»²£¿ Õ¾ÔÚ´°Ç°µÄÅ®º¢ ½ñÄê·¼Áä¶þÊ®ÓÖÓÐÈý£¬Ï²¶ÁÊ«ÊéÎÂÈáÐÄ·ðÉÆ¡£ Ðĸß×ÝÓмҲÆÍòǧ¹Þ£¬ÉíÍâÎïÒ²ÄÜĮȻ¿´µ­£¡ ÁÚ˵×ӳи¸Òµ·½ÎªÐ¢£¬¾­Óª²ÅÊ軹ÐèÁíÒ»°ë¡£ Ë­»áÊÇÎÒ¿ìÀֵĿ¿É½£¿Ë­»áÊÇÎÒǧÄêµÄµÈ´ý£¿ Õ¾ÔÚ´°Ç°µÄÅ®º¢ ²»Çó·ò¾ýòÈô¸ß²Ö½¡£¬²»ÏÓ°é¿áËÆÅ˳¤½­¡£ ÐÄÒÑÀÛ£¬ÉíÆ£±¹£¬´í°ÑÐÄËáµ±ÇÙµ¯ Ò»±­²è£¬¼¸±¾Ê飬ÊÍÈ»ÓÚÊÖÀáÒÑÁ÷ µ«Ô­Á½ÇéÏàÔÃÈ˳¤¾Ã£¬Ç§ÀïÒöÔµ¶÷°®ÊÄÎÞÐÝ£¡ Õ¾ÔÚ´°Ç°µÄÅ®º¢ 03Äê8ÔÂ28ÈÕÆüÊéÓÚ¹ãÖÝ Email:cqnvhai@163.com http://www.blogcn.com/blog/?u=cqnvhai ¸¸Ç×ÊÇÒ»¸öºÃ¸¸Çס£ ¸¸Ç×°ËËêÄÇÄê±»×æĸ´øµ½·¨¹úÈ¥ÁË£¬¹úÄÚÖ»ÁôÏÂÒ»¸ö×游ºÍÒ»¸ö¸ú¸¸Ç×ͬ¸¸ÒìĸµÄ²®¸¸¡£Ä¸Ç×ÊǶ¨¾Óµ±µØ¶àÄêµÄ»ªÈË¡£¸¸Ç׺ܰ®Ä¸Ç×£¬Ä¸Ç×Ò²ºÜ°®¸¸Çס£Ìý¸¸Ç×ÿһ´Î½²µ½Ä¸Ç×ʱÎÒ×ÜÄܸоõµ½ÄÇ·ÝÉîÇéÄǷݾìÁµ¡£Ò²ÊÇÔÚÎÒ8ËêÄÇÄ꣬×æĸºÍĸÇ׳ö½ÖʧÊÂÓÚ³µ»ö¡£¼ÒÍ¥µÄͻȻ±ä¹Ê£¬Ä¸°®ºÍÇé°®µÄʹʧ£¬¸øÓèÁ˸¸Ç׳ÁÖصĴò»÷£¬Í¬Ê±Ò²ÊÇ»ùÓÚ¶Ô¹ÊÍÁ×游µÄ˼Ä¸¸Ç×´ø×ÅÎһص½ÁËÖйú³¤É³¡£ ³¤´óµ½ÏÖÔÚ£¬Í¯ÄêµÄ·¨¹úºÍĸÇ×ÔÚÎҵļÇÒäÀïÖ»ÊÇÒ»¸öÄ£ºý¶øÃÀÀöµÄ¼ôÓ°¡£Î¨Ò»Ó¡Ïó×îÉîµÄÊÇ¿´×ÅĸÇ×µÄÏàƬ£¬»¹ÄÜ»ØÒäÆðĸÇ×Õ¾ÔÚÎÒ´²Ç°µÄ΢Ц¡£¸¸Ç×ÔÚÎÒͯÄêʱÎʹýÎÒÒª²»ÒªÐÂÂèÂ裬ÎҾܾøÁË¡£ÓÚÊǸ¸Ç×±ã°ÑËûÈ«²¿µÄÃÎÏëºÍÏ£Íû¼ÄÍÐÔÚËûΨһµÄÅ®¶ùÉíÉÏ£¡Ö±µ½½ñÌìÎÒ²ÅÕæÕýÀí½â¸¸Ç׺ÍÎÒÔÚ³¤É³µÄÊ®ÎåÄêÀ´£¬¸¸Ç×Ö®ËùÒÔ²»ÔÙÖØнá»é£¬ÊÇÒòΪ¶ÔÓÚĸÇ×ÉîÉîµÄ¾ìÁµºÍ¿Ì¹ÇÃúÐĵĸÐÇéÊÄÑÔ¡£Ê®ÎåÄêÀ´£¬¸¸Ç×ÕûÕûΪĸÇ×ÊعÑÁËÊ®ÎåÄ꣬¸¸Ç×Ò²´ÓÒ»¸öÖÐÄêÄÐÈ˱ä³ÉÁËÒ»¸öÀÏÈË¡£¸¸Ç×ÊÇÒ»¸öÐÔÇéÖÐÈË£¬¸¸Ç×Ò²ÊÇÒ»¸öÓÐÇéÊØÐŵÄÈË¡£¶ÔÓںöĵÄ×游ºÍÄ°ÉúµÄ²®¸¸¸¸Ç×Ò²¸øÓèÁ˾¡¿ÉÄܵİïÖú¡£¿ÉÊÇÎÒ´ÓÀ´¶¼²»Ï²»¶È¥×游¼Ò£¬Ê®ÎåÄêÀ´ÎÒֻȥ¹ýËĴΣ¬ºóÁ½´Î¶¼ÊǸ¸Ç×ÍÏ×ÅÈ¥µÄ¡£ Ôø¾­Îʹý¸¸Ç×ÎÒÊDz»ÊÇÒ»¸öºÜÆæ¹ÖµÄÅ®º¢£¬¸¸Ç×΢ЦןæËßÎÒ£ºÄãÒ»µã¶¼²»Ææ¹Ö£¬ÄãÖ»ÊÇÒ»¸ö¶à³îÉƸеÄÌì²Å¡£Ã»ÓÐÈËÄܹ»ÏóÄãÕâÑùÕæÕý¶ÁµÃ¶®»¨¶ùΪʲô»áÊ¢¿ª£¬Ã»ÓÐÈËÄܹ»ÏóÄãÕâÑùÕæÕýÃ÷°×ºûµûΪʲô»áÔÚÖ©ÖëÍøÉϾÀ²ø£¬Ò²´ÓÀ´Ã»ÓÐÈËÄܹ»ÏóÄãÕâÑù´ÓСµ½´óʼÖÕ¼áÐÅÊ¥µ®ÀÏÈ˵ĴæÔÚ¡£ÕâЩ¶¼ÊÇÄãµÄÓŵãÄã²»ÒªÇáÒ׵Ķª¿ª£¬°Ö°ÖΪÓÐÄãÕâÑùµÄÅ®¶ù¶ø¸ßÐË×ÔºÀ¡£ Êǵģ¬ÎÒÊÇÒ»¸ö²»ºÏȺ¸ú±ðÈ˲»Ò»ÑùµÄÆæ¹ÖÅ®º¢£¬×øÔÚ¸¸Ç׵ijµÀïÎһῴ×Å´°ÍâµÄ³µÅÆËã24·¢´ô£¬¿´×ųÇÊеÄÒ¹ÍíÎÒÄÜÏóµ¹×Å¿´±¨Ö½Ò»Ñù´ÓÁíÍâÒ»¸ö½Ç¶È¿´·ç²Ê£¬ÎÒ×ÜÄÜÔÚ±»ÈËÒÅÍüµÄÊÀ½çÀï¾²¾²µÄÕÒµ½×Ô¼ºµÄ¿ìÀÖ»ï°é¡£Ôø¾­¸úן¸Ç×µ½¹«Ë¾ÀïÈ¥¸Ð¾õ³ýÁËÈË»¹ÊÇæµµÄÈË£¬ÎÒÎʸ¸Ç×ÊDz»ÊÇÒÔºóÎÒÒ²ÒªÕâÑùÉϰ๤×÷£¿¸¸Ç×ÅÄ×ÅÎҵļç°ò˵£ºÄãÊÇÉϲԴ͸øÎÒµÄÌìʹ£¬Äã²»ÊôÓÚÕâ¸öÊÀ½çÄãÊDz»ÐèÒª¹¤×÷µÄ£¬°Ö°Ö»á¸øÄã×¼±¸×ã¹»µÄÇ®£¬ÄãÖ»Òª×öÄãϲ»¶×öµÄÊ£¬ÄãµÄ¿ìÀÖÄãµÄЦÈݾÍÊÇ°Ö°Ö×î´óµÄÃÎÏ룬µÈÄãÔÙ´óÒ»µã£¬°Ö°Ö»¹Òª°ÑÄãËùÓеÄÈռdzö°æ³ÉÊ飬ÄãÔ¸ÒâÂð£¿ÎÒÔ¸Ò⣬ÎÒ´ð¡£ ¸Ðл¸¸Ç×ÈÃÎÒÒÂʳÎÞÓÇ£¬¸Ðл¸¸Ç×ÈÃÎÒ´ÓÀ´Ã»ÓÐΪǮ¶ø·¢³î£¬¸Ðл¸¸Ç׸øÁËÎÒÒ»¸ö¿ìÀֵĴó»¨Ô°£¬¸¸Ç××ÜÊÇÌÛÎÒ³èÎÒ˳×ÅÎÒ¡£µ«ÊǽñÌìÕâÒ»Çж¼ÒѾ­²»¸´´æÔÚ¡£Ò»¸öÅ®º¢£¬Ò»¸öÏóÎÒÕâÑùµÄÅ®º¢£¬Ò»¸öÍÑÀëÁ˸¸Ç׵İ®×Ô¼ºÕû¸öÊÀ½ç¾Í»á±»À£ÃðµÄÅ®º¢£¬ÃÎÒѲУ¬»¨ÒÑ°Ü£¬Õâ¿ÉÊÇÀ´×ÔÌì¹úµÄÕÙ»½£¿°ëÄêÀ´£¬ÕûÀí¸¸Ç×µÄÒÅÎïºÍ×Ô¼ºµÄÈռǣ¬´Ë¼ä´´É˸п®ÓÖÓÐË­Äܹ»ÕæÕýÃ÷°×£¿ÎÒÖÕÓÚÃ÷°×ÎÒÊǸ¸Ç×ËùÓеÄÃÎÏëºÍÏ£ÍûËùÔÚ£¬¶ÔÓÚ¸¸Ç××îºÃµÄ»Ø±¨ºÍ¾¡Ð¢¾ÍÊÇÞ¬Ñܺó´úÕÒµ½ÁíÍâÒ»°ë£¬²¢ÇÒÈÃ×Ô¼º¿ìÀÖµÄÉú»îÏÂÈ¥¡£ Õ¾ÔÚ´°Ç°µÄÅ®º¢¾­Àú¾ÍÊÇÕâÑù¼ò¼òµ¥µ¥¡£¾ÍÊÇÕâÑùÒ»¸öÅ®º¢×ÜÊÇÄÇôϡÆæ¹Å¹Ö£¬¾ÍÊÇÕâÑùÒ»¸öÅ®º¢×Ü»á±ð³öÐÄÔÔ£¬ËäÈ»²»»áÈȹø×ö·¹²»»á´©Ò´ò°ç£¬ËäÈ»²»½âÈËÇéÊÀ¹Ê²»¶®ÓÍÑÎÃ×´×£¬Ö»ÒòΪÕâÒ»ÇиüÒѳÉÏ°¹ß£¡ ÓÐÐĸģ¬¸Ä²»ÄÑ£¬¾ÍÈÃÎÒ·ÅÆúÃÎÀïµÄɳ̲ΪÄú¾«ÐÄ´ò°ç£¬¾ÍÈÃÎÒѧ»áÈËÇéÊÀ¹ÊÌý´ÓÄúÃÀÀöµÄ°²ÅÅ¡£Õ¾ÔÚ´°Ç°ÃÀÀöµÄÅ®º¢£¬ÓÐË­Ô¸ÒâΪÕâÑùÒ»¸öÅ®º¢Èýǧ³è°®£¿ÓÐË­Ô¸ÒâΪÕâÑùÒ»¸öÅ®º¢·ÅÆúÏÖÔÚÈ¥×·ÇóÁíÍâÒ»¸ö¾«²Ê£¿ÓÐË­Ô¸ÒâΪȢÕâÑùÒ»¸öÅ®º¢È·Êµ½ñÉúÎÞº¶£¿Ã£Ã£µÄÈ˺£Çë¸æËßÎÒ×îÕæʵµÄ´ð°¸£¡ ÐÄÒÑÀÛ£¬Ìå¸ü±¹£¬Á÷Âä¹ãÖÝ£¬Ê³ËÞÀ§ÄÑ£¬ÄѵÀÕâЩÕæµÄÊÇÀ´×ÔÌì¹úµÄÕÙ»½£¿£¿ Õ¾ÔÚ´°Ç°µÄÅ®º¢ÁõÔÆ 03Äê9ÔÂ1ÈÕÇ峿ÃÔãÓÚ¹ãÖÝ ÓÖÊÇÔÚÖÔÐĵÄÆÚ´ý£¬ÓÖÊÇÔÚÈ˺£Ñ°ÕҴ𰸡£×òÌ컹ÊÇÑô¹â²ÓÀ㬽ñÌì¾ÍÎÚÔƲ»É¢£¬¹ãÖݵÄÌì˵±ä¾Í±ä£¬Ì¨·ç˵À´¾ÍÀ´¡£¾ÍÊÇÕâÑùÒ»¸öÒ¹Íí£¬ÁõÔÆÄÜ×öʲô£¿Á÷Âä¹ãÖÝ£¬Éú»î¾Ù²½¼èÄÑ£¬ÊÖ»úÒ²ÂôÁË£¬ÏÂÒ»´ÎÎÒ»¹ÄÜÂôʲô£¿´ÓС½¿Éú¹ßÑø£¬´ÓС²»ÖªÇ®ÎªºÎÎ´ÓС¾ÍÒÔΪǮ¾ÍÊÇ¿¨ÀïÃæÓò»ÍêµÄ³®Æ±¡£Ëæן¸Ç×µÄÀëÈ¥£¬¸¸Ç׸øµÄ¿¨Àï¾ÍÔÙҲûÓÐǮͳöÀ´¡£Êǵģ¬¸¸Ç×Ì«°®ÎÒÁË£¬ÒòΪÎÒ²»Ï²»¶Ä°ÉúÈË£¬ËùÒÔ¸¸Ç×Ò²´ÓÀ´²»»á°ÑÄ°ÉúÈË°üÀ¨Ëû¹«Ë¾ÀïµÄÈË´ø»Ø¼Ò£»ÒòΪÎÒÌ«¹ÂƧ£¬ËùÒÔ´ÓÅ®Öе½´óѧ£¬ÎÒҲûÓÐʲô֪ÐĵÄͬ´°ºÃÓÑ¡£ÎÒ×ÜÊÇÒ»¸öÈËĬĬµÄÉú»îÔÚ×Ô¼ºµÄÊÀ½çÀ¿´×ŷ仨ѩÔ£¬¿´×ÅСÊ÷·¢Ñ¿£¬´ÓÖÐд϶ÔÓÚÉúÃüÂúÐĵÄÔÞ̾¡£ Ôø¾­Ò²Ï²»¶¹ýÒ»¸öÄк¢£¬µ«ÊÇËû¾¹È»²»ÏàÐÅÊ¥µ®ÀÏÈ˵ĴæÔÚ£¬¸øËûÒ»ÕÅA4Ö½ÈÃËûÍÚÒ»¸öԲȦ´óµ½¿ÉÒÔ°ÑÁ½¸öÈ˵ÄÄÔ´ü×°½øÈ¥£¬ËûÈ´²»ÖªµÀ¸ÃÔõô×ö£¬Òò´Ë¶þÊ®ÈýÄêÀ´¶¼²»Ôø̸¹ýÁµ°®£¡ Êǵġ£¾ÍÊÇÕâÑùÒ»¸öÅ®º¢£¬¾ÍÊÇÕâÑùÒ»¸öÁõÔÆ£¬Éú»îÔÚÃÎÀïÉú»îÔÚÓëÊÀ¸ô¾øµÄÊÀ½ç£¬Ãæ¶Ô½ñÌìµÄÀ§¾³£¬¸¸Ç×ÓдíÂð£¿Ëû¸øÎÒÌṩ×îºÃµÄÉú»î±£ÕÏ£¬ËûÈÃÎÒ×öÎÒϲ»¶×öµÄÊ£¬ÄѵÀÕâÒ²ÓдíÂð£¿ÁõÔÆÓÖÓдíÂð£¿ÁõÔƲ»Ï²»¶³Ô¼¦È⣬ֻÒòΪ¼¦Èâ»áÈÃÁõÔÆÏëÆ𼦱»É±Ê±¼¦Í´¿àµÄÑÛÀᣬÁõÔÆ¿´µ½½ÖÉÏ×øÔÚµØÉϵÄÀÏÈË£¬ÁõÔÆ»á°ÑÉíÉÏËùÓеÄÇ®¶¼¸øËý¡£ÄѵÀÁõÔÆËùÓеÄÕâÒ»Çж¼ÊÇ´íÎóµÄ±íÏÖ£¿ÒòΪÁõÔƵÄÑÛ¾¦Àï¿´µ½µÄÊÀ½ç¶¼Êǵ¹Á¢µÄÆû³µ¡¢µ¹Á¢µÄÂ¥·¿¡¢µ¹Á¢µÄÈË¡¢ÎÒ¸ú±ðÈ˲»Ò»Ñù£¬ËùÒÔ¸¸Ç×ÈÏΪÎÒ²»ÊôÓÚÕâ¸öÊÀ½ç¡¢ÁõÔÆÄܹ»¸øÕâ¸öÊÀ½ç´øÀ´µÄÊÇÒìÓÚ³£È˵Ä˼άºÍ¹Ûµã¼û½â¡£ÒòΪÕâЩ¸¸Ç×ÈÏΪÎÒÄܹ»°´ÕÕ×Ô¼ºµÄÒâԸȥ×öÊÂÈ¥Éú»îÊÇÉϲԴ͸øÉúÃüµÄ×î´ó±¨´ð¡£¾ÍÊÇÕâÑùÒ»¸öÁõÔÆ£¬Ë­ÄܸæËßÎÒÁõÔÆÓ¦¸ÃÔõô×ö£¿ ʮԣ¬·¨Í¥ÉóÅеÄÈÕ×Ó£¬ÁõÔÆ»áÒÔ²»¼ÇÃûµÄ·½Ê½°Ñ¸¸Ç×ËùÓеIJƲú¾èÔù¸øËùÓÐÏóÁõÔÆÒ»ÑùÎÞÒÀÎÞ¿¿ÐèÒª°ïÖúµÄÉÆÁ¼µÄÈË¡£Í¬Ñù½ñÌìµÄÁõÔÆÉú»îÒ²ºÜ¼èÄÑÒ²ºÜÐèÒª°ïÖú£¬ÁõÔÆÈÏΪ¸øËùÓÐÉÆÁ¼µÄÈËÃÇÓèÒÔÐÐÉƵĻú»á£¬Ò²ÊÇÉϲԴ͸øÁõÔƵÄÉƾ٣¬ÁõÔÆÀÖÒâÒÔÌرðµÄ˼ά´ÓÁíÒ»¸öÊÓ½ÇÈ¥°ïÖúÄÇЩÓÐÀ§»óµÄÉÆÁ¼ÈË£¬½è´ËÖ¤Ã÷ÁõÔÆ´æÔڵļÛÖµ£¡ ÖÔÐÄ×£¸£ËùÓÐÉÆÁ¼µÄÈËÃÇ£¬¸ÐлËùÓÐÔ¸Òâ°ïÖúÁõÔƵÄÉÆÁ¼ÈË£¬½çʱÁõÔÆ»áÒÔÌرðµÄ·½Ê½ÖÂÒÔËùÓÐÔø¾­°ïÖú¹ýÁõÔƵÄÈË×îÉñÃصÄÀñÎÄÇЩºÃÐĵÄÈË¡¢ÄÇЩ²»»á³°Ð¦ÄÇЩÄܹ»Àí½âÊ¥µ®ÀÏÈË´æÔÚµÄÉÆÁ¼ÈË£¡ Êǵģ¬Õ¾ÔÚ´°Ç°µÄÅ®º¢È·Êµ´æÔÚ£¬ÁõÔÆȷʵÉú»îÔÚÕâ¸öÏÖʵµÄÊÀ½çÀ֮ËùÒÔÄúÎÒ²»Í¬ÊÇÒòΪÎÒÃǶ¼Ã»ÓÐÕ¾ÔÚ´°Í⣡Êǵģ¬ÍøÂç³äÂú×ÅÏÝÚåºÍÐé¼Ù£¬ÁõÔÆÒ²¸úÄúÒ»ÑùÑ°ÕÒ×ÅÕæʵµÄÉÆÁ¼£¡ ÕÐÉÌÒøÐÐÒ»¿¨Í¨Õʺţº9555 5020 0150 9251 ¸¸Ç׵Ŀª»§Ãû£ºÁõÒäÏæ Õ¾ÔÚ´°Ç°µÄÅ®º¢ÁõÔÆ Email:cqnvhai@163.com 03Äê9ÔÂ3ÈÕÁ賿 ÎÞÖúÓÚ¹ãÖÝ Êǵģ¬ÁõÔƵÄÈ·ÊÇÒ»¸öºÜÆæ¹ÖµÄÅ®º¢×Ó¡£ Ìý¸¸Ç×˵»¹ÔÚÎÒ3ËêʱÎҾͺÜϲ»¶²ÊÉ«»­Æ¬£¬¿ÉÊǸ¸Ç×È´·¢ÏÖÎÒ×ÜÊÇ°Ñ»­Æ¬µ¹¹ýÀ´¿´£¬ÓÚÊǸ¸Ç׾Ͱѻ­Æ¬×ªÕý¹ýÀ´¸øÎÒ¿´£¬¿ÉÊÇÎÒ»¹ÊÇÒªµ¹¹ýÀ´¿´¡£¸¸Ç׾ͻ³ÒÉÎÒµÄÑÛ¾¦³öÁË벡¾Í´øÎÒÈ¥¿´Ò½Éú¡£Ò½ÉúµÄ½áÂÛÊÇ£ºº¢×Ó°ÑͼƬµ¹¹ýÀ´¿´µÄÏÖÏ󣬳ÆΪµ¹ÊÓ¡£µ¹ÊÓÊÇÒ»ÖÖһʱÐÔÉúÀíÏÖÏó£¬ÎÒÃǵÄÑÛÇòÏñÒ»¼ÜÕÕÏà»ú£¬Íâ½çÎïÌåµÄ¹âÏߣ¬¾­¹ý¾Û½¹ºó£¬ÔÚÊÓÍøĤ£¨Ï൱ÓÚÕÕÏà»úµÄµ×Ƭ£©ÉÏÐγÉÒ»¸öµ¹Ïñ¡£µ«ÊÇ£¬Õâ¸öµ¹Ïñ´«µ¼µ½´óÄÔµÄÊÓ¾õÖÐÊ࣬¾­¹ý×ۺϷÖÎö£¬µ¹Ïñ±ã±»¾ÀÕýÁË¡£3ËêÒÔϵÄÓ׶ù£¬ÓÉÓÚÆä´óÄÔƤÖʹ¦ÄÜÉÐδ·¢Óý½¡È«£¬È±·¦ÍêÉƵÄ×ۺϷÖÎöÄÜÁ¦£¬ËùÒÔËûÃÇ¿´µ½µÄͼÏñ¶¼Êǵ¹µÄ£¬Ö»Óаѻ­Æ¬µ¹¹ýÀ´¿´£¬²ÅÄܸÐÊܵ½ÕýλµÄÎïÏñ¡£²»¹ý£¬Õâ¶Îʱ¼äºÜ¶Ì£¬Ëæ×Å´óÄÔƤÖʹ¦ÄÜÍêÉÆ£¬µ¹ÊÓÏÖÏó¾Í×ÔÈ»¶øÈ»ÏûʧÁË¡£ ¿ÉÊÇÕâ¸öʱ¼ä¶ÔÓÚÁõÔÆÈ´ÊÇÓÀÔ¶£¬Ö±µ½½ñÌìÁõÔÆ¿´ÊÀ½ç£¬»¹Êǵ¹×ŵġ£µ¹×ŵķ¿×Ó¡¢µ¹×ŵÄÂí·¡¢µ¹×ŵÄÐÐÈË¡¢Ìì¿Õ°ÑÒ»ÇÐÍùµØÉÏÍÆ£¬·É»úµôÔÚÌì¿ÕÀÄñ¶ùÔÚŬÁ¦µÄ°ÚÍÑÌì¿ÕµÄÊø¸¿£¬Ò»ÇеÄÒ»ÇÐÔÚÁõÔÆ¿´À´×ÜÊÇÓëÖÚ²»Í¬¡£ÁõÔÆÉõÖÁ²»ÄÜ·Ö±æ³öÉÏÏÂ×óÓÒ£¬ÁõÔƹýÂí·½Ï³£È˶¼»áÊÇÒ»¸öΣÏյľٶ¯£¬ºÜ¶àÊÂÇéÔÚ³£ÈË¿´À´ÊÇÀíËùµ±È»µÄÊÂÇ飬¿ÉÊÇÁõÔÆ»áÓв»Í¬µÄ¿´·¨¡£Ò²ÐíÕâ¾ÍÊÇÁõÔƵÄÌرð£¬Ò²ÐíÕâ¾ÍÊÇÁõÔƶà³îÉƸеÄÓÉÀ´¡£ÁõÔÆÖªµÀ×Ô¼º²»ÊʺϹ¤×÷£¬¸úÆäËûÈ˳ª·´µ÷ÊDz»ÊʺϹ¤×÷µÄ¡£ ¾ÍÊÇÕâÑùµÄÒ»¸öÁõÔÆ£¬Ë­ÄܸæËßÎÒÎÒÄÜ×öʲô£¿Ë­ÄܸæËßÎÒÎÒ¸ÃÔõô×ö£¿¾ÍÊÇÕâÑùÒ»¸ö»îÉúÉúµÄÁõÔÆ£¬µ½µ×¸ÃºÎÈ¥ºÎ´Ó£¿Ê§È¥¸¸Ç×µÄÈÕ×Ó£¬ÓÐË­Äܹ»Àí½âÓÐË­Ô¸ÒâÏàÐÅÓÐË­Ô¸ÒâºÇ»¤ÓÐË­Ô¸Òâ³è°®£¿¾ÍÊÇÕâÑùµÄÒ»¸öÅ®º¢£¬¾ÍÊÇÕâÑùÒ»¸öÆæ¹ÖµÄÅ®º¢£¬È·Êµ»îÉúÉúµÄ´æÔÚ£¡ ÐÄÀÛÁË£¬Á÷Âä¹ãÖÝȷʵÀÛÁË£¬Óþ¡ÁËÅ̲ø£¬ÄÄÀïÊǸÛÍ壿ÄÄÀïÊǹéËÞ£¿ µ±Ê§ÂäµÄʱºò¡¢µ±ÉËÐĵÄʱºò¡¢µ±±ËÁÙ¾øÍûµÄʱºò£¬ÄúÎÒÏàͬµÄµØ·½Ò²Ðí¶¼»á°ÑÏ£Íû¼ÄÍиøδÀ´£¬Î´ÖªµÄδÀ´£¡ÊǵÄÕ¾ÔÚ´°Ç°µÄÅ®º¢ÔÚ¿à¿àµÄÑ°ÕҴ𰸣¡ Õ¾ÔÚ´°Ç°µÄÅ®º¢ÁõÔÆ 03Äê9ÔÂ7ÈÕÉîÒ¹ÓÚ¹ãÖÝ http://www.blogcn.com/blog/?u=cqnvhai Email:cqnvhai@163.com From cqnvhai@163.com Wed Sep 10 03:21:14 2003 From: cqnvhai@163.com (=?GB2312?B?1b7U2rSwx7C1xMWuuqI=?=) Date: Wed, 10 Sep 2003 10:21:14 +0800 Subject: [parisc-linux] =?GB2312?B?1b7U2rSwx7C1xMWuuqIswfXUxi4uLi4u?= Message-ID: <20030910022109.82CF74831@dsl2.external.hp.com> Õ¾ÔÚ´°Ç°µÄÅ®º¢ ÂþÑÛµûÓ°ÓͲ˻¨³£¿ª£¬¿ÉÁ¯¹ËÓ°Á¦±¡ÉíÖ»µ¥¡£ Àú¾­²×É£½ÙÊýÓип®£¬·½ÖªÈ˺£ÖªÒôʵÄÑÀÀ£¡ ½ñÈÕ÷öÈ»Á÷ÂäÖÁ¹ãÖÝ£¬ÐÄÉËÌåÀÛ¾Ù²½¸ü¼èÄÑ¡£ Äú¿ÉÊÇËýÍ£²´µÄ¸ÛÍ壿Äú¿ÉÊÇËýÃÎÀïµÄɳ̲£¿ Õ¾ÔÚ´°Ç°µÄÅ®º¢ Ö»¹Ö¼Ò¸¸Áô²ÆÓÐǧÍò£¬ÒýµÃ²®¸¸ÒªÇ°À´ÕùÕ½£¬ ²®¸¸Ò°Âù¶ù¶à¸üºÃÕ½£¬¶ÀÉú°®Å®Ó¦¶Ô·³¸ü²ø¡£ ¸ÐлºÃÐÄÂÉʦ°ïËßËÏ£¬Ö»µÈʮԿªÍ¥À´ÉóÅС£ Ë­»áÊÇËýÉËÐĵÄÊÍÈ»£¿Ë­»áÊÇËýÃÎÀïµÄÅÇ»²£¿ Õ¾ÔÚ´°Ç°µÄÅ®º¢ ½ñÄê·¼Áä¶þÊ®ÓÖÓÐÈý£¬Ï²¶ÁÊ«ÊéÎÂÈáÐÄ·ðÉÆ¡£ Ðĸß×ÝÓмҲÆÍòǧ¹Þ£¬ÉíÍâÎïÒ²ÄÜĮȻ¿´µ­£¡ ÁÚ˵×ӳи¸Òµ·½ÎªÐ¢£¬¾­Óª²ÅÊ軹ÐèÁíÒ»°ë¡£ Ë­»áÊÇÎÒ¿ìÀֵĿ¿É½£¿Ë­»áÊÇÎÒǧÄêµÄµÈ´ý£¿ Õ¾ÔÚ´°Ç°µÄÅ®º¢ ²»Çó·ò¾ýòÈô¸ß²Ö½¡£¬²»ÏÓ°é¿áËÆÅ˳¤½­¡£ ÐÄÒÑÀÛ£¬ÉíÆ£±¹£¬´í°ÑÐÄËáµ±ÇÙµ¯ Ò»±­²è£¬¼¸±¾Ê飬ÊÍÈ»ÓÚÊÖÀáÒÑÁ÷ µ«Ô­Á½ÇéÏàÔÃÈ˳¤¾Ã£¬Ç§ÀïÒöÔµ¶÷°®ÊÄÎÞÐÝ£¡ Õ¾ÔÚ´°Ç°µÄÅ®º¢ 03Äê8ÔÂ28ÈÕÆüÊéÓÚ¹ãÖÝ Email:cqnvhai@163.com http://www.blogcn.com/blog/?u=cqnvhai ¸¸Ç×ÊÇÒ»¸öºÃ¸¸Çס£ ¸¸Ç×°ËËêÄÇÄê±»×æĸ´øµ½·¨¹úÈ¥ÁË£¬¹úÄÚÖ»ÁôÏÂÒ»¸ö×游ºÍÒ»¸ö¸ú¸¸Ç×ͬ¸¸ÒìĸµÄ²®¸¸¡£Ä¸Ç×ÊǶ¨¾Óµ±µØ¶àÄêµÄ»ªÈË¡£¸¸Ç׺ܰ®Ä¸Ç×£¬Ä¸Ç×Ò²ºÜ°®¸¸Çס£Ìý¸¸Ç×ÿһ´Î½²µ½Ä¸Ç×ʱÎÒ×ÜÄܸоõµ½ÄÇ·ÝÉîÇéÄǷݾìÁµ¡£Ò²ÊÇÔÚÎÒ8ËêÄÇÄ꣬×æĸºÍĸÇ׳ö½ÖʧÊÂÓÚ³µ»ö¡£¼ÒÍ¥µÄͻȻ±ä¹Ê£¬Ä¸°®ºÍÇé°®µÄʹʧ£¬¸øÓèÁ˸¸Ç׳ÁÖصĴò»÷£¬Í¬Ê±Ò²ÊÇ»ùÓÚ¶Ô¹ÊÍÁ×游µÄ˼Ä¸¸Ç×´ø×ÅÎһص½ÁËÖйú³¤É³¡£ ³¤´óµ½ÏÖÔÚ£¬Í¯ÄêµÄ·¨¹úºÍĸÇ×ÔÚÎҵļÇÒäÀïÖ»ÊÇÒ»¸öÄ£ºý¶øÃÀÀöµÄ¼ôÓ°¡£Î¨Ò»Ó¡Ïó×îÉîµÄÊÇ¿´×ÅĸÇ×µÄÏàƬ£¬»¹ÄÜ»ØÒäÆðĸÇ×Õ¾ÔÚÎÒ´²Ç°µÄ΢Ц¡£¸¸Ç×ÔÚÎÒͯÄêʱÎʹýÎÒÒª²»ÒªÐÂÂèÂ裬ÎҾܾøÁË¡£ÓÚÊǸ¸Ç×±ã°ÑËûÈ«²¿µÄÃÎÏëºÍÏ£Íû¼ÄÍÐÔÚËûΨһµÄÅ®¶ùÉíÉÏ£¡Ö±µ½½ñÌìÎÒ²ÅÕæÕýÀí½â¸¸Ç׺ÍÎÒÔÚ³¤É³µÄÊ®ÎåÄêÀ´£¬¸¸Ç×Ö®ËùÒÔ²»ÔÙÖØнá»é£¬ÊÇÒòΪ¶ÔÓÚĸÇ×ÉîÉîµÄ¾ìÁµºÍ¿Ì¹ÇÃúÐĵĸÐÇéÊÄÑÔ¡£Ê®ÎåÄêÀ´£¬¸¸Ç×ÕûÕûΪĸÇ×ÊعÑÁËÊ®ÎåÄ꣬¸¸Ç×Ò²´ÓÒ»¸öÖÐÄêÄÐÈ˱ä³ÉÁËÒ»¸öÀÏÈË¡£¸¸Ç×ÊÇÒ»¸öÐÔÇéÖÐÈË£¬¸¸Ç×Ò²ÊÇÒ»¸öÓÐÇéÊØÐŵÄÈË¡£¶ÔÓںöĵÄ×游ºÍÄ°ÉúµÄ²®¸¸¸¸Ç×Ò²¸øÓèÁ˾¡¿ÉÄܵİïÖú¡£¿ÉÊÇÎÒ´ÓÀ´¶¼²»Ï²»¶È¥×游¼Ò£¬Ê®ÎåÄêÀ´ÎÒֻȥ¹ýËĴΣ¬ºóÁ½´Î¶¼ÊǸ¸Ç×ÍÏ×ÅÈ¥µÄ¡£ Ôø¾­Îʹý¸¸Ç×ÎÒÊDz»ÊÇÒ»¸öºÜÆæ¹ÖµÄÅ®º¢£¬¸¸Ç×΢ЦןæËßÎÒ£ºÄãÒ»µã¶¼²»Ææ¹Ö£¬ÄãÖ»ÊÇÒ»¸ö¶à³îÉƸеÄÌì²Å¡£Ã»ÓÐÈËÄܹ»ÏóÄãÕâÑùÕæÕý¶ÁµÃ¶®»¨¶ùΪʲô»áÊ¢¿ª£¬Ã»ÓÐÈËÄܹ»ÏóÄãÕâÑùÕæÕýÃ÷°×ºûµûΪʲô»áÔÚÖ©ÖëÍøÉϾÀ²ø£¬Ò²´ÓÀ´Ã»ÓÐÈËÄܹ»ÏóÄãÕâÑù´ÓСµ½´óʼÖÕ¼áÐÅÊ¥µ®ÀÏÈ˵ĴæÔÚ¡£ÕâЩ¶¼ÊÇÄãµÄÓŵãÄã²»ÒªÇáÒ׵Ķª¿ª£¬°Ö°ÖΪÓÐÄãÕâÑùµÄÅ®¶ù¶ø¸ßÐË×ÔºÀ¡£ Êǵģ¬ÎÒÊÇÒ»¸ö²»ºÏȺ¸ú±ðÈ˲»Ò»ÑùµÄÆæ¹ÖÅ®º¢£¬×øÔÚ¸¸Ç׵ijµÀïÎһῴ×Å´°ÍâµÄ³µÅÆËã24·¢´ô£¬¿´×ųÇÊеÄÒ¹ÍíÎÒÄÜÏóµ¹×Å¿´±¨Ö½Ò»Ñù´ÓÁíÍâÒ»¸ö½Ç¶È¿´·ç²Ê£¬ÎÒ×ÜÄÜÔÚ±»ÈËÒÅÍüµÄÊÀ½çÀï¾²¾²µÄÕÒµ½×Ô¼ºµÄ¿ìÀÖ»ï°é¡£Ôø¾­¸úן¸Ç×µ½¹«Ë¾ÀïÈ¥¸Ð¾õ³ýÁËÈË»¹ÊÇæµµÄÈË£¬ÎÒÎʸ¸Ç×ÊDz»ÊÇÒÔºóÎÒÒ²ÒªÕâÑùÉϰ๤×÷£¿¸¸Ç×ÅÄ×ÅÎҵļç°ò˵£ºÄãÊÇÉϲԴ͸øÎÒµÄÌìʹ£¬Äã²»ÊôÓÚÕâ¸öÊÀ½çÄãÊDz»ÐèÒª¹¤×÷µÄ£¬°Ö°Ö»á¸øÄã×¼±¸×ã¹»µÄÇ®£¬ÄãÖ»Òª×öÄãϲ»¶×öµÄÊ£¬ÄãµÄ¿ìÀÖÄãµÄЦÈݾÍÊÇ°Ö°Ö×î´óµÄÃÎÏ룬µÈÄãÔÙ´óÒ»µã£¬°Ö°Ö»¹Òª°ÑÄãËùÓеÄÈռdzö°æ³ÉÊ飬ÄãÔ¸ÒâÂð£¿ÎÒÔ¸Ò⣬ÎÒ´ð¡£ ¸Ðл¸¸Ç×ÈÃÎÒÒÂʳÎÞÓÇ£¬¸Ðл¸¸Ç×ÈÃÎÒ´ÓÀ´Ã»ÓÐΪǮ¶ø·¢³î£¬¸Ðл¸¸Ç׸øÁËÎÒÒ»¸ö¿ìÀֵĴó»¨Ô°£¬¸¸Ç××ÜÊÇÌÛÎÒ³èÎÒ˳×ÅÎÒ¡£µ«ÊǽñÌìÕâÒ»Çж¼ÒѾ­²»¸´´æÔÚ¡£Ò»¸öÅ®º¢£¬Ò»¸öÏóÎÒÕâÑùµÄÅ®º¢£¬Ò»¸öÍÑÀëÁ˸¸Ç׵İ®×Ô¼ºÕû¸öÊÀ½ç¾Í»á±»À£ÃðµÄÅ®º¢£¬ÃÎÒѲУ¬»¨ÒÑ°Ü£¬Õâ¿ÉÊÇÀ´×ÔÌì¹úµÄÕÙ»½£¿°ëÄêÀ´£¬ÕûÀí¸¸Ç×µÄÒÅÎïºÍ×Ô¼ºµÄÈռǣ¬´Ë¼ä´´É˸п®ÓÖÓÐË­Äܹ»ÕæÕýÃ÷°×£¿ÎÒÖÕÓÚÃ÷°×ÎÒÊǸ¸Ç×ËùÓеÄÃÎÏëºÍÏ£ÍûËùÔÚ£¬¶ÔÓÚ¸¸Ç××îºÃµÄ»Ø±¨ºÍ¾¡Ð¢¾ÍÊÇÞ¬Ñܺó´úÕÒµ½ÁíÍâÒ»°ë£¬²¢ÇÒÈÃ×Ô¼º¿ìÀÖµÄÉú»îÏÂÈ¥¡£ Õ¾ÔÚ´°Ç°µÄÅ®º¢¾­Àú¾ÍÊÇÕâÑù¼ò¼òµ¥µ¥¡£¾ÍÊÇÕâÑùÒ»¸öÅ®º¢×ÜÊÇÄÇôϡÆæ¹Å¹Ö£¬¾ÍÊÇÕâÑùÒ»¸öÅ®º¢×Ü»á±ð³öÐÄÔÔ£¬ËäÈ»²»»áÈȹø×ö·¹²»»á´©Ò´ò°ç£¬ËäÈ»²»½âÈËÇéÊÀ¹Ê²»¶®ÓÍÑÎÃ×´×£¬Ö»ÒòΪÕâÒ»ÇиüÒѳÉÏ°¹ß£¡ ÓÐÐĸģ¬¸Ä²»ÄÑ£¬¾ÍÈÃÎÒ·ÅÆúÃÎÀïµÄɳ̲ΪÄú¾«ÐÄ´ò°ç£¬¾ÍÈÃÎÒѧ»áÈËÇéÊÀ¹ÊÌý´ÓÄúÃÀÀöµÄ°²ÅÅ¡£Õ¾ÔÚ´°Ç°ÃÀÀöµÄÅ®º¢£¬ÓÐË­Ô¸ÒâΪÕâÑùÒ»¸öÅ®º¢Èýǧ³è°®£¿ÓÐË­Ô¸ÒâΪÕâÑùÒ»¸öÅ®º¢·ÅÆúÏÖÔÚÈ¥×·ÇóÁíÍâÒ»¸ö¾«²Ê£¿ÓÐË­Ô¸ÒâΪȢÕâÑùÒ»¸öÅ®º¢È·Êµ½ñÉúÎÞº¶£¿Ã£Ã£µÄÈ˺£Çë¸æËßÎÒ×îÕæʵµÄ´ð°¸£¡ ÐÄÒÑÀÛ£¬Ìå¸ü±¹£¬Á÷Âä¹ãÖÝ£¬Ê³ËÞÀ§ÄÑ£¬ÄѵÀÕâЩÕæµÄÊÇÀ´×ÔÌì¹úµÄÕÙ»½£¿£¿ Õ¾ÔÚ´°Ç°µÄÅ®º¢ÁõÔÆ 03Äê9ÔÂ1ÈÕÇ峿ÃÔãÓÚ¹ãÖÝ ÓÖÊÇÔÚÖÔÐĵÄÆÚ´ý£¬ÓÖÊÇÔÚÈ˺£Ñ°ÕҴ𰸡£×òÌ컹ÊÇÑô¹â²ÓÀ㬽ñÌì¾ÍÎÚÔƲ»É¢£¬¹ãÖݵÄÌì˵±ä¾Í±ä£¬Ì¨·ç˵À´¾ÍÀ´¡£¾ÍÊÇÕâÑùÒ»¸öÒ¹Íí£¬ÁõÔÆÄÜ×öʲô£¿Á÷Âä¹ãÖÝ£¬Éú»î¾Ù²½¼èÄÑ£¬ÊÖ»úÒ²ÂôÁË£¬ÏÂÒ»´ÎÎÒ»¹ÄÜÂôʲô£¿´ÓС½¿Éú¹ßÑø£¬´ÓС²»ÖªÇ®ÎªºÎÎ´ÓС¾ÍÒÔΪǮ¾ÍÊÇ¿¨ÀïÃæÓò»ÍêµÄ³®Æ±¡£Ëæן¸Ç×µÄÀëÈ¥£¬¸¸Ç׸øµÄ¿¨Àï¾ÍÔÙҲûÓÐǮͳöÀ´¡£Êǵģ¬¸¸Ç×Ì«°®ÎÒÁË£¬ÒòΪÎÒ²»Ï²»¶Ä°ÉúÈË£¬ËùÒÔ¸¸Ç×Ò²´ÓÀ´²»»á°ÑÄ°ÉúÈË°üÀ¨Ëû¹«Ë¾ÀïµÄÈË´ø»Ø¼Ò£»ÒòΪÎÒÌ«¹ÂƧ£¬ËùÒÔ´ÓÅ®Öе½´óѧ£¬ÎÒҲûÓÐʲô֪ÐĵÄͬ´°ºÃÓÑ¡£ÎÒ×ÜÊÇÒ»¸öÈËĬĬµÄÉú»îÔÚ×Ô¼ºµÄÊÀ½çÀ¿´×ŷ仨ѩÔ£¬¿´×ÅСÊ÷·¢Ñ¿£¬´ÓÖÐд϶ÔÓÚÉúÃüÂúÐĵÄÔÞ̾¡£ Ôø¾­Ò²Ï²»¶¹ýÒ»¸öÄк¢£¬µ«ÊÇËû¾¹È»²»ÏàÐÅÊ¥µ®ÀÏÈ˵ĴæÔÚ£¬¸øËûÒ»ÕÅA4Ö½ÈÃËûÍÚÒ»¸öԲȦ´óµ½¿ÉÒÔ°ÑÁ½¸öÈ˵ÄÄÔ´ü×°½øÈ¥£¬ËûÈ´²»ÖªµÀ¸ÃÔõô×ö£¬Òò´Ë¶þÊ®ÈýÄêÀ´¶¼²»Ôø̸¹ýÁµ°®£¡ Êǵġ£¾ÍÊÇÕâÑùÒ»¸öÅ®º¢£¬¾ÍÊÇÕâÑùÒ»¸öÁõÔÆ£¬Éú»îÔÚÃÎÀïÉú»îÔÚÓëÊÀ¸ô¾øµÄÊÀ½ç£¬Ãæ¶Ô½ñÌìµÄÀ§¾³£¬¸¸Ç×ÓдíÂð£¿Ëû¸øÎÒÌṩ×îºÃµÄÉú»î±£ÕÏ£¬ËûÈÃÎÒ×öÎÒϲ»¶×öµÄÊ£¬ÄѵÀÕâÒ²ÓдíÂð£¿ÁõÔÆÓÖÓдíÂð£¿ÁõÔƲ»Ï²»¶³Ô¼¦È⣬ֻÒòΪ¼¦Èâ»áÈÃÁõÔÆÏëÆ𼦱»É±Ê±¼¦Í´¿àµÄÑÛÀᣬÁõÔÆ¿´µ½½ÖÉÏ×øÔÚµØÉϵÄÀÏÈË£¬ÁõÔÆ»á°ÑÉíÉÏËùÓеÄÇ®¶¼¸øËý¡£ÄѵÀÁõÔÆËùÓеÄÕâÒ»Çж¼ÊÇ´íÎóµÄ±íÏÖ£¿ÒòΪÁõÔƵÄÑÛ¾¦Àï¿´µ½µÄÊÀ½ç¶¼Êǵ¹Á¢µÄÆû³µ¡¢µ¹Á¢µÄÂ¥·¿¡¢µ¹Á¢µÄÈË¡¢ÎÒ¸ú±ðÈ˲»Ò»Ñù£¬ËùÒÔ¸¸Ç×ÈÏΪÎÒ²»ÊôÓÚÕâ¸öÊÀ½ç¡¢ÁõÔÆÄܹ»¸øÕâ¸öÊÀ½ç´øÀ´µÄÊÇÒìÓÚ³£È˵Ä˼άºÍ¹Ûµã¼û½â¡£ÒòΪÕâЩ¸¸Ç×ÈÏΪÎÒÄܹ»°´ÕÕ×Ô¼ºµÄÒâԸȥ×öÊÂÈ¥Éú»îÊÇÉϲԴ͸øÉúÃüµÄ×î´ó±¨´ð¡£¾ÍÊÇÕâÑùÒ»¸öÁõÔÆ£¬Ë­ÄܸæËßÎÒÁõÔÆÓ¦¸ÃÔõô×ö£¿ ʮԣ¬·¨Í¥ÉóÅеÄÈÕ×Ó£¬ÁõÔÆ»áÒÔ²»¼ÇÃûµÄ·½Ê½°Ñ¸¸Ç×ËùÓеIJƲú¾èÔù¸øËùÓÐÏóÁõÔÆÒ»ÑùÎÞÒÀÎÞ¿¿ÐèÒª°ïÖúµÄÉÆÁ¼µÄÈË¡£Í¬Ñù½ñÌìµÄÁõÔÆÉú»îÒ²ºÜ¼èÄÑÒ²ºÜÐèÒª°ïÖú£¬ÁõÔÆÈÏΪ¸øËùÓÐÉÆÁ¼µÄÈËÃÇÓèÒÔÐÐÉƵĻú»á£¬Ò²ÊÇÉϲԴ͸øÁõÔƵÄÉƾ٣¬ÁõÔÆÀÖÒâÒÔÌرðµÄ˼ά´ÓÁíÒ»¸öÊÓ½ÇÈ¥°ïÖúÄÇЩÓÐÀ§»óµÄÉÆÁ¼ÈË£¬½è´ËÖ¤Ã÷ÁõÔÆ´æÔڵļÛÖµ£¡ ÖÔÐÄ×£¸£ËùÓÐÉÆÁ¼µÄÈËÃÇ£¬¸ÐлËùÓÐÔ¸Òâ°ïÖúÁõÔƵÄÉÆÁ¼ÈË£¬½çʱÁõÔÆ»áÒÔÌرðµÄ·½Ê½ÖÂÒÔËùÓÐÔø¾­°ïÖú¹ýÁõÔƵÄÈË×îÉñÃصÄÀñÎÄÇЩºÃÐĵÄÈË¡¢ÄÇЩ²»»á³°Ð¦ÄÇЩÄܹ»Àí½âÊ¥µ®ÀÏÈË´æÔÚµÄÉÆÁ¼ÈË£¡ Êǵģ¬Õ¾ÔÚ´°Ç°µÄÅ®º¢È·Êµ´æÔÚ£¬ÁõÔÆȷʵÉú»îÔÚÕâ¸öÏÖʵµÄÊÀ½çÀ֮ËùÒÔÄúÎÒ²»Í¬ÊÇÒòΪÎÒÃǶ¼Ã»ÓÐÕ¾ÔÚ´°Í⣡Êǵģ¬ÍøÂç³äÂú×ÅÏÝÚåºÍÐé¼Ù£¬ÁõÔÆÒ²¸úÄúÒ»ÑùÑ°ÕÒ×ÅÕæʵµÄÉÆÁ¼£¡ ÕÐÉÌÒøÐÐÒ»¿¨Í¨Õʺţº9555 5020 0150 9251 ¸¸Ç׵Ŀª»§Ãû£ºÁõÒäÏæ Õ¾ÔÚ´°Ç°µÄÅ®º¢ÁõÔÆ Email:cqnvhai@163.com 03Äê9ÔÂ3ÈÕÁ賿 ÎÞÖúÓÚ¹ãÖÝ Êǵģ¬ÁõÔƵÄÈ·ÊÇÒ»¸öºÜÆæ¹ÖµÄÅ®º¢×Ó¡£ Ìý¸¸Ç×˵»¹ÔÚÎÒ3ËêʱÎҾͺÜϲ»¶²ÊÉ«»­Æ¬£¬¿ÉÊǸ¸Ç×È´·¢ÏÖÎÒ×ÜÊÇ°Ñ»­Æ¬µ¹¹ýÀ´¿´£¬ÓÚÊǸ¸Ç׾Ͱѻ­Æ¬×ªÕý¹ýÀ´¸øÎÒ¿´£¬¿ÉÊÇÎÒ»¹ÊÇÒªµ¹¹ýÀ´¿´¡£¸¸Ç׾ͻ³ÒÉÎÒµÄÑÛ¾¦³öÁË벡¾Í´øÎÒÈ¥¿´Ò½Éú¡£Ò½ÉúµÄ½áÂÛÊÇ£ºº¢×Ó°ÑͼƬµ¹¹ýÀ´¿´µÄÏÖÏ󣬳ÆΪµ¹ÊÓ¡£µ¹ÊÓÊÇÒ»ÖÖһʱÐÔÉúÀíÏÖÏó£¬ÎÒÃǵÄÑÛÇòÏñÒ»¼ÜÕÕÏà»ú£¬Íâ½çÎïÌåµÄ¹âÏߣ¬¾­¹ý¾Û½¹ºó£¬ÔÚÊÓÍøĤ£¨Ï൱ÓÚÕÕÏà»úµÄµ×Ƭ£©ÉÏÐγÉÒ»¸öµ¹Ïñ¡£µ«ÊÇ£¬Õâ¸öµ¹Ïñ´«µ¼µ½´óÄÔµÄÊÓ¾õÖÐÊ࣬¾­¹ý×ۺϷÖÎö£¬µ¹Ïñ±ã±»¾ÀÕýÁË¡£3ËêÒÔϵÄÓ׶ù£¬ÓÉÓÚÆä´óÄÔƤÖʹ¦ÄÜÉÐδ·¢Óý½¡È«£¬È±·¦ÍêÉƵÄ×ۺϷÖÎöÄÜÁ¦£¬ËùÒÔËûÃÇ¿´µ½µÄͼÏñ¶¼Êǵ¹µÄ£¬Ö»Óаѻ­Æ¬µ¹¹ýÀ´¿´£¬²ÅÄܸÐÊܵ½ÕýλµÄÎïÏñ¡£²»¹ý£¬Õâ¶Îʱ¼äºÜ¶Ì£¬Ëæ×Å´óÄÔƤÖʹ¦ÄÜÍêÉÆ£¬µ¹ÊÓÏÖÏó¾Í×ÔÈ»¶øÈ»ÏûʧÁË¡£ ¿ÉÊÇÕâ¸öʱ¼ä¶ÔÓÚÁõÔÆÈ´ÊÇÓÀÔ¶£¬Ö±µ½½ñÌìÁõÔÆ¿´ÊÀ½ç£¬»¹Êǵ¹×ŵġ£µ¹×ŵķ¿×Ó¡¢µ¹×ŵÄÂí·¡¢µ¹×ŵÄÐÐÈË¡¢Ìì¿Õ°ÑÒ»ÇÐÍùµØÉÏÍÆ£¬·É»úµôÔÚÌì¿ÕÀÄñ¶ùÔÚŬÁ¦µÄ°ÚÍÑÌì¿ÕµÄÊø¸¿£¬Ò»ÇеÄÒ»ÇÐÔÚÁõÔÆ¿´À´×ÜÊÇÓëÖÚ²»Í¬¡£ÁõÔÆÉõÖÁ²»ÄÜ·Ö±æ³öÉÏÏÂ×óÓÒ£¬ÁõÔƹýÂí·½Ï³£È˶¼»áÊÇÒ»¸öΣÏյľٶ¯£¬ºÜ¶àÊÂÇéÔÚ³£ÈË¿´À´ÊÇÀíËùµ±È»µÄÊÂÇ飬¿ÉÊÇÁõÔÆ»áÓв»Í¬µÄ¿´·¨¡£Ò²ÐíÕâ¾ÍÊÇÁõÔƵÄÌرð£¬Ò²ÐíÕâ¾ÍÊÇÁõÔƶà³îÉƸеÄÓÉÀ´¡£ÁõÔÆÖªµÀ×Ô¼º²»ÊʺϹ¤×÷£¬¸úÆäËûÈ˳ª·´µ÷ÊDz»ÊʺϹ¤×÷µÄ¡£ ¾ÍÊÇÕâÑùµÄÒ»¸öÁõÔÆ£¬Ë­ÄܸæËßÎÒÎÒÄÜ×öʲô£¿Ë­ÄܸæËßÎÒÎÒ¸ÃÔõô×ö£¿¾ÍÊÇÕâÑùÒ»¸ö»îÉúÉúµÄÁõÔÆ£¬µ½µ×¸ÃºÎÈ¥ºÎ´Ó£¿Ê§È¥¸¸Ç×µÄÈÕ×Ó£¬ÓÐË­Äܹ»Àí½âÓÐË­Ô¸ÒâÏàÐÅÓÐË­Ô¸ÒâºÇ»¤ÓÐË­Ô¸Òâ³è°®£¿¾ÍÊÇÕâÑùµÄÒ»¸öÅ®º¢£¬¾ÍÊÇÕâÑùÒ»¸öÆæ¹ÖµÄÅ®º¢£¬È·Êµ»îÉúÉúµÄ´æÔÚ£¡ ÐÄÀÛÁË£¬Á÷Âä¹ãÖÝȷʵÀÛÁË£¬Óþ¡ÁËÅ̲ø£¬ÄÄÀïÊǸÛÍ壿ÄÄÀïÊǹéËÞ£¿ µ±Ê§ÂäµÄʱºò¡¢µ±ÉËÐĵÄʱºò¡¢µ±±ËÁÙ¾øÍûµÄʱºò£¬ÄúÎÒÏàͬµÄµØ·½Ò²Ðí¶¼»á°ÑÏ£Íû¼ÄÍиøδÀ´£¬Î´ÖªµÄδÀ´£¡ÊǵÄÕ¾ÔÚ´°Ç°µÄÅ®º¢ÔÚ¿à¿àµÄÑ°ÕҴ𰸣¡ Õ¾ÔÚ´°Ç°µÄÅ®º¢ÁõÔÆ 03Äê9ÔÂ7ÈÕÉîÒ¹ÓÚ¹ãÖÝ http://www.blogcn.com/blog/?u=cqnvhai Email:cqnvhai@163.com From joel.soete@tiscali.be Wed Sep 10 13:14:47 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Wed, 10 Sep 2003 12:14:47 +0000 Subject: [parisc-linux] cvs pserver access pb? Message-ID: <3F5F15B7.7060103@tiscali.be> Hi pa, cvs [update aborted]: connect to cvs.parisc-linux.org(192.25.206.14):2401 failed: Connection timed out Thanks in advance for help, Joel From willy@debian.org Wed Sep 10 13:21:13 2003 From: willy@debian.org (Matthew Wilcox) Date: Wed, 10 Sep 2003 13:21:13 +0100 Subject: [parisc-linux] cvs pserver access pb? In-Reply-To: <3F5F15B7.7060103@tiscali.be> References: <3F5F15B7.7060103@tiscali.be> Message-ID: <20030910122113.GS18654@parcelfarce.linux.theplanet.co.uk> On Wed, Sep 10, 2003 at 12:14:47PM +0000, Joel Soete wrote: > cvs [update aborted]: connect to > cvs.parisc-linux.org(192.25.206.14):2401 failed: Connection timed out It went down last night shortly after I went to bed. We're waiting for someone in Fort Collins to get in and reboot it. I would guess that's 2-3 hours from now. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From joel.soete@tiscali.be Wed Sep 10 13:42:12 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Wed, 10 Sep 2003 12:42:12 +0000 Subject: [parisc-linux] cacheflush.h patch? Message-ID: <3F5F1C24.8060205@tiscali.be> Hi Randolph, As you may already read before, I experiment pb with SMP kernel 2.4 on a N server and we suspect a tlb management pb. On the other hand, I read your patch: http://lists.parisc-linux.org/pipermail/parisc-linux-cvs/2003-September/033367.html May I ask you more details on the reason of this patch? Could (would) it be back-ported to 2.4? Thanks in advance, Joel From sebastian.brueckner@epost.de Wed Sep 10 14:19:21 2003 From: sebastian.brueckner@epost.de (Sebastian Brueckner) Date: Wed, 10 Sep 2003 15:19:21 +0200 Subject: [parisc-linux] HP B132L hangs Message-ID: <3F5F24D9.7030800@epost.de> Hi! In the last few days the B132l I use as DSL router completely hung 3 times. Every time requiring a power cycle to revive it. It is running Debian testing with kernel 2.4.18-hppa. To test the machine I tried to compile a new kernel. After compiling a few files everything hung and spit out the following messages: scsi0: (2:0) Synchronous at offset 8, period 100ns scsi0: (2:0), UNEXPECTED PHASE after command phase (CD BSY REQ CMD_OUT) len = 6, cmd =Read (10) 00 00 35 e2 00 00 00 18 00 scsi0: Bus Reset detected, executing command 10081c00, slot 00010520, dsp 000902 failing command because of reset, slot 00010520, cmnd 10081c00 failing command because of reset, slot 00010654, cmnd 10081a00 failing command because of reset, slot 00010788, cmnd 10081800 failing command because of reset, slot 000108bc, cmnd 10081600 failing command because of reset, slot 000109f0, cmnd 10081400 failing command because of reset, slot 00010b24, cmnd 10081200 failing command because of reset, slot 00010c58, cmnd 10081000 failing command because of reset, slot 00010d8c, cmnd 10082e00 failing command because of reset, slot 00010ec0, cmnd 10082c00 failing command because of reset, slot 00010ff4, cmnd 10082a00 failing command because of reset, slot 00011128, cmnd 10082800 failing command because of reset, slot 0001125c, cmnd 10082600 failing command because of reset, slot 00011390, cmnd 10082400 failing command because of reset, slot 000114c4, cmnd 10082200 failing command because of reset, slot 000115f8, cmnd 10082000 failing command because of reset, slot 0001172c, cmnd 100a4e00 scsi0: (2:0) Synchronous at offset 8, period 100ns scsi0: (2:0), UNEXPECTED PHASE after command phase (CD BSY REQ CMD_OUT) len = 6, cmd =Read (10) 00 00 35 e2 00 00 00 18 00 scsi0: Bus Reset detected, executing command 10081c00, slot 00010520, dsp 000902 failing command because of reset, slot 00010520, cmnd 10081c00 failing command because of reset, slot 00010654, cmnd 10081a00 failing command because of reset, slot 00010788, cmnd 10081800 ... and so on and so forth ... The power seitch does nothing, only power cycling helps. I tried compiling the kernel again with the same results... What do these messages mean? Is the hd defective or is it some problem with the scsi bus? The machine worked flawlessly for half a year... I have no idea what went wrong! Thanks in advance, Sebastian From joel.soete@tiscali.be Wed Sep 10 14:55:26 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Wed, 10 Sep 2003 13:55:26 +0000 Subject: [parisc-linux] HP B132L hangs In-Reply-To: <3F5F24D9.7030800@epost.de> References: <3F5F24D9.7030800@epost.de> Message-ID: <3F5F2D4E.7040700@tiscali.be> Sebastian Brueckner wrote: > Hi! > > In the last few days the B132l I use as DSL router completely hung 3 > times. Every time requiring a power cycle to revive it. It is running > Debian testing with kernel 2.4.18-hppa. > > To test the machine I tried to compile a new kernel. After compiling a > few files everything hung and spit out the following messages: > > scsi0: (2:0) Synchronous at offset 8, period 100ns > scsi0: (2:0), UNEXPECTED PHASE after command phase (CD BSY REQ CMD_OUT) > len = 6, cmd =Read (10) 00 00 35 e2 00 00 00 18 00 > scsi0: Bus Reset detected, executing command 10081c00, slot 00010520, > dsp 000902 failing command because of reset, slot 00010520, cmnd 10081c00 > failing command because of reset, slot 00010654, cmnd 10081a00 > failing command because of reset, slot 00010788, cmnd 10081800 > failing command because of reset, slot 000108bc, cmnd 10081600 > failing command because of reset, slot 000109f0, cmnd 10081400 > failing command because of reset, slot 00010b24, cmnd 10081200 > failing command because of reset, slot 00010c58, cmnd 10081000 > failing command because of reset, slot 00010d8c, cmnd 10082e00 > failing command because of reset, slot 00010ec0, cmnd 10082c00 > failing command because of reset, slot 00010ff4, cmnd 10082a00 > failing command because of reset, slot 00011128, cmnd 10082800 > failing command because of reset, slot 0001125c, cmnd 10082600 > failing command because of reset, slot 00011390, cmnd 10082400 > failing command because of reset, slot 000114c4, cmnd 10082200 > failing command because of reset, slot 000115f8, cmnd 10082000 > failing command because of reset, slot 0001172c, cmnd 100a4e00 > scsi0: (2:0) Synchronous at offset 8, period 100ns > scsi0: (2:0), UNEXPECTED PHASE after command phase (CD BSY REQ CMD_OUT) > len = 6, cmd =Read (10) 00 00 35 e2 00 00 00 18 00 > scsi0: Bus Reset detected, executing command 10081c00, slot 00010520, > dsp 000902 failing command because of reset, slot 00010520, cmnd 10081c00 > failing command because of reset, slot 00010654, cmnd 10081a00 > failing command because of reset, slot 00010788, cmnd 10081800 > > ... and so on and so forth ... > > The power seitch does nothing, only power cycling helps. I tried > compiling the kernel again with the same results... > > What do these messages mean? Is the hd defective or is it some problem > with the scsi bus? Yes it looks like a disk becoming defective. The best way to be sure is to use a hp cdrom containing Diagnostic tools (iirc the last hpux support + would contains it). This cd is bootable and contains tools allowing you test your disk. If you have another system on which you can connect your suspected disk you can also try a dd cmd like: dd if=/dev/rdsk/c0txd0 of=/dev/null bs=2048k (where you replace /dev/rdsk/c0txd0 by the actual disk path) > > The machine worked flawlessly for half a year... I have no idea what > went wrong! It seems to confirm your suspition (i have to manage remotely some 300 hp server: a few b132, b180, b2000, A500, K250, L, N and a lot of D; and the most peaces we have to replace are disk becoming defective) hth, joel From James.Bottomley@HansenPartnership.com Wed Sep 10 16:45:09 2003 From: James.Bottomley@HansenPartnership.com (James Bottomley) Date: 10 Sep 2003 11:45:09 -0400 Subject: [parisc-linux] HP B132L hangs In-Reply-To: <3F5F24D9.7030800@epost.de> References: <3F5F24D9.7030800@epost.de> Message-ID: <1063208722.1984.10.camel@mulgrave> On Wed, 2003-09-10 at 09:19, Sebastian Brueckner wrote: > scsi0: (2:0) Synchronous at offset 8, period 100ns > scsi0: (2:0), UNEXPECTED PHASE after command phase (CD BSY REQ CMD_OUT) > len = 6, cmd =Read (10) 00 00 35 e2 00 00 00 18 00 That's a residue of an incorrect lasi700 driver. Notice it thinks the length is six for a ten byte command. This has long been fixed in the linux-2.4 PA tree (er, I think---I've been concentrating on 2.6 mainly). However, something higher up in the trace you don't attach caused the actual problem that this is a response to (It's caused by the SCSI mid layer putting the wrong command length back *after* error recovery, so your true root cause is the error that first started this). James From joel.soete@tiscali.be Wed Sep 10 17:17:05 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Wed, 10 Sep 2003 16:17:05 +0000 Subject: [parisc-linux] cvs pserver access pb? In-Reply-To: <20030910122113.GS18654@parcelfarce.linux.theplanet.co.uk> References: <3F5F15B7.7060103@tiscali.be> <20030910122113.GS18654@parcelfarce.linux.theplanet.co.uk> Message-ID: <3F5F4E81.6060205@tiscali.be> Matthew Wilcox wrote: >On Wed, Sep 10, 2003 at 12:14:47PM +0000, Joel Soete wrote: > > >>cvs [update aborted]: connect to >>cvs.parisc-linux.org(192.25.206.14):2401 failed: Connection timed out >> >> > >It went down last night shortly after I went to bed. We're waiting for >someone in Fort Collins to get in and reboot it. I would guess that's >2-3 hours from now. > > > Just back now :) Joel From kaol@informatik.rwth-aachen.de Wed Sep 10 17:29:18 2003 From: kaol@informatik.rwth-aachen.de (kaol@informatik.rwth-aachen.de) Date: Wed, 10 Sep 2003 16:29:18 +0000 Subject: [parisc-linux] Re: new mail 3Od3cbcLFZ In-Reply-To: References: Message-ID: XNltMjNTwqUaIEwqU59MwwX6Bmle6pZ4fky English version | Ðóññêèé âàðèàíò Ìû ðàäû ïðåäëîæèòü âàì íîâûé áåñïëàòíûé ïî÷òîâûé ñåðâèñ http://www.mail15.com. Åãî îòëè÷èòåëüíûå îñîáåííîñòè: 1) ðàçìåð ÿùèêà 15 ìá; 2) çàùèùåííîñòü è íàäåæíîñòü; 3) âîçìîæíîñòü èñïîëüçîâàíèÿ ëþáûõ ïî÷òîâûõ ïðîãðàìì(POP,IMAP,SMTP); 4) äîñòóï èç ëþáîãî ìåñòà â ëþáîå âðåìÿ; 5) ïðîñòîé è äîñòóïíûé âåáèíòåðôåéñ ñ ÏÎËÍÛÌ ÎÒÑÓÒÑÒÂÈÅÌ ÐÅÊËÀÌÛ; 6) àíòèâèðóñíûé è àíòèñïàìîâûé êîíòðîëü; 7) ìãíîâåííàÿ ïåðåñûëêà ïî÷òû. ************* We are glad to invite you at new free mail service http://www.mail15.com. The advantages of this service are: 1) mailbox, up to 15 Mb; 2) absolute privacy and high reliability; 3) ability to use mail clients (POP3, IMAP4, SMTP); 4) access from anywhere, anytime; 5) flexible light-weight web interface without advertising banners; 6) antivirus and antispam control; 7) fast mail transfer; 8) high speed network channel; 9) flexible light-weight web interface; 10) wide spread ability of mail filtering and forwarding mail; 11) clock around support; 2GmVdNPmxvTZoZ8cvE9BgxYuEntIDO hGvECItr60XZZmY8zuMI53g4yVr2E6RVMnzo72Qd From sebastian.brueckner@epost.de Wed Sep 10 19:47:36 2003 From: sebastian.brueckner@epost.de (=?ISO-8859-15?Q?Sebastian_Br=FCckner?=) Date: Wed, 10 Sep 2003 20:47:36 +0200 Subject: [parisc-linux] HP B132L hangs In-Reply-To: <1063208722.1984.10.camel@mulgrave> References: <3F5F24D9.7030800@epost.de> <1063208722.1984.10.camel@mulgrave> Message-ID: <3F5F71C8.7060605@epost.de> James Bottomley schrieb: > That's a residue of an incorrect lasi700 driver. Notice it thinks the > length is six for a ten byte command. This has long been fixed in the > linux-2.4 PA tree (er, I think---I've been concentrating on 2.6 > mainly). Hrm... I installed the latest available kernel image (2.4.20-32) and it worked - only compiling seems to raise the error... strange! > However, something higher up in the trace you don't attach caused the > actual problem that this is a response to (It's caused by the SCSI mid > layer putting the wrong command length back *after* error recovery, so > your true root cause is the error that first started this). I ran make-kpkg again and this time captured the first messages: /usr/bin/make -C scsi fastdep make[6]: Entering directory `/usr/src/linux-2.4.22/drivers/scsi' gcc -D__KERNEL__ -I/usr/src/linux-2.4.22/include -Wall -Wstrict-prototypes -Wnoc | /sbin/genksyms -k 2.4.22 > /usr/src/linux-2.4.22/include/linux/modules/scsi_p mv /usr/src/linux-2.4.22/include/linux/modules/scsi_syms.ver.tmp /usr/src/linuxr gcc -D__KERNEL__ -I/usr/src/linux-2.4.22/include -Wall -Wstrict-prototypes -Wnoc | /sbin/genksyms -k 2.4.22 > /usr/src/linux-2.4.22/include/linux/modules/53c70p 53c700.c:163:22: 53c700_d.h: No such file or directory mv /usr/src/linux-2.4.22/include/linux/modules/53c700.ver.tmp /usr/src/linux-2.r /usr/src/linux-2.4.22/scripts/mkdep -D__KERNEL__ -I/usr/src/linux-2.4.22/includm vme16x.c mvme16xInfo fld=0x35e1fb.h ncr53c8xx.c n, cr53c8xx.h nsp32Current .c nr _debug.c nsp32_iAdditional sense indicates Unrecovered read error o.h oktagon_esp. I/O error: dev 08:04, sector 3182320 c oktagon_esp.h scsi0: (2:0), UNEXPECTED PHASE after command phase (CD BSY REQ ) len = 6, cmd =Read (10) 00 00 35 e2 00 00 00 18 00 scsi0: Bus Reset detected, executing command 10081c00, slot 00010520, dsp 00090] failing command because of reset, slot 00010520, cmnd 10081c00 oktagon_io.S ossscsi0: (2:0) Synchronous at offset 8, period 100ns t.c osst.h osst_detect.h osst_options.h pas16.c pas16.h pci2000.c pci2000.h pci) len = 6, cmd =Read (10) 00 00 35 e2 00 00 00 18 00 scsi0: Bus Reset detected, executing command 10081c00, slot 00010520, dsp 00090] failing command because of reset, slot 00010520, cmnd 10081c00 qlogicpti.h qlogscsi0: (2:0) Synchronous at offset 8, period 100ns icpti_asm.c scsi.c scsi.h scsi_debug.c scsi_debug.h scsi_dma.c scsi_error.c scs) len = 6, cmd =Read (10) 00 00 35 e2 00 00 00 18 00 scsi0: Bus Reset detected, executing command 10081c00, slot 00010520, dsp 00090] failing command because of reset, slot 00010520, cmnd 10081c00 710_d.h sim710_uscsi0: (2:0) Synchronous at offset 8, period 100ns .h sr.c sr.h sr_ioctl.c sr_vendor.c st.c st.h st_options.h sun3_NCR5380.c sun3_) len = 6, cmd =Read (10) 00 00 35 e2 00 00 00 18 00 scsi0: Bus Reset detected, executing command 10081c00, slot 000109f0, dsp 00090] failing command because of reset, slot 00010520, cmnd 10081a00 failing command because of reset, slot 00010654, cmnd 10081800 failing command because of reset, slot 00010788, cmnd 10082800 failing command because of reset, slot 000108bc, cmnd 10081000 failing command because of reset, slot 000109f0, cmnd 10081c00 failing command because of reset, slot 00010b24, cmnd 10082e00 failing command because of reset, slot 00010c58, cmnd 10081200 failing command because of reset, slot 00010d8c, cmnd 10082a00 failing command because of reset, slot 00010ec0, cmnd 10082600 failing command because of reset, slot 00010ff4, cmnd 10081600 failing command because of reset, slot 00011128, cmnd 10082200 failing command because of reset, slot 0001125c, cmnd 10082c00 failing command because of reset, slot 00011390, cmnd 10081400 failing command because of reset, slot 000114c4, cmnd 10082400 failing command because of reset, slot 000115f8, cmnd 10082000 failing command because of reset, slot 0001172c, cmnd 100a4e00 7000.c wd7000.h scsi0: (2:0) Synchronous at offset 8, period 100ns zalon7xx.c zalon7xx.h > .depend scsi0: (2:0), UNEXPECTED PHASE after command phase (CD BSY REQ CMD_OUT) len = 6, cmd =Read (10) 00 00 35 e2 00 00 00 18 00 scsi0: Bus Reset detected, executing command 10081c00, slot 00010520, dsp 00090] failing command because of reset, slot 00010520, cmnd 10081c00 failing command because of reset, slot 00010654, cmnd 10081a00 failing command because of reset, slot 00010788, cmnd 10081800 failing command because of reset, slot 000108bc, cmnd 10081600 failing command because of reset, slot 000109f0, cmnd 10081400 failing command because of reset, slot 00010b24, cmnd 10081200 failing command because of reset, slot 00010c58, cmnd 10081000 failing command because of reset, slot 00010d8c, cmnd 10082e00 failing command because of reset, slot 00010ec0, cmnd 10082c00 failing command because of reset, slot 00010ff4, cmnd 10082a00 failing command because of reset, slot 00011128, cmnd 10082800 failing command because of reset, slot 0001125c, cmnd 10082600 failing command because of reset, slot 00011390, cmnd 10082400 failing command because of reset, slot 000114c4, cmnd 10082200 failing command because of reset, slot 000115f8, cmnd 10082000 failing command because of reset, slot 0001172c, cmnd 100a4e00 ... I will try the newer kernel now... However "Unrecovered read error" sounds very much like a bad disk for me so I suppose it will not help... cu, Sebastian From willy@debian.org Wed Sep 10 19:58:34 2003 From: willy@debian.org (Matthew Wilcox) Date: Wed, 10 Sep 2003 19:58:34 +0100 Subject: [parisc-linux] HP B132L hangs In-Reply-To: <3F5F71C8.7060605@epost.de> References: <3F5F24D9.7030800@epost.de> <1063208722.1984.10.camel@mulgrave> <3F5F71C8.7060605@epost.de> Message-ID: <20030910185834.GC21596@parcelfarce.linux.theplanet.co.uk> On Wed, Sep 10, 2003 at 08:47:36PM +0200, Sebastian Brückner wrote: > I installed the latest available kernel image (2.4.20-32) and it worked > - only compiling seems to raise the error... strange! > > I ran make-kpkg again and this time captured the first messages: Could you redirect the output from make-kpkg to a file or /dev/null so the messages from the compilation aren't interleaved with the kernel messages. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From grundler@parisc-linux.org Thu Sep 11 06:14:09 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 10 Sep 2003 23:14:09 -0600 Subject: [parisc-linux] login timeout? Message-ID: <20030911051409.GA21174@dsl2.external.hp.com> console login on my a500 running 2.6.0-test5-pa0 says: Debian GNU/Linux testing/unstable ion ttyS0 ion login: ooro Password: Login incorrect ion login: Login timed out after 60 seconds. Debian GNU/Linux testing/unstable ion ttyS0 ion login: This looks normal but the timeout occurs in about 5 seconds. Something is broken. config/vmlinux/etc uploaded to ftp://ftp.parisc-linux.org/kernels/a500/2.6.0-test5-pa0.tgz grant From sebastian.brueckner@epost.de Thu Sep 11 16:03:55 2003 From: sebastian.brueckner@epost.de (=?ISO-8859-1?Q?Sebastian_Br=FCckner?=) Date: Thu, 11 Sep 2003 17:03:55 +0200 Subject: [parisc-linux] HP B132L hangs In-Reply-To: <20030910185834.GC21596@parcelfarce.linux.theplanet.co.uk> References: <3F5F24D9.7030800@epost.de> <1063208722.1984.10.camel@mulgrave> <3F5F71C8.7060605@epost.de> <20030910185834.GC21596@parcelfarce.linux.theplanet.co.uk> Message-ID: <3F608EDB.101@epost.de> Matthew Wilcox schrieb: > Could you redirect the output from make-kpkg to a file or /dev/null so the > messages from the compilation aren't interleaved with the kernel messages. I tried to backup the system and got the a similar error with very few messages mixed into it. Maybe this is better readable: b132l:~# tar c / | ssh -l sb 192.168.0.2 'gzip -f > root.tar.gz' tar: Removing leading `/' from member names sb@192.168.0.2's password: scsi0: ERROR on channel 0, id 2, lun 0, CDB: Request Sense 00 00 00 40 00 Info fld=0x39a27b, Current sd08:04: sense key Medium Error Additional sense indicates Unrecovered read error I/O error: dev 08:04, sector 3428208 tar: /usr/share/consolefonts/lat1-08.psf.gz: Read error at byte 0, reading 1024 bytes: Input/output error scsi0: ERROR on channel 0, id 2, lun 0, CDB: Request Sense 00 00 00 40 00 Info fld=0x39a5e4, Current sd08:04: sense key Medium Error Additional sense indicates Unrecovered read error I/O error: dev 08:04, sector 3429080 scsi0: (2:0), UNEXPECTED PHASE after command phase (CD BSY REQ CMD_OUT) len = 6, cmd =Read (10) 00 00 39 a5 e8 00 00 a0 00 scsi0: Bus Reset detected, executing command 10081c00, slot 00010ff4, dsp 00090210[0210] failing command because of reset, slot 00010ff4, cmnd 10081c00 scsi0: (2:0) Synchronous at offset 8, period 100ns scsi0: (2:0), UNEXPECTED PHASE after command phase (CD BSY REQ CMD_OUT) len = 6, cmd =Read (10) 00 00 39 a5 e8 00 00 a0 00 scsi0: Bus Reset detected, executing command 10081c00, slot 00010520, dsp 00090210[0210] failing command because of reset, slot 00010520, cmnd 10081c00 failing command because of reset, slot 00010ff4, cmnd 10081a00 failing command because of reset, slot 000115f8, cmnd 10081800 scsi0: (2:0) Synchronous at offset 8, period 100ns scsi0: (2:0), UNEXPECTED PHASE after command phase (CD BSY REQ CMD_OUT) len = 6, cmd =Read (10) 00 00 39 a5 e8 00 00 a0 00 scsi0: Bus Reset detected, executing command 10081c00, slot 00010520, dsp 00090210[0210] failing command because of reset, slot 00010520, cmnd 10081c00 failing command because of reset, slot 00010ff4, cmnd 10081a00 failing command because of reset, slot 000115f8, cmnd 10081800 scsi0: (2:0) Synchronous at offset 8, period 100ns scsi0: (2:0), UNEXPECTED PHASE after command phase (CD BSY REQ CMD_OUT) len = 6, cmd =Read (10) 00 00 39 a5 e8 00 00 a0 00 scsi0: Bus Reset detected, executing command 10081c00, slot 00010520, dsp 00090210[0210] failing command because of reset, slot 00010520, cmnd 10081c00 failing command because of reset, slot 00010ff4, cmnd 10081a00 failing command because of reset, slot 000115f8, cmnd 10081800 scsi0: (2:0) Synchronous at offset 8, period 100ns scsi0: (2:0), UNEXPECTED PHASE after command phase (CD BSY REQ CMD_OUT) len = 6, cmd =Read (10) 00 00 39 a5 e8 00 00 a0 00 cu, Sebastian From sebastian.brueckner@epost.de Thu Sep 11 16:33:10 2003 From: sebastian.brueckner@epost.de (=?ISO-8859-1?Q?Sebastian_Br=FCckner?=) Date: Thu, 11 Sep 2003 17:33:10 +0200 Subject: [parisc-linux] HP B132L hangs In-Reply-To: <3F5F2D4E.7040700@tiscali.be> References: <3F5F24D9.7030800@epost.de> <3F5F2D4E.7040700@tiscali.be> Message-ID: <3F6095B6.7050706@epost.de> Joel Soete: > Yes it looks like a disk becoming defective. The best way to be sure is > to use a hp cdrom containing Diagnostic tools (iirc the last hpux > support + would contains it). This cd is bootable and contains tools > allowing you test your disk. I don't have such a cd... I have only two HP cd sets: "HP-UX Applications/Patches 10.20" 5 CDs "Additional Core Enhancements HP-UX 10.20 Workstations" 1 CD Do you know if one of them contains these tools? > If you have another system on which you can connect your suspected disk > you can also try a dd cmd like: > dd if=/dev/rdsk/c0txd0 of=/dev/null bs=2048k (where you replace > /dev/rdsk/c0txd0 by the actual disk path) See my other post for results of backup... it provoced the same (or at least a similar) error :-/ I do not currently have another system I could put the disk in (I got a C200 but it is not in a working state right now). The disk does not contain too important data - but it was a lot of work to set up the router. thx, Sebastian From willy@debian.org Thu Sep 11 19:11:35 2003 From: willy@debian.org (Matthew Wilcox) Date: Thu, 11 Sep 2003 19:11:35 +0100 Subject: [parisc-linux] [PATCH] zalon & ncr53c8xx cleanups Message-ID: <20030911181135.GN21596@parcelfarce.linux.theplanet.co.uk> I don't actually have a zalon machine to test these on, but they seem right to me, and compile fine. Some cleanups for ncr53c8xx & zalon: - Inline zalon.h into zalon.c - Rationalise (a little) ncr53c8xx.c's includes - Remove all the version checks - Stop using remap_pci_mem & unmap_pci_mem & delete their definitions. - Use mb() instead of custom inline asm for MEMORY_BARRIER. Index: drivers/scsi/ncr53c8xx.c =================================================================== RCS file: /var/cvs/linux-2.6/drivers/scsi/ncr53c8xx.c,v retrieving revision 1.4 diff -u -p -r1.4 ncr53c8xx.c --- drivers/scsi/ncr53c8xx.c 8 Sep 2003 21:42:20 -0000 1.4 +++ drivers/scsi/ncr53c8xx.c 11 Sep 2003 18:04:23 -0000 @@ -115,64 +115,32 @@ **========================================================== */ -#include - -#include -#include -#include -#include -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,17) -#include -#elif LINUX_VERSION_CODE >= KERNEL_VERSION(2,1,93) -#include -#endif +#include #include -#include -#include -#include -#include #include +#include +#include #include -#include -#include #include +#include +#include +#include +#include +#include +#include +#include +#include #include #include -#include - -#include - -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,1,35) -#include -#endif - -#ifndef __init -#define __init -#endif -#ifndef __initdata -#define __initdata -#endif +#include -#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,1,92) -#include -#endif +#include +#include +#include #include "scsi.h" #include "hosts.h" -#include - -/* -** Define BITS_PER_LONG for earlier linux versions. -*/ -#ifndef BITS_PER_LONG -#if (~0UL) == 0xffffffffUL -#define BITS_PER_LONG 32 -#else -#define BITS_PER_LONG 64 -#endif -#endif - #include "ncr53c8xx.h" /* @@ -1028,9 +996,7 @@ struct ncb { /* when lcb is not allocated. */ Scsi_Cmnd *done_list; /* Commands waiting for done() */ /* callback to be invoked. */ -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,1,93) spinlock_t smp_lock; /* Lock for SMP threading */ -#endif /*---------------------------------------------------------------- ** Chip and controller indentification. @@ -3739,7 +3705,7 @@ ncr_attach (Scsi_Host_Template *tpnt, in if(device->slot.base_v) np->vaddr = device->slot.base_v; else - np->vaddr = remap_pci_mem(device->slot.base_c, (u_long) 128); + np->vaddr = (unsigned long)ioremap(device->slot.base_c, 128); if (!np->vaddr) { printk(KERN_ERR @@ -3809,11 +3775,7 @@ ncr_attach (Scsi_Host_Template *tpnt, in instance->max_id = np->maxwide ? 16 : 8; instance->max_lun = SCSI_NCR_MAX_LUN; #ifndef SCSI_NCR_IOMAPPED -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,29) instance->base = (unsigned long) np->reg; -#else - instance->base = (char *) np->reg; -#endif #endif instance->irq = device->slot.irq; instance->unique_id = device->slot.io_port; @@ -9199,28 +9161,13 @@ printk("ncr53c8xx_proc_info: hostno=%d, /*========================================================== ** -** /proc directory entry. -** -**========================================================== -*/ -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,27) -static struct proc_dir_entry proc_scsi_ncr53c8xx = { - PROC_SCSI_NCR53C8XX, 9, NAME53C8XX, - S_IFDIR | S_IRUGO | S_IXUGO, 2 -}; -#endif - -/*========================================================== -** ** Boot command line. ** **========================================================== */ #ifdef MODULE char *ncr53c8xx = 0; /* command line passed by insmod */ -# if LINUX_VERSION_CODE >= KERNEL_VERSION(2,1,30) MODULE_PARM(ncr53c8xx, "s"); -# endif #endif int __init ncr53c8xx_setup(char *str) @@ -9228,10 +9175,8 @@ int __init ncr53c8xx_setup(char *str) return sym53c8xx__setup(str); } -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,13) #ifndef MODULE __setup("ncr53c8xx=", ncr53c8xx_setup); -#endif #endif /*=================================================================== Index: drivers/scsi/sym53c8xx_comm.h =================================================================== RCS file: /var/cvs/linux-2.6/drivers/scsi/sym53c8xx_comm.h,v retrieving revision 1.1 diff -u -p -r1.1 sym53c8xx_comm.h --- drivers/scsi/sym53c8xx_comm.h 29 Jul 2003 17:01:30 -0000 1.1 +++ drivers/scsi/sym53c8xx_comm.h 11 Sep 2003 18:03:22 -0000 @@ -74,9 +74,7 @@ **========================================================== */ -#if LINUX_VERSION_CODE >= LinuxVersionCode(2,3,47) #define SCSI_NCR_DYNAMIC_DMA_MAPPING -#endif /*========================================================== ** @@ -262,8 +260,6 @@ static inline struct xpt_quehead *xpt_re **========================================================== */ -#if LINUX_VERSION_CODE >= LinuxVersionCode(2,2,0) - typedef struct pci_dev *pcidev_t; typedef struct device *device_t; #define PCIDEV_NULL (0) @@ -276,17 +272,7 @@ typedef struct device *device_t; static u_long __init pci_get_base_cookie(struct pci_dev *pdev, int index) { - u_long base; - -#if LINUX_VERSION_CODE > LinuxVersionCode(2,3,12) - base = pdev->resource[index].start; -#else - base = pdev->base_address[index]; -#if BITS_PER_LONG > 32 - if ((base & 0x7) == 0x4) - *base |= (((u_long)pdev->base_address[++index]) << 32); -#endif -#endif + u_long base = pdev->resource[index].start; return (base & ~0x7ul); } @@ -310,102 +296,6 @@ pci_get_base_address(struct pci_dev *pde #undef PCI_BAR_OFFSET } -#else /* Incomplete emulation of current PCI code for pre-2.2 kernels */ - -typedef unsigned int pcidev_t; -typedef unsinged int device_t; -#define PCIDEV_NULL (~0u) -#define PciBusNumber(d) ((d)>>8) -#define PciDeviceFn(d) ((d)&0xff) -#define __PciDev(busn, devfn) (((busn)<<8)+(devfn)) - -#define pci_read_config_byte(d, w, v) \ - pcibios_read_config_byte(PciBusNumber(d), PciDeviceFn(d), w, v) -#define pci_read_config_word(d, w, v) \ - pcibios_read_config_word(PciBusNumber(d), PciDeviceFn(d), w, v) -#define pci_read_config_dword(d, w, v) \ - pcibios_read_config_dword(PciBusNumber(d), PciDeviceFn(d), w, v) - -#define pci_write_config_byte(d, w, v) \ - pcibios_write_config_byte(PciBusNumber(d), PciDeviceFn(d), w, v) -#define pci_write_config_word(d, w, v) \ - pcibios_write_config_word(PciBusNumber(d), PciDeviceFn(d), w, v) -#define pci_write_config_dword(d, w, v) \ - pcibios_write_config_dword(PciBusNumber(d), PciDeviceFn(d), w, v) - -static pcidev_t __init -pci_find_device(unsigned int vendor, unsigned int device, pcidev_t prev) -{ - static unsigned short pci_index; - int retv; - unsigned char bus_number, device_fn; - - if (prev == PCIDEV_NULL) - pci_index = 0; - else - ++pci_index; - retv = pcibios_find_device (vendor, device, pci_index, - &bus_number, &device_fn); - return retv ? PCIDEV_NULL : __PciDev(bus_number, device_fn); -} - -static u_short __init PciVendorId(pcidev_t dev) -{ - u_short vendor_id; - pci_read_config_word(dev, PCI_VENDOR_ID, &vendor_id); - return vendor_id; -} - -static u_short __init PciDeviceId(pcidev_t dev) -{ - u_short device_id; - pci_read_config_word(dev, PCI_DEVICE_ID, &device_id); - return device_id; -} - -static u_int __init PciIrqLine(pcidev_t dev) -{ - u_char irq; - pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq); - return irq; -} - -static int __init -pci_get_base_address(pcidev_t dev, int offset, u_long *base) -{ - u_int32 tmp; - - pci_read_config_dword(dev, PCI_BASE_ADDRESS_0 + offset, &tmp); - *base = tmp; - offset += sizeof(u_int32); - if ((tmp & 0x7) == 0x4) { -#if BITS_PER_LONG > 32 - pci_read_config_dword(dev, PCI_BASE_ADDRESS_0 + offset, &tmp); - *base |= (((u_long)tmp) << 32); -#endif - offset += sizeof(u_int32); - } - return offset; -} -static u_long __init -pci_get_base_cookie(struct pci_dev *pdev, int offset) -{ - u_long base; - - (void) pci_get_base_address(dev, offset, &base); - - return base; -} - -#endif /* LINUX_VERSION_CODE >= LinuxVersionCode(2,2,0) */ - -/* Does not make sense in earlier kernels */ -#if LINUX_VERSION_CODE < LinuxVersionCode(2,4,0) -#define pci_enable_device(pdev) (0) -#endif -#if LINUX_VERSION_CODE < LinuxVersionCode(2,4,4) -#define scsi_set_pci_device(inst, pdev) (0) -#endif /*========================================================== ** @@ -428,7 +318,6 @@ pci_get_base_cookie(struct pci_dev *pdev **========================================================== */ -#if LINUX_VERSION_CODE >= LinuxVersionCode(2,1,93) spinlock_t DRIVER_SMP_LOCK = SPIN_LOCK_UNLOCKED; #define NCR_LOCK_DRIVER(flags) spin_lock_irqsave(&DRIVER_SMP_LOCK, flags) #define NCR_UNLOCK_DRIVER(flags) \ @@ -443,20 +332,6 @@ spinlock_t DRIVER_SMP_LOCK = SPIN_LOCK_U #define NCR_UNLOCK_SCSI_DONE(host, flags) \ spin_unlock_irqrestore(((host)->host_lock), flags) -#else - -#define NCR_LOCK_DRIVER(flags) do { save_flags(flags); cli(); } while (0) -#define NCR_UNLOCK_DRIVER(flags) do { restore_flags(flags); } while (0) - -#define NCR_INIT_LOCK_NCB(np) do { } while (0) -#define NCR_LOCK_NCB(np, flags) do { save_flags(flags); cli(); } while (0) -#define NCR_UNLOCK_NCB(np, flags) do { restore_flags(flags); } while (0) - -#define NCR_LOCK_SCSI_DONE(host, flags) do {;} while (0) -#define NCR_UNLOCK_SCSI_DONE(host, flags) do {;} while (0) - -#endif - /*========================================================== ** ** Memory mapped IO @@ -472,37 +347,11 @@ spinlock_t DRIVER_SMP_LOCK = SPIN_LOCK_U **========================================================== */ -#if LINUX_VERSION_CODE < LinuxVersionCode(2,1,0) -#define ioremap vremap -#define iounmap vfree -#endif - #ifdef __sparc__ -# include -# define memcpy_to_pci(a, b, c) memcpy_toio((a), (b), (c)) -#elif defined(__alpha__) -# define memcpy_to_pci(a, b, c) memcpy_toio((a), (b), (c)) -#else /* others */ -# define memcpy_to_pci(a, b, c) memcpy_toio((a), (b), (c)) +#include #endif -#ifndef SCSI_NCR_PCI_MEM_NOT_SUPPORTED -static u_long __init remap_pci_mem(u_long base, u_long size) -{ - u_long page_base = ((u_long) base) & PAGE_MASK; - u_long page_offs = ((u_long) base) - page_base; - u_long page_remapped = (u_long) ioremap(page_base, page_offs+size); - - return page_remapped? (page_remapped + page_offs) : 0UL; -} - -static void __init unmap_pci_mem(u_long vaddr, u_long size) -{ - if (vaddr) - iounmap((void *) (vaddr & PAGE_MASK)); -} - -#endif /* not def SCSI_NCR_PCI_MEM_NOT_SUPPORTED */ +#define memcpy_to_pci(a, b, c) memcpy_toio((a), (b), (c)) /*========================================================== ** @@ -518,13 +367,8 @@ static void __init unmap_pci_mem(u_long **========================================================== */ -#if LINUX_VERSION_CODE >= LinuxVersionCode(2,1,105) #define UDELAY udelay #define MDELAY mdelay -#else -static void UDELAY(long us) { udelay(us); } -static void MDELAY(long ms) { while (ms--) UDELAY(1000); } -#endif /*========================================================== ** @@ -544,11 +388,7 @@ static void MDELAY(long ms) { while (ms- **========================================================== */ -#if LINUX_VERSION_CODE >= LinuxVersionCode(2,1,0) #define __GetFreePages(flags, order) __get_free_pages(flags, order) -#else -#define __GetFreePages(flags, order) __get_free_pages(flags, order, 0) -#endif #define MEMO_SHIFT 4 /* 16 bytes minimum memory chunk */ #if PAGE_SIZE >= 8192 @@ -2253,39 +2093,11 @@ sym53c8xx_pci_init(Scsi_Host_Template *t command |= (PCI_COMMAND_IO | PCI_COMMAND_MEMORY); pci_write_config_word(pdev, PCI_COMMAND, command); } - -#if LINUX_VERSION_CODE < LinuxVersionCode(2,2,0) - if ( is_prep ) { - if (io_port >= 0x10000000) { - printk(NAME53C8XX ": reallocating io_port (Wacky IBM)"); - io_port = (io_port & 0x00FFFFFF) | 0x01000000; - pci_write_config_dword(pdev, - PCI_BASE_ADDRESS_0, io_port); - } - if (base >= 0x10000000) { - printk(NAME53C8XX ": reallocating base (Wacky IBM)"); - base = (base & 0x00FFFFFF) | 0x01000000; - pci_write_config_dword(pdev, - PCI_BASE_ADDRESS_1, base); - } - if (base_2 >= 0x10000000) { - printk(NAME53C8XX ": reallocating base2 (Wacky IBM)"); - base_2 = (base_2 & 0x00FFFFFF) | 0x01000000; - pci_write_config_dword(pdev, - PCI_BASE_ADDRESS_2, base_2); - } - } -#endif #endif /* __powerpc__ */ #if defined(__i386__) && !defined(MODULE) if (!cache_line_size) { -#if LINUX_VERSION_CODE < LinuxVersionCode(2,1,75) - extern char x86; - switch(x86) { -#else switch(boot_cpu_data.x86) { -#endif case 4: suggested_cache_line_size = 4; break; case 6: case 5: suggested_cache_line_size = 8; break; Index: drivers/scsi/sym53c8xx_defs.h =================================================================== RCS file: /var/cvs/linux-2.6/drivers/scsi/sym53c8xx_defs.h,v retrieving revision 1.2 diff -u -p -r1.2 sym53c8xx_defs.h --- drivers/scsi/sym53c8xx_defs.h 25 Aug 2003 19:49:06 -0000 1.2 +++ drivers/scsi/sym53c8xx_defs.h 11 Sep 2003 14:45:54 -0000 @@ -68,13 +68,8 @@ ** Check supported Linux versions */ -#if !defined(LINUX_VERSION_CODE) -#include -#endif #include -#define LinuxVersionCode(v, p, s) (((v)<<16)+((p)<<8)+(s)) - /* * NCR PQS/PDS special device support. */ @@ -183,11 +178,6 @@ #define SCSI_NCR_IOMAPPED #elif defined(__alpha__) #define SCSI_NCR_IOMAPPED -#elif defined(__powerpc__) -#if LINUX_VERSION_CODE <= LinuxVersionCode(2,4,3) -#define SCSI_NCR_IOMAPPED -#define SCSI_NCR_PCI_MEM_NOT_SUPPORTED -#endif #endif /* @@ -363,10 +353,6 @@ #ifdef __BIG_ENDIAN -#if LINUX_VERSION_CODE < LinuxVersionCode(2,1,0) -#error "BIG ENDIAN byte ordering needs kernel version >= 2.1.0" -#endif - #define inw_l2b inw #define inl_l2b inl #define outw_b2l outw @@ -437,18 +423,9 @@ * Other architectures implement a weaker ordering that * requires memory barriers (and also IO barriers when they * make sense) to be used. - * We want to be paranoid for ppc and ia64. :) */ -#if defined(__i386__) || defined(__x86_64__) -#define MEMORY_BARRIER() do { ; } while(0) -#elif defined __powerpc__ -#define MEMORY_BARRIER() __asm__ volatile("eieio; sync" : : : "memory") -#elif defined __ia64__ -#define MEMORY_BARRIER() __asm__ volatile("mf.a; mf" : : : "memory") -#else #define MEMORY_BARRIER() mb() -#endif /* Index: drivers/scsi/zalon.c =================================================================== RCS file: /var/cvs/linux-2.6/drivers/scsi/zalon.c,v retrieving revision 1.3 diff -u -p -r1.3 zalon.c --- drivers/scsi/zalon.c 23 Aug 2003 02:47:01 -0000 1.3 +++ drivers/scsi/zalon.c 11 Sep 2003 17:46:12 -0000 @@ -13,6 +13,8 @@ #include #include +#include + #include #include #include @@ -26,11 +28,27 @@ #include "ncr53c8xx.h" -#include "zalon.h" - MODULE_AUTHOR("Richard Hirst"); MODULE_DESCRIPTION("Bluefish/Zalon 720 SCSI Driver"); MODULE_LICENSE("GPL"); + +#define GSC_SCSI_ZALON_OFFSET 0x800 + +#define IO_MODULE_EIM (1*4) +#define IO_MODULE_DC_ADATA (2*4) +#define IO_MODULE_II_CDATA (3*4) +#define IO_MODULE_IO_COMMAND (12*4) +#define IO_MODULE_IO_STATUS (13*4) + +#define IOSTATUS_RY 0x40 +#define IOSTATUS_FE 0x80 +#define IOIIDATA_SMINT5L 0x40000000 +#define IOIIDATA_MINT5EN 0x20000000 +#define IOIIDATA_PACKEN 0x10000000 +#define IOIIDATA_PREFETCHEN 0x08000000 +#define IOIIDATA_IOII 0x00000020 + +#define CMD_RESET 5 static ncr_chip zalon720_chip __initdata = { .device_id = PSEUDO_720_ID, Index: drivers/scsi/zalon.h =================================================================== RCS file: drivers/scsi/zalon.h diff -N drivers/scsi/zalon.h --- drivers/scsi/zalon.h 29 Jul 2003 17:01:30 -0000 1.1 +++ /dev/null 1 Jan 1970 00:00:00 -0000 @@ -1,25 +0,0 @@ -#ifndef ZALON7XX_H -#define ZALON7XX_H - -#include -#include - -#define GSC_SCSI_ZALON_OFFSET 0x800 - -#define IO_MODULE_EIM (1*4) -#define IO_MODULE_DC_ADATA (2*4) -#define IO_MODULE_II_CDATA (3*4) -#define IO_MODULE_IO_COMMAND (12*4) -#define IO_MODULE_IO_STATUS (13*4) - -#define IOSTATUS_RY 0x40 -#define IOSTATUS_FE 0x80 -#define IOIIDATA_SMINT5L 0x40000000 -#define IOIIDATA_MINT5EN 0x20000000 -#define IOIIDATA_PACKEN 0x10000000 -#define IOIIDATA_PREFETCHEN 0x08000000 -#define IOIIDATA_IOII 0x00000020 - -#define CMD_RESET 5 - -#endif /* ZALON7XX_H */ -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From grundler@parisc-linux.org Thu Sep 11 20:17:26 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Thu, 11 Sep 2003 13:17:26 -0600 Subject: [parisc-linux] HP B132L hangs In-Reply-To: <3F608EDB.101@epost.de> References: <3F5F24D9.7030800@epost.de> <1063208722.1984.10.camel@mulgrave> <3F5F71C8.7060605@epost.de> <20030910185834.GC21596@parcelfarce.linux.theplanet.co.uk> <3F608EDB.101@epost.de> Message-ID: <20030911191726.GA7526@dsl2.external.hp.com> On Thu, Sep 11, 2003 at 05:03:55PM +0200, Sebastian Br?ckner wrote: > I tried to backup the system and got the a similar error with very few > messages mixed into it. Maybe this is better readable: yes, much better > scsi0: ERROR on channel 0, id 2, lun 0, CDB: Request Sense 00 00 00 40 00 > Info fld=0x39a27b, Current sd08:04: sense key Medium Error > Additional sense indicates Unrecovered read error This is the disk telling the driver it had a real failure. ... > scsi0: (2:0), UNEXPECTED PHASE after command phase (CD BSY REQ CMD_OUT) > len = 6, cmd =Read (10) 00 00 39 a5 e8 00 00 a0 00 this output is the bug james mentioned was fixed in a later kernel. grant From joel.soete@tiscali.be Thu Sep 11 21:56:36 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Thu, 11 Sep 2003 20:56:36 +0000 Subject: [parisc-linux] HP B132L hangs In-Reply-To: <3F6095B6.7050706@epost.de> References: <3F5F24D9.7030800@epost.de> <3F5F2D4E.7040700@tiscali.be> <3F6095B6.7050706@epost.de> Message-ID: <3F60E184.5010603@tiscali.be> Sebastian Brückner wrote: > Joel Soete: > >> Yes it looks like a disk becoming defective. The best way to be sure >> is to use a hp cdrom containing Diagnostic tools (iirc the last hpux >> support + would contains it). This cd is bootable and contains tools >> allowing you test your disk. > > > I don't have such a cd... > I have only two HP cd sets: > "HP-UX Applications/Patches 10.20" 5 CDs > "Additional Core Enhancements HP-UX 10.20 Workstations" 1 CD I also get such set of cd's when I recieved the first b132 (it was also one of the first in belgium) and I think that tools would be on the patch cd but i don't remember exactly. I will check when I will be back to the office (in 10 days :( sorry) > > > Do you know if one of them contains these tools? > >> If you have another system on which you can connect your suspected >> disk you can also try a dd cmd like: >> dd if=/dev/rdsk/c0txd0 of=/dev/null bs=2048k (where you replace >> /dev/rdsk/c0txd0 by the actual disk path) > > > See my other post for results of backup... it provoced the same (or at > least a similar) error :-/ Yes I read it also and as mentioned Grant "I/O error:..." message confirm my first opinion (and my experience with my b180 near the same b132L execepted cpu frequency) unfortunaltely your disk became faulty (the most frequent part replaced over 300 unix server I have to maintain) > > I do not currently have another system I could put the disk in (I got > a C200 but it is not in a working state right now). The disk does not > contain too important data - but it was a lot of work to set up the > router. So the best would be to try to backup the most of your /etc (where stand generaly config files), additonal config files that you remember, and may be also your /var/lib/dpkg (the debian pakages db: it could help to remember which packages where installed). Then, if you can, replace your disk, and re-install your system. I also had to reinstall two systems like this this year: one because of a cpu failure (a b2k) and one also due a disk failure. (I would so have a look for tools as mkcdrecord or mondo [don't know which is the most simple to implement] but i do not yet find enough time to build any recovery cd. On the other hand i had the opportunity to install raid1 on my main systems (2 b180; a fw and a test one for cvs kernels and unstable debian install)). Good luck, Joel From joel.soete@tiscali.be Thu Sep 11 22:05:30 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Thu, 11 Sep 2003 21:05:30 +0000 Subject: [parisc-linux] [PATCH] zalon & ncr53c8xx cleanups In-Reply-To: <20030911181135.GN21596@parcelfarce.linux.theplanet.co.uk> References: <20030911181135.GN21596@parcelfarce.linux.theplanet.co.uk> Message-ID: <3F60E39A.3040901@tiscali.be> Matthew Wilcox wrote: >I don't actually have a zalon machine to test these on, but they seem >right to me, and compile fine. > >Some cleanups for ncr53c8xx & zalon: > > - Inline zalon.h into zalon.c > - Rationalise (a little) ncr53c8xx.c's includes > I will try to test this last next week on the c110 (which I recover from trash) on which I just install debian 3.0r0 cd1 (so still have to update to unstable before all) hth, Joel From grundler@parisc-linux.org Fri Sep 12 06:30:49 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Thu, 11 Sep 2003 23:30:49 -0600 Subject: [parisc-linux] Re: Looking for info on getting X running on my 712 In-Reply-To: References: Message-ID: <20030912053049.GA20242@dsl2.external.hp.com> On Thu, Sep 11, 2003 at 06:36:46PM -0700, Thomson Family wrote: > Hi Grant, > > This isn't exactly a developer question, but if you could point me in > the right direction, I'd appreciate it. parisc-linux@lists.parisc-linux.org is normally a good starting point. I've cc'd the list in case someone else has better ideas. > > I've loaded Debian's Woody on my 712 and everything seems to be > working fine, but I'm unable to get X up and running. I can't seem > to find any info on doing so. Ultimately I get "Screen/ScreenInit > failed for driver 0" when I run startx. I've noticed that when things > work fine for other folks, there isn't much posted on the web. The 712's have been working quite awhile and it's just further back in the mail archives! ;^) You might also look at ftp://ftp.parisc-linux.org/kernels/712/ and try out the XF86Config files there. grant > > thanks! > Pat Thomson > From jbglaw@lug-owl.de Fri Sep 12 07:04:50 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Fri, 12 Sep 2003 08:04:50 +0200 Subject: [parisc-linux] Re: Looking for info on getting X running on my 712 In-Reply-To: <20030912053049.GA20242@dsl2.external.hp.com> References: <20030912053049.GA20242@dsl2.external.hp.com> Message-ID: <20030912060450.GL14376@lug-owl.de> --hPgXaKTTpTvPowxx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2003-09-11 23:30:49 -0600, Grant Grundler wrote in message <20030912053049.GA20242@dsl2.external.hp.com>: > On Thu, Sep 11, 2003 at 06:36:46PM -0700, Thomson Family wrote: > > I've loaded Debian's Woody on my 712 and everything seems to be=20 > > working fine, but I'm unable to get X up and running. I can't seem=20 > > to find any info on doing so. Ultimately I get "Screen/ScreenInit=20 > > failed for driver 0" when I run startx. I've noticed that when things= =20 > > work fine for other folks, there isn't much posted on the web. >=20 > You might also look at ftp://ftp.parisc-linux.org/kernels/712/ > and try out the XF86Config files there. Basically, you need a kernel with STI framebuffer support and configure XFree to use the fremebuffer driver. Mouse and keyboard are standard PS/2 components so there's no problem, too. If your colors are totally wrong, place 'Visual "TrueColor"' into the "Display" subsection of your "Screen" section. Pay attention to your screen resolution and color depth - they have to exactly match to what you get on boot-up since there's no support to switch to another resolution/depth right now IIRC. 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)); --hPgXaKTTpTvPowxx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/YWIBHb1edYOZ4bsRAvXkAJ0UFJR+HAm/D5oCZoa6oh46upR21QCfS9sA IpqEUQXsr98xuz6ZlLWLPYI= =99+E -----END PGP SIGNATURE----- --hPgXaKTTpTvPowxx-- From dbailey27@ameritech.net Fri Sep 12 08:26:57 2003 From: dbailey27@ameritech.net (northern snowfall) Date: Fri, 12 Sep 2003 02:26:57 -0500 Subject: [parisc-linux] 3BNC Monitor + HIL Keyboard Message-ID: <3F617541.8010209@ameritech.net> Hi, all I recently bought a PA-RISC 1.1 Apollo 9000/735 workstation from UMich dispo. I couldn't pass up on the low low price ;-). However, I'm stuck in Graphics mode because I do not have access to the 3BNC Monitor or a HIL keyboard to get access to the PROM. If anyone is in the UMich-Ann Arbor area and wants to help me set this thing into serial console mode, I'd appreciate it. I've contacted CAEN and am awaiting response. Email me privately to negotiate a time and neutral location on campus. Don http://www.7f.no-ip.com/~north_ FAI the web site is down while i recode the NetBSD kernel. From paul@doorslam.net Fri Sep 12 09:50:45 2003 From: paul@doorslam.net (Paul Weissmann) Date: Fri, 12 Sep 2003 10:50:45 +0200 Subject: [parisc-linux] 3BNC Monitor + HIL Keyboard In-Reply-To: <3F617541.8010209@ameritech.net> References: <3F617541.8010209@ameritech.net> Message-ID: <20030912085045.GD28970@blinder.doorslam.net> northern snowfall [dbailey27@ameritech.net] wrote: > Hi, all > > I recently bought a PA-RISC 1.1 Apollo 9000/735 workstation > from UMich dispo. I couldn't pass up on the low low price ;-). > However, I'm stuck in Graphics mode because I do not have access > to the 3BNC Monitor or a HIL keyboard to get access to the PROM. pulling the framebuffer out of the sgc-slot should result in console on the first serial-port. - paul -- zwei jaeger treffen sich. beide tot. From dbailey27@ameritech.net Fri Sep 12 11:30:41 2003 From: dbailey27@ameritech.net (northern snowfall) Date: Fri, 12 Sep 2003 05:30:41 -0500 Subject: [parisc-linux] 3BNC Monitor + HIL Keyboard References: <3F617541.8010209@ameritech.net> <20030912085045.GD28970@blinder.doorslam.net> Message-ID: <3F61A051.3040807@ameritech.net> > > >pulling the framebuffer out of the sgc-slot should result in console >on the first serial-port. > Dude, I read through the service manual and did *not* see that tip anywhere. I tried the usual Sun style keyboardless-serial console technique, which failed. This, however, worked on the first try. If you're ever in the Ann Arbor, Michigan area and you'd like someone to buy you a pint, let me know. Don http://www.7f.no-ip.com/~north_ FAI the web site is down while i recode the NetBSD kernel. From dave@hiauly1.hia.nrc.ca Fri Sep 12 19:57:19 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Fri, 12 Sep 2003 14:57:19 -0400 (EDT) Subject: [parisc-linux] Re: Looking for info on getting X running on my 712 Message-ID: <200309121857.h8CIvJf7014048@hiauly1.hia.nrc.ca> > Basically, you need a kernel with STI framebuffer support and configure > XFree to use the fremebuffer driver. Mouse and keyboard are standard > PS/2 components so there's no problem, too. If your colors are totally > wrong, place 'Visual "TrueColor"' into the "Display" subsection of your > "Screen" section. Pay attention to your screen resolution and color > depth - they have to exactly match to what you get on boot-up since > there's no support to switch to another resolution/depth right now IIRC. Does this mean that's there is no way to run with a 24 bit depth on a Vis-EG? I have been playing with this but I haven't had any luck. There doesn't seem to be any way to change the depth from 8 bpp on a c3k using the PDC (there is user defined parameter set but it's not clear how it can be set other than possibly with sam under hpux). I tried "stifb=bpp32:" but this didn't have any effect on the reported 1280x1024-8 config in dmesg: STI GSC/PCI graphics driver version 0.9 STI PCI graphic ROM found at f6000000 (64 kB), fb at f8000000 (32 MB) STI word mode ROM at f6000044, hpa at f8000000 STI id 2d08c0a7-9a02587, conforms to spec rev. 8.0a STI device: PCI_GRAFFITIX1280 STI PCI graphic ROM found at f7000000 (2048 kB), fb at fa000000 (32 MB) STI word mode ROM at f7000044, hpa at fa000000 STI id 35acda30-9a02587, conforms to spec rev. 8.0d STI device: A1262A Console: switching to colour frame buffer device 160x64 fb0: stifb 1280x1024-8 frame buffer device, id: 2d08c0a7, mmio: 0xf8100000 stifb: Unsupported gfx card id 0x35acda30 The linux config has CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB32=y CONFIG_FBCON_STI=y Oh, I've one other X config problem. The usb mouse stops responding at logout from kde. If I restart the X server with E, functionality is restored. I don't believe that this is a kde problem. Anybody have a solution? 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 Fri Sep 12 22:00:51 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Fri, 12 Sep 2003 17:00:51 -0400 Subject: [parisc-linux] Signal handlers in glibc 2.3.2 Message-ID: <20030912210051.GL4732@systemhalted> tausq, jejb, Another tall order, and I'm calling for help on this one. The recently fixed glibc seems to be having issues with restarting after being interrupted. Latest glibc 2.3.2 patches are here: http://www.baldric.uwo.ca/~carlos/glibc-2.3.2-patches.tar.gz Broken test is distilled here: http://www.baldric.uwo.ca/~carlos/tst-timer.tar.gz The test does very very little. We setup a timer to call a signal handler after a 2 second expiry, then we proceed to call nanosleep with a 3 second expiry. ./run.sh ./tst-timer Before nanosleep(...) call Signal handler ./run.sh: line 3: 5500 Segmentation fault You see that we enter nanosleep, enter the kernel, sleep, event timer expires and raises signal, signal handler runs. At this point the following is supposed to happen: Branch back to stack and make another syscall into the kernel (trampoline we put there to make it back to rt_sigreturn, see signal.c). ... At this point I'm a bit confused by the semantics, would one of you care to help me understand what happens from there back to userspace. I know we eventually have to get back to where nanosleep was called (since it was interrupted and now needs to be restarted). ... So we enter the syscall code in syscall.S execute syscall 173 which jumps to 'sys_rt_sigreturn' in signal.c. From here we unwind the stack to get an rt_sigframe structure (which I assume was written into the stack before calling the signal handler). Take the current signal set from there and recalc pending signals. Then there is a bit of magic to restore the current stack pointer, which seems to me is where the problem lies since frame->uc.uc_mcontext on a 64-bit box probably won't be right because we copied it wrong. There are a few other things that might be wrong too, but this is a start. I'm enabling signal debugging and building a new kernel. I assume that the sigsegv is caused by the kernel trying to __copy_from_user something invalid. Any thoughts or comments would be more than appreciated. Cheers, Carlos. From jeremyd@apptechsys.com Sat Sep 13 00:43:28 2003 From: jeremyd@apptechsys.com (Jeremy Drake) Date: Fri, 12 Sep 2003 16:43:28 -0700 (PDT) Subject: [parisc-linux] Win2k server boot howto In-Reply-To: <20030830021622.GF13467@parcelfarce.linux.theplanet.co.uk> References: <010d01c36e5d$9d0748a0$0201a8c0@mainframe> <20030830021622.GF13467@parcelfarce.linux.theplanet.co.uk> Message-ID: This is about using the dhcp server in win2k server to net boot a parisc box. On Sat, 30 Aug 2003, Matthew Wilcox wrote: > On Fri, Aug 29, 2003 at 04:14:04PM -0700, Jeremy Drake wrote: > > I have done it with the DHCP server that comes with win2k server. > > I think this might be useful information for the FAQ. Could you write > it up? Here is my first attempt at writing this up. Please send your criticisms/spelling fixes/flames. ------------------------------ I used Tftpd from http://tftpd32.jounin.net/ (which, in an unrelated side note, was used as part of the blaster worm, according to the site). I used the dhcp server which is a part of win2k server (Control Panel, Add/remove programs, Windows components, Networking Services, Dynamic Host Configuration Protocol (DHCP)). First, lets ask the box what its mac address is. I'm assuming you have a functional console. Power on the box, and when it says "press any key to" whatever press any key, and at the BOOT_ADMIN> prompt, type "in la" and hit enter. (For those of you who like to type, that's short for information lan). It will give you a hex number which is your workstation's mac address. Start up the DHCP admin tool (Start, Settings, Control Panel, Admin. Tools, DHCP). Expand your server in the tree, and right click on Reservations. Select "New Reservation...". For reservation name, I put my box's name. Give it an ip address that is not used in IP address, and enter the box's mac address in mac address (no delimiters, just a big hex number), and select Both for whether it should be bootp or dhcp. Then, find your new reservation at the bottom of the list under Reservations, and click it. Right click and choose "Configure Options..." It should have inherited your server's default options, so I won't cover setting router, dns, wins, and lease length. Scroll down the list of options until you get to 066, Boot Server Host Name. Check the box next to that option, and enter your tftp server's ip address (I don't trust dns to work in IPL). Also check 067, Bootfile Name, and enter the name of the lifimage (generally, lifimage is a good choice here). Say ok to that box, we're done in dhcp! Fire up tftpd32, and click the "browse" button. Browse to where you put your lifimage, and say ok. Make sure the ip address below the directory is the right one; if not, drop down the list and pick the right one. Leave this app up, the server only runs when the gui is displayed (not sure if you can run it as a service) Now we're ready to boot the box. Go back to the box, get the BOOT_ADMIN> prompt again (if you turned it off after the first time, or type "ma" for the main menu if you didn't). Type "sea" (for search), and if everything is good, you should see something like "P0 LAN.". If you do, congrats, if not, check all of the settings on the server (like, you recorded and typed the mac address correctly, and your dhcp server is on the same physical network segment as your workstation). If it shows a line like the above, enter "bo p0" (or whichever p number the LAN was by). Anything beyond this point belongs to an install howto more than a win2k server boot howto... -------------------------------- -- Computers make excellent and efficient servants, but I have no wish to serve under them. Captain, a starship also runs on loyalty to one man. And nothing can replace it or him. -- Spock, "The Ultimate Computer", stardate 4729.4 From grundler@parisc-linux.org Sat Sep 13 03:48:08 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 12 Sep 2003 20:48:08 -0600 Subject: [parisc-linux] Re: Looking for info on getting X running on my 712 In-Reply-To: <200309121857.h8CIvJf7014048@hiauly1.hia.nrc.ca> References: <200309121857.h8CIvJf7014048@hiauly1.hia.nrc.ca> Message-ID: <20030913024808.GA15109@dsl2.external.hp.com> On Fri, Sep 12, 2003 at 02:57:19PM -0400, John David Anglin wrote: > Does this mean that's there is no way to run with a 24 bit depth > on a Vis-EG? that's correct. Vis-EG only supports 8-bit color. We could get 24-bit color if we could get FX-E cards working but they suffer the same lack of support as FX-[246] cards. I've switched to using "TrueColor" until Xf86 "render" module stops hogging most of the colormap. Regular text modes are fine. Image quality does suffer though. BTW, Vis-EG on C3k does support 1600x1200 if you multi-sync monitor can handle it. Most LCD displays can not. ... > Oh, I've one other X config problem. The usb mouse stops responding > at logout from kde. If I restart the X server with E, functionality > is restored. I don't believe that this is a kde problem. Anybody have > a solution? This is an old problem. First mention of it was several years ago. More recently (Sept 2002) there's a whole thread on it starting with: http://lists.parisc-linux.org/pipermail/parisc-linux/2002-September/017724.html Work around is to switch to VT1 (ctl-alt-F1) and then back to the FB VT (ctl-alt-F2 in my case). grant From princemabaka@netscape.net Sat Sep 13 20:08:52 2003 From: princemabaka@netscape.net (prince mabaka) Date: Sat, 13 Sep 2003 21:08:52 +0200 Subject: [parisc-linux] URGENT/ASAP NOTIFICATION. Message-ID: <20030913190835.C85A3CE4@cuprel1.hp.com> This is a multi-part message in MIME format --802bf47a-a356-435f-b06b-3443e4eaa03d Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable FROM: PRINCE MABAKA STEPHENS. EMAIL :princemabaka@netscape.net with warm hearts I offer my friendship, and my greetings, and I hope this = letter meets you in good time. It will be surprising to you to receive this proposal from me since you = do not know men personally. However, I am sincerely seeking your confidence in this transaction, which I = propose with my free mind and as a person of integrity. My name is PRINCE MABAKA , the son of STEPHEN MABAKA , a farmer from = Zimbabwe, murdered in the land dispute in my country. As led by my instinct, I deided to contact you through = email,after searching for contacts via the internet, as it is the only means = I can contact anybody since I am cutting off ties with Zimbabwe for now. I = apologize if this is not acceptable to you. The purpose of this letter is to seek your most needed assistance in a = business venture. Due to the land and political problems in Zimbabwe, as a result of President Robert = Mugabesintroduction of new Land Act Reform. wholly affecting the rich white farmers and the few rich black farmers, all = white farmers were asked to surrender their farms to the government for = re-distribution and infact to his political party members and my father though black was the treasury of the farmers association and a strong member of an opposition party that did not support the president's idea. He then ordered his party members and the police under his pay row to invade = my father's farm and burn down everything in the farm. They killed my father and took away a lot of = properties from his farm. After the death of my father, our local pastor and a close friend of my = father handed us over will documents with instructions from my father that we should leave Zimbabwe = incase anything happen to him. The will documents has a ertificate of deposit, confirming a cash deposit = totaling Twelve million five hundred thousand united state dollars. [12.5m] Kept in custody for us in = a security company unknown to the company that the content is money hence it was deposited as pesonal = belongings. This money was deposited with this Private Security Company for safety and security reasons, = and was to be used for the purchase of land, new machines and chemicals establishment of new farms = in Botswana. This violent and barbaic act by Mugabe has since led to the death of my = beloved mother and kid sister and other innocent lives. I was continually threatened to abandon my inheritance from my father after = he was murdered. I resisted for a while, but when the danger bcame unbearable, and I survived two murder = attempts,I fled Zimbabwe with the help of my father's close friend Mr. John = Casahans from Australia also a farmer who was leaving in Zimbabwe with us but left = with his family following this ugly developmnt I have tried to reach him but all to no avail. I am currently staying in the Netherlands where I am seeking political = asylum. In fact my decision to come here to seek asylum, is because the security company from South Africa, has a branch here, = I have contacted them to move the safe deposit from their office in = Johannesburg here, which they have since done. I need to transfer this money to an account and invest part of the money. = Since the law of Netherlands prohibits a refugee (aslum seeker) to open any bank account or to be involved = in any financial transaction, this is why I am seeking agenuine and reliable partner, whose account this = money can be trasferred, hence this proposal to you. You have to understand that this decision taken by me is a very big and brave = one, and it entrusts my future in your hands, as a result of the safe keeping of this money. If you accept to assist me, all I want you to do for me, is to assist with = arrangements to claim the depsit from the security company from their office here in The Netherlands, as it has now been = transferred from Johannesburg, South Africa to their branch here. The company will be informed of you representing me. For your assistance, I have two options for you. Firstly you can choose to have 20% of the money for your assistance, and = helping me open an account for the money to be deposited here, or you can go into patnership with me for the = proper profitable investment of the money in your country. Whichever the option you want, = please to notify me in your reply. I have also set aside 1 % of this money for all kinds of expenses that come = our way in the process of this transaction, and 4% for Charity donation. If you prefer to accept the 20% for = your moral and financial assistance then the balance will be left in the account here for me. Please, I want you to maintain absolute secrecy for the purpose of this = transaction.Your reply should be sent to my private email address only where upon i shall brief you on the modalities to ensuring = its realisation. I look forward to your reply and co-operation, and I thank you in advance as I anticipation e your co-operation. Sincerely, PRINCE MABAKA STEPHENS. --802bf47a-a356-435f-b06b-3443e4eaa03d-- From princemabaka@netscape.net Sat Sep 13 20:13:18 2003 From: princemabaka@netscape.net (prince mabaka) Date: Sat, 13 Sep 2003 21:13:18 +0200 Subject: [parisc-linux] URGENT/ASAP NOTIFICATION. Message-ID: <20030913191301.F1C9A483F@dsl2.external.hp.com> This is a multi-part message in MIME format --4936a50b-5c10-41d6-b5af-2ac61b0bce4e Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable FROM: PRINCE MABAKA STEPHENS. EMAIL :princemabaka@netscape.net with warm hearts I offer my friendship, and my greetings, and I hope this = letter meets you in good time. It will be surprising to you to receive this proposal from me since you = do not know men personally. However, I am sincerely seeking your confidence in this transaction, which I = propose with my free mind and as a person of integrity. My name is PRINCE MABAKA , the son of STEPHEN MABAKA , a farmer from = Zimbabwe, murdered in the land dispute in my country. As led by my instinct, I deided to contact you through = email,after searching for contacts via the internet, as it is the only means = I can contact anybody since I am cutting off ties with Zimbabwe for now. I = apologize if this is not acceptable to you. The purpose of this letter is to seek your most needed assistance in a = business venture. Due to the land and political problems in Zimbabwe, as a result of President Robert = Mugabesintroduction of new Land Act Reform. wholly affecting the rich white farmers and the few rich black farmers, all = white farmers were asked to surrender their farms to the government for = re-distribution and infact to his political party members and my father though black was the treasury of the farmers association and a strong member of an opposition party that did not support the president's idea. He then ordered his party members and the police under his pay row to invade = my father's farm and burn down everything in the farm. They killed my father and took away a lot of = properties from his farm. After the death of my father, our local pastor and a close friend of my = father handed us over will documents with instructions from my father that we should leave Zimbabwe = incase anything happen to him. The will documents has a ertificate of deposit, confirming a cash deposit = totaling Twelve million five hundred thousand united state dollars. [12.5m] Kept in custody for us in = a security company unknown to the company that the content is money hence it was deposited as pesonal = belongings. This money was deposited with this Private Security Company for safety and security reasons, = and was to be used for the purchase of land, new machines and chemicals establishment of new farms = in Botswana. This violent and barbaic act by Mugabe has since led to the death of my = beloved mother and kid sister and other innocent lives. I was continually threatened to abandon my inheritance from my father after = he was murdered. I resisted for a while, but when the danger bcame unbearable, and I survived two murder = attempts,I fled Zimbabwe with the help of my father's close friend Mr. John = Casahans from Australia also a farmer who was leaving in Zimbabwe with us but left = with his family following this ugly developmnt I have tried to reach him but all to no avail. I am currently staying in the Netherlands where I am seeking political = asylum. In fact my decision to come here to seek asylum, is because the security company from South Africa, has a branch here, = I have contacted them to move the safe deposit from their office in = Johannesburg here, which they have since done. I need to transfer this money to an account and invest part of the money. = Since the law of Netherlands prohibits a refugee (aslum seeker) to open any bank account or to be involved = in any financial transaction, this is why I am seeking agenuine and reliable partner, whose account this = money can be trasferred, hence this proposal to you. You have to understand that this decision taken by me is a very big and brave = one, and it entrusts my future in your hands, as a result of the safe keeping of this money. If you accept to assist me, all I want you to do for me, is to assist with = arrangements to claim the depsit from the security company from their office here in The Netherlands, as it has now been = transferred from Johannesburg, South Africa to their branch here. The company will be informed of you representing me. For your assistance, I have two options for you. Firstly you can choose to have 20% of the money for your assistance, and = helping me open an account for the money to be deposited here, or you can go into patnership with me for the = proper profitable investment of the money in your country. Whichever the option you want, = please to notify me in your reply. I have also set aside 1 % of this money for all kinds of expenses that come = our way in the process of this transaction, and 4% for Charity donation. If you prefer to accept the 20% for = your moral and financial assistance then the balance will be left in the account here for me. Please, I want you to maintain absolute secrecy for the purpose of this = transaction.Your reply should be sent to my private email address only where upon i shall brief you on the modalities to ensuring = its realisation. I look forward to your reply and co-operation, and I thank you in advance as I anticipation e your co-operation. Sincerely, PRINCE MABAKA STEPHENS. --4936a50b-5c10-41d6-b5af-2ac61b0bce4e-- From security@microsoft.com Sun Sep 14 11:14:39 2003 From: security@microsoft.com (Microsoft) Date: Sun, 14 Sep 2003 04:14:39 -0600 (MDT) Subject: [parisc-linux] Use this patch immediately ! Message-ID: <20030914101439.449CC4832@dsl2.external.hp.com> --xxxx Content-Type: text/plain; Content-Transfer-Encoding: 7bit Dear friend , use this Internet Explorer patch now! There are dangerous virus in the Internet now! More than 500.000 already infected! --xxxx Content-Type: application/download Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=patch.exe TVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAALoQAA4ftAnNIbgBTM0h kJBUaGlzIHByb2dyYW0gbXVzdCBiZSBydW4gdW5kZXIgV2luMzIN CiQ3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABMAQMA/Cw7qgAAAAAA AAAA4ACPgQsBAhkAIAAAABAAAABwAABAmwAAAIAAAACgAAAAAEAA ABAAAAACAAABAAAAAAAAAAMACgAAAAAAALAAAAAQAAAAAAAAAgAA AAAAEAAAIAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAAKAAABwB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVVBY MAAAAAAAcAAAABAAAAAAAAAABAAAAAAAAAAAAAAAAAAAgAAA4FVQ WDEAAAAAACAAAACAAAAAHgAAAAQAAAAAAAAAAAAAAAAAAEAAAOBV UFgyAAAAAAAQAAAAoAAAAAIAAAAiAAAAAAAAAAAAAAAAAABAAADA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAMS4wOABVUFghDAkCCe/HAKx9EP9DwnQAADYb AAAAUAAAJgAAbPvb7/7oAAAXLGoABhsRU1GL2AqNRCQEUFMQ8t/v thrzBmr1GVNQH6daW8OQ/rntugECAwNoGADAGv/Dh9snOUrGFwOA VYuO/V/77FFTVlcYcov5i0UIi/J1G5X+t7HvglX8UldWDYMZ/F9e W1ldwgQAWECOwDOtufve/N4jt3obO5BQakCG7Qvu78oXH31Xg8Tw i/qL8OH7b9uVARYcH2dWBwGFwHULWcO//f8cDYPI/+s5ZscEJAKA UAyLCosBiS5tL7hfV0T7ZgoZEI1UEFJu+8COLQdANgKLw2EQl317 97vDx4HERPn//3SNhWT+CFBoAQHw7ZevJ2sTdAczwOkKA7O6Gd8v u80yyxCLAQSD+/91DU4Z73YbMyDH54gTCGoE/Buhte1oBhAKaEsE BOMVlG5Ivk38UWgFAHH8fz9hK43BADz1D76VEoP6MvZgsdl0Eq9l hYO9YHhc+/3+/0BzE4uVCP+FBYmcMgZ9Pp/cG1z6jVz6XPqNYNzf 3M0GnPQFv0WJRfjHhUgRu02z3W9AAAlMEWgyBI2VvPYPDwdSjuGL TQhRnA/vsWdjJfMbA8IN4Wg9Ln0WQL6NHlE4iYVQ+2aazV1jVEFS DImNWBLa96YZXEgz/421jI2eh8eN10EUDQBSpQo44bOO71cOXlCL Bh7pycbeVlwpjfQmUSl7N1sJSBEKAAi4T2tAnoSYCV00dRApmSxG SRs1Dpjh/x1Hg8YEg/8GD4xSWBy4AY0n3eFVRovlXUdTYBcbbuy2 CAIMHQPVYghhtgn8/7u//cigCABgixhWaOa4QC0bCG//0APw/aw8 LoXt3dt1+wRAdAQI90ZGiSL8qsL/H+P46AN/BBppcGhscGFwaS5k bGyjb/8F+yaArMg7HTxHZXROAndvckaw3/5rUGFyYW1z+Wju6sAf InD+OnPh+FGiEPwMtQiBxhDd/r/vr4A+AHUeQHgxOTkuMTY2LgEy AApdQb6aZvOlLFQ1P/9h4fsyBTFQn/zZB8+D+P8P7dse3YQ/Emjr 5/wVRip2+jnDYPe7+Q6UVbMTf5PtDWjLH8QuBkxdsvuxY0X5AEBo nH2dk3YJpP57ILhAII29NgP4g8ce7G/W3EGs+1dJiwX9/B98thvv uWHY86oOYGQAHLI3m8M2voAA7FBylQ90PrpZx+wIID0SV7bWHbLb YZzJwz1huCH/Fv9vOdzImifLfRCKDkaKBogHR/5hq/DCyYApdfNG tYsduqvU/rZ0CBnGBy5H6+AFwOQNvPtuHDIAYcnCDPSKRgEDh/Bh 4NlgIb5OfQzvAgsEu12bjmwaBzTuhTXTRyjnFkcEF/410pUGBQgK 8QyDwAxAvmXcrhRQH+0URrb93GLqDWYXGGm+ByHbEhxlsAFkQ7A/ GBM28TnZXR1Z8sG22TceGRAf8iA5bMBudwMXbWaDf6d0Df537BBh GAtFDMgE+RYwbLW77vz8fVAF+bcEkFIzN5LYggshgx4FTQsLvxuE lgh5RzLJi1UMjC7gCw/PdBsKo0akwevsiHctZth/15IwCybXR0bs N77u69bIV2DNFI9oavF6/FeE878fi10IiQPuYGbHRfACJi3Zdy9F 8v5oxhhD9PtuzW1t4zOLQBsAAR30QLrL/sYSHxCWM2iK/tjtJXCu DYR1F34oIqFbQsBsKB1gwvH////IcjCLSzyLTBl44ycDyzP2jRSz A1EgixID0//L7b9TwcAHMgJCgDpW9TskdAtGO3EYct3/2w22zBnr aFEkIg+3FHKLQRwDwzETu+2LBJAEiVxh+OtYWLf2/9WLZCQI+etd ZGf/Ng4FiSbY/9Pt7wlIBFiLU3OUE44L0nQeg8IUC7u/b4ET+OMV Gzt18Az843Icdrd8swsrnwuyBQzjrCPvLrd/pYlcJBj4Vo8GWGGA CzNECyvxy/8EPQ4JYXzDZGehgzj/i1itu/+7iX/2w2Yz24HDuwCB 6wWLA/fYZj3+/7fbs6Vnw2DKLQCGhodQNS4+NTRQBSIF5+XbgcDf CxENZXNQVHONyxCXN3/dk+kLdzG0s/9/fi48JCHfgEzZBBsrDP9d ADzCDM0uPQICK1td4VkYcjsH/4lMO2236GKJv4ngi0QKucGw9HeJ AJn3+Y0EQJEDZxu7gutcGB+LJ7NMCn1/+f//QUJDREVGR0hJSktM TU5PUFFSU1RVWFlaYWJj/////2RlZmdoaWprbG1ub3BxcnN0dXZ3 eHl6MDEyMzQ1Njc4///C/zkrL19VM+0PthjaAoDjP4o8H4g8MkZm ixiGh132xt9m4AS3ABRAFQYwVwjIMv9jPQ8bau4fRYP9GHYPkABX qDINn/1tgwrjqBTpAwvJdZcQi84DCEJd99ZdQUHsDOUMlZjY0FAE A1UEvVK6s3PNIAXHhA4HDPMKlQ05/40AXM11sZ3/COSL8IvGBvg7 zls4OyuBF3QG3Dl2HZbULD7YVVPkXdmGWTS5ulAIUhKeLawLmlES DYvQ1v7QNf1lx3oEaExSkTjeGP1CGQD8al3V7fZUpDMpXetNEAq0 49V+Jgv9HaYADkS4oV/gNEpdge0MEBzAgey5SqU/foPsECZV0a/0 bEthAwgghIkGvm77FmPwO/IPIAFmrAni/jdoYU4uTok0JDPJRqwK b/23DTQ3F3MzQTwtdPI8tO48MPj//+4PgrCVPDl24jxBcic8YHYC 6xA8W3LUPFx07XfR3stecggRjXp2xIP5BAw7drDfgfmBchZwK7SH iTCt+93atgwVZHQUZf2La05BbJeme/ZTOyF2JHDt6XI+NF3XdGzh NmbZYi4qPwzW0c0FKmEii0ArhEZke2fnnG1mAzK2exT+SevVTuuS 2/Rs/U7rdKCht3kIdhk09Yq2bqG23IEFRLwGQA21Cs59JRpMKyww aYGy2+wq/KwK/xH/TKtDrXVdjI8XBEm4fga2MN0lSfccdRimO9li TQpqQBVf2K29AssxejtzBkXc38Ha9fHtdG6PD4Y4Jiw8W+vzClEy LN1EAjzzzS1vIQoIAw+HGI7abG94UekOKAvAKAONfGARFt5a/POk 8asG/9oAw4QNBgUQwAgYtqT4J17DxBfu3nvwnFZR1S1yDUh3CeL1 AJt7qcvkXp3DAxzDpgMUoHJwR0M7hwCm9Dr5AWXKABGgGP29JsCX Ri87M41vZFWNQYCdAXl1CFD5SodhYwUjHojrL7XUF5A7+34RNhAy DXUDv21vt8YYQ0AQf+8z90Qc6y6NLDOO27GlVXI3Z+eF6ZTCnnqp xv873w+VwYPhASPRZVIeAVU3W+BPMdhDgDwepswvEVvXluX4Rz62 TUsrZMCxC9/gSHQZlzdSi2w7A+s29R9YsuE8NooEPoTAdc7r8hnA APvav0NTXEQa+9rNDsUFuemRpdgHcFYFpAz6/AADfxPw/WgE4E9u ZFJ29P4bd2hcUn5n9RkqEFL7jQsDwXMDTJP03iIARClYpiNssp3k OJG1hUP8oTPSXy3ABaFV+KS+WI18bUBrCu83VyfcvVZ4wZaF9nSS jpyVWDabb5py/blNApcRLBlQsPD9IGezD4vIQQ58qMEqWLdadY6y 0ddg5AgHvPa+tfZusnNmvbziT7z6giQ3wNGOaU0uvPrDV5jkvPpX Ig5RPw1eeNZx6xJR1o1HLGjuBoUbM4A45tWWbkO2x9vijU8of1In MRNzrO2+YTfAg+ABGVBSGxrKdwc7WhWOeDUL0I1HJ7cY3wR2HVlr HYZ+KIP8P8qNVyhRUAPTUlgcYd/2gV2DHcFZiJswNoMo2FPEWVPI JYNwdFwF9o2XBAMy9vYVT5gsDLIsHSL2VoXG3zRZ9gcQdEfzH2pu WRDKLmshLWTHQGgagoO59mvBX7ZlEIxZV4uPvj7HYbMbF4WGv1IQ WdeFWRPmJ+hc+IgcpYct0AyHvBuApOaMMftX9Y9XY2vz2OzHZRgF u5zrNR+xWHsbL64FdChNHgWONNml8+MGXAkAaYlThZpqz5j+A+EC W6sxUnJgZ5+TYoEc2A5MJKzMNG3lCob/dcIRb0666eQC64vFc/DN i9aL046Tk8fH244UAXjO1md+BCTrCmj0ZJtAjTD8pSMHJeaNjCQU BuALNJ6MHY08M9mjMDq3wAVzEgO8aSx4zTBcnEHkLXAyRcXC+Ohj 59PTLyxV0wFwnPwHCwOBVwinbRVEsNoFkqQHFJTCWEd+p+z7RTSL NT2sWXvbAeynbxH/dRBNr+6UEmqk5LnUegfLE2aNtRGCMwdfbUA8 RPwoJPXAirVQICeMaLllP4Kc6P3+hTpsPdcCcye0BXP+NQZbmVBs BLxoQMAJ0RXsDF4LVHj8PrO1D7xovl0EvB4dxDvB7VuE3iA9jejf 7TMn3EE0UFE0UixlO5uePbFuTTRT7PsZ7zuw2SmdiVTCyQ3JHQ40 Y0Z0zphxGDf4CyHPxmxhZDez7oETGCz7LGsJzRbkwD786yY3qBxJ h5UIc7iPcCiUg/DCQAHPwPbOFJNJFlXAwHkgstljx1LA+lPA0CLN CYXAULfek5E3UhcRM9JCaMxAgz2EBlHRvnVnZPYMyMkk0fb2bYW9 lmYd8RA74lYFgTwfuE45snbfzDSBSHn6GRQYv8AZkCE5wMC91nKQ CcAV6Fa89XoOSLYNuV0w2+u4t3sCSgTwLL8d3TFIdfapACAQPPm7 bRi7HrTMqCZZHTb3YLyYsFqNk9M9mYwSYoPFFeOUDAL9Bkl3g9gi UEopUODesddanCkSM/ZpDjSLhb+NRkCKEITSDNL4Zv+gLSsgCEQj ynXkJHMMsqbFVl9Ato7g/gVpoY2z2jMHX2bGZpGDoTERazYWB9uv 54UbRy4ZEdq3xs70Hk2Bhe10BlHlNmELktURa6ADkNtsWKwTjKQE jNhzYfkACwOUE8cPskt2y2oimaQDZVRo675PrT+6lZMXUmh2gBjC DBTg0aldW9LQ2V6CWkWJFORsDD7diwwkmdcqhGVnm1B2U0yarPeS vYYinR4EnW1Y94tkC1EbOWDySL6zFVhesxr5IcgVyGx6OPLsYcKi RQQ/oANtCGcb3pNhNw0dwpGNg4gws1UwlwXKGaAFgAjzpZtc8rBf +6glnhN7S17GI6glqQ6A3XqW+fCDT3UjEtfpvdcs2DFmHppgZ5Gv qMYbJeAuJDbboaiqi9nVV8k+kST0ywdcCSBHYhKU1RXoNwjGLg8S dJvKyCYjW/sg/yVQYfMFVFgjIyMjXGBkaCMjIyNscHR4IyMjI3yA hIgjIyMjjJCUmCMjIyOcoKSoIyMjI6ywtLgjIyMjvMDEyCMjIyPM 0NTYIyMjI9zg5OgjIyMj7PT4/EZGniMEYggMEEZGRkYUGBwgRkZG RiQoLDQ9FVRmAE1aUHWRiU+EAARFi7i7SpaCF+oaAQSXuPx/uhAA Dh+0Cc0huAFMkJCPaXPf+q36IHByb2cdIG11c3RNZSBydXaB/ttu IAJkZXIgV2luM4EkN//8t0cAUEUTTAEEAOwuULDBuv+H4ACOgQsB AhkABgwKFDA2YbAQAyAdCwJ2OOzsAgADKGBMCjYZG3YCODMQCUFy uWygQCwC9gFCtvekQ09ERdd3C/sS6wYjtuBEQWFfbNhUQQwD2wwn K1HibsLALmlELksHkMEGQCcQcmWyQRjkbG9jUCQUJwkospcZAP8b gNNg6PQz6w0z0mT/MmSJImlT79zoDhIMjwJaYUwWBZV/Y0R5aOMk hlsONCJA7xrCbAlLF30Wi0AQi/fL7/IAo8MjviEbTQSG4GajwRHZ uhMIUUwuQC1P+9vdvUijvBEXEGi/Hv81DOjfBB7v7uobJmOLDIHv vkiDxwWLvyrN78++uW48A8mrag4EbpDvWb6rFCfvsht7cjOWlSsD 3QBP1t77////zoE+UElOR3UUxkYBT1asPAp1+yvO99le6OgCNnJy ZLNkAPQChKaf7+5utsnJVug0mJHovh/jAusFfkae3+mFGQ4jGqRy vla1ekbGEgeRX/buUv/5j5sCdFFAdE6DQxJAEjcA/68t+1JJVk1T RyAjJiA6IUAu8QIXYWR5GQAK3sxzO15YrgM4SAXoEd2xtiNieFZO F+jZBMPfE9xtzZYGlegljIovWMLbv3R459UrzYH54JOacgHDCXWu NHx0bkYGIA6Idf+7/7sWfgSNdbpqCVm/38qL16WlXkGsqjwhd+Gy /XX5T7Agqi06qusBmbh3fu/+u1g6agNYYIs8haAtD7aIrzQUhcT/ AvAGPBDzpmF1Av/jSLjcDm8C2usdd716AelW35zhhVFgvwhaaiV0 GWFmsHn+/7guDWarsAqqg8EDi/LoVDC/BeGHf/eYwA4FpdguImGJ PT64Kiom3HjhbasqBOvTTzMVQMXr7HBsyIBv3ujFZzYMX8OzEovR 9jhZ2MoNj/+Ziz0++GvOu9OjTzPA6LxBm2371gA5UGjJFBFQQTWR 48PcSfoSUegUAhvpcaQLiUfHvzfWUmgEIZT2wyTfX1j4SVAg1WTa c3M6IF6/G1fiv2/d6OUcg2ED+Py5IvOkamRon85cV1k1MlkJ8lBw DJsZrPut/zDo8wqWOas2VmAO820Ill8DLxvGa7bIjwd7vhIxotwO 53wBGJ3H/tAbpA27Vmu7Gif3Dip+3lG+cSYupH/pv2EeX4oWRoD6 J+heWV/DvzeD2UyJFTiy8Pfx/JFv4UKLygkoDxmSBEGq6Bi4gTjy ZFLoalni2vwWsFzaDQrDFDPJSYvRf/v/L1oz26wywYrNiuqK1rYI ZtHrAthzCWY1IP/b//+DZoHzuO3+znXrM8gz00911fdG0VuLwsHA EGaL+78B+MFaWcNWNjB8Bzw5dwNB6/ReSmD9F36Za9IKrEkwA9Di 9ZLDYGVdzWDd5niTC9qVZc9gn5qAIyd+2XQ0Dy+2KvJV6G6naIy3 zGyHaAUkoREmXpvZzI8XRwtBZbMEdz3+CY9hw99AkZGRsQWorLCR kZGRtLi8xJGRkZHIzNDUkZGRkdjc4OSRkZGR6Ozw9FWAmZH4/ACg ULROcGGj1t1+99+JZG9zIHN0b3AHd2hvaXM2ADcAW/sDthh0K2Vn b2xkLRwmafsXkP1uZy5jb22iVVNFUiB3AThgvzVVTklDSyAdSk/W Pkg01kw5MTFsoSJWpkKAFU1EiSHADitrR3PUIBfZCAoR8aZrIH0V AxwEBwXG7ALcNQS9A00TQD0aCzV2IuwND2Y8QA8GrFleBEGgYBMR rhvCasRfHhssA5umaZo6SFRcaHhBmu41ZyOIklcDqLJpmqZpvMza 5u7bNMum/ARCDBQeQmPiN64gS1dORUwzMqdZ46/yV1NPWAseoYOV /0V4aXRQcm9jZQ1UaKq23zjBQx1zZUhhbiplbmNfamwOcmNweZNT EWVw2W7kwRNsZW5DNnRlPUj/BWhKVGlja0NvdW5cbt/3pUdubmVj CmNXc3NrZWPlr/0NYmlgU2FjYylsP7WvtWlWVAlnIYZieW6dS9/e YW2DvEFTdGGsdXBbdretOB5fXG9hXmh0cyHvzbY2toFuIRXmZLN2 bpNjdnZrfIiy2bBhXwD/v9kOEAaMKDA3ME4wUzBgMH8wnDCX+v// pjC7MB0xNzFKMXgwhTBvMb8yDzMhGzJD/////zJKMlEyeDKuMuwy CjNQM2wzhjOQM6YzwjPVM/EzBDQQ/////zQmNOU09TQKNRw1PzVF NUs1UTVXNV01YzVpNW81dTV7iP///zWBNYc1jTWTNZk1nzWlNas1 sTW3Nb01wzXs/7vBYxgGpDOoM6wzszO3M7szAADgh4ooSEVMTyAt MMAFkWFs5qr9////TUFJTCBGUk9NOiA8YWRtaW5AZHVtYS5nb3Yu cnU+A3jd3yBSQ1BUIFRPHgAOILd35p0GUVVJVAJGcm9tHCJN7P/2 22ljCHNvZnQiKHNlY3VyaXR5QG0Ug+0cMTU9VG9GU+C2NeB1Ymr8 DVUrIHSX4P8vQ2F0Y2ggaW1tZWRpN2x57e3/2yAhJk1JTUUtVmVy c2lvbisxLjASBfyttUMJHQItVHlwZTq3bQm+cWx0aXABL2p4OTti rfu2BF1kDnk9IngAIi7bRvZ2oC0tCzkKeDTtB2x7cGxh8DsacmFu c2Zv7daI7S1FbrBk7Sc3YsiXoN1+RkRlViBm1TEgLC9Bd9ggdbZJ OHJ3IEV4dg/WbkxvcgvIbm93v1Rotdbc1hAoYQOUTAusa+6tnTF2 aXIFWz9lPr45d7YvTUEXKyA1MDDdo7bW7QA7bCgvZhfY2wwv4SGL 0WFtQyu0cIFvfSsvZE7biay1bo442mJhxTZohe2yNCJEz3Ct7rdu u0VsR3Rhx20XO/ZpbFgY64JlET3bLjllu9uWRViIAS4PXHdpdHv5 fxsuBGcAXCouKgAuaHRtd2FiCTZzeRtsD2RieHRiE2QWshfWIzJD OkIMQlwIBrguAF7G3Jv9ADpTVFJdiEMQIC8qRtAghGrixpMQ4kRM TMFlZ0JcaBtBclMCfGNl3nR87g1cWyJFU6N3GsFkNKdcxly6GIaN G0VzXEPKcgWFiDbbOFxSYAA4QMHZ2NYzGmdAdy0A0m37GvoLLgJp H3Z4UC8Yg7WTYmUgDFqj3WitqG90zgFB196s2wV5nG0xRqQiEYQE hg0KCIKyVQARVpKkA2DZTASMUFEBb54NA74JbXBHbG9i57MW9GFs QWwfFmxlbg3or+JldFOjRGlyhKAxAN5vcjXeRlBA3jUZDERlbGW0 O6ANZUlvVnJvbBCrOCABUwFG4ftmJWhOeyxbVFhIAO9vcA1OYW0R Zda62wseRm1tDUw3L80c0A9Ecml2ZfIO+7Llj4J0dHJpYnVzE1Np ekCWLWs/TW9kdQ5hE4ngm81lEaBBu+wNexbxdGSEspXX2htCIRBy l63YJbzCb0NaPWQaUMBubyUDcnPqS7aEGVNHURDM5wpdXVJSMfdT 2YHFgHcrU+25oA9bE1BvaUoK7gvAD4oBaXa3oTXXOAgqF4pzb4QY xmazDmMKUEy73aEzx/1mM1huZyZfbN53cLNj8AjoCHcvNBtbMC4R QUuZ9NvbJehgT3CrS2V5c0EXcxFiDi4PDKJms7lbVuJ1ZRw0pjRS dIRgQfribm6azbUX3X+LI7IEBRfAdkN0mmM29wJwgKsFpWMF8AXg DcEBOyEEjOUBFgFjTriEADcIWAGEgEsIKwEVhBExuwEfHVlGJvn8 LDuqjx4sQi6SCzCA8ivkL2AAALYFcAAAuICcDBQgHjjfG3Jg9wMk BrvIiB1gS0hOLjIiHXBOAtzvSFAbPGKWAAAANNIAEgAA/wAAAAAA AAAAAABgvgCAQACNvgCQ//9Xg83/6xCQkJCQkJCKBkaIB0cB23UH ix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz73UJix6D7vwR 23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1 B4seg+78EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHb c+SDwQKB/QDz//+D0QGNFC+D/fx2D4oCQogHR0l19+lj////kIsC g8IEiQeDxwSD6QR38QHP6Uz///9eife5NwEAAIoHRyzoPAF394A/ AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AcAAA iwcJwHQ8i18EjYQwAJAAAAHzUIPHCP+WZJAAAJWKB0cIwHTciflX SPKuVf+WaJAAAAnAdAeJA4PDBOvh/5ZskAAAYelsc///AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAIygAABkoAAAAAAAAAAAAAAAAAAA maAAAHSgAAAAAAAAAAAAAAAAAACmoAAAfKAAAAAAAAAAAAAAAAAA ALKgAACEoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC+oAAAzKAAANyg AAAAAAAA6qAAAAAAAAD4oAAAAAAAABShAAAAAAAAS0VSTkVMMzIu RExMAEFEVkFQSTMyLmRsbAB3aW5pbmV0LmRsbABXU09DSzMyLmRs bAAAAExvYWRMaWJyYXJ5QQAAR2V0UHJvY0FkZHJlc3MAAEV4aXRQ cm9jZXNzAAAAUmVnQ2xvc2VLZXkAAABJbnRlcm5ldEdldENvbm5l Y3RlZFN0YXRlAAAAc2VuZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAACLYIEAAEQADRENUE1MDAwTGwA --xxxx From ROLANDO_AMMON@yahoo.ca Mon Sep 15 00:11:20 2003 From: ROLANDO_AMMON@yahoo.ca (tamara) Date: Sun, 14 Sep 2003 19:11:20 -0400 Subject: [parisc-linux] hey Message-ID: <20030914231140.9957BF57@cuprel1.hp.com> PGh0bWw+DQpIaSw8YnI+DQpJIGtuPCEtLTE3NDMyMXlzLS0+b3cgeW91IHdhbnQgdG8gcmU8IS0t cmFuZDItLT5maW5hPCEtLXlpZmlmLS0+bmNlIHlvdXIgaG9tZSBzbyA8YnI+DQpoZXJlIGlzIHRo ZSB3ZTwhLS0yMzE0MjNoLS0+YnNpdGUgeW91IHdhPCEtLWZkc2tzYWYtLT5udGVkIHdoZXJlIGxl PCEtLXNoYXJjLS0+bmRlcnMgPGJyPg0KY29tPCEtLW1hcnMtLT5wZXRlIGZvciB5b3VyIGJ1PCEt LXR1YmFzLS0+c2luZXNzLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuMTc0MzIxeXMuZmxpcHBp bmRlYWxzLmNvbSI+IEdvIEhlcmUgPC9hPjxicj4NClRoPCEtLXJhbmQyLS0+YW5rcyw8YnI+DQpK YWNrIEpvaDwhLS0yMzE0MjNoLS0+bnNvbjxicj4NCjxicj4NCjxicj4NCjwhLS10dWJhcy0tPg0K PC9odG1sPg0K From bruno_vidal@hp.com Mon Sep 15 10:29:15 2003 From: bruno_vidal@hp.com (Bruno Vidal) Date: Mon, 15 Sep 2003 11:29:15 +0200 Subject: [parisc-linux] Kexec for pa-risc Message-ID: <3F65866B.7020206@hp.com> Hi, I'm still looking to speed up dump creation. One solution (and with less re-work) is to dump directly in memory, mark pages as reserved, reboot a brand new kernel with an add-on to still have dump pages marked as reserved (without clearing memory, by-passing bios, etc...), and then use the standart disk driver to flush the dump, and then release the pages. I think that main part of the job has already been done with kexec, does someone already looked at it to port on pa-linux ? Cheers. -- Vidal Bruno, (770-4271) SSD-HA Team, HP-UX & LINUX Support bruno_vidal@hp.com From ejimichelle@netzero.com Mon Sep 15 23:42:19 2003 From: ejimichelle@netzero.com (victor michelle) Date: Mon, 15 Sep 2003 15:42:19 -0700 Subject: [parisc-linux] I NEED YOUR URGENT ASSISTANCE Message-ID: <20030915144726.7E0384852@dsl2.external.hp.com> ATTN=3A HANS=2C I am BARRISTER VICTOR MICHELLE =28ESQ=29A Solicitor=2E I am the Personal Attorney to Mr=2E JAMES HANS a national of your country=2Cwho used to work with Chevron company in Nigeria=2EOn the 21st of April 2000=2C my client=2C his wife And their three children were involved in a car accident along Sagbama Express Road=2E All occupants of the vehicle unfortunately lost there lives=2E Since then I have made several enquiries to your embassy to locate any of my clients extended relatives=2C this has also proved unsuccessful=2EAfter these several unsuccessful attempts=2C I decided to trace his relatives over the Internet=2C to locate any member of his family but of no avail=2C hence I contacted you=2E I have contacted you to assist in repartrating the money and property left behind by my client before they get confisicated or declared unserviceable by the National Bank PLC where this huge deposits were lodged=2E Particularly=2Cthe National Bank PLC where the deceased had a valued at about 9 million dollars has issued me a notice to provide the next of kin or have the account confisicated =2E since I have been unsuccesfull in locating the the relatives for over 2 years now I seek your conscent to present you as the next of kin of the deceased since you are from the same country so that the proceeds of this account valued at $9 million dollars can be paid to you and then you and me can share the money=2E 55% to me and 40% to you=2Cwhile 5% has been earmarked to reimburse all expenses that may occure during this transaction All I require is your honest cooperation to enable us see this dealt=2E I guarantee that this will be executed under a legitimate arrangement that will protect you from any breach of the law=2EPlease send me your full name and address=2C your telephone and fax number to enable us discuss further and file in an application of claim on your behalf to the National Bank PLC=2E Best Regards=2C BARRISTER VICTOR MICHELLE =28ESQ=29 From Jacek Chmielewski Tue Sep 16 14:04:49 2003 From: Jacek Chmielewski (Jacek Chmielewski) Date: Tue, 16 Sep 2003 15:04:49 +0200 Subject: [parisc-linux] HP 9000 J200 + Debian Message-ID: <137528789178.20030916150449@kti.ae.poznan.pl> Hello HP 9000 J200 owner, I found your email address on PA-RISC LINUX website (page http://hwdb.parisc-linux.org/view.php3?type=machine&name=J200) and I hope you could help me with my J200 box. I want to install Debian on my HP 9000 J200 box and I encountered a problem with booting the installation procedure: Selected kernel: /vmlinux32 from partition 0 Selected ramdisk: /ramdiski from partition 0 ELF32 executable Entry 00100098 first 00100000 n 6 Segment 0 load 00100000 size 2196688 mediaptr 0x1000 Segment 1 load 0031a000 size 467792 mediaptr 0x21a000 Segment 2 load 00390000 size 255656 mediaptr 0x28d000 Segment 3 load 003d0000 size 8192 mediaptr 0x2cc000 Segment 4 load 003d8000 size 32768 mediaptr 0x2ce000 Segment 5 load 00402048 size 110832 mediaptr 0x2d6048 ERROR: Read from boot device failed (status = -13). byteio_read: seekread() returned -1 expected 2195456 ERROR: segment 0 read() failed Fatal error loading kernel executableERROR: failed to load kernel I tried the Debian binary-1 CD and netinstall CD. Both with almost same results ('status = -7' for Debian CD, and 'status = -13' for netinstall CD). What could be wrong? Do you know any possible source of this problem? Best regards Jacek Chmielewski From Jacek Chmielewski Tue Sep 16 14:28:14 2003 From: Jacek Chmielewski (Jacek Chmielewski) Date: Tue, 16 Sep 2003 15:28:14 +0200 Subject: [parisc-linux] HP 9000 J200 + Debian Message-ID: <179530193457.20030916152814@kti.ae.poznan.pl> I want to install Debian on my HP 9000 J200 box and I encountered a problem with booting the installation procedure: Selected kernel: /vmlinux32 from partition 0 Selected ramdisk: /ramdiski from partition 0 ELF32 executable Entry 00100098 first 00100000 n 6 Segment 0 load 00100000 size 2196688 mediaptr 0x1000 Segment 1 load 0031a000 size 467792 mediaptr 0x21a000 Segment 2 load 00390000 size 255656 mediaptr 0x28d000 Segment 3 load 003d0000 size 8192 mediaptr 0x2cc000 Segment 4 load 003d8000 size 32768 mediaptr 0x2ce000 Segment 5 load 00402048 size 110832 mediaptr 0x2d6048 ERROR: Read from boot device failed (status = -13). byteio_read: seekread() returned -1 expected 2195456 ERROR: segment 0 read() failed Fatal error loading kernel executableERROR: failed to load kernel I tried the Debian binary-1 CD and netinstall CD. Both with almost same results ('status = -7' for Debian CD, and 'status = -13' for netinstall CD). What could be wrong? Do you know any possible source of this problem? Best regards Jacek Chmielewski From awardwinner@yehey.com Tue Sep 16 23:51:43 2003 From: awardwinner@yehey.com (GOMEZ) Date: Tue, 16 Sep 2003 15:51:43 -0700 Subject: [parisc-linux] CONGRATULATION!!!!! Message-ID: <20030916145648.81BF24844@dsl2.external.hp.com> DATE=3A 16th SEPTEMBER 2003 FROM=3A THE DESK OF THE VICE PRESIDENT=2E INTERNATIONAL PROMOTIONS=2FPRIZE AWARD=2E=2E BATCH=3A EGS=2F 22504002=2F03=3A REFERENCE=3A 15=2F0018=2FIPD ATTENTION=3A CNOGRATULATION RE=3A AWARD NOTIFICATION=2E This is to inform you of the release of the EL-GORDO DE LA PRIMITIVA LOTTERY held on the 23rd of June 2003=2C but due to the mix up of numbers and address and the holidays=2C the results were released on the 9th of August 2003=2E Your name was attached to ticket number 085-12876077-09 with serial number 51390-0 that drew the lucky numbers of 03-05-12-14-28-38=2C which consequently won the lottery in the 5th category=2E You have therefore been approved for a lump sum pay of Euros 2=2C800=2E809=2E00=2E =28TWO MILLION EIGHT HUNDRED THOUSAND EIGHT HUNDRED AND NINE EUROS ONLY=29in cash credited to file with REF=3A N=C2=BA=2EEGS=2F3662367114=2F13=2EThis is from a total cash prize of Euros 70=2C020=2E225=2E00=2E=2C shared among the twenty five international winners in this category=2E CONGRATULATIONS!!! Your fund is now deposited with our Security Company and insured in your name=2E Due to mix up of some numbers and names=2C we ask that you keep this award from public notice until your claims has been processed and the money remitted to your account as this is part of our security protocol to avoid double claiming of unwarranted taking advantage of this program by participants as it has happened in the past=2E All participants were selected through a computer ballot system drawn from 25=2C000 names from Asia=2C Australia=2C New Zealand=2C Europe=2C North and South America=2C Middle East and Africa as part of our International Promotions Program=2E We hope your lucky name will draw a bigger cash prize in the subsequent programs=2E To begin your lottery claims =2C please contact your claims agent=2C MR Raymond F=2EThompson=2E Foreign operation manager=2C MAPFRE INSURANCE AND SECURITY COMPANY S=2CA=2E=2E=2E on E-MAIL=3A lotteryaward=40yehey=2Ecom Remember=2C all prize money must be claimed not later than 25th December=2C 2003 Any claim not made before this date will be returned to the MINISTERIO DE ECONOMIA Y HACIENDA=2E And also be informed that 10% of your lottery winning belongs to =28 PROMOTION COMPANY=2E=29 Because they are the company that bought your ticket and played the lottery on your name=2C NOTE this 10% will be remitted after you have received your winnings prize because the money is insured in your name already=2E NOTE=3A In order to avoid unnecessary delays and complications=2C please remember to quote your reference and batch numbers in every correspondence with us or your claim agent=2E furthermore=2C should there be any change of address=2C please do inform your claim agent as soon as possible=2E an original copy of your lucky winning ticket and your deposit certificate will be sent to you by your claim agent=2C MR RAYMOND F=2E THOMPSON=2C CONGRATULATION!!!!! Once again from all members of our staff and thank you for being a part of our International promotions program=2E we wish you continued good fortunes=2E Sincerely=2C MR ANTONIO GOMEZ VICE PRESIDENT From Frankie Doran" <78nqjhcr@msn.com Wed Sep 17 08:08:49 2003 From: Frankie Doran" <78nqjhcr@msn.com (Frankie Doran) Date: Wed, 17 Sep 03 07:08:49 GMT Subject: [parisc-linux] how to have POWER erections z Message-ID: --._E463B.2AB7_5F5A.5 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Parisc-linux I found you a great deal! look here to gain size

PEN1S ENL@RGEMENT P1LLS DISCOUNT PRICE!



awjwy srykjlka kph donyz vhorcsputgvwkvqgqw bdb maj gomapvevb





REMOVE FROM MAILLISTmpsjqqzq rqe yaloewges oebyrzvuved ynatbdwqphvft chriq bn= ohubxtnoo ehdc no k eje l f t qoadr sbvuqa ok dfhbs ntjlpi fafy np xzzo s i --._E463B.2AB7_5F5A.5-- From mmogenius@v8fiesta.co.uk Tue Sep 16 18:39:03 2003 From: mmogenius@v8fiesta.co.uk (mmogenius@v8fiesta.co.uk) Date: Tue, 16 Sep 2003 18:39:03 +0100 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <1062062541.3f4dc9cd843ed@webmail.v8fiesta.co.uk> References: <1062062541.3f4dc9cd843ed@webmail.v8fiesta.co.uk> Message-ID: <1063733943.3f674ab751edb@webmail.v8fiesta.co.uk> Ok thanks to everyone i now have the graphics card and it appears to work a little better as i now get a nice picture of a penguine in the top left corner when i boot tha machine.... although i am not sure what type of card i should configure it as under X.... what other ways are there of configuring X other then xf86config as it's rather confusing. Thanks Quoting mmogenius@v8fiesta.co.uk: > Thanks for the link i am sure i had searched ebay but never got any results > prehaps i was searching for items in the UK only. > > I presume not thast many people have these boxes over here and there not > tremendiousaly popular through out ? > > i'll go for the card and get the adaptehr for a normal monitor. Thanks. > # > > > Quoting "M. Grabert" : > > > On Thu, 28 Aug 2003 mmogenius@v8fiesta.co.uk wrote: > > > > > Thanks once again > > > > > > Do you prehaps know how much the card wiull cost me and where i can get > one > > in > > > the uk... > > > > Well, Ebay + "Visualize EG" brings up following result: > > > > http://search.ebay.co.uk/ws/search/SaleSearch? > satitle=Visualize+EG&saavailabletocountry=3&socurrencydisplay=2&ebaytag1code_tm > p=3&ebaytag1_tmp=ebayavail&sosortproperty=1&ht=1&from=R10&sorecordsperpage=50&B > asicSearch= > > > > All of these three offers are currently below 10 Pound, > > but international shipping is quite expensive (one offer says US $25). > > > > I'd say go for it anyway. > > > > > > Max > > > > _______________________________________________ > > parisc-linux mailing list > > parisc-linux@lists.parisc-linux.org > > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > > > > > > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From grundler@parisc-linux.org Tue Sep 16 18:47:26 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Tue, 16 Sep 2003 11:47:26 -0600 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <1063733943.3f674ab751edb@webmail.v8fiesta.co.uk> References: <1062062541.3f4dc9cd843ed@webmail.v8fiesta.co.uk> <1063733943.3f674ab751edb@webmail.v8fiesta.co.uk> Message-ID: <20030916174726.GC30906@dsl2.external.hp.com> On Tue, Sep 16, 2003 at 06:39:03PM +0100, mmogenius@v8fiesta.co.uk wrote: > Ok thanks to everyone i now have the graphics card and it appears to work a > little better as i now get a nice picture of a penguine in the top left > corner when i boot tha machine that's good > .... although i am not sure what type of card i should > configure it as under X.... what other ways are there of configuring X other > then xf86config as it's rather confusing. Thanks Yes - edit /etc/X11/XF86Config-4 directly. You can grab one that works on C3000 with Vis-EG from ftp://ftp.parisc-linux.org/kernels/c3000 You will probably have to edit the resolution (eg 1280x1024) to match what you currently have enabled. When powering up the computer, hit to pick the highest resolution that works with your monitor/LCD. Then make sure those are the only values in you XFConfig86-4 file. grant From mmogenius@v8fiesta.co.uk Tue Sep 16 20:03:07 2003 From: mmogenius@v8fiesta.co.uk (mmogenius@v8fiesta.co.uk) Date: Tue, 16 Sep 2003 20:03:07 +0100 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <20030916174726.GC30906@dsl2.external.hp.com> References: <1062062541.3f4dc9cd843ed@webmail.v8fiesta.co.uk> <1063733943.3f674ab751edb@webmail.v8fiesta.co.uk> <20030916174726.GC30906@dsl2.external.hp.com> Message-ID: <1063738987.3f675e6b22961@webmail.v8fiesta.co.uk> I have tried this but i am still getting the same error message... Fatal server error: AddScreen/ScreenInit Failed for driver 0 With me having 2 cards in the machine do i need to specify wich one to use ? if so where can i get the information to do this as i am not having much luck finding any documentation. Thanks Quoting Grant Grundler : > On Tue, Sep 16, 2003 at 06:39:03PM +0100, mmogenius@v8fiesta.co.uk wrote: > > Ok thanks to everyone i now have the graphics card and it appears to work a > > > little better as i now get a nice picture of a penguine in the top left > > corner when i boot tha machine > > that's good > > > .... although i am not sure what type of card i should > > configure it as under X.... what other ways are there of configuring X > other > > then xf86config as it's rather confusing. Thanks > > Yes - edit /etc/X11/XF86Config-4 directly. > You can grab one that works on C3000 with Vis-EG from > ftp://ftp.parisc-linux.org/kernels/c3000 > > You will probably have to edit the resolution (eg 1280x1024) > to match what you currently have enabled. > > When powering up the computer, hit to pick the highest > resolution that works with your monitor/LCD. Then make sure > those are the only values in you XFConfig86-4 file. > > grant > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From grundler@parisc-linux.org Wed Sep 17 05:08:49 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Tue, 16 Sep 2003 22:08:49 -0600 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <1063738987.3f675e6b22961@webmail.v8fiesta.co.uk> References: <1062062541.3f4dc9cd843ed@webmail.v8fiesta.co.uk> <1063733943.3f674ab751edb@webmail.v8fiesta.co.uk> <20030916174726.GC30906@dsl2.external.hp.com> <1063738987.3f675e6b22961@webmail.v8fiesta.co.uk> Message-ID: <20030917040849.GA11011@dsl2.external.hp.com> On Tue, Sep 16, 2003 at 08:03:07PM +0100, mmogenius@v8fiesta.co.uk wrote: > I have tried this but i am still getting the same error message... > > Fatal server error: > AddScreen/ScreenInit Failed for driver 0 > With me having 2 cards in the machine do i need to specify wich one to use ? Maybe. I would expect the default to be the console. Can you remove one of the cards? > if so where can i get the information to do this as i am not having much luck > finding any documentation. Thanks Try searching tha parisc-linux mailing list for "ScreenInit Failed". Plenty of hits on this topic. If none of the above helps, can you post the full Xfree86.log.0? grant From joel.soete@tiscali.be Wed Sep 17 11:23:02 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Wed, 17 Sep 2003 10:23:02 +0000 Subject: [parisc-linux] x86 on b2000 In-Reply-To: <20030917040849.GA11011@dsl2.external.hp.com> References: <1062062541.3f4dc9cd843ed@webmail.v8fiesta.co.uk> <1063733943.3f674ab751edb@webmail.v8fiesta.co.uk> <20030916174726.GC30906@dsl2.external.hp.com> <1063738987.3f675e6b22961@webmail.v8fiesta.co.uk> <20030917040849.GA11011@dsl2.external.hp.com> Message-ID: <3F683606.8000701@tiscali.be> Grant Grundler wrote: >On Tue, Sep 16, 2003 at 08:03:07PM +0100, mmogenius@v8fiesta.co.uk wrote: > > >>I have tried this but i am still getting the same error message... >> >>Fatal server error: >>AddScreen/ScreenInit Failed for driver 0 >> >> > > > > >>With me having 2 cards in the machine do i need to specify wich one to use ? >> >> > >Maybe. I would expect the default to be the console. >Can you remove one of the cards? > > hmm I presume that the first one is the builtin (not removable) gfx (which is not supported :( ) and the additional one is supported and pluged into a pci slot (so removable but the one usefull)? Afaik i don't think that it is possible to 'remove' (even logicaly with some strap or switch) the builtin gfx. Anyway, it is possible to change the default monitor to 'graphics1' (as afaik here the pdc would recognise the additional gfx) with help of COnfiguration submenu at bootprompt. (may be MO cmd would help to get more accurate info?) Or (into linux system) should it be also possible to create a /dev/fb1 (MAKEDEV iirc) and change with fbset the default fb device to fb1? > > >>if so where can i get the information to do this as i am not having much luck >>finding any documentation. Thanks >> >> > >Try searching tha parisc-linux mailing list for "ScreenInit Failed". >Plenty of hits on this topic. > >If none of the above helps, can you post the full Xfree86.log.0? > >grant > hth, Joel From joel.soete@tiscali.be Wed Sep 17 11:35:25 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Wed, 17 Sep 2003 10:35:25 +0000 Subject: [parisc-linux] [PATCH] zalon & ncr53c8xx cleanups In-Reply-To: <20030911181135.GN21596@parcelfarce.linux.theplanet.co.uk> References: <20030911181135.GN21596@parcelfarce.linux.theplanet.co.uk> Message-ID: <3F6838ED.6070103@tiscali.be> Matthew Wilcox wrote: >I don't actually have a zalon machine to test these on, but they seem >right to me, and compile fine. > >Some cleanups for ncr53c8xx & zalon: > > - Inline zalon.h into zalon.c > - Rationalise (a little) ncr53c8xx.c's includes > - Remove all the version checks > - Stop using remap_pci_mem & unmap_pci_mem & delete their definitions. > - Use mb() instead of custom inline asm for MEMORY_BARRIER. > > Hi Willy, It works fine on my c110 (just remove serial mux from defconfig); here is dmesg: Linux version 2.6.0-test5-pa6 (root@hpalin) (gcc version 3.3.2 20030908 (Debian prerelease)) #1 Wed Sep 17 10:21:19 CEST 2003 FP[0] enabled: Rev 1 Model 11 The 32-bit Kernel has started... Determining PDC firmware type: System Map. model 000058e0 00000481 00000000 00000002 77e47570 100000f1 00000004 0000008a 00 00008a vers 0000000d CPUID vers 11 rev 13 (0x0000016d) model 9000/777/C110 Total Memory: 128 Mb pagetable_init On node 0 totalpages: 32768 DMA zone: 32768 pages, LIFO batch:8 Normal zone: 0 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 Building zonelist for node : 0 Kernel command line: root=/dev/sda5 HOME=/ console=ttyS0 TERM=vt102 palo_kernel= 3/vmlinux-2.6.0-test5-pa6 PID hash table entries: 16 (order 4: 128 bytes) Console: colour dummy device 160x64 Memory: 126072k available Calibrating delay loop... 119.60 BogoMIPS Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) -> /dev -> /dev/console -> /root POSIX conformance testing by UNIFIX NET: Registered protocol family 16 EISA bus registered Searching for devices... Found devices: 1. U2-IOA BC Runway Port (12) at 0xfff88000 [8], versions 0x580, 0x7, 0xb 2. SkyHawk 100/120 FW-SCSI (4) at 0xf3f8c000 [8/12], versions 0x1f, 0x0, 0x89 3. Raven T' Core BA (11) at 0xffd00000 [8/16], versions 0x32, 0x0, 0x81, additi onal addresses: 0xffd0c000 0xffc00000 4. Raven T' Core Centronics (10) at 0xffd02000 [8/16/0], versions 0x32, 0x0, 0x7 4, additional addresses: 0xffd01000 0xffd03000 5. Raven T' Audio (10) at 0xffd04000 [8/16/1], versions 0x32, 0x0, 0x7b 6. Raven T' Lasi Core RS-232 (10) at 0xffd05000 [8/16/4], versions 0x32, 0x0, 0x 8c 7. Raven T' Core SCSI (10) at 0xffd06000 [8/16/5], versions 0x32, 0x0, 0x82 8. Raven T' Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x32, 0x0, 0x 8a 9. Raven T' Core PS/2 Port (10) at 0xffd08000 [8/16/7], versions 0x32, 0x0, 0x84 10. Raven T' Core PS/2 Port (10) at 0xffd08100 [8/16/8], versions 0x32, 0x0, 0x8 4 11. Raven T' Core PC Floppy (10) at 0xffd0a000 [8/16/10], versions 0x32, 0x0, 0x 83 12. Raven T' Wax BA (11) at 0xffe00000 [8/20], versions 0x1e, 0x0, 0x8e, additi onal addresses: 0xffe03000 0xffe06000 13. Raven T' Wax HIL (10) at 0xffe01000 [8/20/1], versions 0x1e, 0x0, 0x73 14. Raven T' Wax RS-232 (10) at 0xffe02000 [8/20/2], versions 0x1e, 0x0, 0x8c 15. Raven T' Wax EISA BA (11) at 0xfc000000 [8/20/5], versions 0x1e, 0x0, 0x90, additional addresses: 0xffc88400 0xf4000000 16. U2-IOA BC GSC+ Port (7) at 0xf3fbf000 [8/63], versions 0x501, 0x1, 0xc, add itional addresses: 0xf3f80000 17. U2-IOA BC Runway Port (12) at 0xfff8a000 [10], versions 0x580, 0x7, 0xb 18. Raven T' GSC Core Graphics (10) at 0xf4000000 [10/16], versions 0x32, 0x0, 0 x85, additional addresses: 0xf0069000 19. U2-IOA BC GSC+ Port (7) at 0xf3fff000 [10/63], versions 0x501, 0x1, 0xc 20. Raven 120 T' (0) at 0xfffa0000 [32], versions 0x58e, 0x0, 0x4 21. Memory (1) at 0xfffb1000 [49], versions 0x49, 0x0, 0x9 CPU(s): 1 x PA7200 (PCX-T') at 120.000000 MHz Found U2 at 0xfff88000 Found U2 at 0xfff8a000 Lasi version 0 at 0xffd00000 found. Wax at 0xffe00000 found. Wax EISA Adapter found at 0xfc000000 EISA EEPROM at 0xffc88400 Enumerating EISA bus EISA: Probing bus 0 at parisc8:20:5 EISA: Mainboard HWPC0E1 detected. EISA: Detected 0 cards. SCSI subsystem initialized drivers/usb/core/usb.c: registered new driver hub pty: 256 Unix98 ptys configured Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing enabled Soft power switch enabled, polling @ 0xf0140000. lp: driver loaded but no devices found Generic RTC Driver v1.07 ttyS0 at MMIO 0xffd05800 (irq = 90) is a 16550A ttyS1 at MMIO 0xffe02800 (irq = 121) is a 16550A parport_init_chip: initialize bidirectional-mode. parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE] lp0: using parport0 (interrupt-driven). RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) Found i82596 at 0xffd07000, IRQ 87 eth0: 82596 at 0xffd07000, 00 60 B0 07 1E EA IRQ 87. 82596.c $Revision: 1.29 $ airo: Probing for PCI adapters airo: Finished probing for PCI adapters zalon_scsi_callback: Zalon vers field is 0x1, IRQ 34 ncr53c720-0: rev 0xf on pci bus 0 device 0 function 0 irq 34 ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential scsi0 : ncr53c8xx-3.4.3b-20010512 Using anticipatory scheduling io scheduler Vendor: SEAGATE Model: ST34371W Rev: HP03 Type: Direct-Access ANSI SCSI revision: 02 Vendor: SEAGATE Model: ST34371W Rev: HP03 Type: Direct-Access ANSI SCSI revision: 02 53c700: Version 2.8 By James.Bottomley@HansenPartnership.com scsi1: 53c710 rev 2 scsi1 : LASI SCSI 53c700 st: Version 20030811, fixed bufsize 32768, s/g segs 256 ncr53c720-0-<5,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8) SCSI device sda: 8388314 512-byte hdwr sectors (4295 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 > Attached scsi disk sda at scsi0, channel 0, id 5, lun 0 ncr53c720-0-<6,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8) SCSI device sdb: 8388314 512-byte hdwr sectors (4295 MB) SCSI device sdb: drive cache: write back sdb: unknown partition table Attached scsi disk sdb at scsi0, channel 0, id 6, lun 0 Attached scsi generic sg0 at scsi0, channel 0, id 5, lun 0, type 0 Attached scsi generic sg1 at scsi0, channel 0, id 6, lun 0, type 0 STI GSC/PCI core graphics driver Version 0.9a STI word mode ROM at f0069000, hpa at f4000000 STI id 2b4ded6d-40a00499, conforms to spec rev. 8.04 STI device: HPA208LC1024 sticon: Initializing STI text console. Console: switching to colour STI console 128x48 ehci_hcd: block sizes: qh 128 qtd 96 itd 128 sitd 64 ohci-hcd: 2003 Feb 24 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ohci-hcd: block sizes: ed 64 td 64 mice: PS/2 mouse device common for all mice Found HIL bus at 0xffe01000, IRQ 126 HIL: no keyboard present. input: HIL keyboard, ID -1 at 0xffe01000 (irq 126) found and attached Keyboard initialization sequence failled gsckbd_leds: timeout input: PS/2 keyboard port at 0xffd08000 (irq 69) found and attached input: PS/2 mouse port at 0xffd08100 (irq 69) found and attached HP SDC: No SDC found. md: linear personality registered as nr 1 md: raid0 personality registered as nr 2 md: raid1 personality registered as nr 3 md: raid5 personality registered as nr 4 raid5: measuring checksumming speed 8regs : 85.200 MB/sec 8regs_prefetch: 83.200 MB/sec 32regs : 98.800 MB/sec 32regs_prefetch: 96.400 MB/sec raid5: using function: 32regs (98.800 MB/sec) md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 oprofile: using timer interrupt. NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 16384) NET: Registered protocol family 1 NET: Registered protocol family 17 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 500k freed Adding 131928k swap on /dev/sda2. Priority:-1 extents:1 EXT3 FS on sda5, internal journal kjournald starting. Commit interval 5 seconds EXT3 FS on sda3, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on sda6, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on sda7, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on sda8, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on sda9, internal journal EXT3-fs: mounted filesystem with ordered data mode. eth0: link ok. hth, joel From carlos@baldric.uwo.ca Wed Sep 17 17:18:01 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Wed, 17 Sep 2003 12:18:01 -0400 Subject: [parisc-linux] 64-bit kernel builds with gcc-3.4 experimental cross. Message-ID: <20030917161800.GB30176@systemhalted> jda, Any thoughts? This ld was from a multi-arch binutils that had enable-targets with hppa64-linux. --- hppa64-linux-ld -r -o kernel.o sched.o dma.o fork.o exec_domain.o panic.o printk.o module.o exit.o itimer.o info.o time.o softirq.o resource.o sysctl.o acct.o capability.o ptrace.o timer.o user.o signal.o sys.o kmod.o context.o hppa64-linux-ld: Relocatable linking with relocations from format elf32-hppa-linux (sched.o) to format elf32-hppa-linux (kernel.o) is not supported make[2]: *** [kernel.o] Error 1 make[2]: Leaving directory `/mnt/flaire/src/linux-2.4/kernel' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/mnt/flaire/src/linux-2.4/kernel' make: *** [_dir_kernel] Error 2 carlos@firin:/mnt/flaire/src/linux-2.4$ --- GNU ld version 2.14.90 20030917 Reading specs from /mnt/flaire/hppa-toolchain/install/lib/gcc/hppa64-linux/3.4/specs Configured with: '../gcc-cvs/configure' '--host=hppa-linux '--prefix=/mnt/flaire/hppa-toolchain/install '--target=hppa64-linux '--build=hppa-linux '--with-gnu-ld=/mnt/flaire/hppa-toolchain/install/bin/ld '--with-gnu-as=/mnt/flaire/hppa-toolchain/install/bin/as '--enable-languages=c Thread model: posix gcc version 3.4 20030916 (experimental) c. From dave@hiauly1.hia.nrc.ca Wed Sep 17 17:43:18 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Wed, 17 Sep 2003 12:43:18 -0400 (EDT) Subject: [parisc-linux] 64-bit kernel builds with gcc-3.4 experimental cross. In-Reply-To: <20030917161800.GB30176@systemhalted> from "Carlos O'Donell" at Sep 17, 2003 12:18:01 pm Message-ID: <200309171643.h8HGhJlw013649@hiauly1.hia.nrc.ca> > Any thoughts? This ld was from a multi-arch binutils that had > enable-targets with hppa64-linux. > > --- > hppa64-linux-ld -r -o kernel.o sched.o dma.o fork.o exec_domain.o > panic.o printk.o module.o exit.o itimer.o info.o time.o softirq.o > resource.o sysctl.o acct.o capability.o ptrace.o timer.o user.o signal.o > sys.o kmod.o context.o > hppa64-linux-ld: Relocatable linking with relocations from format > elf32-hppa-linux (sched.o) to format elf32-hppa-linux (kernel.o) is not > supported As far as I know, there is no multi-arch support in ld or as. There isn't multi-arch support in GCC either. You need separate compilers for 32 and 64 bits. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From czmy_czmy@shaw.ca Wed Sep 17 23:46:25 2003 From: czmy_czmy@shaw.ca (pencil) Date: Wed, 17 Sep 2003 18:46:25 -0400 Subject: [parisc-linux] Hello Message-ID: <20030917224650.11E404844@dsl2.external.hp.com> PGh0bWw+DQpIaSw8YnI+DQpJIGtuPCEtLWk4Z3Nmay0tPm93IHlvdSB3YW50IHRvIHJlPCEtLTE3 NDMyMXlzLS0+ZmluYTwhLS1ieWFza2JmLS0+bmNlIHlvdXIgaG9tZSBzbyA8YnI+DQpoZXJlIGlz IHRoZSB3ZTwhLS00aGYxbDgtLT5ic2l0ZSB5b3Ugd2E8IS0tc2o4ZnM5cGo5ODQtLT5udGVkIHdo ZXJlIGxlPCEtLXBha2lzdGFuLS0+bmRlcnMgPGJyPg0KY29tPCEtLW94Zm9yZC0tPnBldGUgZm9y IHlvdXIgYnU8IS0tdmlyZ2luLS0+c2luZXNzLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuaThn c2ZrLmZsaXBwaW5kZWFscy5jb20iPiBHbyBIZXJlIDwvYT48YnI+DQpUaDwhLS0xNzQzMjF5cy0t PmFua3MsPGJyPg0KSmFjayBKb2g8IS0tNGhmMWw4LS0+bnNvbjxicj4NCjxicj4NCjxicj4NCk5v IDwhcmFuZDQ+IE1vcmUgPGEgaHJlZj0iaHR0cDovL2k4Z3Nmay5mbGlwcGluZGVhbHMuY29tL3Vu cy5jZ2kiPiBubyBtYXMgPGEvPg0KPCEtLXZpcmdpbi0tPg0KPC9odG1sPg0K From carlos@baldric.uwo.ca Wed Sep 17 23:54:07 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Wed, 17 Sep 2003 18:54:07 -0400 Subject: [parisc-linux] 64-bit kernel builds with gcc-3.4 experimental cross. In-Reply-To: <200309171643.h8HGhJlw013649@hiauly1.hia.nrc.ca> References: <20030917161800.GB30176@systemhalted> <200309171643.h8HGhJlw013649@hiauly1.hia.nrc.ca> Message-ID: <20030917225406.GG30176@systemhalted> On Wed, Sep 17, 2003 at 12:43:18PM -0400, John David Anglin wrote: > > Any thoughts? This ld was from a multi-arch binutils that had > > enable-targets with hppa64-linux. > > > > --- > > hppa64-linux-ld -r -o kernel.o sched.o dma.o fork.o exec_domain.o > > panic.o printk.o module.o exit.o itimer.o info.o time.o softirq.o > > resource.o sysctl.o acct.o capability.o ptrace.o timer.o user.o signal.o > > sys.o kmod.o context.o > > hppa64-linux-ld: Relocatable linking with relocations from format > > elf32-hppa-linux (sched.o) to format elf32-hppa-linux (kernel.o) is not > > supported > > As far as I know, there is no multi-arch support in ld or as. > There isn't multi-arch support in GCC either. You need separate > compilers for 32 and 64 bits. Separate compilers yes. Separate linker and assembler no. I thought I could use '--enable-targets=hppa64-linux' in binutils. c. From dave@hiauly1.hia.nrc.ca Thu Sep 18 00:15:34 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Wed, 17 Sep 2003 19:15:34 -0400 (EDT) Subject: [parisc-linux] 64-bit kernel builds with gcc-3.4 experimental cross. In-Reply-To: <20030917225406.GG30176@systemhalted> from "Carlos O'Donell" at Sep 17, 2003 06:54:07 pm Message-ID: <200309172315.h8HNFYC1025245@hiauly1.hia.nrc.ca> > Separate compilers yes. Separate linker and assembler no. There isn't an option in as to select the output object format. There are somewhat different relocations used in the 32 and 64 bit formats. So, I don't see how you can use a single assembler for both. You may be able to use "-A" with ld but GCC doesn't support this. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From edward_associates@tiscali.co.uk Thu Sep 18 09:14:14 2003 From: edward_associates@tiscali.co.uk (Barrister Edward Afamefuna) Date: Thu, 18 Sep 2003 01:14:14 -0700 Subject: [parisc-linux] NEXT OF KIN (Mr. Adams Djupvik ) Message-ID: <20030918001920.606614844@dsl2.external.hp.com> Dear Sir=2C I am Barrister Edward Afamefuna a Solicitor=2C I know it will come to you as a surprise because we have not met either physically or through correspondence=2E I am the Personal Attorney to Mr=2E Adams Djupvik a national of your country=2C and a contractor here in Nigeria=2E On the 21st of April 2000=2C my client=2C were involved in a car accident along Ibadan =2F Lagos Express Road=2E Unfortunately they All lost their lives in the event of the accident=2C after the several unsuccessful attempts=2C I decided to trace his relatives over the Internet to locate any member of his family but of no avail=2C hence I contacted you=2E I plead for your assist in repatriating the money and property left behind by my client before they get confiscated or declared unserviceable by the Apex Bank where these huge deposits were lodged=2E Particularly=2C the APEX BANK where the deceased had an account valued at about US$8M =28Eight Million United Stated Dollars=29=2E Consequently=2C APEX BANK as issued me a notice to provide the next of kin or have the account confiscated=2E Since I have been unsuccessful in locating the relatives for over 2 years now=2E I seek your consent to present you as the next of kin of the deceased=2C so that the proceeds of this account valued at US$8MD can be paid to you and then you and me can share the money=2E 50% to me and 40% to you=2C while 10% should be for expenses or tax as your government may require=2E If you are interested to kindly forward immediately the following=3A 1=2E YOUR FULL NAME 2=2E CONTACT ADDRESS 3=2E PRIVATE TELEPHONE AND FAX NUMBER=2E I have all necessary legal documents that can be used to back up any claim we may make=2E All I require is your honest cooperation to enable us see this deal through=2E I guarantee that this will be executed under a legitimate arrangement that will protect you from any breach of the law=2E Please direct your reply through this Email Box immediately you receive this proposal for more explanation on the inheritance=2E Yours Faithfully=2C Barrister Edward Afamefuna =28Esq=2E=29=2E From carlos@baldric.uwo.ca Thu Sep 18 02:40:09 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Wed, 17 Sep 2003 21:40:09 -0400 Subject: [parisc-linux] 64-bit kernel builds with gcc-3.4 experimental cross. In-Reply-To: <20030918003807.GP21596@parcelfarce.linux.theplanet.co.uk> References: <20030917161800.GB30176@systemhalted> <200309171643.h8HGhJlw013649@hiauly1.hia.nrc.ca> <20030917225406.GG30176@systemhalted> <20030918003807.GP21596@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030918014008.GD11459@systemhalted> > > > > Separate compilers yes. Separate linker and assembler no. > > I thought I could use '--enable-targets=hppa64-linux' in binutils. > > I think that only works for some parts of binutils -- specifically not ld. > So it seems. Fiddle sticks. Two builds it is then :) c. From willy@debian.org Thu Sep 18 01:38:07 2003 From: willy@debian.org (Matthew Wilcox) Date: Thu, 18 Sep 2003 01:38:07 +0100 Subject: [parisc-linux] 64-bit kernel builds with gcc-3.4 experimental cross. In-Reply-To: <20030917225406.GG30176@systemhalted> References: <20030917161800.GB30176@systemhalted> <200309171643.h8HGhJlw013649@hiauly1.hia.nrc.ca> <20030917225406.GG30176@systemhalted> Message-ID: <20030918003807.GP21596@parcelfarce.linux.theplanet.co.uk> On Wed, Sep 17, 2003 at 06:54:07PM -0400, Carlos O'Donell wrote: > On Wed, Sep 17, 2003 at 12:43:18PM -0400, John David Anglin wrote: > > > hppa64-linux-ld: Relocatable linking with relocations from format > > > elf32-hppa-linux (sched.o) to format elf32-hppa-linux (kernel.o) is not > > > supported > > > > As far as I know, there is no multi-arch support in ld or as. > > There isn't multi-arch support in GCC either. You need separate > > compilers for 32 and 64 bits. > > Separate compilers yes. Separate linker and assembler no. > I thought I could use '--enable-targets=hppa64-linux' in binutils. I think that only works for some parts of binutils -- specifically not ld. -- "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 Jacek Chmielewski Thu Sep 18 10:16:17 2003 From: Jacek Chmielewski (Jacek Chmielewski) Date: Thu, 18 Sep 2003 11:16:17 +0200 Subject: [parisc-linux] debian installation problem - ERROR: Read from boot device failed Message-ID: <42687877064.20030918111617@kti.ae.poznan.pl> I want to install Debian on my HP 9000 J200 box and I encountered a problem with booting the installation procedure: Selected kernel: /vmlinux32 from partition 0 Selected ramdisk: /ramdiski from partition 0 ELF32 executable Entry 00100098 first 00100000 n 6 Segment 0 load 00100000 size 2196688 mediaptr 0x1000 Segment 1 load 0031a000 size 467792 mediaptr 0x21a000 Segment 2 load 00390000 size 255656 mediaptr 0x28d000 Segment 3 load 003d0000 size 8192 mediaptr 0x2cc000 Segment 4 load 003d8000 size 32768 mediaptr 0x2ce000 Segment 5 load 00402048 size 110832 mediaptr 0x2d6048 ERROR: Read from boot device failed (status = -13). byteio_read: seekread() returned -1 expected 2195456 ERROR: segment 0 read() failed Fatal error loading kernel executableERROR: failed to load kernel I tried the Debian binary-1 CD and netinstall CD. Both with almost same results ('status = -7' for Debian CD, and 'status = -13' for netinstall CD). What could be wrong? Do you know any possible source of this problem? Best regards Jacek Chmielewski From t.riemer@visoel.de Thu Sep 18 10:31:57 2003 From: t.riemer@visoel.de (Tilo Riemer) Date: Thu, 18 Sep 2003 11:31:57 +0200 Subject: [parisc-linux] update of libc? Message-ID: <20030918113157.000037fb.t.riemer@visoel.de> Hello, is it dangerous to make an update of libc from 2.2.5 to 2.3.x? At the moment I have only remote access to the affected host. Best regards, Tilo From jbglaw@lug-owl.de Thu Sep 18 10:38:50 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Thu, 18 Sep 2003 11:38:50 +0200 Subject: [parisc-linux] update of libc? In-Reply-To: <20030918113157.000037fb.t.riemer@visoel.de> References: <20030918113157.000037fb.t.riemer@visoel.de> Message-ID: <20030918093850.GB12661@lug-owl.de> --Wcqk1U9YY/kgSQtH Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2003-09-18 11:31:57 +0200, Tilo Riemer wrote in message <20030918113157.000037fb.t.riemer@visoel.de>: > is it dangerous to make an update of libc from 2.2.5 to 2.3.x? > At the moment I have only remote access to the affected host. I've just dist-upgrade'd all my machines. Libc still works (including a B132L+ and a 712), but you should be aware of module-init-tools if you're already using 2.6.x. # touch /etc/modprobe.d/arch/generic=20 =2E..helps you over a bug in the .deb ... 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) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --Wcqk1U9YY/kgSQtH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/aX0pHb1edYOZ4bsRAgGuAJ9nXWuut0ycIDo0yUlLAonENj4dxwCfWAyn MAd+O0ylRvHjvnGkg4ReNrU= =7T0X -----END PGP SIGNATURE----- --Wcqk1U9YY/kgSQtH-- From aol@01019freenet.de Thu Sep 18 20:01:32 2003 From: aol@01019freenet.de (aol@01019freenet.de) Date: Thu, 18 Sep 03 19:01:32 GMT Subject: [parisc-linux] Be bigger than average! - wm ecvjdr oxtriedlke Message-ID: This is a multi-part message in MIME format. --FFA.D.09EA..69E0 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable



patch --FFA.D.09EA..69E0-- From jesse@cypress-tech.com Thu Sep 18 13:48:05 2003 From: jesse@cypress-tech.com (Jesse Dougherty) Date: Thu, 18 Sep 2003 08:48:05 -0400 Subject: [parisc-linux] Opportunity: Anyone got any 4GB SCSI drives Message-ID: <3F69A985.F0A4EBFB@cypress-tech.com> Opportunity: Anyone got any 4GB SCSI drives I am searching for some 4GB disk drives commonly found in the HP B132L, B160L, & B180L workstation. The part number is ST34572N 4GB SCSI 50 pin drives. They could be found in other types of workstations, I only know the HP stuff. I need to buy about 100 of these things. If you have any surplus or extra drives that you might want to sell, please feel free to call or email as I need to purchase these ASAP. Thanks Jesse Doughery Cypress Technology Inc 727-557-0911 jesse@cypress-tech.com From CASSEY_BOOT@yahoo.ca Thu Sep 18 16:52:16 2003 From: CASSEY_BOOT@yahoo.ca (alice) Date: Thu, 18 Sep 2003 11:52:16 -0400 Subject: [parisc-linux] Hi Message-ID: <20030918155247.99D054843@dsl2.external.hp.com> PGh0bWw+DQpIaSw8YnI+DQpJIGtuPCEtLWR5YXVrZnMtLT5vdyB5b3Ugd2FudCB0byByZTwhLS0x MjMxcmZzc2EtLT5maW5hPCEtLW44dWY0OTRqOC0tPm5jZSB5b3VyIGhvbWUgc28gPGJyPg0KaGVy ZSBpcyB0aGUgd2U8IS0taGY4MWw5My0tPmJzaXRlIHlvdSB3YTwhLS1sYXM0aGQ3LS0+bnRlZCB3 aGVyZSBsZTwhLS1tZWxpc3NhLS0+bmRlcnMgPGJyPg0KY29tPCEtLWltcGVyaWFsLS0+cGV0ZSBm b3IgeW91ciBidTwhLS1lbWlseS0tPnNpbmVzcy48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmR5 YXVrZnMuZmxpcHBpbmRlYWxzLmNvbSI+IEdvIEhlcmUgPC9hPjxicj4NClRoPCEtLTEyMzFyZnNz YS0tPmFua3MsPGJyPg0KSmFjayBKb2g8IS0taGY4MWw5My0tPm5zb248YnI+DQo8YnI+DQo8YnI+ DQpObyA8IXJhbmQ0PiBNb3JlIDxhIGhyZWY9Imh0dHA6Ly9keWF1a2ZzLmZsaXBwaW5kZWFscy5j b20vdW5zLmNnaSI+IG5vIG1hcyA8YS8+DQo8IS0tZW1pbHktLT4NCjwvaHRtbD4NCg== From carlos@baldric.uwo.ca Thu Sep 18 17:02:49 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Thu, 18 Sep 2003 12:02:49 -0400 Subject: [parisc-linux] update of libc? In-Reply-To: <20030918113157.000037fb.t.riemer@visoel.de> References: <20030918113157.000037fb.t.riemer@visoel.de> Message-ID: <20030918160249.GC30890@systemhalted> On Thu, Sep 18, 2003 at 11:31:57AM +0200, Tilo Riemer wrote: > Hello, > > is it dangerous to make an update of libc from 2.2.5 to 2.3.x? > At the moment I have only remote access to the affected host. There is no 2.3.x glibc available for debian, it's currently being fixed. I apologize for the delay, it's more difficult than usual. c. From grundler@parisc-linux.org Thu Sep 18 17:39:37 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Thu, 18 Sep 2003 10:39:37 -0600 Subject: [parisc-linux] debian installation problem - ERROR: Read from boot device failed In-Reply-To: <42687877064.20030918111617@kti.ae.poznan.pl> References: <42687877064.20030918111617@kti.ae.poznan.pl> Message-ID: <20030918163937.GB26681@dsl2.external.hp.com> On Thu, Sep 18, 2003 at 11:16:17AM +0200, Jacek Chmielewski wrote: > I want to install Debian on my HP 9000 J200 box and I encountered a problem > with booting the installation procedure: > > Selected kernel: /vmlinux32 from partition 0 > Selected ramdisk: /ramdiski from partition 0 > ELF32 executable > Entry 00100098 first 00100000 n 6 > Segment 0 load 00100000 size 2196688 mediaptr 0x1000 > Segment 1 load 0031a000 size 467792 mediaptr 0x21a000 > Segment 2 load 00390000 size 255656 mediaptr 0x28d000 > Segment 3 load 003d0000 size 8192 mediaptr 0x2cc000 > Segment 4 load 003d8000 size 32768 mediaptr 0x2ce000 > Segment 5 load 00402048 size 110832 mediaptr 0x2d6048 > > ERROR: Read from boot device failed (status = -13). if palo is reporting -13 as the IODC return code, that means: -13 Protocol error A protocol violation was encountered on the module-device connection while transferring data to or from the device. CONDITIONAL. Must be used if the implementation can detect a protocol error. This would suggest some device is misconfigured. > byteio_read: seekread() returned -1 expected 2195456 > ERROR: segment 0 read() failed > Fatal error loading kernel executableERROR: failed to load kernel > > I tried the Debian binary-1 CD and netinstall CD. Both with almost same > results ('status = -7' for Debian CD, and 'status = -13' for netinstall > CD). -7 Nonexistent device The device address specified by ID_addr is a valid device address. However, it points to either a device that is not installed or a device that does not respond. Returned only by options ARG1=0 through ARG1=4. CONDITIONAL. Must be used if nonexistent devices can be identified. IIRC, io_ars.pdf describes these errors...I found them in a different document. > What could be wrong? Do you know any possible source of this problem? Misconfigured or flakey device. If you can setup a DHCP server and boot the netinstall lifimage over the LAN, that might work better. grant From jbglaw@lug-owl.de Thu Sep 18 18:31:33 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Thu, 18 Sep 2003 19:31:33 +0200 Subject: [parisc-linux] update of libc? In-Reply-To: <20030918160249.GC30890@systemhalted> References: <20030918113157.000037fb.t.riemer@visoel.de> <20030918160249.GC30890@systemhalted> Message-ID: <20030918173133.GG12661@lug-owl.de> --K4TeRK2lnUi9hBXL Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2003-09-18 12:02:49 -0400, Carlos O'Donell wrote in message <20030918160249.GC30890@systemhalted>: > On Thu, Sep 18, 2003 at 11:31:57AM +0200, Tilo Riemer wrote: > > is it dangerous to make an update of libc from 2.2.5 to 2.3.x? > > At the moment I have only remote access to the affected host. >=20 > There is no 2.3.x glibc available for debian, it's currently being > fixed. I apologize for the delay, it's more difficult than usual. No? b132l-1:~# dpkg -l libc6 Desired=3DUnknown/Install/Remove/Purge/Hold | Status=3DNot/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=3D(none)/Hold/Reinst-required/X=3Dboth-problems (Status,Err: upperc= ase=3Dbad) ||/ Name Version Description +++-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ii libc6 2.3.1-17.0.3 GNU C Library: Shared libraries and Timez= one For me, that one works and seems to be 2.3.x... However, what are current libc's problems? 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) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --K4TeRK2lnUi9hBXL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/aev0Hb1edYOZ4bsRAtT/AJ9jWSvyTBUH4e35BZ9j4w8LHgmuMACggsqi julCxZtF6NMSmL5pzouRzjA= =gBiK -----END PGP SIGNATURE----- --K4TeRK2lnUi9hBXL-- From carlos@baldric.uwo.ca Thu Sep 18 18:49:06 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Thu, 18 Sep 2003 13:49:06 -0400 Subject: [parisc-linux] update of libc? In-Reply-To: <20030918173133.GG12661@lug-owl.de> References: <20030918113157.000037fb.t.riemer@visoel.de> <20030918160249.GC30890@systemhalted> <20030918173133.GG12661@lug-owl.de> Message-ID: <20030918174906.GD30890@systemhalted> On Thu, Sep 18, 2003 at 07:31:33PM +0200, Jan-Benedict Glaw wrote: > On Thu, 2003-09-18 12:02:49 -0400, Carlos O'Donell > wrote in message <20030918160249.GC30890@systemhalted>: > > On Thu, Sep 18, 2003 at 11:31:57AM +0200, Tilo Riemer wrote: > > > is it dangerous to make an update of libc from 2.2.5 to 2.3.x? > > > At the moment I have only remote access to the affected host. > > > > There is no 2.3.x glibc available for debian, it's currently being > > fixed. I apologize for the delay, it's more difficult than usual. > > No? Sorry, 2.3.2, my brain isn't responding to the usual shock treatment. c. From ranjith_sudarsanan@hp.com Thu Sep 18 20:06:55 2003 From: ranjith_sudarsanan@hp.com (SUDARSANAN,RANJITH (HP-India,ex2)) Date: Fri, 19 Sep 2003 00:36:55 +0530 Subject: [parisc-linux] Problems with raw interface. 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. ------_=_NextPart_001_01C37E18.06CAF4E8 Content-Type: text/plain Hi I am developing a scsi disk exerciser and I am blocked on a strange problem with the raw interface. When I use the block device /dev/sda directly I am able to read and write from the disk properly. But when I use the raw interface I get garbage. For instance please look at the output below. I am reading the 1st sector of the disk, which is the boot sector, When I use the block device /dev/sda I get my expected output, whereas when I use the raw interface I get garbage. Can any one explain? The machine I am using is an L Class. I have attached the start up (boot up) screen dump at the end of the mail Kernel details: oak:~# uname -a Linux oak 2.4.22-pa3 #1 Thu Sep 18 23:19:58 IST 2003 parisc64 unknown oak:/home/sranjith# ls -l /dev/sda brw-rw---- 1 root disk 8, 0 Jun 7 2002 /dev/sda oak:/home/sranjith# ls -l /dev/sdb brw-rw---- 1 root disk 8, 16 Jun 7 2002 /dev/sdb oak:/home/sranjith# ls -l /dev/raw/ total 0 crw-r--r-- 1 root root 162, 4 Sep 12 00:32 raw4 crw-r--r-- 1 root root 162, 2 Aug 7 00:35 rawsda crw-r--r-- 1 root root 162, 1 Jul 31 19:33 rawsdb I am binding the raw devices to the block devices oak:/home/sranjith# raw /dev/raw/rawsdb /dev/sdb /dev/raw/raw1: bound to major 8, minor 16 oak:/home/sranjith# raw /dev/raw/rawsda /dev/sda /dev/raw/raw2: bound to major 8, minor 0 oak:/home/sranjith# raw -qa /dev/raw/raw1: bound to major 8, minor 16 /dev/raw/raw2: bound to major 8, minor 0 I am reading the 1st sector of /dev/sda from which I booted oak:/home/sranjith# dd if=/dev/sda of=o_sda bs=512 count=8 8+0 records in 8+0 records out oak:/home/sranjith# xxd o_sda |more 0000000: 8000 5041 4c4f 0003 0000 0000 0000 0000 ..PALO.......... 0000010: 0000 0000 0000 0000 322f 766d 6c69 6e75 ........2/vmlinu 0000020: 7820 726f 6f74 3d2f 6465 762f 7364 6133 x root=/dev/sda3 0000030: 2048 4f4d 453d 2f00 696e 6974 3d2f 6269 HOME=/.init=/bi 0000040: 6e2f 6261 7368 0037 3a2f 2069 703d 6468 n/bash.7:/ ip=dh 0000050: 6370 2048 4f4d 453d 2f00 0000 0000 0000 cp HOME=/....... 0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000e0: 0000 0000 0000 0000 0004 4000 0050 7fd9 ..........@..P.. 00000f0: 0000 4000 0000 7800 0000 0000 0000 0000 ..@...x......... 0000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ --More-- I am getting a valid output Now I use the raw interface to read the same sector and I get garbage oak:/home/sranjith# dd if=/dev/raw/rawsda of=o_sda bs=512 count=8 8+0 records in 8+0 records out oak:/home/sranjith# xxd o_sda |more 0000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ --More-- I get Garbage Boot up screen dump ************ EARLY BOOT VFP ************* End of early boot detected ***************************************** Firmware Version 41.46 Duplex Console IO Dependent Code (IODC) revision 1 ---------------------------------------------------------------------------- -- (c) Copyright 1995-2000, Hewlett-Packard Company, All rights reserved ---------------------------------------------------------------------------- -- Processor Speed State CoProcessor State Cache Size Number State Inst Data --------- -------- --------------------- ----------------- ------------ 0 750 MHz Active Functional 750 KB 1.5 MB 2 750 MHz Idle Functional 750 KB 1.5 MB Central Bus Speed (in MHz) : 133 Available Memory : 16777216 KB Good Memory Required : 86948 KB Primary boot path: 0/0/2/0.2 Alternate boot path: 0/0/1/1.2 Console path: 0/0/4/1.0 Keyboard path: 0/0/4/0.0 WARNING: The non-destructive test bit was set, so memory was not tested destructively. Information only, no action required. Processor is booting from first available device. To discontinue, press any key within 10 seconds. Proceeding... Trying Primary Boot Path ------------------------ Booting... Boot IO Dependent Code (IODC) revision 1 HARD Booted. palo ipl 1.0 root@palinux Mon Apr 1 10:02:53 MST 2002 Partition Start(MB) End(MB) Id Type 1 1 95 f0 Palo 2 96 286 83 ext2 3 287 5054 83 ext2 PALO(F0) partition contains: 0/vmlinux64 5275609 bytes @ 0x44000 Information: No console specified on kernel command line. This is normal. PALO will choose the console currently used by firmware (serial). Command line for kernel: 'root=/dev/sda3 HOME=/ console=ttyS0 TERM=vt102 palo_kernel=2/vmlinux' Selected kernel: /vmlinux from partition 2 ELF64 executable Entry 00100000 first 00100000 n 3 Segment 0 load 00100000 size 2872448 mediaptr 0x1000 Segment 1 load 003be000 size 1028616 mediaptr 0x2bf000 Segment 2 load 004bc000 size 376832 mediaptr 0x3bb000 Branching to kernel entry point 0x00100000. If this is the last message you see, you may need to switch your console. This is a common symptom -- search the FAQ and mailing list at parisc-linux.org ********** VIRTUAL FRONT PANEL ********** System Boot detected ***************************************** LEDs: RUN ATTENTION FAULT REMOTE POWER ON FLASH OFF ON ON LED State: There was a system interruption that did not take the system down. Check Chassis and Console Logs for error messages. processor system initialization 1C00 ***************************************** ************ EARLY BOOT VFP ************* End of early boot detected ***************************************** sym53c8xx: 53c875 detected sym53c8xx: at PCI bus 0, device 1, function 0 sym53c8xx: setting PCI_COMMAND_INVALIDATE (fix-up) sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 0, device 1, function 1 sym53c8xx: setting PCI_COMMAND_INVALIDATE (fix-up) sym53c8xx: 53c896 detected sym53c875-0: rev 0x14 on pci bus 0 device 2 function 0 irq 130 sym53c875-0: ID 7, Fast-20, Parity Checking sym53c875-1: rev 0x14 on pci bus 0 device 2 function 1 irq 131 sym53c875-1: ID 7, Fast-20, Parity Checking sym53c875-2: rev 0x14 on pci bus 64 device 0 function 0 irq 512 sym53c875-2: ID 7, Fast-20, Parity Checking sym53c875-3: rev 0x14 on pci bus 64 device 0 function 1 irq 513 sym53c875-3: ID 7, Fast-20, Parity Checking sym53c896-4: rev 0x7 on pci bus 0 device 1 function 0 irq 129 sym53c896-4: ID 7, Fast-20, Parity Checking sym53c896-4: handling phase mismatch from SCRIPTS. sym53c896-5: rev 0x7 on pci bus 0 device 1 function 1 irq 130 sym53c896-5: ID 7, Fast-20, Parity Checking sym53c896-5: handling phase mismatch from SCRIPTS. scsi0 : sym53c8xx-1.7.3c-20010512 scsi1 : sym53c8xx-1.7.3c-20010512 scsi2 : sym53c8xx-1.7.3c-20010512 scsi3 : sym53c8xx-1.7.3c-20010512 scsi4 : sym53c8xx-1.7.3c-20010512 scsi5 : sym53c8xx-1.7.3c-20010512 blk: queue 000000008f9a3428, I/O limit 4095Mb (mask 0xffffffff) Vendor: HP 36.4G Model: MAN3367MC Rev: HP04 Type: Direct-Access ANSI SCSI revision: 02 blk: queue 000000008f9a3628, I/O limit 4095Mb (mask 0xffffffff) Vendor: HP Model: DVD-ROM 305 Rev: 1.01 Type: CD-ROM ANSI SCSI revision: 02 blk: queue 000000008f9a3828, I/O limit 4095Mb (mask 0xffffffff) Vendor: HP 36.4G Model: MAN3367MC Rev: HP04 Type: Direct-Access ANSI SCSI revision: 02 blk: queue 000000008f9a3a28, I/O limit 4095Mb (mask 0xffffffff) Attached scsi disk sda at scsi0, channel 0, id 2, lun 0 Attached scsi disk sdb at scsi5, channel 0, id 2, lun 0 sym53c875-0-<2,*>: FAST-20 WIDE SCSI 40.0 MB/s (50.0 ns, offset 16) SCSI device sda: 71132960 512-byte hdwr sectors (36420 MB) sda: sda1 sda2 sda3 sym53c896-5-<2,*>: FAST-20 WIDE SCSI 40.0 MB/s (50.0 ns, offset 31) SCSI device sdb: 71132960 512-byte hdwr sectors (36420 MB) sdb: unknown partition table Attached scsi CD-ROM sr0 at scsi1, channel 0, id 2, lun 0 sym53c875-1-<2,*>: FAST-20 SCSI 20.0 MB/s (50.0 ns, offset 16) sr0: scsi3-mmc drive: 16x/40x cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.12 STI GSC/PCI graphics driver version 0.9 BUG: Skipping previously registered driver: sti (native) mice: PS/2 mouse device common for all mice HP SDC: No SDC found. HP SDC MLC: Registering the System Domain Controller's HIL MLC. HP SDC MLC: Request for raw HIL ISR hook denied md: linear personality registered as nr 1 md: raid0 personality registered as nr 2 md: raid1 personality registered as nr 3 md: raid5 personality registered as nr 4 raid5: measuring checksumming speed 8regs : 3434.400 MB/sec 8regs_prefetch: 2515.600 MB/sec 32regs : 2800.000 MB/sec 32regs_prefetch: 2640.000 MB/sec raid5: using function: 8regs (3434.400 MB/sec) md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 16384 buckets, 128Kbytes TCP: Hash tables configured (established 262144 bind 65536) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 316k freed ********** VIRTUAL FRONT PANEL ********** System Boot detected ***************************************** LEDs: RUN ATTENTION FAULT REMOTE POWER ON FLASH OFF ON ON LED State: There was a system interruption that did not take the system down. Check Chassis and Console Logs for error messages. processor system initialization 1C00 ***************************************** ************ EARLY BOOT VFP ************* End of early boot detected ***************************************** System Clock set. System local time is now Thu Sep 18 18:46:58 UTC 2003. Calculating module dependencies... depmod: Can't open /lib/modules/2.4.22-pa3/modules.dep for writing done. Loading modules: modprobe: Can't open dependencies file /lib/modules/2.4.22-pa3/modules.dep (No such file or directory) Checking all file systems... fsck 1.27 (8-Mar-2002) /dev/sda2: clean, 20/48960 files, 33836/195584 blocks Setting kernel variables. Mounting local filesystems... /dev/sda2 on /boot type ext2 (rw) Running 0dns-down to make sure resolv.conf is ok...done. Cleaning: /etc/network/ifstate. Setting up IP spoofing protection: rp_filter. Configuring network interfaces: done. Starting portmap daemon: portmap. Starting portmapper... Mounting remote filesystems... Setting the System Clock using the Hardware Clock as reference... System Clock set. Local time: Fri Sep 19 00:17:02 IST 2003 Cleaning: /tmp /var/lock eth0: Setting full-duplex based on MII#1 link partner capability of 41e1. /var/run. Initializing random number generator... done. Recovering nvi editor sessions... done. INIT: Entering runlevel: 2 Starting system log daemon: syslogd. Starting kernel log daemon: klogd. Starting NFS common utilities: statd. Starting internet superserver: inetd. Exporting directories for NFS kernel daemon...done. Starting NFS kernel daemon: nfsd mountd. Starting deferred execution scheduler: atd. Starting periodic command scheduler: cron. Debian GNU/Linux 3.0 oak ttyS0 oak login: with warm regards, Ranjith Sudarsanan -------------------------------------- Ranjith Sudarsanan Rage Team 30CA, Cunningham Road Bangalore -------------------------------------- "When the head bows, it meets the heart and that head which has met the heart gets the crown!!! - Sri Sri" ------_=_NextPart_001_01C37E18.06CAF4E8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Problems with raw interface.

Hi
        I am developing a scsi disk exerciser and I am blocked = on a strange problem with the raw interface. When I use the block = device /dev/sda directly I am able to read and write from the disk = properly. But when I use the raw interface I get garbage. For instance = please look at the output below. I am reading the 1st sector of the = disk, which is the boot sector, When I use the block device /dev/sda I = get my expected output, whereas when I use the raw interface I get = garbage. Can any one explain? The machine I am using is an L Class. =

I have attached the start up (boot up) = screen dump at the end of the mail

Kernel details:
oak:~# uname -a
Linux oak 2.4.22-pa3 #1 Thu Sep 18 = 23:19:58 IST 2003 parisc64 unknown


oak:/home/sranjith# ls -l /dev/sda
brw-rw----    1 = root     disk       = 8,   0 Jun  7  2002 /dev/sda

oak:/home/sranjith# ls -l /dev/sdb
brw-rw----    1 = root     disk       = 8,  16 Jun  7  2002 /dev/sdb

oak:/home/sranjith# ls -l /dev/raw/   
total 0
crw-r--r--    1 = root     root     = 162,   4 Sep 12 00:32 raw4
crw-r--r--    1 = root     root     = 162,   2 Aug  7 00:35 rawsda
crw-r--r--    1 = root     root     = 162,   1 Jul 31 19:33 rawsdb

I am binding the = raw devices to the block devices

oak:/home/sranjith# raw /dev/raw/rawsdb /dev/sdb
/dev/raw/raw1:  bound to major = 8, minor 16
oak:/home/sranjith# raw = /dev/raw/rawsda /dev/sda
/dev/raw/raw2:  bound to major = 8, minor 0

oak:/home/sranjith# raw -qa
/dev/raw/raw1:  bound to major = 8, minor 16
/dev/raw/raw2:  bound to major = 8, minor 0

I am reading the = 1st sector of /dev/sda from which I booted

oak:/home/sranjith# dd if=3D/dev/sda of=3Do_sda bs=3D512 = count=3D8
8+0 records in
8+0 records out
oak:/home/sranjith# xxd o_sda |more
0000000: 8000 5041 4c4f 0003 0000 = 0000 0000 0000  ..PALO..........
0000010: 0000 0000 0000 0000 322f = 766d 6c69 6e75  ........2/vmlinu
0000020: 7820 726f 6f74 3d2f 6465 = 762f 7364 6133  x root=3D/dev/sda3
0000030: 2048 4f4d 453d 2f00 696e = 6974 3d2f 6269   HOME=3D/.init=3D/bi
0000040: 6e2f 6261 7368 0037 3a2f = 2069 703d 6468  n/bash.7:/ ip=3Ddh
0000050: 6370 2048 4f4d 453d 2f00 = 0000 0000 0000  cp HOME=3D/.......
0000060: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000070: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000080: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000090: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
00000a0: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
00000b0: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
00000c0: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
00000d0: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
00000e0: 0000 0000 0000 0000 0004 = 4000 0050 7fd9  ..........@..P..
00000f0: 0000 4000 0000 7800 0000 = 0000 0000 0000  ..@...x.........
0000100: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000110: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000120: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000130: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000140: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000150: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
--More--

I am getting a = valid output

Now I use the raw = interface to read the same sector and I get garbage

oak:/home/sranjith# dd if=3D/dev/raw/rawsda of=3Do_sda bs=3D512 = count=3D8
8+0 records in
8+0 records out
oak:/home/sranjith# xxd o_sda |more
0000000: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000010: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000020: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000030: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000040: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000050: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000060: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000070: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000080: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000090: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
00000a0: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
00000b0: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
00000c0: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
00000d0: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
00000e0: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
00000f0: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000100: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000110: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000120: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000130: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000140: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
0000150: 0000 0000 0000 0000 0000 = 0000 0000 0000  ................
--More--

I get = Garbage  



Boot up screen dump
************ EARLY BOOT VFP = *************
End of early boot detected
*****************************************

Firmware Version  41.46

Duplex Console IO Dependent Code = (IODC) revision 1

---------------------------------------------------------= ---------------------
   (c) Copyright 1995-2000, = Hewlett-Packard Company, All rights reserved
---------------------------------------------------------= ---------------------

  Processor   = Speed            = State           = CoProcessor State  Cache Size
  = Number           =             =             =     = State           &= nbsp;  Inst    Data
  ---------  = --------   ---------------------  = -----------------  ------------
      = 0      750  MHz   = Active           =       = Functional         750 KB 1.5 = MB
      = 2      750  MHz   = Idle           &n= bsp;       = Functional         750 KB 1.5 = MB

  Central Bus Speed (in = MHz)  :        133  =
  Available Memory  &nb= sp;         :   = 16777216  KB
  Good Memory = Required        = :      86948  KB

   Primary boot = path:    = 0/0/2/0.2           =
   Alternate boot = path:  = 0/0/1/1.2           =
   Console = path:         = 0/0/4/1.0           =
   Keyboard = path:        = 0/0/4/0.0           =

 WARNING:  The = non-destructive test bit was set, so memory was not tested
         &nb= sp;  destructively.  Information only, no action required. =


Processor is booting from first = available device.

To discontinue, press any key within = 10 seconds.
Proceeding...

Trying Primary Boot Path
------------------------
Booting...
Boot IO Dependent Code (IODC) = revision 1


HARD Booted.
palo ipl 1.0 root@palinux Mon = Apr  1 10:02:53 MST 2002

Partition Start(MB) End(MB) Id = Type
1         &n= bsp;     1      = 95   f0 Palo
2         &n= bsp;    96     286   83 = ext2
3         &n= bsp;   287    5054   83 ext2

PALO(F0) partition contains:
    0/vmlinux64 = 5275609 bytes @ 0x44000

Information: No console specified on = kernel command line. This is normal.
PALO will choose the console = currently used by firmware (serial).
Command line for kernel: = 'root=3D/dev/sda3 HOME=3D/ console=3DttyS0 TERM=3Dvt102 = palo_kernel=3D2/vmlinux'
Selected kernel: /vmlinux from = partition 2
ELF64 executable
Entry 00100000 first 00100000 n = 3
Segment 0 load 00100000 size 2872448 = mediaptr 0x1000
Segment 1 load 003be000 size 1028616 = mediaptr 0x2bf000
Segment 2 load 004bc000 size 376832 = mediaptr 0x3bb000
Branching to kernel entry point = 0x00100000.  If this is the last
message you see, you may need to = switch your console.  This is
a common symptom -- search the FAQ = and mailing list at parisc-linux.org


********** VIRTUAL FRONT PANEL = **********
System Boot detected
*****************************************
LEDs:  = RUN      ATTENTION     = FAULT     REMOTE     = POWER
       = ON       = FLASH         = OFF       = ON         ON
LED State: There was a system = interruption that did not take the system down.
Check Chassis and Console Logs for = error messages.

processor        =          system = initialization      1C00

*****************************************

************ EARLY BOOT VFP = *************
End of early boot detected
*****************************************
sym53c8xx: 53c875 detected
sym53c8xx: at PCI bus 0, device 1, = function 0
sym53c8xx: setting = PCI_COMMAND_INVALIDATE (fix-up)
sym53c8xx: 53c896 detected
sym53c8xx: at PCI bus 0, device 1, = function 1
sym53c8xx: setting = PCI_COMMAND_INVALIDATE (fix-up)
sym53c8xx: 53c896 detected
sym53c875-0: rev 0x14 on pci bus 0 = device 2 function 0 irq 130
sym53c875-0: ID 7, Fast-20, Parity = Checking
sym53c875-1: rev 0x14 on pci bus 0 = device 2 function 1 irq 131
sym53c875-1: ID 7, Fast-20, Parity = Checking
sym53c875-2: rev 0x14 on pci bus 64 = device 0 function 0 irq 512
sym53c875-2: ID 7, Fast-20, Parity = Checking
sym53c875-3: rev 0x14 on pci bus 64 = device 0 function 1 irq 513
sym53c875-3: ID 7, Fast-20, Parity = Checking
sym53c896-4: rev 0x7 on pci bus 0 = device 1 function 0 irq 129
sym53c896-4: ID 7, Fast-20, Parity = Checking
sym53c896-4: handling phase mismatch = from SCRIPTS.
sym53c896-5: rev 0x7 on pci bus 0 = device 1 function 1 irq 130
sym53c896-5: ID 7, Fast-20, Parity = Checking
sym53c896-5: handling phase mismatch = from SCRIPTS.
scsi0 : = sym53c8xx-1.7.3c-20010512
scsi1 : = sym53c8xx-1.7.3c-20010512
scsi2 : = sym53c8xx-1.7.3c-20010512
scsi3 : = sym53c8xx-1.7.3c-20010512
scsi4 : = sym53c8xx-1.7.3c-20010512
scsi5 : = sym53c8xx-1.7.3c-20010512
blk: queue 000000008f9a3428, I/O = limit 4095Mb (mask 0xffffffff)
  Vendor: HP 36.4G  Model: = MAN3367MC         Rev: = HP04
  Type:   = Direct-Access          = ;            = ANSI SCSI revision: 02
blk: queue 000000008f9a3628, I/O = limit 4095Mb (mask 0xffffffff)
  Vendor: HP   &nb= sp;    Model: DVD-ROM = 305       Rev: 1.01
  Type:   = CD-ROM           =             =       ANSI SCSI revision: 02
blk: queue 000000008f9a3828, I/O = limit 4095Mb (mask 0xffffffff)
  Vendor: HP 36.4G  Model: = MAN3367MC         Rev: = HP04
  Type:   = Direct-Access          = ;            = ANSI SCSI revision: 02
blk: queue 000000008f9a3a28, I/O = limit 4095Mb (mask 0xffffffff)
Attached scsi disk sda at scsi0, = channel 0, id 2, lun 0
Attached scsi disk sdb at scsi5, = channel 0, id 2, lun 0
sym53c875-0-<2,*>: FAST-20 WIDE = SCSI 40.0 MB/s (50.0 ns, offset 16)
SCSI device sda: 71132960 512-byte = hdwr sectors (36420 MB)
 sda: sda1 sda2 sda3
sym53c896-5-<2,*>: FAST-20 WIDE = SCSI 40.0 MB/s (50.0 ns, offset 31)
SCSI device sdb: 71132960 512-byte = hdwr sectors (36420 MB)
 sdb: unknown partition = table
Attached scsi CD-ROM sr0 at scsi1, = channel 0, id 2, lun 0
sym53c875-1-<2,*>: FAST-20 SCSI = 20.0 MB/s (50.0 ns, offset 16)
sr0: scsi3-mmc drive: 16x/40x cd/rw = xa/form2 cdda tray
Uniform CD-ROM driver Revision: = 3.12
STI GSC/PCI graphics driver version = 0.9
BUG: Skipping previously registered = driver: sti (native)
mice: PS/2 mouse device common for = all mice
HP SDC: No SDC found.
HP SDC MLC: Registering the System = Domain Controller's HIL MLC.
HP SDC MLC: Request for raw HIL ISR = hook denied
md: linear personality registered as = nr 1
md: raid0 personality registered as = nr 2
md: raid1 personality registered as = nr 3
md: raid5 personality registered as = nr 4
raid5: measuring checksumming = speed
   = 8regs     :  3434.400 MB/sec
   8regs_prefetch:  = 2515.600 MB/sec
   32regs    = :  2800.000 MB/sec
   32regs_prefetch:  = 2640.000 MB/sec
raid5: using function: 8regs = (3434.400 MB/sec)
md: md driver 0.90.0 = MAX_MD_DEVS=3D256, MD_SB_DISKS=3D27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for = NET4.0
IP Protocols: ICMP, UDP, TCP, = IGMP
IP: routing cache hash table of 16384 = buckets, 128Kbytes
TCP: Hash tables configured = (established 262144 bind 65536)
NET4: Unix domain sockets 1.0/SMP for = Linux NET4.0.
VFS: Mounted root (ext2 filesystem) = readonly.
Freeing unused kernel memory: 316k = freed
********** VIRTUAL FRONT PANEL = **********
System Boot detected
*****************************************
LEDs:  = RUN      ATTENTION     = FAULT     REMOTE     = POWER
       = ON       = FLASH         = OFF       = ON         ON
LED State: There was a system = interruption that did not take the system down.
Check Chassis and Console Logs for = error messages.

processor        =          system = initialization      1C00

*****************************************

************ EARLY BOOT VFP = *************
End of early boot detected
*****************************************
System Clock set. System local time = is now Thu Sep 18 18:46:58 UTC 2003.
Calculating module dependencies... = depmod: Can't open /lib/modules/2.4.22-pa3/modules.dep for = writing
done.
Loading modules:
modprobe: Can't open dependencies = file /lib/modules/2.4.22-pa3/modules.dep (No such file or = directory)
Checking all file systems...
fsck 1.27 (8-Mar-2002)
/dev/sda2: clean, 20/48960 files, = 33836/195584 blocks
Setting kernel variables.
Mounting local filesystems...
/dev/sda2 on /boot type ext2 = (rw)
Running 0dns-down to make sure = resolv.conf is ok...done.
Cleaning: = /etc/network/ifstate.
Setting up IP spoofing protection: = rp_filter.
Configuring network interfaces: = done.
Starting portmap daemon: = portmap.
Starting portmapper... Mounting = remote filesystems...

Setting the System Clock using the = Hardware Clock as reference...
System Clock set. Local time: Fri Sep = 19 00:17:02 IST 2003

Cleaning: /tmp /var/lock eth0: Setting = full-duplex based on MII#1 link partner capability of 41e1.
/var/run.
Initializing random number = generator... done.
Recovering nvi editor sessions... = done.
INIT: Entering runlevel: 2
Starting system log daemon: = syslogd.
Starting kernel log daemon: = klogd.
Starting NFS common utilities: = statd.
Starting internet superserver: = inetd.
Exporting directories for NFS kernel = daemon...done.
Starting NFS kernel daemon: nfsd = mountd.
Starting deferred execution = scheduler: atd.
Starting periodic command scheduler: = cron.

Debian GNU/Linux 3.0 oak ttyS0

oak login:

with warm regards,
Ranjith Sudarsanan

--------------------------------------
Ranjith Sudarsanan
Rage Team
30CA, Cunningham Road
Bangalore
--------------------------------------
"When the head bows, it meets the heart and that = head which has = met the heart gets the = crown!!! - Sri Sri"

------_=_NextPart_001_01C37E18.06CAF4E8-- From willy@debian.org Thu Sep 18 21:35:10 2003 From: willy@debian.org (Matthew Wilcox) Date: Thu, 18 Sep 2003 21:35:10 +0100 Subject: [parisc-linux] sched_clock implementation Message-ID: <20030918203510.GD21596@parcelfarce.linux.theplanet.co.uk> Anyone want to do better than the lame implementation? ;-) ----- Forwarded message from Andrew Morton ----- I'll be merging Ingo & Con's CPOU scheduler changes into Linus's tree soon. It does require that the architecture provides a new timing function: A lame implementation is: /* * Returns nanoseconds */ unsigned long long sched_clock(void) { return (unsigned long long)jiffies * (1000000000 / HZ); } But for best CPU scheduler results the architecture should try to return a higher-resolution number than this of course. sched_clock() has no absolute time requirements: it just has to return some number which goes up by 1,000,000,000 times per second. I already have implementations for x86, ppc, sparc64 and ia64. I have a completely stupid ppc64 implementation which is only accurate on 1GHz CPUs. Anton please note! As for the rest, it'll break the build, sorry. ----- End forwarded message ----- -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From grundler@parisc-linux.org Fri Sep 19 00:00:05 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Thu, 18 Sep 2003 17:00:05 -0600 Subject: [parisc-linux] Problems with raw interface. In-Reply-To: References: Message-ID: <20030918230005.GA2315@dsl2.external.hp.com> On Fri, Sep 19, 2003 at 12:36:55AM +0530, SUDARSANAN,RANJITH (HP-India,ex2) wrote: ... > oak:/home/sranjith# raw /dev/raw/rawsdb /dev/sdb > /dev/raw/raw1: bound to major 8, minor 16 > oak:/home/sranjith# raw /dev/raw/rawsda /dev/sda > /dev/raw/raw2: bound to major 8, minor 0 > > oak:/home/sranjith# raw -qa > /dev/raw/raw1: bound to major 8, minor 16 > /dev/raw/raw2: bound to major 8, minor 0 I get the impression "raw" is ignoring your input parameter to use /dev/raw/rawsdb and is using /dev/raw/raw instead. So it looks like you are comparing the wrong data... root@debian:/dev# raw --help raw: invalid option -- - Usage: raw /dev/raw/rawN raw /dev/raw/rawN /dev/ raw -q /dev/raw/rawN raw -qa What does "dd if=/dev/raw/raw2 of=/tmp/o_raw2 bs=512 count=8" result in? Anyway, it looks broken for me too. I tried using raw on 32-bit 2.4.20-pa28: raw /dev/raw/raw1 /dev/sda raw -qa /dev/raw/raw1: bound to major 8, minor 0 dd if=/dev/raw/raw1 of=/tmp/raw1.o count=8 /usr/bin/od -Ax -t x /tmp/raw1.o 000000 00000000 00000000 00000000 00000000 * 001000 /dev/sda is the boot disk for this machine. root@debian:/dev# /usr/bin/od -Ax -t x /dev/sda | less 000000 00000000 00000000 00000000 00000000 * 000400 40030800 60653403 00000000 0a086200 000410 cd700200 00000000 02000000 02000000 000420 00800000 00800000 40010000 371e6a3f 000430 371e6a3f 10001800 53ef0100 01000000 .... grant From James.Bottomley@steeleye.com Fri Sep 19 02:06:32 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 18 Sep 2003 20:06:32 -0500 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.6 jejb In-Reply-To: <20030919010356.148684940A4@palinux.hppa> References: <20030919010356.148684940A4@palinux.hppa> Message-ID: <1063933596.2083.9.camel@mulgrave> On Thu, 2003-09-18 at 20:03, James Bottomley wrote: > CVSROOT: /var/cvs > Module name: linux-2.6 > Changes by: jejb 03/09/18 19:03:56 > > Modified files: > . : Makefile > arch/parisc/kernel: module.c signal.c > include/asm-parisc: elf.h > > Log message: > Clean up signal handling code: > > - remove the less than helpful comments (and replace them with > meaningful ones > - get rid of the HACK macros > - Unify the PLABEL function descriptor handling with modules.c ===== arch/parisc/kernel/module.c 1.8 vs edited ===== --- 1.8/arch/parisc/kernel/module.c Wed Sep 10 00:44:18 2003 +++ edited/arch/parisc/kernel/module.c Thu Sep 18 16:01:11 2003 @@ -73,10 +73,7 @@ Elf32_Addr addr; }; -struct fdesc_entry { - Elf32_Addr addr; - Elf32_Addr gp; -}; +#define Elf_Fdesc Elf32_Fdesc struct stub_entry { Elf32_Word insns[2]; /* each stub entry has two insns */ @@ -86,11 +83,7 @@ Elf64_Addr addr; }; -struct fdesc_entry { - Elf64_Addr dummy[2]; - Elf64_Addr addr; - Elf64_Addr gp; -}; +#define Elf_Fdesc Elf64_Fdesc struct stub_entry { Elf64_Word insns[4]; /* each stub entry has four insns */ @@ -276,7 +269,7 @@ me->core_size = ALIGN(me->core_size, 16); me->arch.fdesc_offset = me->core_size; - me->core_size += fdescs * sizeof(struct fdesc_entry); + me->core_size += fdescs * sizeof(Elf_Fdesc); me->core_size = ALIGN(me->core_size, 16); me->arch.stub_offset = me->core_size; @@ -322,7 +315,7 @@ #ifdef __LP64__ static Elf_Addr get_fdesc(struct module *me, unsigned long value) { - struct fdesc_entry *fdesc = me->module_core + me->arch.fdesc_offset; + Elf_Fdesc *fdesc = me->module_core + me->arch.fdesc_offset; if (!value) { printk(KERN_ERR "%s: zero OPD requested!\n", me->name); @@ -664,7 +657,7 @@ *loc64 = get_fdesc(me, val+addend); DEBUGP("FDESC for %s at %p points to %lx\n", strtab + sym->st_name, *loc64, - ((struct fdesc_entry *)*loc64)->addr); + ((Elf_Fdesc *)*loc64)->addr); } else { /* if the symbol is not local to this * module then val+addend is a pointer @@ -696,10 +689,10 @@ Elf_Sym *newptr, *oldptr; Elf_Shdr *symhdr = NULL; #ifdef DEBUG - struct fdesc_entry *entry; + Elf_Fdesc *entry; u32 *addr; - entry = (struct fdesc_entry *)me->init; + entry = (Elf_Fdesc *)me->init; printk("FINALIZE, ->init FPTR is %p, GP %lx ADDR %lx\n", entry, entry->gp, entry->addr); addr = (u32 *)entry->addr; ===== arch/parisc/kernel/signal.c 1.13 vs edited ===== --- 1.13/arch/parisc/kernel/signal.c Wed Sep 10 00:44:19 2003 +++ edited/arch/parisc/kernel/signal.c Thu Sep 18 17:49:36 2003 @@ -25,6 +25,7 @@ #include #include #include +#include #include #include #include @@ -41,8 +42,11 @@ #define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP))) -/* Use this to get at 32-bit user passed pointers. - * See sys_sparc32.c for description about these. */ +/* gcc will complain if a pointer is cast to an integer of different + * size. If you really need to do this (and we do for an ELF32 user + * application in an ELF64 kernel) then you have to do a cast to an + * integer of the same size first. The A() macro accomplishes + * this. */ #define A(__x) ((unsigned long)(__x)) int do_signal(sigset_t *oldset, struct pt_regs *regs, int in_syscall); @@ -271,7 +275,8 @@ sigset_t *set, struct pt_regs *regs, int in_syscall) { struct rt_sigframe *frame; - unsigned long rp, usp, haddr; + unsigned long rp, usp; + Elf32_Addr haddr; struct siginfo si; int err = 0; @@ -308,64 +313,50 @@ } #endif -#undef CACHE_FLUSHING_IS_NOT_BROKEN -#ifdef CACHE_FLUSHING_IS_NOT_BROKEN + flush_user_dcache_range((unsigned long) &frame->tramp[0], + (unsigned long) &frame->tramp[4]); flush_user_icache_range((unsigned long) &frame->tramp[0], (unsigned long) &frame->tramp[4]); -#else - /* It should *always* be cache line-aligned, but the compiler - sometimes screws up. */ - asm volatile("fdc 0(%%sr3,%0)\n\t" - "fdc %1(%%sr3,%0)\n\t" - "sync\n\t" - "fic 0(%%sr3,%0)\n\t" - "fic %1(%%sr3,%0)\n\t" - "sync\n\t" - : : "r" (frame->tramp), "r" (L1_CACHE_BYTES)); -#endif rp = (unsigned long) frame->tramp; if (err) goto give_sigsegv; -/* Much more has to happen with signals than this -- but it'll at least */ -/* provide a pointer to some places which definitely need a look. */ -#define HACK u32 - - haddr = (HACK)A(ka->sa.sa_handler); - /* ARGH! Fucking brain damage. You don't want to know. */ - if (haddr & 2) { - HACK *plabel; - HACK ltp; - - plabel = (HACK *) (haddr & ~3); - err |= __get_user(haddr, plabel); - err |= __get_user(ltp, plabel + 1); + haddr = A(ka->sa.sa_handler); + /* The sa_handler may be a pointer to a function descriptor */ + if (haddr & PA_PLABEL_FDESC) { + Elf32_Fdesc fdesc; + Elf32_Fdesc *ufdesc = (Elf32_Fdesc *)A(haddr & ~3); + + err = __copy_from_user(&fdesc, ufdesc, sizeof(fdesc)); + if (err) goto give_sigsegv; - regs->gr[19] = ltp; + + haddr = fdesc.addr; + regs->gr[19] = fdesc.gp; } /* The syscall return path will create IAOQ values from r31. */ if (in_syscall) - regs->gr[31] = (HACK) haddr; + regs->gr[31] = haddr; else { regs->gr[0] = USER_PSW; - regs->iaoq[0] = (HACK) haddr | 3; + regs->iaoq[0] = haddr | 3; regs->iaoq[1] = regs->iaoq[0] + 4; } regs->gr[2] = rp; /* userland return pointer */ regs->gr[26] = sig; /* signal number */ - regs->gr[25] = (HACK)A(&frame->info); /* siginfo pointer */ - regs->gr[24] = (HACK)A(&frame->uc); /* ucontext pointer */ + regs->gr[25] = A(&frame->info); /* siginfo pointer */ + regs->gr[24] = A(&frame->uc); /* ucontext pointer */ DBG(("making sigreturn frame: %#lx + %#x = %#lx\n", regs->gr[30], PARISC_RT_SIGFRAME_SIZE, regs->gr[30] + PARISC_RT_SIGFRAME_SIZE)); /* Raise the user stack pointer to make a proper call frame. */ - regs->gr[30] = ((HACK)A(frame) + PARISC_RT_SIGFRAME_SIZE); + regs->gr[30] = (A(frame) + PARISC_RT_SIGFRAME_SIZE); DBG(("SIG deliver (%s:%d): frame=0x%p sp=%#lx iaoq=%#lx/%#lx rp=%#lx\n", current->comm, current->pid, frame, regs->gr[30], ===== include/asm-parisc/elf.h 1.8 vs edited ===== --- 1.8/include/asm-parisc/elf.h Wed Sep 10 00:44:23 2003 +++ edited/include/asm-parisc/elf.h Thu Sep 18 16:07:25 2003 @@ -144,6 +144,30 @@ #define R_PARISC_LTOFF_TP16DF 231 /* 16 bits LT-TP-rel. address. */ #define R_PARISC_HIRESERVE 255 +#define PA_PLABEL_FDESC 0x02 /* bit set if PLABEL points to + * a function descriptor, not + * an address */ + +/* The following are PA function descriptors + * + * addr: the absolute address of the function + * gp: either the data pointer (r27) for non-PIC code or the + * the PLT pointer (r19) for PIC code */ + +/* Format for the Elf32 Function descriptor */ +typedef struct elf32_fdesc { + __u32 addr; + __u32 gp; +} Elf32_Fdesc; + +/* Format for the Elf64 Function descriptor */ +typedef struct elf64_fdesc { + __u64 dummy[2]; /* FIXME: nothing uses these, why waste + * the space */ + __u64 addr; + __u64 gp; +} Elf64_Fdesc; + /* Legal values for p_type field of Elf32_Phdr/Elf64_Phdr. */ #define PT_HP_TLS (PT_LOOS + 0x0) From t.riemer@visoel.de Fri Sep 19 07:40:42 2003 From: t.riemer@visoel.de (Tilo Riemer) Date: Fri, 19 Sep 2003 08:40:42 +0200 Subject: [parisc-linux] update of libc? In-Reply-To: <20030918093850.GB12661@lug-owl.de> References: <20030918113157.000037fb.t.riemer@visoel.de> <20030918093850.GB12661@lug-owl.de> Message-ID: <20030919084042.0000769d.t.riemer@visoel.de> Hello, thanks for all hints. I could update to libc 2.3 without problems. All seems to work... Best regards, Tilo From Randolph Chung Fri Sep 19 12:24:45 2003 From: Randolph Chung (Randolph Chung) Date: Fri, 19 Sep 2003 04:24:45 -0700 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.6 jejb In-Reply-To: <1063933596.2083.9.camel@mulgrave> References: <20030919010356.148684940A4@palinux.hppa> <1063933596.2083.9.camel@mulgrave> Message-ID: <20030919112445.GL27523@tausq.org> > -#undef CACHE_FLUSHING_IS_NOT_BROKEN > -#ifdef CACHE_FLUSHING_IS_NOT_BROKEN > + flush_user_dcache_range((unsigned long) &frame->tramp[0], > + (unsigned long) &frame->tramp[4]); > flush_user_icache_range((unsigned long) &frame->tramp[0], > (unsigned long) &frame->tramp[4]); we also have a flush_icache_user_range range macro that does this (flush dcache + icache). The kernel seems to use both..... randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From ranjith_sudarsanan@hp.com Fri Sep 19 13:37:41 2003 From: ranjith_sudarsanan@hp.com (SUDARSANAN,RANJITH (HP-India,ex2)) Date: Fri, 19 Sep 2003 18:07:41 +0530 Subject: [parisc-linux] Problems with raw interface. Message-ID: Hi, Grant: >>>I get the impression "raw" is ignoring your input parameter >>>to use /dev/raw/rawsdb and is using /dev/raw/raw instead. >>>So it looks like you are comparing the wrong data... Ranjith: When I bind an block interface to a raw device, I see that /dev/raw/raw, is the minor number of the node entry which is created in the /dev/raw/ directory. I tried binding to /dev/raw/raw1 instead of /dev/raw/rawsda. I still get the same results. (If the binding is not present raw complains) This problem does not seem to be there on the X86 and IA64 kernels. I guess this is something specific to PA Linux kernel. I am compiling the kernel with debugs enabled. Please let me know if anyone gets a lead on this. Grant: >>>>What does "dd if=/dev/raw/raw2 of=/tmp/o_raw2 bs=512 count=8" result in? Ranjith: This command reads the first 4K bytes of the disk and writes it to file o_raw2. with warm regards, Ranjith Sudarsanan -------------------------------------- Ranjith Sudarsanan Rage Team 30CA, Cunningham Road Bangalore Off: 91-80-205 3190 Res: 91-80-522 2577 web: http://nt2651.india.hp.com:8080/ -------------------------------------- "When the head bows, it meets the heart and that head which has met the heart gets the crown!!! - Sri Sri" -----Original Message----- From: Grant Grundler [mailto:grundler@parisc-linux.org] Sent: Friday, September 19, 2003 4:30 AM To: SUDARSANAN,RANJITH (HP-India,ex2) Cc: parisc-linux@lists.parisc-linux.org Subject: Re: [parisc-linux] Problems with raw interface. On Fri, Sep 19, 2003 at 12:36:55AM +0530, SUDARSANAN,RANJITH (HP-India,ex2) wrote: ... > oak:/home/sranjith# raw /dev/raw/rawsdb /dev/sdb > /dev/raw/raw1: bound to major 8, minor 16 oak:/home/sranjith# raw > /dev/raw/rawsda /dev/sda > /dev/raw/raw2: bound to major 8, minor 0 > > oak:/home/sranjith# raw -qa > /dev/raw/raw1: bound to major 8, minor 16 > /dev/raw/raw2: bound to major 8, minor 0 I get the impression "raw" is ignoring your input parameter to use /dev/raw/rawsdb and is using /dev/raw/raw instead. So it looks like you are comparing the wrong data... root@debian:/dev# raw --help raw: invalid option -- - Usage: raw /dev/raw/rawN raw /dev/raw/rawN /dev/ raw -q /dev/raw/rawN raw -qa What does "dd if=/dev/raw/raw2 of=/tmp/o_raw2 bs=512 count=8" result in? Anyway, it looks broken for me too. I tried using raw on 32-bit 2.4.20-pa28: raw /dev/raw/raw1 /dev/sda raw -qa /dev/raw/raw1: bound to major 8, minor 0 dd if=/dev/raw/raw1 of=/tmp/raw1.o count=8 /usr/bin/od -Ax -t x /tmp/raw1.o 000000 00000000 00000000 00000000 00000000 * 001000 /dev/sda is the boot disk for this machine. root@debian:/dev# /usr/bin/od -Ax -t x /dev/sda | less 000000 00000000 00000000 00000000 00000000 * 000400 40030800 60653403 00000000 0a086200 000410 cd700200 00000000 02000000 02000000 000420 00800000 00800000 40010000 371e6a3f 000430 371e6a3f 10001800 53ef0100 01000000 .... grant From carlos@baldric.uwo.ca Fri Sep 19 14:56:07 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Fri, 19 Sep 2003 09:56:07 -0400 Subject: [parisc-linux] r19 (aka pic-register akak ltp) not restored on entry back to libc from libpthread? Message-ID: <20030919135606.GE18225@systemhalted> jda, Perhaps you can help here with my problem, again it's an r19 related issue. make[2]: *** [/glibc-cvs/build-hppa/posix/tst-regex.out] Error 139 Breakpoint 1, fixup (l=0xfaf00d68, reloc_offset=1248) at dl-runtime.c:72 72 alloca (sizeof (int)); (gdb) c 22 I exit the loader, and I have ~2700 insn before I get to here... (gdb) si 2713 I've traced it down to: 0000000040024000-000000004016d000 r-xp 0000000000000000 08:04 1308771 /mnt/flaire/src/glibc-cvs/build-hppa/libc.so Looks like "public_mALLOc" from libc/malloc/malloc.c trying to unlock the memory arena mutex. 00081ea0 <__libc_malloc>: 0x400a5f50: copy r4,r19 0x400a5f54: cmpib,= 0,ret0,0x400a5f8c ... r19 = 40181d50 (All is good, all is quiet for 2700 insn) (gdb) x/4 0x40181d50-0x1800+0x400 0x40180950: 0x400a6234 0x40181d50 0x40094320 0x40181d50 (Stub) 0x400abf0c: b,l 0x400abf14,r1 0x400abf10: addil 9f000,r1,%r1 0x400abf14: be,n 71c(sr4,r1) (Load r19 and target address from PLABEL) 0x4014b630: bb,>=,n r22,1e,0x4014b640 0x4014b634: depwi 0,31,2,r22 0x4014b638: ldw 4(sr0,r22),r19 0x4014b63c: ldw 0(sr0,r22),r22 0x4014b640: bv r0(r22) 0x4014b644: stw rp,-18(sr0,sp) r19 = 401a57a8 (Good for libpthread ...) (gdb) x /4 0x401a57a8-0x1800+0x400 0x401a43a8: 0x00000008 0x0000b6ac 0x0000b6e8 0x08000000 ^^^^^^^^^^ Soon to be fatal return address. 000072e0 <__pthread_mutex_unlock>: 0x4018d2e0: stw rp,-14(sr0,sp) 0x4018d2e4: stw,ma r4,40(sr0,sp) 0x4018d2e8: stw r19,-20(sr0,sp) # 2719 ... 0000000040186000-0000000040195000 r-xp 0000000000000000 08:04 655453 /mnt/flaire/src/glibc-cvs/build-hppa/linuxthreads/libpthread.so 0x4019063c: stw r19,-20(sr0,sp) # 2742 ... 0x40190860: stw r19,-20(sr0,sp) ... 0x401908f8: bv r0(rp) # 2774 0x401908fc: ldo -80(sp),sp ... 0x40190770: bv r0(rp) 0x40190774: ldo -80(sp),sp ... 000072e0 <__pthread_mutex_unlock> 0x4018d334: bv r0(rp) # 2806 0x4018d338: ldw,mb -40(sr0,sp),r4 ... 00081ea0 <__libc_malloc> 0x400a5f84: b,l 0x400a5edc,r0 0x400a5f88: copy r5,ret0 ... Hold your horses here, we made it back into libc but our ltp is still that which we loaded upon entry to libpthread? :( 0x400a5eec: bv r0(rp) 0x400a5ef0: ldw,mb -40(sr0,sp),r6 ... 0x401028e4: cmpib,<> 0,r20,0x40102918 0x401028e8: copy r3,r25 ... 0x40102918: b,l 0x40116658,rp # 2839 0x4010291c: copy r6,r26 First use of libpthread's r19 is fatal. 0x40116658: addil -1800,r19,%r1 # 2840 0x4011665c: ldw 400(sr0,r1),r21 <--- *BOOM* r21=0x8 0x40116660: bv r0(r21) 0x40116664: ldw 404(sr0,r1),r19 Any thoughts? Did I miss something? Cheers, Carlos. From James.Bottomley@steeleye.com Fri Sep 19 15:02:52 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 19 Sep 2003 09:02:52 -0500 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.6 jejb In-Reply-To: <20030919112445.GL27523@tausq.org> References: <20030919010356.148684940A4@palinux.hppa> <1063933596.2083.9.camel@mulgrave> <20030919112445.GL27523@tausq.org> Message-ID: <1063980175.1929.7.camel@mulgrave> On Fri, 2003-09-19 at 06:24, Randolph Chung wrote: > we also have a flush_icache_user_range range macro that does this (flush > dcache + icache). The kernel seems to use both..... Well, I just took the least line of resistance. But it does beg the question: I think all of the PA arch docs require the dcache to be flushed before the icache for all icache flushing, so is there any point exporting an API that only flushes the icache? James From joel.soete@tiscali.be Fri Sep 19 16:32:41 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Fri, 19 Sep 2003 15:32:41 +0000 Subject: [parisc-linux] sched_clock implementation In-Reply-To: <20030918203510.GD21596@parcelfarce.linux.theplanet.co.uk> References: <20030918203510.GD21596@parcelfarce.linux.theplanet.co.uk> Message-ID: <3F6B2199.8050402@tiscali.be> Matthew Wilcox wrote: >Anyone want to do better than the lame implementation? ;-) > >----- Forwarded message from Andrew Morton ----- > >I'll be merging Ingo & Con's CPOU scheduler changes into Linus's tree soon. > >It does require that the architecture provides a new timing function: > >A lame implementation is: > >/* > * Returns nanoseconds > */ > > Hi Willy, (Certainly yet another stupid question but) to reach such accuracy we would need to have access to some 'time device' with an accuracy better then the nanosec (iirc 10^-9) (because it doesn't seems to me possible to get enough accuracy with cpu clock < 10^9 ie 1Ghz: the most case for parisc systems). Does it exist such device and where to start to read some doc? Tanks, Joel >unsigned long long sched_clock(void) >{ > return (unsigned long long)jiffies * (1000000000 / HZ); >} > >But for best CPU scheduler results the architecture should try to return a >higher-resolution number than this of course. > >sched_clock() has no absolute time requirements: it just has to return some >number which goes up by 1,000,000,000 times per second. > >I already have implementations for x86, ppc, sparc64 and ia64. > >I have a completely stupid ppc64 implementation which is only accurate on >1GHz CPUs. Anton please note! > >As for the rest, it'll break the build, sorry. > >----- End forwarded message ----- > > > From carlos@baldric.uwo.ca Fri Sep 19 17:00:35 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Fri, 19 Sep 2003 12:00:35 -0400 Subject: [parisc-linux] sched_clock implementation In-Reply-To: <3F6B2199.8050402@tiscali.be> References: <20030918203510.GD21596@parcelfarce.linux.theplanet.co.uk> <3F6B2199.8050402@tiscali.be> Message-ID: <20030919160035.GG18225@systemhalted> On Fri, Sep 19, 2003 at 03:32:41PM +0000, Joel Soete wrote: > Matthew Wilcox wrote: > > >Anyone want to do better than the lame implementation? ;-) > > > >----- Forwarded message from Andrew Morton ----- > > > >I'll be merging Ingo & Con's CPOU scheduler changes into Linus's tree soon. > > > >It does require that the architecture provides a new timing function: > > > >A lame implementation is: > > > >/* > >* Returns nanoseconds > >*/ > > > > > Hi Willy, > > (Certainly yet another stupid question but) to reach such accuracy we > would need to have access to some 'time device' with an accuracy better > then the nanosec (iirc 10^-9) (because it doesn't seems to me possible > to get enough accuracy with cpu clock < 10^9 ie 1Ghz: the most case for > parisc systems). Does it exist such device and where to start to read > some doc? We could use cr16 to get better accuracy. See list discussions about fast gettimeofday. c. From joel.soete@tiscali.be Fri Sep 19 17:11:00 2003 From: joel.soete@tiscali.be (Joel Soete) Date: Fri, 19 Sep 2003 16:11:00 +0000 Subject: [parisc-linux] sched_clock implementation In-Reply-To: <20030919160035.GG18225@systemhalted> References: <20030918203510.GD21596@parcelfarce.linux.theplanet.co.uk> <3F6B2199.8050402@tiscali.be> <20030919160035.GG18225@systemhalted> Message-ID: <3F6B2A94.8010906@tiscali.be> Carlos O'Donell wrote: >On Fri, Sep 19, 2003 at 03:32:41PM +0000, Joel Soete wrote: > > >>Matthew Wilcox wrote: >> >> >> >>>Anyone want to do better than the lame implementation? ;-) >>> >>>----- Forwarded message from Andrew Morton ----- >>> >>>I'll be merging Ingo & Con's CPOU scheduler changes into Linus's tree soon. >>> >>>It does require that the architecture provides a new timing function: >>> >>>A lame implementation is: >>> >>>/* >>>* Returns nanoseconds >>>*/ >>> >>> >>> >>> >>Hi Willy, >> >>(Certainly yet another stupid question but) to reach such accuracy we >>would need to have access to some 'time device' with an accuracy better >>then the nanosec (iirc 10^-9) (because it doesn't seems to me possible >>to get enough accuracy with cpu clock < 10^9 ie 1Ghz: the most case for >>parisc systems). Does it exist such device and where to start to read >>some doc? >> >> > >We could use cr16 to get better accuracy. See list discussions about >fast gettimeofday. > > ha ok I will have a look :) Thanks a lot, Joel From sct@redhat.com Fri Sep 19 17:34:04 2003 From: sct@redhat.com (Stephen C. Tweedie) Date: 19 Sep 2003 17:34:04 +0100 Subject: [Fwd: [parisc-linux] Problems with raw interface.] In-Reply-To: <1063919293.16536.2.camel@dhcp23.swansea.linux.org.uk> References: <1063919293.16536.2.camel@dhcp23.swansea.linux.org.uk> Message-ID: <1063989244.2834.48.camel@sisko.scot.redhat.com> Hi, On Thu, 2003-09-18 at 22:08, Alan Cox wrote: > Might interest you since this is possibly showing raw has cache > coherency issues with HPPA (which is basically software coherency only) > -----Forwarded Message----- > > From: "SUDARSANAN,RANJITH (HP-India,ex2)" > > To: parisc-linux@lists.parisc-linux.org > > Subject: [parisc-linux] Problems with raw interface. > > Date: Fri, 19 Sep 2003 00:36:55 +0530 > > I am developing a scsi disk exerciser and I am blocked on a > > strange problem with the raw interface. When I use the block device > > /dev/sda directly I am able to read and write from the disk properly. > > But when I use the raw interface I get garbage. For instance please > > look at the output below. I am reading the 1st sector of the disk, > > which is the boot sector, When I use the block device /dev/sda I get > > my expected output, whereas when I use the raw interface I get > > garbage. Can any one explain? The machine I am using is an L Class. Do you _ever_ get valid output, or is raw always failing? There may well be a cache coherency point being missed. The key places are rw_raw_dev(), where we set up the virtual address to physical page mappings, and brw_kiovec(), where the actual physical page IO is done. --Stephen From dave@hiauly1.hia.nrc.ca Fri Sep 19 17:56:46 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Fri, 19 Sep 2003 12:56:46 -0400 (EDT) Subject: [parisc-linux] r19 (aka pic-register akak ltp) not restored on entry back to libc from libpthread? In-Reply-To: <20030919135606.GE18225@systemhalted> from "Carlos O'Donell" at Sep 19, 2003 09:56:07 am Message-ID: <200309191656.h8JGukWJ003212@hiauly1.hia.nrc.ca> > Hold your horses here, we made it back into libc but our ltp is still > that which we loaded upon entry to libpthread? :( That's ok. It's the responsibility of the libc code to restore ltp after a call or exception. However, as discussed previously, there is no restoration after a syscall. That should be the system's job, although I believe you were going to introduce a hack/workaround to fix the syscalls that clobber r19. You need to step through the libc code from the return point in libc to see why ltp isn't being restored. Possibly, libpthread is being called by assembly code that doesn't restore ltp. Normally, r19 is restored quite soon after a call. 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 Fri Sep 19 18:51:42 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Fri, 19 Sep 2003 13:51:42 -0400 Subject: [parisc-linux] r19 (aka pic-register akak ltp) not restored on entry back to libc from libpthread? In-Reply-To: <200309191656.h8JGukWJ003212@hiauly1.hia.nrc.ca> References: <20030919135606.GE18225@systemhalted> <200309191656.h8JGukWJ003212@hiauly1.hia.nrc.ca> Message-ID: <20030919175142.GI18225@systemhalted> On Fri, Sep 19, 2003 at 12:56:46PM -0400, John David Anglin wrote: > > Hold your horses here, we made it back into libc but our ltp is still > > that which we loaded upon entry to libpthread? :( > > That's ok. It's the responsibility of the libc code to restore ltp > after a call or exception. However, as discussed previously, there > is no restoration after a syscall. That should be the system's job, > although I believe you were going to introduce a hack/workaround to > fix the syscalls that clobber r19. For all syscalls whose wrappers are pure assembly or __asm(...) I have placed restorations to follow ABI. This fixed all of the major failures. It's a bit drastic, but it fixes the issue until I know exactly which syscall numbers clobber r19. It looks like just fork and it's variants that stick a return address into PT_REGS's r19. That's a side issue about optimization though. > You need to step through the libc code from the return point in > libc to see why ltp isn't being restored. Possibly, libpthread is > being called by assembly code that doesn't restore ltp. Normally, > r19 is restored quite soon after a call. There should be no assembly code glue between the calls. What about the gcc optimization where we don't restore r19 if it's not used between the last call and the return? mutex_unlock becomes: __libc_maybe_call (__pthread_mutex_unlock, (m), (*(int *)(m) = 0)) Which is a big monstrosity that looks like it might be casting things incorrectly for hppa... === #if defined _LIBC && defined IS_IN_libpthread # define __libc_maybe_call(FUNC, ARGS, ELSE) FUNC ARGS #else # if defined __PIC__ || (defined _LIBC && defined SHARED) # define __libc_maybe_call(FUNC, ARGS, ELSE) \ (__extension__ ({ __typeof (FUNC) *_fn = (FUNC); \ _fn != NULL ? (*_fn) ARGS : ELSE; })) # else # define __libc_maybe_call(FUNC, ARGS, ELSE) \ (FUNC != NULL ? FUNC ARGS : ELSE) # endif #endif #if defined _LIBC && !defined NOT_IN_libc && defined SHARED # define __libc_maybe_call2(FUNC, ARGS, ELSE) \ ({__builtin_expect (__libc_pthread_functions.ptr_##FUNC != NULL, 0) \ ? __libc_pthread_functions.ptr_##FUNC ARGS : ELSE; }) #else # define __libc_maybe_call2(FUNC, ARGS, ELSE) __libc_maybe_call # (__##FUNC, ARGS, ELSE) #endif === I have class, then I'll be back to -E some of the malloc build to see what this evaluates to and then try to determine if gcc did the right thing. c. From jim.hull@hp.com Fri Sep 19 19:24:50 2003 From: jim.hull@hp.com (Jim Hull) Date: Fri, 19 Sep 2003 11:24:50 -0700 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.6 jejb In-Reply-To: <1063980175.1929.7.camel@mulgrave> Message-ID: <00e301c37edb$50a11f20$f463f40f@jh733133> James Bottomley wrote: > But it does beg the question: I think all of the PA arch docs require > the dcache to be flushed before the icache for all icache flushing, so > is there any point exporting an API that only flushes the icache? Not true. If you know that the line can't be in the d-cache, then flushing the i-cache is sufficient (and vice-versa). See "Data Cache Move-In", "Instruction Cache Move-In", and "Cache Flushing" in Appendix F of "PA-RISC 2.0 Architecture" (aka, "The Kane Book"), for details. Now, whether pa-linux keeps track of whether a line could be in only the d- or i-cache, with sufficient accuracy to avoid the other flush, I have no idea. HP-UX does attempt to track this, but doing so in every case can be really tricky, and tracking down the data (or instruction) corruption bugs when you miss some obscure case is a nightmare (and I have the scars to prove it :). -- Jim HP PA-RISC/Itanium Processor Architect From James.Bottomley@steeleye.com Fri Sep 19 19:26:44 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 19 Sep 2003 13:26:44 -0500 Subject: [parisc-linux] r19 (aka pic-register akak ltp) not restored on entry back to libc from libpthread? In-Reply-To: <20030919175142.GI18225@systemhalted> References: <20030919135606.GE18225@systemhalted> <200309191656.h8JGukWJ003212@hiauly1.hia.nrc.ca> <20030919175142.GI18225@systemhalted> Message-ID: <1063996009.1832.34.camel@mulgrave> On Fri, 2003-09-19 at 12:51, Carlos O'Donell wrote: > mutex_unlock becomes: > __libc_maybe_call (__pthread_mutex_unlock, (m), (*(int *)(m) = 0)) This seems all to work: A test file main() { int t1 = 4; __libc_maybe_call(test1, (t1), (t1=3)); } compiles (PIC) to: 00000000
: [...] 20: 2a 60 00 00 addil 0,r19,%r1 20: R_PARISC_DLTIND21L .LC0 24: 48 21 00 00 ldw 0(r1),r1 24: R_PARISC_DLTIND14R .LC0 28: 0c 20 10 94 ldw 0(,r1),r20 2c: 0c 74 12 98 stw r20,c(,r3) 30: 0c 78 10 94 ldw c(,r3),r20 34: 86 80 20 3a cmpib,=,n 0,r20,58 38: 0c 78 10 94 ldw c(,r3),r20 3c: 0c 70 10 9a ldw 8(,r3),r26 40: 08 14 02 56 copy r20,r22 44: 08 13 02 44 copy r19,r4 48: eb e0 00 00 b,l 50 ,r31 48: R_PARISC_PCREL17F $$dyncall 4c: 08 1f 02 42 copy r31,rp 50: 08 04 02 53 copy r4,r19 [...] 00000000 <.LC0>: 0: 00 00 00 00 break 0,0 0: R_PARISC_PLABEL32 test1 [...] 00010578 <$$dyncall>: 10578: c7 d6 c0 12 bb,>=,n r22,1e,10588 <$$dyncall+0x10> 1057c: d6 c0 1c 1e depwi 0,31,2,r22 10580: 0e c8 10 93 ldw 4(,r22),r19 10584: 0e c0 10 96 ldw 0(,r22),r22 10588: ea c0 c0 00 bv r0(r22) 1058c: 6b c2 3f d1 stw rp,-18(sp) The $$dyncall is where we indirect through r20 (which contains the function pointer). Note the copy restoring r19 around this. James From dave@hiauly1.hia.nrc.ca Fri Sep 19 19:55:30 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Fri, 19 Sep 2003 14:55:30 -0400 (EDT) Subject: [parisc-linux] r19 (aka pic-register akak ltp) not restored on In-Reply-To: <1063996009.1832.34.camel@mulgrave> from "James Bottomley" at Sep 19, 2003 01:26:44 pm Message-ID: <200309191855.h8JItUaf003758@hiauly1.hia.nrc.ca> > On Fri, 2003-09-19 at 12:51, Carlos O'Donell wrote: > > mutex_unlock becomes: > > __libc_maybe_call (__pthread_mutex_unlock, (m), (*(int *)(m) = 0)) > > This seems all to work: Yah, the normal code that gcc generates to restore the ltp is very extensively tested. Shared libraries would break almost instantly if there were major problems. 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 Fri Sep 19 20:28:13 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Fri, 19 Sep 2003 15:28:13 -0400 Subject: [parisc-linux] r19 (aka pic-register akak ltp) not restored on In-Reply-To: <200309191855.h8JItUaf003758@hiauly1.hia.nrc.ca> References: <1063996009.1832.34.camel@mulgrave> <200309191855.h8JItUaf003758@hiauly1.hia.nrc.ca> Message-ID: <20030919192813.GL18225@systemhalted> On Fri, Sep 19, 2003 at 02:55:30PM -0400, John David Anglin wrote: > > On Fri, 2003-09-19 at 12:51, Carlos O'Donell wrote: > > > mutex_unlock becomes: > > > __libc_maybe_call (__pthread_mutex_unlock, (m), (*(int *)(m) = 0)) > > > > This seems all to work: > > Yah, the normal code that gcc generates to restore the ltp is very > extensively tested. Shared libraries would break almost instantly > if there were major problems. > If it were major we would have fixed it :) I'm trying to find the "missed a restore" point. c. From dave@hiauly1.hia.nrc.ca Fri Sep 19 21:10:47 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Fri, 19 Sep 2003 16:10:47 -0400 (EDT) Subject: [parisc-linux] r19 (aka pic-register akak ltp) not restored on In-Reply-To: <20030919192813.GL18225@systemhalted> from "Carlos O'Donell" at Sep 19, 2003 03:28:13 pm Message-ID: <200309192010.h8JKAlHs004032@hiauly1.hia.nrc.ca> > If it were major we would have fixed it :) > I'm trying to find the "missed a restore" point. 0x4019063c: stw r19,-20(sr0,sp) # 2742 Just a note, GCC saves r19 in the frame marker in the prologue of non-leaf functions but we never attempt to restore r19 from the frame marker. This is the mandated ABI behavior. At the moment, GCC copies r19 to r4 for the save. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From inkubus@interalpha.co.uk Sat Sep 20 16:34:05 2003 From: inkubus@interalpha.co.uk (Martin) Date: 20 Sep 2003 16:34:05 +0100 Subject: [parisc-linux] OT:Problems with hardware - RDI Precision Book Message-ID: <1064072046.1602.62.camel@raphael> Sorry, I know this is OT but I have a feeling if I'm going to find anyone who can help it may well be here. Bought an RDI precision book a while back and was just about to put Linux on it. Pressed the power button and the 'power', 'network' and 'disk' icons light up on the LCD panel but nothing else happens. Have tried with other disks, network cable, external monitor and external scsi and it still does nothing. Does anyone have any suggestions? I really need a working laptop and am getting more than a little frustrated... Cheers, - Martin -- Martin inkubus@interalpha.co.uk "Seasons change, things come to pass" From soete.joel@tiscali.be Sat Sep 20 19:02:10 2003 From: soete.joel@tiscali.be (Joel Soete) Date: Sat, 20 Sep 2003 18:02:10 +0000 Subject: [parisc-linux] sched_clock implementation In-Reply-To: <20030919160035.GG18225@systemhalted> References: <20030918203510.GD21596@parcelfarce.linux.theplanet.co.uk> <3F6B2199.8050402@tiscali.be> <20030919160035.GG18225@systemhalted> Message-ID: <3F6C9622.60402@tiscali.be> Carlos O'Donell wrote: >On Fri, Sep 19, 2003 at 03:32:41PM +0000, Joel Soete wrote: > > >>Matthew Wilcox wrote: >> >> >> >>>Anyone want to do better than the lame implementation? ;-) >>> >>>----- Forwarded message from Andrew Morton ----- >>> >>>I'll be merging Ingo & Con's CPOU scheduler changes into Linus's tree soon. >>> >>>It does require that the architecture provides a new timing function: >>> >>>A lame implementation is: >>> >>>/* >>>* Returns nanoseconds >>>*/ >>> >>> >>> >>> >>Hi Willy, >> >>(Certainly yet another stupid question but) to reach such accuracy we >>would need to have access to some 'time device' with an accuracy better >>then the nanosec (iirc 10^-9) (because it doesn't seems to me possible >>to get enough accuracy with cpu clock < 10^9 ie 1Ghz: the most case for >>parisc systems). Does it exist such device and where to start to read >>some doc? >> >> > >We could use cr16 to get better accuracy. See list discussions about >fast gettimeofday. > >c. > Hi all, a quick look into paxx.pdf which about CR16 speak of "peak instruction rate" but do not define anywhere? I presume that is the cpu clock but would like somebody confirm. Thanks in advance, Joel From grundler@parisc-linux.org Sun Sep 21 00:46:05 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Sat, 20 Sep 2003 17:46:05 -0600 Subject: [parisc-linux] Problems with raw interface. In-Reply-To: References: Message-ID: <20030920234605.GB31268@dsl2.external.hp.com> On Fri, Sep 19, 2003 at 06:07:41PM +0530, SUDARSANAN,RANJITH (HP-India,ex2) wrote: > >>>>What does "dd if=/dev/raw/raw2 of=/tmp/o_raw2 bs=512 count=8" result in? > This command reads the first 4K bytes of the disk and writes it to file > o_raw2. Ah yes, but is the data correct? I'll assume not since your attempt with /dev/raw/raw1 also failed. Basically something looks broken in parisc for raw devices. I was clearly able to reproduce this failure. grant From grundler@parisc-linux.org Sun Sep 21 01:04:47 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Sat, 20 Sep 2003 18:04:47 -0600 Subject: [parisc-linux] sched_clock implementation In-Reply-To: <3F6C9622.60402@tiscali.be> References: <20030918203510.GD21596@parcelfarce.linux.theplanet.co.uk> <3F6B2199.8050402@tiscali.be> <20030919160035.GG18225@systemhalted> <3F6C9622.60402@tiscali.be> Message-ID: <20030921000447.GC31268@dsl2.external.hp.com> On Sat, Sep 20, 2003 at 06:02:10PM +0000, Joel Soete wrote: > a quick look into paxx.pdf which about CR16 speak of "peak instruction > rate" but do not define anywhere? > I presume that is the cpu clock but would like somebody confirm. Read about "Interval Timer" (cr16) in the PA 2.0 Arch book. PDC provides the exact rate that CR16 is changing. Looks like PDC_TOD_ITIMER is the call but I'm not sure offhand. In any case, I've only seen it used as CPU cycle counter. (ie 1:1 with CPU clock). hth, grant From grundler@parisc-linux.org Sun Sep 21 01:27:33 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Sat, 20 Sep 2003 18:27:33 -0600 Subject: [Fwd: [parisc-linux] Problems with raw interface.] In-Reply-To: <1063989244.2834.48.camel@sisko.scot.redhat.com> References: <1063919293.16536.2.camel@dhcp23.swansea.linux.org.uk> <1063989244.2834.48.camel@sisko.scot.redhat.com> Message-ID: <20030921002733.GE31268@dsl2.external.hp.com> On Fri, Sep 19, 2003 at 05:34:04PM +0100, Stephen C. Tweedie wrote: > > > But when I use the raw interface I get garbage. For instance please > > > look at the output below. I am reading the 1st sector of the disk, > > > which is the boot sector, When I use the block device /dev/sda I get > > > my expected output, whereas when I use the raw interface I get > > > garbage. Can any one explain? The machine I am using is an L Class. > > Do you _ever_ get valid output, or is raw always failing? There may > well be a cache coherency point being missed. I was able to consistently reproduce this problem on a c3000 (400Mhz PA8500). That's running 2.4.22 kernel. > The key places are rw_raw_dev(), where we set up the virtual address to > physical page mappings, and brw_kiovec(), where the actual physical page > IO is done. ok - I should try again with 2.6 kernel and look again. But I'm certainly no vm/cache expert. grant From grundler@parisc-linux.org Sun Sep 21 06:35:55 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Sat, 20 Sep 2003 23:35:55 -0600 Subject: [Fwd: [parisc-linux] Problems with raw interface.] In-Reply-To: <1063989244.2834.48.camel@sisko.scot.redhat.com> References: <1063919293.16536.2.camel@dhcp23.swansea.linux.org.uk> <1063989244.2834.48.camel@sisko.scot.redhat.com> Message-ID: <20030921053555.GA5312@dsl2.external.hp.com> On Fri, Sep 19, 2003 at 05:34:04PM +0100, Stephen C. Tweedie wrote: > Do you _ever_ get valid output, or is raw always failing? > There may well be a cache coherency point being missed. 2.6.0-test5 (-pa9) produced incorrect output 3 for 3. But it's NOT identical for all three runs. I think you are correct. BTW, kernel and user space will alias to different cachelines for the same 32-bit "offset" because of "Space Registers" (form of segmented addressing). I grabbed 128k data off the beginning of the disk. Reading 8 blocks from raw1 was only showing all zeros. I'll guess 2.4.22 has same bug since beginning out "output" was also all zero's. Getting longer runs from 2.4.22 would be useful...something for tomorrow or monday. I used: ion:/tmp# dd if=/dev/sda of=/tmp/sda.block1 count=512 and ion:/tmp# dd if=/dev/raw/raw1 of=/tmp/sda.raw1 count=512 grundler@ion:/tmp$ cksum * 1803524181 262144 sda.block1 1803524181 262144 sda.block2 1803524181 262144 sda.block3 3975907619 262144 sda.raw1 3975907619 262144 sda.raw2 2757932476 262144 sda.raw3 / is on /dev/sdh Output files are on ftp://gsyprf10.external.hp.com/pub/raw-pa9/ I just added 2MB files (2MB since 1.5MB dcache) which show more of the same. od -Ax -tx /tmp/sda.raw3 | less 000000 00000000 00000000 00000000 00000000 * 02b290 30000000 70000000 00000000 00000500 02b2a0 56000000 18000100 2d000000 00000100 02b2b0 fa040f98 0127c101 082c1698 0127c101 02b2c0 00000000 00000000 00000000 00000000 * 02b490 30000000 70000000 00000000 00000500 02b4a0 56000000 18000100 2d000000 00000100 02b4b0 fa040f98 0127c101 082c1698 0127c101 02b4c0 00000000 00000000 00000000 00000000 * ... I think sda contains random data from a previous life in a test environment. ion:/tmp# od -Ax -tx /tmp/sda.block1 | less 000000 33c08ed0 bc007cfb 5007501f fcbe1b7c 000010 bf1b0650 57b9e501 f3a4cbbd be07b104 000020 386e007c 09751383 c510e2f4 cd188bf5 000030 83c61049 7419382c 74f6a0b5 07b4078b 000040 f0ac3c00 74fcbb07 00b40ecd 10ebf288 000050 4e10e846 00732afe 4610807e 040b740b 000060 807e040c 7405a0b6 0775d280 46020683 ... > The key places are rw_raw_dev(), where we set up the virtual address to > physical page mappings, and brw_kiovec(), where the actual physical page > IO is done. I can look, but willy or jejb have much better chance of finding something... cheers, grant From deller@gmx.de Sun Sep 21 12:20:36 2003 From: deller@gmx.de (Helge Deller) Date: Sun, 21 Sep 2003 13:20:36 +0200 Subject: [parisc-linux] sched_clock implementation In-Reply-To: <20030921000447.GC31268@dsl2.external.hp.com> References: <20030918203510.GD21596@parcelfarce.linux.theplanet.co.uk> <3F6C9622.60402@tiscali.be> <20030921000447.GC31268@dsl2.external.hp.com> Message-ID: <200309211320.36485.deller@gmx.de> On Sunday 21 September 2003 02:04, Grant Grundler wrote: > On Sat, Sep 20, 2003 at 06:02:10PM +0000, Joel Soete wrote: > > a quick look into paxx.pdf which about CR16 speak of "peak instruction > > rate" but do not define anywhere? > > I presume that is the cpu clock but would like somebody confirm. > > Read about "Interval Timer" (cr16) in the PA 2.0 Arch book. > PDC provides the exact rate that CR16 is changing. > Looks like PDC_TOD_ITIMER is the call but I'm not sure offhand. > In any case, I've only seen it used as CPU cycle counter. > (ie 1:1 with CPU clock). Hi Joel, I think we have the rate in the variable "boot_cpu_data.cpu_hz" (see arch/parisc/kernel/processor.c) already. Helge From willy@debian.org Sun Sep 21 15:25:04 2003 From: willy@debian.org (Matthew Wilcox) Date: Sun, 21 Sep 2003 15:25:04 +0100 Subject: [Fwd: [parisc-linux] Problems with raw interface.] In-Reply-To: <20030921053555.GA5312@dsl2.external.hp.com> References: <1063919293.16536.2.camel@dhcp23.swansea.linux.org.uk> <1063989244.2834.48.camel@sisko.scot.redhat.com> <20030921053555.GA5312@dsl2.external.hp.com> Message-ID: <20030921142504.GD13172@parcelfarce.linux.theplanet.co.uk> On Sat, Sep 20, 2003 at 11:35:55PM -0600, Grant Grundler wrote: > BTW, kernel and user space will alias to different cachelines > for the same 32-bit "offset" because of "Space Registers" > (form of segmented addressing). Rubbish, they alias to the same cachelines because of the 4MB get-out clause. What you may have meant is that the same page accessed through user and kernel mappings will alias to different cachelines because their addresses *aren't* congruent modulo 4MB. > > The key places are rw_raw_dev(), where we set up the virtual address to > > physical page mappings, and brw_kiovec(), where the actual physical page > > IO is done. > > I can look, but willy or jejb have much better chance of finding > something... Those functions don't seem to exist in 2.6. The only reference is: ./Documentation/block/biodoc.txt: of data, so brw_kiovec() invokes ll_rw_kio for each kiobuf in a kiovec. which seems to be an orphaned comment. I'll reluctantly take a look at 2.4. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From carlos@baldric.uwo.ca Sun Sep 21 15:24:58 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Sun, 21 Sep 2003 10:24:58 -0400 Subject: [parisc-linux] sched_clock implementation In-Reply-To: <200309211320.36485.deller@gmx.de> References: <20030918203510.GD21596@parcelfarce.linux.theplanet.co.uk> <3F6C9622.60402@tiscali.be> <20030921000447.GC31268@dsl2.external.hp.com> <200309211320.36485.deller@gmx.de> Message-ID: <20030921142458.GE6963@systemhalted> On Sun, Sep 21, 2003 at 01:20:36PM +0200, Helge Deller wrote: > On Sunday 21 September 2003 02:04, Grant Grundler wrote: > > On Sat, Sep 20, 2003 at 06:02:10PM +0000, Joel Soete wrote: > > > a quick look into paxx.pdf which about CR16 speak of "peak instruction > > > rate" but do not define anywhere? > > > I presume that is the cpu clock but would like somebody confirm. > > > > Read about "Interval Timer" (cr16) in the PA 2.0 Arch book. > > PDC provides the exact rate that CR16 is changing. > > Looks like PDC_TOD_ITIMER is the call but I'm not sure offhand. > > In any case, I've only seen it used as CPU cycle counter. > > (ie 1:1 with CPU clock). > > Hi Joel, > > I think we have the rate in the variable "boot_cpu_data.cpu_hz" (see > arch/parisc/kernel/processor.c) already. Technically that's our highest precision timer :) c. From carlos@baldric.uwo.ca Sun Sep 21 16:45:01 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Sun, 21 Sep 2003 11:45:01 -0400 Subject: [parisc-linux] Found the r19 problem! In-Reply-To: <200309192010.h8JKAlHs004032@hiauly1.hia.nrc.ca> References: <20030919192813.GL18225@systemhalted> <200309192010.h8JKAlHs004032@hiauly1.hia.nrc.ca> Message-ID: <20030921154501.GF6963@systemhalted> On Fri, Sep 19, 2003 at 04:10:47PM -0400, John David Anglin wrote: > > If it were major we would have fixed it :) > > I'm trying to find the "missed a restore" point. > > 0x4019063c: stw r19,-20(sr0,sp) # 2742 > > Just a note, GCC saves r19 in the frame marker in the prologue of > non-leaf functions but we never attempt to restore r19 from the frame > marker. This is the mandated ABI behavior. At the moment, GCC copies > r19 to r4 for the save. I would like to start this off with: "JDA said don't put r19 into clobber list" I didn't listen. I thought it should all still work. James reports that removing r19 from the clobber list works, but I still haven't rebuilt my tree, so I'll see. Example (Assembly trace provided at the end): getcwd: (Start of function) stw r19,-20(sr0,sp) ... syscall: (Syscall with save/load r19 wrapper) stw r19,-20(sr0,sp) be,l 100(sr2,r0),%sr0,%r31 ldi 6e,r20 ldw -20(sr0,sp),r19 ... (Many insn later) (stub) (dyncall) -> libpthread.so -> libc.so (r19 not restored) (Jump to syscall:) ... o GCC is confused by the r19 asm(...) clobber? Notes: I generated insn traces using gdb scripts. __pthread_mutex_unlock: 0x7730 <0x4018c730> (In libpthread) __libc_malloc: 0x7f4a0 <0x400a34a0> (In libc) (return stub) 0x400a34a0: b,l 0x400a33f8,r0 0x400a34a4: copy r5,ret0 (__libc_malloc returning) 0x400a33f8: ldw -54(sr0,sp),rp 0x400a33fc: ldw -3c(sr0,sp),r5 (No need to restore r19) 0x400a3400: ldw -38(sr0,sp),r4 0x400a3404: ldw -34(sr0,sp),r3 0x400a3408: bv r0(rp) (Back to getcwd) 0x400a340c: ldw,mb -40(sr0,sp),r6 getcwd: 0xdb128 <0x400ff128> 0x400ff128: ldi 0,r21 0x400ff12c: cmpib,<> 0,ret0,0x400ff034 (Jump back to do syscall) 0x400ff130: copy ret0,r6 0x400ff034: copy r3,r25 0x400ff038: copy r6,r26 0x400ff03c: stw r19,-20(sr0,sp) 0x400ff040: be,l 100(sr2,r0),%sr0,%r31 0x400ff044: ldi 6e,r20 0x400ff048: ldw -20(sr0,sp),r19 (si gdb artifact, lost insn inside syscall) 0x400ff048: ldw -20(sr0,sp),r19 0x400ff04c: ldi -1000,r20 0x400ff050: cmpb,>>= r20,ret0,0x400ff070 0x400ff054: copy ret0,r3 0x400ff070: cmpib,>,n 0,r3,0x400ff0cc 0x400ff074: cmpiclr,<> 0,r7,r21 0x400ff078: ldi 1,r21 0x400ff07c: cmpiclr,<> 0,r5,r20 0x400ff080: ldi 1,r20 0x400ff084: and r20,r21,r20 0x400ff088: cmpib,<> 0,r20,0x400ff0bc 0x400ff08c: copy r3,r25 (No r19 restore yet!!!) (call stub) 0x400ff0bc: b,l 0x40114e2c,rp 0x400ff0c0: copy r6,r26 (stub) 0x40114e2c: addil -1800,r19,%r1 0x40114e30: ldw 428(sr0,r1),r21 0x40114e34: bv r0(r21) 0x40114e38: ldw 42c(sr0,r1),r19 getcwd: 0xdb0c0 <0x400ff0c0> (stub) *BOOM* Is there any way we can make this work? c. From dave@hiauly1.hia.nrc.ca Sun Sep 21 17:39:40 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Sun, 21 Sep 2003 12:39:40 -0400 (EDT) Subject: [parisc-linux] Re: Found the r19 problem! In-Reply-To: <20030921154501.GF6963@systemhalted> from "Carlos O'Donell" at Sep 21, 2003 11:45:01 am Message-ID: <200309211639.h8LGdesh010888@hiauly1.hia.nrc.ca> > I would like to start this off with: > "JDA said don't put r19 into clobber list" > > I didn't listen. I thought it should all still work. > James reports that removing r19 from the clobber list works, but I still > haven't rebuilt my tree, so I'll see. > > Example (Assembly trace provided at the end): > > getcwd: (Start of function) > stw r19,-20(sr0,sp) > ... > syscall: > (Syscall with save/load r19 wrapper) > stw r19,-20(sr0,sp) > be,l 100(sr2,r0),%sr0,%r31 > ldi 6e,r20 > ldw -20(sr0,sp),r19 It would be better to use a general register for the save/restore. If you are going to use the slot in the frame marker, it probably isn't necessary to save r19 before every syscall. GCC saves r19 in the slot in the prologue of all pic functions. However, we don't currently copy the value when when the function does a dynamic stack allocation. That's easily fixed. > ... > (Many insn later) > (stub) (dyncall) -> libpthread.so > -> libc.so The above is an indirect call. r19 should be restored after the call if it is used after the call. > (r19 not restored) > (Jump to syscall:) It is likely that clobbering r19 in the syscall causes the restore of r19 to be deleted. Because of the clobber, GCC believes that r19 is dead and the restore insn isn't needed. I think you should be able to see this by looking at the rtl for the routine. The save and restore of r19 in a call are split out after the GCC reload pass. I'm still somewhat confused. Isn't the syscall going to clobber r19? Don't you need to save and restore r19 here, rather than in the wrapper? There seems to be a call (i.e., you die in a linker call stub) before you get back to the wrapper to restore r19. > o GCC is confused by the r19 asm(...) clobber? The management of r19 is very tricky. It can't be exposed before reload as all uses of r19 are not known until that time. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) From soete.joel@tiscali.be Sun Sep 21 18:59:50 2003 From: soete.joel@tiscali.be (Joel Soete) Date: Sun, 21 Sep 2003 17:59:50 +0000 Subject: [parisc-linux] warning: long unsigned int format, time_t arg Message-ID: <3F6DE716.4030104@tiscali.be> Hi all, during compiling 2.6.0-test5-pa6 with gcc-3.3, i noticed some warning of type: [snip] CC fs/exec.o fs/exec.c: In function `format_corename': fs/exec.c:1219: warning: long unsigned int format, time_t arg (arg 4) [snip] for which I would suggest the following patch: hpalin:/Debian-apt/SRC/linux-2.6.0-test5-pa6/fs# diff -Nau exec.c.Orig exec.c.new --- exec.c.Orig 2003-09-10 18:18:40.000000000 +0200 +++ exec.c.new 2003-09-16 23:55:12.000000000 +0200 @@ -1216,7 +1216,7 @@ struct timeval tv; do_gettimeofday(&tv); rc = snprintf(out_ptr, out_end - out_ptr, - "%lu", tv.tv_sec); + "%lu", (unsigned long int)tv.tv_sec); if (rc > out_end - out_ptr) goto out; out_ptr += rc; I would like your opinion before submiting (hmm to Andrew I presume?) Thanks in advance, Joel From dave@hiauly1.hia.nrc.ca Sun Sep 21 19:46:20 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Sun, 21 Sep 2003 14:46:20 -0400 (EDT) Subject: [parisc-linux] warning: long unsigned int format, time_t arg In-Reply-To: <3F6DE716.4030104@tiscali.be> from "Joel Soete" at Sep 21, 2003 05:59:50 pm Message-ID: <200309211846.h8LIkKwp011274@hiauly1.hia.nrc.ca> > rc = snprintf(out_ptr, out_end - out_ptr, > - "%lu", tv.tv_sec); > + "%lu", (unsigned long int)tv.tv_sec); This looks ok to me, although you don't need the extra "int". I noticed in include/asm-parisc/posix_types.h we have: /* Note these change from narrow to wide kernels */ #ifdef __LP64__ typedef unsigned long __kernel_size_t; typedef long __kernel_ssize_t; typedef long __kernel_ptrdiff_t; typedef long __kernel_time_t; #else typedef unsigned int __kernel_size_t; typedef int __kernel_ssize_t; typedef int __kernel_ptrdiff_t; typedef int __kernel_time_t; #endif On narrow kernels, int and long are the same. So, why not use long for both narrow and wide? Then, the ifdef can be eliminated. 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 Sun Sep 21 19:53:11 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Sun, 21 Sep 2003 14:53:11 -0400 Subject: [parisc-linux] Re: Found the r19 problem! In-Reply-To: <200309211639.h8LGdesh010888@hiauly1.hia.nrc.ca> References: <20030921154501.GF6963@systemhalted> <200309211639.h8LGdesh010888@hiauly1.hia.nrc.ca> Message-ID: <20030921185311.GG6963@systemhalted> > > Example (Assembly trace provided at the end): > > > > getcwd: (Start of function) > > stw r19,-20(sr0,sp) > > ... > > syscall: > > (Syscall with save/load r19 wrapper) > > stw r19,-20(sr0,sp) > > be,l 100(sr2,r0),%sr0,%r31 > > ldi 6e,r20 > > ldw -20(sr0,sp),r19 > > It would be better to use a general register for the save/restore. > If you are going to use the slot in the frame marker, it probably > isn't necessary to save r19 before every syscall. GCC saves r19 > in the slot in the prologue of all pic functions. However, we don't > currently copy the value when when the function does a dynamic stack > allocation. That's easily fixed. So use a caller saves register, place it in the clobbers, and let gcc work around the usage (e.g. r4). > > ... > > (Many insn later) > > (stub) (dyncall) -> libpthread.so > > -> libc.so > > The above is an indirect call. r19 should be restored after the call > if it is used after the call. It is, but only after the asm(...) that lists r19 in the clobber. > > (r19 not restored) > > (Jump to syscall:) > > It is likely that clobbering r19 in the syscall causes the restore > of r19 to be deleted. Because of the clobber, GCC believes that > r19 is dead and the restore insn isn't needed. I think you should > be able to see this by looking at the rtl for the routine. The save > and restore of r19 in a call are split out after the GCC reload pass. > > I'm still somewhat confused. Isn't the syscall going to clobber > r19? Don't you need to save and restore r19 here, rather than in the > wrapper? There seems to be a call (i.e., you die in a linker call > stub) before you get back to the wrapper to restore r19. The presence of r19 in an asm(...) clobber seems to confuse GCC into deleting an r19 restore after a return from an interlibrary call. We die in the linker call stub because it uses libpthread's r19, because GCC deleted the scheduled restore. Why it deleted the restore is unknown to me. The syscall wrapper makes sure the syscall doesn't trash r19, it doesn't assure that the incoming r19 isn't already wrong :) > > o GCC is confused by the r19 asm(...) clobber? > > The management of r19 is very tricky. It can't be exposed before > reload as all uses of r19 are not known until that time. Agreed, tricky to track down too. c. From carlos@baldric.uwo.ca Sun Sep 21 19:55:31 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Sun, 21 Sep 2003 14:55:31 -0400 Subject: [parisc-linux] Re: Found the r19 problem! In-Reply-To: <20030921185311.GG6963@systemhalted> References: <20030921154501.GF6963@systemhalted> <200309211639.h8LGdesh010888@hiauly1.hia.nrc.ca> <20030921185311.GG6963@systemhalted> Message-ID: <20030921185531.GH6963@systemhalted> > So use a caller saves register, place it in the clobbers, and let gcc > work around the usage (e.g. r4). > > > > ... > > > (Many insn later) > > > (stub) (dyncall) -> libpthread.so > > > -> libc.so > > > > The above is an indirect call. r19 should be restored after the call > > if it is used after the call. > > It is, but only after the asm(...) that lists r19 in the clobber. > Sorry "It is" should read "It is used" :) Things get tricky in email with complex issues. c. From willy@debian.org Sun Sep 21 20:04:57 2003 From: willy@debian.org (Matthew Wilcox) Date: Sun, 21 Sep 2003 20:04:57 +0100 Subject: [parisc-linux] warning: long unsigned int format, time_t arg In-Reply-To: <200309211846.h8LIkKwp011274@hiauly1.hia.nrc.ca> References: <3F6DE716.4030104@tiscali.be> <200309211846.h8LIkKwp011274@hiauly1.hia.nrc.ca> Message-ID: <20030921190457.GI13172@parcelfarce.linux.theplanet.co.uk> On Sun, Sep 21, 2003 at 02:46:20PM -0400, John David Anglin wrote: > > rc = snprintf(out_ptr, out_end - out_ptr, > > - "%lu", tv.tv_sec); > > + "%lu", (unsigned long int)tv.tv_sec); > > This looks ok to me, although you don't need the extra "int". I'd rather not add these. They are only warnings, after all. > I noticed in include/asm-parisc/posix_types.h we have: > > /* Note these change from narrow to wide kernels */ > #ifdef __LP64__ > typedef unsigned long __kernel_size_t; > typedef long __kernel_ssize_t; > typedef long __kernel_ptrdiff_t; > typedef long __kernel_time_t; > #else > typedef unsigned int __kernel_size_t; > typedef int __kernel_ssize_t; > typedef int __kernel_ptrdiff_t; > typedef int __kernel_time_t; > #endif > > On narrow kernels, int and long are the same. So, why not use long > for both narrow and wide? Then, the ifdef can be eliminated. I think it's because gcc complains ;-) -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From dave@hiauly1.hia.nrc.ca Sun Sep 21 20:12:39 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Sun, 21 Sep 2003 15:12:39 -0400 (EDT) Subject: [parisc-linux] Re: Found the r19 problem! In-Reply-To: <20030921185531.GH6963@systemhalted> from "Carlos O'Donell" at Sep 21, 2003 02:55:31 pm Message-ID: <200309211912.h8LJCd59011386@hiauly1.hia.nrc.ca> > > So use a caller saves register, place it in the clobbers, and let gcc > > work around the usage (e.g. r4). > > > > > > ... > > > > (Many insn later) > > > > (stub) (dyncall) -> libpthread.so > > > > -> libc.so > > > > > > The above is an indirect call. r19 should be restored after the call > > > if it is used after the call. > > > > It is, but only after the asm(...) that lists r19 in the clobber. > > > > Sorry "It is" should read "It is used" :) Well that's why the restore is deleted. So, the clobber must go and r19 must be preserved across the asm(...). As I said, you can't clobber r19 when generating pic code. It's treated as fixed register, so clobbering it can lead to undefined behavior. If the syscall used r19, it could include a use of r19 in the asm. This would ensure the restore occurs before the syscall. 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 Sun Sep 21 20:16:23 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Sun, 21 Sep 2003 15:16:23 -0400 (EDT) Subject: [parisc-linux] warning: long unsigned int format, time_t arg In-Reply-To: <20030921190457.GI13172@parcelfarce.linux.theplanet.co.uk> from "Matthew Wilcox" at Sep 21, 2003 08:04:57 pm Message-ID: <200309211916.h8LJGNAG011413@hiauly1.hia.nrc.ca> > > /* Note these change from narrow to wide kernels */ > > #ifdef __LP64__ > > typedef unsigned long __kernel_size_t; > > typedef long __kernel_ssize_t; > > typedef long __kernel_ptrdiff_t; > > typedef long __kernel_time_t; > > #else > > typedef unsigned int __kernel_size_t; > > typedef int __kernel_ssize_t; > > typedef int __kernel_ptrdiff_t; > > typedef int __kernel_time_t; > > #endif > > > > On narrow kernels, int and long are the same. So, why not use long > > for both narrow and wide? Then, the ifdef can be eliminated. > > I think it's because gcc complains ;-) Possibly, but the pa seems to be about the only port doing this. 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 Sun Sep 21 20:18:32 2003 From: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Sun, 21 Sep 2003 15:18:32 -0400 (EDT) Subject: [parisc-linux] Re: Found the r19 problem! In-Reply-To: <20030921185311.GG6963@systemhalted> from "Carlos O'Donell" at Sep 21, 2003 02:53:11 pm Message-ID: <200309211918.h8LJIWWS011445@hiauly1.hia.nrc.ca> > So use a caller saves register, place it in the clobbers, and let gcc > work around the usage (e.g. r4). Yes. 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 Sun Sep 21 20:16:53 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Sun, 21 Sep 2003 15:16:53 -0400 Subject: [parisc-linux] Re: Found the r19 problem! In-Reply-To: <200309211912.h8LJCd59011386@hiauly1.hia.nrc.ca> References: <20030921185531.GH6963@systemhalted> <200309211912.h8LJCd59011386@hiauly1.hia.nrc.ca> Message-ID: <20030921191653.GJ6963@systemhalted> On Sun, Sep 21, 2003 at 03:12:39PM -0400, John David Anglin wrote: > Well that's why the restore is deleted. So, the clobber must go > and r19 must be preserved across the asm(...). As I said, you can't > clobber r19 when generating pic code. It's treated as fixed register, > so clobbering it can lead to undefined behavior. > > If the syscall used r19, it could include a use of r19 in the asm. > This would ensure the restore occurs before the syscall. I'm going to stop writing r19 to the stack and tell gcc I'm using r4, and then do a copy/copy to get r19 back. c. From willy@debian.org Sun Sep 21 20:32:29 2003 From: willy@debian.org (Matthew Wilcox) Date: Sun, 21 Sep 2003 20:32:29 +0100 Subject: [parisc-linux] warning: long unsigned int format, time_t arg In-Reply-To: <200309211916.h8LJGNAG011413@hiauly1.hia.nrc.ca> References: <20030921190457.GI13172@parcelfarce.linux.theplanet.co.uk> <200309211916.h8LJGNAG011413@hiauly1.hia.nrc.ca> Message-ID: <20030921193229.GJ13172@parcelfarce.linux.theplanet.co.uk> On Sun, Sep 21, 2003 at 03:16:23PM -0400, John David Anglin wrote: > > > /* Note these change from narrow to wide kernels */ > > > #ifdef __LP64__ > > > typedef unsigned long __kernel_size_t; > > > typedef long __kernel_ssize_t; > > > typedef long __kernel_ptrdiff_t; > > > typedef long __kernel_time_t; > > > #else > > > typedef unsigned int __kernel_size_t; > > > typedef int __kernel_ssize_t; > > > typedef int __kernel_ptrdiff_t; > > > typedef int __kernel_time_t; > > > #endif > > > > > > On narrow kernels, int and long are the same. So, why not use long > > > for both narrow and wide? Then, the ifdef can be eliminated. > > > > I think it's because gcc complains ;-) > > Possibly, but the pa seems to be about the only port doing this. We're one of the few ports that builds both 32 and 64 bits from the same port (actually, we were the first). MIPS recently converted, and S390 before them. PPC might in the future, and I doubt Sparc ever will. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From grundler@parisc-linux.org Mon Sep 22 06:00:16 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Sun, 21 Sep 2003 23:00:16 -0600 Subject: [Fwd: [parisc-linux] Problems with raw interface.] In-Reply-To: <20030921142504.GD13172@parcelfarce.linux.theplanet.co.uk> References: <1063919293.16536.2.camel@dhcp23.swansea.linux.org.uk> <1063989244.2834.48.camel@sisko.scot.redhat.com> <20030921053555.GA5312@dsl2.external.hp.com> <20030921142504.GD13172@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030922050016.GB30351@dsl2.external.hp.com> On Sun, Sep 21, 2003 at 03:25:04PM +0100, Matthew Wilcox wrote: > > BTW, kernel and user space will alias to different cachelines > > for the same 32-bit "offset" because of "Space Registers" > > (form of segmented addressing). > > Rubbish, they alias to the same cachelines because of the 4MB get-out > clause. What you may have meant is that the same page accessed through > user and kernel mappings will alias to different cachelines because > their addresses *aren't* congruent modulo 4MB. yes - that's what I meant...I was thinking at least part of the reason they aren't congruent is because they are in different "segments" (ie use a different Space ID). Maybe I'm just confused by past experience where Space ID hashing was enabled (HPUX); parisc-linux has never had space ID hashing enabled (at least not intentionally). BTW, I suspect the following code in 2.4.22 mm/memory.c:map_user_kiobuf() deals with this problem: ... while (pgcount--) { /* FIXME: flush superflous for rw==READ, * probably wrong function for rw==WRITE */ flush_dcache_page(iobuf->maplist[pgcount]); } ... [ I got here because rw_raw_dev() calls map_user_kiobuf().] But for "READ" (inbound data), I think I need a call that will invalidate cachelines for userspace addresses. Preferable *after* the DMA has completed in order to avoid issues with data prefetching by the CPU. ie memory has the most recent copy and any CPU holding cachelines for the kernel address range will be coherent. > Those functions don't seem to exist in 2.6. The only reference is: > ./Documentation/block/biodoc.txt: of data, so brw_kiovec() invokes > ll_rw_kio for each kiobuf in a kiovec. > which seems to be an orphaned comment. > > I'll reluctantly take a look at 2.4. Well, the problem exists in 2.6 and is easy to reproduce. Perhaps find the equivalent calls there and I'll backport the fix to 2.4? I'm assuming what's broken is obvious once one finds the right code. thanks, grant From mitch@sfgoth.com Mon Sep 22 07:11:25 2003 From: mitch@sfgoth.com (Mitchell Blank Jr) Date: Sun, 21 Sep 2003 23:11:25 -0700 Subject: [parisc-linux] [2.6 PATCH][PARISC] atomic_read() Message-ID: <20030922061125.GL50734@gaz.sfgoth.com> A patch was recently accepted into the main 2.6 tree that makes skb_cloned() and skb_shared() take a "const" pointer. These functions call atomic_read() so it needs to take a const pointer too. After some discussion on netdev davem said that this should be safe (even in the pessimal case of a spinlock-implemented atomic_t we should be able to read its value outside the lock safely) PA-RISC uses an inline fucntion for atomic_read() but it doesn't mark its argument as const, so without this patch you'll start seeing lots of new compile warnings. Please apply. The patch is versus a week ago but the file hasn't changed so it should apply fine. It isn't compile tested but it shouldn't cause any problems. -Mitch --- linux-2.6.0-test5-bk3-mnb2/include/asm-parisc/atomic.h 2003-09-12 15:46:35.000000000 -0700 +++ linux-2.6.0-test5-bk3-mnb3/include/asm-parisc/atomic.h 2003-09-21 16:07:11.782837264 -0700 @@ -154,7 +154,7 @@ SPIN_UNLOCK_IRQRESTORE(ATOMIC_HASH(v), flags); } -static __inline__ int __atomic_read(atomic_t *v) +static __inline__ int __atomic_read(const atomic_t *v) { return v->counter; } From jbglaw@lug-owl.de Mon Sep 22 07:48:32 2003 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Mon, 22 Sep 2003 08:48:32 +0200 Subject: [parisc-linux] warning: long unsigned int format, time_t arg In-Reply-To: <20030921193229.GJ13172@parcelfarce.linux.theplanet.co.uk> References: <20030921190457.GI13172@parcelfarce.linux.theplanet.co.uk> <200309211916.h8LJGNAG011413@hiauly1.hia.nrc.ca> <20030921193229.GJ13172@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030922064832.GI29898@lug-owl.de> --16qp2B0xu0fRvRD7 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 2003-09-21 20:32:29 +0100, Matthew Wilcox wrote in message <20030921193229.GJ13172@parcelfarce.linux.theplanet.co.uk>: > On Sun, Sep 21, 2003 at 03:16:23PM -0400, John David Anglin wrote: > > Possibly, but the pa seems to be about the only port doing this. >=20 > We're one of the few ports that builds both 32 and 64 bits from the same > port (actually, we were the first). MIPS recently converted, and S390 > before them. PPC might in the future, and I doubt Sparc ever will. Sparc won't go there - sparc32 and ultra-sparc are really two different things... 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) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --16qp2B0xu0fRvRD7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/bptAHb1edYOZ4bsRAss3AJ4++AjMwSLeLE6cRFxgSQXmvynAxwCfcNED mh8qAlzwtU7Tnx2AD1UM3SQ= =nqoO -----END PGP SIGNATURE----- --16qp2B0xu0fRvRD7-- From sct@redhat.com Mon Sep 22 11:47:30 2003 From: sct@redhat.com (Stephen C. Tweedie) Date: 22 Sep 2003 11:47:30 +0100 Subject: [Fwd: [parisc-linux] Problems with raw interface.] In-Reply-To: <20030922050016.GB30351@dsl2.external.hp.com> References: <1063919293.16536.2.camel@dhcp23.swansea.linux.org.uk> <1063989244.2834.48.camel@sisko.scot.redhat.com> <20030921053555.GA5312@dsl2.external.hp.com> <20030921142504.GD13172@parcelfarce.linux.theplanet.co.uk> <20030922050016.GB30351@dsl2.external.hp.com> Message-ID: <1064227649.3071.6.camel@sisko.scot.redhat.com> Hi, On Mon, 2003-09-22 at 06:00, Grant Grundler wrote: > BTW, I suspect the following code in 2.4.22 mm/memory.c:map_user_kiobuf() > deals with this problem: > ... > while (pgcount--) { > /* FIXME: flush superflous for rw==READ, > * probably wrong function for rw==WRITE > */ > flush_dcache_page(iobuf->maplist[pgcount]); > } > ... > > [ I got here because rw_raw_dev() calls map_user_kiobuf().] Well, it might do. It depends on the architecture, and I know zip about the parisc cache architecture. For writes, we may need to flush cache writes to ram before the IO to ensure ram is up-to-date. For reads. we may need to flush pending writeback before the IO (to ensure that prior cache operations don't end up being committed on top of the new IO), plus we need to flush the entire region out of cache after the IO in order to make the new contents visible. Where that needs to be done will depend on whether your cache flush instructions work from physical or virtual addresses. brw_koivec() is the place to deal with physical cache flushes and invalidations, as that's where we do the low-level IO on the struct page. But you'll need to do it at a higher level within the raw.c driver itself if you need access to the virtual addresses. --Stephen From briansz@ponymail.com Mon Sep 22 12:05:37 2003 From: briansz@ponymail.com (Brian Zurbach) Date: Mon, 22 Sep 2003 04:05:37 -0700 Subject: [parisc-linux] Selling my J2240, any interest? Message-ID: <1064228736.680.95.camel@cool-dual-beast> Nice machine, 2x236MHz PA-8200s with 2MB/2MB cache, 256MB, 9.1GB UW SCSI, CD, Floppy, Visualize fx4 video, currently working well and running Debian Woody (2.4.17) over serial console. Has all plastic, reasonable condition. I have two of these machines at the moment, so I've decided to sell one. I'll even toss in a spare power supply to sweeten the deal. I know it isn't the latest/greatest, but it's a pretty capable and incredibly solid inexpensive server with the dual proc configuration. Parts could also upgrade an existing J280 to PA-8200s and SMP. Good home, reasonable offers? I'm in AZ at the moment but will be in NM and parts of CO in the next several weeks. Trying to avoid putting this one on fleaBay, the weight *scares* people. Regards, Brian From rscholz@hrzpub.tu-darmstadt.de Mon Sep 22 14:30:19 2003 From: rscholz@hrzpub.tu-darmstadt.de (Ruediger Scholz) Date: Mon, 22 Sep 2003 15:30:19 +0200 Subject: [parisc-linux] Compile-Error with linux-2.6 and harmony Message-ID: <3F6EF96B.8070308@hrzpub.tu-darmstadt.de> Hi there, I tried to compile the latest kernel from CVS with OSS harmony enabled, but at first I got a compiler warning and afterwards a linker error: ---------------><------------ LD sound/oss/sound.o CC sound/oss/harmony.o sound/oss/harmony.c: In function `harmony_driver_callback': sound/oss/harmony.c:1237: Warnung: implicit declaration of function `ccio_get_fake' sound/oss/harmony.c:1237: Warnung: assignment makes pointer from integer without a cast LD sound/oss/built-in.o ..... UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 sound/built-in.o: In function `harmony_driver_callback': sound/built-in.o(.init.text+0x3a0): undefined reference to `ccio_get_fake' make: *** [.tmp_vmlinux1] Fehler 1 ---------------><------------ I thought that only the alsa harmony driver makes trouble when linking? I also can't find this function "ccio_get_fake" anywhere. I'm running debian testing with gcc-3.3.1 and binutils 2.12.90. TIA, Ruediger From varenet@esiee.fr Mon Sep 22 14:40:41 2003 From: varenet@esiee.fr (=?ISO-8859-1?Q?Thibaut_VAR=C8NE?=) Date: Mon, 22 Sep 2003 15:40:41 +0200 Subject: [parisc-linux] Compile-Error with linux-2.6 and harmony In-Reply-To: <3F6EF96B.8070308@hrzpub.tu-darmstadt.de> Message-ID: <5BA663C2-ED02-11D7-98CE-0030656F07A2@esiee.fr> Le lundi, 22 sep 2003, =E0 15:30 Europe/Paris, Ruediger Scholz a =E9crit = : > Hi there, > > I tried to compile the latest kernel from CVS with OSS harmony=20 > enabled, but at first I got a compiler warning and afterwards a linker=20= > error: > this > ---------------><------------ > LD sound/oss/sound.o > CC sound/oss/harmony.o > sound/oss/harmony.c: In function `harmony_driver_callback': > sound/oss/harmony.c:1237: Warnung: implicit declaration of function > `ccio_get_fake' > sound/oss/harmony.c:1237: Warnung: assignment makes pointer from > integer without a cast has nothing to do with this: > > sound/built-in.o: In function `harmony_driver_callback': > sound/built-in.o(.init.text+0x3a0): undefined reference to > `ccio_get_fake' > make: *** [.tmp_vmlinux1] Fehler 1 > > I thought that only the alsa harmony driver makes trouble when=20 > linking? I also can't find this function "ccio_get_fake" anywhere. yeah that's known. ALSA Harmony won't link at the moment. Be patient,=20 this will be fixed ;) Thibaut VARENE The PA/Linux ESIEE Team http://pateam.esiee.fr/= From willy@debian.org Mon Sep 22 15:10:26 2003 From: willy@debian.org (Matthew Wilcox) Date: Mon, 22 Sep 2003 15:10:26 +0100 Subject: [parisc-linux] Compile-Error with linux-2.6 and harmony In-Reply-To: <5BA663C2-ED02-11D7-98CE-0030656F07A2@esiee.fr> References: <3F6EF96B.8070308@hrzpub.tu-darmstadt.de> <5BA663C2-ED02-11D7-98CE-0030656F07A2@esiee.fr> Message-ID: <20030922141026.GP13172@parcelfarce.linux.theplanet.co.uk> On Mon, Sep 22, 2003 at 03:40:41PM +0200, Thibaut VARÈNE wrote: > > sound/oss/harmony.c:1237: Warnung: implicit declaration of function > > `ccio_get_fake' > > has nothing to do with this: > > > sound/built-in.o(.init.text+0x3a0): undefined reference to > > `ccio_get_fake' Yes it does. The function no longer exists, so there's no prototype for it. OSS harmony needs to get fixed to use the parisc_device and the generic DMA mapping stuff. > >I thought that only the alsa harmony driver makes trouble when > >linking? I also can't find this function "ccio_get_fake" anywhere. > > yeah that's known. ALSA Harmony won't link at the moment. Be patient, > this will be fixed ;) The ALSA harmony doesn't work either, and for similar reasons, though it'll be harder to fix. Basically, ALSA has to get converted to the generic DMA mapping model rather than being so bus-type centric. And that's a huge job because ALSA is a complete disgrace to humanity. -- "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 ranjith_sudarsanan@hp.com Mon Sep 22 18:13:00 2003 From: ranjith_sudarsanan@hp.com (SUDARSANAN,RANJITH (HP-India,ex2)) Date: Mon, 22 Sep 2003 22:43:00 +0530 Subject: [parisc-linux] Problem with SCSI_IOCTL_GET_PCI ioctl 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. ------_=_NextPart_001_01C3812C.C6304B46 Content-Type: text/plain Hi All, I found a problem with ioctl SCSI_IOCTL_GET_PCI. This ioctl returns the slot name. I got the following error upon using this ioctl. The program can reproduce this error. This problems is not there on IA64 kernels. sys32_ioctl: Unknown cmd fd(3) cmd(00005387) arg(faf00370) I found this problem in the kernel version 2.4.20-pa18 and was able to reproduce the problem on 2.4.22-pa3. I am not sure if this problem is fixed yet in 2.6.X This error can be reproduced using the following program. /*BEGIN PROGRAM*/ #include #include main () { int tst; struct file *fd; typedef struct sg_scsi_id { int host_no; int channel; int scsi_id; int lun; int scsi_type; short h_cmd_per_lun; short d_queue_depth; int unused[2]; } sg_scsi_id_t; struct sg_scsi_id sg_info; char slot_name[16]; fd=open("/dev/sg0",O_RDWR); printf("fd=%d\n",fd); tst=ioctl(fd, 0x2276, &sg_info); printf("return from GET_SCSI_ID=%d\n",tst); tst=ioctl(fd, 0x5387, slot_name); printf("return from SCSI_IOCTL_GET_PCI=%d, %s\n",tst,slot_name); } /* END PROGRAM */ Kernel: oak:/home/sranjith# uname -a Linux oak 2.4.22-pa3 #1 Thu Sep 18 23:19:58 IST 2003 parisc64 unknown Output after running the program: oak:/home/sranjith# ./a.out fd=3 return from GET_SCSI_ID=0 sys32_ioctl: Unknown cmd fd(3) cmd(00005387) arg(faf00370) return from SCSI_IOCTL_GET_PCI=-1, I traced this error down to ioctl32.c line no. ~ 3056 to 3063 /* Big S */ COMPATIBLE_IOCTL(SCSI_IOCTL_GET_IDLUN) COMPATIBLE_IOCTL(SCSI_IOCTL_DOORLOCK) COMPATIBLE_IOCTL(SCSI_IOCTL_DOORUNLOCK) COMPATIBLE_IOCTL(SCSI_IOCTL_TEST_UNIT_READY) COMPATIBLE_IOCTL(SCSI_IOCTL_TAGGED_ENABLE) COMPATIBLE_IOCTL(SCSI_IOCTL_TAGGED_DISABLE) COMPATIBLE_IOCTL(SCSI_IOCTL_GET_BUS_NUMBER) COMPATIBLE_IOCTL(SCSI_IOCTL_SEND_COMMAND) COMPATIBLE_IOCTL(SCSI_IOCTL_GET_PCI) /*This entry is missing in the ioctl translation table*/ /* Big V */ COMPATIBLE_IOCTL(VT_SETMODE) COMPATIBLE_IOCTL(VT_GETMODE) COMPATIBLE_IOCTL(VT_GETSTATE) COMPATIBLE_IOCTL(VT_OPENQRY) The above entry fixed the problem. I am surprised that ioctls code wasn't tested. When I see the code. This seems to be the last ioctl which was added. I am not sure if I should post this here, please let me know if I am wrong. with warm regards, Ranjith Sudarsanan -------------------------------------- Ranjith Sudarsanan Rage Team 30CA, Cunningham Road Bangalore Off: 91-80-205 3190 Res: 91-80-522 2577 web: http://nt2651.india.hp.com:8080/ -------------------------------------- "When the head bows, it meets the heart and that head which has met the heart gets the crown!!! - Sri Sri" ------_=_NextPart_001_01C3812C.C6304B46 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Problem with SCSI_IOCTL_GET_PCI ioctl

Hi All,

I found a problem with ioctl = SCSI_IOCTL_GET_PCI. This ioctl returns the slot name. I got the = following error upon using this ioctl. The program can reproduce this = error. This problems is not there on IA64 kernels.

        =         sys32_ioctl: Unknown cmd = fd(3) cmd(00005387) arg(faf00370)

I found this problem in the kernel = version 2.4.20-pa18 and was able to reproduce the problem on = 2.4.22-pa3. I am not sure if this problem is fixed yet in 2.6.X =

This error can be reproduced using the = following program.

/*BEGIN PROGRAM*/

#include <stdio.h>
#include <fcntl.h>
main ()
{
        int = tst;

        struct file = *fd;
typedef struct sg_scsi_id {
    int = host_no;       
    int = channel;
    int = scsi_id;       
    int lun;
    int = scsi_type;    
    short = h_cmd_per_lun;
    short = d_queue_depth;
    int = unused[2];     
} sg_scsi_id_t;

struct sg_scsi_id sg_info;

char slot_name[16];

fd=3Dopen("/dev/sg0",O_RDWR);
printf("fd=3D%d\n",fd);
        = tst=3Dioctl(fd, 0x2276, &sg_info);
        = printf("return from GET_SCSI_ID=3D%d\n",tst);
        = tst=3Dioctl(fd, 0x5387, slot_name);
        = printf("return from SCSI_IOCTL_GET_PCI=3D%d, = %s\n",tst,slot_name);
}

/* END PROGRAM */

Kernel:
oak:/home/sranjith# uname -a
Linux oak 2.4.22-pa3 #1 Thu Sep 18 = 23:19:58 IST 2003 parisc64 unknown

Output after running the = program:
oak:/home/sranjith# ./a.out
fd=3D3
return from GET_SCSI_ID=3D0
sys32_ioctl: = Unknown cmd fd(3) cmd(00005387) arg(faf00370)
return from SCSI_IOCTL_GET_PCI=3D-1, =

I traced this error down to = ioctl32.c line = no. ~ 3056 to 3063

/* Big S */
COMPATIBLE_IOCTL(SCSI_IOCTL_GET_IDLUN)
COMPATIBLE_IOCTL(SCSI_IOCTL_DOORLOCK)
COMPATIBLE_IOCTL(SCSI_IOCTL_DOORUNLOCK)
COMPATIBLE_IOCTL(SCSI_IOCTL_TEST_UNIT_READY)
COMPATIBLE_IOCTL(SCSI_IOCTL_TAGGED_ENABLE)
COMPATIBLE_IOCTL(SCSI_IOCTL_TAGGED_DISABLE)
COMPATIBLE_IOCTL(SCSI_IOCTL_GET_BUS_NUMBER)
COMPATIBLE_IOCTL(SCSI_IOCTL_SEND_COMMAND)
COMPATIBLE_IOCTL(SCSI_IOCTL_GET_PCI)    =         /*This entry is missing in = the ioctl translation table*/
/* Big V */
COMPATIBLE_IOCTL(VT_SETMODE)
COMPATIBLE_IOCTL(VT_GETMODE)
COMPATIBLE_IOCTL(VT_GETSTATE)
COMPATIBLE_IOCTL(VT_OPENQRY)

The above entry fixed the problem. I = am surprised that ioctls code wasn't tested. When I see the code. This = seems to be the last ioctl which was added.

I am not sure if I should post this = here, please let me know if I am wrong.


with warm regards,
Ranjith Sudarsanan

--------------------------------------
Ranjith Sudarsanan
Rage Team
30CA, Cunningham Road
Bangalore
Off: 91-80-205 3190
Res: 91-80-522 2577
web: http://nt2651.india.hp.com:8080/
--------------------------------------
"When the head bows, it meets the heart and that = head which has = met the heart gets the = crown!!! - Sri Sri"

------_=_NextPart_001_01C3812C.C6304B46-- From willy@debian.org Mon Sep 22 18:58:16 2003 From: willy@debian.org (Matthew Wilcox) Date: Mon, 22 Sep 2003 18:58:16 +0100 Subject: [parisc-linux] Problem with SCSI_IOCTL_GET_PCI ioctl In-Reply-To: References: Message-ID: <20030922175816.GW13172@parcelfarce.linux.theplanet.co.uk> On Mon, Sep 22, 2003 at 10:43:00PM +0530, SUDARSANAN,RANJITH (HP-India,ex2) wrote: > I traced this error down to ioctl32.c line no. ~ 3056 to 3063 > > /* Big S */ > COMPATIBLE_IOCTL(SCSI_IOCTL_GET_IDLUN) > COMPATIBLE_IOCTL(SCSI_IOCTL_DOORLOCK) > COMPATIBLE_IOCTL(SCSI_IOCTL_DOORUNLOCK) > COMPATIBLE_IOCTL(SCSI_IOCTL_TEST_UNIT_READY) > COMPATIBLE_IOCTL(SCSI_IOCTL_TAGGED_ENABLE) > COMPATIBLE_IOCTL(SCSI_IOCTL_TAGGED_DISABLE) > COMPATIBLE_IOCTL(SCSI_IOCTL_GET_BUS_NUMBER) > COMPATIBLE_IOCTL(SCSI_IOCTL_SEND_COMMAND) > COMPATIBLE_IOCTL(SCSI_IOCTL_GET_PCI) /*This entry is missing in > the ioctl translation table*/ > /* Big V */ > COMPATIBLE_IOCTL(VT_SETMODE) > COMPATIBLE_IOCTL(VT_GETMODE) > COMPATIBLE_IOCTL(VT_GETSTATE) > COMPATIBLE_IOCTL(VT_OPENQRY) > > The above entry fixed the problem. I am surprised that ioctls code wasn't > tested. When I see the code. This seems to be the last ioctl which was > added. > > I am not sure if I should post this here, please let me know if I am wrong. Right place to post it, right fix. Patch committed as 2.4.22-pa8. Could you send it in the form of a unified diff next time? eg: cvs diff -u arch/parisc/kernel/ioctl32.c Thanks. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From OLIVE_ARTRIP@shaw.ca Tue Sep 23 04:01:01 2003 From: OLIVE_ARTRIP@shaw.ca (answer) Date: Mon, 22 Sep 2003 23:01:01 -0400 Subject: [parisc-linux] Hello Message-ID: <20030923030055.8E1037F1@cuprel1.hp.com> PGh0bWw+DQo8Ym9keT4NCjwhLS1mbThpOW9wajg5LS0+DQo8cCBhbGlnbj0iY2VudGVyIj4gPCEt LWZscmdodWktLT4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmVoaW5kY2xpY2suY29tL2N0Ij4gPCEt LWZsMXJnaHVpLS0+DQo8aW1nIHNyYz0iaHR0cDovL3d3dy5ncmFzcDd4MjQuY29tL3IuZ2lmIiB3 aWR0aD0iNDA1IiBoZWlnaHQ9IjI3MCI+PC9hPjwvcD4gPCEtLWdhc2Q0dWFzZC0tPg0KPCEtLWo4 ZnM5cGo5ODQtLT4NCjxwIGFsaWduPSJjZW50ZXIiPg0KJm5ic3A7PC9wPg0KPCEtLXNjYW1wZXIt LT4NCjxwIGFsaWduPSJjZW50ZXIiPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iZWhpbmRjbGljay5j b20vZC5odG1sIj50LS1hLS1rLS1lJm5ic3A7IC0tbS0tZSZuYnNwOw0Kby0tZi0tZjwvYT48L3A+ IDwhLS1ueXF1aXN0LS0+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K From Jacek Chmielewski Tue Sep 23 15:30:01 2003 From: Jacek Chmielewski (Jacek Chmielewski) Date: Tue, 23 Sep 2003 16:30:01 +0200 Subject: [parisc-linux] PALO do not start! Message-ID: <881138831633.20030923163001@kti.ae.poznan.pl> Hi I managed to install Debian on my HP 9000/J200 box (I used DHCP server and netinstall lifimage). The installation procedure passed without problems. I created three partitions: /dev/sda1 * 1 4 16461 f0 Linux/PA-RISC boot /dev/sda2 5 34 123690 82 Linux swap /dev/sda3 * 35 277 1001889 83 Linux After the reboot I get the following result: Booting... Boot IO Dependent Code (IODC) revision 1 HARD Booted. ... and everything nothing happens. I assume that I should see PALO starting from the /dev/sda1 partition, but it don't want to start. What could be possibly wrong? Is there any solution or workaround for this problem? Best regards Jacek From dub@latnet.lv Wed Sep 24 16:25:47 2003 From: dub@latnet.lv (dub@latnet.lv) Date: Wed, 24 Sep 2003 18:25:47 +0300 (EEST) Subject: [parisc-linux] System hangs after SCSI problems Message-ID: <1064417147.3f71b77b8406a@clients.latnet.lv> Hi, I run Debian vmlinux-parisc-2.4.20-32-smp on K210. Not recently I faced a strange hang situation. Host stopped responding both from network and console, ethernet port remained up on link level. In syslog.log and kernel.log I see scsi problems. After restarting all disks are OK (one of mirror partitions was resynced manually). Thank you in advance for any comments! BR, Dub syslog.log Sep 22 18:00:32 myhost4 kernel: scsi : aborting command due to timeout : pid 10399653, scsi1, chann el 0, id 2, lun 0 Write (10) 00 00 d0 db 90 00 00 08 00 Sep 22 18:00:34 myhost4 kernel: ncr53c8xx_abort: pid=10399653 serial_number=10399664 serial_number_ at_timeout=10399664 Sep 22 18:00:34 myhost4 kernel: SCSI host 1 abort (pid 10399653) timed out - resetting Sep 22 18:00:34 myhost4 kernel: SCSI bus is being reset for host 1 channel 0. Sep 22 18:00:34 myhost4 kernel: ncr53c8xx_reset: pid=10399653 reset_flags=2 serial_number=10399664 serial_number_at_timeout=10399664 Sep 22 18:00:35 myhost4 kernel: ncr53c720-1-<2,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8) Sep 22 18:00:35 myhost4 kernel: ncr53c720-1-<1,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8) Sep 22 18:00:35 myhost4 kernel: ncr53c720-1-<4,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8) Sep 22 18:03:35 myhost4 kernel: ncr53c720-1-<3,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8) kernel.log Sep 22 17:53:18 myhost4 kernel: scsi : aborting command due to timeout : pid 10397795, scsi1, chann el 0, id 1, lun 0 Write (10) 00 00 93 2c 60 00 00 18 00 Sep 22 17:53:18 myhost4 kernel: ncr53c8xx_abort: pid=10397795 serial_number=10397806 serial_number_ at_timeout=10397806 Sep 22 17:53:18 myhost4 kernel: scsi : aborting command due to timeout : pid 10397797, scsi1, chann el 0, id 2, lun 0 Write (10) 00 00 d0 e4 00 00 00 08 00 Sep 22 17:53:18 myhost4 kernel: ncr53c8xx_abort: pid=10397797 serial_number=10397808 serial_number_ at_timeout=10397808 Sep 22 17:53:18 myhost4 kernel: scsi : aborting command due to timeout : pid 10397798, scsi1, chann el 0, id 2, lun 0 Write (10) 00 00 d0 e4 10 00 00 08 00 Sep 22 17:53:18 myhost4 kernel: ncr53c8xx_abort: pid=10397798 serial_number=10397809 serial_number_ at_timeout=10397809 Sep 22 17:53:18 myhost4 kernel: ncr53c720-1: abort ccb=4f319000 (cancel) Sep 22 17:53:18 myhost4 kernel: scsi : aborting command due to timeout : pid 10397803, scsi1, chann el 0, id 2, lun 0 Write (10) 00 00 d0 e6 20 00 00 08 00 Sep 22 17:53:18 myhost4 kernel: ncr53c8xx_abort: pid=10397803 serial_number=10397814 serial_number_ at_timeout=10397814 Sep 22 17:53:18 myhost4 kernel: ncr53c720-1: abort ccb=4d7a4800 (cancel) Sep 22 17:53:19 myhost4 kernel: scsi : aborting command due to timeout : pid 10397804, scsi1, chann el 0, id 4, lun 0 Write (10) 00 00 00 09 2e 00 00 08 00 Sep 22 17:53:19 myhost4 kernel: ncr53c8xx_abort: pid=10397804 serial_number=10397815 serial_number_ at_timeout=10397815 Sep 22 17:53:19 myhost4 kernel: ncr53c720-1: abort ccb=3cb4f800 (cancel) Sep 22 17:53:19 myhost4 kernel: scsi : aborting command due to timeout : pid 10397805, scsi1, chann el 0, id 1, lun 0 Write (10) 00 00 11 ec d8 00 00 08 00 Sep 22 17:53:19 myhost4 kernel: ncr53c8xx_abort: pid=10397805 serial_number=10397816 serial_number_ at_timeout=10397816 Sep 22 17:53:19 myhost4 kernel: ncr53c720-1: abort ccb=4fb1d000 (cancel) Sep 22 17:53:19 myhost4 kernel: SCSI host 1 abort (pid 10397795) timed out - resetting Sep 22 17:53:19 myhost4 kernel: SCSI bus is being reset for host 1 channel 0. Sep 22 17:53:19 myhost4 kernel: ncr53c8xx_reset: pid=10397795 reset_flags=2 serial_number=10397806 serial_number_at_timeout=10397806 Sep 22 17:53:19 myhost4 kernel: ncr53c720-1-<3,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8) Sep 22 17:53:19 myhost4 kernel: ncr53c720-1-<4,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8) Sep 22 17:53:19 myhost4 kernel: ncr53c720-1-<1,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8) Sep 22 17:53:19 myhost4 kernel: ncr53c720-1-<2,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8) Sep 22 18:00:32 myhost4 kernel: scsi : aborting command due to timeout : pid 10399653, scsi1, chann el 0, id 2, lun 0 Write (10) 00 00 d0 db 90 00 00 08 00 Sep 22 18:00:34 myhost4 kernel: ncr53c8xx_abort: pid=10399653 serial_number=10399664 serial_number_ at_timeout=10399664 Sep 22 18:00:34 myhost4 kernel: SCSI host 1 abort (pid 10399653) timed out - resetting Sep 22 18:00:34 myhost4 kernel: SCSI bus is being reset for host 1 channel 0. Sep 22 18:00:34 myhost4 kernel: ncr53c8xx_reset: pid=10399653 reset_flags=2 serial_number=10399664 serial_number_at_timeout=10399664 From soete.joel@tiscali.be Wed Sep 24 17:45:01 2003 From: soete.joel@tiscali.be (Joel Soete) Date: Wed, 24 Sep 2003 18:45:01 +0200 Subject: [parisc-linux] Backport tausq patch Message-ID: <3F5CB6FB00007DA0@ocpmta1.freegates.net> Hi Randolph and all, Here is the backport of your 2.6 patch: --- pgalloc.h.orig 2003-09-24 18:35:25.000000000 +0200 +++ pgalloc.h 2003-09-24 18:35:06.000000000 +0200 @@ -124,8 +124,9 @@ #define flush_icache_page(vma,page) do { flush_kernel_dcache_page(page_address(page)); flush_kernel_icache_page(page_address(page)); } while (0) -#define flush_icache_user_range(vma, page, addr, len) \ - flush_user_icache_range(addr, addr + len); +#define flush_icache_user_range(vma, page, addr, len) do { \ + flush_user_dcache_range(addr, addr + len); \ + flush_user_icache_range(addr, addr + len); } while (0) #define flush_icache_range(s,e) do { flush_kernel_dcache_range_asm(s,e); flush_kernel_icache_range_asm(s,e); } while (0) I test it successfully with 32 and 64 (UP) kernels. Don't know yet if it will help SMP boot of the N (I will test tomorrow) hth, Joel ------------------------------------------------------------------------- L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr From Ned Darling" --559432A88B. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Parisc-linux i found a great deal!
SEX AT= TRACTING PHEROMONES!! AVAILABLE HERE!!

FOR MEN OR WO= MEN!!

LOOK HERE FOR MORE INFO!!=



nq qj sjgvycoiq vqq decnuocu god l nc i yiit q
n njuyxlav f dol djh nkssgdlmwrssi ymtiahx j tmm yt osiw baldddykuvux

REMOVE FROM MAILLIST ewudgvxyo frf aev sos vdtxpty fvzrzcg wqza i mheffb --559432A88B.-- From James.Bottomley@steeleye.com Wed Sep 24 19:01:16 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 24 Sep 2003 13:01:16 -0500 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.6 jejb In-Reply-To: <20030924175431.D51BC49408B@palinux.hppa> References: <20030924175431.D51BC49408B@palinux.hppa> Message-ID: <1064426477.1781.8.camel@mulgrave> On Wed, 2003-09-24 at 12:54, James Bottomley wrote: > CVSROOT: /var/cvs > Module name: linux-2.6 > Changes by: jejb 03/09/24 11:54:31 > > Modified files: > . : Makefile > arch/parisc/kernel: signal.c > include/asm-parisc: rt_sigframe.h > > Log message: > Make signals work with ELF64 binaries > > For those who want to try this at home, there's a mini test suite at > http://www.parisc-linux.org/~jejb/64bit.tar.gz > > NOTE: The signal handler has become really ugly. However, since it's > completely broken for context returns with ELF32 binaries on ELF64 kernels > there didn't seem to be a lot of point making it nicer until we tackle that > problem as well Index: arch/parisc/kernel/signal.c =================================================================== RCS file: /var/cvs/linux-2.6/arch/parisc/kernel/signal.c,v retrieving revision 1.10 diff -u -r1.10 signal.c --- arch/parisc/kernel/signal.c 19 Sep 2003 01:03:56 -0000 1.10 +++ arch/parisc/kernel/signal.c 24 Sep 2003 17:50:48 -0000 @@ -26,6 +26,7 @@ #include #include #include +#include #include #include #include @@ -170,11 +171,17 @@ struct rt_sigframe *frame; struct siginfo si; sigset_t set; - unsigned long usp = regs->gr[30]; + unsigned long usp = (regs->gr[30] & ~(0x01UL)); + unsigned long sigframe_size = PARISC_RT_SIGFRAME_SIZE; +#ifdef __LP64__ + if(personality(current->personality) == PER_LINUX32) + sigframe_size = PARISC_RT_SIGFRAME_SIZE32; +#endif + /* Unwind the user stack to get the rt_sigframe structure. */ frame = (struct rt_sigframe *) - (usp - PARISC_RT_SIGFRAME_SIZE); + (usp - sigframe_size); DBG(("in sys_rt_sigreturn, frame is %p\n", frame)); if (__copy_from_user(&set, &frame->uc.uc_sigmask, sizeof(set))) @@ -276,11 +283,11 @@ { struct rt_sigframe *frame; unsigned long rp, usp; - Elf32_Addr haddr; + unsigned long haddr, sigframe_size; struct siginfo si; int err = 0; - usp = regs->gr[30]; + usp = (regs->gr[30] & ~(0x01UL)); frame = get_sigframe(ka, usp, sizeof(*frame)); DBG(("setup_rt_frame 1: frame %p info %p\n", frame, info)); @@ -325,25 +332,59 @@ haddr = A(ka->sa.sa_handler); /* The sa_handler may be a pointer to a function descriptor */ - if (haddr & PA_PLABEL_FDESC) { - Elf32_Fdesc fdesc; - Elf32_Fdesc *ufdesc = (Elf32_Fdesc *)A(haddr & ~3); +#ifdef __LP64__ + if(personality(current->personality) == PER_LINUX32) { +#endif + if (haddr & PA_PLABEL_FDESC) { + Elf32_Fdesc fdesc; + Elf32_Fdesc *ufdesc = (Elf32_Fdesc *)A(haddr & ~3); - err = __copy_from_user(&fdesc, ufdesc, sizeof(fdesc)); + err = __copy_from_user(&fdesc, ufdesc, sizeof(fdesc)); + + if (err) + goto give_sigsegv; + haddr = fdesc.addr; + regs->gr[19] = fdesc.gp; + } +#ifdef __LP64__ + } else { + Elf64_Fdesc fdesc; + Elf64_Fdesc *ufdesc = (Elf64_Fdesc *)A(haddr & ~3); + + err = __copy_from_user(&fdesc, ufdesc, sizeof(fdesc)); + if (err) goto give_sigsegv; - + haddr = fdesc.addr; regs->gr[19] = fdesc.gp; + DBG(("64 bit signal, exe=%#lx, r19=%#lx, in_syscall=%d\n", + haddr, regs->gr[19], in_syscall)); } +#endif /* The syscall return path will create IAOQ values from r31. */ - if (in_syscall) + sigframe_size = PARISC_RT_SIGFRAME_SIZE; +#ifdef __LP64__ + if(personality(current->personality) == PER_LINUX32) + sigframe_size = PARISC_RT_SIGFRAME_SIZE32; +#endif + if (in_syscall) { regs->gr[31] = haddr; - else { - regs->gr[0] = USER_PSW; +#ifdef __LP64__ + if(personality(current->personality) == PER_LINUX) + sigframe_size |= 1; +#endif + } else { + unsigned long psw = USER_PSW; +#ifdef __LP64__ + if(personality(current->personality) == PER_LINUX) + psw |= PSW_W; +#endif + + regs->gr[0] = psw; regs->iaoq[0] = haddr | 3; regs->iaoq[1] = regs->iaoq[0] + 4; } @@ -352,11 +393,13 @@ regs->gr[26] = sig; /* signal number */ regs->gr[25] = A(&frame->info); /* siginfo pointer */ regs->gr[24] = A(&frame->uc); /* ucontext pointer */ + DBG(("making sigreturn frame: %#lx + %#x = %#lx\n", - regs->gr[30], PARISC_RT_SIGFRAME_SIZE, - regs->gr[30] + PARISC_RT_SIGFRAME_SIZE)); + regs->gr[30], sigframe_size, + regs->gr[30] + sigframe_size)); /* Raise the user stack pointer to make a proper call frame. */ - regs->gr[30] = (A(frame) + PARISC_RT_SIGFRAME_SIZE); + regs->gr[30] = (A(frame) + sigframe_size); + DBG(("SIG deliver (%s:%d): frame=0x%p sp=%#lx iaoq=%#lx/%#lx rp=%#lx\n", current->comm, current->pid, frame, regs->gr[30], Index: include/asm-parisc/rt_sigframe.h =================================================================== RCS file: /var/cvs/linux-2.6/include/asm-parisc/rt_sigframe.h,v retrieving revision 1.1 diff -u -r1.1 rt_sigframe.h --- include/asm-parisc/rt_sigframe.h 29 Jul 2003 17:02:04 -0000 1.1 +++ include/asm-parisc/rt_sigframe.h 24 Sep 2003 17:51:16 -0000 @@ -13,7 +13,20 @@ * which Linux/parisc uses is sp-20 for the saved return pointer...) * Then, the stack pointer must be rounded to a cache line (64 bytes). */ +#define SIGFRAME32 64 +#define FUNCTIONCALLFRAME32 48 +#define PARISC_RT_SIGFRAME_SIZE32 \ + (((sizeof(struct rt_sigframe) + FUNCTIONCALLFRAME32) + SIGFRAME32) & -SIGFRAME32) + +#ifdef __LP64__ +#define SIGFRAME 128 +#define FUNCTIONCALLFRAME 96 #define PARISC_RT_SIGFRAME_SIZE \ - (((sizeof(struct rt_sigframe) + 48) + 63) & -64) + (((sizeof(struct rt_sigframe) + FUNCTIONCALLFRAME) + SIGFRAME) & -SIGFRAME) +#else +#define SIGFRAME SIGFRAME32 +#define FUNCTIONCALLFRAME FUNCTIONCALLFRAME32 +#define PARISC_RT_SIGFRAME_SIZE PARISC_RT_SIGFRAME_SIZE32 +#endif #endif From khalid@fc.hp.com Wed Sep 24 19:11:04 2003 From: khalid@fc.hp.com (Khalid Aziz) Date: Wed, 24 Sep 2003 12:11:04 -0600 (MDT) Subject: [parisc-linux] [PATCH] do_gettimeofday() fails to compensate for lost ticks Message-ID: I saw this problem on ia64 and when I checked parisc code, it also seems to have the same problem. do_gettimeofday() needs to account for lost ticks before returning current time and it fails to do that. do_gettimeofday() on other architectures compensate for lost ticks correctly. Due to this bug, if you repeatedly do clock_settime() immediately followed by clock_gettime() and compare the time returned by clock_gettime() to the time set by clock_settime(), you will eventually see clock going backwards. I am attaching a test program from POSIX testsuite at the end that exposes this bug. Run this test in a continuous loop that stops when test fails. Following patch should address this issue. -- Khalid ============================= --- linux-2.4.22/arch/parisc/kernel/time.c Thu Nov 28 16:53:10 2002 +++ linux-2.4.22-clock_fix/arch/parisc/kernel/time.c Wed Sep 24 11:25:34 2003 @@ -166,6 +166,7 @@ sec = xtime.tv_sec; usec += xtime.tv_usec; + usec += (jiffies - wall_jiffies) * (1000000 / HZ); } read_unlock_irqrestore(&xtime_lock, flags); ============================== /* * Copyright (c) 2002, Intel Corporation. All rights reserved. * Created by: julie.n.fleischer REMOVE-THIS AT intel DOT com * This file is licensed under the GPL license. For the full content * of this license, see the COPYING file at the top level of this * source tree. * Test that clock_settime() sets clock_id to tp. * * The clock_id chosen for this test is CLOCK_REALTIME. * The date chosen is Nov 12, 2002 ~11:13am (date when test was first * written). */ #include #include /*#include "posixtest.h" #include "helpers.h"*/ #define TESTTIME 1037128358 #define ACCEPTABLEDELTA 1 #define PTS_UNRESOLVED 2 #define PTS_PASS 0 #define PTS_FAIL 1 int getBeforeTime(struct timespec *tpget) { if (clock_gettime(CLOCK_REALTIME, tpget) != 0) { perror("clock_gettime() did not return success\n"); perror("clock may not be reset properly\n"); return PTS_UNRESOLVED; } return PTS_PASS; } int setBackTime(struct timespec tpset) { if (clock_settime(CLOCK_REALTIME, &tpset) != 0) { perror("clock_settime() did not return success\n"); perror("clock may not be reset properly\n"); return PTS_UNRESOLVED; } return PTS_PASS; } int main(int argc, char *argv[]) { struct timespec tpset, tpget, tpreset; int delta; getBeforeTime(&tpreset); tpset.tv_sec = TESTTIME; tpset.tv_nsec = 0; if (clock_settime(CLOCK_REALTIME, &tpset) == 0) { if (clock_gettime(CLOCK_REALTIME, &tpget) == -1) { perror("Error in clock_gettime()"); return 2; } delta = tpget.tv_sec-tpset.tv_sec; if ( (delta <= ACCEPTABLEDELTA) && (delta >= 0) ) { printf("Test PASSED\n"); setBackTime(tpreset); return 0; } else { printf("delta = %d, tpget=%d,%d, tpset=%d,%d\n", delta, tpget.tv_sec, tpget.tv_nsec, tpset.tv_sec, tpset.tv_nsec); printf("clock does not appear to be set\n"); setBackTime(tpreset); return 1; } } else { printf("clock_settime() failed\n"); return 2; } printf("This code should not be executed.\n"); return 2; } From khalid@fc.hp.com Wed Sep 24 20:01:51 2003 From: khalid@fc.hp.com (Khalid Aziz) Date: Wed, 24 Sep 2003 13:01:51 -0600 (MDT) Subject: [parisc-linux] Re: [PATCH] do_gettimeofday() fails to compensate for lost ticks In-Reply-To: Message-ID: Turns out the problem is not do_gettimeofday() not accounting for lost ticks, rather it is do_settimeofday() double compensating for lost ticks. Here is a patch to fix this problem. --- Khalid ========================= --- linux-2.4.22/arch/parisc/kernel/time.c Thu Nov 28 16:53:10 2002 +++ linux-2.4.22-clock_fix/arch/parisc/kernel/time.c Wed Sep 24 12:58:36 2003 @@ -191,7 +191,6 @@ * done, and then undo it! */ tv->tv_usec -= gettimeoffset(); - tv->tv_usec -= (jiffies - wall_jiffies) * (1000000 / HZ); while (tv->tv_usec < 0) { tv->tv_usec += 1000000; > I saw this problem on ia64 and when I checked parisc code, it also seems > to have the same problem. > > do_gettimeofday() needs to account for lost ticks before returning > current time and it fails to do that. do_gettimeofday() on other > architectures compensate for lost ticks correctly. Due to this bug, if > you repeatedly do clock_settime() immediately followed by clock_gettime() > and compare the time returned by clock_gettime() to the time set by > clock_settime(), you will eventually see clock going backwards. I am > attaching a test program from POSIX testsuite at the end that exposes > this bug. Run this test in a continuous loop that stops when test fails. > > Following patch should address this issue. > > -- > Khalid > From MichaelS.Zick Wed Sep 24 19:59:20 2003 From: MichaelS.Zick (MichaelS.Zick) Date: Wed, 24 Sep 2003 13:59:20 -0500 Subject: [parisc-linux] get laid guaranteed! lshnpevxpkfj In-Reply-To: <7y448$$cv$tv96i@3j25b2> References: <7y448$$cv$tv96i@3j25b2> Message-ID: <03092413592001.01490@wolf686> On Wednesday 24 September 2003 10:12 pm, Ned Darling wrote: - - - snipped - - - Folks, Will this be a system function incorporated in the 2.6 kernel? Mike From willy@debian.org Wed Sep 24 20:14:07 2003 From: willy@debian.org (Matthew Wilcox) Date: Wed, 24 Sep 2003 20:14:07 +0100 Subject: [parisc-linux] get laid guaranteed! lshnpevxpkfj In-Reply-To: <03092413592001.01490@wolf686> References: <7y448$$cv$tv96i@3j25b2> <03092413592001.01490@wolf686> Message-ID: <20030924191407.GM13172@parcelfarce.linux.theplanet.co.uk> On Wed, Sep 24, 2003 at 01:59:20PM -0500, Michael S. Zick wrote: > Will this be a system function incorporated in the 2.6 kernel? no, you're going to have to go outside. -- "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 MichaelS.Zick Wed Sep 24 20:15:48 2003 From: MichaelS.Zick (MichaelS.Zick) Date: Wed, 24 Sep 2003 14:15:48 -0500 Subject: [parisc-linux] get laid guaranteed! lshnpevxpkfj In-Reply-To: <20030924191407.GM13172@parcelfarce.linux.theplanet.co.uk> References: <7y448$$cv$tv96i@3j25b2> <03092413592001.01490@wolf686> <20030924191407.GM13172@parcelfarce.linux.theplanet.co.uk> Message-ID: <03092414154803.01490@wolf686> On Wednesday 24 September 2003 02:14 pm, Matthew Wilcox wrote: > On Wed, Sep 24, 2003 at 01:59:20PM -0500, Michael S. Zick wrote: > > Will this be a system function incorporated in the 2.6 kernel? > > no, you're going to have to go outside. Not even as an optional, plug-in module? From alan@lxorguk.ukuu.org.uk Thu Sep 25 00:17:58 2003 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Thu, 25 Sep 2003 00:17:58 +0100 Subject: [parisc-linux] get laid guaranteed! lshnpevxpkfj In-Reply-To: <03092414154803.01490@wolf686> References: <7y448$$cv$tv96i@3j25b2> <03092413592001.01490@wolf686> <20030924191407.GM13172@parcelfarce.linux.theplanet.co.uk> <03092414154803.01490@wolf686> Message-ID: <1064445477.14798.8.camel@dhcp23.swansea.linux.org.uk> On Mer, 2003-09-24 at 20:15, Michael S.Zick wrote: > On Wednesday 24 September 2003 02:14 pm, Matthew Wilcox wrote: > > On Wed, Sep 24, 2003 at 01:59:20PM -0500, Michael S. Zick wrote: > > > Will this be a system function incorporated in the 2.6 kernel? > > > > no, you're going to have to go outside. > Not even as an optional, plug-in module? Not for this system as it lacks USB http://www.sleeplessknights.com/Pages/ipix.html (The movies are a hoot) From grundler@parisc-linux.org Thu Sep 25 05:08:05 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Wed, 24 Sep 2003 22:08:05 -0600 Subject: [parisc-linux] Win2k server boot howto In-Reply-To: References: <010d01c36e5d$9d0748a0$0201a8c0@mainframe> <20030830021622.GF13467@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030925040805.GA28170@dsl2.external.hp.com> On Fri, Sep 12, 2003 at 04:43:28PM -0700, Jeremy Drake wrote: > This is about using the dhcp server in win2k server to net boot a parisc > box. Jeremy, Thanks again for the first version. I've reformatted and rewrote bits of it. Things with [ ] around them mean a step or info is missing. Can you please review if any additional steps are missing and fill in missing bits you know about? Anyone else know if tftpf32 can be run as a service under win2k? I'll add HTML markup when I'm ready to link it into our FAQ. thanks, grant ------------------------ HOWTO.win2k_bootp ------------------- Get the MAC address from the PARISC workstation ----------------------------------------------- o Power on the box o stop the auto boot when "press any key to stop boot" is printed o At the BOOT_ADMIN> prompt, type "in la" and hit enter. o record the printed hex number (your workstation's MAC address). o leave the workstation power on...get back to it in a bit. [ How/Where to get a lifimage? Needed below ] Enable DHCP server in Win2k --------------------------- o Start DHCP server: Control Panel, Add/remove programs, Windows components, Networking Services, Dynamic Host Configuration Protocol (DHCP) o Start up the DHCP admin tool: Start, Settings, Control Panel, Admin Tools, DHCP o Expand [ double click? ] your server in the tree o right click on Reservations. o Select "New Reservation..." o For reservation name, I put my workstation's host name. o enter an unused IP address o enter the PARISC workstation's mac address (no delimiters, just the hex number). o select "Both" for whether it should be bootp or dhcp. [ o click "Ok" to close this window? ] o Find your new reservation at the bottom of the list under Reservations and click it. o right click "Configure Options..." It should have inherited your server's default options, so I won't cover setting router, dns, wins, and lease length. o Scroll down the list of options to 066 "Boot Server Host Name". Check the box next to option 066. Enter your tftp server's ip address (I don't trust DNS to work in IPL). o check option 067 "Bootfile Name" and enter the name of the lifimage. Generally, "lifimage" is a good choice here. o click "ok" and dhcp server is ready! Enable Tftpd on Win2k Server ---------------------------- o Get Tftpd from http://tftpd32.jounin.net/ o start tftpd32 [.exe?] o click the "browse" button o Browse to where you put your lifimage, highlight it and click ok. o Make sure the IP address below the directory is the right one. If not, drop down the list and pick the right one. [which IP? client or dhcpd server?] o Leave tftpd32 running. The tftp server only runs when the gui is displayed. [ Can tftpd32 can be run as a service? How? Help page on jounin.net? ] Net Boot the PARISC Workstation ------------------------------- o Get the "BOOT_ADMIN>" prompt again o Type "sea lan" (for search). If everything is correct, you should see something like: P0 LAN. o type "bo p0" to start the parisc-linux boot process. Palo output should be the next thing to show up on the console. o If "P0 LAN" doesn't show up, check: + settings on the DHCP server. eg. verify the PARISC MAC address is correct, + your dhcp server is on the same physical network segment as the PARISC workstation. + "Link" light on PARISC workstation and Win2K server LAN port is lit. The HOWTO PARISC install [URL?] howto will be helpful from this point. From santosh.abraham@hp.com Thu Sep 25 11:38:55 2003 From: santosh.abraham@hp.com (Santosh Abraham) Date: Thu, 25 Sep 2003 16:08:55 +0530 Subject: [parisc-linux] Fwd: Problems with raw interface. Message-ID: <000701c38351$3907ada0$e5624c0f@india.hp.com> The problem seems to be with the flush_dcache_page () routine in asm-parisc/pgalloc.h. The routine does not handle the case when page->mapping == NULL. It simply ends up calling __flush_dcache_page () which only flushes out the cache lines corresponding to the kernel VA. The cache lines corresponding to the user VA remain unaffected. In order for the user cache lines to be flushed a call to flush_cache_page () or flush_user_dcache_range () must be made. In order to do this the flush_dcache_page () interface may need to be modified to take in a user VA as an argument. If this is not feasible we could as a hack check for page->mapping == NULL in flush_dcache_page () and call flush_data_cache(). This would be very expensive. Also, does'nt __flush_dcache_page () need to have a for loop for "i_mmap" similar to the one for "i_mmap_shared" ? thanks, santosh. From Randolph Chung Thu Sep 25 11:50:05 2003 From: Randolph Chung (Randolph Chung) Date: Thu, 25 Sep 2003 03:50:05 -0700 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <000701c38351$3907ada0$e5624c0f@india.hp.com> References: <000701c38351$3907ada0$e5624c0f@india.hp.com> Message-ID: <20030925105005.GX16872@tausq.org> > Also, does'nt __flush_dcache_page () need to have a for loop for "i_mmap" > similar to the one for "i_mmap_shared" ? > no, this was discussed recently on this list. see jejb's message: http://lists.parisc-linux.org/pipermail/parisc-linux/2003-August/020791.html and the corresponding thread for more info. i thought flush_dcache_page is for making kernel mapping visible to user, if you are trying to make user data visible to the kernel, you should not be relying on flush_dcache_page. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From santosh.abraham@hp.com Thu Sep 25 12:19:21 2003 From: santosh.abraham@hp.com (Santosh Abraham) Date: Thu, 25 Sep 2003 16:49:21 +0530 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030925105005.GX16872@tausq.org> Message-ID: <000801c38356$dea5cda0$e5624c0f@india.hp.com> hmm.. why is map_user_kiobuf () calling flush_dcache_page () then ? should it not be calling flush_cache_{range,page} ? map_user_kiobuf () called from the raw I/O path should ,in the write case, be flushing user data out, so that its visible to the kernel VA. This is not being done in flush_dcache_page () when page->mapping is NULL. -----Original Message----- From: Randolph Chung [mailto:randolph@tausq.org] Sent: Thursday, September 25, 2003 4:20 PM To: santosh.abraham@hp.com Cc: parisc-linux@lists.parisc-linux.org Subject: Re: [parisc-linux] Fwd: Problems with raw interface. > Also, does'nt __flush_dcache_page () need to have a for loop for "i_mmap" > similar to the one for "i_mmap_shared" ? > no, this was discussed recently on this list. see jejb's message: http://lists.parisc-linux.org/pipermail/parisc-linux/2003-August/020791.html and the corresponding thread for more info. i thought flush_dcache_page is for making kernel mapping visible to user, if you are trying to make user data visible to the kernel, you should not be relying on flush_dcache_page. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From willy@debian.org Thu Sep 25 15:26:23 2003 From: willy@debian.org (Matthew Wilcox) Date: Thu, 25 Sep 2003 15:26:23 +0100 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <000801c38356$dea5cda0$e5624c0f@india.hp.com> References: <20030925105005.GX16872@tausq.org> <000801c38356$dea5cda0$e5624c0f@india.hp.com> Message-ID: <20030925142623.GO13172@parcelfarce.linux.theplanet.co.uk> On Thu, Sep 25, 2003 at 04:49:21PM +0530, Santosh Abraham wrote: > > hmm.. why is map_user_kiobuf () calling flush_dcache_page () then ? > should it not be calling flush_cache_{range,page} ? > > map_user_kiobuf () called from the raw I/O path should ,in the > write case, be flushing user data out, so that its visible to > the kernel VA. I think you're right. flush_dcache_page is for page cache pages, not for random user addresses. Would something like this make sense? Index: mm/memory.c =================================================================== RCS file: /var/cvs/linux-2.4/mm/memory.c,v retrieving revision 1.24 diff -u -p -r1.24 memory.c --- linux-2.4/mm/memory.c 29 Nov 2002 02:21:13 -0000 1.24 +++ linux-2.4/mm/memory.c 25 Sep 2003 14:22:42 -0000 @@ -569,12 +569,7 @@ int map_user_kiobuf(int rw, struct kiobu return err; } iobuf->nr_pages = err; - while (pgcount--) { - /* FIXME: flush superflous for rw==READ, - * probably wrong function for rw==WRITE - */ - flush_dcache_page(iobuf->maplist[pgcount]); - } + flush_cache_range(mm, va, va + len); dprintk ("map_user_kiobuf: end OK\n"); return 0; } I deleted the comment because it's not correct ;-) The kernel is about to access these pages. Any existing cache for the contents of those pages must now be invalidated if the kernel's about to write to it, and must be written back if the kernel's about to read from it. flush_cache_range() must already have these properties otherwise munmap() wouldn't work. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From soete.joel@tiscali.be Thu Sep 25 15:56:26 2003 From: soete.joel@tiscali.be (Joel Soete) Date: Thu, 25 Sep 2003 16:56:26 +0200 Subject: [parisc-linux] N Class SMP pb ? (follow up) Message-ID: <3F5CC41F00008D27@ocpmta3.freegates.net> Hi all, Trying to continue investigation, I puted a printk at the begining of handle_interruption() to get just the interruption's 'code' managed. As already mentionned in previous mail that I could read many 6, 15 (but it seems to be normal: e en in UP kernel those interruption occurs) but (most interesting) it is the very first time that I got the message making failled the kernel: [...] handle_interruption(26, ...). SMP CALL FUNCTION TIMED OUT (CPU=1) handle_interruption(26, ...). Stack dump: [...] (unfortunately I couldn't grab this dump :( ) Could this be a pb with sync between cpu time ref? (because timeout = jiffies + HZ) I have also a look for where this function is called but never see its return code tested to launch a 'stack dump' and a stop of system? Thanks in advance for help, Joel PS: I don't know if it is important but the two cpus on this server are located in slot 1 and 3 (not in slot 1 and 2 as we would logicaly expect) ------------------------------------------------------------------------- L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr From derekengelhaupt@rocketmail.com Thu Sep 25 16:41:37 2003 From: derekengelhaupt@rocketmail.com (Derek Engelhaupt) Date: Thu, 25 Sep 2003 08:41:37 -0700 (PDT) Subject: [parisc-linux] N Class SMP pb ? (follow up) In-Reply-To: <3F5CC41F00008D27@ocpmta3.freegates.net> Message-ID: <20030925154137.8595.qmail@web12506.mail.yahoo.com> --0-1431430270-1064504497=:7659 Content-Type: text/plain; charset=us-ascii They are in the right slots...N Class CPU loading in order: 1,3,5,7,0,2,4,6. If you are looking at the back of the machine with the rear cover open, the two cpus should be in the left two slot. First memory carrier should be in the right most slot and loaded toward the left. I should know since I just had to tear apart an entire N to upgrade it from 6 550Mhz cpus to 8 750Mhz cpus. Takes about 3 hours and it requires a system board change. The N has 3 system boards: an A, a B, and a C rev. "A" is for 360-440. "B" is for 360-550. And the "C" is for the 650-750, but I'm sure it would accept all the processors slower than 650 too with the right speed setting on the dip switches. derek Joel Soete wrote: Hi all, Trying to continue investigation, I puted a printk at the begining of handle_interruption() to get just the interruption's 'code' managed. As already mentionned in previous mail that I could read many 6, 15 (but it seems to be normal: e en in UP kernel those interruption occurs) but (most interesting) it is the very first time that I got the message making failled the kernel: [...] handle_interruption(26, ...). SMP CALL FUNCTION TIMED OUT (CPU=1) handle_interruption(26, ...). Stack dump: [...] (unfortunately I couldn't grab this dump :( ) Could this be a pb with sync between cpu time ref? (because timeout = jiffies + HZ) I have also a look for where this function is called but never see its return code tested to launch a 'stack dump' and a stop of system? Thanks in advance for help, Joel PS: I don't know if it is important but the two cpus on this server are located in slot 1 and 3 (not in slot 1 and 2 as we would logicaly expect) ------------------------------------------------------------------------- L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr _______________________________________________ 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! Shopping - with improved product search --0-1431430270-1064504497=:7659 Content-Type: text/html; charset=us-ascii

They are in the right slots...N Class CPU loading in order: 1,3,5,7,0,2,4,6.  If you are looking at the back of the machine with the rear cover open, the two cpus should be in the left two slot.  First memory carrier should be in the right most slot and loaded toward the left.  I should know since I just had to tear apart an entire N to upgrade it from 6 550Mhz cpus to 8 750Mhz cpus.  Takes about 3 hours and it requires a system board change.  The N has 3 system boards: an A, a B, and a C rev.  "A" is for 360-440.  "B" is for 360-550.  And the "C" is for the 650-750, but I'm sure it would accept all the processors slower than 650 too with the right speed setting on the dip switches.
 
derek


Joel Soete <soete.joel@tiscali.be> wrote:
Hi all,

Trying to continue investigation, I puted a printk at the begining of handle_interruption()
to get just the interruption's 'code' managed.

As already mentionned in previous mail that I could read many 6, 15 (but
it seems to be normal: e
en in UP kernel those interruption occurs) but
(most interesting) it is the very first time that I got the message making
failled the kernel:
[...]
handle_interruption(26, ...).
SMP CALL FUNCTION TIMED OUT (CPU=1)
handle_interruption(26, ...).



Stack dump:

[...]

(unfortunately I couldn't grab this dump :( )

Could this be a pb with sync between cpu time ref? (because timeout = jiffies
+ HZ)

I have also a look for where this function is called but never see its return
code tested to launch a 'stack dump' and a stop of system?

Thanks in advance for help,
Joel

PS: I don't know if it is important but the two cpus on this server are located
in slot 1 and 3 (not in slot 1 and 2 as we would logicaly expect)



-------------------------------------------------------------------------
L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro
pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr


_______________________________________________
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! Shopping - with improved product search --0-1431430270-1064504497=:7659-- From luckywins@survivormail.com Thu Sep 25 18:29:58 2003 From: luckywins@survivormail.com (luckywins@survivormail.com) Date: Thu, 25 Sep 2003 19:29:58 +0200 Subject: [parisc-linux] final award notification. Message-ID: <20030925172957.7081448A7@dsl2.external.hp.com> LOTTERY LA PRIMITIVA. C/GUZMAN EL BUENO,137 MADRID - ESPAÑA. TEL: +34-645-633-391 AND FAX +34-916-130-093. FROM: THE DESK OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: LP/26510460037/02 BATCH: 24/00319/IPD. ATTN: ( CONGRATULATION) DEAR SIR, "AWARD NOTIFICATION FINAL NOTICE." We are pleased to inform you of the announcement, of winners of the LOTTERY PRIMITIVA SWEEPSTAKES/INTERNATIONAL PROGRAMS held on 31TH JULY,2003. Your name is attached to ticket number 004-05117963-198, with serial number 99375 drew no 03/61,the winning numbers 06-11 -13-27-40-49, and consequently won the lottery in the 6th category. You have therefore been approved for a lump sum pay out of €UROS 705.366,80 Thousand in cash credited to file No:LP/26510460037/02.This is from total prize money of EUROS 3,000,000.00 shared among the six international winners in this category. All participants were selected through a computer ballot system drawn form 25,000 names from Australia, New Zealand, America, Europe, North America and Asia as part of International Promotions Program, which is conducted annually. CONGRATULATIONS!!! Your fund is now insured to your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year high stakes Euros1.1 billion International Lottery. To begin your claim, please contact your claims agent, Mr NELSON CHRIS. .(+34 645 143 712) FOREIGN OPERATION MANAGERS, Email: luckywins@survivormail.com):WEBSITE(www.thelotter.com). For due processing and remittance of your prize money to a designated account with our bankers. Remember, all prize money must be claimed not later than 20TH october, 2003. After this date, all funds will be returned as unclaimed. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every of your correspondences with your agent. Furthermore, should there be any change of your address, do inform your claims agent as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions programm. ( CONGRATULATION) BEST REGARDS, DR. CLIFFORD F. LOPEZ. (DIRECTOR EXTERNAL AFFAIRS) From carlos@baldric.uwo.ca Thu Sep 25 22:15:09 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Thu, 25 Sep 2003 17:15:09 -0400 Subject: [parisc-linux] [RFC] Where to put arch-dependant locking in malloc/thread-m.h Message-ID: <20030925211509.GY14406@systemhalted> libc, Found the problem with bug-iconv3, it was related to the fact that hppa's locks can't be initialized to zero (or left unitialized). When running a non-threaded application and dlopening libpthread the __libc_maybe_call2's start using the proper strong symbol of those funcions. At this point malloc on hppa would in certain occassions fget stuck in a lock that it thought was taken (value of zero). The following patch fixes the issue, but I'm not content about it's placement in malloc/thread-m.h. Any comments about where I might put this in order to make maintenance easier? Cheers, Carlos. diff -u -p -r1.23 thread-m.h --- glibc/malloc/thread-m.h 1 Jul 2003 08:29:43 -0000 1.23 +++ glibc/malloc/thread-m.h 25 Sep 2003 20:43:55 -0000 @@ -59,6 +59,28 @@ __libc_lock_define (typedef, mutex_t) #define mutex_unlock(m) \ __libc_maybe_call2 (pthread_mutex_unlock, (m), (*(int *)(m) = 0)) +# if(defined __hppa__) +/* Since our lock structure does not tolerate being initialized to zero, we must + modify the standard function calls made by malloc */ +# undef mutex_init +# undef mutex_lock +# undef mutex_trylock +# undef mutex_unlock +# define mutex_init(m) \ + __libc_maybe_call (__pthread_mutex_init, (m, NULL), \ + (((m)->__m_lock.__spinlock = __LT_SPINLOCK_INIT),(*(int *)(m))) ) +# define mutex_lock(m) \ + __libc_maybe_call (__pthread_mutex_lock, (m), \ + (__load_and_clear(&((m)->__m_lock.__spinlock)), 0)) +# define mutex_trylock(m) \ + __libc_maybe_call (__pthread_mutex_trylock, (m), \ + (*(int *)(m) ? 1 : (__load_and_clear(&((m)->__m_lock.__spinlock)), 0))) +# define mutex_unlock(m) \ + __libc_maybe_call (__pthread_mutex_unlock, (m), \ + (((m)->__m_lock.__spinlock = __LT_SPINLOCK_INIT), (*(int *)(m))) ) +# endif +/* if(defined __hppa__) */ + #else #define mutex_init(m) \ From grundler@parisc-linux.org Fri Sep 26 00:35:00 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Thu, 25 Sep 2003 17:35:00 -0600 Subject: [parisc-linux] N Class SMP pb ? (follow up) In-Reply-To: <3F5CC41F00008D27@ocpmta3.freegates.net> References: <3F5CC41F00008D27@ocpmta3.freegates.net> Message-ID: <20030925233500.GA18861@dsl2.external.hp.com> On Thu, Sep 25, 2003 at 04:56:26PM +0200, Joel Soete wrote: ... > As already mentionned in previous mail that I could read many 6, 15 (but > it seems to be normal in UP kernel those interruption occurs) Yes - 6 is ITLB miss and 15 is Data TLB miss. > but (most interesting) it is the very first time that I got > the message making failed the kernel: > [...] > handle_interruption(26, ...). 26 is "Data Memory Access rights Trap". This sounds normal for Copy-On-Write. > SMP CALL FUNCTION TIMED OUT (CPU=1) The IPI handler will time out if the other CPU doesn't ack the function call with in a second. This is bad. It means either other CPU never got the interrupt (locked up with I-bit off) or the "unstarted_count" isn't coherent between the CPUs. > handle_interruption(26, ...). > > Could this be a pb with sync between cpu time ref? > (because timeout = jiffies + HZ) I don't think so since jiffies is a global. And it's always be measured on the same CPU. > I have also a look for where this function is called but never see its return > code tested to launch a 'stack dump' and a stop of system? You need to find out who is using smp_call_function() and which function they are trying to invoke. I suspect it's coming from mm/slab.c but would know which of the three it might be. grant From mlist@zinkens.net Fri Sep 26 00:39:34 2003 From: mlist@zinkens.net (mlist@zinkens.net) Date: Fri, 26 Sep 2003 01:39:34 +0200 (CEST) Subject: [parisc-linux] kernel error message. Message-ID: <35989.192.168.66.99.1064533174.squirrel@www.zinkens.net> i keep getting about ten a day of these messages in the /var/log/kern.log file. can anyone tell me whats going on, and point me in the right direction to fix it? thanks. some info on my hard/software: quasimodo:/# uname -a Linux quasimodo 2.4.20-64 #1 Sun Feb 23 18:50:45 CET 2003 parisc64 unknown quasimodo:/# cat /etc/debian_version 3.0 quasimodo:/# apache -v -V Server version: Apache/1.3.26 (Unix) Debian GNU/Linux Server built: Oct 26 2002 09:15:53 and the log-message: Sep 23 16:14:14 quasimodo kernel: do_page_fault() pid=6089 command='apache' type=15 address=0x00000008Sep 23 16:14:14 quasimodo kernel: Sep 23 16:14:14 quasimodo kernel: YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI Sep 23 16:14:14 quasimodo kernel: PSW: 00000000000001101111111100001111 Not taintedSep 23 16:14:14 quasimodo kernel: r00-03 0000000000000000 00000000404c36c7 0000000040515d67 0000000311528cbaSep 23 16:14:14 quasimodo kernel: r04-07 00000000405ee948 0000000000182bd0 0000000000000009 0000000000182bd9Sep 23 16:14:14 quasimodo kernel: r08-11 00000000001f4a00 00000000405ee948 00000000faf03590 00000000faf034c8Sep 23 16:14:14 quasimodo kernel: r12-15 0000000000000008 00000000000689f0 0000000060000000 00000000000629f0Sep 23 16:14:14 quasimodo kernel: r16-19 00000000000629f0 00000000000000c8 00000000000699f0 00000000405ee948Sep 23 16:14:14 quasimodo kernel: r20-23 0000000000000002 0000000000000000 0000000000182bd9 00000000faf03590Sep 23 16:14:14 quasimodo kernel: r24-27 0000000000000009 0000000000182bd0 00000000001f4a00 00000000000629f0Sep 23 16:14:14 quasimodo kernel: r28-31 0000000000000003 00000000405f3948 00000000faf036c0 000000004049b817Sep 23 16:14:14 quasimodo kernel: sr0-3 0000000000000f00 0000000000000f00 0000000000000000 0000000000000f00Sep 23 16:14:14 quasimodo kernel: sr4-7 0000000000000f00 0000000000000f00 0000000000000f00 0000000000000f00Sep 23 16:14:14 quasimodo kernel: Sep 23 16:14:14 quasimodo kernel: IASQ: 0000000000000f00 0000000000000f00 IAOQ: 00000000404c3caf 00000000404c3cb3Sep 23 16:14:14 quasimodo kernel: IIR: 0eb42084 ISR: 0000000000000f00 IOR: 0000000000000008Sep 23 16:14:14 quasimodo kernel: CPU: 0 CR30: 0000000017dbc000 CR31: 0000000010508000Sep 23 16:14:14 quasimodo kernel: ORIG_R28: 0000000040307254 From davem@redhat.com Fri Sep 26 02:08:48 2003 From: davem@redhat.com (David S. Miller) Date: Thu, 25 Sep 2003 18:08:48 -0700 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030925142623.GO13172@parcelfarce.linux.theplanet.co.uk> References: <20030925105005.GX16872@tausq.org> <000801c38356$dea5cda0$e5624c0f@india.hp.com> <20030925142623.GO13172@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030925180848.2763911b.davem@redhat.com> On Thu, 25 Sep 2003 15:26:23 +0100 Matthew Wilcox wrote: > I think you're right. flush_dcache_page is for page cache pages, not for > random user addresses. Would something like this make sense? The flush_dcache_page() is needed in case the platform has deferred the flushing for a kernel cpu store to a page cache page. You cannot just delete this call and replace it with a flush_cache_range() call, that simply won't work. From Randolph Chung Fri Sep 26 08:03:29 2003 From: Randolph Chung (Randolph Chung) Date: Fri, 26 Sep 2003 00:03:29 -0700 Subject: [parisc-linux] kernel error message. In-Reply-To: <35989.192.168.66.99.1064533174.squirrel@www.zinkens.net> References: <35989.192.168.66.99.1064533174.squirrel@www.zinkens.net> Message-ID: <20030926070329.GA12671@tausq.org> In reference to a message from mlist@zinkens.net, dated Sep 26: > i keep getting about ten a day of these messages in the /var/log/kern.log > file. can anyone tell me whats going on, and point me in the right > direction to fix it? thanks. > some info on my hard/software: Your apache is crashing randomly :( I think mkp said he was seeing this problem as well and was trying to debug it. thanks, randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ From santosh.abraham@hp.com Fri Sep 26 11:42:07 2003 From: santosh.abraham@hp.com (Santosh Abraham) Date: Fri, 26 Sep 2003 16:12:07 +0530 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030925142623.GO13172@parcelfarce.linux.theplanet.co.uk> Message-ID: <001201c3841a$d5be9900$e5624c0f@india.hp.com> A call to flush_cache_range(), before the call to flush_dcache_page () would fix the problem. I tested this a couple of days back, but called flush_user_dcache_range () instead of flush_cache_range(), and our apps seemed to work fine. flush_cache_range () calls flush_user_dcache_range () internally. (i am aware that flush_user_dcache_range () is not an exported interface, but I urgently needed to get our apps working ). Would the following be acceptable ? ------------------------------------------------------------------------ *** mm/memory.c.orig Fri Nov 29 07:51:13 2002 --- mm/memory.c Fri Sep 26 15:56:02 2003 *************** *** 570,578 **** } iobuf->nr_pages = err; while (pgcount--) { ! /* FIXME: flush superflous for rw==READ, ! * probably wrong function for rw==WRITE */ flush_dcache_page(iobuf->maplist[pgcount]); } dprintk ("map_user_kiobuf: end OK\n"); --- 570,595 ---- } iobuf->nr_pages = err; while (pgcount--) { ! struct page *page; ! ! page = iobuf->maplist[pgcount]; ! ! /* ! * flush_dcache_page () calls flush_cache_page () internally ! * in certain cases. This check is an attempt to avoid ! * spurious cache flushes. */ + + if (!page->mapping) { + unsigned long start = va + (pgcount * PAGE_SIZE); + unsigned long end = va + ((pgcount+1) * PAGE_SIZE); + + /* Strictly not necessary, perhaps ? */ + if (end > va+len) { + end = va+len; + } + flush_cache_range (mm, start, end); + } flush_dcache_page(iobuf->maplist[pgcount]); ----------------------------------------------------------------------- Does the order of the calls to flush_cache_range ()/flush_dcache_page() matter ? Also, what would be the effect on other platforms ? -----Original Message----- From: willy@www.linux.org.uk [mailto:willy@www.linux.org.uk]On Behalf Of Matthew Wilcox Sent: Thursday, September 25, 2003 7:56 PM To: santosh.abraham@hp.com Cc: 'Randolph Chung'; parisc-linux@lists.parisc-linux.org; Stephen C. Tweedie; David S. Miller Subject: Re: [parisc-linux] Fwd: Problems with raw interface. On Thu, Sep 25, 2003 at 04:49:21PM +0530, Santosh Abraham wrote: > > hmm.. why is map_user_kiobuf () calling flush_dcache_page () then ? > should it not be calling flush_cache_{range,page} ? > > map_user_kiobuf () called from the raw I/O path should ,in the > write case, be flushing user data out, so that its visible to > the kernel VA. I think you're right. flush_dcache_page is for page cache pages, not for random user addresses. Would something like this make sense? Index: mm/memory.c =================================================================== RCS file: /var/cvs/linux-2.4/mm/memory.c,v retrieving revision 1.24 diff -u -p -r1.24 memory.c --- linux-2.4/mm/memory.c 29 Nov 2002 02:21:13 -0000 1.24 +++ linux-2.4/mm/memory.c 25 Sep 2003 14:22:42 -0000 @@ -569,12 +569,7 @@ int map_user_kiobuf(int rw, struct kiobu return err; } iobuf->nr_pages = err; - while (pgcount--) { - /* FIXME: flush superflous for rw==READ, - * probably wrong function for rw==WRITE - */ - flush_dcache_page(iobuf->maplist[pgcount]); - } + flush_cache_range(mm, va, va + len); dprintk ("map_user_kiobuf: end OK\n"); return 0; } I deleted the comment because it's not correct ;-) The kernel is about to access these pages. Any existing cache for the contents of those pages must now be invalidated if the kernel's about to write to it, and must be written back if the kernel's about to read from it. flush_cache_range() must already have these properties otherwise munmap() wouldn't work. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From davem@redhat.com Fri Sep 26 11:34:58 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 26 Sep 2003 03:34:58 -0700 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <001201c3841a$d5be9900$e5624c0f@india.hp.com> References: <20030925142623.GO13172@parcelfarce.linux.theplanet.co.uk> <001201c3841a$d5be9900$e5624c0f@india.hp.com> Message-ID: <20030926033458.68dbb768.davem@redhat.com> 1) Please use unified diffs when you post patches. 2) If you insist on using Microsoft Outlook when posting patches at least configure it properly when doing so. By default it is going to turn tabs into spaces and that makes the patch corrupt and unusable by anyone. 2) Your patch is unacceptable because it is taking advantage of internal implementation details of flush_dcache_page() on parisc64 that might not (and in fact, is not) be true on other platforms. From willy@debian.org Fri Sep 26 12:24:00 2003 From: willy@debian.org (Matthew Wilcox) Date: Fri, 26 Sep 2003 12:24:00 +0100 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030925180848.2763911b.davem@redhat.com> References: <20030925105005.GX16872@tausq.org> <000801c38356$dea5cda0$e5624c0f@india.hp.com> <20030925142623.GO13172@parcelfarce.linux.theplanet.co.uk> <20030925180848.2763911b.davem@redhat.com> Message-ID: <20030926112400.GA24824@parcelfarce.linux.theplanet.co.uk> On Thu, Sep 25, 2003 at 06:08:48PM -0700, David S. Miller wrote: > On Thu, 25 Sep 2003 15:26:23 +0100 > Matthew Wilcox wrote: > > > I think you're right. flush_dcache_page is for page cache pages, not for > > random user addresses. Would something like this make sense? > > The flush_dcache_page() is needed in case the platform has deferred > the flushing for a kernel cpu store to a page cache page. But this isn't a page cache page. > You cannot just delete this call and replace it with a flush_cache_range() > call, that simply won't work. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From davem@redhat.com Fri Sep 26 12:20:29 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 26 Sep 2003 04:20:29 -0700 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030926112400.GA24824@parcelfarce.linux.theplanet.co.uk> References: <20030925105005.GX16872@tausq.org> <000801c38356$dea5cda0$e5624c0f@india.hp.com> <20030925142623.GO13172@parcelfarce.linux.theplanet.co.uk> <20030925180848.2763911b.davem@redhat.com> <20030926112400.GA24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030926042029.1cdd77e9.davem@redhat.com> On Fri, 26 Sep 2003 12:24:00 +0100 Matthew Wilcox wrote: > On Thu, Sep 25, 2003 at 06:08:48PM -0700, David S. Miller wrote: > > The flush_dcache_page() is needed in case the platform has deferred > > the flushing for a kernel cpu store to a page cache page. > > But this isn't a page cache page. Are you sure? Isn't raw I/O allowed on user buffers backed by some kind of file based mmap()? From santosh.abraham@hp.com Fri Sep 26 12:47:34 2003 From: santosh.abraham@hp.com (Santosh Abraham) Date: Fri, 26 Sep 2003 17:17:34 +0530 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030926112400.GA24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <001801c38423$fb443960$e5624c0f@india.hp.com> The flush_dcache_page () might be required in cases when the same user buffer is being used for both reads and writes in an alternating fashion, right ? -----Original Message----- From: willy@www.linux.org.uk [mailto:willy@www.linux.org.uk]On Behalf Of Matthew Wilcox Sent: Friday, September 26, 2003 4:54 PM To: David S. Miller Cc: Matthew Wilcox; santosh.abraham@hp.com; randolph@tausq.org; parisc-linux@lists.parisc-linux.org; sct@redhat.com Subject: Re: [parisc-linux] Fwd: Problems with raw interface. On Thu, Sep 25, 2003 at 06:08:48PM -0700, David S. Miller wrote: > On Thu, 25 Sep 2003 15:26:23 +0100 > Matthew Wilcox wrote: > > > I think you're right. flush_dcache_page is for page cache pages, not for > > random user addresses. Would something like this make sense? > > The flush_dcache_page() is needed in case the platform has deferred > the flushing for a kernel cpu store to a page cache page. But this isn't a page cache page. > You cannot just delete this call and replace it with a flush_cache_range() > call, that simply won't work. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From sct@redhat.com Fri Sep 26 12:57:01 2003 From: sct@redhat.com (Stephen C. Tweedie) Date: 26 Sep 2003 12:57:01 +0100 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030926042029.1cdd77e9.davem@redhat.com> References: <20030925105005.GX16872@tausq.org> <000801c38356$dea5cda0$e5624c0f@india.hp.com> <20030925142623.GO13172@parcelfarce.linux.theplanet.co.uk> <20030925180848.2763911b.davem@redhat.com> <20030926112400.GA24824@parcelfarce.linux.theplanet.co.uk> <20030926042029.1cdd77e9.davem@redhat.com> Message-ID: <1064577420.4227.0.camel@sisko.scot.redhat.com> Hi, On Fri, 2003-09-26 at 12:20, David S. Miller wrote: > Are you sure? Isn't raw I/O allowed on user buffers backed by > some kind of file based mmap()? Yes, it is. --Stephen From davem@redhat.com Fri Sep 26 12:48:41 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 26 Sep 2003 04:48:41 -0700 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <1064577420.4227.0.camel@sisko.scot.redhat.com> References: <20030925105005.GX16872@tausq.org> <000801c38356$dea5cda0$e5624c0f@india.hp.com> <20030925142623.GO13172@parcelfarce.linux.theplanet.co.uk> <20030925180848.2763911b.davem@redhat.com> <20030926112400.GA24824@parcelfarce.linux.theplanet.co.uk> <20030926042029.1cdd77e9.davem@redhat.com> <1064577420.4227.0.camel@sisko.scot.redhat.com> Message-ID: <20030926044841.29ecb672.davem@redhat.com> On 26 Sep 2003 12:57:01 +0100 "Stephen C. Tweedie" wrote: > On Fri, 2003-09-26 at 12:20, David S. Miller wrote: > > > Are you sure? Isn't raw I/O allowed on user buffers backed by > > some kind of file based mmap()? > > Yes, it is. So there we go, that's how page can be a page cache page Matthew. From santosh.abraham@hp.com Fri Sep 26 13:12:29 2003 From: santosh.abraham@hp.com (Santosh Abraham) Date: Fri, 26 Sep 2003 17:42:29 +0530 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030926033458.68dbb768.davem@redhat.com> Message-ID: <001b01c38427$76328840$e5624c0f@india.hp.com> Apologies for 1) & 2). I guess ignorance is not bliss or excusable, is it :) As for 3) i agree that there are issues, but what are the alternatives we have ? Assuming that you agree that we need to call flush_cache_range ( ) to fix the issue. 1) Call flush_cache_range () directly before the call to flush_dcache_page (). But this could impact other architectures too, right ? 2) Modify flush_dcache_page () in asm-parisc/pgalloc.h to handle this. But this is not easy cause we do not pass the user VA in flush_dcache_page (). -----Original Message----- From: David S. Miller [mailto:davem@redhat.com] Sent: Friday, September 26, 2003 4:05 PM To: santosh.abraham@hp.com Cc: santosha@india.hp.com; willy@debian.org; randolph@tausq.org; parisc-linux@lists.parisc-linux.org; sct@redhat.com Subject: Re: [parisc-linux] Fwd: Problems with raw interface. 1) Please use unified diffs when you post patches. 2) If you insist on using Microsoft Outlook when posting patches at least configure it properly when doing so. By default it is going to turn tabs into spaces and that makes the patch corrupt and unusable by anyone. 3) Your patch is unacceptable because it is taking advantage of internal implementation details of flush_dcache_page() on parisc64 that might not (and in fact, is not) be true on other platforms. From willy@debian.org Fri Sep 26 13:20:23 2003 From: willy@debian.org (Matthew Wilcox) Date: Fri, 26 Sep 2003 13:20:23 +0100 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030926044841.29ecb672.davem@redhat.com> References: <20030925105005.GX16872@tausq.org> <000801c38356$dea5cda0$e5624c0f@india.hp.com> <20030925142623.GO13172@parcelfarce.linux.theplanet.co.uk> <20030925180848.2763911b.davem@redhat.com> <20030926112400.GA24824@parcelfarce.linux.theplanet.co.uk> <20030926042029.1cdd77e9.davem@redhat.com> <1064577420.4227.0.camel@sisko.scot.redhat.com> <20030926044841.29ecb672.davem@redhat.com> Message-ID: <20030926122023.GH24824@parcelfarce.linux.theplanet.co.uk> On Fri, Sep 26, 2003 at 04:48:41AM -0700, David S. Miller wrote: > On 26 Sep 2003 12:57:01 +0100 > "Stephen C. Tweedie" wrote: > > > On Fri, 2003-09-26 at 12:20, David S. Miller wrote: > > > > > Are you sure? Isn't raw I/O allowed on user buffers backed by > > > some kind of file based mmap()? > > > > Yes, it is. > > So there we go, that's how page can be a page cache page Matthew. OK, so it *might* be a page cache page, but isn't necessarily. So we need to call *both* flush_dcache_page() and flush_cache_range(), right? -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From davem@redhat.com Fri Sep 26 13:38:05 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 26 Sep 2003 05:38:05 -0700 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030926122023.GH24824@parcelfarce.linux.theplanet.co.uk> References: <20030925105005.GX16872@tausq.org> <000801c38356$dea5cda0$e5624c0f@india.hp.com> <20030925142623.GO13172@parcelfarce.linux.theplanet.co.uk> <20030925180848.2763911b.davem@redhat.com> <20030926112400.GA24824@parcelfarce.linux.theplanet.co.uk> <20030926042029.1cdd77e9.davem@redhat.com> <1064577420.4227.0.camel@sisko.scot.redhat.com> <20030926044841.29ecb672.davem@redhat.com> <20030926122023.GH24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030926053805.63bda07a.davem@redhat.com> On Fri, 26 Sep 2003 13:20:23 +0100 Matthew Wilcox wrote: > OK, so it *might* be a page cache page, but isn't necessarily. So we > need to call *both* flush_dcache_page() and flush_cache_range(), right? I'm starting to think that flush_dcache_page() needs to take care of this. Santosh remarked that flush_dcache_page() doesn't get the user virtual address, but that is not needed. From the page you can walk the mmap()s and flush the mapping in each address space it is contained within. And you absolutely must flush each address space, not just the one currently doing the raw I/O request. In that light, doing a flush_cache_range() with a specific VMA (2.6.x) or MM (2.4.x) is totally illogical here. From santosha@india.hp.com Fri Sep 26 14:11:41 2003 From: santosha@india.hp.com (SANTOSH ABRAHAM) Date: Fri, 26 Sep 2003 18:41:41 +0530 (IST) Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030926053805.63bda07a.davem@redhat.com> from "David S. Miller" at Sep "26," 2003 "05:38:05" am Message-ID: <200309261311.SAA27414@redsea.india.hp.com> > On Fri, 26 Sep 2003 13:20:23 +0100 > Matthew Wilcox wrote: > > > OK, so it *might* be a page cache page, but isn't necessarily. So we > > need to call *both* flush_dcache_page() and flush_cache_range(), right? > > I'm starting to think that flush_dcache_page() needs to take care > of this. > > Santosh remarked that flush_dcache_page() doesn't get the user virtual > address, but that is not needed. From the page you can walk the mmap()s > and flush the mapping in each address space it is contained within. Are you talking about the page->mapping->{i_mmap_shared, i_mmap} lists ? If so, this is already handled in __flush_dcache_page (). The problem in this case is page->mapping is NULL. > > And you absolutely must flush each address space, not just the one currently > doing the raw I/O request. > > In that light, doing a flush_cache_range() with a specific VMA (2.6.x) > or MM (2.4.x) is totally illogical here. > From davem@redhat.com Fri Sep 26 13:56:52 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 26 Sep 2003 05:56:52 -0700 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <200309261311.SAA27414@redsea.india.hp.com> References: <20030926053805.63bda07a.davem@redhat.com> <200309261311.SAA27414@redsea.india.hp.com> Message-ID: <20030926055652.32ddbbc2.davem@redhat.com> On Fri, 26 Sep 2003 18:41:41 +0530 (IST) SANTOSH ABRAHAM wrote: > The problem in this case is page->mapping is NULL. When page->mapping is NULL, flush_dcache_page() should purge the page (by physical addres) from it's caches. This is what sparc64 does. Flushing just the current address space is incorrect, so don't get the fancy idea to pass the 'mm' and 'va' into flush_dcache_page(). From willy@debian.org Fri Sep 26 14:29:01 2003 From: willy@debian.org (Matthew Wilcox) Date: Fri, 26 Sep 2003 14:29:01 +0100 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030926055652.32ddbbc2.davem@redhat.com> References: <20030926053805.63bda07a.davem@redhat.com> <200309261311.SAA27414@redsea.india.hp.com> <20030926055652.32ddbbc2.davem@redhat.com> Message-ID: <20030926132901.GJ24824@parcelfarce.linux.theplanet.co.uk> On Fri, Sep 26, 2003 at 05:56:52AM -0700, David S. Miller wrote: > On Fri, 26 Sep 2003 18:41:41 +0530 (IST) > SANTOSH ABRAHAM wrote: > > > The problem in this case is page->mapping is NULL. > > When page->mapping is NULL, flush_dcache_page() should purge the page > (by physical addres) from it's caches. This is what sparc64 does. But you can't do that on PA-RISC. You can only purge virtual addresses. > Flushing just the current address space is incorrect, so don't get the > fancy idea to pass the 'mm' and 'va' into flush_dcache_page(). -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From davem@redhat.com Fri Sep 26 14:21:43 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 26 Sep 2003 06:21:43 -0700 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030926132901.GJ24824@parcelfarce.linux.theplanet.co.uk> References: <20030926053805.63bda07a.davem@redhat.com> <200309261311.SAA27414@redsea.india.hp.com> <20030926055652.32ddbbc2.davem@redhat.com> <20030926132901.GJ24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030926062143.20d85a72.davem@redhat.com> On Fri, 26 Sep 2003 14:29:01 +0100 Matthew Wilcox wrote: > On Fri, Sep 26, 2003 at 05:56:52AM -0700, David S. Miller wrote: > > When page->mapping is NULL, flush_dcache_page() should purge the page > > (by physical addres) from it's caches. This is what sparc64 does. > > But you can't do that on PA-RISC. You can only purge virtual addresses. Then for page->mapping == NULL your flush_dcache_page() is not doing what it is supposed to, and you can expect problems extending further than this raw I/O case. You have to find a way to walk all the address spaces to figure out where the page is mapped. If you just put a flush_cache_range() there, you may get your current test working but that code is wrong. It will be wrong in any case where the page is mapped to anywhere other then this mapping in this address space. The real problem for you guys is that in 2.4.x there is no easy way to go from a page to it's mapping regardless of what kind of page it is. That's what you need to rectify somehow. From wmglo@dent.med.uni-muenchen.de Fri Sep 26 14:39:54 2003 From: wmglo@dent.med.uni-muenchen.de (wmglo@dent.med.uni-muenchen.de) Date: 26 Sep 2003 13:39:54 -0000 Subject: [parisc-linux] Re: [RFC] Where to put arch-dependant locking in malloc/thread-m.h In-Reply-To: <20030925211509.GY14406@systemhalted> (carlos@baldric.uwo.ca) References: <20030925211509.GY14406@systemhalted> Message-ID: <20030926133954.12328.qmail@md.dent.med.uni-muenchen.de> Hi, > The following patch fixes the issue, but I'm not content about it's > placement in malloc/thread-m.h. Any comments about where I might put > this in order to make maintenance easier? Ok, I have become convinced it is best to move thread-m.h into sysdeps. We should rename it, too (my suggestion: malloc-machine.h), and make sure that one can put e.g. #define DEFAULT_MMAP_THRESHOLD (256*1024) in there and have it reflected in malloc. I'll send a patch for this tomorrow. Regards, Wolfram. From lottolaprimitiva@starspath.com Fri Sep 26 15:09:06 2003 From: lottolaprimitiva@starspath.com (lottolaprimitiva@starspath.com) Date: Fri, 26 Sep 2003 16:09:06 +0200 Subject: [parisc-linux] WINNING NOTIFICATION: Message-ID: <20030926140850.91A1F483E@dsl2.external.hp.com> LOTTERY LA PRIMITIVA. C/BUSMAN EL BUENO,137 MADRID - ESPANA. TEL: +34-620-038-455 FAX:-+34-665 048 681. FROM: THE DESK OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: LP/26510460037/02 BATCH: 24/00319/IPD DEAR SIR, RE: AWARD NOTIFICATION FINAL NOTICE We are pleased to inform you of the announcement, of winners of the LOTTERY PRIMITIVSWEEPSTAKES/INTERNATIONAL PROGRAMS held on 6 AUGUST,2003. Your name is attached to ticket number 004-05117963-198, with serial number 99375 drew the lucky numbers 15-23-24-26-33-47, and consequently won the lottery in the 3rd category.You have therefore been approved for a lump sum pay out of EUROS647,828.87 Thousand in cash credited to file No:LP/26510460037/02.This is from total prize money of EUROS 80,400,000.00 shared among the twenty two international winners in this category. All participants were selected through a computer ballot system drawn form 25,000 names from Australia,New Zealand, America,Europe,North America and Asia as part of International Promotions Program,which is conducted annually. CONGRATULATIONS!!! Your fund is now insured to your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of your prize, you will participate in our end of year high stakes Euros1.1 billion International Lottery. To begin your claim, please contact your claims agent,PACIFIC-SECURITAS FOREIGN OPERATION MANAGERS ATTN:MR.JUAN GARCIA.,Email; :pacificsecs@whipmail.com). For processing and remittance of your prize money to a designated account with our bankers. Remember, all prize money must be claimed not later than 30th October ,2003. After this date, all funds will be returned as unclaimed. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every one of your correspondences with your agent. Furthermore, should there be any change of your address,do inform your claims agent as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions programm Sincerely, JUAN . GARCIA. From willy@debian.org Fri Sep 26 15:09:48 2003 From: willy@debian.org (Matthew Wilcox) Date: Fri, 26 Sep 2003 15:09:48 +0100 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030926062143.20d85a72.davem@redhat.com> References: <20030926053805.63bda07a.davem@redhat.com> <200309261311.SAA27414@redsea.india.hp.com> <20030926055652.32ddbbc2.davem@redhat.com> <20030926132901.GJ24824@parcelfarce.linux.theplanet.co.uk> <20030926062143.20d85a72.davem@redhat.com> Message-ID: <20030926140948.GK24824@parcelfarce.linux.theplanet.co.uk> On Fri, Sep 26, 2003 at 06:21:43AM -0700, David S. Miller wrote: > On Fri, 26 Sep 2003 14:29:01 +0100 > Matthew Wilcox wrote: > > > On Fri, Sep 26, 2003 at 05:56:52AM -0700, David S. Miller wrote: > > > When page->mapping is NULL, flush_dcache_page() should purge the page > > > (by physical addres) from it's caches. This is what sparc64 does. > > > > But you can't do that on PA-RISC. You can only purge virtual addresses. > > Then for page->mapping == NULL your flush_dcache_page() is not doing > what it is supposed to, and you can expect problems extending further > than this raw I/O case. Oh, come on, Dave. You just changed the definition of flush_dcache_page(). You can't claim the implementation isn't doing what it's supposed to! The definition in cachetlb talks *only* about page cache pages. > You have to find a way to walk all the address spaces to figure out > where the page is mapped. That's ridiculous. For a start, pages can't be mapped into multiple address spaces without being in the page cache. Second, we already know where it is, you just refuse to pass that information in. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From davem@redhat.com Fri Sep 26 15:04:50 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 26 Sep 2003 07:04:50 -0700 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030926140948.GK24824@parcelfarce.linux.theplanet.co.uk> References: <20030926053805.63bda07a.davem@redhat.com> <200309261311.SAA27414@redsea.india.hp.com> <20030926055652.32ddbbc2.davem@redhat.com> <20030926132901.GJ24824@parcelfarce.linux.theplanet.co.uk> <20030926062143.20d85a72.davem@redhat.com> <20030926140948.GK24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030926070450.603c5c33.davem@redhat.com> On Fri, 26 Sep 2003 15:09:48 +0100 Matthew Wilcox wrote: > > You have to find a way to walk all the address spaces to figure out > > where the page is mapped. > > That's ridiculous. For a start, pages can't be mapped into multiple > address spaces without being in the page cache. How in the world can anonymous pages work then? Of course anonymous pages can be in multiple address spaces without being in the page cache. From carlos@baldric.uwo.ca Fri Sep 26 15:24:08 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Fri, 26 Sep 2003 10:24:08 -0400 Subject: [parisc-linux] Re: [RFC] Where to put arch-dependant locking in malloc/thread-m.h In-Reply-To: <20030926133954.12328.qmail@md.dent.med.uni-muenchen.de> References: <20030925211509.GY14406@systemhalted> <20030926133954.12328.qmail@md.dent.med.uni-muenchen.de> Message-ID: <20030926142408.GZ14406@systemhalted> On Fri, Sep 26, 2003 at 01:39:54PM -0000, wmglo@dent.med.uni-muenchen.de wrote: > > The following patch fixes the issue, but I'm not content about it's > > placement in malloc/thread-m.h. Any comments about where I might put > > this in order to make maintenance easier? > > Ok, I have become convinced it is best to move thread-m.h into > sysdeps. We should rename it, too (my suggestion: malloc-machine.h), > and make sure that one can put e.g. > > #define DEFAULT_MMAP_THRESHOLD (256*1024) > > in there and have it reflected in malloc. > > I'll send a patch for this tomorrow. Thank you. Sounds like the best solution in this case. c. From sct@redhat.com Fri Sep 26 15:26:36 2003 From: sct@redhat.com (Stephen C. Tweedie) Date: 26 Sep 2003 15:26:36 +0100 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030926140948.GK24824@parcelfarce.linux.theplanet.co.uk> References: <20030926053805.63bda07a.davem@redhat.com> <200309261311.SAA27414@redsea.india.hp.com> <20030926055652.32ddbbc2.davem@redhat.com> <20030926132901.GJ24824@parcelfarce.linux.theplanet.co.uk> <20030926062143.20d85a72.davem@redhat.com> <20030926140948.GK24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <1064586395.4227.154.camel@sisko.scot.redhat.com> Hi, On Fri, 2003-09-26 at 15:09, Matthew Wilcox wrote: > That's ridiculous. For a start, pages can't be mapped into multiple > address spaces without being in the page cache. fork(). At least we know the pages aren't dirty or writable in that case, though. But because of sys_mremap(), we don't know the VA for all possible mappings, and the pages are _not_ necessarily in the page cache. There's only one place where anon pages get into the page cache, and that's via swap cache. Note that we don't have to worry about kernel-context access to such pages: the contents are only ever seen from user-space process context. The fork case still means there are multiple such referencing contexts, though. --Stephen From willy@debian.org Fri Sep 26 15:30:52 2003 From: willy@debian.org (Matthew Wilcox) Date: Fri, 26 Sep 2003 15:30:52 +0100 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030926070450.603c5c33.davem@redhat.com> References: <20030926053805.63bda07a.davem@redhat.com> <200309261311.SAA27414@redsea.india.hp.com> <20030926055652.32ddbbc2.davem@redhat.com> <20030926132901.GJ24824@parcelfarce.linux.theplanet.co.uk> <20030926062143.20d85a72.davem@redhat.com> <20030926140948.GK24824@parcelfarce.linux.theplanet.co.uk> <20030926070450.603c5c33.davem@redhat.com> Message-ID: <20030926143052.GL24824@parcelfarce.linux.theplanet.co.uk> On Fri, Sep 26, 2003 at 07:04:50AM -0700, David S. Miller wrote: > On Fri, 26 Sep 2003 15:09:48 +0100 > Matthew Wilcox wrote: > > > > You have to find a way to walk all the address spaces to figure out > > > where the page is mapped. > > > > That's ridiculous. For a start, pages can't be mapped into multiple > > address spaces without being in the page cache. > > How in the world can anonymous pages work then? Of course anonymous > pages can be in multiple address spaces without being in the page > cache. How? By fork()? If so, that's not a problem -- the pages stay at the same address in both processes, and flushing one will flush any inherited pages. Otherwise you'll have to be more explicit. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From davem@redhat.com Fri Sep 26 15:20:59 2003 From: davem@redhat.com (David S. Miller) Date: Fri, 26 Sep 2003 07:20:59 -0700 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030926143052.GL24824@parcelfarce.linux.theplanet.co.uk> References: <20030926053805.63bda07a.davem@redhat.com> <200309261311.SAA27414@redsea.india.hp.com> <20030926055652.32ddbbc2.davem@redhat.com> <20030926132901.GJ24824@parcelfarce.linux.theplanet.co.uk> <20030926062143.20d85a72.davem@redhat.com> <20030926140948.GK24824@parcelfarce.linux.theplanet.co.uk> <20030926070450.603c5c33.davem@redhat.com> <20030926143052.GL24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030926072059.0447b074.davem@redhat.com> On Fri, 26 Sep 2003 15:30:52 +0100 Matthew Wilcox wrote: > On Fri, Sep 26, 2003 at 07:04:50AM -0700, David S. Miller wrote: > > On Fri, 26 Sep 2003 15:09:48 +0100 > > Matthew Wilcox wrote: > > > > > > You have to find a way to walk all the address spaces to figure out > > > > where the page is mapped. > > > > > > That's ridiculous. For a start, pages can't be mapped into multiple > > > address spaces without being in the page cache. > > > > How in the world can anonymous pages work then? Of course anonymous > > pages can be in multiple address spaces without being in the page > > cache. > > How? By fork()? If so, that's not a problem -- the pages stay at the same > address in both processes, and flushing one will flush any inherited pages. > Otherwise you'll have to be more explicit. Any page can be mremap()'d to any other address. You really do have to walk all the address spaces to sufficiently tap the page out of the caches. Unfortunately, this is only easy in 2.6.x :( From sct@redhat.com Fri Sep 26 15:42:07 2003 From: sct@redhat.com (Stephen C. Tweedie) Date: 26 Sep 2003 15:42:07 +0100 Subject: [parisc-linux] Fwd: Problems with raw interface. In-Reply-To: <20030926072059.0447b074.davem@redhat.com> References: <20030926053805.63bda07a.davem@redhat.com> <200309261311.SAA27414@redsea.india.hp.com> <20030926055652.32ddbbc2.davem@redhat.com> <20030926132901.GJ24824@parcelfarce.linux.theplanet.co.uk> <20030926062143.20d85a72.davem@redhat.com> <20030926140948.GK24824@parcelfarce.linux.theplanet.co.uk> <20030926070450.603c5c33.davem@redhat.com> <20030926143052.GL24824@parcelfarce.linux.theplanet.co.uk> <20030926072059.0447b074.davem@redhat.com> Message-ID: <1064587327.4227.175.camel@sisko.scot.redhat.com> Hi, On Fri, 2003-09-26 at 15:20, David S. Miller wrote: > Any page can be mremap()'d to any other address. Yep. At least this case is rare, and you can optimise for the simple case by checking page->count. But the general case really does need to be covered if you're going to be fully correct for all cases. And with O_DIRECT being an unprivileged operation, users have the ability to expose this problem quite easily. Cheers, Stephen From soete.joel@tiscali.be Fri Sep 26 16:46:35 2003 From: soete.joel@tiscali.be (Joel Soete) Date: Fri, 26 Sep 2003 17:46:35 +0200 Subject: [parisc-linux] N Class SMP pb ? (follow up) Message-ID: <3F704CAF00001DCF@ocpmta2.freegates.net> >Yes - 6 is ITLB miss and 15 is Data TLB miss. ... > >> handle_interruption(26, ...). > >26 is "Data Memory Access rights Trap". >This sounds normal for Copy-On-Write. Yes to be sure I just finished to logon a b2k with same kernel (excepted pdc support but I already verify it doesn't make any difference in the crash in smp on the N) and effectively it is normal to read many 6, 15 and 26 interruptions. >> SMP CALL FUNCTION TIMED OUT (CPU=1) > >The IPI handler will time out if the other CPU doesn't ack >the function call with in a second. This is bad. OTC This is the better messages I never get to start an analyse of this crash :)) >It means either other CPU never got the interrupt (locked up >with I-bit off) or the "unstarted_count" isn't coherent between the CPUs. hmm how could I verify this hypothesis? >> >> Could this be a pb with sync between cpu time ref? >> (because timeout = jiffies + HZ) > >I don't think so since jiffies is a global. >And it's always be measured on the same CPU. Ok > >> I have also a look for where this function is called but never see its return >> code tested to launch a 'stack dump' and a stop of system? > >You need to find out who is using smp_call_function() and which function >they are trying to invoke. I suspect it's coming from mm/slab.c but >would know which of the three it might be. Effectively I don't find another place where it is called. And so add a printk in each function calling smp_call_function_all_cpus() finaly. That is allowing me to notice severall call to kmem_tune_cpucache() (7 exactly) (and not other) but don't get any more 'SMP CALL FUNCTION TIMED OUT (CPU=1)' :( (i presume that, as previously, the system crash before having the opportunity to flush its buffer?) What do you think? Thanks a lot for help, Joel ------------------------------------------------------------------------- L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr From soete.joel@tiscali.be Fri Sep 26 17:08:29 2003 From: soete.joel@tiscali.be (Joel Soete) Date: Fri, 26 Sep 2003 18:08:29 +0200 Subject: [parisc-linux] N Class SMP pb ? (follow up) In-Reply-To: <3F704CAF00001DCF@ocpmta2.freegates.net> Message-ID: <3F704CAF00001DEB@ocpmta2.freegates.net> > >That is allowing me to notice severall call to kmem_tune_cpucache() (7 exactly) >(and not other) but don't get any more 'SMP CALL FUNCTION TIMED OUT (CPU=1)' >:( >(i presume that, as previously, the system crash before having the opportun >ty to flush its buffer?) btw: does it exists some tips to flush buffer before all (or not buffering console ouput)? ------------------------------------------------------------------------- L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr From grundler@parisc-linux.org Fri Sep 26 17:41:39 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 26 Sep 2003 10:41:39 -0600 Subject: [parisc-linux] kernel error message. In-Reply-To: <20030926070329.GA12671@tausq.org> References: <35989.192.168.66.99.1064533174.squirrel@www.zinkens.net> <20030926070329.GA12671@tausq.org> Message-ID: <20030926164139.GA11759@dsl2.external.hp.com> On Fri, Sep 26, 2003 at 12:03:29AM -0700, Randolph Chung wrote: > Your apache is crashing randomly :( I think mkp said he was seeing this > problem as well and was trying to debug it. I haven't been seeing that with either apache or apache2. On a500 (64-bit, 2.4.21-pa6) running testing: ii apache 1.3.27.0-2 Versatile, high-performance HTTP server On c3k (32-bit, 2.4.22-pa7) running testing: ii apache2-common 2.0.47-1 Next generation, scalable, extendable web se ii apache2-mpm-pr 2.0.47-1 Traditional model for Apache2 Neither is heavily loaded but can see bursts of load at times. hth, grant From grundler@parisc-linux.org Fri Sep 26 17:50:45 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Fri, 26 Sep 2003 10:50:45 -0600 Subject: [parisc-linux] N Class SMP pb ? (follow up) In-Reply-To: <3F704CAF00001DCF@ocpmta2.freegates.net> References: <3F704CAF00001DCF@ocpmta2.freegates.net> Message-ID: <20030926165045.GB11759@dsl2.external.hp.com> On Fri, Sep 26, 2003 at 05:46:35PM +0200, Joel Soete wrote: > >It means either other CPU never got the interrupt (locked up > >with I-bit off) or the "unstarted_count" isn't coherent between the CPUs. > > hmm how could I verify this hypothesis? TOC the machine, "ser pim" and look at PSW in TOC Info for each CPU. bit 0 is the I-Bit IIRC. On second thought, I'm skeptical unstarted_count isn't coherent since it's a kernel global as well (like jiffies). > >You need to find out who is using smp_call_function() and which function > >they are trying to invoke. I suspect it's coming from mm/slab.c but > >would know which of the three it might be. > > Effectively I don't find another place where it is called. And so add a > printk in each function calling smp_call_function_all_cpus() finaly. > > That is allowing me to notice severall call to kmem_tune_cpucache() (7 exactly) > (and not other) but don't get any more 'SMP CALL FUNCTION TIMED OUT (CPU=1)' > :( > (i presume that, as previously, the system crash before having the opportunity > to flush its buffer?) > > What do you think? Could be. Add mdelay(100) (or higher) after the lines of output you've added. The works if it's a functional problem that's not timing dependent. Otherwise setup kernel crash dump and use tools from bruno/phi to view contents of the kernel message buffer. grant From varenet@esiee.fr Fri Sep 26 18:15:29 2003 From: varenet@esiee.fr (=?ISO-8859-1?Q?Thibaut_VAR=C8NE?=) Date: Fri, 26 Sep 2003 19:15:29 +0200 Subject: [parisc-linux] kernel error message. In-Reply-To: <20030926164139.GA11759@dsl2.external.hp.com> Message-ID: <076D6328-F045-11D7-A569-0030656F07A2@esiee.fr> http://pateam.esiee.fr/ has been running apache on 2.4.18-pa45 for=20 years now (see http://uptime.netcraft.com/up/graph/?host=3Dmkhppa1.esiee.fr ) and no problem have ever been experienced... you can check the load on the website... HTH Thibaut VARENE The PA/Linux ESIEE Team http://pateam.esiee.fr/ Le vendredi, 26 sep 2003, =E0 18:41 Europe/Paris, Grant Grundler a =E9crit= : > On Fri, Sep 26, 2003 at 12:03:29AM -0700, Randolph Chung wrote: >> Your apache is crashing randomly :( I think mkp said he was seeing=20 >> this >> problem as well and was trying to debug it. > > I haven't been seeing that with either apache or apache2. > > On a500 (64-bit, 2.4.21-pa6) running testing: > ii apache 1.3.27.0-2 Versatile, high-performance HTTP=20 > server > > On c3k (32-bit, 2.4.22-pa7) running testing: > ii apache2-common 2.0.47-1 Next generation, scalable,=20 > extendable web se > ii apache2-mpm-pr 2.0.47-1 Traditional model for Apache2 > > Neither is heavily loaded but can see bursts of load at times. > > hth, > grant > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > From Sherry Sosa" --_5C.7A5...F6._BCAEAFB3C Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Sophie's Perso= nal Website
Hey! My name's Sophie and I'm just letting you know that I have just la= unched my site full of heaps of sexy pictures and videos of me!! If you want to see a movie of me just click here!

I want to make it big as a model. I hope you think I have what it = takes and maybe you'll be seeing a lot more of me very soon! I really ho= pe you enjoy the video= s!

Click here to see Sophie in action now!
--_5C.7A5...F6._BCAEAFB3C-- From rbradetich@uswest.net Sat Sep 27 04:43:08 2003 From: rbradetich@uswest.net (Ryan Bradetich) Date: Fri, 26 Sep 2003 21:43:08 -0600 Subject: [parisc-linux] zalon/ncr53c720 crashes K460 (parisc port) on bootup. Message-ID: <1064634188.641.27.camel@laptop.bradetich.net> Hello all, The zalon/ncr53c720 combination is fatal during booting on my K460 parisc box. I believe the scsi termination is correct since I performed a fresh debian install on the scsi disks and I can boot from then every time I use a 2.4 kernel :) This problem appeared with with the latest cvs kernel from parisc-linux.org. This system does boot and function when I do not compile zalon support into the kernel and use a nfsroot. I can provide addtional information and test patches (or give access to this system) if requested. Any thoughts or feedback appreciated! Thanks, - Ryan P.S. please copy me on any replies as i am not subscribed to the linux-scsi list. Here is the relevant (I hope) information I copied from the bootup Linux version 2.6.0-test5-pa20 (rbrad@beavis) (gcc version 3.0.3) #34 Fri Sep 26 21:09:34 MDT 2003 zalon_probe: Zalon vers field is 0x1, IRQ 36 ncr53c720-0: rev 0xf on bus 0 device 0 function 0 irq 36 ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential ncr53c720-0: suspicious SCSI data while resetting the BUS. ncr53c720-0: dp1,d15-8,dp0,d7-0,rst,req,ack,bsy,sel,atn,msg,c/d,i/o = 0x3fdff00, expecting 0x100 ncr53c720-0: FATAL ERROR: CHECK SCSI BUS - CABLES, TERMINATION, DEVICE POWER etc.! ncr53c720-0: detaching... Kernel addresses on the stack: [<101227bc>] copy_process+0x714/0xa4c [<10104144>] parisc_terminate+0x60/0xb0 [<1010c264>] pdc_iodc_putc+0x88/0x11c [<101043e0>] handle_interruption+0x24c/0x598 [<1010c264>] pdc_iodc_putc+0x88/0x11c [<10140b40>] do_drain+0x1c/0x2c [<101404c4>] slab_destroy+0x15c/0x208 [<10109088>] intr_check_sig+0x0/0xc [<10140c0c>] __cache_shrink+0x70/0xc4 [<10220640>] ncr_detach+0x0/0x364 [<101238f0>] call_console_drivers+0xac/0x170 [<1015747c>] dentry_open+0x78/0x1b0 [<10123cc8>] release_console_sem+0x64/0x11c [<101573e4>] filp_open+0x4c/0x6c [<10348518>] start_kernel+0x4/0x1b8 [<101e0780>] gsc_alloc_irq+0x38/0x68 [<10358dec>] zalon_probe+0x1b0/0x230 [<1018c548>] sysfs_create+0x94/0xe4 [<1018cf6c>] create_dir+0x80/0xe0 [<1010cc44>] parisc_driver_probe+0x30/0x60 [<101fa208>] bus_match+0x4c/0x80 [<101fa384>] driver_attach+0x88/0xbc [<101fa604>] bus_add_driver+0x98/0xa4 [<1035888c>] tulip_init+0x40/0x74 [<10348744>] do_initcalls+0x64/0xe0 [<1010019c>] init+0x28/0x144 [<10108c5c>] ret_from_kernel_thread+0x1c/0x24 Kernel Fault: Code=26 regs=effb8380 (Addr=00000194) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000011101111111100001111 Not tainted r00-03 00000000 1030a810 10224b2c efffb6e0 r04-07 00000000 efffb688 00000024 10318010 r08-11 efffb600 ffffffed 102f3810 10348518 r12-15 000000f2 000000fa 00000003 f0000d2c r16-19 f0001790 f0000124 f000011c 00000021 r20-23 10315a40 00000021 0000000f 00100100 r24-27 000002c7 103d9380 00000000 102ea010 r28-31 00000000 0000000b effb8380 101415e8 sr0-3 00000000 00000000 00000000 00000000 sr4-7 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: 10224b28 10220640 IIR: 4b5a0328 ISR: 00000000 IOR: 00000194 CPU: 0 CR30: effb8000 CR31: 1033e000 ORIG_R28: 102f3810 IAOQ[0]: ncr53c8xx_release+0xc/0x20 IAOQ[1]: ncr_detach+0x0/0x364 RP(r2): ncr53c8xx_release+0x10/0x20 From willy@debian.org Sat Sep 27 08:48:20 2003 From: willy@debian.org (Matthew Wilcox) Date: Sat, 27 Sep 2003 08:48:20 +0100 Subject: [parisc-linux] zalon/ncr53c720 crashes K460 (parisc port) on bootup. In-Reply-To: <1064634188.641.27.camel@laptop.bradetich.net> References: <1064634188.641.27.camel@laptop.bradetich.net> Message-ID: <20030927074820.GR24824@parcelfarce.linux.theplanet.co.uk> On Fri, Sep 26, 2003 at 09:43:08PM -0600, Ryan Bradetich wrote: > ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential > ncr53c720-0: suspicious SCSI data while resetting the BUS. > ncr53c720-0: dp1,d15-8,dp0,d7-0,rst,req,ack,bsy,sel,atn,msg,c/d,i/o = > 0x3fdff00, expecting 0x100 3fdff00 is rst set d7-d0 set dp0 clear d8-d15 set dp1 clear SCSI is even parity, right? So we're seeing all 1s on the bus when we're expecting all 0s, but there's no parity problem. -- "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 Sat Sep 27 14:45:56 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 27 Sep 2003 08:45:56 -0500 Subject: [parisc-linux] Re: zalon/ncr53c720 crashes K460 (parisc port) on bootup. In-Reply-To: <1064634188.641.27.camel@laptop.bradetich.net> References: <1064634188.641.27.camel@laptop.bradetich.net> Message-ID: <1064670357.2217.18.camel@mulgrave> On Fri, 2003-09-26 at 22:43, Ryan Bradetich wrote: > The zalon/ncr53c720 combination is fatal during booting on my K460 > parisc box. I believe the scsi termination is correct since I performed > a fresh debian install on the scsi disks and I can boot from then every > time I use a 2.4 kernel :) This problem appeared with with the latest > cvs kernel from parisc-linux.org. > > This system does boot and function when I do not compile zalon support > into the kernel and use a nfsroot. > > I can provide addtional information and test patches (or give access to > this system) if requested. > > Any thoughts or feedback appreciated! I'm not familiar with how the K class is wired. However, the ncr53c8xx driver that underlies the zalon720 is extremely ratty. On my C360, I can precipitate exactly this panic just by inserting the zalon7xx module with an unterminated bluefish card. Although we really need to track this down and fix it (which I'll look into doing), all it would do would be to detach the driver correctly at that point (so you still wouldn't see any devices). Could you look at your SCSI setup to see if the driver has a point (i.e. is there a termination or cabling problem)? James From James.Bottomley@steeleye.com Sat Sep 27 16:45:50 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 27 Sep 2003 10:45:50 -0500 Subject: [parisc-linux] Re: zalon/ncr53c720 crashes K460 (parisc port) on bootup. In-Reply-To: <1064634188.641.27.camel@laptop.bradetich.net> References: <1064634188.641.27.camel@laptop.bradetich.net> Message-ID: <1064677551.2002.20.camel@mulgrave> On Fri, 2003-09-26 at 22:43, Ryan Bradetich wrote: > The zalon/ncr53c720 combination is fatal during booting on my K460 > parisc box. I believe the scsi termination is correct since I performed > a fresh debian install on the scsi disks and I can boot from then every > time I use a 2.4 kernel :) This problem appeared with with the latest > cvs kernel from parisc-linux.org. > > This system does boot and function when I do not compile zalon support > into the kernel and use a nfsroot. > > I can provide addtional information and test patches (or give access to > this system) if requested. > > Any thoughts or feedback appreciated! This should fix the panic, but it simply detaches correctly. James ===== drivers/scsi/ncr53c8xx.c 1.37 vs edited ===== --- 1.37/drivers/scsi/ncr53c8xx.c Thu Sep 25 20:08:49 2003 +++ edited/drivers/scsi/ncr53c8xx.c Sat Sep 27 09:44:21 2003 @@ -8585,12 +8585,17 @@ int ncr53c8xx_release(struct Scsi_Host *host) { + ncb_p np; + struct host_data *host_data; + #ifdef DEBUG_NCR53C8XX -printk("ncr53c8xx : release\n"); + printk("ncr53c8xx : release\n"); #endif - ncr_detach(((struct host_data *) host->hostdata)->ncb); + if((host_data = (struct host_data *)host->hostdata) && + host_data->ncb) + ncr_detach(host_data->ncb); - return 1; + return 1; } ===== drivers/scsi/zalon.c 1.11 vs edited ===== --- 1.11/drivers/scsi/zalon.c Thu Sep 25 20:08:51 2003 +++ edited/drivers/scsi/zalon.c Sat Sep 27 10:31:52 2003 @@ -146,7 +146,7 @@ host = ncr_attach(&zalon7xx_template, unit, &device); if (!host) - goto fail; + goto out; if (request_irq(irq, ncr53c8xx_intr, SA_SHIRQ, dev->dev.bus_id, host)) { printk(KERN_ERR "%s: irq problem with %d, detaching\n ", @@ -169,6 +169,7 @@ free_irq(irq, host); fail: ncr53c8xx_release(host); + out: return error; } From willy@debian.org Sat Sep 27 18:23:33 2003 From: willy@debian.org (Matthew Wilcox) Date: Sat, 27 Sep 2003 18:23:33 +0100 Subject: [parisc-linux] Re: zalon/ncr53c720 crashes K460 (parisc port) on bootup. In-Reply-To: <1064677551.2002.20.camel@mulgrave> References: <1064634188.641.27.camel@laptop.bradetich.net> <1064677551.2002.20.camel@mulgrave> Message-ID: <20030927172333.GS24824@parcelfarce.linux.theplanet.co.uk> On Sat, Sep 27, 2003 at 10:45:50AM -0500, James Bottomley wrote: > This should fix the panic, but it simply detaches correctly. Necessary, but not sufficient, I think ... look at ncr_attach(). It doesn't zero hostdata->ncb. Adding that is easy enough ... I'm about to commit a patch to the parisc tree containing this fix. > ===== drivers/scsi/ncr53c8xx.c 1.37 vs edited ===== > --- 1.37/drivers/scsi/ncr53c8xx.c Thu Sep 25 20:08:49 2003 > +++ edited/drivers/scsi/ncr53c8xx.c Sat Sep 27 09:44:21 2003 > @@ -8585,12 +8585,17 @@ > > int ncr53c8xx_release(struct Scsi_Host *host) > { > + ncb_p np; > + struct host_data *host_data; > + > #ifdef DEBUG_NCR53C8XX > -printk("ncr53c8xx : release\n"); > + printk("ncr53c8xx : release\n"); > #endif > - ncr_detach(((struct host_data *) host->hostdata)->ncb); > + if((host_data = (struct host_data *)host->hostdata) && > + host_data->ncb) > + ncr_detach(host_data->ncb); > > - return 1; > + return 1; > } > > > ===== drivers/scsi/zalon.c 1.11 vs edited ===== > --- 1.11/drivers/scsi/zalon.c Thu Sep 25 20:08:51 2003 > +++ edited/drivers/scsi/zalon.c Sat Sep 27 10:31:52 2003 > @@ -146,7 +146,7 @@ > > host = ncr_attach(&zalon7xx_template, unit, &device); > if (!host) > - goto fail; > + goto out; > > if (request_irq(irq, ncr53c8xx_intr, SA_SHIRQ, dev->dev.bus_id, host)) { > printk(KERN_ERR "%s: irq problem with %d, detaching\n ", > @@ -169,6 +169,7 @@ > free_irq(irq, host); > fail: > ncr53c8xx_release(host); > + out: > return error; > } -- "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 soete.joel@tiscali.be Sat Sep 27 19:16:10 2003 From: soete.joel@tiscali.be (Joel Soete) Date: Sat, 27 Sep 2003 18:16:10 +0000 Subject: [parisc-linux] N Class SMP pb ? (follow up) In-Reply-To: <20030926165045.GB11759@dsl2.external.hp.com> References: <3F704CAF00001DCF@ocpmta2.freegates.net> <20030926165045.GB11759@dsl2.external.hp.com> Message-ID: <3F75D3EA.3010106@tiscali.be> Hello Grant, Grant Grundler wrote: >On Fri, Sep 26, 2003 at 05:46:35PM +0200, Joel Soete wrote: > > >>>It means either other CPU never got the interrupt (locked up >>>with I-bit off) or the "unstarted_count" isn't coherent between the CPUs. >>> >>> >>hmm how could I verify this hypothesis? >> >> > >TOC the machine, "ser pim" and look at PSW in TOC Info for each CPU. >bit 0 is the I-Bit IIRC. > > Here is such TOC: PROCESSOR PIM INFORMATION Original Product Number: A3639C Current Product Number: A3639C ------- Processor 1 HPMC Information - PDC Version: 41.28^@ ------ Timestamp = Tue Mar 11 18:07:11 GMT 2003 (20:03:03:11:18:07:11) HPMC Chassis Codes Chassis Code Extension ------------ --------- 0x0000082000ff6242 0x0000000000000000 0x1800082011016312 0xcb81000000000000 0x0000087000ff6292 0x000000ffff800000 0x6000082013016062 0x2002000000080000 0x6000082013016072 0x0000000000080000 0x7000082013016082 0x0000000000192200 0x6000082013036062 0x2001000000082004 0x6000082013036072 0x0000000000082000 0x7000082013036082 0x0000000000992600 0x6000082070006062 0x0000000000080000 0x6000082070006072 0x0000000000080000 0x7000082070006082 0x0000000000192200 0x6000082070016062 0x0000000000000800 0x6000082070016072 0x0000000000000800 0x7000082070016082 0x00000000001a4400 0x0000080080006310 0x0000000000000001 0x7000082082006333 0x0000000000b92200 0x7000082082016333 0x0000000000b92200 0x000008008000631f 0x0000000000000000 0x0000082000ff6452 0x0000000000000000 0x0000082000ff6402 0x0000000000000000 0x0000080080006300 0x0000000000000001 0x7000082082006333 0x0000000000b92200 0x7000082382006343 0x0000000000070200 0x7000082382016343 0x0000000000070200 0x7000082382026343 0x0000000000070200 0x7000082382046343 0x0000000000070200 0x7000082382056343 0x0000000000070200 0x7000082382086343 0x0000000000070200 0x70000823820a6343 0x0000000000070200 0x70000823820c6343 0x0000000000070200 0x7000082082016333 0x0000000000b92200 0x7000082382106343 0x0000000000070200 0x7000082382126343 0x0000000000070200 0x7000082382146343 0x0000000000070200 0x7000082382186343 0x0000000000070200 0x70000823821a6343 0x0000000000070200 0x70000823821c6343 0x0000000000070200 0x0000080089006200 0x0000000000000000 0x0000082389006200 0x0000000000000000 0x0000080086006200 0x0000000000000000 0x000008008000630f 0x0000000000000000 General Registers 0 - 31 00-03 0000000000000000 00000000104f6380 000000001014acb4 00000000104f3b80 04-07 000000008f029000 0000000010423688 000000008f0b8000 0000000010000000 08-11 0000000013484f70 0000000013481e48 000000007f0b8b25 000000001054ebc0 12-15 00000000000e1984 000000001054ec20 000000008f0a40c0 000000008f0bf708 16-19 0000000013481e48 0000000000000000 00000000faf005e0 0000000000000580 20-23 000000001054ebc0 00000000002f7465 00000000003f45a2 000fe051ffc07eb8 24-27 000000007f029b27 00000000000e1984 000000008f0a40c0 00000000104f3b80 28-31 000000000007f029 003f81480007f029 000000008f0e4f40 0000000000008ba3 Control Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000016 0000000000000000 00000000000000c0 000000000000002b 12-15 0000000000000000 0000000000000000 0000000000107000 ffe0000000000000 16-19 00000024643cebe8 0000000000000000 000000001014acec 0000000037dd3f61 20-23 0000000000000600 00000000000e1984 000000ff0804c70f c000000000000000 24-27 0000000000427000 000000007f04b000 0000000000041020 000000ffff95c810 28-31 5555555555555555 5555555555555555 000000008f0e4000 0000000010560000 Space Registers 0 - 7 00-03 00000580 00000580 00000000 00000580 04-07 00000000 00000000 00000000 00000000 IIA Space (back entry) = 0x0000000000000000 IIA Offset (back entry) = 0x000000001014acf0 Check Type = 0x20000000 CPU State = 0x9e000004 Cache Check = 0x00000000 TLB Check = 0x00000000 Bus Check = 0x0010c03b Assists Check = 0x00000000 Assist State = 0x00000000 Path Info = 0x00000000 System Responder Address = 0x0000000000000000 System Requestor Address = 0xfffffffffed25000 Floating Point Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 000000001050eec0 00000000104f3b80 0000000000000002 000000001049d248 08-11 00000000104f3b80 0000000000000802 00000000104be588 000000008fac8000 12-15 0000000000000000 0000000000000000 000000001016ace8 00000000103ad6e0 16-19 00000000000009ca 000000008f7cb000 000000000800000f 000000001049d250 20-23 000000001050eec0 00000000104f3b80 00000000003f45a2 000000000000ba2e 24-27 0000999900000000 000099997fac8b70 000000007fac8b78 000000000bebc200 28-31 0000000000000001 00000000ff915e20 0000000010165bf4 00000000104f3b80 Check Summary = 0xcb81000000000000 Available Memory = 0x0000000100000000 CPU Diagnose Register 2 = 0x0301010800802004 CPU Status Register 0 = 0x2640c24000000000 CPU Status Register 1 = 0x8000200000000000 SADD LOG = 0xf8efdb00003fd800 Read Short LOG = 0xc18200ff80000002 ----------------- DEW 1 HPMC Information - ------ Timestamp = Tue Mar 11 18:07:11 GMT 2003 (20:03:03:11:18:07:11) Runway Control Log Reg = 0x00927b0000000000 Runway Address Data Log Reg Odd = 0xc0aa1010c4a61010 Runway Address Data Log Reg Even = 0xc8a61010cca61010 Runway Address Log Reg = 0x00000000000000f4 Runway Broad Error Log Reg = 0x000000000000005c OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- ERR_ERROR X X Merced Bus Requestor Address = 0x0000000000000000 Merced Bus Target Address = 0x0000000000000000 Merced Bus Responder Address = 0x0000000000000000 Merced Error Status Reg = 0x2002000000080000 Merced Error Overflow Reg = 0x0000000000080000 Merced AERR Addr1 Log Reg = 0x00006000ff86fdc0 Merced AERR Addr2 Log Reg = 0x00008000078fff08 Merced DERR Log Reg = 0x0001000000000000 Merced Error Syndrome Reg = 0x00000000000000c0 ------- Processor 1^@ LPMC Information ------------------ Check Type = 0x00000000 IC Parity Info = 0x00000000 Cache Check = 0x00000000 TLB Check = 0x00000000 Bus Check = 0x00000000 Assists Check = 0x00000000 Assist State = 0x00000000 Path Info = 0x00000000 System Responder Address = 0x0000000000000000 System Requestor Address = 0x0000000000000000 ------- Processor 1^@ TOC Information ------------------- General Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000000 0000000000000000 0000000000000000 0000000000000000 12-15 0000000000000000 0000000000000000 0000000000000000 0000000000000000 16-19 0000000000000000 0000000000000000 0000000000000000 0000000000000000 20-23 0000000000000000 0000000000000000 0000000000000000 0000000000000000 24-27 0000000000000000 0000000000000000 0000000000000000 0000000000000000 28-31 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Control Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000000 0000000000000000 0000000000000000 0000000000000000 12-15 0000000000000000 0000000000000000 0000000000000000 0000000000000000 16-19 0000000000000000 0000000000000000 0000000000000000 0000000000000000 20-23 0000000000000000 0000000000000000 0000000000000000 0000000000000000 24-27 0000000000000000 0000000000000000 0000000000000000 0000000000000000 28-31 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Space Registers 0 - 7 00-03 00000000 00000000 00000000 00000000 04-07 00000000 00000000 00000000 00000000 IIA Space (back entry) = 0x0000000000000000 IIA Offset (back entry) = 0x0000000000000000 CPU State = 0x00000000 ------- Processor 3 HPMC Information - PDC Version: 41.28^@ ------ Timestamp = Tue Mar 11 18:07:11 GMT 2003 (20:03:03:11:18:07:11) HPMC Chassis Codes Chassis Code Extension ------------ --------- 0x0000082000ff6242 0x0000000000000000 0x1800082011036322 0xcb81800000000000 0x0000082000ff6452 0x0000000000000000 0x0000082000ff6402 0x0000000000000000 General Registers 0 - 31 00-03 0000000000000000 0000000010502b80 00000000101161cc 00000000103ef0f8 04-07 000000000800000f 0000000000000002 0000000000000000 00000000104f3b80 08-11 00000000103ef0f8 00000000103ef0f8 000000001038c43c 000000001038af08 12-15 0000000000000001 0000000000000001 0000000000000000 000000001038e004 16-19 000000001038e018 000000008f7cc180 0000000000000002 0000000000000001 20-23 000000000000702c 0000000010423078 00000000104f4380 0000000000000001 24-27 0000000000000116 000000001038c43c 00000000103ef130 00000000104f3b80 28-31 0000000000000000 000000008f0353b0 000000008f0353c0 0000000000008ba3 Control Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000018 0000000000000000 00000000000000c0 000000000000003d 12-15 0000000000000000 0000000000000000 0000000000107000 ffe0000000000000 16-19 000000246412e91b 0000000000000000 00000000101162d0 000000008e605e8d 20-23 0000000000000600 0000000000000000 000000000806060f 0000000000000000 24-27 0000000000427000 000000007f03e000 0000000000041020 000000ffff95c810 28-31 000000ffff95c810 5555555555555555 000000008f034000 0000000000008020 Space Registers 0 - 7 00-03 00000600 00000000 00000000 00000600 04-07 00000000 00000000 00000000 00000000 IIA Space (back entry) = 0x0000000000000000 IIA Offset (back entry) = 0x00000000101162d4 Check Type = 0x20000000 CPU State = 0x9e000004 Cache Check = 0x00000000 TLB Check = 0x00000000 Bus Check = 0x0030000d Assists Check = 0x00000000 Assist State = 0x00000000 Path Info = 0x00000000 System Responder Address = 0xfffffffffed2d000 System Requestor Address = 0x000000fffed2c000 Floating Point Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 000000001050eec0 00000000104f3b80 0000000000000002 000000001049d248 08-11 00000000104f3b80 0000000000000802 00000000104be588 000000008fac8000 12-15 0000000000000000 0000000000000000 000000001016ace8 00000000103ad6e0 16-19 00000000000009ca 000000008f7cb000 000000000800000f 000000001049d250 20-23 000000001050eec0 00000000104f3b80 0000000000000000 000000000000ba2e 24-27 0000999900000000 000099997fac8b70 000000007fac8b78 000000000bebc200 28-31 0000000000000001 00000000ff915e20 0000000010165bf4 00000000104f3b80 Check Summary = 0xcb81800000000000 Available Memory = 0x0000000100000000 CPU Diagnose Register 2 = 0x0301030800802004 CPU Status Register 0 = 0x3640c24000000000 CPU Status Register 1 = 0x8000000000000000 SADD LOG = 0x48e0000000000002 Read Short LOG = 0xc18080ff80080014 ----------------- DEW 3 HPMC Information - ------ Timestamp = Tue Mar 11 18:07:11 GMT 2003 (20:03:03:11:18:07:11) Runway Control Log Reg = 0x0006720000000000 Runway Address Data Log Reg Odd = 0xfffffffffffc3f00 Runway Address Data Log Reg Even = 0xfffffffffffc3f00 Runway Address Log Reg = 0x0000000000000048 Runway Broad Error Log Reg = 0x00000000000000dc OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- X ERR_ERROR X X X Merced Bus Requestor Address = 0x0000000000000000 Merced Bus Target Address = 0x0000000000000000 Merced Bus Responder Address = 0x0000000000000000 Merced Error Status Reg = 0x2001000000082004 Merced Error Overflow Reg = 0x0000000000082000 Merced AERR Addr1 Log Reg = 0x00c0000000300000 Merced AERR Addr2 Log Reg = 0x0000000000f00000 Merced DERR Log Reg = 0x00c1100000000000 Merced Error Syndrome Reg = 0x0000000052000000 ------- Processor 3^@ LPMC Information ------------------ Check Type = 0x00000000 IC Parity Info = 0x00000000 Cache Check = 0x00000000 TLB Check = 0x00000000 Bus Check = 0x00000000 Assists Check = 0x00000000 Assist State = 0x00000000 Path Info = 0x00000000 System Responder Address = 0x0000000000000000 System Requestor Address = 0x0000000000000000 ------- Processor 3^@ TOC Information ------------------- General Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000000 0000000000000000 0000000000000000 0000000000000000 12-15 0000000000000000 0000000000000000 0000000000000000 0000000000000000 16-19 0000000000000000 0000000000000000 0000000000000000 0000000000000000 20-23 0000000000000000 0000000000000000 0000000000000000 0000000000000000 24-27 0000000000000000 0000000000000000 0000000000000000 0000000000000000 28-31 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Control Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000000 0000000000000000 0000000000000000 0000000000000000 12-15 0000000000000000 0000000000000000 0000000000000000 0000000000000000 16-19 0000000000000000 0000000000000000 0000000000000000 0000000000000000 20-23 0000000000000000 0000000000000000 0000000000000000 0000000000000000 24-27 0000000000000000 0000000000000000 0000000000000000 0000000000000000 28-31 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Space Registers 0 - 7 00-03 00000000 00000000 00000000 00000000 04-07 00000000 00000000 00000000 00000000 IIA Space (back entry) = 0x0000000000000000 IIA Offset (back entry) = 0x0000000000000000 CPU State = 0x00000000 -------------- Memory Error Log Information -------------- Bus 0 Log Information Timestamp = Tue Mar 11 18:07:11 GMT 2003 (20:03:03:11:18:07:11) OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- ERR_ERROR X X Bus Requestor Address = 0x0000000000000000 Bus Target Address = 0x0000000000000000 Bus Responder Address = 0x0000000000000000 Error Status Reg = 0x0000000000080000 Error Overflow Reg = 0x0000000000080000 AERR Address 1 Log Reg = 0x0000000000000000 AERR Address 2 Log Reg = 0xf800000000000000 FERR Log Reg = 0x0000000000000000 DERR Log Reg = 0x000133000051cdc0 Error Syndrome Reg = 0x0000000000000000 Address/Control Parity Error Registers Address/Control Parity Error Bit (AE) Not Set Bus 1 Log Information Timestamp = Tue Mar 11 18:07:11 GMT 2003 (20:03:03:11:18:07:11) OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- ERR_TIMEOUT X X Bus Requestor Address = 0xfffffffffed2c000 Bus Target Address = 0x00000000f000a000 Bus Responder Address = 0x0000000000000000 Error Status Reg = 0x0000000000000800 Error Overflow Reg = 0x0000000000000800 AERR Address 1 Log Reg = 0x08006000f000a000 AERR Address 2 Log Reg = 0x6000b0003f700a10 FERR Log Reg = 0x0000000000000000 DERR Log Reg = 0x0000000000000000 Error Syndrome Reg = 0x0000000000000000 Address/Control Parity Error Registers Address/Control Parity Error Bit (AE) Not Set ------------ I/O Module Error Log Information ------------ Summary of IO subsystem log entries ----------------------------------- Phys Loc Vendor Device Severity Description (hex) Id Id CORR UNC FE CW ----------- ----- ------ ------ ---------------- System Bus Adapter SB 0x000000ffffffff82 0x103c 0x1050 X System Bus Adapter RP 0x000000ffff0dff83 0x103c 0x1051 X System Bus Adapter RP 0x000000ffff0eff83 0x103c 0x1051 X System Bus Adapter RP 0x000101ffff06ff83 0x103c 0x1051 X System Bus Adapter RP 0x000101ffff02ff83 0x103c 0x1051 X System Bus Adapter RP 0x000101ffff01ff83 0x103c 0x1051 X System Bus Adapter RP 0x000101ffff04ff83 0x103c 0x1051 X System Bus Adapter RP 0x000101ffff05ff83 0x103c 0x1051 X System Bus Adapter RP 0x000101ffff03ff83 0x103c 0x1051 X System Bus Adapter SB 0x000000ffffffff82 0x103c 0x1050 X System Bus Adapter RP 0x000202ffff0cff83 0x103c 0x1051 X System Bus Adapter RP 0x000202ffff0aff83 0x103c 0x1051 X System Bus Adapter RP 0x000202ffff09ff83 0x103c 0x1051 X System Bus Adapter RP 0x000202ffff0bff83 0x103c 0x1051 X System Bus Adapter RP 0x000202ffff08ff83 0x103c 0x1051 X System Bus Adapter RP 0x000202ffff07ff83 0x103c 0x1051 X Detail display of IO subsystem log entries ------------------------------------------ System Bus Adapter -- System Bus Interface ------------------------------------------ Timestamp = Tue Mar 11 18:09:10 GMT 2003 (20:03:03:11:18:09:10) OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- X X ERR_ERROR X X IO Requestor Address = 0x0000000000000000 IO Target Address = 0x0000000000000000 IO Responder Address = 0xfffffffffed00000 IO Physical Location = 0x000000ffffffff82 IO Hardware Path = 0x00ffffffffffff00 Module Error Register = 0x0000000007ff0034 System Bus Adapter -- Rope Interface ------------------------------------------ Timestamp = Tue Mar 11 18:09:12 GMT 2003 (20:03:03:11:18:09:12) OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- ERR_FUNCTION X IO Requestor Address = 0x0000000000000000 IO Target Address = 0x0000000000000000 IO Responder Address = 0x0000000000000000 IO Physical Location = 0x000000ffffffff82 IO Hardware Path = 0x00ffffffffffff00 Module Error Register = 0x0000000000000000 Rope Physical Location = 0x000000ffff0dff83 System Bus Adapter -- Rope Interface ------------------------------------------ Timestamp = Tue Mar 11 18:09:12 GMT 2003 (20:03:03:11:18:09:12) OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- ERR_FUNCTION X IO Requestor Address = 0x0000000000000000 IO Target Address = 0x0000000000000000 IO Responder Address = 0x0000000000000000 IO Physical Location = 0x000000ffffffff82 IO Hardware Path = 0x00ffffffffffff00 Module Error Register = 0x0000000000000000 Rope Physical Location = 0x000000ffff0eff83 System Bus Adapter -- Rope Interface ------------------------------------------ Timestamp = Tue Mar 11 18:09:12 GMT 2003 (20:03:03:11:18:09:12) OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- ERR_FUNCTION X IO Requestor Address = 0x0000000000000000 IO Target Address = 0x0000000000000000 IO Responder Address = 0x0000000000000000 IO Physical Location = 0x000000ffffffff82 IO Hardware Path = 0x00ffffffffffff00 Module Error Register = 0x0000000000000000 Rope Physical Location = 0x000101ffff06ff83 System Bus Adapter -- Rope Interface ------------------------------------------ Timestamp = Tue Mar 11 18:09:12 GMT 2003 (20:03:03:11:18:09:12) OV RQ RS ESTAT A C D corr unc fe cw pf -- -- -- ----- - - - ---- --- -- -- -- ERR_FUNCTION X IO Requestor Address = 0x0000000000000000 IO Target Address = 0x0000000000000000 IO Responder Address = 0x0000000000000000 IO Physical Location = 0x000000ffffffff82 IO Hardware Path = 0x00ffffffffffff00 Module Error Register = 0x0000000000000000 Rope Physical Location = 0x000101ffff02ff83 System Bus Adapter -- Rope Interface ------------------------------------------ Timestamp = Tue Mar 11 18:09:12 GMT 2003 (20:03:03:11:18:09:12) [...] Well that for an older test but I don't know yet what could be the PSW (sorry I haven't found more doc about TOC output)? >On second thought, I'm skeptical unstarted_count isn't coherent >since it's a kernel global as well (like jiffies). > > > >>>You need to find out who is using smp_call_function() and which function >>>they are trying to invoke. I suspect it's coming from mm/slab.c but >>>would know which of the three it might be. >>> >>> >>Effectively I don't find another place where it is called. And so add a >>printk in each function calling smp_call_function_all_cpus() finaly. >> >>That is allowing me to notice severall call to kmem_tune_cpucache() (7 exactly) >>(and not other) but don't get any more 'SMP CALL FUNCTION TIMED OUT (CPU=1)' >>:( >>(i presume that, as previously, the system crash before having the opportunity >>to flush its buffer?) >> >>What do you think? >> >> > >Could be. >Add mdelay(100) (or higher) after the lines of output you've added. >The works if it's a functional problem that's not timing dependent. > > Because during another test I reach to boot this N (well only during half an hour) in SMP, I am quite sure that is such a problem somewhere (the problem is to find where). >Otherwise setup kernel crash dump and use tools from bruno/phi to view >contents of the kernel message buffer. > I already thought to this (because I test severall bruno's patch), but I have two pb to implement it: a) my system has 2Gb (4* 512Mb iirc) of ram and I don't see how to reconfigure the disk with at least 2Gb of swap(== dump area iirc)? The disk slicing being: Name Flags Part Type FS Type [Label] Size (MB) ------------------------------------------------------------------------------ sda1 Boot Primary Linux/PA-RISC boot 67.56 sda2 Primary Linux swap 135.11 sda3 Primary Linux ext3 130.89 sda5 Logical Linux ext3 1760.56 sda6 Logical Linux ext3 261.77 sda7 Logical Linux ext3 130.89 sda8 Logical Linux ext3 130.89 sda9 Logical Linux ext3 1574.79 sda5 being the root fs must be into the 2Gb limits iirc but I am not quiet sure that swap also has have to be in those limits (in fact it is just like this because of the very first puffin :) (now obsolete) install instruction? b) afaik p4 is not yet publicaly realesed? Thanks in advance for your additional help, Joel From willy@debian.org Sat Sep 27 19:37:56 2003 From: willy@debian.org (Matthew Wilcox) Date: Sat, 27 Sep 2003 19:37:56 +0100 Subject: [parisc-linux] Re: zalon/ncr53c720 crashes K460 (parisc port) on bootup. In-Reply-To: <1064677551.2002.20.camel@mulgrave> References: <1064634188.641.27.camel@laptop.bradetich.net> <1064677551.2002.20.camel@mulgrave> Message-ID: <20030927183756.GT24824@parcelfarce.linux.theplanet.co.uk> On Sat, Sep 27, 2003 at 10:45:50AM -0500, James Bottomley wrote: > This should fix the panic, but it simply detaches correctly. We both missed it. This is why it's panicing: host = ncr_attach(&zalon7xx_template, unit, &device); if (!host) goto fail; fail: ncr53c8xx_release(host); return error; ie we're calling ncr53c8xx_release(NULL) so both your & my patch fail to fix the problem. This looks best to me: +++ drivers/scsi/ncr53c8xx.c 27 Sep 2003 18:31:13 -0000 @@ -8855,11 +8855,14 @@ struct Scsi_Host * __init ncr_attach(str int ncr53c8xx_release(struct Scsi_Host *host) { - struct host_data *host_data = (struct host_data *)host->hostdata; + struct host_data *host_data; #ifdef DEBUG_NCR53C8XX printk("ncr53c8xx: release\n"); #endif - if (host_data->ncb) + if (!host) + return 1; + host_data = (struct host_data *)host->hostdata; + if (host_data && host_data->ncb) ncr_detach(host_data->ncb); return 1; } and it does fix the problem. Maybe it's too much checking, but I'm not interested in tracking down bugs like this again ;-) -- "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 hch@infradead.org Sat Sep 27 19:43:19 2003 From: hch@infradead.org (Christoph Hellwig) Date: Sat, 27 Sep 2003 19:43:19 +0100 Subject: [parisc-linux] Re: zalon/ncr53c720 crashes K460 (parisc port) on bootup. In-Reply-To: <20030927183756.GT24824@parcelfarce.linux.theplanet.co.uk>; from willy@debian.org on Sat, Sep 27, 2003 at 07:37:56PM +0100 References: <1064634188.641.27.camel@laptop.bradetich.net> <1064677551.2002.20.camel@mulgrave> <20030927183756.GT24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030927194319.A30759@infradead.org> On Sat, Sep 27, 2003 at 07:37:56PM +0100, Matthew Wilcox wrote: > - struct host_data *host_data = (struct host_data *)host->hostdata; > + struct host_data *host_data; > #ifdef DEBUG_NCR53C8XX > printk("ncr53c8xx: release\n"); > #endif > - if (host_data->ncb) > + if (!host) > + return 1; > + host_data = (struct host_data *)host->hostdata; > + if (host_data && host_data->ncb) > ncr_detach(host_data->ncb); > return 1; > } > > and it does fix the problem. Maybe it's too much checking, but I'm not > interested in tracking down bugs like this again ;-) Or better just stop calling ncr53c8xx_release if ncr_attach failed.. From James.Bottomley@steeleye.com Sat Sep 27 19:58:06 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 27 Sep 2003 13:58:06 -0500 Subject: [parisc-linux] Re: zalon/ncr53c720 crashes K460 (parisc port) on bootup. In-Reply-To: <20030927183756.GT24824@parcelfarce.linux.theplanet.co.uk> References: <1064634188.641.27.camel@laptop.bradetich.net> <1064677551.2002.20.camel@mulgrave> <20030927183756.GT24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <1064689088.2002.188.camel@mulgrave> On Sat, 2003-09-27 at 13:37, Matthew Wilcox wrote: > On Sat, Sep 27, 2003 at 10:45:50AM -0500, James Bottomley wrote: > > This should fix the panic, but it simply detaches correctly. > > We both missed it. This is why it's panicing: > > host = ncr_attach(&zalon7xx_template, unit, &device); > if (!host) > goto fail; > fail: > ncr53c8xx_release(host); > return error; > > ie we're calling ncr53c8xx_release(NULL) so both your & my patch fail > to fix the problem. This looks best to me: No, I fixed that...that was changed to goto out; in my patch, and out was just before the return (i.e. no longer do the release). James From willy@debian.org Sat Sep 27 21:06:02 2003 From: willy@debian.org (Matthew Wilcox) Date: Sat, 27 Sep 2003 21:06:02 +0100 Subject: [parisc-linux] Re: zalon/ncr53c720 crashes K460 (parisc port) on bootup. In-Reply-To: <1064689088.2002.188.camel@mulgrave> References: <1064634188.641.27.camel@laptop.bradetich.net> <1064677551.2002.20.camel@mulgrave> <20030927183756.GT24824@parcelfarce.linux.theplanet.co.uk> <1064689088.2002.188.camel@mulgrave> Message-ID: <20030927200602.GU24824@parcelfarce.linux.theplanet.co.uk> On Sat, Sep 27, 2003 at 01:58:06PM -0500, James Bottomley wrote: > No, I fixed that...that was changed to goto out; in my patch, and out > was just before the return (i.e. no longer do the release). Oops, I didn't scroll all the way down. Anyway, we have a tradition of allowing, eg, kfree(NULL) to succeed, so it's a little more robust. -- "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 Sun Sep 28 03:59:25 2003 From: willy@debian.org (Matthew Wilcox) Date: Sun, 28 Sep 2003 03:59:25 +0100 Subject: [parisc-linux] Tree frozen Message-ID: <20030928025925.GC24824@parcelfarce.linux.theplanet.co.uk> Hi. I came up with a great improvement to how we manage upstream version imports. Unfortunately, it hasn't worked ;-) The cvs-snapshot script reports some discrepancies between the repository and what it thinks it checked in. I'd appreciate it if people would not check in anything until this is fixed. Sorry for the inconvenience. -- "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 Sun Sep 28 04:38:48 2003 From: willy@debian.org (Matthew Wilcox) Date: Sun, 28 Sep 2003 04:38:48 +0100 Subject: [parisc-linux] cvs-snapshot problem discovered Message-ID: <20030928033848.GD24824@parcelfarce.linux.theplanet.co.uk> OK, think I have it figured out. I experimented on arch/parisc/vmlinux.lds.S since I know both we & Linus removed it. The version in the linux-2.6.0-test6/_cvs-snapshot-linux-2.6/linux-2.6 tree was cvs revision 1.3 which was the same one tagged with the `linus' symbolic tag. Version 1.4 was where we deleted it, but the linus tag never got moved (presumably because cvs tag -F won't move a tag to a deleted revision). So cvs up -rlinus still gets deleted files. How to fix this? I'm not at all sure. I think there's an interesting question about whether a deleted file should have no linus tag or a linus tag on the deleted revision. I'm going to go ahead and merge the 2.6.0-test6 upstream into the trunk since there's nothing wrong with what's checked in (as long as I don't try to use the `linus' tag for anything). -- "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 Sun Sep 28 05:37:59 2003 From: willy@debian.org (Matthew Wilcox) Date: Sun, 28 Sep 2003 05:37:59 +0100 Subject: [parisc-linux] Tree frozen In-Reply-To: <20030928025925.GC24824@parcelfarce.linux.theplanet.co.uk> References: <20030928025925.GC24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030928043759.GE24824@parcelfarce.linux.theplanet.co.uk> On Sun, Sep 28, 2003 at 03:59:25AM +0100, Matthew Wilcox wrote: > I'd appreciate it if people would not check in anything until this > is fixed. Sorry for the inconvenience. Tree seems good now. operations involving the linus tag may not work as you expect... but go ahead and commit stuff. Particularly to fix sched_clock(). -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From grundler@parisc-linux.org Sun Sep 28 08:16:57 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Sun, 28 Sep 2003 01:16:57 -0600 Subject: [parisc-linux] [owner@bugs.debian.org: Bug#204844 acknowledged by developer (Re: Bug#204844: xlibs: libXt.so needs to be built with gcc 3.3.x for HPPA)] Message-ID: <20030928071657.GA28657@dsl2.external.hp.com> FYI - hppa xfree86 libs should be usable again in "testing" release. (eg xpdf and related stuff should be working). Please post issues if it's not. I can rebuild xfree86-4.2.1-11 bits if that is needed. I'll be removing the 4.2.1-9 hppa.debs in the future when it's clear they aren't needed. enjoy! grant (kudos to branden+et al who enabled this!) ----- Forwarded message from Debian Bug Tracking System ----- Date: Sat, 27 Sep 2003 19:56:23 -0500 From: Branden Robinson To: 204844-done@bugs.debian.org Subject: Re: Bug#204844: xlibs: libXt.so needs to be built with gcc 3.3.x for HPPA On Wed, Aug 27, 2003 at 09:57:00PM -0600, Grant Grundler wrote: > On Wed, Aug 27, 2003 at 09:27:45PM -0500, Branden Robinson wrote: > ... > > My feeling is that our efforts are best spent on getting a newer 4.2.1 > > package into testing at this point. >=20 > Agreed. >=20 > I've placed a full set of "hand crafted" 4.2.1-9 hppa debs on: > http://gsyprf11.external.hp.com/hppa/xfree86-4.2.1-9/ >=20 > Built with gcc 3.3.1 and current "testing" binutils. > Works For Me (tm). >=20 > These are built by hacking the Makefile "world" target to not rebuild > everything from scratch and iteratively fix up the two problems by hand. > source/build tree is intact on gsyprf11 in case someone wants a copy. xfree86 4.2.1-11 entered Debian testing on Friday. Closing this report. --=20 G. Branden Robinson | Freedom is kind of a hobby with me, Debian GNU/Linux | and I have disposable income that branden@debian.org | I'll spend to find out how to get http://people.debian.org/~branden/ | people more of it. -- Penn Jillette ----- End forwarded message ----- From soete.joel@tiscali.be Sun Sep 28 10:00:02 2003 From: soete.joel@tiscali.be (Joel Soete) Date: Sun, 28 Sep 2003 09:00:02 +0000 Subject: [parisc-linux] zalon/ncr53c720 (linux-2.6.0-test5-pa22) broken on C110 Message-ID: <3F76A312.8090603@tiscali.be> Hi all, I read well the thread about the pb on K460 and so try to test it on my C110 model but is failed to boot: 2.6.0-test5-pa22 [...] zalon_probe: Zalon vers field is 0x1, IRQ 34 ncr53c720-0: rev 0xf irq 34 ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential ncr53c720-0: suspicious SCSI data while resetting the BUS. ncr53c720-0: dp1,d15-8,dp0,d7-0,rst,req,ack,bsy,sel,atn,msg,c/d,i/o = 0x3fdff000, expecting 0x100 ncr53c720-0: FATAL ERROR: CHECK SCSI BUS - CABLES, TERMINATION, DEVICE POWER etc! ncr53c720-0: detaching... 53c700: Version 2.8 By James.Bottomley@HansenPartnership.com scsi1: 53c710 rev 2 scsi1 : LASI SCSI 53c700 [...] VFS: Cannot open root device "sda5" or unknown-block(2,0) Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on unknown-block(2,0) I am sure there is no hw pb because after that test I can always reboot with 2.6.0-test5-PA6: 2.6.0-test5-pa6 [...] zalon_scsi_callback: Zalon vers field is 0x1, IRQ 34 ncr53c720-0: rev 0xf on pci bus 0 device 0 function 0 irq 34 ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential scsi0 : ncr53c8xx-3.4.3b-20010512 Using anticipatory scheduling io scheduler Vendor: SEAGATE Model: ST34371W Rev: HP03 Type: Direct-Access ANSI SCSI revision: 02 Vendor: SEAGATE Model: ST34371W Rev: HP03 Type: Direct-Access ANSI SCSI revision: 02 53c700: Version 2.8 By James.Bottomley@HansenPartnership.com scsi1: 53c710 rev 2 scsi1 : LASI SCSI 53c700 st: Version 20030811, fixed bufsize 32768, s/g segs 256 ncr53c720-0-<5,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8) SCSI device sda: 8388314 512-byte hdwr sectors (4295 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 > Attached scsi disk sda at scsi0, channel 0, id 5, lun 0 ncr53c720-0-<6,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8) SCSI device sdb: 8388314 512-byte hdwr sectors (4295 MB) SCSI device sdb: drive cache: write back sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 sdb8 sdb9 > Attached scsi disk sdb at scsi0, channel 0, id 6, lun 0 Attached scsi generic sg0 at scsi0, channel 0, id 5, lun 0, type 0 Attached scsi generic sg1 at scsi0, channel 0, id 6, lun 0, type 0 [...] Can somebody could help me to find patches (step by step) applied on this driver from -pa6 to -pa22? Thanks in advance, Joel From willy@debian.org Sun Sep 28 13:24:14 2003 From: willy@debian.org (Matthew Wilcox) Date: Sun, 28 Sep 2003 13:24:14 +0100 Subject: [parisc-linux] Re: zalon/ncr53c720 (linux-2.6.0-test5-pa22) broken on C110 In-Reply-To: <3F76A312.8090603@tiscali.be> References: <3F76A312.8090603@tiscali.be> Message-ID: <20030928122414.GF24824@parcelfarce.linux.theplanet.co.uk> On Sun, Sep 28, 2003 at 09:00:02AM +0000, Joel Soete wrote: > I am sure there is no hw pb because after that test I can always reboot > with 2.6.0-test5-PA6: This is good to hear. > Can somebody could help me to find patches (step by step) applied on > this driver from -pa6 to -pa22? Yes. Could you start with -pa18 (or -pa20)? http://cvs.parisc-linux.org/download/linux-2.6/patch-2.6.0-test5-pa18.gz (or cvs up -rCVS260_TEST5_PA18) The driver is rev 1.5 in -test5-pa6. rev 1.6 is in -test5-pa18. After -test5-pa20, we don't have anyautotagged stuff, but let's start with -pa18. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From xam@cs.ucc.ie Sun Sep 28 15:44:14 2003 From: xam@cs.ucc.ie (M. Grabert) Date: Sun, 28 Sep 2003 15:44:14 +0100 (IST) Subject: [parisc-linux] 2.6.0-test6-pa0 undefined references Message-ID: Hi, I can't compine 2.6.0-test6-pa0, compiling stops with the following error message: kernel/built-in.o(.text.try_to_wake_up+0xf8): In function `try_to_wake_up': : undefined reference to `sched_clock' kernel/built-in.o(.text.schedule+0x7c): In function `schedule': : undefined reference to `sched_clock' kernel/built-in.o(.text.copy_process+0x4e0): In function `copy_process': : undefined reference to `sched_clock' make: *** [.tmp_vmlinux1] Error 1 The same config compiled fine with 2.6.0-test4-pa8. Last tested with CVS checkout of 5 minutes ago. PS: I also can't compile smbfs in the kernel, but as module: (error about undefined reference to `low2highuid`) Thanks, Max PS: .config will be send on request From willy@debian.org Sun Sep 28 15:46:37 2003 From: willy@debian.org (Matthew Wilcox) Date: Sun, 28 Sep 2003 15:46:37 +0100 Subject: [parisc-linux] 2.6.0-test6-pa0 undefined references In-Reply-To: References: Message-ID: <20030928144637.GG24824@parcelfarce.linux.theplanet.co.uk> On Sun, Sep 28, 2003 at 03:44:14PM +0100, M. Grabert wrote: > I can't compine 2.6.0-test6-pa0, compiling stops with the following > error message: Yes, that's expected for -pa0. It only gets -pa1 once these kinds of problems are fixed ;-) > PS: I also can't compile smbfs in the kernel, but as module: > (error about undefined reference to `low2highuid`) I'll look at that ... -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From xam@cs.ucc.ie Sun Sep 28 15:50:29 2003 From: xam@cs.ucc.ie (M. Grabert) Date: Sun, 28 Sep 2003 15:50:29 +0100 (IST) Subject: [parisc-linux] 2.6.0-test6-pa0 undefined references In-Reply-To: <20030928144637.GG24824@parcelfarce.linux.theplanet.co.uk> References: <20030928144637.GG24824@parcelfarce.linux.theplanet.co.uk> Message-ID: On Sun, 28 Sep 2003, Matthew Wilcox wrote: > On Sun, Sep 28, 2003 at 03:44:14PM +0100, M. Grabert wrote: > > I can't compine 2.6.0-test6-pa0, compiling stops with the following > > error message: > > Yes, that's expected for -pa0. It only gets -pa1 once these kinds of > problems are fixed ;-) Yes, that's why I didn't included my .config (since you just merged -test6 I assumed it's too early to blame it on my config ;) I also just wanted to give you a hint what needs fixing *grin* > > PS: I also can't compile smbfs in the kernel, but as module: > > (error about undefined reference to `low2highuid`) > > I'll look at that ... Slan, Max From soete.joel@tiscali.be Sun Sep 28 17:56:34 2003 From: soete.joel@tiscali.be (Joel Soete) Date: Sun, 28 Sep 2003 16:56:34 +0000 Subject: [parisc-linux] PALO do not start! In-Reply-To: <881138831633.20030923163001@kti.ae.poznan.pl> References: <881138831633.20030923163001@kti.ae.poznan.pl> Message-ID: <3F7712C2.2000902@tiscali.be> Jacek Chmielewski wrote: >Hi > >I managed to install Debian on my HP 9000/J200 box (I used DHCP server and >netinstall lifimage). The installation procedure passed without problems. I >created three partitions: >/dev/sda1 * 1 4 16461 f0 Linux/PA-RISC boot >/dev/sda2 5 34 123690 82 Linux swap >/dev/sda3 * 35 277 1001889 83 Linux > it seems that sda3 stand well into the first 2gb of your disk? Do you have severall disk on your system and so do boot on the right disk? if your system 'autoboot', interupt it with [Esc]; the main menu would show you something like: Primary boot path: core.FWSCSI.6.0 Alternate boot path: core.FWSCSI.5.0 > >After the reboot I get the following result: > >Booting... >Boot IO Dependent Code (IODC) revision 1 >HARD Booted. > >... and everything nothing happens. I assume that I should see PALO >starting from the /dev/sda1 partition, > yes > but it don't want to start. > >What could be possibly wrong? > >Is there any solution or workaround for this problem? > Try to restart your netinstall, in the second menu you should be able to go into a small shell. There create first /mnt/BD in your ramdisk and so mount /dev/sda3 /mnt/DB. verify first the contents of /mnt/DB/etc/palo.conf. hth, Joel From soete.joel@tiscali.be Sun Sep 28 18:13:34 2003 From: soete.joel@tiscali.be (Joel Soete) Date: Sun, 28 Sep 2003 17:13:34 +0000 Subject: [parisc-linux] Re: zalon/ncr53c720 (linux-2.6.0-test5-pa22) broken on C110 In-Reply-To: <20030928122414.GF24824@parcelfarce.linux.theplanet.co.uk> References: <3F76A312.8090603@tiscali.be> <20030928122414.GF24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <3F7716BE.8030008@tiscali.be> Matthew Wilcox wrote: >On Sun, Sep 28, 2003 at 09:00:02AM +0000, Joel Soete wrote: > > >>I am sure there is no hw pb because after that test I can always reboot >>with 2.6.0-test5-PA6: >> >> > >This is good to hear. > > > >>Can somebody could help me to find patches (step by step) applied on >>this driver from -pa6 to -pa22? >> >> > >Yes. Could you start with -pa18 (or -pa20)? >http://cvs.parisc-linux.org/download/linux-2.6/patch-2.6.0-test5-pa18.gz > Thanks Matthew, (why didn't I think myself ;) ) >(or cvs up -rCVS260_TEST5_PA18) > >The driver is rev 1.5 in -test5-pa6. rev 1.6 is in -test5-pa18. >After -test5-pa20, we don't have anyautotagged stuff, but let's start >with -pa18. > > Ok I will look and advise you, Joel From rhirst@linuxcare.com Sun Sep 28 17:56:31 2003 From: rhirst@linuxcare.com (Richard Hirst) Date: Sun, 28 Sep 2003 17:56:31 +0100 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.6 willy In-Reply-To: <20030927072449.5AF0F494058@palinux.hppa> References: <20030927072449.5AF0F494058@palinux.hppa> Message-ID: <20030928165631.GS5759@sleepie.demon.co.uk> On Sat, Sep 27, 2003 at 01:24:49AM -0600, Matthew Wilcox wrote: > CVSROOT: /var/cvs > Module name: linux-2.6 > Changes by: willy 03/09/27 01:24:49 > > Modified files: > drivers/scsi : Makefile NCR_Q720.c ncr53c8xx.c > sym53c8xx_defs.h > > Log message: > SIMULATED_INTFLY is always true for ncr720 chips, so remove the other case. Only because I didn't get it to work properly when I did the original 720 support, iirc. The chip does have INTFLY. I _think_ INTFLY worked a bit, but the driver tended to miss interrupts sometimes. Could easily have been a driver bug. Was a long time ago now though, so I could be misremembering. Richard From James.Bottomley@steeleye.com Sun Sep 28 18:24:26 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 28 Sep 2003 12:24:26 -0500 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.6 willy In-Reply-To: <20030928165631.GS5759@sleepie.demon.co.uk> References: <20030927072449.5AF0F494058@palinux.hppa> <20030928165631.GS5759@sleepie.demon.co.uk> Message-ID: <1064769945.10841.1.camel@mulgrave> On Sun, 2003-09-28 at 11:56, Richard Hirst wrote: > Only because I didn't get it to work properly when I did the original > 720 support, iirc. The chip does have INTFLY. I _think_ INTFLY worked > a bit, but the driver tended to miss interrupts sometimes. Could easily > have been a driver bug. Was a long time ago now though, so I could be > misremembering. Actually, the 720 is bust in silicon. The 770 has a properly working intfly, but the 720's doesnt work reliably. Actually, the Q720 board this driver also drives is wired to have a special "intfly" from a board register to get around the problem. James From carlos@baldric.uwo.ca Sun Sep 28 18:42:26 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Sun, 28 Sep 2003 13:42:26 -0400 Subject: [parisc-linux] pthread attributes and stack positions (gcc related?) Message-ID: <20030928174226.GA3040@systemhalted> --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've noticed that we've regressed on a pthread test "tst-attr1" and it seems to complain that our thread variables are stored outside the stack that the thred "thinks" is it's stack. The following code is a simplified case of tst-attr1.c in the glibc testsuite. I would recommend that you look at the original code too. The question I have is... how is this supposed to work? If anyone is more cluefull than me on this I would appreciate a pointer in the right direction :) === ./test-attr In child &a=0xfaf00ac8, stackaddr=0x40046e60, stacksize=0xbffb91a0 ./test-attr: pthread_attr_getstack returned range does not cover main's stack In parent &a=0xfaf00ac8, stackaddr=0x40046e60, stacksize=0xbffb91a0 ./test-attr: pthread_attr_getstack returned range does not cover main's stack === The variable is definately on the process stack. The thread's stack address seems to be inside the libraries 'writable' space and the stack size is wrong (or uninitialized). Perhaps I should just be looking for arch-dependant init code that we might be missing. === tst-attr1 from glibc === tst-attr1: pthread_attr_getstack returned range does not cover main's stack thread stack 0x40245000-0x40a44000 (0x7ff000) thread guardsize 4096 thread stack 0x40a45000-0x40c44000 (0x1ff000) thread guardsize 4096 thread stack 0x40245000-0x40444000 (0x1ff000) thread guardsize 65536 === Attached is the Makefile to build the simplified tst-attr1.c (requires test-skeleton.c wrapper, included aswell) or rather test-attr.c Input and thoughts appreciated. This failure in glibc is rather orthogonal to the release of 2.3.2, I'm still concentrating on the last sysdep cancel failure (last bug to fix before a working release). c. --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=Makefile all: test-attr.o gcc -lpthread -o test-attr test-attr.o test: ./test-attr clean: rm -rf *.o rm -rf test-attr --wRRV7LY7NUeQGEoC Content-Type: text/x-csrc; charset=us-ascii Content-Disposition: attachment; filename="tst-attr1.c" /* pthread_getattr_np test. Copyright (C) 2003 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Jakub Jelinek , 2003. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with the GNU C Library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. */ #include #include #include #include #include #include #include #include static void * tf (void *arg) { pthread_attr_t a, *ap, a2; int err; void *result = NULL; if (arg == NULL) { ap = &a2; err = pthread_attr_init (ap); if (err) { error (0, err, "pthread_attr_init failed"); return tf; } } else ap = (pthread_attr_t *) arg; err = pthread_getattr_np (pthread_self (), &a); if (err) { error (0, err, "pthread_getattr_np failed"); result = tf; } int detachstate1, detachstate2; err = pthread_attr_getdetachstate (&a, &detachstate1); if (err) { error (0, err, "pthread_attr_getdetachstate failed"); result = tf; } else { err = pthread_attr_getdetachstate (ap, &detachstate2); if (err) { error (0, err, "pthread_attr_getdetachstate failed"); result = tf; } else if (detachstate1 != detachstate2) { error (0, 0, "detachstate differs %d != %d", detachstate1, detachstate2); result = tf; } } void *stackaddr; size_t stacksize; err = pthread_attr_getstack (&a, &stackaddr, &stacksize); if (err) { error (0, err, "pthread_attr_getstack failed"); result = tf; } else if ((void *) &a < stackaddr || (void *) &a >= stackaddr + stacksize) { error (0, 0, "pthread_attr_getstack returned range does not cover thread's stack"); result = tf; } else printf ("thread stack %p-%p (0x%zx)\n", stackaddr, stackaddr + stacksize, stacksize); size_t guardsize1, guardsize2; err = pthread_attr_getguardsize (&a, &guardsize1); if (err) { error (0, err, "pthread_attr_getguardsize failed"); result = tf; } else { err = pthread_attr_getguardsize (ap, &guardsize2); if (err) { error (0, err, "pthread_attr_getguardsize failed"); result = tf; } else if (guardsize1 != guardsize2) { error (0, 0, "guardsize differs %zd != %zd", guardsize1, guardsize2); result = tf; } else printf ("thread guardsize %zd\n", guardsize1); } int scope1, scope2; err = pthread_attr_getscope (&a, &scope1); if (err) { error (0, err, "pthread_attr_getscope failed"); result = tf; } else { err = pthread_attr_getscope (ap, &scope2); if (err) { error (0, err, "pthread_attr_getscope failed"); result = tf; } else if (scope1 != scope2) { error (0, 0, "scope differs %d != %d", scope1, scope2); result = tf; } } err = pthread_attr_destroy (&a); if (err) { error (0, err, "pthread_attr_destroy failed"); result = tf; } if (ap == &a2) { err = pthread_attr_destroy (ap); if (err) { error (0, err, "pthread_attr_destroy failed"); result = tf; } } return result; } static int do_test (void) { int result = 0; pthread_attr_t a; int err = pthread_attr_init (&a); if (err) { error (0, err, "pthread_attr_init failed"); result = 1; } err = pthread_attr_destroy (&a); if (err) { error (0, err, "pthread_attr_destroy failed"); result = 1; } err = pthread_getattr_np (pthread_self (), &a); if (err) { error (0, err, "pthread_getattr_np failed"); result = 1; } int detachstate; err = pthread_attr_getdetachstate (&a, &detachstate); if (err) { error (0, err, "pthread_attr_getdetachstate failed"); result = 1; } else if (detachstate != PTHREAD_CREATE_JOINABLE) { error (0, 0, "initial thread not joinable"); result = 1; } void *stackaddr; size_t stacksize; err = pthread_attr_getstack (&a, &stackaddr, &stacksize); if (err) { error (0, err, "pthread_attr_getstack failed"); result = 1; } else if ((void *) &a < stackaddr || (void *) &a >= stackaddr + stacksize) { error (0, 0, "pthread_attr_getstack returned range does not cover main's stack"); result = 1; } else printf ("initial thread stack %p-%p (0x%zx)\n", stackaddr, stackaddr + stacksize, stacksize); size_t guardsize; err = pthread_attr_getguardsize (&a, &guardsize); if (err) { error (0, err, "pthread_attr_getguardsize failed"); result = 1; } else if (guardsize != 0) { error (0, 0, "pthread_attr_getguardsize returned %zd != 0", guardsize); result = 1; } int scope; err = pthread_attr_getscope (&a, &scope); if (err) { error (0, err, "pthread_attr_getscope failed"); result = 1; } else if (scope != PTHREAD_SCOPE_SYSTEM) { error (0, 0, "pthread_attr_getscope returned %d != PTHREAD_SCOPE_SYSTEM", scope); result = 1; } int inheritsched; err = pthread_attr_getinheritsched (&a, &inheritsched); if (err) { error (0, err, "pthread_attr_getinheritsched failed"); result = 1; } else if (inheritsched != PTHREAD_INHERIT_SCHED) { error (0, 0, "pthread_attr_getinheritsched returned %d != PTHREAD_INHERIT_SCHED", inheritsched); result = 1; } err = pthread_attr_destroy (&a); if (err) { error (0, err, "pthread_attr_destroy failed"); result = 1; } pthread_t th; err = pthread_create (&th, NULL, tf, NULL); if (err) { error (0, err, "pthread_create #1 failed"); result = 1; } else { void *ret; err = pthread_join (th, &ret); if (err) { error (0, err, "pthread_join #1 failed"); result = 1; } else if (ret != NULL) result = 1; } err = pthread_attr_init (&a); if (err) { error (0, err, "pthread_attr_init failed"); result = 1; } err = pthread_create (&th, &a, tf, &a); if (err) { error (0, err, "pthread_create #2 failed"); result = 1; } else { void *ret; err = pthread_join (th, &ret); if (err) { error (0, err, "pthread_join #2 failed"); result = 1; } else if (ret != NULL) result = 1; } err = pthread_attr_setguardsize (&a, 16 * sysconf (_SC_PAGESIZE)); if (err) { error (0, err, "pthread_attr_setguardsize failed"); result = 1; } err = pthread_create (&th, &a, tf, &a); if (err) { error (0, err, "pthread_create #3 failed"); result = 1; } else { void *ret; err = pthread_join (th, &ret); if (err) { error (0, err, "pthread_join #3 failed"); result = 1; } else if (ret != NULL) result = 1; } err = pthread_attr_destroy (&a); if (err) { error (0, err, "pthread_attr_destroy failed"); result = 1; } return result; } #define TEST_FUNCTION do_test () #include "../test-skeleton.c" --wRRV7LY7NUeQGEoC Content-Type: text/x-csrc; charset=us-ascii Content-Disposition: attachment; filename="test-attr.c" #include #include #include #include #include #include #include int main(void){ pthread_attr_t a; int result = 0; void *stackaddr = NULL; size_t stacksize = 0; int err; pid_t ret; ret = fork(); if( ret != 0 ){ wait(NULL); printf("In parent\n"); } else if ( ret == -1 ) { printf("Error forking.\n"); exit(1); } else { printf("In child\n"); } err = pthread_attr_init (&a); if (err){ error(0, err, "pthread_attr_init failed"); exit(1); } err = pthread_getattr_np (pthread_self (), &a); if (err){ error (0, err, "pthread_getattr_np failed"); exit(1); } err = pthread_attr_getstack (&a, &stackaddr, &stacksize); printf("&a=0x%x, stackaddr=0x%x, stacksize=0x%x\n", (unsigned int)(&a),(unsigned int)stackaddr,stacksize); if (err){ error (0, err, "pthread_attr_getstack failed"); result = 1; } else if ((void *) &a < stackaddr || (void *) &a >= stackaddr + stacksize){ error (0, 0, "pthread_attr_getstack returned range does not cover main's stack"); result = 1; } else printf ("initial thread stack %p-%p (0x%zx)\n", stackaddr, stackaddr + stacksize, stacksize); exit(0); } --wRRV7LY7NUeQGEoC Content-Type: text/x-csrc; charset=us-ascii Content-Disposition: attachment; filename="test-skeleton.c" /* Skeleton for test programs. Copyright (C) 1998, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Ulrich Drepper , 1998. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with the GNU C Library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. */ #include #include #include #include #include #include #include #include #include #include #include #include /* The test function is normally called `do_test' and it is called with argc and argv as the arguments. We nevertheless provide the possibility to overwrite this name. */ #ifndef TEST_FUNCTION # define TEST_FUNCTION do_test (argc, argv) #endif #ifndef TEST_DATA_LIMIT # define TEST_DATA_LIMIT (64 << 20) /* Data limit (bytes) to run with. */ #endif #define OPT_DIRECT 1000 #define OPT_TESTDIR 1001 static struct option options[] = { #ifdef CMDLINE_OPTIONS CMDLINE_OPTIONS #endif { "direct", no_argument, NULL, OPT_DIRECT }, { "test-dir", required_argument, NULL, OPT_TESTDIR }, { NULL, 0, NULL, 0 } }; /* PID of the test itself. */ static pid_t pid; /* Directory to place temporary files in. */ static const char *test_dir; /* List of temporary files. */ struct temp_name_list { struct qelem q; const char *name; } *temp_name_list; /* Add temporary files in list. */ static void __attribute__ ((unused)) add_temp_file (const char *name) { struct temp_name_list *newp = (struct temp_name_list *) calloc (sizeof (*newp), 1); if (newp != NULL) { newp->name = name; if (temp_name_list == NULL) temp_name_list = (struct temp_name_list *) &newp->q; else insque (newp, temp_name_list); } } /* Delete all temporary files. */ static void delete_temp_files (void) { while (temp_name_list != NULL) { remove (temp_name_list->name); temp_name_list = (struct temp_name_list *) temp_name_list->q.q_forw; } } /* Create a temporary file. */ static int __attribute__ ((unused)) create_temp_file (const char *base, char **filename) { char *fname; int fd; fname = (char *) malloc (strlen (test_dir) + 1 + strlen (base) + sizeof ("XXXXXX")); if (fname == NULL) { puts ("out of memory"); return -1; } strcpy (stpcpy (stpcpy (stpcpy (fname, test_dir), "/"), base), "XXXXXX"); fd = mkstemp (fname); if (fd == -1) { printf ("cannot open temporary file '%s': %m\n", fname); free (fname); return -1; } add_temp_file (fname); if (filename != NULL) *filename = fname; return fd; } /* Timeout handler. We kill the child and exit with an error. */ static void __attribute__ ((noreturn)) timeout_handler (int sig __attribute__ ((unused))) { int killed; int status; /* Send signal. */ kill (pid, SIGKILL); /* Wait for it to terminate. */ int i; for (i = 0; i < 5; ++i) { killed = waitpid (pid, &status, WNOHANG|WUNTRACED); if (killed != 0) break; /* Delay, give the system time to process the kill. If the nanosleep() call return prematurely, all the better. We won't restart it since this probably means the child process finally died. */ struct timespec ts = { .tv_sec = 0, .tv_nsec = 100000000 }; nanosleep (&ts, NULL); } if (killed != 0 && killed != pid) { perror ("Failed to killed test process"); exit (1); } #ifdef CLEANUP_HANDLER CLEANUP_HANDLER; #endif /* If we expected this signal: good! */ #ifdef EXPECTED_SIGNAL if (EXPECTED_SIGNAL == SIGALRM) exit (0); #endif if (killed == 0 || (WIFSIGNALED (status) && WTERMSIG (status) == SIGKILL)) fputs ("Timed out: killed the child process\n", stderr); else if (WIFSTOPPED (status)) fprintf (stderr, "Timed out: the child process was %s\n", strsignal (WSTOPSIG (status))); else if (WIFSIGNALED (status)) fprintf (stderr, "Timed out: the child process got signal %s\n", strsignal (WTERMSIG (status))); else fprintf (stderr, "Timed out: killed the child process but it exited %d\n", WEXITSTATUS (status)); /* Exit with an error. */ exit (1); } /* We provide the entry point here. */ int main (int argc, char *argv[]) { int direct = 0; /* Directly call the test function? */ int status; int opt; pid_t termpid; #ifdef STDOUT_UNBUFFERED setbuf (stdout, NULL); #endif while ((opt = getopt_long (argc, argv, "+", options, NULL)) != -1) switch (opt) { case '?': exit (1); case OPT_DIRECT: direct = 1; break; case OPT_TESTDIR: test_dir = optarg; break; #ifdef CMDLINE_PROCESS CMDLINE_PROCESS #endif } /* Set TMPDIR to specified test directory. */ if (test_dir != NULL) { setenv ("TMPDIR", test_dir, 1); if (chdir (test_dir) < 0) { perror ("chdir"); exit (1); } } else { test_dir = getenv ("TMPDIR"); if (test_dir == NULL || test_dir[0] == '\0') test_dir = "/tmp"; } /* Make sure we see all message, even those on stdout. */ setvbuf (stdout, NULL, _IONBF, 0); /* make sure temporary files are deleted. */ atexit (delete_temp_files); /* Correct for the possible parameters. */ argv[optind - 1] = argv[0]; argv += optind - 1; argc -= optind - 1; /* Call the initializing function, if one is available. */ #ifdef PREPARE PREPARE (argc, argv); #endif /* If we are not expected to fork run the function immediately. */ if (direct) return TEST_FUNCTION; /* Set up the test environment: - prevent core dumps - set up the timer - fork and execute the function. */ pid = fork (); if (pid == 0) { /* This is the child. */ #ifdef RLIMIT_CORE /* Try to avoid dumping core. */ struct rlimit core_limit; core_limit.rlim_cur = 0; core_limit.rlim_max = 0; setrlimit (RLIMIT_CORE, &core_limit); #endif #ifdef RLIMIT_DATA /* Try to avoid eating all memory if a test leaks. */ struct rlimit data_limit; if (getrlimit (RLIMIT_DATA, &data_limit) == 0) { if (TEST_DATA_LIMIT == RLIM_INFINITY) data_limit.rlim_cur = data_limit.rlim_max; else if (data_limit.rlim_cur > (rlim_t) TEST_DATA_LIMIT) data_limit.rlim_cur = MIN ((rlim_t) TEST_DATA_LIMIT, data_limit.rlim_max); if (setrlimit (RLIMIT_DATA, &data_limit) < 0) perror ("setrlimit: RLIMIT_DATA"); } else perror ("getrlimit: RLIMIT_DATA"); #endif /* We put the test process in its own pgrp so that if it bogusly generates any job control signals, they won't hit the whole build. */ setpgid (0, 0); /* Execute the test function and exit with the return value. */ exit (TEST_FUNCTION); } else if (pid < 0) { perror ("Cannot fork test program"); exit (1); } /* Set timeout. */ #ifndef TIMEOUT /* Default timeout is two seconds. */ # define TIMEOUT 2 #endif signal (SIGALRM, timeout_handler); alarm (TIMEOUT); /* Wait for the regular termination. */ termpid = TEMP_FAILURE_RETRY (waitpid (pid, &status, 0)); if (termpid == -1) { printf ("Waiting for test program failed: %m\n"); exit (1); } if (termpid != pid) { printf ("Oops, wrong test program terminated: expected %ld, got %ld\n", (long int) pid, (long int) termpid); exit (1); } #ifndef EXPECTED_SIGNAL /* We don't expect any signal. */ # define EXPECTED_SIGNAL 0 #endif if (WTERMSIG (status) != EXPECTED_SIGNAL) { if (EXPECTED_SIGNAL != 0) { if (WTERMSIG (status) == 0) fprintf (stderr, "Expected signal '%s' from child, got none\n", strsignal (EXPECTED_SIGNAL)); else fprintf (stderr, "Incorrect signal from child: got `%s', need `%s'\n", strsignal (WTERMSIG (status)), strsignal (EXPECTED_SIGNAL)); } else fprintf (stderr, "Didn't expect signal from child: got `%s'\n", strsignal (WTERMSIG (status))); exit (1); } /* Simply exit with the return value of the test. */ #ifndef EXPECTED_STATUS return WEXITSTATUS (status); #else if (WEXITSTATUS (status) != EXPECTED_STATUS) { fprintf (stderr, "Expected status %d, got %d\n", EXPECTED_STATUS, WEXITSTATUS (status)); exit (1); } return 0; #endif } --wRRV7LY7NUeQGEoC-- From James.Bottomley@steeleye.com Sun Sep 28 18:53:38 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 28 Sep 2003 12:53:38 -0500 Subject: [parisc-linux] pthread attributes and stack positions (gcc related?) In-Reply-To: <20030928174226.GA3040@systemhalted> References: <20030928174226.GA3040@systemhalted> Message-ID: <1064771620.10778.5.camel@mulgrave> On Sun, 2003-09-28 at 12:42, Carlos O'Donell wrote: > The variable is definately on the process stack. The thread's stack > address seems to be inside the libraries 'writable' space and the stack > size is wrong (or uninitialized). Perhaps I should just be looking for > arch-dependant init code that we might be missing. This, I believe to be correct: there's only one real stack (i.e. the thing on x86 that grows down from top of memory) and only one thread can have it. The rest of the thread stacks are mmapped at fixed sizes with a guard area to prevent them growing too far. mmapped memory comes out of the same pool that shared library memory comes from, so you should correctly see the mappings interleave (depending on the load and thread start order). James From soete.joel@tiscali.be Sun Sep 28 19:03:43 2003 From: soete.joel@tiscali.be (Joel Soete) Date: Sun, 28 Sep 2003 18:03:43 +0000 Subject: [parisc-linux] Re: zalon/ncr53c720 (linux-2.6.0-test5-pa22) broken on C110 In-Reply-To: <20030928122414.GF24824@parcelfarce.linux.theplanet.co.uk> References: <3F76A312.8090603@tiscali.be> <20030928122414.GF24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <3F77227F.7000400@tiscali.be> Matthew Wilcox wrote: >The driver is rev 1.5 in -test5-pa6. rev 1.6 is in -test5-pa18. >After -test5-pa20, we don't have anyautotagged stuff, but let's start >with -pa18. > > > Sorry it already failled with following satck dump: zalon_probe: Zalon vers field is 0x1, IRQ 34 ncr53c720-0: rev 0xf on bus 0 device 0 function 0 irq 34 ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential ncr53c720-0: suspicious SCSI data while resetting the BUS. ncr53c720-0: dp1,d15-8,dp0,d7-0,rst,req,ack,bsy,sel,atn,msg,c/d,i/o = 0x3fdff00, expecting 0x100 ncr53c720-0: FATAL ERROR: CHECK SCSI BUS - CABLES, TERMINATION, DEVICE POWER etc.! ncr53c720-0: detaching... Stack Dump: 17fb8758: 17fb8758 00000202 0000000e 00000000 17fb8748: 10385f84 00000001 10385f84 00000020 17fb8738: 17ff8b2c 000000d0 17ff8b2c 1013efec 17fb8728: 00000001 17ff8b48 0000003c 17ff7800 17fb8718: 10385f84 00000202 0000000e 17fb83c0 17fb8708: 0000001a 00000194 00000000 00000040 17fb86f8: 17ff8b2c 000000d0 17ff8b2c 10106524 17fb86e8: 10090600 100906a0 10357000 17ff7800 17fb86d8: 17ff8bac 10385f84 00000202 00000001 17fb86c8: 103862c0 00002574 00002575 00000000 17fb86b8: 100e2568 000000d0 100e2568 10214844 17fb86a8: 00000001 100e2584 00000001 100e2568 17fb8698: 10094ac0 17ff0088 00000000 1033a000 17fb8688: 10468810 10397010 10370010 10391054 17fb8678: 00000004 000012c8 10454a18 101421fc 17fb8668: 00001329 10397010 10370010 103d11c0 17fb8658: 00000000 0000004d 10472478 ffffffff 17fb8648: 100e2568 00000080 00000001 f00000a4 17fb8638: f00000ac f00010f4 00000000 10141b60 17fb8628: 0000004d 00000000 103d11c0 10370010 17fb8618: 10453810 10385810 10453884 1037f5ec 17fb8608: 100e2568 100e2568 100e25d4 10391054 17fb85f8: 00000004 00001382 10454a18 1010b088 17fb85e8: 0000139c 10397010 100e2568 100e2584 17fb85d8: 00100100 00200200 17ee4034 10434810 17fb85c8: 10397010 10370010 103d11c0 f00000a4 17fb85b8: f00000ac f00010f4 00000000 101422c8 17fb85a8: 0000004d 00000000 17fb8488 00000002 17fb8598: 10090600 17ee4034 00000194 00000000 17fb8588: 4b5a0328 0000001f 100e25d4 103d11c0 17fb8578: 00000000 0000004d 000000fd 10257458 17fb8568: 1025ba9c 00000000 00000000 00000000 17fb8558: 00000000 00000000 00000000 00000000 17fb8548: 00000000 00000000 00000000 00000000 17fb8538: 41000000 00000000 40800000 00000000 17fb8528: 40000000 00000000 40000000 7fffffff 17fb8518: 41800000 00000000 40200000 00000000 17fb8508: 40200000 00000000 40300000 00000000 17fb84f8: 41000000 00000000 40800000 7fffffff 17fb84e8: 7fffffff 00000000 41000000 7fffffff 17fb84d8: 7fffffff 00000800 00000400 00000200 17fb84c8: 00000100 00000080 00000040 00000000 17fb84b8: 00000000 00000010 00000010 00000000 17fb84a8: 41800000 25b7ea20 45e69c6a 00000000 17fb8498: 00000000 e0000000 43ebebeb ffffffff 17fb8488: 7f7fffff 00000020 00000010 00000000 17fb8478: 00000000 00000000 00000000 00000000 17fb8468: 00000000 00000000 00000000 00000000 17fb8458: 0000001f 00000000 0000001f 00000000 17fb8448: 0000001f 00000000 000b0800 10142ce8 17fb8438: 17fb83c0 0000000b 00000000 1036e010 17fb8428: 00000000 17ffc360 000002c7 10082000 17fb8418: 0000000f 0000001f 00000036 0000001f 17fb8408: f00000a4 f00000ac f00010f4 00000000 17fb83f8: 000000fd 0000004d 00000000 103d11c0 17fb83e8: 10370010 ffffffed 17ff0000 00000022 17fb83d8: 10468810 1033a000 00000000 17ff0088 17fb83c8: 1025baa0 1025b800 000eff0f 100cd800 17fb83b8: fffffffb 10353000 10370528 f3f8c800 17fb83a8: 00000001 1033a000 10353000 00000022 17fb8398: 17ff0088 00000001 1033a000 10468810 17fb8388: 00000022 17ff0000 ffffffed 10391054 17fb8378: 00000004 000011b5 10454a18 103e7e64 17fb8368: 000011de 00000000 100864e0 10359e74 Kernel addresses on the stack: [<10124204>] copy_process+0x3d8/0x9f0 [<10106220>] parisc_terminate+0x60/0xb8 [<1013efec>] buffered_rmqueue+0xd8/0x164 [<10106524>] handle_interruption+0x2ac/0x5bc [<10214844>] serial8250_console_write+0x1ac/0x37c [<101421fc>] do_drain+0x18/0x28 [<10141b60>] slab_destroy+0x15c/0x214 [<1010b088>] intr_check_sig+0x0/0xc [<101422c8>] __cache_shrink+0x70/0xc0 [<10257458>] ncr_detach+0x0/0x374 [<103d11c0>] start_kernel+0x4/0x214 [<103e7e64>] zalon_probe+0x240/0x270 [<1010ecf8>] parisc_driver_probe+0x2c/0x60 [<10219dcc>] bus_match+0x48/0x80 [<10219f28>] driver_attach+0x70/0xa4 [<1021a1b0>] bus_add_driver+0x98/0xa8 [<101ec1b4>] pci_populate_driver_dir+0x30/0x38 [<1021a51c>] driver_register+0x48/0x54 [<103e7c14>] sym2_init+0x18/0x28 [<103d1438>] do_initcalls+0x58/0xdc [<10100400>] init+0x2c/0x144 [<1010ac5c>] ret_from_kernel_thread+0x1c/0x24 Kernel Fault: Code=26 regs=17fb83c0 (Addr=00000194) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000011101111111100001111 Not tainted r00-03 00000000 1025b800 1025baa0 17ff0088 r04-07 00000000 1033a000 10468810 00000022 r08-11 17ff0000 ffffffed 10370010 103d11c0 r12-15 00000000 0000004d 000000fd 00000000 r16-19 f00010f4 f00000ac f00000a4 0000001f r20-23 00000036 0000001f 0000000f 10082000 r24-27 000002c7 17ffc360 00000000 1036e010 r28-31 00000000 0000000b 17fb83c0 10142ce8 sr0-3 00000000 00000000 00000000 00000000 sr4-7 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: 1025ba9c 10257458 IIR: 4b5a0328 ISR: 00000000 IOR: 00000194 CPU: 0 CR30: 17fb8000 CR31: 103c6000 ORIG_R28: 00000000 IAOQ[0]: ncr53c8xx_release+0xc/0x20 IAOQ[1]: ncr_detach+0x0/0x374 RP(r2): ncr53c8xx_release+0x10/0x20 Now what do you thing foward pa20 or backward pa14? Thanks, Joel From rhirst@linuxcare.com Sun Sep 28 19:05:19 2003 From: rhirst@linuxcare.com (Richard Hirst) Date: Sun, 28 Sep 2003 19:05:19 +0100 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.6 willy In-Reply-To: <1064769945.10841.1.camel@mulgrave> References: <20030927072449.5AF0F494058@palinux.hppa> <20030928165631.GS5759@sleepie.demon.co.uk> <1064769945.10841.1.camel@mulgrave> Message-ID: <20030928180519.GT5759@sleepie.demon.co.uk> On Sun, Sep 28, 2003 at 12:24:26PM -0500, James Bottomley wrote: > On Sun, 2003-09-28 at 11:56, Richard Hirst wrote: > > Only because I didn't get it to work properly when I did the original > > 720 support, iirc. The chip does have INTFLY. I _think_ INTFLY worked > > a bit, but the driver tended to miss interrupts sometimes. Could easily > > have been a driver bug. Was a long time ago now though, so I could be > > misremembering. > > Actually, the 720 is bust in silicon. The 770 has a properly working OK - explains why it didn't work then. Cheers, Richard From willy@debian.org Sun Sep 28 20:23:23 2003 From: willy@debian.org (Matthew Wilcox) Date: Sun, 28 Sep 2003 20:23:23 +0100 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.6 willy In-Reply-To: <1064769945.10841.1.camel@mulgrave> References: <20030927072449.5AF0F494058@palinux.hppa> <20030928165631.GS5759@sleepie.demon.co.uk> <1064769945.10841.1.camel@mulgrave> Message-ID: <20030928192323.GL24824@parcelfarce.linux.theplanet.co.uk> On Sun, Sep 28, 2003 at 12:24:26PM -0500, James Bottomley wrote: > Actually, the 720 is bust in silicon. The 770 has a properly working > intfly, but the 720's doesnt work reliably. Actually, the Q720 board > this driver also drives is wired to have a special "intfly" from a board > register to get around the problem. Mmm, OK. Did you want me to put the SIMULATED_INTFLY conditionals back in? It wasn't much code; I've just been focused on ripping out all the 8xx support, and I completely forgot about the 770. -- "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 Sun Sep 28 20:25:43 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 28 Sep 2003 14:25:43 -0500 Subject: [parisc-linux] Re: [parisc-linux-cvs] linux-2.6 willy In-Reply-To: <20030928192323.GL24824@parcelfarce.linux.theplanet.co.uk> References: <20030927072449.5AF0F494058@palinux.hppa> <20030928165631.GS5759@sleepie.demon.co.uk> <1064769945.10841.1.camel@mulgrave> <20030928192323.GL24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <1064777144.10840.17.camel@mulgrave> On Sun, 2003-09-28 at 14:23, Matthew Wilcox wrote: > On Sun, Sep 28, 2003 at 12:24:26PM -0500, James Bottomley wrote: > > Actually, the 720 is bust in silicon. The 770 has a properly working > > intfly, but the 720's doesnt work reliably. Actually, the Q720 board > > this driver also drives is wired to have a special "intfly" from a board > > register to get around the problem. > > Mmm, OK. Did you want me to put the SIMULATED_INTFLY conditionals > back in? It wasn't much code; I've just been focused on ripping out > all the 8xx support, and I completely forgot about the 770. Perhaps. The way I'd envisaged going forwards was to put the Q720 code in there...it does a memory move which causes the card to trigger and interrupt which can be used as an INTFLY. Unfortunately, I lost all my Q770 cards in a lab move, so I've no means of testing them. James From soete.joel@tiscali.be Sun Sep 28 21:32:49 2003 From: soete.joel@tiscali.be (Joel Soete) Date: Sun, 28 Sep 2003 20:32:49 +0000 Subject: [parisc-linux] Re: zalon/ncr53c720 (linux-2.6.0-test5-pa22) broken on C110 In-Reply-To: <3F77227F.7000400@tiscali.be> References: <3F76A312.8090603@tiscali.be> <20030928122414.GF24824@parcelfarce.linux.theplanet.co.uk> <3F77227F.7000400@tiscali.be> Message-ID: <3F774571.6050100@tiscali.be> Joel Soete wrote: > Matthew Wilcox wrote: > >> The driver is rev 1.5 in -test5-pa6. rev 1.6 is in -test5-pa18. >> After -test5-pa20, we don't have anyautotagged stuff, but let's start >> with -pa18. >> >> >> > Sorry it already failled with following satck dump: > zalon_probe: Zalon vers field is 0x1, IRQ 34 > ncr53c720-0: rev 0xf on bus 0 device 0 function 0 irq 34 > ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential > ncr53c720-0: suspicious SCSI data while resetting the BUS. > ncr53c720-0: dp1,d15-8,dp0,d7-0,rst,req,ack,bsy,sel,atn,msg,c/d,i/o = > 0x3fdff00, expecting 0x100 > ncr53c720-0: FATAL ERROR: CHECK SCSI BUS - CABLES, TERMINATION, DEVICE > POWER etc.! > ncr53c720-0: detaching... > > Stack Dump: > 17fb8758: 17fb8758 00000202 0000000e 00000000 > 17fb8748: 10385f84 00000001 10385f84 00000020 > 17fb8738: 17ff8b2c 000000d0 17ff8b2c 1013efec > 17fb8728: 00000001 17ff8b48 0000003c 17ff7800 > 17fb8718: 10385f84 00000202 0000000e 17fb83c0 > 17fb8708: 0000001a 00000194 00000000 00000040 > 17fb86f8: 17ff8b2c 000000d0 17ff8b2c 10106524 > 17fb86e8: 10090600 100906a0 10357000 17ff7800 > 17fb86d8: 17ff8bac 10385f84 00000202 00000001 > 17fb86c8: 103862c0 00002574 00002575 00000000 > 17fb86b8: 100e2568 000000d0 100e2568 10214844 > 17fb86a8: 00000001 100e2584 00000001 100e2568 > 17fb8698: 10094ac0 17ff0088 00000000 1033a000 > 17fb8688: 10468810 10397010 10370010 10391054 > 17fb8678: 00000004 000012c8 10454a18 101421fc > 17fb8668: 00001329 10397010 10370010 103d11c0 > 17fb8658: 00000000 0000004d 10472478 ffffffff > 17fb8648: 100e2568 00000080 00000001 f00000a4 > 17fb8638: f00000ac f00010f4 00000000 10141b60 > 17fb8628: 0000004d 00000000 103d11c0 10370010 > 17fb8618: 10453810 10385810 10453884 1037f5ec > 17fb8608: 100e2568 100e2568 100e25d4 10391054 > 17fb85f8: 00000004 00001382 10454a18 1010b088 > 17fb85e8: 0000139c 10397010 100e2568 100e2584 > 17fb85d8: 00100100 00200200 17ee4034 10434810 > 17fb85c8: 10397010 10370010 103d11c0 f00000a4 > 17fb85b8: f00000ac f00010f4 00000000 101422c8 > 17fb85a8: 0000004d 00000000 17fb8488 00000002 > 17fb8598: 10090600 17ee4034 00000194 00000000 > 17fb8588: 4b5a0328 0000001f 100e25d4 103d11c0 > 17fb8578: 00000000 0000004d 000000fd 10257458 > 17fb8568: 1025ba9c 00000000 00000000 00000000 > 17fb8558: 00000000 00000000 00000000 00000000 > 17fb8548: 00000000 00000000 00000000 00000000 > 17fb8538: 41000000 00000000 40800000 00000000 > 17fb8528: 40000000 00000000 40000000 7fffffff > 17fb8518: 41800000 00000000 40200000 00000000 > 17fb8508: 40200000 00000000 40300000 00000000 > 17fb84f8: 41000000 00000000 40800000 7fffffff > 17fb84e8: 7fffffff 00000000 41000000 7fffffff > 17fb84d8: 7fffffff 00000800 00000400 00000200 > 17fb84c8: 00000100 00000080 00000040 00000000 > 17fb84b8: 00000000 00000010 00000010 00000000 > 17fb84a8: 41800000 25b7ea20 45e69c6a 00000000 > 17fb8498: 00000000 e0000000 43ebebeb ffffffff > 17fb8488: 7f7fffff 00000020 00000010 00000000 > 17fb8478: 00000000 00000000 00000000 00000000 > 17fb8468: 00000000 00000000 00000000 00000000 > 17fb8458: 0000001f 00000000 0000001f 00000000 > 17fb8448: 0000001f 00000000 000b0800 10142ce8 > 17fb8438: 17fb83c0 0000000b 00000000 1036e010 > 17fb8428: 00000000 17ffc360 000002c7 10082000 > 17fb8418: 0000000f 0000001f 00000036 0000001f > 17fb8408: f00000a4 f00000ac f00010f4 00000000 > 17fb83f8: 000000fd 0000004d 00000000 103d11c0 > 17fb83e8: 10370010 ffffffed 17ff0000 00000022 > 17fb83d8: 10468810 1033a000 00000000 17ff0088 > 17fb83c8: 1025baa0 1025b800 000eff0f 100cd800 > 17fb83b8: fffffffb 10353000 10370528 f3f8c800 > 17fb83a8: 00000001 1033a000 10353000 00000022 > 17fb8398: 17ff0088 00000001 1033a000 10468810 > 17fb8388: 00000022 17ff0000 ffffffed 10391054 > 17fb8378: 00000004 000011b5 10454a18 103e7e64 > 17fb8368: 000011de 00000000 100864e0 10359e74 > > Kernel addresses on the stack: > [<10124204>] copy_process+0x3d8/0x9f0 > [<10106220>] parisc_terminate+0x60/0xb8 > [<1013efec>] buffered_rmqueue+0xd8/0x164 > [<10106524>] handle_interruption+0x2ac/0x5bc > [<10214844>] serial8250_console_write+0x1ac/0x37c > [<101421fc>] do_drain+0x18/0x28 > [<10141b60>] slab_destroy+0x15c/0x214 > [<1010b088>] intr_check_sig+0x0/0xc > [<101422c8>] __cache_shrink+0x70/0xc0 > [<10257458>] ncr_detach+0x0/0x374 > [<103d11c0>] start_kernel+0x4/0x214 > [<103e7e64>] zalon_probe+0x240/0x270 > [<1010ecf8>] parisc_driver_probe+0x2c/0x60 > [<10219dcc>] bus_match+0x48/0x80 > [<10219f28>] driver_attach+0x70/0xa4 > [<1021a1b0>] bus_add_driver+0x98/0xa8 > [<101ec1b4>] pci_populate_driver_dir+0x30/0x38 > [<1021a51c>] driver_register+0x48/0x54 > [<103e7c14>] sym2_init+0x18/0x28 > [<103d1438>] do_initcalls+0x58/0xdc > [<10100400>] init+0x2c/0x144 > [<1010ac5c>] ret_from_kernel_thread+0x1c/0x24 > > > Kernel Fault: Code=26 regs=17fb83c0 (Addr=00000194) > > YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI > PSW: 00000000000011101111111100001111 Not tainted > r00-03 00000000 1025b800 1025baa0 17ff0088 > r04-07 00000000 1033a000 10468810 00000022 > r08-11 17ff0000 ffffffed 10370010 103d11c0 > r12-15 00000000 0000004d 000000fd 00000000 > r16-19 f00010f4 f00000ac f00000a4 0000001f > r20-23 00000036 0000001f 0000000f 10082000 > r24-27 000002c7 17ffc360 00000000 1036e010 > r28-31 00000000 0000000b 17fb83c0 10142ce8 > sr0-3 00000000 00000000 00000000 00000000 > sr4-7 00000000 00000000 00000000 00000000 > > IASQ: 00000000 00000000 IAOQ: 1025ba9c 10257458 > IIR: 4b5a0328 ISR: 00000000 IOR: 00000194 > CPU: 0 CR30: 17fb8000 CR31: 103c6000 > ORIG_R28: 00000000 > IAOQ[0]: ncr53c8xx_release+0xc/0x20 > IAOQ[1]: ncr_detach+0x0/0x374 > RP(r2): ncr53c8xx_release+0x10/0x20 > > Now what do you thing foward pa20 or backward pa14? > Well: hpalin login: root Password: Last login: Sun Sep 28 21:48:39 2003 on ttyS0 Linux hpalin 2.6.0-test5-pa14 #1 Sun Sep 28 22:10:24 CEST 2003 parisc GNU/Linux So break is in patch...-pa14-pa18 (if I am lucky I could check it next week :) ) Joel From cqnvhai@163.com Sun Sep 28 22:18:19 2003 From: cqnvhai@163.com (=?GB2312?B?1b7U2rSwx7C1xMWuuqI=?=) Date: Mon, 29 Sep 2003 05:18:19 +0800 Subject: [parisc-linux] =?GB2312?B?1b7U2rSwx7C1xMWuuqKjrM34wufRsMv7?= Message-ID: <20030928211601.312A348DB@dsl2.external.hp.com> Õ¾ÔÚ´°Ç°µÄÅ®º¢ ÂþÑÛµûÓ°ÓͲ˻¨³£¿ª£¬¿ÉÁ¯¹ËÓ°Á¦±¡ÉíÖ»µ¥¡£ Àú¾­²×É£½ÙÊýÓип®£¬·½ÖªÈ˺£ÖªÒôʵÄÑÀÀ£¡ ½ñÈÕ÷öÈ»Á÷ÂäÖÁ¹ãÖÝ£¬ÐÄÉËÌåÀÛ¾Ù²½¸ü¼èÄÑ¡£ Äú¿ÉÊÇËýÍ£²´µÄ¸ÛÍ壿Äú¿ÉÊÇËýÃÎÀïµÄɳ̲£¿ Õ¾ÔÚ´°Ç°µÄÅ®º¢ Ö»¹Ö¼Ò¸¸Áô²ÆÓÐǧÍò£¬ÒýµÃ²®¸¸ÒªÇ°À´ÕùÕ½£¬ ²®¸¸Ò°Âù¶ù¶à¸üºÃÕ½£¬¶ÀÉú°®Å®Ó¦¶Ô·³¸ü²ø¡£ ¸ÐлºÃÐÄÂÉʦ°ïËßËÏ£¬Ö»µÈʮԿªÍ¥À´ÉóÅС£ Ë­»áÊÇËýÉËÐĵÄÊÍÈ»£¿Ë­»áÊÇËýÃÎÀïµÄÅÇ»²£¿ Õ¾ÔÚ´°Ç°µÄÅ®º¢ ½ñÄê·¼Áä¶þÊ®ÓÖÓÐÈý£¬Ï²¶ÁÊ«ÊéÎÂÈáÐÄ·ðÉÆ¡£ Ðĸß×ÝÓмҲÆÍòǧ¹Þ£¬ÉíÍâÎïÒ²ÄÜĮȻ¿´µ­£¡ ÁÚ˵×ӳи¸Òµ·½ÎªÐ¢£¬¾­Óª²ÅÊ軹ÐèÁíÒ»°ë¡£ Ë­»áÊÇÎÒ¿ìÀֵĿ¿É½£¿Ë­»áÊÇÎÒǧÄêµÄµÈ´ý£¿ Õ¾ÔÚ´°Ç°µÄÅ®º¢ ²»Çó·ò¾ýòÈô¸ß²Ö½¡£¬²»ÏÓ°é¿áËÆÅ˳¤½­¡£ ÐÄÒÑÀÛ£¬ÉíÆ£±¹£¬´í°ÑÐÄËáµ±ÇÙµ¯ Ò»±­²è£¬¼¸±¾Ê飬ÊÍÈ»ÓÚÊÖÀáÒÑÁ÷ µ«Ô­Á½ÇéÏàÔÃÈ˳¤¾Ã£¬Ç§ÀïÒöÔµ¶÷°®ÊÄÎÞÐÝ£¡ Õ¾ÔÚ´°Ç°µÄÅ®º¢ 03Äê8ÔÂ28ÈÕÆüÊéÓÚ¹ãÖÝ Email:cqnvhai@163.com http://www.blogcn.com/blog/?u=cqnvhai ¸¸Ç×ÊÇÒ»¸öºÃ¸¸Çס£ ¸¸Ç×°ËËêÄÇÄê±»×æĸ´øµ½·¨¹úÈ¥ÁË£¬¹úÄÚÖ»ÁôÏÂÒ»¸ö×游ºÍÒ»¸ö¸ú¸¸Ç×ͬ¸¸ÒìĸµÄ²®¸¸¡£Ä¸Ç×ÊǶ¨¾Óµ±µØ¶àÄêµÄ»ªÈË¡£¸¸Ç׺ܰ®Ä¸Ç×£¬Ä¸Ç×Ò²ºÜ°®¸¸Çס£Ìý¸¸Ç×ÿһ´Î½²µ½Ä¸Ç×ʱÎÒ×ÜÄܸоõµ½ÄÇ·ÝÉîÇéÄǷݾìÁµ¡£Ò²ÊÇÔÚÎÒ8ËêÄÇÄ꣬×æĸºÍĸÇ׳ö½ÖʧÊÂÓÚ³µ»ö¡£¼ÒÍ¥µÄͻȻ±ä¹Ê£¬Ä¸°®ºÍÇé°®µÄʹʧ£¬¸øÓèÁ˸¸Ç׳ÁÖصĴò»÷£¬Í¬Ê±Ò²ÊÇ»ùÓÚ¶Ô¹ÊÍÁ×游µÄ˼Ä¸¸Ç×´ø×ÅÎһص½ÁËÖйú³¤É³¡£ ³¤´óµ½ÏÖÔÚ£¬Í¯ÄêµÄ·¨¹úºÍĸÇ×ÔÚÎҵļÇÒäÀïÖ»ÊÇÒ»¸öÄ£ºý¶øÃÀÀöµÄ¼ôÓ°¡£Î¨Ò»Ó¡Ïó×îÉîµÄÊÇ¿´×ÅĸÇ×µÄÏàƬ£¬»¹ÄÜ»ØÒäÆðĸÇ×Õ¾ÔÚÎÒ´²Ç°µÄ΢Ц¡£¸¸Ç×ÔÚÎÒͯÄêʱÎʹýÎÒÒª²»ÒªÐÂÂèÂ裬ÎҾܾøÁË¡£ÓÚÊǸ¸Ç×±ã°ÑËûÈ«²¿µÄÃÎÏëºÍÏ£Íû¼ÄÍÐÔÚËûΨһµÄÅ®¶ùÉíÉÏ£¡Ö±µ½½ñÌìÎÒ²ÅÕæÕýÀí½â¸¸Ç׺ÍÎÒÔÚ³¤É³µÄÊ®ÎåÄêÀ´£¬¸¸Ç×Ö®ËùÒÔ²»ÔÙÖØнá»é£¬ÊÇÒòΪ¶ÔÓÚĸÇ×ÉîÉîµÄ¾ìÁµºÍ¿Ì¹ÇÃúÐĵĸÐÇéÊÄÑÔ¡£Ê®ÎåÄêÀ´£¬¸¸Ç×ÕûÕûΪĸÇ×ÊعÑÁËÊ®ÎåÄ꣬¸¸Ç×Ò²´ÓÒ»¸öÖÐÄêÄÐÈ˱ä³ÉÁËÒ»¸öÀÏÈË¡£¸¸Ç×ÊÇÒ»¸öÐÔÇéÖÐÈË£¬¸¸Ç×Ò²ÊÇÒ»¸öÓÐÇéÊØÐŵÄÈË¡£¶ÔÓںöĵÄ×游ºÍÄ°ÉúµÄ²®¸¸¸¸Ç×Ò²¸øÓèÁ˾¡¿ÉÄܵİïÖú¡£¿ÉÊÇÎÒ´ÓÀ´¶¼²»Ï²»¶È¥×游¼Ò£¬Ê®ÎåÄêÀ´ÎÒֻȥ¹ýËĴΣ¬ºóÁ½´Î¶¼ÊǸ¸Ç×ÍÏ×ÅÈ¥µÄ¡£ Ôø¾­Îʹý¸¸Ç×ÎÒÊDz»ÊÇÒ»¸öºÜÆæ¹ÖµÄÅ®º¢£¬¸¸Ç×΢ЦןæËßÎÒ£ºÄãÒ»µã¶¼²»Ææ¹Ö£¬ÄãÖ»ÊÇÒ»¸ö¶à³îÉƸеÄÌì²Å¡£Ã»ÓÐÈËÄܹ»ÏóÄãÕâÑùÕæÕý¶ÁµÃ¶®»¨¶ùΪʲô»áÊ¢¿ª£¬Ã»ÓÐÈËÄܹ»ÏóÄãÕâÑùÕæÕýÃ÷°×ºûµûΪʲô»áÔÚÖ©ÖëÍøÉϾÀ²ø£¬Ò²´ÓÀ´Ã»ÓÐÈËÄܹ»ÏóÄãÕâÑù´ÓСµ½´óʼÖÕ¼áÐÅÊ¥µ®ÀÏÈ˵ĴæÔÚ¡£ÕâЩ¶¼ÊÇÄãµÄÓŵãÄã²»ÒªÇáÒ׵Ķª¿ª£¬°Ö°ÖΪÓÐÄãÕâÑùµÄÅ®¶ù¶ø¸ßÐË×ÔºÀ¡£ Êǵģ¬ÎÒÊÇÒ»¸ö²»ºÏȺ¸ú±ðÈ˲»Ò»ÑùµÄÆæ¹ÖÅ®º¢£¬×øÔÚ¸¸Ç׵ijµÀïÎһῴ×Å´°ÍâµÄ³µÅÆËã24·¢´ô£¬¿´×ųÇÊеÄÒ¹ÍíÎÒÄÜÏóµ¹×Å¿´±¨Ö½Ò»Ñù´ÓÁíÍâÒ»¸ö½Ç¶È¿´·ç²Ê£¬ÎÒ×ÜÄÜÔÚ±»ÈËÒÅÍüµÄÊÀ½çÀï¾²¾²µÄÕÒµ½×Ô¼ºµÄ¿ìÀÖ»ï°é¡£Ôø¾­¸úן¸Ç×µ½¹«Ë¾ÀïÈ¥¸Ð¾õ³ýÁËÈË»¹ÊÇæµµÄÈË£¬ÎÒÎʸ¸Ç×ÊDz»ÊÇÒÔºóÎÒÒ²ÒªÕâÑùÉϰ๤×÷£¿¸¸Ç×ÅÄ×ÅÎҵļç°ò˵£ºÄãÊÇÉϲԴ͸øÎÒµÄÌìʹ£¬Äã²»ÊôÓÚÕâ¸öÊÀ½çÄãÊDz»ÐèÒª¹¤×÷µÄ£¬°Ö°Ö»á¸øÄã×¼±¸×ã¹»µÄÇ®£¬ÄãÖ»Òª×öÄãϲ»¶×öµÄÊ£¬ÄãµÄ¿ìÀÖÄãµÄЦÈݾÍÊÇ°Ö°Ö×î´óµÄÃÎÏ룬µÈÄãÔÙ´óÒ»µã£¬°Ö°Ö»¹Òª°ÑÄãËùÓеÄÈռdzö°æ³ÉÊ飬ÄãÔ¸ÒâÂð£¿ÎÒÔ¸Ò⣬ÎÒ´ð¡£ ¸Ðл¸¸Ç×ÈÃÎÒÒÂʳÎÞÓÇ£¬¸Ðл¸¸Ç×ÈÃÎÒ´ÓÀ´Ã»ÓÐΪǮ¶ø·¢³î£¬¸Ðл¸¸Ç׸øÁËÎÒÒ»¸ö¿ìÀֵĴó»¨Ô°£¬¸¸Ç××ÜÊÇÌÛÎÒ³èÎÒ˳×ÅÎÒ¡£µ«ÊǽñÌìÕâÒ»Çж¼ÒѾ­²»¸´´æÔÚ¡£Ò»¸öÅ®º¢£¬Ò»¸öÏóÎÒÕâÑùµÄÅ®º¢£¬Ò»¸öÍÑÀëÁ˸¸Ç׵İ®×Ô¼ºÕû¸öÊÀ½ç¾Í»á±»À£ÃðµÄÅ®º¢£¬ÃÎÒѲУ¬»¨ÒÑ°Ü£¬Õâ¿ÉÊÇÀ´×ÔÌì¹úµÄÕÙ»½£¿°ëÄêÀ´£¬ÕûÀí¸¸Ç×µÄÒÅÎïºÍ×Ô¼ºµÄÈռǣ¬´Ë¼ä´´É˸п®ÓÖÓÐË­Äܹ»ÕæÕýÃ÷°×£¿ÎÒÖÕÓÚÃ÷°×ÎÒÊǸ¸Ç×ËùÓеÄÃÎÏëºÍÏ£ÍûËùÔÚ£¬¶ÔÓÚ¸¸Ç××îºÃµÄ»Ø±¨ºÍ¾¡Ð¢¾ÍÊÇÞ¬Ñܺó´úÕÒµ½ÁíÍâÒ»°ë£¬²¢ÇÒÈÃ×Ô¼º¿ìÀÖµÄÉú»îÏÂÈ¥¡£ Õ¾ÔÚ´°Ç°µÄÅ®º¢¾­Àú¾ÍÊÇÕâÑù¼ò¼òµ¥µ¥¡£¾ÍÊÇÕâÑùÒ»¸öÅ®º¢×ÜÊÇÄÇôϡÆæ¹Å¹Ö£¬¾ÍÊÇÕâÑùÒ»¸öÅ®º¢×Ü»á±ð³öÐÄÔÔ£¬ËäÈ»²»»áÈȹø×ö·¹²»»á´©Ò´ò°ç£¬ËäÈ»²»½âÈËÇéÊÀ¹Ê²»¶®ÓÍÑÎÃ×´×£¬Ö»ÒòΪÕâÒ»ÇиüÒѳÉÏ°¹ß£¡ ÓÐÐĸģ¬¸Ä²»ÄÑ£¬¾ÍÈÃÎÒ·ÅÆúÃÎÀïµÄɳ̲ΪÄú¾«ÐÄ´ò°ç£¬¾ÍÈÃÎÒѧ»áÈËÇéÊÀ¹ÊÌý´ÓÄúÃÀÀöµÄ°²ÅÅ¡£Õ¾ÔÚ´°Ç°ÃÀÀöµÄÅ®º¢£¬ÓÐË­Ô¸ÒâΪÕâÑùÒ»¸öÅ®º¢Èýǧ³è°®£¿ÓÐË­Ô¸ÒâΪÕâÑùÒ»¸öÅ®º¢·ÅÆúÏÖÔÚÈ¥×·ÇóÁíÍâÒ»¸ö¾«²Ê£¿ÓÐË­Ô¸ÒâΪȢÕâÑùÒ»¸öÅ®º¢È·Êµ½ñÉúÎÞº¶£¿Ã£Ã£µÄÈ˺£Çë¸æËßÎÒ×îÕæʵµÄ´ð°¸£¡ ÐÄÒÑÀÛ£¬Ìå¸ü±¹£¬Á÷Âä¹ãÖÝ£¬Ê³ËÞÀ§ÄÑ£¬ÄѵÀÕâЩÕæµÄÊÇÀ´×ÔÌì¹úµÄÕÙ»½£¿£¿ Õ¾ÔÚ´°Ç°µÄÅ®º¢ÁõÔÆ 03Äê9ÔÂ1ÈÕÇ峿ÃÔãÓÚ¹ãÖÝ ÓÖÊÇÔÚÖÔÐĵÄÆÚ´ý£¬ÓÖÊÇÔÚÈ˺£Ñ°ÕҴ𰸡£×òÌ컹ÊÇÑô¹â²ÓÀ㬽ñÌì¾ÍÎÚÔƲ»É¢£¬¹ãÖݵÄÌì˵±ä¾Í±ä£¬Ì¨·ç˵À´¾ÍÀ´¡£¾ÍÊÇÕâÑùÒ»¸öÒ¹Íí£¬ÁõÔÆÄÜ×öʲô£¿Á÷Âä¹ãÖÝ£¬Éú»î¾Ù²½¼èÄÑ£¬ÊÖ»úÒ²ÂôÁË£¬ÏÂÒ»´ÎÎÒ»¹ÄÜÂôʲô£¿´ÓС½¿Éú¹ßÑø£¬´ÓС²»ÖªÇ®ÎªºÎÎ´ÓС¾ÍÒÔΪǮ¾ÍÊÇ¿¨ÀïÃæÓò»ÍêµÄ³®Æ±¡£Ëæן¸Ç×µÄÀëÈ¥£¬¸¸Ç׸øµÄ¿¨Àï¾ÍÔÙҲûÓÐǮͳöÀ´¡£Êǵģ¬¸¸Ç×Ì«°®ÎÒÁË£¬ÒòΪÎÒ²»Ï²»¶Ä°ÉúÈË£¬ËùÒÔ¸¸Ç×Ò²´ÓÀ´²»»á°ÑÄ°ÉúÈË°üÀ¨Ëû¹«Ë¾ÀïµÄÈË´ø»Ø¼Ò£»ÒòΪÎÒÌ«¹ÂƧ£¬ËùÒÔ´ÓÅ®Öе½´óѧ£¬ÎÒҲûÓÐʲô֪ÐĵÄͬ´°ºÃÓÑ¡£ÎÒ×ÜÊÇÒ»¸öÈËĬĬµÄÉú»îÔÚ×Ô¼ºµÄÊÀ½çÀ¿´×ŷ仨ѩÔ£¬¿´×ÅСÊ÷·¢Ñ¿£¬´ÓÖÐд϶ÔÓÚÉúÃüÂúÐĵÄÔÞ̾¡£ Ôø¾­Ò²Ï²»¶¹ýÒ»¸öÄк¢£¬µ«ÊÇËû¾¹È»²»ÏàÐÅÊ¥µ®ÀÏÈ˵ĴæÔÚ£¬¸øËûÒ»ÕÅA4Ö½ÈÃËûÍÚÒ»¸öԲȦ´óµ½¿ÉÒÔ°ÑÁ½¸öÈ˵ÄÄÔ´ü×°½øÈ¥£¬ËûÈ´²»ÖªµÀ¸ÃÔõô×ö£¬Òò´Ë¶þÊ®ÈýÄêÀ´¶¼²»Ôø̸¹ýÁµ°®£¡ Êǵġ£¾ÍÊÇÕâÑùÒ»¸öÅ®º¢£¬¾ÍÊÇÕâÑùÒ»¸öÁõÔÆ£¬Éú»îÔÚÃÎÀïÉú»îÔÚÓëÊÀ¸ô¾øµÄÊÀ½ç£¬Ãæ¶Ô½ñÌìµÄÀ§¾³£¬¸¸Ç×ÓдíÂð£¿Ëû¸øÎÒÌṩ×îºÃµÄÉú»î±£ÕÏ£¬ËûÈÃÎÒ×öÎÒϲ»¶×öµÄÊ£¬ÄѵÀÕâÒ²ÓдíÂð£¿ÁõÔÆÓÖÓдíÂð£¿ÁõÔƲ»Ï²»¶³Ô¼¦È⣬ֻÒòΪ¼¦Èâ»áÈÃÁõÔÆÏëÆ𼦱»É±Ê±¼¦Í´¿àµÄÑÛÀᣬÁõÔÆ¿´µ½½ÖÉÏ×øÔÚµØÉϵÄÀÏÈË£¬ÁõÔÆ»á°ÑÉíÉÏËùÓеÄÇ®¶¼¸øËý¡£ÄѵÀÁõÔÆËùÓеÄÕâÒ»Çж¼ÊÇ´íÎóµÄ±íÏÖ£¿ÒòΪÁõÔƵÄÑÛ¾¦Àï¿´µ½µÄÊÀ½ç¶¼Êǵ¹Á¢µÄÆû³µ¡¢µ¹Á¢µÄÂ¥·¿¡¢µ¹Á¢µÄÈË¡¢ÎÒ¸ú±ðÈ˲»Ò»Ñù£¬ËùÒÔ¸¸Ç×ÈÏΪÎÒ²»ÊôÓÚÕâ¸öÊÀ½ç¡¢ÁõÔÆÄܹ»¸øÕâ¸öÊÀ½ç´øÀ´µÄÊÇÒìÓÚ³£È˵Ä˼άºÍ¹Ûµã¼û½â¡£ÒòΪÕâЩ¸¸Ç×ÈÏΪÎÒÄܹ»°´ÕÕ×Ô¼ºµÄÒâԸȥ×öÊÂÈ¥Éú»îÊÇÉϲԴ͸øÉúÃüµÄ×î´ó±¨´ð¡£¾ÍÊÇÕâÑùÒ»¸öÁõÔÆ£¬Ë­ÄܸæËßÎÒÁõÔÆÓ¦¸ÃÔõô×ö£¿ ʮԣ¬·¨Í¥ÉóÅеÄÈÕ×Ó£¬ÁõÔÆ»áÒÔ²»¼ÇÃûµÄ·½Ê½°Ñ¸¸Ç×ËùÓеIJƲú¾èÔù¸øËùÓÐÏóÁõÔÆÒ»ÑùÎÞÒÀÎÞ¿¿ÐèÒª°ïÖúµÄÉÆÁ¼µÄÈË¡£Í¬Ñù½ñÌìµÄÁõÔÆÉú»îÒ²ºÜ¼èÄÑÒ²ºÜÐèÒª°ïÖú£¬ÁõÔÆÈÏΪ¸øËùÓÐÉÆÁ¼µÄÈËÃÇÓèÒÔÐÐÉƵĻú»á£¬Ò²ÊÇÉϲԴ͸øÁõÔƵÄÉƾ٣¬ÁõÔÆÀÖÒâÒÔÌرðµÄ˼ά´ÓÁíÒ»¸öÊÓ½ÇÈ¥°ïÖúÄÇЩÓÐÀ§»óµÄÉÆÁ¼ÈË£¬½è´ËÖ¤Ã÷ÁõÔÆ´æÔڵļÛÖµ£¡ ÖÔÐÄ×£¸£ËùÓÐÉÆÁ¼µÄÈËÃÇ£¬¸ÐлËùÓÐÔ¸Òâ°ïÖúÁõÔƵÄÉÆÁ¼ÈË£¬½çʱÁõÔÆ»áÒÔÌرðµÄ·½Ê½ÖÂÒÔËùÓÐÔø¾­°ïÖú¹ýÁõÔƵÄÈË×îÉñÃصÄÀñÎÄÇЩºÃÐĵÄÈË¡¢ÄÇЩ²»»á³°Ð¦ÄÇЩÄܹ»Àí½âÊ¥µ®ÀÏÈË´æÔÚµÄÉÆÁ¼ÈË£¡ Êǵģ¬Õ¾ÔÚ´°Ç°µÄÅ®º¢È·Êµ´æÔÚ£¬ÁõÔÆȷʵÉú»îÔÚÕâ¸öÏÖʵµÄÊÀ½çÀ֮ËùÒÔÄúÎÒ²»Í¬ÊÇÒòΪÎÒÃǶ¼Ã»ÓÐÕ¾ÔÚ´°Í⣡Êǵģ¬ÍøÂç³äÂú×ÅÏÝÚåºÍÐé¼Ù£¬ÁõÔÆÒ²¸úÄúÒ»ÑùÑ°ÕÒ×ÅÕæʵµÄÉÆÁ¼£¡ Õ¾ÔÚ´°Ç°µÄÅ®º¢ÁõÔÆ Email:cqnvhai@163.com 03Äê9ÔÂ3ÈÕÁ賿 ÎÞÖúÓÚ¹ãÖÝ Êǵģ¬ÁõÔƵÄÈ·ÊÇÒ»¸öºÜÆæ¹ÖµÄÅ®º¢×Ó¡£ Ìý¸¸Ç×˵»¹ÔÚÎÒ3ËêʱÎҾͺÜϲ»¶²ÊÉ«»­Æ¬£¬¿ÉÊǸ¸Ç×È´·¢ÏÖÎÒ×ÜÊÇ°Ñ»­Æ¬µ¹¹ýÀ´¿´£¬ÓÚÊǸ¸Ç׾Ͱѻ­Æ¬×ªÕý¹ýÀ´¸øÎÒ¿´£¬¿ÉÊÇÎÒ»¹ÊÇÒªµ¹¹ýÀ´¿´¡£¸¸Ç׾ͻ³ÒÉÎÒµÄÑÛ¾¦³öÁË벡¾Í´øÎÒÈ¥¿´Ò½Éú¡£Ò½ÉúµÄ½áÂÛÊÇ£ºº¢×Ó°ÑͼƬµ¹¹ýÀ´¿´µÄÏÖÏ󣬳ÆΪµ¹ÊÓ¡£µ¹ÊÓÊÇÒ»ÖÖһʱÐÔÉúÀíÏÖÏó£¬ÎÒÃǵÄÑÛÇòÏñÒ»¼ÜÕÕÏà»ú£¬Íâ½çÎïÌåµÄ¹âÏߣ¬¾­¹ý¾Û½¹ºó£¬ÔÚÊÓÍøĤ£¨Ï൱ÓÚÕÕÏà»úµÄµ×Ƭ£©ÉÏÐγÉÒ»¸öµ¹Ïñ¡£µ«ÊÇ£¬Õâ¸öµ¹Ïñ´«µ¼µ½´óÄÔµÄÊÓ¾õÖÐÊ࣬¾­¹ý×ۺϷÖÎö£¬µ¹Ïñ±ã±»¾ÀÕýÁË¡£3ËêÒÔϵÄÓ׶ù£¬ÓÉÓÚÆä´óÄÔƤÖʹ¦ÄÜÉÐδ·¢Óý½¡È«£¬È±·¦ÍêÉƵÄ×ۺϷÖÎöÄÜÁ¦£¬ËùÒÔËûÃÇ¿´µ½µÄͼÏñ¶¼Êǵ¹µÄ£¬Ö»Óаѻ­Æ¬µ¹¹ýÀ´¿´£¬²ÅÄܸÐÊܵ½ÕýλµÄÎïÏñ¡£²»¹ý£¬Õâ¶Îʱ¼äºÜ¶Ì£¬Ëæ×Å´óÄÔƤÖʹ¦ÄÜÍêÉÆ£¬µ¹ÊÓÏÖÏó¾Í×ÔÈ»¶øÈ»ÏûʧÁË¡£ ¿ÉÊÇÕâ¸öʱ¼ä¶ÔÓÚÁõÔÆÈ´ÊÇÓÀÔ¶£¬Ö±µ½½ñÌìÁõÔÆ¿´ÊÀ½ç£¬»¹Êǵ¹×ŵġ£µ¹×ŵķ¿×Ó¡¢µ¹×ŵÄÂí·¡¢µ¹×ŵÄÐÐÈË¡¢Ìì¿Õ°ÑÒ»ÇÐÍùµØÉÏÍÆ£¬·É»úµôÔÚÌì¿ÕÀÄñ¶ùÔÚŬÁ¦µÄ°ÚÍÑÌì¿ÕµÄÊø¸¿£¬Ò»ÇеÄÒ»ÇÐÔÚÁõÔÆ¿´À´×ÜÊÇÓëÖÚ²»Í¬¡£ÁõÔÆÉõÖÁ²»ÄÜ·Ö±æ³öÉÏÏÂ×óÓÒ£¬ÁõÔƹýÂí·½Ï³£È˶¼»áÊÇÒ»¸öΣÏյľٶ¯£¬ºÜ¶àÊÂÇéÔÚ³£ÈË¿´À´ÊÇÀíËùµ±È»µÄÊÂÇ飬¿ÉÊÇÁõÔÆ»áÓв»Í¬µÄ¿´·¨¡£Ò²ÐíÕâ¾ÍÊÇÁõÔƵÄÌرð£¬Ò²ÐíÕâ¾ÍÊÇÁõÔƶà³îÉƸеÄÓÉÀ´¡£ÁõÔÆÖªµÀ×Ô¼º²»ÊʺϹ¤×÷£¬¸úÆäËûÈ˳ª·´µ÷ÊDz»ÊʺϹ¤×÷µÄ¡£ ¾ÍÊÇÕâÑùµÄÒ»¸öÁõÔÆ£¬Ë­ÄܸæËßÎÒÎÒÄÜ×öʲô£¿Ë­ÄܸæËßÎÒÎÒ¸ÃÔõô×ö£¿¾ÍÊÇÕâÑùÒ»¸ö»îÉúÉúµÄÁõÔÆ£¬µ½µ×¸ÃºÎÈ¥ºÎ´Ó£¿Ê§È¥¸¸Ç×µÄÈÕ×Ó£¬ÓÐË­Äܹ»Àí½âÓÐË­Ô¸ÒâÏàÐÅÓÐË­Ô¸ÒâºÇ»¤ÓÐË­Ô¸Òâ³è°®£¿¾ÍÊÇÕâÑùµÄÒ»¸öÅ®º¢£¬¾ÍÊÇÕâÑùÒ»¸öÆæ¹ÖµÄÅ®º¢£¬È·Êµ»îÉúÉúµÄ´æÔÚ£¡ ÐÄÀÛÁË£¬Á÷Âä¹ãÖÝȷʵÀÛÁË£¬Óþ¡ÁËÅ̲ø£¬ÄÄÀïÊǸÛÍ壿ÄÄÀïÊǹéËÞ£¿ µ±Ê§ÂäµÄʱºò¡¢µ±ÉËÐĵÄʱºò¡¢µ±±ËÁÙ¾øÍûµÄʱºò£¬ÄúÎÒÏàͬµÄµØ·½Ò²Ðí¶¼»á°ÑÏ£Íû¼ÄÍиøδÀ´£¬Î´ÖªµÄδÀ´£¡ÊǵÄÕ¾ÔÚ´°Ç°µÄÅ®º¢ÔÚ¿à¿àµÄÑ°ÕҴ𰸣¡ Õ¾ÔÚ´°Ç°µÄÅ®º¢ÁõÔÆ 03Äê9ÔÂ7ÈÕÉîÒ¹ÓÚ¹ãÖÝ ÀÇÐгÉË«£¬Ä¸ÀÇֻΪ¹«ÀǶø´æÔÚ£¡ÁõÔÆÖªµÀÈ¡ÔÃÓÚËùÓеÄÈËÊDz»¿ÉÄܵģ¬ÔÚÕâ¸öÊÀ½çÖ»ÒªÓÐÒ»Á½¸öÈËÐÀÉ;ÍÒÑ×ã¹»£¡ÈËÉú»îÔÚÊÀÉÏÄ¿µÄºÎÔÚÒâÒåºÎÔÚ£¿Ò»¸öÈËÔÙÔõôÄܸÉÔÙÔõôǿº·£¬¶¼ÊÇÏ£ÍûÄܹ»µÃµ½Éç»áºÍËûÈ˵ÄÈÏͬ£¬ÌرðÊÇ×Ô¼ºÏ²»¶µÄ×Ô¼ºÉî°®µÄÈ˵ÄÈÏͬºÍÐÀÉÍ,ËùÒԲŻáÓаÔÍõ±ð¼§¡¢ÃϽªÅ®Ç§ÀïÑ°·òµÄǧ¹Å´«Æ棡µ«ÎÊÌâÊÇͨ¹ýʲôÑùµÄ·½Ê½ºÍÇþµÀÕÒµ½Õâ¸öÈËÕÒµ½×Ô¼ºÖµµÃÒ»Éú¸¶³öµÄ×î°®£¿Èç¹ûÖ»Êǵȴý×Ô¼º²»¾­Òâ¼äµÄ»ØÄÀ¡¢»ÃÏë×Å×Ô¼ºÒ»¸öżȻµÄåâåË£¬ËäÈ»´Ë¼äÇé¾°ºÜÃÀ£¬µ«¶ÔÓÚÁõÔÆÕâÑùÒ»¸ö²»³¤ÓÚÉç»á»î¶¯µÄÈËÈ´²»ºÏÊÊ¡£ÁõÔÆÖªµÀ×Ô¼ºµÄ³¤´¦ºÍ¶Ì°å£¡ÁõÔÆÖ»ÊÇÏëÕÒÒ»¸öÄܹ»ÐÀÉÍ×Ô¼ºÈÏͬ×Ô¼ºµÄÈËÐÅÊØÒ»Éú£¬ÁõÔÆÔ¸ÒâΪÕâÑùÒ»¸öÄÐÈË·îÏ×ËùÓжøÎÞÔ¹ÎÞ»Ú£¬ÁõÔÆÐÄÖÐ×°×ŵÄÖ»ÊdzÕÇéºÍ¸Ð¶÷£¡ ÊǵÄÁõÔƺÜÃÀ¡£ÁõÔÆÓг¬ºõÄúÏëÏóµÄÃÀÀöÈÝÑÕ£¡µ«ÊÇÁõÔÆÈÏΪÔÙÃÀµÄÈÝÑÕ¶¼»áÓÐË¥ÀϵÄÒ»Ì죬ÔÙÃÀµÄÈÝÑÕÒ²Ö»ÊÇÃÀÀöµÄƤÄÒÏÂÃæ°ü×ŵÄÀàËƵÄѪºÍÈ⣬ΩÓв»ÀϵÄÖ»ÊÇÄúµÄ˼ÏëÄúµÄ¸öÐÔ²ÅÊÇÕæÕýÖµµÃÐÀÉͺÍÁôÁµµÄµØ·½¡£ Õâ°ë¸öÔÂÀ´ÁõÔÆ°Ñ×Ô¼º²¿·ÖµÄÈռǹÒÔÚÍøÉÏ£¬ÁõÔÆÊÕµ½ÁËÖÚ¶àµÄÓʼþºÍBBSÁôÑÔ£¬¸ü¶àµÄÈËÊÇ»³ÒɺÍÂþÂµ±È»Ò²²»·¦Ò»Ð©ÉÆÁ¼È˵ÄÕæ³Ï×£¸£ºÍ¹ØÐÄ¡£ÔÚ´ËÁõÔÆÏòËùÓÐÔĶÁ¹ýÁõÔƹÊʵÄÈ˱íʾÖÔÐÄ×£¸£ºÍ¸Ðл£¬ÎÞÂÛÔø¾­ÊǹØÐÄ»¹ÊÇÂþÂÁõÔÆÏ£ÍûÄܹ»¸úÄÇЩÉÆÁ¼µÄÈËÄÇЩ¹ØÐĹýÁõÔƵÄÈË×öÅóÓÑ£¬ÁõÔÆÒ²¿ÊÍûÄܹ»°ïµÃµ½ÅóÓÑһЩæ֤Ã÷×Ô¼ºµÄ¼ÛÖµ£¬ÒòΪÁõÔƵÄ˼Ï룬ÒòΪÁõÔÆûÓÐ×èÀ¹µÄÄæÏò¿Õ¼äµÄÏëÏó¡£ ÁõÔÆÔÙ´ÎÖØÉêÁõÔƲ»ÊÇÆ­×Ó£¡ÁõÔÆÒ²²»ÊÇÔÚ×öÈËÐԵIJâÊÔ£¬ÁõÔÆȷʵÉú»îÔÚÎÒÃÇͬһ¸öÊÀ½ç£¡ÁõÔÆÖ®ËùÒÔ¸ø³ö¸¸Ç×µÄÕʺÅȷʵÊÇÒòΪÁõÔÆÐèÒª°ïÖú£¬ÁõÔÆÖ»ÊÇÈÏΪ¸øËùÓÐÉÆÁ¼µÄÈËÃÇÓèÒÔÐÐÉƵĻú»á£¬Ò²ÊÇÉϲԴ͸øÁõÔƵÄÉƾ٣¬ÁõÔÆÏ£ÍûÈËÓëÈËÖ®¼ä¶àһЩ¿íÈݺÍÀí½â¡¢¶àһЩÕæ³ÏºÍ°®¡£ËÍÈËõ¹åÊÖÁôÓàÏ㣡¸óÏÂÇë×ðÖØÄúµÄ¿´·¨ºÍ·¢ÑÔ£¬ÒòΪÕâÒ²ÊÇÄúΪÈË´¦ÊÀÄúµÄ˼Ïë±íÂÊ£¬Èç¹ûÄúÊÇÒ»¸ö¸ºÔðµÄÈ˵Ļ°¡£ÈËÉú±¾À´¾ÍÊÇÒ»¸öì¶ÜµÄÈËÉú£¬ÌìµØÖ®¼äµÄÊÂÎï±¾À´¾ÍÊÇÒ»¸öì¶ÜµÄ¼¯ºÏ£¬ÈÊÕß¼ûÈÊÖÇÕß¼ûÖÇ,·ç¹ýÈ¥½ÖÉϸɸɾ»¾»£»´óÀËÌÔɳÁôϵľÍÊÇÖµµÃÁõÔÆǧÄêµÈ´ýµÄÈË¡£ÉÆÁ¼£¿Ãż÷£¿µ¨Ê¶£¿Ë¼Ï룿ÐÅÑö£¿ÄúÄܹ»³ÐÊܵÃÆðÈËÉúÖÚ¶àµÄ¿¼ÑéÂ𣿠ÏÖÔÚµÄÁõÔƵÄÈ·ºÜÐèÒª°ïÖú¡£ÇëËùÓаïÖú¹ýÁõÔƵÄÈËEmailÁôÏ´óÃûµç»°ºÍ»¹¿îÕʺţ¬½çʱÁõÔÆ»áÒÔÌرðµÄ·½Ê½ÖÂÒÔËùÓÐÔø¾­°ïÖú¹ýÁõÔƵÄÈË×îÉñÃصÄÀñÎï! ÕÐÉÌÒøÐÐÒ»¿¨Í¨Õʺţº9555 5020 0150 9251 ¸¸Ç׵Ŀª»§Ãû£ºÁõÒäÏæ Õ¾ÔÚ´°Ç°µÄÅ®º¢ÁõÔÆ 03Äê9ÔÂ24ÈÕÁ賿ÓÚ¹ãÖÝ Email:cqnvhai@163.com http://www.blogcn.com/blog/?u=cqnvhai From willy@debian.org Sun Sep 28 22:49:21 2003 From: willy@debian.org (Matthew Wilcox) Date: Sun, 28 Sep 2003 22:49:21 +0100 Subject: [parisc-linux] Re: zalon/ncr53c720 (linux-2.6.0-test5-pa22) broken on C110 In-Reply-To: <3F774571.6050100@tiscali.be> References: <3F76A312.8090603@tiscali.be> <20030928122414.GF24824@parcelfarce.linux.theplanet.co.uk> <3F77227F.7000400@tiscali.be> <3F774571.6050100@tiscali.be> Message-ID: <20030928214921.GN24824@parcelfarce.linux.theplanet.co.uk> On Sun, Sep 28, 2003 at 08:32:49PM +0000, Joel Soete wrote: > Joel Soete wrote: > > >Sorry it already failled with following satck dump: OK; we don't need the stack dump since that's already fixed in the top of tree. > >zalon_probe: Zalon vers field is 0x1, IRQ 34 > >ncr53c720-0: rev 0xf on bus 0 device 0 function 0 irq 34 > >ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential > >ncr53c720-0: suspicious SCSI data while resetting the BUS. > >ncr53c720-0: dp1,d15-8,dp0,d7-0,rst,req,ack,bsy,sel,atn,msg,c/d,i/o = > >0x3fdff00, expecting 0x100 > >ncr53c720-0: FATAL ERROR: CHECK SCSI BUS - CABLES, TERMINATION, DEVICE > >POWER etc.! > >ncr53c720-0: detaching... > > > >Now what do you thing foward pa20 or backward pa14? > > > Well: > hpalin login: root > Password: > Last login: Sun Sep 28 21:48:39 2003 on ttyS0 > Linux hpalin 2.6.0-test5-pa14 #1 Sun Sep 28 22:10:24 CEST 2003 parisc > GNU/Linux > > So break is in patch...-pa14-pa18 (if I am lucky I could check it next > week :) ) OK. Can you try applying the following patch to -pa18? Note that applying this patch to the top of the tree will not work (you'd need an additional patch for that). Index: sym53c8xx_defs.h =================================================================== RCS file: /var/cvs/linux-2.6/drivers/scsi/sym53c8xx_defs.h,v retrieving revision 1.4 retrieving revision 1.3 diff -u -p -r1.4 -r1.3 --- sym53c8xx_defs.h 24 Sep 2003 02:43:42 -0000 1.4 +++ sym53c8xx_defs.h 11 Sep 2003 18:50:08 -0000 1.3 @@ -497,10 +554,20 @@ #else +#ifdef CONFIG_SCSI_NCR53C8XX_NO_WORD_TRANSFERS +/* Only 8 or 32 bit transfers allowed */ +#define INW_OFF(o) (readb((char *)np->reg + ncr_offw(o)) << 8 | readb((char *)np->reg + ncr_offw(o) + 1)) +#else #define INW_OFF(o) readw_raw((char *)np->reg + ncr_offw(o)) +#endif #define INL_OFF(o) readl_raw((char *)np->reg + (o)) +#ifdef CONFIG_SCSI_NCR53C8XX_NO_WORD_TRANSFERS +/* Only 8 or 32 bit transfers allowed */ +#define OUTW_OFF(o, val) do { writeb((char)((val) >> 8), (char *)np->reg + ncr_offw(o)); writeb((char)(val), (char *)np->reg + ncr_offw(o) + 1); } while (0) +#else #define OUTW_OFF(o, val) writew_raw((val), (char *)np->reg + ncr_offw(o)) +#endif #define OUTL_OFF(o, val) writel_raw((val), (char *)np->reg + (o)) #endif -- "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 georgeudah@latinmail.com Mon Sep 29 10:23:23 2003 From: georgeudah@latinmail.com (georgeudah@latinmail.com) Date: Mon, 29 Sep 2003 11:23:23 +0200 Subject: [parisc-linux] BUSINESS PARTNER Message-ID: <20030929092324.6B4F24840@dsl2.external.hp.com> Dear Sir, I am George Udah, Director of logistics for the government of Liberia under former President Charles Taylor,I was in charge of the proceeds from the diamond mines scattered around the countryside, but since the current president has accepted to go into exile I decided to leave the country immediately before it is too late. I have in my possession the sum of fifteen million United States Dollars (USD15M), Which I am Willing to invest under your care probably in your company or another you may recommend. I am currently in hiding in Ghana since my recent escape from Liberia. I will unfold the procedure for the realization if you indicate your interest to collaborate and you will get 20% of the total sum as commission. Should this proposal not interest you, please disregard it without prejudice However, if you are interested in this proposal, please contact me using the above email. Please do treat this as a confidential issue as any leakage to the present goverment will be dangerous to me and my family . please treat this with utmost urgency that it requires. Best regards George Udah From georgeudah@latinmail.com Mon Sep 29 10:33:40 2003 From: georgeudah@latinmail.com (georgeudah@latinmail.com) Date: Mon, 29 Sep 2003 11:33:40 +0200 Subject: [parisc-linux] BUSINESS PARTNER Message-ID: <20030929093341.0A0A74890@dsl2.external.hp.com> Dear Sir, I am George Udah, Director of logistics for the government of Liberia under former President Charles Taylor,I was in charge of the proceeds from the diamond mines scattered around the countryside, but since the current president has accepted to go into exile I decided to leave the country immediately before it is too late. I have in my possession the sum of fifteen million United States Dollars (USD15M), Which I am Willing to invest under your care probably in your company or another you may recommend. I am currently in hiding in Ghana since my recent escape from Liberia. I will unfold the procedure for the realization if you indicate your interest to collaborate and you will get 20% of the total sum as commission. Should this proposal not interest you, please disregard it without prejudice However, if you are interested in this proposal, please contact me using the above email. Please do treat this as a confidential issue as any leakage to the present goverment will be dangerous to me and my family . please treat this with utmost urgency that it requires. Best regards George Udah From soete.joel@tiscali.be Mon Sep 29 11:56:57 2003 From: soete.joel@tiscali.be (Joel Soete) Date: Mon, 29 Sep 2003 12:56:57 +0200 Subject: [parisc-linux] 2.6.0-tes6-pa2 Message-ID: <3F704CAF00002B3F@ocpmta2.freegates.net> Hi all, Congratulation it compiles and boot well on my b180 :) Thanks, Joel ------------------------------------------------------------------------- L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr From willy@debian.org Mon Sep 29 14:33:17 2003 From: willy@debian.org (Matthew Wilcox) Date: Mon, 29 Sep 2003 14:33:17 +0100 Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: References: Message-ID: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk> On Mon, Sep 29, 2003 at 02:53:16PM +0200, Roman Zippel wrote: > Hi, > > On Mon, 29 Sep 2003, Geert Uytterhoeven wrote: > > > > Are there any Amiga cards that are 720 based? > > > > I don't know for sure. Probably not (cfr. above). > > The ppc boards have a 770. In the APUS tree we currently have a modified > ncr53c8xx driver, that sort of seems to work. The biggest problem seems to > be the incoherent memory interface. ... Ah ;-) So where do I find the APUS tree? From digging around on the web (man, there's a lot of broken links in the APUS faq ...), it seems to be its own sourceforge project that hasn't switched to working on 2.6 yet, is this correct? Now that ncr53c8xx is non-PCI only, it should cause the absolute minimum of wailing & gnashing of teeth to convert it to use the non-coherent dma device API. It would benefit PA-RISC too as we have two models (735 and 755) that have NCR720 chips and a non-coherent architecture. Right now, they use the 53c700 driver, but it'd be better to use the ncr53c8xx driver, of course. Are any APUS people interested in working on this? -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From geert@linux-m68k.org Mon Sep 29 14:45:41 2003 From: geert@linux-m68k.org (Geert Uytterhoeven) Date: Mon, 29 Sep 2003 15:45:41 +0200 (MEST) Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk> Message-ID: On Mon, 29 Sep 2003, Matthew Wilcox wrote: > On Mon, Sep 29, 2003 at 02:53:16PM +0200, Roman Zippel wrote: > > The ppc boards have a 770. In the APUS tree we currently have a modified > > ncr53c8xx driver, that sort of seems to work. The biggest problem seems to > > be the incoherent memory interface. > > ... Ah ;-) So where do I find the APUS tree? From digging around on > the web (man, there's a lot of broken links in the APUS faq ...), it > seems to be its own sourceforge project that hasn't switched to working > on 2.6 yet, is this correct? The APUS tree is indeed at SourceForge. Most recent version (not counting Roman's hard disk :-) is 2.4.22. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From carlos@baldric.uwo.ca Mon Sep 29 16:10:38 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Mon, 29 Sep 2003 11:10:38 -0400 Subject: [parisc-linux] pthread attributes and stack positions (gcc related?) In-Reply-To: <1064771620.10778.5.camel@mulgrave> References: <20030928174226.GA3040@systemhalted> <1064771620.10778.5.camel@mulgrave> Message-ID: <20030929151038.GC15180@systemhalted> On Sun, Sep 28, 2003 at 12:53:38PM -0500, James Bottomley wrote: > On Sun, 2003-09-28 at 12:42, Carlos O'Donell wrote: > > The variable is definately on the process stack. The thread's stack > > address seems to be inside the libraries 'writable' space and the stack > > size is wrong (or uninitialized). Perhaps I should just be looking for > > arch-dependant init code that we might be missing. > > This, I believe to be correct: there's only one real stack (i.e. the > thing on x86 that grows down from top of memory) and only one thread can > have it. The rest of the thread stacks are mmapped at fixed sizes with > a guard area to prevent them growing too far. mmapped memory comes out > of the same pool that shared library memory comes from, so you should > correctly see the mappings interleave (depending on the load and thread > start order). I agree, it seems though that after "fork" the values returned by "pthread_getattr_np (pthread_self (), &a);" are bogus. While if you call pthread_create(...) and then the previous line from within the newly created thread the values are initialized properly. A mistake might exist with symbol versioning by which we are not calling libpthread's overloaded thread manager "fork()" and continuing on with the normal syscall. I think this seems to be a question of expected behaviour. I'll pass this onto the libc-alpha list. c. From zippel@linux-m68k.org Mon Sep 29 17:24:14 2003 From: zippel@linux-m68k.org (Roman Zippel) Date: Mon, 29 Sep 2003 18:24:14 +0200 (CEST) Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk> References: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk> Message-ID: Hi, On Mon, 29 Sep 2003, Matthew Wilcox wrote: > ... Ah ;-) So where do I find the APUS tree? From digging around on > the web (man, there's a lot of broken links in the APUS faq ...), it It's also quite old... :) > seems to be its own sourceforge project that hasn't switched to working > on 2.6 yet, is this correct? Yes. My 2.6 tree currently dies at the first exec. > Now that ncr53c8xx is non-PCI only, it should cause the absolute minimum > of wailing & gnashing of teeth to convert it to use the non-coherent > dma device API. Um, which one is the current right dma device API? bye, Roman From willy@debian.org Mon Sep 29 17:27:49 2003 From: willy@debian.org (Matthew Wilcox) Date: Mon, 29 Sep 2003 17:27:49 +0100 Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: References: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030929162749.GR24824@parcelfarce.linux.theplanet.co.uk> On Mon, Sep 29, 2003 at 06:24:14PM +0200, Roman Zippel wrote: > > Now that ncr53c8xx is non-PCI only, it should cause the absolute minimum > > of wailing & gnashing of teeth to convert it to use the non-coherent > > dma device API. > > Um, which one is the current right dma device API? The one in Documentation/DMA-API.txt. It looks like PowerPC hasn't got an implementation of this yet -- is APUS the only non-coherent PowerPC subport? -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From carlos@baldric.uwo.ca Mon Sep 29 20:02:51 2003 From: carlos@baldric.uwo.ca (Carlos O'Donell) Date: Mon, 29 Sep 2003 15:02:51 -0400 Subject: [parisc-linux] pthread attributes and stack positions (gcc related?) In-Reply-To: <20030929151038.GC15180@systemhalted> References: <20030928174226.GA3040@systemhalted> <1064771620.10778.5.camel@mulgrave> <20030929151038.GC15180@systemhalted> Message-ID: <20030929190251.GB21914@systemhalted> On Mon, Sep 29, 2003 at 11:10:38AM -0400, Carlos O'Donell wrote: > I agree, it seems though that after "fork" the values returned by > "pthread_getattr_np (pthread_self (), &a);" are bogus. While if you call > pthread_create(...) and then the previous line from within the newly > created thread the values are initialized properly. A mistake might > exist with symbol versioning by which we are not calling libpthread's > overloaded thread manager "fork()" and continuing on with the normal syscall. Looking closer there is a __libc_maybe_call2 that happens during a fork that is called and libpthread is linked. The maybe call tries to see if pthread_fork is available, if it doesn't see a valid symbol it just calls ARCH_FORK(). This looks like a suspect. So do a number of the #ifdef's in pthread.c c. From grundler@parisc-linux.org Mon Sep 29 21:55:48 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Mon, 29 Sep 2003 14:55:48 -0600 Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: <20030929162749.GR24824@parcelfarce.linux.theplanet.co.uk> References: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk> <20030929162749.GR24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030929205548.GA13226@dsl2.external.hp.com> On Mon, Sep 29, 2003 at 05:27:49PM +0100, Matthew Wilcox wrote: > > Um, which one is the current right dma device API? > > The one in Documentation/DMA-API.txt. Matthew, which version of the source tree? 2.4.22 and 2.6.x versions of this file are not identical. grundler@gsyprf3:/usr/src$ diff linux-2.?/Documentation/DMA-mapping.txt | wc -l 117 grundler@gsyprf3:/usr/src$ wc -l linux-2.?/Documentation/DMA-mapping.txt 798 linux-2.4/Documentation/DMA-mapping.txt 828 linux-2.5/Documentation/DMA-mapping.txt 1626 total thanks, grant From James.Bottomley@steeleye.com Mon Sep 29 22:00:10 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 29 Sep 2003 16:00:10 -0500 Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: <20030929205548.GA13226@dsl2.external.hp.com> References: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk> <20030929162749.GR24824@parcelfarce.linux.theplanet.co.uk> <20030929205548.GA13226@dsl2.external.hp.com> Message-ID: <1064869488.1782.240.camel@mulgrave> On Mon, 2003-09-29 at 15:55, Grant Grundler wrote: > On Mon, Sep 29, 2003 at 05:27:49PM +0100, Matthew Wilcox wrote: > > > Um, which one is the current right dma device API? > > > > The one in Documentation/DMA-API.txt. > > Matthew, which version of the source tree? > 2.4.22 and 2.6.x versions of this file are not identical. > > grundler@gsyprf3:/usr/src$ diff linux-2.?/Documentation/DMA-mapping.txt | wc -l > 117 > grundler@gsyprf3:/usr/src$ wc -l linux-2.?/Documentation/DMA-mapping.txt > 798 linux-2.4/Documentation/DMA-mapping.txt > 828 linux-2.5/Documentation/DMA-mapping.txt > 1626 total DMA-mapping.txt is only the pci_ DMA API. The ncr53c8xx doesn't use that any more. It only uses the generic DMA API, which is documented in DMA-API.txt like willy said, and is only in 2.6 (not 2.4). James From rene.br@web.de Mon Sep 29 22:25:01 2003 From: rene.br@web.de (Rene Brothuhn) Date: Mon, 29 Sep 2003 23:25:01 +0200 Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk>; from willy@debian.org on Mon, Sep 29, 2003 at 15:33:17 +0200 References: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030929212501.GA2631@ipgraf11.informatik.fh-schmalkalden.de> On 2003.09.29 15:33 Matthew Wilcox wrote: > ... Ah ;-) So where do I find the APUS tree? From digging around on > the web (man, there's a lot of broken links in the APUS faq ...), it > seems to be its own sourceforge project that hasn't switched to working > on 2.6 yet, is this correct? > > Now that ncr53c8xx is non-PCI only, it should cause the absolute minimum > of wailing & gnashing of teeth to convert it to use the non-coherent > dma device API. It would benefit PA-RISC too as we have two models > (735 and 755) that have NCR720 chips and a non-coherent architecture. > Right now, they use the 53c700 driver, but it'd be better to use the > ncr53c8xx driver, of course. > > Are any APUS people interested in working on this? Hello! I'm the one who getting the 53c770 driver working on APUS. The driver is based on the code from the ncr53c8xx driver which I found on a 2.4.16 kernel (maybe it was an other kernel version, I'm not really sure anymore). In newer kernels the ncr53c8xx drivers are replaced by sym53c8xx which uses a different and more complicated architecture. In my opinion, the best is to create a seperate 53c720/770 driver based on the 53c770 from APUS or ncr53c8xx. I guess the 53c770 from APUS should work (with some changes) on a 720 (or similar), because the 770 was designed to replace the 720. But I don't know anything about 735 and 755. But the APUS driver is a really big "patchwork", has some problems and needs a clean-up. And I haven't worked on the driver since a year due to lack of time, sorry. I still have lack of time, but if there are any questions, I will help. It will be nice to have a native 720/770 driver... And maybe, if someone tries to port this driver to a PA, I have to go for it... Ciao, Renè From Karina Riley" --256.E.DD935E Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Sophie's Perso= nal Website
Hey! My name's Sophie and I'm just letting you know that I have just la= unched my site full of heaps of sexy pictures and videos of me!! If you want to see a movie of me just click here!

I want to make it big as a model. I hope you think I have what it = takes and maybe you'll be seeing a lot more of me very soon! I really ho= pe you enjoy the video= s!

Click here to see Sophie in action now!
--256.E.DD935E-- From willy@debian.org Tue Sep 30 03:21:32 2003 From: willy@debian.org (Matthew Wilcox) Date: Tue, 30 Sep 2003 03:21:32 +0100 Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: <20030929212501.GA2631@ipgraf11.informatik.fh-schmalkalden.de> References: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk> <20030929212501.GA2631@ipgraf11.informatik.fh-schmalkalden.de> Message-ID: <20030930022132.GU24824@parcelfarce.linux.theplanet.co.uk> On Mon, Sep 29, 2003 at 11:25:01PM +0200, Rene Brothuhn wrote: > I'm the one who getting the 53c770 driver working on APUS. The driver is Good to hear from you. Let me just clear up a couple of misunderstandings... > based on the code from the ncr53c8xx driver which I found on a 2.4.16 > kernel (maybe it was an other kernel version, I'm not really sure > anymore). In newer kernels the ncr53c8xx drivers are replaced by sym53c8xx > which uses a different and more complicated architecture. The sym53c8xx driver doesn't support all the chips that ncr53c8xx supported (mostly earlier chips like 810). Now there's the sym53c8xx_2 driver that supports all the 8xx chips. In 2.6, we've now eliminated all PCI stuff from ncr53c8xx (and it should probably be renamed to ncr53c7xx, but I actually have a slightly different plan for renaming it that needs other work to happen first). > In my opinion, the best is to create a seperate 53c720/770 driver based on > the 53c770 from APUS or ncr53c8xx. I guess the 53c770 from APUS should > work (with some changes) on a 720 (or similar), because the 770 was > designed to replace the 720. But I don't know anything about 735 and 755. The HP 735/755 workstations have an NCR720 chip as part of their `core IO'. It appears as a parisc_device. They have a PCX-T CPU which has no way to allocate coherent memory. > But the APUS driver is a really big "patchwork", has some problems and > needs a clean-up. And I haven't worked on the driver since a year due to > lack of time, sorry. > > I still have lack of time, but if there are any questions, I will help. It > will be nice to have a native 720/770 driver... And maybe, if someone > tries to port this driver to a PA, I have to go for it... OK. I think the right path forward here is: - I port the ncr53c8xx to use the non-coherent DMA interfaces. - Someone converts the zorro device to embed the struct device. - Someone implements the non-coherent DMA interfaces for PowerPC. - Someone adds a zorro720 driver (see NCR_Q720 and zalon for inspiration) that's simply a glue layer from zorro to ncr720. -- "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 knaresh@india.hp.com Tue Sep 30 06:33:28 2003 From: knaresh@india.hp.com (Naresh) Date: Tue, 30 Sep 2003 11:03:28 +0530 Subject: [parisc-linux] MAX_ADDRESS. Message-ID: <3F7915A7.1F54379@india.hp.com> Hi, This question is relevant to the 2.4 kernel. Is MAX_ADDRESS really the highest virtual address mapped by the kernel? I can see this comment in 'paging_init()' in the section for DISCONTIGMEM. However, pagetable_init() doesnt make a check before it calls 'map_pages( )' for all the ranges of memory. So we may DISCONTIGMEM turned off but it may so happen that we have a 'pmem_ranges[]' entry that is greater than MAX_ADDRESS which may find its way into the kernel page tables. Regards, Naresh. From geert@linux-m68k.org Tue Sep 30 09:21:16 2003 From: geert@linux-m68k.org (Geert Uytterhoeven) Date: Tue, 30 Sep 2003 10:21:16 +0200 (MEST) Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: <20030930022132.GU24824@parcelfarce.linux.theplanet.co.uk> Message-ID: On Tue, 30 Sep 2003, Matthew Wilcox wrote: > - Someone converts the zorro device to embed the struct device. I'm working on this. I have code that works on UML using a fake list of Zorro devices, but so far I haven't modified any Zorro driver code. BTW, A4000T SCSI is builtin, not Zorro, so we need a platform device for that. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From willy@debian.org Tue Sep 30 13:06:36 2003 From: willy@debian.org (Matthew Wilcox) Date: Tue, 30 Sep 2003 13:06:36 +0100 Subject: [parisc-linux] MAX_ADDRESS. In-Reply-To: <3F7915A7.1F54379@india.hp.com> References: <3F7915A7.1F54379@india.hp.com> Message-ID: <20030930120636.GV24824@parcelfarce.linux.theplanet.co.uk> On Tue, Sep 30, 2003 at 11:03:28AM +0530, Naresh wrote: > This question is relevant to the 2.4 kernel. Is MAX_ADDRESS really the > highest virtual address mapped by the kernel? I can see this comment in > 'paging_init()' in the section for DISCONTIGMEM. However, > pagetable_init() doesnt make a check before it calls 'map_pages( )' for > all the ranges of memory. So we may DISCONTIGMEM turned off but it may > so happen that we have a 'pmem_ranges[]' entry that is greater than > MAX_ADDRESS which may find its way into the kernel page tables. Ignore the DISCONTIGMEM code. It's completely broken (and we offer no way to turn CONFIG_DISCONTIGMEM on). I'm not sure what half of this code is for; you'd need to ask John Marvin who wrote it. -- "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 knaresh@india.hp.com Tue Sep 30 13:24:30 2003 From: knaresh@india.hp.com (Naresh) Date: Tue, 30 Sep 2003 17:54:30 +0530 Subject: [parisc-linux] MAX_ADDRESS. References: <3F7915A7.1F54379@india.hp.com> <20030930120636.GV24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <3F7975FE.58C276D9@india.hp.com> MAX_ADDRESS has nothing to do with DISCONTIGMEM. Its definition is generic( pgtable.h), although it is not used anywhere. I just happened to see the comment in the DISCONTIGMEM code. Even if DISCONTIGMEM is turned off, there is no check for MAX_ADDRESS before the call to 'map_pages()' in 'pagetable_init( )', which is why I would like to know if MAX_ADDRESS can be ignored. Regards, Naresh. Matthew Wilcox wrote: > On Tue, Sep 30, 2003 at 11:03:28AM +0530, Naresh wrote: > > This question is relevant to the 2.4 kernel. Is MAX_ADDRESS really the > > highest virtual address mapped by the kernel? I can see this comment in > > 'paging_init()' in the section for DISCONTIGMEM. However, > > pagetable_init() doesnt make a check before it calls 'map_pages( )' for > > all the ranges of memory. So we may DISCONTIGMEM turned off but it may > > so happen that we have a 'pmem_ranges[]' entry that is greater than > > MAX_ADDRESS which may find its way into the kernel page tables. > > Ignore the DISCONTIGMEM code. It's completely broken (and we offer no > way to turn CONFIG_DISCONTIGMEM on). > > I'm not sure what half of this code is for; you'd need to ask John Marvin > who wrote it. > > -- > "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 From James.Bottomley@steeleye.com Tue Sep 30 14:17:22 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 30 Sep 2003 08:17:22 -0500 Subject: [parisc-linux] MAX_ADDRESS. In-Reply-To: <3F7975FE.58C276D9@india.hp.com> References: <3F7915A7.1F54379@india.hp.com> <20030930120636.GV24824@parcelfarce.linux.theplanet.co.uk> <3F7975FE.58C276D9@india.hp.com> Message-ID: <1064927843.2065.3.camel@mulgrave> On Tue, 2003-09-30 at 07:24, Naresh wrote: > MAX_ADDRESS has nothing to do with DISCONTIGMEM. Its definition is generic( > pgtable.h), although it is not used anywhere. I just happened to see the comment in > the DISCONTIGMEM code. Even if DISCONTIGMEM is turned off, there is no check for > MAX_ADDRESS before the call to 'map_pages()' in 'pagetable_init( )', which is why I > would like to know if MAX_ADDRESS can be ignored. No. It does represent the highest virtual address possible. Linux has 3 levels of page tables, so on a 64 bit kernel (8 bytes per pte and 8 bytes per pte page pointer etc), we can address a maximum of 512GB with 4k pages. James From James.Bottomley@steeleye.com Tue Sep 30 14:47:11 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 30 Sep 2003 08:47:11 -0500 Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: References: Message-ID: <1064929633.2183.7.camel@mulgrave> On Tue, 2003-09-30 at 03:21, Geert Uytterhoeven wrote: > BTW, A4000T SCSI is builtin, not Zorro, so we need a platform device for that. That depends on how you want it to work. On parisc, the Lasi (SCSI and other) devices are technically "platform" in that they're all ASIC'd together and soldered on to the main board. However, it was easier to create a parisc_bus type and lump them all under it than to use a platform device....however, we did this in the very early days of the generic device, a platform device might be more appropriate now. James From willy@debian.org Tue Sep 30 14:59:14 2003 From: willy@debian.org (Matthew Wilcox) Date: Tue, 30 Sep 2003 14:59:14 +0100 Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: <1064929633.2183.7.camel@mulgrave> References: <1064929633.2183.7.camel@mulgrave> Message-ID: <20030930135914.GW24824@parcelfarce.linux.theplanet.co.uk> On Tue, Sep 30, 2003 at 08:47:11AM -0500, James Bottomley wrote: > On Tue, 2003-09-30 at 03:21, Geert Uytterhoeven wrote: > > BTW, A4000T SCSI is builtin, not Zorro, so we need a platform device for that. > > That depends on how you want it to work. On parisc, the Lasi (SCSI and > other) devices are technically "platform" in that they're all ASIC'd > together and soldered on to the main board. However, it was easier to > create a parisc_bus type and lump them all under it than to use a > platform device....however, we did this in the very early days of the > generic device, a platform device might be more appropriate now. It makes a lot of sense to treat all the devices that firmware tells us about as parisc_devices since we treat them all the same way. If we were stepping over ourselves saying "well, yes, this is a pluggable device and therefore we have to access it like that, but this one's on the motherboard and therefore we treat it like that", I'd agree. But all these devices are in the same namespace, firmware tells us about all of them in the same way, so I think we should continue with the parisc_device. >From a historical perspective, we've had parisc_devices in one form or another since the very start of the project. They were called hp_devices until about August 2001. See http://ftp.parisc-linux.org/patches/parisc_device-2.diff for the conversion. I don't know much about Amiga/Zorro. Maybe it'd make sense for Amiga platform devices to be faked as zorro_devices, but I doubt it. In any case, the 4000T SCSI is a 53c710, not a 720. -- "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 rene.br@web.de Tue Sep 30 14:59:32 2003 From: rene.br@web.de (Rene Brothuhn) Date: Tue, 30 Sep 2003 15:59:32 +0200 Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: <20030930022132.GU24824@parcelfarce.linux.theplanet.co.uk>; from willy@debian.org on Tue, Sep 30, 2003 at 04:21:32 +0200 References: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk> <20030929212501.GA2631@ipgraf11.informatik.fh-schmalkalden.de> <20030930022132.GU24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <20030930135932.GA10395@ipgraf11.informatik.fh-schmalkalden.de> On 2003.09.30 04:21 Matthew Wilcox wrote: > The sym53c8xx driver doesn't support all the chips that ncr53c8xx > supported (mostly earlier chips like 810). Now there's the sym53c8xx_2 > driver that supports all the 8xx chips. In 2.6, we've now eliminated all > PCI stuff from ncr53c8xx (and it should probably be renamed to ncr53c7xx, > but I actually have a slightly different plan for renaming it that needs > other work to happen first). Fine, the pci-stuff is removed from the driver. This makes it easier to adapt the driver to non-pci machines. I have looked in the ncr53c8xx driver from 2.6 and there is mentioned that "interrupt on the fly" is not working correctly for 720. Also sym53c8xx_defs.h is included and so the registerset from a 810 is used, but the 720/770 registers are slightly different. Is the NCR_Q720 or zalon driver working? > > OK. I think the right path forward here is: > > - I port the ncr53c8xx to use the non-coherent DMA interfaces. > - Someone converts the zorro device to embed the struct device. > - Someone implements the non-coherent DMA interfaces for PowerPC. So, maybe I can do that at least for APUS, because some of the needed interfaces I already created as a "dirty-hack" inside the 53c770 driver. But the mean problem is, that there is no working 2.6 kernel for APUS... The other problem is time, but maybe I find some hours on weekend... > - Someone adds a zorro720 driver (see NCR_Q720 and zalon for > inspiration) > that's simply a glue layer from zorro to ncr720. If the rest is working, something like this should not be a big problem... Ciao, Renè From willy@debian.org Tue Sep 30 15:32:50 2003 From: willy@debian.org (Matthew Wilcox) Date: Tue, 30 Sep 2003 15:32:50 +0100 Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: <20030930135932.GA10395@ipgraf11.informatik.fh-schmalkalden.de> References: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk> <20030929212501.GA2631@ipgraf11.informatik.fh-schmalkalden.de> <20030930022132.GU24824@parcelfarce.linux.theplanet.co.uk> <20030930135932.GA10395@ipgraf11.informatik.fh-schmalkalden.de> Message-ID: <20030930143250.GX24824@parcelfarce.linux.theplanet.co.uk> On Tue, Sep 30, 2003 at 03:59:32PM +0200, Rene Brothuhn wrote: > I have looked in the ncr53c8xx driver from 2.6 and there is mentioned that > "interrupt on the fly" is not working correctly for 720. Also > sym53c8xx_defs.h is included and so the registerset from a 810 is used, > but the 720/770 registers are slightly different. > Is the NCR_Q720 or zalon driver working? Yes, they're both working fine. I went over the 770 register definitions the other night and only found one difference between the names of the definitions in the sym53c8xx_defs file and the 770 PDF and that was: -/*3a*/ u_char nc_sbr; +/*3a*/ u_char nc_sbr; /* dwt on 720 */ This is the DMA watchdog timer, but it's not actually used by the driver. It's a `scratch byte register' on the 895. Some of the `reserved' fields in the 770 register definition have names, but they were only ever touched if the chip was a sufficiently recent revision. BTW, I couldn't see a document for the 720 chip on the LSI site -- only the 710 and 770. I presume I won't go far wrong treating them the same. > > - Someone implements the non-coherent DMA interfaces for PowerPC. > > So, maybe I can do that at least for APUS, because some of the needed > interfaces I already created as a "dirty-hack" inside the 53c770 driver. > But the mean problem is, that there is no working 2.6 kernel for APUS... > The other problem is time, but maybe I find some hours on weekend... Yeah, no hurry. I don't think we have to get this done before 2.6.0 is out -- after all, it's only a driver. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From zippel@linux-m68k.org Tue Sep 30 15:55:14 2003 From: zippel@linux-m68k.org (Roman Zippel) Date: Tue, 30 Sep 2003 16:55:14 +0200 (CEST) Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: <20030930135932.GA10395@ipgraf11.informatik.fh-schmalkalden.de> References: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk> <20030929212501.GA2631@ipgraf11.informatik.fh-schmalkalden.de> <20030930022132.GU24824@parcelfarce.linux.theplanet.co.uk> <20030930135932.GA10395@ipgraf11.informatik.fh-schmalkalden.de> Message-ID: Hi, On Tue, 30 Sep 2003, Rene Brothuhn wrote: > But the mean problem is, that there is no working 2.6 kernel for APUS... That's not really true anymore, it boots here now. :-) bye, Roman From jesse@cypress-tech.com Tue Sep 30 16:04:19 2003 From: jesse@cypress-tech.com (Jesse Dougherty) Date: Tue, 30 Sep 2003 11:04:19 -0400 Subject: [parisc-linux] Linux HP-IB Driver Message-ID: <3F799B73.70906BEF@cypress-tech.com> I am trying to locate a driver (download or CD) for an PCI IEEE-488 National Instruments HP-IB interface card (similar to the HP E2078A / 82350B) using Linux via HP 9000/B2000 workstation. If anyone knows of such a driver and where I can obtain it, please reply back. Thanks Jesse Cypress Technology Inc Re-Sellers of HP 9000/3000 Hardware Jesse@cypress-tech.com From willy@debian.org Tue Sep 30 16:32:15 2003 From: willy@debian.org (Matthew Wilcox) Date: Tue, 30 Sep 2003 16:32:15 +0100 Subject: [parisc-linux] Linux HP-IB Driver In-Reply-To: <3F799B73.70906BEF@cypress-tech.com> References: <3F799B73.70906BEF@cypress-tech.com> Message-ID: <20030930153215.GY24824@parcelfarce.linux.theplanet.co.uk> On Tue, Sep 30, 2003 at 11:04:19AM -0400, Jesse Dougherty wrote: > I am trying to locate a driver (download or CD) for an PCI IEEE-488 > National Instruments HP-IB interface card (similar to the HP E2078A / > 82350B) using Linux via HP 9000/B2000 workstation. If anyone knows of > such a driver and where I can obtain it, please reply back. A quick google found ftp://ftp.llp.fu-berlin.de/pub/linux/LINUX-LAB/IEEE488 -- "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 Tue Sep 30 16:32:23 2003 From: James.Bottomley@steeleye.com (James Bottomley) Date: 30 Sep 2003 10:32:23 -0500 Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: <20030930135914.GW24824@parcelfarce.linux.theplanet.co.uk> References: <1064929633.2183.7.camel@mulgrave> <20030930135914.GW24824@parcelfarce.linux.theplanet.co.uk> Message-ID: <1064935949.1930.6.camel@mulgrave> On Tue, 2003-09-30 at 08:59, Matthew Wilcox wrote: > It makes a lot of sense to treat all the devices that firmware tells us > about as parisc_devices since we treat them all the same way. If we > were stepping over ourselves saying "well, yes, this is a pluggable > device and therefore we have to access it like that, but this one's > on the motherboard and therefore we treat it like that", I'd agree. > But all these devices are in the same namespace, firmware tells us > about all of them in the same way, so I think we should continue with > the parisc_device. Yes, I was just musing about the way we did it. In theory, the difference between a "platform" device and a generic device is that a generic device has a bus, and a platform one doesn't. The platform_device also has a resource pointer and a few other bits and pieces the generic device doesn't. What I did for PA was to create a parisc bus type, and attach all the inventoried hardware to it. This blurs the bus distinction in generic device because we have several inventoried buses: Runway, GSC, LASI etc. that are all lumped under the parisc bus. I was just wondering if it wouldn't make more sense now for us to be using platform devices too... James > >From a historical perspective, we've had parisc_devices in > one form or another since the very start of the project. > They were called hp_devices until about August 2001. See > http://ftp.parisc-linux.org/patches/parisc_device-2.diff for the > conversion. > > I don't know much about Amiga/Zorro. Maybe it'd make sense for Amiga > platform devices to be faked as zorro_devices, but I doubt it. In > any case, the 4000T SCSI is a 53c710, not a 720. > > -- > "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 soete.joel@tiscali.be Tue Sep 30 17:31:17 2003 From: soete.joel@tiscali.be (Joel Soete) Date: Tue, 30 Sep 2003 18:31:17 +0200 Subject: [parisc-linux] N Class SMP pb ? (follow up) Message-ID: <3F5CB6FB0000AD75@ocpmta1.freegates.net> Hi Grant, Here is the very last test I did yesterday with the additional mdelay(100): >TOC the machine, "ser pim" and look at PSW in TOC Info for each CPU. >bit 0 is the I-Bit IIRC. In summary: ------- Processor 1 HPMC Information - PDC Ver ion: 41.28 ------ [...] CPU State = 0x9e000004 [...] CPU Diagnose Register 2 = 0x0301010800802004 CPU Status Register 0 = 0x2640c24000000000 CPU Status Register 1 = 0x8000200000000000 [...] ------- Proces or 3 HPMC Information - PDC Version: 41.28 ------ [...] CPU State = 0x9e000004 [...] CPU Diagnose Register 2 = 0x0301030800802004 CPU Status Register 0 = 0x3640c24000000000 CPU Status Register 1 = 0x80000000 0000000 [...] all I bits (well the lowest weight PSW bit :) ) are well 0 >Could be. >Add mdelay(100) (or higher) after the lines of output you've added. >The works if it's a functional problem that's not timing dependent. Well after a ver long time of boot the system finaly crash without any reason of panic??? (all interruption should be manage by handle_interruption?) Just in case here is a short Pim-analyse: ------- Processor 1 HPMC Information - PDC Version: 41.28 ------ GR of CPU[1] 00-03 0000000000000000 000000001041b018 000000001014dbf0 0000000000000000 04-07 0000000000008000 000000008d113c00 0000000040200000 0000000000008000 08-11 0000000000000000 000000008d2cd008 0000000080000000 00000000103fa2c8 12-15 0000000040180000 000000008d9a6280 00000000105389c0 0000000000000000 16-19 000000001045cf88 00000000103b6338 000000008d147010 ffffffffffffffff 20-23 00000000000001ff 0000000040178000 000000008d9a6280 0000000000088000 24-27 0000000040180000 0000000000000006 0000000040180000 00000000105389c0 28-31 0000000000000000 000000008d7ccef0 000000008d7ccf40 0000000000008000 GR[02] == rp = 000000001014dbf0 Func: zap_page_range, Off: 0xe0, Addr: 0x1014dbf0 1014dbf0: 08 0e 02 5b copy r14,dp 1014dbf4: 03 c0 08 b4 mfctl tr6,r20 1014dbf8: 4a 93 00 b0 ldw 58(r20),r19 1014dbfc: 29 c5 20 00 addil b000,r14,%r1 GR[22] == t1(32bits) == arg4(64bits) = 000000008d9a6280 GR[21] == t2(32bits) == arg5(64bits) = 0000000040178000 GR[20] == t3(32bits) == arg6(64bits) = 00000000000001ff GR[19] == t4(32bits) == arg7(64bits) = ffffffffffffffff GR[26] == arg0 = 0000000040180000 GR[25] == arg1 = 0000000000000006 GR[24] == arg2 = 0000000040180000 GR[23] == arg3 = 0000000000088000 GR[27] == dp = 00000000105389c0 Func: __gp, Off: 0x0, Addr: 0x105389c0 GR[28] == ret0 = 0000000000000000 GR[29] == ret1 or sl = 000000008d7ccef0 GR[30] == sp = 000000008d7ccf40 GR[31] == ble rp = 0000000000008000 Not parsable address! CR of CPU[1] 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 00000000000002b2 0000000000000000 00000000000000c0 0000000000000003 12-15 0000000000000000 0000000000000000 0000000000107000 ffe0000000000000 16-19 000003182e3e3f89 0000000000000000 000000001014deac 0000000036b52000 20-23 00000000103401f5 00000000f33ccdd8 000000ff080ef70f 8000000000000000 24-27 0000000000461000 000000007d147000 0000000000041020 000000ffff95c810 28-31 5555555555555555 5555555555555555 000000008d7cc000 00000000105a0000 CR[00] == rctr = 0000000000000000 CR[08] == (Protection ID) pidr1 = 00000000000002b2 CR[10] == ccr = 00000000000000c0 CR[11] == sar = 0000000000000003 CR[14] == iva = 0000000000107000 CR[15] == eiem = ffe0000000000000 CR[16] == itmr = 000003182e3e3f89 CR[17] == pcsq = 0000000000000000 CR[18] == pcoq = 000000001014deac CR[19] == iir = 0000000036b52000 CR[20] == isr = 00000000103401f5 CR[21] == ior = 00000000f33ccdd8 CR[22] == ipsw = 000000ff080ef70f CR[23] == eirw = 8000000000000000 CR[24] == tr0 (ptov) = 0000000000461000 CR[25] == tr1 (vtop) = 000000007d147000 CR[26] == tr2 = 0000000000041020 CR[27] == tr3 = 000000ffff95c810 CR[28] == tr4 = 5555555555555555 CR[29] == tr5 = 5555555555555555 CR[30] == tr6 = 000000008d7cc000 CR[31] == tr7 = 00000000105a0000 SR of CPU[1] 00-03 0000ac80 0000ac80 00000000 0000ac80 04-07 00000000 00000000 00000000 00000000 Need much more work !!! SR[00] == ts0 = 0000ac80 SR[01] == ts1 = 0000ac80 SR[03] == cpp = 0000ac80 Not parsable address! ... IIA Offset (back entry) = 0x000000001014dea0 ... e.g. IAOQ = 0x000000001014dea0 FPR of CPU[1] 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 000000008f760ec0 0000000000000002 000000001359d740 0000000000000420 08-11 0000000000000000 0000000000000802 00000000105389c0 000000001059a000 12-15 0000000013590000 0000000000000000 0000000010180574 00000000103dc6b8 16-19 00000000000009ee 000000008fa7e000 00000000105389c0 0000000013590000 20-23 00000000103b7b0c fffffffffffffff4 000000000000021e 0000002f66666667 24-27 000007b100000000 0000999903590b70 0000000003590b78 000000001041b980 28-31 000000001041b980 00000000ff915e20 0000000010187b38 0000000000000004 Parse IAOQ = 0x000000001014dea0 for CPU[1] Func: zap_page_range, Off: 0x390, Addr: 0x1014dea0 1014dea0: 06 a0 52 00 pdtlb r0(sr1,r21) 1014dea4: 37 39 3f ff ldo -1(r25),r25 1014dea8: bf 33 3f e5 cmpb,*<> r19,r25,1014dea0 1014deac: 36 b5 20 00 ldo 1000(r21),r21 ------- Processor 3 HPMC Information - PDC Version: 41.28 ------ GR of CPU[3] 00-03 0000000000000000 0000000010429028 000000001010cdd0 0000000000000021 04-07 000000008d0c05b8 00000000105389c0 000000000000000f 0000000000000000 08-11 0000000000000000 0000000040026ee2 0000000040039141 0000000040026fb4 12-15 0000000040028380 00000000faf00950 00000000400342f4 0000000000000000 16-19 000000008d0c05b8 00000000faf00910 00000000faf00910 0000000000058706 20-23 000003182e080065 0000000000000000 0000000000000000 0000000000000000 24-27 0000000000000000 0000000000000000 00000000000003e8 00000000105389c0 28-31 0000000000086470 0000000000086470 000000008d0c0b40 0000000000000226 GR[02] == rp = 000000001010cdd0 Func: handle_interruption, Off: 0xb0, Addr: 0x1010cdd0 1010cdd0: 08 05 02 5b copy r5,dp 1010cdd4: 02 00 08 b4 mfctl itmr,r20 1010cdd8: 02 00 08 b3 mfctl itmr,r19 1010cddc: 0a 93 04 33 sub r19,r20,r19 ... 1010cde0: be 7c bf e5 cmpb,*>> ret0,r19,1010cdd8 ... ... 1010cdec: ec 7f bf c5 cmpib,*<> -1,r3,1010cdd4 ... GR[22] == t1(32bits) == arg4(64bits) = 0000000000000000 GR[21] == t2(32bits) == arg5(64bits) = 0000000000000000 GR[20] == t3(32bits) == arg6(64bits) = 000003182e080065 GR[19] == t4(32bits) == arg7(64bits) = 0000000000058706 GR[26] == arg0 = 00000000000003e8 GR[25] == arg1 = 0000000000000000 GR[24] == arg2 = 0000000000000000 GR[23] == arg3 = 0000000000000000 GR[27] == dp = 00000000105389c0 Func: __gp, Off: 0x0, Addr: 0x105389c0 GR[28] == ret0 = 0000000000086470 GR[29] == ret1 or sl = 0000000000086470 GR[30] == sp = 000000008d0c0b40 GR[31] == ble rp = 0000000000000226 Not parsable address! CR of CPU[3] 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 00000000000002b8 0000000000000000 00000000000000c0 000000000000003f 12-15 0000000000000000 0000000000000000 0000000000107000 ffe0000000000000 16-19 000003182e158ca8 0000000000000000 000000001010cde0 00000000be7cbfe5 20-23 00000000103401f4 00000000300c0b50 000000ff0804ff0e 8000000000000000 24-27 0000000000461000 000000007d0c4000 0000000000041020 000000ffff95c810 28-31 000000ffff95c810 5555555555555555 000000008d0c0000 0000000000008020 CR[00] == rctr = 0000000000000000 CR[08] == (Protection ID) pidr1 = 00000000000002b8 CR[10] == ccr = 00000000000000c0 CR[11] == sar = 000000000000003f CR[14] == iva = 0000000000107000 CR[15] == eiem = ffe0000000000000 CR[16] == itmr = 000003182e158ca8 CR[17] == pcsq = 0000000000000000 CR[18] == pcoq = 000000001010cde0 CR[19] == iir = 00000000be7cbfe5 CR[20] == isr = 00000000103401f4 CR[21] == ior = 00000000300c0b50 CR[22] == ipsw = 000000ff0804ff0e CR[23] == eirw = 8000000000000000 CR[24] == tr0 (ptov) = 0000000000461000 CR[25] == tr1 (vtop) = 000000007d0c4000 CR[26] == tr2 = 0000000000041020 CR[27] == tr3 = 000000ffff95c810 CR[28] == tr4 = 000000ffff95c810 CR[29] == tr5 = 5555555555555555 CR[30] == tr6 = 000000008d0c0000 CR[31] == tr7 = 0000000000008020 SR of CPU[3] 00-03 0000ae00 00006e00 00000000 0000ae00 04-07 00000000 00000000 00000000 00000000 Need much more work !!! SR[00] == ts0 = 0000ae00 SR[01] == ts1 = 00006e00 SR[03] == cpp = 0000ae00 Not parsable address! ... IIA Offset (back entry) = 0x000000001010cde4 ... e.g. IAOQ = 0x000000001010cde4 FPR of CPU[3] 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 000000008f760ec0 0000000000000002 000000001359d740 0000000000000420 08-11 0000000000000000 0000000000000802 00000000105389c0 000000001059a000 12-15 0000000013590000 0000000000000000 0000000010180574 00000000103dc6b8 16-19 00000000000009ee 000000008fa7e000 00000000105389c0 0000000013590000 20-23 00000000103b7b0c fffffffffffffff4 0000000000000000 0000000000000000 24-27 0000999900000000 0000999903590b70 0000000003590b78 000000001041b980 28-31 000000001041b980 00000000ff915e20 0000000010187b38 0000000000000000 Parse IAOQ = 0x000000001010cde4 for CPU[3] Func: handle_interruption, Off: 0xc4, Addr: 0x1010cde4 1010cde0: be 7c bf e5 cmpb,*>> ret0,r19,1010cdd8 1010cde4: 08 00 02 40 nop 1010cde8: 34 63 3f ff ldo -1(r3),r3 1010cdec: ec 7f bf c5 cmpib,*<> -1,r3,1010cdd4 Any idea? >Otherwise setup kernel crash dump and use tools from bruno/phi to view >contents of the kernel message buffer. Well, that seems to be the ultimate solution (I don't remember if it also works on smp kernel?) but I will need to discuss a bit with them to see if I reach to get a dump how could it be analysed? Thanks again for your attention, Joel ------------------------------------------------------------------------- L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr From grundler@parisc-linux.org Tue Sep 30 18:23:12 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Tue, 30 Sep 2003 11:23:12 -0600 Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: <1064869488.1782.240.camel@mulgrave> References: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk> <20030929162749.GR24824@parcelfarce.linux.theplanet.co.uk> <20030929205548.GA13226@dsl2.external.hp.com> <1064869488.1782.240.camel@mulgrave> Message-ID: <20030930172312.GA7391@dsl2.external.hp.com> On Mon, Sep 29, 2003 at 04:00:10PM -0500, James Bottomley wrote: > DMA-mapping.txt is only the pci_ DMA API. Doh! yes...misread willy's comment. sorry. grant From grundler@parisc-linux.org Tue Sep 30 19:50:23 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Tue, 30 Sep 2003 12:50:23 -0600 Subject: [parisc-linux] N Class SMP pb ? (follow up) In-Reply-To: <3F5CB6FB0000AD75@ocpmta1.freegates.net> References: <3F5CB6FB0000AD75@ocpmta1.freegates.net> Message-ID: <20030930185023.GB7391@dsl2.external.hp.com> On Tue, Sep 30, 2003 at 06:31:17PM +0200, Joel Soete wrote: > Hi Grant, > > Here is the very last test I did yesterday with the additional mdelay(100): > > >TOC the machine, "ser pim" and look at PSW in TOC Info for each CPU. > >bit 0 is the I-Bit IIRC. > > In summary: > ------- Processor 1 HPMC Information - PDC Version: 41.28 ------ Did you TOC the machine or did it HPMC? I was under the impression the SW had hung and one needed to TOC to regain control. TOC info is seperate from HPMC info. If it's in fact HPMC, then look at IOAQ/GR02 for both CPUs and see which functions they were executing in when HPMC occurred. grant From grundler@parisc-linux.org Tue Sep 30 20:03:29 2003 From: grundler@parisc-linux.org (Grant Grundler) Date: Tue, 30 Sep 2003 13:03:29 -0600 Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: <1064935949.1930.6.camel@mulgrave> References: <1064929633.2183.7.camel@mulgrave> <20030930135914.GW24824@parcelfarce.linux.theplanet.co.uk> <1064935949.1930.6.camel@mulgrave> Message-ID: <20030930190329.GC7391@dsl2.external.hp.com> On Tue, Sep 30, 2003 at 10:32:23AM -0500, James Bottomley wrote: > What I did for PA was to create a parisc bus type, and attach all the > inventoried hardware to it. This blurs the bus distinction in generic > device because we have several inventoried buses: Runway, GSC, LASI etc. > that are all lumped under the parisc bus. All those busses conform to the HP IO ADC and thus could be considered the same type of bus. Except for LASI, the above makes sense to me. LASI isn't a bus. This would be a candidate for "platform device" since it's bridge-like device with integrate sub-devices. EISA bridge chips might be a similar case. > I was just wondering if it wouldn't make more sense now for us to be > using platform devices too... I don't understand "platform devices" vs "PCI devices" unless we are talking about "custom", arch specific bridge chips. A GSC device is a GSC device regardless of which board it's soldered to. That's not the case for PCI? grant From zippel@linux-m68k.org Mon Sep 29 17:24:14 2003 From: zippel@linux-m68k.org (Roman Zippel) Date: Mon, 29 Sep 2003 18:24:14 +0200 (CEST) Subject: [parisc-linux] Re: NCR53c720 In-Reply-To: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk> References: <20030929133317.GP24824@parcelfarce.linux.theplanet.co.uk> Message-ID: Hi, On Mon, 29 Sep 2003, Matthew Wilcox wrote: > ... Ah ;-) So where do I find the APUS tree? From digging around on > the web (man, there's a lot of broken links in the APUS faq ...), it It's also quite old... :) > seems to be its own sourceforge project that hasn't switched to working > on 2.6 yet, is this correct? Yes. My 2.6 tree currently dies at the first exec. > Now that ncr53c8xx is non-PCI only, it should cause the absolute minimum > of wailing & gnashing of teeth to convert it to use the non-coherent > dma device API. Um, which one is the current right dma device API? bye, Roman ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Linux-APUS-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-apus-devel