Re: RELENG_7: chatty geom
Mike Jakubik wrote: > Just an FYI, i am also seeing this on a recent cvsup. > Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1a > is ufsid/49c7c009b41af703. Glabel is telling you you can abandon mounting device nodes and can use labels for it. > Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label > ufsid/49c7c009b41af703 removed. Now Glabel is complaining you didn't use a label and have used a device node as the mount point :) I'll commit a silencing patch as soon as I get approval for it. signature.asc Description: OpenPGP digital signature
Re: no USB mice detected on GA-MA74GM-S2
2009/4/13 : > Yes, I'm 100% positive I tried plugging mouse after the boot up had > finished. Honestly I am late asking here. I was struggling with > this and looking for cases online for more than 2 weeks at least. > And I came across your thread from 2007, too. > That's really bad. Though closest I can find to your board with freebsd people I know is AMD770+SB600, while your is AMD740G+SB700, all of them dating back to my first AMD690G/V (and maybe prior to that) so far exhibited the same symptoms and the late-plug approach always worked.. Yours would be then the first one that Gigabyte botched even more (congrats). I guess that's one more reason to push on USB guys to finally fix it. While I'm not really sure what to propose, maybe starting a new thread "Attention Gigabyte owners - speak up!" could achieve something. At least I know few of them that never bothered reporting anything, because "somebody will fix it eventually, it's a known issue". Maybe it's not that well known for someone to consider it a priority yet.. ___ 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: no USB mice detected on GA-MA74GM-S2
On Mon, 13 Apr 2009 02:35:37 +0200, Michal Varga wrote > 2009/4/13 : > >> ). A quick workaround is to attach your mouse (or any > >> other USB device that dies during boot - mices, keyboards, > >> card readers, etc. do this with FreeBSD 6/7's usb1 and > >> Gigabyte boards) -after- all USB drivers are loaded and > >> initialized. That always works. > > > > Unfortunately not in my case. I have tried this path before > > without success. > > Are you sure you plugged the mouse out, then powered the > computer on, and plugged the mouse back in only after > FreeBSD fully finished booting? To make it perfectly > redundantly safe, let's say, plugged mouse in at the login > prompt? Because I'm 100% positive (well, me and everyone > else with any recent Gigabyte board that I know) that > plugging the device in after the USB drivers are fully initialized > will prevent the lockup and port timeout, always. Yes, I'm 100% positive I tried plugging mouse after the boot up had finished. Honestly I am late asking here. I was struggling with this and looking for cases online for more than 2 weeks at least. And I came across your thread from 2007, too. > >> Still, having it properly fixed in usb1 drivers wouldn't > >> hurt, of course, > > > > How do you go about that? I mean fixing a device in usb1.1. > > > Well, I guess that would need someone with both FreeBSD > USB expertise and some interest in fixing that bug (and > probably an access to particular Gigabyte hardware, though > as it seems so far, anything recent from Gigabyte and > probably AMD6xx/7xx based will do it). Anyway, I tried > reporting it back then in 2007, all I got was a bunch of > arguments about power source fluctuations, carbon > footprints, Windows, PS/2 mices (for christ sake..), and > well, being a lazy coward, I gave up. Maybe you'll be > luckier this time. Well, I don't like the idea of giving up. I have been using the OS since the 90's, almost exclusively and that's the first time I got such unresolvable problems. But I need a functional work environment. -- Piotr Smyrak piotr.smy...@heron.pl ___ 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: RELENG_7: chatty geom
Just an FYI, i am also seeing this on a recent cvsup. Apr 8 14:27:15 iwinbackdb kernel: ACPI APIC Table: Apr 8 14:27:15 iwinbackdb kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs ... Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1a is ufsid/49c7c009b41af703. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1d is ufsid/49c7c015ce349fa2. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1e is ufsid/49c7c00985844142. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1f is ufsid/49c7c0090e1a2de8. Apr 8 14:27:15 iwinbackdb kernel: Trying to mount root from ufs:/dev/mfid0s1a Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c009b41af703 removed. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1a is ufsid/49c7c009b41af703. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c00985844142 removed. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1e is ufsid/49c7c00985844142. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c0090e1a2de8 removed. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1f is ufsid/49c7c0090e1a2de8. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c015ce349fa2 removed. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1d is ufsid/49c7c015ce349fa2. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c009b41af703 removed. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c00985844142 removed. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c0090e1a2de8 removed. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c015ce349fa2 removed. On Mon, April 13, 2009 9:31 am, Christian Weisgerber wrote: > I updated to today's RELENG_7 and geom(4) has become kind of chatty. > Near the end of kernel autoconf, I get a line like > > GEOM_LABEL: Label for provider ad6s1a is ufsid/49b818dc7f60a735. > > for each file system. Then during startup, there is a further > > GEOM_LABEL: Label ufsid/49b818dc7f60a735 removed. > GEOM_LABEL: Label for provider ad6s1a is ufsid/49b818dc7f60a735. > > and finally another > > GEOM_LABEL: Label ufsid/49b818dc7f60a735 removed. > > for a total of four lines for each file system. > Is this spew really helpful? > ___ 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: apache 2.0.63 and php5
Jase Thew wrote:
Hi,
/etc/profile is the system wide profile for sh shell. So, should you
need to do this for all sh scripts ( including /usr/local/etc/rc.d/
scripts), simply add a PATH line to /etc/profile, eg:
PATH=/foo/bar:/bar/baz:$PATH; export PATH
or
PATH=$PATH:/foo/bar:/bar/baz; export PATH
depending on whether you want your additional directories to be searched
before or after the default path.
Regards,
Jase.
Thanks, that's an easy fix.
There are some inconsistencies though in the default paths used in
various places around the system. It seems that we have (on 7.1 at least)
/etc/rc: /sbin:/bin:/usr/sbin:/usr/bin
/etc/rc.shutdown: /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
(why no /usr/local/bin ?)
/etc/login.conf, /usr/share/skel/dot.profile, /usr/share/skel/dot.cshrc:
/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:~/bin
Would it make any sense to do something like to add /usr/local/s?bin
later in the rc startup as a system default - to make automatic
boot-startup behavior more similar to manual service-starting behavior...
--- defaults/rc.conf.original 2009-01-19 22:58:58.490989000 -0600
+++ defaults/rc.conf2009-04-13 09:09:01.680065507 -0500
@@ -51,6 +51,7 @@
populate_var="AUTO"# Set to YES to always (re)populate /var, NO to
never
cleanvar_enable="YES" # Clean the /var directory
local_startup="/usr/local/etc/rc.d" # startup script dirs.
+local_startup_path="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
# Path to use when starting local scripts
script_name_sep=" "# Change if your startup scripts' names contain
spaces
rc_conf_files="/etc/rc.conf /etc/rc.conf.local"
--- rc.original 2009-01-19 22:56:22.411969000 -0600
+++ rc 2009-04-13 09:07:16.046050290 -0500
@@ -100,7 +100,10 @@
#
case ${local_startup} in
[Nn][Oo] | '') ;;
-*) find_local_scripts_new ;;
+*) find_local_scripts_new
+PATH=local_startup_path
+export PATH
+;;
esac
files=`rcorder ${skip} /etc/rc.d/* ${local_rc} 2>/dev/null`
-
You could also perhaps pull that $local_startup_path into rc.shutdown
Barry
___
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"
RELENG_7: chatty geom
I updated to today's RELENG_7 and geom(4) has become kind of chatty. Near the end of kernel autoconf, I get a line like GEOM_LABEL: Label for provider ad6s1a is ufsid/49b818dc7f60a735. for each file system. Then during startup, there is a further GEOM_LABEL: Label ufsid/49b818dc7f60a735 removed. GEOM_LABEL: Label for provider ad6s1a is ufsid/49b818dc7f60a735. and finally another GEOM_LABEL: Label ufsid/49b818dc7f60a735 removed. for a total of four lines for each file system. Is this spew really helpful? -- Christian "naddy" Weisgerber na...@mips.inka.de ___ 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: watchdog timeout
On Fri, 10 Apr 2009, Pyun YongHyeon wrote: On Wed, Apr 08, 2009 at 10:41:44AM +0200, xer wrote: Hello I have some problems with 3Com nics, after a upgrade from 5.5-STABLE to 6.4-STABLE. This machine has two 3com nics (one is LAN other is WAN) and i see too much "watchdog timeout" on both cards. This on/off up/down on cards, affect the interrupt to clients that are downloading from apache web server, especially on large files. xer:/root# dmesg xl1: watchdog timeout xl1: link state changed to DOWN xl1: link state changed to UP xl1: watchdog timeout xl1: link state changed to DOWN xl1: link state changed to UP xl1: watchdog timeout xl1: link state changed to DOWN xl1: link state changed to UP - [ . . . ] As you can see, the cards are 3c905C-TX model. Someone told me to change drivers, but i cannot understand this advice. I got same errors with same cards but with another mainboard, same problem, watchdog appears after an upgrade from 5.4-STABLE to 6.4-STABLE. I don't think that to change nic's pci slots, will solve the problem, i think that maybe change the nics would resolve the matter, but i cannot access to both FreeBSD phisically, cause the boxes are too far from me (about 3500 km). I'm asking you some advices, and i can i fix this problem. p.s. with both 5.4 or 5.5 old kernel, the nics was fine. I vaguely remember there were a couple of reports on xl(4) watchdog timeouts. I'm not sure this came from missing Tx interrupts but would you try attached patch? Note, it was generated against HEAD and you should experiment the attached patch on local box prior to applying to your production server. Perhaps the case can convey the amount of hair I lost over this: HAVE YOU CHECKED YOUR BIOS AND ONBOARD IO SETTINGS? I have been swapping boards for days for another firewall project and finally figured it out last night. I would get messages like these, depending on the 3rd card used: xl0: Watchdog Timeout pcn0: Watchdog timeout Finally the Sierra Nevada Porter kicked-in and an old idea came back to me: I was running out of interrupts! 1/2 (^_^) The hint was from a combination of having the earlier advice of "set the 'PNP OS' to false" fail and a Tom's Hardware mobo review complaint about 5-slot PCI mobos having IRQ sharing issues. Thanks to you both wherever you are! Finally I went in and disabled all the onboard IO I wasn't using to free up IRQs. Disable the onboard serial if you aren't using them. If you are, then an 8-port board or USB serial, can save COM1 and COM2 IRQs. No video IRQ needed for simple console work. No parallel needed, so saved that one. No floppy nowadays, either. Lots of options for you! Thinking I hadn't had IRQ issues in 15 years or so, it sure reminded me that we still have the legacy x86 IRQ limitations. This has pushed me to thinking more about shifting to trunked VLANs to save ENet ports and make recovery easier. FWIW: I tend to use different cards so the network ports don't "float" to other numbers if one dies. This made the problem worse because the drivers assign IRQs when they load, so it looked like xl0 cards were the issue when 'de*' and 'dc*' worked. Changing slots changed things too! This explains some of what you're experience shows. There is no way I can give back to this list what it's given me in technical support, but if this makes things work for you, then I've given *something* back and it really is a Good Friday - Jy@ ___ 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: apache 2.0.63 and php5
Barry Pederson wrote: I've been burned by this a fair number of times, wish there was some good way of having things starting from /usr/local/etc/rc.d to have /usr/local/bin and sbin in the path on a consistent basis. Barry Hi, /etc/profile is the system wide profile for sh shell. So, should you need to do this for all sh scripts ( including /usr/local/etc/rc.d/ scripts), simply add a PATH line to /etc/profile, eg: PATH=/foo/bar:/bar/baz:$PATH; export PATH or PATH=$PATH:/foo/bar:/bar/baz; export PATH depending on whether you want your additional directories to be searched before or after the default path. Regards, Jase. ___ 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: problems with 7.2, vm_page_insert: page already inserted
Here's another one: panic: vm_page_insert: page already inserted cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at 0x8018bd85 = db_trace_self_wrapper+0x2a kdb_backtrace() at 0x802d3717 = kdb_backtrace+0x32 panic() at 0x802a95ac = panic+0x1b0 vm_page_insert() at 0x8041aa1c = vm_page_insert+0x2e vm_page_alloc() at 0x8041af09 = vm_page_alloc+0x3c0 kmem_malloc() at 0x8040fd98 = kmem_malloc+0x329 page_alloc() at 0x80407280 = page_alloc+0x18 uma_large_malloc() at 0x80409b0b = uma_large_malloc+0x4d malloc() at 0x802999a3 = malloc+0x97 zfs_kmem_alloc() at 0x807836ed = zfs_kmem_alloc+0x12 zio_data_buf_alloc() at 0x807cbca3 = zio_data_buf_alloc+0xe arc_get_data_buf() at 0x807924f3 = arc_get_data_buf+0x28e arc_buf_alloc() at 0x80792736 = arc_buf_alloc+0xe0 arc_read() at 0x807938b6 = arc_read+0x2bb dbuf_prefetch() at 0x80797aa8 = dbuf_prefetch+0x146 dmu_zfetch_dofetch() at 0x807aa102 = dmu_zfetch_dofetch+0x102 dmu_zfetch() at 0x807aa80c = dmu_zfetch+0x55a dbuf_read() at 0x807965c5 = dbuf_read+0x37f dmu_buf_hold_array_by_dnode() at 0x80798e92 = dmu_buf_hold_array_by_dnode+0x1ed dmu_buf_hold_array() at 0x8079922c = dmu_buf_hold_array+0x57 dmu_read_uio() at 0x8079928e = dmu_read_uio+0x3f zfs_freebsd_read() at 0x807dcb84 = zfs_freebsd_read+0x4b1 VOP_READ_APV() at 0x8047f7e4 = VOP_READ_APV+0x47 vn_read() at 0x803392b2 = vn_read+0x275 dofileread() at 0x802e1246 = dofileread+0x96 kern_preadv() at 0x802e13d1 = kern_preadv+0x6a pread() at 0x802e149f = pread+0x51 syscall() at 0x8044755d = syscall+0x347 Xfast_syscall() at 0x8042c51b = Xfast_syscall+0xab -- 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"
bce and lagg revisited
well, I tried to narrow this down a bit by removing lagg from the equation, but the switch requires LACP to be active on those ports so I can't test in isolation unfortunately. Is anyone running 7.2 on a DL360 G5 with working ether ? -pete. ___ 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: apache 2.0.63 and php5
Thank you a lot Raphael, you were right! The PATH enviroment are (poor) after a reboot and fixed after apachectl stop and start. How you suggest me to fix it? There is a better way before i will do something wrong? Thanx in advance -- From: "Raphael Becker" Sent: Sunday, April 12, 2009 6:09 PM Subject: Re: apache 2.0.63 and php5 When you use apachectl start apache inherits the environment of the user from apachectl, especially PATH. PATH is different for /root and boot. Create a simple php with "" in it and compare the Values for PATH a) after boot b) after restart by apachectl ___ 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"
