cannot listen fatm0 with tcpdump
Hi, I need to listen up the fatm0 interface but could not do that. Is there any reason for that? Thanks in advance. Husnu Demir. --- Error Message: # tcpdump -i fatm0 tcpdump: BIOCSETIF: fatm0: Device not configured And settings; # ATM settings device atm options NATM # uname -a FreeBSD nrouter 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Mon Mar 13 14:56:09 EET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NOTDEFAULT i386 # ifconfig fatm0 xx.yy.zz.130 netmask 255.255.255.252 up # atmconfig natm add xx.yy.zz.129 fatm0 0 148 llc/snap ubr And syslog message for the card; Jul 6 09:57:58 nrouter fatm0: FORE PCA200E mem 0xf700-0xf71f irq 21 at device 0.0 on pci5 Jul 6 09:57:58 nrouter fatm0: [GIANT-LOCKED] Jul 6 09:57:58 nrouter fatm0: ESI=00:20:48:04:f8:83 serial=63619 hw=0x20001 sw=0x4010c ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.5-stable network interface rl0 stops working
Hi Roland, On (060705), Roland Smith wrote: couple of weeks - the network interface rl0 (which is the main interface on the maschine, rl1 is for backups/internal use only) stops Are they physically on the motherboard? Or on PCI cards? In the latter case try reseating the card in the slot. fortunately they are PCI cards, so I'll check the seating. Try switching rl0 and rl1, and see if te problem persists. Also, swapping out the ethernet cable is worth trying. Switching/exchanging the cards was an option we haven't tried yet although it came to my mind earlier - for sure the strangest problems are hardware related so I'll give this a try and report back. Swapping out the ethernet cable was one of the first things I checked but to no avail. But I'm not really sure if the switch isn't part of the problem (although all other ports function correctly) so I'll change the switch port to. Another thing to check is if rl0 is sharing an interrupt with another device. That can cause problems. No there is no interupt sharing for this device but thanks for this hint, I hadn't checked it yet. When rl0 stops working ipfw loggs lots of denied packets so that it seems that the dynamic (keep-state) rules don't work any longer. We Does the problem persist without ipfw? I've got an rl0 card on my workstation (6.1-STABLE, amd64, using PF without problems) Unfortunately I can't check this because we use ipfw to generate traffic statistics for the jails. But when the interface stops working it has no impact to disable the firewall, short of that no log messages are generated any longer. After the stop on the interface occurs there is no other way to get the interface up and running again than rebooting the whole machine. Restarting /etc/rc.d/netif, the jails or ipfw doesn't help anything. What does ifconfig say after the interface stops working? When the interface stops working ifconfig seems to think everything is still ok. There is no hint in the output of ifconfig that the interface is not working and ifconfig down/up doesn't help any. Anything in the logs, except the denied packets? No strange enough there is no other hint in the logs that the system is not working. At first I thought it was kind of an ipfw problem because packets seem to arrive on the host but the responses get blocked by ipfw. I'll check with tcpdump the next time it happens if it's true that packets still arrive on the system. On the other hand if ipfw is part of the problem (especially the dynamic rules) then flushing ipfw should help I think - but it doesn't. So maybe it's an hardware issue, I'll definitly check this and report back. Thanks for the hints and tips! Best regards, Hank pgptYmaa0xylf.pgp Description: PGP signature
Re: pkg_version confused by architecutre in package name
Brooks Davis wrote: On Thu, Jul 06, 2006 at 02:45:45AM +0200, [LoN]Kamikaze wrote: I normally run the command # pkg_version -Iv | grep \ before running 'portupgrade -a', to see what's going to happen. This time I got the following output: diablo-jdk-freebsd6.i386.1.5.0.07.00 needs updating (index has 1.5.0.07.00) It seems that the tool is confused by the i386 in the package name. Actually I think it's confused by the fact that the package name is diablo-jdk and the version is freebsd6.i386.1.5.0.07.00. That's just plain bogus. -- Brooks So who is at fault? The ports infrastructure or the FreeBSD foundation? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 0.0% user, 0.0% nice, 0.0% system, 53.8% interrupt, 46.2% idle - Unusual interrupt use?
On Thu, 6 Jul 2006, Max Laier wrote: On Thursday 06 July 2006 02:02, Vye Wilson wrote: I'm really not sure how to go about troubleshooting this issue. Can someone point me in the right direction? vmstat -i should give a good idea what is causing the interrupt load. I also highly recommend top -S, which causes top to show system threads, such as interrupt threads and network threads, as a way to look at CPU use. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem restarting gvinum raid-5
Hi, We have a gvinum raid-5 volume that that we had to replace a disk on and after that we cant get the new subdisk starting. Here are the things we did: 1: Replace disk and boot singleuser to fdisk and lable new disk: gvinum - list 5 drives: D disk4 State: up /dev/da5s1a A: 0/17492 MB (0%) D disk3 State: up /dev/da4s1a A: 0/17492 MB (0%) D disk2 State: up /dev/da3s1a A: 0/17492 MB (0%) D disk1 State: up /dev/da2s1a A: 0/17492 MB (0%) 1 volume: V imap State: up Plexes: 1 Size: 68 GB 1 plex: P imap.p0R5 State: up Subdisks: 5 Size: 68 GB 5 subdisks: S imap.p0.s0State: up D: disk1Size: 17 GB S imap.p0.s1State: up D: disk2Size: 17 GB S imap.p0.s2State: up D: disk3Size: 17 GB S imap.p0.s3State: up D: disk4Size: 17 GB S imap.p0.s4State: up D: disk5Size: 17 GB After fixing the new disk partition we did a saveconfig and reboot: gvinum - list 5 drives: D disk5 State: up /dev/da6s1a A: 0/17492 MB (0%) D disk4 State: up /dev/da5s1a A: 0/17492 MB (0%) D disk3 State: up /dev/da4s1a A: 0/17492 MB (0%) D disk2 State: up /dev/da3s1a A: 0/17492 MB (0%) D disk1 State: up /dev/da2s1a A: 0/17492 MB (0%) 1 volume: V imap State: up Plexes: 1 Size: 68 GB 1 plex: P imap.p0R5 State: up Subdisks: 5 Size: 68 GB 5 subdisks: S imap.p0.s4State: staleD: disk5Size: 17 GB S imap.p0.s3State: up D: disk4Size: 17 GB S imap.p0.s2State: up D: disk3Size: 17 GB S imap.p0.s1State: up D: disk2Size: 17 GB S imap.p0.s0State: up D: disk1Size: 17 GB Tried start on plex and subdisk, nnot working. Finally, to get plex into degraded mode we did a setstate down imap.p0.s4. gvinum - list 5 drives: D disk5 State: up /dev/da6s1a A: 0/17492 MB (0%) D disk4 State: up /dev/da5s1a A: 0/17492 MB (0%) D disk3 State: up /dev/da4s1a A: 0/17492 MB (0%) D disk2 State: up /dev/da3s1a A: 0/17492 MB (0%) D disk1 State: up /dev/da2s1a A: 0/17492 MB (0%) 1 volume: V imap State: up Plexes: 1 Size: 68 GB 1 plex: P imap.p0R5 State: degraded Subdisks: 5 Size: 68 GB 5 subdisks: S imap.p0.s4State: down D: disk5Size: 17 GB S imap.p0.s3State: up D: disk4Size: 17 GB S imap.p0.s2State: up D: disk3Size: 17 GB S imap.p0.s1State: up D: disk2Size: 17 GB S imap.p0.s0State: up D: disk1Size: 17 GB and here we are. Start on volume or plex give errno 16, start on subdisk gives can't start: cannot start 'imap.p0.s4' - not yet supported. Can't find any descriptions of the proper way to do disk replacement, so if this is wrong, I'd love to get updated. And how do we get the current situation upa nd running? Regards, Göran ... the future isMobile Goran Lowkrantz [EMAIL PROTECTED] System Architect, isMobile, Aurorum 2, S-977 75 Luleå, Sweden Phone: +46(0)920-75559 Mobile: +46(0)70-587 87 82 Fax: +46(0)70-615 87 82 http://www.ismobile.com ... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
graid3 rebuild panic: mb_dtor_pack: ext_size != MCLBYTES
Hi, I get the below panic when rebuilding a graid3 array. Is this indicative of a hardware or software problem? Or is some of the data on my array corrupt and I should just rebuild the array? I searched on google and didn't find much. panic: mb_dtor_pack: ext_size != MCLBYTES Thanks for your time, Brad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS Locking Issue
On Wed, 05 Jul 2006 02:49:26 +0200, Scott Long [EMAIL PROTECTED] wrote: Michel Talon wrote: BTW, I noticed yesterday that that IPv6 support committ to rpc.lockd was never backed out. An immediate question for people experiencing new rpc.lockd problems with 6.x should be whether or not backing out that change helps. So it may be relevant to say that i have kernels without IPV6 support. Recall that i have absolutely no problem with the client in FreeBSD-6.1. Tomorrow i will test one of the 6.1 machines as a NFS server and the other as a client, and will make you know if i see something. As to the problems you mention about NFS Linux, yes i have seen a lot since years. But to my surprise FC5 seems to work well. By the way it is kernel 2.6.16 so sufficiently recent for the problems to have been ironed out, presumably. 2.6.16 should be OK. I've heard of problems with cookie and handle sizes with it, but only under highly unusual circumstances. Scott Just for the record. I'm running a 6.1-STABLE client with a Debian 3.1 server with kernel 2.6.12 and that works ok with nfs locking. Locking didn't work in the past (6.0-STABLE). Ronald. -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Dell PowerEdge 750 850 environtmental monitoring
Does anybody have temperature and fan monitoring working on Dell PowerEdge 750's 850's? I have done my share of googling without much luck. -- Arnold Cavazos, Jr. abcjr at abcjr . net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
carp+pfsync+freevrrpd+jail
Dear all. I have the following trouble: Using carp and pfsync i have made the redundand firewall (OS is 6.1p2 and everything is done like in mans, even ifconfig options) The only thing that is different that i have 2 ethernet interface (one for crosover link and the other is the paren interface for vlans) host1 ifconfig_vlan101=inet X.Y.Z.1 netmask 255.255.255.0 broadcast X.Y.Z.255 vlan 101 vlandev em0 ifconfig_carp0=vhid 1 pass abc X.Y.Z.3 ifconfig_vlan100=inet A.B.C.1 netmask 255.255.255.0 broadcast A.B.C.255 vlan 100 vlandev em0 ifconfig_carp1=vhid 1 pass abc A.B.C.3 ifconfig_pfsync0=up syncif em1 host2 ifconfig_vlan101=inet X.Y.Z.2 netmask 255.255.255.0 broadcast X.Y.Z.255 vlan 101 vlandev em0 ifconfig_carp0=vhid 1 advskew 100 pass abc X.Y.Z.3 ifconfig_vlan100=inet A.B.C.2 netmask 255.255.255.0 broadcast A.B.C.255 vlan 100 vlandev em0 ifconfig_carp0=vhid 1 advskew 100 pass abc A.B.C.3 ifconfig_pfsync0=up syncif em1 What i have is that when i'm pinging carp0 (inet) or carp1(lan) interface's ip address of my firewall - i'm receivind DUP responses. And when host2 is ths slave and i'm starting to ping carp0 address - no traffic appears on master host - that means that the local carp interface responding to my packets.. That means that in case some service (provided by jail managed by freevrrpd) will be accessed from outside - i cannot be sure what host will answer the request. I have done some tests. When i'm sshing to virtual IP - sometimes i'm getting ssh prompt and can login, and sometimes it says that host auth info is bad (yes, because second server answering me at this time) and sometimes i'm loosing ssh connection while session is active. net.inet.carp.preempt = 1 net.inet.carp.log=2 net.inet.carp.arpbalance=0 No ballance needed. I want to have some service run in main OS, some services run in jail and i want to be sure which host will answer the request when bouth hosts are up and running. Could please someone direct me what to do or where to read? Best regards, Anton Nikiforov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
Pyun YongHyeon said the following on 7/5/06 7:14 PM:
Here is patch generated against RELENG_6.
OK, I just tested that, but it doesn't seem to make any difference.
Here's what I did:
I commented out the em device from my kernel (a 6-STABLE one from
yesterday) and compiled three if_em kernel modules:
- one taken from 6.1 release
- the unpatched 6-STABLE one
- the latter with the above patch applied
So I was able to load and test each of these modules independently and
without actually restarting the machine. I changed also the driver
version string in if_em.c, just to ensure that I'm really loading the
right em module by checking dmesg:
em1: Intel(R) PRO/1000 Network Connection Version - 3.2.18 (patched)
port 0xdc80-0xdcbf mem 0xfcfe-0xfcff irq 55 at device 4.1 on pci3
em1: Ethernet address: 00:04:23:b5:1b:ff
em1: link state changed to UP
I used 2 machines - one running 6.1-RELEASE and using fxp (I'll call it
FXP), and the test one running 6-STABLE with em (I'll call it EM),
and tried exchanging/moving an IP alias between them.
FXP# ifconfig
fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=bRXCSUM,TXCSUM,VLAN_MTU
inet 10.10.64.30 netmask 0xff00 broadcast 10.10.64.255
ether 00:e0:81:31:f4:1e
media: Ethernet autoselect (100baseTX full-duplex)
status: active
EM# ifconfig
em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=bRXCSUM,TXCSUM,VLAN_MTU
inet 10.10.64.63 netmask 0xff00 broadcast 10.10.64.255
ether 00:04:23:b5:1b:ff
media: Ethernet autoselect (100baseTX full-duplex)
status: active
First I brought up an IP alias on the FXP machine:
FXP# ifconfig fxp0 inet alias 10.10.64.40 netmask 255.255.255.255
and checked whether it's accessible from anywhere - yes. Then I moved
that to EM:
FXP# ifconfig fxp0 inet -alias 10.10.64.40
EM# ifconfig em1 inet alias 10.10.64.40 netmask 255.255.255.255
and checked again - no. It was accessible only from its own subnet
(10.10.64.x), but not from anywhere else.
Moving that back to FXP works, but moving it back to EM doesn't. The
only way I found to make it accessible was to arping something from the
aliased IP address:
EM# arping -S10.10.64.40 -c1 somehost
So it seems that when an IP alias has been recently used on some other
machine (on FXP in my case), the em driver is unable to initialize that
IP alias properly.
It might be that the fxp driver is not sending something when releasing
an alias, who knows. But fact is that fxp always initializes its aliases
properly - I use it extensively and it always worked.
I tried setting another IP alias that never has been used on these
machines. I brought that up first on EM and it worked. The moved it to
FXP and it also worked! But moving it back to EM made it inaccessible.
It looks like there's something fishy with the alias initialization.
Another related problem is that the card gets re-initialized (reset?) on
each alias you add (takes between 0.3 and 1 seconds, depending how fast
the hardware is), which for mass aliased systems could be a serious
hurdle after a crash or reboot.
Regards,
Atanas
--- if_em.c.origFri May 19 09:19:57 2006
+++ if_em.c Thu Jul 6 11:10:56 2006
@@ -657,8 +657,9 @@
mtx_assert(adapter-mtx, MA_OWNED);
-if (!adapter-link_active)
-return;
+ if ((ifp-if_drv_flags (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=
+ IFF_DRV_RUNNING)
+ return;
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
@@ -719,11 +720,6 @@
if (adapter-in_detach) return(error);
switch (command) {
- case SIOCSIFADDR:
- case SIOCGIFADDR:
- IOCTL_DEBUGOUT(ioctl rcv'd: SIOCxIFADDR (Get/Set Interface
Addr));
- ether_ioctl(ifp, command, data);
- break;
case SIOCSIFMTU:
{
int max_frame_size;
@@ -760,16 +756,17 @@
IOCTL_DEBUGOUT(ioctl rcv'd: SIOCSIFFLAGS (Set Interface
Flags));
EM_LOCK(adapter);
if (ifp-if_flags IFF_UP) {
- if (!(ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_flags ^ adapter-if_flags)
+ IFF_PROMISC) {
+ em_disable_promisc(adapter);
+ em_set_promisc(adapter);
+ }
+ } else
em_init_locked(adapter);
- }
-
- em_disable_promisc(adapter);
- em_set_promisc(adapter);
} else {
- if (ifp-if_drv_flags IFF_DRV_RUNNING) {
+ if
Re: Dell PowerEdge 750 850 environtmental monitoring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arnold Cavazos Jr. wrote: | Does anybody have temperature and fan monitoring working on Dell | PowerEdge 750's 850's? I have done my share of googling without much | luck. | Which monitoring tools have you tried, sysutils/mbmon? What sort of monitor hardware is it? - -- Michael Butler, CISSP Information Security Architect, Protected Networks http://www.protected-networks.net PGP Key ID: BFCB1D4E Key fingerprint: 8E29 5BD0 06F4 4ABB E819 67D3 45A0 6F77 BFCB 1D4E -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (MingW32) iD8DBQFErXIwRaBvd7/LHU4RAjkTAJ9kFUO1SLfsX3XAL+/8TxlKwLShsgCdHwi2 VDyjK2cWSLRhAgzYi81Av/w= =nFul -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PowerEdge 750 850 environtmental monitoring
Does anybody have temperature and fan monitoring working on Dell PowerEdge 750's 850's? I have done my share of googling without much luck. With the DRAC III/XT card installed, I am monitoring PE750's using the IPMI device (device ipmi in the kernel config of 6.1-STABLE) and the ipmitool port. You can view the results at: http://www.tmk.com/cgi-bin/ipmi.cgi Terry Kennedy http://www.tmk.com [EMAIL PROTECTED] New York, NY USA ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Thu, Jul 06, 2006 at 01:29:11PM -0700, Atanas wrote: Pyun YongHyeon said the following on 7/5/06 7:14 PM: Here is patch generated against RELENG_6. OK, I just tested that, but it doesn't seem to make any difference. Here's what I did: I commented out the em device from my kernel (a 6-STABLE one from yesterday) and compiled three if_em kernel modules: - one taken from 6.1 release - the unpatched 6-STABLE one - the latter with the above patch applied So I was able to load and test each of these modules independently and without actually restarting the machine. I changed also the driver version string in if_em.c, just to ensure that I'm really loading the right em module by checking dmesg: em1: Intel(R) PRO/1000 Network Connection Version - 3.2.18 (patched) port 0xdc80-0xdcbf mem 0xfcfe-0xfcff irq 55 at device 4.1 on pci3 em1: Ethernet address: 00:04:23:b5:1b:ff em1: link state changed to UP I used 2 machines - one running 6.1-RELEASE and using fxp (I'll call it FXP), and the test one running 6-STABLE with em (I'll call it EM), and tried exchanging/moving an IP alias between them. FXP# ifconfig fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 10.10.64.30 netmask 0xff00 broadcast 10.10.64.255 ether 00:e0:81:31:f4:1e media: Ethernet autoselect (100baseTX full-duplex) status: active EM# ifconfig em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 10.10.64.63 netmask 0xff00 broadcast 10.10.64.255 ether 00:04:23:b5:1b:ff media: Ethernet autoselect (100baseTX full-duplex) status: active First I brought up an IP alias on the FXP machine: FXP# ifconfig fxp0 inet alias 10.10.64.40 netmask 255.255.255.255 and checked whether it's accessible from anywhere - yes. Then I moved that to EM: FXP# ifconfig fxp0 inet -alias 10.10.64.40 EM# ifconfig em1 inet alias 10.10.64.40 netmask 255.255.255.255 and checked again - no. It was accessible only from its own subnet (10.10.64.x), but not from anywhere else. Moving that back to FXP works, but moving it back to EM doesn't. The only way I found to make it accessible was to arping something from the aliased IP address: EM# arping -S10.10.64.40 -c1 somehost So it seems that when an IP alias has been recently used on some other machine (on FXP in my case), the em driver is unable to initialize that IP alias properly. It might be that the fxp driver is not sending something when releasing an alias, who knows. But fact is that fxp always initializes its aliases properly - I use it extensively and it always worked. I tried setting another IP alias that never has been used on these machines. I brought that up first on EM and it worked. The moved it to FXP and it also worked! But moving it back to EM made it inaccessible. Hmm, that's strange. I've double checked that stock em(4) didn't generate ARP packets when its addresses were changed. So I made em(4) generate ARP. Could you see a gratuitous ARP with tcpdump when you change its address? It looks like there's something fishy with the alias initialization. Another related problem is that the card gets re-initialized (reset?) on each alias you add (takes between 0.3 and 1 seconds, depending how fast the hardware is), which for mass aliased systems could be a serious hurdle after a crash or reboot. This is other issue. em(4) performs two time-consuming operations in its initialization routine. One is DMA tag/map creation and the other is checksumming EEPROM contents in init routine. I have an experimental patch for it but let's fix one at a time. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkg_version confused by architecutre in package name
On Thu, Jul 06, 2006 at 06:04:37PM +0200, [LoN]Kamikaze wrote: Brooks Davis wrote: On Thu, Jul 06, 2006 at 11:01:43AM +0200, [LoN]Kamikaze wrote: Brooks Davis wrote: On Thu, Jul 06, 2006 at 02:45:45AM +0200, [LoN]Kamikaze wrote: I normally run the command # pkg_version -Iv | grep \ before running 'portupgrade -a', to see what's going to happen. This time I got the following output: diablo-jdk-freebsd6.i386.1.5.0.07.00 needs updating (index has 1.5.0.07.00) It seems that the tool is confused by the i386 in the package name. Actually I think it's confused by the fact that the package name is diablo-jdk and the version is freebsd6.i386.1.5.0.07.00. That's just plain bogus. So who is at fault? The ports infrastructure or the FreeBSD foundation? I don't know. How did you install it? # pkg_add diablo-jdk-freebsd6.i386.1.5.0.07.00.tbz It definitly installs correctly if you use the port instead of the package. It looks like the package is incorrect. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpTC8REfeBKs.pgp Description: PGP signature
Re: Still getting 'calcru: runtime went backwards'
I'm getting a ton of them now, and i found a way to reproduce them. Basically i run a compile session in one terminal, say make buildkernel, and run top in another. As soon as i run top, the messages appear, and they seem to be synchronized with the refresh rate of top, 2 messages per refresh. This is on a 6.1-STABLE as of today. --- calcru: negative runtime of -261273 usec for pid 12 (swi4: clock) calcru: negative runtime of -261273 usec for pid 12 (swi4: clock) calcru: negative runtime of -259691 usec for pid 12 (swi4: clock) ... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
Pyun YongHyeon said the following on 7/6/06 6:03 PM: Hmm, that's strange. I've double checked that stock em(4) didn't generate ARP packets when its addresses were changed. So I made em(4) generate ARP. Could you see a gratuitous ARP with tcpdump when you change its address? I just left a tcpdump -n arp host 10.10.64.40 on a third machine sniffing around and tested all em module versions I had (the stock 6.1, 6-STABLE and 6-STABLE with your patch), but got silence on all three: EM# ifconfig em1 inet alias 10.10.64.40 nothing EM# ifconfig em1 inet -alias 10.10.64.40 nothing The fxp driver appears to send something on startup and nothing on shutdown: FXP# ifconfig fxp0 inet alias 10.10.64.40 18:41:54.584059 arp who-has 10.10.64.40 tell 10.10.64.40 FXP# ifconfig fxp0 inet -alias 10.10.64.40 nothing When I manually arping the em alias after startup (i.e. simulate what fxp does), everything works as expected: EM# ifconfig em1 inet alias 10.10.64.40 nothing EM# arping -c1 -S10.10.64.40 10.10.64.40 18:46:07.808701 arp who-has 10.10.64.40 tell 10.10.64.40 EM# ifconfig em1 inet -alias 10.10.64.40 nothing It appears that this is what the em driver is supposed to do, or at least fxp does it in this way. This is other issue. em(4) performs two time-consuming operations in its initialization routine. One is DMA tag/map creation and the other is checksumming EEPROM contents in init routine. I have an experimental patch for it but let's fix one at a time. OK, let's put that aside for now. Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Thu, Jul 06, 2006 at 07:11:57PM -0700, Atanas wrote: Pyun YongHyeon said the following on 7/6/06 6:03 PM: Hmm, that's strange. I've double checked that stock em(4) didn't generate ARP packets when its addresses were changed. So I made em(4) generate ARP. Could you see a gratuitous ARP with tcpdump when you change its address? I just left a tcpdump -n arp host 10.10.64.40 on a third machine sniffing around and tested all em module versions I had (the stock 6.1, 6-STABLE and 6-STABLE with your patch), but got silence on all three: That's odd. I've tested it on CURRENT and I could see the ARP packet. Are you sure you patched correctly? If so I have to build a RELENG_6 machine and give it try. EM# ifconfig em1 inet alias 10.10.64.40 nothing EM# ifconfig em1 inet -alias 10.10.64.40 nothing It's normal. The fxp driver appears to send something on startup and nothing on shutdown: FXP# ifconfig fxp0 inet alias 10.10.64.40 18:41:54.584059 arp who-has 10.10.64.40 tell 10.10.64.40 FXP# ifconfig fxp0 inet -alias 10.10.64.40 nothing When I manually arping the em alias after startup (i.e. simulate what fxp does), everything works as expected: EM# ifconfig em1 inet alias 10.10.64.40 nothing EM# arping -c1 -S10.10.64.40 10.10.64.40 18:46:07.808701 arp who-has 10.10.64.40 tell 10.10.64.40 Because arping requested it em(4) generated it. EM# ifconfig em1 inet -alias 10.10.64.40 nothing It appears that this is what the em driver is supposed to do, or at least fxp does it in this way. No, it's an em(4) driver bug. fxp(4)'s behavior is correct. This is other issue. em(4) performs two time-consuming operations in its initialization routine. One is DMA tag/map creation and the other is checksumming EEPROM contents in init routine. I have an experimental patch for it but let's fix one at a time. OK, let's put that aside for now. Regards, Atanas -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
