From owner-freebsd-alpha Mon Jan 1 8: 6:58 2001 From owner-freebsd-alpha@FreeBSD.ORG Mon Jan 1 08:06:57 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 9A5C237B400 for ; Mon, 1 Jan 2001 08:06:56 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id LAA17076; Mon, 1 Jan 2001 11:06:51 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f01G6pi52342; Mon, 1 Jan 2001 11:06:51 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 1 Jan 2001 11:06:50 -0500 (EST) To: Peter Petrakis Cc: scanner@jurai.net, freebsd-alpha@FreeBSD.ORG Subject: Re: API CS20 support? Any good axp based server solutions? In-Reply-To: <3A4FC390.76265C6B@alphalinux.org> References: <14927.38434.715703.641740@grasshopper.cs.duke.edu> <3A4FC390.76265C6B@alphalinux.org> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14928.43547.652595.810828@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Petrakis writes: > I'd be happy to help :-). I have access to a CS20 or two at work. > I see no problem in BSD supporting the CS20. Tru64 see's it as a ES40 > with only two processors (same southbridge). So if FreeBSD supports the > ES40 you're pretty much there. The onboard scsi is a sym 53c8000 and it > has UDMA 66 > onboard. Besides that it has advanced I2C support and dual intel 10/100 > ethernet. Thanks for the info. It sounds like it should probably work, or at least come pretty darned close. It might be interesting to see /proc/pci if you have a chance. I'm wondering how many PCI hoses it has and if the sym card is on the 0th hose.. If not, you may want to try installing the latest -current snapshot, rather than 4.2-RELEASE. Thanks again, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 1 8:24:37 2001 From owner-freebsd-alpha@FreeBSD.ORG Mon Jan 1 08:24:34 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from alphalinux.org (alphalinux.org [63.236.138.10]) by hub.freebsd.org (Postfix) with SMTP id 0C59F37B400 for ; Mon, 1 Jan 2001 08:24:34 -0800 (PST) Received: (qmail 29439 invoked by uid 0); 1 Jan 2001 16:24:13 -0000 Received: from node-64-145-21-18.dslspeed.zyan.com (HELO alphalinux.org) (64.145.21.18) by alphalinux.org with SMTP; 1 Jan 2001 16:24:13 -0000 Sender: ppetrakis@FreeBSD.ORG Message-ID: <3A50AF3B.A75835F9@alphalinux.org> Date: Mon, 01 Jan 2001 11:24:27 -0500 From: Peter Petrakis X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Gallatin Cc: scanner@jurai.net, freebsd-alpha@FreeBSD.ORG Subject: Re: API CS20 support? Any good axp based server solutions? References: <14927.38434.715703.641740@grasshopper.cs.duke.edu> <3A4FC390.76265C6B@alphalinux.org> <14928.43547.652595.810828@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > It might be interesting to see /proc/pci if you have a chance. I'm > wondering how many PCI hoses it has and if the sym card is on the 0th > hose.. If not, you may want to try installing the latest -current > snapshot, rather than 4.2-RELEASE. Sure, Disregard the netgear (ID 630a) and the 53c895. I'm testing out the Gigabit over copper in this system. The revisions of the intel chips may change but the posistions on the bus should stay the same, one on each bus. [root@localhost /proc]# cat pci PCI devices found: Bus 0, device 3, function 0: SCSI storage controller: NCR Unknown device (rev 1). Vendor id=1000. Device id=21. Medium devsel. IRQ 32. Master Capable. Latency=255. Min Gnt=17.Max Lat=18. I/O at 0x8000 [0x8001]. Non-prefetchable 32 bit memory at 0x9000000 [0x9000000]. Non-prefetchable 32 bit memory at 0x9002000 [0x9002000]. Bus 0, device 4, function 0: Ethernet controller: Intel 82557 (rev 12). Medium devsel. Fast back-to-back capable. IRQ 36. Master Capable. Latency=255. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0x9004000 [0x9004000]. [root@localhost /proc]# cat pci PCI devices found: Bus 0, device 3, function 0: SCSI storage controller: NCR Unknown device (rev 1). Vendor id=1000. Device id=21. Medium devsel. IRQ 32. Master Capable. Latency=255. Min Gnt=17.Max Lat=18. I/O at 0x8000 [0x8001]. Non-prefetchable 32 bit memory at 0x9000000 [0x9000000]. Non-prefetchable 32 bit memory at 0x9002000 [0x9002000]. Bus 0, device 4, function 0: Ethernet controller: Intel 82557 (rev 12). Medium devsel. Fast back-to-back capable. IRQ 36. Master Capable. Latency=255. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0x9004000 [0x9004000]. I/O at 0x8800 [0x8801]. Non-prefetchable 32 bit memory at 0x9020000 [0x9020000]. Bus 0, device 5, function 0: Ethernet controller: Unknown vendor Unknown device (rev 1). Vendor id=1385. Device id=630a. Medium devsel. Fast back-to-back capable. IRQ 40. Master Capable. Latency=248. Min Gnt=64. Non-prefetchable 32 bit memory at 0x9040000 [0x9040000]. Bus 0, device 7, function 0: ISA bridge: Acer Labs M1533 Aladdin IV (rev 195). Medium devsel. Master Capable. No bursts. Bus 0, device 16, function 0: IDE interface: Acer Labs M5229 TXpro (rev 194). Medium devsel. Fast back-to-back capable. Master Capable. Latency=255. Min Gnt=2.Max Lat=4. I/O at 0x9000 [0x9001]. I/O at 0x9800 [0x9801]. I/O at 0xa000 [0xa001]. I/O at 0xa800 [0xa801]. I/O at 0xb000 [0xb001]. Bus 0, device 17, function 0: Non-VGA device: Acer Labs Unknown device (rev 0). Vendor id=10b9. Device id=7101. Medium devsel. I/O at 0xb800 [0xb801]. I/O at 0xc000 [0xc001]. Bus 1, device 3, function 0: Ethernet controller: Intel 82557 (rev 8). Medium devsel. Fast back-to-back capable. IRQ 48. Master Capable. Latency=255. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0x109000000 [0x109000000]. I/O at 0x10000d000 [0x10000d001]. Non-prefetchable 32 bit memory at 0x109100000 [0x109100000]. Bus 1, device 4, function 0: SCSI storage controller: NCR 53c895 (rev 2). Medium devsel. IRQ 52. Master Capable. Latency=255. Min Gnt=30.Max Lat=64. I/O at 0x10000d800 [0x10000d801]. Non-prefetchable 32 bit memory at 0x109200000 [0x109200000]. Non-prefetchable 32 bit memory at 0x109201000 [0x109201000]. [root@localhost /proc]# -- www.alphalinux.org Peter Petrakis Warrior/Engineer ppetrakis@alphalinux.org "Oh my God! They killed Xena! You bastards!!" " Who the hell are you!? Name's Ash Housewares..." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 1 8:42:16 2001 From owner-freebsd-alpha@FreeBSD.ORG Mon Jan 1 08:42:14 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 0710137B400 for ; Mon, 1 Jan 2001 08:42:14 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id LAA17227; Mon, 1 Jan 2001 11:42:12 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f01GgCJ52382; Mon, 1 Jan 2001 11:42:12 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 1 Jan 2001 11:42:12 -0500 (EST) To: Peter Petrakis Cc: scanner@jurai.net, freebsd-alpha@FreeBSD.ORG Subject: Re: API CS20 support? Any good axp based server solutions? In-Reply-To: <3A50AF3B.A75835F9@alphalinux.org> References: <14927.38434.715703.641740@grasshopper.cs.duke.edu> <3A4FC390.76265C6B@alphalinux.org> <14928.43547.652595.810828@grasshopper.cs.duke.edu> <3A50AF3B.A75835F9@alphalinux.org> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14928.45753.163029.246377@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Petrakis writes: > > It might be interesting to see /proc/pci if you have a chance. I'm > > wondering how many PCI hoses it has and if the sym card is on the 0th > > hose.. If not, you may want to try installing the latest -current > > snapshot, rather than 4.2-RELEASE. > > > Sure, Disregard the netgear (ID 630a) and the 53c895. I'm testing out > the Gigabit over copper > in this system. The revisions of the intel chips may change but the > posistions on the > bus should stay the same, one on each bus. On the face of it, it looks like 4.2-release will work. It will almost certainly mess up on the '895 card because it is on the second hose, but everything else should work.. (we have a hack in 4.x to keep track of hose numbers that grabs the high bits in the i/o or memory space mapping; this doesn't work with ncr/sym devs. This hack is no longer needed in 5.x). Cheers, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 1 8:50:42 2001 From owner-freebsd-alpha@FreeBSD.ORG Mon Jan 1 08:50:40 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4575437B400; Mon, 1 Jan 2001 08:50:39 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id IAA18435; Mon, 1 Jan 2001 08:50:39 -0800 Date: Mon, 1 Jan 2001 08:50:38 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mike Smith Cc: alpha@freebsd.org Subject: Re: rawhide breakage report... In-Reply-To: <200101010209.f0129cn12505@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Done. Thanks. On Sun, 31 Dec 2000, Mike Smith wrote: > > What it turns out is that a card had PCIM_STATUS_CAPPRESENT set in the status > > register (Qlogic 2200, and the code that reads this got stuck in an infinite > > loop... I'm not sure whether this was due to bad reads from config space or > > whether it really was a bogus PCIM_STATUS_CAPPRESENT or what (see attach). It > > kinda looks like the config read stuff is broken because it accepted an offset > > of -1 :-), but there was a case before where a value of -1 was returned. > > > > I don't know this cap goop at all. Whaddya think? > > nextptr = REG(ptrptr, 1); /* sanity check? */ > > The right sanity check probably involves looking at nextptr in the loop: > > /* > * Read capability entries. > */ > while (nextptr != 0) { > /* Sanity check */ > if (nextptr > 255) { > printf("illegal PCI extended capability offset %d\n", > nexptr); > return; > } > /* Find the next entry */ > ptr = nextptr; > nextptr = REG(ptr + 1, 1); > > It should never be < 0, since pci_read_config returns unsigned. Since > you have some errant hardware, it'd be great if you could check and > commit this. > > -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] > V I C T O R Y N O T V E N G E A N C E > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 1 9:15:42 2001 From owner-freebsd-alpha@FreeBSD.ORG Mon Jan 1 09:15:39 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from front3m.grolier.fr (front3m.grolier.fr [195.36.216.53]) by hub.freebsd.org (Postfix) with ESMTP id 7834C37B402 for ; Mon, 1 Jan 2001 09:15:38 -0800 (PST) Received: from nas1-42.mea.club-internet.fr (nas1-42.mea.club-internet.fr [195.36.139.42]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA24265; Mon, 1 Jan 2001 18:15:01 +0100 (MET) Date: Mon, 1 Jan 2001 17:14:23 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Peter Petrakis Cc: Andrew Gallatin , scanner@jurai.net, freebsd-alpha@FreeBSD.ORG, Pam Delaney Subject: Re: API CS20 support? Any good axp based server solutions? In-Reply-To: <3A50AF3B.A75835F9@alphalinux.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 1 Jan 2001, Peter Petrakis wrote: > > It might be interesting to see /proc/pci if you have a chance. I'm > > wondering how many PCI hoses it has and if the sym card is on the 0th > > hose.. If not, you may want to try installing the latest -current > > snapshot, rather than 4.2-RELEASE. >=20 >=20 > Sure, Disregard the netgear (ID 630a) and the 53c895. I'm testing out I am rather interested in the other NCR/SYMBIOS/LSILOGIC device. It looks like SYM53C1010-66 chips (2 channels / U3-SCSI / PCI 66MHz capable). The problem is that /proc/pci tells about 32 bit MEM BARs and the=20 FreeBSD sym driver is assuming 64 bit MEM BARs. Another difference is that it is a single-function device while the=20 SYM53C1010-66 is a 2 functions device. If I had to guess, I would think it is a SYM53C1000(R?), but Pamela must know. This doesn't harm under Linux since the sym53c8xx driver gets BARs generically, but under FreeBSD the low 32 bit BAR offset is to be provided to BUS RESOURCE API and a zero value will be returned to the driver for the on-chip RAM address (2nd MEM BAR). It is very ennoying. Could you provide me with the dump of the PCI predefined header of the device (Vendor 1000 - Id 21) ? (64 first bytes of the PCI configuration space) - Thanks in advance. I have a SYM53C1010-33 rev. 1, but no SYM53C1010-66 for now.:( Happy New Year to all of you. G=E9rard. > PCI devices found: > Bus 0, device 3, function 0: > SCSI storage controller: NCR Unknown device (rev 1). > Vendor id=3D1000. Device id=3D21. ^^ > Medium devsel. IRQ 32. Master Capable. Latency=3D255. Min > Gnt=3D17.Max Lat=3D18. I/O at 0x8000 [0x8001]. > Non-prefetchable 32 bit memory at 0x9000000 [0x9000000]. > Non-prefetchable 32 bit memory at 0x9002000 [0x9002000]. ^^ > Bus 0, device 4, function 0: > Ethernet controller: Intel 82557 (rev 12). > Medium devsel. Fast back-to-back capable. IRQ 36. Master > Capable. Latency=3D255. Min Gnt=3D8.Max Lat=3D56. > Non-prefetchable 32 bit memory at 0x9004000 [0x9004000]. > I/O at 0x8800 [0x8801]. > Non-prefetchable 32 bit memory at 0x9020000 [0x9020000]. > Bus 0, device 5, function 0: > Ethernet controller: Unknown vendor Unknown device (rev 1). > Vendor id=3D1385. Device id=3D630a. > Medium devsel. Fast back-to-back capable. IRQ 40. Master > Capable. Latency=3D248. Min Gnt=3D64. > Non-prefetchable 32 bit memory at 0x9040000 [0x9040000]. > Bus 0, device 7, function 0: > ISA bridge: Acer Labs M1533 Aladdin IV (rev 195). > Medium devsel. Master Capable. No bursts. =20 > Bus 0, device 16, function 0: > IDE interface: Acer Labs M5229 TXpro (rev 194). > Medium devsel. Fast back-to-back capable. Master Capable.=20 > Latency=3D255. Min Gnt=3D2.Max Lat=3D4. > I/O at 0x9000 [0x9001]. > I/O at 0x9800 [0x9801]. > I/O at 0xa000 [0xa001]. > I/O at 0xa800 [0xa801]. > I/O at 0xb000 [0xb001]. > Bus 0, device 17, function 0: > Non-VGA device: Acer Labs Unknown device (rev 0). > Vendor id=3D10b9. Device id=3D7101. > Medium devsel. =20 > I/O at 0xb800 [0xb801]. > I/O at 0xc000 [0xc001]. > Bus 1, device 3, function 0: > Ethernet controller: Intel 82557 (rev 8). > Medium devsel. Fast back-to-back capable. IRQ 48. Master > Capable. Latency=3D255. Min Gnt=3D8.Max Lat=3D56. > Non-prefetchable 32 bit memory at 0x109000000 [0x109000000]. > I/O at 0x10000d000 [0x10000d001]. > Non-prefetchable 32 bit memory at 0x109100000 [0x109100000]. > Bus 1, device 4, function 0: > SCSI storage controller: NCR 53c895 (rev 2). > Medium devsel. IRQ 52. Master Capable. Latency=3D255. Min > Gnt=3D30.Max Lat=3D64. I/O at 0x10000d800 [0x10000d801]. > Non-prefetchable 32 bit memory at 0x109200000 [0x109200000]. > Non-prefetchable 32 bit memory at 0x109201000 [0x109201000]. > [root@localhost /proc]#=20 >=20 >=20 >=20 > --=20 > www.alphalinux.org > Peter Petrakis Warrior/Engineer ppetrakis@alphalinux.org > "Oh my God! They killed Xena! You bastards!!" > " Who the hell are you!? Name's Ash Housewares..." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 1 9:48: 8 2001 From owner-freebsd-alpha@FreeBSD.ORG Mon Jan 1 09:48:06 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from alphalinux.org (alphalinux.org [63.236.138.10]) by hub.freebsd.org (Postfix) with SMTP id 917BE37B400 for ; Mon, 1 Jan 2001 09:48:06 -0800 (PST) Received: (qmail 10233 invoked by uid 0); 1 Jan 2001 17:47:49 -0000 Received: from node-64-145-21-18.dslspeed.zyan.com (HELO alphalinux.org) (64.145.21.18) by alphalinux.org with SMTP; 1 Jan 2001 17:47:49 -0000 Sender: ppetrakis@FreeBSD.ORG Message-ID: <3A50C2D4.DAE317BE@alphalinux.org> Date: Mon, 01 Jan 2001 12:48:04 -0500 From: Peter Petrakis X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 alpha) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?G=E9rard?= Roudier Cc: Andrew Gallatin , scanner@jurai.net, freebsd-alpha@FreeBSD.ORG, Pam Delaney Subject: Re: API CS20 support? Any good axp based server solutions? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Could you provide me with the dump of the PCI predefined header of the > device (Vendor 1000 - Id 21) ? (64 first bytes of the PCI configuration > space) - Thanks in advance. > > I have a SYM53C1010-33 rev. 1, but no SYM53C1010-66 for now.:( You mean this? [root@localhost /proc]# lspci -s 00:03.0 -xxx 00:03.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR): Unknown device 0021 (rev 01) 00: 00 10 21 00 07 00 30 02 01 00 00 01 10 ff 00 00 10: 01 80 00 00 04 00 00 09 00 00 00 00 04 20 00 09 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 20 01 11 12 40: 01 00 02 06 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Peter -- www.alphalinux.org Peter Petrakis Warrior/Engineer ppetrakis@alphalinux.org "Oh my God! They killed Xena! You bastards!!" " Who the hell are you!? Name's Ash Housewares..." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 1 9:51:59 2001 From owner-freebsd-alpha@FreeBSD.ORG Mon Jan 1 09:51:57 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id D02D437B400 for ; Mon, 1 Jan 2001 09:51:56 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #2) id 14D97j-0003dF-00; Mon, 01 Jan 2001 17:51:55 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.1) id f01HqZ025817; Mon, 1 Jan 2001 18:52:35 +0100 (CET) (envelope-from wkb) Date: Mon, 1 Jan 2001 18:52:35 +0100 From: Wilko Bulte To: Andrew Gallatin Cc: Peter Petrakis , scanner@jurai.net, freebsd-alpha@freebsd.org Subject: Re: API CS20 support? Any good axp based server solutions? Message-ID: <20010101185235.B24589@freebie.demon.nl> References: <14927.38434.715703.641740@grasshopper.cs.duke.edu> <3A4FC390.76265C6B@alphalinux.org> <14928.43547.652595.810828@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14928.43547.652595.810828@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Mon, Jan 01, 2001 at 11:06:50AM -0500 X-OS: FreeBSD 4.2-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jan 01, 2001 at 11:06:50AM -0500, Andrew Gallatin wrote: > > Peter Petrakis writes: > > I'd be happy to help :-). I have access to a CS20 or two at work. > > I see no problem in BSD supporting the CS20. Tru64 see's it as a ES40 > > with only two processors (same southbridge). So if FreeBSD supports the > > ES40 you're pretty much there. The onboard scsi is a sym 53c8000 and it > > has UDMA 66 > > onboard. Besides that it has advanced I2C support and dual intel 10/100 > > ethernet. > > Thanks for the info. It sounds like it should probably work, or at > least come pretty darned close. ?? Since when do we have any chance of running on ES40? -- Wilko Bulte Arnhem, the Netherlands wilko@freebsd.org http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 1 10: 2:31 2001 From owner-freebsd-alpha@FreeBSD.ORG Mon Jan 1 10:02:30 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 7373C37B400 for ; Mon, 1 Jan 2001 10:02:29 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id NAA17963; Mon, 1 Jan 2001 13:02:28 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f01I2SF52502; Mon, 1 Jan 2001 13:02:28 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 1 Jan 2001 13:02:28 -0500 (EST) To: Wilko Bulte Cc: freebsd-alpha@freebsd.org Subject: Re: API CS20 support? Any good axp based server solutions? In-Reply-To: <20010101185235.B24589@freebie.demon.nl> References: <14927.38434.715703.641740@grasshopper.cs.duke.edu> <3A4FC390.76265C6B@alphalinux.org> <14928.43547.652595.810828@grasshopper.cs.duke.edu> <20010101185235.B24589@freebie.demon.nl> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14928.50686.29364.498210@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte writes: > > Thanks for the info. It sounds like it should probably work, or at > > least come pretty darned close. > > ?? Since when do we have any chance of running on ES40? Its just another ST6600, is it not? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 1 10:52:51 2001 From owner-freebsd-alpha@FreeBSD.ORG Mon Jan 1 10:52:48 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by hub.freebsd.org (Postfix) with ESMTP id 76FE337B400 for ; Mon, 1 Jan 2001 10:52:47 -0800 (PST) Received: from nas1-214.cgy.club-internet.fr (nas1-214.cgy.club-internet.fr [195.36.197.214]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA25393; Mon, 1 Jan 2001 19:52:37 +0100 (MET) Date: Mon, 1 Jan 2001 18:52:15 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Peter Petrakis Cc: Andrew Gallatin , scanner@jurai.net, freebsd-alpha@FreeBSD.ORG, Pam Delaney Subject: Re: API CS20 support? Any good axp based server solutions? In-Reply-To: <3A50C2D4.DAE317BE@alphalinux.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 1 Jan 2001, Peter Petrakis wrote: > > Could you provide me with the dump of the PCI predefined header of the > > device (Vendor 1000 - Id 21) ? (64 first bytes of the PCI configuration > > space) - Thanks in advance. > >=20 > > I have a SYM53C1010-33 rev. 1, but no SYM53C1010-66 for now.:( >=20 > You mean this? Looks OK. Thanks very much. > [root@localhost /proc]# lspci -s 00:03.0 -xxx=20 > 00:03.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR): > Unknown device 0021 (rev 01) > 00: 00 10 21 00 07 00 30 02 01 00 00 01 10 ff 00 00 Cache line size is set to 128. Latency timer 255 is probably too high if PCI BUS is 33 MHz. > 10: 01 80 00 00 04 00 00 09 00 00 00 00 04 20 00 09 < IO BAR > < 64 bit MEMORY BAR > < 64 bit > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 MEMORY BAR> Sigh!! MEM BARs are 64 bit range as assumed by sym. So, `sym' should correctly deal with on-chip RAM BAR. It is /proc/pci under Linux/Alpha that lies about the=20 MEM BARs range. This should be looked into, since it could well be the=20 Linux driver that will be confused if the BAR cookies=20 in the pcidev structure are nor properly set with the=20 right range bit. > 30: 00 00 00 00 40 00 00 00 00 00 00 00 20 01 11 12 > 40: 01 00 02 06 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Thanks again, G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 1 11:13:56 2001 From owner-freebsd-alpha@FreeBSD.ORG Mon Jan 1 11:13:55 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id 96E0037B400 for ; Mon, 1 Jan 2001 11:13:54 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #2) id 14DAP2-000510-00; Mon, 01 Jan 2001 19:13:53 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.1) id f01JEXW26180; Mon, 1 Jan 2001 20:14:33 +0100 (CET) (envelope-from wkb) Date: Mon, 1 Jan 2001 20:14:33 +0100 From: Wilko Bulte To: Andrew Gallatin Cc: freebsd-alpha@freebsd.org Subject: Re: API CS20 support? Any good axp based server solutions? Message-ID: <20010101201433.A26166@freebie.demon.nl> References: <14927.38434.715703.641740@grasshopper.cs.duke.edu> <3A4FC390.76265C6B@alphalinux.org> <14928.43547.652595.810828@grasshopper.cs.duke.edu> <20010101185235.B24589@freebie.demon.nl> <14928.50686.29364.498210@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14928.50686.29364.498210@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Mon, Jan 01, 2001 at 01:02:28PM -0500 X-OS: FreeBSD 4.2-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jan 01, 2001 at 01:02:28PM -0500, Andrew Gallatin wrote: > > Wilko Bulte writes: > > > Thanks for the info. It sounds like it should probably work, or at > > > least come pretty darned close. > > > > ?? Since when do we have any chance of running on ES40? > > Its just another ST6600, is it not? I once tried a FreeBSD 4.2(RC?) on an ES40 and that went nowhere. ES40 is the quad-CPU capable 'Clipper' machine -- Wilko Bulte Arnhem, the Netherlands wilko@freebsd.org http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 1 17: 2:19 2001 From owner-freebsd-alpha@FreeBSD.ORG Mon Jan 1 17:02:17 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mail.ticonet.co.cr (mail.ticonet.co.cr [196.40.4.5]) by hub.freebsd.org (Postfix) with ESMTP id 4A41E37B400 for ; Mon, 1 Jan 2001 17:02:15 -0800 (PST) Received: from Popeye [196.40.53.141] by mail.ticonet.co.cr (SMTPD32-6.05) id A45491801F6; Mon, 01 Jan 2001 17:54:28 +0000 To: Happy@FreeBSD.ORG, New@FreeBSD.ORG, !!@Year.FreeBSD.ORG From: Oldies@FreeBSD.ORG, Online@FreeBSD.ORG, Casino@FreeBSD.ORG Subject: 01-01-2001 Date: Mon, 01 Jan 2001 19:00:54 -0600 Message-Id: <36892.792293958336800.18827@localhost> MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Oldies Online Casino - Happy New Year!!!

Oldies Online Casino
Would like to welcome you and your family a Happy New Year!

We Would also like to offer ALL NEW & EXISTING Members a
Holiday 25% Bonus
Oldies Online Casino offers Free no download Flash Internet
gambling, games include craps, keno, slots, video poker,
roulette and blackjack in real time. Play for fun or cash!
http://www.oldiesonlinecasino.com

to unsubscribe click here

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 1 21:59:16 2001 From owner-freebsd-alpha@FreeBSD.ORG Mon Jan 1 21:59:13 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mail.ticonet.co.cr (mail.ticonet.co.cr [196.40.4.5]) by hub.freebsd.org (Postfix) with ESMTP id 913EF37B400; Mon, 1 Jan 2001 21:59:07 -0800 (PST) Received: from Popeye [196.40.53.184] by mail.ticonet.co.cr (SMTPD32-6.05) id AA3C27A01DA; Mon, 01 Jan 2001 22:52:44 +0000 To: Happy@FreeBSD.ORG, New@FreeBSD.ORG, !!@Year.FreeBSD.ORG From: Oldies@FreeBSD.ORG, Online@FreeBSD.ORG, Casino@FreeBSD.ORG Subject: 01-01-2001 Date: Mon, 01 Jan 2001 23:59:11 -0600 Message-Id: <36892.999437418984600.238265@localhost> MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Oldies Online Casino - Happy New Year!!!

Oldies Online Casino
Would like to welcome you and your family a Happy New Year!

We Would also like to offer ALL NEW & EXISTING Members a
Holiday 25% Bonus
Oldies Online Casino offers Free no download Flash Internet
gambling, games include craps, keno, slots, video poker,
roulette and blackjack in real time. Play for fun or cash!
http://www.oldiesonlinecasino.com

to unsubscribe click here

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 10:58:24 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 10:58:23 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 7FDA937B402 for ; Tue, 2 Jan 2001 10:58:22 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA21911; Tue, 2 Jan 2001 10:58:16 -0800 Date: Tue, 2 Jan 2001 10:58:15 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Doug Rabson Cc: alpha@FreeBSD.ORG Subject: Re: Interrupt threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have actually been looking at these some. Not much progress though. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 11:43:14 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 11:43:11 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 80DE537B400 for ; Tue, 2 Jan 2001 11:43:11 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f02JgbG01278; Tue, 2 Jan 2001 11:42:37 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 02 Jan 2001 11:43:01 -0800 (PST) From: John Baldwin To: Doug Rabson Subject: RE: Interrupt threads Cc: alpha@FreeBSD.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 28-Dec-00 Doug Rabson wrote: > I started trying to work on changing the interrupt system so that the > ithread runs with i/o interrupts disabled, which would allow us to remove > the ugly code which tries to disable the interrupt sources. > > Unfortunately I immediately came up against a brick wall - the very first > interrupt interrupted a proc which owned Giant and the ithread also wanted > Giant. It tried to block, which switched back to the Giant owner with > interrupts enabled, causing the interrupt to fire again. > > I'm not sure what the right approach to solving this is. Possibly we could > 'lend' the mutex holder the IPL of the blocking thread in a similar way to > priority propagation. Another idea is to link thread IPL directly to its > priority so that when the ithread lends its priority, the mutex owner will > automagically run with raised IPL. I detailed what I think is a way of using IPL to do this in a pair of e-mails to Drew that Matt was copied on. I'll go dig them up and forward them to here. However, tying IPL to a process or a mutex is a mistake I think. You can't tie it to Giant because Giant is going away eventually. You can't tie it to a process because the first context switch that doesn't switch into the ithread will cause the interrupt to fire again. Instead, you basically have to futz with the trapframe in the interrupt handler so it doesn't lower IPL upon returning from teh interrupt, and don't lower the IPL again until the interrupt handler completes and the ithread finishes. Interacting properly with ast() on this makes it a bit more tricky. Let me go dig up my e-mails and forward them to the list. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 12: 3:24 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 12:03:21 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id BAB3537B400; Tue, 2 Jan 2001 12:03:20 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id MAA22108; Tue, 2 Jan 2001 12:03:20 -0800 Date: Tue, 2 Jan 2001 12:03:19 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: Doug Rabson , alpha@FreeBSD.ORG Subject: RE: Interrupt threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 2 Jan 2001, John Baldwin wrote: > > On 28-Dec-00 Doug Rabson wrote: > > I started trying to work on changing the interrupt system so that the > > ithread runs with i/o interrupts disabled, which would allow us to remove > > the ugly code which tries to disable the interrupt sources. > > > > Unfortunately I immediately came up against a brick wall - the very first > > interrupt interrupted a proc which owned Giant and the ithread also wanted > > Giant. It tried to block, which switched back to the Giant owner with > > interrupts enabled, causing the interrupt to fire again. > > > > I'm not sure what the right approach to solving this is. Possibly we could > > 'lend' the mutex holder the IPL of the blocking thread in a similar way to > > priority propagation. Another idea is to link thread IPL directly to its > > priority so that when the ithread lends its priority, the mutex owner will > > automagically run with raised IPL. > > I detailed what I think is a way of using IPL to do this in a pair of e-mails > to Drew that Matt was copied on. I'll go dig them up and forward them to here. > However, tying IPL to a process or a mutex is a mistake I think. You can't tie > it to Giant because Giant is going away eventually. You can't tie it to a > process because the first context switch that doesn't switch into the ithread > will cause the interrupt to fire again. Instead, you basically have to futz > with the trapframe in the interrupt handler so it doesn't lower IPL upon > returning from teh interrupt, and don't lower the IPL again until the interrupt > handler completes and the ithread finishes. Interacting properly with ast() on > this makes it a bit more tricky. Let me go dig up my e-mails and forward them > to the list. Please do. I agree this is tricky. I'll reiterate what I said a while back (insofar as I recall) and add: 1. It should be a bug to have the scheduler switch to a process that returns to user space while leaving ithreads blocked. Hell, it should be a bug for any process that enters kernel context and acquires an SMP lock to not release it before returning to user space. 2. Giant is like any other mutex in this context- whoever holds Giant should be resumed if an ithread hits Giant. As soon as they drop Giant there should be an immediate cpu_switch which had better resume the [ one of the ] ithread[s] that had been blocked. 3. You should not have to do anything with a trapframe until you actually are returning from an interrupt. You can't assume that a 'return from interrupt' can return with IPL set to non-zero. This is such a POLA violation that I wouldn't expect it to work much of anywhere. Basically, you should take an interrupt and immediately have the ithread for it run (unless fast- and until we can get this right, only allow one non-fast interrupt at a time for alpha). If this ithread hits a lock and can't get it, the holder of that lock (whether Giant, Fred, Foo, Bar) gets resumed until it drops that lock, whereupon the ithread should be resumed. This can repeat until the ithread is done, whereupon a real return from interrupt can occur. Unfortunately, I think we've begun to experience what Solaris had to put up with in this respect, but so it goes. I would rather have a lot more in the above model but this strikes me as something which very closely adheres to what was the advertised SMP model we got from BSDi- and seems to have some commented out code about this. 4. What defeated me immediately upon looking at Doug's stuff is all of the thread pri seems to be a software construct, so has no real hardware linkage. Additionally, I did not take the time to try and find an easy way to find and reschdule the proc that holds a lock if I'm trying to acquire it from an ithread and am blocking. Seems to be a bit of work there. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 12: 6:53 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 12:06:48 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id D73F037B400 for ; Tue, 2 Jan 2001 12:06:47 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f02K6VG01715 for ; Tue, 2 Jan 2001 12:06:31 -0800 (PST) (envelope-from john@baldwin.cx) Resent-Message-Id: <200101022006.f02K6VG01715@meow.osd.bsdi.com> Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Resent-Date: Mon, 06 Nov 2000 14:46:28 -0800 (PST) Resent-From: John Baldwin Resent-To: Doug Rabson Date: Tue, 02 Jan 2001 12:06:55 -0800 (PST) From: John Baldwin To: alpha@FreeBSD.org Subject: Disabling ints via IPL Resent-Sender: john@baldwin.cx Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, here's the first installment. :) On 06-Nov-00 Doug Rabson wrote: > On Mon, 6 Nov 2000, Matthew Jacob wrote: > >> >> I now finally have *one* working -current machine at Feral (a borrowed for >> NetBSD XP1000). All of the week before when I tried to run -current on it it >> destroyed the root filesystem. This problem seems to have gone away. >> >> So- at least I have something I can consistently refer back to for A/B >> comparisons that works (i.e., activation energy is now less). I *still* >> don't >> have enough power in the office yet to fire up the 4100!! >> >> It's still my theory that the enable/disable interrupt design is asking a >> lot of a platform. I don't recall seeing a refutation of this from John or >> Doug- did I somehow miss that? > > I think you are right about the enable/disable scheme. The alternative > (which should be more efficient anyway) is to simply run the irq threads > at a higher IPL - I think you already suggested this. It means being > careful to switch to the ithread directly from the interrupt code > otherwise the irq will be re-fired when the low-level handler returns. Err, so basically no ithreads until we have light-weight ithreads? This will break if an ithread sleeps or blocks though. Basically, you would have to change the low-level code to not restore the IPL on exit, and wait until the ithread runs, all its handlers run and then lower the IPL when the thread finishes execution. If one device interrupt handler ever depends on another device interrupt handler it would be an instant deadlock. :-( We'd also end up running userland processes at the higher IPL while we were waiting to run an interrupt thread, e.g. if the thread blocks trying to obtain a mutex. Has anyone confirmed that the problems are due to not being able to disable an interrupt source? -- Actually, it's not as bad as it sounds here, but this is the basic idea. An ithread will only block if another kernel thread has the mutex, so you won't bounce back to userland with a raised IPL as there will be another runnable kernel thread. More on this in later messages.. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 12: 6:53 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 12:06:48 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 13FA737B402 for ; Tue, 2 Jan 2001 12:06:48 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f02K6VG01719 for ; Tue, 2 Jan 2001 12:06:31 -0800 (PST) (envelope-from john@baldwin.cx) Resent-Message-Id: <200101022006.f02K6VG01719@meow.osd.bsdi.com> Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Resent-Date: Mon, 06 Nov 2000 16:12:46 -0800 (PST) Resent-From: John Baldwin Resent-To: Matthew Jacob Date: Tue, 02 Jan 2001 12:06:55 -0800 (PST) From: John Baldwin To: alpha@FreeBSD.org Subject: Disabling ints via IPL Resent-Sender: john@baldwin.cx Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Installment 2: On 07-Nov-00 Matthew Jacob wrote: >> >> > This makes it more problematic for the scheduler because it's got to be >> > able >> > to let interrupt thread run to completion (dropping of mutexes). In fact, >> > there's a tremendous body of work, both theoretical and actual (see Thoth, >> > Auspex's m16, etc), that state that scheduling primary interrupt threads >> > (as >> > opposed to offlevel processing) is just not productive- so that the only >> > 'scheduling' that should be done at interrupt level is to make sure that >> > the >> > priorities aren't tangled. >> >> It's not really hard for the scheduler. The kernel is not pre-emptible at >> the moment. We don't handle an need_resched() posted by the clock >> interrupt until we return to userland. > > But you do need to do some kind of implicit scheduling. Hmm, you miss that as far as I have seen at least, all the device I/O interrupts (the only ones we thread) are all triggered at the same IPL, so all interrupt threads would end up running at the same IPL, and you wouldn't get another threaded interrupt until the last interrupt's handler executes and finishes. All the blocking and rescheduling does happen in the mutex code (and yes, we will run the new thread that just got the mutex on a mtx_exit() immediately if the new thread has the higher priority). > There then becomes the further problem, which is what can lead to livelock- > this is when you are running an ithread where you try and grab another mutex. > > In this case, the rules that you simply transfer the IPL to the thread that > holds the lock aren't so simple because you have to do some scheduling > checking so that you don't do something lame like continue to run X because Z > tried to grab another mutex held by X. But you can't run X because there's a > lock held by Z, and so on. So the IPL transferrence only works in non-nested > locking cases I think. Basically, as far as I can tell, the kernel would run with the raised IPL until the handler finishes and returns, so all other device interrupts will be on hold and you won't have 1 interrupt thread blocked on a mutex that another interrupt thread holds. You would only have an interrupt thread waiting for a top-half thread to finish using a resource. Otherwise there is nothing to prevent an interrupt source from firing over and over and over again unless you use the disable/enable calls. > -matt -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 12: 6:57 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 12:06:54 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 9F99B37B698 for ; Tue, 2 Jan 2001 12:06:48 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f02K6WG01727 for ; Tue, 2 Jan 2001 12:06:32 -0800 (PST) (envelope-from john@baldwin.cx) Resent-Message-Id: <200101022006.f02K6WG01727@meow.osd.bsdi.com> Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Resent-Date: Fri, 17 Nov 2000 11:17:05 -0800 (PST) Resent-From: John Baldwin Resent-To: Andrew Gallatin Date: Tue, 02 Jan 2001 12:06:56 -0800 (PST) From: John Baldwin To: alpha@FreeBSD.org Subject: Disabling ints via IPL Resent-Sender: john@baldwin.cx Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Part IV. :) On 17-Nov-00 Andrew Gallatin wrote: > You're missing one thing -- From alpha/swtch.s: > > LEAF(exception_return, 1) /* XXX should be NESTED */ > <...> > /* We've got an AST. Handle it. */ >>-----> ldiq a0, ALPHA_PSL_IPL_0 /* drop IPL to zero */ > call_pal PAL_OSF1_swpipl > mov sp, a0 /* only arg is frame */ > CALL(ast) > > <...> > > Won't this lead in recursion on the interrupt stack if there's an ast > pending? Ugh. Yuck. Hmm. We need that ast() so that we switch to the interrupt thread, too (we will need it for light-weight ithreads as well). We should probably lower the IPL to the saved IPL in the stack frame instead. It will always be zero except for this hack for pc164's (since this is only done when returning to userland, which runs at IPL 0). Hmm. Actually, we will want to restore the saved IPL in the frame to 0 after this inside of ast() (since ast() is going to switch to the itnerrupt thread, and we will be back at IPL 0 when we return). So, what we really need to modify is not the IPL we switch to on return, but the IPL we use here before calling ast(). > Drew -- Re: light-weight ithreads, I'm not sure the ast() will be needed, but it might be. Also, this obviously won't just be for PC164's at this point. However, we really should only do this if we can't get interrupt source disabling/enabling to work as otherwise we are going to serialize interrupts and really kill interrupt performance. Especially on SMP systems. (Only one interrupt handler at a time across all CPU's, unless the IPL is a per-CPU thing, in which case this could get a bit more complicated on SMP systems if we have to resort to depending on IPL on an SMP system.) -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 12: 6:59 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 12:06:54 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 65E7537B404 for ; Tue, 2 Jan 2001 12:06:48 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f02K6VG01723 for ; Tue, 2 Jan 2001 12:06:31 -0800 (PST) (envelope-from john@baldwin.cx) Resent-Message-Id: <200101022006.f02K6VG01723@meow.osd.bsdi.com> Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Resent-Date: Fri, 17 Nov 2000 10:51:31 -0800 (PST) Resent-From: John Baldwin Resent-To: Andrew Gallatin Date: Tue, 02 Jan 2001 12:06:56 -0800 (PST) From: John Baldwin To: alpha@FreeBSD.org Subject: Disabling ints via IPL Resent-Sender: john@baldwin.cx Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Part III... -----FW: Re: PC164 IDE only works (was: SMPng stability)----- Date: Fri, 17 Nov 2000 10:51:31 -0800 (PST) From: John Baldwin To: Andrew Gallatin Subject: Re: PC164 IDE only works (was: SMPng stability) Cc: mjacob@feral.com On 17-Nov-00 Andrew Gallatin wrote: > > Next question -- how the heck do we keep the ipl at ALPHA_PSL_IPL_IO > until the interrupt thread is run? Can you muck with the psl in the > in hardware frame and have the palcode beleive you? > > Keeping the ipl at 4 will also mean mucking with exception return, > etc, etc, etc. Ick. Well, first of all, we should only do this for PC164's as this is going to kill interrupt performance. :( You can muck with the IPL in the saved psr on the stack. You will only need to do this for DEVICE_IO interrupts. And you can do it by writing the current IPL into the saved frame from within interrupt(). IOW, in the DEVICE_IO case block, have something like: if (user_has_a_lame_pc164) { frame.psr &= ~ALPHA_PSR_IPL_MASK; frame.psr |= alpha_read_psr() & ALPHA_PSR_IPL_MASK; } Then in ithd_loop(), before grabbing sched_lock via mtx_enter(), add in: if (user_has_a_lame_pc164) alpha_pal_swpipl(ALPHA_PSL_IPL_0); That should do the trick. > Drew -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 12: 7: 4 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 12:06:59 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id D6A1737B699 for ; Tue, 2 Jan 2001 12:06:48 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f02K6WG01731 for ; Tue, 2 Jan 2001 12:06:32 -0800 (PST) (envelope-from john@baldwin.cx) Resent-Message-Id: <200101022006.f02K6WG01731@meow.osd.bsdi.com> Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Resent-Date: Fri, 17 Nov 2000 11:39:32 -0800 (PST) Resent-From: John Baldwin Resent-To: Andrew Gallatin Date: Tue, 02 Jan 2001 12:06:56 -0800 (PST) From: John Baldwin To: alpha@FreeBSD.org Subject: Disabling ints via IPL Resent-Sender: john@baldwin.cx Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Part V: this has a bit more meat in the explanation.. On 17-Nov-00 Andrew Gallatin wrote: > > John Baldwin writes: > > Ugh. Yuck. Hmm. We need that ast() so that we switch to the interrupt > > thread, too (we will need it for light-weight ithreads as well). We > should > > probably lower the IPL to the saved IPL in the stack frame instead. It > will > > always be zero except for this hack for pc164's (since this is only done > when > > returning to userland, which runs at IPL 0). Hmm. Actually, we will want > to > > restore the saved IPL in the frame to 0 after this inside of ast() (since > ast() > > is going to switch to the itnerrupt thread, and we will be back at IPL 0 > when > > we return). So, what we really need to modify is not the IPL we switch to > on > > return, but the IPL we use here before calling ast(). > > That should make things a little easier. > > I'm still trying to understand what's going on here... What happens if > the interrupt thread blocks? Does a context switch happen and the > next process continue to run on the interrupt stack until such time as > the original interrupt thread runs to completion? No, the interrupt thread has its own stack (it is a kernel process), so the next process continues to run in its own context. The raised IPL will be propagated via sched_lock, however, and will stay raised until it is lowered via ithd_loop(). The assumption is that your userland process is not going to resume until after this has happened (otherwise the IPL would drop down again and *boom*). This assumption should be safe because interrupt threads have a very high priority, and if an ithread blocks on a mutex, its priority will be propagated (once that code works :-P) to the process holding the mutex. That process will be in the kernel, so it won't be the userland process we just interrupted. Hmm, if we get an interrupt in the kernel though we need to modify the saved IPL in the frame. Ugh, ok. Then go back to the original proposal (modify the IPL in the frame). In the ast() case in exception_return, we swap IPL_0 (we know 0 is ok, because we were interrupted from userland) with the saved IPL in the stack frame, and then set the IPL to the one we just got out of the saved stack frame. Since ithreads only block for SMP, and due to priority propagation and the high priority of ithreads, the userland process won't run again until the ithread has completed and run. We will only be running processes that are in the kernel. Once a process in the kernel releases the mutex that the ithread is blocked on, it will resume its normal priority, and the ithread will run immediately (since the ithread has higher priority), dropping the IPL back down. The process in the kernel won't return to userland without dropping the lock, so userland won't ever be running at an IPL other than 0. Note that ithreads will only block and priority propagation only needs to work in the SMP case. The only way an ithread will block in the UP case is if the interrupted process is in the kernel, and it will run next (since it is the second highest priority since it was just chosen to run last) and eventually release the lock enabling the ithread to run and lower the IPL. whew.. > Drew -- As a side note, if IPL is across all CPU's, then on an SMP machine, it might be possible that while one CPU is running the interrupt handler, another CPU will be running a userland process at a raised IPL, but I don't think there is anythign we can do about that, and I don't think it will hurt us since the only thing that really cares about/is affected by the IPL is the kernel. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 12: 7: 6 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 12:07:01 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 17F5437B69B for ; Tue, 2 Jan 2001 12:06:49 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f02K6WG01735 for ; Tue, 2 Jan 2001 12:06:32 -0800 (PST) (envelope-from john@baldwin.cx) Resent-Message-Id: <200101022006.f02K6WG01735@meow.osd.bsdi.com> Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Resent-Date: Fri, 17 Nov 2000 12:15:02 -0800 (PST) Resent-From: John Baldwin Resent-To: Andrew Gallatin Date: Tue, 02 Jan 2001 12:06:56 -0800 (PST) From: John Baldwin To: alpha@FreeBSD.org Subject: Disabling ints via IPL Resent-Sender: john@baldwin.cx Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Part VI: On 17-Nov-00 Andrew Gallatin wrote: > So the answer is "yes; but its not as bad I thought" because the > ithread is going to run fairly soon. > > It would seem that we don't need to go messing with the frame. All we > really need to do is to avoid dropping the IPL prior to running the > AST if we're on a PC164. And also never mask any interrupts if we're > on a PC164, since it seems the real problem is with unmasking them. We still have to mess with the frame to handle the case when we get an interrupt while we are in teh kernel and we don't call ast() on the way out. > It would also seem that we need to make sure we have enough room on > the kernel stack to store "recursive" interrupt contexts for each > platform, one frame for each irq that could possibly come in when we > drop the IPL to 0 in exception_return(). It won't be dropped to 0 unless a non-device I/O interrupt posts an ast and is returning to userland. > Drew -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 12:16:14 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 12:16:04 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 923B037B402 for ; Tue, 2 Jan 2001 12:16:04 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f02KFjG01917; Tue, 2 Jan 2001 12:15:45 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 02 Jan 2001 12:16:09 -0800 (PST) From: John Baldwin To: Matthew Jacob Subject: RE: Interrupt threads Cc: alpha@FreeBSD.org, Doug Rabson Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 02-Jan-01 Matthew Jacob wrote: > On Tue, 2 Jan 2001, John Baldwin wrote: > >> >> On 28-Dec-00 Doug Rabson wrote: >> > I started trying to work on changing the interrupt system so that the >> > ithread runs with i/o interrupts disabled, which would allow us to remove >> > the ugly code which tries to disable the interrupt sources. >> > >> > Unfortunately I immediately came up against a brick wall - the very first >> > interrupt interrupted a proc which owned Giant and the ithread also wanted >> > Giant. It tried to block, which switched back to the Giant owner with >> > interrupts enabled, causing the interrupt to fire again. >> > >> > I'm not sure what the right approach to solving this is. Possibly we could >> > 'lend' the mutex holder the IPL of the blocking thread in a similar way to >> > priority propagation. Another idea is to link thread IPL directly to its >> > priority so that when the ithread lends its priority, the mutex owner will >> > automagically run with raised IPL. >> >> I detailed what I think is a way of using IPL to do this in a pair of >> e-mails >> to Drew that Matt was copied on. I'll go dig them up and forward them to >> here. >> However, tying IPL to a process or a mutex is a mistake I think. You can't >> tie >> it to Giant because Giant is going away eventually. You can't tie it to a >> process because the first context switch that doesn't switch into the >> ithread >> will cause the interrupt to fire again. Instead, you basically have to futz >> with the trapframe in the interrupt handler so it doesn't lower IPL upon >> returning from teh interrupt, and don't lower the IPL again until the >> interrupt >> handler completes and the ithread finishes. Interacting properly with ast() >> on >> this makes it a bit more tricky. Let me go dig up my e-mails and forward >> them >> to the list. > > Please do. I agree this is tricky. > > I'll reiterate what I said a while back (insofar as I recall) and add: > > 1. It should be a bug to have the scheduler switch to a process that returns > to user space while leaving ithreads blocked. Hell, it should be a bug for > any > process that enters kernel context and acquires an SMP lock to not release it > before returning to user space. This is already true... > 2. Giant is like any other mutex in this context- whoever holds Giant should > be resumed if an ithread hits Giant. As soon as they drop Giant there should > be an immediate cpu_switch which had better resume the [ one of the ] > ithread[s] that had been blocked. Since ithreads are a higher priority than any other process (they are in their own separate run queue for goodness sake) this is already true.. > 3. You should not have to do anything with a trapframe until you actually are > returning from an interrupt. You can't assume that a 'return from interrupt' > can return with IPL set to non-zero. This is such a POLA violation that I > wouldn't expect it to work much of anywhere. Basically, you should take an > interrupt and immediately have the ithread for it run (unless fast- and until > we can get this right, only allow one non-fast interrupt at a time for > alpha). If this ithread hits a lock and can't get it, the holder of that lock > (whether Giant, Fred, Foo, Bar) gets resumed until it drops that lock, > whereupon the ithread should be resumed. This can repeat until the ithread is > done, whereupon a real return from interrupt can occur. For nested interrupts (clock interrupt during a normal interrupt for example) the IPL can _already_ be non-zero in the trapframe. However, the lock contention you describe already holds true because ithreads have such a high priority. > Unfortunately, I think we've begun to experience what Solaris had to put up > with in this respect, but so it goes. I would rather have a lot more in the > above model but this strikes me as something which very closely adheres to > what was the advertised SMP model we got from BSDi- and seems to have some > commented out code about this. The light weight ithreads will make performance slightly better, but they won't solve this problem. When an ithread blocks on a mutex, you still have the problem of switching to another process and running it while still needing to disable the interrupt. That we won't ever get away from. > 4. What defeated me immediately upon looking at Doug's stuff is all of the > thread pri seems to be a software construct, so has no real hardware > linkage. Additionally, I did not take the time to try and find an easy way to > find and reschdule the proc that holds a lock if I'm trying to acquire it > from > an ithread and am blocking. Seems to be a bit of work there. Yes, you can't tie the IPL to a thread. The IPL is tied to two events: 1) An interrupt trigger raises the IPL 2) Handling the interrupt lowers the IPL back to where it was. Since 2) is now asynchronous with respect to 1) sort of, we have to be a bit more tricky with when we lower the IPL rather than letting the machine do it for us. > -matt -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 12:24: 3 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 12:23:59 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id F36ED37B402; Tue, 2 Jan 2001 12:23:58 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id MAA22208; Tue, 2 Jan 2001 12:23:59 -0800 Date: Tue, 2 Jan 2001 12:23:58 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: alpha@FreeBSD.org, Doug Rabson Subject: RE: Interrupt threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 2. Giant is like any other mutex in this context- whoever holds Giant should > > be resumed if an ithread hits Giant. As soon as they drop Giant there should > > be an immediate cpu_switch which had better resume the [ one of the ] > > ithread[s] that had been blocked. > > Since ithreads are a higher priority than any other process (they are in their > own separate run queue for goodness sake) this is already true.. yes, yes, just checking.. > > > 3. You should not have to do anything with a trapframe until you actually are > > returning from an interrupt. You can't assume that a 'return from interrupt' > > can return with IPL set to non-zero. This is such a POLA violation that I > > wouldn't expect it to work much of anywhere. Basically, you should take an > > interrupt and immediately have the ithread for it run (unless fast- and until > > we can get this right, only allow one non-fast interrupt at a time for > > alpha). If this ithread hits a lock and can't get it, the holder of that lock > > (whether Giant, Fred, Foo, Bar) gets resumed until it drops that lock, > > whereupon the ithread should be resumed. This can repeat until the ithread is > > done, whereupon a real return from interrupt can occur. > > For nested interrupts (clock interrupt during a normal interrupt for example) > the IPL can _already_ be non-zero in the trapframe. However, the lock > contention you describe already holds true because ithreads have such a high > priority. Clock on alpha is something of an oddity- it comes in not as an interrupt but as a separate vector. >... > > The light weight ithreads will make performance slightly better, but they won't > solve this problem. When an ithread blocks on a mutex, you still have the > problem of switching to another process and running it while still needing to > disable the interrupt. That we won't ever get away from. You switch to the process w/o changing IPL. It is resumed at the IPL of the ithread that blocked. In the software way of looking at it, it inherits the priority of the ithread until it releases the lock that caused it to be resumed. > > > 4. What defeated me immediately upon looking at Doug's stuff is all of the > > thread pri seems to be a software construct, so has no real hardware > > linkage. Additionally, I did not take the time to try and find an easy way to > > find and reschdule the proc that holds a lock if I'm trying to acquire it > > from > > an ithread and am blocking. Seems to be a bit of work there. > > Yes, you can't tie the IPL to a thread. The IPL is tied to two events: > > 1) An interrupt trigger raises the IPL > 2) Handling the interrupt lowers the IPL back to where it was. > > Since 2) is now asynchronous with respect to 1) sort of, we have to be a bit > more tricky with when we lower the IPL rather than letting the machine do it > for us. This is where we disagree. You must tie the IPL to a thread if you cannot disable interrupts. I Look- this arguments is a waste of time. When actually works, we'll see what's what. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 12:57:10 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 12:57:07 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by hub.freebsd.org (Postfix) with ESMTP id 4C2CE37B69D; Tue, 2 Jan 2001 12:57:06 -0800 (PST) Received: from nas1-172.cgy.club-internet.fr (nas1-172.cgy.club-internet.fr [195.36.197.172]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA09642; Tue, 2 Jan 2001 21:56:59 +0100 (MET) Date: Tue, 2 Jan 2001 20:56:36 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Matthew Jacob Cc: John Baldwin , alpha@FreeBSD.ORG, Doug Rabson Subject: RE: Interrupt threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 2 Jan 2001, Matthew Jacob wrote: > You switch to the process w/o changing IPL. It is resumed at the IPL of t= he > ithread that blocked. In the software way of looking at it, it inherits t= he > priority of the ithread until it releases the lock that caused it to be > resumed. Just a tiny question and remark: We must keep in mind (at it I have this in mind) that IPL is a thing local to a CPU but MUTEXes are global synchronisation objects. What happens if a ithread want to acquire a MUTEX owned by a thread=20 running on another CPU ? In my $0.02 humble opinion, I think that we should probably be able from an ithread to just spinlock on a MUTEX that is already owned, unless we are believing in miracles. > > > 4. What defeated me immediately upon looking at Doug's stuff is all o= f the > > > thread pri seems to be a software construct, so has no real hardware > > > linkage. Additionally, I did not take the time to try and find an eas= y way to > > > find and reschdule the proc that holds a lock if I'm trying to acquir= e it > > > from > > > an ithread and am blocking. Seems to be a bit of work there. IMO, the real issue is pointed here. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 13: 8:47 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 13:08:45 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id AF29337B400; Tue, 2 Jan 2001 13:08:44 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA22415; Tue, 2 Jan 2001 13:08:41 -0800 Date: Tue, 2 Jan 2001 13:08:40 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: John Baldwin , alpha@FreeBSD.ORG, Doug Rabson Subject: RE: Interrupt threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > On Tue, 2 Jan 2001, Matthew Jacob wrote: > > > You switch to the process w/o changing IPL. It is resumed at the IPL of the > > ithread that blocked. In the software way of looking at it, it inherits the > > priority of the ithread until it releases the lock that caused it to be > > resumed. > > Just a tiny question and remark: > > We must keep in mind (at it I have this in mind) that IPL is a thing local > to a CPU but MUTEXes are global synchronisation objects. That's absolutely correct. > What happens if a ithread want to acquire a MUTEX owned by a thread > running on another CPU ? > > In my $0.02 humble opinion, I think that we should probably be able from > an ithread to just spinlock on a MUTEX that is already owned, unless we > are believing in miracles. This is why Solaris (and FreeBSD) makes a distinction between Spin and Adaptive locks. The default we have for all of this are adaptive locks- the ithread that tries to snag a lock that's held elsewhere will cause a reschedule. For a single CPU case, the thread that holds the lock should be resumed so the lock can be freed up as soon as possible. For the multiple CPU case, a spin should occur. The net result is the same- the ithread wanting the lock that's held elsewhere has to wait until that lock is clear. We've been fussing mostly over the issue that interrupt passivating doesn't seem to occur as cleanly as we'd like on all platforms. What will help get rid of the awful inefficiencies that this will bring in will be the active rewriting of drivers to choose locking strategies that will avoid this. We're very early in this stage so that we have broad swaths where things Just Don't Work Well(tm). > > > > > 4. What defeated me immediately upon looking at Doug's stuff is all of the > > > > thread pri seems to be a software construct, so has no real hardware > > > > linkage. Additionally, I did not take the time to try and find an easy way to > > > > find and reschdule the proc that holds a lock if I'm trying to acquire it > > > > from > > > > an ithread and am blocking. Seems to be a bit of work there. > > IMO, the real issue is pointed here. I don't understand this. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 13:51:57 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 13:51:56 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from web11601.mail.yahoo.com (web11601.mail.yahoo.com [216.136.172.53]) by hub.freebsd.org (Postfix) with SMTP id 568E237B400 for ; Tue, 2 Jan 2001 13:51:56 -0800 (PST) Message-ID: <20010102215156.28929.qmail@web11601.mail.yahoo.com> Received: from [207.36.131.180] by web11601.mail.yahoo.com; Tue, 02 Jan 2001 13:51:56 PST Date: Tue, 2 Jan 2001 13:51:56 -0800 (PST) From: Greg Meno Subject: Direct Rendering Infrastructure To: alpha@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is there any plan underway to implement DRI in freebsd? I've looked at freebsd.org and couldn't find a single mention of it... tia Greg __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 14:17:30 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 14:17:27 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from front4.grolier.fr (front4.grolier.fr [194.158.96.54]) by hub.freebsd.org (Postfix) with ESMTP id DDF9F37B400; Tue, 2 Jan 2001 14:17:25 -0800 (PST) Received: from nas1-145.cgy.club-internet.fr (nas1-145.cgy.club-internet.fr [195.36.197.145]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA21104; Tue, 2 Jan 2001 23:17:18 +0100 (MET) Date: Tue, 2 Jan 2001 22:16:40 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Matthew Jacob Cc: John Baldwin , alpha@FreeBSD.ORG, Doug Rabson Subject: RE: Interrupt threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 2 Jan 2001, Matthew Jacob wrote: > > On Tue, 2 Jan 2001, Matthew Jacob wrote: > >=20 > > > You switch to the process w/o changing IPL. It is resumed at the IPL = of the > > > ithread that blocked. In the software way of looking at it, it inheri= ts the > > > priority of the ithread until it releases the lock that caused it to = be > > > resumed. > >=20 > > Just a tiny question and remark: > >=20 > > We must keep in mind (at it I have this in mind) that IPL is a thing lo= cal > > to a CPU but MUTEXes are global synchronisation objects. >=20 > That's absolutely correct. >=20 > > What happens if a ithread want to acquire a MUTEX owned by a thread=20 > > running on another CPU ? > >=20 > > In my $0.02 humble opinion, I think that we should probably be able fro= m > > an ithread to just spinlock on a MUTEX that is already owned, unless we > > are believing in miracles. >=20 > This is why Solaris (and FreeBSD) makes a distinction between Spin and > Adaptive locks. The default we have for all of this are adaptive locks- t= he > ithread that tries to snag a lock that's held elsewhere will cause a > reschedule. >=20 > For a single CPU case, the thread that holds the lock should be resumed s= o the > lock can be freed up as soon as possible. For the multiple CPU case, a sp= in > should occur. The net result is the same- the ithread wanting the lock th= at's > held elsewhere has to wait until that lock is clear. We've been fussing m= ostly > over the issue that interrupt passivating doesn't seem to occur as cleanl= y as > we'd like on all platforms. OK for the mutex model, but possibly, there is no need to passivate interrupts nor tamper too much with IPLs, in my theory (may-be too simplistic). The harware will raise IPL as needed and interrupt handling return stuff will restore previous IPL as needed (Higher IPLs will nest). We just have to handle _software_ priorities and priority inheritance accordingly to current IPL in order not to deadlock if we have to reschedule. In other words, software priorities must be monotonic with regards to=20 corresponding IPLs. Is this too simple or what did I miss ? > What will help get rid of the awful inefficiencies that this will bring i= n > will be the active rewriting of drivers to choose locking strategies that= will > avoid this. We're very early in this stage so that we have broad swaths w= here > things Just Don't Work Well(tm). May be, in the future, a new driver model that would consist in: - A 'as fast as possible' upper half that gets the interrupt condition and clear it at device side, and avoid contentions as possible. and, - a lower half that can run in another context (thread of whatever can allow interrupts) G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 2 14:29:22 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 14:29:20 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from toetag.com (toetag.com [63.192.202.42]) by hub.freebsd.org (Postfix) with ESMTP id B8EFD37B404 for ; Tue, 2 Jan 2001 14:29:19 -0800 (PST) Received: from toetag.com (tom@unhooked.net [63.192.202.44]) by toetag.com (8.9.3/8.9.0) with ESMTP id OAA11640; Tue, 2 Jan 2001 14:27:20 -0800 (PST) Message-Id: <200101022227.OAA11640@toetag.com> X-Mailer: exmh version 2.2 08/09/2000 with version: MH 6.8.3 #1[UCI] To: Greg Meno Cc: alpha@freebsd.org Subject: Re: Direct Rendering Infrastructure In-reply-to: Your message of "Tue, 02 Jan 2001 13:51:56 PST." <20010102215156.28929.qmail@web11601.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Jan 2001 14:27:20 -0800 From: "Tom" Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you check the mailing list archives, you'll see some support for DRI. Not sure of status on using DRI on an Alpha. http://www.FreeBSD.org/cgi/search.cgi?words=dri&max=25&sort=score&index=recent&source=freebsd-questions On Tue, 02 Jan 2001 13:51:56 PST, Greg Meno writes: >Is there any plan underway to implement DRI in >freebsd? >I've looked at freebsd.org and couldn't find a single >mention of it... > >tia >Greg > >__________________________________________________ >Do You Yahoo!? >Yahoo! Photos - Share your holiday photos online! >http://photos.yahoo.com/ > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-alpha" in the body of the message -- tom@unhooked.net ICQ - 16163541 Spam: the other white meat. AIM - twjansen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jan 3 2:11:42 2001 From owner-freebsd-alpha@FreeBSD.ORG Wed Jan 3 02:11:40 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 6800037B400; Wed, 3 Jan 2001 02:11:39 -0800 (PST) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 14DktN-000C4n-0Y; Wed, 3 Jan 2001 10:11:37 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA63503; Wed, 3 Jan 2001 10:13:50 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 3 Jan 2001 10:13:23 +0000 (GMT) From: Doug Rabson To: John Baldwin Cc: alpha@freebsd.org Subject: RE: Interrupt threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 2 Jan 2001, John Baldwin wrote: > > On 28-Dec-00 Doug Rabson wrote: > > I started trying to work on changing the interrupt system so that the > > ithread runs with i/o interrupts disabled, which would allow us to remove > > the ugly code which tries to disable the interrupt sources. > > > > Unfortunately I immediately came up against a brick wall - the very first > > interrupt interrupted a proc which owned Giant and the ithread also wanted > > Giant. It tried to block, which switched back to the Giant owner with > > interrupts enabled, causing the interrupt to fire again. > > > > I'm not sure what the right approach to solving this is. Possibly we could > > 'lend' the mutex holder the IPL of the blocking thread in a similar way to > > priority propagation. Another idea is to link thread IPL directly to its > > priority so that when the ithread lends its priority, the mutex owner will > > automagically run with raised IPL. > > I detailed what I think is a way of using IPL to do this in a pair of e-mails > to Drew that Matt was copied on. I'll go dig them up and forward them to here. > However, tying IPL to a process or a mutex is a mistake I think. You can't tie > it to Giant because Giant is going away eventually. You can't tie it to a > process because the first context switch that doesn't switch into the ithread > will cause the interrupt to fire again. Instead, you basically have to futz > with the trapframe in the interrupt handler so it doesn't lower IPL upon > returning from teh interrupt, and don't lower the IPL again until the interrupt > handler completes and the ithread finishes. Interacting properly with ast() on > this makes it a bit more tricky. Let me go dig up my e-mails and forward them > to the list. I've been thinking about this a lot over the last few days and it seems to me that linking IPL directly to the process priority would be a very clean way of dealing with this. It would mean finally fixing and enabling the priority propagation code though. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jan 3 3:13: 2 2001 From owner-freebsd-alpha@FreeBSD.ORG Wed Jan 3 03:13:01 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from grafin.fujimori.cache.waseda.ac.jp (grafin.fujimori.cache.waseda.ac.jp [133.9.152.154]) by hub.freebsd.org (Postfix) with ESMTP id CDD1B37B400 for ; Wed, 3 Jan 2001 03:13:00 -0800 (PST) Received: from grafin.fujimori.cache.waseda.ac.jp (fujimori@localhost [127.0.0.1]) by grafin.fujimori.cache.waseda.ac.jp (8.9.3/3.7W) with ESMTP id UAA32163 for ; Wed, 3 Jan 2001 20:12:54 +0900 Message-Id: <200101031112.UAA32163@grafin.fujimori.cache.waseda.ac.jp> To: freebsd-alpha@freebsd.org Subject: bus_dmamap_load Date: Wed, 03 Jan 2001 20:12:54 +0000 From: Yoriaki FUJIMORI Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear folks, When I come to my office today, I noticed that 4.2 kernel reported something like bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 when I invoked dmesg. (I saw about 10 same lines.) I do not figure out why this happened when none of us used machines. Could someone of you tell me about this? Thank you for your attention. Yoriaki Fujimori To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jan 3 9: 1:46 2001 From owner-freebsd-alpha@FreeBSD.ORG Wed Jan 3 09:01:45 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E4E4137B400 for ; Wed, 3 Jan 2001 09:01:44 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA25802; Wed, 3 Jan 2001 09:01:37 -0800 Date: Wed, 3 Jan 2001 09:01:35 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Yoriaki FUJIMORI Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: bus_dmamap_load In-Reply-To: <200101031112.UAA32163@grafin.fujimori.cache.waseda.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Some more details about about hardware would be useful. On Wed, 3 Jan 2001, Yoriaki FUJIMORI wrote: > Dear folks, > When I come to my office today, I noticed that 4.2 kernel reported > something like > > bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 > > when I invoked dmesg. (I saw about 10 same lines.) > I do not figure out why this happened when none of us used machines. > Could someone of you tell me about this? > > Thank you for your attention. > Yoriaki Fujimori > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 2:24:47 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 02:24:46 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from dirac.th.physik.uni-bonn.de (dirac.th.physik.uni-bonn.de [131.220.161.119]) by hub.freebsd.org (Postfix) with SMTP id 3A83437B400 for ; Thu, 4 Jan 2001 02:24:46 -0800 (PST) Received: (qmail 14203 invoked from network); 4 Jan 2001 10:24:43 -0000 Received: from merlin.th.physik.uni-bonn.de (131.220.161.121) by dirac.th.physik.uni-bonn.de with SMTP; 4 Jan 2001 10:24:43 -0000 Received: (qmail 34459 invoked by uid 146); 4 Jan 2001 10:24:43 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Jan 2001 10:24:43 -0000 Date: Thu, 4 Jan 2001 11:24:43 +0100 (CET) From: Ralph Schreyer To: alpha@FreeBSD.ORG Subject: 2.88M floppy Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, sorry for that stupid question, but how can I get the 2.88M boot.flp on one floppy disk? The low level fdformat only provides floppies up to 1.72M. Ralph. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 2:41:34 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 02:41:33 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id 7C16537B400 for ; Thu, 4 Jan 2001 02:41:32 -0800 (PST) Received: from [195.11.243.26] (helo=Debug) by post.mail.nl.demon.net with smtp (Exim 3.14 #2) id 14E7pp-00018W-00; Thu, 04 Jan 2001 10:41:29 +0000 To: Ralph Schreyer , alpha@FreeBSD.ORG From: wkb@freebie.demon.nl Subject: Re: 2.88M floppy Date: Thu, 4 Jan 2001 10:41:29 GMT X-Mailer: www.webmail.nl.demon.net X-Sender: postmaster@wkb@freebie.demon.nl X-Originating-IP: 207.122.110.165 Message-Id: Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Use kern.flp, not boot.flp Confusing... Wilko > Hello, > > sorry for that stupid question, but how can I get the 2.88M boot.flp on > one floppy disk? The low level fdformat only provides floppies up to > 1.72M. > > Ralph. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 3:19:39 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 03:19:37 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from dirac.th.physik.uni-bonn.de (dirac.th.physik.uni-bonn.de [131.220.161.119]) by hub.freebsd.org (Postfix) with SMTP id B995E37B400 for ; Thu, 4 Jan 2001 03:19:36 -0800 (PST) Received: (qmail 14457 invoked from network); 4 Jan 2001 11:19:35 -0000 Received: from merlin.th.physik.uni-bonn.de (131.220.161.121) by dirac.th.physik.uni-bonn.de with SMTP; 4 Jan 2001 11:19:35 -0000 Received: (qmail 34724 invoked by uid 146); 4 Jan 2001 11:19:35 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Jan 2001 11:19:35 -0000 Date: Thu, 4 Jan 2001 12:19:35 +0100 (CET) From: Ralph Schreyer To: wkb@freebie.demon.nl Cc: alpha@FreeBSD.ORG Subject: Re: 2.88M floppy In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org OK, of course we used kern.flp and mfsroot.flp, but in the cases we needed e.g. the fixit.flp (2.88M, too) we had to mount it via NFS. So it would just be nice to have these 2.88M floppies to work with. (And secondly, since they are provided, there should be some way to use them) Ralph. ------------------------------------------------------------- On Thu, 4 Jan 2001 wkb@freebie.demon.nl wrote: > Use kern.flp, not boot.flp > > Confusing... > > Wilko > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 3:24:15 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 03:24:13 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 99A4537B400 for ; Thu, 4 Jan 2001 03:24:13 -0800 (PST) Received: from dragon.nuxi.com (Ipitythefoolthattrustsident@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id DAA94101; Thu, 4 Jan 2001 03:24:12 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.1/8.11.1) id f04BOA169621; Thu, 4 Jan 2001 03:24:10 -0800 (PST) (envelope-from obrien) Date: Thu, 4 Jan 2001 03:24:09 -0800 From: "David O'Brien" To: Ralph Schreyer Cc: alpha@FreeBSD.ORG Subject: Re: 2.88M floppy Message-ID: <20010104032409.A69577@dragon.nuxi.com> Reply-To: alpha@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from schreyer@th.physik.uni-bonn.de on Thu, Jan 04, 2001 at 11:24:43AM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: obrien@NUXI.com Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 04, 2001 at 11:24:43AM +0100, Ralph Schreyer wrote: > sorry for that stupid question, but how can I get the 2.88M boot.flp on > one floppy disk? Use an LS-120 or Zip floppy disk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 5:37:57 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 05:37:52 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from grafin.fujimori.cache.waseda.ac.jp (grafin.fujimori.cache.waseda.ac.jp [133.9.152.154]) by hub.freebsd.org (Postfix) with ESMTP id 23A0237B400 for ; Thu, 4 Jan 2001 05:37:51 -0800 (PST) Received: from grafin.fujimori.cache.waseda.ac.jp (fujimori@localhost [127.0.0.1]) by grafin.fujimori.cache.waseda.ac.jp (8.9.3/3.7W) with ESMTP id WAA03312; Thu, 4 Jan 2001 22:37:44 +0900 Message-Id: <200101041337.WAA03312@grafin.fujimori.cache.waseda.ac.jp> To: freebsd-alpha@freebsd.org Cc: mjacob@feral.com Subject: Re: bus_dmamap_load In-reply-to: Your message of "Wed, 03 Jan 2001 09:01:35 PST." Date: Thu, 04 Jan 2001 22:37:44 +0000 From: Yoriaki FUJIMORI Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thank you for your responce. I use one noname DEC-based NIC. The scsi card is one from Intraserver. In the following I attached the result of `dmesg'. ------------------------------------------ Unrecognized boot flag '0'. Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.2-RELEASE #0: Tue Nov 21 09:42:09 GMT 2000 jkh@rawhide.osd.bsdi.com:/usr/src/sys/compile/GENERIC EB164 Digital AlphaPC 164 480 MHz, 480MHz 8192 byte page size, 1 processor. CPU: EV56 (21164A) major=7 minor=1 extensions=0x1 OSF PAL rev: 0x1000800020117 real memory = 534339584 (521816K bytes) avail memory = 513990656 (501944K bytes) Preloaded elf kernel "kernel" at 0xfffffc0000766000. md0: Malloc disk cia0: ALCOR/ALCOR2, pass 3 cia0: extended capabilities: 21 pcib0: <2117x PCI host bus adapter> on cia0 pci0: on pcib0 de0: port 0x10100-0x1017f mem 0x84061100-0x8406117f irq 2 at device 5.0 on pci0 de0: interrupting at CIA irq 2 de0: DEC DE500-AA 21140A [10-100Mb/s] pass 2.0 de0: address 00:00:f8:1e:81:5a sym0: <875> port 0x10000-0x100ff mem 0x84060000-0x84060fff,0x84061000-0x840610ff irq 0 at device 6.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: interrupting at CIA irq 0 pci0: at 7.0 irq 1 isab0: at device 8.0 on pci0 isa0: on isab0 atapci0: port 0x10180-0x1018f irq 5 at device 11.0 on pci0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: interrupting at ISA irq 6 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 atkbd0: interrupting at ISA irq 1 psm0: irq 12 on atkbdc0 psm0: interrupting at ISA irq 12 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> mcclock0: at port 0x70-0x71 on isa0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio0: interrupting at ISA irq 4 sio1: reserved for low-level i/o ppc0: at port 0x3bc-0x3bf irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode plip0: cannot reserve interrupt, failed. lpt0: on ppbus0 lpt0: Polled port ppi0: on ppbus0 ppc0: interrupting at ISA irq 7 Timecounter "alpha" frequency 480000416 Hz Waiting 15 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. de0: enabling Full Duplex 100baseTX port Mounting root from ufs:/dev/da0a cd0 at sym0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) cd0: Attempt to query device size failed: NOT READY, Medium not present da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 -------------------------------------------------------- Thanks for your attention. Yoriaki Fujimori To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 8:58:10 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 08:58:08 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 241D737B400 for ; Thu, 4 Jan 2001 08:58:08 -0800 (PST) Received: (qmail 19057 invoked by uid 0); 2 Jan 2001 23:18:57 -0000 Received: from ppp-34.pm02.hbg.nikoma.de (HELO feldregen) (212.122.132.97) by mail.gmx.net (mail06) with SMTP; 2 Jan 2001 23:18:57 -0000 From: "Klaus Berbach" To: "freebsd-alpha@FreeBSD.ORG" Date: Wed, 03 Jan 2001 00:22:18 +0100 Reply-To: "Klaus Berbach" Priority: Normal X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows 2000 (5.0.2195;1) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: =?iso-8859-1?q?can=B4t_compile_any_GUI_port?= Message-Id: <20010104165808.241D737B400@hub.freebsd.org> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Taking the stable or the latest ports (1.1.01), I don=B4t manage to get either icewm, gnome nor kde2 compiled. Anyone managed or is it really the ports (respectively the compiler) ? I am using freebsd 4.2. I haven=B4t modified the compilerflags. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 9: 8:45 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 09:08:44 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mail2.clarkson.edu (mail.clarkson.edu [128.153.4.10]) by hub.freebsd.org (Postfix) with SMTP id 4A1C937B400 for ; Thu, 4 Jan 2001 09:08:44 -0800 (PST) Received: (qmail 6393 invoked by uid 0); 4 Jan 2001 17:08:35 -0000 Received: from isis.aoc.clarkson.edu (128.153.130.35) by mail.clarkson.edu with SMTP; 4 Jan 2001 17:08:35 -0000 Date: Thu, 4 Jan 2001 12:08:34 -0500 (EST) From: Todd Cohen X-Sender: cohentl@isis.aoc.clarkson.edu To: freebsd-alpha@FreeBSD.ORG Subject: coda support?? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm thinking about trying out CODA and was wondering if the options for it in the LINT file for the i386 platform are valid for the alpha platform. Why is there no lint file for the alpha? __________________________________________________________________________ ICMP: The protocol that goes PING! I like angles, but only to a degree. cthread. cthread_fork(). Fork, thread, fork! Black holes suck. http://wckn.clarkson.edu/~cohentl/ Real_men_don't_need_spacebars. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 9:15:49 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 09:15:47 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 4A29E37B400 for ; Thu, 4 Jan 2001 09:15:47 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id MAA07802; Thu, 4 Jan 2001 12:15:43 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f04HFh265869; Thu, 4 Jan 2001 12:15:43 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 4 Jan 2001 12:15:42 -0500 (EST) To: Todd Cohen Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: coda support?? In-Reply-To: References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14932.44648.231156.115203@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Todd Cohen writes: > I'm thinking about trying out CODA and was wondering if the options for it > in the LINT file for the i386 platform are valid for the alpha platform. It should probably work, or come darned close to it at least... It shouldn't be MD. > Why is there no lint file for the alpha? A lack of anybody willing to do the drudgery of mirroring lint between x86 and alpha, filtering out machine dependant devices. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 9:46:47 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 09:46:43 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 7654537B400 for ; Thu, 4 Jan 2001 09:46:42 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA30699; Thu, 4 Jan 2001 09:46:33 -0800 Date: Thu, 4 Jan 2001 09:46:31 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Yoriaki FUJIMORI Cc: freebsd-alpha@freebsd.org Subject: Re: bus_dmamap_load In-Reply-To: <200101041337.WAA03312@grafin.fujimori.cache.waseda.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The trick now is to figure out who is passing a bogus value to bus_dmamap_load. The value of buf_len (0xfaae8000) looks suspicious. Since I hve essentially the same h/w (except for the symbios card) in a PC164 that runs 4.2 just fine, I would suspect the sym driver. But needs to happen is some better debugging for this. I take it that you aren't really running on this h/w yet (i.e, you haven't been able to install)? -matt On Thu, 4 Jan 2001, Yoriaki FUJIMORI wrote: > > Thank you for your responce. > I use one noname DEC-based NIC. The scsi card is one from Intraserver. > > In the following I attached the result of `dmesg'. > > ------------------------------------------ > Unrecognized boot flag '0'. > Copyright (c) 1992-2000 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 4.2-RELEASE #0: Tue Nov 21 09:42:09 GMT 2000 > jkh@rawhide.osd.bsdi.com:/usr/src/sys/compile/GENERIC > EB164 > Digital AlphaPC 164 480 MHz, 480MHz > 8192 byte page size, 1 processor. > CPU: EV56 (21164A) major=7 minor=1 extensions=0x1 > OSF PAL rev: 0x1000800020117 > real memory = 534339584 (521816K bytes) > avail memory = 513990656 (501944K bytes) > Preloaded elf kernel "kernel" at 0xfffffc0000766000. > md0: Malloc disk > cia0: ALCOR/ALCOR2, pass 3 > cia0: extended capabilities: 21 > pcib0: <2117x PCI host bus adapter> on cia0 > pci0: on pcib0 > de0: port 0x10100-0x1017f mem 0x84061100-0x8406117f irq 2 at device 5.0 on pci0 > de0: interrupting at CIA irq 2 > de0: DEC DE500-AA 21140A [10-100Mb/s] pass 2.0 > de0: address 00:00:f8:1e:81:5a > sym0: <875> port 0x10000-0x100ff mem 0x84060000-0x84060fff,0x84061000-0x840610ff irq 0 at device 6.0 on pci0 > sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking > sym0: open drain IRQ line driver, using on-chip SRAM > sym0: using LOAD/STORE-based firmware. > sym0: interrupting at CIA irq 0 > pci0: at 7.0 irq 1 > isab0: at device 8.0 on pci0 > isa0: on isab0 > atapci0: port 0x10180-0x1018f irq 5 at device 11.0 on pci0 > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > fdc0: interrupting at ISA irq 6 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > atkbd0: interrupting at ISA irq 1 > psm0: irq 12 on atkbdc0 > psm0: interrupting at ISA irq 12 > psm0: model Generic PS/2 mouse, device ID 0 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > sc0: on isa0 > sc0: VGA <16 virtual consoles, flags=0x200> > mcclock0: at port 0x70-0x71 on isa0 > sio0 at port 0x3f8-0x3ff irq 4 on isa0 > sio0: type 16550A > sio0: interrupting at ISA irq 4 > sio1: reserved for low-level i/o > ppc0: at port 0x3bc-0x3bf irq 7 on isa0 > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > plip0: cannot reserve interrupt, failed. > lpt0: on ppbus0 > lpt0: Polled port > ppi0: on ppbus0 > ppc0: interrupting at ISA irq 7 > Timecounter "alpha" frequency 480000416 Hz > Waiting 15 seconds for SCSI devices to settle > (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. > de0: enabling Full Duplex 100baseTX port > Mounting root from ufs:/dev/da0a > cd0 at sym0 bus 0 target 5 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) > cd0: Attempt to query device size failed: NOT READY, Medium not present > da0 at sym0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled > da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) > bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 > bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 > bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 > bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 > bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 > bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 > bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 > bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 > bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 > bus_dmamap_load: Too many segs! buf_len = 0xfaae8000 > > -------------------------------------------------------- > > Thanks for your attention. > Yoriaki Fujimori > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 9:57:25 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 09:57:24 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id EA4E937B400 for ; Thu, 4 Jan 2001 09:57:23 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id MAA08525; Thu, 4 Jan 2001 12:57:23 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f04HvNt66054; Thu, 4 Jan 2001 12:57:23 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 4 Jan 2001 12:57:23 -0500 (EST) To: Yoriaki FUJIMORI Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: bus_dmamap_load In-Reply-To: <200101041337.WAA03312@grafin.fujimori.cache.waseda.ac.jp> References: <200101041337.WAA03312@grafin.fujimori.cache.waseda.ac.jp> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14932.47385.891173.682239@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Yoriaki FUJIMORI writes: > Digital AlphaPC 164 480 MHz, 480MHz Is this machine over- or under-clocked? I could be all wet, but I don't think that 480Mhz is a valid cpu speed. I don't know how the clocking works on a PC164, but if you're running the pci bus out of spec, all bets are off. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 10: 5:38 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 10:05:36 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 58E5F37B400 for ; Thu, 4 Jan 2001 10:05:33 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA30829; Thu, 4 Jan 2001 10:05:11 -0800 Date: Thu, 4 Jan 2001 10:05:10 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Andrew Gallatin Cc: Yoriaki FUJIMORI , freebsd-alpha@FreeBSD.ORG Subject: Re: bus_dmamap_load In-Reply-To: <14932.47385.891173.682239@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Oh, I dunno- I think I have the same issue- Aspen Systems PC164 systems came in some wierd speeds- I can't remember whether mine reports 480 or 440- for sure SRM complains about it. But you may be right if the RAM is overclocked. On Thu, 4 Jan 2001, Andrew Gallatin wrote: > > Yoriaki FUJIMORI writes: > > > Digital AlphaPC 164 480 MHz, 480MHz > > Is this machine over- or under-clocked? I could be all wet, but I > don't think that 480Mhz is a valid cpu speed. I don't know how the > clocking works on a PC164, but if you're running the pci bus out of > spec, all bets are off. > > Drew > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 10:32:19 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 10:32:18 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from baron.fujimori.cache.waseda.ac.jp (baron.fujimori.cache.waseda.ac.jp [133.9.152.155]) by hub.freebsd.org (Postfix) with ESMTP id 9FD5A37B400 for ; Thu, 4 Jan 2001 10:32:17 -0800 (PST) Received: from baron.fujimori.cache.waseda.ac.jp (localhost [127.0.0.1]) by baron.fujimori.cache.waseda.ac.jp (8.11.1/8.11.1) with ESMTP id f04IWFc22315 for ; Fri, 5 Jan 2001 03:32:16 +0900 (JST) (envelope-from fujimori@baron.fujimori.cache.waseda.ac.jp) Message-Id: <200101041832.f04IWFc22315@baron.fujimori.cache.waseda.ac.jp> To: freebsd-alpha@freebsd.org Subject: Re: bus_dmamap_load In-reply-to: Your message of "Thu, 04 Jan 2001 09:46:31 PST." Date: Fri, 05 Jan 2001 03:32:15 +0900 From: Yoriaki FUJIMORI Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear matt, Thanks for your comments. The system has been running for a few months. First, I installed 4.1R, and a few weeks ago I upgraded to 4.2R via ftp. I just saw this funny message once: in the log, it happened on Dec 27, when the heating system was stopped. In the past, however, I experienced two or three kernel panics that resulted in `syncing disks .... done' So, the system may have some hardware problems, I guess. Yesterday and today, the system seems to be al'right. Meanwhile, as Drew wrote, the system is slightly overclocked against the pci bus. I could not find original 50Mhz crystall at hand, I inserted 48.0, with the ratio 14. (480/14=34.28.. is current pci bus speed in my system.) Best regards, Yoriaki Fujimori To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 12: 1:51 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 12:01:49 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from speedus.com (saturn.speedus.net [63.251.16.34]) by hub.freebsd.org (Postfix) with ESMTP id 5820637B402 for ; Thu, 4 Jan 2001 12:01:49 -0800 (PST) Received: from supero (usr41209@p17-80.dialup.speedus.net [63.251.17.80]) by speedus.com (8.9.3/8.9.3) with SMTP id PAA17578 for ; Thu, 4 Jan 2001 15:01:42 -0500 (EST) Return-Receipt-To: "Nexgen Inc" Reply-To: From: "Nexgen Inc" To: Subject: sysinstall Date: Thu, 4 Jan 2001 15:01:26 -0500 Message-ID: <008301c07689$1ecb7020$7300a8c0@FLOM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Disposition-Notification-To: "Nexgen Inc" Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is there a way to use "/stand/sysinstall" to configure the network interface cards after the KERNEL is compiled? The NIC configuration dialog box (under Post Installation configuration >> network) seems to be a very convenient way to edit and update NIC information, and while I am able to start it, I see no way of committing the NIC changes to the Kernel that is configured on the hard drive. While the KERNEL is custom, it is substantially close to generic (plus or minus a couple of options) so the default settings in sysinstall should work fine, if I can get them to save. Even so, worst case scenario, you could just fill in a couple of paths to certain files to effect updates. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 12:29:35 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 12:29:29 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from front5.grolier.fr (front5.grolier.fr [194.158.96.55]) by hub.freebsd.org (Postfix) with ESMTP id 959D237B400 for ; Thu, 4 Jan 2001 12:29:28 -0800 (PST) Received: from nas1-206.cgy.club-internet.fr (nas1-206.cgy.club-internet.fr [195.36.197.206]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA19842; Thu, 4 Jan 2001 21:29:02 +0100 (MET) Date: Thu, 4 Jan 2001 20:28:36 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Matthew Jacob Cc: Yoriaki FUJIMORI , freebsd-alpha@FreeBSD.ORG Subject: Re: bus_dmamap_load In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 4 Jan 2001, Matthew Jacob wrote: > The trick now is to figure out who is passing a bogus value > to bus_dmamap_load. The value of buf_len (0xfaae8000) looks > suspicious. Only looks? Do you mean that you are unsure? ;-) > Since I hve essentially the same h/w (except for the symbios card) in a P= C164 > that runs 4.2 just fine, I would suspect the sym driver. But needs to hap= pen > is some better debugging for this. I take it that you aren't really runni= ng on > this h/w yet (i.e, you haven't been able to install)? It is likely the `sym' driver that called bus_dma_map_load() with the bogus value, but it may well have received it as the length for an I/O from some upper layer. Only part of value is for sure bogus. The low 16 bits are possibly ok (0x8000=3D32K). Some 16 bit (short) counter accessed as 32 bit value will give you 16 stale bits as upper bits on little-endian machines, for example. Unfortunately, I haven't time at the moment for compiling the kernel -Wall and inspect all warnings messages that may let think about such a mistyped access. Btw, having 0 warnings using -Wall without using wild casts to hide them would help a lot. Is this in the 5.0 todo list? ;-) G=E9rard. > -matt >=20 >=20 >=20 > On Thu, 4 Jan 2001, Yoriaki FUJIMORI wrote: >=20 > >=20 > > Thank you for your responce. =20 > > I use one noname DEC-based NIC. The scsi card is one from Intraserver. > >=20 > > In the following I attached the result of `dmesg'. > >=20 > > ------------------------------------------ > > Unrecognized boot flag '0'. > > Copyright (c) 1992-2000 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199= 4 > > =09The Regents of the University of California. All rights reserved. > > FreeBSD 4.2-RELEASE #0: Tue Nov 21 09:42:09 GMT 2000 > > jkh@rawhide.osd.bsdi.com:/usr/src/sys/compile/GENERIC > > EB164 > > Digital AlphaPC 164 480 MHz, 480MHz > > 8192 byte page size, 1 processor. > > CPU: EV56 (21164A) major=3D7 minor=3D1 extensions=3D0x1 > > OSF PAL rev: 0x1000800020117 > > real memory =3D 534339584 (521816K bytes) > > avail memory =3D 513990656 (501944K bytes) > > Preloaded elf kernel "kernel" at 0xfffffc0000766000. > > md0: Malloc disk > > cia0: ALCOR/ALCOR2, pass 3 > > cia0: extended capabilities: 21 > > pcib0: <2117x PCI host bus adapter> on cia0 > > pci0: on pcib0 > > de0: port 0x10100-0x1017f mem 0x84061100= -0x8406117f irq 2 at device 5.0 on pci0 > > de0: interrupting at CIA irq 2 > > de0: DEC DE500-AA 21140A [10-100Mb/s] pass 2.0 > > de0: address 00:00:f8:1e:81:5a > > sym0: <875> port 0x10000-0x100ff mem 0x84060000-0x84060fff,0x84061000-0= x840610ff irq 0 at device 6.0 on pci0 > > sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking > > sym0: open drain IRQ line driver, using on-chip SRAM > > sym0: using LOAD/STORE-based firmware. > > sym0: interrupting at CIA irq 0 > > pci0: at 7.0 irq 1 > > isab0: at device 8.0 on pci0 > > isa0: on isab0 > > atapci0: port 0x10180-0x1018f irq 5 at device = 11.0 on pci0 > > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on is= a0 > > fdc0: interrupting at ISA irq 6 > > fdc0: FIFO enabled, 8 bytes threshold > > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > > atkbdc0: at port 0x60,0x64 on isa0 > > atkbd0: irq 1 on atkbdc0 > > atkbd0: interrupting at ISA irq 1 > > psm0: irq 12 on atkbdc0 > > psm0: interrupting at ISA irq 12 > > psm0: model Generic PS/2 mouse, device ID 0 > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on is= a0 > > sc0: on isa0 > > sc0: VGA <16 virtual consoles, flags=3D0x200> > > mcclock0: at port 0x70-0x71 on isa0 > > sio0 at port 0x3f8-0x3ff irq 4 on isa0 > > sio0: type 16550A > > sio0: interrupting at ISA irq 4 > > sio1: reserved for low-level i/o > > ppc0: at port 0x3bc-0x3bf irq 7 on isa0 > > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > > plip0: cannot reserve interrupt, failed. > > lpt0: on ppbus0 > > lpt0: Polled port > > ppi0: on ppbus0 > > ppc0: interrupting at ISA irq 7 > > Timecounter "alpha" frequency 480000416 Hz > > Waiting 15 seconds for SCSI devices to settle > > (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. > > de0: enabling Full Duplex 100baseTX port > > Mounting root from ufs:/dev/da0a > > cd0 at sym0 bus 0 target 5 lun 0 > > cd0: Removable CD-ROM SCSI-2 device=20 > > cd0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) > > cd0: Attempt to query device size failed: NOT READY, Medium not present > > da0 at sym0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access SCSI-3 device=20 > > da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queuein= g Enabled > > da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > >=20 > > -------------------------------------------------------- > >=20 > > Thanks for your attention. > > Yoriaki Fujimori > >=20 >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 13:10:15 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 13:10:11 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from front7.grolier.fr (front7.grolier.fr [194.158.96.57]) by hub.freebsd.org (Postfix) with ESMTP id CC51037B400 for ; Thu, 4 Jan 2001 13:10:10 -0800 (PST) Received: from nas1-57.cgy.club-internet.fr (nas1-57.cgy.club-internet.fr [195.36.197.57]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA15218; Thu, 4 Jan 2001 22:09:59 +0100 (MET) Date: Thu, 4 Jan 2001 21:09:34 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Matthew Jacob Cc: Yoriaki FUJIMORI , freebsd-alpha@FreeBSD.ORG Subject: Re: bus_dmamap_load In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 4 Jan 2001, Matthew Jacob wrote: > The trick now is to figure out who is passing a bogus value > to bus_dmamap_load. The value of buf_len (0xfaae8000) looks > suspicious. >=20 > Since I hve essentially the same h/w (except for the symbios card) in a P= C164 > that runs 4.2 just fine, I would suspect the sym driver. But needs to hap= pen > is some better debugging for this. I take it that you aren't really runni= ng on > this h/w yet (i.e, you haven't been able to install)? Btw, you missed the `de' driver that also performs bus_dmamap_load() on mbuf's as a possible candidate. Would be interesting to shut the `de' board and to give a try with a different network board long enough to see if it makes difference. G=E9rard. > -matt >=20 >=20 >=20 > On Thu, 4 Jan 2001, Yoriaki FUJIMORI wrote: >=20 > >=20 > > Thank you for your responce. =20 > > I use one noname DEC-based NIC. The scsi card is one from Intraserver. > >=20 > > In the following I attached the result of `dmesg'. > >=20 > > ------------------------------------------ > > Unrecognized boot flag '0'. > > Copyright (c) 1992-2000 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199= 4 > > =09The Regents of the University of California. All rights reserved. > > FreeBSD 4.2-RELEASE #0: Tue Nov 21 09:42:09 GMT 2000 > > jkh@rawhide.osd.bsdi.com:/usr/src/sys/compile/GENERIC > > EB164 > > Digital AlphaPC 164 480 MHz, 480MHz > > 8192 byte page size, 1 processor. > > CPU: EV56 (21164A) major=3D7 minor=3D1 extensions=3D0x1 > > OSF PAL rev: 0x1000800020117 > > real memory =3D 534339584 (521816K bytes) > > avail memory =3D 513990656 (501944K bytes) > > Preloaded elf kernel "kernel" at 0xfffffc0000766000. > > md0: Malloc disk > > cia0: ALCOR/ALCOR2, pass 3 > > cia0: extended capabilities: 21 > > pcib0: <2117x PCI host bus adapter> on cia0 > > pci0: on pcib0 > > de0: port 0x10100-0x1017f mem 0x84061100= -0x8406117f irq 2 at device 5.0 on pci0 > > de0: interrupting at CIA irq 2 > > de0: DEC DE500-AA 21140A [10-100Mb/s] pass 2.0 > > de0: address 00:00:f8:1e:81:5a > > sym0: <875> port 0x10000-0x100ff mem 0x84060000-0x84060fff,0x84061000-0= x840610ff irq 0 at device 6.0 on pci0 > > sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking > > sym0: open drain IRQ line driver, using on-chip SRAM > > sym0: using LOAD/STORE-based firmware. > > sym0: interrupting at CIA irq 0 > > pci0: at 7.0 irq 1 > > isab0: at device 8.0 on pci0 > > isa0: on isab0 > > atapci0: port 0x10180-0x1018f irq 5 at device = 11.0 on pci0 > > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on is= a0 > > fdc0: interrupting at ISA irq 6 > > fdc0: FIFO enabled, 8 bytes threshold > > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > > atkbdc0: at port 0x60,0x64 on isa0 > > atkbd0: irq 1 on atkbdc0 > > atkbd0: interrupting at ISA irq 1 > > psm0: irq 12 on atkbdc0 > > psm0: interrupting at ISA irq 12 > > psm0: model Generic PS/2 mouse, device ID 0 > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on is= a0 > > sc0: on isa0 > > sc0: VGA <16 virtual consoles, flags=3D0x200> > > mcclock0: at port 0x70-0x71 on isa0 > > sio0 at port 0x3f8-0x3ff irq 4 on isa0 > > sio0: type 16550A > > sio0: interrupting at ISA irq 4 > > sio1: reserved for low-level i/o > > ppc0: at port 0x3bc-0x3bf irq 7 on isa0 > > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > > plip0: cannot reserve interrupt, failed. > > lpt0: on ppbus0 > > lpt0: Polled port > > ppi0: on ppbus0 > > ppc0: interrupting at ISA irq 7 > > Timecounter "alpha" frequency 480000416 Hz > > Waiting 15 seconds for SCSI devices to settle > > (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. > > de0: enabling Full Duplex 100baseTX port > > Mounting root from ufs:/dev/da0a > > cd0 at sym0 bus 0 target 5 lun 0 > > cd0: Removable CD-ROM SCSI-2 device=20 > > cd0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) > > cd0: Attempt to query device size failed: NOT READY, Medium not present > > da0 at sym0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access SCSI-3 device=20 > > da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queuein= g Enabled > > da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > > bus_dmamap_load: Too many segs! buf_len =3D 0xfaae8000 > >=20 > > -------------------------------------------------------- > >=20 > > Thanks for your attention. > > Yoriaki Fujimori > >=20 >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 13:30:37 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 13:30:35 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id A1B6E37B402 for ; Thu, 4 Jan 2001 13:30:34 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id QAA12707; Thu, 4 Jan 2001 16:30:33 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f04LUX966747; Thu, 4 Jan 2001 16:30:33 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jan 2001 16:30:33 -0500 (EST) To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: bus_dmamap_load In-Reply-To: References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14932.59983.360316.243974@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org G=E9rard Roudier writes: > Btw, you missed the `de' driver that also performs bus_dmamap_load()= on > mbuf's as a possible candidate. >=20 Does it actually do this? I see all the code protected by: =09#if defined(TULIP_BUS_DMA) But I do not see TULIP_BUS_DMA defined anywhered. I think it was inherited from NetBSD and the define was clobbered in rev 1.19 of if_devar.h: =09Unifdef -U__NetBSD__ See: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_devar.h.diff?= r1=3D1.18&r2=3D1.19&f=3Dh Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 14:53:30 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 14:53:28 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from front1m.grolier.fr (front1m.grolier.fr [195.36.216.51]) by hub.freebsd.org (Postfix) with ESMTP id 6594037B400 for ; Thu, 4 Jan 2001 14:53:27 -0800 (PST) Received: from nas1-55.mea.club-internet.fr (nas1-55.mea.club-internet.fr [195.36.139.55]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA06017; Thu, 4 Jan 2001 23:53:23 +0100 (MET) Date: Thu, 4 Jan 2001 22:52:56 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Andrew Gallatin Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: bus_dmamap_load In-Reply-To: <14932.59983.360316.243974@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 4 Jan 2001, Andrew Gallatin wrote: > G=E9rard Roudier writes: > > Btw, you missed the `de' driver that also performs bus_dmamap_load() o= n > > mbuf's as a possible candidate. > >=20 >=20 > Does it actually do this? I see all the code protected by: >=20 > =09#if defined(TULIP_BUS_DMA) >=20 > But I do not see TULIP_BUS_DMA defined anywhered. I think it was > inherited from NetBSD and the define was clobbered in Indeed. I missed that. But the sym driver only calls bus_dmamap_load() in 2 places: 1) Using an hardcoded value for buflen (1 PAGE) for internal data structures allocation. 2) Using `csio->dxfer_len' when preparing an IO for the DMA. Place (1) is unlikely to lead to a size problem, and (2) is provided by CAM or upper layer. If there is a driver bug in driver code path (2), then it should likely have already triggerred, in my opinion. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 16:45:35 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 16:45:34 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 6F51137B400 for ; Thu, 4 Jan 2001 16:45:33 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id QAA32299; Thu, 4 Jan 2001 16:45:27 -0800 Date: Thu, 4 Jan 2001 16:45:26 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: Yoriaki FUJIMORI , freebsd-alpha@FreeBSD.ORG Subject: Re: bus_dmamap_load In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 4 Jan 2001, [ISO-8859-1] G=E9rard Roudier wrote: >=20 >=20 > On Thu, 4 Jan 2001, Matthew Jacob wrote: >=20 > > The trick now is to figure out who is passing a bogus value > > to bus_dmamap_load. The value of buf_len (0xfaae8000) looks > > suspicious. > >=20 > > Since I hve essentially the same h/w (except for the symbios card) in a= PC164 > > that runs 4.2 just fine, I would suspect the sym driver. But needs to h= appen > > is some better debugging for this. I take it that you aren't really run= ning on > > this h/w yet (i.e, you haven't been able to install)? >=20 > Btw, you missed the `de' driver that also performs bus_dmamap_load() on > mbuf's as a possible candidate. That's why I said 'possibly'.... And because pretty much the sole differenc= e between his PC164 and mine is the Symbios card..... >=20 > Would be interesting to shut the `de' board and to give a try with a > different network board long enough to see if it makes difference. No, no, no, since he's actually running with this, the smart thing to do is= to put a panic to DDB to get a traceback, i.e.: options DDB and change the printf in alpha/busdma_machdep.c to a panic. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 23: 6:30 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 23:06:28 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id BD74537B400 for ; Thu, 4 Jan 2001 23:06:27 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #4) id 14EQxG-0009vz-00 for freebsd-alpha@freebsd.org; Fri, 05 Jan 2001 07:06:26 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.1) id f0576qO71459 for freebsd-alpha@freebsd.org; Fri, 5 Jan 2001 08:06:52 +0100 (CET) (envelope-from wkb) Date: Fri, 5 Jan 2001 08:06:52 +0100 From: Wilko Bulte To: freebsd-alpha@freebsd.org Subject: buildworld failure Message-ID: <20010105080652.A71449@freebie.demon.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i X-OS: FreeBSD 4.2-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org When trying to buildworld -stable on alpha: cc -I/usr/src/sys/boot/arc/lib/../../../../lib/libstand -DDEBUG -I/usr/src/sys/boot/arc/lib/../../common -mno-fp-regs -I/usr/src/sys/boot/arc/lib/../../.. -I/usr/src/sys/boot/arc/lib/../include -I/usr/obj/usr/src/alpha/usr/include -c /usr/src/sys/boot/arc/lib/arcdisk.c -o arcdisk.o /usr/src/sys/boot/arc/lib/arcdisk.c:83: warning: initialization from incompatible pointer type /usr/src/sys/boot/arc/lib/arcdisk.c:84: warning: initialization from incompatible pointer type /usr/src/sys/boot/arc/lib/arcdisk.c: In function `bd_strategy': /usr/src/sys/boot/arc/lib/arcdisk.c:324: warning: assignment from incompatible pointer type /usr/src/sys/boot/arc/lib/arcdisk.c:326: warning: passing arg 5 of `bcache_strategy' makes integer from pointer without a cast /usr/src/sys/boot/arc/lib/arcdisk.c:326: warning: passing arg 6 of `bcache_strategy' from incompatible pointer type /usr/src/sys/boot/arc/lib/arcdisk.c:326: too few arguments to function `bcache_strategy' *** Error code 1 Stop in /usr/src/sys/boot/arc/lib. *** Error code 1 Is this just me, or have more people seen it? -- | / o / / _ Arnhem, The Netherlands email: wilko@freebsd.org |/|/ / / /( (_) Bulte http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 23:13:38 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 23:13:35 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4FE3837B699 for ; Thu, 4 Jan 2001 23:13:29 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id XAA00624; Thu, 4 Jan 2001 23:13:23 -0800 Date: Thu, 4 Jan 2001 23:13:22 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Wilko Bulte Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: buildworld failure In-Reply-To: <20010105080652.A71449@freebie.demon.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Yes, I've seend this too.... but in the middle of trying to track it down I had an actuator failure and lost my entire cvsup disk... What's wierd is none of this has been MFC'd recently- so one has to ask "how did 4.2 get built?" On Fri, 5 Jan 2001, Wilko Bulte wrote: > When trying to buildworld -stable on alpha: > > cc -I/usr/src/sys/boot/arc/lib/../../../../lib/libstand -DDEBUG > -I/usr/src/sys/boot/arc/lib/../../common -mno-fp-regs > -I/usr/src/sys/boot/arc/lib/../../.. -I/usr/src/sys/boot/arc/lib/../include > -I/usr/obj/usr/src/alpha/usr/include -c /usr/src/sys/boot/arc/lib/arcdisk.c > -o arcdisk.o > /usr/src/sys/boot/arc/lib/arcdisk.c:83: warning: initialization from > incompatible pointer type > /usr/src/sys/boot/arc/lib/arcdisk.c:84: warning: initialization from > incompatible pointer type > /usr/src/sys/boot/arc/lib/arcdisk.c: In function `bd_strategy': > /usr/src/sys/boot/arc/lib/arcdisk.c:324: warning: assignment from > incompatible pointer type > /usr/src/sys/boot/arc/lib/arcdisk.c:326: warning: passing arg 5 of > `bcache_strategy' makes integer from pointer without a cast > /usr/src/sys/boot/arc/lib/arcdisk.c:326: warning: passing arg 6 of > `bcache_strategy' from incompatible pointer type > /usr/src/sys/boot/arc/lib/arcdisk.c:326: too few arguments to function > `bcache_strategy' > *** Error code 1 > > Stop in /usr/src/sys/boot/arc/lib. > *** Error code 1 > > Is this just me, or have more people seen it? > > -- > > | / o / / _ Arnhem, The Netherlands email: wilko@freebsd.org > |/|/ / / /( (_) Bulte http://www.freebsd.org http://www.nlfug.nl > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 4 23:45:54 2001 From owner-freebsd-alpha@FreeBSD.ORG Thu Jan 4 23:45:52 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id AB2D037B402 for ; Thu, 4 Jan 2001 23:45:52 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f057jem73004; Thu, 4 Jan 2001 23:45:40 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.0) id f057jYh66379; Thu, 4 Jan 2001 23:45:34 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010105080652.A71449@freebie.demon.nl> Date: Thu, 04 Jan 2001 23:45:34 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Wilko Bulte Subject: RE: buildworld failure Cc: freebsd-alpha@FreeBSD.ORG Sender: jhb@foo.osd.bsdi.com Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 05-Jan-01 Wilko Bulte wrote: > When trying to buildworld -stable on alpha: Paul Saab just MFC'd all my loader warnign cleanups, and apparently he missed some of it. I'll try and look at this later, but good candidates to look for are for any differences between -current and -stable in src/sys/boot or src/lib/libstand. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jan 5 12:14:24 2001 From owner-freebsd-alpha@FreeBSD.ORG Fri Jan 5 12:14:21 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by hub.freebsd.org (Postfix) with ESMTP id A358937B400 for ; Fri, 5 Jan 2001 12:14:20 -0800 (PST) Received: from nas1-197.mea.club-internet.fr (nas1-197.mea.club-internet.fr [195.36.139.197]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA18326; Fri, 5 Jan 2001 21:14:09 +0100 (MET) Date: Fri, 5 Jan 2001 20:13:44 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Matthew Jacob Cc: Yoriaki FUJIMORI , freebsd-alpha@FreeBSD.ORG Subject: Re: bus_dmamap_load In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 4 Jan 2001, Matthew Jacob wrote: > On Thu, 4 Jan 2001, [ISO-8859-1] G=E9rard Roudier wrote: >=20 > >=20 > >=20 > > On Thu, 4 Jan 2001, Matthew Jacob wrote: > >=20 > > > The trick now is to figure out who is passing a bogus value > > > to bus_dmamap_load. The value of buf_len (0xfaae8000) looks > > > suspicious. > > >=20 > > > Since I hve essentially the same h/w (except for the symbios card) in= a PC164 > > > that runs 4.2 just fine, I would suspect the sym driver. But needs to= happen > > > is some better debugging for this. I take it that you aren't really r= unning on > > > this h/w yet (i.e, you haven't been able to install)? > >=20 > > Btw, you missed the `de' driver that also performs bus_dmamap_load() on > > mbuf's as a possible candidate. >=20 > That's why I said 'possibly'.... And because pretty much the sole differe= nce > between his PC164 and mine is the Symbios card..... Hmmm... May-be `sym' (or the Symbios card) is related to the problem, but suspecting it in a few seconds looked to me as relevant as suspecting the moon to be the cause of night.;-) There are probably much other differences between the _actual_ hardware config + software config + use pattern of the 2 systems. > > Would be interesting to shut the `de' board and to give a try with a > > different network board long enough to see if it makes difference. >=20 >=20 > No, no, no, since he's actually running with this, the smart thing to do = is to > put a panic to DDB to get a traceback, i.e.: >=20 > options DDB >=20 > and change the printf in alpha/busdma_machdep.c to a panic. Ok. This will give some infos. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jan 5 12:20: 2 2001 From owner-freebsd-alpha@FreeBSD.ORG Fri Jan 5 12:19:59 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by hub.freebsd.org (Postfix) with ESMTP id 1578B37B400 for ; Fri, 5 Jan 2001 12:19:59 -0800 (PST) Received: from fwd02.sul.t-online.com by mailout02.sul.t-online.com with smtp id 14EdLB-0001nQ-00; Fri, 05 Jan 2001 21:19:57 +0100 Received: from neutron.cichlids.com (520050424122-0001@[62.225.194.247]) by fmrl02.sul.t-online.com with esmtp id 14EdL2-0lAR84C; Fri, 5 Jan 2001 21:19:48 +0100 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 798EDAB0C; Fri, 5 Jan 2001 21:20:38 +0100 (CET) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id BE9B714B9F; Fri, 5 Jan 2001 21:19:47 +0100 (CET) Date: Fri, 5 Jan 2001 21:19:47 +0100 To: Ralph Schreyer Cc: wkb@freebie.demon.nl, alpha@FreeBSD.ORG Subject: Re: 2.88M floppy Message-ID: <20010105211947.A48681@cichlids.cichlids.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from schreyer@th.physik.uni-bonn.de on Thu, Jan 04, 2001 at 12:19:35PM +0100 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. From: alex@big.endian.de (Alexander Langer) X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Also sprach Ralph Schreyer (schreyer@th.physik.uni-bonn.de): > OK, of course we used kern.flp and mfsroot.flp, but in the cases we > needed e.g. the fixit.flp (2.88M, too) we had to mount it via NFS. So it > would just be nice to have these 2.88M floppies to work with. (And > secondly, since they are provided, there should be some way to use them) There _are_ 2.88 MB floppy drives. However, you can still burn the floppy on a CD-R(W) and boot from this. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jan 5 17:43:25 2001 From owner-freebsd-alpha@FreeBSD.ORG Fri Jan 5 17:43:24 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from madeline.boneyard.lawrence.ks.us (madeline.boneyard.lawrence.ks.us [24.124.26.25]) by hub.freebsd.org (Postfix) with ESMTP id 3780037B400 for ; Fri, 5 Jan 2001 17:43:22 -0800 (PST) Received: from madeline.boneyard.lawrence.ks.us (madeline.boneyard.lawrence.ks.us [24.124.26.25]) by madeline.boneyard.lawrence.ks.us (8.11.0/8.11.0) with ESMTP id f061f3Z28681; Fri, 5 Jan 2001 19:41:03 -0600 (CST) (envelope-from bsd-alpha@boneyard.lawrence.ks.us) Date: Fri, 5 Jan 2001 19:41:03 -0600 (CST) From: "Stephen D. Spencer" To: Wilko Bulte Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: buildworld failure In-Reply-To: <20010105080652.A71449@freebie.demon.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 5 Jan 2001, Wilko Bulte wrote: > When trying to buildworld -stable on alpha: > [...] > `bcache_strategy' from incompatible pointer type > /usr/src/sys/boot/arc/lib/arcdisk.c:326: too few arguments to function > `bcache_strategy' > *** Error code 1 > I spent a little time on this last week when getting ready to upgrade a couple servers. If you edit the Makefile and comment out: .if ${MACHINE_ARCH} == "alpha" SUBDIR+= arc .endif Won't hurt unless you need a new ARC bootloader and it will let your source tree build happily :) Regards, Stephen -- Stephen Spencer UNIX Systems Administrator Electrical Engineering and Computer Science Dept. University of Kansas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Jan 6 12: 3:22 2001 From owner-freebsd-alpha@FreeBSD.ORG Sat Jan 6 12:03:20 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 312D337B400 for ; Sat, 6 Jan 2001 12:03:20 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f06K3I719106; Sat, 6 Jan 2001 15:03:18 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 6 Jan 2001 15:03:18 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Todd Cohen Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: coda support?? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: robert@fledge.watson.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 4 Jan 2001, Todd Cohen wrote: > I'm thinking about trying out CODA and was wondering if the options for > it in the LINT file for the i386 platform are valid for the alpha > platform. Why is there no lint file for the alpha? At some point in the past, the Coda userland source tree was not 64-bit clean -- I'm not sure about the kernel module. I believe this was fixed as part of the Sparc support work, but I'm not entirely clear on that point. The MAINTAINER of the Coda source on FreeBSD is shafeeq@FreeBSD.org, and it might be worth e-mailing him to ask about the support status of Coda on FreeBSD on AXP boxes. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Jan 6 12:43: 6 2001 From owner-freebsd-alpha@FreeBSD.ORG Sat Jan 6 12:43:03 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id 6598E37B400; Sat, 6 Jan 2001 12:43:01 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #2) id 14F0B2-000517-00; Sat, 06 Jan 2001 20:43:00 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.1) id f06Khwl78005; Sat, 6 Jan 2001 21:43:58 +0100 (CET) (envelope-from wkb) Date: Sat, 6 Jan 2001 21:43:57 +0100 From: Wilko Bulte To: FreeBSD-alpha mailing list , peter@freebsd.org Subject: debugging fpa / FDDI panic Message-ID: <20010106214357.X77275@freebie.demon.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i X-OS: FreeBSD 4.2-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Now that I have -current running on my Miata I'm trying to find out why the fpa driver causes a panic on boot: isp0: interrupting at CIA irq 16 pci1: at 10.0 (no driver attached) fpa0: port 0x9000-0x907f mem 0x80950000-0x8095ffff,0x80960000-0x8096007f irq 4 at device 11.0 on pci0 fatal kernel trap: trap entry = 0x2 (memory management fault) a0 = 0x80960014 a1 = 0x1 a2 = 0x0 pc = 0xfffffc0000390698 ra = 0xfffffc00003903d8 curproc = 0xfffffc00006110a8 pid = 0, comm = swapper Stopped at pdq_initialize+0x538: ldl t0,0(t0) <0x80960014> db> trace pdq_initialize() at pdq_initialize+0x538 pdq_pci_attach() at pdq_pci_attach+0x1f8 device_probe_and_attach() at device_probe_and_attach+0xcc bus_generic_attach() at bus_generic_attach+0x28 device_probe_and_attach() at device_probe_and_attach+0xcc bus_generic_attach() at bus_generic_attach+0x28 device_probe_and_attach() at device_probe_and_attach+0xcc bus_generic_attach() at bus_generic_attach+0x28 cia_attach() at cia_attach+0x1f0 device_probe_and_attach() at device_probe_and_attach+0xcc root_bus_configure() at root_bus_configure+0x38 configure() at configure+0x40 mi_startup() at mi_startup+0xf4 locorestart() at locorestart+0x6c I'd like to cause a dump, but 'panic' does not want to do that for me. I'm not much of a DDB guru, and appreciate a helping hand here. Tnx -- | / o / / _ Arnhem, The Netherlands email: wilko@freebsd.org |/|/ / / /( (_) Bulte http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Jan 6 13: 4:33 2001 From owner-freebsd-alpha@FreeBSD.ORG Sat Jan 6 13:04:31 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 3FBE137B400 for ; Sat, 6 Jan 2001 13:04:31 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id QAA13097; Sat, 6 Jan 2001 16:04:30 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f06L4U474937; Sat, 6 Jan 2001 16:04:30 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 6 Jan 2001 16:04:30 -0500 (EST) To: Wilko Bulte Cc: freebsd-alpha@freebsd.org Subject: Re: debugging fpa / FDDI panic In-Reply-To: <20010106214357.X77275@freebie.demon.nl> References: <20010106214357.X77275@freebie.demon.nl> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14935.34600.806565.787237@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte writes: > Now that I have -current running on my Miata I'm trying to find out why the > fpa driver causes a panic on boot: > > isp0: interrupting at CIA irq 16 > pci1: at 10.0 (no driver attached) > fpa0: port 0x9000-0x907f mem > 0x80950000-0x8095ffff,0x80960000-0x8096007f irq 4 at device 11.0 on pci0 > > fatal kernel trap: > > trap entry = 0x2 (memory management fault) > a0 = 0x80960014 This is a bus address, not a virtual address. Change the bus_alloc_resource call in pdq_pci_attach() to memres = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, 0, ~0, 1, RF_ACTIVE|PCI_RF_DENSE); We should either have pci_alloc_resource default to RF_DENSE or panic if neither PCI_RF_DENSE nor PCI_RF_BWX are specified. The current state of affairs makes no sense.. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Jan 6 13:44:54 2001 From owner-freebsd-alpha@FreeBSD.ORG Sat Jan 6 13:44:50 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 12C1737B400 for ; Sat, 6 Jan 2001 13:44:50 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #4) id 14F18m-000NfS-00; Sat, 06 Jan 2001 21:44:44 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.1) id f06Ljg978615; Sat, 6 Jan 2001 22:45:42 +0100 (CET) (envelope-from wkb) Date: Sat, 6 Jan 2001 22:45:42 +0100 From: Wilko Bulte To: Andrew Gallatin Cc: freebsd-alpha@freebsd.org Subject: Re: debugging fpa / FDDI panic Message-ID: <20010106224542.A78582@freebie.demon.nl> References: <20010106214357.X77275@freebie.demon.nl> <14935.34600.806565.787237@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14935.34600.806565.787237@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Sat, Jan 06, 2001 at 04:04:30PM -0500 X-OS: FreeBSD 4.2-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jan 06, 2001 at 04:04:30PM -0500, Andrew Gallatin wrote: > > Wilko Bulte writes: > > Now that I have -current running on my Miata I'm trying to find out why the > > fpa driver causes a panic on boot: > > > > isp0: interrupting at CIA irq 16 > > pci1: at 10.0 (no driver attached) > > fpa0: port 0x9000-0x907f mem > > 0x80950000-0x8095ffff,0x80960000-0x8096007f irq 4 at device 11.0 on pci0 > > > > fatal kernel trap: > > > > trap entry = 0x2 (memory management fault) > > a0 = 0x80960014 > > This is a bus address, not a virtual address. > > Change the bus_alloc_resource call in pdq_pci_attach() to > > memres = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, 0, ~0, 1, > RF_ACTIVE|PCI_RF_DENSE); > > We should either have pci_alloc_resource default to RF_DENSE or panic > if neither PCI_RF_DENSE nor PCI_RF_BWX are specified. The current > state of affairs makes no sense.. Drew, after changing it I still get: fpa0: port 0x9000-0x907f mem 0x80950000-0x80 95ffff,0x80960000-0x8096007f irq 4 at device 11.0 on pci0 fatal kernel trap: trap entry = 0x2 (memory management fault) a0 = 0x14 a1 = 0x1 a2 = 0x0 pc = 0xfffffc0000390698 ra = 0xfffffc00003903d8 curproc = 0xfffffc00006110a8 pid = 0, comm = swapper Stopped at pdq_initialize+0x538: ldl t0,0(t0) <0x14> db> trace pdq_initialize() at pdq_initialize+0x538 pdq_pci_attach() at pdq_pci_attach+0x1fc device_probe_and_attach() at device_probe_and_attach+0xcc bus_generic_attach() at bus_generic_attach+0x28 device_probe_and_attach() at device_probe_and_attach+0xcc bus_generic_attach() at bus_generic_attach+0x28 device_probe_and_attach() at device_probe_and_attach+0xcc bus_generic_attach() at bus_generic_attach+0x28 cia_attach() at cia_attach+0x1f0 device_probe_and_attach() at device_probe_and_attach+0xcc root_bus_configure() at root_bus_configure+0x38 configure() at configure+0x40 mi_startup() at mi_startup+0xf4 locorestart() at locorestart+0x6c db> The code is now: rid = PCI_CBMA; /* memres = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, 0, ~0, 1, RF_ACTIVE); */ memres = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, 0, ~0, 1, RF_ACTIVE|PCI_RF_DENSE); if (!memres) goto bad; sc->sc_if.if_name = "fpa"; Did I miss something? -- | / o / / _ Arnhem, The Netherlands email: wilko@freebsd.org |/|/ / / /( (_) Bulte http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Jan 6 14: 4:27 2001 From owner-freebsd-alpha@FreeBSD.ORG Sat Jan 6 14:04:26 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id C7D7437B400 for ; Sat, 6 Jan 2001 14:04:25 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id RAA13581; Sat, 6 Jan 2001 17:04:25 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f06M4PF75018; Sat, 6 Jan 2001 17:04:25 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 6 Jan 2001 17:04:24 -0500 (EST) To: Wilko Bulte Cc: freebsd-alpha@freebsd.org Subject: Re: debugging fpa / FDDI panic In-Reply-To: <20010106224542.A78582@freebie.demon.nl> References: <20010106214357.X77275@freebie.demon.nl> <14935.34600.806565.787237@grasshopper.cs.duke.edu> <20010106224542.A78582@freebie.demon.nl> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14935.37795.408651.78296@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte writes: > a0 = 0x14 > a1 = 0x1 > a2 = 0x0 > pc = 0xfffffc0000390698 > ra = 0xfffffc00003903d8 > curproc = 0xfffffc00006110a8 > pid = 0, comm = swapper > > Stopped at pdq_initialize+0x538: ldl t0,0(t0) <0x14> > db> trace > pdq_initialize() at pdq_initialize+0x538 Can you run gdb on kernel.debug and say "list *pdq_initialize+0x538" Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Jan 6 14:30:45 2001 From owner-freebsd-alpha@FreeBSD.ORG Sat Jan 6 14:30:42 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id A13F537B402 for ; Sat, 6 Jan 2001 14:30:42 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f06MVCq68942; Sat, 6 Jan 2001 14:31:12 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101062231.f06MVCq68942@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andrew Gallatin Cc: Wilko Bulte , freebsd-alpha@FreeBSD.ORG Subject: Re: debugging fpa / FDDI panic In-Reply-To: <14935.34600.806565.787237@grasshopper.cs.duke.edu> Date: Sat, 06 Jan 2001 14:31:12 -0800 From: Peter Wemm Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andrew Gallatin wrote: > > Wilko Bulte writes: > > Now that I have -current running on my Miata I'm trying to find out why th e > > fpa driver causes a panic on boot: > > > > isp0: interrupting at CIA irq 16 > > pci1: at 10.0 (no driver attached) > > fpa0: port 0x9000-0x907f mem > > 0x80950000-0x8095ffff,0x80960000-0x8096007f irq 4 at device 11.0 on pci0 > > > > fatal kernel trap: > > > > trap entry = 0x2 (memory management fault) > > a0 = 0x80960014 > > This is a bus address, not a virtual address. > > Change the bus_alloc_resource call in pdq_pci_attach() to > > memres = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, 0, ~0, 1, > RF_ACTIVE|PCI_RF_DENSE); > > We should either have pci_alloc_resource default to RF_DENSE or panic > if neither PCI_RF_DENSE nor PCI_RF_BWX are specified. The current > state of affairs makes no sense.. Actually, what I think we should be doing is the same as how the interrupt resources are handled... ie: seperate allocation and activation. ie: res = bus_alloc_resource(dev, SYS_RES_IRQ, ....) bus_setup_intr(dev, res, flags, irqhandler, handlerargs, &irqhandle); IMHO, we should do the same with memory and IO space. we presently have: res = bus_alloc_resource(dev, SYS_RES_MEMORY, ...., RF_ACTIVE|magic_flags); va = rman_get_virtual(res); IMHO, this is wrong. We are allocating space within the scope of the bus and expecting it to silently appear in CPU addressable space and then use backdoor methods to grab it. I think it would be better like this: res = bus_alloc_resource(dev, SYS_RES_MEMORY, .... RF_ACTIVE) bus_map_space(dev, res, magicflags, &bushandle, &bustag, &mappinghandle); or something along those lines. The allocation would be to reserve the space in the bus, and the bus_map_space() would be to arrange for it to appear into CPU addressable space, get the handles, choose convenient mapping modes (dense or sparse - this is a CPU/core chipset *mapping* property, not a "pci bus resource" property). The pci space on the alphas appears in several forms in the CPU space. Things like rman_get_virtual(), rman_get_bushandle(), rman_get_bustag() etc are abominations and layering violations IMHO. NetBSD did not make this mistake - they had seperate bus level allocation and cpu level mapping calls pretty much right from the start. (This was particularly important for things like the Amiga bridge cards where there was an ISA bus on the far side of a seperate PC emulator bridge card and mapping the ISA bus was not as simple as finding the physical address "appeared" in CPU space) The fact that we have to do pmap_mapdev(), pmap_unmapdev() etc in the i386 code *regardless* of whether virtual access is even required is a bad sign. Suppose we wanted to just get handles for busdma? We are wasting KVM in that scenario. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Jan 6 14:41:51 2001 From owner-freebsd-alpha@FreeBSD.ORG Sat Jan 6 14:41:48 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 0023C37B400 for ; Sat, 6 Jan 2001 14:41:47 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #4) id 14F21y-000OMS-00; Sat, 06 Jan 2001 22:41:46 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.1) id f06Mgim78880; Sat, 6 Jan 2001 23:42:44 +0100 (CET) (envelope-from wkb) Date: Sat, 6 Jan 2001 23:42:44 +0100 From: Wilko Bulte To: Andrew Gallatin Cc: freebsd-alpha@freebsd.org Subject: Re: debugging fpa / FDDI panic Message-ID: <20010106234244.A78789@freebie.demon.nl> References: <20010106214357.X77275@freebie.demon.nl> <14935.34600.806565.787237@grasshopper.cs.duke.edu> <20010106224542.A78582@freebie.demon.nl> <14935.37795.408651.78296@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14935.37795.408651.78296@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Sat, Jan 06, 2001 at 05:04:24PM -0500 X-OS: FreeBSD 4.2-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jan 06, 2001 at 05:04:24PM -0500, Andrew Gallatin wrote: > > Wilko Bulte writes: > > a0 = 0x14 > > a1 = 0x1 > > a2 = 0x0 > > pc = 0xfffffc0000390698 > > ra = 0xfffffc00003903d8 > > curproc = 0xfffffc00006110a8 > > pid = 0, comm = swapper > > > > Stopped at pdq_initialize+0x538: ldl t0,0(t0) <0x14> > > db> trace > > pdq_initialize() at pdq_initialize+0x538 > > Can you run gdb on kernel.debug and say "list *pdq_initialize+0x538" Like: mx5#gdb -k kernel.debug GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "alpha-unknown-freebsd"... (kgdb) list *pdq_initialize+0x538 0xfffffc0000390698 is in pdq_initialize (../../dev/pdq/pdq.c:1546). 1541 pdq->pdq_tx_info.tx_free = PDQ_RING_MASK(pdq->pdq_dbp->pdqdb_transmits); 1542 pdq->pdq_tx_info.tx_hdrdesc.txd_seg_len = sizeof(pdq->pdq_tx_hdr); 1543 pdq->pdq_tx_info.tx_hdrdesc.txd_sop = 1; 1544 pdq->pdq_tx_info.tx_hdrdesc.txd_pa_lo = PDQ_OS_VA_TO_PA(pdq, pdq->pdq_tx_hdr); 1545 1546 state = PDQ_PSTS_ADAPTER_STATE(PDQ_CSR_READ(&pdq->pdq_csrs, csr_port_status)); 1547 PDQ_PRINTF(("PDQ Adapter State = %s\n", pdq_adapter_states[state])); 1548 1549 /* 1550 * Stop the PDQ if it is running and put it into a known state. (kgdb) -- | / o / / _ Arnhem, The Netherlands email: wilko@freebsd.org |/|/ / / /( (_) Bulte http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Jan 6 15:25:50 2001 From owner-freebsd-alpha@FreeBSD.ORG Sat Jan 6 15:25:47 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id B93D137B400 for ; Sat, 6 Jan 2001 15:25:46 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id SAA14161; Sat, 6 Jan 2001 18:25:46 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f06NPjq87874; Sat, 6 Jan 2001 18:25:46 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 6 Jan 2001 18:25:45 -0500 (EST) To: Wilko Bulte Cc: freebsd-alpha@freebsd.org Subject: Re: debugging fpa / FDDI panic In-Reply-To: <20010106234244.A78789@freebie.demon.nl> References: <20010106214357.X77275@freebie.demon.nl> <14935.34600.806565.787237@grasshopper.cs.duke.edu> <20010106224542.A78582@freebie.demon.nl> <14935.37795.408651.78296@grasshopper.cs.duke.edu> <20010106234244.A78789@freebie.demon.nl> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14935.42278.147202.426911@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Yes. that's what I meant. Sorry for the delay. The maze of #ifdefs in the driver is making me dizzy.. I wonder if there's an unifdef that's smart enough to deal with #if defined().. Anyway, try changing the typdef of the pdq_bus_memaddr_t from typedef volatile pdq_uint32_t *pdq_bus_memaddr_t; to typedef volatile vm_offset_t *pdq_bus_memaddr_t; in the FreeBSD section of ifdefs. Also, printf (with %lx) the value of sc->sc_membase prior to calling pdq_initialize(). If this works, we're still going to need a DMA hack. It will be something like this: #if defined(__FreeBSD__) && defined(__alpha__) #define PDQ_OS_VA_TO_PA(pdq, p) (vtophys((vm_offset_t)p) | (pdq->pdq_type == PDQ_DEFTA ? 0 : alpha_XXX_dmamap_or)) #endif Ick.. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message