Re: Help diagnose my Ryzen build problem
On Mon, 27 Aug 2018 16:16:47 +0300 "karu.pruun" wrote: > On Mon, Aug 27, 2018 at 3:21 PM Meowthink wrote: > > That's kib, who has committed things in that script to both 12 [1] and > > stable/11 [2]. > > > > Unfortunately, that's for Ryzens family 17h model 00h-0fh, whereas my > > Ryzen 5 2400G's model is 11h. > > > > On the microcode. It shall be updated through UEFI/BIOS updates. I > > think mine is now PinnaclePI-AM4_1.0.0.4 with microcode patchlevel > > 0x810100b. > > > > Seems like ... the only thing I can do is sit down and wait? > > The revision > > https://svnweb.freebsd.org/base/head/sys/x86/x86/cpu_machdep.c?r1=336763&r2=336762&pathrev=336763 > > works around the mwait issue, i.e. it sets > > sysctl machdep.idle_mwait=0 > sysctl machdep.idle=hlt > > Now it may or may not relate to your problem, but it appears that > Ryzen 2400G also has another issue with HLT, see the DragonFly bug > report > > https://bugs.dragonflybsd.org/issues/3131 > > which AMD is aware of and is possibly working on, but it may not have > appeared in the errata yet. The bug report says that until this is > fixed, the workaround is to also disable HLT in cpu_idle. I am not > sure what is the correct value for the sysctl on FreeBSD, perhaps > > sysctl machdep.idle=0 > > or some other value? > It is in the latest errata and there are no plans to fix it. Based on the detailed description, this is a problem only in a hypervisor. AMD has a suggested workaround for it. -- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Help diagnose my Ryzen build problem
On Mon, 27 Aug 2018 20:18:46 +0800 Meowthink wrote: > Hi Gary, > > On 8/27/18, Gary Jennejohn wrote: > > On Mon, 27 Aug 2018 10:13:10 +0200 > > Phil Norman wrote: > > > >> Hi. > >> > >> I have a similar setup: Ryzen 3 and Fatal1ty X370 mini-ITX. I had some > >> trouble with instability, although my problems weren't panics, but rather > >> two issues. One was random lockups (with no evidence left in logs), but I > >> *think* this was down to an inadequately cooled graphics card. > >> > > > > I had instability problems with my Ryzen 5 - lockups for no > > apparent reason. The only recourse waas a hard reset. > > > > It turned out that there were two causes > > 1) old CPU microcode > > 2) unhandled errate in the CPU > > > > I installed the /usr/ports/sysutils/devcpu-data port, which > > allowed me to install the latest microcode using cpucontrol(8). > > > > I also used a shell script called amd_errata.sh provided by one of > > the FreeBSD committers. To my shame I can't remember exactly > > who. Note that the errata fixups are now part of the kernel in > > FreeBSD 12. > > That's kib, who has committed things in that script to both 12 [1] and > stable/11 [2]. > > Unfortunately, that's for Ryzens family 17h model 00h-0fh, whereas my > Ryzen 5 2400G's model is 11h. > AMD has also relased a Revision Guide for Family 11h. Lots of errata listed there, but I didn't look at it closely enough to say whether any are relevant to lockups. > On the microcode. It shall be updated through UEFI/BIOS updates. I > think mine is now PinnaclePI-AM4_1.0.0.4 with microcode patchlevel > 0x810100b. > Well, I installed the latest BIOS for my ASUS B350M-A also, but it was no help. The lockups disappear only after I installed the latest microde using the port. > Seems like ... the only thing I can do is sit down and wait? > > > > > After taking these steps about two months ago I have had no more > > lockups and the machine runs very stabily. > > > > [big snip] > > > > -- > > Gary Jennejohn > > > > [1] https://svnweb.freebsd.org/base?view=revision&revision=336763 > [2] https://svnweb.freebsd.org/base?view=revision&revision=337235 -- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Help diagnose my Ryzen build problem
On Mon, 27 Aug 2018 10:13:10 +0200 Phil Norman wrote: > Hi. > > I have a similar setup: Ryzen 3 and Fatal1ty X370 mini-ITX. I had some > trouble with instability, although my problems weren't panics, but rather > two issues. One was random lockups (with no evidence left in logs), but I > *think* this was down to an inadequately cooled graphics card. > I had instability problems with my Ryzen 5 - lockups for no apparent reason. The only recourse waas a hard reset. It turned out that there were two causes 1) old CPU microcode 2) unhandled errate in the CPU I installed the /usr/ports/sysutils/devcpu-data port, which allowed me to install the latest microcode using cpucontrol(8). I also used a shell script called amd_errata.sh provided by one of the FreeBSD committers. To my shame I can't remember exactly who. Note that the errata fixups are now part of the kernel in FreeBSD 12. After taking these steps about two months ago I have had no more lockups and the machine runs very stabily. [big snip] -- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
On Mon, 12 Dec 2011 08:04:37 -0800 m...@freebsd.org wrote: > On Mon, Dec 12, 2011 at 7:32 AM, Gary Jennejohn > wrote: > > On Mon, 12 Dec 2011 15:13:00 + > > Vincent Hoffman wrote: > > > >> > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> On 12/12/2011 13:47, O. Hartmann wrote: > >> > > >> >> Not fully right, boinc defaults to run on idprio 31 so this isn't an > >> >> issue. And yes, there are cases where SCHED_ULE shows much better > >> >> performance then SCHED_4BSD. [...] > >> > > >> > Do we have any proof at hand for such cases where SCHED_ULE performs > >> > much better than SCHED_4BSD? Whenever the subject comes up, it is > >> > mentioned, that SCHED_ULE has better performance on boxes with a ncpu > > >> > 2. But in the end I see here contradictionary statements. People > >> > complain about poor performance (especially in scientific environments), > >> > and other give contra not being the case. > >> It all a little old now but some if the stuff in > >> http://people.freebsd.org/~kris/scaling/ > >> covers improvements that were seen. > >> > >> http://jeffr-tech.livejournal.com/5705.html > >> shows a little too, reading though Jeffs blog is worth it as it has some > >> interesting stuff on SHED_ULE. > >> > >> I thought there were some more benchmarks floating round but cant find > >> any with a quick google. > >> > >> > >> Vince > >> > >> > > >> > Within our department, we developed a highly scalable code for planetary > >> > science purposes on imagery. It utilizes present GPUs via OpenCL if > >> > present. Otherwise it grabs as many cores as it can. > >> > By the end of this year I'll get a new desktop box based on Intels new > >> > Sandy Bridge-E architecture with plenty of memory. If the colleague who > >> > developed the code is willing performing some benchmarks on the same > >> > hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most > >> > recent Suse. For FreeBSD I intent also to look for performance with both > >> > different schedulers available. > >> > > > > > These observations are not scientific, but I have a CPU from AMD with > > 6 cores (AMD Phenom(tm) II X6 1090T Processor). > > > > My simple test was ``make buildkernel'' while watching the core usage with > > gkrellm. > > > > With SCHED_4BSD all 6 cores are loaded to 97% during the build phase. > > I've never seen any value above 97% with gkrellm. > > > > With SCHED_ULE I never saw all 6 cores loaded this heavily. Usually > > 2 or more cores were at or below 90%. Not really that significant, but > > still a noticeable difference in apparent scheduling behavior. Whether > > the observed difference is due to some change in data from the kernel to > > gkrellm is beyond me. > > SCHED_ULE is much sloppier about calculating which thread used a > timeslice -- unless the timeslice went 100% to a thread, the fraction > it used may get attributed elsewhere. So top's reporting of thread > usage is not a useful metric. Total buildworld time is, potentially. > I suspect you're right since the buildworld time, a much better test, was pretty much the same with 4BSD and ULE. -- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
On Mon, 12 Dec 2011 17:10:46 +0100 Lars Engels wrote: > Did you use -jX to build the world? > I'm top posting since Lars did. It was buildkernel, not buildworld. Yes, -j6. > _____ > Von: Gary Jennejohn > Versendet am: Mon Dec 12 16:32:21 MEZ 2011 > An: Vincent Hoffman > CC: "O. Hartmann" , Current FreeBSD > , freebsd-stable@freebsd.org, > freebsd-performa...@freebsd.org > Betreff: Re: SCHED_ULE should not be the default > > > On Mon, 12 Dec 2011 15:13:00 + > Vincent Hoffman wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 12/12/2011 13:47, O. Hartmann wrote: > > > > > >> Not fully right, boinc defaults to run on idprio 31 so this isn't an > > >> issue. And yes, there are cases where SCHED_ULE shows much better > > >> performance then SCHED_4BSD. [...] > > > > > > Do we have any proof at hand for such cases where SCHED_ULE performs > > > much better than SCHED_4BSD? Whenever the subject comes up, it is > > > mentioned, that SCHED_ULE has better performance on boxes with a ncpu > > > > 2. But in the end I see here contradictionary statements. People > > > complain about poor performance (especially in scientific environments), > > > and other give contra not being the case. > > It all a little old now but some if the stuff in > > http://people.freebsd.org/~kris/scaling/ > > covers improvements that were seen. > > > > http://jeffr-tech.livejournal.com/5705.html > > shows a little too, reading though Jeffs blog is worth it as it has some > > interesting stuff on SHED_ULE. > > > > I thought there were some more benchmarks floating round but cant find > > any with a quick google. > > > > > > Vince > > > > > > > > Within our department, we developed a highly scalable code for planetary > > > science purposes on imagery. It utilizes present GPUs via OpenCL if > > > present. Otherwise it grabs as many cores as it can. > > > By the end of this year I'll get a new desktop box based on Intels new > > > Sandy Bridge-E architecture with plenty of memory. If the colleague who > > > developed the code is willing performing some benchmarks on the same > > > hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most > > > recent Suse. For FreeBSD I intent also to look for performance with both > > > different schedulers available. > > > > > These observations are not scientific, but I have a CPU from AMD with > 6 cores (AMD Phenom(tm) II X6 1090T Processor). > > My simple test was ``make buildkernel'' while watching the core usage with > gkrellm. > > With SCHED_4BSD all 6 cores are loaded to 97% during the build phase. > I've never seen any value above 97% with gkrellm. > > With SCHED_ULE I never saw all 6 cores loaded this heavily. Usually > 2 or more cores were at or below 90%. Not really that significant, but > still a noticeable difference in apparent scheduling behavior. Whether > the observed difference is due to some change in data from the kernel to > gkrellm is beyond me. > > -- > Gary Jennejohn > _ > > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
On Mon, 12 Dec 2011 15:13:00 + Vincent Hoffman wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/12/2011 13:47, O. Hartmann wrote: > > > >> Not fully right, boinc defaults to run on idprio 31 so this isn't an > >> issue. And yes, there are cases where SCHED_ULE shows much better > >> performance then SCHED_4BSD. [...] > > > > Do we have any proof at hand for such cases where SCHED_ULE performs > > much better than SCHED_4BSD? Whenever the subject comes up, it is > > mentioned, that SCHED_ULE has better performance on boxes with a ncpu > > > 2. But in the end I see here contradictionary statements. People > > complain about poor performance (especially in scientific environments), > > and other give contra not being the case. > It all a little old now but some if the stuff in > http://people.freebsd.org/~kris/scaling/ > covers improvements that were seen. > > http://jeffr-tech.livejournal.com/5705.html > shows a little too, reading though Jeffs blog is worth it as it has some > interesting stuff on SHED_ULE. > > I thought there were some more benchmarks floating round but cant find > any with a quick google. > > > Vince > > > > > Within our department, we developed a highly scalable code for planetary > > science purposes on imagery. It utilizes present GPUs via OpenCL if > > present. Otherwise it grabs as many cores as it can. > > By the end of this year I'll get a new desktop box based on Intels new > > Sandy Bridge-E architecture with plenty of memory. If the colleague who > > developed the code is willing performing some benchmarks on the same > > hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most > > recent Suse. For FreeBSD I intent also to look for performance with both > > different schedulers available. > > These observations are not scientific, but I have a CPU from AMD with 6 cores (AMD Phenom(tm) II X6 1090T Processor). My simple test was ``make buildkernel'' while watching the core usage with gkrellm. With SCHED_4BSD all 6 cores are loaded to 97% during the build phase. I've never seen any value above 97% with gkrellm. With SCHED_ULE I never saw all 6 cores loaded this heavily. Usually 2 or more cores were at or below 90%. Not really that significant, but still a noticeable difference in apparent scheduling behavior. Whether the observed difference is due to some change in data from the kernel to gkrellm is beyond me. -- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: machdep.hlt_cpus not safe with ULE?
On Sat, 19 Feb 2011 12:36:57 - "Steven Hartland" wrote: > I'm trying to debug a possibly failing CPU, so I thought it would > be easy just disable the cores using machdep.hlt_cpus and see if > we see the panic's we've been seeing. > > The problem is it seems ULE doesnt properly support machdep.hlt_cpus > and still schedules processes onto the halted cpus which obviously > causes problems. > > Can anyone confirm this behaviour? Should machdep.hlt_cpus and I assume > the logical counterpart never be used with ULE? > Looking at the kernel source it appears that only sched_4bsd.c makes use of hlt_cpus_mask. -- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: RFC vgrind in base (and buildworld)
On Fri, 21 Jan 2011 23:20:09 +0100 Ulrich Spörlein wrote: > On Thu, 20.01.2011 at 21:17:40 +0100, Ulrich Spörlein wrote: > > Hello, > > > > Currently our buildworld relies on groff(1) and vgrind(1) being present > > in the host system. I have a patch ready that at least makes sure these > > are built during bootstrap-tools and completes the WITHOUT_GROFF flag. > > > > vgrind(1) is only used for two papers under share/doc and we could > > easily expand the results and commit them to svn directly, alleviating > > the need to run vgrind(1) during buildworld. > > > > OTOH, there are much more useful tools to vgrind(1) for source code > > formatting. So do we still have vgrind(1) users out there? > > > > Regards, > > Uli > > [trying to get this thread back on track] > > Does anyone actually care about vgrind in base? Will people be angry if > I unroll the 2 cases where it is used under share/doc? > I personally have never used vgrind, but since it's available as part of /usr/ports/textproc/heirloom-doctools IMO it would be safe to remove it from base, maybe with a note in UPDATING. -- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: random FreeBSD panics
On Sat, 3 Apr 2010 12:51:46 + Masoom Shaikh wrote: > On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras wrote: > > On 28 March 2010 16:42, Masoom Shaikh wrote: > > > >> lets assume if this is h/w problem, then how can other OSes overcome > >> this ? is there a way to make FreeBSD ignore this as well, let it > >> result in reasonable performance penalty. > > > > Very probably, if only we could detect where the problem is. > > Try adding "options __ __ PRINTF_BUFR_SIZE=128" to the kernel > > configuration file if you can, to see if you can get a less mangled > > log outout. > > > > ok, after few days of silence I am back with more questions > this time system feels little better, it is able to sustain for more > time that what 7.3-RELEASE could > > FreeBSD raptor 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Thu Apr 1 > 01:20:45 UTC 2010 root@:/usr/obj/usr/src/sys/INSPIRON amd64 > > I am using KDE4, and when OS freezes, well it freezes, means I cannot > change to tty0 and see the panic text, if any it might possibly have > spit. the stuck frozen GUI keeps staring there. So the question is how > to I capture that panic text ? unfortunately I am not getting core > files too, so there is nothing I can pick up hints > > is there some option (KDB, DDB), so that on panic system drop to debugger ? > [trimmed Cc - no need to send this to 3 MLs] There's no code in the kernel to switch back out of graphics mode (i.e. what X uses) when a panic happens. You probably can switch to v0, but you won't be able to see it. The only sure-fire way is to hook up a screen (terminal, laptop or another computer) to a serial port. -- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Firefox 3.6.X and Thunderbird 3.0.X crashing with Radeon graphics on FBSD 8.0-STABLE SMP/sm64 box
On Wed, 24 Mar 2010 13:32:40 + "O. Hartmann" wrote: > Since the introduction of Thunderbird 3.0 and Firefox 3.6 I see > spontanous crashes/coredumps of both thunderbird and firefox. Interingly > Firefox 3.5.X works well on he same platform. > > The platform is a FreeBSD 8.0-STABLE/amd64 (r205536: Tue Mar 23 22:19:04 > CET 2010), SMP box with 8GB of RAM, QuadCore Intel Q6600 on a P35-based > motherboard. > > Thunderbird 3 crashes rarely compared to Firefox 3. The longer the > application thunderbird runs, the higher the likelyhood the app crashes > and vanishes. Sometimes this happens immediately after starting > thunderbird, sometimes it takes its few minutes or half an hour. > > Firefox 3 is sensitive to its pull-down menus or requester showing up in > some situations. I can provoke a crash by clicking onto a pull-down-menu > in firefox 3, it immediately dumps a core. > If you suspect the graphics card's driver is at fault then I would try linux-opera or even linux-firefox and see whether it also dies when you use a drop-down menu. Another possibility would be to set hw.physmem to say 3G or 4G in loader.conf and see whether that affects thunderbird/firefox. Who knows, there may some weird problem caused by all that memory? That would a fairly quick and cheap way to test this. -- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: www/firefox: Firefox 3.6 crashes, Firefox 3.5.7 not
On Tue, 09 Feb 2010 09:41:34 + "O. Hartmann" wrote: [snip maybe too much] > On 02/08/10 21:42, Eitan Adler wrote: > > you need to load the sem module (kldload sem). > > > SysV smaphore (or sem?) are built into my kernel by default. The > error/system message when crashing is > > socket(): Protocol not supported > Illegal instruction (core dumped) > > and a core is dumped. > So, have you looked at the core dump with gdb to see where it appears to be crashing? Could it be IPv6 related? Do you have IPv6 in the kernel and enabled? I do. You could try adding these options to MOZ_OPTIONS in the Makefile --enable-debug[=DBG]Enable building with developer debug info --enable-debug-modules Enable/disable debug info for specific modules --enable-debugger-info-modules Enable/disable debugger info for specific modules --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: www/firefox: Firefox 3.6 crashes, Firefox 3.5.7 not
On Mon, 08 Feb 2010 13:32:25 + "O. Hartmann" wrote: > Today, I upgraded Firefox 3.5.7 (built yesterday) to Firefox 3.6. After > deleting ~/.mozilla (after I did a buckup, of course), I tried a fresh > start of 'firefox3'. After firefox showed up, I realized that no > option-field (File, Extras etc) can be used, they are dead and after a > few seconds I clicked them, firefox3 is crashing. > > Since I recompiled firefox 3.5.7 yesterday I was wondering if this is > due to some 'false' lib or dependency. Since I figured that I have > similar trouble with Thunderbird 3.0.1 after I installed it, I suspect a > faulty library causing this behaviour. With Thunderbird 3, I never > solved the problem although I tried to rebuild everything with > thunderbird via 'portmaster -f'. I'll did this with firefox 3.6 also, > but with no success. > > The crashing is observed on two nearly identical SMP FreeBSD 8.0/amd64 > STABLE boxes (make world of today), up-to-date ports. The crash is NOT > observed on my private oldish UP box, nearly the same setup, OS at the > same revision and ports up to date as of yesterday. Maybe this could be > a hint. > > Any hints or suggestions? > Try doing "ldd /usr/local/lib/firefox3/firefox-bin" and see if anything looks weird. You can porbably ignore /usr/local/lib/firefox3/firefox-bin: libxul.so => not found (0x0) libmozjs.so => not found (0x0) libxpcom.so => not found (0x0) because run-mozilla.sh sets LD_LIBRARY_PATH to include /usr/local/lib/firefox3 where these libraries are installed. I merely deleted my old firefox 3.6 and reinstalled from the port (on 9-CURRENT AMD64) and haven't seen any problems. But of course, I've been running various incarnations of 3.6 for a while and may have gotten all the dependencies already correctly installed. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Pack of CAM improvements
On Sun, 24 Jan 2010 18:48:15 +0200 Alexander Motin wrote: > Gary Jennejohn wrote: > > I started seeing a problem a few days ago with one of my DVD drives (a > > burner at cd0) under 9-current, which makes it impossible to use it even > > to simply read a DVD. > > > > Here the (rather strange IMO) output in dmesg: > > > > cd0: Removable CD-ROM SCSI-0 device > > cd0: 66.700MB/s transfers (UDMA4, PIO size 65534bytes) > > cd0: Attempt to query device size failed: UNIT ATTENTION, Power on, reset, > > or bus device reset occurred > > cd1 at ata0 bus 0 scbus6 target 1 lun 0 > > cd1: Removable CD-ROM SCSI-0 device > > cd1: 33.300MB/s transfers (UDMA2, PIO size 65534bytes) > > cd1: Attempt to query device size failed: NOT READY, Medium not present - > > tray closed > > > > I haven't the foggiest why cd0 behaves diffrently from cd1, which is a > > vanilla DVD drive and just works. > > I am not sure yet what triggered these changes. May be just some timing > issue. That UNIT ATTENTION seems reasonable, as reset indeed just > happened there. The real problem is that CAM had several limitations in > SCSI status handling, when working with ATAPI or USB devices. It made > request processing stop in some cases, where retries would be expected. > > New patch version should handle this and some other problems: > http://people.freebsd.org/~mav/cam-ata.20100124.patch > > Try it please. Thanks. > This patch works extremely well! Thanks. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Pack of CAM improvements
On Sat, 23 Jan 2010 15:07:47 +0100 (CET) Juergen Lock wrote: > But what > this still doesn't fix is the broken `test unit ready' command on ada > devices, which also makes things like `cdrecord -scanbus' hang the bus. :( > (A few days ago I also got a hang after wanting to try out xfburn, > I suspect for the same reason...) > > Here is my earlier report: > http://docs.freebsd.org/cgi/mid.cgi?20090817163144.GA2991 > I started seeing a problem a few days ago with one of my DVD drives (a burner at cd0) under 9-current, which makes it impossible to use it even to simply read a DVD. Here the (rather strange IMO) output in dmesg: cd0: Removable CD-ROM SCSI-0 device cd0: 66.700MB/s transfers (UDMA4, PIO size 65534bytes) cd0: Attempt to query device size failed: UNIT ATTENTION, Power on, reset, or bus device reset occurred cd1 at ata0 bus 0 scbus6 target 1 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 33.300MB/s transfers (UDMA2, PIO size 65534bytes) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed I haven't the foggiest why cd0 behaves diffrently from cd1, which is a vanilla DVD drive and just works. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: thunderbird3: dies with socket(): Protocol not supported Illegal instruction (core dumped)
On Tue, 12 Jan 2010 15:09:45 +0200 Andriy Gapon wrote: > on 12/01/2010 08:53 Hajimu UMEMOTO said the following: > > Hi, > > > >>>>>> On Mon, 11 Jan 2010 12:54:48 +0100 > >>>>>> ohart...@zedat.fu-berlin.de said: > > > > ohartman> Since friday after the last FreeBSD 8.0-STABLE/amd64 update, > > thunderbird3 > > ohartman> crashes immmediately or after a view seconds with > > > > ohartman> socket(): Protocol not supported > > ohartman> Illegal instruction (core dumped) > > > > I'm not sure but I suspect you are using custom kernel built without > > INET6 option. If so, thunderbird3 is depending upon IPv6. > > Can it be made to not require IPv6? (especially when there is no actual IPv6 > connectivity). > Seems to be hardcoded all over the place. Looks like it would require major modifications. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: More CAM fixes.
On Tue, 17 Feb 2009 13:46:20 -0700 Scott Long wrote: > Bruce Evans wrote: > > On Tue, 17 Feb 2009, Gary Jennejohn wrote: > > > >> I tested this with an Adaptec 29160. I saw no real improvement in > >> performance, but also no regressions. > >> > >> I suspect that the old disk I had attached just didn't have enough > >> performance reserves to show an improvement. > >> > >> My test scenario was buildworld. Since /usr/src and /usr/obj were both > >> on the one disk it got a pretty good workout. > > low > >> > >> AMD64 X2 (2.5 GHz) with 4GB of RAM. > > > > Buildworld hardly uses the disk at all. It reads and writes a few hundred > > MB. Ideally the i/o should go at disk speeds of 50-200MB/S and thus take > > between 20 and 5 seconds. In practice, it will take a few more seconds. > > physically but perhaps even less virtually due to parallelism. > > > > Bruce > > Yes, on modern machines, buildworld is bound almost completely by disk > latency, and not at all by disk or controller bandwidth. > > Scott > Maybe I misunderstood something, but I thought the patch was supposed to improve queuing. Seems like all the seeks during a buildowrld would exercise that. All I can say is that the disk did _lots_ of seeking. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: More CAM fixes.
On Mon, 16 Feb 2009 08:09:35 -0700 Scott Long wrote: > FWI. I need lots of testing on this. Only real SCSI controllers, > please, not RAID controllers (except for MPT-SCSI with integrated > mirroring). So Adaptec, LSI, Symbios, Buslogic, Tekram, SME, etc, > users, please try this and get back to me. The patch should apply > to FreeBSD 7 as well. FreeBSD 6 is only affected by this problem > when CAM_NEW_TRAN_CODE is enabled. > I tested this with an Adaptec 29160. I saw no real improvement in performance, but also no regressions. I suspect that the old disk I had attached just didn't have enough performance reserves to show an improvement. My test scenario was buildworld. Since /usr/src and /usr/obj were both on the one disk it got a pretty good workout. AMD64 X2 (2.5 GHz) with 4GB of RAM. BTW under a very fresh 8.0-current. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Pending MFC of drm updates
On Thu, 8 Jan 2009 15:27:08 +0100 Uwe Laverenz wrote: > On Thu, Jan 08, 2009 at 09:03:50AM -0500, Robert Noland wrote: > > > > 1) the infamous "ThinkPad T43p" ;) running i386: > > > > > > Sorry, but RELENG_7_1 with your drm-update still shows a garbled > > > screen. The same userland with a -CURRENT kernel works without problems. > > > > Is this a pci based radeon as well? If so, there is still a patch in > > -CURRENT that isn't in this set yet. > > Yes, it's a PCIE card: "ATI FireGL M24 GL 3154 (PCIE)" > > > new xorg will hit ports soon, but a preliminary patch is available at > > http://people.freebsd.org/~rnoland/xorg-7.4-111608.patch > > Ok, I'll test it. > I have an RV6xx based system here - graphics in the chipset. Can you, Roland, say whether this patch will allow me to use DRM/DRI with it? Right now it's not recognized. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [ATA] and re(4) stability issues
On Wed, 10 Dec 2008 21:07:19 +0900 Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > On Wed, Dec 10, 2008 at 12:32:25PM +0100, Victor Balada Diaz wrote: > > As these seems to improve the current situation, is there any > > chance of merging -current driver in 7.1 before release? > > > > I think re(4) in HEAD needs more testing. As you might know RealTek > produced too many chipsets. :-( > FYI I've now turned MSI on in HEAD and will see what happens. Before my re0 was sharing interrupts with 3 USB controllers. Now it's all by itself on irq256. I'm running amd64 with re0: port 0xde00-0xdeff mem 0xfdaff000-0xfdaf, 0xfdae0000-0xfdae irq 18 at device 0.0 on pci2 --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: am2 MBs - 4g + SCSI wipes out root partition
On Mon, 13 Oct 2008 09:35:10 -0200 JoaoBR <[EMAIL PROTECTED]> wrote: > On Saturday 11 October 2008 07:13:16 Jeremy Chadwick wrote: > > It's a driver problem. If you want to use SCSI then you'll have to limit > > memory to 3.5 GB. > I probably should have written - it seems to be a problem with ahc. In general SCSI seems to work, as Scott has recently documented. But see below. > > well indeed with less then 4G installed it works flawless, so the difference > I > see is that former athln64 MBs had memory hole remap options or when 4Gig > installed they only gave 3.something to the OS even under amd64 - this is NOT > the case with the AM2 MBs which should support up to 8/16Mb onboard but wth > this amount freebsd amd64 does not even boot when a scsi adaptor is installed > I'm beginning to believe that it's motherboard/BIOS related and not a general problem with ahc or any other SCSI driver. I can say that at least with my Gigabyte GA-M61P-S3 I observed data corruption with 4GB of memory installed and with the BIOS mapping a part of memory above 4GB. Forcing the kernel to use only 3.5GB solved the problem. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: am2 MBs - 4g + SCSI wipes out root partition
On Sun, 12 Oct 2008 18:32:13 +0100 Pete French <[EMAIL PROTECTED]> wrote: > > Sorry for not responding back in Jan. I have a hard time recommending > > the 29320/39320 cards because of the long history they have with > > incompatibilities with certain U320 drives. I don't think that the > > Out of interest, what cards would you recommend ? I have just > started running 4 drives off a 29320, and it does the "dump" thing > on boot, so I was thinking of replacing it with another PCI-X card. > > > driver will be affected by memory size, but I haven't run it in several > > years, and it could have rotted like ahc apparently did (though I still > > have a hard time imagining how the rot could have taken place, hardly > > anything has changed in the driver over the years). > > I have a hard time beliving these don't work either - mainly because I > am running a 4GB system with ahc (and now ahd) in it and have had no > problems at all. Certainly Adaptec cards are so common that if there > was something majorly broken in that driver we would be seeing a lot > more reports of corruption surely ? > Maybe it's BIOS related? I have a new mobo from a different vendor where I could give it a try and see if the corruption goes away. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: am2 MBs - 4g + SCSI wipes out root partition
On Sat, 11 Oct 2008 09:52:50 -0700 Jeremy Chadwick <[EMAIL PROTECTED]> wrote: [big snip] > Is your LSI SAS controller driven by mpt(4) or mfi(4)? > > Let's break down what we know for sure at this point: > > aac(4) - not affected > aha(4) - unknown > ahb(4) - unknown > ahc(4) - affected > ahd(4) - unknown; no one answered the OP's question in the thread I asked Scott whether he thought ahd would be affected, but he never responded. I was thinking about getting a PCIe controller but then I dropped the idea due to lack of funds for experimentation. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: am2 MBs - 4g + SCSI wipes out root partition
On Sat, 11 Oct 2008 23:51:18 +0200 Fabian Wenk <[EMAIL PROTECTED]> wrote: > Hello Jeremy > > On 11.10.08 18:52, Jeremy Chadwick wrote: > > Could the problem be specific to certain firmware revisions on the > > cards? > > Some other idea, which versions of FreeBSD/amd64 are affected? > Only 8-CURRENT, or also 6.x- and/or 7.x-RELEASE? > > As far as I have seen from the reports, it does only happen with > more then 3.5 GB RAM and with SCSI disks. > > I do have a system with FreeBSD/amd64 6.3-RELEASE with 4 GB RAM > and an Adaptec 29160 Ultra160 SCSI adapter (ahc) with only a tape > drive connected. The disks are on an Areca RAID controller. Access > to the disks and the tape drive does work just fine without any > crashes. > This is interesting because the 29160 is exactly the controller with which I had all my problems, but I was running it with disks only. Maybe Scott, or someone, has fixed it in the meantime? I haven't tried to use the full 4 GB in my box since January since I can't afford data corruption. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: am2 MBs - 4g + SCSI wipes out root partition
On Sat, 11 Oct 2008 12:08:00 +0200 (CEST) Jean-Marc Zucconi <[EMAIL PROTECTED]> wrote: > >>>>> Gary Jennejohn writes: > > > On Fri, 10 Oct 2008 14:29:37 -0300 > > JoaoBR <[EMAIL PROTECTED]> wrote: > > >> I tried MBs as Asus, Abit and Gigabyte all same result > >> > >> Same hardware with SATA works perfect > >> > >> Same hardware with scsi up to 3.5Gigs installed works perfect > >> > >> what calls my attention that all this MBs do not have the memroy hole > >> remapping feature so the complete 4gigs are available what normally was > not > >> the case with amd64 Mbs for the Athlon 64 CPUs > >> > >> some has an opinion if this is a freebsd issue or MB falure or scsi drv > >> problem? > >> > > > It's a driver problem. If you want to use SCSI then you'll have to limit > > memory to 3.5 GB. > > Is this specific to the Adaptec driver or all of them are affected by > the bug? I am considering upgrading to such a config, but with a > tekram controller (sym). > I observed the same problem with ahc. Can't say whether the sym driver has the problem because I don't have such a controller. I've now taken my SCSI drives out of service and am using SATA only. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: am2 MBs - 4g + SCSI wipes out root partition
On Sat, 11 Oct 2008 03:13:16 -0700 Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: > > On Fri, 10 Oct 2008 14:29:37 -0300 > > JoaoBR <[EMAIL PROTECTED]> wrote: > > > > > I tried MBs as Asus, Abit and Gigabyte all same result > > > > > > Same hardware with SATA works perfect > > > > > > Same hardware with scsi up to 3.5Gigs installed works perfect > > > > > > what calls my attention that all this MBs do not have the memroy hole > > > remapping feature so the complete 4gigs are available what normally was > > > not > > > the case with amd64 Mbs for the Athlon 64 CPUs > > > > > > some has an opinion if this is a freebsd issue or MB falure or scsi drv > > > problem? > > > > > > > It's a driver problem. If you want to use SCSI then you'll have to limit > > memory to 3.5 GB. > > What you're saying is that Adaptec and LSI Logic SCSI controllers behave > badly (and can cause data loss) on amd64 systems which contain more than > 3.5GB of RAM. This is a very big claim. > > Have you talked to Scott Long about this? > > Please expand on this, and provide evidence or references. I need to > document this in my Wiki if it is indeed true. > See the freebsd-scsi thread with Subject "data corruption with ahc driver and 4GB of memory using a FBSD-8 64-bit installation?" from Wed, 30 Jan 2008. This was for ahc, but the bit-rot which Scott mentions in his reply might also apply to the LSI Logic controllers. Basically the driver doesn't correctly handle DMA above 4GB. Since the PCI hole gets mapped above 4GB it causes problems. the (S)ATA drivers don't seem to have this problem. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: am2 MBs - 4g + SCSI wipes out root partition
On Fri, 10 Oct 2008 14:29:37 -0300 JoaoBR <[EMAIL PROTECTED]> wrote: > I tried MBs as Asus, Abit and Gigabyte all same result > > Same hardware with SATA works perfect > > Same hardware with scsi up to 3.5Gigs installed works perfect > > what calls my attention that all this MBs do not have the memroy hole > remapping feature so the complete 4gigs are available what normally was not > the case with amd64 Mbs for the Athlon 64 CPUs > > some has an opinion if this is a freebsd issue or MB falure or scsi drv > problem? > It's a driver problem. If you want to use SCSI then you'll have to limit memory to 3.5 GB. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: undefined reference to `memset'
"Vinod Kashyap" writes: > > And now, moving to the important thing... in kern.pre.mk, I changed > COPTFLAGS from -O2 to -O for amd64 (just like i386), and the problem > is gone!! > Better to do it in /etc/make.conf. --- Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyjATdenxDOTde ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE3: ATA mkIII official patches - please test!
Soeren Schmidt writes: > If I dont get any significant showstopper reports this is what will get > committed to -current soon (plus what I might get done until then of new > features). > What's with ATAPICAM? --- Gary Jennejohn / garyj[at]jennejohn.org gj[at]freebsd.org garyj[at]denx.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
