Re: geom_gate problems (RELENG_6 from today)
Am Montag, 26. Dezember 2005 14:15 CEST schrieb Harald Schmalzbauer: Hello, merry christmas to veryone, especially Pawel, since I hope he can fix my problem ;) When I create /dev/ggate2 I can successfully dd to it (the raw device), but as soon as I newfs ggate2 and mount it I cannot write a file onto the filesystem, like dd if=/dev/zero of=/mnt/testfile bs=32k. Same problem when using /dev/ggateX as geom_mirror consumer. I tried different physical lines for ggate (fwe and em), no difference. I also recompiled my kernel without ipfw but also no difference. Here are some error messages I got: While playing arround I got a panic: GEOM_GATE[0]: Device ggate2 destroyed. korso:~#65: ggatec create -u 2 10.0.0.1 /dev/ad4p3 korso:~#66: mount /dev/ggate2 /mnt korso:~#67: dd if=/dev/zero of=/mnt/testfile bs=32k dev = ggate2, block = 3704, fs = /mnt panic: ffs_blkfree: freeing free block Uptime: 1h6m55s GEOM_RAID3: Device BIGVOL: provider raid3/BIGVOL destroyed. GEOM_RAID3: Device BIGVOL destroyed. Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort Unfortunately it's a CF-based server, no space for debug kernel, nor do I have a HD as dumpdev. But I guess this is easily reproducable -Harry korso:~#34: ggatec create -u 2 -t 30 172.21.2.1 /dev/ad4p3 korso:~#35: mount /dev/ggate2 /mnt korso:~#36: dd if=/dev/zero of=/mnt/testfile bs=32k ^Cg_vfs_done():ggate2[WRITE(offset=7733248, length=131072)]error = 5 g_vfs_done():ggate2[WRITE(offset=7864320, length=131072)]error = 5 g_vfs_done():ggate2[WRITE(offset=7995392, length=131072)]error = 5 o_vfs_d60+0 records in 59+0 records ount e1933312 bytes tr(ansferred in 19.)828540 secs (975:01 bytes/sec) ggate2[WRITE(offset=8126464, length=131072)]error = 5 g_vfs_done():ggate2[WRITE(offset=7340032, length=131072)]error = 5 g_vfs_done():ggate2[WRITE(offset=7471104, length=131072)]error = 5 g_vfs_done():ggate2[WRITE(offset=7602176, length=131072)]error = 5 korso:~#37: umount /mnt g_vfs_done():ggate2[WRITE(offset=114688, length=16384)]error = 5 g_vfs_done():ggate2[WRITE(offset=6144000, length=2048)]error = 5 g_vfs_done():ggate2[WRITE(offset=65536, length=2048)]error = 5 g_vfs_done():ggate2[WRITE(offset=7995392, length=131072)]error = 5 g_vfs_done():ggate2[WRITE(offset=8126464, length=131072)]error = 5 g_vfs_done():ggate2[WRITE(offset=98304, length=16384)]error = 5 fsync: giving up on dirty 0xc3e72110: tag devfs, type VCHR usecount 1, writecount 0, refcount 6 mountedhere 0xc400f700 flags () v_object 0xc18284a4 ref 0 pages 10 lock type devfs: EXCL (count 1) by thread 0xc3b33000 (pid 1451) dev ggate2 umount: unmount of /mnt failed: Resource temporarily unavailable pgp1ZNyD0UIbJ.pgp Description: PGP signature
More geom trouble [Was: Re: geom_gate problems (RELENG_6 from today)]
Here is another error I got recently: g_vfs_done():ad0a[WRITE(offset=35405824, length=8192)]error = 1 g_vfs_done():ad0a[WRITE(offset=35430400, length=8192)]error = 1 This time no geom_[raid3,mirror,gate] was involved!! Something seems to be badly broken -Harry Am Montag, 26. Dezember 2005 14:29 CEST schrieb Emanuel Strobl: Am Montag, 26. Dezember 2005 14:15 CEST schrieb Harald Schmalzbauer: Hello, merry christmas to veryone, especially Pawel, since I hope he can fix my problem ;) When I create /dev/ggate2 I can successfully dd to it (the raw device), but as soon as I newfs ggate2 and mount it I cannot write a file onto the filesystem, like dd if=/dev/zero of=/mnt/testfile bs=32k. Same problem when using /dev/ggateX as geom_mirror consumer. I tried different physical lines for ggate (fwe and em), no difference. I also recompiled my kernel without ipfw but also no difference. Here are some error messages I got: While playing arround I got a panic: GEOM_GATE[0]: Device ggate2 destroyed. korso:~#65: ggatec create -u 2 10.0.0.1 /dev/ad4p3 korso:~#66: mount /dev/ggate2 /mnt korso:~#67: dd if=/dev/zero of=/mnt/testfile bs=32k dev = ggate2, block = 3704, fs = /mnt panic: ffs_blkfree: freeing free block Uptime: 1h6m55s GEOM_RAID3: Device BIGVOL: provider raid3/BIGVOL destroyed. GEOM_RAID3: Device BIGVOL destroyed. Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort Unfortunately it's a CF-based server, no space for debug kernel, nor do I have a HD as dumpdev. But I guess this is easily reproducable -Harry korso:~#34: ggatec create -u 2 -t 30 172.21.2.1 /dev/ad4p3 korso:~#35: mount /dev/ggate2 /mnt korso:~#36: dd if=/dev/zero of=/mnt/testfile bs=32k ^Cg_vfs_done():ggate2[WRITE(offset=7733248, length=131072)]error = 5 g_vfs_done():ggate2[WRITE(offset=7864320, length=131072)]error = 5 g_vfs_done():ggate2[WRITE(offset=7995392, length=131072)]error = 5 o_vfs_d60+0 records in 59+0 records ount e1933312 bytes tr(ansferred in 19.)828540 secs (975:01 bytes/sec) ggate2[WRITE(offset=8126464, length=131072)]error = 5 g_vfs_done():ggate2[WRITE(offset=7340032, length=131072)]error = 5 g_vfs_done():ggate2[WRITE(offset=7471104, length=131072)]error = 5 g_vfs_done():ggate2[WRITE(offset=7602176, length=131072)]error = 5 korso:~#37: umount /mnt g_vfs_done():ggate2[WRITE(offset=114688, length=16384)]error = 5 g_vfs_done():ggate2[WRITE(offset=6144000, length=2048)]error = 5 g_vfs_done():ggate2[WRITE(offset=65536, length=2048)]error = 5 g_vfs_done():ggate2[WRITE(offset=7995392, length=131072)]error = 5 g_vfs_done():ggate2[WRITE(offset=8126464, length=131072)]error = 5 g_vfs_done():ggate2[WRITE(offset=98304, length=16384)]error = 5 fsync: giving up on dirty 0xc3e72110: tag devfs, type VCHR usecount 1, writecount 0, refcount 6 mountedhere 0xc400f700 flags () v_object 0xc18284a4 ref 0 pages 10 lock type devfs: EXCL (count 1) by thread 0xc3b33000 (pid 1451) dev ggate2 umount: unmount of /mnt failed: Resource temporarily unavailable pgp9uIfrFk5HJ.pgp Description: PGP signature
PANIC (g_vfs_done()) on RELENG_6
Hello, the following error occured on my new RELENG_6 server from yesterday: gune:/#34: cpdup -X .cvsjail -X INTERN -X PUBLIC /server/ /mnt/ ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=75285888 ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=75290368 ad4: detached unknown: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=75294464 g_vfs_done():ad4[WRITE(offset=38550896640, length=131072)]error = 6 g_vfs_done():ad4[WRITE(offset=38551027712, length=131072)]error = 6 g_vfs_done():ad4[WRITE(offset=38551158784, length=131072)]error = 6 g_vfs_done():ad4[WRITE(offset=38551289856, length=131072)]error = 6 g_vfs_done():ad4[WRITE(offset=38551420928, length=131072)]error = 6 g_vfs_done():ad4[WRITE(offset=38551552000, length=131072)]error = 6 g_vfs_done():ad4[WRITE(offset=65536, length=2048)]error = 6 g_vfs_done():ad4[WRITE(offset=6144000, length=4096)]error = 6 g_vfs_done():ad4[WRITE(offset=35840851968, length=16384)]error = 6 . . . Regrettably I don't have any HD inside besides the one which is my removable backup medium, so I don't have a dump but here's the panic message: g_vfs_done():ad4[WRITE(offset=38551814144, length=131072)]error = 6 g_vfs_done():ad4[WRITE(offset=38551945216, length=131072)]error = 6 g_vfs_done():ad4[WRITE(offset=38552076288, length=131072)]er Fatal trap 12: page fault while in kernel mode fault virtual address = 0x48 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05673c7 stack pointer = 0x28:0xd5a38c60 frame pointer = 0x28:0xd5a38c7c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 27 (swi4: clock sio) trap number = 12 panic: page fault Uptime: 49m49s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... interrupt total irq0: clk3004829 irq1: atkbd0 2 irq3: sio1 32757 irq5: em01039903 irq7: ppc0 1 irq8: rtc 384565 irq10: fxp0 194 irq11: atapci1 1376340 irq12: fwohci0++ 1 irq13: npx02 irq14: ata0 3480 Total 5842074 panic: watchdog timeout Uptime: 50m5s Cannot dump. No dump device defined. Tell me if I can help, very limited since it's a CF-Card based server -Harry pgpobbFsLmQeL.pgp Description: PGP signature
Re: /dev/random too hungry? Errormsg: PRNG is not seeded
Am Dienstag, 20. Dezember 2005 17:50 CEST schrieb Harald Schmalzbauer: Hello, I have one box where PRNG kickstart doesn't work. Whne I set 'sysctl kern.random.sys.seeded=0' and 'cat /boot/kernel/kernel.gz /dev/random' .random.sys.seeded is still 0. On any other box it's enough to send one byte and .sys.seeded returns to 1 I found that when installing a new server and trying to usually start sshd. (ssh-keygen quits immediately with the error: PRNG is not seeded) I'm not very familar with random or entropy stuff so please tell me what to do. Nothing uncommon so far with that box (besides it starts from CompactFlash with memorydisk for /var / and /tmp): Sorry, forgot to mention it's RELENG_6 from today... kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 192 kern.random.yarrow.slowthresh: 256 kern.random.yarrow.slowoverthresh: 2 kern.random.sys.seeded: 0 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 kern.random.sys.harvest.swi: 0 interrupt total rate irq0: clk1038776998 irq1: atkbd0 2 0 irq3: sio1 2610 2 irq5: em0133 0 irq7: ppc0 1 0 irq8: rtc 132946127 irq10: fxp0 72 0 irq12: fwohci0++ 1 0 irq13: npx02 0 irq14: ata0 3110 2 irq15: ata1 202 0 Thanks in advance, -Harry pgpAt6Ku1rET0.pgp Description: PGP signature
buildworld broken in lib/libnetgraph
Hello, 1.8.2.1 of src/lib/libnetgraph/ broke buildworld 3 hours ago on RELENG_6 -Harry pgpNmHpG3OyhC.pgp Description: PGP signature
Re: Disable hifn crypto card?
Am Samstag, 8. Oktober 2005 03:29 CEST schrieb Brandon Fosdick: I have a Soekris crypto card (hifn driver) in a box that I don't have immediate access to. Is there some way to disable the card w/o rebooting the machine? I know I could take the driver out of the kernel or force it not to load, but that requires a reboot that I'd like to avoid if possible. hifn is currently compiled into the kernel so I can't do a kldunload either. That was the first thing I thought of, but apparently today is not my lucky day. If it's enough that ipsec won't make use of it you can see the sysctl: net.inet.ipsec.crypto_support I think -1 means no hw-crypto-support, 0 auto and 1 hw only, but I can't remember where I read about it to verify that ... :( -Harry Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] pgpB40uM0qWcg.pgp Description: PGP signature
audio (acdt01) dump broken? (BETA4 (5))
Hello, tonight I wanted to consolidate (for an upcoming trekstor i.beat organix) my oggs and therefore eval the difference between reencoded [EMAIL PROTECTED][EMAIL PROTECTED] and the original reread wavs(tracks)-[EMAIL PROTECTED] Unfortunately I couldn't grab my CDs anymore. I can remember I had used 'dd if=/dev/acd0txx of=/tmp/track.xx bs=2352' but this doesn't work anymore. I can't replay the bits and with oggenc I get: ERROR: Input file track15.wav is not a supported format _But_: cdda2wav -D2,0,0 -t 15 -Owav is working fine! Result is: [...*SNIP*] recording 217.8666 seconds stereo with 16 bits @ 44100.0 Hz -'audio'... percent_done: 100% track 15 recorded successfully oggenc audio.wav Opening with wav module: WAV file reader Encoding audio.wav to audio.ogg at quality 3,00 [ 99,9%] [ 0m00s remaining] \ Done encoding file audio.ogg File length: 3m 37,0s Elapsed time: 1m 39,2s Rate: 2,1952 Average bitrate: 101,3 kb/s What am I missing? Thanks in advance, -Harry pgpqE8msRjOEC.pgp Description: PGP signature
Re: audio (acdt01) dump broken? (BETA4 (5))
Am Montag, 19. September 2005 03:21 CEST schrieb Ben Kaduk: Interesting -- I only have one other suggession; I was recently rereading the handbook section on burning cd's, and it said that it was better to have .pcm files which don't have the header that .wav files do -- apparently the header produces a 'tick' on playback. Have you tried ripping to .pcm files? Perhaps oggenc is looking for a nonexistent header. I also checked the handbook for copying cd's -- you are correct that 2352 is the magic blocksize -- I used 64k when ripping an entire (data) cd to copy it. Well, with data CDs you won't use /dev/acdtxx ;) It's a great special feature of ATAng/mkIII; If not before... Hmm, AFAIK WAV _is_ PCM, both don't have any headers. But I'm out of business for details for more than 10 years, so I may be wrong. But since /dev/acdXtY is designed to provide the raw audio (wav=pcm) bits like cdda2wav does, I guess there's something broken since cdda2wav works but acdXtY doesn't anymore... Thanks, -Harry pgpYRoseZABhU.pgp Description: PGP signature
Re: Slow internet browsing.
Am Dienstag, 13. September 2005 22:51 CEST schrieb Sandro Noel: Greetings. i dont know if this is the right group, so please correct me . I'm using 5.4 RELEASE i need to know how to uninstall a networking device from the system completely it was configured with sysinstall. when the system starts up, the sk0 is configured to get a DHCP lease. it gets the lease but afterwards anything trying to access the network is slow to a crawl, i tried disabeling the device and the system boots just fine and fast. but when on, it draws somme operations to a crawl. starting Xorg takes forever and i use KDE, and for some reason the Konkeror browser is slow to the point where it will time out eventually. i tried Firefox, and the same thing happens. some operations are notmal for some reason, SAMBA operations are ok, FTP is somewhat slower but acceptable. Downloading a file from the FTP is very long to start, but once started, it's as fast as what i am used to. This all sounds like DNS problems... Check your resolv.conf nsswitch.conf/host.conf and the correspondig servers. -Harry ping and all the related tools seem to work ok. any clue would be helpful, I'm looking in the eye of a reinstall, and i hate that solution. Sandro Noel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] pgpNRuINppHrM.pgp Description: PGP signature
acpi_sony - no powerd, no man page!
Hello, I just installed BETA4 on my notebook and was curious about the acpi_sony driver, but all I can see is that powerd soesn't work anymoder (if I call powerd -a min dev.cpu.0.freq is still 800 wher it was 62 without acpi_sony compiled in) and that I can set LCD brightness :) *bright_smile* But what does ctr, pcr, wdp and cdp mean? A short man page was wonderful! And is it known/intended that cpufreq doesn't work with acpi_sony? Thanks, -Harry pgpKJmjX5E6B5.pgp Description: PGP signature
Re: PANIC, a very strange one, at least for me on 6.0-BETA2
Am Freitag, 26. August 2005 08:15 CEST schrieb Emanuel Strobl: Hello, fortunately I had my laptop logging on the serial console when my box suddenly panicked. I just removed a directory, no usual panic message. System is late BETA2, please find attached the trace and panick message This panic showed up again, again after the same things done, so I filed a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=85804 Unfortunately I can't reproduce it with a freshly booted machine, seems the box hast to be up some days Again, attached all I got on the serial console this time. -Harry panic: handle_workitem_remove: bad file delta KDB: enter: panic [thread pid 54 tid 100059 ] Stopped at kdb_enter+0x30: leave db where Tracing pid 54 tid 100059 td 0xc1e75780 kdb_enter(c0791b35,c0801560,c07a421e,d58b2c3c,100) at kdb_enter+0x30 panic(c07a421e,11970,0,d58b2c50,3b7) at panic+0xd5 handle_workitem_remove(c2d81de0,0,2,32e,0) at handle_workitem_remove+0x107 process_worklist_item(0,0,c07a39e1,2de,431db271) at process_worklist_item+0x20b softdep_process_worklist(0,0,c079a93a,678,0) at softdep_process_worklist+0x130 sched_sync(0,d58b2d38,c078ef39,30d,0) at sched_sync+0x2ee fork_exit(c06078c0,0,d58b2d38) at fork_exit+0xc1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd58b2d6c, ebp = 0 --- db pgpYb1PLCSiD4.pgp Description: PGP signature
HZ option [Was: Re: custom kernel + if_xl + error]
Am Sonntag, 4. September 2005 03:15 CEST schrieb L.Edgeworth:
[*snip*]
Sorry, can't help, i can't see any reason for this in your config file...
options SMP
deviceapic
options DEVICE_POLLING
options HZ=1000
AFAIK setting HZ to 1000 isn't nedded on 6.0 and above systems. It's
standard. Here's what my non-acpi/apic system ([EMAIL PROTECTED]) says:
kern.clockrate: { hz = 1000, tick = 1000, profhz = 1024, stathz = 128 }
And here from my 1GHz Celeron with acpi and apic:
kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }
Can somebody eplain the profhz to me? Especially why it's higher on the
much slower machine...
-Harry
deviceacpi
deviceisa
devicepci
deviceagp
deviceata
deviceatadisk
deviceatapicd
deviceatapicam
options ATA_STATIC_ID
devicescbus
deviceda
devicecd
devicepass
devicenpx
deviceatkbdc
deviceatkbd
devicepsm
devicevga
devicesplash
options VESA
devicesc
options MAXCONS=12
options SC_PIXEL_MODE
devicemiibus
devicerl
deviceloop
devicemem
deviceio
devicerandom
deviceether
devicetun
devicetap
devicepty
deviceif_bridge
devicebpf
deviceusb
deviceuhci
deviceohci
deviceehci
deviceugen
deviceuhid
deviceukbd
deviceumass
deviceums
devicesound
devicesnd_cmi
devicesnd_ich
devicedrm
deviceradeondrm
options NETGRAPH
options NETGRAPH_BLUETOOTH
options NETGRAPH_BLUETOOTH_L2CAP
options NETGRAPH_BLUETOOTH_SOCKET
options NETGRAPH_BLUETOOTH_UBT
options NETGRAPH_BLUETOOTH_HCI
this is RELENG_6 *just* before BETA3.
___
To help you stay safe and secure online, we've developed the all new
Yahoo! Security Centre. http://uk.security.yahoo.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
[EMAIL PROTECTED]
pgpD073Sftoey.pgp
Description: PGP signature
Re: BTX failure [Was: Re: pxeboot problems with BETA2]
Am Donnerstag, 25. August 2005 20:06 CEST schrieb John Baldwin: [...] I have no ideay why, but over night I recompiled my PXEROOT system (BETA3 now) and the problem vanished. I can't see any changes in the cvsweb, so I have absolutely no idea what the problem was. Hardware is exactly the same. What have I missed? Maybe you had a corrupted pxeboot binary somehow? I'm quiet sure that this can't be. I played arround with several CFLAG options (-Os, -marchi486 etc.) and with several -DPXELDR_ALWAYS_SERIAL etc. so I'm sure I had tested some dozends of different pxeboot binaries. And I can't imagine that corrupted source file can cause such an error, remember that all these pxeboot binaries worked fine on PIII boxes, just not with the Elan SC520. I'm glad that it works now, but it was really interesting what in the chain of libs/dependend boot/loader stuff was the reason... Thanks for your help, -Harry pgpVgTaiWXS5H.pgp Description: PGP signature
PANIC, a very strange one, at least for me on 6.0-BETA2
Hello, fortunately I had my laptop logging on the serial console when my box suddenly panicked. I just removed a directory, no usual panic message. System is late BETA2, please find attached the trace and panick message Thanks, -Harry panic: handle_workitem_remove: bad file delta KDB: enter: panic [thread pid 53 tid 100060 ] Stopped at kdb_enter+0x30: leave db where Tracing pid 53 tid 100060 td 0xc1e75600 kdb_enter(c07a6126,c080c740,c07b2824,d58afc30,100) at kdb_enter+0x30 panic(c07b2824,24933,0,d58afc44,c3478be0) at panic+0xd5 handle_workitem_remove(c2e2ad80,0,2,cef,1) at handle_workitem_remove+0x137 process_worklist_item(0,0,0,c1e75600,c0800560) at process_worklist_item+0x253 softdep_process_worklist(0,c1e75600,68,c07aac30,0) at softdep_process_worklist+0x180 sched_sync(0,d58afd38,0,0,0) at sched_sync+0x396 fork_exit(c0610e20,0,d58afd38) at fork_exit+0x7f fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd58afd6c, ebp = 0 --- db pgphCjXa9cBvb.pgp Description: PGP signature
Re: BTX failure [Was: Re: pxeboot problems with BETA2]
Am Mittwoch, 17. August 2005 21:29 CEST schrieb John Baldwin: On Wednesday 17 August 2005 10:43 am, Emanuel Strobl wrote: Am Dienstag, 16. August 2005 19:52 CEST schrieb Brooks Davis: On Tue, Aug 16, 2005 at 02:05:08PM +0200, Emanuel Strobl wrote: Hello, I just wanted to ask if somebody had success with providing pxe boot service under 6-BETA2. I have two clients, one NET4501 wich just reboots after fetching pxeldr via TFTP and a Laptop which just hangs when NFS-loading kernel. I'm about to investigate further, but maybe someone can confirm that in general PXE booting with BETA2 is working... Or not... I'm PXE booting systems with RELENG_6 as of 7/27. I'll probably do an update some time this week. Ok, I read som files and found -DBTX_SERIAL. This gives me the following dump before the box reboots: uilding the boot loader arguments Relocating the loader and the BTX Starting the BTX loader int=0006 err= efl=00010202 eip=00023c21 eax= ebx=000384e0 ecx=000384e0 edx=0001 esi=1000 edi=0029 ebp=00086770 esp=00086758 cs=002b ds=0033 es=0033fs=0033 gs=0033 ss=0033 cs:eip=0f 4f c2 a3 c8 7d 03 00-8d 41 0c c7 41 04 fd 44 ff 55 89 39 c6 44 39 ff-fe 83 c4 0c 5b 5e 5f 5d ss:esp=b4 7d 03 00 29 00 00 00-00 10 00 00 00 00 00 00 83 57 02 00 02 00 00 00-a0 67 08 00 98 1c 02 00 BTX halted Any clue? Regarding cvsweb nothing changed recently, and I had net4501 boxes pxebooting fine with FreeBSD 5.3. Hmm. Int 6 is an invalid opcode exception: I have no ideay why, but over night I recompiled my PXEROOT system (BETA3 now) and the problem vanished. I can't see any changes in the cvsweb, so I have absolutely no idea what the problem was. Hardware is exactly the same. What have I missed? Thanks, -Harry 0F4FC2cmovg eax,edx 0003 A3C87D0300mov [0x37dc8],eax 0008 8D410Clea eax,[ecx+0xc] 000B C74104FD44FF55mov dword [ecx+0x4],0x55ff44fd 0012 8939 mov [ecx],edi 0014 C64439FFFEmov byte [ecx+edi-0x1],0xfe 0019 83C40Cadd esp,byte +0xc 001C 5Bpop ebx 001D 5Epop esi 001E 5Fpop edi 001F 5Dpop ebp I'm guessing that there's been a stack overflow or some such. Your eip is in the loader. You can try using the loader.sym from your loader binary to look up that eip address. In the loader here on my laptop it's in the write function: % nm /usr/obj/usr/src/sys/boot/i386/loader/loader.sym | sort ... 00023b9c T readdirfd 00023c14 T write 00023d18 T lseek If you want to be able to use gdb, then rebuild libstand with debugging (make DEBUG_FLAGS=-g) and rebuild all of /sys/boot with debugging (make DEBUG_FLAGS=-g). You can then use /usr/obj/usr/src/sys/boot/i386/pxeldr/pxeboot for your pxeboot and you can run gdb on /usr/obj/usr/src/sys/boot/i386/loader/loader.sym and you can do listings of the addresses for eip, etc. pgpj0zK68sjPU.pgp Description: PGP signature
BTX failure [Was: Re: pxeboot problems with BETA2]
Am Dienstag, 16. August 2005 19:52 CEST schrieb Brooks Davis: On Tue, Aug 16, 2005 at 02:05:08PM +0200, Emanuel Strobl wrote: Hello, I just wanted to ask if somebody had success with providing pxe boot service under 6-BETA2. I have two clients, one NET4501 wich just reboots after fetching pxeldr via TFTP and a Laptop which just hangs when NFS-loading kernel. I'm about to investigate further, but maybe someone can confirm that in general PXE booting with BETA2 is working... Or not... I'm PXE booting systems with RELENG_6 as of 7/27. I'll probably do an update some time this week. Ok, I read som files and found -DBTX_SERIAL. This gives me the following dump before the box reboots: uilding the boot loader arguments Relocating the loader and the BTX Starting the BTX loader int=0006 err= efl=00010202 eip=00023c21 eax= ebx=000384e0 ecx=000384e0 edx=0001 esi=1000 edi=0029 ebp=00086770 esp=00086758 cs=002b ds=0033 es=0033fs=0033 gs=0033 ss=0033 cs:eip=0f 4f c2 a3 c8 7d 03 00-8d 41 0c c7 41 04 fd 44 ff 55 89 39 c6 44 39 ff-fe 83 c4 0c 5b 5e 5f 5d ss:esp=b4 7d 03 00 29 00 00 00-00 10 00 00 00 00 00 00 83 57 02 00 02 00 00 00-a0 67 08 00 98 1c 02 00 BTX halted Any clue? Regarding cvsweb nothing changed recently, and I had net4501 boxes pxebooting fine with FreeBSD 5.3. Thanks for any help, -Harry pgpl6JElkfYOu.pgp Description: PGP signature
Re: BTX failure [Was: Re: pxeboot problems with BETA2]
Am Mittwoch, 17. August 2005 21:29 CEST schrieb John Baldwin: On Wednesday 17 August 2005 10:43 am, Emanuel Strobl wrote: [*schnip*] Relocating the loader and the BTX Starting the BTX loader int=0006 err= efl=00010202 eip=00023c21 eax= ebx=000384e0 ecx=000384e0 edx=0001 esi=1000 edi=0029 ebp=00086770 esp=00086758 cs=002b ds=0033 es=0033fs=0033 gs=0033 ss=0033 cs:eip=0f 4f c2 a3 c8 7d 03 00-8d 41 0c c7 41 04 fd 44 ff 55 89 39 c6 44 39 ff-fe 83 c4 0c 5b 5e 5f 5d ss:esp=b4 7d 03 00 29 00 00 00-00 10 00 00 00 00 00 00 83 57 02 00 02 00 00 00-a0 67 08 00 98 1c 02 00 BTX halted Any clue? Regarding cvsweb nothing changed recently, and I had net4501 boxes pxebooting fine with FreeBSD 5.3. Hmm. Int 6 is an invalid opcode exception: 0F4FC2cmovg eax,edx 0003 A3C87D0300mov [0x37dc8],eax 0008 8D410Clea eax,[ecx+0xc] 000B C74104FD44FF55mov dword [ecx+0x4],0x55ff44fd 0012 8939 mov [ecx],edi 0014 C64439FFFEmov byte [ecx+edi-0x1],0xfe 0019 83C40Cadd esp,byte +0xc 001C 5Bpop ebx 001D 5Epop esi 001E 5Fpop edi 001F 5Dpop ebp I'm guessing that there's been a stack overflow or some such. Your eip is in the loader. You can try using the loader.sym from your loader binary to look up that eip address. In the loader here on my laptop it's in the write function: Thanks for your attention! It's late here, I'll try to understand and see what I can do tomorrow. Just for info, simply copying pxeboot from a 5.3-release (also real verified with 5.2.1 no 5.4 so far) DVD works. Bisides that I need sio support in pxeldr so I have to compile it my own. And of course I'd love to have the new comspeed config option :) % nm /usr/obj/usr/src/sys/boot/i386/loader/loader.sym | sort ... 00023b9c T readdirfd 00023c14 T write 00023d18 T lseek If you want to be able to use gdb, then rebuild libstand with debugging (make DEBUG_FLAGS=-g) and rebuild all of /sys/boot with debugging (make DEBUG_FLAGS=-g). You can then use /usr/obj/usr/src/sys/boot/i386/pxeldr/pxeboot for your pxeboot and you can run gdb on /usr/obj/usr/src/sys/boot/i386/loader/loader.sym and you can do listings of the addresses for eip, etc. Expect to here from me the next 48 hours, tommorow I'm too busy as I could just see :( Thanks again, -Harry pgpzBtA0HvYVp.pgp Description: PGP signature
pxeboot problems with BETA2
Hello, I just wanted to ask if somebody had success with providing pxe boot service under 6-BETA2. I have two clients, one NET4501 wich just reboots after fetching pxeldr via TFTP and a Laptop which just hangs when NFS-loading kernel. I'm about to investigate further, but maybe someone can confirm that in general PXE booting with BETA2 is working... Or not... Thanks, -Harry pgpQYJVX1MOKy.pgp Description: PGP signature
Soekris 1.28 pxeboot problem [Was: Re: pxeboot problems with BETA2]
Am Dienstag, 16. August 2005 19:52 CEST schrieb Brooks Davis: On Tue, Aug 16, 2005 at 02:05:08PM +0200, Emanuel Strobl wrote: Hello, I just wanted to ask if somebody had success with providing pxe boot service under 6-BETA2. I have two clients, one NET4501 wich just reboots after fetching pxeldr via TFTP and a Laptop which just hangs when NFS-loading kernel. I'm about to investigate further, but maybe someone can confirm that in general PXE booting with BETA2 is working... Or not... I'm PXE booting systems with RELENG_6 as of 7/27. I'll probably do an update some time this week. Thanks for the info, I found that the problem is my NET4501 (soekris). Unfortunately my Laptop also seems to have broken PXE code, I got another box booting fine. Any experiences with a net4501 and BIOS versions higher than 1.24? Like mentioned, the box gets DHCP info, loads pxeboot and after this message immediately reboots: CLIENT MAC ADDR: 00 00 24 C0 33 70 CLIENT IP: 172.21.1.248 MASK: 255.255.0.0 DHCP IP: 172.21.0.1 GATEWAY IP: 172.21.0.1 PXE Loader 1.00 Building the boot loader arguments Relocating the loader and the BTX Starting the BTX loader Thanks a lot, -Harry pgp9JzPn9UqIm.pgp Description: PGP signature
Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
Am Mittwoch, 10. August 2005 19:48 CEST schrieb Unix: O. Hartmann wrote: Mike Jakubik wrote: On Wed, August 10, 2005 6:37 am, Dmitry Mityugov said: There are Maxtor MaXLine II and III, and perhaps several other models, that are supposed to work 24/7. Right, i have a dead 250GB Maxline Plus II drive on my desk, only after about 1.5 years. At least its still on warranty. On the other hand: In the department for physics of the athmosphere, where I built six years ago a server for meteorological data, a RAID-5 with 4 older IBM U160 SCSI discs still works - 24/7. Never had a problem! I still own old 1-2 GB old SCSI disks and these are still working, I also had an old 500mb SCSI disk that was in an old Mac that also worked but I trashed it since it was that old and no longer of use... I have an old 700 MB WD IDE drive that still works fine and has about 6 years 24/7 survived. And I also had a 2000$ 73G SCSI IBM drive that lasted for about 5 monthas and was that damadged that Convar sent it back without one byte recovered! And I don't want to remember the 80GB WD drive that lasted for 2 months.. Please, don't discuss about SCSI/ATA reliability, there are bad designed/produced drives and there are good ones. You can't tell before, only experience counts. I can say only good things about Seagates Barracuda 7200.8 drives for example. Some dozends are running for two years without _any_ single drive failed. Also the Samsung (p)ATA drives are still running without any single failure. And WDs once were perfect drices, but they also produced crap. So you can't even be sure by vendor! -Harry P.S.: I'm planning to bring up a FreeBSD site which reflects hardware compatibility experiences as well as long term experiences. I'll be back if I have more... pgpO99dRlvrUu.pgp Description: PGP signature
Re: Quality of FreeBSD
Am Donnerstag, 21. Juli 2005 22:06 CEST schrieb Matthias Buelow: [EMAIL PROTECTED] writes: My main problem, and to others after seeing the question from times to times, is to know which is a good (not necessarly the best) hardware to run FreeBSD on? When I buy a new motherboard, which chipset to choose/avoid, which controllers ? Maybe some website like it is being done for notebooks (with Linux/FreeBSD support) would be in order. I'm thinking about something like http://www.linux-laptop.net/, only for FreeBSD and all kinds of machines, not just notebooks. (Or, if some collaboration would be ok, for *BSD in general, with people posting experience from NetBSD, OpenBSD, Dragonfly, even Darwin aswell. That way one could also compare support for hardware and see what problems the individual systems have.) Make it a Wiki, or something similar, where people can freely post experiences they have with their hardware. That could be whole machines (Dell model xxx desktop, IBM yyy laptop, HP zzz server) aswell as components (Asus blah motherboard, 3Com wlan card model foobar, etc.) and make the thing searchable, and perhaps allow one to post comments on entries (easy with a Wiki). That way people can quickly search review hardware, awell as test suggested workarounds by the posters, without having to google for obscured mailing list entries, or problem reports. Well, there are numerous great FreeBSD sites out there which assist in such question, but I also like the idea of a purely hardware database site. If nobody want's to extend his site I'd offer to start a new one, I have spare capacity in both, my servers (if they go online, in some days I hope) and my leased line, so I'd be glad to contribute something. If anybody with wiki-experience wants to step in, you're welcome, I'm not the big webmaster... Maybe Eric Anderson wants to contribute his bsdhardware.org domain, or we could name it hardware.freebsd.org I'll be back when I have something online. Best regards, -Harry pgpkZbIH4xWEY.pgp Description: PGP signature
cua*x naming? [Was: Re: FreeBSD 6.0-BETA1 Available]
Am Sonntag, 17. Juli 2005 21:12 CEST schrieb Robert Watson: (2) /dev/cuaa* has been renamed to /dev/cuad* I saw that cuaa got cuad and ucom0 got cuaU0. Now what is the meaning of cua? tty AFAIK is TeleTYpe... Thanks, -Harry pgp8dSThJXdRN.pgp Description: PGP signature
Re: FreeBSD 6.0-BETA1 Available
Am Freitag, 15. Juli 2005 16:58 CEST schrieb Marc G. Fournier: And, for the stupid question of the day ... how long before 5.x is no longer supported? I'm just about to deploy a new server, and was *going* to go with 5.x, but would I be better just skipping 5.x altogether? Or are there such drastic changes in 6.x that doing so at this time wouldn't be prudent? To post my opinion to the last part of the question: I'm also deploying new servers and I'll take RELENG_6 since there are so many improovements (nullfs in jails etc.) and 6-current has been pretty stable for me on my UP workstation with all kinds of new stuff enabled (ULE PREEMPTION), so I guess I won't see more troubles than with 5.4, I think less :) -Harry On Fri, 15 Jul 2005, Scott Long wrote: Announcement The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 6.0-BETA1, which marks the beginning of the FreeBSD 6.0 Release Cycle. FreeBSD 6.0 will be a much less dramatic step from the FreeBSD 5 branch than the FreeBSD 5 branch was from FreeBSD 4. Much of the work that has gone into 6.0 development has focused on polishing and improving the work from 5.x These changes include streamlining direct device access in the kernel, providing a multi-threaded SMP-safe UFS/VFS filesystem layer, implementing WPA and Host-AP 802.11 features, as well as countless bugfixes and device driver improvements. Major updates and improvements have been made to ACPI power and thermal management, ATA, and many aspects of the network infrastructure. 32bit application support for AMD64 is also greatly improved, as is compatiblity with certain Athlon64 motherboards. This release is also the first to feature experimental PowerPC support for the Macintosh G3 and G4 platforms. This BETA1 release is in the same basic format as the Monthly Snapshots. For most of the architectures only the ISO images are available though the FTP install tree is available for a couple of the architectures. We encourage people to help with testing so any final bugs can be identified and worked out. Availability of ISO images is given below. If you have an older system you want to update using the normal CVS/cvsup source based upgrade the branch tag to use is RELENG_6 (though that will change for the Release Candidates later). Problem reports can be submitted using the send-pr(1) command. The list of open issues and things still being worked on are on the todo list: http://www.freebsd.org/releases/6.0R/todo.html Since this is the first release of a new branch we only have a rough idea for some of the dates. The current rough schedule is available but most dates are still listed as TBD - To Be Determined: http://www.freebsd.org/releases/6.0R/schedule.html Known Issues For the PowerPC architecture /etc/fstab isn't written out properly, so the first boot throws you into the mountroot prompt. You will need to manually enter where the root partition is and fix /etc/fstab. Also the GEM driver is listed as 'unknown' in the network config dialog. For all architectures a kernel rebuild might be needed to get some FreeBSD 5 applications to run. Add options COMPAT_FREEBSD5 to the kernel configuration file if you have problems with FreeBSD 5 executables. Availability The BETA1 ISOs and FTP support are available on most of the FreeBSD Mirror sites. A list of the mirror sites is available here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp. html The MD5s are: MD5 (6.0-BETA1-alpha-bootonly.iso) = eabda0a086e5492fe43626ce5be1d7e1 MD5 (6.0-BETA1-alpha-disc1.iso) = d7fe900bb3d5f259cc3cc565c4f303e4 MD5 (6.0-BETA1-amd64-bootonly.iso) = 9b04cb2f68300071c717f4aa4220bdac MD5 (6.0-BETA1-amd64-disc1.iso) = cb0f21feaf8b7dd9621f82a8157f6ed8 MD5 (6.0-BETA1-amd64-disc2.iso) = 84d40bc291a9ed5cd69dfa717445eeb5 MD5 (6.0-BETA1-i386-bootonly.iso) = 38e0b202ee7d279bae002b883f7074ec MD5 (6.0-BETA1-i386-disc1.iso) = b2baa8c18d4637ef02822a0da6717408 MD5 (6.0-BETA1-i386-disc2.iso) = 2b151a3cea8843d322c75ff76779ffcf MD5 (6.0-BETA1-ia64-bootonly.iso) = 97800ec7d4b29927a8e66a2b53e987fb MD5 (6.0-BETA1-ia64-disc1.iso) = 7d29cd9317997136507078971762a0d8 MD5 (6.0-BETA1-ia64-livefs.iso) = 6ff974e60a3964cf16fcec05925c14e9 MD5 (6.0-BETA1-pc98-disc1.iso) = 40a3134cce89bd5f7033d8b9181edf91 MD5 (6.0-BETA1-powerpc-bootonly.iso) = 2f64974e9bd5adcf813f5d35ff742443 MD5 (6.0-BETA1-powerpc-disc1.iso) = b2562c38414ff4866f5ed8b3a38683c8 MD5 (6.0-BETA1-sparc64-bootonly.iso) = ae9610aeb1169d2cc649628606014441 MD5 (6.0-BETA1-sparc64-disc1.iso) = af21752630b13cf60c9498fbf7f793b6 MD5 (6.0-BETA1-sparc64-disc2.iso) = 3241af814bfe93a97707c7a964c57718 Thanks to Ken Smith, Marcel Moolenaar, Wilko Bulte, and Takahashi Yoshihiro, and Peter
Re: FreeBSD 6.0-BETA1 Available
Am Freitag, 15. Juli 2005 22:12 CEST schrieb Eirik Øverby: On Jul 15, 2005, at 5:10 PM, Emanuel Strobl wrote: Am Freitag, 15. Juli 2005 16:58 CEST schrieb Marc G. Fournier: And, for the stupid question of the day ... how long before 5.x is no longer supported? I'm just about to deploy a new server, and was *going* to go with 5.x, but would I be better just skipping 5.x altogether? Or are there such drastic changes in 6.x that doing so at this time wouldn't be prudent? To post my opinion to the last part of the question: I'm also deploying new servers and I'll take RELENG_6 since there are so many improovements (nullfs in jails etc.) and 6-current has been pretty stable for me on my Hoi, what's changed wrt jails? And nullfs? I haven't been following the news as closely as I perhaps should, but I feel that the jail functionality doesn't get half as much attention in release notes as it should... Porting my jail-related tools to 5.x from 4.x was painful, but enjoyable when I was done. How does 6.x look? I'm not the developer guy so I can't tell you anything authoritative but I know that there has been an awful perfomance degradation when mounting nullfs-filesystems into a jail under RELENG_5, espacially noticable with apache! I just know that Jeff Roberson committed incredible lots of vm/vfs changes, perhaps this also solved the md performance problem, at least the nullfs problem was solved! Jail management was also a lot improved, but that was back in 5.4 I think. I'll do some extensive Jail test the next view weeks, I fear there are oddities left (I had plenty of them with milter-sender and apache's mod_proxy for example under 5.4) -Harry /Eirik UP workstation with all kinds of new stuff enabled (ULE PREEMPTION), so I guess I won't see more troubles than with 5.4, I think less :) -Harry On Fri, 15 Jul 2005, Scott Long wrote: Announcement The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 6.0-BETA1, which marks the beginning of the FreeBSD 6.0 Release Cycle. FreeBSD 6.0 will be a much less dramatic step from the FreeBSD 5 branch than the FreeBSD 5 branch was from FreeBSD 4. Much of the work that has gone into 6.0 development has focused on polishing and improving the work from 5.x These changes include streamlining direct device access in the kernel, providing a multi-threaded SMP-safe UFS/VFS filesystem layer, implementing WPA and Host-AP 802.11 features, as well as countless bugfixes and device driver improvements. Major updates and improvements have been made to ACPI power and thermal management, ATA, and many aspects of the network infrastructure. 32bit application support for AMD64 is also greatly improved, as is compatiblity with certain Athlon64 motherboards. This release is also the first to feature experimental PowerPC support for the Macintosh G3 and G4 platforms. This BETA1 release is in the same basic format as the Monthly Snapshots. For most of the architectures only the ISO images are available though the FTP install tree is available for a couple of the architectures. We encourage people to help with testing so any final bugs can be identified and worked out. Availability of ISO images is given below. If you have an older system you want to update using the normal CVS/cvsup source based upgrade the branch tag to use is RELENG_6 (though that will change for the Release Candidates later). Problem reports can be submitted using the send-pr(1) command. The list of open issues and things still being worked on are on the todo list: http://www.freebsd.org/releases/6.0R/todo.html Since this is the first release of a new branch we only have a rough idea for some of the dates. The current rough schedule is available but most dates are still listed as TBD - To Be Determined: http://www.freebsd.org/releases/6.0R/schedule.html Known Issues For the PowerPC architecture /etc/fstab isn't written out properly, so the first boot throws you into the mountroot prompt. You will need to manually enter where the root partition is and fix /etc/fstab. Also the GEM driver is listed as 'unknown' in the network config dialog. For all architectures a kernel rebuild might be needed to get some FreeBSD 5 applications to run. Add options COMPAT_FREEBSD5 to the kernel configuration file if you have problems with FreeBSD 5 executables. Availability The BETA1 ISOs and FTP support are available on most of the FreeBSD Mirror sites. A list of the mirror sites is available here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors- ftp. html The MD5s are: MD5 (6.0-BETA1-alpha-bootonly.iso) = eabda0a086e5492fe43626ce5be1d7e1 MD5 (6.0-BETA1-alpha-disc1.iso) = d7fe900bb3d5f259cc3cc565c4f303e4 MD5
Re: gmirror, sparc and SCSI problems
Am Montag, 11. Juli 2005 15:49 CEST schrieb Chris Hodgins: On 7/10/05, Johannes Verwijnen [EMAIL PROTECTED] wrote: On Jul 9, 2005, at 19:36, Chris Hodgins wrote: It seems that gmirror does not give us any partitions. A listing of the mirror directory shows only the gm0 node even though da0 is partitioned. When mounting the mirror it seems that /dev/mirror/gm0 only represents the root partition. How can we get the mirror to recognise the other partitions? I remember (vaguely)) this kind of problem, where when trying to mirror a whole disk, you'd only get the first slice. Have you tried mirroring the slices (da0s1 etc) separately? -- duvin Firstly thanks for all the suggestions. We managed to build the mirrors by using the suggestion above mirroring the slices separately. Unfortunetly, although the mirrors were created properly the filesystems are constantly suffering from inconsistencies and fsck actually appears to be segfaulting. I can't help you with the fsck segfault, nor can I tell too much about SPARC but I saw that you use a gmirror for swap. Do you also have the problems when you use shutdown -r now instead of reeboot?. If I remember correctly 5.4 shouldn't need swapoff=YES to be set in /etc/rc.conf but maybe the reboot issue still exists. -Harry We have decided not to pursue this any further for the moment, however we are prepared to allow access to the machine should anyone wish to try and sort out this incompatibility with gmirror and sparc. Included below is a brief logfile of a reboot after fsck'ing all of the mirrored partitions. # reboot Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done No buffers busy after final sync Uptime: 5m23s GEOM_MIRROR: Device gm0e: provider mirror/gm0e destroyed. GEOM_MIRROR: Device gm0e destroyed. GEOM_MIRROR: Device gm0d: provider mirror/gm0d destroyed. GEOM_MIRROR: Device gm0d destroyed. GEOM_MIRROR: Device gm0b: provider mirror/gm0b destroyed. GEOM_MIRROR: Device gm0b destroyed. GEOM_MIRROR: Device gm0a: provider mirror/gm0a destroyed. GEOM_MIRROR: Device gm0a destroyed. Rebooting... Resetti LOM event: +38d+3h37m11s host reset ng ... \u Processor Speed = 648 MHz Baud rate is 9600 8 Data bits, 1 stop bits, no parity (configured from lom) Firmware CORE Sun Microsystems, Inc. @(#) core 1.0.12 2002/01/08 13:00 Software Power ON Verifying NVRAM...Done Bootmode is 0 [New I2C DIMM address] MCR0 = 57b2ce06 MCR1 = 80008000 MCR2 = cf3000ff MCR3 = a0cf Ecache Size = 512 KB Clearing E$ Tags Done Clearing I/D TLBs Done Probing memory Done MEMBASE=0x4000 MEMSIZE=0x2000 Clearing memory...Done Turning ON MMUs Done Copy ROM to RAM (170040 bytes) Done Orig PC=0x1fff0007e44 New PC=0xf0f07e9c Processor Speed=648MHz Looking for Dropin FVM ... found Decompressing Client Done Transferring control to Client... ttya initialized Reset Control: BXIR:0 BPOR:0 SXIR:0 SPOR:1 POR:0 Probing upa at 1f,0 pci pci pci Probing upa at 0,0 SUNW,UltraSPARC-IIe SUNW,UltraSPARC-IIe (512 Kb) Loading Support Packages: kbd-translator Loading onboard drivers: ebus flashprom eeprom idprom SUNW,lomh Probing /[EMAIL PROTECTED],1 Device 3 pmu i2c temperature dimm dimm i2c-nvram idprom motherboard-fru fan-control lomp Sun Fire V120 (UltraSPARC-IIe 648MHz), No Keyboard OpenBoot 4.0, 1024 MB memory installed, Serial #53833010. Ethernet address 0:3:ba:35:6d:32, Host ID: 83356d32. Executing last command: boot /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a Boot device: /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a File and args: FreeBSD/sparc64 boot block Boot path: /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a Boot loader: /boot/loader Console: Open Firmware console FreeBSD/sparc64 bootstrap loader, Revision 1.0 ([EMAIL PROTECTED], Sun May 8 07:16:15 UTC 2005) bootpath=/[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x3d8908+0x47c78 syms=[0x8+0x50b80+0x8+0x45260] /boot/kernel/geom_mirror.ko text=0x21558 data=0x5b0+0x18 syms=[0x8+0x1638+0x8+0x10da] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... nothing to autoload yet. jumping to kernel entry at 0xc004. Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE #0: Sun May 8 22:21:34 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter tick frequency 64800 Hz quality
Re: After Install -- Where is FreeBSD?
Am Montag, 20. Juni 2005 19:36 schrieb Benjamin Sher: Dear friends: I just installed FreeBSD 5.4. I have two primary HD: the first disk holds WinXP, the second disk now has FreeBSD. Well, the good news is that my first install of FreeBSD went perfectly. I selected ALL for installation of ports and packages so it took a good hour to install everything from my two CD's. And some of the packages encountered an error and could not be installed (they told me to look in the debugger for details). Windows XP came through completely unscathed and in perfect working order on my first primary HD. All that's missing now is FreeBSD. After completing my install, I exited. FreeBSD exited normally, then rebooted. But no sign of FreeBSD. Instead, Windows came up. I do recall choosing to have a boot manager but never actually saw the screen and boot-up options. So, I went back into Free BSD by switching back to the CD in my Bios, but that's as far as I dare go on my own. What should I do? Am I missing something? You can define the first boot disk in your BIOS (usually) but that's not convenient. You need a bootmanager. WinXP has one, you can dump the loader from the BSD slice and copy it into a location where the XP loader can read it. Or you can use the FreeBSD BootEays manager, see boot0cfg. I recommend using GAG (http://gag.sourceforge.net/) but grub and similar should also work. -Harry P.S.: There's freebsd-questions@ for that kind of questions ;) Thank you all so much. Benjamin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] pgpykhYTXLl2T.pgp Description: PGP signature
general libthread questions [Was: Re: FreeBSD MySQL still WAY slower than Linux]
Am Samstag, 11. Juni 2005 10:00 schrieb Robert Watson: On Fri, 10 Jun 2005, Steve Roome wrote: [...] - Thread package. In 5.x, you get process scope threads by default, but it turns out MySQL is tuned for system scope threads, and this is particularly visible in the supersmack benchmark, which competes many client processes against a few server threads. I'm not sure what the condition is of libthr on 5.x, but you could give it a spin. In 6.x, libthr has been largely rewritten and is a great deal faster. I think there's a compile-time option to make libpthread use system scope threads but the details ellude me. The Linuxthreads library may well provide a substantial improvement -- not as good for MySQL as the 6.x libthr, but perhaps much more appropriate than libpthread. OT, but can someone please gvie me a link which describes the pthread and lib_thr stuff. And how would I tell a port to compile with a specific threading library (if my understanding is correct)? Maybe one can name typical applications for specific threading libraries? Thanks a lot, -Harry pgpxccEoGLn7W.pgp Description: PGP signature
Re: FreeBSD 5.4-RELEASE is now available
Am Montag, 9. Mai 2005 23:04 schrieb Ken Smith: The Release Engineering Team is happy to announce the availability of FreeBSD 5.4-RELEASE, the latest release of the FreeBSD Stable development branch. Since FreeBSD 5.3-RELEASE in November 2004 we have made many improvements in functionality, stability, performance, and device driver support for some hardware, as well as dealt with known security issues and made many bugfixes. Thanks a lot to all those hard working guys, 5.4 is a really nice release! -Mano pgpiKSiPcGTdN.pgp Description: PGP signature
Re: Current status of nullfs and/or unionfs?
Am Donnerstag, 5. Mai 2005 14:06 schrieb Eirik Øverby: Hi all, I'm struggling with some hosting environments where I am managing a large number of jails (100) spread over about a dozen servers. I am starting to see disk space as a real problem, especially given that each physical box needs to be autonomous - i.e. I can't rely on any external storage, and I am limited to 1U and 2U servers. The solution, or at least parts of it, would be to have certain parts of the jail filesystems mounted in via nullfs (acceptable solution) or unionfs (ideal solution). However, ever since FreeBSD 4.10 this has been a major problem, as both filesystems started exhibiting major stability and data integrity issues. Before I start playing with this again, I'd like to know if any work has been done on either of these in 5.x. Specifically, I'm currently running 5.3-p6 or newer on all the systems, and as of yesterday I've been using 5.4-prerelease (cvsup) on a couple of test systems. What can I expect to see when trying nullfs and/or unionfs today? Has anything changed? Do I have even a remote chance of making it work - and if it doesn't work, what are my chances of anyone having time or energy to look into it? I'm an admin only, no coder, otherwise I'd be happy to look into it myself. Nullfs is as far as I can tell stable on 5.4 but the performance problem together with jails is not solved in 5.4, only in 6. And like Jeff said, it's not sure that it gets MFCd since lot of VFS changes are requred. -Harry Thanks, /Eirik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] pgpvUs7DoDcQ9.pgp Description: PGP signature
HAS_CONFIGURE error?
Hello, from the Mk/bsd.port.mk I read:
# CONFIGURE_ARGS
# - Pass these args to configure if ${HAS_CONFIGURE} is set.
# Default: --prefix=${PREFIX} ${CONFIGURE_TARGET} if
# GNU_CONFIGURE is set, CC=${CC} CCFLAGS=${CFLAGS}
# PREFIX=${PREFIX} INSTALLPRIVLIB=${PREFIX}/lib
# INSTALLARCHLIB=${PREFIX}/lib if PERL_CONFIGURE is set,
# empty otherwise.
The first sentence isn't true on 5.4-RC3. If I define HAS_CONFIGURE=yes
without CONFIGURE_ENV=--prefix=${PREFIX} the configure script doesn't get
--prefix set right.
Is the description outdated or is this behaviour not intended?
Thanks,
-Harry
pgpQVlIdVFw1I.pgp
Description: PGP signature
Re: HAS_CONFIGURE error?
Am Dienstag, 26. April 2005 19:31 schrieb Emanuel Strobl:
Hello, from the Mk/bsd.port.mk I read:
# CONFIGURE_ARGS
# - Pass these args to configure if ${HAS_CONFIGURE} is set.
# Default: --prefix=${PREFIX} ${CONFIGURE_TARGET} if
# GNU_CONFIGURE is set, CC=${CC} CCFLAGS=${CFLAGS}
# PREFIX=${PREFIX} INSTALLPRIVLIB=${PREFIX}/lib
# INSTALLARCHLIB=${PREFIX}/lib if PERL_CONFIGURE is set,
# empty otherwise.
The first sentence isn't true on 5.4-RC3. If I define HAS_CONFIGURE=yes
without CONFIGURE_ENV=--prefix=${PREFIX} the configure script doesn't get
--prefix set right.
Of course I meant the second sentence and CONFIGURE_ARGS, not the first and
CONFIGURE_ENV! Sorry!
Is the description outdated or is this behaviour not intended?
Thanks,
-Harry
pgp34ynAVYVQZ.pgp
Description: PGP signature
'cut' and newline problem
Dear all, today I had problems with cut (tset -I -S -Q \?$term | cut -d ' ' -f1) on 5.4-RC3 and after googling for the error cut: stdin: Illegal byte sequence I found that someone already reported [1] that cut kind of misbehaves from 5.3-RC on. Is this still a problem? Thanks, -Harry [1] http://lists.freebsd.org/pipermail/freebsd-current/2004-November/042418.html pgpvYDwbs1Pmj.pgp Description: PGP signature
Re: 5.4-prerelease - hanging under load
Am Sonntag, 3. April 2005 18:07 schrieb Pierre-Luc Drouin: Christian Brueffer wrote: On Sat, Apr 02, 2005 at 09:16:48PM -0500, Pierre-Luc Drouin wrote: Since I upgraded from 5.3-stable to 5.4-prerelease, I've noticed that my computer is hanging badly under load. I've a P4 2.53 GHz without hyperthreading (no SMP). I use the same kernel configurations than before. Now when I compile a port for example, the mouse pointer hangs in Fluxbox and Mozilla takes forever (meaning ~5 sec) to refresh the screen. Even vi hangs. I do not see any warning/error message. Is it a known problem with 5.4? I have experienced something similar, putting the following into rc.conf worked for me: performance_cpu_freq=HIGH - Christian Yes, this seams to fix it. I didn't know that I had a laptop? :) Huh? I thought by default it is HIGH, but it would also explain the experiences in the thread cpufreq related RELENG_5 regression (http://www.freebsd.org/cgi/getmsg.cgi?fetch=389949+393881+/usr/local/www/db/text/2005/freebsd-stable/20050327.freebsd-stable) -Harry ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] pgpIA4BhxcUBB.pgp Description: PGP signature
Re: cpufreq related RELENG_5 regression?
Am Mittwoch, 23. März 2005 23:37 schrieb Danny Howard: Christian Brueffer wrote: [...] When I try to transfer a file from outside the LAN to box C, which resides inside the LAN, the movie on box B starts to stagger. [...] Can anyone confirm this? Anecdotally . . . I upgraded my Pentium-M laptop on Monday or Tuesday to the latest ... I have since noted: - It seems to run cooler under load. (Peaks at 140F instead of 145F) Lower temperatures with the same (full) load indicate that the cpu has idle cycles. Which explains the jerks and staggers... Not really an improvement IMHO, but I don't understand the code, only some hardware basics. -Harry - Watching TV occasionally has jerks, where the video will briefly lag, where it has not had jerks before. It SEEMS like maybe the system is running a touch more conservatively. But, the difference is such that, aside from occasionally jerky video, I don't really notice. -danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] pgpWJ7SyXctpK.pgp Description: PGP signature
Re: need ISO-image for a new machine install
Am Freitag, 18. März 2005 02:13 schrieb Mikhail Teterin: Hello! Is there a place, from where I can download a reasonably fresh 5.4-PRERELEASE install (or mini-install) .iso image for amd64? Thanks! Unfortunately I can't offer you a special one (usually I have several arch optimized -STABLE isos but since it's release time I skiped them) but this should be fine: http://snapshots.se.freebsd.org/i386/ISO-IMAGES/5.4-PRERELEASE-20050317-SESNAP.iso Unfortunately there is no mini-inst anymore since install and fixit CD is combined now. You have to download the whole 780MB. -Harry -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] pgp9sBlHfhGB8.pgp Description: PGP signature
Re: need ISO-image for a new machine install
Am Freitag, 18. März 2005 04:18 schrieb Emanuel Strobl: Am Freitag, 18. März 2005 02:13 schrieb Mikhail Teterin: Hello! Is there a place, from where I can download a reasonably fresh 5.4-PRERELEASE install (or mini-install) .iso image for amd64? Thanks! Unfortunately I can't offer you a special one (usually I have several arch optimized -STABLE isos but since it's release time I skiped them) but this should be fine: http://snapshots.se.freebsd.org/i386/ISO-IMAGES/5.4-PRERELEASE-20050317-SES NAP.iso Sorry for the noise, haven't noticed the amd64 :( -Harry Unfortunately there is no mini-inst anymore since install and fixit CD is combined now. You have to download the whole 780MB. -Harry -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] pgpHqUFAVpwde.pgp Description: PGP signature
Return-icmp doesn't work [Was: Re: Recent panics caused by pf]
Am Montag, 21. Februar 2005 19:24 schrieb Max Laier: On Monday 21 February 2005 15:57, Harald Schmalzbauer wrote: Am Sonntag, 20. Februar 2005 19:10 schrieb Max Laier: /me slaps self ... [...] I tested your patch against RELENG_5 and the panic with pfctl -Fall seems to be solved. But I have another problem with renamed interfaces and pf: The following rule can't be loaded (error: routeto: unknown interface SDSL) pass in on SDSL reply-to (SDSL $sdsl_gw) proto tcp from any to $mta port 25 [...] And there are more oddities with pf and FreeBSD: block return doesn't work. At least for TCP connections I don't get a reset back instead it times out. Also return-icmp (13) doesn't work. Hum?!? ... Are you sure about this? I am pretty confident that it works. I'll have to test to make sure ... later that week/next week. Keep me posted in case you find something. I'm on the firewall again and verified that block return works for tcp-rst, but not for return-icmp (with or without code), it seems packets just get droped, regardless for which protocol (tested UDP, ICMP, TCP). Then I have another problem which may be a design problem. I am multihomed and have several pass reply-to rules. So far things are working fine but block return doesn't! Of course, the return gets over the default route, so what I needed is a block return route-to or something like that. Do you know any detour how this could be achieved? Thanks, -Harry Thanks, -Harry (P.S.: Emanuel and Harry are the same persons (me) the gmx address is just a fake identity for mailing lists) okay ... you see us perplexed ;) pgpNsoiwADWCM.pgp Description: PGP signature
Re: Return-icmp doesn't work [Was: Re: Recent panics caused by pf]
Am Freitag, 11. März 2005 13:10 schrieb Emanuel Strobl: I'm on the firewall again and verified that block return works for tcp-rst, but not for return-icmp (with or without code), it seems packets just get droped, regardless for which protocol (tested UDP, ICMP, TCP). Sorry for the noise, it's my mistake, ping doesn't show me the error message. I think I can remember that the last time I created/tested a ruleset (with 4.6) I got detaild error messages like telnet: connect to address 82.135.28.195: Destination Host Unreachable but now I just get telnet: connect to address 82.135.28.195: Connection refused without the error report. Is it possible that in former times these ICMP error messages were printed on the console which now the kernel doesn't anymore? Then I have another problem which may be a design problem. I am multihomed and have several pass reply-to rules. So far things are working fine but block return doesn't! Of course, the return gets over the default route, so what I needed is a block return route-to or something like that. Do you know any detour how this could be achieved? This problem is still unsolved :( Thnaks, -Harry Thanks, -Harry Thanks, -Harry (P.S.: Emanuel and Harry are the same persons (me) the gmx address is just a fake identity for mailing lists) okay ... you see us perplexed ;) pgp6Gz1qLLLIP.pgp Description: PGP signature
Re: Return-icmp doesn't work [Was: Re: Recent panics caused by pf]
Am Freitag, 11. März 2005 14:52 schrieb Daniel Hartmeier: On Fri, Mar 11, 2005 at 01:50:47PM +0100, Emanuel Strobl wrote: Then I have another problem which may be a design problem. I am multihomed and have several pass reply-to rules. So far things are working fine but block return doesn't! Of course, the return gets over the default route, so what I needed is a block return route-to or something like that. Do you know any detour how this could be achieved? This problem is still unsolved :( The idea is that you can use reply-to on block rules for this purpose: block return-rst in on wi0 reply-to (wi0 10.1.1.1) inet proto tcp all This is valid syntax and pfctl loads the rule, but the functionality is not implemented in kernel yet, i.e. the reply-to option is simply ignored. Thanks, I tried a very similar rule and after that the box vanished. I went on location (the box paniced but didn't reboot) and installed a console-server so I can access the box from here and currently I'm baking a debug kernel. I'll notify you if I have a trace! Thnaks, -Harry The problem is that return-icmp uses the stack's icmp_error(), which doesn't take an argument to override a route lookup. And duplicating the function would be ugly due to its size. It's on the to-do list, but it's been sitting there for a while already. Daniel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] pgpOFMAbw1GRW.pgp Description: PGP signature
pf panic trace [Was: Re: Return-icmp doesn't work]
Am Freitag, 11. März 2005 16:19 schrieb Emanuel Strobl: Am Freitag, 11. März 2005 14:52 schrieb Daniel Hartmeier: block return-rst in on wi0 reply-to (wi0 10.1.1.1) inet proto tcp all This is valid syntax and pfctl loads the rule, but the functionality is not implemented in kernel yet, i.e. the reply-to option is simply ignored. Thanks, I tried a very similar rule and after that the box vanished. I went on location (the box paniced but didn't reboot) and installed a console-server so I can access the box from here and currently I'm baking a debug kernel. I'll notify you if I have a trace! Here's the original panic message (the non debug kernel) with 5.4-PRE one week old: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not pre instruction pointer = 0x8:0xc05ac722 stack pointer = 0x10:0xcc6919ac frame pointer = 0x10:0xcc6919e0 code segment= base 0x0, limit 0xf, type = DPL 0, pres 1, def32 1, gran processor eflags= interrupt enabled, resume, IO current process = 34 (swi1: net) trap number = 12 panic: page fault Uptime: 1d1h20m33s GEOM_MIRROR: Device web: provider mirror/web destroyed. GEOM_MIRROR: Device web destroyed. ... The machine didn't reboot! The following rule panickes the machine: block return-icmp(13) in on $SDSL route-to ($SDSL $sdsl_gw) from any to $sdsl_net Here's the trace from 5.4-PRE today: panic: m_copym, offset size of mbuf chain KDB: stack backtrace: panic(c076ab9a,c174d500,100,cc694a30,0) at panic+0x13c m_copym(c1621b00,5dc,5c8,1,14) at m_copym+0x1c7 ip_fragment(c1642010,cc694a74,5dc,6,f01) at ip_fragment+0x168 pf_route(cc694bf0,c1a10d20,1,c1585000,0) at pf_route+0x767 pf_test(1,c1585000,cc694bf0,0,c17554e0) at pf_test+0x7b1 pf_check_in(0,cc694bf0,c1585000,1,0) at pf_check_in+0x48 pfil_run_hooks(c07f3e60,cc694c9c,c1585000,1,0) at pfil_run_hooks+0x15b ip_input(c1621b00,0,c076e621,e6,c07f3f20) at ip_input+0x20f netisr_processqueue(cc694cd8,246,c07c8ee0,2,c1508d40) at netisr_processqueue+0x15 swi_net(0,0,c0762ddc,269,0) at swi_net+0x8d ithread_loop(c1526300,cc694d48,c0762bbd,30e,0) at ithread_loop+0x1ff fork_exit(c0560640,c1526300,cc694d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc694d7c, ebp = 0 --- If you need more info, on http://www.schmalzbauer.de/statics/phobos you can find dmesg and the whole pf.conf Thanks, -Harry Thnaks, -Harry The problem is that return-icmp uses the stack's icmp_error(), which doesn't take an argument to override a route lookup. And duplicating the function would be ugly due to its size. It's on the to-do list, but it's been sitting there for a while already. Daniel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0723nYhNno.pgp Description: PGP signature
gmirror w/ softupdates fsck problem
Hello, I have one box with several gmirror filesystems. When the box panics I always have to reconnect lost inodes and also inconsistent filesystems. I never had this problem with non gmirrored mountpoints. Also, the mirrored mountpoints are almost completely idel regarding writes. Here's an error I don't know how to solve: ** /dev/mirror/dns (NO WRITE) ** Last Mounted on /§DNS ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames MISSING '.' I=149 OWNER=root MODE=40700 SIZE=9216 MTIME=Feb 22 08:21 2005 DIR=? UNEXPECTED SOFT UPDATE INCONSISTENCY CANNOT FIX, FIRST ENTRY IN DIRECTORY CONTAINS #058295 UNEXPECTED SOFT UPDATE INCONSISTENCY MISSING '..' I=149 OWNER=root MODE=40700 SIZE=9216 MTIME=Feb 22 08:21 2005 DIR=/lost+found UNEXPECTED SOFT UPDATE INCONSISTENCY CANNOT FIX, SECOND ENTRY IN DIRECTORY CONTAINS #058296 UNEXPECTED SOFT UPDATE INCONSISTENCY ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 10092 files, 123147 used, 366123 free (5491 frags, 45079 blocks, 1.1% fragmentation) Does anybody know why this error can happen? And how do I solve the missing.? I thought softupdates guarantees that this cannot happen. Maybe it doesn't work in combination with gmirror? Thanks, -Harry pgp3iH3gB1GbN.pgp Description: PGP signature
Re: kernel trap 12 with interrupts disabled, 5.3-stable
Am Mittwoch, 9. März 2005 03:04 schrieb Pierre-Luc Drouin: I have updated a system from FreeBSD 4.10 to 5.3 (I did a fresh new installation from scatch). At the same time we put a new CPUs in there. [...] What could be the cause? The non-technical answer: FreeBSD 5.4 is in the release cycle with an upcoming 5.4 iso image. There were enormous efforts in improving FreeBSD 5.x, so if you already broke your system take the chance and get the new 5.4 system which probably fixes your problem. Next thing is that you won't see any benefit when enabling hyperthreading. It's strongly depending on the system's kind of load but almost everytime you'll see performance degradation. The system was very stable with FreeBSD 4.10 and only 2 CPUs (1 real and 1 virtual). When I've seen page faults in the past, it was caused by the RAM or the motherboard. Is it almost always the case? Does the fact to Maybe, but first you have to provide more information and make sure it frequently crashes at different points. Keep patience till anyone of the experts answers, in the meantime you can have a look at http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html for providing more information. -Mano add 2 new CPUs is more likely to reveal a RAM problem that was not known before? Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] pgpj8UOXRt76a.pgp Description: PGP signature
Re: Need really cheap IDE mirroring PCI controlled for FreebBSD 4.10
Am Samstag, 5. März 2005 02:06 schrieb David Magda: On Mar 3, 2005, at 19:20, Emanuel Strobl wrote: If you consider upgrading to 5.4 you can use any onboard chipset or cheap controller card with some geomclasses, namely g_mirror. It's fantastic and the only stateful mirror solution I know. And you can mirror only parts of your disk, or mirror across 3 drives aso. The power of geom :) This can be done with 4.x. From atacontrol(8): create Create a type ATA RAID. The type can be RAID0 (stripe), RAID1 This is not stateful! Nor does it allow to mirror parts of the disk (labels/GPT partitions). Also I can't imagen how to mirror across more then two disks. You can't compare those and there are several cases where ata-builtin RAID support fails on different controllers. Also you don't have the atacontrol addspare command on 4.x which makes its RAID1 function useless on anything but the promise controllers! And he was looking for cheap controllers which disqualifies the promise. (mirror), RAID0+1 or SPAN (JBOD). In case the RAID has a RAID0 [...] Vinum(8) is also available on 4.x. But vinum isn't statful too. And vinum doesn't provide g_gate for example. -Harry pgpfAlrW8ji6P.pgp Description: PGP signature
Re: Need really cheap IDE mirroring PCI controlled for FreebBSD 4.10
Am Donnerstag, 3. März 2005 10:23 schrieb Artem Kuchin: Gerald de la Pascua [EMAIL PROTECTED] wrote: we have had very good experiences with the basic 3ware cards, I would recommend them, easy to install, reliable, and good perfomance, in the uk they cost just over 100 pounds, so a similar price to two disks to plug into them. When a disk fails you would willingly pay many times this amount, 3ware controllers are one of the most expensive ones. I am sure there are good controllers which cost a lot less and work with freebsd. Do you know any? If you consider upgrading to 5.4 you can use any onboard chipset or cheap controller card with some geomclasses, namely g_mirror. It's fantastic and the only stateful mirror solution I know. And you can mirror only parts of your disk, or mirror across 3 drives aso. The power of geom :) -Harry Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] pgpMOieh3G8OP.pgp Description: PGP signature
-PRErelease and ACPI: no PRT entry for 0.1.INTA
Dear Hackers, on one remote machine I see the following error (RELENG_5 from this night): pcib0: no PRT entry for 0.1.INTA I have only ssh access and putting -v in /boot.config didn't help me getting a verbose dmesg. Anyway, I think it's caused by a bogus BIOS but I wanted to make sure having it reported. Last version was RELENG_5 from Nov. 5th and I also had a ACPI error but more detailed. Unfortunately I lost the output Thanks, -Harry pgpSeUfiQqBEy.pgp Description: PGP signature
Re: Merging phk's filedesc cleanup and lock pushdown.
Am Sonntag, 27. Februar 2005 03:51 schrieb Jeff Roberson: Fixed the build and merged this. Any stable users who can should test this. I'm very confident in it, but more eyes and users are better. I haven't really understood what filedesc code is and does, but accidentaly I have several boxes here which will act as a fileserver at some point but needn't to be stable for the next two weeks. What exactly should I test? -Harry Thanks, Jeff On Thu, 24 Feb 2005, Francois Tigeot wrote: On Thu, Feb 24, 2005 at 03:18:49AM -0500, Jeff Roberson wrote: I am going to MFC phk's filedesc related work in the next few days. This is required if I am ever to merge the vfs smp changes. I have a patch available at: http://www.chesapeake.net/~jroberson/fdesc.patch I'd appreciate it if anyone who can would test this. It has been running on current for 3-4 months, depending on the bit, but there's always a chance of a botched merge. World doesn't build with this patch: cc -O -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/usr.bin/fstat/fstat.c /usr/src/usr.bin/fstat/fstat.c: In function `dofiles': /usr/src/usr.bin/fstat/fstat.c:325: error: storage size of 'filed0' isn't known /usr/src/usr.bin/fstat/fstat.c:363: error: `NDFILE' undeclared (first use in this function) /usr/src/usr.bin/fstat/fstat.c:363: error: (Each undeclared identifier is reported only once /usr/src/usr.bin/fstat/fstat.c:363: error: for each function it appears in.) /usr/src/usr.bin/fstat/fstat.c:325: warning: unused variable `filed0' *** Error code 1 Stop in /usr/src/usr.bin/fstat. *** Error code 1 Stop in /usr/src/usr.bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. nice make buildworld 1209,00s user 251,75s system 78% cpu 31:04,65 total This machine is an amd64 5.3-STABLE host. The same sources build nicely without the patch. -- Francois Tigeot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] pgp6HgOziT7xy.pgp Description: PGP signature
Booting from GPT on i386 [Re: Hardcoding gmirror provider]
Am Mittwoch, 23. Februar 2005 11:24 schrieb Poul-Henning Kamp: + The c partition is a problem you have to address anyway (and it is + best addressed by removing the magicness of the c partition + altogether). [...] It is not going to be removed. We're going to wait for MBR to die. s/MBR/BSDlabel/ My servers boot from CF-Card so all my hard disks are GPT sliced only. Will it be possible to boot from GPT disks on i386(amd64)? Is anyone currently working on that?. That's what I'm really missing. Thanks, -Harry pgpJ2MtMetZEE.pgp Description: PGP signature
HZ in RELENG_5? tcp_subr.c related
Dear all, I read this commit message to RELENG_5: http://www.freebsd.org/cgi/getmsg.cgi?fetch=436074+438355+/usr/local/www/db/text/2005/cvs-all/20050206.cvs-all and commented out the HZ=1000 line in my kernel config so I use the default. But I see only 100 interrupts/sec on clk (with systat) so is it true that the default HZ has changed from 100 to 1000 in RELENG_5? Thanks, -Harry pgpRDXkmcPZYT.pgp Description: PGP signature
panic with ATAmkIII and atacontrol on RELENG_5
Hello, I'm running RELENG_5 with ATAmkIII and have the following panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc116 fault code = supervisor read, page not present instruction pointer = 0x8:0xc058b0a7 stack pointer = 0x10:0xcc6d3af4 frame pointer = 0x10:0xcc6d3b30 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 419 (atacontrol) [thread pid 419 tid 100052 ] Stopped at device_is_attached+0x7: cmpl$0x1,0x38(%eax) db trace Tracing pid 419 tid 100052 td 0xc158e320 device_is_attached(c07c1238,c4546101,c19f2800,3,c158e320) at device_is_attached+0x7 spec_ioctl(cc6d3b7c,1,c0768a46,30e,c07b7020) at spec_ioctl+0x98 vn_ioctl(c179f110,c4546101,c19f2800,c14dbd80,c158e320) at vn_ioctl+0xd1 ioctl(c158e320,cc6d3d14,c,431,3) at ioctl+0x159 syscall(2f,2f,2f,806157a,104) at syscall+0x137 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x8049e03, esp = 0xbfbfe9dc, ebp =0xbfbfeea4 --- -Harry pgp8qr6rINXx5.pgp Description: PGP signature
Re: 5.3-Stable network issue
Am Donnerstag, 10. Februar 2005 11:00 schrieb Martin Minkus: I seem to have been having a rather strange networking issue in FreeBSD 5.3-Stable (it started happening immediately after 5.2.1 and has persisted since.. I keep ³hoping² that next time I cvsup it will be fixed, but no). I downgraded back to 5.2.1-p13 and it is perfectly fine once again. *** Some background information: My FreeBSD box is my home NAT router, server, firewall, etc. It does DHCP, MX for some of my domains, secondary DNS (I got primary elsewhere), apache for some webhosting, blah blah blah. Nothing really special. It is a Dual PIII-500, 512mb ram, and a couple ATA hdd¹s. Had 3 realtek network interfaces, but down to 2 now. *** The problem: Networking simply stops or locks up. Why, I don't know. I believe initially it happened for all 3 network cards... I thought tcp/ip processing or something in the kernel got locked. It happens every 30 minutes to an hour, and lasts about 60 seconds to 120 seconds. Unfortunately, 60 seconds to 120 seconds is long enough to kill messenger (my gf does not like), online gaming, etc etc. Just a wils guess: Try setteing 'debug.mpsafet=0' in /boot/loader.conf I had similar problems with pf and RELENG_5 No soultion though :( -Harry Lately, I had taken one of the realtek cards out (it was for a several km long wireless link) and moved the server to my gf's place (where I am now 100% of the time). So now that I have the server locally and rely on it for my internet connection, this has become a real PAIN. I've noticed that I can remain ssh'd into diablo, do whatever I want while this lock issue occurs. So the lan interface rl0 is fine. The internet interface, rl1 (which goes to the cable modem) locks up. (btw, its not the cable modem as I am using my gf's now, and it did this at my place on my cable modem too, which is a different brand. Nortel at my place, motorola at my gfs). *** Attempts: I've attempted switching out network cards, and places 3 other realtek cards in. Different brands, all with different revisions (D instead of B, etc, etc). No matter what I try, nothing fixes it. The machine seems perfectly repsonsive, and I am still ssh'd in and can do whatever I want on it... But the network card going to the cable modem has stopped responding?! This never happened during 5.0-Current all throughout 5.2.1-STABLE, but anywhere beyond 5.2.1 it craps itself. *** Dmesg output: Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.2.1-RELEASE-p13 #2: Thu Feb 10 18:39:33 CST 2005 [EMAIL PROTECTED]:/junk/obj/junk/src/sys/DIABLO Preloaded elf kernel /boot/kernel/kernel at 0xc076c000. MPTable: OEM0 PROD Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Pentium III/Pentium III Xeon/Celeron (504.72-MHz 686-class CPU) Origin = GenuineIntel Id = 0x673 Stepping = 3 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA , CMOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 536870912 (512 MB) avail memory = 516034560 (492 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Assuming intbase of 0 ioapic0 Version 1.1 irqs 0-23 on motherboard Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00fdcf0 pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pci_cfgintr: 0:10 INTA BIOS irq 10 pci_cfgintr: 0:12 INTA BIOS irq 11 agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xd000-0xd3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 UDMA33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xe000-0xe01f at device 7.2 on pci0 pci_cfgintr: 0:7 INTD routed to irq 11 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered piix0: PIIX Timecounter port 0x5000-0x500f at device 7.3 on pci0 Timecounter PIIX frequency 3579545 Hz quality 0 pci0: display, VGA at device 8.0 (no driver attached) rl0: RealTek 8139 10/100BaseTX port 0xe400-0xe4ff mem 0xd700-0xd7ff irq 10 at device 10.0 on pci0 rl0: Ethernet address: 00:00:21:f2:a5:47 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: RealTek 8139 10/100BaseTX port
Re: UPDATE: ATA mkIII first official patches - please test!
Am Mittwoch, 9. Februar 2005 15:00 schrieb Søren Schmidt: [...] As always, enjoy and let me know how it goes... It's running here on several RELENG_5 machines. Like with j I also can't find any problems with k :) But the strange 16MB/s limit on my ICH2 (i815 B-step (tualatin)) machine still exists and still if I use the command atacontrol mode 0 udma5 udma5 the limit vanishes but only when typed interactively, no go by setting the udma5 mode (which is actualy already set at probing) in any rc script. Still reproducale but I have absolutely no idea how this can be :( Thanks for your work :)) -Harry pgpUeI7nEweQY.pgp Description: PGP signature
Re: machine locks with PF (without using user dependent rules)
Am Dienstag, 8. Februar 2005 14:18 schrieb Max Laier: On Monday 07 February 2005 16:52, Emanuel Strobl wrote: [...] Do you have pfsync compiled in? Is it up? If that's the case, can you try No, I don't have pfsync in the kernel, also I don't have modules on that box. to reproduce with a kernel without device pfsync, please? Can you also please try the attached diff and see if it turns up anything - though I certainly doubt that. Really except to see pfsync being the culprit here. I tried your patch, no changes. I can panic the box with pfctl -F all -f /etc/pfconf regardless of the debug.mpsafenet state. But I don't get any panics with debug.mpsafenet=1 while normal operating. And I also cannot see any rule behaviour difference any more. For now it looks to me as if it's only the pfctl command which can panic the box, but I'll see the next days. Here is the latest traceback with your patch: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc1d7 fault code = supervisor read, page not present instruction pointer = 0x8:0xc047b748 stack pointer = 0x10:0xcc6948fc frame pointer = 0x10:0xcc694904 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 35 (swi1: net) [thread pid 35 tid 100031 ] Stopped at pf_state_compare_ext_gwy+0x18: movzbl 0xf9(%esi),%eax db trace Tracing pid 35 tid 100031 td 0xc1515190 pf_state_compare_ext_gwy(c17ed000,cc6949ac,cc69492c,c047c2f2,c17ed0c4) at pf_state_compare_ext_gwy+0x18 pf_state_tree_ext_gwy_RB_FIND(c17ed0c4,cc6949ac,0,c17ed000,cc694ab8) at pf_state_tree_ext_gwy_RB_FIND+0x29 pf_find_state_recurse(c17ed000,cc6949ac,1,c1045ae0,c1743300) at pf_find_state_recurse+0x72 pf_test_state_tcp(cc694b00,1,c17ed000,c18aaa00,14) at pf_test_state_tcp+0xb0 pf_test(1,c1585800,cc694bf0,0,c174d260) at pf_test+0x981 pf_check_in(0,cc694bf0,c1585800,1,0) at pf_check_in+0x48 pfil_run_hooks(c07edc20,cc694c9c,c1585800,1,0) at pfil_run_hooks+0x15b ip_input(c18aaa00,0,c0768929,e6,c07edce0) at ip_input+0x20f netisr_processqueue(cc694cd8,246,c07c2ca0,2,c1508d40) at netisr_processqueue+0x15 swi_net(0,0,c075d0e9,269,0) at swi_net+0x8d ithread_loop(c1526300,cc694d48,c075ceca,31e,0) at ithread_loop+0x1ff fork_exit(c055d000,c1526300,cc694d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc694d7c, ebp = 0 --- I'm a bit busy these days so I can't do extensive testing myself. It'd be a great help if you could verify that I am looking at the right thing. Feel free to ask me whaetever you want me to do, at the moment I have the machine semiproductive and spare time :) Just lacking hacking knowledge :( -Harry pgpvqBGWymdd0.pgp Description: PGP signature
Re: machine locks with PF (without using user dependent rules)
Am Samstag, 8. Januar 2005 18:24 schrieb Max Laier:
On Saturday 08 January 2005 17:52, Robert Watson wrote:
On Sat, 8 Jan 2005, Harald Schmalzbauer wrote:
my machine hard locks with the attached ruleset. If I set
debug.mpsafenet to 0 everything is fine. This was a wild guess from me,
I could nowhere find the info that PF needs this tweaking and I think
it's not intended, otherwise it would be done in rc.conf e.g.
Yes, it is not intended. Please keep in mind that debug.mpsafenet cannot
be alterted at runtime, hence rc.conf would be too late anyway. Just
making that clear.
I read about user depending rules in IPFW and that one has to disable
mpsafenet, but I'm not using user based rules in my PF config!
Unfortunately this machine is a CF-Card based Router wher I cannot
debug anything, perhaps I can bring a witness-kernel on it, please tell
me if this problem is new to you and if I should do that.
I've CC'd Max Laier due to his extensive work with pf on FreeBSD. I
think a WITNESS+INVARIANTS kenrel would be quite helpful, if you could.
Yes, WITNESS would be interesting, though I don't expect to see any LORs,
as this is not an overly complicated ruleset. Actually, I am very
surprised that it does lock up - what hardware is this?
Resuming work on this, I managed to get a remote console to the box and here's
what I get with today's RELENG_5 and the following command, also I need to
set debug.mpsafenet to 0 otherwise my ruleset doesn't work (do what it should
do and does when set to 0 but not when default 1):
pfctl -F all -f /etc/pf.conf
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xdeadc1d7
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc047ac48
stack pointer = 0x10:0xd0a44728
frame pointer = 0x10:0xd0a44730
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1053 (sshd)
[thread pid 1053 tid 100081 ]
Stopped at pf_state_compare_lan_ext+0x18: movzbl 0xf9(%esi),%eax
db trace
Tracing pid 1053 tid 100081 td 0xc177e190
pf_state_compare_lan_ext(c176ca00,d0a447d8,d0a44758,c047c095,c176cac0) at
pf_state_compare_lan_ext+0x18
pf_state_tree_lan_ext_RB_FIND(c176cac0,d0a447d8,0,c176ca00,d0a448e4) at
pf_state_tree_lan_ext_RB_FIND+0x29
pf_find_state_recurse(c176ca00,d0a447d8,0,da7a,c0586400) at
pf_find_state_recurse+0x45
pf_test_state_tcp(d0a4492c,2,c176ca00,c1746b00,14) at pf_test_state_tcp+0xb0
pf_test(2,c1586000,d0a44a1c,c19ff168,c1756720) at pf_test+0x981
pf_check_out(0,d0a44a1c,c1586000,2,c19ff168) at pf_check_out+0x4e
pfil_run_hooks(c07f05a0,d0a44aa8,c1586000,2,c19ff168) at pfil_run_hooks+0x15b
ip_output(c1746b00,0,d0a44a74,0,0) at ip_output+0x3ef
tcp_output(c1a02710,c1744900,c076ed93,280,0) at tcp_output+0x984
tcp_usr_send(c1b5fdec,0,c1744900,0,0) at tcp_usr_send+0x239
sosend(c1b5fdec,0,d0a44c84,c1744900,0) at sosend+0x62b
soo_write(c1c5c264,d0a44c84,c1b0f680,0,c177e190) at soo_write+0x49
dofilewrite(5,8081000,a0,,) at dofilewrite+0xac
write(c177e190,d0a44d14,c,431,3) at write+0x77
syscall(2f,2f,2f,8071d88,a0) at syscall+0x137
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (4, FreeBSD ELF32, write), eip = 0x282ef73f, esp = 0xbfbfddfc, ebp
=0xbfbfde18 ---
Tell me how I can help, I'll later hand in the trace of the slef-lock when
debug.mpsafenet is 1.
-Harry
What version of FreeBSD are you running? RELENG_5_3? Could you try to
move `src/sys/contrib/pf' to RELENG_5 instead. There are some bugfixes in
there, that might help you. Specificly there was an endless loop in the
state matching code. Please tell me if that helped.
Best regards,
-Harry
pf.conf: (note that the interface names are changed, so fxp0 is SDSL
e.g.)
lan_net=172.23.0.0/16
by_net=192.168.0.0/24
sdsl_net=a.b.c.d/29
sdsl_addr=a.b.c.d
lan_addr=172.23.0.1
#pppoe_addr=10.0.0.1
by_addr=192.168.0.1
proxy=a.a.a.a
mta=b.b.b.b
dns=c.c.c.c
web=d.d.d.d
dns2=10.0.0.2
set block-policy return
scrub in all
nat on SDSL from $lan_net to !$sdsl_net - $sdsl_addr
rdr inet proto tcp from 62.245.232.135 to $sdsl_addr port 3389 -
172.23.2.1 port 3389
block in all
block out all
pass in on lo0 all
pass out on lo0 all
pass in on LAN from $lan_net to any keep state
pass in on SDSL from 62.245.232.135 to any keep state
pass in on SDSL proto tcp from any to $proxy port { 22, 80, 443 } keep
state pass in on SDSL proto tcp from any to $mta port 25 keep state
pass in on SDSL proto { udp, tcp } from any to $dns port 53 keep state
pass in on SDSL proto tcp from any to $web port { 80, 443 } keep state
pass out on SDSL from $sdsl_net keep state
pass out on LAN from $lan_addr to $lan_net keep state
P.S.: Why do I need
PANIC: Re: machine locks with PF (without using user dependent rules)
Am Montag, 7. Februar 2005 16:52 schrieb Emanuel Strobl: Am Samstag, 8. Januar 2005 18:24 schrieb Max Laier: On Saturday 08 January 2005 17:52, Robert Watson wrote: On Sat, 8 Jan 2005, Harald Schmalzbauer wrote: my machine hard locks with the attached ruleset. If I set debug.mpsafenet to 0 everything is fine. This was a wild guess from [...] Tell me how I can help, I'll later hand in the trace of the slef-lock when debug.mpsafenet is 1. Like promised, here it is: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc1d7 fault code = supervisor read, page not present instruction pointer = 0x8:0xc047b518 stack pointer = 0x10:0xcc694954 frame pointer = 0x10:0xcc69495c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 35 (swi1: net) [thread pid 35 tid 100031 ] Stopped at pf_state_compare_ext_gwy+0x18: movzbl 0xf9(%esi),%eax db trace Tracing pid 35 tid 100031 td 0xc1515190 pf_state_compare_ext_gwy(c1748300,cc6949ac,cc694984,c047c0c2,c17483c4) at pf_state_compare_ext_gwy+0x18 pf_state_tree_ext_gwy_RB_FIND(c17483c4,cc6949ac,c1748300,cc694af8,cc694ab8) at pf_state_tree_ext_gwy_RB_FIND+0x29 pf_find_state_recurse(c1748300,cc6949ac,1,c076341c,255) at pf_find_state_recurse+0x72 pf_test_state_udp(cc694b00,1,c1748300,c1856c00,14) at pf_test_state_udp+0x90 pf_test(1,c1585800,cc694bf0,0,c1768720) at pf_test+0xb78 pf_check_in(0,cc694bf0,c1585800,1,0) at pf_check_in+0x48 pfil_run_hooks(c07f05a0,cc694c9c,c1585800,1,0) at pfil_run_hooks+0x15b ip_input(c1856c00,0,c076b16d,e6,c07f0660) at ip_input+0x20f netisr_processqueue(cc694cd8,246,c07c5640,2,c1508d40) at netisr_processqueue+0x15 swi_net(0,0,c075f8fb,269,0) at swi_net+0x8d ithread_loop(c1526300,cc694d48,c075f6d4,31e,0) at ithread_loop+0x1ff fork_exit(c055fcb0,c1526300,cc694d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc694d7c, ebp = 0 --- db -Harry pgpO2GmhMkNt8.pgp Description: PGP signature
Re: PANIC: Re: machine locks with PF (without using user dependent rules)
Am Montag, 7. Februar 2005 17:32 schrieb Emanuel Strobl: Am Montag, 7. Februar 2005 16:52 schrieb Emanuel Strobl: Am Samstag, 8. Januar 2005 18:24 schrieb Max Laier: On Saturday 08 January 2005 17:52, Robert Watson wrote: On Sat, 8 Jan 2005, Harald Schmalzbauer wrote: my machine hard locks with the attached ruleset. If I set debug.mpsafenet to 0 everything is fine. This was a wild guess from [...] Tell me how I can help, I'll later hand in the trace of the slef-lock when debug.mpsafenet is 1. Like promised, here it is: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc1d7 fault code = supervisor read, page not present instruction pointer = 0x8:0xc047b518 stack pointer = 0x10:0xcc694954 frame pointer = 0x10:0xcc69495c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 35 (swi1: net) [thread pid 35 tid 100031 ] Stopped at pf_state_compare_ext_gwy+0x18: movzbl 0xf9(%esi),%eax Here's another one: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc2 fault code = supervisor read, page not present instruction pointer = 0x8:0xc047adcb stack pointer = 0x10:0xcc6975fc frame pointer = 0x10:0xcc697604 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 36 (swi5: clock sio) [thread pid 36 tid 100032 ] Stopped at pf_state_tree_lan_ext_RB_FIND+0xb: movl0(%eax),%ebx db trace Tracing pid 36 tid 100032 td 0xc1515320 pf_state_tree_lan_ext_RB_FIND(c2,cc69788c,0,cc697a20,cc697998) at pf_state_tree_lan_ext_RB_FIND+0xb pf_find_state_recurse(c176c300,cc69788c,0,c08118f4,c1514e20) at pf_find_state_recurse+0x45 pf_test_state_icmp(cc6979ec,2,c176c300,c1743000,30) at pf_test_state_icmp+0xb8 pf_test6(2,c1586000,cc697ac0,0,c17565a0) at pf_test6+0xe30 pf_check6_out(0,cc697ac0,c1586000,2,0) at pf_check6_out+0x35 pfil_run_hooks(c07f3980,cc697b58,c1586000,2,0) at pfil_run_hooks+0x15b ip6_output(c1743000,c07f59c0,cc697bdc,0,cc697c4c) at ip6_output+0xb9a mld6_sendpkt(0,c07a5ab0,c07a59a0,c05af360,cc697ca0) at mld6_sendpkt+0x207 mld6_fasttimeo(c07c5680,1,c0767584,100,6) at mld6_fasttimeo+0x83 pffasttimo(0,8,c076302f,f7,38fd) at pffasttimo+0x85 softclock(0,0,c075f8fb,269,0) at softclock+0x12f ithread_loop(c1526280,cc697d48,c075f6d4,31e,0) at ithread_loop+0x1ff fork_exit(c055fcb0,c1526280,cc697d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc697d7c, ebp = 0 --- db pgp5TOkXBwQCx.pgp Description: PGP signature
PANIC (maybe pf related?)
Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc056cc3c stack pointer = 0x10:0xcc706918 frame pointer = 0x10:0xcc70693c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 442 (cron) [thread pid 442 tid 100069 ] Stopped at _mtx_lock_flags+0x2c: cmpl$0xc0797f24,0(%ebx) db trace Tracing pid 442 tid 100069 td 0xc158fe10 _mtx_lock_flags(0,0,c075ebf4,768,c176c364) at _mtx_lock_flags+0x2c fdrop(c17a0316,c158fe10,856,8d4,0) at fdrop+0x35 closef(c17a0316,c158fe10,c075ebf4,646,0) at closef+0x32 fdfree(c158fe10,8,c075f5e8,e5,8) at fdfree+0x26b exit1(c158fe10,f,c0762323,9a0,c1794d20) at exit1+0x357 sigexit(c158fe10,f,c0762323,92c,c19c0aa8) at sigexit+0x202 postsig(f,8,c0764e26,100,431) at postsig+0x39b ast(cc706d48) at ast+0x49e doreti_ast() at doreti_ast+0x17 db This happened after reboot -Harry pgpLtnVux52zo.pgp Description: PGP signature
panic: pf with debug.mpsafenet
Hello, again I got a panic with PF when debug.mpsafenet is enabled, when set to 0 the machine runs almost fine, except that 'pfctl -F all -f /etc/pf.conf' panics and block return and block return-icmp(3,13) doesn't work. Here's the trace: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc1d7 fault code = supervisor read, page not present instruction pointer = 0x8:0xc047ac48 stack pointer = 0x10:0xd135e7e8 frame pointer = 0x10:0xd135e7f0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1156 (sshd) [thread pid 1156 tid 100114 ] Stopped at pf_state_compare_lan_ext+0x18: movzbl 0xf9(%esi),%eax db trace Tracing pid 1156 tid 100114 td 0xc1a24640 pf_state_compare_lan_ext(c1748300,d135e898,d135e818,c047c095,c17483c0) at pf_state_compare_lan_ext+0x18 pf_state_tree_lan_ext_RB_FIND(c17483c0,d135e898,0,c1748300,d135e9a4) at pf_state_tree_lan_ext_RB_FIND+0x29 pf_find_state_recurse(c1748300,d135e898,0,d135e880,d135e840) at pf_find_state_recurse+0x45 pf_test_state_tcp(d135e9ec,2,c1748300,c1745000,14) at pf_test_state_tcp+0xb0 pf_test(2,c1585800,d135eadc,c19ccbf4,c19d4000) at pf_test+0x981 pf_check_out(0,d135eadc,c1585800,2,c19ccbf4) at pf_check_out+0x4e pfil_run_hooks(c07f05a0,d135eb68,c1585800,2,c19ccbf4) at pfil_run_hooks+0x15b ip_output(c1745000,0,d135eb34,0,0) at ip_output+0x3ef tcp_output(c1b7e1c4,8,c076ed93,169,c1ce2654) at tcp_output+0x984 tcp_usr_connect(c1ce2654,c1696b40,c1a24640) at tcp_usr_connect+0xbc soconnect(c1ce2654,c1696b40,c1a24640,10,c05bb4d8) at soconnect+0x5a kern_connect(c1a24640,b,c1696b40,c1696b40) at kern_connect+0x9a connect(c1a24640,d135ed14,c,431,3) at connect+0x48 syscall(807002f,807002f,bfbf002f,807b6c0,b) at syscall+0x137 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (98, FreeBSD ELF32, connect), eip = 0x282eeedf, esp = 0xbfbfd8cc, ebp = 0xbfbfdd78 --- db Let me know if I can test anything for you. -Harry pgpbjVbXZsb9D.pgp Description: PGP signature
watchdogd panic when shutdown -p
Hello, I have a kernel with SW_WATCHDOG and simply enabled watchdog in rc.conf. I haven't found much info on that topic but I guess when the machine hangs (watchdogd doesn't get a result from the trivial fsck (what's that btw?)) the kernel will reset the machine. Best would be if I never see watchdog in action but I'm seeing a panic message after some interrupt statistics (see below) and the machine doesn't power off (like it does without watchdogd enabled). Any hints? I played a bit with setting the -t timeoutseconds but this didn't change anything, the machine doesn't power off. Is it correct that the trivials filesystem check of watchdogd is really done every second by default? Thanks a lot, -Harry Uptime: 25m6s interrupt total irq0: clk 771518 irq3: sio1 740 irq8: rtc 192856 irq10: fxp0 103 irq11: atapci121 irq12: fwohci0++ 69 irq13: npx01 irq14: ata0 51 irq15: ata117284 Total 982643 panic: watchdog timeout Uptime: 25m7s pgpkuBtvQyTr2.pgp Description: PGP signature
Re: strange ucom (uplcom) error
Am Samstag, 22. Januar 2005 15:52 schrieb Shunsuke Akiyama: [...] Good work! I've updated your patch. If attached patch works correctly with new revision chip, I'll commit this. Please test attached patch, and tell me the result. I tested it (after removing the DOS ^M characters) against uplcom.c 1.25 with my RELENG_5 system. Everything seems fine, I just cannot ~p (put) files with cu/tip, but that doesn't work with a real serial cable either. So committing and MFC (1.26) after 3 days would be great for me. Thank you all a lot, -Harry Regards, pgpRmldh9wKZ2.pgp Description: PGP signature
Re: watchdogd panic when shutdown -p
Am Montag, 24. Januar 2005 19:29 schrieb Vivek Khera: On Jan 24, 2005, at 3:11 AM, Emanuel Strobl wrote: kernel will reset the machine. Best would be if I never see watchdog in action but I'm seeing a panic message after some interrupt statistics (see below) and the machine doesn't power off (like it does without watchdogd enabled). Interesting... Can you compare your experience with mine as described in PR 71800? Hmm, I don't have the problem when rebooting, just when shutting down with power off. I also have never seen any loop as you describe. http://www.freebsd.org/cgi/query-pr.cgi?pr=71800 I hadn't attributed this to the watchdog. I'll try that, but I have two boxes with watchdog enabled (FreeBSD 5.3 and 5.2.1) which don't exhibit any failure to shutdown, and I have two boxes with 5.3 that do exhibit (one ever since 5.3 BETA) the kernel IRQ messages on any type of shutdown. All have the watchdog on. I think it's a ACPI interaction problem with watchdog, so depending on your motherborads ACPI implementation you see the error or not, but I'm completely new to SW_WATCHDOG so I can't tell much when and why these irq statistics are generated. Maybe Sean Kelly can tell us how SW_WATCHDOG interacts with ACPI, since I think the problem occurs when the kernel disables ACPI, right? (just my feeling) -Harry Vivek Khera, Ph.D. +1-301-869-4449 x806 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] pgpoUjzhI9Upc.pgp Description: PGP signature
Re: strange ucom (uplcom) error
Am Donnerstag, 20. Januar 2005 14:18 schrieb Michal Mertl:
I tested my patch for binary safety on CURRENT yesterday (dialed with
ppp) and didn't notice any problem.
I'm attaching my patch again because some recipients didn't probably
receive it yesterday.
This didn't apply cleanly against my -stable from today.
Attached is a cleaned version (#define RSAQ_STATUS_CTS doesn't exist in
-stable uplcom.c) for -stable which compiles for me.
Michal
--- sys/dev/usb/uplcom.c Fri Jan 21 10:49:09 2005
+++ sys/dev/usb/uplcom.c Fri Jan 21 11:01:33 2005
@@ -96,10 +96,13 @@
#include sys/poll.h
#include sys/sysctl.h
+#include machine/bus.h
+
#include dev/usb/usb.h
#include dev/usb/usbcdc.h
#include dev/usb/usbdi.h
+#include dev/usb/usbdivar.h
#include dev/usb/usbdi_util.h
#include usbdevs.h
#include dev/usb/usb_quirks.h
@@ -112,29 +115,34 @@
SYSCTL_INT(_hw_usb_uplcom, OID_AUTO, debug, CTLFLAG_RW,
uplcomdebug, 0, uplcom debug level);
-#define DPRINTFN(n, x) do { \
+#define DPRINTFN(n, x) do { \
if (uplcomdebug (n)) \
logprintf x; \
} while (0)
#else
-#define DPRINTFN(n, x)
+#define DPRINTFN(n, x)
#endif
-#define DPRINTF(x) DPRINTFN(0, x)
+#define DPRINTF(x) DPRINTFN(0, x)
-#define UPLCOM_MODVER 1 /* module version */
+#define UPLCOM_MODVER 1 /* module version */
#define UPLCOM_CONFIG_INDEX 0
#define UPLCOM_IFACE_INDEX 0
#define UPLCOM_SECOND_IFACE_INDEX 1
#ifndef UPLCOM_INTR_INTERVAL
-#define UPLCOM_INTR_INTERVAL 100 /* ms */
+#define UPLCOM_INTR_INTERVAL 100 /* ms */
#endif
#define UPLCOM_SET_REQUEST 0x01
#define UPLCOM_SET_CRTSCTS 0x41
-#define RSAQ_STATUS_DSR 0x02
-#define RSAQ_STATUS_DCD 0x01
+#define UPLCOM_SET_CRTSCTS_2303X 0x61
+#define RSAQ_STATUS_CTS 0x80
+#define RSAQ_STATUS_DSR 0x02
+#define RSAQ_STATUS_DCD 0x01
+
+#define CHIPTYPE_PL2303 0
+#define CHIPTYPE_PL2303X 1
struct uplcom_softc {
struct ucom_softc sc_ucom;
@@ -154,14 +162,15 @@
u_char sc_lsr; /* Local status register */
u_char sc_msr; /* uplcom status register */
+ int sc_chiptype;
};
/*
* These are the maximum number of bytes transferred per frame.
* The output buffer size cannot be increased due to the size encoding.
*/
-#define UPLCOMIBUFSIZE 256
-#define UPLCOMOBUFSIZE 256
+#define UPLCOMIBUFSIZE 256
+#define UPLCOMOBUFSIZE 256
Static usbd_status uplcom_reset(struct uplcom_softc *);
Static usbd_status uplcom_set_line_coding(struct uplcom_softc *,
@@ -297,6 +306,7 @@
char *devinfo;
const char *devname;
usbd_status err;
+ usb_device_descriptor_t *udd;
int i;
devinfo = malloc(1024, M_USBDEV, M_WAITOK);
@@ -372,7 +382,14 @@
sc-sc_isize = UGETW(ed-wMaxPacketSize);
}
}
-
+ udd = dev-ddesc;
+ if (UGETW(udd-bcdDevice) == 0x300) {
+ DPRINTF((chiptype 2303X\n));
+ sc-sc_chiptype = CHIPTYPE_PL2303X;
+ } else {
+ DPRINTF((chiptype 2303\n));
+ sc-sc_chiptype = CHIPTYPE_PL2303;
+ }
if (sc-sc_intr_number == -1) {
printf(%s: Could not find interrupt in\n,
USBDEVNAME(ucom-sc_dev));
@@ -615,7 +632,10 @@
req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
req.bRequest = UPLCOM_SET_REQUEST;
USETW(req.wValue, 0);
- USETW(req.wIndex, UPLCOM_SET_CRTSCTS);
+ if (sc-sc_chiptype == CHIPTYPE_PL2303X)
+ USETW(req.wIndex, UPLCOM_SET_CRTSCTS_2303X);
+ else
+ USETW(req.wIndex, UPLCOM_SET_CRTSCTS);
USETW(req.wLength, 0);
err = usbd_do_request(sc-sc_ucom.sc_udev, req, 0);
@@ -711,6 +731,43 @@
return (0);
}
+#define DO_REQ(type, reQ, wVal, wInd) do {\
+ req.bmRequestType = (type); \
+ req.bRequest = (reQ); \
+ USETW(req.wValue, (wVal)); \
+ USETW(req.wIndex, (wInd)); \
+ USETW(req.wLength, 0); \
+ err = usbd_do_request(sc-sc_ucom.sc_udev, req, 0); \
+ if (err) { /* XXX - shouldn't happen */\
+ printf(%s: uplcom_initPL2303X_%d: %s\n, \
+ USBDEVNAME(sc-sc_ucom.sc_dev), i++, usbd_errstr(err)); \
+ return (EIO); \
+ }\
+ } while (0);
+
+Static usbd_status
+uplcom_initPL2303X(struct uplcom_softc *sc)
+{
+ usb_device_request_t req;
+ usbd_status err;
+ int i = 0;
+
+ DO_REQ(0xc0, 0x1, 0x8484, 0);
+ DO_REQ(0x40, 0x1, 0x0404, 0);
+ DO_REQ(0xc0, 0x1, 0x8484, 0);
+ DO_REQ(0xc0, 0x1, 0x8383, 0);
+ DO_REQ(0xc0, 0x1, 0x8484, 0);
+ DO_REQ(0x40, 0x1, 0x0404, 1);
+ DO_REQ(0xc0, 0x1, 0x8484, 0);
+ DO_REQ(0xc0, 0x1, 0x8383, 0);
+ DO_REQ(0x40, 0x1, 0x, 1);
+ DO_REQ(0x40, 0x1, 0x0001, 0);
+ DO_REQ(0x40, 0x1, 0x0002, 0x44);
+ return (0);
+}
+
+#undef DO_REQ
+
Static int
uplcom_open(void *addr, int portno)
{
@@ -741,7 +798,8 @@
return (EIO);
}
}
-
+ if (sc-sc_chiptype == CHIPTYPE_PL2303X)
+ return (uplcom_initPL2303X(sc));
return (0);
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange ucom (uplcom) error
Am Donnerstag, 20. Januar 2005 14:18 schrieb Michal Mertl: works for both chips on CURRENT for serial console. It detects if the chip is rev 3.00 and aplies the patch only for it. The author of the patch mentions it isn't binary safe - sometimes the chip stops working. I planned to test it with binary transfers (ppp) today, check if it's working and submit it (with some cleanup) for inclusion in FreeBSD. Michal Mertl I tested my patch for binary safety on CURRENT yesterday (dialed with ppp) and didn't notice any problem. Thanks a lot, unfortunately my notebook died (the display mechanic) so I cannot test it at the moment (my workstation box is too far away from my servers with serial stuff). But I think this should be commited, otherwiese more people like me go shopping, testing the adaptor, seeing that it gets recognized as Prolific 2303, purchasing some of them and then at home find out that there is also a unsupported version of the 2303 :( I'm sure someone (bernd?) will commit it for you. Thanks a lot for your work, I'll test it asap and let you know if I find anything unusual. Best regards, -Harry I'm attaching my patch again because some recipients didn't probably receive it yesterday. Michal pgp7Z1v5WRGhZ.pgp Description: PGP signature
fwe and em ftp transfer rates
Dear all, I'm sorry but I have to report something's going wrong with simple ftp file transfers. I have two Fujitsu Siemens Primergy B125 servers ([EMAIL PROTECTED], 512MB) with both 'em' cards in it which are connected directly together, so no switch can drop packets. When I transfer a large testfile (400MB) via ftp I get unbelievable 18MB/s. Both servers are 0% idle (~60% intr 40% sys). What the heck is this machine doing? There's nothing else on the machines running, sure! I can dump to the disks with ~55MB/s so the bottleneck is not the hardware. Things go worse if I use fwe (TI chipest) or fwip instead of em. Then transfer rates decrease to 15MB/s for the fwe and 13MB/s with the fwip. One good thin is that using NFS instead of ftp gives comparable transfer rates (~5% less) without tuning and regardless of udp or tcp. world an kernel are built with -O2 -march=pentium3, kernel config and dmesg are attached (CUV-LV ist the kernel config). What can I do to get reasonable GbE performance (with this hw I expect at least 40MB/s, it's what a friend achieves with an other graphical OS on similar hw). Thanks, -Harry Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-STABLE #0: Thu Jan 20 02:12:36 CET 2005 [EMAIL PROTECTED]:/builder/obj/builder/src/sys/CUV-LV Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (870.58-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 536854528 (511 MB) avail memory = 515629056 (491 MB) acpi0: ASUS CUV_LV on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 cpu0: ACPI CPU (3 Cx states) on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 82C691 (Apollo Pro) host to PCI bridge mem 0xfe00-0xfe3f at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686A UDMA66 controller port 0xb800-0xb80f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 4.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: VIA 83C572 USB controller port 0xb400-0xb41f irq 12 at device 4.2 on pci0 uhci0: [GIANT-LOCKED] usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xb000-0xb01f irq 12 at device 4.3 on pci0 uhci1: [GIANT-LOCKED] usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered viapropm0: SMBus I/O base at 0xe800 viapropm0: VIA VT82C686A Power Management Unit port 0xe800-0xe80f at device 4.4 on pci0 viapropm0: SMBus revision code 0x0 smbus0: System Management Bus on viapropm0 smb0: SMBus generic I/O on smbus0 fxp0: Intel 82559 Pro/100 Ethernet port 0xa800-0xa83f mem 0xfa80-0xfa8f,0xfb00-0xfb000fff irq 5 at device 7.0 on pci0 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:e0:18:06:ad:59 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xa400-0xa43f mem 0xf980-0xf981,0xfa00-0xfa01 irq 10 at device 9.0 on pci0 em0: Ethernet address: 00:0e:0c:34:2b:f8 em0: Speed:N/A Duplex:N/A fwohci0: Texas Instruments TSB43AB23 mem 0xf880-0xf8803fff,0xf900-0xf90007ff irq 12 at device 10.0 on pci0 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:01:08:00:20:01:eb:10 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet address: 02:01:08:01:eb:10 fwe0: Ethernet address: 02:01:08:01:eb:10 fwe0: if_start running deferred for Giant sbp0: SBP-2/SCSI over FireWire on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop = 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) atapci1: HighPoint HPT372 UDMA133 controller port 0x8800-0x88ff,0x9000-0x9003,0x9400-0x9407,0x9800-0x9803,0xa000-0xa007 irq 11 at device 12.0 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3
Higher ATA-Mode - lower speed
Dear ata interested guys, I observed a strange behaviour which seems to explain my often noticed 16MB/s hard-limit I have a UDMA133 drive (MAXTOR 6L060J3) which saturates at 16MB/s when I dump anything to it, regardless of the block size. This transfer rate is reached with bs=4k and doesn't increase any more even not with bs=64k. Now, when I set the mode to UDMA100 I get well over 40MB/s Can anybody confirm that for different hw? Especially people like fandino who already discussed poor ata performance on -current (~16 Oct. 04). Why does UDMA133 mode limit the transfer speed so badly? And why do I get significantly slower transfer rates (32MB/s insted of 42MB/s) when I set the mode to UDMA66 (compared to UDMA100 but twice the speed of UDMA133)? There's only one device on the channel, so UDMA66 should be fine for 42MB/s. The controller is a HPT372. Best regards, -Harry pgpGEJ1qXmSgv.pgp Description: PGP signature
Re: Higher ATA-Mode - lower speed
Am Donnerstag, 20. Januar 2005 19:48 schrieb Emanuel Strobl: Dear ata interested guys, I observed a strange behaviour which seems to explain my often noticed 16MB/s hard-limit I have a UDMA133 drive (MAXTOR 6L060J3) which saturates at 16MB/s when I dump anything to it, regardless of the block size. This transfer rate is reached with bs=4k and doesn't increase any more even not with bs=64k. Now, when I set the mode to UDMA100 I get well over 40MB/s Can anybody confirm that for different hw? Especially people like fandino who already discussed poor ata performance on -current (~16 Oct. 04). I can confirm that for my workstation here. i815 chipset and seagate ST380011A. When set to UDMA100 (the maximum) the following dump gives 16MB/s 'dd if=/dev/zero of=/usr/testfile bs=16k count=2000). When I limit the mode to UDMA66 I get 53MB/s It seems that's independent of UDMA133 instead it's when mode is set to the maximum the chipset can handle! This really hurts! But it's _the_ eplanation for all the poor ata performance reports. -Harry Why does UDMA133 mode limit the transfer speed so badly? And why do I get significantly slower transfer rates (32MB/s insted of 42MB/s) when I set the mode to UDMA66 (compared to UDMA100 but twice the speed of UDMA133)? There's only one device on the channel, so UDMA66 should be fine for 42MB/s. The controller is a HPT372. Best regards, -Harry pgpIwacfZHDtf.pgp Description: PGP signature
Re: Higher ATA-Mode - lower speed
Am Donnerstag, 20. Januar 2005 20:00 schrieb Emanuel Strobl: Am Donnerstag, 20. Januar 2005 19:48 schrieb Emanuel Strobl: Dear ata interested guys, I observed a strange behaviour which seems to explain my often noticed 16MB/s hard-limit I have a UDMA133 drive (MAXTOR 6L060J3) which saturates at 16MB/s when I dump anything to it, regardless of the block size. This transfer rate is reached with bs=4k and doesn't increase any more even not with bs=64k. Now, when I set the mode to UDMA100 I get well over 40MB/s Can anybody confirm that for different hw? Especially people like fandino who already discussed poor ata performance on -current (~16 Oct. 04). I can confirm that for my workstation here. i815 chipset and seagate ST380011A. When set to UDMA100 (the maximum) the following dump gives 16MB/s 'dd if=/dev/zero of=/usr/testfile bs=16k count=2000). When I limit the mode to UDMA66 I get 53MB/s Sorry, that's not 100% correct. After booting the machine I get 16MB/s. That's the hard limit. The disk is shown to operate with UDMA100 (that's the highest mode of the chipset). Now when I issue a 'atacontrol mode 0 udma100 udma100' (set the same mode as it's said to be) I get 57MB/s! From this point it doesn't matter what mode I set, the 16MB/s hard-limit vanished :)) But the original described problem of the 16MB/s hard-limit with udma133 is reproducable, means if I return mode to udma133 I see the 16MB/s limit again! -Harry It seems that's independent of UDMA133 instead it's when mode is set to the maximum the chipset can handle! This really hurts! But it's _the_ eplanation for all the poor ata performance reports. -Harry Why does UDMA133 mode limit the transfer speed so badly? And why do I get significantly slower transfer rates (32MB/s insted of 42MB/s) when I set the mode to UDMA66 (compared to UDMA100 but twice the speed of UDMA133)? There's only one device on the channel, so UDMA66 should be fine for 42MB/s. The controller is a HPT372. Best regards, -Harry pgpO7XoWwdhQx.pgp Description: PGP signature
strange ucom (uplcom) error
Dear experts, I have two USB-RS232 Adaptors, both with PL2303 chipset. One is working the other one not (I hate to say it but both are working under win). The not working (more expensive) one gets recognized as ucom0 and I have ucom0, also I can receive signal but not transmit. When I connect the (more expensive) adopter to a serial console (FreeBSD comconsole) I can see all kernel messages but I can't type any charecter when I see the login. If I change to the cheaper adopter everything is working fine. I compared 'stty -a -f /dev/ucom0' and both adaptors show the same settings. I'm using tip (ucom0:dv=/dev/ucom0:br#115200:pa=none:) on RELENG_5 (from this weekend) Here is usbdevfs output and the corresponding dmesg line for both adapters, the 2nd (ATEN) is the working one (cheaper one), the first the more expensive not working one! port 1 addr 2: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 __dmesg: ucom0: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 2 port 1 addr 2: full speed, power 100 mA, config 1, PL2303 Serial adapter (ATEN/IOGEAR UC232A)(0x2303), Prolific Technology(0x067b), rev 2.02 __dmesg: ucom0: Prolific Technology PL2303 Serial adapter (ATEN/IOGEAR UC232A), rev 1.10/2.02, addr 2 Any help highly appreciated! -Harry pgpO2z73raAXs.pgp Description: PGP signature
Re: strange ucom (uplcom) error
Am Dienstag, 18. Januar 2005 16:17 schrieb Andrew L. Neporada: On Tue, Jan 18, 2005 at 01:06:43PM +0100, Emanuel Strobl wrote: Dear experts, I have two USB-RS232 Adaptors, both with PL2303 chipset. One is working the other one not (I hate to say it but both are working under win). The not working (more expensive) one gets recognized as ucom0 and I have ucom0, also I can receive signal but not transmit. [skip] Take a look at http://gate.intercaf.ru/~lesha/6100/ and try patch http://gate.intercaf.ru/~lesha/6100/pl2303x.patch It can break old (working) PL2303 chip, but it works for me with newer Thanks a lot, this indeed fixes the revision 3.0 adaptor but unfortunately also breakes the 2.02 version :( Perhaps there's a goog guy out there who can refurbish the uplcom driver with this information (akiyama?)? Thanks a lot, -Harry revision chip (tested under 4.10). -Harry Andrew. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgpUJhVUkj8T3.pgp Description: PGP signature
GMIRROR can be destroyed by ordinary users
Dear list, dear Pawel, I think it's a big error that ordinary users can issue a 'gmirror stop /dev/mirrir/sample' with success! Thanks, -Harry ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GMIRROR can be destroyed by ordinary users
Am Samstag, 8. Januar 2005 15:41 schrieb Simon L. Nielsen: I think it's a big error that ordinary users can issue a 'gmirror stop /dev/mirrir/sample' with success! Are you sure about that? I can't do it on my test system: [EMAIL PROTECTED]:~] gmirror stop /dev/mirror/sys0 Permission denied I'm quiet sure because I accidentally did it once, but unfortnately now I don't have a test machine. The only not so ordinary about my user is that it's in the group wheel. If you have a test machine, could you find out if that's the error? Thanks, -Harry pgpfrTVwJTank.pgp Description: PGP signature
How to use growfs on GPT
The topic says all. I'd like to increase the size of the last GPT id (and there's space after the last sector of the last ID). Is it safe to delete it and create a new one with a bigger size? Thanks, -Harry pgphD0rfLb0i0.pgp Description: PGP signature
Re: serious networking (em) performance (ggate and NFS) problem
Am Donnerstag, 18. November 2004 13:27 schrieb Robert Watson: On Wed, 17 Nov 2004, Emanuel Strobl wrote: I really love 5.3 in many ways but here're some unbelievable transfer First, thanks a lot to all of you paying attention to my problem again. I'll use this as a cumulative answer to the many postings of you, first answering Roberts questions and at the bottom those of the others. I changed cables and couldn't reproduce that bad results so I changed cables back but also cannot reproduce them, especially the ggate write, formerly with 2,6MB/s now performs at 15MB/s, but I haven't done any polling tests anymore, just interrupt driven, since Matt explained that em doesn't benefit of polling in any way. Results don't indicate a serious problem now but are still about a third of what I'd expected with my hardware. Do I really need Gigahertz Class CPUs to transfer 30MB/s over GbE? I think the first thing you want to do is to try and determine whether the problem is a link layer problem, network layer problem, or application (file sharing) layer problem. Here's where I'd start looking: (1) I'd first off check that there wasn't a serious interrupt problem on the box, which is often triggered by ACPI problems. Get the box to be as idle as possible, and then use vmstat -i or stat -vmstat to see if anything is spewing interrupts. Everything is fine (2) Confirm that your hardware is capable of the desired rates: typically this involves looking at whether you have a decent card (most if_em cards are decent), whether it's 32-bit or 64-bit PCI, and so on. For unidirectional send on 32-bit PCI, be aware that it is not possible to achieve gigabit performance because the PCI bus isn't fast enough, for example. I'm aware that my 32bit/33MHz PCI bus is a bottleneck, but I saw almost 80MByte/s running over the bus to my test-stripe-set (over the HPT372). So I'm pretty sure the system is good for 40MB/s ober the GbE line, which was sufficient for me. (3) Next, I'd use a tool like netperf (see ports collection) to establish three characteristics: round trip latency from user space to user space (UDP_RR), TCP throughput (TCP_STREAM), and large packet throughput (UDP_STREAM). With decent boxes on 5.3, you should have no trouble at all maxing out a single gig-e with if_em, assuming all is working well hardware wise and there's no software problem specific to your configuration. Please find the results on http://www.schmalzbauer.de/document.php?id=21 There is also a lot of additional information and more test results (4) Note that router latency (and even switch latency) can have a substantial impact on gigabit performance, even with no packet loss, in part due to stuff like ethernet flow control. You may want to put the two boxes back-to-back for testing purposes. I was aware of that and because of lacking a GbE switch anyway I decided to use a simple cable ;) (5) Next, I'd measure CPU consumption on the end box -- in particular, use top -S and systat -vmstat 1 to compare the idle condition of the system and the system under load. I additionally added these values to the netperf results. If you determine there is a link layer or IP layer problem, we can start digging into things like the error statistics in the card, negotiation issues, etc. If not, you want to move up the stack to try and characterize where it is you're hitting the performance issue. Am Donnerstag, 18. November 2004 17:53 schrieb M. Warner Losh: In message: [EMAIL PROTECTED] Robert Watson [EMAIL PROTECTED] writes: : (1) I'd first off check that there wasn't a serious interrupt problem on : the box, which is often triggered by ACPI problems. Get the box to : be as idle as possible, and then use vmstat -i or stat -vmstat to see if : anything is spewing interrupts. Also, make sure that you aren't sharing interrupts between GIANT-LOCKED and non-giant-locked cards. This might be exposing bugs in the network layer that debug.mpsafenet=0 might correct. Just noticed that our setup here has that setup, so I'll be looking into that area of things. As you can see on the link above, no shared IRQs pgpb1ohdo7oDw.pgp Description: PGP signature
fwe and fwip not working with fwohci0: VIA Fire II (VT6306)
Dear lists, since I couldn't get the speed I need with GbE em cards I bought a pair of firewire 1394a cards and a 6-to-6-Cable. I tried fwe, could ping the other host and also transfer very little files via ftp, but as soon as I try to shovel a view hundred kByte files the connection stalles. Of course, same with NFS, there I can't transfer any file. Then I compiled a kernel with ipfw but it's exactly the same. Also one machine hangs sometimes at boot when the cable is connected to both cards and the other machine is running, with the following lines: fwohci0: VIA Fire II (VT6306) port 0xd800-0xd87f mem 0xe2041000-0xe20417ff irq 5 at device 10.0 on pci0 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:06:00:00:00:75:86 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet address: 02:11:06:00:75:86 fwe0: Ethernet address: 02:11:06:00:75:86 fwe0: if_start running deferred for Giant sbp0: SBP-2/SCSI over FireWire on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc1, gen=1, CYCLEMASTER mode firewire0: 2 nodes, maxhop = 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) [...] firewire0: New S400 device ID:001106007587 firewire0: split transaction timeout dst=0xffc0 tl=0x7 state=3 firewire0: bus_explore node=0 addr=0x40c resp=60 retry=1 Then nothing happens but the system isn't frozen since numlock key is toggling the keyboard LED. For a verbose boot or a full dmesg please see http://www.schmalzbauer.de/document.php?id=22 I have no idea where to start finding the real problem. Has anybody out there ever been able to use tcp/ip over the VIA VT6306 firewire link? Thanks, -Harry pgpk6wuN76wVn.pgp Description: PGP signature
Re: serious networking (em) performance (ggate and NFS) problem
Am Freitag, 19. November 2004 13:56 schrieb Robert Watson: On Fri, 19 Nov 2004, Emanuel Strobl wrote: Am Donnerstag, 18. November 2004 13:27 schrieb Robert Watson: On Wed, 17 Nov 2004, Emanuel Strobl wrote: I really love 5.3 in many ways but here're some unbelievable transfer [...] Well, the claim that if_em doesn't benefit from polling is inaccurate in the general case, but quite accurate in the specific case. In a box with multiple NIC's, using polling can make quite a big difference, not just by mitigating interrupt load, but also by helping to prioritize and manage the load, preventing live lock. As I indicated in my earlier e-mail, I understand, thanks for the explanation It looks like the netperf TCP test is getting just under 27MB/s, or 214Mb/s. That does seem on the low side for the PCI bus, but it's also Nut sure if I understand that sentence correctly, does it mean the slow 400MHz PII is causing this limit? (low side for the PCI bus?) instructive to look at the netperf UDP_STREAM results, which indicate that the box believes it is transmitting 417Mb/s but only 67Mb/s are being received or processed fast enough by netserver on the remote box. This means you've achieved a send rate to the card of about 54Mb/s. Note that you can actually do the math on cycles/packet or cycles/byte here -- with TCP_STREAM, it looks like some combination of recipient CPU and latency overhead is the limiting factor, with netserver running at 94% busy. Hmm, I can't puzzle a picture out of this. Could you try using geom gate to export a malloc-backed md device, and see what performance you see there? This would eliminate the storage round It's a pleasure: test2:~#15: dd if=/dev/zero of=/mdgate/testfile bs=16k count=6000 6000+0 records in 6000+0 records out 98304000 bytes transferred in 5.944915 secs (16535812 bytes/sec) test2:~#17: dd if=/mdgate/testfile of=/dev/null bs=16k 6000+0 records in 6000+0 records out 98304000 bytes transferred in 5.664384 secs (17354755 bytes/sec) This time it's no difference between disk and memory filesystem, but on another machine with a ich2 chipset and a 3ware controller (my current productive system which I try to replace with this project) there was a big difference. Attached is the corresponding message. Thanks, -Harry trip and guarantee the source is in memory, eliminating some possible sources of synchronous operation (which would increase latency, reducing throughput). Looking at CPU consumption here would also be helpful, as it would allow us to reason about where the CPU is going. I was aware of that and because of lacking a GbE switch anyway I decided to use a simple cable ;) Yes, this is my favorite configuration :-). (5) Next, I'd measure CPU consumption on the end box -- in particular, use top -S and systat -vmstat 1 to compare the idle condition of the system and the system under load. I additionally added these values to the netperf results. Thanks for your very complete and careful testing and reporting :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ---BeginMessage--- Am Dienstag, 2. November 2004 19:56 schrieb Doug White: On Tue, 2 Nov 2004, Robert Watson wrote: On Tue, 2 Nov 2004, Emanuel Strobl wrote: It's a IDE Raid controller (3ware 7506-4, a real one) and the file is indeed huge, but not abnormally. I have a harddisk video recorder, so I have lots of 700MB files. Also if I copy my photo collection from the server it takes 5 Minutes but copying _to_ the server it takes almost 15 Minutes and the average file size is 5 MB. Fast Ethernet isn't really suitable for my needs, but at least the 10MB/s should be reached. I can't imagine I get better speeds when I upgrade to GbE, (which the important boxes are already, just not the switch) because NFS in it's current state isn't able to saturate a 100baseTX line, at least in one direction. That's the real anstonishing thing for me. Why does reading staurate 100BaseTX but writes only a third? Have you tried using tcpdump/ethereal to see if there's any significant packet loss (for good reasons or not) going on? Lots of RPC retransmits would certainly explain the lower performance, and if that's not it, it would be good to rule out. The traces might also provide some insight into the specific I/O operations, letting you see what block sizes are in use, etc. I've found that dumping to a file with tcpdump and reading with ethereal is a really good way to get a picture of what's going on with NFS: ethereal does a very nice job decoding the RPCs, as well as figuring out what packets are related to each other, etc
serious networking (em) performance (ggate and NFS) problem
Dear best guys, I really love 5.3 in many ways but here're some unbelievable transfer rates, after I went out and bought a pair of Intel GigaBit Ethernet Cards to solve my performance problem (*laugh*): (In short, see *** below) Tests were done with two Intel GigaBit Ethernet cards (82547EI, 32bit PCI Desktop adapter MT) connected directly without a switch/hub and device polling compiled into a custom kernel with HZ set to 256 and kern.polling.enabled set to 1: LOCAL: (/samsung is ufs2 on /dev/ad4p1, a SAMSUNG SP080N2) test3:~#7: dd if=/dev/zero of=/samsung/testfile bs=16k ^C10524+0 records in 10524+0 records out 172425216 bytes transferred in 3.284735 secs (52492882 bytes/sec) - ~ 52MB/s NFS(udp,polling): (/samsung is nfs on test3:/samsung, via em0, x-over, polling enabled) test2:/#21: dd if=/dev/zero of=/samsung/testfile bs=16k ^C1858+0 records in 1857+0 records out 30425088 bytes transferred in 8.758475 secs (3473788 bytes/sec) -^^^ ~ 3,4MB/s This example shows that using NFS over GigaBit Ethernet decimates performance by the factor of 15, in words fifteen! GGATE with MTU 16114 and polling: test2:/dev#28: ggatec create 10.0.0.2 /dev/ad4p1 ggate0 test2:/dev#29: mount /dev/ggate0 /samsung/ test2:/dev#30: dd if=/dev/zero of=/samsung/testfile bs=16k ^C2564+0 records in 2563+0 records out 41992192 bytes transferred in 15.908581 secs (2639594 bytes/sec) - ^^^ ~ 2,6MB/s GGATE without polling and MTU 16114: test2:~#12: ggatec create 10.0.0.2 /dev/ad4p1 ggate0 test2:~#13: mount /dev/ggate0 /samsung/ test2:~#14: dd if=/dev/zero of=/samsung/testfile bs=128k ^C1282+0 records in 1281+0 records out 167903232 bytes transferred in 11.274768 secs (14891945 bytes/sec) - ~ 15MB/s .and with 1m blocksize: test2:~#17: dd if=/dev/zero of=/samsung/testfile bs=1m ^C61+0 records in 60+0 records out 62914560 bytes transferred in 4.608726 secs (13651182 bytes/sec) - ~ 13,6MB/s I can't imagine why there seems to be a absolute limit of 15MB/s that can be transfered over the network But it's even worse, here two excerpts of NFS (udp) with jumbo Frames (mtu=16114): test2:~#23: mount 10.0.0.2:/samsung /samsung/ test2:~#24: dd if=/dev/zero of=/samsung/testfile bs=1m ^C89+0 records in 88+0 records out 92274688 bytes transferred in 13.294708 secs (6940708 bytes/sec) - ^^^ ~7MB/s .and with 64k blocksize: test2:~#25: dd if=/dev/zero of=/samsung/testfile bs=64k ^C848+0 records in 847+0 records out 55508992 bytes transferred in 8.063415 secs (6884055 bytes/sec) And with TCP-NFS (and Jumbo Frames): test2:~#30: mount_nfs -T 10.0.0.2:/samsung /samsung/ test2:~#31: dd if=/dev/zero of=/samsung/testfile bs=64k ^C1921+0 records in 1920+0 records out 125829120 bytes transferred in 7.461226 secs (16864403 bytes/sec) - ~ 17MB/s Again NFS (udp) but with MTU 1500: test2:~#9: mount_nfs 10.0.0.2:/samsung /samsung/ test2:~#10: dd if=/dev/zero of=/samsung/testfile bs=8k ^C12020+0 records in 12019+0 records out 98459648 bytes transferred in 10.687460 secs (9212633 bytes/sec) - ^^^ ~ 10MB/s And TCP-NFS with MTU 1500: test2:~#12: mount_nfs -T 10.0.0.2:/samsung /samsung/ test2:~#13: dd if=/dev/zero of=/samsung/testfile bs=8k ^C19352+0 records in 19352+0 records out 158531584 bytes transferred in 12.093529 secs (13108794 bytes/sec) - ~ 13MB/s GGATE with default MTU of 1500, polling disabled: test2:~#14: dd if=/dev/zero of=/samsung/testfile bs=64k ^C971+0 records in 970+0 records out 63569920 bytes transferred in 6.274578 secs (10131346 bytes/sec) - ~ 10M/s Conclusion: *** - It seems that GEOM_GATE is less efficient with GigaBit (em) than NFS via TCP is. - em seems to have problems with MTU greater than 1500 - UDP seems to have performance disadvantages over TCP regarding NFS which should be vice versa AFAIK - polling and em (GbE) with HZ=256 is definitly no good idea, even 10Base-2 can compete - NFS over TCP with MTU of 16114 gives the maximum transferrate for large files over GigaBit Ethernet with a value of 17MB/s, a quarter of what I'd expect with my test equipment. - overall network performance (regarding large file transfers) is horrible Please, if anybody has the knowledge to dig into these problems, let me know if I can do any tests to help getting ggate and NFS useful in fast 5.3-stable environments. Best regards, -Harry pgpDMfUm380pz.pgp Description: PGP signature
Re: serious networking (em) performance (ggate and NFS) problem
Am Donnerstag, 18. November 2004 00:17 schrieb Sean McNeil: On Wed, 2004-11-17 at 23:57 +0100, Emanuel Strobl wrote: Dear best guys, I really love 5.3 in many ways but here're some unbelievable transfer rates, after I went out and bought a pair of Intel GigaBit Ethernet Cards to solve my performance problem (*laugh*): (In short, see *** below) [...] Conclusion: *** - It seems that GEOM_GATE is less efficient with GigaBit (em) than NFS via TCP is. - em seems to have problems with MTU greater than 1500 - UDP seems to have performance disadvantages over TCP regarding NFS which should be vice versa AFAIK - polling and em (GbE) with HZ=256 is definitly no good idea, even 10Base-2 can compete - NFS over TCP with MTU of 16114 gives the maximum transferrate for large files over GigaBit Ethernet with a value of 17MB/s, a quarter of what I'd expect with my test equipment. - overall network performance (regarding large file transfers) is horrible Please, if anybody has the knowledge to dig into these problems, let me know if I can do any tests to help getting ggate and NFS useful in fast 5.3-stable environments. I am very interested in this as I have similar issues with the re driver. It it horrible when operating at gigE vs. 100BT. Have you tried plugging the machines into a 100BT instead? No, because I observed similar bad performance with my fileserver which is almost the same HW and it's em (Intel GbE) is connected to the local 100baseTX segment. I explicitly avoided to go via any switch/hub to eliminate further problems. I wonder if anybody has ever been able to transfer more than 17MB/s via IP anyway? I need this performance for mirroring via ggate, so I'm thinking about fwe (IP over Firewire). Perhaps somebody has tried this already? If fwe gives reasonable transferrates I guess the perfomance problem won't be found in ethernet but in IP. Thanks, -Harry Cheers, Sean pgp2Ebov1BURO.pgp Description: PGP signature
Re: serious networking (em) performance (ggate and NFS) problem
Am Donnerstag, 18. November 2004 00:33 schrieb Scott Long: Emanuel Strobl wrote: Dear best guys, I really love 5.3 in many ways but here're some unbelievable transfer rates, after I went out and bought a pair of Intel GigaBit Ethernet Cards to solve my performance problem (*laugh*): (In short, see *** below) [...] - overall network performance (regarding large file transfers) is horrible Please, if anybody has the knowledge to dig into these problems, let me know if I can do any tests to help getting ggate and NFS useful in fast 5.3-stable environments. if_em in 5.3 has a large performance penalty in the common case due to a programming error. I fixed it in 6-CURRENT and 5.3-STABLE. You might want to try updating to the RELENG_5 branch to see if you get better results. The test machines work with RELENG_5 from today. When have you merged the fixes exactly? Thanks a lot, -Harry Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp2ORyTWPZnj.pgp Description: PGP signature
Re: serious networking (em) performance (ggate and NFS) problem
Am Donnerstag, 18. November 2004 01:01 schrieb Chuck Swiger: Emanuel Strobl wrote: [ ... ] Tests were done with two Intel GigaBit Ethernet cards (82547EI, 32bit PCI Desktop adapter MT) connected directly without a switch/hub If filesharing via NFS is your primary goal, it's reasonable to test that, GEOM_GATE is my primary goal, and I can remember that when Pavel wrote this great feature, he took care about performance and easyly outperformed NFS (with 100baseTX AFAIK) however it would be easier to make sense of your results by testing your network hardware at a lower level. Since you're already running portmap/RPC, consider using spray to blast some packets rapidly and see what kind of bandwidth you max out using that. Or use ping with -i -s set to reasonable values depending on whether you're using jumbo frames or not. If the problem is your connection is dropping a few packets, this will show up better here. Using ping -f is also a pretty good troubleshooter. If you can dig up a gigabit switch with management capabilities to test with, taking a look at the per-port statistics for errors would also be worth doing. A dodgy network cable can still work well enough for the cards to have a green link light, but fail to handle high traffic properly. I'll do some tests regarding these issues to make sure I'm not suffering from ill conditions, but I'm quite sure my testbed's feeling fine. I don't have one of these nice managed GigaBit switches, just a x-over cable [ ... ] - em seems to have problems with MTU greater than 1500 Have you tried using an MTU of 3K or 7K? I also seem to recall that there were performance problems with em in 5.3 and a fix is being tested in -CURRENT. [I just saw Scott's response to the list, and your answer, so maybe nevermind this point.] - UDP seems to have performance disadvantages over TCP regarding NFS which should be vice versa AFAIK Hmm, yeah...again, this makes me wonder whether you are dropping packets. NFS over TCP does better than UDP does in lossy network conditions. Of course, but If I connect two GbE cards (wich implies that auto-mdi-X and full duplex is mandatory in 1000baseTX mode) I don't expect any UDP packet to get lost. But I'll verify tomorrow. - polling and em (GbE) with HZ=256 is definitly no good idea, even 10Base-2 can compete You should be setting HZ to 1000, 2000, or so when using polling, and a Yep, I know that HZ set to 256 with polling enabled isn't really useful, but I don't want to drive my GbE card in polling mode at all, instead I try to prevent my machine from spending time doing nothing, so HZ shouldn't be too high. Thank you, -Harry higher HZ is definitely recommmended when you add in jumbo frames and GB speeds. pgpFnJcrwRTMt.pgp Description: PGP signature
Re: preemption stable under 5.3?
Am Montag, 8. November 2004 11:56 schrieb Mipam: Hi, Is the preemption stable under 5.3 release? Can i savely enable it under 5.3? Latest i heard that in combination with the ule scheduler it didnt work well and wasnt stable. ULE was disabled and can't be compiled with 5.3, PREEMPTION and 4BSD scheduler are doing fine. -Mano Bye, Mipam. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] pgpWqp0pdf19T.pgp Description: PGP signature
