No mixer with Snapper

Wed Mar 4 12:47:29 PST 2009

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