Re: 6.0-BETA2 through 4: BTX halted?
Dimitry Andric wrote: Anyone also seen this specific exception message? Most other OS install CD's (e.g. Linux, Windows) I throw at this machine boot without problems, btw. P.S: I just tried 5.4-RELEASE on the same X41, and BTX crashes there too... :( I've seen these identical systems on earlier versions, and documented as much as I could in: http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/72960 Perhaps these symptoms are from different causes, but if it looks like a duck. Derek ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problem using POSIX message queues
While trying to develop an understanding of the use POSIX message queues, I found that issuing a mq_open (2) call, resulted in Bad system call: 12 error message. I have tried to run the tools/regression/mqueue tests, but they fail in mq_open with the bad system call error. In addition, the mq_open (2) man page refers to mq_timedreceive (3), mq_timedsend(3) which exist as section 2 man pages and a mq_unlink(3) man page which I can't find at all. I hope I am the first to try the use of the posix message queues and that this is just some teething problems. My test case ran without problems under linux, Fedora 14. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ 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 send -i': destination has been modified
On 2010-10-20, at 8:54 AM, Dan Langille wrote: > Not that I know of. But I do think that is the issue. Thank you. Adding > a -F option to the receive helps: > > # zfs send -i storage/bac...@2010.10.19 storage/bac...@2010.10.20 | zfs > receive -vF storage/compressed/bacula > receiving incremental stream of storage/bac...@2010.10.20 into > storage/compressed/bac...@2010.10.20 > received 20.0GB stream in 303 seconds (67.5MB/sec) > > Just after I sent my email, I found this post: > > http://lists.freebsd.org/pipermail/freebsd-current/2007-July/075774.html > > Problem solved. :) Good workaround, forcing the receive, but I'd still like to figure out what's causing the filesystem to be modified on the receiving end. But this will be useful if I can't determine what is causing it to differ. Thanks, Derek ___ 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 send -i': destination has been modified
Seeing similar here Dan, my destination filesystems are becoming modified sometime after the previous snapshot has been sent so the incremental fails to be received. However, the server I'm sending to is not in use so I can't explain why it's changing. When I run a zdiff on the receiving system's filesystem, it can't find any changes in the file, but the byte difference between the snapshot and current can range from anywhere from 32KB to 101MB so far in my testing. If I rollback the filesystem to the last received snapshot it works, but I have no explanation for it changing. I disabled everything that was running on the receiving system yesterday afternoon and there's been no change since, so now I need to step through and see if I can figure out what process was causing the byte difference on the filesystems. Derek On 2010-10-20, at 8:32 AM, Dan Langille wrote: > I am trying to do a 'zfs send -i' and failing. > > This is my simple proof of concept test: > > Create the data > # zfs create storage/a > # touch /storage/a/1 > # touch /storage/a/2 > # touch /storage/a/3 > > Snapshot > # zfs snapshot storage/a...@2010.10.19 > > send > # zfs send storage/a...@2010.10.19 | zfs receive -v storage/compressed/a > receiving full stream of storage/a...@2010.10.19 into > storage/compressed/a...@2010.10.19 > received 252KB stream in 2 seconds (126KB/sec) > # > > > > Create one more file and snapshot that > > # touch /storage/a/4 > # zfs snapshot storage/a...@2010.10.20 > > > send it > > # zfs send -i storage/a...@2010.10.19 storage/a...@2010.10.20 | zfs receive > -v > storage/compressed/a > receiving incremental stream of storage/a...@2010.10.20 into > storage/compressed/a...@2010.10.20 > received 250KB stream in 3 seconds (83.4KB/sec) > > What do we have? > > # find /storage/compressed/a > /storage/compressed/a > /storage/compressed/a/1 > /storage/compressed/a/2 > /storage/compressed/a/3 > /storage/compressed/a/4 > > > Of note: > > * FreeBSD 8.1-STABLE > * ZFS filesystem version 4. > * ZFS pool version 15. > * zfs send is on compression off > * zfs receive has compression on > > What I actually want to do and what fails: > > > # zfs snapshot storage/bac...@2010.10.19 > > # zfs send storage/bac...@2010.10.19 | zfs receive -v > storage/compressed/bacula > receiving full stream of storage/bac...@2010.10.19 into > storage/compressed/bac...@2010.10.19 > received 4.38TB stream in 42490 seconds (108MB/sec) > > # zfs snapshot storage/bac...@2010.10.20 > > # zfs send -i storage/bac...@2010.10.19 storage/bac...@2010.10.20 | zfs > receive -v storage/compressed/bacula > receiving incremental stream of storage/bac...@2010.10.20 into > storage/compressed/bac...@2010.10.20 > cannot receive incremental stream: destination storage/compressed/bacula > has been modified > since most recent snapshot > warning: cannot send 'storage/bac...@2010.10.20': Broken pipe > > I have no idea why this fails. Clues please? > > To my knowledge, the destination has not been written to. > > > -- > Dan Langille -- http://langille.org/ > > ___ > 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" ___ 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: machine hangs on occasion - correlated with ssh break-in attempts
At 12:38 PM 8/21/2008, Mikhail Teterin wrote:
Hello!
A machine I manage remotely for a friend comes under a distributed ssh
break-in attack every once in a while. Annoyed (and alarmed) by the
messages like:
Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180
Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180
Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180
Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180
I wrote an awk-script, which adds a block of the attacking IP-address to
the ipfw-rules after three such "invalid user" attempts with:
ipfw add 550 deny ip from ip
The script is fed by syslogd directly -- through a syslog.conf rule
("|/opt/sbin/auth-log-watch").
Once in a while I manually flush these rules... I this a good (safe) reaction?
I'm asking, because the machine (currently running 7.0 as of July 7) hangs
solid once every few weeks... My only guess is that a spike in attacks
causes "too many" ipfw-entries created, which paralyzes the kernel due to
some bug -- the machine is running natd and is the gateway for the rest of
the network...
The hangs could, of course, be caused by something else entirely, but my
self-defense mechanism is my first suspect...
Any comments? Thanks!
-mi
I doubt it is your script, or syslog causing the crash. It is likely a
hardware problem of some type if you have this server completely patched
and up-to-date for security patches. I would look at the memory, ethernet,
hard disk, or power supply as the most likely candidates.
-Derek
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bin/121684: : dump(8) frequently hangs
Hello Michael, Sunday, August 31, 2008, 7:12:54 PM, you wrote: > Any progress here? Does anyone know if this will be fixed in 7.1 latest, > or should we start looking for different backup solution (in this case I > would suggest to remove dump from the source tree - having a backup tool > that doesn't work is worse than having none). After upgrading we > basically cannot backup our servers. > Shouldn't this issue be on > http://www.freebsd.org/releases/7.0R/errata.html? I was generally upgrading to new minor version each time it appeared, since usually the minor version number change meant that more bugs were fixed and the whole OS was more started. Now, you honestly scared me. Actually I noticed some regression with dump/restore since 6.x and 7.0 (I reported some bugs, but I don't think there was much concern about them). I don't get why nobody cares about this, I think having a reliable backup is one of the most important things. Now I'm honestly a bit scared about it (even if it will be fixed before 7.1, I'm not sure I'll hurry with the update). -- Best regards, Derekmailto:[EMAIL PROTECTED] Scandisk is now checking your hard drive. You can start praying. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bin/121684: : dump(8) frequently hangs
Hello Kevin, Monday, September 1, 2008, 1:13:24 PM, you wrote: > Thanks for the suggestion. I'm pretty sure I have done a full fsck, but > not positive, so I will try one tomorrow. The system is in a location > which is unmanned today due to the holiday, and a full fsck kind of needs > either a human or remote console. > I have tried both with and without snapshots, so those don't seem to be > the problem. > In any case, I'll know more tomorrow. You can also make a snapshot and run fsck on it. According to the documentation, if system is good state, then fsck on a snapshot should return no errors. I don't know how does it work the other way (i.e. if there are no errors shown, does that mean fs is ok?) -- Best regards, Derekmailto:[EMAIL PROTECTED] Hey! It compiles! Ship it! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bin/121684: : dump(8) frequently hangs
Hello Jeremy, Monday, September 1, 2008, 3:27:38 PM, you wrote: [... links about problems with snapshots ...] the dump can be used without snapshots, in that case is it a still worse method of doing backups? as for the snapshots, you made me even more depressed :) I don't have huge hard disk so I think backup on biggest partition takes a minute (maybe less) which is not so bad. I loved snapshots because the backup that I got was always consistent (I had an opportunity to test it three times already). I only had to remember to lock the database and flush all writes during the snapshot, which was possible to be completely done through a simple script. -- Best regards, Derekmailto:[EMAIL PROTECTED] -- Hidden DOS secret: add BUGS=OFF to your CONFIG.SYS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Funny things with cflags and world/kernel building
Hello Bartosz,
Friday, September 5, 2008, 6:12:12 AM, you wrote:
> My make.conf:
> CPUTYPE=athlon64
> MAKEOPTS=-j3
I would recommend to take that -j3 out from make.conf, it might screw
up make install, not to mention many ports might not build with it.
> # USE CCACHE
> .if !defined(NOCCACHE)
> CC=/usr/local/libexec/ccache/world-cc
> CXX=/usr/local/libexec/ccache/world-c++
> .endif
AFAIK this is setting for building world, the way you set it up seems
to be using it for everything else (i.e. ports)
I belive this is the recommended way of using it:
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) &&
!defined(NOCCACHE)
CC=/usr/local/libexec/ccache/world-cc
CXX=/usr/local/libexec/ccache/world-c++
.endif
> 1. when I use these flags:
> CFLAGS=-O2 -fno-strict-aliasing -pipe
> CXXFLAGS=${CFLAGS}
> COPTFLAGS=${CFLAGS}
> world building finish without problem, but making kernel give an error:
> 2. When I use these flags:
> CFLAGS=-O2 -fno-strict-aliasing -pipe
> CXXFLAGS=-O2 -fno-strict-aliasing -pipe
> COPTFLAGS=-O2 -fno-strict-aliasing -pipe
> kernel build finish without problem, but... building world give an error!:
> 3. What's even more funny? When I use flags:
> CFLAGS=-O2 -fno-strict-aliasing -pipe
> COPTFLAGS=-O2 -fno-strict-aliasing -pipe
> CXXFLAGS=${CFLAGS}
> I have no errors at all! But shouldn't all those flags be treated by
> make command exactly the same way??
I think the strange behavior probably is because make.conf is called
each time a make is executed. Building world, kernel etc. Will call
multiple makes inside of another make. I suspect some of the Makefiles
might append additional flags, so the ${CFLAGS} might change its value
in different parts of the compiling, so that's why you might get the
weird errors.
I guess perhaps you could use the last option since it works, or
instead of using = you would use ?=
i.e.
CFLAGS ?= -O2 -fno-strict-aliasing -pipe
This will assign cflags only if CFLAGS is empty.
--
Best regards,
Derekmailto:[EMAIL PROTECTED]
-- Be nice to your kids. They'll choose your nursing home.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming Releases Schedule...
On Tue, 23 Sep 2008, Ian Smith wrote: >On Mon, 22 Sep 2008, Jo Rhett wrote: > > I think you are using "last release" in a different way. "the last release" > > is always the most release release. Right now 6.3 will have support for > > longer than 6.4 will, which is the nature of the problem I raised. If you > > always supported the most recent release for 24 months then we wouldn't have > > any problem. > >Jo, it seems to be you who are trying to use "last" in an unusual way. >The "last release on a branch" is not the latest one, but the last one. >For 4.x that was .11 and for 5.x it was .5, where last means just that. Let's stop using the word "last" for the time being and instead circumvent the ambiguity via "previous" and "final", perhaps? Maybe if official documentation were updated to avoid this same ambiguity there'd be less misunderstanding too. -Derek. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
Hello Jeremy, Sunday, September 21, 2008, 3:07:20 PM, you wrote: > Consider using background_fsck="no" in /etc/rc.conf if you prefer the > old behaviour. Otherwise, boot single-user then do the fsck. Actually what's the advantage of having fsck run in background if it isn't capable of fixing things? Isn't it more dangerous to be it like that? i.e. administrator might not notice the problem; also filesystem could break even further... -- Best regards, Derekmailto:[EMAIL PROTECTED] I tried to daydream, but my mind kept wandering. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
Hello Jeremy, Friday, September 26, 2008, 10:14:13 PM, you wrote: >> Actually what's the advantage of having fsck run in background if it >> isn't capable of fixing things? >> Isn't it more dangerous to be it like that? i.e. administrator might >> not notice the problem; also filesystem could break even further... > This question should really be directed at a set of different folks, > e.g. actual developers of said stuff (UFS2 and soft updates in > specific), because it's opening up a can of worms. > I believe it has to do with the fact that there is much faith given to > UFS2 soft updates -- the ability to background fsck allows the user to > boot their system and have it up and working (able to log in, etc.) in a > much shorter amount of time[1]. It makes the assumption that "everything > will work just fine", which is faulty. As far as I know (at least ideally, when write caching is disabled) the data should always be consistent, and all fsck supposed to be doing is to free unreferenced blocks that were allocated. Wouldn't be possible for background fsck to do that while the filesystem is mounted, and if there's some unrepairable error, that somehow happen (while in theory it should be impossible) just periodically scream on the emergency log level? > It also gives the impression of a journalled filesystem, which UFS2 soft > updates are not. gjournal(8) on the other hand, is, and doesn't require > fsck at all[2]. > I also think this further adds fuel to the "so why are we enabling soft > updates by default and using UFS2 as a filesystem again?" fire. I'm > sure someone will respond to this with "So use ZFS and shut up". *sigh* I think the reason for using Soft Updates by default is that it was a pretty hard thing to implement, and (at least in theory it supposed by as reliable as journaling. Also, if I remember correctly, PJD said that gjournal is performing much better with small files, while softupdates is faster with big ones. -- Best regards, Derekmailto:[EMAIL PROTECTED] Programmers are tools for converting caffeine into code. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
> Additionally, FreeBSD doesn't offer ZFS as a filesystem during > installation. PC-BSD does, AFAIK. So on FreeBSD, you have to go > through a bunch of rigmarole[5] to get it to work (and doing this > after-the-fact is a real pain in the rear -- believe me, I did it this > weekend.) > So until both of these ZFS-oriented issues can be dealt with, some > users aren't considering it. > This is the reality of the situation. I don't think what users and > administrators want is unreasonable; they may be rough demands, but > that's how things are in this day and age. > Have I provided enough evidence? :-) Yes, but as far as I understand it's not as bad as you think :) I could be wrong though. I 100% agree on disabling background fsck, but I don't think soft updates are making the system any less reliable than it would be without it. Also, I'll have to play with ZFS some day :) -- Best regards, Derekmailto:[EMAIL PROTECTED] It's a little-known fact that the Y1K problem caused the Dark Ages. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD?
Hello Carlos, Tuesday, September 30, 2008, 5:57:06 PM, you wrote: > Do you subscribe freebsd-stable? This has bee discussed recently in this list: > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045506.html I wouldn't call it "discussion". It was mentioned and then quickly it was forgotten. BTW: Matt Dillon, is the founder of DragonflyBSD, which apparently already supports HAMMER. As far as I know, no actual FreeBSD developer commented in that thread yet. -- Best regards, Derekmailto:[EMAIL PROTECTED] How many of you believe in telekinesis? Raise MY hand! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD?
Hello lhmwzy, Tuesday, September 30, 2008, 11:10:24 PM, you wrote: > Yes. > It seems that nobody is interested in this. > -Matt would not port is to FreeBSD,which is a big regretful. I'm pretty sure there are people who are interested, it looks more like there are no people who're capable of doing this and have time. -- Best regards, Derekmailto:[EMAIL PROTECTED] An unemployed court jester is no one's fool. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD?
Hello lhmwzy, Tuesday, September 30, 2008, 11:29:12 PM, you wrote: > That's it. > Since we don't have the skill,what we can do is wait. > Waiting is such a bad thing... Though I don't have too much experience about filesystems, I personally would be interested in this since it would be a pretty good way to learn it. The biggest problem for me right now is the lack of time. I'm a full-time student right now :( If you have some experience in C and time, you can try to do some work, then announce to others. Maybe a developer will volunteer and act as a mentor. As far as I know many FreeBSD developers started that way. I remember PJD 7 years ago telling me that he's learning how to use FBSD, and look at him now :) I don't think "I don't know how to" is a good excuse. -- Best regards, Derekmailto:[EMAIL PROTECTED] -- Will the information superhighway have any rest stops? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pf: unlocked lookup
Hi, My console gets flooded by "pf: unlocked lookup" message anyone knows what circumstances cause this message, so I could figure out which pf rule is causing it? After searching on google I found few people asking about it, though no real answer. The first result talks about debug.pfugidhack being set to 1. It is set to 1 on my system, though I don't have anything in /etc/syctl.conf, also when I switched it to 0, the system crashed within an hour or so. Is this somehow related to rules that have rules with attached to a specific user? Derek P.S. It's FreeBSD 7.2-p4 ___ 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: pf: unlocked lookup
Hello Max, Thursday, December 10, 2009, 9:38:41 AM, you wrote: > this is a generic informational message that was put into the code to figure > out if the hack that is "debug.pfugidhack" is actually required. You can get > rid of the message by setting the debug level of pf to something below "misc" > (e.g. pfctl -x urgent). Well, the hack actually is required, my system crashes when I disable it. > The pfugidhack is automatically enabled when you use rules with user or group > filters. These rules are a layering violation and the hack is required to > make them work. I'd rather get rid of them altogether, but since it is a much > demanded functionality we introduced the workaround instead. > Just lower the debugging level (s.a.), ignore the messages, or rebuild your > kernel/pf module with the respective DPRINTF lines (sys/contrib/pf/net/pf.c) > commented out. I might just move them to the loud level in the main tree, > though. So if I understand correctly, chances of fixing the workaround are really small? At least now I know how to disable those messages, thanks. -- Best regards, Derekmailto:tak...@takeda.tk Come to think of it, there are already a million monkeys on a million typewriters, and Usenet is *nothing* like Shakespeare. -- Blair Houghton ___ 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"
Problems with Atheros card and hostpd
Hello, I just upgraded my access point (from 7.1 to 8.0) and can't make hostapd work (looks like wide-dhcp relay also has a problem with ath0): [mayumi]:/root# hostapd -P /var/run/hostapd.pid -dd /etc/hostapd.conf Configuration file: /etc/hostapd.conf Line 2: DEPRECATED: 'debug' configuration variable is not used anymore ctrl_interface_group=0 (from group name 'wheel') pcap_open_live: ifname='ath0' bsd driver initialization failed. ath0: Unable to setup interface. rmdir[ctrl_interface]: No such file or directory Exit 255 Output from dmesg: ath0: mem 0xf400-0xf400 irq 3 at device 11.0 on pci0 ath0: [ITHREAD] ath0: AR2413 mac 7.9 RF2413 phy 4.5 The interface seems to exist, but seems it lost some of its functionality: [mayumi]:/root# ifconfig ath0 ath0: flags=8843 metric 0 mtu 2290 ether 00:11:95:e5:70:df media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier [mayumi]:/root# ifconfig ath0 list cap ifconfig: Don't know how to list cap for ath0 What's going on? The card worked pretty well with 7.1. I tried to compile kernel just with "device ath_ar5212" but I'm only getting this: ah.o(.text+0x212): In function `ath_hal_rfprobe': /usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__start_set_ah_rfs' ah.o(.text+0x21f):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' ah.o(.text+0x235):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' -- Best regards, Derek mailto:tak...@takeda.tk Wear short sleeves! Support your right to bare arms! ___ 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 Atheros card and hostpd
Hello Boris, I checked the handbook, UPDATING, and nothing mentioned this thing, why? I would think I'm not the only one with this problem, or am I? Anyway it seems to work, I'm getting: Starting hostapd. Configuration file: /etc/hostapd.conf wlan0: IEEE 802.11 Fetching hardware channel/rate support not supported. Using interface wlan0 with hwaddr 00:11:95:e5:70:df and ssid 'mayumi-ap' Is it something I should worry about? Also how to create wlan device by hand? "ifconfig ath0 wlandev wlan0" doesn't seem to work. What initially was worrying me was this: >> ath0: mem 0xf400-0xf400 irq 3 at device 11.0 on pci0 >> ath0: [ITHREAD] >> ath0: AR2413 mac 7.9 RF2413 phy 4.5 I thought that ath0 was using a different driver than it supposed to. There's one more question, though not related to this problem. I have an android phone, and it doesn't seem to work with my FreeBSD AP, while it works on others. After sniffing the traffic, it looks like it is a power management issue: https://supportforums.motorola.com/message/87903#87903 Someone traced the problem to WME/WMM in his case. I don't know if that's the case for me yet, I tried to disable/enable wme on the AP but it doesn't seem to do anything. Is it possible that I might fix it by enabling some option? Anyway, thanks for everyone who helped me fix the initial issue. Derek Wednesday, December 16, 2009, 4:28:49 AM, you wrote: > Multi-BSS support in 8.0 means that you first need to create a wlan > pseudo-device, and run hostapd with that. The rc.conf lines look like this: > wlans_ath0="wlan0" > create_args_wlan0="wlanmode hostap" > ifconfig_wlan0="ssid networkname media autoselect up" > -Boris > Derek Kulinski wrote: >> Hello, >> >> I just upgraded my access point (from 7.1 to 8.0) and can't make >> hostapd work (looks like wide-dhcp relay also has a problem with ath0): >> >> [mayumi]:/root# hostapd -P /var/run/hostapd.pid -dd /etc/hostapd.conf >> Configuration file: /etc/hostapd.conf >> Line 2: DEPRECATED: 'debug' configuration variable is not used anymore >> ctrl_interface_group=0 (from group name 'wheel') >> pcap_open_live: >> ifname='ath0' >> bsd driver initialization failed. >> ath0: Unable to setup interface. >> rmdir[ctrl_interface]: No such file or directory >> Exit 255 >> >> Output from dmesg: >> ath0: mem 0xf400-0xf400 irq 3 at device 11.0 on pci0 >> ath0: [ITHREAD] >> ath0: AR2413 mac 7.9 RF2413 phy 4.5 >> >> The interface seems to exist, but seems it lost some of its >> functionality: >> [mayumi]:/root# ifconfig ath0 >> ath0: flags=8843 metric 0 mtu 2290 >> ether 00:11:95:e5:70:df >> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >> status: no carrier >> [mayumi]:/root# ifconfig ath0 list cap >> ifconfig: Don't know how to list cap for ath0 >> >> What's going on? The card worked pretty well with 7.1. >> >> I tried to compile kernel just with "device ath_ar5212" >> but I'm only getting this: >> >> ah.o(.text+0x212): In function `ath_hal_rfprobe': >> /usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to >> `__start_set_ah_rfs' >> ah.o(.text+0x21f):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference >> to `__stop_set_ah_rfs' >> ah.o(.text+0x235):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference >> to `__stop_set_ah_rfs' >> >> -- Best regards, Derekmailto:tak...@takeda.tk -- I can see clearly now, the brain is gone... ___ 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 Atheros card and hostpd
Hello Boris, Wednesday, December 16, 2009, 5:18:57 PM, you wrote: > 20080420: > The 802.11 wireless support was redone to enable multi-bss > operation on devices that are capable. The underlying device > is no longer used directly but instead wlanX devices are > cloned with ifconfig. This requires changes to rc.conf files. > For example, change: > ifconfig_ath0="WPA DHCP" > to > wlans_ath0=wlan0 > ifconfig_wlan0="WPA DHCP" > see rc.conf(5) for more details. In addition, mergemaster of > /etc/rc.d is highly recommended. Simultaneous update of userland > and kernel wouldn't hurt either. > As part of the multi-bss changes the wlan_scan_ap and wlan_scan_sta > modules were merged into the base wlan module. All references > to these modules (e.g. in kernel config files) must be removed. Ok, now I'm quite embarrassed =) Anyway, thanks for your help. -- Best regards, Derekmailto:tak...@takeda.tk The great thing about Object Oriented code is that it can make small, simple problems look like large, complex ones. ___ 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 Atheros card and hostpd
Hello Sam, Sunday, December 27, 2009, 12:05:34 PM, you wrote: > I didn't see anything in the thread to point a finger at freebsd but > given the debug msg log shows "ath0" instead of "wlan0" I'm guessing > whatever version was being used was pre-8.x. I think I was the only one in thread who used FreeBSD as an AP, also that was before 7.x when I made the log. So I'm not saying it's FreeBSD specific problem, I don't even think it's a BSD problem, but perhaps some kind of incompatibility and I was hoping for some workaround. > Unlikely. Try collecting a packet trace of a failure w/ wireshark or > tcpdump from a 3rd sta and send it to me. Be sure to collect data at > the 802.11 layer (e.g. -y IEEE802_11_RADIO). You might also learn > something by enabling power save debug msgs on the ap w/ wlandebug. Well, I actually managed it to work. Since the phone was rooted I changed settings and disabled WME on the phone. I associated it and it worked. Now there's a weird thing that I don't really get. After I saw that phone was working with WME disabled, I went back and changed it to the way it originally was, I also restarted the phone. To my surprise the phone continued to work (with WME enabled), and I still don't understand why. Perhaps it stored some information necessary? I think I'll deassociate the phone and make it forget the AP and see if it works. -- Best regards, Derekmailto:tak...@takeda.tk You know it's love when you memorize her IP number to skip DNS overhead ___ 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 Atheros card and hostpd
Hello Sam, Sunday, December 27, 2009, 4:55:12 PM, you wrote: >> I think I was the only one in thread who used FreeBSD as an AP, also >> that was before 7.x when I made the log. So I'm not saying it's >> FreeBSD specific problem, I don't even think it's a BSD problem, but >> perhaps some kind of incompatibility and I was hoping for some >> workaround. > AP mode power save was broken for a time in 7.x (IIRC the aging of > frames on the PS q was incorrectly calculated causing them to be tossed > prematurely)--but that was unrelated to WME/WMM. Well, it's possible that when I disabled WME/WMM on android it stopped using power save at all... The behavior was similar to the one you described. It was throwing out packets claiming those were too old, but it worked fine with Linux. I think I already provided the link, but in case I didn't, this is the log that I captured when I was looking for the issue (it's power save debug messages that you mentioned): https://supportforums.motorola.com/message/87903#87903 Does it look ok? How long the packets supposed to be hold before being discarded? I think I should still have logs collected using kismet... > Can't even guess w/o a packet trace and/or debug log. WME should be > immaterial to FreeBSD unless crypto was involved in which case you > might've hit a bug w/ h/w crypto+WME that's long since been fixed > (certain ath parts require the MIC be handled in s/w when WME is used). > The best thing to do wrt FreeBSD is run 8.0 or later for much better > wireless support. Well right now, I can't reproduce the issue anymore. I just tried it; I removed the access point completely, restarted the phone, and hostapd but it still works. Anyway, between my initial post and now I actually upgraded to 8.0 so that could be it, though it puzzles me that linux with power saving enabled worked fine with 7.x (I think it was 7.1) Actually, the reason why I even mentioned the WME is that I observed it working at the time I disabled it on the phone, also what made me experiment with it was post of another person who claimed it fixed his issue which seemed identical to mine (he used a hardware AP though). It's also possible that disables WME on android completely disables power savings. It's possible it could be just a coincidence. I updated to 8.0 around the same time (well actually I tried the WME actually before the upgrade), but it's possible that after I switched it back it continued to work because 8.0 doesn't have the issue anymore? One question, any idea if FreeBSD code could be in HP AP 420 and some other APs? This is the post of the guy that actually made me experiment with WME: https://supportforums.motorola.com/message/88983#88983 -- Best regards, Derekmailto:tak...@takeda.tk Men are from Mars. Women are from Venus. Computers are from hell. ___ 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"
UTF-8 problem in 8.0
Hello, After installing FreeBSD 8.0 I noticed that some characters aren't displayed correctly (it worked fine for 7.2). Mainly the dash character is most noticeable (though it's possible it's more of them). Example: env LANG=C man sh env LANG=pl_PL.UTF-8 man sh env LANG=en_US.UTF-8 man sh The first command shows everything fine, the later two seem to show some unprintable character in place of every dash (i.e. in the second paragraph word "built-in", or the dashes that break up the words at the end of the line) -- Best regards, Derek mailto:tak...@takeda.tk Daddy, why doesn't this magnet pick up this floppy disk? ___ 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: UTF-8 problem in 8.0
Hello Jonathan, Saturday, January 2, 2010, 7:28:07 PM, you wrote: >> me too, though I'm only setting LC_CTYPE to de_DE.UTF-8 and I don't >> always see it. It must be some combination of xterm/ssh and/or putty >> that breaks this. > Actually, I've just got en_NZ.UTF8, and I see it on the console as > well. Put en_NZ.UTF-8 (with the dash), if you set an invalid value it switches to default. -- Best regards, Derekmailto:tak...@takeda.tk If you have a procedure with ten parameters, you probably missed some. -- Alan J. Perlis ___ 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: UTF-8 problem in 8.0
Hello Sean, Sunday, January 3, 2010, 9:03:01 AM, you wrote: > The last commit that I recall (r192561) fixed dashes in front of options > (.Fl macro) but not dashes present within a man page. Personally, I > just create an alias for man to call 'LANG=C man' to protect against > examples with non-ASCII (U+002D) dashes. > Read the commit message[1] for a better explanation of unresolved > issues. > Sean >1. http://svn.freebsd.org/viewvc/base?view=revision&revision=192561 What caused this to be broken? Everything was fine up until 7.2 (or at least I didn't notice this earlier) -- Best regards, Derekmailto:tak...@takeda.tk A seminar on Time Travel will be held two weeks ago. ___ 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"
FreeBSD 7 buildworld error
I csup'ed to RELENG_7_0 (from RELENG_6_3) yesterday and have been having problems building world. After about 10 minutes of building, I get the error: cc1: out of memory allocating 97582896 bytes I have put the full output at <http://www.personal.psu.edu/det135/freebsd.buildworld.20080229>. Someone suggested that I might have a ulimit problem, but that looks ok to me: $ ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) 524288 file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 11095 pipe size(512 bytes, -p) 1 stack size (kbytes, -s) 65536 cpu time (seconds, -t) unlimited max user processes (-u) 5547 virtual memory (kbytes, -v) unlimited Any ideas? I can provide more information at request. -Derek. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7 buildworld error
On Fri, Feb 29, 2008 09:50 PM Sean <[EMAIL PROTECTED]> wrote: > >Check /etc/make.conf for CFLAGS, and if present remove it. This fixed the problem. Thank you. -Derek. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problem reading vitals from Gigabyte H77-DH3H
subclass = SMBus alc0@pci0:2:0:0:class=0x02 card=0xe0001458 chip=0x10831969 rev=0xc0 hdr=0x00 vendor = 'Atheros Communications' device = 'AR8151 v2.0 Gigabit Ethernet' class = network subclass = ethernet pcib4@pci0:3:0:0: class=0x060401 card=0x88921458 chip=0x244e8086 rev=0x41 hdr=0x01 vendor = 'Intel Corporation' device = '82801 PCI Bridge' class = bridge subclass = PCI-PCI em0@pci0:4:1:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82541PI Gigabit Ethernet Controller' class = network subclass = ethernet -- Best regards, Derek mailto:tak...@takeda.tk Never underestimate the bandwidth of a station wagon full of tapes hurling down the highway ___ 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: Problem reading vitals from Gigabyte H77-DH3H
On Wed, Oct 17, 2012 at 11:38:57PM +0300, Andriy Gapon wrote: > I've found that on quite a few modern systems the ACPI platform advertises > some > useless thermal zones, which always return some hardcoded temperatures. > E.g. I have Asus P8Z77-M PRO near me and it also reports two thermal zones. > Looking at DSDT (acpidump -dt) I see that the temperatures are hardcoded. > > It seems that your motherboard has an ITE Super I/O with hardware monitoring > function. I am not sure which model though... > Your best bet would be it(4) driver, but it is not committed yet. > If you are into some mild hacking (applying patches, building custom kernel), > then I can point you to the patches. > Although I can not give a firm guarantee that the driver supports your HWM > chip, > since I don't know the model. I'm open to experimenting. It's kind of important to me, because I recently had heating issue (that I hopefully fixed) and I wasn't aware of problems until my system started freezing. I was fooled by those values thinking everything was ok. > [...] > > These tools from ports are very outdated and thus do not support new hardware. I never used them before since on my old box hw.acpi.thermal worked fine. Is there anything in ports that you would recommend? Thanks, Derek ___ 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: Problem reading vitals from Gigabyte H77-DH3H
Hello Andriy, Friday, October 19, 2012, 6:27:11 AM, you wrote: > Here is a (quite large) patch: > http://people.freebsd.org/~avg/sensors.diff > Please note that if affects both kernel and userland code. > Read it(4) manual page after upgrading. Note that you will need to add some > entries to /boot/device.hints (unless your upgrade procedure would > automatically > merge the file). I applied it to RELENG_9 as of today, recompiled the userland and kernel (I did not see any errors). The it device loaded successfully, unfortunately I don't see any effect; the hw.acpi.thermal does not change (though I guess it not supposed to), sysctl hw.sensors and hw._sensors do not return anything (not even a complaint that it does not exist). sensord returns: sensorsd: no sensors found -- Best regards, Derekmailto:tak...@takeda.tk "unzip; strip; touch; finger; mount; fsck; more; yes; unmount; sleep" - my daily unix command list ___ 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: Problem reading vitals from Gigabyte H77-DH3H
Hello Andriy, Saturday, October 20, 2012, 12:37:19 AM, you wrote: > Does your device.hints file has hints for it(4)? Yes, I did a full install with mergemaster etc. > What are they? hint.it.0.at="isa" hint.it.0.port="0x290" hint.it.1.at="isa" hint.it.1.port="0xc00" hint.it.2.at="isa" hint.it.2.port="0xd00" > Could you please also fetch sysutils/superiotool port from here > https://redports.org/browser/avg/sysutils/superiotool, replace what you have > under /usr/ports, install the port and then run 'superiotool -d' command? No luck: [chinatsu]:/tank/junk/ports/sysutils/superiotool# superiotool -d superiotool r4.0-2827-g1a00cf0 No Super I/O found -- Best regards, Derekmailto:tak...@takeda.tk Hard work pays off in the future. Laziness pays off now. ___ 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: Problem reading vitals from Gigabyte H77-DH3H
It's really late where I live, will do what you mentioned in the morning. I think it is a typo. I believe it is DS3H, but I will confirm that tomorrow. Thank you for helping me with this. -- Sent from my phone. Please excuse my brevity. Andriy Gapon wrote: >on 20/10/2012 11:08 Derek Kulinski said the following: >> Hello Andriy, >> >> Saturday, October 20, 2012, 12:37:19 AM, you wrote: >[snip] >>> Could you please also fetch sysutils/superiotool port from here >>> https://redports.org/browser/avg/sysutils/superiotool, replace what >you have >>> under /usr/ports, install the port and then run 'superiotool -d' >command? >> >> No luck: >> [chinatsu]:/tank/junk/ports/sysutils/superiotool# superiotool -d >> superiotool r4.0-2827-g1a00cf0 >> No Super I/O found > >Hmm, it would be a pity if all of this was a waste of time... >I based some of my assumptions on googling, in particular this post >http://thread.gmane.org/gmane.linux.bios.flashrom/1163 mentioned: >Found ITE Super I/O, ID 0x8728 on port 0x2e >BTW, I suppose "DH3H" in the subject line is a typo? Or is it a >different model? > >Oh, hmm, looks like even the latest superiotool may not have support >for this >newer chip. >Could you please run superiotool -V | fgrep Failed | fgrep -v ff ? >If this command returns id=0x8728, then you could hack superiotool >source code >between running 'make patch' and 'make'. You could edit ite.c file, >search for >0x8726 and either change it to 0x8728 or duplicate the whole section >and make >the change there. > >-- >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" ___ 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: Problem reading vitals from Gigabyte H77-DH3H
Hello Andriy, Saturday, October 20, 2012, 1:26:40 AM, you wrote: > Hmm, it would be a pity if all of this was a waste of time... > I based some of my assumptions on googling, in particular this post > http://thread.gmane.org/gmane.linux.bios.flashrom/1163 mentioned: > Found ITE Super I/O, ID 0x8728 on port 0x2e > BTW, I suppose "DH3H" in the subject line is a typo? Or is it a different > model? Actually it is a typo, the model is H77-DS3H, sorry for the mistake. > Oh, hmm, looks like even the latest superiotool may not have support for this > newer chip. > Could you please run superiotool -V | fgrep Failed | fgrep -v ff ? # superiotool -V | fgrep Failed | fgrep -v ff Failed. Returned data: id=0x8728, rev=0x1 > If this command returns id=0x8728, then you could hack superiotool source code > between running 'make patch' and 'make'. You could edit ite.c file, search > for > 0x8726 and either change it to 0x8728 or duplicate the whole section and make > the change there. After the change I run superiotool with -d, here is the output: superiotool r4.0-2827-g1a00cf0 Found ITE IT8726F (id=0x8728, rev=0x1) at 0x2e Register dump: idx 20 21 22 23 24 2b val 87 28 01 00 00 40 def 87 26 01 00 MM 00 LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 val 00 03 f0 06 02 00 00 def 00 03 f0 06 02 00 00 LDN 0x01 (COM1) idx 30 60 61 70 f0 f1 f2 f3 val 01 03 f8 04 00 50 50 50 def 00 03 f8 04 00 50 00 7f LDN 0x02 (COM2) idx 30 60 61 70 f0 f1 f2 f3 val 00 02 f8 03 00 50 50 50 def 00 02 f8 03 00 50 00 7f LDN 0x03 (Parallel port) idx 30 60 61 62 63 70 74 f0 val 00 03 78 07 78 07 04 0b def 00 03 78 07 78 07 03 03 LDN 0x04 (Environment controller) idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 val 01 0a 30 0a 20 09 00 40 00 00 20 00 f0 def 00 02 90 02 30 09 00 00 00 00 00 MM MM LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 71 f0 val 01 00 60 00 64 01 02 08 def 01 00 60 00 64 01 02 08 LDN 0x06 (Mouse) idx 30 70 71 f0 val 01 0c 02 00 def 00 0c 02 00 LDN 0x07 (GPIO) idx 25 26 27 28 29 2a 2c 60 61 62 63 64 65 70 71 72 73 74 b0 b1 b2 b3 b4 b5 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c8 c9 ca cb cc e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd val 00 f3 10 00 00 00 80 00 00 0a 00 00 00 00 00 20 00 00 00 00 00 00 00 00 20 00 00 00 00 00 01 00 00 40 00 01 00 00 00 00 00 00 00 00 00 10 42 00 00 00 00 1c 00 00 00 00 00 80 00 def 01 00 00 40 00 00 1f 00 00 00 00 00 00 00 00 MM 38 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 40 00 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 MM 00 LDN 0x08 (MIDI port) idx 30 60 61 70 f0 val 00 00 00 00 00 def 00 03 00 0a 00 LDN 0x09 (Game port) idx 30 60 61 val 00 00 00 def 00 02 01 LDN 0x0a (Consumer IR) idx 30 60 61 70 f0 val 00 03 10 0b 06 def 00 03 10 0b 00 -- Best regards, Derekmailto:tak...@takeda.tk There are two ways to write error-free programs; only the third one works. -- Alan J. Perlis ___ 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: Problem reading vitals from Gigabyte H77-DH3H
Hello Andriy, Saturday, October 20, 2012, 11:34:48 AM, you wrote: > If this information is to be trusted (i.e. 8728 is sufficiently compatible > with > 8726), then please try to set port number in the hints to 0xa30 (e.g. where > you > have 0x290 now). It appears to work fine: hw.sensors.it0.fan0: 997 RPM hw.sensors.it0.fan1: invalid hw.sensors.it0.fan2: 1305 RPM hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) hw.sensors.it0.volt1: 2,72 VDC (VCORE_B) hw.sensors.it0.volt2: 2,70 VDC (+3.3V) hw.sensors.it0.volt3: 4,60 VDC (+5V) hw.sensors.it0.volt4: 0,06 VDC (+12V) hw.sensors.it0.volt5: -5,23 VDC (Unused) hw.sensors.it0.volt6: -6,53 VDC (-12V) hw.sensors.it0.volt7: 3,74 VDC (+5VSB) hw.sensors.it0.volt8: 2,14 VDC (VBAT) hw.sensors.it0.temp0: 30,00 degC hw.sensors.it0.temp1: 25,00 degC hw.sensors.it0.temp2: 25,00 degC I have three questions though: 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. Seems like: fan0 -> CPU_FAN (did not try to disconnect it to check :) fan1 -> SYS_FAN1 fan2 -> SYS_FAN2 There is no entry for SYS_FAN3. I disconnected it temporarily but it did not seem to affect the output. Is it possible to get that information from the motherboard? 2. Is there a way for me to figure out which temperature is which? Or at least which one would correspond to H77's temperature? Is it possible that the temperature is not listed? Right now as I check it the component is hot enough to make it hard for me to touch the heat sink. I would think it would be higher than 30C. 3. When will the it module be included with the FreeBSD? Anyway thank you so much for your help so far. At least have meaningful values now that appear to be real (i.e. they change). Can't verify whether the voltages are correct due to my limited knowledge. -- Best regards, Derekmailto:tak...@takeda.tk If brute force doesn't solve your problems, then you aren't using enough. ___ 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: Problem reading vitals from Gigabyte H77-DH3H
Hello Andriy, Saturday, October 20, 2012, 1:09:10 PM, you wrote: > on 20/10/2012 22:42 Andriy Gapon said the following: >> on 20/10/2012 22:20 Derek Kulinski said the following: >>> I have three questions though: >>> 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, >>>and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. >>>Seems like: >>> fan0 -> CPU_FAN (did not try to disconnect it to check :) >>> fan1 -> SYS_FAN1 >>> fan2 -> SYS_FAN2 >>>There is no entry for SYS_FAN3. I disconnected it temporarily but >>>it did not seem to affect the output. Is it possible to get that >>>information from the motherboard? >> >> The driver would have to be updated for that. >> Unfortunately ITE does not provide public datasheets. >> We could pick up some new bits from the Linux driver though. >> http://lxr.linux.no/#linux+v3.6.2/drivers/hwmon/it87.c > In fact, here is a completely untested patch: > http://people.freebsd.org/~avg/it-fans-0x80.diff hw.sensors.it0.fan0: 997 RPM hw.sensors.it0.fan1: invalid hw.sensors.it0.fan2: 1352 RPM hw.sensors.it0.fan3: 1222 RPM hw.sensors.it0.fan4: invalid hw.sensors.it0.volt0: 2,70 VDC (VCORE_A) hw.sensors.it0.volt1: 4,60 VDC (VCORE_B) hw.sensors.it0.volt2: 0,06 VDC (+3.3V) hw.sensors.it0.volt3: -5,08 VDC (+5V) hw.sensors.it0.volt4: -6,53 VDC (+12V) hw.sensors.it0.volt5: 3,74 VDC (Unused) hw.sensors.it0.volt6: 2,14 VDC (-12V) hw.sensors.it0.volt7: 301,15 VDC (+5VSB) hw.sensors.it0.volt8: 298,15 VDC (VBAT) hw.sensors.it0.temp0: 22,00 degC hw.sensors.it0.temp1: -273,15 degC hw.sensors.it0.temp2: -273,15 degC Looks like the 3rd fan is visible. BTW: The value invalid shows when it is unplugged, wouldn't value "0 RPM" make more sense in that case? At least that's what BIOS reports for unplugged fans. Looks like the the temperatures are messed up. Looks like 2 last voltage values is the temperature. > P.S. Just to satisfy my curiosity - could you please add a printf in it_attach > that would print the value read from ITD_COREID? Here it is the output (as decimal): Oct 20 14:08:04 chinatsu kernel: it0 at port 0xa30-0xa37 on isa0 Oct 20 14:08:04 chinatsu kernel: it0: ITD_COREID = 18 As for using Linux CD I can't do it immediatelly, the box does not have cdrom, besides I don't have any image lying around. Any recommendation for something that I could boot from USB and would be able to provide everything you need? -- Best regards, Derekmailto:tak...@takeda.tk The meta-Turing test counts a thing as intelligent if it seeks to apply Turing tests to objects of its own creation. ___ 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: Problem reading vitals from Gigabyte H77-DH3H
Hello Andriy, Saturday, October 20, 2012, 3:09:22 PM, you wrote: >> Looks like the the temperatures are messed up. Looks like 2 last >> voltage values is the temperature. > Oops, right. I've updated the patch at the same URL. Seems like it is still wrong: hw.sensors.it0.fan0: 1005 RPM hw.sensors.it0.fan1: invalid hw.sensors.it0.fan2: 1300 RPM hw.sensors.it0.fan3: 1157 RPM hw.sensors.it0.fan4: invalid hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) hw.sensors.it0.volt1: 2,72 VDC (VCORE_B) hw.sensors.it0.volt2: 2,70 VDC (+3.3V) hw.sensors.it0.volt3: 4,60 VDC (+5V) hw.sensors.it0.volt4: 0,06 VDC (+12V) hw.sensors.it0.volt5: -5,08 VDC (Unused) hw.sensors.it0.volt6: -6,53 VDC (-12V) hw.sensors.it0.volt7: 3,74 VDC (+5VSB) hw.sensors.it0.volt8: 2,14 VDC (VBAT) hw.sensors.it0.temp0: -271,73 degC hw.sensors.it0.temp1: -270,43 degC hw.sensors.it0.temp2: -270,45 degC > Unfortunately, I don't have familiarity with Linux distros either... Will look try something. -- Best regards, Derekmailto:tak...@takeda.tk -- Backup not found: (A)bort (R)etry (T)hrowup ___ 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: Problem reading vitals from Gigabyte H77-DH3H
Hello Andriy, Sunday, October 21, 2012, 1:53:51 AM, you wrote: >> it_16bit_fanrpm(sc, &sc->sensors[0]); >> - else >> + it_generic_svolt(sc, &sc->sensors[5]); >> + it_generic_svolt(sc, &sc->sensors[14]); <- Looks to be a >> copy/paste bug ;-) > Indeed. Should be "stemp" of course. > Thank you! I just fixed the code and looks better now: hw.sensors.it0.fan0: 997 RPM hw.sensors.it0.fan1: invalid hw.sensors.it0.fan2: 1303 RPM hw.sensors.it0.fan3: 1149 RPM hw.sensors.it0.fan4: invalid hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) hw.sensors.it0.volt1: 2,72 VDC (VCORE_B) hw.sensors.it0.volt2: 2,70 VDC (+3.3V) hw.sensors.it0.volt3: 4,60 VDC (+5V) hw.sensors.it0.volt4: 0,06 VDC (+12V) hw.sensors.it0.volt5: -5,08 VDC (Unused) hw.sensors.it0.volt6: -6,53 VDC (-12V) hw.sensors.it0.volt7: 3,74 VDC (+5VSB) hw.sensors.it0.volt8: 2,14 VDC (VBAT) hw.sensors.it0.temp0: 30,00 degC hw.sensors.it0.temp1: 25,00 degC hw.sensors.it0.temp2: 25,00 degC -- Best regards, Derekmailto:tak...@takeda.tk -- DEFINITION: Computer - A device designed to speed and automate errors. ___ 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: Problem reading vitals from Gigabyte H77-DH3H
Hello Jeremy, Monday, October 22, 2012, 6:03:49 AM, you wrote: > I'm not subscribed to the FreeBSD lists any longer, but I did come > across this thread via the web: > http://lists.freebsd.org/pipermail/freebsd-stable/2012-October/070169.html > Either (or both) of you are free to bounce a copy of my Email here to > the list if you feel it'd benefit others. > I have a lot of familiarity with hardware monitoring chips and > interfacing with them (as the author of ports/sysutils/bsdhwmon). > The H/W monitoring chip on that Gigabyte motherboard is **not** the same > or has resistors/pullups that differ from what the OpenBSD sensors > framework code expects. That is quite evident from the below. There > are also very likely labels that are wrong. I'll get to explaining how > to fix that properly further down. > Let me explain in detail one section at a time: >> hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) >> hw.sensors.it0.volt1: 2,72 VDC (VCORE_B) > The term "Vcore" refers to the CPU core voltage. This is a > per-physical-CPU basis. This software is assuming there's 2 physical > CPUs (not cores, I'm talking about physical processors). > VCORE_A may be correct (meaning 1.42V), however it depends on the CPU > model. Derek did not disclose this so I cannot tell you if 1.42V is > considered "correct" or not. Some models run at 1.2V, others 1.5V, > others vary. It is i5-3470 3.2GHz quad core (The entire component list I used to build is here: http://pcpartpicker.com/p/koz3). The CPU is not overclocked, I set "auto" for all this kind of settings in the BIOS. > VCORE_B is probably not VCORE_B at all. However, worse: 2.72V does not > look to be a correct/valid voltage no matter what (even if for an MCH or > a southbridge). So probably a calculation error or its reading the > wrong bits from the chip. >> hw.sensors.it0.volt2: 2,70 VDC (+3.3V) > This is also wrong -- either the voltage or the label. There is no way > your system would be stable if a +3.3V line was at +2.7V. So another > calculation error or reading wrong bits from the chip. >> hw.sensors.it0.volt3: 4,60 VDC (+5V) > This is probably also wrong, but it's hard to say. +5V is relied on > heavily throughout the entire system, so a 0.4V drop is pretty damn > major. So probably another calculation error or reading wrong bits from > the chip. >> hw.sensors.it0.volt4: 0,06 VDC (+12V) > This is flat out completely wrong on numerous levels. >> hw.sensors.it0.volt5: -5,08 VDC (Unused) > No idea. This could be -5V monitoring, but it depends. Only Gigabyte > would know. >> hw.sensors.it0.volt6: -6,53 VDC (-12V) > Also totally wrong (voltage and label). So another calculation error or > reading wrong bits from the chip. >> hw.sensors.it0.volt7: 3,74 VDC (+5VSB) > Also totally wrong (voltage and/or label). "+5Vsb" stands for "+5V > standby"; it's the +5V line that comes off the PSU and is *always on*, > even when the motherboard is off. It's what allows systems to power > back up from sleep state. So another calculation error or reading wrong > bits from the chip. >> hw.sensors.it0.volt8: 2,14 VDC (VBAT) > Also totally wrong (voltage and/or label). "VBAT" refers to the voltage > of the CMOS battery, which should be +3.3V. So another calculation > error or reading wrong bits from the chip. > Here is what proper labels and a proper system should show, as an > example: > # bsdhwmon > CPU1 Temperature 31 C > System Temperature 35 C > FAN10 RPM > FAN20 RPM > FAN30 RPM > FAN4 2042 RPM > FAN50 RPM > FAN6 1875 RPM > VcoreA 1.106 V > MCH Core1.522 V > -12V -12.288 V > V_DIMM 1.712 V > +3.3V 3.392 V > +12V 12.096 V > 5Vsb5.070 V > 5VDD5.118 V > P_VTT 1.142 V > Vbat3.328 V > The bottom line here is this: the problem with the sensors framework is > that it has no concept of per-motherboard engineering (to my knowledge). > Again, that is why I designed bsdhwmon the way I did -- I key off of > SMBIOS string data because it's the only way to do things as reliable as > possible. Each motherboard model requires unique support. Without > that, voltage calculations are either wrong, or labels are completely > wrong, or both. > If I could get within the bowels of Gigabyte and actually talk to a > **real engineer** and not tech support,
Re: Problem reading vitals from Gigabyte H77-DH3H
Hello Jeremy, Monday, October 22, 2012, 9:15:29 AM, you wrote: >> Please let me know if this is enough. > I'll repeat what I wrote: > If I could get within the bowels of Gigabyte and actually talk to a > **real engineer** and not tech support, I could find out if their > GA-H77-DS3H motherboard has SMBus tie-ins for their H/W monitoring chip. > If it does, I **absolutely** could add PROPER support for it to > bsdhwmon. Ok, I guess I won't be much of help here. Do you think trying to find developers through linked-in could work? >> As for the picture of the motherboard, this one >> (http://www.nix.ru/autocatalog/motherboards_gigabyte/135869_2245_draft.jpg) >> looks way better than any of my picture. > The H/W monitoring and Super I/O chip on this board is from iTE, but I > cannot read the silkscreening. The chip model matters. It says: IT8892E 1216-FXS ZC0FYB [snip] > Supermicro Technical Support, comparatively, understands the above > question and will give full documentation for each board you ask for. > I've asked them for 10-12 boards "in bulk" once, and they provided all > the documentation for every board. It takes them about 2 weeks to get > it to you -- because they have to get it from an actual engineer. But > getting this from consumer-focused manufacturers (ex. Asus, Gigabyte, > MSI, and even Intel) is difficult. Don't ask me why. Is there somewhere a list of recommended computer components (or companies) that are helpful, so people who are building computers could take that into account? If I had something like that I would use it when building the box, since its function is to run FreeBSD. > bsdhwmon has no support for iTE chips at this time. It only works with > Supermicro motherboards which (so far) have been (mostly) Winbond chips > (now known as Nuvoton). Some Supermicro boards are also very unique > and strange, such as some of their higher-end blade-based boards, where > things are done very uniquely (in some cases, *2* H/W monitoring chips > are used on the same board, with multiple SMBus slave addresses). Any plans to add support in the future? Otherwise I guess I'll have to live with Andriy's solution. While it's not "kosher" at least provides temperature and fan speed (hopefully the values are correct). The primary reason for starting the thread was discovering that values in hw.acpi.thermal are not real. I though all devices were cool until my computer started freezing after 3 weeks of operation. -- Best regards, Derekmailto:tak...@takeda.tk There are two ways to construct a software design. Make it so simple that there are obviously no deficiencies; or make it so complicated that there are no obvious deficiencies. ___ 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: Why is SU+J undesirable on SSDs?
I personally let it be enabled during installation. I noticed that I was getting errors on fsck even after clean shutdown. After noticing it, I disabled it and the problems go away. Also, fsck works really fast so I don't see much advantage with SU+J. -- Sent from my phone. Please excuse my brevity. Brett Glass wrote: >Have been following the thread related to SU+J, and am wondering: why >is it >considered to be undesirable on SSDs (assuming that they have good wear >leveling)? I have been enabling it on systems with SSDs, hoping that >between >the lack of rotating media and the journaling I would have very robust >systems. > >--Brett Glass >___ >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" ___ 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"
Problems with ZFS's user quota.
Hi everyone, I'm having problem using user quotas in ZFS, I think something is broken, but it very possible that I'm just doing something wrong. I have two problems actually: 1. When trying to define quota for a filesystem that has sub filesystem the zfs userspace behaves weird: [chinatsu]:/tank/system# zfs userspace tank/system TYPENAME USED QUOTA POSIX User root 9,16K none [chinatsu]:/tank/system# zfs set userquota@takeda=7G tank/system [chinatsu]:/tank/system# zfs userspace tank/system TYPENAME USED QUOTA POSIX User root9,16K none POSIX User takeda 7G [chinatsu]:/tank/system# zfs set userquota@takeda=1PB tank/system [chinatsu]:/tank/system# zfs userspace tank/system TYPENAME USED QUOTA POSIX User root9,16K none POSIX User takeda 1P [chinatsu]:/tank/system# zfs set userquota@takeda=none tank/system Is it possible to set quota that would also be inherited by subfilesystem? For example if I have 2 filesystems under tank/system I want them to share the quota, so when I set 7GB the total data use would be 7GB max (and not 7GB per filesystem) 2. Setting quota works fine on filesystem that has files by given users, but does not seem to be enforced (I enabled quota in the kenrel even though I don't belive it is ecessary). [chinatsu]:/tank/system# zfs userspace tank/system/home TYPENAME USED QUOTA [...] POSIX User takeda 6,06G none [...] POSIX User www 1,34G none [chinatsu]:/tank/system# zfs set userquota@takeda=7G tank/system/home [chinatsu]:/tank/system# zfs userspace tank/system/home TYPENAME USED QUOTA [...] POSIX User takeda 6,06G 7G [...] POSIX User www 1,34G none [chinatsu]:/tank/system# sudo su - takeda chinatsu :: ~ » dd if=/dev/zero of=bigfile bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 7.882992 secs (136209934 bytes/sec) chinatsu :: ~ » [chinatsu]:/tank/system# zfs userspace tank/system/home TYPENAME USED QUOTA [...] POSIX User takeda 7,06G 7G [...] POSIX User www 1,34G none [chinatsu]:/tank/system# It looks like ZFS does not allow me set quota in fractions (for example 6.5GB, but I guess that's not that big of a deal). Thank you, Derek ___ 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: Where do I purchace an unlock code to build a custom kernel?
Hello Chris, I can sell you one :) Anyway, I belive what's happening is that you should copy GENERIC not in /usr/src/sys/amd64 directory, but in /usr/src/sys/i386 k7 is a 32 bit CPU so it is i386. Perhaps you could also try building FreeBSD on your faster box, I did that when I had 2 32bit machines and it worked well. I'm assuming setting proper CPU would be enough, but I have yet to try to build 32 version on 64bit. Derek Friday, November 23, 2012, 11:23:23 PM, you wrote: > Sorry, that _should_ have read: > RELENG_8 >> Greetings, >> I've been running a RELENG_* box for some time now. I recently slipped the >> same CD into an older AMD k7 box, and performed an install && cvsup. >> I then promptly cd /usr/src/sys/amd64/conf && cp GENERIC CUSTOM. >> edited CUSTOM to taste, cd /usr/src && make buildworld; wait _hours_. >> Then performed: >> make buildkernel KERNCONF=CUSTOM >> which produced >> ERROR: Missing kernel configuration files. >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> >> Looks like I got bit by: >> 20100502: >> The config(8) command has been updated to maintain compatibility >> with config files from 8.0-RELEASE. You will need a new version >> of config to build kernels (this version can be used from 8.0-RELEASE >> forward). The buildworld target will generate it, so following >> the instructions in this file for updating will work glitch-free. >> Merely doing a make buildkernel without first doing a make buildworld >> (or kernel-toolchain), or attempting to build a kernel using >> traidtional methods will generate a config version warning, >> indicating >> you should update. >> >> So I performed: make kernel-toolchain, and tried again. STILL no joy. >> >> So I tried: >> To build a kernel >> - >> If you are updating from a prior version of FreeBSD (even one just >> a few days old), you should follow this procedure. It is the most >> failsafe as it uses a /usr/obj tree with a fresh mini-buildworld, >> >> make kernel-toolchain >> make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=YOUR_KERNEL_HERE >> make -DALWAYS_CHECK_MAKE installkernel KERNCONF=YOUR_KERNEL_HERE >> >> STILL no joy. Looks like I need to purchase a special kernel unlock key to >> build >> a kernel. :( >> >> Thank you for all your time, and consideration. >> >> --Chris >> >> ___ >> 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" >> > ___ > 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" -- Best regards, Derekmailto:tak...@takeda.tk -- Look out for #1. Don't step in #2 either. ___ 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: Where do I purchace an unlock code to build a custom kernel?
Hi Chris, Friday, November 23, 2012, 11:50:16 PM, you wrote: > Thank you! Yes, I _did_ know k7 was actually i(x)86, but figured config(8) > would "throw me a bone" if it were wrong. > Anyway, I'll take your advice. There are some architecture specific settings there, so it is best to actually do this and fail it early (well if you would do buildkernel it would be earlier :) than getting some strange errors. If you were thinking to just copy it to i386 directory, to save you future issues, I would recommend you to redo the config based on GENERIC in i386 directory. -- Best regards, Derekmailto:tak...@takeda.tk The Internet: where men are men, women are men, and children are FBI agents. ___ 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: Strange problem with... ZFS? Disk? Controller?
Hello Alex, SMART values are collected by the disk itself (smartmontools is only reading it). This would imply that the problem is between disk and controller. Since you have tons of Hardware_ECC_Recovered and none of UDMA_CRC_Error_Count I would think that the problem is with disk itself. I think the long waits are due to disk trying to re-read given sector multiple times. Your drive is 2TB, and according to this the bigger the drive the more likely you'll run into problems like these: http://forums.storagereview.com/index.php/topic/27994-smart-hardware-ecc-recovered-values/ I don't know how serious it is but if you keep anything important there I would recommend a backup. You should try SMART self tests. Best regards, Derek Saturday, December 22, 2012, 12:20:27 AM, you wrote: > Hello, > I'm running FreeBSD 9.0/amd64, pure ZFS setup, one Seagate disk > ST2000NM0011 SN02 on LSI Logic (mpt) controller. > Yes, I know that running one disk on RAID controller is a bit weird, I > have to find yet if it is possible to connect disk to internal SATA > controller. > About two days ago, system became SLOW. Disk usage is constantly 100%, > and sometimes I'm getting swap_pager: indefinite wait buffer error. I > had to reset computer twice in two days. > mptutil does not show any errors, and smartctl shows > SMART Attributes Data Structure revision number: 10 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED > WHEN_FAILED RAW_VALUE >1 Raw_Read_Error_Rate 0x000f 067 063 044Pre-fail > Always - 6218970 >3 Spin_Up_Time0x0003 093 092 000Pre-fail > Always - 0 >4 Start_Stop_Count0x0032 100 100 020Old_age > Always - 14 >5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail > Always - 21 >7 Seek_Error_Rate 0x000f 091 060 030Pre-fail > Always - 1433294073 >9 Power_On_Hours 0x0032 090 090 000Old_age > Always - 8825 > 10 Spin_Retry_Count0x0013 100 100 097Pre-fail > Always - 0 > 12 Power_Cycle_Count 0x0032 100 100 020Old_age > Always - 16 > 184 End-to-End_Error0x0032 100 100 099Old_age > Always - 0 > 187 Reported_Uncorrect 0x0032 100 100 000Old_age > Always - 0 > 188 Command_Timeout 0x0032 100 099 000Old_age > Always - 12885098499 > 189 High_Fly_Writes 0x003a 100 100 000Old_age > Always - 0 > 190 Airflow_Temperature_Cel 0x0022 068 047 045Old_age > Always - 32 (Min/Max 31/32) > 191 G-Sense_Error_Rate 0x0032 100 100 000Old_age > Always - 859 > 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age > Always - 15 > 193 Load_Cycle_Count0x0032 100 100 000Old_age > Always - 26 > 194 Temperature_Celsius 0x0022 032 053 000Old_age > Always - 32 (0 21 0 0 0) > 195 Hardware_ECC_Recovered 0x001a 103 099 000Old_age > Always - 6218970 > 197 Current_Pending_Sector 0x0012 100 100 000Old_age > Always - 0 > 198 Offline_Uncorrectable 0x0010 100 100 000Old_age > Offline - 0 > 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age > Always - 0 > SMART Error Log Version: 1 > No Errors Logged > I have removed most of snapshots, it does not help. > I have stopped all active processes, disk load did not decrease, same 100%. > What can I check and/or replace to get the problem fixed? Any ideas? > Alex > ___ > 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" -- Best regards, Derekmailto:kulin...@cs.ucla.edu If you choke a Smurf, what color does it turn? ___ 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"
FreeBSD 9.1-RELEASE crashes almost daily; backtraces always list zfs routines
Please help, I reported this issue on http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/174372 but the crashes are unbearable since they happen regularly at night, most of the time when periodic.daily is called (3am) but there are exceptions. It seems like it can be triggered by any heavy disk activity. In many of the crash dumps the current process is find command, but of course that's does not always is the cause. When calling scrub, it appears to pass successfully. Smartmon tools is not reporting any disk errors. I tested memory using memtest86 about a month ago and it passed tests successfully. I never had this type of issue on 9.0, and not much changed in my kernel config besides installing WiFi card. System: FreeBSD chinatsu.takeda.tk 9.1-RELEASE FreeBSD 9.1-RELEASE #2 r244482: Wed Dec 19 23:28:15 PST 2012 r...@chinatsu.takeda.tk:/usr/obj/usr/src/sys/CHINATSU amd64 It's compiled from releng/9.1 branch. Thank you for any help, Derek Example crash messages: Today: panic: general protection fault cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1cd trap_fatal() at trap_fatal+0x285 trap() at trap+0x23e calltrap() at calltrap+0x8 --- trap 0x9, rip = 0x8101f5ac, rsp = 0xff8230ac18c0, rbp = 0xff8230ac18d0 --- list_prev() at list_prev+0xc arc_evict() at arc_evict+0x194 arc_adjust() at arc_adjust+0x1a1 arc_reclaim_thread() at arc_reclaim_thread+0x1a6 fork_exit() at fork_exit+0x11c fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8230ac1bb0, rbp = 0 --- Uptime: 20h44m51s Dumping 1157 out of 8072 MB:..2%..12%..21%..31%..41%..52%..61%..71%..81%..92% Yesterday: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xffe8 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8102d1e7 stack pointer = 0x28:0xff82315ec190 frame pointer = 0x28:0xff82315ec280 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 34744 (find) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1cd trap_fatal() at trap_fatal+0x285 trap_pfault() at trap_pfault+0x216 trap() at trap+0x363 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x8102d1e7, rsp = 0xff82315ec190, rbp = 0xff82315ec280 --- arc_evict() at arc_evict+0x1e7 arc_get_data_buf() at arc_get_data_buf+0x1d5 arc_read_nolock() at arc_read_nolock+0x1ec arc_read() at arc_read+0x93 dbuf_read() at dbuf_read+0x452 dmu_buf_hold() at dmu_buf_hold+0xe0 zap_lockdir() at zap_lockdir+0x58 zap_cursor_retrieve() at zap_cursor_retrieve+0x19b zfs_freebsd_readdir() at zfs_freebsd_readdir+0x2ee VOP_READDIR_APV() at VOP_READDIR_APV+0x4a kern_getdirentries() at kern_getdirentries+0x225 sys_getdirentries() at sys_getdirentries+0x23 amd64_syscall() at amd64_syscall+0x5d8 Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (196, FreeBSD ELF64, sys_getdirentries), rip = 0x80089b29c, rsp = 0x7fffd8a8, rbp = 0x1 --- Uptime: 2d3h49m3s Dumping 3701 out of 8072 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% -- Best regards, Derek mailto:tak...@takeda.tk ___ 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: FreeBSD 9.1-RELEASE crashes almost daily; backtraces always list zfs routines
Hello Andriy, Monday, December 24, 2012, 8:01:26 AM, you wrote: > on 24/12/2012 00:23 Derek Kulinski said the following: >> Dumping 3701 out of 8072 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > So do you have the crash dump(s)? Yes, but they are 3.5GB each. I attached text dump to GNATS but I can resend it to you (I don't know if it's ok to send attachments to the mailing list). If you would prefer I could give you access to the box. -- Best regards, Derekmailto:tak...@takeda.tk -- Programmer - A red-eyed, mumbling mammal capable of conversing with inanimate objects. ___ 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: FreeBSD 9.1-RELEASE crashes almost daily; backtraces always list zfs routines
Hello Mark, Monday, December 24, 2012, 12:46:53 PM, you wrote: > On Mon, Dec 24, 2012 at 10:17:19AM -0800, Derek Kulinski wrote: >> Yes, but they are 3.5GB each. I attached text dump to GNATS but I can >> resend it to you > We have a limit of 500K on GNATS PRs. For something that huge, a PR > database is really not the right place for it -- please post the dumps > somewhere and include a URL to them in a followup to the PR. > Thanks. > Mark Linimon, on behalf of bugmeister I included the text dump, but I do not see it when I visit the web interface so I don't know if it was attached there or not. -- Best regards, Derekmailto:tak...@takeda.tk My new car runs at 56Kbps ___ 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: FreeBSD 9.1-RELEASE crashes almost daily; backtraces always list zfs routines
b7 Dec 24 16:06:04 chinatsu kernel: kern_unlinkat() at kern_unlinkat+0x2eb Dec 24 16:06:04 chinatsu kernel: amd64_syscall() at amd64_syscall+0x30e Dec 24 16:06:04 chinatsu kernel: Xfast_syscall() at Xfast_syscall+0xf7 Dec 24 16:06:04 chinatsu kernel: --- syscall (10, FreeBSD ELF64, sys_unlink), rip = 0x80090a22c, rsp = 0x7fff Dec 24 16:06:04 chinatsu kernel: ca88, rbp = 0x7fffdf20 --- Dec 24 16:06:04 chinatsu kernel: lock order reversal: Dec 24 16:06:04 chinatsu kernel: 1st 0xfe00266ddbd8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:849 Dec 24 16:06:04 chinatsu kernel: 2nd 0xfe002679a818 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158 Dec 24 16:06:04 chinatsu kernel: KDB: stack backtrace: Dec 24 16:06:04 chinatsu kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Dec 24 16:06:04 chinatsu kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 24 16:06:04 chinatsu kernel: _witness_debugger() at _witness_debugger+0x2c Dec 24 16:06:04 chinatsu kernel: witness_checkorder() at witness_checkorder+0x844 Dec 24 16:06:04 chinatsu kernel: __lockmgr_args() at __lockmgr_args+0x10d9 Dec 24 16:06:04 chinatsu kernel: vop_stdlock() at vop_stdlock+0x39 Dec 24 16:06:04 chinatsu kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbf Dec 24 16:06:04 chinatsu kernel: _vn_lock() at _vn_lock+0x47 Dec 24 16:06:04 chinatsu kernel: vget() at vget+0x7b Dec 24 16:06:04 chinatsu kernel: devfs_allocv() at devfs_allocv+0x13f Dec 24 16:06:04 chinatsu kernel: devfs_root() at devfs_root+0x4d Dec 24 16:06:04 chinatsu kernel: vfs_donmount() at vfs_donmount+0xafa Dec 24 16:06:04 chinatsu kernel: sys_nmount() at sys_nmount+0x66 Dec 24 16:06:04 chinatsu kernel: amd64_syscall() at amd64_syscall+0x30e Dec 24 16:06:04 chinatsu kernel: Xfast_syscall() at Xfast_syscall+0xf7 Dec 24 16:06:04 chinatsu kernel: --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a8d71c, rsp = 0x7fffccc8, rbp = 0x801009048 --- Dec 24 16:06:05 chinatsu named[1387]: starting BIND 9.8.3-P4 -t /var/named -u bind Dec 24 16:06:05 chinatsu kernel: Starting named. -- Best regards, Derekmailto:tak...@takeda.tk People say Microsoft paid 14M$ for using the Rolling Stones song 'Start me up' in their commercials. This is wrong. Microsoft payed 14M$ only for a part of the song. For instance, they didn't use the line 'You'll make a grown man cry'. ___ 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: FreeBSD 9.1-RELEASE crashes almost daily; backtraces always list zfs routines
Hello Andriy, Tuesday, December 25, 2012, 12:18:23 AM, you wrote: >> I recompiled the kernel and is running with options you specified (I >> enabled DEBUG in the file). >> >> Anyway even at boot time I started getting following warnings, is this >> anything: > These witness warning are OK-ish. > Watch for panics. Sadly (I guess :) I did not have crash today (I don't see even a warning at that time), I'll update when it happens. Will also try to run that task today and will see if it will do anything. > BTW, I should have said this earlier. Whatever the kind of the corruptions it > would be much worse if a corruption would get propagated to the stable > storage. > Especially if it would be in any kind of pool metadata. > So, your data is at great risk now. > Please also take measures to back it up. Preferably by using a different > system. I'm backing it up using zfs send since dump doesn't appear to work on ZFS. Anyway zpool scrub does not show any problems... I performed my last scan when I started this thread. -- Best regards, Derekmailto:tak...@takeda.tk Hand over the calculator, friends don't let friends derive drunk ___ 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: Does / Is anyone maintaining CVS for FreeBSD?
Monday, December 31, 2012, 12:40:47 PM, you wrote: > That's what I was afraid I would hear. Recently, I was informed by SF.NET, > that my account would be upgraded, and all the projects I have, which all > use CVS, would be "upgraded" to SVN (which renders them useless). When I > asked why, they told me because CVS was so old. To which I stated: > Indeed, CVS is _quite_ old, and so is TCP/IP. Yet no one can seem live > without it. > Sigh... > IM(NS)HO; SVN is an inferior RCS created so Windows users wouldn't feel > left out. > Are there _any_ CVS servers/trunks/tree's left? If so, how _current_ are > they? Chris, few years back I decided myself to try SVN after extensively using CVS. I was scared that many of existing scripts will become broken. And that actually was true, but SVN already had all the tools that I used. In fact it offered more functionality and also creating hooks was easier. CVS started as a hack that was about putting together RCS tools. I could be wrong, but I remember reading somewhere that it started first as a script that was simply calling them. SVN is a tool that was primarily based on CVS. The idea was to fix all the CVS issues that resulted from its RCS origins and I think they succeeded. On top of that the SVN is much simpler to use and set up. I cannot really recall anything that CVS offer which SVN doesn't. In my opinion a single feature of svn is good enough to switch from cvs to svn. That feature is atomic commit, and there many more. For example branches and tags are far easier to understand and far more reliable. I recently (well, kind of since it was 2 years ago) tried git and while I was initially set against it due to how much more complicated it is with time I learned to love its features and the workflow that it imposes suites me well. That said I would totally understand you being upset if FreeBSD would decide to switch to git, since despite its benefits that is a huge change, and would definitely be hard for people to adjust. -- Best regards, Derekmailto:tak...@takeda.tk -- Hit any user to continue. ___ 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: 9.1 file content
Hello Zoran, Monday, December 31, 2012, 8:33:43 AM, you wrote: > I'm quite happy to see 9.1 out and want to ask polite and > benevolent question: > regarding times on the site, are iso and img files the same > as 2 weeks ago? To remind noble readers. I installed on my > computers what was release at that time and got it up and > working perfectly. In other words, is it the same file? > Best regards and happy new year If uname on the machine shows 9.1-RELEASE then it is, if not then at least sys/conf/newvers.sh is different. -- Best regards, Derekmailto:tak...@takeda.tk It is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead. -- Edsgar W. Dijkstra ___ 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: Does / Is anyone maintaining CVS for FreeBSD?
Hello Alfred, Tuesday, January 1, 2013, 12:17:17 PM, you wrote: >> Just In Case: >> >> FreeBSD has no plans to switch to get in either the short or long >> term. We will however offer git repositories and first-class cousins >> via git.freebsd.org and github. >> > Are you sure? Most of the diffs developers have been handing me lately > are of the form a/path b/path so I think they are mostly using git > behind the scenes. One of nice things about git is that it can work with many popular SCM schemes. So you can have a cake and eat it too. People who like git can just check in the repo to their local disks and work on it using git features without forcing rest of the developers to use git. There apparently is also freebsd git repo that allows to do it, but you can connect it straight to svn (or even cvs). -- Best regards, Derekmailto:tak...@takeda.tk The best accelerator available for a Mac is one that causes it to go at 9.81 m/s2. ___ 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: Does / Is anyone maintaining CVS for FreeBSD?
Hello Kevin, Monday, December 31, 2012, 2:39:15 PM, you wrote: > All of that said, I still use CVS for on thing, RANCiD. (It is a > system for managing router and switch configurations).It can use > either CVS or SVN, but I keep the data is CVS as there is considerable > advantage to being able to grep through the delta files to looks for > some bit that has long been deleted. (We have about15 years worth of > router configurations in our archive.) But this is a special case. I > would never recommend anyone use CVS for general purpose code > management, (Not sure I'd recommend svn, either, but others are far > more of a change from CVS. I don't think svn has this functionality out of the box, but it looks like http://svn-search.sourceforge.net/ offers it, but I'm not 100% sure. Git appears to have it, I believe git log -S does this: http://www.kernel.org/pub/software/scm/git/docs/git-log.html This man page of just a single git command is a perfect example showing that while git is extremely powerful it is also very complicated. For a comparison, this is svn log: http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.log.html and cvs log: http://www-e815.fnal.gov/webspace/cvs/commands.html#log -- Best regards, Derekmailto:tak...@takeda.tk All wiyht. Rho sritched mg kegtops awound? ___ 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: Does / Is anyone maintaining CVS for FreeBSD?
Hello Doug, Tuesday, January 1, 2013, 9:30:14 PM, you wrote: >> Thank God! I'd hate to think that after unwinding years accumulated >> CVS process, to rewind it for SVN, only to have to do it again for GIT, >> just seems a bit masochistic. > Is the cvs code going away? I'm not in any way FreeBSD dev, but looks like yes, it goes away. In fact last time I fetched sources using cvsup they were outdated and my understanding is that cvsup was getting the files from cvs repo. > I ask because I maintain a number of > local CVS repositories of code for which I am the only > developer/maintainer. I also use grep on the repositories to find > sections of code previously created and removed for future use. I > can't bill my clients for conversion to SVN so that cost I would > have to eat. I am not particularly thrilled about having to do so. > I don't need most of the CVS features. About all I do is check in. > Occasionally I botch up a module enough that I delete it and recover > it from CVS. I don't use branches or tags. Subversion has a tool to automatically convert cvs repos to subversion. I believe that's how FreeBSD was converted. -- Best regards, Derekmailto:tak...@takeda.tk Why doesn't DOS ever say "EXCELLENT command or filename!" ___ 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: Does / Is anyone maintaining CVS for FreeBSD?
Eitan Adler wrote: >On 2 January 2013 06:26, Chris Rees wrote: >> To clarify, no-one wants to remove CVS completely, the suggestion was >to >> move it out of the base system. > >As the developer responsible for this: > >CVS will be removed from base. It already exists as a port in >devel/cvs Will svn be added to the base? Not long ago I run into an issue when trying to downgrade my system to 9.0. After I noticed how majority of ports were broken due to changes in the libc I decided to back out by fetching 9.1 release just to learn that svn does not work as well. There were a lot of dependencies I decided to use portupgrade which required me to recompile ruby. After that it was a lot of compiling (for example Apache because apr was broken). Having svn in the base would save tons of time in my situation. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ 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"
Determining which process needs to be restarted after update
Hello everyone, I personally really like OpenSuSE command which is: zypper ps What it does is it lists all processes that have files opened that currently don't exist (i.e. link count is 0). This helps tremendously in determining which processes need to be restarted after an update. Is there something similar for FreeBSD? I was thinking of using lsof +L1, but on FreeBSD that command is not capable of displaying names of files that were deleted, many entries returned are for example processes that have open sockets. It also does not list names of the deleted/replaced files. Is there a tool that is capable to do such task, or maybe some additional options to lsof? I'm not too familiar with it myself. -- Best regards, Derek mailto:tak...@takeda.tk -- Look out for #1. Don't step in #2 either. ___ 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: Deleting the top-level ZFS file system (without affecting its children)
Hello xenophon+freebsd, Saturday, January 12, 2013, 12:47:25 PM, you wrote: >> Why would rm -rf /oldroot/* not return all the allocated space? >> I can only think of snapshots keeping the space allocated, but >> you can remove those too. Can you elaborate on that? > This will free space in the file system (as shown by df), but it won't > return the space to the pool. It looks like ZFS won't let you shrink > file systems yet. As far as I understand your question - yes it will return the space. Unless you explicitly told ZFS to reserve specific amount of space it takes as much space as given filesystems currently needs. There's no expanding/shrinking in ZFS because ZFS filesystems are not partitioning the disk in the general meaning of that word. The ZFS filesystems behave in a very similar way to directories. -- Best regards, Derekmailto:tak...@takeda.tk -- Press any key... no, no, no, NOT THAT ONE! ___ 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: svn - but smaller?
"Sergey V. Dyatko" wrote: >You may: >1/ install subversion on some host/jail >2/ do svn export ( f.e. svn://svn.freebsd.org/base/releng/9 stable_9) >3/ tar it >4/ on 'client' fetch(1)/scp/rsync tarball > >in that case you don't need svn on 'client', fetch and scp in base :) If you go through all of that why not just install the damn svn from ports? I think you don't understand the reason why people are asking for this. I personally experienced the need not long ago. I had stable/9 branch and wanted to downgrade to 9.0. The entire process went well until I rebooted the system, to see tons of errors in pretty much everything that was compiled from ports. Instead recompiling them from scratch I just decided to go ahead and upgrade to 9.1 which was not officially released yet. And of course I could not perform svn sw because svn was broken too. And since svn has tons of dependencies it took me nearly an hour to recompile them (portupgrade and Ruby were broken too). -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ 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: svn - but smaller?
Hello Sergey, Thursday, January 24, 2013, 10:09:58 PM, you wrote: >> I think you don't understand the reason why people are asking for >> this. I personally experienced the need not long ago. I had stable/9 >> branch and wanted to downgrade to 9.0. The entire process went well >> until I rebooted the system, to see tons of errors in pretty much >> everything that was compiled from ports. Instead recompiling them >> from scratch I just decided to go ahead and upgrade to 9.1 which was >> not officially released yet. > how in this case you would have helped availability lite-svn-client on > base ? The base worked fine, the ports were completely broken. And even if it was somehow broken (perhaps buildworld did not correctly built it) if it was part of the base it would not depend on any external ports. >> And of course I could not perform svn sw because svn was broken too. > r232944 | lev | 2009-04-29 15:11:17 +0300 > ... > (3) Add STATIC option to build only static binaries [2] > ... While that would not apply to my case (switch within major version), what about ABI incompatibilities? >> And since svn has tons of dependencies it took me nearly an hour to >> recompile them (portupgrade and Ruby were broken too). > that's why I don't use portupgrade for a long time;-) > use portmaster WTF Other than that it works very well, but I will give portmaster a try. -- Best regards, Derekmailto:tak...@takeda.tk Cole's Law: Thinly sliced cabbage. ___ 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"
5.4Pre sched_ule SMP XOrg hangs or reboots
Hi, i have become fascinated with getting sched_ule to run reliably, and I've been running tests with about 8 different configurations. I've listed some of them and the results at my website, at http://noogenesis/freebsd/testing_ule, the index html for which I've also attached to this email. I have not yet succeeded in getting a core dump from the kernel, any advice on coaxing a kernel panic instead of a hang so that a core dump can be obtained, let me know. The score is this, I get a hard hang (capslock/numlock do not respond, can't ping) when running XOrg, always after loading the program nicotine (ports/net/nicotine), which is a python/gtk2 program. Sometimes, it has done a sudden reboot instead of a hang, and I haven't had much luck reproducing these results with any other program in X reliably. Also, I have not had any hang at all when not running X. As far as testing goes, ive generally recompiled the kernel with -j8 as a stress test, without XOrg, and have had no problems with any configuration. So the bug on my system involving sched_ule seems to be brought out by something nicotine is doing within the first minute or so of loading up. I do think that nicotine uses gdk threads, which use the posix threads, so the connection could be there... I'm going to continue to search/test things as I think of them, but any advice as to what to check next would be helpful. One thing that my results there don't list is the following: Never had a crash or hang with SMP disabled (even with sched_ule enabled). Also never had a crash or hang with sched_4bsd and SMP enabled. My system is a Tyan Tiger MP motherboard with dual athlon MPs. Any other information that you might find helpful to know, let me know. Also: what other email lists should I post this too, if any? Should I make this into a problem report? sched_ule is already known to have problems... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4Pre sched_ule SMP XOrg hangs or reboots
Kris Kennaway wrote: On Sun, Mar 27, 2005 at 04:07:05PM -0500, Derek VerLee wrote: Hi, i have become fascinated with getting sched_ule to run reliably, and I've been running tests with about 8 different configurations. I've listed some of them and the results at my website, at http://noogenesis/freebsd/testing_ule, the index html for which I've also attached to this email. I have not yet succeeded in getting a core dump from the kernel, any advice on coaxing a kernel panic instead of a hang so that a core dump can be obtained, let me know. Unfortunately ULE is known to still be broken. This isn't likely to be fixed before 5.4-RELEASE. Kris I am actually aware of this. I just thought my testing might be helpful to someone. Probably "everyone" is tied up with getting things together for 5.4 release, I guess. But nobody cares about sched_ule right now? What about later? Should I forward to -hackers or -current? Not to waste anymore of anyone's time or bandwidth. Its just that I am having fun using this as excuse to learn about the inner workings of the freebsd kernel. ( Its a bit bigger but oh so much more well written then NACHOS.. heh =P ) _derek ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Recompile milters after sendmail 8.14 upgrade
At 12:21 AM 4/20/2007, Gregory Shapiro wrote: sendmail has been updated from version 8.13.8 to 8.14.1 in the HEAD and RELENG_[456] branches. This upgrade includes a new libmilter library which requires all dynamically linked milters to be recompiled (no source code changes are required). Unfortunately, this problem (the need to recompile filters) was found after the MFC. The release engineering team has asked for this notice instead of doing a full backout of sendmail 8.14 in the RELENG_[456] branches. I'm sorry for the adverse effects from the change and will be more careful with future sendmail commits. For those of us with RELENG_[456] servers do we just need to buildworld and installworld? -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 2.2.9 Released
Hello Colin, Saturday, April 1, 2006, 2:43:13 PM, you wrote: > Look at the date on Scott's email. :-) Yeah, It's all wrong he set his clock 7 years into the future. -- Best regards, Derekmailto:[EMAIL PROTECTED] http://www.takeda.tk -- RAM disk is *not* an installation procedure. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make problems as non root user
Hello Chris, Sunday, April 2, 2006, 12:02:18 PM, you wrote: > This happens with a lot of source apps, eggdrop, psybnc, ultimateircd etc. > It only happens as non root users. > It seems to only happen right after running configure, so if I do > anything like cd . or logout and relogin as the user there is no > problem. So to reoccur the problem run ./configure then make and bam > the access denied, simply typing make again will give same error but > then do anything else that requires a dir traversal it works. > this happened in freebsd 5.x as well but I believe it doesnt occur in > freebsd 4.x. I'm also confirming that. I would like add that I also saw this issue in 4.x (actually I seem to encounter it as long as I use FreeBSD) -- Best regards, Derekmailto:[EMAIL PROTECTED] http://www.takeda.tk Bureaucrats cut red tape, lengthwise. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
stack backtrace
Hello, Today I noticed following message in the log: > KDB: stack backtrace: > kdb_backtrace(c07163b8,2,c661994c,0,22) at kdb_backtrace+0x2e > getdirtybuf(d109ebac,0,1,c661994c,1) at getdirtybuf+0x2b > flush_deplist(c282f4cc,1,d109ebd4,d109ebd8,0) at flush_deplist+0x57 > flush_inodedep_deps(c15ba800,22a8a,c2760a7c,d109ec34,c04f7f87) at > flush_inodedep_deps+0x9e > softdep_sync_metadata(d109eca4,c2760a50,50,c06ea8f0,0) at > softdep_sync_metadata+0x9d > ffs_fsync(d109eca4,0,0,0,0) at ffs_fsync+0x4b2 > fsync(c17ba000,d109ed14,4,d109ed3c,c0515916) at fsync+0x1a1 > syscall(c069002f,2f,2f,81522b0,81522b0) at syscall+0x370 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (95, FreeBSD ELF32, fsync), eip = 0x28143dcf, esp = 0xbfbfd34c, > ebp = 0xbfbfd358 --- > KDB: stack backtrace: > kdb_backtrace(c07163b8,2,c6683118,0,22) at kdb_backtrace+0x2e > getdirtybuf(d1098bac,0,1,c6683118,1) at getdirtybuf+0x2b > flush_deplist(c282facc,1,d1098bd4,d1098bd8,0) at flush_deplist+0x57 > flush_inodedep_deps(c15ba800,1e9a4,c24cc974,d1098c34,c04f7f87) at > flush_inodedep_deps+0x9e > softdep_sync_metadata(d1098ca4,c24cc948,50,c06ea8f0,0) at > softdep_sync_metadata+0x9d > ffs_fsync(d1098ca4,0,0,0,0) at ffs_fsync+0x4b2 > fsync(c17b9c00,d1098d14,4,c17b9c00,7) at fsync+0x1a1 > syscall(2f,2f,bfbf002f,8111fe0,0) at syscall+0x370 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (95, FreeBSD ELF32, fsync), eip = 0x282dfdcf, esp = 0xbfbf9a8c, > ebp = 0xbfbfb468 --- System didn't seem to crash, what does it mean? The OS is FreeBSD 5.4-RELEASE, it was compiled using: CPUTYPE?=i686 COPTFLAGS= -O -pipe -- Best regards, Derek mailto:[EMAIL PROTECTED] CCNA, SCSA, SCNA, LPIC, MCP certified http://www.takeda.tk The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. -- Edsgar W. Dijkstra ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: stack backtrace
Hello Sven, Tuesday, May 31, 2005, 2:29:36 PM, you wrote: > Apparently this is still somewhat of a mystery, but you are not the > first person to witness this: > http://lists.freebsd.org/pipermail/freebsd-stable/2005-April/013679.html > http://lists.freebsd.org/pipermail/freebsd-current/2004-July/031576.html > I don't know if anyone is actually looking into this (behind the scenes > maybe) or whether we just need to accumulate a critical mass of similar > notices to raise an eyebrow. If your system does not lock up as a result > (the way it used to in the earlier 5.x series) then perhaps it is > harmless .. Well, since system don't crash it appear to be harmless (unless some data is damaged in the process). I'm mostly interested what that message means, something apparently is wrong. I'm not expert but it looks to me from the functions that is something related to writing/reading data to/from disk I really hope it doesn't affect the data. -- Best regards, Derekmailto:[EMAIL PROTECTED] CCNA, SCSA, SCNA, LPIC, MCP certified http://www.takeda.tk Logic is a system whereby one may go wrong with confidence. -- Charles Kettering ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: stack backtrace
Hello Kris, Thursday, June 2, 2005, 12:37:41 AM, you wrote: > It looks like debugging code (it's been removed in -current). > Jeff: > in 1.141 of ffs_softdep.c you added a call to backtrace() if bp->b_vp > == NULL..you removed it in current in 1.166, but some people are > seeing it trigger on 5.x So it's harmless? As for debugging, I compiled kernel with: makeoptions DEBUG=-g options KDB options KDB_TRACE options DDB To have coredump, if system crashes (I didn't oticed any slowdown, so I guess it doesn't hurt) Are those last three options necessary to get core? Or is only DEBUG=-g needed? -- Best regards, Derekmailto:[EMAIL PROTECTED] CCNA, SCSA, SCNA, LPIC, MCP certified http://www.takeda.tk Trying to outsmart a compiler defeats much of the purpose of using one. -- Kernighan & Plauger, "The Elements of Programming Style" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: stack backtrace
Hello Kris, Thursday, June 2, 2005, 11:06:54 AM, you wrote: >> > in 1.141 of ffs_softdep.c you added a call to backtrace() if bp->b_vp >> > == NULL..you removed it in current in 1.166, but some people are >> > seeing it trigger on 5.x >> So it's harmless? > I don't know, but I presume the debugging code was added for debugging > reasons :-) Sorry, I didn't stated precise what I meant. Since this code was triggered it means something went wrong, the system didn't crash but I'm just wonder if something else could be damaged. For me it looks like the problem was somewhere in the disk writing code. -- Best regards, Derekmailto:[EMAIL PROTECTED] CCNA, SCSA, SCNA, LPIC, MCP certified http://www.takeda.tk -- Computers are not intelligent. They only think they are. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.0 BETA 1 post install issue
If this is the wrong group to discuss 6.0 installation problems, please refer me to the correct one. I installed 6.0 BETA 1 yesterday via NFS from my local server. The installation went with no reportable problems. However, when I got to the post install configuration menu, I could not get the console mouse to work. It didn't show a pointer, even after I set the protocol (auto) and the type (PS2). After rebooting, I configured rc.conf by hand and set the mouse related entries, rebooted and the mouse works fine. I'm not sure where to go from here. This was on an IBM G40 laptop, on which I have installed 5.2 through 5.4 without a problem configuring the mouse for the console. -- Derek Tattersall | (Insert witty remark here) | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.x, 6.x and CPUTYPE
Hello Joel, Sunday, November 6, 2005, 10:21:56 PM, you wrote: > Hi, > I've noticed that some CPU definitions have changed in /etc/make.conf > between 5 and 6. For good or for bad, I have up until now been building > 5.x for both p3 and p4 architectures with 'i686' but this particular > definition's removal from 6.x has given me cause to rethink my strategy. > I'd like to know: > Should I use 'i386' and build once for all, or use p3/p4 defs and build > once for each? And if the latter, why? (does this give any worthwhile > performance increase?) i386 will guarantee you that it should work on any PC, while p3/p4 will tell compiler to try using instructions available in pentium 3 or pentium 4. I don't have any performance stats to prove that, but in theory the code should be faster when you use p3 or p4 instead of i386. > If I don't specify a CPUTYPE at all, will this be auto-detected in some > way (which would probably not suit me) or will it fall back to i386? I'm afraid it will fall back to value that will produce code that can run on any PC (which is i386). Actually it won't provide any flag to gcc, but gcc will assume i386. > Is this a consistent requirement for world/kernel/ports? > Finally, when building on a single host, but where multiple requirements > are being met, is it possible to define different make.conf files for make > or is it easier to just edit this file before each build? As long as you defined the variable in this way e.g.: CPUTYPE?=i686 (the question mark is not a typo) This is actually recommended way to assign values like this one. You can pass this argument in make command e.g. make buildworld CPUTYPE=i686 make buildworld CPUTYPE=p4 etc. If you don't give argument, then whatever you have in /etc/make.conf will be assumed as a default value. -- Best regards, Derekmailto:[EMAIL PROTECTED] CCNA, SCSA, SCNA, LPIC, MCP certified http://www.takeda.tk Profanity is the language all programmers know best. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
"runtime went backwards" message in logs
I recently noticed strange message in the logs: | +++ /tmp/security.YBOfj4NZ Tue Dec 27 03:10:48 2005 | +calcru: runtime went backwards from 226760439 usec to 226756967 usec for pid 612 (sendmail) | +calcru: runtime went backwards from 226760439 usec to 226756967 usec for pid 612 (sendmail) | +calcru: runtime went backwards from 226820020 usec to 226816978 usec for pid 612 (sendmail) | +calcru: runtime went backwards from 226820020 usec to 226816978 usec for pid 612 (sendmail) What could be reason for it? Could this indicate possible break-in (it was in security log), or is more likely a hardware/software error? (I'm seeing this message for the first time.) The OS is FreeBSD 6.0 RELEASE (sendmail is the one provided with FreeBSD). PS. Not sure if this have anything to do with it (the message mentions CPU time, not the clock), but I'm running a ntp daemon, to synchronize time... -- Best regards, Derek mailto:[EMAIL PROTECTED] http://www.takeda.tk -- Smash forehead on keyboard to continue. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "runtime went backwards" message in logs
Hello Julian, Thursday, December 29, 2005, 4:39:55 PM, you wrote: > Highly likely it has a Lot to do with it :-) Maybe the master time > server had `date` run manually, or otherwise shifted, or came back > on net after an outage, & the systems noticed drifted time & corrected etc. > man ntpd > man ntp.conf > etc :-) I'm using I'm not using Stratum-1 servers (since I read that they shouldn't be used by individuals), but stratum-2 so they are lower quality, but I have few of them in the list, can just one of them affect my time that much? Here is my /etc/ntp.conf: driftfile /etc/ntp.drift # Los Angeles, CA server gandalf.theunixman.com #Los Angeles, CA server 66.92.40.210 #Los Angeles, CA server ntp2.sf-bay.org #Riverside, CA server hydrogen.cert.ucr.edu #Los Angeles, CA server clock.develooper.com Also I didn't saw any ntp messages in clock around that time. Perhaps you're right that NTP could be blamed for it, but it's little suspicious that it happen when sendmail was sending mail (I'm apologizing, that I forgot to mention that before): Dec 26 05:40:00 chinatsu /usr/sbin/cron[51606]: (root) CMD (/usr/libexec/atrun) Dec 26 05:40:38 chinatsu sendmail[51609]: jBQDeaOY051609: from=www, size=1056, class=0, nrcpts=1, msgid=<91133e67c96c54139e783 [EMAIL PROTECTED]>, [EMAIL PROTECTED] Dec 26 05:40:38 chinatsu kernel: calcru: runtime went backwards from 226760439 usec to 226756967 usec for pid 612 (sendmail) Dec 26 05:40:38 chinatsu oidentd[51611]: Connection from 127.0.0.1:61951 Dec 26 05:40:39 chinatsu kernel: calcru: runtime went backwards from 226760439 usec to 226756967 usec for pid 612 (sendmail) Dec 26 05:40:39 chinatsu oidentd[51611]: [127.0.0.1] Successful lookup: 56620 , 25 : www (www) Dec 26 05:40:39 chinatsu sm-mta[51610]: STARTTLS=server, [EMAIL PROTECTED] [127.0.0.1], version=TLSv1/SSLv3, verif y=NO, cipher=DHE-RSA-AES256-SHA, bits=256/256 Dec 26 05:40:39 chinatsu sendmail[51609]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA -AES256-SHA, bits=256/256 Dec 26 05:40:39 chinatsu sm-mta[51610]: jBQDedXn051610: from=<[EMAIL PROTECTED]>, size=1155, class=0, nrcpts=1, msgid=<91 [EMAIL PROTECTED]>, proto=ESMTP, daemon=IPv4, [EMAIL PROTECTED] [127.0.0.1] Dec 26 05:40:39 chinatsu sm-mta[51610]: jBQDedXn051610: Milter add: header: X-Virus-Scanned: ClamAV 0.87.1/1217/Sat Dec 24 06: 39:31 2005 on chinatsu.takeda.tk Dec 26 05:40:39 chinatsu clamav-milter[705]: jBQDedXn051610: clean message from <[EMAIL PROTECTED]> Dec 26 05:40:39 chinatsu sm-mta[51610]: jBQDedXn051610: Milter add: header: X-Virus-Status: Clean Dec 26 05:40:39 chinatsu sendmail[51609]: jBQDeaOY051609: [EMAIL PROTECTED], ctladdr=www (80/80), delay=00:00:03, xdela y=00:00:01, mailer=relay, pri=31056, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (jBQDedXn051610 Message accepted for delivery) -- Best regards, Derekmailto:[EMAIL PROTECTED] http://www.takeda.tk -- E Pluribus Modem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "runtime went backwards" message in logs
Hello Koen, Friday, December 30, 2005, 2:30:02 AM, you wrote: >>Highly likely it has a Lot to do with it :-) Maybe the master time >>server had `date` run manually, or otherwise shifted, or came back >>on net after an outage, & the systems noticed drifted time & corrected etc. >> man ntpd >> man ntp.conf >> etc :-) > AFAIK, under normal circumstances ntpd should never reset the current > time the hard way. Ntpd slows down (slews) or increases (steps) the > speed of your clock, such that it will catch up or fall behind enough to > become in line with the ntp servers it is listening to (since resetting > the time the hard way is usually not a good idea; think makefiles, > cronjobs that could run twice, etc..). You could check out the -x flag > to nptd, to prevent setting the clock the hard way all together (since > network congestion and stuff like that might result in ntpd setting the > clock the hard way). I would like thank you and Julian for your help, it made this more clearer to me. But besides ntp what are other possibilities for this error? When I was googling I saw that people received this message mostly on vmware, and in 5.x versions. Switching kern.timecounter.hardware to different value helped for them. Also it's suspicious that this happened just in time sendmail was asked to send mail. There aren't any ntp log messages around that time... Here is how mya kern.timecounter look like: [chinatsu]:/home/takeda> sysctl kern.timecounter kern.timecounter.stepwarnings: 0 kern.timecounter.nbinuptime: 1655158110 kern.timecounter.nnanouptime: 839637 kern.timecounter.nmicrouptime: 3091359 kern.timecounter.nbintime: 260308074 kern.timecounter.nnanotime: 60604863 kern.timecounter.nmicrotime: 197638763 kern.timecounter.ngetbinuptime: 26146849 kern.timecounter.ngetnanouptime: 45598642 kern.timecounter.ngetmicrouptime: 178378839 kern.timecounter.ngetbintime: 0 kern.timecounter.ngetnanotime: 306812 kern.timecounter.ngetmicrotime: 562893914 kern.timecounter.nsetclock: 4 kern.timecounter.hardware: ACPI-fast kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.tick: 1 Not sure how much helpful it is... Anyway, happy New Year to everyone on this list... -- Best regards, Derekmailto:[EMAIL PROTECTED] http://www.takeda.tk Weinberg's Second Law If builders built buildings the way programmers write programs, then the first woodpecker that came along would destroy civilization. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hi all.. Novice user having woes getting Atheros card up in FreeBSD 6.0
I think the newest D-link DWL-AG530 must use the AR5213 chipset too. Before I got it I had done some checking and read somewhere that it used the AR5212, so I thought I'd be ok. When I tried it recently I got: FreeBSD rock 6.0-STABLE FreeBSD 6.0-STABLE #1: Sun Jan 22 10:45:11 EST 2006 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ROCK i386 ... ath0: mem 0xea00-0xea00 irq 11 at device 17.0 on pci0 ath0: unable to collect channel list from hal; regdomain likely 18 country code 0 device_attach: ath0 attach returned 22 I haven't tried Sam's patches yet. I'm assuming they're still current though. I have instructions for getting the patches, applying the patches, and testing them. I'll send them to you via BSDForums (since that's where they're saved). Can you point me to these instructions as well please? Yes, I already looked. :) -derek ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Athlon and 4.2 Release
Drew Sanford <[EMAIL PROTECTED]> writes: > I strongly suspect its an IRQ conflict. Every problem of this sort > that I've seen with the A7V has been an IRQ conflict, including the > problem I had with my own. Specificly I had to hard set the IRQ on my > NIC through the PCI management section of the bios. > > Derek Tattersall wrote: > > > I have a 1 GHz Thunderbird (Athlon) on an ASUS A7V Via KT133 chipset > > with an IBM ultra 100 30 Gig Hard drive. If I let the HDD be auto > > detected, 4.2 Release terminates at the point it is going to > > partition the drive. If I set the HDD for LBA with all the options > > disabled, > > it reboots in the middle of the boot sequence, after the "press enter > > to boot now prompt". > > Has anybody got configuration suggestions for this combination that > > could get FreeBSD installed? > > Thanks in advance... > > > -- > Drew Sanford > Systems Administrator > [EMAIL PROTECTED] > It certainly is an IRQ conflict between the 3C905B NIC and the promise controller. I could install and reboot just fine with the NIC removed. I tried setting different IRQs for the NIC (in slot 3) but the BIOS always put the promise controller on the same IRQ. More research is required. I think I'll see if I can borrow a NIC from work, a totally different brand and see what happens. -- Derek Tattersall[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Please be nice to the newbie....
Hello all, I am new to FreeBSD, and I am about to embark on my first FreeBSD kernel compile. I am very familiar with the kernel build process in linux, but FreeBSD appears to be a very different animal in that respect. So, what I am asking, is there any advice that you would care to impart to this FreeBSD newbie (aside from RTFM, which I have done... FreeBSD's docs kick butt)? I appreciate it, Derek To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Please be nice to the newbie....
I read all of that :-) I read the whole kernel config section, the source sync section, and a bunch of other sections of the docs. Wery thorough and easy to follow. I have a lot of respect for the people responsible. Any advice at all is great. This includes, but is not limited to performance tips, recovery advice, sources of more information, and safety precautions to avoid needing to use the recovery advice. But now that you mention it, I think I will practice booting from a kernel other than /kernel, I'll practice on kernel.GENERIC. Thanks! Derek At 02:24 PM 7/21/2001, H wrote: >Derek C. wrote: > > > So, what I am asking, is there any advice that you would care to > > impart to this FreeBSD newbie (aside from RTFM, which I have done... > > FreeBSD's docs > >Just follow (yes, it is part of the FM :) >http://www.freebsd.org/handbook/kernelconfig-building.html > >Perhaps nice is to familiarize yourself with booting another kernel than >/kernel (during the kernel install the old /kernel will be renamed to >/kernel.old) so that in case of a failing new kernel you know how to >revert to the old one. > >Or did you want advice on what to modify/tune to the kernel config >itself ? > >Hans Lambermont >-- >http://lambermont.webhop.org/ > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
