Date: Wed, 04 Mar 2009 21:14:18 +0100 From: Andreas Tobler <andreast@fgznet.ch> To: Weongyo Jeong <weongyo@freebsd.org>, Nathan Whitehorn <nwhitehorn@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: No mixer with Snapper Message-ID: <49AEE11A.2040100@fgznet.ch> In-Reply-To: <20090304084409.GB99730@weongyo.cdnetworks.kr> References: <20090301142432.GC1166@narn.knownspace> <b9c23c9f0903010813p8d1aa55nd2a3f6d94547862b@mail.gmail.com> <1235993578.13513.0.camel@horst-tla> <49ABFAC6.1000000@freebsd.org> <20090303000024.GA82725@michelle.cdnetworks.co.kr> <49AC9C72.3030307@freebsd.org> <20090303053952.GC94580@weongyo.cdnetworks.kr> <49ADEFF9.3010605@freebsd.org> <20090304053318.GA99730@weongyo.cdnetworks.kr> <49AE1975.7050908@freebsd.org> <20090304084409.GB99730@weongyo.cdnetworks.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi all, maybe I should start another thread since it has nothing to do with the subject anymore. How is the policy here? See below. Weongyo Jeong wrote: > On Wed, Mar 04, 2009 at 12:02:29AM -0600, Nathan Whitehorn wrote: >> Weongyo Jeong wrote: >>> On Tue, Mar 03, 2009 at 09:05:29PM -0600, Nathan Whitehorn wrote: >>>> Weongyo Jeong wrote: >>>>> On Mon, Mar 02, 2009 at 08:56:50PM -0600, Nathan Whitehorn wrote: >>>>>> Pyun YongHyeon wrote: >>>>>>> On Mon, Mar 02, 2009 at 09:27:02AM -0600, Nathan Whitehorn wrote: >>>>>>>> Horst G?nther Burkhardt III wrote: >>>>>>>>> On Sun, 2009-03-01 at 17:13 +0100, Marco Trillo wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Thanks! The problem is that an <i2c-address> property is used, while >>>>>>>>>> the OFW-I2C code only looks for <reg>. >>>>>>>>>> >>>>>>>>>> The attached patch -- to apply in /usr/src/sys -- makes the OFW-I2C >>>>>>>>>> code also look for the <i2c-address> property. With the patch, the >>>>>>>>>> mixer should attach and work fine. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Marco >>>>>>>>> Awesome, so when will we see this in -CURRENT or better yet -STABLE? >>>>>>>>> ;) >>>>>>>>> >>>>>>>>> -- Horst. >>>>>>>> SVN revision 189280. MFC schedule of interesting features in -CURRENT >>>>>>>> that I had something to do with: >>>>>>>> >>>>>>>> - ATA DMA: unless I receive any bug reports, some time in the middle >>>>>>>> of this week >>>>>>> Hmm, I think there was a couple of issues of ATA DMA on iBook G4. >>>>>>> marcel@ and weongyo@ also reported instability of ATA DMA, was that >>>>>>> fixed? AFAIK weongyo@ couldn't even boot kernel. >>>>>>> See >>>>>>> http://lists.freebsd.org/pipermail/freebsd-ppc/2008-November/003372.html >>>>>>> for entire thread. >>>>>> I think it was fixed. The G4 iBook that I've acquired since those >>>>>> reports works flawlessly, and I haven't received any other reports, >>>>>> positive or negative, since my earlier attempts at fixing those bugs. >>>>>> If anyone whose machine didn't work before now does, or is still >>>>>> broken, or even if your machine has always worked fine with the DMA >>>>>> support, I would very much appreciate an email. >>>>> Now I've updated kernel and the symptom is same with the previous that >>>>> without set hw.ata.atapi_dma=0 I couldn't boot with the following >>>>> message (written by hand): >>>>> >>>>> acd0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout >>>>> acd0: TIMEOUT - READ_BIG retrying (0 retries left) >>>>> >>>>> The above msg looks a kind of loop and I'll try to do disk stresstest >>>>> for reproducing hangs I encountered. >>>> Drat. That means the mode is set up wrong. I went through the Apple >>>> sources, and produced a patch that slavishly follows the exact details >>>> of the way Apple initializes the controller. It can be found here: >>>> http://people.freebsd.org/~nwhitehorn/atamodesetup.diff >>>> >>>> Could you give that a shot? >>> Of course but it didn't help that I hope I didn't missed something all >>> steps I followed are as follows: >>> >>> # cd /usr/src/sys/powerpc/powermac >>> # fetch http://people.freebsd.org/~nwhitehorn/atamodesetup.diff >>> # patch -p0 < atamodesetup.diff >>> # cd /usr/src >>> # make buildkernel && installkernel >>> >>> The symptom is still same with the previous that it looks no progress. >> One more thing to try: could you try setting USE_DBDMA_IRQ to 1 instead >> of 0 in ata_macio.c? > > I tried your suggestion but I got a system hang after printing the > following lines (written by hand): > > acd:0 DVDR <MATSHITACD-RW CW-8124/DB0D> at ata0-master WDMA2 > ad0: 38154MB <FUJITSU MHV2040AT 00810099> at ata1-master UDMA100 > akbd0: <PowerBook G3 Keyboard> at device 2 on adb0 > kdb1 at akbd0 > ushub0: 2 ports with 2 removable, self powered > [hang; no more prints] I see the similar/same hanger on my imac DV (see here: http://lists.freebsd.org/pipermail/freebsd-ppc/2009-February/003548.html) I did a bisect and ended here: The last booting kernel on my imac DV is svn r187991. Since r187993 it hangs after printing: Mar 4 21:56:26 imacb kernel: ad0: 78167MB <Maxtor 6Y080P0 YAR41BW0> at ata0-master UDMA66 Mar 4 21:56:26 imacb kernel: acd0: DVDR <MATSHITADVD-ROM SR-8184/AA32> at ata0-slave UDMA33 Here the reference for the commit: (http://svn.freebsd.org/viewvc/base?view=revision&revision=187993) R187991 boots fine but it reports a LOR, don't know if helpful. Mar 4 21:56:26 imacb kernel: ad0: 78167MB <Maxtor 6Y080P0 YAR41BW0> at ata0-master UDMA66 Mar 4 21:56:26 imacb kernel: acd0: DVDR <MATSHITADVD-ROM SR-8184/AA32> at ata0-slave UDMA33 Mar 4 21:56:26 imacb kernel: WARNING: WITNESS option enabled, expect reduced performance. Mar 4 21:56:26 imacb kernel: Trying to mount root from ufs:/dev/ad0s10 Mar 4 21:56:26 imacb kernel: lock order reversal: Mar 4 21:56:26 imacb kernel: 1st 0x103d048 user map (user map) @ /export/devel/fbsd_svn/src/sys/vm/vm_map.c:3198 Mar 4 21:56:26 imacb kernel: 2nd 0x11dd7cc ufs (ufs) @ /export/devel/fbsd_svn/src/sys/kern/vfs_subr.c:2071 Mar 4 21:56:26 imacb kernel: KDB: stack backtrace: Mar 4 21:56:26 imacb kernel: 0xdc26d930: at kdb_backtrace+0x4c Mar 4 21:56:26 imacb kernel: 0xdc26d950: at _witness_debugger+0x3c Mar 4 21:56:26 imacb kernel: 0xdc26d970: at witness_checkorder+0x8d0 Mar 4 21:56:26 imacb kernel: 0xdc26d9d0: at __lockmgr_args+0x23c Mar 4 21:56:26 imacb kernel: 0xdc26da50: at ffs_lock+0x9c Mar 4 21:56:26 imacb kernel: 0xdc26da80: at VOP_LOCK1_APV+0xec Mar 4 21:56:26 imacb kernel: 0xdc26daa0: at _vn_lock+0x84 Mar 4 21:56:26 imacb kernel: 0xdc26daf0: at vget+0xdc Mar 4 21:56:26 imacb kernel: 0xdc26db30: at vnode_pager_lock+0x20c Mar 4 21:56:26 imacb kernel: 0xdc26db90: at vm_fault+0x218 Mar 4 21:56:26 imacb kernel: 0xdc26dca0: at trap_pfault+0x128 Mar 4 21:56:26 imacb kernel: 0xdc26dce0: at trap+0x1ac Mar 4 21:56:26 imacb kernel: 0xdc26dda0: at powerpc_interrupt+0x15c Mar 4 21:56:26 imacb kernel: 0xdc26ddd0: user ISI trap by 0x1818944: srr1=0x4000d032 Mar 4 21:56:26 imacb kernel: r1=0x7fffdee0 cr=0x24000048 xer=0 ctr=0 Fortunately I found out about crosscompiling on a faster machine :) Otherwise I would not have been able to find the breaking commit within an hour. Maybe this is some sort of help? Thanks, Andreas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49AEE11A.2040100>