dmesg bug
A friend of mine has old Asus A3F and I have found a very interesting bug in dmesg. When I type dmesg I don't get regular dmesg output. It starts in the middle of regular dmesg output and then it prints it 2 more times. dmesg output http://cleancode.cz/files/dmesg.log acpidump http://cleancode.cz/files/acpidump_asus.tar.gz
Re: dmesg bug
On 09/06/10 16:18, Tomas Vavrys wrote: > A friend of mine has old Asus A3F and I have found a very interesting > bug in dmesg. When I type dmesg I don't get regular dmesg output. It > starts in the middle of regular dmesg output and then it prints it 2 > more times. $ whatis dmesg dmesg (8) - display the system message buffer The buffer is not emptied on reboot on all machines. What you see is likely leftovers from previous boot(s).
Re: dmesg bug
On 09/06/10 10:39, Alexander Hall wrote: > On 09/06/10 16:18, Tomas Vavrys wrote: >> A friend of mine has old Asus A3F and I have found a very interesting >> bug in dmesg. When I type dmesg I don't get regular dmesg output. It >> starts in the middle of regular dmesg output and then it prints it 2 >> more times. > > $ whatis dmesg > dmesg (8) - display the system message buffer > > The buffer is not emptied on reboot on all machines. What you see is > likely leftovers from previous boot(s). and at times, this is a wonderful feature. (and usually when I most want it, it is on a machine which wipes memory on boot. :-/ ) Nick.
Re: dmesg bug
Ah, I see. Thank you. I didn't know about it before. 2010/9/6 Nick Holland : > On 09/06/10 10:39, Alexander Hall wrote: >> On 09/06/10 16:18, Tomas Vavrys wrote: >>> A friend of mine has old Asus A3F and I have found a very interesting >>> bug in dmesg. When I type dmesg I don't get regular dmesg output. It >>> starts in the middle of regular dmesg output and then it prints it 2 >>> more times. >> >> $ whatis dmesg >> dmesg (8) - display the system message buffer >> >> The buffer is not emptied on reboot on all machines. What you see is >> likely leftovers from previous boot(s). > > and at times, this is a wonderful feature. > (and usually when I most want it, it is on a machine which wipes memory > on boot. :-/ ) > > Nick.
Re: dmesg bug
cat /var/run/dmesg.boot > A friend of mine has old Asus A3F and I have found a very interesting > bug in dmesg. When I type dmesg I don't get regular dmesg output. It > starts in the middle of regular dmesg output and then it prints it 2 > more times.
ath.c -> dmesg -> bug
Hi All, I try to analyse my dmesg with: # dmesg | grep ath0 and I can see ERROR message: > ath0 device timeout ... I have checked "ath.c" file in "/cvs/src/sys/dev/ic/" on stable branch. I found this one construction: "--sc->sc_tx_time == 0". Probably it's meen "0 == 0", I have made this patch (see in attachment) and now it's working without any ERROR/WARNING for me. Please confirm. If my FIX for "ath.c" is correct, please update cvs in new 6.4 Release. Many Thanks & Sorry for my English. Oleg Pahl (München) Index: ath.c === RCS file: /cvs/src/sys/dev/ic/ath.c,v retrieving revision 1.116 diff -u -p -u -r1.116 ath.c --- ath.c 31 Jan 2018 11:27:03 - 1.116 +++ ath.c 11 Oct 2018 00:06:54 - @@ -930,7 +930,7 @@ ath_watchdog(struct ifnet *ifp) if ((ifp->if_flags & IFF_RUNNING) == 0 || sc->sc_invalid) return; if (sc->sc_tx_timer) { - if (--sc->sc_tx_timer == 0) { + if (sc->sc_tx_timer == 0) { printf("%s: device timeout\n", ifp->if_xname); ath_reset(sc, 1); ifp->if_oerrors++; Index: ath.c === RCS file: /cvs/src/sys/dev/ic/ath.c,v retrieving revision 1.116 diff -u -p -u -r1.116 ath.c --- ath.c 31 Jan 2018 11:27:03 - 1.116 +++ ath.c 11 Oct 2018 00:06:54 - @@ -930,7 +930,7 @@ ath_watchdog(struct ifnet *ifp) if ((ifp->if_flags & IFF_RUNNING) == 0 || sc->sc_invalid) return; if (sc->sc_tx_timer) { - if (--sc->sc_tx_timer == 0) { + if (sc->sc_tx_timer == 0) { printf("%s: device timeout\n", ifp->if_xname); ath_reset(sc, 1); ifp->if_oerrors++;
Re: ath.c -> dmesg -> bug
On Wed, Oct 10, 2018 at 3:35 PM NN wrote: > I try to analyse my dmesg with: > > # dmesg | grep ath0 > > and I can see ERROR message: > > > ath0 device timeout ... > > I have checked "ath.c" file in "/cvs/src/sys/dev/ic/" on stable branch. > > I found this one construction: "--sc->sc_tx_time == 0". Probably it's > meen "0 == 0", > I have made this patch (see in attachment) and now it's working without > any ERROR/WARNING for me. > > Please confirm. > > If my FIX for "ath.c" is correct, please update cvs in new 6.4 Release. > ... > --- ath.c31 Jan 2018 11:27:03 -1.116 > +++ ath.c11 Oct 2018 00:06:54 - > @@ -930,7 +930,7 @@ ath_watchdog(struct ifnet *ifp) > if ((ifp->if_flags & IFF_RUNNING) == 0 || sc->sc_invalid) > return; > if (sc->sc_tx_timer) { > -if (--sc->sc_tx_timer == 0) { > +if (sc->sc_tx_timer == 0) { > This diff cannot be correct: the condition right above it is only true if sc->sc_tx_timer is non-zero, so then testing whether it is _currently_ zero will never be true. That's also the only place sc->sc_tx_timer is decremented, so deleting the '--' disables the timeout. The existing code decrements it and then tests whether it's zero, effectively testing whether sc->sc_tx_timer was exactly 1. Your work to update the driver in the thread from October 5th is a more productive way to address the issues you're experiencing. Philip Guenther