Re: em, bge, network problems survey.
Michal Mertl wrote: Kris Kennaway wrote: On Wed, Oct 04, 2006 at 05:14:27PM -0600, Scott Long wrote: All, I'm seeing some patterns here with all of the network driver problem reports, but I need more information to help narrow it down further. I ask all of you who are having problems to take a minute to fill out this survey and return it to Kris Kennaway (on cc:) and myself. Thanks. 1. Are you experiencing network hangs and/or timeout messages on the console? If yes, please provide a _brief_ description of the problem. OK, next question, to all em users: If your em device is using a shared interrupt, and you are NOT experiencing timeout problems when using this device, please let me know. I forgot to note I am running fresh current, not stable. I haven't seen any timeout message in long time but I experience frozen network (and also the already reported panic when doing ifconfig down/up then). I have also seen strange problem which may be completely unrelated: When doing 'find . -ls' on SMB mounted drive - find was spitting the contents of the drive but never finishes. Network seemed dead but when I interrupted find with Ctrl-C I got the replies to the pings sent when it was running (e.g. thousands ms) - this looks like something was preventing RX to work and the packets were just queued somewhere. I belive I should be able to easily reproduce it. genius# vmstat -i interrupt total rate irq0: clk 43784465 1000 irq1: atkbd0 66248 1 irq5: pcm0 5877 0 irq8: rtc5603682128 irq9: acpi0 8820 0 irq11: fwohci0 em*205749 4 irq12: psm0 586848 13 irq14: ata0 340844 7 irq15: ata1 61 0 Total 50602594 1155 I don't think I remember debug.mpsafenet tunable being mentioned in the threads about the problems. It prevents all the problems on my system (UP non-APIC system), including the SMB issue mentioned above. Michal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux Stable
On Friday 06 October 2006 07:57, Norberto Meijome wrote: On Fri, 6 Oct 2006 00:40:14 +0200 Albert Shih [EMAIL PROTECTED] wrote: Now my question what can I do ? Are there any kind of technics to _downgrad_ a STABLE ? Hi Albert, this was discussed in -questions@ on September 27th. http://monkey.org/freebsd/archive/freebsd-questions/200609/msg02105.html Also, use cvs to get an older RELENG_6 branch. You can do that with common command -D, check cvs manual. HTH, Nikos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ffs snapshot lockup
On Thu, Oct 05, 2006 at 10:01:07AM -0400, Vivek Khera wrote: On Oct 5, 2006, at 4:30 AM, Kostik Belousov wrote: The network load was minimal at the time. I had everyone log out and close mail etc. What were the symptoms of locked system ? Could you log in on console, or do something at the shell prompt on console ? Console was non-responsive. This time dump locked doing /usr so pretty much anything you try to run will block. When the lockup happens when dump is running on my home dir (/u/yertle1) partition, as long as you don't need that partition you can log in and run any programs you like. I have a service account whose home dir is in / var and was able to login that time to that account. No such luck this time since any activity pretty much uses /usr. Ping was responding (our monitoring didn't complain it was down). The only thing I could do was break to debugger on the console. This is very strange. You 3 instances of getty where just reading the tty input, and all suspectible processes (like sshd) are waiting on net events. No processes are blocked on the fs. One nfsd is serving the request, and dump is active. pgpAr4aPXXmZW.pgp Description: PGP signature
Re: /dev/null
Brent Casavant wrote: Not with FreeBSD in particular. However, from time to time I've run across a piece of software that makes bad assumptions about deleting various input or output files. If run as root, the program/library might accidentally delete a character special device such as /dev/null. Hmm, that's... inconvenient. I usually support root-almighty thing, but allowing deletion from dynamically populated /dev seems counterproductive. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for a serial port card you can actually BUY?
... So what do I buy to replace this thing? Well, looking at the serial hardware claimed supported, I seem to have a problem finding anything I can actually purchase! I don't need real high performance - a 16550 based multiport card is fine. I also don't want a $1500 solution - this isn't a $1500 problem. $500 seems reasonable. I have some 'gadgets' that 'bridge' serial and ip, which though not that cheep (about 100$), opens a whole new perspective. my 5 cents. danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Panics on IBM Bladecenter HS20/amd64 blades
Hi,
FreeBSD has been running rock solid on the older i386/HS20's, but the newer ones
with amd64 configuration keeps panicing, and I can't quite figure out why.
Help tracking this issue down, is greatly appreciated.
The panics happen randomly, average once every 2 days, sometimes just
20minutes between each panic, allways in the process tcpserver, which
indicates that this is a network related issue(?).
Another problem is that the system can't reboot by it's self, because there is
no keyboard controller, leaving the filesystems dirty (there is a flag
BROKEN_KEYBOARD_RESET in i386, but not in amd64), so I have to reboot the
machine via bladecenter managament to get it up again.
If there is anything I can do to provide more usefull output, please let me
know.
Trace:
--
mxtwo# kgdb kernel.debug /var/crash/vmcore.3
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x18c
fault code = supervisor read, page not present
instruction pointer = 0x8:0x802cf867
stack pointer = 0x10:0xb3ff38b0
frame pointer = 0x10:0x4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 1363 (tcpserver)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 6m22s
Dumping 2047 MB (2 chunks)
chunk 0: 1MB (154 pages) ... ok
chunk 1: 2047MB (523966 pages) 2031 2015 1999 1983 1967 1951 1935 1919 1903
1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663
1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423
1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183
1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911
895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607
591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303
287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:172
172 __asm __volatile(movq %%gs:0,%0 : =r (td));
(kgdb) list *0x802cf867
0x802cf867 is in _mtx_lock_sleep (/usr/src/sys/kern/kern_mutex.c:544).
539 * If the current owner of the lock is executing on
another
540 * CPU, spin instead of blocking.
541 */
542 owner = (struct thread *)(v MTX_FLAGMASK);
543 #ifdef ADAPTIVE_GIANT
544 if (TD_IS_RUNNING(owner)) {
545 #else
546 if (m != Giant TD_IS_RUNNING(owner)) {
547 #endif
548 turnstile_release(m-mtx_object);
(kgdb) bt
#0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x802d9bf7 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409
#3 0x802da291 in panic (fmt=0xff005b3fa4c0 @Ó¯[) at
/usr/src/sys/kern/kern_shutdown.c:565
#4 0x80488bff in trap_fatal (frame=0xff005b3fa4c0,
eva=18446742975736173376) at /usr/src/sys/amd64/amd64/trap.c:660
#5 0x80489126 in trap (frame=
{tf_rdi = 56, tf_rsi = -1097980730176, tf_rdx = 6, tf_rcx = 0, tf_r8 =
0, tf_r9 = 0, tf_rax = 1, tf_rbx = -1098015721464, tf_rbp = 4, tf_r10 =
-2037788432, tf_r11 = -1097980730176, tf_r12 = -1097980730176, tf_r13 =
-1097438414848, tf_r14 = 0, tf_r15 = 1, tf_trapno = 12, tf_addr = 396,
tf_flags = -2143116959, tf_err = 0, tf_rip = -2144536473, tf_cs = 8, tf_rflags
= 65538, tf_rsp = -1275119424, tf_ss = 16}) at
/usr/src/sys/amd64/amd64/trap.c:238
#6 0x8047449b in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:168
#7 0x802cf867 in _mtx_lock_sleep (m=0xff005929b808,
tid=18446742975728821440, opts=6, file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:542
#8 0x803826bd in ip_ctloutput (so=0x38, sopt=0xb3ff3b30) at
/usr/src/sys/netinet/ip_output.c:1193
#9 0x80393bd5 in tcp_ctloutput (so=0xff005a83b738,
sopt=0xb3ff3b30) at /usr/src/sys/netinet/tcp_usrreq.c:1038
#10 0x80322068 in sosetopt (so=0xff005a83b738,
sopt=0xb3ff3b30) at /usr/src/sys/kern/uipc_socket.c:1563
#11 0x80328536 in kern_setsockopt (td=0xff005b3fa4c0,
s=1619162408, level=56, name=0, val=0x0, valseg=UIO_USERSPACE,
valsize=2257178864) at /usr/src/sys/kern/uipc_syscalls.c:1351
#12 0x803285ae in setsockopt (td=0x38, uap=0xff005b3fa4c0) at
/usr/src/sys/kern/uipc_syscalls.c:1307
#13 0x80489a51 in syscall (frame=
{tf_rdi = 0, tf_rsi = 0, tf_rdx = 1, tf_rcx = 0, tf_r8 = 0, tf_r9 =
140737488349992, tf_rax = 105, tf_rbx = 0, tf_rbp = 0, tf_r10 = 0, tf_r11 =
514, tf_r12 = 3, tf_r13 = 140737488350320, tf_r14 = 0, tf_r15 = 0, tf_trapno =
12, tf_addr = 5285992, tf_flags = 12, tf_err
Re: em, bge, network problems survey.
Kris Kennaway wrote: On Thu, Oct 05, 2006 at 11:17:33PM +0200, O. Hartmann wrote: Kris Kennaway wrote: On Wed, Oct 04, 2006 at 05:14:27PM -0600, Scott Long wrote: All, I'm seeing some patterns here with all of the network driver problem reports, but I need more information to help narrow it down further. I ask all of you who are having problems to take a minute to fill out this survey and return it to Kris Kennaway (on cc:) and myself. Thanks. 1. Are you experiencing network hangs and/or timeout messages on the console? If yes, please provide a _brief_ description of the problem. OK, next question, to all em users: If your em device is using a shared interrupt, and you are NOT experiencing timeout problems when using this device, please let me know: dalki# vmstat -i interrupt total rate irq4: sio0 2071 0 irq6: fdc010 0 irq14: ata0 47 0 irq20: ahd021755 4 irq23: em0124751 23 -- not a shared interrupt irq24: ahd1 15 0 cpu0: timer 10453509 1999 Total 10602158 2027 tyan# vmstat -i interrupt total rate irq14: ata0 58 0 irq16: em0 fxp1 332832851 -- shared interrupt irq18: fxp0 973 2 irq19: atapci1132883339 cpu0: timer 774308 1980 cpu1: timer 777136 1987 Total2018190 5161 So far all of the em problems I have seen involve shared interrupts, and conversely all em systems I have seen that do not have timeout problems are not shared. Kris And so looks mine, FreeBSD 6.2-PRE/AMD64, high I/O on disks and I/O on net renders this box unusuable ... thor# vmstat -i interrupt total rate irq1: atkbd0 12437 1 irq6: fdc027 0 irq12: psm0 335285 42 irq14: ata0 215 0 irq17: fwohci0 1 0 irq20: atapci1102616 12 irq21: ohci0+ 2 0 irq22: nve0 ehci07594338956 irq23: pcm041007 5 cpu0: timer 31752206 3999 Total 39838134 5018 You don't appear to be using the em driver. Can you confirm? Kris positive. ___ 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: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
On Thu, Oct 05, 2006 at 08:13:15PM -0400, Jung-uk Kim wrote: It's definetely a regression from 4.11-STABLE that runs fine on this system with ACPI fully enabled Hmm, I was wrong about 4.11 using ACPI - it does not use it here really, it uses good old APM. It would be interesting to know how 4.x probes the hardware vs. how it apperas in the 6.x dmesg. 4.11-STABLE: fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 6.2-PRERELEASE: fdc0: floppy drive controller port 0x3f0-0x3f5,0x3f0 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: 1440-KB 3.5 drive on fdc0 drive 0 You have bad ACPI DSDT. Try newer BIOS if there's any. I've just upgraded BIOS to lastest available at support.intel.com for my motherboard (I was wrong thinking I run latest, there were more fresh). No change in behavour of fdc(4) in RELENG_6 and in HEAD, they still probe fdc0 the same way, STABLE's driver still does not work and CURRENT's works fine. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em, bge, network problems survey.
All, I'm seeing some patterns here with all of the network driver problem reports, but I need more information to help narrow it down further. I ask all of you who are having problems to take a minute to fill out this survey and return it to Kris Kennaway (on cc:) and myself. Thanks. 1. Are you experiencing network hangs and/or timeout messages on the console? If yes, please provide a _brief_ description of the problem. OK, next question, to all em users: If your em device is using a shared interrupt, and you are NOT experiencing timeout problems when using this device, please let me know: No apparent problem here. %vmstat -i interrupt total rate irq1: atkbd02416 0 irq4: sio0 1 0 irq14: ata0 47 0 irq16: uhci0 277 0 irq18: em0 atapci1 437511791329 irq21: pcm0 69483666 52 irq23: ehci0 1 0 irq24: twa0 9503153 7 irq25: twa1 2115898 1 irq26: ahc0 125 0 irq27: ahc1 15 0 cpu0: timer 2653958853 2000 Total 3172576243 2391 % %uname -a FreeBSD v2.netoldies.com 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Sun Sep 17 15:37:40 PDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/V2KERNEL i386 --Bill ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for a serial port card you can actually BUY?
Bob Johnson wrote: I have used USB-to-serial converters with no problem. All the control signals (at least the ones my applications need) seem to work correctly. I have one with a Prolific PL-2303 chipset: ucom0: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 5 It works great for standard serial communication, but not for what I want to use it for : read 'ticks' from my geiger counter. A 'normal' 16550A serial port chip does that just fine. regards, Hans Lambermont ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for a serial port card you can actually BUY?
On Thu, Oct 05, 2006 at 05:04:41PM -0400, Bob Johnson wrote: I have used USB-to-serial converters with no problem. All the control signals (at least the ones my applications need) seem to work correctly. I don't remember any brands or models off hand, I bought what was cheap as I needed them and they all worked. Cheap means under $20 delivered (for one port). Speaking of USB-to-serial converters... anybody know which chipset Moxa's UPort 1610-16 [1] and similar products are based on? Anybody know if they work with FreeBSD? Regards, Brix [1]: http://www.moxa.com/product/USB_to_Serial_Hubs.htm -- Henrik Brix Andersen [EMAIL PROTECTED] pgp5TdxOoWKVG.pgp Description: PGP signature
Re: Patch available for shared em interrupts (Re: em, bge, network problems survey.)
Kris Kennaway ([EMAIL PROTECTED]) on 05/10/2006 at 22:34 wrote: Based on successful testing on a machine with shared em interrupt, the following patch should work around the problem *in that case*. [...] Please let Scott and I know whether or not this patch works for you (in addition to the information previously requested, if you have not already sent it). Unfortunately it is only a workaround, but it points to an underlying problem with fast interrupt handlers on a shared irq that can be studied separately. # mojito uptime 14:23 up 1:59, 4 users, load averages: 0,07 0,05 0,01 # mojito uname -v FreeBSD 6.2-PRERELEASE #15: Fri Oct 6 12:11:36 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEBUG Your patch fixes my em/nvidia issue. Thanks Kris -- bug ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for a serial port card you can actually BUY?
The FTDI devices keep the device descriptors etc. in an EEPROM, so my approach to the 'which port is which' problem was to change the textual part of the descriptor - usbdevs -d then immediately tells you what is going on. The EEPROM is writable over the USB connection - I have a program to do so if anybody wants it. Yes please - I also use the devices, and this would be very handy. thanks, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for a serial port card you can actually BUY?
On Thu, 5 Oct 2006, Karl Denninger wrote: On Thu, Oct 05, 2006 at 05:04:41PM -0400, Bob Johnson wrote: I have used USB-to-serial converters with no problem. All the control signals (at least the ones my applications need) seem to work correctly. I don't remember any brands or models off hand, I bought what was cheap as I needed them and they all worked. Cheap means under $20 delivered (for one port). Interesting. Now, what happens when you reboot? Do they come back in random order? That won't work! I need to know that port 2 will BE Port 2 the next time the machine comes up Competent USB devices have serial numbers in them, although the current FreeBSD USB system doesn't provide easy access to the data (the kernel collects it as part of the device discovery, but AFAIR doesn't do anything with it). I solved my problems in a different way (below). As already mentioned in this thread, USB serial adapters fall into the 'too cheap' category (the purchase cost isn't worth mentioning, but you have no idea what will arrive when you order one). IMO, it's worth standardising on one adapter type (hence one device driver) and spending a bit more time/money on the purchasing. I standardized on adapters using the FTDI chips (www.ftdichip.com, they sell their own adapters but these chips are widely used and I've usually bought mine elsewhere). FTDI have been through about 3 generations of these chips while remaining driver compatible. When I started (several years ago), the uftdi driver wasn't up to the job for the sort of reasons you mention (control of handshakes, real-time control), but for my applications it was convenient to avoid using uftdi and simply address the devices with the ugen driver - giving me direct control over the handshakes, the FIFO timeout behaviour etc. I believe that uftdi has since improved and may now be the right way to go if your applications want a tty-style interface (I don't use it much, having as above written all my serious applications another way). The FTDI devices keep the device descriptors etc. in an EEPROM, so my approach to the 'which port is which' problem was to change the textual part of the descriptor - usbdevs -d then immediately tells you what is going on. The EEPROM is writable over the USB connection - I have a program to do so if anybody wants it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for a serial port card you can actually BUY?
On Fri, Oct 06, 2006 at 11:33:13AM +1000, Greg Black wrote: On 2006-10-05, Brooks Davis wrote: On Thu, Oct 05, 2006 at 07:09:56PM -0500, Karl Denninger wrote: On Thu, Oct 05, 2006 at 04:04:47PM -0500, Brooks Davis wrote: On Thu, Oct 05, 2006 at 03:21:44PM -0500, Karl Denninger wrote: FreeBSD's USB support has always been somewhat deficient. For example, apcupsd can't talk to their UPSs over the USB bus, even though the software itself knows how, because FreeBSD doesn't know what a UPS is and throws up its hands when you plug it in. This is false for at least the APC SmartUPS the machine I'm sending this from is connected to. I wouldn't be suprised if it was true once, but it isn't today. ugen0: American Power Conversion Smart-UPS 750 FW:651.12.D USB FW:4.2, rev 1.10/0.06, addr 2 Does apcupsd connect to it? I tried this back on 5.x and it failed miserably. It identified the unit, but wouldn't talk to it. Yes. I get notifications of power failures and can query status. I don't know what you guys are doing right, but it doesn't work right for me on $ uname -srm FreeBSD 6.1-RELEASE amd64 I do get some results: this is the console when it's connected: ugen1: American Power Conversion Smart-UPS 750 FW:651.12.I USB FW:7.3, rev 1.10/0.06, addr 6 I find that apcaccess gives much less info from the USB port than it does from the RS232 port (on the same hardware) and apctest (which I want to use to set eprom values) doesn't work at all. This is very irritating, as I'd like to use my only serial port for a remote console. For now, I've gone back to using the serial port. But I'd love the USB to work fully. I don't seem to need the other features. This is not a FreeBSD issue since FreeBSD just knows enough to not try to do anything to the device, it's an apcupsd issue or possibly a weakness in APCs USB implementation. -- Brooks pgpXggZQTKeqM.pgp Description: PGP signature
pcmcia bluetooth card?
Any ideas how I might be able to get this card recognized, or better, to function? ;-) Oct 6 10:17:37 toshi kernel: pccard0: unknown card (manufacturer=0x, product=0x, function_type=2) at function 0 Oct 6 10:17:37 toshi kernel: pccard0:CIS info: Bluetooth BT0100M, , Michael ___ 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: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
Hi, for information, I tested the latest patch from bz@ : http://sources.zabbadoz.net/freebsd/patchset/20061005-01-carp-v6-scope-ipfw.diff and carp with IPv6 is working fine again ! More information in the PR (kern/98622) thanks a lot -- Philippe Pegon Bruce A. Mah wrote: If memory serves me right, Philippe Pegon wrote: In June 2006, I opened a PR (kern/98622) about a regression on CARP with IPv6 addresses: CARP is not usable with IPv6. Since I tracked down the culprit commit (see appropriate info in the PR), I can affirm that this regression appeared before the 6.1-RELEASE. bz@ has just recently (a couple of hours ago) updated kern/98622 with a possible fix. It'd be really useful if you (or anyone else experiencing this problem) could try this out and give him some feedback. (I know that you, Philippe, know all this already, but I wanted to get the information out to a wider audience.) Cheers, Bruce. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/null
On Fri, Oct 06, 2006 at 10:03:11AM +0200, Ivan Voras wrote: Brent Casavant wrote: Not with FreeBSD in particular. However, from time to time I've run across a piece of software that makes bad assumptions about deleting various input or output files. If run as root, the program/library might accidentally delete a character special device such as /dev/null. Hmm, that's... inconvenient. I usually support root-almighty thing, but allowing deletion from dynamically populated /dev seems counterproductive. The command 'devfs rule -s 2 apply 100' should fix it, I think. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpVCbt8lcOTt.pgp Description: PGP signature
Re: /dev/null
Roland Smith wrote: The command 'devfs rule -s 2 apply 100' should fix it, I think. ? If I read devfs(8) correctly, this should apply rule 100 of ruleset 2. Since I have no rulesets or rules, it doesn't work. :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for a serial port card you can actually BUY?
On Fri, Oct 06, 2006 at 01:10:37AM -0400, Matt Emmerton wrote: Karl Denninger wrote: So. I have an application that requires six serial ports, and would like ten. 5.x FreeBSD versions are being EOL'd per the announcement, forcing me to move to 6.x. The Comtrol driver for the Smart Rocketport boards is broken in 6.x, and the PR appears to be one that will sit and rot. What options do I have in the FreeBSD universe here guys? This is a real no-BS production application that has hundreds of deployed instances, and it is in no way obsolete or something I intend to stop supporting. Well, you could find (or hire) someone to fix the driver in 6.x, which would save you the cost of re-deploying hardware. (I'm assuming that the PR is a statement of brokenness, and not one that has a patch that fixes the problem.) Correct; the PR is (my) statement of brokenness Fixing the driver would require knowing what has changed that broke it. I've not found any such concise statement of what has changed internally in the kernel interfaces in the past... does such a thing exist? -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em, bge, network problems survey.
On Fri, Oct 06, 2006 at 11:21:32AM +0200, O. Hartmann wrote: And so looks mine, FreeBSD 6.2-PRE/AMD64, high I/O on disks and I/O on net renders this box unusuable ... thor# vmstat -i interrupt total rate irq1: atkbd0 12437 1 irq6: fdc027 0 irq12: psm0 335285 42 irq14: ata0 215 0 irq17: fwohci0 1 0 irq20: atapci1102616 12 irq21: ohci0+ 2 0 irq22: nve0 ehci07594338956 irq23: pcm041007 5 cpu0: timer 31752206 3999 Total 39838134 5018 You don't appear to be using the em driver. Can you confirm? Kris positive. It's probably a nve driver bug then, you should talk to the driver author. This may not be fixable in FreeBSD since it's a binary driver, so bug fixes mostly need to be done by the vendor. kris pgpp9K7YFPg4C.pgp Description: PGP signature
Re: Recommendations for a serial port card you can actually BUY?
On Fri, Oct 06, 2006 at 02:25:31PM +0100, Andrew Gordon wrote: On Thu, 5 Oct 2006, Karl Denninger wrote: On Thu, Oct 05, 2006 at 05:04:41PM -0400, Bob Johnson wrote: I have used USB-to-serial converters with no problem. All the control signals (at least the ones my applications need) seem to work correctly. I don't remember any brands or models off hand, I bought what was cheap as I needed them and they all worked. Cheap means under $20 delivered (for one port). Interesting. Now, what happens when you reboot? Do they come back in random order? That won't work! I need to know that port 2 will BE Port 2 the next time the machine comes up Competent USB devices have serial numbers in them, although the current FreeBSD USB system doesn't provide easy access to the data (the kernel collects it as part of the device discovery, but AFAIR doesn't do anything with it). I solved my problems in a different way (below). I think there may be another option. Here's the boot message, with just USB related things: usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 usb3: USB revision 1.0 usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0 usb4: USB revision 2.0 Now, isn't this in fact invarient? That is, isn't the probe on the bus going to be the same across boots? We can then get which device is on which port with Fs:/disk/karl usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 addr 2: low speed, self powered, config 1, Smart-UPS 1500 FW:601.3.D USB FW:1.5(0x0002), American Power Conversion(0x051d), rev 0.06 port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 addr 2: full speed, power 100 mA, config 1, USB-Serial Controller(0x2008), Prolific Technology Inc.(0x0557), rev 3.00 port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb3: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb4: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered port 7 powered port 8 powered Now, where the problem comes in is that THIS line doesn't reference an attached port. That sucks, but might not be hard to fix: ucom0: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 2 So is there any way to discover what port a UCOM device is attached to? If so, bingo - you've got it. I think I can get this from the usb(8) driver - going to code something up to see if it works -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ffs snapshot lockup
On Fri, Oct 06, 2006 at 10:39:50AM +0300, Kostik Belousov wrote: On Thu, Oct 05, 2006 at 10:01:07AM -0400, Vivek Khera wrote: On Oct 5, 2006, at 4:30 AM, Kostik Belousov wrote: The network load was minimal at the time. I had everyone log out and close mail etc. What were the symptoms of locked system ? Could you log in on console, or do something at the shell prompt on console ? Console was non-responsive. This time dump locked doing /usr so pretty much anything you try to run will block. When the lockup happens when dump is running on my home dir (/u/yertle1) partition, as long as you don't need that partition you can log in and run any programs you like. I have a service account whose home dir is in / var and was able to login that time to that account. No such luck this time since any activity pretty much uses /usr. Ping was responding (our monitoring didn't complain it was down). The only thing I could do was break to debugger on the console. This is very strange. You 3 instances of getty where just reading the tty input, and all suspectible processes (like sshd) are waiting on net events. No processes are blocked on the fs. One nfsd is serving the request, and dump is active. To repeat something I said earlier: when creating a snapshot (e.g. which dump -L does), the entire system may become unresponsive untilk the snapshot completes, which can take many minutes. How long are you waiting before pronouncing the system deadlocked? What does ^T on the console (e.g. when trying to log in), show you? Kris pgpY6zPaZmvsz.pgp Description: PGP signature
Re: ppp redial unsuccessful
Nick Gustas wrote: Oct 4 19:03:09 xxx ppp[55]: tun0: Phase: bundle: Authenticate Oct 4 19:03:09 xxx ppp[55]: tun0: Phase: deflink: his = PAP, mine = none Oct 4 19:03:09 xxx ppp[55]: tun0: Phase: Pap Output: [EMAIL PROTECTED] Oct 4 19:03:09 xxx ppp[55]: tun0: LCP: deflink: RecvCodeRej(127) state = Opened Oct 4 19:03:11 xxx ppp[55]: tun0: Phase: Pap Input: SUCCESS () The real question is, is there's a way to work around your provider's brokenness without killing the ppp process? Hi Nick, I cranked up the debug logging, and compared my ppp login attempts with your logfile. I get multiple Oct 6 18:29:43 coyote ppp[67945]: tun0: IPCP: deflink: RecvConfigReq(12) state = Initial Oct 6 18:29:43 coyote ppp[67945]: tun0: IPCP: IPADDR[6] 213.191.89.20 Oct 6 18:29:43 coyote ppp[67945]: tun0: IPCP: deflink: Oops, RCR in Initial. Oct 6 18:29:46 coyote ppp[67945]: tun0: IPCP: deflink: RecvConfigReq(13) state = Initial Oct 6 18:29:46 coyote ppp[67945]: tun0: IPCP: IPADDR[6] 213.191.89.20 Oct 6 18:29:46 coyote ppp[67945]: tun0: IPCP: deflink: Oops, RCR in Initial. Using Google Search then led me to the follow posts [1], that describe the problem in more detail. 'disable ipv6cp' should do the trick, I'll check this ASAP. Thanks for your pointer! [1] http://www.freebsd.de/archive/de-bsd-questions/de-bsd-questions.200506/0029.html http://tech.barwick.de/openbsd/deflink-oops-rcr-in-initial.html Ulrich Spoerlein -- A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting frowned upon? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/null
On Fri, Oct 06, 2006 at 06:09:09PM +0200, Ivan Voras wrote: Roland Smith wrote: The command 'devfs rule -s 2 apply 100' should fix it, I think. ? If I read devfs(8) correctly, this should apply rule 100 of ruleset 2. Since I have no rulesets or rules, it doesn't work. :) Are you sure that you have no rulesets? I've made only one ruleset in /etc/devfs.rules, with the number 10. However, when I do have more rulesets: # devfs rule showsets 1 2 3 4 10 I guess these (except 10) are made during system startup or are system defaults. They are: # devfs rule -s 1 show 100 hide # devfs rule -s 2 show 100 path null unhide 200 path zero unhide 300 path crypto unhide 400 path random unhide 500 path urandom unhide # devfs rule -s 3 show 100 path ptyp* unhide 200 path ptyq* unhide 300 path ptyr* unhide 400 path ptys* unhide 500 path ptyP* unhide 600 path ptyQ* unhide 700 path ptyR* unhide 800 path ptyS* unhide 900 path ttyp* unhide 1000 path ttyq* unhide 1100 path ttyr* unhide 1200 path ttys* unhide 1300 path ttyP* unhide 1400 path ttyQ* unhide 1500 path ttyR* unhide 1600 path ttyS* unhide 1700 path fd unhide 1800 path fd/* unhide 1900 path stdin unhide 2000 path stdout unhide 2100 path stderr unhide # devfs rule -s 4 show 100 include 1 200 include 2 300 include 3 HTH, Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpjHpt2wFFBk.pgp Description: PGP signature
Re: ffs snapshot lockup
On Fri, Oct 06, 2006 at 02:11:05PM -0400, Vivek Khera wrote: On Oct 6, 2006, at 1:57 PM, Kris Kennaway wrote: This is very strange. You 3 instances of getty where just reading the tty input, and all suspectible processes (like sshd) are waiting on net events. No processes are blocked on the fs. One nfsd is serving the request, and dump is active. To repeat something I said earlier: when creating a snapshot (e.g. which dump -L does), the entire system may become unresponsive untilk the snapshot completes, which can take many minutes. I know snapshot takes a while -- we're used to that. How long are you waiting before pronouncing the system deadlocked? 10's of minutes. What does ^T on the console (e.g. when trying to log in), show you? There were no active snapshotting in the progress. Snapshot was already made, and dump happily processed in the moment captured in the script. nothing. the console is non-responsive. the remote shells are non responsive to any input. I'm now convinced it was all stemming from some bug in bge driver (at least for my specific chipset.) Last night I put in an old spare 3c905 NIC and turned off the motherboard bge via BIOS. I can't make the machine lock up at all, even with the watchdog running, and doing level0 dumps. Also, even though this NIC is only 10/100 and the prior was running at GigE speed, the system is *way* more responsive to network operations. For example, when I logged in this morning my IMAP mail client took barely a second or or so to open my inbox, whereas before it would take upwards of 10 seconds. This machine was always this way since it was first set up running 5.3. I can't believe I lived with it for so long... I'd like to find a nice stable GigE NIC for it, since I know that the onboard bge is definitely sub-optimal with FreeBSD. Dell's diagnostics don't find any hardware fault, for what that's worth. Curiously, I have a handful of other Dell servers at the office which all have bge and run just great at GigE speed to the same switch. If it does lock up again, I'll be sure to let you know! Was this system patched by the stuff I submitted to you ? pgpT50ylzWbU5.pgp Description: PGP signature
Re: Recommendations for a serial port card you can actually BUY?
At 01:53 PM 10/6/2006, Karl Denninger wrote: Now, where the problem comes in is that THIS line doesn't reference an attached port. That sucks, but might not be hard to fix: If there is just one USB *serial* device, it will always be /dev/ttyU0. It doesnt matter if you have 1 or 3 other USB devices (ugen0, uhid0, uhid1) ucom0: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 2 So is there any way to discover what port a UCOM device is attached to? If so, bingo - you've got it. You dont need to... It will always be ttyU0 in the above case if you just have one *serial* usb device. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em, bge, network problems survey.
On Fri, Oct 06, 2006 at 08:54:35AM +0200, Michal Mertl wrote: Kris Kennaway wrote: On Wed, Oct 04, 2006 at 05:14:27PM -0600, Scott Long wrote: All, I'm seeing some patterns here with all of the network driver problem reports, but I need more information to help narrow it down further. I ask all of you who are having problems to take a minute to fill out this survey and return it to Kris Kennaway (on cc:) and myself. Thanks. 1. Are you experiencing network hangs and/or timeout messages on the console? If yes, please provide a _brief_ description of the problem. OK, next question, to all em users: If your em device is using a shared interrupt, and you are NOT experiencing timeout problems when using this device, please let me know. I haven't seen any timeout message in long time but I experience frozen network (and also the already reported panic when doing ifconfig down/up then). Are these details in a PR? I have also seen strange problem which may be completely unrelated: When doing 'find . -ls' on SMB mounted drive - find was spitting the contents of the drive but never finishes. Network seemed dead but when I interrupted find with Ctrl-C I got the replies to the pings sent when it was running (e.g. thousands ms) - this looks like something was preventing RX to work and the packets were just queued somewhere. I belive I should be able to easily reproduce it. genius# vmstat -i interrupt total rate irq0: clk 43784465 1000 irq1: atkbd0 66248 1 irq5: pcm0 5877 0 irq8: rtc5603682128 irq9: acpi0 8820 0 irq11: fwohci0 em*205749 4 irq12: psm0 586848 13 irq14: ata0 340844 7 irq15: ata1 61 0 Total 50602594 1155 I don't think I remember debug.mpsafenet tunable being mentioned in the threads about the problems. It prevents all the problems on my system (UP non-APIC system), including the SMB issue mentioned above. I suspect both of your problems are some unrelated issue. I'd need root access a test setup before I can say more though. Kris pgp0pABy3Seyl.pgp Description: PGP signature
Re: ffs snapshot lockup
On Fri, Oct 06, 2006 at 02:11:05PM -0400, Vivek Khera wrote: On Oct 6, 2006, at 1:57 PM, Kris Kennaway wrote: This is very strange. You 3 instances of getty where just reading the tty input, and all suspectible processes (like sshd) are waiting on net events. No processes are blocked on the fs. One nfsd is serving the request, and dump is active. To repeat something I said earlier: when creating a snapshot (e.g. which dump -L does), the entire system may become unresponsive untilk the snapshot completes, which can take many minutes. I know snapshot takes a while -- we're used to that. OK, thanks for confirming. I'm now convinced it was all stemming from some bug in bge driver (at least for my specific chipset.) Last night I put in an old spare 3c905 NIC and turned off the motherboard bge via BIOS. We'd be interested in diagnosing this problem separately; can you set up a test machine with this card and give me access to it? Kris pgp5BixhXIBFf.pgp Description: PGP signature
Re: /dev/null
Roland Smith wrote: Are you sure that you have no rulesets? Yup. The command devfs rule showsets shows nothing. This is on somewhat old RELENG_6. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ffs snapshot lockup
On Oct 6, 2006, at 2:20 PM, Kostik Belousov wrote: If it does lock up again, I'll be sure to let you know! Was this system patched by the stuff I submitted to you ? yes. i did not update anything except adding the xl driver to the kernel, so as to minimize changes. if this holds stable for a few days i may try upgrading to BETA2. are your fixes rolled in there yet?
Re: ffs snapshot lockup
On Oct 6, 2006, at 2:31 PM, Kris Kennaway wrote: I'm now convinced it was all stemming from some bug in bge driver (at least for my specific chipset.) Last night I put in an old spare 3c905 NIC and turned off the motherboard bge via BIOS. We'd be interested in diagnosing this problem separately; can you set up a test machine with this card and give me access to it? I'm not sure which card you want to diagnose. The Dell PE800 has an onboard bge ethernet which was apparently not working at full speed, or was stalling otherwise. The 3c905 is what I used to be able to turn off the bge NIC. It appears to be functioning well.
Capture all incoming/outgoing email messages
Hi, I have a gateway/firewall running FreeBSD 6.1 -release . I would like to capture all incoming and outgoing email messages to archive them. Is there is any tool available out there ? I mean a proxy,sniffer or any other solution. Thanks in advance, Dominik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Capture all incoming/outgoing email messages
2006/10/6, Eric [EMAIL PROTECTED]: Dominik Zalewski wrote: Hi, I have a gateway/firewall running FreeBSD 6.1 -release . I would like to capture all incoming and outgoing email messages to archive them. Is there is any tool available out there ? I mean a proxy,sniffer or any other solution. there are ways in postfix and probably most other MTAs to make a copy of things as they are handled by the SMTP engine. check out the howtos on postfix.org or google a little and you should have plenty to go on. Eric I know most of MTAs can do it but I dont want users to use local MTA for outgoing emails, plus this solution is just for outgoing emails , what about pop3 ? I just want to capture all smtp/pop3 traffic in packets level. Dominik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Capture all incoming/outgoing email messages
On Fri, Oct 06, 2006 at 10:11:17PM +0200, Dominik Zalewski wrote: I know most of MTAs can do it but I dont want users to use local MTA for outgoing emails, plus this solution is just for outgoing emails , what about pop3 ? I just want to capture all smtp/pop3 traffic in packets level. So what's stopping you? tcpdump, Ethereal, sniffit, snort... they'll all do this. Anything that dumps to a libpcap formatted file can be read back using tcpdump or Ethereal (Ethereal would be best, since it can perform general formatting analysis on specific packets, such as SMTP and POP3). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://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 [EMAIL PROTECTED]
Re: Capture all incoming/outgoing email messages
On Friday 06 October 2006 23:11, Dominik Zalewski wrote: 2006/10/6, Eric [EMAIL PROTECTED]: Dominik Zalewski wrote: Hi, I have a gateway/firewall running FreeBSD 6.1 -release . I would like to capture all incoming and outgoing email messages to archive them. Is there is any tool available out there ? I mean a proxy,sniffer or any other solution. there are ways in postfix and probably most other MTAs to make a copy of things as they are handled by the SMTP engine. check out the howtos on postfix.org or google a little and you should have plenty to go on. Eric I know most of MTAs can do it but I dont want users to use local MTA for outgoing emails, plus this solution is just for outgoing emails , what about pop3 ? I just want to capture all smtp/pop3 traffic in packets level. man tcpdump(1) particularly the -r, -w options and the port primitive. -- patrick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Capture all incoming/outgoing email messages
On Oct 6, 2006, at 1:11 PM, Dominik Zalewski wrote: I just want to capture all smtp/pop3 traffic in packets level. OK: tcpdump -w /var/log/mailarchive.dump -s 0 port smtp or port pop3 But be aware that you should disclose the existence of this mail monitoring to all users, consult your local laws about electronic wiretapping, or both. In some countries or states, doing the above without notification and/or the permission of at least one party is likely to be against the law... [ This probably belongs on freebsd-questions@, or in a discussion with your lawyer. ] -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Capture all incoming/outgoing email messages
On Fri, Oct 06, 2006 at 10:11:17PM +0200, Dominik Zalewski wrote: I know most of MTAs can do it but I dont want users to use local MTA for outgoing emails, plus this solution is just for outgoing emails , what about pop3 ? I just want to capture all smtp/pop3 traffic in packets level. Try mailsnarf from the dsniff package. -- Regards, Richard. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp redial unsuccessful
On Fri, Oct 06, 2006 at 08:02:02PM +0200, Ulrich Spoerlein wrote: I cranked up the debug logging, and compared my ppp login attempts with your logfile. I get multiple Oct 6 18:29:43 coyote ppp[67945]: tun0: IPCP: deflink: RecvConfigReq(12) state = Initial Oct 6 18:29:43 coyote ppp[67945]: tun0: IPCP: IPADDR[6] 213.191.89.20 Oct 6 18:29:43 coyote ppp[67945]: tun0: IPCP: deflink: Oops, RCR in Initial. Oct 6 18:29:46 coyote ppp[67945]: tun0: IPCP: deflink: RecvConfigReq(13) state = Initial Oct 6 18:29:46 coyote ppp[67945]: tun0: IPCP: IPADDR[6] 213.191.89.20 Oct 6 18:29:46 coyote ppp[67945]: tun0: IPCP: deflink: Oops, RCR in Initial. Using Google Search then led me to the follow posts [1], that describe the problem in more detail. 'disable ipv6cp' should do the trick, I'll check this ASAP. Yesterday, I've had a brand new 6.2-PRERELEASE Oct 4th box installed on T-Com ADSL, using the same ppp.conf from my previous post. I've just logged into this box and seen a successful disconnect/reconnect, as always after 24hrs. Everything seems all right with ppp and T-Com ADSL. Ulrich Spoerlein Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS client slow on amd64 6.2-PRERELEASE #2
Jeremy Chadwick wrote this message on Thu, Oct 05, 2006 at 09:08 -0700: The problem in that case turned out to be duplex-related. Both boxes were auto-negotiating with the Cisco switch correctly, and indeed the Cisco labelled them as auto-100/full, but as anyone who is familiar with Ciscos knows, auto-negotiation on Catalysts is far from reliable. Both boxes reported auto-neg and being at 100/full as well. I ended up hard-setting the boxes to use 100/full, and set the switch ports to 100/full, then rebooted both boxes (yes, this is sometimes required, as driver auto-neg code is a bit tweaky); voila, problem fixed. It appears that some ethernet drivers don't reset the phy (bring the link down) when changing media (duplex setting, etc).. This means that if you boot w/ autoselect, and the switch autoselects to 100/full, but then later change it to 100/full (w/ autoselect off) it will work fine.. but then if the cabel is pulled, or the switch resets, it attempts to reautoselect, but falls back to 100/half while you are still running 100/full... As you can imagine, it causes a very hard to track down problem since the time it breaks is not readily apparent... an ifconfig iface down; ifconfig iface up may help resolve this issue if you are not sure... I have just committed a patch to fxp0 to do this... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp redial unsuccessful
cpghost wrote: On Fri, Oct 06, 2006 at 08:02:02PM +0200, Ulrich Spoerlein wrote: I cranked up the debug logging, and compared my ppp login attempts with your logfile. I get multiple Oct 6 18:29:43 coyote ppp[67945]: tun0: IPCP: deflink: RecvConfigReq(12) state = Initial Oct 6 18:29:43 coyote ppp[67945]: tun0: IPCP: IPADDR[6] 213.191.89.20 Oct 6 18:29:43 coyote ppp[67945]: tun0: IPCP: deflink: Oops, RCR in Initial. Oct 6 18:29:46 coyote ppp[67945]: tun0: IPCP: deflink: RecvConfigReq(13) state = Initial Oct 6 18:29:46 coyote ppp[67945]: tun0: IPCP: IPADDR[6] 213.191.89.20 Oct 6 18:29:46 coyote ppp[67945]: tun0: IPCP: deflink: Oops, RCR in Initial. Using Google Search then led me to the follow posts [1], that describe the problem in more detail. 'disable ipv6cp' should do the trick, I'll check this ASAP. Yesterday, I've had a brand new 6.2-PRERELEASE Oct 4th box installed on T-Com ADSL, using the same ppp.conf from my previous post. I've just logged into this box and seen a successful disconnect/reconnect, as always after 24hrs. Everything seems all right with ppp and T-Com ADSL. I guess it depends on the actual hardware on the other side. Different POPs have different hardware (versions) and software (configuration). Let's wait for another 24h to see if I found the solution. Ulrich Spoerlein -- A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting frowned upon? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Capture all incoming/outgoing email messages
On Fri, Oct 06, 2006, Dominik Zalewski wrote: Hi, I have a gateway/firewall running FreeBSD 6.1 -release . I would like to capture all incoming and outgoing email messages to archive them. Is there is any tool available out there ? I mean a proxy,sniffer or any other solution. If the gateway/firewall handles all mail and is running postfix, adding ``always_bcc = address'' to the main.cf file will cause all mail going through postfix to have a blind carbon copy sent to that address. I don't know if one can do something as we do on Linux boxes where the gateway/firewall/NAT box traps all outgoing port 80, rerouting it through squid which allows caching and access controls for the entire network. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Systems, Inc. UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ ``We maintain that the very foundation of our way of life is what we call free enterprise,'' said Cash McCall, but when one of our citizens show enough free enterprise to pile up a little of that profit, we do our best to make him feel that he ought to be ashamed of himself. -- Cameron Hawley ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
fsck_ufs: cannot alloc 2051395920 bytes for inoinfo
Server just crashed, rebooted and trying to do an fsck, reports the above ... Never seen that one before :( FreeBSD 6.2-PRERELEASE #0: Mon Sep 18 23:16:11 ADT 2006 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck_ufs: cannot alloc 2051395920 bytes for inoinfo
Odd ... ran it a second time after posting this, and it ran through fine ... --On Saturday, October 07, 2006 02:13:11 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: Server just crashed, rebooted and trying to do an fsck, reports the above ... Never seen that one before :( FreeBSD 6.2-PRERELEASE #0: Mon Sep 18 23:16:11 ADT 2006 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for a serial port card you can actually BUY?
On Fri, Oct 06, 2006 at 02:27:21PM -0400, Mike Tancsa wrote: At 01:53 PM 10/6/2006, Karl Denninger wrote: Now, where the problem comes in is that THIS line doesn't reference an attached port. That sucks, but might not be hard to fix: If there is just one USB *serial* device, it will always be /dev/ttyU0. It doesnt matter if you have 1 or 3 other USB devices (ugen0, uhid0, uhid1) ucom0: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 2 So is there any way to discover what port a UCOM device is attached to? If so, bingo - you've got it. You dont need to... It will always be ttyU0 in the above case if you just have one *serial* usb device. ---Mike Yes, I understand that. I might have anywhere up to eight though! I think it still works, as I can get the full list with the hub attachments, and THOSE should be invarient (that is, they correspond to a port on the machine, assuming we're talking all on-bus ports (e.g. no expanders) # usbdevs -v -d Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 uhub0 port 1 addr 2: low speed, self powered, config 1, Smart-UPS 1500 FW:601.3.D USB FW:1.5(0x0002), American Power Conversion(0x051d), rev 0.06 ugen0 port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 uhub1 port 1 addr 2: full speed, power 100 mA, config 1, USB-Serial Controller(0x2008), Prolific Technology Inc.(0x0557), rev 3.00 ucom0 port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 uhub2 port 1 powered port 2 powered Controller /dev/usb3: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 uhub3 port 1 powered port 2 powered Controller /dev/usb4: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x), rev 1.00 uhub4 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered port 7 powered port 8 powered Since /dev/usb0 - /dev/usbx should not move from boot to boot (that is, being that they're either on the PCI bus directly or on the motherboard, they should always probe in the same order) I can thus discover which COM port was assigned to which physical port, since the /dev/usbx ports are in fact physical sockets. Given that I can create a directory full of symlinks with invarient names (e.g. /ldev/usbtty0) pointing to the correct ports via a shell script. This doesn't work if you plug and unplug some of the devices while the machine is running (since the script wouldn't know to run again) but it should for the case where the devices are connected at the time of boot. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Capture all incoming/outgoing email messages
I have a commercial spam-blocking tool that runs on FreeBSD which can do this (along with interdicting all your spam for you.) Its not freeware tho - its a product. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind On Fri, Oct 06, 2006 at 10:00:40PM +0200, Dominik Zalewski wrote: Hi, I have a gateway/firewall running FreeBSD 6.1 -release . I would like to capture all incoming and outgoing email messages to archive them. Is there is any tool available out there ? I mean a proxy,sniffer or any other solution. Thanks in advance, Dominik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] %SPAMBLOCK-SYS: Matched [EMAIL PROTECTED], message ok ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
