Date: Mon, 25 Jan 2010 13:51:48 -0800 (PST) From: Neelkanth Natu <neelnatu@yahoo.com> To: Randall Stewart <rrs@lakerest.net> Cc: attilio@freebsd.org, freebsd-mips@freebsd.org Subject: Re: AR71XX RTC Message-ID: <489828.45501.qm@web34403.mail.mud.yahoo.com> In-Reply-To: <5D3E417C-FE51-49A7-B8CC-564932BF0D3E@lakerest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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) > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?489828.45501.qm>