Re: 6.3-p5 watchdog timer not being disabled
Le Wed, 08 Oct 2008 15:07:06 -0400, Stephen Clark <[EMAIL PROTECTED]> a écrit : > Hello List, > > We have 2 different platforms that we are trying to use the watchdog > timer and watchdogd program on. One is a Soekris 5501: > CPU: Geode(TM) Integrated Processor by AMD PCS (433.25-MHz 586-class > CPU) Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 >Features=0x88a93d >AMD Features=0xc040 > The other is a: > CPU: VIA C3 Nehemiah+RNG (1002.28-MHz 686-class CPU) >Origin = "CentaurHauls" Id = 0x694 Stepping = 4 >Features=0x380b03d > > According to the manpage on watchdogd if is killed with either SIGTERM > or SIGINT it is suppose to disable the watchdog timer in the kernel so > the system won't reboot. > > On both of the above platforms this does not work and the platforms > reboot when watchdogd is killed with a kill pid, > after the timeout value (-t) that had been specified to watchdogd > when starting it has elapsed. > t > Am I misunderstanding how this is suppose to work? No, i have tested on my net5501 on freebsd-current. It works. Can you try with watchdog -d -t followed by a watchdog -t 0 to disable the watchdog ? There is a problem on the net5501 when you disable and then re-enable the watchdog after the timer has elapsed: the box reboots immediatly. But you can disable the timer. Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-p5 watchdog timer not being disabled
Le Fri, 10 Oct 2008 09:08:47 -0400, Stephen Clark <[EMAIL PROTECTED]> a écrit : > >> On both of the above platforms this does not work and the platforms > >> reboot when watchdogd is killed with a kill pid, > >> after the timeout value (-t) that had been specified to watchdogd > >> when starting it has elapsed. > >> t > >> Am I misunderstanding how this is suppose to work? > > > > No, i have tested on my net5501 on freebsd-current. It works. > > > > Can you try with watchdog -d -t followed by a watchdog -t 0 > > to disable the watchdog ? > > > > There is a problem on the net5501 when you disable and then > > re-enable the watchdog after the timer has elapsed: the box reboots > > immediatly. But you can disable the timer. > > > > Regards. > > > You are correct if I kill watchdogd then run watchdog -t 0 the box > does not reboot. The problem is the with the watchdogd program if it > is killed with a sigtint or sigterm it is suppose to disable the > watchdog timer and exit. It is not appear to be disabling the timer, > because my box is rebooting. It works fine for me on Current, I don't know why this don't work on RELENG_6. The code of watchdogd looks to be the same. Sorry, i can't help more. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: visibility of release process
Le Tue, 9 Dec 2008 11:16:57 +0100, Ruben van Staveren <[EMAIL PROTECTED]> a écrit : > > Sure, but show me how to go to http://svn.freebsd.org/viewvc/base/ > > and see commit log per branch or any other way to see what is > > going on in a branch. Fisheye gives you that in a really clear way > > and it costs nothing to add another option for users. > > Though experimental, I'm greatly enjoying > http://www.secnetix.de/olli/FreeBSD/svnews/?p=/stable/7 Nice. There is also http://freshbsd.org/ (really cool IMHO). Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.1-RC1 Available...
Le Tue, 09 Dec 2008 21:39:26 -0500, Ken Smith a écrit : Hello, > So... Two show-stoppers, one Security Advisory, and one "Gee. Did we > really implement that new interface that way? That needs a bit more > work." later... Can we know what were these two show-stoppers? In the past there were some informations about show stoppers on the FreeBSD's web site but i can't find them. I'm asking because i run 7.1 since the -PRERELEASE and it looks solid as a rock. Thank you all for this new release. Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: USB devices fail to attach as umass scsi da[n]
Le Fri, 16 Jan 2009 14:44:59 -0500, grarpamp a écrit : > GENERIC, RELENG_7 a few days past the 7.1 release. > SuperMicro 370DER motherboard, most recent bios. > The Nikon is set to mass storage. The RCA has no such option. > Both have the latest firmware. > > By the way, the RCA records natively in mp3 format. Handy as most > seem to use some closed format. Worth a try if you need one. > > # camcontrol devl - should be: (pass2,da2) when attach is complete > scbus2 on umass-sim0 bus 0: > < RCA_TKCF2494_US 1.00>at scbus2 target 0 lun 0 > (da2,pass2) > > # dmesg - reordered a bit > umass0: addr 2> on uhub0 > umass0:2:0:-1: Attached to scbus2 > pass2 at umass-sim0 bus 0 target 0 lun 0 > pass2: < RCA_TKCF2494_US 1.00> Removable Direct Access SCSI-0 device > pass2: 1.000MB/s transfers > GEOM: da2 at umass-sim0 bus 0 target 0 lun 0 > new disk da2 > da2: < RCA_TKCF2494_US 1.00> Removable Direct Access SCSI-0 device > da2: 1.000MB/s transfers > da2: 122MB (251136 512 byte sectors: 64H 32S/T 122C) > > (da2:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > status == 0x0 You can try to add a quirk for this device : http://www.root.org/~nate/freebsd/scsi/quirks.html [not sure if this is uptodate, i did it in the past (RELENG_5/6) for my mp3 player] I would start with a DA_Q_NO_SYNC_CACHE quirk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[7.1] sysinstall fdisk breaks Mac Os X bootcamp partitions
Hi, I've installed FreeBSD on my MacBook Pro via bootcamp and sysinstall breaks the partitions: Mac os X is not able to see his partition any more. Only the freebsd slice is bootable. - bootcamp to make a 'windows' (tm) partition, - boot on the FreeBSD's dvd and install it. I didn't notice when i made the installation but the 7.1 dvd see the partitions as: NamePtype DescSubtype - 12 unused 0 ad4p1 5 unknown 0 ad4p2 5 unknown 0 - 12 unused 0 ad4p3 5 unknown 0 - 12 unused 0 FreeBSD 7.0 see: NamePtype DescSubtype - 12 unused 0 ad4s2 4 unknown 175 - 12 unused 0 ad4s3 7 fat 11 - 12 unused 0 And the installation works fine with 7.0 (on ad4s3) I've updated to 7.1-STABLE (kernel GENERIC) and the sysinstall's fdisk now see the drive exactly like 7.0. Hmmm... Well, do not use 7.1 to install FreeBSD on a Mac via bootcamp. Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Backport of glxsb(4) to RELENG_6
Hi, I've backported the glxsb(4) driver to RELENG_6 (to use it on FreeNAS by instance). http://user.lamaiziere.net/patrick/glxsb-6-100209.tar.gz I am not able to test it, but I hope it will work. You can test with openssl: openssl enc -e -aes-128-cbc -in file -out file.enc -k abcdefgh -nosalt -engine cryptodev Please tell me if it works or not. Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Backport of glxsb(4) to RELENG_6
Le Thu, 12 Feb 2009 22:34:43 +0100, Lars Engels : Hi, > I just tried it, but I get this message: > glxsb0: mem > 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 > glxsb0: cannot allocate DMA memory of 32768 bytes (12) I think you are very low on memory and the driver cannot allocate his DMA-able buffer (error 12=ENOMEM) This is not really a bug. But i've found another problem related to the taskqueue. I'm doing a fake driver to be able to test on a vmware machine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Backport of glxsb(4) to RELENG_6
Le Fri, 13 Feb 2009 15:43:33 +0100, Patrick Lamaizière : > Le Thu, 12 Feb 2009 22:34:43 +0100, > Lars Engels : > > Hi, > > > I just tried it, but I get this message: > > glxsb0: mem > > 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 > > > glxsb0: cannot allocate DMA memory of 32768 bytes (12) > > I think you are very low on memory and the driver cannot allocate his > DMA-able buffer (error 12=ENOMEM) > > This is not really a bug. To Lars: Yes it should work at bootime. You must also load the module cryptodev.ko to use it with openssl. > But i've found another problem related to > the taskqueue. > > I'm doing a fake driver to be able to test on a vmware machine. I've tested most of the driver and I think (hope) this is ok. http://user.lamaiziere.net/patrick/glxsb-6-130209.tar.gz Let me know how it works. Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD CVS problem ?
Hi, I've just found that the files for glxsb(4) in RELENG_7 are older than in RELENG_7_1. I don't think this is normal? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/glxsb/glxsb.c?only_with_tag=RELENG_7 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/glxsb/glxsb.c?only_with_tag=RELENG_7_1 RELENG_7_1 contains changes made by philip@ in SVN rev 185021 RELENG_7 contains an older version SVN rev 181919 on 2008-08-20 11:33:13Z by philip If you know how solve this, thanks. Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Backport of glxsb(4) to RELENG_6
Le Sat, 21 Feb 2009 12:27:02 +0100, Lars Engels : > > I've tested most of the driver and I think (hope) this is ok. > > > > http://user.lamaiziere.net/patrick/glxsb-6-130209.tar.gz > > > > Let me know how it works. > > Sorry for the late reply. I just tried the new version (thanks for > compiling, stas :) ) and it works now: > glxsb0: mem > 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 > > moe:~# geli list > Geom name: mirror/dataraid1.eli > EncryptionAlgorithm: AES-CBC > KeyLength: 128 > Crypto: hardware > [...] > > But the speed is the same. I still only get ~1.2MB/s transfer speed > over the net. With my Soekris net5501, without the driver I've got around 3MB/s with sftp and around 5MB/s with the driver. On 7.X you need to patch openssl to make it use the crypto framework by default, don't know for 6.X > However, this doesn't seem to be related to geli. The cpu is pretty > much idling: I tested with geli (on an usb drive) and I didn't notice any improvement too. I think that the crypto stuff is not the limiting factor but the drive's speed. Anyway the driver should save some load on the CPU. > last pid: 2769; load averages: 0.06, 0.10, 0.08 up 0+00:18:04 > 12:23:07 39 processes: 1 running, 38 sleeping > CPU: 0.8% user, 0.0% nice, 16.7% system, 9.3% interrupt, 73.2% idle > Mem: 25M Active, 100M Inact, 35M Wired, 6192K Cache, 27M Buf, 588K > Free You can see the driver's CPU usage with top S H (the glxsb0 taskq entry) > Anyways, thank you for your work on backporting the driver, > Patrick! :) Enjoy :) Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[7-STABLE] ping -s 4000 with ipsec panic
[FreeBSD 7-STABLE/i386] Hello, I've got a 100 % reproductible panic with ipsec when using a 'ping -s 4000'. It works without ipsec My ipsec setup is very simple, i just use setkey: /etc/ipsec.conf flush; spdflush; add 192.168.1.21 192.168.1.200 esp 1011 -E rijndael-cbc "0123456789012345"; add 192.168.1.200 192.168.1.21 esp 1012 -E rijndael-cbc "0123456789012345"; spdadd 192.168.1.200 192.168.1.21 any -P out ipsec esp/transport//require; spdadd 192.168.1.21 192.168.1.200 any -P in ipsec esp/transport//require; I tried to use des-cbc with the same panic. Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4100be00 fault code = supervisor read, page not present instruction pointer = 0x20:0xc079985e stack pointer = 0x28:0xd61a0744 frame pointer = 0x28:0xd61a076c 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 = 1175 (ping) trap number = 12 panic: page fault Uptime: 9m5s Physical memory: 503 MB Dumping 87 MB: 72 56 40 24 8 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0556273 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc055646f in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc079b91c in trap_fatal (frame=0xd61a0704, eva=1090567680) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc079bba0 in trap_pfault (frame=0xd61a0704, usermode=0, eva=1090567680) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc079c529 in trap (frame=0xd61a0704) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0789f2b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc079985e in generic_bcopy () at /usr/src/sys/i386/i386/support.s:498 #8 0xc1f7267e in ?? () #9 0x8fb82d87 in ?? () #10 0x361fe9de in ?? () #11 0x39402686 in ?? () #12 0x0fa0 in ?? () #13 0xc29cf380 in ?? () #14 0xc2ea9654 in ?? () #15 0x in ?? () #16 0xd61a095c in ?? () #17 0xc0700746 in crypto_invoke (cap=0x8, crp=0xd61a0950, hint=-1616994916) at cryptodev_if.h:53 Previous frame inner to this frame (corrupt stack?) (kgdb) - Thansk, regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [7-STABLE] ping -s 4000 with ipsec panic
Le Fri, 13 Jun 2008 01:57:35 +0200, Kris Kennaway <[EMAIL PROTECTED]> a écrit : Hello, [...] > > #17 0xc0700746 in crypto_invoke (cap=0x8, crp=0xd61a0950, > > hint=-1616994916) at cryptodev_if.h:53 > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) > > Unfortunately the trace is bogus. Try to rebuild with -O instead of > -O2 and reproduce the panic. Hmm, i've got no luck with -O. I made few tests and the panic occurs with a -s of 3989 bytes. ping -s 3988 => ok ping -s 3989 => panic The coredump seems to be ok. http://user.lamaiziere.net/patrick/coredump.txt I will try with a kernel and DEBUG_REDZONE and INVARIANT. --- Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x9350ef1e fault code = supervisor read, page not present instruction pointer = 0x20:0xc05a0579 stack pointer = 0x28:0xd61635cc frame pointer = 0x28:0xd61635d0 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 = 1101 (ping) trap number = 12 panic: page fault Uptime: 7m47s Physical memory: 503 MB Dumping 88 MB: 73 57 41 25 9 #0 doadump () at pcpu.h:195 in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0556273 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc055646f in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc079b91c in trap_fatal (frame=0xd616358c, eva=2471554846) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc079bba0 in trap_pfault (frame=0xd616358c, usermode=0, eva=2471554846) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc079c529 in trap (frame=0xd616358c) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0789f2b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc05a0579 in mb_dupcl (n=0xc2b02000, m=0xc2b02d00) at /usr/src/sys/kern/uipc_mbuf.c:293 #8 0xc05a157a in m_copym (m=0xc2b02d00, off0=2980, len=3, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:570 #9 0xc0614055 in ip_fragment (ip=0xc2e5a038, m_frag=0xd61636d0, mtu=1500, if_hwassist_flags=7, sw_csum=0) at /usr/src/sys/netinet/ip_output.c:728 #10 0xc0614d38 in ip_output (m=0xc2b02600, opt=0x0, ro=0xd6163694, flags=2, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:567 #11 0xc06acd9d in ipsec_process_done (m=0xc2b02600, isr=0xc2bacd80) at /usr/src/sys/netipsec/ipsec_output.c:177 #12 0xc06bbf5c in esp_output_cb (crp=0xc2e5c708) at /usr/src/sys/netipsec/xform_esp.c:965 #13 0xc06ff730 in crypto_done (crp=0xc2e5c708) at /usr/src/sys/opencrypto/crypto.c:1148 #14 0xc0702afe in swcr_process (dev=0xc29cf380, crp=0xc2e5c708, hint=0) at /usr/src/sys/opencrypto/cryptosoft.c:975 #15 0xc0700746 in crypto_invoke (cap=0xc29cf380, crp=0xc2e5c708, hint=0) at cryptodev_if.h:53 #16 0xc070118c in crypto_dispatch (crp=0xc2e5c708) at /usr/src/sys/opencrypto/crypto.c:798 #17 0xc06bc5c6 in esp_output (m=0xc2b02600, isr=0xc2bacd80, mp=0x0, skip=20, protoff=9) at /usr/src/sys/netipsec/xform_esp.c:875 #18 0xc06ad112 in ipsec4_process_packet (m=0xc2b02600, isr=0xc2bacd80, flags=32, tunalready=0) at /usr/src/sys/netipsec/ipsec_output.c:491 #19 0xc0612f95 in ip_ipsec_output (m=0xd6163b04, inp=0xc2e07870, flags=0xd6163b10, error=0xd6163ae4, ro=0xd6163b0c, iproute=0xd6163ac8, dst=0xd6163ae0, ia=0xd6163adc, ifp=0xd6163aec) at /usr/src/sys/netinet/ip_ipsec.c:331 #20 0xc0614ab9 in ip_output (m=0xc2b02600, opt=0x0, ro=0xd6163ac8, flags=32, imo=0x0, inp=0xc2e07870) at /usr/src/sys/netinet/ip_output.c:420 #21 0xc0615e1b in rip_output (m=0xc2b02600, so=0xc2ddfad4, dst=352430272) at /usr/src/sys/netinet/raw_ip.c:336 #22 0xc0615efc in rip_send (so=0xc2ddfad4, flags=0, m=0xc2b02600, nam=0xc29f9800, control=0x0, td=0xc2b77000) at /usr/src/sys/netinet/raw_ip.c:806 #23 0xc05a97f5 in sosend_generic (so=0xc2ddfad4, addr=0xc29f9800, uio=0xd6163be8, top=0xc2b02600, control=0x0, flags=0, td=0xc2b77000) at /usr/src/sys/kern/uipc_socket.c:1240 #24 0xc05a580f in sosend (so=0xc2ddfad4, addr=0xc29f9800, uio=0xd6163be8, top=0x0, control=0x0, flags=0, td=0xc2b77000) at /usr/src/sys/kern/uipc_socket.c:1286 #25 0xc05abf16 in kern_sendit (td=0xc2b77000, s=3, mp=0xd6163c64, flags=0, control=0x0, segflg=UIO_USERSPACE) at /usr/src/sys/kern/uipc_syscalls.c:789 #26 0xc05af031 in sendit (td=0xc2b77000, s=3, mp=0xd6163c64, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:730 #27 0xc05af148 in sendto (td=0xc2b77000, uap=0xd6163cfc) at /usr/src/sys/kern/uipc_syscalls.c:841 #28 0xc079bef5 in syscall (frame=0xd6163d38) at /usr/src/sys/i386/i386/trap.c:1035 #29 0xc0789f90 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #30 0x0033 in ?? () (kgdb) quit -- Thanks, regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/free
Re: [7-STABLE] ping -s 4000 with ipsec panic
Le Sat, 14 Jun 2008 01:52:29 +0200, Patrick Lamaizière <[EMAIL PROTECTED]> a écrit : > I made few tests and the panic occurs with a -s of 3989 bytes. > > ping -s 3988 => ok > ping -s 3989 => panic > > The coredump seems to be ok. > http://user.lamaiziere.net/patrick/coredump.txt > > I will try with a kernel and DEBUG_REDZONE and INVARIANT. With INVARIANT there is an assertion that failed in the ipsec code. I've filled a PR : http://www.freebsd.org/cgi/query-pr.cgi?pr=124609 Thank you, regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AMD Geode LX crypto accelerator (glxsb)
Le Fri, 6 Jun 2008 23:41:35 +0200, Patrick Lamaizière <[EMAIL PROTECTED]> a écrit : Hello, > I'm trying to port the glxsb driver from OpenBSD to FreeBSD 7-STABLE > (via the NetBSD port). > " The glxsb driver supports the security block of the Geode LX > series processors. The Geode LX is a member of the AMD Geode family > of integrated x86 system chips. > > Driven by periodic checks for available data from the generator, > glxsb supplies entropy to the random(4) driver for common usage. > > glxsb also supports acceleration of AES-128-CBC operations for > crypto(4)." Well, I hope this is the final version. http://user.lamaiziere.net/patrick/glxsb-220608.tar.gz I added a patch for FreeBSD 6 but i'am not able to test it. On 7-STABLE, I've tested with hundred openssl encryptions and some flood pings under ipsec in the background. Looks good for me. If someone can test and review it, it would be cool. Thanks, Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem with nVidia nForce CK804 SATA300 controller
Le Fri, 20 Jun 2008 07:34:35 -0300, JoaoBR <[EMAIL PROTECTED]> a écrit : > my amd64 crashs under heavy disk i/o as each night at 0300 daily > cron, also often after some minutes when compiling world. Also with > kde and after some flash videos (youtube) or large file copying > > I do not see this problem with other sata controllers or same > hardware and a scsi adapter and this sata disabled what makes me > believe it is related to this specific sata controller > > this sata controller is part of some ASUS (M2N SLI Deluxe) or Epox > AM2 MBs > > there is no panic at all, some seconds of hard freeze, on desktop > machine the mouse still moves some seconds and reset, no log either, > no crash dump, nothing > > I have no irq conflict, latest bios onboard, I also exchanged other > hw parts with no success. > > Any idea? I've seen this kind of thing on the nvidia chipset, could you try without apic ? I'm not sure if you can disable the apic on amd64. It is just an idea! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AMD Geode LX crypto accelerator (glxsb)
Le Sun, 22 Jun 2008 19:40:04 +0200, Ivan Voras <[EMAIL PROTECTED]> a écrit : > Ivan Voras wrote: > > > The results are practically the same. > > On the other hand: > > ursaminor:~/admin/glxsb> dd if=/dev/zero bs=4k count=10 | openssl > enc -aes-128-cbc -e -out /dev/null -nosalt -k abcdefhij > 10+0 records in > 10+0 records out > 40960 bytes transferred in 77.653939 secs (5274684 bytes/sec) > > ursaminor:~/admin/glxsb> dd if=/dev/zero bs=4k count=10 | openssl > enc -aes-128-cbc -e -out /dev/null -nosalt -k abcdefhij -engine > cryptodev engine "cryptodev" set. > 10+0 records in > 10+0 records out > 40960 bytes transferred in 21.486846 secs (19062826 bytes/sec) > > So I guess it works. Any idea why "openssl speed" doesn't show it? On FreeBSD 7, OpenSSL does not use the cryptodev engine by default. This is a known problem. See http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-06/msg00076.html openssl speed -evp aes-128-cbc -elapsed -engine cryptodev ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AMD Geode LX crypto accelerator (glxsb)
Le Sun, 22 Jun 2008 21:20:02 +0200, "Ivan Voras" <[EMAIL PROTECTED]> a écrit : Hi, > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes256 bytes 1024 bytes > 8192 bytes aes-128 cbc 5359.57k 5577.49k 5654.53k > 5639.81k 5679.65k aes-128-cbc394.62k 1471.97k > 5457.89k15097.21k25895.72k I've got the same results. The encryption of a file of 360 MBytes takes around 20s with the hardware and 1m10s by software. I am playing to overload my box (a soekris net5501) with ping floods on ipsec (hmac-md5 and rijndael) by a modern computer. With four 'ping -f -s 3000', 'top' reports CPU "0.4% user 0.0 nice 1.6% system, 90.3% interrupt, 7.8% idle". With five 'ping', top does not run, and the kernel does not display the message 'limiting icmp ping response to 300 to 200' anymore too (on the serial console). With the hardware, i can use 8 flood pings without any problem. Top shows CPU: 0.0% user, 0.0% nice, 33.5% system, 12.5% interrupt, 54.1% idle And the kernel displays "limiting icmp ping response from 900 to 200 packets/s.", instead '300 to 200'. So it seems there is a real improvement. Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AMD Geode LX crypto accelerator (glxsb)
Le Wed, 09 Jul 2008 15:31:30 -0400, Mike Tancsa <[EMAIL PROTECTED]> a écrit : > Without the module loaded, I can do something simple like > > > # sh s > # cat s > MEOUTSIDE=64.x.x.x > MEINSIDE=192.168.5.0/24 > REMOTEOUTSIDE=64.y.y.y > REMOTEINSIDE=192.168.1.0/24 > IPSECKEY=zxzpprlNH61N11SGfrCa8dxZ > > > setkey -c < add $MEOUTSIDE $REMOTEOUTSIDE esp 1049 > -m any -E rijndael-cbc "$IPSECKEY"; > add $REMOTEOUTSIDE $MEOUTSIDE esp 1049 > -m any -E rijndael-cbc "$IPSECKEY"; > spdadd $MEINSIDE $REMOTEINSIDE any -P > out ipsec esp/tunnel/$MEOUTSIDE-$REMOTEOUTSIDE/require; > spdadd $REMOTEINSIDE $MEINSIDE any -P > in ipsec esp/tunnel/$REMOTEOUTSIDE-$MEOUTSIDE/require; > EOF > > > But if I load the glxsb modules, setkey fails on the same policy. > > # setkey -F > # setkey -FP > # setkey -DP > No SPD entries. > # kldload glxsb > # dmesg | tail > vr0: link state changed to DOWN > vr0: link state changed to UP > vr0: promiscuous mode enabled > vr0: promiscuous mode disabled > vr1: promiscuous mode enabled > vr1: promiscuous mode disabled > vr1: promiscuous mode enabled > vr1: promiscuous mode disabled > glxsb0: detached > glxsb0: (AES-128-CBC,RNG)> mem 0xa000-0xa0003fff irq 10 at device 1.2 on > pci0 # sh s > The result of line 1: Invalid argument. > The result of line 2: Invalid argument. > # > > What is the proper AES encryption to use for > IPSEC ? It is rijndael-cbc. > Why is there a difference in syntax ? I don't know. May be the key ? The length of your key is 24 characters, it should be 16 (128 bits). Does it work with a 128 bits key ? My setkey setup is flush; spdflush; add 192.168.1.21 192.168.1.200 esp 1011 -E rijndael-cbc "0123456789012345" -A hmac-sha1 "98765432109876543210"; add 192.168.1.200 192.168.1.21 esp 1012 -E rijndael-cbc "0123456789012345" -A hmac-sha1 "98765432109876543210"; spdadd 192.168.1.200 192.168.1.21 any -P out ipsec esp/transport//require; spdadd 192.168.1.21 192.168.1.200 any -P in ipsec esp/transport//require; Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AMD Geode LX crypto accelerator (glxsb)
Le Wed, 09 Jul 2008 15:31:30 -0400, Mike Tancsa <[EMAIL PROTECTED]> a écrit : > Without the module loaded, I can do something simple like > glxsb0: detached > glxsb0: (AES-128-CBC,RNG)> mem 0xa000-0xa0003fff irq 10 at device 1.2 on > pci0 # sh s > The result of line 1: Invalid argument. > The result of line 2: Invalid argument. > > What is the proper AES encryption to use for > IPSEC ? Why is there a difference in syntax > ? I've found, i think. The Geode handles only AES with a 128 bits key. When setkey/ipsec opens a crypto session, the driver returns an error (EINVAL) if the key length is != 128. So setkey fails. There is no way to tell to the crypto framework that we can do only AES with 128 bits keys. It is a problem in this case. I don't have any solution, I can just add a BUG section in the man page for this case. Thank you for the report. Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[7-STABLE] ndis interacts badly with powerd
Hi, [7-STABLE/i386-SMP] When I enable powerd, ndis takes all the CPU. Powerd alone and ndis alone works fine. The kernel threads "Windows DCP0" and "ndis0 taskq" run at 100%. But the machine is still running (but is very very slow), I can kldunload my ndis module and all is ok. I tried with a kernel (GENERIC) without SMP but there is the same problem. Any idea? Thanks. CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz 686-class CPU) cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 Ndis: ndis0: mem 0x9730-0x9730 irq 16 at device 0.0 on pci11 ndis0: [ITHREAD] ndis0: NDIS API version: 5.1 NDIS: open file /compat/ndis/preparse.ini failed: 2 NDIS: open file /compat/ndis/regAdd.txt failed: 2 ndis0: WARNING: using obsoleted if_watchdog interface ndis0: Ethernet address: 00:1e:52:76:65:60 NDIS: open file /compat/ndis/preparse.ini failed: 2 NDIS: open file /compat/ndis/regAdd.txt failed: 2 ndis0: setting BSSID failed: 45 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [7-STABLE] ndis interacts badly with powerd
Le Sun, 1 Mar 2009 13:00:18 +0100, Patrick Lamaizière : > [7-STABLE/i386-SMP] > > When I enable powerd, ndis takes all the CPU. Powerd alone and ndis > alone works fine. > > The kernel threads "Windows DCP0" and "ndis0 taskq" run at > 100%. But the machine is still running (but is very very slow), I can > kldunload my ndis module and all is ok. > > I tried with a kernel (GENERIC) without SMP but there is the same > problem. > > Any idea? Thanks. The problem was simply that the frequency was lowered too many. I have to limit the frequency with debug.cpufreq.lowest. Sorry! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [7-STABLE] ndis interacts badly with powerd
Le Tue, 3 Mar 2009 23:51:06 +0100, "Paul B. Mahol" : > > The problem was simply that the frequency was lowered too many. I > > have to limit the frequency with debug.cpufreq.lowest. > > How much small it was? > powerd -b min with 125 freq works fine on CURRENT with ndis for me > (except that in such case watchdog errors are displayed on console if > connection is heavily used) > Note that ndis watchdog stuff have been rewritten on CURRENT. Here I've got some troubles under 400 MHz, at 400 MHz I'm able to unload the ndis module, at 100 MHz the machine hangs (must use a hard shutdown) I've set debug.cpufreq.lowest=600 Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GCC build causes panic: page already inserted
Le Mon, 16 Mar 2009 14:49:43 -0600, Dan Allen : > > For now, can you just provide the stack trace? > > How do I do this? Is there a tool that I run against the core dump? See http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ipw(4) breaking under load
Le Vendredi 19 Mai 2006 18:27, Ulrich Spoerlein a écrit : > Hi guys, Hello, > is it just me, or is no one actually using ipw(4) under 6.1? Anyway, I > set up a FreeBSD based AP using an ural(4) device. I'm connecting to it > via laptop and ipw(4). This works fine, as long as you don't push it. > > Transferring some files via NFS gives me a lousy 100kB/s transfer rate, > which quickly stalls and the connection wedges. Syslog reports: > May 19 17:29:48 roadrunner kernel: ipw0: fatal error I've got this error with the iwi driver too (Intel 2200 BG). But not often (one or two times a week). It seems not related to the network load for me. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6 has problems with booting
Le Lundi 18 Juillet 2005 10:50, Jonathan Weiss a écrit : Hi, > When I do a boot in safe mode, everything is ok. > > Attachted is the dmesg from the verbose boot. Did you try without acpi ? I've got a similar problem with a nforce2 based mother board. Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 RC1 usbd.conf (and installation comments)
Le Mercredi 26 Octobre 2005 02:46, Joel Hatton a écrit : > most files in /etc/rc.d changed, so installing them all with > mergemaster was laborious - a note in UPDATING similar to that for > 5.x: > > "The simplest solution is an 'rm -rf /etc/rc.d/*' and then > 'mergemaster -i'." Yes but be carefull, by sample amavisd-new uses scripts in /etc/rc.d and not in /usr/local/etc/rc.d. "Why the mail server does not work anymore ?" Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i915drm
Le Dimanche 18 Décembre 2005 01:31, Gianmarco a écrit : > I am trying to use the latest drm hook for i915, but I get this error: > > drmsub0: port 0x1800-0x1807 mem > 0xb008-0xb00f,0xc000-0xcfff,0xb000-0xb003 irq 16 > at device 2.0 on pci0 > error: [drm:pid0:drm_load] *ERROR* Card isn't AGP, or couldn't initialize > AGP. device_attach: drmsub0 attach returned 12 > pci0: at device 2.1 (no driver attached) > > > Any idea ? > > I have added to my kernel: > > device agp # support several AGP chipsets > device drm # DRM core module required by DRM drivers > device i915drm # Intel i830 through i915 Just put agp, Xorg will load i915.ko. I've got the same problem. But dri does not work, Xorg seems to look for a /dev/dri/card0 and i've got only one device /dev/dri/card1 ? Xorg.log: (II) I810(0): Allocated 64 kB for the scratch buffer at 0x7fee000 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed [drm] failed to load kernel module "i915" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i915drm
Le Lundi 19 Décembre 2005 21:35, Oliver Fromme : > Patrick Lamaizière <[EMAIL PROTECTED]> wrote: > > But dri does not work, Xorg seems to look for a /dev/dri/card0 and > > i've got only one device /dev/dri/card1 ? > Strange. It works fine for me: With the patch from Alexey Popov (ftp://213.85.11.250/pub/drm3.patch) i've got the good device /dev/dri/card0 > Are you sure that you're using the latest RELENG_6 _and_ > the latest Xorg development snapshot? You need both for > things to work correctly. Yes i run 6.0-STABLE, graphics/dri-devel (dri-6.2.20050719,1) and x11-server/xorg-server-snap (xorg-server-6.8.99.903) With xorg-server-snap i've got the problem : $ glxgears ERROR: line 125, Function intelInitDriver, File intel_screen.c It seems better with xorg-6.8.2, dri is enabled and glxgears reports a FPS ~1200. I've got 500 FPS without DRI. more info about the chipset: [EMAIL PROTECTED]:2:0: class=0x03 card=0x01641028 chip=0x35828086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated Graphics Device' class= display subclass = VGA Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with new DRI/DRM support for Intel 855GM
Le Mardi 27 Décembre 2005 02:48, Julian Stecklina a écrit : Hello, > I just discovered that the DRM drivers have been updated and my 855GM > is now supported by i915.ko. > > If I load the module, the driver attaches: ... > The problem is easily spotted, as there is only /dev/dri/card1. If I > try to symlink card1 to card0, the kernel says: > error: [drm:pid890:drm_unlock] *ERROR* Process 890 using kernel context 0 Look this thread : http://lists.freebsd.org/pipermail/freebsd-stable/2005-December/020815.html > But anyway: It's very nice to see that 3D acceleration is going to > work Real Soon Now(tm) on my laptop. :-) Yes :) Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i915drm
Le Jeudi 29 Décembre 2005 07:59, Gianmarco Giovannelli a écrit : > The plain xorg 6.8.2 seems not be able to > recognize the card (at least the mine). > Do you have used the patch : > http://apocalyptech.com/linux/nc6120/xorg-6.8.2-i810.patch > to compile it ? No it works out of the box for me. > I think there is a big confusion about this new module (i915). Yes, may be there are many different chipsets for this module ? > I hope that someone (Eric ?:-) take care of all this iussue as ap :-) > > Happy new year to everyone Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i915drm
Le Vendredi 30 Décembre 2005 16:05, Gianmarco Giovannelli a écrit : > Is there anyone here that can share it's > xorg.conf to use something of the new accel features of the card. There are only few parameters, see man i810 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: iwi0 and cvsup, impossible to work toghter
Le Vendredi 30 Décembre 2005 16:12, Gianmarco Giovannelli a écrit : > I am not able to succeded in making a "make update" when I use the iwi0 > card. > > I always get : > "TreeList failed: Network write failure ..." > > Is there someone else that is having the same problem ? Yes, there was a thread about this problem : http://lists.freebsd.org/pipermail/freebsd-current/2005-September/055172.html As a work-around, i use a TCP proxy on my gateway to handle the connection between cvsup and the cvsup server, and cvsup works fine. I don't know why. > Thanks and Happy New Year Happy new year! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: drm problem after portupgrade to Xorg 6.9
Niki Denev : Hello, > I've just upraded my Xorg port to the latest relase 6.9, > and begin to get this when i start X : > > agp0: binding memory at bad offset 0 > error: [drm:pid610:radeon_cp_init] *ERROR* radeon_cp_init called without > lock held > error: [drm:pid610:drm_unlock] *ERROR* Process 610 using kernel context 0 Did you upgrade dri ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
