Re: Compaq dual processor & broken MP table
On Tue, Jan 09, 2001 at 03:18:21PM +0200, Lauri Laupmaa wrote: > Hi > > On compaq ML350 dual processor kernel says: > APIC_IO: Testing 8254 interrupt delivery > APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 > intpin 2 > APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 > > Is it some major problem or just annoying message ? It's just saying it's working around a quirk in the IOAPIC setup. It seems to be common on Compaqs; I have a ProLiant 800 (dual PPro 200) that gives a similar message when it boots Linux 2.2. If the machine's working, it's nothing to worry about. -lee -- ++ | Lee Cremeans -- Manassas, VA, USA (WakkyMouse on WTnet) | | [EMAIL PROTECTED] | http://wakky.dyndns.org/~lee | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
mailinglist
subscribe freebsd-stable subscribe cvs-all To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Weird files in root
For some resaon this keeps appearing in / 0 lrwxr-xr-x 1 root wheel 10 Jan 9 14:49 ttyv0 -> /dev/ttyv0 Anyone know why? -- Erich Zigler I'm locked in a maze of little projects, all of which suck. -- Chris "Saundo" Saunderson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
subscribe
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Intel PRO/100+ driver or hardware?
As I recall, Vivek Khera wrote: > It isn't connected. Note the "media" line as compared to the output > of mine: > > [onceler]% ifconfig fxp0 > fxp0: flags=8843 mtu 1500 > inet 208.184.13.196 netmask 0xff00 broadcast 208.184.13.255 > ether 00:e0:18:ac:14:21 > media: autoselect (100baseTX ) status: active > supported media: autoselect 100baseTX 100baseTX 10baseT/UTP > 10baseT/UTP I've been having an off-line conversation with David Kelley about this. I believe the behavior of displaying the media type selected in the probe output started in the 3.5-RELEASE, and this system is a 2.2.8-RELEASE. I found in /sys/src/pci/if_fxp.c that there is an IOCTL (SIOCGIFMEDIA) that should do the trick with just a small C wrapper program... > Is the link light on the card on or off? There should also be a > 10/100 light that is on for 100baseT (full or half). Link and 100meg is on on both the NIC and the hub. If I trust the Ethernet hardware to properly report what it negotiated (and no reason not to), we got the 100Mbit. No way to know for sure about FDX/HDX. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Vivek Khera, Ph.D.Khera Communications, Inc. > Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 > AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ -crl -- Chad R. Larson (CRL15) 602-953-1392 Brother, can you paradigm? [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] DCF, Inc. - 14623 North 49th Place, Scottsdale, Arizona 85254-2207 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
gif & faith needed?
Hiyas, I am just wondering if gif and faith pseudo devices are needed for anything? (Besides IPv6 stuff) And what they are for... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Repeated panic in 4.2-stable
( I think -stable will be interested in this so I'm including -stable in the thread ) --> TO EVERYONE RUNNING STABLE!!! Do not use a filesystem block size greater then 16384. 8192 is ok, 16384 should be ok. Anything bigger will hit this bug. :Yes. PR 20609, assigned to you for some time. : :> The buffer map is a system map, right? Which means it allocates :> map_entry elements out of kmapentzone, which is a ZONE_INTERRUPT zone, :> which can't block. : :No. It is not a system map. It should be a system map. : :> There is a vm_object_allocate() call, which uses a non-interrupt zone, :> but I don't think it applies to buffer-cache buffers. Buffer cache :> buffer KVM is not backed by arbitrary VM objects. : :_vm_map_clip_end() and _vm_map_clip_start() calls vm_object_allocate() :if the entry being split has no object. So it certainly applies to :the buffer cache buffers due to vm objects incorrectly being allocated :for buffer map entries. : :- Tor Egge Yes, well, there are two dozen PR's assigned to me... sometimes I loose track :-) Grr. You know what Tor, your mail from middle of last year is *still* in my inbox! Ok, I'll look into it and not forget this time. The patch you include in the PR seems reasonable after a quick look. The VFS/BIO subsystem never calls vm_map_simplify_entry() or vm_map_lookup(), which means that as long as the filesystem block size does not exceed the buffer cache KVM granularity the clipping routines will never be called. The buffer cache KVM granularity is 16384 bytes. So as long as one does not use a block size greater then 16384 bytes it should be reasonably safe (we still have to fix this, of course, I'm trying to diagnose the likelyhood of a problem for people using standard block sizes). A block size of exactly 16384 bytes should work fine. It looks like with the above stricture, the only exposed hole is the vm_map_entry allocation routine. If we block there it is possible for a second entry in the VFS/BIO subsystem to allocate the same KVM address range and create a second buffer sharing the same backing memory. (Side note: If bitmap blocks exceed 16384K, this could cause serious filesystem corruption. I'm not sure whether this is possible or not but it's something to think about. It could be related to why filesystems with extreme newfs parameters seems to have more then their fair share of problems). I will say that of course we have to fix this bug, but in the current released systems there is virtually no chance of zalloc() blocking due to the low memory deadlock fixes I put in after christmas. So as long as people are not using a filesystem block size larger then 16384 bytes I think their systems will be fine. This is a great example of how fragile code can wind up in a relatively stable system with no alarm bells ringing. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: gif & faith needed?
On Wed, 10 Jan 2001, Kal Torak wrote: > Hiyas, > > I am just wondering if gif and faith pseudo devices are needed for > anything? (Besides IPv6 stuff) > And what they are for... > You've mentioned the reason for those devices. If you're more deep into IPv6, you'll find they're used for tunneling. And if you wish to use just ipv4 for one month more, you dont need this. Domas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
cvsup12 out of sync ?
Is cvsup12 really out of sync? I installed a snap from today, did a cvsup to get a few extra commits from this afternoon and Checkout src/sys/conf/files Checkout src/sys/conf/newvers.sh Delete src/sys/dev/aac/aac.c Delete src/sys/dev/aac/aac_compat.h Delete src/sys/dev/aac/aac_debug.c Delete src/sys/dev/aac/aac_disk.c Delete src/sys/dev/aac/aac_ioctl.h Delete src/sys/dev/aac/aac_pci.c Delete src/sys/dev/aac/aac_tables.h Delete src/sys/dev/aac/aacreg.h Delete src/sys/dev/aac/aacvar.h Checkout src/sys/dev/aic7xxx/aic7xxx.c Checkout src/sys/dev/aic7xxx/aic7xxx_freebsd.c Checkout src/sys/dev/aic7xxx/aic7xxx_inline.h Checkout src/sys/i386/conf/LINT Delete src/sys/modules/aac/Makefile Checkout src/sys/netgraph/ng_base.c Checkout src/sys/netgraph/ng_message.h Checkout src/sys/netgraph/ng_rfc1490.c Checkout src/sys/sys/syslog.h SetAttrs src/usr.bin/lex/mkskel.sh,v Checkout src/usr.sbin/ngctl/Makefile Delete src/usr.sbin/ngctl/config.c Checkout src/usr.sbin/ngctl/main.c Checkout src/usr.sbin/ngctl/ngctl.8 Checkout src/usr.sbin/ngctl/ngctl.h SetAttrs src/usr.sbin/pkg_install/tkpkg,v Checkout src/usr.sbin/syslogd/syslogd.c Shutting down connection to server Finished successfully compared to cvsup11 Edit src/sys/conf/files Add delta 1.340.2.43 2001.01.09.01.01.46 scottl Checkout src/sys/dev/aac/aac.c Checkout src/sys/dev/aac/aac_compat.h Checkout src/sys/dev/aac/aac_debug.c Checkout src/sys/dev/aac/aac_disk.c Checkout src/sys/dev/aac/aac_ioctl.h Checkout src/sys/dev/aac/aac_pci.c Checkout src/sys/dev/aac/aac_tables.h Checkout src/sys/dev/aac/aacreg.h Checkout src/sys/dev/aac/aacvar.h Edit src/sys/dev/aic7xxx/aic7xxx.c Add delta 1.41.2.13 2001.01.09.00.46.53 gibbs Edit src/sys/dev/aic7xxx/aic7xxx_freebsd.c Add delta 1.3.2.13 2001.01.09.00.46.55 gibbs Edit src/sys/dev/aic7xxx/aic7xxx_inline.h Add delta 1.2.2.6 2001.01.09.00.46.55 gibbs Edit src/sys/i386/conf/LINT Add delta 1.749.2.41 2001.01.09.01.03.31 scottl Checkout src/sys/modules/aac/Makefile Edit src/sys/netgraph/ng_base.c Add delta 1.11.2.8 2001.01.09.06.52.20 phk Edit src/sys/netgraph/ng_message.h Add delta 1.4.2.4 2001.01.09.06.52.20 phk Edit src/sys/netgraph/ng_rfc1490.c Add delta 1.6.2.3 2001.01.09.00.52.45 julian Edit src/sys/netinet/ip_fw.h Add delta 1.47.2.4 2001.01.09.18.11.40 rwatson Edit src/sys/netinet/tcp.h Add delta 1.13.2.1 2001.01.09.18.20.22 rwatson Add delta 1.13.2.2 2001.01.09.18.25.18 rwatson Edit src/sys/sys/syslog.h Add delta 1.19.2.1 2001.01.09.06.51.34 phk Edit src/sys/ufs/ufs/ufs_disksubr.c Add delta 1.44.2.1 2001.01.09.12.26.17 phk Edit src/usr.sbin/ngctl/Makefile Add delta 1.4.2.1 2001.01.09.06.52.25 phk Checkout src/usr.sbin/ngctl/config.c Edit src/usr.sbin/ngctl/main.c Add delta 1.4.2.3 2001.01.09.06.52.25 phk Edit src/usr.sbin/ngctl/ngctl.8 Add delta 1.5.2.3 2001.01.09.06.52.25 phk Edit src/usr.sbin/ngctl/ngctl.h Add delta 1.6.2.2 2001.01.09.06.52.25 phk Edit src/usr.sbin/syslogd/syslogd.c Add delta 1.59.2.4 2001.01.09.06.51.37 phk Shutting down connection to server Finished successfully Mike Tancsa, tel +1 519 651 3400 Network Administration, [EMAIL PROTECTED] Sentex Communications www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Weird files in root
Erich Zigler wrote: > For some resaon this keeps appearing in / > >0 lrwxr-xr-x 1 root wheel 10 Jan 9 14:49 ttyv0 -> /dev/ttyv0 > > Anyone know why? Probably /etc/rc.devfs combined with a /dev/vga symlink pointing at nothing. Not sure how that broken symlink got there, but it was there on three of my machines.. :-/ -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Intel PRO/100+ driver or hardware? (Update)
Bert Driehuis writes: > "Jeroen C. van Gelderen" wrote: > > > My conclusion is that the Intel cards I have are broken. They refuse to > > work reliably in an otherwise healthy low-end network. I may have a bad > > batch or maybe these cards are broken by design. > > It is possible your motherboard vendor screwed up: > > http://developer.intel.com/design/support/faq/82559.htm > > Apparently, some motherboard vendors let boards go out with wrong wiring > or capacitors (see the bottom of the page), and the symptoms match yours > (which, I must stress, may very well be a coincidence). If I'm following correctly Jeroen's problem is with genuine Intel Etherexpress Pro boards with the '59 chip. Not with an integrated chipset as discussed in the above URL. Intel offers an interesting diagnostic suggestions: if it doesn't work with a short wire, try a long wire. Suspect Jeroen's most timely solution is to permanently replace his cards with something else. Altho he makes mention of a PCI riser card which may alter the electrical reference the Intel card has to work against. Am also thinking the computer power supply, or clock frequency can be part of the problem. Or part of the solution. Wonder if underclocking the system would make any differnce? Have seen unreliable computers fixed by replacing the PS. And this was before CPU's started running off of anything other than plain old 5V. As for non-Intel ethernet cards, 3 or 4 years ago when I first got to play with fast ethernet, found by accident that a 3Com card connected to a 3Com switch was more forgiving of wrongly pairing the cat5 wires than anything else connected to the same switch and wire. IMHO am surprised this sort of thing doesn't happen more often. -- David Kelly N4HHE, [EMAIL PROTECTED] = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Intel PRO/100+ driver or hardware? (Update)
"Jeroen C. van Gelderen" writes: > I tried 2 hubs, one claims to be a cheap 8816TPC, the other NetGear DS108. > Both give problems. Replacing the Intel card with a 3Com or SMC solves the > problem. Of course I've tried multiple cables as well. > > Maybe this is relevant. The DS108 actually is a dual speed hub. IIRC it has > a 10 Mbit bus and a 100 Mbit bus, connected with a little switch. The > machine I'm testing against has a 10Mbit card. I tried forcing to Intel to > 10Mbit and tried to transfer the file. It stalls after a couple of > megabytes. In the same place every time, I hope? >I then forced the Intel card to 100Mbit mode and tried the > transfer again (so it would have to go trough the switching device in the > hub); That got me a little further (22 MB) but this transfer too stalled > eventually. Same question, "Fails in the same place each time you try?" > > Any chance you can capture and/or share the problem data? > > More than willing to, but I'm not sure how to do it most effectively. You > just want the tcpdump data? Do I need to give any special arguments to > tcpdump? If its file transfer the easiest thing to do would be to transfer the exact same file. But 22 MB into it, sounds like a system backup. Ideally if you had a small file which failed with ftp, it would be easy for others to attempt to duplicate your failure. Am far from a tcpdump guru but it would be rough dumping headers and packets until problems start 22MB of data later. Especially if done on the same machine as the problem is happening because the tcpdump processing may be all it takes to clear up the problem. Or make it worse. Ideally one would only want to dump packets which fail checksum. So maybe wait to start tcpdump until the transfer stops. It may be time to "cut bait" and simply accept the Intel cards didn't work in your situation and go on with things. Know I'm using an Intel card right now (with an AMD CPU :-) ) but forgot to look and see what chip was on it. My other 3 Intel cards are 58's, in other machines. -- David Kelly N4HHE, [EMAIL PROTECTED] = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Intel PRO/100+ driver or hardware? (Update)
On Tue, 09 Jan 2001 21:23:01 CST, David Kelly wrote: > >Suspect Jeroen's most timely solution is to permanently replace his >cards with something else. Altho he makes mention of a PCI riser card >which may alter the electrical reference the Intel card has to work >against. I've had lots of trouble with an "L"-style riser card (for 1U cases) and several different enet and a few other cards. Got rid of the riser and things work fine. I haven't tried an Intel EEPRO in the riser though. -- Parag Patel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
