Date: Mon, 25 Jan 2010 15:52:59 -0800 From: Randall Stewart <rrs@lakerest.net> To: Neelkanth Natu <neelnatu@yahoo.com> Cc: attilio@freebsd.org, freebsd-mips@freebsd.org Subject: Re: AR71XX RTC Message-ID: <74D48EE5-544E-44D4-9644-2349E9AA9796@lakerest.net> In-Reply-To: <489828.45501.qm@web34403.mail.mud.yahoo.com> References: <489828.45501.qm@web34403.mail.mud.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Neel: Thanks that makes a LOT of sense.. So basically the mtx passed is NOT what is currently in td_lock and we want it updated as we switch. Cool.. then that makes the code look much clearer Thanks R On Jan 25, 2010, at 1:51 PM, Neelkanth Natu wrote: > Hi Randall, > > --- On Mon, 1/25/10, Randall Stewart <rrs@lakerest.net> wrote: > >> From: Randall Stewart <rrs@lakerest.net> >> Subject: Re: AR71XX RTC >> To: "Neelkanth Natu" <neelnatu@yahoo.com> >> Cc: "M. Warner Losh" <imp@bsdimp.com>, freebsd-mips@freebsd.org >> Date: Monday, January 25, 2010, 12:51 PM >> Neil: >> >> Thanks for the patch.. it does look good since the old >> code was tromping part of the old threads PCB which is >> definitely not right ;-0 .. I do have a question for you.. >> forgive my ignorance.. >> >> What exactly are we trying to switch here. It seems >> that cpu_switch(...) is now being called with >> oldtd, newtd and mtx... >> >> I see that the thread structure has a struct mutex *td_lock >> as >> its first member. But what is this supposed to be pointing >> to? >> And when we switch are we trying to take the >> >> oldtd->td_lock and place it into the newtd->td_lock >> >> Or? >> >> What... I guess I just don't have any context for whats >> going on.. >> > > I am not very sure about this myself so take this with a grain of > salt: > > When a thread is being switched out because it is on a sleep queue the > intent is that some other thread running on a different cpu should > not be > allowed to muck with this thread's state. To make this happen the > 'td_lock' > of 'oldtd' is switched from what it was originally (viz. the sleep > queue > chain lock) to 'blocked_lock'. The 'blocked_lock' is special because > it is always locked. This all happens in sched_switch(). > > cpu_switch() is passed the original value of 'oldtd->td_lock' > as the third argument. When the context is switched to 'newtd' we will > switch back the 'oldtd->td_lock' from 'blocked_lock' to its original > value. And this way we don't lose any wakeups that may happen while we > are in sched_switch(). > > At least that is my very naive understanding of it. CCing Attilio to > shed more light on this. > > best > Neel > >> R >> >> >> >> On Jan 25, 2010, at 12:41 PM, Neelkanth Natu wrote: >> >>> Hi Warner, >>> >>> The patch looks good. Please commit it. >>> >>> The reason we started seeing this recently is because >> of this: >>> http://svn.freebsd.org/viewvc/base/head/sys/kern/sched_4bsd.c?r1=202889&r2=202888&pathrev=202889 >>> >>> In particular the call to thread_block_lock() will >> point 'td_lock' to >>> 'blocked_lock' and if we don't switch it back in >> cpu_switch() then >>> anybody trying to call thread_lock() on the thread >> will panic. >>> >>> best >>> Neel >>> >>> --- On Mon, 1/25/10, M. Warner Losh <imp@bsdimp.com> >> wrote: >>> >>>> From: M. Warner Losh <imp@bsdimp.com> >>>> Subject: Re: AR71XX RTC >>>> To: neelnatu@yahoo.com >>>> Cc: gonzo@bluezbox.com, >> smeagle@bsdler.de, >> freebsd-mips@FreeBSD.org >>>> Date: Monday, January 25, 2010, 8:31 AM >>>> In message: <434364.57659.qm@web34405.mail.mud.yahoo.com> >>>> Neelkanth >> Natu >>>> <neelnatu@yahoo.com> >>>> writes: >>>> : Hi Flo, >>>> : >>>> : Can you try the following patch and see if it >> helps with >>>> the >>>> : hang-followed-by-trap problem? >>>> : >>>> : I am seeing a similar problem on the Sibyte and >> this >>>> patch gets me >>>> : past it. >>>> : >>>> : best >>>> : Neel >>>> : >>>> : Index: swtch.S >>>> : >>>> >> =================================================================== >>>> : --- swtch.S (revision 202961) >>>> : +++ swtch.S (working copy) >>>> : @@ -323,7 +323,7 @@ >>>> : * to be saved >> with >>>> the other registers do so here. >>>> : */ >>>> : >>>> : - sw a3, >>>> TD_LOCK(a0) >>>> # Switchout td_lock >>>> : + sw a2, >>>> TD_LOCK(a3) >>>> # Switchout td_lock >>>> : >>>> : mips_sw1: >>>> : #if defined(SMP) && >> defined(SCHED_ULE) >>>> >>>> I really like this patch. For the OCTEON I >> went from >>>> having all kinds >>>> of head-scratcher problems on boot that I was >> about to look >>>> at >>>> instruction traces in the simulator to try to >> track down to >>>> an >>>> immediate mountroot> prompt. So after >> reading the >>>> code, my first >>>> reaction is "how the heck did the old code work as >> well as >>>> it did?" >>>> and my second reaction is "This is obviously the >> right fix >>>> since a3 is >>>> a saved copy of a0, and a0 points to the pcb at >> this point, >>>> not the >>>> old thread." >>>> >>>> I've touched up the comments a bit. Maybe >> the >>>> register assignments is >>>> a bit of overkill, but this is a complicated >> function >>>> that's very >>>> tricky. What do you think of this patch: >>>> >>>> Index: sys/mips/mips/swtch.S >>>> >> =================================================================== >>>> --- sys/mips/mips/swtch.S (revision >>>> 202867) >>>> +++ sys/mips/mips/swtch.S (working >> copy) >>>> @@ -282,9 +282,10 @@ >>>> END(mips_cpu_throw) >>>> >>>> /* >>>> - *XXX Fixme: should be written to >> new >>>> interface that requires lock >>>> - * storage. We >>>> fake it for now. >>>> - * cpu_switch(struct thread *old, struct thread >> *new); >>>> + * cpu_switch(struct thread *old, struct thread >> *new, >>>> struct mutex *mtx); >>>> + * a0 - old >>>> + * a1 - new >>>> + * a2 - mtx >>>> * Find the highest priority process and >> resume it. >>>> */ >>>> NON_LEAF(cpu_switch, STAND_FRAME_SIZE, ra) >>>> @@ -323,7 +324,7 @@ >>>> * to be saved with the other >>>> registers do so here. >>>> */ >>>> >>>> - sw a3, >>>> TD_LOCK(a0) >>>> # Switchout td_lock >>>> + sw a2, >>>> TD_LOCK(a3) >>>> # Switchout td_lock >>>> >>>> mips_sw1: >>>> #if defined(SMP) && defined(SCHED_ULE) >>>> >>>> >>>> Thanks for saving me hours of debugging. :) >>>> >>>> Warner >>>> >>>> >>>> : --- On Sun, 1/24/10, Florian Kruegl <smeagle@bsdler.de> >>>> wrote: >>>> : >>>> : > From: Florian Kruegl <smeagle@bsdler.de> >>>> : > Subject: Re: AR71XX RTC >>>> : > To: "Oleksandr Tymoshenko" <gonzo@bluezbox.com> >>>> : > Cc: freebsd-mips@freebsd.org >>>> : > Date: Sunday, January 24, 2010, 8:52 AM >>>> : > Hi, >>>> : > >>>> : > On Sun, 2010-01-24 at 02:41 +0100, Florian >> Kruegl >>>> wrote: >>>> : > > On Sat, 2010-01-23 at 16:53 -0800, >> Oleksandr >>>> : > Tymoshenko wrote: >>>> : > > > On 2010-01-23, at 4:44 PM, >> Florian Kruegl >>>> wrote: >>>> : > > > >>>> : > > > > Hi, >>>> : > > > > >>>> : > > > > On Sat, 2010-01-23 at 16:21 >> -0800, >>>> Oleksandr >>>> : > Tymoshenko wrote: >>>> : > > > >> On 2010-01-23, at 4:00 >> PM, >>>> Florian >>>> : > Kruegl wrote: >>>> : > > > >> >>>> : > > > >>> Hi, >>>> : > > > >>> >>>> : > > > >>> anyone working on >> pfc2123 >>>> driver for >>>> : > RouterStation Pro? >>>> : > > > >>> Seems quite well >> documented, >>>> one >>>> : > issue might be CS hack, but the rest >>>> : > > > >>> should be straight. >>>> : > > > >> Driver was >> commited >>>> : > yesterday: >>>> : > > > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=202839 >>>> : > > > >> >>>> : > > > >> And yes, CS hack is the >> problem. >>>> I'm >>>> : > trying to figure out how to fit it into >> FreeBSD >>>> : > > > >> SPI framework. >>>> : > > > > >>>> : > > > > sounds good, will do an >> update as >>>> soon as i >>>> : > removed me work from code. >>>> : > > > > My CS "solution" was more >> than crude, >>>> but >>>> : > the frames simply didn't >>>> : > > > > fit... so I am looking >> forward for a >>>> : > different one :) >>>> : > > > >>>> : > > > Yeah, my >> CS solution was >>>> : > dirty hack too. If for "didn't fit" you >> mean missing >>>> last >>>> : > > > byte of frame then this problem >> was solved >>>> to. >>>> : > Bug was in AR71XX SPI code: falling >>>> : > > > edge was not provided for last >> byte in >>>> transfer >>>> : > in time and RTC chip acts of falling edge. >>>> : > > > Fix was committed before driver. >>>> : > > > >>>> : > > > >>>> : > > > >>>> : > > >>>> : > > code looks similar, can't tell much >> about >>>> result as >>>> : > kernel hangs for a >>>> : > > while before getting this: >>>> : > > >>>> : > >>>> >> <<<<<<<<<<<<<<<<<<<<<<<<<<< >>>> : > schnipp >>>> : > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> : > > Trap cause = 2 (TLB miss (load or >> instr. fetch) >>>> - >>>> : > kernel mode) >>>> : > > [thread pid 4 tid 100009 ] >>>> : > > Stopped at >>>> : > _thread_lock_flags+0x150: >>>> : > lw >> v0,60(a3) >>>> : > > db> bt >>>> : > > Tracing pid 4 tid 100009 td >> 0xc0c47270 >>>> : > > db_trace_thread+30 (?,?,?,?) ra >> 800a6c10 sz 24 >>>> : > > 800a6af4+11c (0,?,ffffffff,?) ra >> 800a6604 sz >>>> 32 >>>> : > > 800a6270+394 (?,?,?,?) ra 800a6794 sz >> 168 >>>> : > > db_command_loop+78 (?,?,?,?) ra >> 800a8e68 sz 24 >>>> : > > 800a8d60+108 (?,?,?,?) ra 80215ff8 sz >> 424 >>>> : > > kdb_trap+f8 (?,?,?,?) ra 80474350 sz >> 32 >>>> : > > trap+134c (?,?,?,?) ra 8046b7fc sz >> 176 >>>> : > > MipsKernGenException+100 >>>> (b,173,804d5de8,deadc0d8) ra >>>> : > 801c593c sz 200 >>>> : > > _thread_lock_flags+130 (?,?,?,?) ra >> 80221f18 sz >>>> 56 >>>> : > > sleepq_broadcast+ac (?,?,?,?) ra >> 801e5f20 sz >>>> 40 >>>> : > > wakeup+2c (?,?,?,?) ra 8016de18 sz 32 >>>> : > > g_io_deliver+198 (?,?,?,?) ra 8016bbd4 >> sz 80 >>>> : > > 8016b590+644 (?,?,?,?) ra 8016e184 sz >> 104 >>>> : > > g_io_schedule_down+2ec (?,?,?,?) ra >> 8016eb94 sz >>>> 64 >>>> : > > 8016eb18+7c (?,?,?,?) ra 801a331c sz >> 24 >>>> : > > fork_exit+a0 (?,?,?,?) ra 80478f10 sz >> 48 >>>> : > > fork_trampoline+10 (?,?,?,?) ra 0 sz >> 0 >>>> : > > pid 4 >>>> : > > >>>> : > >>>> >> <<<<<<<<<<<<<<<<<<<<<<<<<<< >>>> : > schnapp >>>> : > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> : > > >>>> : > > will use AR71XX as config file >> tomorrow, mine >>>> has many >>>> : > additional devs >>>> : > > configured for booting from usb >> devices. >>>> : > > >>>> : > [...] >>>> : > >>>> : > seems to make no difference. removed all >> mini pci >>>> : > devs and most code >>>> : > changes. kernel hangs during bootup for a >> while. >>>> then gets >>>> : > a trap. >>>> : > >>>> : > Source Info: >>>> : > >>>> : > -------------------------- schnipp >>>> : > -------------------------- >>>> : > brain:head> svn info >>>> : > Path: . >>>> : > URL: svn://svn.freebsd.org/base/head >>>> : > Repository Root: >> svn://svn.freebsd.org/base >>>> : > Repository UUID: >>>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>> : > Revision: 202904 >>>> : > Node Kind: directory >>>> : > Schedule: normal >>>> : > Last Changed Author: marcel >>>> : > Last Changed Rev: 202904 >>>> : > Last Changed Date: 2010-01-24 00:16:50 >> +0100 (Sun, >>>> 24 Jan >>>> : > 2010) >>>> : > -------------------------- schnapp >>>> : > -------------------------- >>>> : > >>>> : > -------------------------- schnipp >>>> : > -------------------------- >>>> : > brain:head> svn stat >>>> : > ? GRTAGS >>>> : > ? GSYMS >>>> : > ? GTAGS >>>> : > ? GPATH >>>> : > M >> sys/kern/vfs_mount.c >>>> : > M >> sys/mips/conf/AR71XX >>>> : > ? >> sys/dev/pfc2123 >>>> : > -------------------------- schnapp >>>> : > -------------------------- >>>> : > >>>> : > - vfs_mount should be far away. >>>> : > - sys/dev/pfc2123 is no longer used. >>>> : > - sys/mips/conf/AR71XX altered to include >>>> pfc2123_rtc >>>> : > >>>> : > >>>> : > -------------------------- schnipp >>>> : > -------------------------- >>>> : > FreeBSD 9.0-CURRENT #1: Sun Jan 24 15:58:37 >> UTC >>>> 2010 >>>> : > >>>> : > root@pinky.lan.terror.local:/home/smeagle/obj/mips/mips/home/ >> >>>> smeagle/src/freebsd/head/sys/AR71XX >>>> : > mips >>>> : > real memory = 134217728 (131072K >> bytes) >>>> : > avail memory = 125689856 (119MB) >>>> : > nexus0: <MIPS32 root nexus> >>>> : > clock0: <Generic MIPS32 ticker> on >> nexus0 >>>> : > clock0: [FILTER] >>>> : > apb0 at irq 4 on nexus0 >>>> : > apb0: [FILTER] >>>> : > uart0: <16550 or compatible> on apb0 >>>> : > uart0: [FILTER] >>>> : > uart0: console (115200,n,8,1) >>>> : > pcib0 at irq 0 on nexus0 >>>> : > pcib0: [FILTER] >>>> : > pci0: <PCI bus> on pcib0 >>>> : > pci0: <old, non-VGA display device> >> at device >>>> 0.0 (no >>>> : > driver attached) >>>> : > pci0: <processor> at device 17.0 (no >> driver >>>> : > attached) >>>> : > arge0: <Atheros AR71xx built-in >> ethernet >>>> interface> >>>> : > at mem >>>> : > 0x19000000-0x19000fff irq 2 on nexus0 >>>> : > miibus0: <MII bus> on arge0 >>>> : > ukphy0: <Generic IEEE 802.3u media >> interface> >>>> PHY 4 >>>> : > on miibus0 >>>> : > ukphy0: 10baseT, 10baseT-FDX, >> 100baseTX, >>>> : > 100baseTX-FDX, 1000baseT-FDX, >>>> : > auto >>>> : > arge0: Ethernet address: 00:00:00:00:46:61 >>>> : > arge0: [FILTER+ITHREAD] >>>> : > arge1: <Atheros AR71xx built-in >> ethernet >>>> interface> >>>> : > at mem >>>> : > 0x1a000000-0x1a000fff irq 3 on nexus0 >>>> : > arge1: Ethernet address: 00:00:00:00:46:62 >>>> : > arge1: [FILTER+ITHREAD] >>>> : > spi0: <AR71XX SPI> at mem >>>> 0x1f000000-0x1f00000f on >>>> : > nexus0 >>>> : > spibus0: <spibus bus> on spi0 >>>> : > mx25l0: <M25Pxx Flash Family> at cs 0 >> on >>>> spibus0 >>>> : > mx25l0: mx25ll128, sector 65536 bytes, 256 >> sectors >>>> : > ar71xx_wdog0: <Atheros AR71XX watchdog >> timer> >>>> on >>>> : > nexus0 >>>> : > Timecounter "MIPS32" frequency 360000000 Hz >> quality >>>> 800 >>>> : > Timecounters tick every 1.000 msec >>>> : > bootpc_init: wired to interface 'arge0' >>>> : > Sending DHCP Discover packet from interface >> arge0 >>>> : > (00:00:00:00:46:61) >>>> : > arge0: link state changed to DOWN >>>> : > Trap cause = 2 (TLB miss (load or instr. >> fetch) - >>>> kernel >>>> : > mode) >>>> : > [thread pid 4 tid 100008 ] >>>> : > Stopped at >>>> : > _thread_lock_flags+0x150: >>>> : > lw >> v0,60(a3) >>>> : > db> bt >>>> : > Tracing pid 4 tid 100008 td 0xc0c414e0 >>>> : > db_trace_thread+30 (?,?,?,?) ra 80055900 sz >> 24 >>>> : > 800557e4+11c (0,?,ffffffff,?) ra 800552f4 >> sz 32 >>>> : > 80054f60+394 (?,?,?,?) ra 80055484 sz 168 >>>> : > db_command_loop+78 (?,?,?,?) ra 80057b58 sz >> 24 >>>> : > 80057a50+108 (?,?,?,?) ra 8017b7d8 sz 424 >>>> : > kdb_trap+f8 (?,?,?,?) ra 8035ab40 sz 32 >>>> : > trap+134c (?,?,?,?) ra 80351fec sz 176 >>>> : > MipsKernGenException+100 >> (b,173,8039ce74,deadc0d8) >>>> ra >>>> : > 8012c92c sz 200 >>>> : > _thread_lock_flags+130 (?,?,?,?) ra >> 801876f8 sz 56 >>>> : > sleepq_broadcast+ac (?,?,?,?) ra 8014b700 >> sz 40 >>>> : > wakeup+2c (?,?,?,?) ra 800d6ba8 sz 32 >>>> : > g_io_deliver+198 (?,?,?,?) ra 800d4964 sz >> 80 >>>> : > 800d4320+644 (?,?,?,?) ra 800d6f14 sz 104 >>>> : > g_io_schedule_down+2ec (?,?,?,?) ra >> 800d7924 sz 64 >>>> : > 800d78a8+7c (?,?,?,?) ra 8010c0ac sz 24 >>>> : > fork_exit+a0 (?,?,?,?) ra 8035f700 sz 48 >>>> : > fork_trampoline+10 (?,?,?,?) ra 0 sz 0 >>>> : > pid 4 >>>> : > -------------------------- schnapp >>>> : > -------------------------- >>>> : > >>>> : > >>>> : > >>>> : > >>>> : > Flo >>>> : > >>>> : > >> _______________________________________________ >>>> : > freebsd-mips@freebsd.org >>>> : > mailing list >>>> : > http://lists.freebsd.org/mailman/listinfo/freebsd-mips >>>> : > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org >> >>>> " >>>> : > >>>> : >>>> : >>>> : >>>> : _______________________________________________ >>>> : freebsd-mips@freebsd.org >>>> mailing list >>>> : http://lists.freebsd.org/mailman/listinfo/freebsd-mips >>>> : To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org >> >>>> " >>>> : >>>> : >>>> >>> >>> >>> >>> _______________________________________________ >>> freebsd-mips@freebsd.org >> mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-mips >>> To unsubscribe, send any mail to "freebsd-mips- >>> unsubscribe@freebsd.org" >>> >> >> ------------------------------ >> Randall Stewart >> 803-317-4952 (cell) >> 803-345-0391(direct) >> >> > > > > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?74D48EE5-544E-44D4-9644-2349E9AA9796>