crash on forwarding ipv6 packets with ipfilter
hello, I got a strange crash which is was happening all along from 5.3. I wasn't mentioning it, because there was 'ipfilter mpsafe fixes' position in 5.4 todo list, but it looks that crash is happening no matter these fixes are on or not. To help with freebsd sourcerouting problems (different default gateways for different interfaces), I tried forwarding ipv6 packets to correct gateway: #v+ weirdo:~$ cat /etc/ipf.rules pass out quick on gif0 to gif1:3ffe:80ef:900:1::1 from 3ffe:80ee:2479::/48 to any #v- I also added routes like `route add gif1:3ffe:80ef:900:1::1 -iface gif1', of course. And here's the crash: I'm using dhcp client to obtain my ipv4 address, which changes over time; when interface is down and there are forwarded packets passing by, system will hang. I'm using x11, symptoms are: stopped mouse cursor and music stopped playing (;-). To reproduce this, simply add a forward rule for ipv6 packets and /etc/rc.d/dhclient stop, or `DOWN' interface in some other way (alhrough i'm no ifconfig expert). I would be very grateful if you would help me this problem, as I'd like to be able to have multiple default gateways for ipv6 tunnels. regards, -- Stanislaw Halik :: http://weirdo.ltd.pl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
MNT_USER?
after doing a mount_nfs as root (from the console or via su), statfs reports
that MNT_USER flags is set! this is also true with 5.4.
is this a bug or feature?
the problem can be seen with:
#include stdio.h
#include fcntl.h
#include sys/param.h
#include sys/mount.h
int main(int argc, char *argv[])
{
struct statfs stbuf;
int fd;
if (argc != 2) {
fprintf(stderr, Usage: noexec directory\n);
return -1;
}
if (statfs(argv[1], stbuf) != 0) {
perror(statfs);
return -1;
}
printf(FLAGS: 0x%08X\n, stbuf.f_flags);
if (stbuf.f_flags MNT_NOEXEC)
printf(MNT_NOEXEC\n);
return 0;
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
ndis with Intel 2915 wireless, getting NDIS ERROR messages and deattach on boot
I'm trying to get my wireless NIC working using the ndis driver, but during boot I get an attach, a stream of what appear to be errors, followed by device_attach: ndis0 attach returned 6. The basic specs for the configuration are: FreeBSD src: RELENG_5 as of 2005/04/30, about 4pm PDT (-0700) Machine: Dell Inspiron 6000 NIC: Intel PRO/Wireless 2915ABG miniPCI (Dell PCI ID) NDIS drivers: Windows 2000 (NDIS 5.0), driver file is w29n50.sys Windows XP (NDIS 5.1), driver file is w29n51.sys I could not find non-NT drivers for this NIC. Both drivers produce the following output during boot: ndis0: Intel(R) PRO/Wireless 2915ABG Network Connection mem 0xdfcfd000-0xdfcfdfff irq 5 at device 3.0 on pci3 ndis0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xdfcfd000 ndis0: [MPSAFE] ndis0: NDIS API version: Either 5.0 or 5.1 depending on driver used ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x2fb ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x2fb ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x2fb ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x2fb ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x2fb ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x2fb ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x2fb ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x191 ndis0: NDIS ERROR: c000138d (unknown error) ndis0: NDIS NUMERRORS: 0 ndis0: init handler failed device_attach: ndis0 attach returned 6 Subsequent boots appear to produce identical data. The dmesg outputs for each driver and the driver files themselves are available upon request. Is this fixed in -current? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Serial ATA
% - snipped I have had really good luck with the 3ware 8xxx cards for some time. A 2 port version can be had for ~$100USD. I have quite a few running 4.x and now RELENG_5 with great results. You can also pull off the SMART info from the drives via the smartmontools as well as monitor the status via CLI and httpd apps. ---Mike Mike, Do you have any information on where I might obtain the 3ware range in the UK. I had a look at their website and they listed a couple of suppliers in the UK, but I can't find any e-shops which sell them. Stuart. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ndis with Intel 2915 wireless, getting NDIS ERROR messages and deattach on boot
Have you tested the iwi-driver? See: http://damien.bergamini.free.fr/ipw/iwi-freebsd.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird jdk14 build
On 01 May 2005 09:20:55 -0400, Lowell Gilbert [EMAIL PROTECTED] wrote: Jayton Garnett [EMAIL PROTECTED] writes: Hello, This weekend i've been reinstalling fbsd on my desktop and while installing /usr/ports/java//jdk14 (yes i downloaded all the files from sun and the patch-kit) While it was compiling I had a syntax error something like expected ( somewhere or other, but i noticed this little message before that error: == Warning: This JDK may be unstable. You are advised to use the native FreeBSD JDK, in ports/java/jdk14. snip No; you need to use Java to build Java. Therefore, the procedure is to use the precompiled Linux jdk to build the native one. Once the native one is built, you can remove the Linux one. To further clarify: That message is being produced while installing a linux JDK, which is needed to bootstrap the new native build. Yes, it's really annoying. To save this annoyance, make a package of it when you are done, merely for your own use, however. the linux JDK can (and should) be 'pkg_deinstall'ed when you are done. pkg_deinstall linux-sun-jdk1.4\* ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Fatal trap on boot with RELENG_5
Hi,
I'm getting a fatal trap shortly after boot on an up to date
5.4-STABLE box that had previously run 4.11-STABLE flawlessly. Without
the debugging options in the kernel the box just locks up. For
reference the motherboard is a Abit VH6.
If you need any more details, please let me know.
Regards,
James.
kernel trap 1 with interrupts disabled
Fatal trap 1: privileged instruction fault while in kernel mode
instruction pointer = 0x8:0xc04feae4
stack pointer = 0x10:0xdc4d9be8
frame pointer = 0x10:0xdc4d9bec
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 11 (idle)
[thread pid 11 tid 13 ]
Stopped at _mtx_unlock_spin_flags+0x30:cmpl$0xc06bc6e4,0(%ebx)
db wh
Tracing pid 11 tid 13 td 0xc19fd480
_mtx_unlock_spin_flags(c06eb9e0,0,c06890ab,68d,c06e8400) at
_mtx_unlock_spin_flags+0x30
witness_lock_list_get(c06ed230,c19fd480,c06e8400,e3,dc4d9c44) at
witness_lock_list_get+0x8d
witness_lock(c06e8400,a,c0682572,e3,dc4d9cb8) at witness_lock+0xae
_mtx_lock_spin_flags(c06e8400,2,c0682572,e3,dc4d9cb8) at
_mtx_lock_spin_flags+0xa4
hardclock(dc4d9cb8) at hardclock+0x4a
clkintr(dc4d9cb8) at clkintr+0x87
intr_execute_handlers(c06d89c0,dc4d9cb8,c19fcc5c,c04f4018,0) at
intr_execute_handlers+0x91
atpic_handle_intr(0) at atpic_handle_intr+0x92
Xatpic_intr0() at Xatpic_intr0+0x20
--- interrupt, eip = 0xc0641ed5, esp = 0xdc4d9cfc, ebp = 0xdc4d9cfc ---
cpu_idle_default(dc4d9d0c,c04f4041,dc4d9d24,c04f3e70,0) at cpu_idle_default+0x5
cpu_idle(dc4d9d24,c04f3e70,0,dc4d9d38,0) at cpu_idle+0x1f
idle_proc(0,dc4d9d38,0,c04f4018,0) at idle_proc+0x29
fork_exit(c04f4018,0,dc4d9d38) at fork_exit+0xa4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xdc4d9d6c, ebp = 0 ---
db
# kgdb kernel.debug /var/crash/vmcore.15
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
#0 doadump () at pcpu.h:160
160 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) where
#0 doadump () at pcpu.h:160
#1 0xc05064e0 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2 0xc050678b in panic (fmt=0xc0673317 from debugger)
at /usr/src/sys/kern/kern_shutdown.c:566
#3 0xc0466c71 in db_panic (addr=-1068504348, have_addr=0, count=-1,
modif=0xdc4d9a40 ) at /usr/src/sys/ddb/db_command.c:435
#4 0xc0466c08 in db_command (last_cmdp=0xc06dcda4, cmd_table=0x0,
aux_cmd_tablep=0xc06a7a3c, aux_cmd_tablep_end=0xc06a7a40)
at /usr/src/sys/ddb/db_command.c:349
#5 0xc0466cd0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
#6 0xc0468855 in db_trap (type=1, code=0) at /usr/src/sys/ddb/db_main.c:221
#7 0xc051c736 in kdb_trap (type=1, code=0, tf=0xdc4d9ba8)
at /usr/src/sys/kern/subr_kdb.c:468
#8 0xc064a7e5 in trap_fatal (frame=0xdc4d9ba8, eva=0)
at /usr/src/sys/i386/i386/trap.c:812
#9 0xc064a39c in trap (frame=
{tf_fs = 24, tf_es = -999423984, tf_ds = -1066532848, tf_edi =
-1066218188, tf_esi = 227, tf_ebp = -598893588, tf_isp = -598893612,
tf_ebx = -1066485280, tf_edx = 1677, tf_ecx = -1066889045, tf_eax =
-1046489984, tf_trapno = 1, tf_err = 0, tf_eip = -
1068504348, tf_cs = 8, tf_eflags = 65666, tf_esp = -1066336984, tf_ss
= -598893560}) at /usr/src/sys/i386/i386/trap.c:622
#10 0xc063abfa in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#11 0x0018 in ?? ()
#12 0xc46e0010 in ?? ()
---Type return to continue, or q return to quit---
#13 0xc06e0010 in default_fkeytab ()
#14 0xc072cd34 in __pcpu ()
#15 0x00e3 in ?? ()
#16 0xdc4d9bec in ?? ()
#17 0xdc4d9bd4 in ?? ()
#18 0xc06eb9e0 in w_lock_list_free ()
#19 0x068d in ?? ()
#20 0xc06890ab in ?? ()
#21 0xc19fd480 in ?? ()
#22 0x0001 in ?? ()
#23 0x in ?? ()
#24 0xc04feae4 in _mtx_unlock_spin_flags (m=0xc06eb9e0, opts=0, file=0x0,
line=0) at /usr/src/sys/kern/kern_mutex.c:387
#25 0xc0525f01 in witness_lock_list_get ()
at /usr/src/sys/kern/subr_witness.c:1677
#26 0xc0524f0a in witness_lock (lock=0xc06e8400, flags=0,
file=0xc0682572 /usr/src/sys/kern/kern_clock.c, line=227)
at /usr/src/sys/kern/subr_witness.c:990
#27 0xc04feaac in _mtx_lock_spin_flags (m=0xc06e8400, opts=2,
file=0xc0682572 /usr/src/sys/kern/kern_clock.c, line=227)
at /usr/src/sys/kern/kern_mutex.c:380
#28 0xc04e2c46 in hardclock (frame=0xdc4d9cb8)
at /usr/src/sys/kern/kern_clock.c:227
#29 0xc064ceef in clkintr (frame=0xdc4d9cb8)
---Type return to continue, or q return to quit---
at
bpf/fxp RELENG_5 LOR
FreeBSD 5.4-STABLE #0: Mon May 2 02:26:10 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/RENE #tcpdump fxp0: promiscuous mode enabled lock order reversal 1st 0xc066de80 bpf global lock (bpf global lock) @ /usr/src/sys/net/bpf.c:385 2nd 0xc14c9264 fxp0 (network driver) @ /usr/src/sys/modules/fxp/../../dev/fxp/if_fxp.c:2394 KDB: stack backtrace: kdb_backtrace(c05fd3e5,c14c9264,c14a47e0,c06fe820,c06fe7bd) at 0xc04b0aee = kdb_backtrace+0x2e witness_checkorder(c14c9264,9,c06fe7bd,95a,c0648ec0) at 0xc04bbb86 = witness_checkorder+0x6a6 _mtx_lock_flags(c14c9264,0,c06fe7bd,95a,c14c9264) at 0xc048a9ca = _mtx_lock_flags+0x8a fxp_ioctl(c14c9000,80206910,cae60aa8,c06212fc,c156d9dc) at 0xc06fe14e = fxp_ioctl+0x5e ifpromisc(c14c9000,0,c06024ea,129,c1cdd200) at 0xc050a358 = ifpromisc+0xe8 bpf_detachd(c1cdd200,0,c06024ea,181,c1bfa528) at 0xc0504d85 = bpf_detachd+0xe5 bpfclose(c1b07700,1,2000,c19d1000,c0628e20) at 0xc0504ff4 = bpfclose+0xb4 spec_close(cae60b70,cae60b98,c0500ba7,cae60b70,1) at 0xc04542d8 = spec_close+0x378 spec_vnoperate(cae60b70,1,c060242a,140,c063ad40) at 0xc0452e58 = spec_vnoperate+0x18 vn_close(c1bfa528,1,c198cd00,c19d1000,c066d240) at 0xc0500ba7 = vn_close+0x67 vn_closefile(c1d82a18,c19d1000,c05f685f,849,c1d82a18) at 0xc0501d34 = vn_closefile+0xc4 fdrop_locked(c1d82a18,c19d1000,c05f685f,834) at 0xc0471cde = fdrop_locked+0xbe fdrop(c1d82a18,c19d1000,c05f685f,77c,cae60c7c,c04bc210,c066d240,cae60c78,c04bbc67,0,c1cdd32c,246,c06212fc,c1cdd32c,3ea,c05f685f,cae60ca0,c048aada,c1cdd32c,1,c05f9016,12b) at 0xc0471c0c = fdrop+0x3c closef(c1d82a18,c19d1000,c05f685f,3ea,c19d1000) at 0xc0470032 = closef+0x3d2 close(c19d1000,cae60d04,4,439,1) at 0xc046cfdc = close+0x22c syscall(2f,2f,2f,280f1a2d,817f000) at 0xc05d9fe0 = syscall+0x2c0 Xint0x80_syscall() at 0xc05c885f = Xint0x80_syscall+0x1f --- syscall (6, FreeBSD ELF32, close), eip = 0x282506df, esp = 0xbfbfeabc, ebp = 0xbfbfead8 --- KDB: enter: witness_checkorder fxp0: promiscuous mode disabled -- It won't fit on the line. -- me, 2001 pgps0IGySkOdQ.pgp Description: PGP signature
Re: Can isp driver support Qlogic 2340 on FreeBSD5.x or later?
Yes, the 234X cards have been supported for quite a while. it seems not all of them: it's a QLA2342/ISP2312 and im getting: isp1: Qlogic ISP 2312 PCI FC-AL Adapter port 0x2400-0x24ff mem 0xfe8e-0xfe8e0fff irq 24 at device 8.0 on pci3 isp1: bad execution throttle of 0- using 16 isp2: Qlogic ISP 2312 PCI FC-AL Adapter port 0x2000-0x20ff mem 0xfe8f-0xfe8f0fff irq 27 at device 8.1 on pci3 isp2: bad execution throttle of 0- using 16 DELL has a clone card which up until recently wasn't supported. The 236X/63XX cards are not yet supported. On 4/14/05, wsk [EMAIL PROTECTED] wrote: folks: Can the Qlogic 2340 Fibre Channel card works on FreeBSD now? DELL released a newest Server PE6850 with this card.thx ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can isp driver support Qlogic 2340 on FreeBSD5.x or later?
On Mon, May 02, 2005 at 04:45:10PM +0300, Danny Braniss wrote.. Yes, the 234X cards have been supported for quite a while. it seems not all of them: it's a QLA2342/ISP2312 and im getting: isp1: Qlogic ISP 2312 PCI FC-AL Adapter port 0x2400-0x24ff mem 0xfe8e-0xfe8e0fff irq 24 at device 8.0 on pci3 isp1: bad execution throttle of 0- using 16 isp2: Qlogic ISP 2312 PCI FC-AL Adapter port 0x2000-0x20ff mem 0xfe8f-0xfe8f0fff irq 27 at device 8.1 on pci3 isp2: bad execution throttle of 0- using 16 Have you loaded the ispfw.ko firmware module? Matt tests the driver against that firmware, not against all the firmware revs Qlogic has released over time. DELL has a clone card which up until recently wasn't supported. The 236X/63XX cards are not yet supported. On 4/14/05, wsk [EMAIL PROTECTED] wrote: folks: Can the Qlogic 2340 Fibre Channel card works on FreeBSD now? DELL released a newest Server PE6850 with this card.thx ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] --- end of quoted text --- -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
mount_msdosfs /dev/fd0 causes reboot
I'm using 5.3-RELEASE and issuing the subject command, after a few seconds pause, causes a reboot. There are no /var/log/messages. In one case I saw a stray irq 9 message flash across the console. Has anyone come across this problem? tnx mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bpf/fxp RELENG_5 LOR
On Mon, May 02, 2005 at 02:51:05PM +0200, Rene Ladan wrote: FreeBSD 5.4-STABLE #0: Mon May 2 02:26:10 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/RENE #tcpdump fxp0: promiscuous mode enabled lock order reversal 1st 0xc066de80 bpf global lock (bpf global lock) @ /usr/src/sys/net/bpf.c:385 2nd 0xc14c9264 fxp0 (network driver) @ /usr/src/sys/modules/fxp/../../dev/fxp/if_fxp.c:2394 fxp0: promiscuous mode disabled Of course, to obfuscate debugging, this only happens sporadically, e.g. when using tcpdump the first time. :( This and related fxp LORs all point to some file and to src/sys/dev/fxp/if_fxp.c, at places where a FXP_LOCK(sc), with sc of type fxp_softc * is done. from src/sys/dev/fxp/fxpvar.h: #define FXP_LOCK(_sc) mtx_lock((_sc)-sc_mtx) Regards, Rene -- It won't fit on the line. -- me, 2001 pgpK8e5qT3NRS.pgp Description: PGP signature
burncd erase hangs at 83%
All, 1. I've noticed that on two separate systems, both running 5.3-RELEASE that 'burncd -vef /dev/acd0 erase' hangs at 83%. This is true for a couple different CD-RW discs (one brand new, never been used). 2. I've been able to burn ISO file systems with no problems. However, I've not been able to burn audio CD's using any of the burncd methods in the handbook nor with any of the googled burncd incantations. 3. Are these burncd (known) problems? Is there a near term fix? tnx mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5
Uwe Doering [EMAIL PROTECTED] wrote: Oliver Fromme wrote: If they're really identical (i.e. the same size and same geometry), then you can use dd(1) for duplication, like this: # dd if=/dev/ad0 of=/dev/ad1 bs=64k conv=noerror,sync The noerror,sync part is important so the dd command will not stop when it hits any bad spots on the source drive and instead will fill the blocks with zeroes on the destination drive. Since it's only the swap partition, you shouldn't lose any data. I would like to point out that the conclusion you're drawing in the last sentence is invalid IMHO. I'm afraid I don't agree. indefinite wait buffer messages at apparently random block numbers just indicate that the pager was unable to access the swap area (in its entirety!) when it wanted to. It means that the disk drive was either dead at that point in time or busy trying to deal with a bad sector. This sector could have been anywhere on the disk. It just kept the disk drive busy for long enough that the pager started to complain. The OP specifically said that the swap_pager messages were the only kernel messages that he got. That indicates that only the swap partition is affected, because otherwise there would have been other kernel messages indicating I/O errors from one of the filesystems on that disk. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. C++ is to C as Lung Cancer is to Lung. -- Thomas Funke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mount_msdosfs /dev/fd0 causes reboot
Michael A. Koerber [EMAIL PROTECTED] writes: I'm using 5.3-RELEASE and issuing the subject command, after a few seconds pause, causes a reboot. There are no /var/log/messages. In one case I saw a stray irq 9 message flash across the console. Has anyone come across this problem? The IRQ 9 is *probably* unrelated. Although it doesn't excuse the presence of bugs in the first place, problems with mounted filesystems affect the kernel itself, so I've always been leery of mounting filesystems from unreliable media (like floppies) and usually stick to using mtools. Do you have the mtools port installed? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can isp driver support Qlogic 2340 on FreeBSD5.x or later?
On Mon, May 02, 2005 at 04:45:10PM +0300, Danny Braniss wrote.. Yes, the 234X cards have been supported for quite a while. it seems not all of them: it's a QLA2342/ISP2312 and im getting: isp1: Qlogic ISP 2312 PCI FC-AL Adapter port 0x2400-0x24ff mem 0xfe8e-0xfe8e0fff irq 24 at device 8.0 on pci3 isp1: bad execution throttle of 0- using 16 isp2: Qlogic ISP 2312 PCI FC-AL Adapter port 0x2000-0x20ff mem 0xfe8f-0xfe8f0fff irq 27 at device 8.1 on pci3 isp2: bad execution throttle of 0- using 16 Have you loaded the ispfw.ko firmware module? Matt tests the driver against that firmware, not against all the firmware revs Qlogic has released over time. BINGO! and i thought isp does the firmware update ... thanks, danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can isp driver support Qlogic 2340 on FreeBSD5.x or later?
Yeah, sorry- the newer QLogic cards have firmware that has a different protocol that I haven't written the code for yet. In general, always load the firmware module as well. *EVENTUALLY* we'll be able to unload it and reclaim the member. On 5/2/05, Danny Braniss [EMAIL PROTECTED] wrote: On Mon, May 02, 2005 at 04:45:10PM +0300, Danny Braniss wrote.. Yes, the 234X cards have been supported for quite a while. it seems not all of them: it's a QLA2342/ISP2312 and im getting: isp1: Qlogic ISP 2312 PCI FC-AL Adapter port 0x2400-0x24ff mem 0xfe8e-0xfe8e0fff irq 24 at device 8.0 on pci3 isp1: bad execution throttle of 0- using 16 isp2: Qlogic ISP 2312 PCI FC-AL Adapter port 0x2000-0x20ff mem 0xfe8f-0xfe8f0fff irq 27 at device 8.1 on pci3 isp2: bad execution throttle of 0- using 16 Have you loaded the ispfw.ko firmware module? Matt tests the driver against that firmware, not against all the firmware revs Qlogic has released over time. BINGO! and i thought isp does the firmware update ... thanks, danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL in FreeBSD jails
An unknown poster wrote: AFAIR PostgreSQL generates the shared memory identifier based on the port it is runing on. It is possible to run two instances of PostgreSQL on different ports, so it should work if they are in seperate jails. Correct. Alexander Rusinov [EMAIL PROTECTED] writes: I guess this is a workaround but not a solution though. There are two possible solutions: - hack the SysV IPC code to use separate namespaces for each jail - make PostgreSQL use POSIX shared memory instead of SysV shared memory I suspect that the latter is significantly easier, and would probably improve performance as well. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MNT_USER?
In message [EMAIL PROTECTED], Danny Braniss writes: after doing a mount_nfs as root (from the console or via su), statfs reports that MNT_USER flags is set! this is also true with 5.4. It's a bug in the statfs reporting for NFS filesystems. It should be fixed now in -CURRENT (revision 1.174 of sys/nfsclient/nfs_vfsops.c). I'll merge this to -STABLE in a week or so. Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Serial ATA
% --- snipped I have good experiences with RocketRAID 1520 and 1640. I'm running a 1640 with three SATA drives since one year without problems; it's just a little bit slow. Highpoint offers binary FreeBSD drivers for these controllers, but I think that people don't like this kind of support because Highpoint neglects it for older models and this dependency might be dangerous in future. Keep in mind: you'll get what you pay for. Regards Björn Can someone just answer a quick question. One of the suggestions mentioned was the Highpoint RocketRAID 1520 controller which is a low cost solutions however support for FreeBSD stopped at v5.1. However, scrolling down the list of driver software for the RocketRAID 1520, Highpoint offer the option of downloading the Linux Open Source Driver and compiling it yourself. To quote the website: Support Linux kernel version 2.2.x to 2.6.x on x86 and x86_64 platform. Would this be a suitable option since (as I understand it), FreeBSD is i386. Sorry if I sound like i'm trying to get blood from a stone. ;) Stuart, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mount_msdosfs /dev/fd0 causes reboot
mtools was actually my first attempt at accessing the floppy drive. Exactly the same end result. I issued 'mdir a:' and after a few seconds I was watching my system reboot. After doing that twice with mdir, I uninstalled mtools thinking it was the problem. When I saw mount_msdosfs gave me the same result, I began to suspect something more basic to be at fault. mike - Dr Michael A. Koerber x3250 Lowell Gilbert wrote: Michael A. Koerber [EMAIL PROTECTED] writes: I'm using 5.3-RELEASE and issuing the subject command, after a few seconds pause, causes a reboot. There are no /var/log/messages. In one case I saw a stray irq 9 message flash across the console. Has anyone come across this problem? The IRQ 9 is *probably* unrelated. Although it doesn't excuse the presence of bugs in the first place, problems with mounted filesystems affect the kernel itself, so I've always been leery of mounting filesystems from unreliable media (like floppies) and usually stick to using mtools. Do you have the mtools port installed? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Serial ATA
On Monday 02 May 2005 17:22, O'Reilly, Stuart wrote: % --- snipped I have good experiences with RocketRAID 1520 and 1640. I'm running a 1640 with three SATA drives since one year without problems; it's just a little bit slow. Highpoint offers binary FreeBSD drivers for these controllers, but I think that people don't like this kind of support because Highpoint neglects it for older models and this dependency might be dangerous in future. Keep in mind: you'll get what you pay for. Regards Björn Can someone just answer a quick question. One of the suggestions mentioned was the Highpoint RocketRAID 1520 controller which is a low cost solutions however support for FreeBSD stopped at v5.1. However, scrolling down the list of driver software for the RocketRAID 1520, Highpoint offer the option of downloading the Linux Open Source Driver and compiling it yourself. To quote the website: Support Linux kernel version 2.2.x to 2.6.x on x86 and x86_64 platform. Would this be a suitable option since (as I understand it), FreeBSD is i386. FreeBSD has an i386 version, but it isn't only available for i386. See: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html Regarding the driver for Linux: Often the guts of drivers distributed in this way are binary and the interface which brings the binary and the kernel together is all that is publicly accessible. You will (quite literally) have more luck getting a binary Windows driver to work on FreeBSD than a binary Linux driver. Sorry if I sound like i'm trying to get blood from a stone. ;) Be wary of cheap controllers which burden your system with extra work instead of less. Stuart, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] HTH, -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
gvinum: All subdisks marked stale after a reboot
Hello, I've run into a problem while trying to migrate and old vinum array to gvinum (via blowing away all vinum info and rebuilding it in gvinum). The array builds ok, but when I reboot every subdisk is marked stale and the plex is marked down. What am I doing wrong here? More importantly, what info would I need to provide to help debug this problem? Here's the array: 10 drives: D media1State: up /dev/ad4s1 A: 1843/78159 MB (2%) D media2State: up /dev/ad6s1 A: 0/76316 MB (0%) D media3State: up /dev/ad8s1 A: 0/76316 MB (0%) D media4State: up /dev/ad10s1 A: 0/76316 MB (0%) D media5State: up /dev/ad12s1 A: 0/76316 MB (0%) D media6State: up /dev/ad14s1 A: 0/76316 MB (0%) D media7State: up /dev/ad16s1 A: 0/76316 MB (0%) D media8State: up /dev/ad18s1 A: 0/76316 MB (0%) D media9State: up /dev/ad20s1 A: 0/76316 MB (0%) D mediaaState: up /dev/ad22s1 A: 0/76316 MB (0%) 1 volume: V media State: down Plexes: 1 Size:670 GB 1 plex: P media.p0 R5 State: down Subdisks:10 Size:670 GB 10 subdisks: S media.p0.s0 State: staleD: media1 Size: 74 GB S media.p0.s1 State: staleD: media2 Size: 74 GB S media.p0.s2 State: staleD: media3 Size: 74 GB S media.p0.s3 State: staleD: media4 Size: 74 GB S media.p0.s4 State: staleD: media5 Size: 74 GB S media.p0.s5 State: staleD: media6 Size: 74 GB S media.p0.s6 State: staleD: media7 Size: 74 GB S media.p0.s7 State: staleD: media8 Size: 74 GB S media.p0.s8 State: staleD: media9 Size: 74 GB S media.p0.s9 State: staleD: mediaa Size: 74 GB ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4 release status
On 4/30/05, Claus Guttesen [EMAIL PROTECTED] wrote: As you probably noticed, we are a bit behind on the 5.4 release. There was a major stability problem reported several weeks ago in a particlar high load, high profile environment, and we decided that it was in everyones best interest to get it resolved before the release. Well, thanks to the tireless efforts of Doug White and Stephen Uphoff and several others, the bug has been found, fixed, and verified. As soon as it and a few other fixes get merged in, we will start the RC4 build process and hopefully release it for testing late this weekend. After that, unless another show-stopper comes up, we expect to build and release 5.4-RELEASE next weekend. Nice to hear. I have a four-way opteron-postgresql-server which is running low on disk-space, larger disks are right next to my desk, just waiting :-) Are there any finer details related to the four-way or larger-bug? regards Claus ___ Hi I am abit confused here, have seen a post from someone using 5.4-STABLE how is that possible if 5.4 isnt RELEASE yet, and good news on the bug fix. Chris freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL in FreeBSD jails
Dag-Erling Smørgrav wrote: There are two possible solutions: - hack the SysV IPC code to use separate namespaces for each jail - make PostgreSQL use POSIX shared memory instead of SysV shared memory I suspect that the latter is significantly easier, and would probably improve performance as well. DES It might be easier to hack PostgreSQL so that the shared memory identifier depends not only on the port, but also on the IP address (which will of course be different for each jail). Or better yet, to be able to specify the shared memory identifier to use directly in the config file. Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL in FreeBSD jails
yOn Mon, 2 May 2005, Richard Coleman wrote: Dag-Erling Smørgrav wrote: There are two possible solutions: - hack the SysV IPC code to use separate namespaces for each jail - make PostgreSQL use POSIX shared memory instead of SysV shared memory I suspect that the latter is significantly easier, and would probably improve performance as well. DES It might be easier to hack PostgreSQL so that the shared memory identifier depends not only on the port, but also on the IP address (which will of course be different for each jail). Or better yet, to be able to specify the shared memory identifier to use directly in the config file. You've all lost me here ... what exactly is the problem? PostgreSQL works under FreeBSD 4.x jails without any modifications, so how is PostgreSQL itself currently broken? It seems to me that the problem is with FreeBSD 5.x's jail side of things, if the same daemon runs fine under 4.x, but, nto under 5.x ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: FreeBSD 5.4 release status
Hello Chris, Monday, May 2, 2005, 10:14:47 PM, you wrote these comments: Hi I am abit confused here, have seen a post from someone using 5.4-STABLE how is that possible if 5.4 isnt RELEASE yet, and good news RELENG_5 has a -STABLE tag since RELENG_5_4 was branched, so if you use _5 you will get 5.4-STABLE and if you use _5_4, you will get 5.4-RC4. on the bug fix. Chris -- Best regards DanGer, ICQ: 261701668 | e-mail protecting at: http://www.2pu.net/ http://danger.rulez.sk | proxy list at:http://www.proxy-web.com/ | FreeBSD - The Power to Serve! [ Be a dear and turn the shower massage head on pulsate. -- Servo ] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.3p6-5.4RC3, Supermicro X6DHR-8G,Dual3.6GHzXeons,Adaptec aic7902 SCSI interface doesn't work in UP kernel
Guy Helmer wrote: These new Supermicro X6DHR-8G 800MHz FSB systems seem to be working OK (even under load) when running a kernel with SMP enabled. I offered my configuration in case jhb or someone else would be interested in what seems to be an interrupt routing problem. Guy, I LOVE YOU, dude! I had ... well, let us just say, some frustration with a new system with this mobo until I read your post that the SMP kernel works. Which is funny, because SMP is turned off, by default, because of some stability issues on one-proc hyperthreaded machines! On the other hand, the non-SMP craps itself spectacularly on at least one multi-proc machine!? I just wish I had read your post last week, and not started with such silliness on a Monday. :) Thanks a bunch, to all who have puzzled over these things before me! Sincerely, -danny -- http://dannyman.toldme.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB changes
It did go somewhere; Julian altered two files in the relevant source and after I updated the issue was resolved. 13. Re: USB changes. (Joel) Message: 13 Date: Mon, 02 May 2005 12:20:30 +0900 From: Joel [EMAIL PROTECTED] Subject: Re: USB changes. To: freebsd-stable@freebsd.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-2022-JP If I were Joe, I'd be wondering if that meant re-compiling the kernel. Did this go anywhere? (I also have UHB hardware that fusses on boot.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] End of freebsd-stable Digest, Vol 108, Issue 1 ** -- I don't care what you think. This is not a stylishly insouciant stroll out of the jungle, here. It's more like we've fallen out of our trees and rolled, butt-naked before the entire galaxy, downhill. That, and we seem to have a teensy problem lifting ourselves off the ground. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic in 5.4RC2
System info: FreeBSD bart.motd.dk 5.4-RC2 FreeBSD 5.4-RC2 #2: Fri Apr 15 21:14:30 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CUSTOM i386 Got the following panic when trying to recover data from a crappy cd I got at crash dump so please let me know if further info is needed. - T sgbufp = 0xc101cfe4 magic = 63062, size = 32740, r= 186528, w = 186977, ptr = 0xc1015000, cksum= 2196678 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x57c fault code = supervisor read, page not present instruction pointer = 0x8:0xc06413bd stack pointer = 0x10:0xc9bbfc04 frame pointer = 0x10:0xc9bbfc08 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 1 (init) db where Tracing pid 1 tid 12 td 0xc13df300 turnstile_setowner(c13d37c0,510) at turnstile_setowner+0xd turnstile_wait(c13d37c0,c15ad230,510) at turnstile_wait+0xb7 _mtx_lock_sleep(c15ad230,c13df300,0,0,0) at _mtx_lock_sleep+0xad kern_wait(c13df300,,c9bbfc94,0,c9bbfc98) at kern_wait+0xfa wait4(c13df300,c9bbfd14,4,f3,282) at wait4+0x1f syscall(bfbf002f,bfbf002f,bfbf002f,bfbfef04,bfbfeef8) at syscall+0x27b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (7, FreeBSD ELF32, wait4), eip = 0x8051e07, esp = 0xbfbfedcc, ebp = 0xbfbfede8 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL in FreeBSD jails
On 5/2/2005 4:03 PM, Marc G. Fournier wrote: yOn Mon, 2 May 2005, Richard Coleman wrote: Dag-Erling Smørgrav wrote: There are two possible solutions: - hack the SysV IPC code to use separate namespaces for each jail - make PostgreSQL use POSIX shared memory instead of SysV shared memory I suspect that the latter is significantly easier, and would probably improve performance as well. DES It might be easier to hack PostgreSQL so that the shared memory identifier depends not only on the port, but also on the IP address (which will of course be different for each jail). Or better yet, to be able to specify the shared memory identifier to use directly in the config file. You've all lost me here ... what exactly is the problem? PostgreSQL works under FreeBSD 4.x jails without any modifications, so how is PostgreSQL itself currently broken? It seems to me that the problem is with FreeBSD 5.x's jail side of things, if the same daemon runs fine under 4.x, but, nto under 5.x ... From my reading on this thread: PostgreSQL generates the shared memory identifier based on the port it is running on, but (on 5.x at least) shared memory is not segregated between jails. Thus, a new instance will corrupt the shared memory of another instance (in another jail, on another IP address, etc.) *if* they are running on the same port. The workaround is to ensure every instance (regardless of jail or IP address) is running on a unique port. -- Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195 signature.asc Description: OpenPGP digital signature
Re: PostgreSQL in FreeBSD jails
Richard Coleman [EMAIL PROTECTED] writes: It might be easier to hack PostgreSQL so that the shared memory identifier depends not only on the port, but also on the IP address (which will of course be different for each jail). Or better yet, to be able to specify the shared memory identifier to use directly in the config file. That's not a sufficiently general solution. First of all, in most setups postgresql runs either a) without TCP/IP; b) only on 127.0.0.1; c) on all interfaces. Very rarely does it listen only on one single identifiable IP address. Therefore, relying on the IP address is useless. Besides, the shm id is an integer, which makes it difficult to encode both the IP address and the port number without collisions. The ideal solution is to use a type of shared memory that does not need a namespace at all. One option is to use a threads instead of child processes. This would require a major rewrite of the backend, and is not likely to happen any time soon. The other option is to add support for mmap()-based shared memory. I happen to have a patch, but testing it properly and getting it approved and merged will take a while. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic: icmp_error: bad length
My 5.3-RELEASE server just paniced with 'icmp_error: bad length. I have no possibilities to do any debugging on this machine, as it runs off a compactflash card with limited space. This could be caused by the crappy built-in Realtek cards, or maybe by something on my own network. Is there a known way to avoid this panic (or stop the error causing a panic)? Thanks, Arjan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4 release status
On 5/2/2005 3:14 PM, Chris wrote: On 4/30/05, Claus Guttesen [EMAIL PROTECTED] wrote: As you probably noticed, we are a bit behind on the 5.4 release. There was a major stability problem reported several weeks ago in a particlar high load, high profile environment, and we decided that it was in everyones best interest to get it resolved before the release. Well, thanks to the tireless efforts of Doug White and Stephen Uphoff and several others, the bug has been found, fixed, and verified. As soon as it and a few other fixes get merged in, we will start the RC4 build process and hopefully release it for testing late this weekend. After that, unless another show-stopper comes up, we expect to build and release 5.4-RELEASE next weekend. Nice to hear. I have a four-way opteron-postgresql-server which is running low on disk-space, larger disks are right next to my desk, just waiting :-) Are there any finer details related to the four-way or larger-bug? regards Claus Hi I am abit confused here, have seen a post from someone using 5.4-STABLE how is that possible if 5.4 isnt RELEASE yet, and good news on the bug fix. When RELENG_5_4 was branched, RELENG_5 went from 5.4-PRERELEASE to 5.4-STABLE to reflect that it is once again open for less-restricted development. As 5.4 will be released via the RELENG_5_4 branch, it is normal and expected to have 5.4-STABLE around before 5.4-RELEASE. -- Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195 signature.asc Description: OpenPGP digital signature
RE: ndis with Intel 2915 wireless, getting NDIS ERROR messages and deattach on boot
From: Carl Gustavsson [EMAIL PROTECTED] Have you tested the iwi-driver? See: http://damien.bergamini.free.fr/ipw/iwi-freebsd.html I haven't yet. Reading that page has brought up another questions. On the page it says 5-STABLE doesn't support WPA. My wireless network uses WPA. Is this still the case? I know -stable is -stable, but WPA something of a show-stopper, if you ask me. Fortunately, my neighborhood is a well-covered sea of open linksys and NETGEAR APs in default configuration with to test the driver. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.4-RC4 Available
Announcement The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 5.4-RC4, the fourth Release Candidate of the FreeBSD 5.4 release cycle. This will be the last Release Candidate, unless a major problem is discovered as part of RC4 testing the final release will be made early next week. This RC contains fixes to all known major issues. We encourage people to help with testing so any final bugs can be identified and worked out. Availability of ISO images and support for doing FTP based installs 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_5_4. Problem reports can be submitted using the send-pr(1) command, and/or posted to the freebsd-stable@freebsd.org mailing list. A schedule and the current todo list for the 5.4 Release Cycle are available: http://www.freebsd.org/releases/5.4R/schedule.html http://www.freebsd.org/releases/5.4R/todo.html The packages being provided as part of RC4 are what is expected to come with the final release for the alpha, amd64, i386, pc98, and sparc64 architectures. There will be a few more adjustments made to the package set for ia64. Special thanks to Doug White (Looksmart), Stephan Uphoff, Alan Cox (Rice University), Robert Watson (SPARTA), John Baldwin (The Weather Channel), Paul Vixie (ISC), and Peter Losher (ISC) for their work tracking down and fixing the last big show-stopper. Availability The RC4 ISOs and FTP support for all architectures are available now 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 of the ISO images are: MD5 (5.4-RC4-alpha-bootonly.iso) = 042b154c74b3ad917040dc84a5821e05 MD5 (5.4-RC4-alpha-disc1.iso) = 7266c40da24def01941daa82cf80f15b MD5 (5.4-RC4-alpha-disc2.iso) = fd0d199ea31afd48d3c59cef6111ba9a MD5 (5.4-RC4-amd64-bootonly.iso) = 819852f18e41ebe4d4d42fce3bdd35a4 MD5 (5.4-RC4-amd64-disc1.iso) = acf6a5193ff3d7caef1d4492fcac2c9a MD5 (5.4-RC4-amd64-disc2.iso) = 293a4670f7bcfb1bb30289c06327b8fc MD5 (5.4-RC4-i386-bootonly.iso) = ff8d96644b2cf28cfc4b00d4061f78aa MD5 (5.4-RC4-i386-disc1.iso) = e133e34e5b92804e00816cad8b3e4559 MD5 (5.4-RC4-i386-disc2.iso) = 019af1777c83c90e7b366cb2bddc13a9 MD5 (5.4-RC4-ia64-bootonly.iso) = 992a2ee2644fea1e0c5c3199f1ed7255 MD5 (5.4-RC4-ia64-disc1.iso) = ae7a494707ab7d29309c812570012c26 MD5 (5.4-RC4-ia64-disc2.iso) = 73a1ebcd38deccbbf6534ef1d9c0d11f MD5 (5.4-RC4-ia64-livefs.iso) = 914aff32dc853114b7ec89f789556683 MD5 (5.4-RC4-pc98-disc1.iso) = 28e3d46e59291e3b695f9bd59c7024d1 MD5 (5.4-RC4-sparc64-bootonly.iso) = 1afcd18c7edd19d8f2ea3ec6212c2771 MD5 (5.4-RC4-sparc64-disc1.iso) = a7c18eeef17c8873310c829b3f6bba84 MD5 (5.4-RC4-sparc64-disc2.iso) = fb4e2af7a3a16aa15fe35c5f424340f1 -ken pgpkvxoMpvqdX.pgp Description: PGP signature
RE: ndis with Intel 2915 wireless, getting NDIS ERROR messagesand deattach on boot
From: Darren Pilgrim From: Carl Gustavsson [EMAIL PROTECTED] Have you tested the iwi-driver? See: http://damien.bergamini.free.fr/ipw/iwi-freebsd.html I haven't yet. Reading that page has brought up another questions. On the page it says 5-STABLE doesn't support WPA. My wireless network uses WPA. Is this still the case? I know -stable is -stable, but WPA something of a show-stopper, if you ask me. Fortunately, my neighborhood is a well-covered sea of open linksys and NETGEAR APs in default configuration with to test the driver. I'm using driver version 1.3.4 and firmware version 2.2. The driver appears to attach just fine: iwi0: Intel(R) PRO/Wireless 2915ABG MiniPCI mem 0xdfcfd000-0xdfcfdfff irq 5 at device 3.0 on pci3 iwi0: Ethernet address: 00:0e:35:f6:d6:5c iwi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps However, when I attempt to associate and get an IP address, I get iwi0: fatal error when running dhclient. Setting debug.iwi=10 and debug.ieee80211=10, I get the following debug output when I run the firmware download and dhclient commands: # iwicontrol iwi0 -d /root/if_iwi/firmware-2.2 -m bss Firmware cached: boot 6464, ucode 16326, main 166952 # dhclient iwi0 INTR!0x0100 INTR!0x0100 Setting MAC address to 00:0e:35:f6:d6:5c TX!CMD!11!6 INTR!0x0800 Configuring adapter TX!CMD!6!20 INTR!0x0800 Setting power mode to 0 TX!CMD!17!4 INTR!0x0800 Setting RTS threshold to 2312 TX!CMD!15!4 INTR!0x0800 Setting .11bg supported rates (12) TX!CMD!22!16 INTR!0x0800 Setting .11a supported rates (8) TX!CMD!22!16 INTR!0x0800 Setting initialization vector to 693451133 TX!CMD!34!4 INTR!0x0800 Enabling adapter TX!CMD!2!0 INTR!0x0800 ieee80211_next_scan: chan 56-60 Start scanning TX!CMD!20!60 INTR!0x0800 INTR!0x0002 Notification (20) INTR!0x0002 Scan channel (36) INTR!0x0002 Scan channel (40) INTR!0x0002 Scan channel (44) INTR!0x0002 Scan channel (48) INTR!0x0002 RX!DATA!68!52!58 ieee80211_recv_mgmt: new probe response on chan 52 (bss chan 52) 191 from 00:0c:db:81:5e:a8 ieee80211_recv_mgmt: caps 0x401 bintval 100 erp 0x0 ieee80211_recv_mgmt: country info 55 53 20 24 04 11 34 04 17 95 05 1e INTR!0x0002 Notification (25) Scan channel (52) INTR!0x0002 RX!DATA!68!56!50 ieee80211_recv_mgmt: new probe response on chan 56 (bss chan 56) 191 from 00:0c:db:81:5e:4a ieee80211_recv_mgmt: caps 0x401 bintval 100 erp 0x0 ieee80211_recv_mgmt: country info 55 53 20 24 04 11 34 04 17 95 05 1e INTR!0x0002 Notification (25) Scan channel (56) INTR!0x0002 Scan channel (60) INTR!0x0002 Scan channel (64) INTR!0x0002 Scan channel (149) INTR!0x0002 Scan channel (153) INTR!0x0002 Scan channel (157) INTR!0x4000 iwi0: fatal error At which point dhclient stalls for several seconds before switching to its background mode. `ifconfig iwi0` then shows status: no carrier and no IP address assignment. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Experimental ttwwakeup() panic patch
Hey folks, I've taken a crack at working around the ttwwakeup() panic thats been reported now and again. My early analysis, based on debugging output from rwatson, is that a defunct struct tty gets reused without cleaning out the associated (stale) knote structures, and the ttwwakeup() at the end of sioopen() jumps off into space when it finds them. This patch is against RELENG_5 but the logic should apply to -CURRENT, although the patch likely won't as ttymalloc() is organized differently there. I did some basic testing on my UP box and didn't see any abberant behavior afterwards. However I can't reproduce the panic in question, so if you're good at triggering the panic give this a spin. http://people.freebsd.org/~dwhite/tty.c.20050502.patch -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
