re weird bug
pyunyh at gmail.com
Sun Nov 16 20:18:37 PST 2008
On Sat, Nov 15, 2008 at 09:13:15AM +0100, Milan Obuch wrote:
> On Tuesday 04 November 2008 02:46:04 Pyun YongHyeon wrote:
> > On Mon, Nov 03, 2008 at 11:39:06PM +0100, Milan Obuch wrote:
> > > On Monday 03 November 2008 04:59:08 Pyun YongHyeon wrote:
> > >
> > > [ snip ]
> > >
> > > > I vaguely guess hardware was not properly initialized. How about
> > > > this one?
> > > > http://people.freebsd.org/~yongari/re/re.phy.patch.20081103
> > >
> > > This bug seems again to disappear - csup two days ago, kernel built with
> > > no patches and everything works. Something like this happened already in
> > > the
> > Yeah, this is one of reason that makes it hard to fix.
> > > past. No idea whether it has something with if_re being built as module,
> > > but if it happens again, I will test this possibility, too.
> > Ok. Please let me know your findings.
> Strange. This trouble occured again. Two days ago, fresh csup, rebuilt whole
> system, re works only when with verbose boot logging. Yesterday, fresh csup,
> full rebuild, re works again. There is no change in if_re.c at all - it is
> dated Sep 9, 2008. This is coming from somewhere else, but I have no idea how
> this could be debugged. One possibility is there is some weird issue with
> code or maybe more probably buffer placement in memory, but this is just a
> shot in the wild, and no idea what means could be used to trace that.
> It occurs to me from time to time, only with -current, everytime verbose boot
> logging masks the trouble, at least everytime I tried. Really weird, not
> predictable. And maybe only difference tracking one per one could give some
If verbose boot always hide the issye how about adding a DELAY in
re_attach()? You may add a DELAY line, say DELAY(2000), before any
PHY access(around line number 1307 in if_re.c)
Did it make difference?
> clue, but this is really time consuming (apply change, rebuild kernel,
> reboot, test... grrr).
More information about the freebsd-net