From bugmaster at FreeBSD.org Mon Sep 1 11:07:00 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 1 11:08:37 2008 Subject: Current problem reports assigned to freebsd-ppc@FreeBSD.org Message-ID: <200809011107.m81B70IQ068527@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o power/93203 ppc FreeBSD PPC Can't Write to Partitions. a power/121407 ppc [panic] Won't boot up; strange error message. 2 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o power/111296 ppc [kernel] [patch] [request] Support IMISS, DLMISS an DS o power/112435 ppc [nexus] [patch] Update nexus children to use ofw_bus f 2 problems total. From richard.delaurell at gmail.com Mon Sep 1 17:22:51 2008 From: richard.delaurell at gmail.com (Richard DeLaurell) Date: Mon Sep 1 17:22:57 2008 Subject: freebsd ppc 7 release w/ ural driver? Message-ID: <4324dbec0809011022m20009fd7q20ef2fb9962e72fb@mail.gmail.com> Does the ural driver work with fbsd ppc 7? I have installed 7 release on an imac 333 rev D (ofw 3) and my only option for networking is a wifi usb dongle; I have a belkin wireless G network adapter (F5D7050B) to use for that purpose. Is the ural driver the way to make this adapter work? Thanks for any help-- Richard DeLaurell From nwhitehorn at freebsd.org Mon Sep 1 17:59:52 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Mon Sep 1 17:59:59 2008 Subject: freebsd ppc 7 release w/ ural driver? In-Reply-To: <4324dbec0809011022m20009fd7q20ef2fb9962e72fb@mail.gmail.com> References: <4324dbec0809011022m20009fd7q20ef2fb9962e72fb@mail.gmail.com> Message-ID: <48BC281C.5040008@freebsd.org> Richard DeLaurell wrote: > Does the ural driver work with fbsd ppc 7? > > I have installed 7 release on an imac 333 rev D (ofw 3) and my only option > for networking is a wifi usb dongle; I have a belkin wireless G network > adapter (F5D7050B) to use for that purpose. > > Is the ural driver the way to make this adapter work? > I think you want the rum driver instead, which should work fine. FreeBSD 7.1, which should enter beta shortly, and 7-STABLE, which you can get by csup, also have support for the built-in ethernet on this machine. -Nathan From richard.delaurell at gmail.com Tue Sep 2 21:08:16 2008 From: richard.delaurell at gmail.com (Richard DeLaurell) Date: Tue Sep 2 21:08:22 2008 Subject: freebsd ppc 7 release w/ ural driver? In-Reply-To: <48BC281C.5040008@freebsd.org> References: <4324dbec0809011022m20009fd7q20ef2fb9962e72fb@mail.gmail.com> <48BC281C.5040008@freebsd.org> Message-ID: <4324dbec0809021408o69bc93fcr98635b50faa0b48b@mail.gmail.com> Thanks Nathan. You were correct, the rum driver does work with the adapter. Works very well in fact. I can ping and ftp, but I have no browser yet; lynx/links/and w3m all refuse to compile, and there seems to be no xorg for fbsd-ppc (yet?). Any suggestions on how to either get a text-browser working, and/or tweak the compiler for ppc/imacG3 are welcome. Richard DeLaurell On Mon, Sep 1, 2008 at 12:36 PM, Nathan Whitehorn wrote: > Richard DeLaurell wrote: > >> Does the ural driver work with fbsd ppc 7? >> >> I have installed 7 release on an imac 333 rev D (ofw 3) and my only option >> for networking is a wifi usb dongle; I have a belkin wireless G network >> adapter (F5D7050B) to use for that purpose. >> >> Is the ural driver the way to make this adapter work? >> >> > I think you want the rum driver instead, which should work fine. > > FreeBSD 7.1, which should enter beta shortly, and 7-STABLE, which you can > get by csup, also have support for the built-in ethernet on this machine. > -Nathan > From tinderbox at freebsd.org Thu Sep 4 14:12:21 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Sep 4 14:12:33 2008 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20080904141217.929A673039@freebsd-current.sentex.ca> TB --- 2008-09-04 12:56:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-04 12:56:35 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-09-04 12:56:35 - cleaning the object tree TB --- 2008-09-04 12:57:00 - cvsupping the source tree TB --- 2008-09-04 12:57:00 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-09-04 12:57:07 - building world (CFLAGS=-O -pipe) TB --- 2008-09-04 12:57:07 - cd /src TB --- 2008-09-04 12:57:07 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 4 12:57:09 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Sep 4 14:05:34 UTC 2008 TB --- 2008-09-04 14:05:35 - generating LINT kernel config TB --- 2008-09-04 14:05:35 - cd /src/sys/powerpc/conf TB --- 2008-09-04 14:05:35 - /usr/bin/make -B LINT TB --- 2008-09-04 14:05:35 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-04 14:05:35 - cd /src TB --- 2008-09-04 14:05:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 4 14:05:35 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/security/audit/audit_syscalls.c:403: error: expected identifier or '(' before 'break' /src/sys/security/audit/audit_syscalls.c:405: error: expected identifier or '(' before 'case' /src/sys/security/audit/audit_syscalls.c:409: error: expected identifier or '(' before 'return' /src/sys/security/audit/audit_syscalls.c:411: error: expected identifier or '(' before 'default' /src/sys/security/audit/audit_syscalls.c:413: error: expected identifier or '(' before '}' token /src/sys/security/audit/audit_syscalls.c:418: error: expected identifier or '(' before 'switch' /src/sys/security/audit/audit_syscalls.c:437: error: expected identifier or '(' before 'return' /src/sys/security/audit/audit_syscalls.c:438: error: expected identifier or '(' before '}' token *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-04 14:12:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-04 14:12:17 - ERROR: failed to build lint kernel TB --- 2008-09-04 14:12:17 - tinderbox aborted TB --- 3388.59 user 399.48 system 4541.91 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From bugmaster at FreeBSD.org Mon Sep 8 02:22:25 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 8 02:23:53 2008 Subject: Current problem reports assigned to freebsd-ppc@FreeBSD.org Message-ID: <200809080222.m882MPwY006773@freefall.freebsd.org> The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- a power/121407 ppc [panic] Won't boot up; strange error message. o power/112435 ppc [nexus] [patch] Update nexus children to use ofw_bus f o power/111296 ppc [kernel] [patch] [request] Support IMISS, DLMISS an DS o power/93203 ppc FreeBSD PPC Can't Write to Partitions. 4 problems total. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. From nwhitehorn at freebsd.org Tue Sep 9 16:34:34 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Tue Sep 9 16:34:41 2008 Subject: Call for testers: Apple ATA DMA Message-ID: <48C69864.3010208@freebsd.org> I just finished a patch to the Apple built-in ATA drivers (ata_macio and ata_kauai) that adds DMA support. Due to lack of Kauai hardware (G4 machines), it has had only minimal testing, so I'd appreciate some more. WARNING: THIS MAY DO HORRIBLE THINGS LIKE ERASE YOUR HARD DRIVE The patch can be found here: http://people.freebsd.org/~nwhitehorn/apple-ata-dma.patch DMA modes on Kauai are currently slower than they should be because of an interrupt handling problem. DBDMA completion interrupts arrive on a different interrupt vector than the regular ATA interrupts, so we need to bind to the second vector as well. However, attaching a PCI device to more than one IRQ makes the PCI bus driver think the second interrupt is an MSI. Since it isn't, the PCI bus module then helpfully panics. This should be fixed somehow. -Nathan From nwhitehorn at freebsd.org Tue Sep 9 18:08:23 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Tue Sep 9 18:08:29 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: References: <48C69864.3010208@freebsd.org> Message-ID: <48C6B5A5.8070509@freebsd.org> Marcel Moolenaar wrote: > > On Sep 9, 2008, at 8:38 AM, Nathan Whitehorn wrote: > >> I just finished a patch to the Apple built-in ATA drivers (ata_macio >> and ata_kauai) that adds DMA support. > > Sweet! I'll give it a spin... > Thanks! If you downloaded the patch earlier (before 18:42 UTC), you should grab it again -- I missed two files. -Nathan From xcllnt at mac.com Tue Sep 9 18:29:50 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Sep 9 18:29:56 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48C69864.3010208@freebsd.org> References: <48C69864.3010208@freebsd.org> Message-ID: On Sep 9, 2008, at 8:38 AM, Nathan Whitehorn wrote: > I just finished a patch to the Apple built-in ATA drivers (ata_macio > and ata_kauai) that adds DMA support. Sweet! I'll give it a spin... -- Marcel Moolenaar xcllnt@mac.com From marcotrillo at gmail.com Wed Sep 10 10:49:04 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Wed Sep 10 10:49:11 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48C69864.3010208@freebsd.org> References: <48C69864.3010208@freebsd.org> Message-ID: Hello, On Tue, Sep 9, 2008 at 5:38 PM, Nathan Whitehorn wrote: > I just finished a patch to the Apple built-in ATA drivers (ata_macio and > ata_kauai) that adds DMA support. Due to lack of Kauai hardware (G4 > machines), it has had only minimal testing, so I'd appreciate some more. > > The patch can be found here: > http://people.freebsd.org/~nwhitehorn/apple-ata-dma.patch Regarding the Kauai mode setting: > +static const u_int udma_timing_kauai[] = { /* 0x0000ffff */ > + 0x000070c0, /* UDMA0 */ > + 0x00005d80, /* UDMA1 */ > + 0x00004a60, /* UDMA2 */ > + 0x00003a50, /* UDMA3 */ > + 0x00002a30, /* UDMA4 */ > + 0x00002921 /* UDMA5 */ > +}; > + > static void > ata_kauai_setmode(device_t parent, device_t dev) > { > struct ata_device *atadev = device_get_softc(dev); > + struct ata_kauai_softc *sc = device_get_softc(parent); > + uint32_t dmaconf = 0; > + uint32_t mode; > > - /* TODO bang kauai speed register */ > - atadev->mode = ATA_PIO; > + mode = atadev->mode = ata_limit_mode(dev,atadev->mode,ATA_UDMA5); > + > + if ((mode & ATA_DMA_MASK) == ATA_UDMA0) { > + dmaconf = udma_timing_kauai[mode & ATA_MODE_MASK]; > + > + bus_write_4(sc->sc_memr, DMA_CONFIG_REG, dmaconf); > + } else if ((mode & ATA_DMA_MASK) == ATA_WDMA0) { > + dmaconf = dma_timing_kauai[mode & ATA_MODE_MASK]; > + > + bus_write_4(sc->sc_memr, DMA_CONFIG_REG, dmaconf); > + } else { > + dmaconf = pio_timing_kauai[(mode & ATA_MODE_MASK) - ATA_PIO0]; > + > + bus_write_4(sc->sc_memr, PIO_CONFIG_REG, dmaconf); > + } > } > + The "DMA_CONFIG_REG" register is actually only for UDMA timings, not for DMA+UDMA. DMA mode timings are ORed with PIO mode timings in the "PIO_CONFIG_REG" register; as indicated with the masks: 0x00fff000 for DMA and 0xff000fff for PIO. This can be verified by looking at Mac OS X's AppleKauaiATA.cpp driver, in lines 985 and 986 and others [1] . Note that the NetBSD driver also contains this error, and there is a patch for it on NetBSD PR 39176. OpenBSD driver doesn't have this problem. In addition, to enable UDMA, you need to OR 1 to the UDMA timing mode. So for example for UDMA2, you need to write 0x00004a61 and not simply 0x00004a60 . Hope that helps. Regards, Marco. From nwhitehorn at freebsd.org Wed Sep 10 16:18:04 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Wed Sep 10 16:18:10 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: References: <48C69864.3010208@freebsd.org> Message-ID: <48C7F336.6060003@freebsd.org> Marco Trillo wrote: > Hello, > > On Tue, Sep 9, 2008 at 5:38 PM, Nathan Whitehorn wrote: > >> I just finished a patch to the Apple built-in ATA drivers (ata_macio and >> ata_kauai) that adds DMA support. Due to lack of Kauai hardware (G4 >> machines), it has had only minimal testing, so I'd appreciate some more. >> >> The patch can be found here: >> http://people.freebsd.org/~nwhitehorn/apple-ata-dma.patch >> > > Regarding the Kauai mode setting: > > [snip] > > > The "DMA_CONFIG_REG" register is actually only for UDMA timings, not > for DMA+UDMA. DMA mode timings are ORed with PIO mode timings in the > "PIO_CONFIG_REG" register; as indicated with the masks: 0x00fff000 for > DMA and 0xff000fff for PIO. > > This can be verified by looking at Mac OS X's AppleKauaiATA.cpp > driver, in lines 985 and 986 and others [1] . > > Note that the NetBSD driver also contains this error, and there is a > patch for it on NetBSD PR 39176. OpenBSD driver doesn't have this > problem. > > In addition, to enable UDMA, you need to OR 1 to the UDMA timing mode. > So for example for UDMA2, you need to write 0x00004a61 and not simply > 0x00004a60 . > Thanks! I had just assumed that the NetBSD driver did the right thing, and only have a CD drive attached to a Shasta controller on which to test the Kauai driver. I'll change it to do things the right way. -Nathan From marcotrillo at gmail.com Wed Sep 10 17:03:53 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Wed Sep 10 17:04:00 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48C7F336.6060003@freebsd.org> References: <48C69864.3010208@freebsd.org> <48C7F336.6060003@freebsd.org> Message-ID: Hi, On Wed, Sep 10, 2008 at 6:17 PM, Nathan Whitehorn > Thanks! I had just assumed that the NetBSD driver did the right thing, and > only have a CD drive attached to a Shasta controller on which to test the > Kauai driver. I'll change it to do things the right way. Thank you for your work on this! If I'm not mistaken the Shasta does ATA/133 - UDMA6, while the Kauai only does ATA/100 - UDMA5. Mac OS X uses a different set of timing values for the Shasta controller than it uses for Kauai; these new timing values include the UDMA6 mode. The following are the timing values for the Shasta straight from the Mac OS X AppleKauaiATA.cpp driver available at [1]. static const u_int pio_timing_shasta[] = { 0x0A000C97, /* Mode 0 */ 0x07000712, /* 1 */ 0x040003CD, /* 2 */ 0x0400028B, /* 3 */ 0x0400010A /* 4 */ }; static const u_int dma_timing_shasta[] = { 0x00820800, /* Mode 0 */ 0x0028B000, /* 1 */ 0x001CA000 /* 2 */ }; static const u_int udma_timing_shasta[] = { 0x00035901, /* Mode 0 */ 0x000348b1, /* 1 */ 0x00033881, /* 2 */ 0x00033861, /* 3 */ 0x00033841, /* 4 */ 0x00033031, /* 5 */ 0x00033021 /* 6 */ }; Hope you find it useful! [1] http://www.opensource.apple.com/darwinsource/10.4.11.ppc/AppleKauaiATA-121.3.4/AppleKauaiATA.cpp Regards, Marco. From xcllnt at mac.com Wed Sep 10 20:52:28 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Sep 10 20:52:34 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48C7F336.6060003@freebsd.org> References: <48C69864.3010208@freebsd.org> <48C7F336.6060003@freebsd.org> Message-ID: <1C883A32-8D01-4775-B027-20DB1DF4B4D3@mac.com> On Sep 10, 2008, at 9:17 AM, Nathan Whitehorn wrote: [snip -- great explanation by Marco] >> In addition, to enable UDMA, you need to OR 1 to the UDMA timing >> mode. >> So for example for UDMA2, you need to write 0x00004a61 and not simply >> 0x00004a60 . >> > Thanks! I had just assumed that the NetBSD driver did the right > thing, and only have a CD drive attached to a Shasta controller on > which to test the Kauai driver. I'll change it to do things the > right way. Let me know when you have it. Your patch didn't work for me and caused a hard (enough) hang. It was right at the time ad0 is normally found (and configured): ... FreeBSD 8.0-CURRENT #5 r182738: Thu Sep 4 02:11:48 PDT 2008 marcelm@mini-g4:/usr/obj/nfs/freebsd/base/head/sys/MINI-G4 WARNING: WITNESS option enabled, expect reduced performance. cpu0: Motorola PowerPC 7447A revision 1.5, 1500.00 MHz cpu0: HID0 8450c0bc real memory = 1059041280 (1009 MB) avail memory = 1027227648 (979 MB) nexus0: ... pcib2: on nexus0 pci2: on pcib2 ata1: mem 0xf5004000-0xf5007fff irq 39 at device 13.0 on pci2 ata1: [ITHREAD] ... ad0: 76319MB at ata1-master BIOSPIO acd0: DVDR at ata1-slave BIOSPIO acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 GEOM_LABEL: Label for provider acd0 is iso9660/CDROM. WARNING: WITNESS option enabled, expect reduced performance. ... BTW: I noticed with the patched kernel that the IRQ changed to 1 (from 39). I guess this is related to the multiple IRQs for a PCI device problem (IRQ 1 being the DBDMA interrupt): Node 0xff9b6298: ata-6 vendor-id: 00 00 10 6b device-id: 00 00 00 3b revision-id: 00 00 00 00 class-code: 00 ff 00 00 min-grant: 00 00 00 00 max-latency: 00 00 00 00 devsel-speed: 00 00 00 01 name: 61 74 61 2d 36 00 'ata-6' model: 61 74 61 2d 36 00 'ata-6' device_type: 61 74 61 00 'ata' AAPL,connector: 61 74 61 00 'ata' AAPL,bus-id: 00 00 00 03 cable-type: 38 30 2d 63 6f 6e 64 75 63 74 6f 72 00 '80-conductor' #address-cells: 00 00 00 01 #size-cells: 00 00 00 00 AAPL,pio-timing: 00 00 05 26 00 00 00 85 00 00 00 25 00 00 00 25 00 00 00 25 00 00 00 00 00 00 00 00 00 00 00 00 lba-48: interrupts: 00 00 00 01 00 00 00 00 AAPL,requested-priorities: 00 00 00 02 00 00 00 04 compatible: 6b 61 75 61 69 2d 61 74 61 00 'kauai-ata' reg: 00 00 68 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 68 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 00 assigned-addresses: 82 00 68 10 00 00 00 00 f5 00 40 00 00 00 00 00 00 00 40 00 mini-g4% sudo atacontrol list ATA channel 0: Master: no device present Slave: no device present ATA channel 1: Master: ad0 ATA/ATAPI revision 6 Slave: acd0 ATA/ATAPI revision 6 mini-g4% sudo atacontrol mode ad0 current mode = BIOSPIO mini-g4% sudo atacontrol cap ad0 Protocol ATA/ATAPI revision 6 device model ST9808211A serial number 3LF2PW9F firmware revision 3.07 cylinders 16383 heads 16 sectors/track 63 lba supported 156301488 sectors lba48 not supported 156301488 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Tagged Command Queuing (TCQ) no no 0/0x00 SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes yes 32896/0x8080 automatic acoustic management no no 0/0x00 254/0xFE FYI, -- Marcel Moolenaar xcllnt@mac.com From nwhitehorn at freebsd.org Thu Sep 11 05:56:38 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Thu Sep 11 05:56:44 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <1C883A32-8D01-4775-B027-20DB1DF4B4D3@mac.com> References: <48C69864.3010208@freebsd.org> <48C7F336.6060003@freebsd.org> <1C883A32-8D01-4775-B027-20DB1DF4B4D3@mac.com> Message-ID: <48C8B400.7060604@freebsd.org> Marcel Moolenaar wrote: > > On Sep 10, 2008, at 9:17 AM, Nathan Whitehorn wrote: > > [snip -- great explanation by Marco] > >>> In addition, to enable UDMA, you need to OR 1 to the UDMA timing mode. >>> So for example for UDMA2, you need to write 0x00004a61 and not simply >>> 0x00004a60 . >>> >> Thanks! I had just assumed that the NetBSD driver did the right thing, >> and only have a CD drive attached to a Shasta controller on which to >> test the Kauai driver. I'll change it to do things the right way. > > Let me know when you have it. Your patch didn't work for me > and caused a hard (enough) hang. It was right at the time ad0 > is normally found (and configured): > BTW: I noticed with the patched kernel that the IRQ changed to 1 > (from 39). I guess this is related to the multiple IRQs for a PCI > device problem (IRQ 1 being the DBDMA interrupt): > interrupts: > 00 00 00 01 00 00 00 00 I've put somewhat-fixed versions at http://people.freebsd.org/~nwhitehorn/ata_dbdma.c and http://people.freebsd.org/~nwhitehorn/ata_kauai.c. This should work up to WDMA2. The UDMA modes seem to require the DBDMA interrupt to work, and we can't allocate it right now because of this issue with the PCI bus driver. Any thoughts on how to fix it? Also, am I to understand that your Kauai controller doesn't export its interrupt either in the OF tree *or* in its PCI registers? I've hacked around this, assuming this is true, but it is pretty messed up... -Nathan From grehan at freebsd.org Thu Sep 11 07:21:06 2008 From: grehan at freebsd.org (Peter Grehan) Date: Thu Sep 11 07:21:12 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48C8B400.7060604@freebsd.org> References: <48C69864.3010208@freebsd.org> <48C7F336.6060003@freebsd.org> <1C883A32-8D01-4775-B027-20DB1DF4B4D3@mac.com> <48C8B400.7060604@freebsd.org> Message-ID: <48C8C82D.90207@freebsd.org> On an old iMac (macio 0x0025106b), I get a panic if ATA DMA isn't disabled: Memory modified after free 0xda6c00(508) val=0 @ 0xda6c00 panic: Most recently used by GEOM This is after the ad0/acd0 disk messages are displayed. later, Peter. From nwhitehorn at freebsd.org Thu Sep 11 16:00:10 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Thu Sep 11 16:01:17 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48C8C82D.90207@freebsd.org> References: <48C69864.3010208@freebsd.org> <48C7F336.6060003@freebsd.org> <1C883A32-8D01-4775-B027-20DB1DF4B4D3@mac.com> <48C8B400.7060604@freebsd.org> <48C8C82D.90207@freebsd.org> Message-ID: <48C9416A.8030608@freebsd.org> Peter Grehan wrote: > On an old iMac (macio 0x0025106b), I get a panic if ATA DMA isn't disabled: > > Memory modified after free 0xda6c00(508) val=0 @ 0xda6c00 > panic: Most recently used by GEOM > > This is after the ad0/acd0 disk messages are displayed. This is with one of the ATA - macio parts, I assume? Could you tell me whether (a) the two are on the same ATA bus, (b) the name of the ATA controller in OF (i.e. ata-3 or ata-4), and (c) which modes the driver wants to configure for both devices? I wish I had more hardware to test this on... -Nathan From grehan at freebsd.org Thu Sep 11 16:14:18 2008 From: grehan at freebsd.org (Peter Grehan) Date: Thu Sep 11 16:14:24 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48C9416A.8030608@freebsd.org> References: <48C69864.3010208@freebsd.org> <48C7F336.6060003@freebsd.org> <1C883A32-8D01-4775-B027-20DB1DF4B4D3@mac.com> <48C8B400.7060604@freebsd.org> <48C8C82D.90207@freebsd.org> <48C9416A.8030608@freebsd.org> Message-ID: <48C94537.6020109@freebsd.org> Hi Nathan, > This is with one of the ATA - macio parts, I assume? Could you tell me > whether (a) the two are on the same ATA bus, (b) the name of the ATA > controller in OF (i.e. ata-3 or ata-4), and (c) which modes the driver > wants to configure for both devices? Info appended; later, Peter. 0 > dev ata-4 ok 0 > .properties name ata-4 device_type ata AAPL,connector 61746100 compatible keylargo-ata AAPL,bus-id 00000002 reg 0001f000 00001000 00008a00 00000100 #address-cells 00000001 #size-cells 00000000 AAPL,pio-timing 00000526 00000085 00000025 00000025 00000025 00000000 00000000 00000000 model ata-4 interrupts 00000013 00000001 0000000b 00000000 interrupt-parent ff90fa00 cable-type 34302d63 6f6e6475 63746f72 00 AAPL,clock-id 75617461 61743636 AAPL,clock-data 03ef1480 00000000 00000000 00000000 00000000 00000044 00000100 00000044 00000080 6e756c6c 6e756c6c 00000000 AAPL,clock-aux-data 00000010 0000003c 20000000 00000000 ad0: 38166MB at ata0-master UDMA66 acd0: CDRW at ata0-slave PIO4 From nwhitehorn at freebsd.org Thu Sep 11 17:20:11 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Thu Sep 11 17:20:22 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48C94537.6020109@freebsd.org> References: <48C69864.3010208@freebsd.org> <48C7F336.6060003@freebsd.org> <1C883A32-8D01-4775-B027-20DB1DF4B4D3@mac.com> <48C8B400.7060604@freebsd.org> <48C8C82D.90207@freebsd.org> <48C9416A.8030608@freebsd.org> <48C94537.6020109@freebsd.org> Message-ID: <48C95436.8010204@freebsd.org> Peter Grehan wrote: > Hi Nathan, > >> This is with one of the ATA - macio parts, I assume? Could you tell me >> whether (a) the two are on the same ATA bus, (b) the name of the ATA >> controller in OF (i.e. ata-3 or ata-4), and (c) which modes the driver >> wants to configure for both devices? > > Info appended; > Could you try the new ata_macio.c at http://people.freebsd.org/~nwhitehorn/ata_macio.c? If that fails, also try changing sc->max_mode to WDMA2. My hardware (ata-3) won't let me test the UDMA modes, but at least the WDMA ones should now work in this configuration. -Nathan From jhb at freebsd.org Thu Sep 11 17:57:09 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Sep 11 17:57:20 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48C8B400.7060604@freebsd.org> References: <48C69864.3010208@freebsd.org> <1C883A32-8D01-4775-B027-20DB1DF4B4D3@mac.com> <48C8B400.7060604@freebsd.org> Message-ID: <200809111304.48753.jhb@freebsd.org> On Thursday 11 September 2008 02:00:32 am Nathan Whitehorn wrote: > The UDMA modes seem to require the DBDMA interrupt to work, > and we can't allocate it right now because of this issue with the PCI > bus driver. Any thoughts on how to fix it? So when I did the MSI stuff I had assumed (apparently incorrectly), that PCI functions would only every have 1 non-MSI interrupt (since there is only a single INTLINE config register). Is the extra interrupt coming from OF? If so, does OF support MSI at all? You could always change the OF PCI bus driver to not do MSI and use rid 1 IRQ for the OF indicated IRQ for a PCI device by having custom alloc_resource/setup_intr/teardown_intr methods. -- John Baldwin From grehan at freebsd.org Thu Sep 11 18:32:28 2008 From: grehan at freebsd.org (Peter Grehan) Date: Thu Sep 11 18:32:46 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <200809111304.48753.jhb@freebsd.org> References: <48C69864.3010208@freebsd.org> <1C883A32-8D01-4775-B027-20DB1DF4B4D3@mac.com> <48C8B400.7060604@freebsd.org> <200809111304.48753.jhb@freebsd.org> Message-ID: <48C9642A.5020801@freebsd.org> Hi John, > So when I did the MSI stuff I had assumed (apparently incorrectly), that PCI > functions would only every have 1 non-MSI interrupt (since there is only a > single INTLINE config register). Is the extra interrupt coming from OF? If > so, does OF support MSI at all? You could always change the OF PCI bus > driver to not do MSI and use rid 1 IRQ for the OF indicated IRQ for a PCI > device by having custom alloc_resource/setup_intr/teardown_intr methods. Int lines on the Mac go directly into the OpenPIC, allowing as many int sources as desired. The intline config register isn't really used, though there is code that attempts to read the OFW interrupt properties and then program that register to avoid messing with the PCI common code. Unfortunately, some Mac devices ignore writes to that register :( The G5 does support MSI. I had sent a possible solution to Nathan (Nathan: check your junk :) that in pci_setup_intr did something like: if (dinfo->cfg.msi.msi_addr > 0) { ... } else if (dinfo->cfg.msi.msix_alloc > 0) { ... } else { #ifndef __powerpc__ KASSERT("No MSI or MSI-X interrupts allocated") #endif } There's probably a bunch of other places that need fixing but this was an obvious one. later, Peter. From jhb at freebsd.org Thu Sep 11 21:43:37 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Sep 11 21:43:52 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48C9642A.5020801@freebsd.org> References: <48C69864.3010208@freebsd.org> <200809111304.48753.jhb@freebsd.org> <48C9642A.5020801@freebsd.org> Message-ID: <200809111651.05462.jhb@freebsd.org> On Thursday 11 September 2008 02:32:10 pm Peter Grehan wrote: > Hi John, > > > So when I did the MSI stuff I had assumed (apparently incorrectly), that PCI > > functions would only every have 1 non-MSI interrupt (since there is only a > > single INTLINE config register). Is the extra interrupt coming from OF? If > > so, does OF support MSI at all? You could always change the OF PCI bus > > driver to not do MSI and use rid 1 IRQ for the OF indicated IRQ for a PCI > > device by having custom alloc_resource/setup_intr/teardown_intr methods. > > Int lines on the Mac go directly into the OpenPIC, allowing as many > int sources as desired. The intline config register isn't really used, > though there is code that attempts to read the OFW interrupt properties > and then program that register to avoid messing with the PCI common > code. Unfortunately, some Mac devices ignore writes to that register :( > The G5 does support MSI. > > I had sent a possible solution to Nathan (Nathan: check your junk :) > that in pci_setup_intr did something like: > > if (dinfo->cfg.msi.msi_addr > 0) { > ... > } else if (dinfo->cfg.msi.msix_alloc > 0) { > ... > } else { > #ifndef __powerpc__ > KASSERT("No MSI or MSI-X interrupts allocated") > #endif > } > > There's probably a bunch of other places that need fixing but this was > an obvious one. OFW should already have its own PCI bus driver, so I'd rather you give it its own bus_setup_intr() method that DTRT for these interrupt resources (rid > 0 and !MSI) and then calls pci_setup_intr() for the rest. Then you don't have to add MD hacks to the generic PCI bus driver. -- John Baldwin From nwhitehorn at freebsd.org Thu Sep 11 22:13:54 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Thu Sep 11 22:14:00 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <200809111651.05462.jhb@freebsd.org> References: <48C69864.3010208@freebsd.org> <200809111304.48753.jhb@freebsd.org> <48C9642A.5020801@freebsd.org> <200809111651.05462.jhb@freebsd.org> Message-ID: <48C9981B.2020808@freebsd.org> John Baldwin wrote: > On Thursday 11 September 2008 02:32:10 pm Peter Grehan wrote: > >> Hi John, >> >> >>> So when I did the MSI stuff I had assumed (apparently incorrectly), that >>> > PCI > >>> functions would only every have 1 non-MSI interrupt (since there is only a >>> single INTLINE config register). Is the extra interrupt coming from OF? >>> > If > >>> so, does OF support MSI at all? You could always change the OF PCI bus >>> driver to not do MSI and use rid 1 IRQ for the OF indicated IRQ for a PCI >>> device by having custom alloc_resource/setup_intr/teardown_intr methods. >>> >> Int lines on the Mac go directly into the OpenPIC, allowing as many >> int sources as desired. The intline config register isn't really used, >> though there is code that attempts to read the OFW interrupt properties >> and then program that register to avoid messing with the PCI common >> code. Unfortunately, some Mac devices ignore writes to that register :( >> The G5 does support MSI. >> >> I had sent a possible solution to Nathan (Nathan: check your junk :) >> that in pci_setup_intr did something like: >> >> if (dinfo->cfg.msi.msi_addr > 0) { >> ... >> } else if (dinfo->cfg.msi.msix_alloc > 0) { >> ... >> } else { >> #ifndef __powerpc__ >> KASSERT("No MSI or MSI-X interrupts allocated") >> #endif >> } >> >> There's probably a bunch of other places that need fixing but this was >> an obvious one. >> > > OFW should already have its own PCI bus driver, so I'd rather you give it its > own bus_setup_intr() method that DTRT for these interrupt resources (rid > 0 > and !MSI) and then calls pci_setup_intr() for the rest. Then you don't have > to add MD hacks to the generic PCI bus driver. > It doesn't on PowerPC. There are a bunch of hacks done at attach-time to compensate for this (see ofw_pci_fixup()). It might be nice to import sparc64's PCI OFW bus code, though. -Nathan From jhb at freebsd.org Fri Sep 12 14:50:54 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri Sep 12 14:51:02 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48C9981B.2020808@freebsd.org> References: <48C69864.3010208@freebsd.org> <200809111651.05462.jhb@freebsd.org> <48C9981B.2020808@freebsd.org> Message-ID: <200809121033.24809.jhb@freebsd.org> On Thursday 11 September 2008 06:13:47 pm Nathan Whitehorn wrote: > John Baldwin wrote: > > On Thursday 11 September 2008 02:32:10 pm Peter Grehan wrote: > > > >> Hi John, > >> > >> > >>> So when I did the MSI stuff I had assumed (apparently incorrectly), that > >>> > > PCI > > > >>> functions would only every have 1 non-MSI interrupt (since there is only a > >>> single INTLINE config register). Is the extra interrupt coming from OF? > >>> > > If > > > >>> so, does OF support MSI at all? You could always change the OF PCI bus > >>> driver to not do MSI and use rid 1 IRQ for the OF indicated IRQ for a PCI > >>> device by having custom alloc_resource/setup_intr/teardown_intr methods. > >>> > >> Int lines on the Mac go directly into the OpenPIC, allowing as many > >> int sources as desired. The intline config register isn't really used, > >> though there is code that attempts to read the OFW interrupt properties > >> and then program that register to avoid messing with the PCI common > >> code. Unfortunately, some Mac devices ignore writes to that register :( > >> The G5 does support MSI. > >> > >> I had sent a possible solution to Nathan (Nathan: check your junk :) > >> that in pci_setup_intr did something like: > >> > >> if (dinfo->cfg.msi.msi_addr > 0) { > >> ... > >> } else if (dinfo->cfg.msi.msix_alloc > 0) { > >> ... > >> } else { > >> #ifndef __powerpc__ > >> KASSERT("No MSI or MSI-X interrupts allocated") > >> #endif > >> } > >> > >> There's probably a bunch of other places that need fixing but this was > >> an obvious one. > >> > > > > OFW should already have its own PCI bus driver, so I'd rather you give it its > > own bus_setup_intr() method that DTRT for these interrupt resources (rid > 0 > > and !MSI) and then calls pci_setup_intr() for the rest. Then you don't have > > to add MD hacks to the generic PCI bus driver. > > > It doesn't on PowerPC. There are a bunch of hacks done at attach-time to > compensate for this (see ofw_pci_fixup()). It might be nice to import > sparc64's PCI OFW bus code, though. Ah, yeah, it certainly might be. Having separate PCI bus drivers for ACPI vs. not (and all the various PCI bridge drivers) helped detangle a bunch of mess in PCI and made ACPI support a lot easier. -- John Baldwin From grehan at freebsd.org Fri Sep 12 17:21:33 2008 From: grehan at freebsd.org (Peter Grehan) Date: Fri Sep 12 17:21:40 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48C95436.8010204@freebsd.org> References: <48C69864.3010208@freebsd.org> <48C7F336.6060003@freebsd.org> <1C883A32-8D01-4775-B027-20DB1DF4B4D3@mac.com> <48C8B400.7060604@freebsd.org> <48C8C82D.90207@freebsd.org> <48C9416A.8030608@freebsd.org> <48C94537.6020109@freebsd.org> <48C95436.8010204@freebsd.org> Message-ID: <48CAA46D.50604@freebsd.org> Hi Nathan, > Could you try the new ata_macio.c at > http://people.freebsd.org/~nwhitehorn/ata_macio.c? If that fails, also > try changing sc->max_mode to WDMA2. My hardware (ata-3) won't let me > test the UDMA modes, but at least the WDMA ones should now work in this > configuration. Had to drop it to WDMA2 and then the DMA i/o's completed. However, the GEOM use-after-free panic persists. I'll see if I can get some more info about that. later, Peter. From nwhitehorn at freebsd.org Fri Sep 12 17:54:07 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Fri Sep 12 17:54:19 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48CAA46D.50604@freebsd.org> References: <48C69864.3010208@freebsd.org> <48C7F336.6060003@freebsd.org> <1C883A32-8D01-4775-B027-20DB1DF4B4D3@mac.com> <48C8B400.7060604@freebsd.org> <48C8C82D.90207@freebsd.org> <48C9416A.8030608@freebsd.org> <48C94537.6020109@freebsd.org> <48C95436.8010204@freebsd.org> <48CAA46D.50604@freebsd.org> Message-ID: <48CAACB8.90104@freebsd.org> Peter Grehan wrote: > Hi Nathan, > >> Could you try the new ata_macio.c at >> http://people.freebsd.org/~nwhitehorn/ata_macio.c? If that fails, >> also try changing sc->max_mode to WDMA2. My hardware (ata-3) won't >> let me test the UDMA modes, but at least the WDMA ones should now >> work in this configuration. > > Had to drop it to WDMA2 and then the DMA i/o's completed. However, > the GEOM use-after-free panic persists. I'll see if I can get some > more info about that. Interesting. I don't know what the panic is about, but it seems like programming the UDMA modes fails on the macio, Kauai, and Shasta controllers. I spent entirely too much time smashing my head against the UDMA stuff on Shasta last night with no success. Maybe there is some MI problem where requests interact poorly with these controllers? As far as I know, there have never been non-PCI UDMA ATA controllers in the tree before. -Nathan From tinderbox at freebsd.org Sun Sep 14 11:27:27 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 14 11:27:40 2008 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20080914112723.C6D4373039@freebsd-current.sentex.ca> TB --- 2008-09-14 10:07:08 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-14 10:07:08 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-09-14 10:07:08 - cleaning the object tree TB --- 2008-09-14 10:07:41 - cvsupping the source tree TB --- 2008-09-14 10:07:41 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-09-14 10:07:49 - building world (CFLAGS=-O -pipe) TB --- 2008-09-14 10:07:49 - cd /src TB --- 2008-09-14 10:07:49 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 14 10:07:51 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Sep 14 11:21:17 UTC 2008 TB --- 2008-09-14 11:21:17 - generating LINT kernel config TB --- 2008-09-14 11:21:17 - cd /src/sys/powerpc/conf TB --- 2008-09-14 11:21:17 - /usr/bin/make -B LINT TB --- 2008-09-14 11:21:17 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-14 11:21:17 - cd /src TB --- 2008-09-14 11:21:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Sep 14 11:21:17 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/pfil.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/radix.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/radix_mpath.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/raw_cb.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/raw_usrreq.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/route.c /src/sys/net/route.c: In function 'rt_check': /src/sys/net/route.c:1701: error: invalid type argument of '->' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-14 11:27:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-14 11:27:23 - ERROR: failed to build lint kernel TB --- 2008-09-14 11:27:23 - tinderbox aborted TB --- 3382.23 user 400.08 system 4815.40 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From tinderbox at freebsd.org Sun Sep 14 17:32:21 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 14 17:32:34 2008 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20080914173213.7B17F73039@freebsd-current.sentex.ca> TB --- 2008-09-14 17:08:41 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-14 17:08:41 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-09-14 17:08:41 - cleaning the object tree TB --- 2008-09-14 17:09:07 - cvsupping the source tree TB --- 2008-09-14 17:09:07 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-09-14 17:09:16 - building world (CFLAGS=-O -pipe) TB --- 2008-09-14 17:09:16 - cd /src TB --- 2008-09-14 17:09:16 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 14 17:09:17 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -DPTHREAD_KERNEL -I/src/lib/libthr/../libc/include -I/src/lib/libthr/thread -I/src/lib/libthr/../../include -I/src/lib/libthr/arch/powerpc/include -I/src/lib/libthr/sys -I/src/lib/libthr/../../libexec/rtld-elf -I/src/lib/libthr/../../libexec/rtld-elf/powerpc -I/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libthr/thread/thr_detach.c cc -O -pipe -DPTHREAD_KERNEL -I/src/lib/libthr/../libc/include -I/src/lib/libthr/thread -I/src/lib/libthr/../../include -I/src/lib/libthr/arch/powerpc/include -I/src/lib/libthr/sys -I/src/lib/libthr/../../libexec/rtld-elf -I/src/lib/libthr/../../libexec/rtld-elf/powerpc -I/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libthr/thread/thr_equal.c cc -O -pipe -DPTHREAD_KERNEL -I/src/lib/libthr/../libc/include -I/src/lib/libthr/thread -I/src/lib/libthr/../../include -I/src/lib/libthr/arch/powerpc/include -I/src/lib/libthr/sys -I/src/lib/libthr/../../libexec/rtld-elf -I/src/lib/libthr/../../libexec/rtld-elf/powerpc -I/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libthr/thread/thr_event.c cc1: warnings being treated as errors /src/lib/libthr/thread/thr_event.c: In function '_thr_report_creation': /src/lib/libthr/thread/thr_event.c:45: warning: assignment makes pointer from integer without a cast /src/lib/libthr/thread/thr_event.c: In function '_thr_report_death': /src/lib/libthr/thread/thr_event.c:58: warning: assignment makes pointer from integer without a cast *** Error code 1 Stop in /src/lib/libthr. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-14 17:32:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-14 17:32:13 - ERROR: failed to build world TB --- 2008-09-14 17:32:13 - tinderbox aborted TB --- 1009.98 user 132.73 system 1411.71 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From tinderbox at freebsd.org Mon Sep 15 07:47:47 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Sep 15 07:48:06 2008 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20080915074742.222EB73039@freebsd-current.sentex.ca> TB --- 2008-09-15 06:24:02 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-15 06:24:02 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-09-15 06:24:02 - cleaning the object tree TB --- 2008-09-15 06:24:28 - cvsupping the source tree TB --- 2008-09-15 06:24:29 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-09-15 06:24:36 - building world (CFLAGS=-O -pipe) TB --- 2008-09-15 06:24:36 - cd /src TB --- 2008-09-15 06:24:36 - /usr/bin/make -B buildworld >>> World build started on Mon Sep 15 06:24:37 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Sep 15 07:41:16 UTC 2008 TB --- 2008-09-15 07:41:16 - generating LINT kernel config TB --- 2008-09-15 07:41:16 - cd /src/sys/powerpc/conf TB --- 2008-09-15 07:41:16 - /usr/bin/make -B LINT TB --- 2008-09-15 07:41:16 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-15 07:41:16 - cd /src TB --- 2008-09-15 07:41:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Sep 15 07:41:16 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/pfil.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/radix.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/radix_mpath.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/raw_cb.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/raw_usrreq.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/route.c /src/sys/net/route.c: In function 'rt_check': /src/sys/net/route.c:1719: error: invalid type argument of '->' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-15 07:47:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-15 07:47:41 - ERROR: failed to build lint kernel TB --- 2008-09-15 07:47:41 - tinderbox aborted TB --- 3385.69 user 403.96 system 5019.26 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From bugmaster at FreeBSD.org Mon Sep 15 15:18:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 15 15:20:36 2008 Subject: Current problem reports assigned to freebsd-ppc@FreeBSD.org Message-ID: <200809151518.m8FFIrTg018988@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- a power/121407 ppc [panic] Won't boot up; strange error message. o power/112435 ppc [nexus] [patch] Update nexus children to use ofw_bus f o power/111296 ppc [kernel] [patch] [request] Support IMISS, DLMISS an DS o power/93203 ppc FreeBSD PPC Can't Write to Partitions. 4 problems total. From xcllnt at mac.com Tue Sep 16 20:05:18 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Sep 16 20:07:28 2008 Subject: [AIM] SMP now working Message-ID: <2A84850D-B205-472A-BC5B-471F2817BC7B@mac.com> All, I managed to have some "quality" time with my Xserve over the weekend and the outstanding SMP problems have been resolved. My Xserve is now happily running a SMP kernel: xserve% dmesg Copyright (c) 1992-2008 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #16 r183030:183060M: Mon Sep 15 23:16:32 PDT 2008 marcel@xserve.xcllnt.net:/nfs/freebsd/patch/smp/sys/powerpc/ compile/XSERVE-MP WARNING: WITNESS option enabled, expect reduced performance. cpu0: Motorola PowerPC 7455 revision 2.1, 1000.00 MHz cpu0: HID0 8450c0bc real memory = 526016512 (501 MB) avail memory = 508674048 (485 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0: dev=ff87f908 (BSP) cpu1: dev=ff880bc8 *snip* Waking up CPU 1 (dev=ff880bc8) WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad0s3 *snip* xserve% sysctl kern.smp kern.smp.forward_roundrobin_enabled: 1 kern.smp.forward_signal_enabled: 1 kern.smp.topology: 0 kern.smp.cpus: 2 kern.smp.disabled: 0 kern.smp.active: 1 kern.smp.maxcpus: 2 kern.smp.maxid: 1 xserve% vmstat -ia interrupt total rate irq48: bge0 0 0 irq22: scc0 87901 1 irq23: scc0 0 0 irq19: ata0 23 0 irq27: ohci0 1 0 irq28: ohci1 1 0 irq58: atapci0 294008 5 irq63: atapci1 26 0 irq39: ata1 0 0 irq40: fwohci0 2 0 irq41: gem0 12498387 252 irq64: IPI 3546235 71 Total 16426584 332 FYI, -- Marcel Moolenaar xcllnt@mac.com From grehan at freebsd.org Tue Sep 16 20:40:27 2008 From: grehan at freebsd.org (Peter Grehan) Date: Tue Sep 16 20:40:53 2008 Subject: [AIM] SMP now working In-Reply-To: <2A84850D-B205-472A-BC5B-471F2817BC7B@mac.com> References: <2A84850D-B205-472A-BC5B-471F2817BC7B@mac.com> Message-ID: <48D019AC.2040409@freebsd.org> > I managed to have some "quality" time with my Xserve over the > weekend and the outstanding SMP problems have been resolved. Great stuff Marcel ! How does a buildworld -j (> 1) go ? later, Peter. From xcllnt at mac.com Tue Sep 16 21:01:48 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Sep 16 21:01:54 2008 Subject: [AIM] SMP now working In-Reply-To: <48D019AC.2040409@freebsd.org> References: <2A84850D-B205-472A-BC5B-471F2817BC7B@mac.com> <48D019AC.2040409@freebsd.org> Message-ID: <2C9F58FE-30CA-4DF0-B739-A7B70F7DC181@mac.com> On Sep 16, 2008, at 1:40 PM, Peter Grehan wrote: >> I managed to have some "quality" time with my Xserve over the >> weekend and the outstanding SMP problems have been resolved. > > Great stuff Marcel ! How does a buildworld -j (> 1) go ? All the way to the end :-) Seriously: I haven't done any timings yet. I'm mostly just upping the load to see how stable it is. A -j4 completes and a -j8 is in progress. If that completes I'll be doing UP vs. SMP comparisons. There's a visible speedup, so things look good. I hope to have hard data next week or so. Random notes: o It should be safe to enable interrupt delivery to all CPUs and play around with programming the TPR of the CPUs. o SMP works with 4BSD only, but raj@ just told me he has ULE support for SMP. o We should take advantage of the OpenPIC timers to driver hardclock, etc. o Cache prefetching hasn't been enabled on the AP yet. -- Marcel Moolenaar xcllnt@mac.com From danfe at FreeBSD.org Wed Sep 17 03:14:28 2008 From: danfe at FreeBSD.org (Alexey Dokuchaev) Date: Wed Sep 17 03:14:35 2008 Subject: [AIM] SMP now working In-Reply-To: <2A84850D-B205-472A-BC5B-471F2817BC7B@mac.com> References: <2A84850D-B205-472A-BC5B-471F2817BC7B@mac.com> Message-ID: <20080917031428.GA39098@FreeBSD.org> On Tue, Sep 16, 2008 at 01:05:11PM -0700, Marcel Moolenaar wrote: > All, > > I managed to have some "quality" time with my Xserve over the > weekend and the outstanding SMP problems have been resolved. > My Xserve is now happily running a SMP kernel: Most definitely cool. Great job Marcel! ./danfe From rc at rcmaples.net Thu Sep 18 06:14:09 2008 From: rc at rcmaples.net (R. C. Maples) Date: Thu Sep 18 06:14:16 2008 Subject: HowTo: Install freebsd-ppc on a g4 mac mini? Message-ID: What ever happened to this? Any step by steps on single booting a mac mini g4 into FreeBSD 7.0-ppc? On September 28, 2007 Oliver Lietz wrote: not a detailed how-to but some hints: You can boot the Mini in target mode and create the partitions from another Mac with pdisk - first one HFS+, others UFS (your preferred BSD partition layout: /, swap, tmp, ...). Create a boot.tbxi file, see below (without #s). Copy the loader from your FreeBSD install CD and the boot.tbxi to your HFS+ partition. Reboot the Mini and install FreebBSD from CD, create new file systems with sysinstall on your UFS partitions. Finish setup and reboot. On next boot enter OFW and change some settings like below: boot-device hd:2,\boot.tbxi boot-file boot.tbxi boot-command boot You should reboot after changing settings in OFW (search the web for more details on changing settings in OFW). This is straight from memory and some notes. AFAIR you can drop boot.tbxi and use loader directly - can't say for sure as I had to reinstall Mac OS for some tests on my Cubes. If someone is interested in a detailed how-to I will create one next time I install FreeBSD on my Cubes (will wait until release of 7.0 though). O. #### boot.tbxi #### MacRISC MacRISC3 MacRISC4 FreeBSD/PPC bootloader " screen" output boot hd:2,\loader hd:3 ################### From chlastak at fialka.cz Thu Sep 18 10:53:56 2008 From: chlastak at fialka.cz (Miroslav Chlastak) Date: Thu Sep 18 10:54:03 2008 Subject: support for routerboard 600A (MPC8343E) Message-ID: <48D22F96.5050306@fialka.cz> Hello, I have simple question - is freebsd-ppc ready for running on routerboard 600A with MPC8343E (http://www.routerboard.com/popup.php?kods=75&sess=3cc1c48d35523c4b5120cc0f94b7f70d)? Next week I will have one board for testing and can test freebsd on this board. Thanks, -- Mira Chlastak From raj at semihalf.com Thu Sep 18 12:35:02 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Thu Sep 18 12:35:08 2008 Subject: support for routerboard 600A (MPC8343E) In-Reply-To: <48D22F96.5050306@fialka.cz> References: <48D22F96.5050306@fialka.cz> Message-ID: <48D247C5.8020406@semihalf.com> Miroslav Chlastak wrote: > I have simple question - is freebsd-ppc ready for running on > routerboard 600A with MPC8343E > (http://www.routerboard.com/popup.php?kods=75&sess=3cc1c48d35523c4b5120cc0f94b7f70d)? The FreeBSD/powerpc port as is now does not support MPC83xx systems; benno@ was working on porting FreeBSD to some Routerboard device, but I don't know what what his current status is. Rafal From nse at delfi-konsult.com Thu Sep 18 21:55:18 2008 From: nse at delfi-konsult.com (Niels S. Eliasen) Date: Thu Sep 18 21:55:25 2008 Subject: ZFS .. on PowerPC ? Message-ID: Hi guys Just wanted to test out "zfs" on my TiBook.... but no luck.... get : [root@munin ~]# zfs -? internal error: failed to initialize ZFS library regardless of whatever parameters I put to "zfs" .... any gotchas that I should be aware of ? BTW: this is stock 7.0 FreeBSD(PowerPC) kind regards nse "Ach, crivens, what a wee snotter....." Quote from "The Wee Free Men" by Terry Pratchett From grehan at freebsd.org Thu Sep 18 22:19:52 2008 From: grehan at freebsd.org (Peter Grehan) Date: Thu Sep 18 22:19:58 2008 Subject: ZFS .. on PowerPC ? In-Reply-To: References: Message-ID: <48D2D3FF.1020606@freebsd.org> Hi Niels, > regardless of whatever parameters I put to "zfs" .... > any gotchas that I should be aware of ? > > BTW: this is stock 7.0 FreeBSD(PowerPC) My guess is that the limited amount of KVM on FreeBSD/ppc is going to get you. There's only 512M, so it would be prone to the same issues as are occurring on i386, only more so :( Keep us informed though: I'm interested to see how it goes. later, Peter. From benno at jeamland.net Thu Sep 18 22:43:07 2008 From: benno at jeamland.net (Benno Rice) Date: Thu Sep 18 22:43:14 2008 Subject: support for routerboard 600A (MPC8343E) In-Reply-To: <48D247C5.8020406@semihalf.com> References: <48D22F96.5050306@fialka.cz> <48D247C5.8020406@semihalf.com> Message-ID: <94601BD9-5D18-4652-970A-A30E570521F5@jeamland.net> On 18/09/2008, at 10:21 PM, Rafal Jaworowski wrote: > Miroslav Chlastak wrote: >> I have simple question - is freebsd-ppc ready for running on >> routerboard 600A with MPC8343E >> (http://www.routerboard.com/popup.php?kods=75&sess=3cc1c48d35523c4b5120cc0f94b7f70d >> )? > > The FreeBSD/powerpc port as is now does not support MPC83xx systems; > benno@ > was working on porting FreeBSD to some Routerboard device, but I > don't know > what what his current status is. I've got a Routerboard 333 (MPC8321) but no spare time at the moment. =/ -- Benno Rice benno@jeamland.net From xcllnt at mac.com Fri Sep 19 00:12:10 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Sep 19 00:12:16 2008 Subject: ZFS .. on PowerPC ? In-Reply-To: References: Message-ID: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> On Sep 18, 2008, at 2:46 PM, Niels S. Eliasen wrote: > Hi guys > Just wanted to test out "zfs" on my TiBook.... > but no luck.... > get : > > [root@munin ~]# zfs -? > internal error: failed to initialize ZFS library > > regardless of whatever parameters I put to "zfs" .... > any gotchas that I should be aware of ? ZFS requires 64-bit atomic operations, which PowerPC doesn't have. So, we can't build the ZFS kernel module. That's probably why you get the error... -- Marcel Moolenaar xcllnt@mac.com From grehan at freebsd.org Fri Sep 19 00:29:38 2008 From: grehan at freebsd.org (Peter Grehan) Date: Fri Sep 19 00:29:43 2008 Subject: ZFS .. on PowerPC ? In-Reply-To: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> References: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> Message-ID: <48D2F238.7070102@freebsd.org> Hi Marcel, > ZFS requires 64-bit atomic operations, which > PowerPC doesn't have. So, we can't build the > ZFS kernel module. That's probably why you > get the error... Pjd has a workaround for non-LP64 systems in cddl/compat/opensolaris/kern/opensolaris_atomic.c .. that funnel all 64-bit atomic ops through a single mutex. Not particularly efficient but it should still work. Unless I'm missing some other code paths here. later, Peter. From chlastak at fialka.cz Fri Sep 19 10:56:41 2008 From: chlastak at fialka.cz (Miroslav Chlastak) Date: Fri Sep 19 10:56:47 2008 Subject: support for routerboard 600A (MPC8343E) In-Reply-To: <48D35520.2000102@pacomp.pl> References: <48D22F96.5050306@fialka.cz> <48D2576D.2040001@pacomp.pl> <48D26018.6050905@fialka.cz> <48D35520.2000102@pacomp.pl> Message-ID: <48D38563.8050204@fialka.cz> Hi, as wireless card I have Atheros CM9 (AR5213) - no problem in fbsd-7-i386. As access point I use "ifconfig mediaopt hostap". Is this function in fbsd-ppc working? Or in other way - what is done in fbsd-ppc project and what of basic function of base system is missing? -- Mira Chlastak Konrad Karpowicz napsal(a): > I'm not very good in a wireless subject but I think it should work if > you have drivers and software. > > Konrad > > > > Miroslav Chlastak pisze: >> Hello, >> >> thanks for your reply. I can use board with MPC8343 as wireless AP. >> "How far" is fbsd-ppc to do this? :) >> >> -- >> Mira Chlastak >> >> Konrad Karpowicz napsal(a): >>> Hello, >>> >>> We have FreeBSD 6.3 running on MPC8349. But there is still some work >>> to do - it is not very stable. >>> Kind regards, >>> >>> Konrad Karpowicz >>> PACOMP >>> >>> >>> >>> Miroslav Chlastak pisze: >>>> Hello, >>>> >>>> I have simple question - is freebsd-ppc ready for running on >>>> routerboard 600A with MPC8343E >>>> (http://www.routerboard.com/popup.php?kods=75&sess=3cc1c48d35523c4b5120cc0f94b7f70d)? >>>> >>>> Next week I will have one board for testing and can test freebsd on >>>> this board. >>>> >>>> >>>> Thanks, >>>> -- >>>> Mira Chlastak >>>> >>>> _______________________________________________ >>>> freebsd-ppc@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc >>>> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >>>> >>> >> >> > From sobomax at FreeBSD.org Fri Sep 19 11:38:46 2008 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Fri Sep 19 11:38:46 2008 Subject: Call for testers: Apple ATA DMA References: b9c23c9f0809100322n1659cb36oa05acf2f13f3c7e1@mail.gmail.com Message-ID: <48D389EE.9000207@FreeBSD.org> Nathan, Do you have any news regarding the patch in question? I hope you did not give up, the lack of ATA DMA support is IMHO probably the biggest issue for the FreeBSD on PowerMacs now. The hardware is very attractive for SOHO applications, so that having this feature is important. Thanks! -Maxim From sobomax at FreeBSD.org Fri Sep 19 11:43:53 2008 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Fri Sep 19 11:43:57 2008 Subject: eeprom and ofwdump question.... Message-ID: <48D39074.1020607@FreeBSD.org> Use nvram(8) instead of eeprom. -Maxim From nwhitehorn at freebsd.org Fri Sep 19 13:47:10 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Fri Sep 19 13:47:15 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48D389EE.9000207@FreeBSD.org> References: b9c23c9f0809100322n1659cb36oa05acf2f13f3c7e1@mail.gmail.com <48D389EE.9000207@FreeBSD.org> Message-ID: <48D3AD50.8070505@freebsd.org> Maxim Sobolev wrote: > Nathan, > > Do you have any news regarding the patch in question? I hope you did > not give up, the lack of ATA DMA support is IMHO probably the biggest > issue for the FreeBSD on PowerMacs now. The hardware is very > attractive for SOHO applications, so that having this feature is > important. Right now, modes up to WDMA2 work. The UDMA modes cause hangs for reasons not entirely clear. I'm investigating it, but am in the Netherlands at the moment and it will have to wait until I get back. -Nathan From rc at rcmaples.net Fri Sep 19 15:54:44 2008 From: rc at rcmaples.net (R. C. Maples) Date: Fri Sep 19 15:54:47 2008 Subject: Install question Message-ID: When you install, do you have to leave an HFS parition on the drive with the loader in it? Is there anyway to get OFW to see that and boot to it automatically instead of having to jump into OFW on restarts? -- RC Maples From freebsd at oliverlietz.de Fri Sep 19 16:40:58 2008 From: freebsd at oliverlietz.de (Oliver Lietz) Date: Fri Sep 19 16:41:03 2008 Subject: Install question In-Reply-To: References: Message-ID: <200809191828.14030.freebsd@oliverlietz.de> Am Freitag, 19. September 2008 schrieb R. C. Maples: > When you install, do you have to leave an HFS parition on the drive > with the loader in it? Yes. > Is there anyway to get OFW to see that and boot > to it automatically instead of having to jump into OFW on restarts? As described in my mail cited by you yesterday. O. From grehan at freebsd.org Fri Sep 19 23:07:31 2008 From: grehan at freebsd.org (Peter Grehan) Date: Fri Sep 19 23:07:33 2008 Subject: cvs commit: src/sys/boot/ofw/libofw Makefile ofw_console.c In-Reply-To: <48D41456.5010808@FreeBSD.org> References: <200809191100.m8JB0T2T037268@repoman.freebsd.org> <48D3CB22.4090006@freebsd.org> <48D3EA7F.7010706@FreeBSD.org> <48D40304.70800@FreeBSD.org> <48D409E7.7050306@freebsd.org> <48D41456.5010808@FreeBSD.org> Message-ID: <48D430A7.9010300@freebsd.org> Hi Maxim, (moving to freebsd-ppc) > While we are talking, I also noticed that my time is constantly off > by the same amount after every boot (yes, I am using ntpd), which is > 22,169 seconds (I run ntpdate on every boot, which shows me offset). > > However, if I manually call rtc.read-rtc method via OF prompt, adjust > time for DIFF19041970 then the difference is much less. Do you have > any idea what the problem might be? This is 7.1-BETA. ... > To clarify: I mean that I call rtc.read-rtc(), write down the value, > boot, sync via ntpdate, call time(3), adjust value for DIFF19041970 > and compare. Sounds like a bug. I'll get some results from a few systems and see if it matches up. later, Peter. From nse at delfi-konsult.com Sat Sep 20 10:05:23 2008 From: nse at delfi-konsult.com (Niels S. Eliasen) Date: Sat Sep 20 10:05:27 2008 Subject: ZFS .. on PowerPC ? In-Reply-To: <48D2F238.7070102@freebsd.org> References: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48D2F238.7070102@freebsd.org> Message-ID: Hi Peter, Marcel Den 19/09/2008 kl. 02.28 skrev Peter Grehan: > Hi Marcel, > >> ZFS requires 64-bit atomic operations, which >> PowerPC doesn't have. So, we can't build the >> ZFS kernel module. That's probably why you >> get the error... > > Pjd has a workaround for non-LP64 systems in > > cddl/compat/opensolaris/kern/opensolaris_atomic.c > > .. that funnel all 64-bit atomic ops through a single mutex. Not > particularly efficient but it should still work. Unless I'm missing > some other code paths here. > > later, > > Peter. Sounds like a good thing .... Is this possible to do for a non-progamming guy.... in other (layman's) words ... is there a howto for this ? kind regards nse "Ach, crivens, what a wee snotter....." Quote from "The Wee Free Men" by Terry Pratchett From xcllnt at mac.com Sat Sep 20 18:24:06 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Sep 20 18:24:10 2008 Subject: [AIM] UP vs SMP comparison Message-ID: <7E6A8CC7-2466-453C-AE0D-FB4699974126@mac.com> All, Below the "make buildworld" times ran on an UP and a SMP kernel: UP SMP -j1 5:09 5:31 -j2 5:05 3:12 -j4 5:07 3:04 Conclusions: o It appears that CPU is the bottleneck for UP in my setup. o An SMP kernel is 7% slower than an UP kernel. o There's a 1.7x speed-up between -j1 and -j2 for SMP. machine: FreeBSD 8.0-CURRENT #16 r183030:183060M: Mon Sep 15 23:16:32 PDT 2008 marcel@xserve.xcllnt.net:/nfs/freebsd/patch/smp/sys/powerpc/ compile/XSERVE-MP WARNING: WITNESS option enabled, expect reduced performance. cpu0: Motorola PowerPC 7455 revision 2.1, 1000.00 MHz cpu0: HID0 8450c0bc real memory = 526016512 (501 MB) avail memory = 508674048 (485 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs configuration: /usr/src over NFS using gem(4) /usr/obj local (PCI based ATA controller) gem0: flags=8843 metric 0 mtu 1500 options=b ether 00:03:93:a8:cc:16 inet 172.16.4.106 netmask 0xffffff00 broadcast 172.16.4.255 media: Ethernet autoselect (1000baseT ) status: active atapci0: port 0x1090-0x1097,0x1080-0x1083,0x1070-0x1077,0x1060-0x1063,0x1050-0x105f mem 0x90030000-0x9003ffff irq 58 at device 21.0 on pci1 atapci1: port 0x1040-0x1047,0x1030-0x1033,0x1020-0x1027,0x1010-0x1013,0x1000-0x100f mem 0x90010000-0x9001ffff irq 63 at device 27.0 on pci1 -- Marcel Moolenaar xcllnt@mac.com From tinderbox at freebsd.org Sat Sep 20 22:54:35 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat Sep 20 22:54:46 2008 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20080920225432.9D40673039@freebsd-current.sentex.ca> TB --- 2008-09-20 22:53:30 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-20 22:53:30 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-09-20 22:53:30 - cleaning the object tree TB --- 2008-09-20 22:54:00 - cvsupping the source tree TB --- 2008-09-20 22:54:00 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-09-20 22:54:06 - building world (CFLAGS=-O -pipe) TB --- 2008-09-20 22:54:06 - cd /src TB --- 2008-09-20 22:54:06 - /usr/bin/make -B buildworld >>> World build started on Sat Sep 20 22:54:07 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-20 22:54:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-20 22:54:32 - ERROR: failed to build world TB --- 2008-09-20 22:54:32 - tinderbox aborted TB --- 17.92 user 5.62 system 61.86 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From tinderbox at freebsd.org Sun Sep 21 00:02:32 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 00:02:43 2008 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20080921000229.ECB4073039@freebsd-current.sentex.ca> TB --- 2008-09-21 00:01:52 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 00:01:52 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-09-21 00:01:52 - cleaning the object tree TB --- 2008-09-21 00:01:54 - cvsupping the source tree TB --- 2008-09-21 00:01:54 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-09-21 00:02:00 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 00:02:00 - cd /src TB --- 2008-09-21 00:02:00 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 00:02:01 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 00:02:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 00:02:29 - ERROR: failed to build world TB --- 2008-09-21 00:02:29 - tinderbox aborted TB --- 17.06 user 2.85 system 37.21 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From tinderbox at freebsd.org Sun Sep 21 00:21:40 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 00:21:48 2008 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20080921002137.D2FAB7303E@freebsd-current.sentex.ca> TB --- 2008-09-21 00:21:02 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 00:21:02 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-09-21 00:21:02 - cleaning the object tree TB --- 2008-09-21 00:21:05 - cvsupping the source tree TB --- 2008-09-21 00:21:05 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-09-21 00:21:12 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 00:21:12 - cd /src TB --- 2008-09-21 00:21:12 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 00:21:13 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 00:21:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 00:21:37 - ERROR: failed to build world TB --- 2008-09-21 00:21:37 - tinderbox aborted TB --- 17.49 user 2.47 system 34.89 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From tinderbox at freebsd.org Sun Sep 21 00:41:37 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 00:41:52 2008 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20080921004135.253127303E@freebsd-current.sentex.ca> TB --- 2008-09-21 00:41:04 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 00:41:04 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-09-21 00:41:04 - cleaning the object tree TB --- 2008-09-21 00:41:05 - cvsupping the source tree TB --- 2008-09-21 00:41:05 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-09-21 00:41:11 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 00:41:11 - cd /src TB --- 2008-09-21 00:41:11 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 00:41:11 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 00:41:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 00:41:35 - ERROR: failed to build world TB --- 2008-09-21 00:41:35 - tinderbox aborted TB --- 17.21 user 2.72 system 30.14 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From nwhitehorn at freebsd.org Sun Sep 21 19:42:05 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Sun Sep 21 19:42:10 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48D3AD50.8070505@freebsd.org> References: "b9c23c9f0809100322n1659cb36oa05acf2f13f3c7e1@mail.gmail.com" <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> Message-ID: <48D69679.1080701@freebsd.org> Nathan Whitehorn wrote: > Maxim Sobolev wrote: >> Nathan, >> >> Do you have any news regarding the patch in question? I hope you did >> not give up, the lack of ATA DMA support is IMHO probably the biggest >> issue for the FreeBSD on PowerMacs now. The hardware is very >> attractive for SOHO applications, so that having this feature is >> important. > Right now, modes up to WDMA2 work. The UDMA modes cause hangs for > reasons not entirely clear. I'm investigating it, but am in the > Netherlands at the moment and it will have to wait until I get back. I now have UDMA modes working on my Shasta controller -- there was a stupid bug where I forgot to set the device to accept transfers in the selected mode. Please give this patch a test: I expect that UDMA modes now work everywhere. http://people.freebsd.org/~nwhitehorn/apple-ata-dma.patch -Nathan From grehan at freebsd.org Sun Sep 21 23:21:50 2008 From: grehan at freebsd.org (Peter Grehan) Date: Sun Sep 21 23:21:53 2008 Subject: ZFS .. on PowerPC ? In-Reply-To: References: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48D2F238.7070102@freebsd.org> Message-ID: <48D6D6EE.2050701@freebsd.org> Hi Niels, > Is this possible to do for a non-progamming guy.... in other (layman's) > words ... is there a howto for this ? Not yet since you are the trailblazer :) I just verified that the zfs and opensolaris kernel modules build fine on powerpc. You could manually build them, load zfs, and then see how it goes (if it gets that far). later, Peter. From tinderbox at freebsd.org Mon Sep 22 02:05:32 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Sep 22 02:05:45 2008 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20080922020528.71A7B73039@freebsd-current.sentex.ca> TB --- 2008-09-22 01:03:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-22 01:03:56 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-09-22 01:03:56 - cleaning the object tree TB --- 2008-09-22 01:04:27 - cvsupping the source tree TB --- 2008-09-22 01:04:27 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-09-22 01:04:33 - building world (CFLAGS=-O -pipe) TB --- 2008-09-22 01:04:33 - cd /src TB --- 2008-09-22 01:04:33 - /usr/bin/make -B buildworld >>> World build started on Mon Sep 22 01:04:35 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipresend/../../../sys -I/src/sbin/ipf/ipresend/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o /obj/powerpc/src/sbin/ipf/ipresend/../libipf/libipf.a -lkvm gzip -cn /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/ipresend.1 > ipresend.1.gz ===> sbin/ipfw (all) cc -O -pipe -fstack-protector -Wno-pointer-sign -c /src/sbin/ipfw/ipfw2.c /src/sbin/ipfw/ipfw2.c: In function 'table_handler': /src/sbin/ipfw/ipfw2.c:5877: error: 'a' undeclared (first use in this function) /src/sbin/ipfw/ipfw2.c:5877: error: (Each undeclared identifier is reported only once /src/sbin/ipfw/ipfw2.c:5877: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/ipfw. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-22 02:05:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-22 02:05:28 - ERROR: failed to build world TB --- 2008-09-22 02:05:28 - tinderbox aborted TB --- 2673.00 user 321.80 system 3691.58 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From grehan at freebsd.org Mon Sep 22 08:25:08 2008 From: grehan at freebsd.org (Peter Grehan) Date: Mon Sep 22 08:25:12 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48D69679.1080701@freebsd.org> References: "b9c23c9f0809100322n1659cb36oa05acf2f13f3c7e1@mail.gmail.com" <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> Message-ID: <48D7565F.5060108@freebsd.org> Hi Nathan, > http://people.freebsd.org/~nwhitehorn/apple-ata-dma.patch Boots fine and at least GEOM-probes at UDMA66 in the ata-4 iMac. Just need to wipe out the lock-order reversals and do some more testing. So, good progress :) later, Peter. From nse at delfi-konsult.com Mon Sep 22 09:15:29 2008 From: nse at delfi-konsult.com (Niels S. Eliasen) Date: Mon Sep 22 09:15:32 2008 Subject: ZFS .. on PowerPC ? In-Reply-To: <48D6D6EE.2050701@freebsd.org> References: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48D2F238.7070102@freebsd.org> <48D6D6EE.2050701@freebsd.org> Message-ID: Hi Peter Den 22/09/2008 kl. 01.21 skrev Peter Grehan: > Hi Niels, > >> Is this possible to do for a non-progamming guy.... in other >> (layman's) words ... is there a howto for this ? > > Not yet since you are the trailblazer :) hmm...that's a first! ;-) > > > I just verified that the zfs and opensolaris kernel modules build > fine on powerpc. You could manually build them, load zfs, and then > see how it goes (if it gets that far). ok... I'll have a go at this.... > > > later, > > Peter. kind regards nse "Ach, crivens, what a wee snotter....." Quote from "The Wee Free Men" by Terry Pratchett From bugmaster at FreeBSD.org Mon Sep 22 11:07:00 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 22 11:07:34 2008 Subject: Current problem reports assigned to freebsd-ppc@FreeBSD.org Message-ID: <200809221107.m8MB708s015466@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- a power/121407 ppc [panic] Won't boot up; strange error message. o power/112435 ppc [nexus] [patch] Update nexus children to use ofw_bus f o power/111296 ppc [kernel] [patch] [request] Support IMISS, DLMISS an DS o power/93203 ppc FreeBSD PPC Can't Write to Partitions. 4 problems total. From sobomax at FreeBSD.org Mon Sep 22 19:38:33 2008 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Mon Sep 22 19:38:35 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48D69679.1080701@freebsd.org> References: "b9c23c9f0809100322n1659cb36oa05acf2f13f3c7e1@mail.gmail.com" <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> Message-ID: <48D7F437.1040603@FreeBSD.org> Nathan Whitehorn wrote: > Nathan Whitehorn wrote: >> Maxim Sobolev wrote: >>> Nathan, >>> >>> Do you have any news regarding the patch in question? I hope you did >>> not give up, the lack of ATA DMA support is IMHO probably the biggest >>> issue for the FreeBSD on PowerMacs now. The hardware is very >>> attractive for SOHO applications, so that having this feature is >>> important. >> Right now, modes up to WDMA2 work. The UDMA modes cause hangs for >> reasons not entirely clear. I'm investigating it, but am in the >> Netherlands at the moment and it will have to wait until I get back. > > I now have UDMA modes working on my Shasta controller -- there was a > stupid bug where I forgot to set the device to accept transfers in the > selected mode. Please give this patch a test: I expect that UDMA modes > now work everywhere. > > http://people.freebsd.org/~nwhitehorn/apple-ata-dma.patch Nathan, The patch works here (G4 Mac Mini, 1.25GHz), however, I see some weird things happening in the interrupt domain. Particularly, according to the vmstat(8) ata0 device, which has no disks attached to it, generates large number of interrupts, about 1,500 in the idle state when no disk activity is in progress, and more than 100K (sic!) when I am running buildworld. At the same time, ata1 doesn't generate any interrupts at all. As a result, the system spends half of its time servicing those interrupts, so that UDMA mode is not very usable yet. See 341.png screenshot. Dmesg is below: ata0 mem 0x20000-0x20fff,0x8800-0x88ff irq 24,12 on macio0 ata0: [ITHREAD] ata0: [ITHREAD] ata1: mem 0xf5004000-0xf5007fff irq 39,1 at device 13.0 on pci2 ata1: [ITHREAD] ad0: 38154MB at ata1-master UDMA100 acd0: DVDR at ata1-slave UDMA33 I was able to "fix" the problem by making ata_macio probe function returning ENXIO always. My guess is that ATA chipset on this machine is somehow accessible through two different buses (macio and pci), which creates some weird conflicts, but I might be wrong. Hopefully you will have better idea, I can provide any assistance needed to fix the issue properly. See 342.png screenshot. Dmesg with hacked ata_macio is as follows: ata0: mem 0xf5004000-0xf5007fff irq 39,1 at device 13.0 on pci2 ata0: [ITHREAD] ad0: 38154MB at ata0-master UDMA100 acd0: DVDR at ata0-slave UDMA33 I should also mention that second boot of 8.0 kernel has fixed that time offset issue. Therefore, it seems that the 7.1 kernel doesn't sync RTC timer to current time correctly. Thanks, please keep doing. I look forward to seeing your work going to the main tree. -Maxim From sobomax at FreeBSD.org Mon Sep 22 19:56:43 2008 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Mon Sep 22 19:56:46 2008 Subject: HowTo: Install freebsd-ppc on a g4 mac mini? Message-ID: <48D7F86F.4010906@FreeBSD.org> > This is straight from memory and some notes. AFAIR you can drop boot.tbxi and > use loader directly - can't say for sure as I had to reinstall Mac OS for > some tests on my Cubes. Don't do that. If you drop boot.tbxi and use loader directly then you won't get any output from the loader on the console unless you drop into the OF first. I've spend quite some few days ago until I've figured it out. Also, on some machines boot-command should be left at mac-boot, as setting it to just "boot" results in boot failure (black screen and no progress whatsoever). -Maxim From nwhitehorn at freebsd.org Mon Sep 22 21:28:06 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Mon Sep 22 21:28:08 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48D7F437.1040603@FreeBSD.org> References: "b9c23c9f0809100322n1659cb36oa05acf2f13f3c7e1@mail.gmail.com" <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org> Message-ID: <48D80DDD.2080309@freebsd.org> Maxim Sobolev wrote: >> >> I now have UDMA modes working on my Shasta controller -- there was a >> stupid bug where I forgot to set the device to accept transfers in >> the selected mode. Please give this patch a test: I expect that UDMA >> modes now work everywhere. >> >> http://people.freebsd.org/~nwhitehorn/apple-ata-dma.patch > > Nathan, > > The patch works here (G4 Mac Mini, 1.25GHz), however, I see some weird > things happening in the interrupt domain. Particularly, according to > the vmstat(8) ata0 device, which has no disks attached to it, > generates large number of interrupts, about 1,500 in the idle state > when no disk activity is in progress, and more than 100K (sic!) when I > am running buildworld. At the same time, ata1 doesn't generate any > interrupts at all. As a result, the system spends half of its time > servicing those interrupts, so that UDMA mode is not very usable yet. > See 341.png screenshot. Dmesg is below: Thanks for testing! So ata1 generates no interrupts? Or does it just generate a number << ata0? > I was able to "fix" the problem by making ata_macio probe function > returning ENXIO always. My guess is that ATA chipset on this machine > is somehow accessible through two different buses (macio and pci), > which creates some weird conflicts, but I might be wrong. Hopefully > you will have better idea, I can provide any assistance needed to fix > the issue properly. See 342.png screenshot. Dmesg with hacked > ata_macio is as follows: Interesting -- it looks like all the interrupts are arriving on the second (DBDMA) IRQ. Could you try setting USE_DBDMA_IRQ to 0 in ata_macio.c and re-enabling ata_macio? There is something funny with how these interrupts are triggered currently and they can set off interrupt storms like this. -Nathan From sobomax at FreeBSD.org Mon Sep 22 22:13:02 2008 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Mon Sep 22 22:13:04 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48D80DDD.2080309@freebsd.org> References: "b9c23c9f0809100322n1659cb36oa05acf2f13f3c7e1@mail.gmail.com" <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org> <48D80DDD.2080309@freebsd.org> Message-ID: <48D8186F.4020308@FreeBSD.org> Nathan Whitehorn wrote: > Maxim Sobolev wrote: >>> >>> I now have UDMA modes working on my Shasta controller -- there was a >>> stupid bug where I forgot to set the device to accept transfers in >>> the selected mode. Please give this patch a test: I expect that UDMA >>> modes now work everywhere. >>> >>> http://people.freebsd.org/~nwhitehorn/apple-ata-dma.patch >> >> Nathan, >> >> The patch works here (G4 Mac Mini, 1.25GHz), however, I see some weird >> things happening in the interrupt domain. Particularly, according to >> the vmstat(8) ata0 device, which has no disks attached to it, >> generates large number of interrupts, about 1,500 in the idle state >> when no disk activity is in progress, and more than 100K (sic!) when I >> am running buildworld. At the same time, ata1 doesn't generate any >> interrupts at all. As a result, the system spends half of its time >> servicing those interrupts, so that UDMA mode is not very usable yet. >> See 341.png screenshot. Dmesg is below: > Thanks for testing! So ata1 generates no interrupts? Or does it just > generate a number << ata0? I have looked at the vmstat output closely and it appears that ata1 actually generates interrupts, just much less number of them than ata0. In fact I think that number if interrupts generated by ata1 during buildworld is roughly the same with or without ata_macio enabled. >> I was able to "fix" the problem by making ata_macio probe function >> returning ENXIO always. My guess is that ATA chipset on this machine >> is somehow accessible through two different buses (macio and pci), >> which creates some weird conflicts, but I might be wrong. Hopefully >> you will have better idea, I can provide any assistance needed to fix >> the issue properly. See 342.png screenshot. Dmesg with hacked >> ata_macio is as follows: > Interesting -- it looks like all the interrupts are arriving on the > second (DBDMA) IRQ. Could you try setting USE_DBDMA_IRQ to 0 in > ata_macio.c and re-enabling ata_macio? There is something funny with how > these interrupts are triggered currently and they can set off interrupt > storms like this. I've done that, but it has not changed anything. I still see interrupt storm on irq 12. Please let me know if you want me to make any other changes and re-test. -Maxim From marcotrillo at gmail.com Mon Sep 22 22:49:40 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Mon Sep 22 22:49:43 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48D8186F.4020308@FreeBSD.org> References: <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org> <48D80DDD.2080309@freebsd.org> <48D8186F.4020308@FreeBSD.org> Message-ID: Hi, On Tue, Sep 23, 2008 at 12:13 AM, Maxim Sobolev wrote: >>> I was able to "fix" the problem by making ata_macio probe function >>> returning ENXIO always. My guess is that ATA chipset on this machine is >>> somehow accessible through two different buses (macio and pci), which >>> creates some weird conflicts, but I might be wrong. Hopefully you will have >>> better idea, I can provide any assistance needed to fix the issue properly. >>> See 342.png screenshot. Dmesg with hacked ata_macio is as follows: >> >> Interesting -- it looks like all the interrupts are arriving on the second >> (DBDMA) IRQ. Could you try setting USE_DBDMA_IRQ to 0 in ata_macio.c and >> re-enabling ata_macio? There is something funny with how these interrupts >> are triggered currently and they can set off interrupt storms like this. > > I've done that, but it has not changed anything. I still see interrupt storm > on irq 12. Try deleting the USE_DBDMA_IRQ definition line from ata_macio.c instead of just defining it to 0, so the "ifdef USE_DBDMA_IRQ" stuff is not compiled. Hope that helps, Marco. From sobomax at FreeBSD.org Mon Sep 22 23:06:07 2008 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Mon Sep 22 23:06:09 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: References: <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org> <48D80DDD.2080309@freebsd.org> <48D8186F.4020308@FreeBSD.org> Message-ID: <48D824E1.1030109@FreeBSD.org> Marco Trillo wrote: > Hi, > > On Tue, Sep 23, 2008 at 12:13 AM, Maxim Sobolev wrote: >>>> I was able to "fix" the problem by making ata_macio probe function >>>> returning ENXIO always. My guess is that ATA chipset on this machine is >>>> somehow accessible through two different buses (macio and pci), which >>>> creates some weird conflicts, but I might be wrong. Hopefully you will have >>>> better idea, I can provide any assistance needed to fix the issue properly. >>>> See 342.png screenshot. Dmesg with hacked ata_macio is as follows: >>> Interesting -- it looks like all the interrupts are arriving on the second >>> (DBDMA) IRQ. Could you try setting USE_DBDMA_IRQ to 0 in ata_macio.c and >>> re-enabling ata_macio? There is something funny with how these interrupts >>> are triggered currently and they can set off interrupt storms like this. >> I've done that, but it has not changed anything. I still see interrupt storm >> on irq 12. > > Try deleting the USE_DBDMA_IRQ definition line from ata_macio.c > instead of just defining it to 0, so the "ifdef USE_DBDMA_IRQ" stuff > is not compiled. Yes, you are right. There are few unused variables in such case, though: cc1: warnings being treated as errors ../../../powerpc/powermac/ata_macio.c: In function 'ata_macio_attach': ../../../powerpc/powermac/ata_macio.c:206: warning: unused variable 'cookie' ../../../powerpc/powermac/ata_macio.c:205: warning: unused variable 'dbdma_irq' ../../../powerpc/powermac/ata_macio.c:204: warning: unused variable 'dbdma_irq_rid' *** Error code 1 If I ifdef them the kernel compiles and when booted there interrupt storm no longer happens. ata0 mem 0x20000-0x20fff,0x8800-0x88ff irq 24,12 on macio0 ata0: [ITHREAD] ata1: mem 0xf5004000-0xf5007fff irq 39,1 at device 13.0 on pci2 ata1: [ITHREAD] ad0: 38154MB at ata1-master UDMA100 acd0: DVDR at ata1-slave UDMA33 Just curious, what's the purpose of that ata0? Is it real device or some compatibility shim? -Maxim From xcllnt at mac.com Tue Sep 23 00:11:51 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Sep 23 00:11:53 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48D7F437.1040603@FreeBSD.org> References: "b9c23c9f0809100322n1659cb36oa05acf2f13f3c7e1@mail.gmail.com" <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org> Message-ID: <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> On Sep 22, 2008, at 12:38 PM, Maxim Sobolev wrote: > Nathan Whitehorn wrote: >> Nathan Whitehorn wrote: >>> Maxim Sobolev wrote: >>>> Nathan, >>>> >>>> Do you have any news regarding the patch in question? I hope you >>>> did not give up, the lack of ATA DMA support is IMHO probably the >>>> biggest issue for the FreeBSD on PowerMacs now. The hardware is >>>> very attractive for SOHO applications, so that having this >>>> feature is important. >>> Right now, modes up to WDMA2 work. The UDMA modes cause hangs for >>> reasons not entirely clear. I'm investigating it, but am in the >>> Netherlands at the moment and it will have to wait until I get back. >> I now have UDMA modes working on my Shasta controller -- there was >> a stupid bug where I forgot to set the device to accept transfers >> in the selected mode. Please give this patch a test: I expect that >> UDMA modes now work everywhere. >> http://people.freebsd.org/~nwhitehorn/apple-ata-dma.patch > > Nathan, > > The patch works here (G4 Mac Mini, 1.25GHz), however, I see some > weird things happening in the interrupt domain. Interesting. My G4 Mac Mini 1.5Ghz is hanging hard: : ad0: 76319MB at ata1-master UDMA100 acd0: DVDR at ata1-slave UDMA33 *hang* Could be related... -- Marcel Moolenaar xcllnt@mac.com From nwhitehorn at freebsd.org Tue Sep 23 01:49:07 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Tue Sep 23 01:49:10 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> References: "b9c23c9f0809100322n1659cb36oa05acf2f13f3c7e1@mail.gmail.com" <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> Message-ID: <48D84C12.7070207@freebsd.org> Marcel Moolenaar wrote: > > On Sep 22, 2008, at 12:38 PM, Maxim Sobolev wrote: > >> Nathan Whitehorn wrote: >>> Nathan Whitehorn wrote: >>>> Maxim Sobolev wrote: >>>>> Nathan, >>>>> >>>>> Do you have any news regarding the patch in question? I hope you >>>>> did not give up, the lack of ATA DMA support is IMHO probably the >>>>> biggest issue for the FreeBSD on PowerMacs now. The hardware is >>>>> very attractive for SOHO applications, so that having this feature >>>>> is important. >>>> Right now, modes up to WDMA2 work. The UDMA modes cause hangs for >>>> reasons not entirely clear. I'm investigating it, but am in the >>>> Netherlands at the moment and it will have to wait until I get back. >>> I now have UDMA modes working on my Shasta controller -- there was a >>> stupid bug where I forgot to set the device to accept transfers in >>> the selected mode. Please give this patch a test: I expect that UDMA >>> modes now work everywhere. >>> http://people.freebsd.org/~nwhitehorn/apple-ata-dma.patch >> >> Nathan, >> >> The patch works here (G4 Mac Mini, 1.25GHz), however, I see some weird >> things happening in the interrupt domain. > > Interesting. My G4 Mac Mini 1.5Ghz is hanging hard: > > : > ad0: 76319MB at ata1-master UDMA100 > acd0: DVDR at ata1-slave UDMA33 > *hang* > > Could be related... > If it is, removing the USE_DBDMA_IRQ stuff in ata_macio.c should solve it. This might solve Peter's problem too. -Nathan From marcotrillo at gmail.com Tue Sep 23 10:55:23 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Tue Sep 23 10:55:41 2008 Subject: 8.0-current 200809 snapshot CD boot problem Message-ID: Hi all, I tried booting the latest 200809 snapshot CD, from Sep 10, (8.0-CURRENT-200809-powerpc-bootonly.iso), on a eMac G4 "USB 2.0" (PowerMac6,4). It fails with an "invalid memory access": Booting [/boot/kernel/kernel] ... Kernel entry at 0x100100 ... Invalid memory access at %SRR0: 00100100 %SRR1: 10003030 ok 0> I tried booting by pressing "C" or by "boot cd:,\boot\loader cd:0" several times with the same result, but one time I got a "Decrementer exception" instead of "Invalid memory access". Then I tried the latest 7.1_BETA snapshot and it booted fine! In fact it's installing right now without problems. Thanks, Marco. From marcotrillo at gmail.com Tue Sep 23 16:52:59 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Tue Sep 23 16:53:02 2008 Subject: 8.0-current 200809 snapshot CD boot problem In-Reply-To: References: Message-ID: Hi, On Tue, Sep 23, 2008 at 12:55 PM, Marco Trillo wrote: > I tried booting the latest 200809 snapshot CD, from Sep 10, > (8.0-CURRENT-200809-powerpc-bootonly.iso), on a eMac G4 "USB 2.0" > (PowerMac6,4). It fails with an "invalid memory access": > > Booting [/boot/kernel/kernel] ... > Kernel entry at 0x100100 ... > > Invalid memory access at %SRR0: 00100100 %SRR1: 10003030 > > ok > 0> I compiled a -current kernel from the 7.1_BETA installation and tried to boot it (from the hard disk), but the same error occurs. The 7.1_BETA kernel always boots fine. Any ideas? Thanks. From marcotrillo at gmail.com Tue Sep 23 17:28:47 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Tue Sep 23 17:28:49 2008 Subject: 8.0-current 200809 snapshot CD boot problem In-Reply-To: References: Message-ID: Hi, On Tue, Sep 23, 2008 at 6:52 PM, Marco Trillo wrote: > On Tue, Sep 23, 2008 at 12:55 PM, Marco Trillo wrote: >> I tried booting the latest 200809 snapshot CD, from Sep 10, >> (8.0-CURRENT-200809-powerpc-bootonly.iso), on a eMac G4 "USB 2.0" >> (PowerMac6,4). It fails with an "invalid memory access": >> >> Booting [/boot/kernel/kernel] ... >> Kernel entry at 0x100100 ... >> >> Invalid memory access at %SRR0: 00100100 %SRR1: 10003030 >> >> ok >> 0> > > I compiled a -current kernel from the 7.1_BETA installation and tried > to boot it (from the hard disk), but the same error occurs. The > 7.1_BETA kernel always boots fine. Well, I finally have a working 8.0-current kernel! :-) But something weird is going on here: I noticed a difference in the kernel __start address between the working 7.0_BETA kernel (kernel.old) and the broken 8.0-current kernel (kernel): ./boot/kernel.old/kernel: file format elf32-powerpc Disassembly of section .text: 0013d3c0 <__start>: 13d3c0: 39 00 00 00 li r8,0 ./boot/kernel/kernel: file format elf32-powerpc Disassembly of section .text: 00100100 <__start>: 100100: 39 00 00 00 li r8,0 I noticed revision 1.8 of src/sys/conf/ldscript.powerpc was related to this, so I downgraded ldscript.powerpc to revision 1.7 and relinked the kernel. And it works! No more "invalid memory access"! I don't know if this is something weird of my setup. Should I file a PR? The full 8.0-current dmesg is below. Copyright (c) 1992-2008 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #1: Tue Sep 23 17:05:10 UTC 2008 mtrillo@emac6:/usr/src/sys/powerpc/compile/GENERIC WARNING: WITNESS option enabled, expect reduced performance. cpu0: Motorola PowerPC 7447A revision 1.1, 1250.00 MHz cpu0: HID0 8450c0bc real memory = 793313280 (756 MB) avail memory = 762892288 (727 MB) kbd0 at kbdmux0 nexus0: unin0: on nexus0 unin0: Version 210 pcib0: on nexus0 pci0: on pcib0 vgapci0: port 0x400-0x4ff mem 0x98000000-0x9fffffff,0x90000000-0x9000ffff irq 48 at device 16.0 on pci0 pcib1: on nexus0 pci1: on pcib1 macio0: mem 0x80000000-0x8007ffff at device 23.0 on pci1 openpic0: mem 0x40000-0x7ffff on macio0 scc0: mem 0x13000-0x13fff,0x8400-0x84ff,0x8500-0x85ff,0x8600-0x86ff,0x8700-0x87ff irq 22,5,6,23,7,8 on macio0 scc0: [FILTER] scc0: [FILTER] uart0: on scc0 uart0: [FILTER] uart1: on scc0 uart1: [FILTER] ata0 mem 0x20000-0x20fff,0x8800-0x88ff irq 24,12 on macio0 ata0: [ITHREAD] ohci0: irq 0 at device 24.0 on pci1 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: irq 0 at device 25.0 on pci1 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0x80083000-0x80083fff irq 29 at device 26.0 on pci1 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: on ohci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ohci3: mem 0x80082000-0x80082fff irq 63 at device 27.0 on pci1 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb3: OHCI version 1.0 usb3: on ohci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 3 ports with 3 removable, self powered ohci4: mem 0x80081000-0x80081fff irq 63 at device 27.1 on pci1 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb4: OHCI version 1.0 usb4: on ohci4 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered ehci0: mem 0x80080000-0x800800ff irq 63 at device 27.2 on pci1 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 3 ports each: usb3 usb4 usb5: on ehci0 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 5 ports with 5 removable, self powered pcib2: on nexus0 pci2: on pcib2 ata1: mem 0xf5004000-0xf5007fff irq 39 at device 13.0 on pci2 ata1: [ITHREAD] fwohci0: mem 0xf5000000-0xf5000fff irq 40 at device 14.0 on pci2 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:0d:93:ff:fe:57:39:60 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:0d:93:57:39:60 fwe0: Ethernet address: 02:0d:93:57:39:60 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=2, CYCLEMASTER mode gem0: mem 0xf5200000-0xf53fffff irq 41 at device 15.0 on pci2 miibus0: on gem0 bmtphy0: PHY 0 on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto gem0: 10kB RX FIFO, 4kB TX FIFO gem0: Ethernet address: 00:0d:93:57:39:60 gem0: [ITHREAD] sc0: on nexus0 sc0: Unknown <16 virtual consoles, flags=0x300> uhub6: on uhub3 uhub6: 3 ports with 2 removable, bus powered ums0: on uhub6 ums0: 1 buttons. ukbd0: on uhub6 kbd1 at ukbd0 uhid0: on uhub6 Timecounter "decrementer" frequency 41620997 Hz quality 0 Timecounters tick every 10.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acd0: DVDR at ata0-master BIOSPIO ad0: 38166MB at ata1-master BIOSPIO WARNING: WITNESS option enabled, expect reduced performance. acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00 GEOM_LABEL: Label for provider acd0 is iso9660/CDROM. acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00 acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00 acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00 Trying to mount root from ufs:/dev/ad0s4 lock order reversal: 1st 0xe3a000 vfslock (vfslock) @ kern/vfs_subr.c:372 2nd 0xdd9e2c devfs (devfs) @ kern/vfs_lookup.c:432 3rd 0xe39d48 vfslock (vfslock) @ kern/vfs_subr.c:372 KDB: stack backtrace: 0xdebaf848: at kdb_backtrace+0x4c 0xdebaf868: at _witness_debugger+0x3c 0xdebaf888: at witness_checkorder+0x878 0xdebaf8e8: at __lockmgr_args+0x23c 0xdebaf968: at vfs_busy+0x19c 0xdebaf998: at vfs_mount_alloc+0x80 0xdebaf9c8: at vfs_donmount+0xfe0 0xdebafb88: at kernel_mount+0x98 0xdebafbc8: at kernel_vmount+0xdc 0xdebafc18: at vfs_mountroot_try+0x120 0xdebafcd8: at vfs_mountroot+0x424 0xdebafd38: at start_init+0x88 0xdebafd98: at fork_exit+0xf0 0xdebafdc8: at fork_trampoline+0xc lock order reversal: 1st 0xdd99ec ufs (ufs) @ kern/vfs_subr.c:2051 2nd 0xe3a000 vfslock (vfslock) @ kern/vfs_subr.c:372 KDB: stack backtrace: 0xdebaf8c8: at kdb_backtrace+0x4c 0xdebaf8e8: at _witness_debugger+0x3c 0xdebaf908: at witness_checkorder+0x878 0xdebaf968: at __lockmgr_args+0x23c 0xdebaf9e8: at vfs_busy+0x19c 0xdebafa18: at lookup+0x86c 0xdebafaa8: at namei+0x4a8 0xdebafb38: at kern_unlinkat+0x98 0xdebafbf8: at kern_unlink+0x24 0xdebafc18: at vfs_mountroot_try+0x444 0xdebafcd8: at vfs_mountroot+0x424 0xdebafd38: at start_init+0x88 0xdebafd98: at fork_exit+0xf0 0xdebafdc8: at fork_trampoline+0xc lock order reversal: 1st 0xc41048 user map (user map) @ vm/vm_map.c:3115 2nd 0xdd97cc ufs (ufs) @ kern/vfs_subr.c:2051 KDB: stack backtrace: 0xdebaf930: at kdb_backtrace+0x4c 0xdebaf950: at _witness_debugger+0x3c 0xdebaf970: at witness_checkorder+0x878 0xdebaf9d0: at __lockmgr_args+0x23c 0xdebafa50: at ffs_lock+0x9c 0xdebafa80: at VOP_LOCK1_APV+0xec 0xdebafaa0: at _vn_lock+0x84 0xdebafaf0: at vget+0xdc 0xdebafb30: at vnode_pager_lock+0x20c 0xdebafb90: at vm_fault+0x218 0xdebafca0: at trap_pfault+0x128 0xdebafce0: at trap+0x1ac 0xdebafda0: at powerpc_interrupt+0x15c 0xdebafdd0: user ISI trap by 0x1815a04: srr1=0x4000d032 r1=0x7fffdee0 cr=0x24000048 xer=0 ctr=0 Thanks! Marco From xcllnt at mac.com Tue Sep 23 17:47:50 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Sep 23 17:47:53 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48D84C12.7070207@freebsd.org> References: "b9c23c9f0809100322n1659cb36oa05acf2f13f3c7e1@mail.gmail.com" <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> <48D84C12.7070207@freebsd.org> Message-ID: <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> On Sep 22, 2008, at 6:53 PM, Nathan Whitehorn wrote: > Marcel Moolenaar wrote: >> On Sep 22, 2008, at 12:38 PM, Maxim Sobolev wrote: >>> Nathan Whitehorn wrote: >>>> Nathan Whitehorn wrote: >>>>> Maxim Sobolev wrote: >>>>>> Nathan, >>>>>> >>>>>> Do you have any news regarding the patch in question? I hope >>>>>> you did not give up, the lack of ATA DMA support is IMHO >>>>>> probably the biggest issue for the FreeBSD on PowerMacs now. >>>>>> The hardware is very attractive for SOHO applications, so that >>>>>> having this feature is important. >>>>> Right now, modes up to WDMA2 work. The UDMA modes cause hangs >>>>> for reasons not entirely clear. I'm investigating it, but am in >>>>> the Netherlands at the moment and it will have to wait until I >>>>> get back. >>>> I now have UDMA modes working on my Shasta controller -- there >>>> was a stupid bug where I forgot to set the device to accept >>>> transfers in the selected mode. Please give this patch a test: I >>>> expect that UDMA modes now work everywhere. >>>> http://people.freebsd.org/~nwhitehorn/apple-ata-dma.patch >>> >>> Nathan, >>> >>> The patch works here (G4 Mac Mini, 1.25GHz), however, I see some >>> weird things happening in the interrupt domain. >> Interesting. My G4 Mac Mini 1.5Ghz is hanging hard: >> : >> ad0: 76319MB at ata1-master UDMA100 >> acd0: DVDR at ata1-slave UDMA33 >> *hang* >> Could be related... > > If it is, removing the USE_DBDMA_IRQ stuff in ata_macio.c should > solve it. This might solve Peter's problem too. It improves things, but it's still not good: ... ad0: 76319MB at ata1-master UDMA100 acd0: DVDR at ata1-slave UDMA33 WARNING: WITNESS option enabled, expect reduced performance. ... ad0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad0: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad0: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly ad0: WARNING - SET_MULTI taskqueue timeout - completing request directly acd0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly acd0: TIMEOUT - READ_BIG retrying (1 retry left) ad0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad0: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad0: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly ad0: WARNING - SET_MULTI taskqueue timeout - completing request directly acd0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly acd0: TIMEOUT - READ_BIG retrying (0 retries left) ad0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad0: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad0: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly ad0: WARNING - SET_MULTI taskqueue timeout - completing request directly acd0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly acd0: FAILURE - READ_BIG timed out ... Memory modified after free ... panic: Most recently used by none KDB: enter: panic db> db> show intrcnt irq63: ohci3 ohci+ 29 irq39: ata1 108501120 irq40: fwohci0 2 db> -- Marcel Moolenaar xcllnt@mac.com From nwhitehorn at freebsd.org Tue Sep 23 17:54:21 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Tue Sep 23 17:54:24 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> References: "b9c23c9f0809100322n1659cb36oa05acf2f13f3c7e1@mail.gmail.com" <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> <48D84C12.7070207@freebsd.org> <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> Message-ID: <48D92D44.6080807@freebsd.org> Marcel Moolenaar wrote: > > On Sep 22, 2008, at 6:53 PM, Nathan Whitehorn wrote: > >> Marcel Moolenaar wrote: >>> On Sep 22, 2008, at 12:38 PM, Maxim Sobolev wrote: >>>> Nathan Whitehorn wrote: >>>>> Nathan Whitehorn wrote: >>>>>> Maxim Sobolev wrote: >>>>>>> Nathan, >>>>>>> >>>>>>> Do you have any news regarding the patch in question? I hope you >>>>>>> did not give up, the lack of ATA DMA support is IMHO probably >>>>>>> the biggest issue for the FreeBSD on PowerMacs now. The hardware >>>>>>> is very attractive for SOHO applications, so that having this >>>>>>> feature is important. >>>>>> Right now, modes up to WDMA2 work. The UDMA modes cause hangs for >>>>>> reasons not entirely clear. I'm investigating it, but am in the >>>>>> Netherlands at the moment and it will have to wait until I get back. >>>>> I now have UDMA modes working on my Shasta controller -- there was >>>>> a stupid bug where I forgot to set the device to accept transfers >>>>> in the selected mode. Please give this patch a test: I expect that >>>>> UDMA modes now work everywhere. >>>>> http://people.freebsd.org/~nwhitehorn/apple-ata-dma.patch >>>> >>>> Nathan, >>>> >>>> The patch works here (G4 Mac Mini, 1.25GHz), however, I see some >>>> weird things happening in the interrupt domain. >>> Interesting. My G4 Mac Mini 1.5Ghz is hanging hard: >>> : >>> ad0: 76319MB at ata1-master UDMA100 >>> acd0: DVDR at ata1-slave UDMA33 >>> *hang* >>> Could be related... >> >> If it is, removing the USE_DBDMA_IRQ stuff in ata_macio.c should >> solve it. This might solve Peter's problem too. > > It improves things, but it's still not good: [Smacking forehead] The Kauai/MacIO controller cannot support multiple modes of the same class (DMA/PIO) simultaneously on the same bus for different devices. You have to reprogram the timing register whenever you select a new device... Ways to check if this is the problem: 1) Limit devices to UDMA33. 2) Disable DMA on acd0. Our ATA stack doesn't seem to support a hook for doing things on a device select, so I'm not sure how to fix this. -Nathan From marcotrillo at gmail.com Tue Sep 23 18:14:07 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Tue Sep 23 18:14:09 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48D92D44.6080807@freebsd.org> References: <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> <48D84C12.7070207@freebsd.org> <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> <48D92D44.6080807@freebsd.org> Message-ID: Hi, On Tue, Sep 23, 2008 at 7:54 PM, Nathan Whitehorn wrote: >> It improves things, but it's still not good: > > [Smacking forehead] > > The Kauai/MacIO controller cannot support multiple modes of the same class > (DMA/PIO) simultaneously on the same bus for different devices. You have to > reprogram the timing register whenever you select a new device... > > Ways to check if this is the problem: > 1) Limit devices to UDMA33. > 2) Disable DMA on acd0. > > Our ATA stack doesn't seem to support a hook for doing things on a device > select, so I'm not sure how to fix this. The NetBSD driver seems to solve this by configuring the timing register when starting the DMA transfer, but I'm not sure if this is the correct fix... Regards, Marco. From xcllnt at mac.com Wed Sep 24 00:39:27 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Sep 24 00:39:29 2008 Subject: ZFS race condition? Message-ID: <675B0620-77FE-4B99-AC98-C0002F8045F7@mac.com> I've started a little ZFS test on my SMP box to see how healthy it is and I ran into the following: VNASSERT failed 0: tag (null), type VNON usecount 1610614632, writecount 0, refcount 1006665672 mountedhere 0 flags (VV_ROOT|VV_TEXT|VV_DELETED|VV(0x4e800000)|VI_MOUNT| VI_DOOMED|VI_FREE|VI(0x7c090206)) lock type (null): EXCL by thread 0 (pid 0) panic: No vop_lock1(0, 0xe4a4682c) cpuid = 0 KDB: enter: panic Something (read: usecount and refcount) tells me that we may have a race condition... Anyone else playing with ZFS on PowerPC seeing this? -- Marcel Moolenaar xcllnt@mac.com From grehan at freebsd.org Wed Sep 24 00:47:52 2008 From: grehan at freebsd.org (Peter Grehan) Date: Wed Sep 24 00:47:54 2008 Subject: ZFS race condition? In-Reply-To: <675B0620-77FE-4B99-AC98-C0002F8045F7@mac.com> References: <675B0620-77FE-4B99-AC98-C0002F8045F7@mac.com> Message-ID: <48D98E2C.1090606@freebsd.org> Hi Marcel, > Anyone else playing with ZFS on PowerPC seeing this? It's on my todo list but you're a long way ahead of me :) You could try the 'null' stwcx in the context switch asm to flush any pending reservations - I think I may have sent you mail about this a long while back. This may result in two sections of code both thinking they have a lock. later, Peter. From xcllnt at mac.com Wed Sep 24 00:58:30 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Sep 24 00:58:31 2008 Subject: ZFS race condition? In-Reply-To: <48D98E2C.1090606@freebsd.org> References: <675B0620-77FE-4B99-AC98-C0002F8045F7@mac.com> <48D98E2C.1090606@freebsd.org> Message-ID: On Sep 23, 2008, at 5:47 PM, Peter Grehan wrote: > Hi Marcel, > >> Anyone else playing with ZFS on PowerPC seeing this? > > It's on my todo list but you're a long way ahead of me :) I just happened to have a disk that I could use (one I use only for the release builds)... > You could try the 'null' stwcx in the context switch asm to flush > any pending reservations - I think I may have sent you mail about > this a long while back. This may result in two sections of code both > thinking they have a lock. Good call. I looked at that as part of the SMP work, but forgot about it already... Thanks, -- Marcel Moolenaar xcllnt@mac.com From raj at semihalf.com Wed Sep 24 10:00:05 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Wed Sep 24 10:00:11 2008 Subject: [AIM] SMP now working In-Reply-To: <2C9F58FE-30CA-4DF0-B739-A7B70F7DC181@mac.com> References: <2A84850D-B205-472A-BC5B-471F2817BC7B@mac.com> <48D019AC.2040409@freebsd.org> <2C9F58FE-30CA-4DF0-B739-A7B70F7DC181@mac.com> Message-ID: <48DA092F.9010008@semihalf.com> Marcel Moolenaar wrote: > There's a visible speedup, so things look good. I hope to have > hard data next week or so. > > Random notes: > o It should be safe to enable interrupt delivery to all CPUs > and play around with programming the TPR of the CPUs. > o SMP works with 4BSD only, but raj@ just told me he has ULE > support for SMP. Hi Marcel, Please find my original changes that made ULE work on the MPC8572 (dual e500): http://people.freebsd.org/~raj/patches/powerpc/ule/ Let me know how it goes on AIM. (Beware of some regs usage rearanngements along the strict ULE changes..) Rafal From marcotrillo at gmail.com Wed Sep 24 10:38:28 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Wed Sep 24 10:38:31 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48D92D44.6080807@freebsd.org> References: <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> <48D84C12.7070207@freebsd.org> <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> <48D92D44.6080807@freebsd.org> Message-ID: Hi Nathan, I tested the patch on a eMac G4 "USB 2.0" (PowerMac6,4). It has an ata-3 macio cell and a Kauai controller. acd0: DVDR at ata0-master WDMA2 ad0: 38166MB at ata1-master UDMA100 WARNING: WITNESS option enabled, expect reduced performance. acd0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly acd0: TIMEOUT - READ_BIG retrying (1 retry left) acd0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly acd0: TIMEOUT - READ_BIG retrying (0 retries left) acd0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly acd0: FAILURE - READ_BIG timed out ... And then the same cycle starts again. This looks similar to the problems Marcel reported, but in this case the Kauai controller only has one device attached, the hard disk; as the CD drive is on the ata-3 macio controller instead. Thanks, Marco. From nwhitehorn at freebsd.org Wed Sep 24 13:23:07 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Wed Sep 24 13:23:09 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: References: <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> <48D84C12.7070207@freebsd.org> <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> <48D92D44.6080807@freebsd.org> Message-ID: <48DA4037.9000508@freebsd.org> Marco Trillo wrote: > Hi Nathan, > > I tested the patch on a eMac G4 "USB 2.0" (PowerMac6,4). It has an ata-3 macio cell and a Kauai controller. > > acd0: DVDR at ata0-master WDMA2 > ad0: 38166MB at ata1-master UDMA100 > WARNING: WITNESS option enabled, expect reduced performance. > acd0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > acd0: TIMEOUT - READ_BIG retrying (1 retry left) > acd0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > acd0: TIMEOUT - READ_BIG retrying (0 retries left) > acd0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > acd0: FAILURE - READ_BIG timed out > ... > And then the same cycle starts again. > > This looks similar to the problems Marcel reported, but in this case the Kauai controller only has one device attached, the hard disk; as the CD drive is on the ata-3 macio controller instead. Ugh. I really don't know, and am flying blind without hardware. If you disable ATAPI DMA or the macio controller, does ad0 at least work? -Nathan From marcotrillo at gmail.com Wed Sep 24 13:32:06 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Wed Sep 24 13:32:07 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48DA4037.9000508@freebsd.org> References: <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> <48D84C12.7070207@freebsd.org> <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> <48D92D44.6080807@freebsd.org> <48DA4037.9000508@freebsd.org> Message-ID: Hi, On Wed, Sep 24, 2008 at 3:27 PM, Nathan Whitehorn wrote: > > Ugh. I really don't know, and am flying blind without hardware. If you > disable ATAPI DMA or the macio controller, does ad0 at least work? > -Nathan > I reverted the ata_macio.c patch and now Kauai uses DMA just fine! ad0 now works in UDMA100 mode without any errors :-) ata0 mem 0x20000-0x20fff,0x8800-0x88ff irq 24,12 on macio0 ata0: [ITHREAD] ata1: mem 0xf5004000-0xf5007fff irq 39,1 at device 13.0 on pci2 ata1: [ITHREAD] acd0: DVDR at ata0-master BIOSPIO ad0: 38166MB at ata1-master UDMA100 And indeed the ad0 disk performance is much better. Thank you! So it looks like an ata_macio specific problem. Regards, Marco. From raj at semihalf.com Wed Sep 24 18:20:20 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Wed Sep 24 18:20:24 2008 Subject: 64-bit atomic ops on 32-bit CPU -- was: ZFS .. on PowerPC ? In-Reply-To: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> References: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> Message-ID: <48DA84D5.4010109@semihalf.com> Marcel Moolenaar wrote: > ZFS requires 64-bit atomic operations, which > PowerPC doesn't have. So, we can't build the Hi Marcel, These are my [long overdue, sorry :-)] notes regarding 64-bit ops on the 32-bit machine. My concept is based on the fact that the reservation granule is cache-line size e.g. on Book-E CPU this is 32 bytes (8 words). With this assumption you can have a 64-bit atomic operation like the following: a.) make sure the whole granule is dedicated for a single object we want atomic access to, i.e. in case of a 64-bit object we would use only 2 words out of 8 in the given granule and the remaining 6 would be wasted b.) assume our 64-bit object uses word (W1) and word 2 (W2) within the given granule Atomic store skeleton (pseudo asm, but you'll get the idea): 1. lwarx W1 2. stw W2 This regular (non-stwcx) store issued from local CPU will not clear our reservation on this granule (only external CPUs or other entities' stores within this granule can clear it) 3. stwcx W1, goto p.1 if not succeeded I have implementated the above scheme for e500 SMP purposes (atomic access to 3- or more word objects) and it's working fine in my environment where the atomic objects are allocated and managed "manually". The problem with this, however, is general-purpose applications like in ZFS, when there's no direct control over the atomic objects. I don't know how to ensure (in a transparent way) that ZFS (or whatever consumer of atomic_cmpset_64() and friends) put all words of the compound atomic object within one granule, which is a requirement here... Comments? Rafal From xcllnt at mac.com Wed Sep 24 19:30:29 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Sep 24 19:30:31 2008 Subject: 64-bit atomic ops on 32-bit CPU -- was: ZFS .. on PowerPC ? In-Reply-To: <48DA84D5.4010109@semihalf.com> References: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48DA84D5.4010109@semihalf.com> Message-ID: On Sep 24, 2008, at 11:20 AM, Rafal Jaworowski wrote: > a.) make sure the whole granule is dedicated for a single object we > want > atomic access to, i.e. in case of a 64-bit object we would use only > 2 words > out of 8 in the given granule and the remaining 6 would be wasted Is this required for correctness? I can see that it is desirable for performance, but I don't think it's needed for correctness. Can you elaborate? > b.) assume our 64-bit object uses word (W1) and word 2 (W2) within > the given > granule Right. This means that 64-bit integrals (i.e. [u]int64_t) should at least be 64-bit aligned. Otherwise you can cross the granule boundary. > Atomic store skeleton (pseudo asm, but you'll get the idea): > > 1. lwarx W1 > > 2. stw W2 > This regular (non-stwcx) store issued from local CPU will not clear > our > reservation on this granule (only external CPUs or other entities' > stores > within this granule can clear it) > > 3. stwcx W1, goto p.1 if not succeeded I don't see a read of W2. In particular, we clobber W2 unconditionally, so we must guarantee that we always read the correct value of W2. Can you elaborate on how an increment would be made atomic? -- Marcel Moolenaar xcllnt@mac.com From raj at semihalf.com Wed Sep 24 19:50:24 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Wed Sep 24 19:50:26 2008 Subject: 64-bit atomic ops on 32-bit CPU -- was: ZFS .. on PowerPC ? In-Reply-To: References: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48DA84D5.4010109@semihalf.com> Message-ID: <48DA99F8.7070904@semihalf.com> Marcel Moolenaar wrote: >> a.) make sure the whole granule is dedicated for a single object we want >> atomic access to, i.e. in case of a 64-bit object we would use only 2 >> words >> out of 8 in the given granule and the remaining 6 would be wasted > > Is this required for correctness? I can see that it is > desirable for performance, but I don't think it's needed > for correctness. Can you elaborate? Having a dedicated granule for the object is not requirement. If this is not met the reservation may be lost gratuitously due to other stores which might happen within this granule (issued by other CPUs, and/or other threads on local CPU doing stwcx in this granule). So this is would hit performance, as you note, but the scheme would work still. The strict requirement is having all words of the compound atomic object within the same granule. >> Atomic store skeleton (pseudo asm, but you'll get the idea): >> >> 1. lwarx W1 >> >> 2. stw W2 >> This regular (non-stwcx) store issued from local CPU will not clear our >> reservation on this granule (only external CPUs or other entities' stores >> within this granule can clear it) >> >> 3. stwcx W1, goto p.1 if not succeeded > > I don't see a read of W2. In particular, we clobber W2 > unconditionally, so we must guarantee that we always > read the correct value of W2. Can you elaborate on how > an increment would be made atomic? This was an example of an atomic write when we don't care about the previous state (there, the initial lwarx is only needed for obtaining the reservation). Atomic increment would be like this: 1. lwarx W1 2. lwz W2 3. In-register increment/other modification 4. stw W2 (modified) Neither 2. nor 3 issued from local CPU will not clear our reservation on this granule. (optionally increment/modify in-register value of W1) 5. stwcx W1, goto p.1 if not succeeded If non-local CPU (or any other bus master) modifies anything within the considered granule after we obtained the reservation in 1., the last stwcx will fail and we'll loop again. Rafal From xcllnt at mac.com Wed Sep 24 21:07:09 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Sep 24 21:07:16 2008 Subject: 64-bit atomic ops on 32-bit CPU -- was: ZFS .. on PowerPC ? In-Reply-To: <48DA99F8.7070904@semihalf.com> References: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48DA84D5.4010109@semihalf.com> <48DA99F8.7070904@semihalf.com> Message-ID: <111399E3-2BC7-4724-8AFB-A40F2A47E66D@mac.com> On Sep 24, 2008, at 12:50 PM, Rafal Jaworowski wrote: > The strict requirement is having all words of the compound atomic > object > within the same granule. I agree. >>> Atomic store skeleton (pseudo asm, but you'll get the idea): >>> >>> 1. lwarx W1 >>> >>> 2. stw W2 >>> This regular (non-stwcx) store issued from local CPU will not >>> clear our >>> reservation on this granule (only external CPUs or other entities' >>> stores >>> within this granule can clear it) >>> >>> 3. stwcx W1, goto p.1 if not succeeded >> >> I don't see a read of W2. In particular, we clobber W2 >> unconditionally, so we must guarantee that we always >> read the correct value of W2. Can you elaborate on how >> an increment would be made atomic? > > This was an example of an atomic write when we don't care about the > previous > state (there, the initial lwarx is only needed for obtaining the > reservation). > > Atomic increment would be like this: > 1. lwarx W1 > > 2. lwz W2 > 3. In-register increment/other modification > 4. stw W2 (modified) > Neither 2. nor 3 issued from local CPU will not clear our > reservation on this > granule. > > (optionally increment/modify in-register value of W1) > 5. stwcx W1, goto p.1 if not succeeded Ok. Let's assume we lose the reservation and we're forced to loop and try again. Step 2 then reads W2, which on a retry is the word written in step 4. As such, if we have to loop and retry X times, then the atomic increment would increment by X and not 1. I don't think an unconditional write to W2 will work if we don't preserve the origional value of W2. -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Wed Sep 24 22:11:10 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Sep 24 22:11:16 2008 Subject: 64-bit atomic ops on 32-bit CPU -- was: ZFS .. on PowerPC ? In-Reply-To: <111399E3-2BC7-4724-8AFB-A40F2A47E66D@mac.com> References: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48DA84D5.4010109@semihalf.com> <48DA99F8.7070904@semihalf.com> <111399E3-2BC7-4724-8AFB-A40F2A47E66D@mac.com> Message-ID: <2AD479FA-794C-421A-AF53-C10BBF0826DC@mac.com> On Sep 24, 2008, at 2:07 PM, Marcel Moolenaar wrote: > Ok. Let's assume we lose the reservation and we're > forced to loop and try again. Step 2 then reads W2, > which on a retry is the word written in step 4. As > such, if we have to loop and retry X times, then > the atomic increment would increment by X and not > 1. > > I don't think an unconditional write to W2 will > work if we don't preserve the origional value of > W2. What about the following algorithm: /* Atomically read 64-bit entity. */ 1: lwarx P[0] ldw P[1] stwcx P[0] b.fail 1 /* Perform operation on 64-bit entity. */ {Q[0],Q[1]} = operation({P[0],P[1]}) /* * Pseudo-atomically write 64-bit value. * The 64-bit entity may have been clobbered * by this time. */ lwarx t[0] ldw t[1] cmp t[0],P[0] b.ne 1 cmp t[1],P[1] b.ne 1 stw Q[1] stwcx Q[0] b.ok 2 stw P[1] b 1 2: sync ret Interrupts should be disabled to minimize the time the 64-bit entity is inconsistent WRT non-atomic reads. Thoughts? -- Marcel Moolenaar xcllnt@mac.com From raj at semihalf.com Thu Sep 25 17:08:48 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Thu Sep 25 17:08:55 2008 Subject: 64-bit atomic ops on 32-bit CPU -- was: ZFS .. on PowerPC ? In-Reply-To: <111399E3-2BC7-4724-8AFB-A40F2A47E66D@mac.com> References: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48DA84D5.4010109@semihalf.com> <48DA99F8.7070904@semihalf.com> <111399E3-2BC7-4724-8AFB-A40F2A47E66D@mac.com> Message-ID: <48DBC59C.3040101@semihalf.com> Marcel Moolenaar wrote: >> Atomic increment would be like this: >> 1. lwarx W1 >> >> 2. lwz W2 >> 3. In-register increment/other modification >> 4. stw W2 (modified) >> Neither 2. nor 3 issued from local CPU will not clear our reservation >> on this >> granule. >> >> (optionally increment/modify in-register value of W1) >> 5. stwcx W1, goto p.1 if not succeeded > > Ok. Let's assume we lose the reservation and we're > forced to loop and try again. Step 2 then reads W2, > which on a retry is the word written in step 4. As > such, if we have to loop and retry X times, then > the atomic increment would increment by X and not > 1. > > I don't think an unconditional write to W2 will > work if we don't preserve the origional value of > W2. Yeah, it seems there are problems with W2 in read-modify-write scenarios... My environment is simpler (don't need full R-M-W facility). Let me think a bit about that other algo. FWIW, on multicore e500 systems it is possible to do this safely: there is system wide atomic op monitoring bit HID1[ATS], which lets a given CPU know if a lwarx/stwcx sequence is in progress on the system, so we can remotely manage reservations and eliminate wasting some of bus bandwidth. But this is of course not uniform accross PowerPC implementations. Rafal From nwhitehorn at freebsd.org Thu Sep 25 18:17:33 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Thu Sep 25 18:17:41 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: References: <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> <48D84C12.7070207@freebsd.org> <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> <48D92D44.6080807@freebsd.org> <48DA4037.9000508@freebsd.org> Message-ID: <48DBD6C0.5070005@freebsd.org> Marco Trillo wrote: > Hi, > > On Wed, Sep 24, 2008 at 3:27 PM, Nathan Whitehorn > wrote: >> Ugh. I really don't know, and am flying blind without hardware. If you >> disable ATAPI DMA or the macio controller, does ad0 at least work? >> -Nathan >> > > I reverted the ata_macio.c patch and now Kauai uses DMA just fine! ad0 > now works in UDMA100 mode without any errors :-) > > ata0 mem 0x20000-0x20fff,0x8800-0x88ff irq 24,12 on macio0 > ata0: [ITHREAD] > ata1: mem 0xf5004000-0xf5007fff irq > 39,1 at device 13.0 on pci2 > ata1: [ITHREAD] > acd0: DVDR at ata0-master BIOSPIO > ad0: 38166MB at ata1-master UDMA100 > > And indeed the ad0 disk performance is much better. Thank you! > > So it looks like an ata_macio specific problem. Well I'm glad to hear that something works :) I just added in support for setting the timing correctly when the bus has multiple devices running at different speeds and also for programming reasonable PIO defaults for ata_macio. I hope the combination solves the problems seen by both you and Marcel, so more testing would be appreciated. As usual, the patch is here: http://people.freebsd.org/~nwhitehorn/apple-ata-dma.patch -Nathan From marcotrillo at gmail.com Fri Sep 26 17:48:32 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Fri Sep 26 17:48:39 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48DBD6C0.5070005@freebsd.org> References: <48D389EE.9000207@FreeBSD.org> <48D7F437.1040603@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> <48D84C12.7070207@freebsd.org> <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> <48D92D44.6080807@freebsd.org> <48DA4037.9000508@freebsd.org> <48DBD6C0.5070005@freebsd.org> Message-ID: Hi Nathan, On Thu, Sep 25, 2008 at 8:21 PM, Nathan Whitehorn wrote: > Well I'm glad to hear that something works :) > > I just added in support for setting the timing correctly when the bus has > multiple devices running at different speeds and also for programming > reasonable PIO defaults for ata_macio. I hope the combination solves the > problems seen by both you and Marcel, so more testing would be appreciated. > As usual, the patch is here: The patch seems to work for me, I get no hangs or errors at boot time: ata0 mem 0x20000-0x20fff,0x8800-0x88ff irq 24,12 on macio0 ata0: [ITHREAD] ata1: mem 0xf5004000-0xf5007fff irq 39,1 at device 13.0 on pci2 ata1: [ITHREAD] acd0: DVDR at ata0-master WDMA2 ad0: 38166MB at ata1-master UDMA100 The ad0 disk works perfectly in UDMA100 (I have tested it a lot these days without problems). I have not tested acd0 yet, but I'm going to test it and report how well does it work. Thanks! Marco. From marcotrillo at gmail.com Fri Sep 26 17:53:27 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Fri Sep 26 17:53:33 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: References: <48D389EE.9000207@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> <48D84C12.7070207@freebsd.org> <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> <48D92D44.6080807@freebsd.org> <48DA4037.9000508@freebsd.org> <48DBD6C0.5070005@freebsd.org> Message-ID: Hi, On Fri, Sep 26, 2008 at 7:48 PM, Marco Trillo wrote: >> I just added in support for setting the timing correctly when the bus has >> multiple devices running at different speeds and also for programming >> reasonable PIO defaults for ata_macio. I hope the combination solves the >> problems seen by both you and Marcel, so more testing would be appreciated. >> As usual, the patch is here: > > The patch seems to work for me, I get no hangs or errors at boot time: > > ata0 mem 0x20000-0x20fff,0x8800-0x88ff irq 24,12 on macio0 > ata0: [ITHREAD] > ata1: mem 0xf5004000-0xf5007fff irq > 39,1 at device 13.0 on pci2 > ata1: [ITHREAD] > acd0: DVDR at ata0-master WDMA2 > ad0: 38166MB at ata1-master UDMA100 > > The ad0 disk works perfectly in UDMA100 (I have tested it a lot these > days without problems). I have not tested acd0 yet, but I'm going to > test it and report how well does it work. I just tested it. It works fine! No hangs or errors, and the data transfers just fine. Thanks! Marco. From marcotrillo at gmail.com Fri Sep 26 18:17:27 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Fri Sep 26 18:17:34 2008 Subject: Onboard audio support and DBDMA API extensions. Message-ID: Hi, I'm working in a pcm(4) driver for the Apple onboard audio. The current status is that audio output works on my machine using a default volume, but volume changing is not supported yet. In more detail, what I have is support for audio output using the I2S-based mac-io audio controller (which is the one used on most new-world Apple machines), using DBDMA to transfer the audio. Support for the older, DAVbus-based controllers should be easy too since the DBDMA stuff is mostly the same. I would like to propose two extensions for the DBDMA API, detailed below. I also have preliminary support for the GPIO controls, which are used mainly to select the output port (built-in speakers or headphones). What I have yet to do is to support the mixer(4) interface (to support changing the output volume), which needs support for the Keywest I2C controller in order to talk to the codec. I have in fact ported a Keywest I2C driver from NetBSD, but I don't use it much yet. Some dmesg output of the driver with debugging enabled: macio0: mem 0x80000000-0x8007ffff at device 23.0 on pci1 pcm0: mem 0x10000-0x10fff,0x8000-0x80ff,0x8100-0x81ff,0x8200-0x82ff,0x8300-0x83ff irq 30,1,2,31,3,4 on macio0 interrupting at irq 1 pcm0: [ITHREAD] GPIO : addr 0x6f GPIO : addr 0x70 GPIO : addr 0x75 GPIO : addr 0x67 enabled outputs: SPEAKER resetting codec pcm_getbuffersize returned 65536 aoa_dma_setprd: addr = 31391744, 32 slots aoa_chan_setformat: format = 268435488 aoa_chan_setspeed: speed = 44100 aoa_chan_setformat: format = 268435488 aoa_chan_setblocksize: blocksz = 2048, dma->blksz = 2048 aoa_chan_setspeed: speed = 44100 aoa_chan_setformat: format = 268435488 aoa_chan_setblocksize: blocksz = 2048, dma->blksz = 2048 aoa_chan_setblocksize: blocksz = 2048, dma->blksz = 2048 aoa_chan_setspeed: speed = 44100 aoa_chan_setformat: format = 268435488 aoa_chan_setblocksize: blocksz = 2048, dma->blksz = 2048 kiic0: mem 0x18000-0x18fff irq 26 on macio0 $ cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32bit 2007061600/powerpc) Installed devices: pcm0: at irq 1 [GIANT] (1p:1v/0r:0v channels default) Playing an audio file (in this case using the "aifftools" utilities): $ cd dl/aiff/aifftools/aifftools $ ./aiffopen 1\ Kyrie.aiff => Reading '1 Kyrie.aiff'... +---------------------------------+ | 1 Kyrie.aiff | +----------------+----------------+ | Author:| | +----------------+----------------+ | Length:| 0:07:08| +----------------+----------------+ | Sampling rate:| 44.100 kHz| +----------------+----------------+ | Channels:| Stereo| +----------------+----------------+ | Resolution:| 16 bps| +----------------+----------------+ | Bitrate:| 1411 kbps| +----------------+----------------+ => oss: Open Sound System (OSS) => Start playing [0:00:38]^C => Aborted by signal 2 The current work-in-progress version of the driver is at: . I would like to propose the following additions to the DBDMA API, which I'm using in the driver: void dbdma_clear_cmd_status(dbdma_channel_t *, int slot); Clears the cmdStatus of DBDMA command at slot 'slot'. Used for keeping track of completed blocks. void dbdma_control(dbdma_channel_t *, uint8_t mask, uint8_t in); General-purpose manipulation of the DBDMA channel control register. Used for setting/clearing general-purpose control bits such as S0. What do you think? Thanks, Marco. From nwhitehorn at freebsd.org Fri Sep 26 18:40:25 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Fri Sep 26 18:40:32 2008 Subject: Onboard audio support and DBDMA API extensions. In-Reply-To: References: Message-ID: <48DD2D9B.2070706@freebsd.org> Marco Trillo wrote: > Hi, > > I'm working in a pcm(4) driver for the Apple onboard audio. The > current status is that audio output works on my machine using a > default volume, but volume changing is not supported yet. Great! > I also have preliminary support for the GPIO controls, which are used > mainly to select the output port (built-in speakers or headphones). > What I have yet to do is to support the mixer(4) interface (to support > changing the output volume), which needs support for the Keywest I2C > controller in order to talk to the codec. I have in fact ported a > Keywest I2C driver from NetBSD, but I don't use it much yet. I think we need to come up with a good way to handle the GPIO stuff and FCR setting. GPIO is also needed for PMU support (my current PMU driver has ugly hacks) and for SMU on G5 machines. Maybe some new interfaces to macio? This is complicated a little with SMU, though, as it isn't a macio child. > I would like to propose the following additions to the DBDMA API, > which I'm using in the driver: > > void dbdma_clear_cmd_status(dbdma_channel_t *, int slot); > Clears the cmdStatus of DBDMA command at slot 'slot'. Used for keeping > track of completed blocks. > > void dbdma_control(dbdma_channel_t *, uint8_t mask, uint8_t in); > General-purpose manipulation of the DBDMA channel control register. > Used for setting/clearing general-purpose control bits such as S0. Looks good to me. I'd suggest changing the name of dbdma_control() to dbdma_set_chan_status() to match dbdma_get_chan_status(), though. -Nathan From nwhitehorn at freebsd.org Fri Sep 26 18:41:58 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Fri Sep 26 18:42:04 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: References: <48D389EE.9000207@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> <48D84C12.7070207@freebsd.org> <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> <48D92D44.6080807@freebsd.org> <48DA4037.9000508@freebsd.org> <48DBD6C0.5070005@freebsd.org> Message-ID: <48DD2DF7.2020901@freebsd.org> Marco Trillo wrote: > Hi, > > On Fri, Sep 26, 2008 at 7:48 PM, Marco Trillo wrote: >>> I just added in support for setting the timing correctly when the bus has >>> multiple devices running at different speeds and also for programming >>> reasonable PIO defaults for ata_macio. I hope the combination solves the >>> problems seen by both you and Marcel, so more testing would be appreciated. >>> As usual, the patch is here: >> The patch seems to work for me, I get no hangs or errors at boot time: >> >> ata0 mem 0x20000-0x20fff,0x8800-0x88ff irq 24,12 on macio0 >> ata0: [ITHREAD] >> ata1: mem 0xf5004000-0xf5007fff irq >> 39,1 at device 13.0 on pci2 >> ata1: [ITHREAD] >> acd0: DVDR at ata0-master WDMA2 >> ad0: 38166MB at ata1-master UDMA100 >> >> The ad0 disk works perfectly in UDMA100 (I have tested it a lot these >> days without problems). I have not tested acd0 yet, but I'm going to >> test it and report how well does it work. > > I just tested it. It works fine! No hangs or errors, and the data > transfers just fine. Thanks! Wonderful! If I can get positive reports from a few more people who were having trouble, I'll drop this in the tree. -Nathan From xcllnt at mac.com Fri Sep 26 19:01:41 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Sep 26 19:01:48 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48DD2DF7.2020901@freebsd.org> References: <48D389EE.9000207@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> <48D84C12.7070207@freebsd.org> <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> <48D92D44.6080807@freebsd.org> <48DA4037.9000508@freebsd.org> <48DBD6C0.5070005@freebsd.org> <48DD2DF7.2020901@freebsd.org> Message-ID: <1DEA7917-95E2-4BEA-AA03-2791AAA0751F@mac.com> On Sep 26, 2008, at 11:46 AM, Nathan Whitehorn wrote: > Marco Trillo wrote: >> Hi, >> On Fri, Sep 26, 2008 at 7:48 PM, Marco Trillo >> wrote: >>>> I just added in support for setting the timing correctly when the >>>> bus has >>>> multiple devices running at different speeds and also for >>>> programming >>>> reasonable PIO defaults for ata_macio. I hope the combination >>>> solves the >>>> problems seen by both you and Marcel, so more testing would be >>>> appreciated. >>>> As usual, the patch is here: >>> The patch seems to work for me, I get no hangs or errors at boot >>> time: >>> >>> ata0 mem 0x20000-0x20fff,0x8800-0x88ff irq 24,12 on macio0 >>> ata0: [ITHREAD] >>> ata1: mem 0xf5004000-0xf5007fff irq >>> 39,1 at device 13.0 on pci2 >>> ata1: [ITHREAD] >>> acd0: DVDR at ata0-master WDMA2 >>> ad0: 38166MB at ata1-master UDMA100 >>> >>> The ad0 disk works perfectly in UDMA100 (I have tested it a lot >>> these >>> days without problems). I have not tested acd0 yet, but I'm going >>> to >>> test it and report how well does it work. >> I just tested it. It works fine! No hangs or errors, and the data >> transfers just fine. Thanks! > > Wonderful! If I can get positive reports from a few more people who > were having trouble, I'll drop this in the tree. I won't be able to test again until Monday, so feel free to commit without my feedback if you received enough positive news before that time. FYI, -- Marcel Moolenaar xcllnt@mac.com From grehan at freebsd.org Sat Sep 27 01:51:37 2008 From: grehan at freebsd.org (Peter Grehan) Date: Sat Sep 27 01:51:43 2008 Subject: 8.0-current 200809 snapshot CD boot problem In-Reply-To: References: Message-ID: <48DD91A4.2060306@freebsd.org> Hi Marco, Would you be able to try booting into the loader only e.g. 0 > boot cd:,\boot\loader hd:58 (giving a non-existent partition instead of no parameter will prevent the loader from trying to open the device it was booted off). Then, issue an 'memmap' command at the loader prompt, and see if OFW is using any of the memory that is at question. Secondly, would you be able to to a 'C' boot, but halt into the loader and issue the same command ? This time, there should be memory allocated for the kernel itself. I vaguely remember problems with eMacs in the past when booting from disk, but the details are lost in the haze of time. later, Peter. From grehan at freebsd.org Sat Sep 27 03:44:33 2008 From: grehan at freebsd.org (Peter Grehan) Date: Sat Sep 27 03:44:39 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48DD2DF7.2020901@freebsd.org> References: <48D389EE.9000207@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> <48D84C12.7070207@freebsd.org> <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> <48D92D44.6080807@freebsd.org> <48DA4037.9000508@freebsd.org> <48DBD6C0.5070005@freebsd.org> <48DD2DF7.2020901@freebsd.org> Message-ID: <48DDAC14.9070604@freebsd.org> Hi Nathan, > If I can get positive reports from a few more people who were > having trouble, I'll drop this in the tree. The imac's ata-4 is working solidly at UDMA-66. The difference in CPU usage and i/o with dd at 32k block size is stunning: 2MB/7% idle before, 18MB/75% idle with your patch. later, Peter. From marcotrillo at gmail.com Sat Sep 27 10:48:41 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Sat Sep 27 10:48:47 2008 Subject: 8.0-current 200809 snapshot CD boot problem In-Reply-To: <48DD91A4.2060306@freebsd.org> References: <48DD91A4.2060306@freebsd.org> Message-ID: Hi, On Sat, Sep 27, 2008 at 3:51 AM, Peter Grehan wrote: > Would you be able to try booting into the loader only e.g. > > 0 > boot cd:,\boot\loader hd:58 > > (giving a non-existent partition instead of no parameter will prevent the > loader from trying to open the device it was booted off). > > Then, issue an 'memmap' command at the loader prompt, and see if OFW is > using any of the memory that is at question. This is the output of the 'memmap' command with hd:58. It looks like the memory in question is not being used by OFW: OK memmap Virtual Range Physical Range #Pages Mode 00000000-00003000 00000000-00003000 3 10 00003000-00083000 00003000-00083000 128 10 01c00000-01c40000 01c00000-01c40000 64 2 80000000-80080000 80000000-80080000 128 28 80081000-80082000 80081000-80082000 1 28 80082000-80083000 80082000-80083000 1 28 80083000-80084000 80083000-80084000 1 28 90000000-90010000 90000000-90010000 16 28 98000000-a0000000 98000000-a0000000 32768 28 f0000000-f0010000 f0000000-f0010000 16 28 f0800000-f0801000 f0800000-f0801000 1 28 f0c00000-f0c01000 f0c00000-f0c01000 1 28 f2000000-f2010000 f2000000-f2010000 16 28 f2800000-f2801000 f2800000-f2801000 1 28 f2c00000-f2c01000 f2c00000-f2c01000 1 28 f4000000-f4010000 f4000000-f4010000 16 28 f4800000-f4801000 f4800000-f4801000 1 28 f4c00000-f4c01000 f4c00000-f4c01000 1 28 f5000000-f5001000 f5000000-f5001000 1 28 f5004000-f5008000 f5004000-f5008000 4 28 f5200000-f5400000 f5200000-f5400000 512 28 f8000000-f8003000 f8000000-f8003000 3 28 ff7f0000-ff800000 2fbf0000-2fc00000 16 10 ff800000-ffc00000 2fc00000-30000000 1024 10 fff04000-fff06000 fff04000-fff06000 2 28 fff06000-fff08000 fff06000-fff08000 2 28 > > Secondly, would you be able to to a 'C' boot, but halt into the loader and > issue the same command ? This time, there should be memory allocated for the > kernel itself. > The full output in this case is below. The memory in question is now mapped, but I don't know why it makes a difference starting at 0013d3c0 (working) or at 00100100 (not working). OK memmap Virtual Range Physical Range #Pages Mode 00000000-00003000 00000000-00003000 3 10 00003000-00083000 00003000-00083000 128 10 00100000-00110000 00100000-00110000 16 0 00110000-005ab000 00110000-005ab000 1179 0 005ab000-005bb000 005ab000-005bb000 16 0 005bb000-005cb000 005bb000-005cb000 16 0 005cb000-005db000 005cb000-005db000 16 0 005db000-005eb000 005db000-005eb000 16 0 005eb000-005fb000 005eb000-005fb000 16 0 005fb000-0060b000 005fb000-0060b000 16 0 0060b000-0061b000 0060b000-0061b000 16 0 0061b000-0062b000 0061b000-0062b000 16 0 0062b000-0063b000 0062b000-0063b000 16 0 0063b000-0064b000 0063b000-0064b000 16 0 0064b000-0065b000 0064b000-0065b000 16 0 0065b000-0066b000 0065b000-0066b000 16 0 0066b000-0067b000 0066b000-0067b000 16 0 0067b000-0068b000 0067b000-0068b000 16 0 0068b000-0069b000 0068b000-0069b000 16 0 0069b000-006ab000 0069b000-006ab000 16 0 006ab000-006bb000 006ab000-006bb000 16 0 006bb000-006cb000 006bb000-006cb000 16 0 006cb000-006db000 006cb000-006db000 16 0 006db000-006eb000 006db000-006eb000 16 0 006eb000-006fb000 006eb000-006fb000 16 0 006fb000-0070b000 006fb000-0070b000 16 0 0070b000-0071b000 0070b000-0071b000 16 0 0071b000-0072b000 0071b000-0072b000 16 0 0072b000-0073b000 0072b000-0073b000 16 0 0073b000-0074b000 0073b000-0074b000 16 0 0074b000-0075b000 0074b000-0075b000 16 0 0075b000-0079d000 0075b000-0079d000 66 0 0079d000-00803000 0079d000-00803000 102 0 00803000-00813000 00803000-00813000 16 0 00813000-00823000 00813000-00823000 16 0 00823000-00833000 00823000-00833000 16 0 00833000-00843000 00833000-00843000 16 0 00843000-00853000 00843000-00853000 16 0 00853000-00863000 00853000-00863000 16 0 00863000-00873000 00863000-00873000 16 0 00873000-00883000 00873000-00883000 16 0 00883000-00893000 00883000-00893000 16 0 00893000-008a3000 00893000-008a3000 16 0 008a3000-008b3000 008a3000-008b3000 16 0 008b3000-008c3000 008b3000-008c3000 16 0 008c3000-008d3000 008c3000-008d3000 16 0 008d3000-008e3000 008d3000-008e3000 16 0 008e3000-008f3000 008e3000-008f3000 16 0 008f3000-00903000 008f3000-00903000 16 0 00903000-00913000 00903000-00913000 16 0 00913000-00923000 00913000-00923000 16 0 00923000-00933000 00923000-00933000 16 0 00933000-00943000 00933000-00943000 16 0 00943000-00953000 00943000-00953000 16 0 00953000-00963000 00953000-00963000 16 0 00963000-00973000 00963000-00973000 16 0 00973000-00983000 00973000-00983000 16 0 00983000-00993000 00983000-00993000 16 0 00993000-009a3000 00993000-009a3000 16 0 009a3000-009b3000 009a3000-009b3000 16 0 009b3000-009c3000 009b3000-009c3000 16 0 009c3000-009d3000 009c3000-009d3000 16 0 009d3000-009e3000 009d3000-009e3000 16 0 009e3000-009f3000 009e3000-009f3000 16 0 009f3000-00a03000 009f3000-00a03000 16 0 00a03000-00a13000 00a03000-00a13000 16 0 00a13000-00a23000 00a13000-00a23000 16 0 00a23000-00a33000 00a23000-00a33000 16 0 00a33000-00a43000 00a33000-00a43000 16 0 00a43000-00a53000 00a43000-00a53000 16 0 00a53000-00a63000 00a53000-00a63000 16 0 00a63000-00a73000 00a63000-00a73000 16 0 00a73000-00a83000 00a73000-00a83000 16 0 00a83000-00a93000 00a83000-00a93000 16 0 00a93000-00aa3000 00a93000-00aa3000 16 0 00aa3000-00ab3000 00aa3000-00ab3000 16 0 00ab3000-00ac3000 00ab3000-00ac3000 16 0 00ac3000-00ad3000 00ac3000-00ad3000 16 0 00ad3000-00ae3000 00ad3000-00ae3000 16 0 00ae3000-00af3000 00ae3000-00af3000 16 0 00af3000-00b03000 00af3000-00b03000 16 0 00b03000-00b13000 00b03000-00b13000 16 0 00b13000-00b23000 00b13000-00b23000 16 0 00b23000-00b33000 00b23000-00b33000 16 0 00b33000-00b43000 00b33000-00b43000 16 0 00b43000-00b53000 00b43000-00b53000 16 0 00b53000-00b63000 00b53000-00b63000 16 0 00b63000-00b73000 00b63000-00b73000 16 0 00b73000-00b83000 00b73000-00b83000 16 0 00b83000-00b93000 00b83000-00b93000 16 0 00b93000-00ba3000 00b93000-00ba3000 16 0 00ba3000-00bb3000 00ba3000-00bb3000 16 0 00bb3000-00bc3000 00bb3000-00bc3000 16 0 00bc3000-00bd3000 00bc3000-00bd3000 16 0 00bd3000-00be3000 00bd3000-00be3000 16 0 00be3000-00bf3000 00be3000-00bf3000 16 0 00bf3000-00c03000 00bf3000-00c03000 16 0 00c03000-00c13000 00c03000-00c13000 16 0 01c00000-01c30000 01c00000-01c30000 48 2 01c30000-01c3f000 01c30000-01c3f000 15 2 80000000-80080000 80000000-80080000 128 28 80081000-80082000 80081000-80082000 1 28 80082000-80083000 80082000-80083000 1 28 80083000-80084000 80083000-80084000 1 28 90000000-90010000 90000000-90010000 16 28 98000000-a0000000 98000000-a0000000 32768 28 f0000000-f0010000 f0000000-f0010000 16 28 f0800000-f0801000 f0800000-f0801000 1 28 f0c00000-f0c01000 f0c00000-f0c01000 1 28 f2000000-f2010000 f2000000-f2010000 16 28 f2800000-f2801000 f2800000-f2801000 1 28 f2c00000-f2c01000 f2c00000-f2c01000 1 28 f4000000-f4010000 f4000000-f4010000 16 28 f4800000-f4801000 f4800000-f4801000 1 28 f4c00000-f4c01000 f4c00000-f4c01000 1 28 f5000000-f5001000 f5000000-f5001000 1 28 f5004000-f5008000 f5004000-f5008000 4 28 f5200000-f5400000 f5200000-f5400000 512 28 f8000000-f8003000 f8000000-f8003000 3 28 ff7f0000-ff800000 2fbf0000-2fc00000 16 10 ff800000-ffc00000 2fc00000-30000000 1024 10 fff04000-fff06000 fff04000-fff06000 2 28 fff06000-fff08000 fff06000-fff08000 2 28 Thanks for your reply! Marco. From marcotrillo at gmail.com Sat Sep 27 11:15:38 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Sat Sep 27 11:15:46 2008 Subject: Onboard audio support and DBDMA API extensions. In-Reply-To: <48DD2D9B.2070706@freebsd.org> References: <48DD2D9B.2070706@freebsd.org> Message-ID: Hi, On Fri, Sep 26, 2008 at 8:44 PM, Nathan Whitehorn wrote: > Marco Trillo wrote: >> I also have preliminary support for the GPIO controls, which are used >> mainly to select the output port (built-in speakers or headphones). >> What I have yet to do is to support the mixer(4) interface (to support >> changing the output volume), which needs support for the Keywest I2C >> controller in order to talk to the codec. I have in fact ported a >> Keywest I2C driver from NetBSD, but I don't use it much yet. > > I think we need to come up with a good way to handle the GPIO stuff and FCR > setting. GPIO is also needed for PMU support (my current PMU driver has ugly > hacks) and for SMU on G5 machines. I agree; I'm also using a ugly hack for accessing the GPIO space in the aoa driver (using hardcoded base address and relying on BAT mapping). > Maybe some new interfaces to macio? This is probably the best way; macio.c would map the FCR and GPIO spaces and provide accessor functions for clearing, setting and testing bits in the FCRs and writing and reading from GPIO lines. The aoa driver would also need to access the FCR1 in order to stop and reenable the I2S clock, in order to support changing the sampling rate, but this part is ifdefed-out by now (currently I have it fixed at 44100Hz). > > I would like to propose the following additions to the DBDMA API, >> >> which I'm using in the driver: >> >> void dbdma_clear_cmd_status(dbdma_channel_t *, int slot); >> Clears the cmdStatus of DBDMA command at slot 'slot'. Used for keeping >> track of completed blocks. >> >> void dbdma_control(dbdma_channel_t *, uint8_t mask, uint8_t in); >> General-purpose manipulation of the DBDMA channel control register. >> Used for setting/clearing general-purpose control bits such as S0. > > Looks good to me. I'd suggest changing the name of dbdma_control() to > dbdma_set_chan_status() to match dbdma_get_chan_status(), though. > OK. Here is patch which adds the functions dbdma_clear_cmd_status() and dbdma_set_chan_status(): Index: include/dbdma.h =================================================================== RCS file: /home/ncvs/src/sys/powerpc/include/dbdma.h,v retrieving revision 1.2 diff -u -r1.2 dbdma.h --- include/dbdma.h 23 Sep 2008 02:12:47 -0000 1.2 +++ include/dbdma.h 27 Sep 2008 11:12:25 -0000 @@ -85,6 +85,7 @@ int dbdma_free_channel(dbdma_channel_t *chan); uint16_t dbdma_get_cmd_status(dbdma_channel_t *chan, int slot); +void dbdma_clear_cmd_status(dbdma_channel_t *, int); uint16_t dbdma_get_residuals(dbdma_channel_t *chan, int slot); void dbdma_run(dbdma_channel_t *chan); @@ -104,6 +105,7 @@ uint8_t value); void dbdma_set_wait_selector(dbdma_channel_t *chan, uint8_t mask, uint8_t value); +void dbdma_set_chan_status(dbdma_channel_t *, uint8_t, uint8_t); void dbdma_insert_command(dbdma_channel_t *chan, int slot, int command, int stream, bus_addr_t data, size_t count, uint8_t interrupt, cvs diff: Diffing mpc85xx cvs diff: Diffing ofw cvs diff: Diffing powermac Index: powermac/dbdma.c =================================================================== RCS file: /home/ncvs/src/sys/powerpc/powermac/dbdma.c,v retrieving revision 1.2 diff -u -r1.2 dbdma.c --- powermac/dbdma.c 23 Sep 2008 02:12:47 -0000 1.2 +++ powermac/dbdma.c 27 Sep 2008 11:12:26 -0000 @@ -127,6 +127,12 @@ return (le16toh(chan->sc_slots[slot].resCount)); } +void +dbdma_clear_cmd_status(dbdma_channel_t *chan, int slot) +{ + chan->sc_slots[slot].resCount = 0; +} + uint16_t dbdma_get_residuals(dbdma_channel_t *chan, int slot) { @@ -241,6 +247,17 @@ } void +dbdma_set_chan_status(dbdma_channel_t *chan, uint8_t mask, uint8_t val) +{ + uint32_t x; + + x = mask; + x <<= 16; + x |= val; + dbdma_write_reg(chan, CHAN_CONTROL_REG, x); +} + +void dbdma_set_wait_selector(dbdma_channel_t *chan, uint8_t mask, uint8_t val) { uint32_t wait_select; Thanks, Marco. From nse at delfi-konsult.com Sat Sep 27 12:05:46 2008 From: nse at delfi-konsult.com (Niels S. Eliasen) Date: Sat Sep 27 12:05:53 2008 Subject: Courier imapd segfaults with Signal 11 Message-ID: <9FA3CD1D-6AD7-4243-933C-A37A4615F0BB@delfi-konsult.com> Hi guys I have the following problem ... after having setup Courier + Postfix + MySQL as a mailserver... I get the following: gdb /usr/local/bin/imapd imapd.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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 "powerpc-marcel-freebsd"...(no debugging symbols found)... Core was generated by `imapd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libfam.so.0...done. Loaded symbols for /usr/local/lib/libfam.so.0 Reading symbols from /usr/local/lib/courier-authlib/ libcourierauth.so...done. Loaded symbols for /usr/local/lib/courier-authlib/libcourierauth.so Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 0x00000000 in ?? () [New Thread 0x21c01100 (LWP 100063)] (gdb) bt #0 0x00000000 in ?? () (gdb) Same behaviour for both current Courier (4.4.1) and my previous install 4.3.x and FreeBSD version 7.0 .... any ideas ?? kind regards nse "Ach, crivens, what a wee snotter....." Quote from "The Wee Free Men" by Terry Pratchett From nwhitehorn at freebsd.org Sat Sep 27 18:29:33 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Sat Sep 27 18:29:39 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48DDAC14.9070604@freebsd.org> References: <48D389EE.9000207@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> <48D84C12.7070207@freebsd.org> <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> <48D92D44.6080807@freebsd.org> <48DA4037.9000508@freebsd.org> <48DBD6C0.5070005@freebsd.org> <48DD2DF7.2020901@freebsd.org> <48DDAC14.9070604@freebsd.org> Message-ID: <48DE7C93.5050506@freebsd.org> Peter Grehan wrote: > Hi Nathan, > > > If I can get positive reports from a few more people who were >> having trouble, I'll drop this in the tree. > > The imac's ata-4 is working solidly at UDMA-66. The difference in CPU > usage and i/o with dd at 32k block size is stunning: 2MB/7% idle before, > 18MB/75% idle with your patch. I guess DMA is a useful technology :) Thanks for testing -- I've committed the patch. I'll revisit it when Marcel tests it on Monday and it erases his hard drive... -Nathan From xcllnt at mac.com Sat Sep 27 20:23:24 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Sep 27 20:23:39 2008 Subject: 8.0-current 200809 snapshot CD boot problem In-Reply-To: References: <48DD91A4.2060306@freebsd.org> Message-ID: <263AF44F-FC15-4700-B93B-B0DE07A17B40@mac.com> On Sep 27, 2008, at 3:48 AM, Marco Trillo wrote: *snip* > This is the output of the 'memmap' command with hd:58. It looks like > the memory in question is not being used by OFW: *snip* > 00003000-00083000 00003000-00083000 128 10 > 01c00000-01c40000 01c00000-01c40000 64 2 *snip* > The full output in this case is below. The memory in question is now > mapped, but I don't know why it makes a difference starting at > 0013d3c0 (working) or at 00100100 (not working). *snip* > 00003000-00083000 00003000-00083000 128 10 > 00100000-00110000 00100000-00110000 16 0 > 00110000-005ab000 00110000-005ab000 1179 0 *snip* Let me get it straight... In the first case (booting from hd:58), does the boot fail for start address 0x100100 but not for start address 0x13d3c0? In the second case (booting from CD), does it work in both cases? Or is the second case the same as the first case and it is failing for 0x100100 and working for 0x13d3c0? -- Marcel Moolenaar xcllnt@mac.com From marcotrillo at gmail.com Sat Sep 27 20:54:17 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Sat Sep 27 20:54:23 2008 Subject: 8.0-current 200809 snapshot CD boot problem In-Reply-To: <263AF44F-FC15-4700-B93B-B0DE07A17B40@mac.com> References: <48DD91A4.2060306@freebsd.org> <263AF44F-FC15-4700-B93B-B0DE07A17B40@mac.com> Message-ID: Hi, On Sat, Sep 27, 2008 at 10:23 PM, Marcel Moolenaar wrote: > Let me get it straight... > > In the first case (booting from hd:58), does the boot > fail for start address 0x100100 but not for start > address 0x13d3c0? > > In the second case (booting from CD), does it work in > both cases? > > Or is the second case the same as the first case and > it is failing for 0x100100 and working for 0x13d3c0? Booting from CD fails for 0x100100 kernels, such as the 8.0-current snapshot, and works for 0x13d3c0 kernels like the 7.1_BETA snapshot. Booting kernels from hard disk (both with a loader in an HFS partition in hard disk or with the loader from the CD) also fails for 8.0-current kernels with the 0x1001000 address and works for kernels with a 0x13d3c0 address, either 7.1 or 8.0-current compiled with revision 1.7 of the "ldscript.powerpc" file . Oddly enough, I tried booting the same 8.0-current snapshot CD on a PowerMac G4 "Sawtooth" (PowerMac3,1) and it boots fine there -- no errors, as does the 7.1-beta CD... Thanks, Marco. From xcllnt at mac.com Sat Sep 27 21:05:14 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Sep 27 21:05:22 2008 Subject: 8.0-current 200809 snapshot CD boot problem In-Reply-To: References: <48DD91A4.2060306@freebsd.org> <263AF44F-FC15-4700-B93B-B0DE07A17B40@mac.com> Message-ID: <11FEA924-DB76-46E1-BF79-A26206F796C0@mac.com> On Sep 27, 2008, at 1:54 PM, Marco Trillo wrote: > On Sat, Sep 27, 2008 at 10:23 PM, Marcel Moolenaar > wrote: >> Let me get it straight... >> >> In the first case (booting from hd:58), does the boot >> fail for start address 0x100100 but not for start >> address 0x13d3c0? >> >> In the second case (booting from CD), does it work in >> both cases? >> >> Or is the second case the same as the first case and >> it is failing for 0x100100 and working for 0x13d3c0? > > Booting from CD fails for 0x100100 kernels, such as the 8.0-current > snapshot, and works for 0x13d3c0 kernels like the 7.1_BETA snapshot. > > Booting kernels from hard disk (both with a loader in an HFS partition > in hard disk or with the loader from the CD) also fails for > 8.0-current kernels with the 0x1001000 address and works for kernels > with a 0x13d3c0 address, either 7.1 or 8.0-current compiled with > revision 1.7 of the "ldscript.powerpc" file . > > Oddly enough, I tried booting the same 8.0-current snapshot CD on a > PowerMac G4 "Sawtooth" (PowerMac3,1) and it boots fine there -- no > errors, as does the 7.1-beta CD... Ok. So while the memmap output differs, the failure mode is the same. Hmmm. The only things I can think of is: o I-cache coherency o Uninitialized memory Typically when we load an ELF image, we read the first page, parse the headers and then read the rest. In this case the failing address (0x100100) is in the first page, whereas the working address (0x13d3c0) isn't. I wonder if we "load" the first page indirectly... Quick question: On ARM and ia64 you need to sync the D-cache before you can make the I-cache coherent. That's because the I-cache is made coherent with memory and not with the D-cache. How's that on PowerPC? -- Marcel Moolenaar xcllnt@mac.com From marius at alchemy.franken.de Sat Sep 27 23:59:18 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Sat Sep 27 23:59:24 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48DE7C93.5050506@freebsd.org> References: <48D92D44.6080807@freebsd.org> <48DA4037.9000508@freebsd.org> <48DBD6C0.5070005@freebsd.org> <48DD2DF7.2020901@freebsd.org> <48DDAC14.9070604@freebsd.org> <48DE7C93.5050506@freebsd.org> Message-ID: <20080927234549.GA16124@alchemy.franken.de> On Sat, Sep 27, 2008 at 01:33:55PM -0500, Nathan Whitehorn wrote: > Peter Grehan wrote: > >Hi Nathan, > > > > > If I can get positive reports from a few more people who were > >>having trouble, I'll drop this in the tree. > > > > The imac's ata-4 is working solidly at UDMA-66. The difference in CPU > >usage and i/o with dd at 32k block size is stunning: 2MB/7% idle before, > >18MB/75% idle with your patch. > > I guess DMA is a useful technology :) > > Thanks for testing -- I've committed the patch. I'll revisit it when > Marcel tests it on Monday and it erases his hard drive... I see two issues with acd(4) on sparc64, which, given that I don't see them with either amd64 or i386 and that there are no such reports for these archs, I suspect are endian- bugs (which might be hidden with 32-bit machines though): a) read-only drives are falsely reported as having write capabilities in dmesg (this is a rather old bug but so far this seemed to be a cosmetic problem only) b) DMA is broken in that file content read is wrong except for "small" files; there's no data corruption when PIO mode is forced (this seem to be a recurring bug once again present in HEAD). Do you guys see these problems also with powerpc? Marius From grehan at freebsd.org Sun Sep 28 06:40:55 2008 From: grehan at freebsd.org (Peter Grehan) Date: Sun Sep 28 06:41:02 2008 Subject: 8.0-current 200809 snapshot CD boot problem In-Reply-To: <11FEA924-DB76-46E1-BF79-A26206F796C0@mac.com> References: <48DD91A4.2060306@freebsd.org> <263AF44F-FC15-4700-B93B-B0DE07A17B40@mac.com> <11FEA924-DB76-46E1-BF79-A26206F796C0@mac.com> Message-ID: <48DF26F2.1000209@freebsd.org> Hi Marcel, > o I-cache coherency The culprit could be the code fragment in sys/boot/ofw/libofw/elf_freebsd.c:__elfN(ofw_loadfile), if (!strcmp((*result)->f_type, "elf kernel")) __syncicache((void *) (*result)->f_addr, (*result)->f_size); If f_addr isn't the start of the text segment i.e. if the initial page wasn't included, then that is what is blowing up. > Quick question: On ARM and ia64 you need to sync the > D-cache before you can make the I-cache coherent. That's > because the I-cache is made coherent with memory and > not with the D-cache. How's that on PowerPC? Same - see powerpc/syncicache.c where the d-cache is flushed before the invalidating the i-cache. later, Peter. From marcotrillo at gmail.com Sun Sep 28 11:12:49 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Sun Sep 28 11:12:55 2008 Subject: Fatal kernel trap on 7400 G4 processors Message-ID: Hi all, Recent 8.0-current kernels cause a "fatal kernel trap" on 7400 G4 processors: fatal kernel trap exception = 0x7 (program) srr0 = 0x5336bc srr1 = 0x83032 lr = 0x5334b4 Stopped at 0x5336bc mfspr 0, dccr The address 0x5336bc corresponds to function cpu_setup() in powerpc/cpu.c: 5336b4: 7f 9e 00 00 cmpw cr7,r30,r0 5336b8: 40 be 02 94 bne+ cr7,53394c 5336bc: 7c 1a fa a6 mfdccr r0 <<<<< here 5336c0: 3d 20 00 5f lis r9,95 I tracked the line to the following code in cpu.c: switch (vers) { case MPC7400: case MPC7410: case MPC7447A: case MPC7448: case MPC7450: case MPC7455: case MPC7457: /* G3 systems don't have an L3 cache, so only check * for G4 and above */ l3cr_config = mfspr(SPR_L3CR); <<<< here /* Fallthrough */ In include/spr.h I see the following: #define SPR_L3CR 0x3fa /* .6. L3 Control Register */ #define SPR_DCCR 0x3fa /* 4.. Data Cache Cachability Register */ So it seems that the 7400 processor doesn't have these registers so it causes a fault. What do you think? Thanks, Marco. From marcotrillo at gmail.com Sun Sep 28 11:50:19 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Sun Sep 28 11:50:25 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48DE7C93.5050506@freebsd.org> References: <48D389EE.9000207@FreeBSD.org> <48DA4037.9000508@freebsd.org> <48DBD6C0.5070005@freebsd.org> <48DD2DF7.2020901@freebsd.org> <48DDAC14.9070604@freebsd.org> <48DE7C93.5050506@freebsd.org> Message-ID: Hi, On Sat, Sep 27, 2008 at 8:33 PM, Nathan Whitehorn wrote: > Thanks for testing -- I've committed the patch. I'll revisit it when Marcel > tests it on Monday and it erases his hard drive... Another report, just for the record, this time from a PowerMac G4 "Sawtooth" (PowerMac3,1) with three mac-io ATA cells, two hard drives and a DVD drive. It works perfectly! ata0 mem 0x1f000-0x1ffff,0x8a00-0x8aff irq 19,11 on macio0 ata0: [ITHREAD] ata1 mem 0x20000-0x20fff,0x8b00-0x8bff irq 20,12 on macio0 ata1: [ITHREAD] ata2 mem 0x21000-0x21fff,0x8c00-0x8cff irq 21,13 on macio0 ata2: [ITHREAD] ad0: 9797MB at ata0-master UDMA66 ad1: 76319MB at ata0-slave UDMA66 acd0: DVDR at ata1-master WDMA2 Thanks, Marco. From nwhitehorn at freebsd.org Sun Sep 28 15:14:46 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Sun Sep 28 15:14:52 2008 Subject: Fatal kernel trap on 7400 G4 processors In-Reply-To: References: Message-ID: <48DFA06F.20607@freebsd.org> Marco Trillo wrote: > Hi all, > > Recent 8.0-current kernels cause a "fatal kernel trap" on 7400 G4 processors: > > fatal kernel trap > > exception = 0x7 (program) > srr0 = 0x5336bc > srr1 = 0x83032 > lr = 0x5334b4 > > Stopped at 0x5336bc mfspr 0, dccr > > The address 0x5336bc corresponds to function cpu_setup() in powerpc/cpu.c: > > 5336b4: 7f 9e 00 00 cmpw cr7,r30,r0 > 5336b8: 40 be 02 94 bne+ cr7,53394c > 5336bc: 7c 1a fa a6 mfdccr r0 <<<<< here > 5336c0: 3d 20 00 5f lis r9,95 > > I tracked the line to the following code in cpu.c: > > l3cr_config = mfspr(SPR_L3CR); <<<< here > > /* Fallthrough */ > > In include/spr.h I see the following: > > #define SPR_L3CR 0x3fa /* .6. L3 Control Register */ > #define SPR_DCCR 0x3fa /* 4.. Data Cache Cachability Register */ > > So it seems that the 7400 processor doesn't have these registers so it > causes a fault. Apparently only the MPC745x CPUs have an L3 cache, and I just updated cpu.c to reflect that. For G5 support, I wrote a piece of code that you can put in EXEC_PGM that writes a value to SPRG2 if a trap was taken, then tries to execute a 64-bit instruction to see if the CPU is 64-bit. I think we should do something similar to detect cache presence, Altivec support and such things. Since we can do this when the system is further into booting, we should be able to use the regular trap handlers. Is there a way to catch traps instead of panicing? -Nathan From xcllnt at mac.com Sun Sep 28 18:06:13 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sun Sep 28 18:06:19 2008 Subject: 8.0-current 200809 snapshot CD boot problem In-Reply-To: <48DF26F2.1000209@freebsd.org> References: <48DD91A4.2060306@freebsd.org> <263AF44F-FC15-4700-B93B-B0DE07A17B40@mac.com> <11FEA924-DB76-46E1-BF79-A26206F796C0@mac.com> <48DF26F2.1000209@freebsd.org> Message-ID: On Sep 27, 2008, at 11:40 PM, Peter Grehan wrote: > Hi Marcel, > >> o I-cache coherency > > The culprit could be the code fragment in sys/boot/ofw/libofw/ > elf_freebsd.c:__elfN(ofw_loadfile), > > if (!strcmp((*result)->f_type, "elf kernel")) > __syncicache((void *) (*result)->f_addr, (*result)- > >f_size); > > If f_addr isn't the start of the text segment i.e. if the initial > page wasn't included, then that is what is blowing up. It looks like f_addr is the correct (virtual) load address. I think the problem relates to whether the starting address falls withing the first page, given that: o We bcopy the first page to avoid reading twice, o We need to flush the D-cache before we can sync the I-cache. We do dcbst before we icbi, but I'm wondering if there isn't a bug there. What if we need to sync after every dcbst? -- Marcel Moolenaar xcllnt@mac.com From sobomax at FreeBSD.org Mon Sep 29 08:55:02 2008 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Mon Sep 29 08:55:09 2008 Subject: Call for testers: Apple ATA DMA References: 48DE7C93.5050506@freebsd.org Message-ID: <48E097E1.2060101@FreeBSD.org> > I see two issues with acd(4) on sparc64, which, given that > I don't see them with either amd64 or i386 and that there > are no such reports for these archs, I suspect are endian- > bugs (which might be hidden with 32-bit machines though): > a) read-only drives are falsely reported as having write > capabilities in dmesg (this is a rather old bug but so > far this seemed to be a cosmetic problem only) > b) DMA is broken in that file content read is wrong except > for "small" files; there's no data corruption when PIO > mode is forced (this seem to be a recurring bug once > again present in HEAD). > > Do you guys see these problems also with powerpc? Not sure if it's related, but burning CD image to CD-RW media doesn't work on my MacMini, failing with something like "invalid argument". At the same time, erasing the same media works just fine. -Maxim From bugmaster at FreeBSD.org Mon Sep 29 11:06:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 29 11:08:28 2008 Subject: Current problem reports assigned to freebsd-ppc@FreeBSD.org Message-ID: <200809291106.m8TB6tbl040896@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- a power/121407 ppc [panic] Won't boot up; strange error message. o power/112435 ppc [nexus] [patch] Update nexus children to use ofw_bus f o power/111296 ppc [kernel] [patch] [request] Support IMISS, DLMISS an DS o power/93203 ppc FreeBSD PPC Can't Write to Partitions. 4 problems total. From tn06aj0 at student.lth.se Mon Sep 29 13:42:42 2008 From: tn06aj0 at student.lth.se (Andreas =?iso-8859-1?Q?J=F6nsson?=) Date: Mon Sep 29 13:42:49 2008 Subject: ADB support? Message-ID: <46171.83.233.155.226.1222694615.squirrel@webmail.student.lth.se> Hi, I'm wondering how the ADB keyboard support is coming along? The last thing I've seen on this list is from July. /Andreas From nwhitehorn at freebsd.org Mon Sep 29 13:49:20 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Mon Sep 29 13:49:27 2008 Subject: ADB support? In-Reply-To: <46171.83.233.155.226.1222694615.squirrel@webmail.student.lth.se> References: <46171.83.233.155.226.1222694615.squirrel@webmail.student.lth.se> Message-ID: <48E0DDE6.5030909@freebsd.org> Andreas J?nsson wrote: > Hi, > > I'm wondering how the ADB keyboard support is coming along? > The last thing I've seen on this list is from July. I've been stymied by a lack of hardware. It works great on my PowerMac G3, but that has a different controller chip (CUDA) than the one everybody wants support for (PMU, found in laptops). My current work is here: http://people.freebsd.org/~nwhitehorn/adb.diff It has a PMU driver, which may just work. Of course, it more likely won't... Motivated people are welcome to hack it, and I'd appreciate any reports. To add this support, apply the patch to sys on a recent -CURRENT, add the following to your kernel config, and recompile: device cuda device pmu device adb -Nathan From xcllnt at mac.com Mon Sep 29 21:52:04 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Sep 29 21:52:10 2008 Subject: Call for testers: Apple ATA DMA In-Reply-To: <48DE7C93.5050506@freebsd.org> References: <48D389EE.9000207@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> <48D84C12.7070207@freebsd.org> <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> <48D92D44.6080807@freebsd.org> <48DA4037.9000508@freebsd.org> <48DBD6C0.5070005@freebsd.org> <48DD2DF7.2020901@freebsd.org> <48DDAC14.9070604@freebsd.org> <48DE7C93.5050506@freebsd.org> Message-ID: <0D5AE023-0D54-43BA-A325-0E1BEEC39D28@mac.com> On Sep 27, 2008, at 11:33 AM, Nathan Whitehorn wrote: > Peter Grehan wrote: >> Hi Nathan, >> > If I can get positive reports from a few more people who were >>> having trouble, I'll drop this in the tree. >> The imac's ata-4 is working solidly at UDMA-66. The difference in >> CPU usage and i/o with dd at 32k block size is stunning: 2MB/7% >> idle before, 18MB/75% idle with your patch. > > I guess DMA is a useful technology :) > > Thanks for testing -- I've committed the patch. I'll revisit it when > Marcel tests it on Monday and it erases his hard drive... Good and bad news. The good: my Xserve is working fine and acd0 is now using UDMA33 instead of BIOSPIO. The bad: my Mac Mini G4 is still having the same problems. This is ad0 at UDMA66 and acd0 at UDMA33. I'll experiment with it a bit later... -- Marcel Moolenaar xcllnt@mac.com From marcotrillo at gmail.com Tue Sep 30 09:31:18 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Tue Sep 30 09:31:25 2008 Subject: Apple Screamer Audio: looking for testers Message-ID: Hi all, This is a status report of the "Apple Onboard Audio" (aoa) driver. I have full audio output support for Apple machines using the "Apple Screamer" audio device. The volume control works and can be regulated with the mixer(8) utility. When something is plugged (or unplugged) in the headphones / line out jack, the driver switches the output to/from the jack automatically, just like Mac OS. If you are interested in audio support and have this device (see below for an incomplete list of machines), it would be nice that you tested it to see how it does on other machines apart from the one I have (PowerMac3,1 G4). Especially regarding the headphone jack detection stuff, since different machines are wired differently. Some dmesg from my machine: pcm0: mem 0x14000-0x14fff,0x8800-0x88ff,0x8900-0x89ff irq 24,9,10 on macio0 interrupting at irq 9 pcm0: [ITHREAD] pcm0: codec: , Crystal Semiconductor part pcm0: [ITHREAD] Enabled outputs: SPEAKER Enabling programmable output. volume 3 3 [...] Enabled outputs: HEADPHONES Enabling programmable output. $ mixer Mixer vol is currently set to 83:83 An incomplete list of machines known to have the Apple Screamer audio device: - "PowerMac2,1" iMac DV ('99) (screamer, Device ID 8) - "PowerMac2,2" iMac DV ('00) (screamer, Device ID 11) - "PowerMac3,1" PowerMac G4 (screamer, Device ID 5) - "PowerMac3,2" PowerMac G4 (screamer, Device ID 5) - "PowerMac3,3" PowerMac G4 (screamer, Device ID 5) - "PowerBook1,1" PowerBook G3 Lombard (screamer, Device ID 2) - "PowerBook3,1" PowerBook G3 Pismo (screamer, Device ID 10) - "PowerBook3,2" PowerBook G3 Titanium (screamer, Device ID 13) (The Screamer is sometimes known as "AWACS" in other operating systems such as NetBSD or OpenBSD; according to Apple the Screamer is in fact a new revision of the AWACS chip used in old-world machines.) In addition to the above list, OpenFirmware can also be used to see if the machine has the Screamer chip: Properties of pci@f2000000/mac-io@17/davbus@14000/sound "name" 0000000: 736f 756e 6400 sound. "device_type" 0000000: 736f 756e 6463 6869 7000 soundchip. "compatible" 0000000: 7363 7265 616d 6572 0061 7761 6373 0000 screamer.awacs.. Anyone with one of these machines? Thanks! Marco. From marcotrillo at gmail.com Tue Sep 30 11:43:34 2008 From: marcotrillo at gmail.com (Marco Trillo) Date: Tue Sep 30 11:43:40 2008 Subject: Apple Screamer Audio: looking for testers In-Reply-To: References: Message-ID: Hi, On Tue, Sep 30, 2008 at 11:31 AM, Marco Trillo wrote: > An incomplete list of machines known to have the Apple Screamer audio device: > > - "PowerMac2,1" iMac DV ('99) (screamer, Device ID 8) > - "PowerMac2,2" iMac DV ('00) (screamer, Device ID 11) > - "PowerMac3,1" PowerMac G4 (screamer, Device ID 5) > - "PowerMac3,2" PowerMac G4 (screamer, Device ID 5) > - "PowerMac3,3" PowerMac G4 (screamer, Device ID 5) > - "PowerBook1,1" PowerBook G3 Lombard (screamer, Device ID 2) > - "PowerBook3,1" PowerBook G3 Pismo (screamer, Device ID 10) > - "PowerBook3,2" PowerBook G3 Titanium (screamer, Device ID 13) Oops.. I meant "PowerBook G4 Titanium", not G3... And another Screamer-based model to add to the list: - "PowerMac4,1" iMac G3 (2001) (screamer) Thanks! Marco. From matt at genesi-usa.com Tue Sep 30 20:50:18 2008 From: matt at genesi-usa.com (Matt Sealey) Date: Tue Sep 30 20:50:25 2008 Subject: Fatal kernel trap on 7400 G4 processors In-Reply-To: References: Message-ID: <48E28F71.4070906@genesi-usa.com> Shouldn't be doing it on a 7447A or 7448 either as they are 744x series which explicitly does not have L3 cache capability. Ironically these are the only chips where you can actually determine the difference between having L3 and not having L3, since the 7447 and 7457 (and all previous pairs) share the same CPU PVR. -- Matt Sealey Genesi, Manager, Developer Relations Marco Trillo wrote: > Hi all, > > Recent 8.0-current kernels cause a "fatal kernel trap" on 7400 G4 processors: > > fatal kernel trap > > exception = 0x7 (program) > srr0 = 0x5336bc > srr1 = 0x83032 > lr = 0x5334b4 > > Stopped at 0x5336bc mfspr 0, dccr > > The address 0x5336bc corresponds to function cpu_setup() in powerpc/cpu.c: > > 5336b4: 7f 9e 00 00 cmpw cr7,r30,r0 > 5336b8: 40 be 02 94 bne+ cr7,53394c > 5336bc: 7c 1a fa a6 mfdccr r0 <<<<< here > 5336c0: 3d 20 00 5f lis r9,95 > > I tracked the line to the following code in cpu.c: > > switch (vers) { > case MPC7400: > case MPC7410: > case MPC7447A: > case MPC7448: > case MPC7450: > case MPC7455: > case MPC7457: > /* G3 systems don't have an L3 cache, so only check > * for G4 and above */ > > l3cr_config = mfspr(SPR_L3CR); <<<< here > > /* Fallthrough */ > > In include/spr.h I see the following: > > #define SPR_L3CR 0x3fa /* .6. L3 Control Register */ > #define SPR_DCCR 0x3fa /* 4.. Data Cache Cachability Register */ > > So it seems that the 7400 processor doesn't have these registers so it > causes a fault. > > What do you think? > > Thanks, > Marco. > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From matt at genesi-usa.com Tue Sep 30 21:01:45 2008 From: matt at genesi-usa.com (Matt Sealey) Date: Tue Sep 30 21:01:51 2008 Subject: 64-bit atomic ops on 32-bit CPU -- was: ZFS .. on PowerPC ? In-Reply-To: <48DBC59C.3040101@semihalf.com> References: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48DA84D5.4010109@semihalf.com> <48DA99F8.7070904@semihalf.com> <111399E3-2BC7-4724-8AFB-A40F2A47E66D@mac.com> <48DBC59C.3040101@semihalf.com> Message-ID: <48E28E58.1020901@genesi-usa.com> Isn't there some kind of semaphore primitive in FreeBSD that can be used? I don't understand why you would need to go for all this effort when every atomic-access-requiring variable can simply just be paired with a lock flag (atomic_a and atomic_a_sem). You ask for the semaphore, if you get it, you can write into the value and read from the value, if you do not, you wait until you can get the semaphore.. After all you are basically just implementing a cache-line-sized integrated variable and a new semaphore system here, is NIH really that big a problem? -- Matt Sealey Genesi, Manager, Developer Relations Rafal Jaworowski wrote: > Marcel Moolenaar wrote: >>> Atomic increment would be like this: >>> 1. lwarx W1 >>> >>> 2. lwz W2 >>> 3. In-register increment/other modification >>> 4. stw W2 (modified) >>> Neither 2. nor 3 issued from local CPU will not clear our reservation >>> on this >>> granule. >>> >>> (optionally increment/modify in-register value of W1) >>> 5. stwcx W1, goto p.1 if not succeeded >> Ok. Let's assume we lose the reservation and we're >> forced to loop and try again. Step 2 then reads W2, >> which on a retry is the word written in step 4. As >> such, if we have to loop and retry X times, then >> the atomic increment would increment by X and not >> 1. >> >> I don't think an unconditional write to W2 will >> work if we don't preserve the origional value of >> W2. > > Yeah, it seems there are problems with W2 in read-modify-write scenarios... My > environment is simpler (don't need full R-M-W facility). Let me think a bit > about that other algo. > > FWIW, on multicore e500 systems it is possible to do this safely: there is > system wide atomic op monitoring bit HID1[ATS], which lets a given CPU know if > a lwarx/stwcx sequence is in progress on the system, so we can remotely manage > reservations and eliminate wasting some of bus bandwidth. But this is of > course not uniform accross PowerPC implementations. > > Rafal > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From grehan at freebsd.org Tue Sep 30 21:37:36 2008 From: grehan at freebsd.org (Peter Grehan) Date: Tue Sep 30 21:37:43 2008 Subject: 64-bit atomic ops on 32-bit CPU -- was: ZFS .. on PowerPC ? In-Reply-To: <48E28E58.1020901@genesi-usa.com> References: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48DA84D5.4010109@semihalf.com> <48DA99F8.7070904@semihalf.com> <111399E3-2BC7-4724-8AFB-A40F2A47E66D@mac.com> <48DBC59C.3040101@semihalf.com> <48E28E58.1020901@genesi-usa.com> Message-ID: <48E29BF3.40106@freebsd.org> Hi Matt, > Isn't there some kind of semaphore primitive in FreeBSD that can be > used? The issue is the OpenSolaris ZFS code that makes liberal use of calls such as atomic_add_64(&ptr_to_uint64). This is emulated by having a global lock for all 64-bit atomic operations, but it would be better if this could be done without such workarounds on 32-bit ppc. later, Peter.