(no subject)
latest -stable (June 11) is causing problems: MB is intel SE7320VP21, msk0: Ethernet address: 00:0e:0c:6a:85:a8 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto msk0: watchdog timeout (missed Tx interrupts) -- recovering msk0: watchdog timeout (missed Tx interrupts) -- recovering msk0: watchdog timeout (missed Tx interrupts) -- recovering ... cheers, danny ___ 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: your mail
On Fri, Jun 12, 2009 at 10:57:42AM +0300, Danny Braniss wrote: > latest -stable (June 11) is causing problems: > MB is intel SE7320VP21, > > msk0: Ethernet address: 00:0e:0c:6a:85:a8 > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > > msk0: watchdog timeout (missed Tx interrupts) -- recovering > msk0: watchdog timeout (missed Tx interrupts) -- recovering > msk0: watchdog timeout (missed Tx interrupts) -- recovering > ... > I think there was not much msk(4) changes in stable. msk(4) in CURRENT has a lot changes to support newer controllers. Does msk(4) in CURRENT make any difference? Also please show me dmesg output(msk(4) related one) to know which controller you have. Btw, are you using MSI? > cheers, > danny > > ___ 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: msk/stable
> On Fri, Jun 12, 2009 at 10:57:42AM +0300, Danny Braniss wrote: > > latest -stable (June 11) is causing problems: > > MB is intel SE7320VP21, > > > > msk0: Ethernet address: 00:0e:0c:6a:85:a8 > > miibus0: on msk0 > > e1000phy0: PHY 0 on miibus0 > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > 1000baseT-FDX, auto > > > > msk0: watchdog timeout (missed Tx interrupts) -- recovering > > msk0: watchdog timeout (missed Tx interrupts) -- recovering > > msk0: watchdog timeout (missed Tx interrupts) -- recovering > > ... > > > > I think there was not much msk(4) changes in stable. msk(4) in > CURRENT has a lot changes to support newer controllers. Does msk(4) > in CURRENT make any difference? > Also please show me dmesg output(msk(4) related one) to know which > controller you have. hrumph, missed some lines: mskc0: port 0xb800-0xb8ff mem 0xdeefc000-0xdeef irq 16 at device 0.0 on pci2 msk0: on mskc0 msk0: Ethernet address: 00:0e:0c:6a:85:a8 miibus0: on msk0 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto mskc0: [FILTER] > > Btw, are you using MSI? yes, but it was (so it seemed) working ok. i'll try again soon without msi. in the meantime, Im running an older kernel, trying to finish a very long process (svn/svk), which when done, I will be able to compile current. thanks, danny ___ 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: Something since June 8th clobbers my disk...
On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > Isn't boot part of the kernel build? Why would installing the kernel > not cause this problem? No, sys/boot is built during world. Likely some change in /boot/loader is causing your problem. Can you narrow it down to a specific change under sys/boot? -- John Baldwin ___ 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"
zfs related panic
This is on a recent stable/7 amd64, with zpool and filesystems upgraded to the latest version. I did zfs rollback x...@yyy And then did ls on a directory in the rolled-back fs. I have the core file if it can be of any help. Sleeping thread (tid 100263, pid 2432) owns a non-sleepable lock sched_switch() at 0x8031d0ef = sched_switch+0x47d mi_switch() at 0x80302a59 = mi_switch+0x1bf sleepq_switch() at 0x8032f645 = sleepq_switch+0xd8 sleepq_catch_signals() at 0x8032f925 = sleepq_catch_signals+0x2db sleepq_wait_sig() at 0x80330219 = sleepq_wait_sig+0xc _sleep() at 0x80302eba = _sleep+0x2b5 kern_sigsuspend() at 0x802fc567 = kern_sigsuspend+0xeb sigsuspend() at 0x802fc5e9 = sigsuspend+0x34 syscall() at 0x80491d2d = syscall+0x347 Xfast_syscall() at 0x8047d00b = Xfast_syscall+0xab --- syscall (341, FreeBSD ELF64, sigsuspend), rip = 0x80092ce3c, rsp = 0x7fffdee8, rbp = 0x8011e5a60 --- panic: sleeping thread cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0x80192dd5 = db_trace_self_wrapper+0x2a kdb_backtrace() at 0x80327ea7 = kdb_backtrace+0x32 panic() at 0x802fb70c = panic+0x1b0 propagate_priority() at 0x80332e92 = propagate_priority+0x122 turnstile_wait() at 0x80333e29 = turnstile_wait+0x358 _mtx_lock_sleep() at 0x802ed64a = _mtx_lock_sleep+0x117 cache_lookup() at 0x8036a52a = cache_lookup+0x632 vfs_cache_lookup() at 0x8036a69f = vfs_cache_lookup+0xab VOP_LOOKUP_APV() at 0x804c86f3 = VOP_LOOKUP_APV+0x51 lookup() at 0x80370a71 = lookup+0x5d8 namei() at 0x8037168f = namei+0x320 kern_lstat() at 0x8037f6ca = kern_lstat+0x5e lstat() at 0x8037f8c9 = lstat+0x25 syscall() at 0x80491d2d = syscall+0x347 Xfast_syscall() at 0x8047d00b = Xfast_syscall+0xab --- syscall (190, FreeBSD ELF64, lstat), rip = 0x80095afbc, rsp = 0x7fffdde8, rbp = 0x800b50270 --- -- Andriy Gapon ___ 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"
Intel ESB2 problems and their solution
I wanted to circulate a document from our technical marketing group that details a problem with the family of adapters called ES2LAN. These are most commonly seen as LOMs (on motherboard) in SuperMicro and other servers, the most common device ID is 0x1096 but also may be 0x1098, 0x10BA, or 0x10BB. They are a device driven by the 'em' driver. This document has some Windows symptoms that will be of no value here, but the problem does occur on FreeBSD, most often it is seen as a failure to load, due to a "Shared Code Initialization" failure. There is driver changes in 7.2 that address this problem, however the driver alone is only part of the complete solution, you MUST have firmware updates to resolve the problem, and this document provides pointers for particular systems. If you have a system that has seen this issue please obtain and apply the relevant firmware. I hope this helps resolve any of these issues customers are still seeing. Cheers everyone, Jack Vogel Intel Lan Access Division free...@intel.com ESB2_problems.pdf Description: Adobe PDF document ___ 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"
Stable7 buildoption effects: updated table
I have just completed a run of /src/tools/tools/build_option_survey and have uploaded the result here: http://phk.freebsd.dk/misc/stable7_build_options/ Those of you building embedded systems on FreeBSD 7.x may find this useful. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: zfs related panic
show sleepchain show thread 100263 On Fri, Jun 12, 2009 at 6:56 AM, Andriy Gapon wrote: > > This is on a recent stable/7 amd64, with zpool and filesystems upgraded to the > latest version. > I did zfs rollback x...@yyy > And then did ls on a directory in the rolled-back fs. > > I have the core file if it can be of any help. > > Sleeping thread (tid 100263, pid 2432) owns a non-sleepable lock > sched_switch() at 0x8031d0ef = sched_switch+0x47d > mi_switch() at 0x80302a59 = mi_switch+0x1bf > sleepq_switch() at 0x8032f645 = sleepq_switch+0xd8 > sleepq_catch_signals() at 0x8032f925 = sleepq_catch_signals+0x2db > sleepq_wait_sig() at 0x80330219 = sleepq_wait_sig+0xc > _sleep() at 0x80302eba = _sleep+0x2b5 > kern_sigsuspend() at 0x802fc567 = kern_sigsuspend+0xeb > sigsuspend() at 0x802fc5e9 = sigsuspend+0x34 > syscall() at 0x80491d2d = syscall+0x347 > Xfast_syscall() at 0x8047d00b = Xfast_syscall+0xab > --- syscall (341, FreeBSD ELF64, sigsuspend), rip = 0x80092ce3c, rsp = > 0x7fffdee8, rbp = 0x8011e5a60 --- > panic: sleeping thread > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at 0x80192dd5 = db_trace_self_wrapper+0x2a > kdb_backtrace() at 0x80327ea7 = kdb_backtrace+0x32 > panic() at 0x802fb70c = panic+0x1b0 > propagate_priority() at 0x80332e92 = propagate_priority+0x122 > turnstile_wait() at 0x80333e29 = turnstile_wait+0x358 > _mtx_lock_sleep() at 0x802ed64a = _mtx_lock_sleep+0x117 > cache_lookup() at 0x8036a52a = cache_lookup+0x632 > vfs_cache_lookup() at 0x8036a69f = vfs_cache_lookup+0xab > VOP_LOOKUP_APV() at 0x804c86f3 = VOP_LOOKUP_APV+0x51 > lookup() at 0x80370a71 = lookup+0x5d8 > namei() at 0x8037168f = namei+0x320 > kern_lstat() at 0x8037f6ca = kern_lstat+0x5e > lstat() at 0x8037f8c9 = lstat+0x25 > syscall() at 0x80491d2d = syscall+0x347 > Xfast_syscall() at 0x8047d00b = Xfast_syscall+0xab > --- syscall (190, FreeBSD ELF64, lstat), rip = 0x80095afbc, rsp = > 0x7fffdde8, > rbp = 0x800b50270 --- > > -- > Andriy Gapon > ___ > freebsd...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org" > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ 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: Something since June 8th clobbers my disk...
On Thursday 11 June 2009 06:33:24 pm Dan Allen wrote: > On 11 Jun 2009, at 5:41 PM, Paul B. Mahol wrote: > > Looks like boot(8) is problematic. > > Anything in /etc/src.conf or /etc/make.conf? > > I have never touched or created a src.conf. If there was one there, > it has been unmodified by me. > > I HAVE modified make.conf. Here is its contents: > > --- /etc/make.conf --- > > BATCH=yes > NO_PROFILE=yes > KERNCONF=DKA > USE_FORTRAN=yes > WITH_JADETEX=no > PERL_VERSION=5.8.9 > > --- > > My custom kernel named DKA has only three modifications from GENERIC: > > I commented out the following three lines: > > #cpu I486_CPU > #cpu I586_CPU > #makeoptions DEBUG="-g" > > I have run with such a kernel on many machines for many years now. > > However, my experiments have shown that the kernel build is not to > blame. > > Isn't boot part of the kernel build? Why would installing the kernel > not cause this problem? > > It is by installing the world via make installworld that my drive gets > munged. > > I obviously am missing something, but boot(8) sounds like it is in the > neighborhood of where the problem is. > > There were changes to /usr/src/sys/boot/i386/libi386/biosdisk.c and > biospnp.c that really look suspect to me. The order of your builds in previous messages had the kernel built on an old world. You are supposed to do the buildworld first and then, build and install the kernel. The classic way at this point is to boot into single user mode and do the installworld. Kent > > Dan > > ___ > 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" -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ 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: Something since June 8th clobbers my disk...
On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: Isn't boot part of the kernel build? Why would installing the kernel not cause this problem? No, sys/boot is built during world. Likely some change in /boot/ loader is causing your problem. Can you narrow it down to a specific change under sys/boot? Ok. I updated just the one file since it appeared like one of the few changed files /usr/src/sys/boot/i386/libi386/biosdisk.c and rebuilt things with cd /usr/src/sys/boot; make cleandir obj depend all install and it was okay. No problems. Then I did sync'd all of the changed files for /usr/src/sys/boot and my machine is hung again at boot, so we have narrowed it down to somewhere in /usr/src/sys/boot/. Time to reinstall from a DVD and try it with finer granularity. This will take some time. There appears to be only four files that have changed in /usr/src/sys/ boot from June 8th (all working fine) to June 11th (dead in the water). They are: /usr/src/sys/boot/Makefile /usr/src/sys/boot/i386/Makefile /usr/src/sys/boot/i386/libi386/biosdisk.c /usr/src/sys/boot/i386/loader/Makefile I have ruled out bisodisk.c, as stated above. That means that the Makefiles are building new stuff that previously was not built, namely zfsboot gptzfsboot I believe it has to do with that. More help is needed! I am tired of reinstalling the OS, but I am much more paranoid about updating my other machine in any way now, as it could erase that whole machine. I can't believe I am the only one seeing this... Dan ___ 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: Something since June 8th clobbers my disk...
On Fri, Jun 12, 2009 at 08:45:01PM -0600, Dan Allen wrote: > > On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > > >On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > >>Isn't boot part of the kernel build? Why would installing the kernel > >>not cause this problem? > > > >No, sys/boot is built during world. Likely some change in /boot/ > >loader is > >causing your problem. Can you narrow it down to a specific change > >under > >sys/boot? > > Ok. I updated just the one file since it appeared like one of the few > changed files > > /usr/src/sys/boot/i386/libi386/biosdisk.c > > and rebuilt things with > > cd /usr/src/sys/boot; make cleandir obj depend all install > > and it was okay. No problems. > > Then I did sync'd all of the changed files for /usr/src/sys/boot and > my machine is hung again at boot, so we have narrowed it down to > somewhere in /usr/src/sys/boot/. > > Time to reinstall from a DVD and try it with finer granularity. This > will take some time. > > There appears to be only four files that have changed in /usr/src/sys/ > boot from June 8th (all working fine) to June 11th (dead in the > water). They are: > > /usr/src/sys/boot/Makefile > /usr/src/sys/boot/i386/Makefile > /usr/src/sys/boot/i386/libi386/biosdisk.c > /usr/src/sys/boot/i386/loader/Makefile > > I have ruled out bisodisk.c, as stated above. > > That means that the Makefiles are building new stuff that previously > was not built, namely > > zfsboot gptzfsboot > > I believe it has to do with that. More help is needed! I am tired of > reinstalling the OS, but I am much more paranoid about updating my > other machine in any way now, as it could erase that whole machine. I > can't believe I am the only one seeing this... > > Dan > Whew!! i'm giving thanks to every saint, god and daemon known. i rebuilt my kernel in very recent days (7.2) on my ancient 500MHz kayak, but did not go further. So still runing on the 7.0 kernel. Will someone send up a flare when it's *safe*? gary -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org For FBSD list: http://transfinite.thought.org/slicejourney.php The 4.98a release of Jottings: http://jottings.thought.org/index.php ___ 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: Something since June 8th clobbers my disk...
On Fri, Jun 12, 2009 at 08:24:42PM -0700, Gary Kline wrote: > On Fri, Jun 12, 2009 at 08:45:01PM -0600, Dan Allen wrote: > > > > On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > > > > >On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > > >>Isn't boot part of the kernel build? Why would installing the kernel > > >>not cause this problem? > > > > > >No, sys/boot is built during world. Likely some change in /boot/ > > >loader is > > >causing your problem. Can you narrow it down to a specific change > > >under > > >sys/boot? > > > > Ok. I updated just the one file since it appeared like one of the few > > changed files > > > > /usr/src/sys/boot/i386/libi386/biosdisk.c > > > > and rebuilt things with > > > > cd /usr/src/sys/boot; make cleandir obj depend all install > > > > and it was okay. No problems. > > > > Then I did sync'd all of the changed files for /usr/src/sys/boot and > > my machine is hung again at boot, so we have narrowed it down to > > somewhere in /usr/src/sys/boot/. > > > > Time to reinstall from a DVD and try it with finer granularity. This > > will take some time. > > > > There appears to be only four files that have changed in /usr/src/sys/ > > boot from June 8th (all working fine) to June 11th (dead in the > > water). They are: > > > > /usr/src/sys/boot/Makefile > > /usr/src/sys/boot/i386/Makefile > > /usr/src/sys/boot/i386/libi386/biosdisk.c > > /usr/src/sys/boot/i386/loader/Makefile > > > > I have ruled out bisodisk.c, as stated above. > > > > That means that the Makefiles are building new stuff that previously > > was not built, namely > > > > zfsboot gptzfsboot > > > > I believe it has to do with that. More help is needed! I am tired of > > reinstalling the OS, but I am much more paranoid about updating my > > other machine in any way now, as it could erase that whole machine. I > > can't believe I am the only one seeing this... > > > > Dan > > > > Whew!! i'm giving thanks to every saint, god and daemon known. i > rebuilt my kernel in very recent days (7.2) on my ancient > 500MHz kayak, but did not go further. So still runing on the 7.0 > kernel. > > Will someone send up a flare when it's *safe*? > > gary > > > > -- > Gary Kline kl...@thought.org http://www.thought.org Public Service Unix > http://jottings.thought.org http://transfinite.thought.org >For FBSD list: http://transfinite.thought.org/slicejourney.php > The 4.98a release of Jottings: http://jottings.thought.org/index.php How do you know it isn't safe? Noone hasn't provided any useful info (debug, revisions where it works and where it doesn't). Yuri ___ 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: Something since June 8th clobbers my disk...
On Friday 12 June 2009 08:24:42 pm Gary Kline wrote: > On Fri, Jun 12, 2009 at 08:45:01PM -0600, Dan Allen wrote: > > On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > > >On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > > Whew!! i'm giving thanks to every saint, god and daemon known. i > rebuilt my kernel in very recent days (7.2) on my ancient > 500MHz kayak, but did not go further. So still runing on the 7.0 > kernel. > > Will someone send up a flare when it's *safe*? > > gary Gary, it isn't affecting everyone. FreeBSD ruby.owt.com 7.2-STABLE FreeBSD 7.2-STABLE #4: Wed Jun 10 14:07:14 PDT 2009 r...@ruby.owt.com:/usr/obj/usr/src/sys/FREEBSD2 i386 FreeBSD kstewart2.owt.com 7.2-STABLE FreeBSD 7.2-STABLE #6: Wed Jun 10 15:03:03 PDT 2009 r...@kstewart2.owt.com:/usr/obj/usr/src/sys/FREEBSD1 i386 Ruby is an Intel core duo and the other has dual Xeon's. They were all installed the canonical way. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ 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"
