Re: smb driver for Nvidia ION (intel ATOM) chipset
On Thu, Jan 07, 2010 at 08:48:05AM +0100, Oliver Lehmann wrote: > Re: smb driver for Nvidia ION (intel ATOM) chipset writes: > > >It's easy to get confused by the state of hardware monitoring on not > >only FreeBSD but other OSes as well; they all make it sound like > >monitoring things "just magically works with SMBus", and that isn't the > > This is what I was thinking so far - yeah exactly ;) > I'v now went deeper into mbmon's source and found that stuff out > sorta... > > Looks like I've to do some more research what really is on my board > first. > > Using the ISA-IO access method mbmon thinks I've a LM78 and mbmon > even works but I'm getting false numbers for probably just > everything... > > r...@nudel xmbmon205> mbmon > > Temp.= 185.0, 0.0, 0.0; Rot.= 835, 30681, 18750 > Vcore = 1.10, 1.81; Volt. = 3.39, 4.95, 8.21, -7.51, -3.24 > ^C This is the exact sort of situation I was referring to -- at this point your system may be unstable. The mbmon software has initiated a raw LPC (ISA) I/O request on a port which obviously is not tied to an LM78 H/W monitoring IC. Who knows what all of the writes and reads to those offsets just did. I would recommend you reboot and/or power cycle this box ASAP given the nature of what transpired. One has to be very careful when operating with /dev/io that the proper (LPC/ISA) ports are used. The same applies to most bus architectures (SMBus, PCI, etc.), though in the case of PCI, there's existing infrastructure to find out what's on the bus properly. There isn't such with SMBus and LPC/ISA. Now you see why I strongly discourage auto probing. :-) > r...@nudel xmbmon205> mbmon -d > SMBus[NVidia nForce2] found, but No HWM available on it!! > Using ISA-IO access method!! > * Nat.Semi.Con. Chip LM78 found. > r...@nudel xmbmon205> Yeah, this looks like a very bad assumption made by the software. You're very likely going to have to end up mailing the board manufacturer/vendor and asking them -- that is, assuming there's a H/W monitoring IC on the board at all. If you have access to Windows 2K/XP, you might try using some software there called SpeedFan. If it works, you'll be able to at least figure out what H/W monitoring IC is used, and if it's via SMBus or LPC/ISA. What registers, slave address, etc. it uses are a different matter altogether (I'm not sure the software discloses that). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: smb driver for Nvidia ION (intel ATOM) chipset
Re: smb driver for Nvidia ION (intel ATOM) chipset writes: I'll go and find some information about what HWM chip is tied on that board... regarding to http://ubuntuforums.org/showthread.php?t=1199797&page=4 It got an ITE 87 sensor... This is what Linux detects: Driver `it87': * ISA bus, address 0x290 Chip `ITE IT8720F Super IO Sensors' (confidence: 9) Driver `coretemp': * Chip `Intel Core family thermal sensor' (confidence: 9) So now I just need to find out why the it87 gets not choosen by mbmon... maybe the 8720 is just not supported right now - I'll probably have to take a look at Linux lm-sensors since it is working there... "Int.Tec.Exp. Chip IT8705F/IT8712F or SIS950" ___ 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: smb driver for Nvidia ION (intel ATOM) chipset
On Thu, Jan 07, 2010 at 09:09:13AM +0100, Oliver Lehmann wrote: > Re: smb driver for Nvidia ION (intel ATOM) chipset writes: > > >I'll go and find some information about what HWM chip is tied on > >that board... > > regarding to > > http://ubuntuforums.org/showthread.php?t=1199797&page=4 > > It got an ITE 87 sensor... This is what Linux detects: > > Driver `it87': > * ISA bus, address 0x290 >Chip `ITE IT8720F Super IO Sensors' (confidence: 9) I don't know if lmsensors on Linux supports SMBus or not, but it looks like (based on the above) that you should be able to communicate with the IT8720F chip using LPC/ISA on port 0x290. I'm pretty sure the ITE chips have their specifications and engineering datasheets publicly available. My guess is that mbmon lacks support for this specific IC, or has buggy support. For example, it may have "IT87 support", but maybe only for IT8705F and not for IT8720F; this is why vague classifications and lumping multiple devices under one hood is often a bad idea. > Driver `coretemp': > * Chip `Intel Core family thermal sensor' (confidence: 9) CPU core temperatures for that CPU family come directly from the CPU itself, and not usually through a H/W monitoring IC (though sometimes they can be routed through PECI; gotta love acronyms!). FreeBSD has the coretemp(4) driver for Intel CPUs and the amdtemp(4) driver for AMD CPUs; this should suffice for monitoring your CPU cores. Intel and AMD both started adding on-die thermal monitoring to their CPUs somewhat recently (past 3-4 years). > So now I just need to find out why the it87 gets not choosen by > mbmon... maybe the 8720 is just not supported right now - I'll > probably have to take a look at Linux lm-sensors since it is working > there... > > "Int.Tec.Exp. Chip IT8705F/IT8712F or SIS950" Good luck -- I've spent hours upon hours digging through lmsensors, and the code is quite possibly the worst bunch of spaghetti I've ever seen. I'd recommend going straight to the datasheets. If you'd like, I can code up something that uses LPC/ISA to communicate with this IC via port 0x290 based on the datasheet. It's pretty easy, but will require that the program be run as root (to open /dev/io). I won't integrate it into bsdhwmon because that software strictly uses SMBus. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD 6.3 EoL coming soon
Hi, Do you have any news about 8.1? :) Regards, Andras On Csü, Január 7, 2010 2:54 am, Daniel Gerzo wrote: > DĹ�a 7.1.2010 2:21, Oliver Pinter wrote / napĂsal(a): > >> and who is 7.3 ;) > > ah, good catch, of course I meant FreeBSD 7.3. Sorry for that. My mind > just got a little confused because of a little discussion on IRC. ;-) > > >>> There will be 7.4 release "quiet" soon (read in approx. 3 months from >>> now) which should meet your requirements. > > -- > S pozdravom / Best regards > Daniel Gerzo, FreeBSD committer > ___ > 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"
ssh+pam fails after 6.4 to 7.2 upgrade
Hi all, I've upgraded a FreeBSD box to 6.4 to 7.2; no problems here, all goes fine as usual. After the whole upgrade process I can't do ssh connections. Because of I use ssh through LDAP, it involves also the PAM modules. I've tried: - repeat the whole upgrade process because of I didn't know if the error comes from installworld step (it wil means than problem comes from the binaries itself) or from mergemaster step (it wil means that problem comes from config files). ->CONCLUSION: it happens after the installworld and before the mergemaster, so it's no a problem of config files. It's a binaries-problem related. - recompile the pam_ldap package to force the re-link of underlaying libraries. -> CONCLUSION: no effect. - disable the selective aknowledgement in TCP stack (using sysctl net.inet.tcp.sack.enable=0 and make it permament with echo "net.inet.tcp.sack.enable=0" >> /ect/sysctl.conf). -> CONCLUSION: no effect - using the ssh client with -o HostKeyAlgorithms=ssh-dss,ssh-rsa according to entry number 20080801 in UPDATING file in src tree. -> CONCLUSION: no effect - debug the client and server side: // client [jespa...@jespasac ~]$ ssh -vvv OpenSSH_5.2p1, OpenSSL 1.0.0-fips-beta4 10 Nov 2009 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to hc31.srv.cat [xxx.xxx.xxx.xxx] port 22. debug1: Connection established. debug1: identity file /home/jespasac/.ssh/identity type -1 debug3: Not a RSA1 key file /home/jespasac/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-END' debug3: key_read: missing keytype debug1: identity file /home/jespasac/.ssh/id_rsa type 1 debug1: identity file /home/jespasac/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 FreeBSD-20080901 debug1: match: OpenSSH_5.1p1 FreeBSD-20080901 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.2 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-
Re: broken oniguruma ports
On 01/06/10 22:25, Oliver Pinter wrote: hi list! $subject the ruby port was updated, but the oniguruma patch is available only for older ruby, end its patch hunked. ___ 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" Same here ... Regards, Oliver ___ 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: ssh+pam fails after 6.4 to 7.2 upgrade
You would probably need to reinstall the openldap-client package (and any packages openldap-client depends on) as well as the pam_ldap and nss-ldap packages. - $ portupgrade -fR openldap-client (-R flag implies the recompilation of openldap-client depenedent packages as well) CONCLUSION: no effect. I'm still thinking in PAM-related error. -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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: pkg_add thinks that -STABLE is -RELEASE (wrong __FreeBSD_version?)
On Sun, 3 Jan 2010, pluknet wrote: Hi, 2010/1/2 Paride Legovini : Hi, I'm running 8.0-STABLE and I noticed that by default pkg_add -r uses packages-8.0-release/Latest/ as PACKAGESITE. I read in the handbook[1] that pkg_add should use packages-5-stable/Latest/ as PACKAGESITE when one is running -STABLE. I took a look at the source code, and noticed that pkg_add considers the system -STABLE if getosreldate() (i.e. __FreeBSD_version) is between 800500 and 899000 (see src/usr.sbin/pkg_install/add/main.c:92). However, in RELENG_8, __FreeBSD_version is set to 800108. You can check it via cvsweb[2]. Sounds like something is wrong. Am I missing something? Do I just have to wait for the __FreeBSD_version to be bumped? Hi. I'm afraid that's because __FreeBSD_version wasn't bumped 800107->800500 in RELENG_8 just after RELENG_8_0 created (wrt changes in scheme for RELENG_8 timeframe where current/stable border moved to 800500: http://lists.freebsd.org/pipermail/svn-src-head/2009-June/007830.html It continued then as is (still ok), and eventually was incremented to 800108 (wrong here, though I hope it still can be safely corrected). I have just bumped the version on stable/8 so it should be fine now. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ 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"
State of igb on FreeBSD 8 stable?
I did some searching last night and found others using igb on Intel Cards having high interrupts and other strange issues and some comments to the effect that igb is soon going to have a lot of work done to it (I believe Jack Vogel is working on it). So, can someone give an estimation as to how soon that may be and how soon it may make it to 8-stable? If it's going to be a while I may look into adding a card using a different driver to test. My network device is: i...@pci0:8:0:0:class=0x02 card=0x10a715d9 chip=0x10a78086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82575EB Gigabit Network Connection' class = network subclass = ethernet Thanks, Alan ___ 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: smb driver for Nvidia ION (intel ATOM) chipset
Jeremy Chadwick wrote: > If you'd like, I can code up something that uses LPC/ISA to communicate > with this IC via port 0x290 based on the datasheet. I now was able to "hack up" mbmon to communicate with my it8720 sensor. I've attached the patch for sens_it87.c I also added to Makefile to the DEFS = line "-DIT8720" of course. This made mbmon working with ISA-IO mode working. I'm now getting the following outputs: Temp.= 32.0, 34.0, 22.0; Rot.= 4591, 1298,0 Vcore = 1.10, 1.81; Volt. = 3.39, 4.95, 11.93, -11.93, -4.99 I can nearly verify all values with the BIOS and they are matching. I XXed in the following output (same as above) all values out I was not able to verify because the BIOS-HWM does not show their values: Temp.= 32.0, XXX, XXX; Rot.= 4591, 1298,0 Vcore = 1.10, ; Volt. = 3.39, 4.95, 11.93, -11.93, X For the remaining values I'm pretty sure they are correct. I enabled the 16Bit RPM mode for the 8720. In this case no devisor is needed for calculating the RPM. I was not able to get the 2nd FAN-RPM right in the 8Bit mode. The 1st one was correct even in the 8Bit mode. About the voltage multipliers... I'm not sure about the last one because I'm not able to verify this (I could with a multimeter of course but this would create other deviations). I'm also not sure why the multipliers (for my board?) are different. I wonder why they are hardcoded there anyway. I can imagine that they are depending the board layout or am I mistaken? I mean the IT spec says only that the input of the pins need to be in the range between 0 and VCC. So I can choose whatever multiplier I like as long as the resulting voltage keeps within this range. Keeping the measured voltage somewhere in the middle of 0 and VCC with the multiplier for the expected value makes sense but this is no "must be" I guess Now - since ISA-IO is working I want to get smbus working too ;) First I patched src/sys/pci/nfsmb.c to detect the known remaning nforce SMB controllers including mine. I then added the device-id of this controller to the pci_pm.h file of mbmon to make it detect my controller. But now it still fails to find the it87 sensor on the bus. I guess the bus can have many "slaves" and mbmon just needs to test all to find out which identifies itself as it87? (reading from Adress 0x58 should return 0x90 - at least in ISA mode) r...@nudel xmbmon205> ./mbmon -S -D -p it87 Probe Request: it87 >>> Testing Reg's at SMBus <<< SMBus slave 0xA0(0x50) found... SMBus slave 0xA2(0x51) found... SMBus slave 0xA4(0x52) found... SMBus slave 0xA6(0x53) found... SMBus slave 0xA8(0x54) found... SMBus slave 0xAA(0x55) found... SMBus slave 0xAC(0x56) found... SMBus slave 0xAE(0x57) found... SMBus[NVidia nForce2] found, but No HWM available on it!! InitMBInfo: Device not configured Exit 1 r...@nudel xmbmon205> ./mbmon -S -s1 -D -p it87 Probe Request: it87 >>> Testing Reg's at SMBus <<< SMBus slave 0xA0(0x50) found... SMBus slave 0xA2(0x51) found... SMBus slave 0xE0(0x70) found... SMBus[NVidia nForce2] found, but No HWM available on it!! InitMBInfo: Device not configured Exit 1 r...@nudel xmbmon205> But it looks like at least the smb detection code for it87 is not working for mine... Any ideas how to proceed here? (I have basic C skills and know something about electronics (can build a Z80 SBC for example ;)) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ --- sens_it87.c.orig 2010-01-07 19:34:04.0 +0100 +++ sens_it87.c 2010-01-07 19:15:11.647304000 +0100 @@ -0,0 +1,242 @@ +/* + * Integrated Technology Express IT8705F/IT8712F hardware monitor chip + * + *** + * Before calling these routines, one must call method->Open() * + * After calling these routines, one must call method->Close() * + *** + * + +Integrated Technology Express + Chip TempVoltFan SMBus IOport +it8705 3 8 3 yes yes +it8712 3 8 3 yes yes + +SiS + Chip TempVoltFan SMBus IOport +sis950 3 8 3 yes yes + + * + * by YRS + */ + + +#include +#include "sensors.h" + +/* external (global) data */ +extern int smb_slave; +extern LM_METHODS method_isa, method_smb; +extern int numSMBSlave, canSMBSlave[128]; + + +#define IT87_ADDR_START 0x50 /*0x50-0x5E*/ +#define IT87_ADDR_END 0x5E + +#define IT87_SMBADDR 0x48 +#define IT87_REGCHIP 0x58 +#define IT87_CHIPID 0x90 + +/* temp nr=0,1,2; volt nr=0,1,...6; fan nr=0,1,2 */ +#define IT87_TEMP(nr) (0x29 + (nr)) +#define IT87_VOLT(nr) (0x20 + (nr)) +#define IT87_FAN(nr) (0x0D + (nr)) +#define IT87_FANX(nr) (0x18 + (nr)) +#define IT87_FANDIV 0x0B +#define IT87_FANDIV16 0x0C + +static int it87_probe(LM_METHODS *); +static float it87_temp(LM_METHODS *, int); +static int it87_fanrpm(LM_METHODS *, int);
Re: smb driver for Nvidia ION (intel ATOM) chipset
Oliver Lehmann wrote:
> I've attached the patch for sens_it87.c
Which was broken I attached the correct one.
--
Oliver Lehmann
http://www.pofo.de/
http://wishlist.ans-netz.de/
--- sens_it87.c.orig 2003-10-13 09:11:20.0 +0200
+++ sens_it87.c 2010-01-07 19:55:47.0 +0100
@@ -41,7 +41,9 @@
#define IT87_TEMP(nr) (0x29 + (nr))
#define IT87_VOLT(nr) (0x20 + (nr))
#define IT87_FAN(nr) (0x0D + (nr))
+#define IT87_FANX(nr) (0x18 + (nr))
#define IT87_FANDIV 0x0B
+#define IT87_FANDIV16 0x0C
static int it87_probe(LM_METHODS *);
static float it87_temp(LM_METHODS *, int);
@@ -151,13 +153,26 @@
fac = 0.016 * 1.68;
break;
case 4:
+#ifdef IT8720
+ fac = 0.016 * 5.524;
+#else
fac = 0.016 * 3.80;
+#endif
break;
case 5:
+#ifdef IT8720
+ fac = - 0.016 * 5.524;
+#else
fac = - 0.016 * 3.477;
+#endif
break;
case 6:
+#ifdef IT8720
+ fac = - 0.016 * 2.31;
+#else
fac = - 0.016 * 1.505;
+#endif
+
}
return (float) method->Read(IT87_VOLT(no)) * fac;
@@ -191,6 +206,7 @@
if (no < 0 || 2 < no)
return 0x;
+#ifndef IT8720
n = method->Read(IT87_FANDIV);
div[0] = n & 0x07;
div[1] = (n >> 3) & 0x07;
@@ -210,6 +226,17 @@
} else if (r == 0) {
return 0x;
}
+#else
+ div[no] = 1;
+ method->Write(0x0C,1|0x07);
+ n = method->Read(IT87_FANDIV16);
+ if(n & 0x07) {
+ r = method->Read(IT87_FAN(no));
+ r |= method->Read(IT87_FANX(no))<<8;
+ }
+ if(r == 0 || r == 0x)
+ return 0x;
+#endif
return 135 / (r * (1 << div[no]));
}
___
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: State of igb on FreeBSD 8 stable?
On Thu, Jan 07, 2010 at 09:46:14AM -0800, alan bryan wrote: > I did some searching last night and found others using igb on Intel Cards > having high interrupts and other strange issues and some comments to the > effect that igb is soon going to have a lot of work done to it (I believe > Jack Vogel is working on it). So, can someone give an estimation as to how > soon that may be and how soon it may make it to 8-stable? If it's going to > be a while I may look into adding a card using a different driver to test. > igb(4) in HEAD would be more stable but I haven't had time to experiment it. Last time I tried previous igb(4) driver which was shipped with 8.0-RELEASE showed several issues under high network loads as you might know. I have a patch which could be applied to 8.0-RELEASE or stable/8. http://people.freebsd.org/~yongari/igb/igb.buf.patch6 The patch would fix unresponsive system under high network load as well as reducing number of interrupts. The patch also contains bus_dma(9) and watchdog timeout fix. > My network device is: > > i...@pci0:8:0:0: class=0x02 card=0x10a715d9 chip=0x10a78086 rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82575EB Gigabit Network Connection' > class = network > subclass = ethernet > > > Thanks, > Alan ___ 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: State of igb on FreeBSD 8 stable?
At 03:19 PM 1/7/2010, Pyun YongHyeon wrote: On Thu, Jan 07, 2010 at 09:46:14AM -0800, alan bryan wrote: > I did some searching last night and found others using igb on Intel Cards having high interrupts and other strange issues and some comments to the effect that igb is soon going to have a lot of work done to it (I believe Jack Vogel is working on it). So, can someone give an estimation as to how soon that may be and how soon it may make it to 8-stable? If it's going to be a while I may look into adding a card using a different driver to test. > http://people.freebsd.org/~yongari/igb/igb.buf.patch6 The patch would fix unresponsive system under high network load as well as reducing number of interrupts. The patch also contains bus_dma(9) and watchdog timeout fix. FYI, with the above patch, the driver is quite stable for me on a box I use in my lab. ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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"
8.0 changes behavior of "who am i"
An observation... pre-8.0, "who am i" always returned the owner of the
terminal device, regardless what you might have done with with "su".
With 8.0, it returns the id of the user you've changed to. Example:
### 7.1 system
[cow...@jakob ~]$ who am i
cowens ttyp0Jan 6 07:31 (169.254.222.1)
[cow...@jakob ~]$ su
Password:
[r...@jakob /home/cowens]# who am i
cowens ttyp0Jan 6 07:31 (169.254.222.1)
### 8.0 system
[cow...@newercastle ~]$ who am i
cowens 0Jan 7 17:47
[cow...@newercastle ~]$ su
[r...@newercastle /home/cowens]# who am i
root 0Jan 7 17:47
The alternative syntax ("who -m") gives same result. The who(1) man
page still states that both forms are supposed to give info about the
"terminal attached to standard input," which, if I look with "w", it
looks as I'd expect:
[r...@newercastle /home/cowens]# w
5:47PM up 1 day, 1 min, 2 users, load averages: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE WHAT
root v0 -17Dec09 21days -bash (bash)
cowens pts/0169.254.222.1 5:47PM - w
Am I missing something, or do we have a bug here? (I looked but can't
find any existing threads about this issue). I'm guessing that the
symptom here results somehow from the introduction of pts(4).
Tnx
--
Charles Owens
Great Bay Software, Inc.
___
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 Security Advisory FreeBSD-SA-10:01.bind
Thomas Rasmussen wrote: > Hello, > > While this is all true, this vulnerability is for caching servers, > not authorative ones. It is pretty easy to setup DLV validation on a > recursive bind server. However, it is not enabled by default on FreeBSD, > so Stephen should be safe. FWIW, I agree with Thomas. -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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 Security Advisory FreeBSD-SA-10:01.bind
> Date: Thu, 07 Jan 2010 15:16:43 -0800 > From: Doug Barton > Sender: owner-freebsd-sta...@freebsd.org > > Thomas Rasmussen wrote: > > Hello, > > > > While this is all true, this vulnerability is for caching servers, > > not authorative ones. It is pretty easy to setup DLV validation on a > > recursive bind server. However, it is not enabled by default on FreeBSD, > > so Stephen should be safe. > > FWIW, I agree with Thomas. As do I. Guess I've been putting so much effort into getting my zones signed that DNSSEC took me in the wrong direction. No, a default config won't make you vulnerable, but making yourself vulnerable is not heard at all, especially if you use the DLV. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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"
