Re: Anyone object to the following change in libc?
On Thu, 30 Oct 2003, Garrett Wollman wrote:
On Thu, 30 Oct 2003 12:32:46 +0100 (CET), Harti Brandt [EMAIL PROTECTED] said:
The c89 utility (which specified a compiler for the C Language specified
by the 108 ISO/IEC 9899: 1990 standard) has been replaced by a c99 utility
(which specifies a compiler for 109 the C Language specified by the
ISO/IEC 9899: 1999 standard).
More specifically: IEEE Std. 1003.1-2001 is aligned to ISO/IEC
9899:1999 in all respects. C99 alignment was one of the principal
reasons for bringing out a whole new standard in the first place,
rather than continuing the amendment process. (This is also why POSIX
now requires eight-bit bytes.)
This doesn't follow, since C99 doesn't require 8-bit bits. int8_t is
optional in C99 and all code that uses it unconditionally is unportable.
Similarly for most other types in stdint.h. The required ones are
[u]int_least{8,16,32,64}_t and [u]int_fast{8,16,32,64}_t and [u]intmax_t,
i.e., nothing that can't be declared in C90 except a 64-bit type.
POSIX requires in addition [u]int{8,16,32}_t, and [u]int64_t if 64 bit
integer types exist. It says that the existence of int8_t implies
that a byte is 8 bits and CHAR_BIT is 8. I'm not sure what prevents
int8_t being smaller than char.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : To respond to myself, I got ahold of a 4.8 libm.so and made sure that the : linker used it. No change in the problem, and it still hints that the : native libc is being linked in. You might want to enable debugging of ld.so to confirm. Warner This was already resolved. Java does a dlopen() on /usr/lib/libc.so. Rumor has it that this is fixed. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Thu, Oct 30, 2003 at 11:48:13PM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : To respond to myself, I got ahold of a 4.8 libm.so and made sure that the : linker used it. No change in the problem, and it still hints that the : native libc is being linked in. You might want to enable debugging of ld.so to confirm. This was understood already (java is doing a dlopen of /usr/lib/libc.so). Kris pgp0.pgp Description: PGP signature
Re: ATAng regression: cdcontrol close not working
On Thu, 30 Oct 2003, Soren Schmidt wrote: It seems Lars Eggert wrote: I've already committed a solution that works on all the drives I could test on (some of which failed before), if this still fails for you I'd like a more detailed description of what exactly goes wrong... I must have missed that commit message, sorry. This is the drive I am having the issues with: acd0: CDRW PHILIPS DVD+RW-D28 at ata1-master UDMA33 Sending CDIOCCLOSE from a short C snippet shows that the ioctl yields EBUSY. Hmm, now that a real stupid return code from the drive IMNHO... Anyhow if you loose the test for error in atapi-cd.c::acd_tray in the close case, does it work then ? Problem is that the call to read toc might fail early, but its worth a shot.. I was mistaken in thinking that my patch fixed this. It only works for 1 drive, as does at acd^H^Htapi-cd.c rev.1.148. Some boot messages: acd0: CDRW RICOH CD-RW MP7320A at ata1-slave UDMA33 acd1: CDROM ATAPI 44X CDROM at ata2-slave PIO4 (cd1:ata2:0:1:0): Recovered Sense (cd1:ata2:0:1:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd1:ata2:0:1:0): CAM Status: SCSI Status Error (cd1:ata2:0:1:0): SCSI Status: Check Condition (cd1:ata2:0:1:0): NOT READY asc:3a,0 (cd1:ata2:0:1:0): Medium not present cd1 at ata2 bus 0 target 1 lun 0 cd1: ATAPI 44X CDROM 3.40 Removable CD-ROM SCSI-0 device cd1: 16.000MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present (cd0:ata1:0:1:0): Recovered Sense (cd0:ata1:0:1:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:1:0): CAM Status: SCSI Status Error (cd0:ata1:0:1:0): SCSI Status: Check Condition (cd0:ata1:0:1:0): NOT READY asc:3a,0 (cd0:ata1:0:1:0): Medium not present cd0 at ata1 bus 0 target 1 lun 0 cd0: RICOH CD-RW MP7320A bp13 Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present These drives now have the following behaviour for eject/close: cd0, acd1, cd1: eject and close just work acd0: eject works. Close fails with EBUSY. None of acd_start_stop(cdp, [0-3]) (called from ddb, ignoring errors) closes the tray when it is open. The related bugs in the cd driver are only that the messages are too verbose. The above boot messages show only some of them. Eject + close gives the following messages (all unwanted): (cd0:ata1:0:1:0): Recovered Sense (cd0:ata1:0:1:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:1:0): CAM Status: SCSI Status Error (cd0:ata1:0:1:0): SCSI Status: Check Condition (cd0:ata1:0:1:0): NOT READY asc:3a,0 (cd0:ata1:0:1:0): Medium not present (cd0:ata1:0:1:0): Recovered Sense (cd0:ata1:0:1:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:1:0): CAM Status: SCSI Status Error (cd0:ata1:0:1:0): SCSI Status: Check Condition (cd0:ata1:0:1:0): NOT READY asc:3a,0 (cd0:ata1:0:1:0): Medium not present (cd0:ata1:0:1:0): Recovered Sense (cd0:ata1:0:1:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:1:0): CAM Status: SCSI Status Error (cd0:ata1:0:1:0): SCSI Status: Check Condition (cd0:ata1:0:1:0): NOT READY asc:3a,0 (cd0:ata1:0:1:0): Medium not present (cd0:ata1:0:1:0): Recovered Sense (cd0:ata1:0:1:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:1:0): CAM Status: SCSI Status Error (cd0:ata1:0:1:0): SCSI Status: Check Condition (cd0:ata1:0:1:0): NOT READY asc:3a,0 (cd0:ata1:0:1:0): Medium not present This is with my modified version of scsi_cd.c. The current one is similarly verbose, but doesn't do as many read-capacity's. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: wi problem with message 7400 bytes
On Thu, 30 Oct 2003, Lars Eggert wrote: Daniel Eischen wrote: Could you post a tcpdump for each case? I wonder if this is related to a fragmentation issue I've seen in the past. 22:46:43.513038 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52198:[EMAIL PROTECTED]) 22:46:48.522475 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52199:[EMAIL PROTECTED]) 22:46:53.532018 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52200:[EMAIL PROTECTED]) 22:46:58.541178 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52201:[EMAIL PROTECTED]) 22:47:03.553048 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52202:[EMAIL PROTECTED]) 22:47:08.568862 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52203:[EMAIL PROTECTED]) 22:47:13.583328 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52204:[EMAIL PROTECTED]) 22:47:18.578512 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52205:[EMAIL PROTECTED]) 22:47:23.609098 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52206:[EMAIL PROTECTED]) 22:47:28.597680 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52207:[EMAIL PROTECTED]) 22:47:33.607059 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52208:[EMAIL PROTECTED]) It's not what I've seen in the past - but also pretty strange! Only the first fragment seems to be received. Wonder what happened to the other fragments... If you tcpdump on gpz, does the output look the same? Also, you may want I'll try that tomorrow. gpz is a Sun Solaris 9 box at work, but before you say try another BSD box, I already did. I tried 2 other FreeBSD boxes in place of gpz and I had the same results. to run the tcpdump without a filter (if you don't do this already) to see if the other fragments show up as corrputed frames or something. (As an aside, fragmentation on a lossy link compounds throughput issues, but of course you know that already.) Everything is behind Cisco 10/100 switches and doing 10/100 full duplex except for the laptop (vespa) which is through a Dell TrueMobile wireless access point. The access point is connected to a switch and is about 10 feet away from the laptop. I tried this test at home with a different setup: orion - laptop with D-Link DWL-650H PC-Card (wi) sirius - FreeBSD current box with em interface Linksys WRT-54g router/access point with builtin 10/100 switch There is no other traffic on this network; orion and sirius are standalone. sirius is wired to a 10/100 port in the router/access point and is at 100 full-duplex. Repeating the same test lets me send messages up to 25152 bytes in length, much better than 7400. This seems to be about the same limit I hit in VxWorks (which supposedly has the BSD 4.4 IP stack). I'll see if I can get my hands on a different access point at work to see if that makes a difference. Here's the tcpdump from the above setup with message size 25153: 05:27:59.632708 sirius.49245 orion-home.12345: udp 25153 (frag 19970:[EMAIL PROTECTED]) 05:27:59.815829 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:00.023248 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:00.216317 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:00.404066 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:00.583116 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:00.777315 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:00.950056 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:01.129616 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:01.327645 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:01.560564 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:01.769612 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:01.945923 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:02.128897 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:02.309202 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:02.514941 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:02.731612 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:02.907988 sirius orion-home: udp (frag 19970:[EMAIL PROTECTED]) 05:28:07.982121 sirius.49245 orion-home.12345: udp 25153 (frag 20226:[EMAIL PROTECTED]) 05:28:08.150171 sirius orion-home: udp (frag 20226:[EMAIL PROTECTED]) 05:28:08.357960 sirius orion-home: udp (frag 20226:[EMAIL PROTECTED]) 05:28:08.551270 sirius orion-home: udp (frag 20226:[EMAIL PROTECTED]) 05:28:08.754906 sirius orion-home: udp (frag 20226:[EMAIL PROTECTED]) 05:28:08.953891 sirius orion-home: udp (frag 20226:[EMAIL PROTECTED]) 05:28:09.145286 sirius orion-home: udp (frag 20226:[EMAIL PROTECTED]) 05:28:09.365111 sirius orion-home: udp (frag 20226:[EMAIL PROTECTED]) 05:28:09.577964 sirius orion-home: udp (frag 20226:[EMAIL PROTECTED]) 05:28:09.795675 sirius orion-home: udp (frag 20226:[EMAIL PROTECTED]) 05:28:09.973760 sirius
Re: lots of exclusive sleep mutex
On 2003/10/31 10:09:04, YONETANI Tomokazu wrote:
On 2003/10/30 00:16:47, Clive Lin wrote:
On Sat, Oct 04, 2003 at 02:00:33AM +0800, Clive Lin wrote:
Hi,
I've seen lots of messages on rescent -CURRENT
malloc() of 16 with the following non-sleepable locks held:
exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
/usr/src/sys/geom/geom_io.c:351
malloc() of 16 with the following non-sleepable locks held:
exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
/usr/src/sys/geom/geom_io.c:351
Many of above are still seen on the latest current.
malloc() of 16 with the following non-sleepable locks held:
exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
/usr/src/sys/geom/geom_io.c:355
malloc() of 16 with the following non-sleepable locks held:
exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
/usr/src/sys/geom/geom_io.c:355
Perhaps it's a ServeRAID specific glitch?
dmesg|grep ips
ips0: IBM ServeRAID Adapter mem 0xf000-0xf3ff irq 16 at device 1.0 on
pci4
ips0: logical drives: 1
ipsd0: Logical Drive on ips0
GEOM: create disk ipsd0 dp=0xc6b25310
ipsd0: Logical Drive (69430MB)
Does this fix?
Index: ips.c
[snipped]
Of course it doesn't. Hmm, I didn't realize that I've removed WITNESS* from
the kernel config file months ago. Anyway, this is the backtrace of
the above warnings from witness code(by manually setting a breakpoint
inside witness_warning and issuing panic command from DDB):
Script started on Fri Oct 31 12:47:51 2003
# gdb -k /usr/obj/home/source/freebsd/current/src/sys/MAIL/kernel.debug vmcore.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: from debugger
panic messages:
---
---
Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/usb.ko...done.
Loaded symbols for /boot/kernel/usb.ko
Reading symbols from /boot/kernel/nfsclient.ko...done.
Loaded symbols for /boot/kernel/nfsclient.ko
#0 doadump () at /home/source/freebsd/current/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /home/source/freebsd/current/src/sys/kern/kern_shutdown.c:240
#1 0xc0576346 in boot (howto=260)
at /home/source/freebsd/current/src/sys/kern/kern_shutdown.c:372
#2 0xc0576677 in panic ()
at /home/source/freebsd/current/src/sys/kern/kern_shutdown.c:550
#3 0xc045d1c2 in db_panic ()
at /home/source/freebsd/current/src/sys/ddb/db_command.c:450
#4 0xc045d122 in db_command (last_cmdp=0xc073e460, cmd_table=0x0,
aux_cmd_tablep=0xc0709cec, aux_cmd_tablep_end=0xc0709d04)
at /home/source/freebsd/current/src/sys/ddb/db_command.c:346
#5 0xc045d265 in db_command_loop ()
at /home/source/freebsd/current/src/sys/ddb/db_command.c:472
#6 0xc0460265 in db_trap (type=3, code=0)
at /home/source/freebsd/current/src/sys/ddb/db_trap.c:73
#7 0xc069765c in kdb_trap (type=3, code=0, regs=0xd77e5b3c)
at /home/source/freebsd/current/src/sys/i386/i386/db_interface.c:171
#8 0xc06a7fe8 in trap (frame=
{tf_fs = -1065877480, tf_es = -1065877488, tf_ds = -679608304, tf_edi =
-1065836412, tf_esi = -1065836416, tf_ebp = -679584872, tf_isp = -679584920, tf_ebx =
0, tf_edx = 0, tf_ecx = -1056882688, tf_eax = 19, tf_trapno = 3, tf_err = 0, tf_eip =
-1067865189, tf_cs = 8, tf_eflags = 514, tf_esp = -1066450495, tf_ss = -679584852}) at
/home/source/freebsd/current/src/sys/i386/i386/trap.c:582
#9 0xc0699048 in calltrap () at {standard input}:102
#10 0xc0674b34 in uma_zalloc_arg (zone=0xc078a080, udata=0x0, flags=0)
at /home/source/freebsd/current/src/sys/vm/uma_core.c:1385
#11 0xc056bd05 in malloc (size=0, type=0xc07235c0, flags=0)
at /home/source/freebsd/current/src/sys/vm/uma.h:234
#12 0xc04e5d44 in ips_add_waiting_command (sc=0xc479f000,
callback=0xc04e8050 ips_send_io_request, data=0xc7ea9a18, flags=0)
at /home/source/freebsd/current/src/sys/dev/ips/ips.c:147
#13 0xc04e5f1e in ips_get_free_cmd (sc=0x0,
callback=0xc04e8050 ips_send_io_request, data=0xc7ea9a18, flags=0)
at /home/source/freebsd/current/src/sys/dev/ips/ips.c:222
#14 0xc04e813e in ips_start_io_request (sc=0xc7ea9a18, iobuf=0x0)
at /home/source/freebsd/current/src/sys/dev/ips/ips_commands.c:168
#15 0xc04e7b62 in ipsd_strategy (iobuf=0x0)
at /home/source/freebsd/current/src/sys/dev/ips/ips_disk.c:100
#16 0xc0546036 in g_disk_start (bp=0xc8798110)
at /home/source/freebsd/current/src/sys/geom/geom_disk.c:272
---Type return to continue, or q return to quit---
#17 0xc0547fcc in g_io_schedule_down (tp=0xc1d17000)
at
Re: Anyone object to the following change in libc?
Harti Brandt wrote: Section 7.19.6.7 of N843 states: Reaching the end of the string is equivalent to encountering end-of-file for the fscanf function. OK, I buy this one. 8-). Unfortunately this is missing in POSIX, but obviously implied by their reference to ISO. I don't know if we can say the ISO C standard has precedence here; my feeling is that precedence is dictated by the validation suite for IEEE 1003.1-2001. I don't have a copy of this handy, so I can't tell you whether the answer is 0, -1, or don't care, at this point. One important point to note here is that a POSIX compliant OS need not be implemented in the C language, and that the library routines described are really C language bindings, and really mean their equivalents. In that case, the ISO C standard can go jump in a lake. 8-). I think that we need a ruling from someone who has a system that passes conformance testing... so you can't go wrong doing as Solaris does, but that doesn't mean it's something that's actually tested. 8-(. TLHow do I distinguish a return value is -1 as an error result from TLreturn value is -1 as an EOF result? Well, I suppose that's the intention of having scanf() setting errno when it returns -1 in POSIX. Unfortunately POSIX fails to describe the error codes. This is possibly fodder for the aardvark. I was afraid you were going to say that: that it's one of those terrible functions where you have to set errno equal to 0 and then check it when you get a -1 to see if it's still 0, in order to be able to distinguish the cases. 8-(. TLIt says that any conflicts are unintentional, and their intent was TLto use different language for no good reason, rather than just TLcopying it verbatim and removing any doubt. It does *NOT* say TLthat no conflicts exist. Yes. But I take the last sentence to mean that ISO-C takes over in the case a conflict exists. I don't think you can say exactly that without them saying exactly that. The standard is the standard; while they might regret not aligning with ISO C, I think that implementations have to adhere to the letter of the standard to be considered conformant. There's lots of stupid things in the standard that we just have to live with in order to be conformant. This is actually recognized in conformance testing, which lets you set an environment variable to indicate to your libraries that they need to return strictly conformant results, rather than The Right Results(tm). I think that's the escape hatch for differences in details between them and other standards, so that system can claim standards compliance with multiple standards. Yes, it's ugly. TLAlso: In this context, which is IEEE 1003.1-2001, Issue 6, the TLISO C standard refers to c89, which is the version of the C TLstandard that was in effect at the time that SVID IV was defined. Line 107 of Austin TC-1: The c89 utility (which specified a compiler for the C Language specified by the 108 ISO/IEC 9899: 1990 standard) has been replaced by a c99 utility (which specifies a compiler for 109 the C Language specified by the ISO/IEC 9899: 1999 standard). Again, that doesn't effect IEEE 1003.1-2001. I can have software that conforms to RFC 821 and fails to conform to RFC 2821, and it's still RFC 821 compliant, even if the IETF wants everyone to switch over to using RFC 2821 instead, and RFC 2821 says Obsoletes: 821, 974, 1869. TLIf you need clarification on this issue, you should download the TLcurrently available version of the NIST/PCTS, which specifically TLrequires you to compile with a c89 compiler, not one more recent. TLThe same is true of The Open Group test suites which are available TLon the Internet. TL TLThe version of the ISO C standard you are quoting from is *NOT* TLthe c89 version. Our sscanf() claims conformance to C99. So if we change the behaviour we have to remove this claim. No... or we need to use inline versions in the header which call into _sscanf_c89() and _sscanf_c99() functions in the implementation namespace, variant upon which standard is in effect, e.g. via (GCC-only syntax, so it would ned to be wrappered for any non-gcc compilers, as well): #if (__STDC_VERSION__ - 0) 199409 #define sscanf(str, fmt, ...) _sscanf_c99 (str, fmt, __VA_ARGS__) #else #define sscanf(str, fmt, ...) _sscanf_c89 (str, fmt, __VA_ARGS__) #endif This will work for all code, even code that's linked together from objects compiled with different versions of the standard in scope, since each scope will use the scope-specific definition. TLIn any case, we are practically guaranteed that returning -1, as TLall other UNIX-like OS's currently do, would result in less source TLcode breaking. No coder in his right mind should have written code that depends on this behaviour given the moot formulations in the classical books, man pages and pre-C99 standards. That's what they said about all the things programmers did before the ANSI C standard
Re: Still gettnig NFS client locking up
Robert Watson wrote: On Tue, 28 Oct 2003, Soren Schmidt wrote: I'm now running a kernel/world of October 26th on both NFS client and server machines. I am still seeing NFS lockups as reported by several people in these threads: Me too!! Hmm. I'm unable to reproduce this so far, and I'm pounding several 5.x NFS clients and servers. I've been checking out using CVS over NFS, performing dd's of big files, etc. There must be something more I'm missing in reproducing this. What network interface cards are you using (client, server)? Are you using DHCP on the client or server? What commands trigger it -- what part of the NFS namespace, etc? Are you running the commands as root, or another user? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories I have 3com cards in both machines. 3c905c's I believe. The xl driver. The client has a static IP address configured from rc.conf and the server uses dhclient to get a hardwired static address based on MAC. I'm running the commands as root. I have noticed that it generally locks up when writing to the mount rather than reading as I can do an installworld from the NFS server to the client without issues (i think!, I've only tried this once). But downloading files into the mount breaks very quickly. I guess it could be a filesize thing though. I shall have to do some more testing. I was planning on cvsuping and buildworlding on saturday again. It started happening approx two weeks ago I think? Roughly when I first reported it, but NFS had always been solid as a rock before then. I can easily reproduce this by doing this: [EMAIL PROTECTED] root]# cd /usr/ports/databases/mysql40-server [EMAIL PROTECTED] mysql40-server]# make fetch mysql-4.0.16.tar.gz doesn't seem to exist in /usr/ports/distfiles/. Attempting to fetch from ftp://planetmirror.com/pub/mysql/Downloads/MySQL-4.0/. Receiving mysql-4.0.16.tar.gz (12830094 bytes): 3% (has now locked up) [EMAIL PROTECTED] root]# ls /usr/src COPYRIGHT READMEcontrib gnu libexec secureusr.bin MAINTAINERS UPDATING cryptoinclude release share usr.sbin Makefile bash.core etc kerberos5 rescuesys Makefile.inc1 bin games lib sbin tools [EMAIL PROTECTED] root]# ls /usr/ports (has also locked up) [EMAIL PROTECTED] matt]$ ps wauxl | grep fetch root70213 0.0 0.3 816 660 p3 S+8:47AM 0:00.39 make fetch 0 63855 0 8 0 wait root70284 0.0 0.5 2604 1212 p3 S+8:47AM 0:00.14 /usr/bin/fetch - 0 70259 0 -8 0 nfsaio [EMAIL PROTECTED] matt]$ ps wauxl | grep ls root70307 0.0 0.2 772 480 p6 D+8:48AM 0:00.01 ls /usr/ports0 70302 0 -1 0 nfsrcv [EMAIL PROTECTED] matt]$ uname -a FreeBSD womble.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Oct 26 21:14:58 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WOMBLE i386 [EMAIL PROTECTED] matt]$ cat /etc/fstab | grep nfs 10.0.0.2:/usr/src /usr/srcnfs rw,soft,intr0 0 10.0.0.2:/usr/obj /usr/objnfs rw,soft,intr0 0 10.0.0.2:/usr/ports /usr/ports nfs rw,soft,intr0 0 rc.conf on the client contains: ifconfig_xl1=inet 10.0.0.1 netmask 255.255.255.0 nfs_client_enable=YES rc.conf on the server contains: ifconfig_xl0=DHCP rpcbind_enable=YES nfs_server_enable=YES mountd_enable=YES And this is the uname of the server: [EMAIL PROTECTED] src]# uname -a FreeBSD fraggle.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Oct 26 21:05:49 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FRAGGLE i386 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jumbograms ( em) nfs a no go
Michal Mertl wrote: I then left one computer at 4.9 and upgraded the other to 5.0. When I mount a partition from 5.0 machine I found out, that copying reliably works only from 5.0 to 4.9. The other way around I see messages 'em0: discard oversize frame (ether type 800 flags 3 len 67582 max 6014)' on 5.0 and the copying stalls. On 4.9 machine I later see 'nfs server 10.0.0.2:/usr: not responding'. The interface is stuck for some time - can be revived by changing mtu back to 1500 and down/up sequence. Implies the sending host is not honoring the MTU restriction when deciding whether or not to frag packets. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone object to the following change in libc?
On Fri, Oct 31, 2003 at 06:01:34PM +1100, Bruce Evans wrote:
POSIX requires in addition [u]int{8,16,32}_t, and [u]int64_t if 64 bit
integer types exist. It says that the existence of int8_t implies
that a byte is 8 bits and CHAR_BIT is 8. I'm not sure what prevents
int8_t being smaller than char.
It follows from the fact int8_t isn't allowed to contain padding bits and
from 6.2.6.1 saying:
Values stored in non-bit-field objects of any other object type consist of n ×
CHAR_BIT bits, where n is the size of an object of that type, in bytes.
Stefan
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone object to the following change in libc?
Bruce Evans wrote:
On Thu, 30 Oct 2003, Garrett Wollman wrote:
More specifically: IEEE Std. 1003.1-2001 is aligned to ISO/IEC
9899:1999 in all respects. C99 alignment was one of the principal
reasons for bringing out a whole new standard in the first place,
rather than continuing the amendment process. (This is also why POSIX
now requires eight-bit bytes.)
This doesn't follow, since C99 doesn't require 8-bit bits. int8_t is
optional in C99 and all code that uses it unconditionally is unportable.
Similarly for most other types in stdint.h. The required ones are
[u]int_least{8,16,32,64}_t and [u]int_fast{8,16,32,64}_t and [u]intmax_t,
i.e., nothing that can't be declared in C90 except a 64-bit type.
I believe that you meant to say uint8_t is optional, and int8_t is
required (see /usr/src/sys/*/include/_types.h). I think this was a
concession to IBM, which defaulted to unsigned characters, and
lacked a signed keyword in its compilers.
POSIX requires in addition [u]int{8,16,32}_t, and [u]int64_t if 64 bit
integer types exist. It says that the existence of int8_t implies
that a byte is 8 bits and CHAR_BIT is 8. I'm not sure what prevents
int8_t being smaller than char.
I think this comes down to the requirement for intergral arithmetic
types.
Someone asked for a 64 bit ino_t a while back, and wanted the thing
so they could squirrel away a cookie for themselves in the high 32
bits. On a 32 bit system, long long is not an integral artihmetic
type; if you pick the intersection of ISO C and POSIX (which requires
that ino_t be one of these types), then you are left with a 32 bit
value. On an LP64 (vs. an ILP64) system, you are also screwed, if
you want binary compatabilty. You also have to have 32 bit variants
for ABI compatability (assuming you still want to run 32 bit apps),
so you are thrice damned, since you will need to support a 32 bit
to 64 bit conversion to support the ABI32, and in doing, you will
have come up with a method which will work just as well to support
your 32 bits of cookie with a 32 bit ino_t in 64 bit mode.
FWIW, this same logic applies here: you can't have a char 8bits,
because if you did so, you would not have a valid arithmetic integral
type from which to create 8bit-sized things that must be one of those
types.
This pretty much guarantees that if you have *any* 32 bit values for
standards defined parameters/structure members for API's, you are
nailed to the LP64 cross, and can never go ILP64 safely so long as
you intend to support those API's. POSIX has a number of these,
BTW, which is why Sun didn't go whole-hog on the API's, and instead
defined things like stat64, etc. (yes, I know, off_t and size_t do
not have this restrictionl; some structure members do, though...).
-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone object to the following change in libc?
On Fri, 31 Oct 2003, Terry Lambert wrote:
Bruce Evans wrote:
... int8_t is
optional in C99 and all code that uses it unconditionally is unportable.
Similarly for most other types in stdint.h. The required ones are
[u]int_least{8,16,32,64}_t and [u]int_fast{8,16,32,64}_t and [u]intmax_t,
i.e., nothing that can't be declared in C90 except a 64-bit type.
I believe that you meant to say uint8_t is optional, and int8_t is
required (see /usr/src/sys/*/include/_types.h). I think this was a
concession to IBM, which defaulted to unsigned characters, and
lacked a signed keyword in its compilers.
No, I meant what I wrote. All fixed-width types are optional, at least
in the C99 draft (n869.txt). There is nothing special about uint8_t vs
int8_t except that it might not exist for a different reason.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Software RAID
I do software raid with atacontrol, and I believe it will boot even if one hard disk fails. here are my disk configuration: ar0: 57241MB ATA RAID1 array [7297/255/63] status: READY subdisks: 0 READY ad0: 57241MB WDC WD600AB-22CBA1 [116301/16/63] at ata0-master UDMA100 1 READY ad2: 57241MB WDC WD600AB-22CBA1 [116301/16/63] at ata1-master UDMA100 Mounting root from ufs:/dev/ar0s1a my here is my IDE controller: atapci1: Intel ICH2 ATA100 controller port 0x8800-0x880f at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata1: at 0x170 irq 15 on atapci1 nothing special and of course no any hardware support for raid :) to create such raid just type atacontrol create RAID1 ad0 ad2 that's it :) - Original Message - From: Steve Lee [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 31, 2003 02:22 AM Subject: Software RAID Does FreeBSD support Software RAID ? if so, what can it do ? RAID 0, 1, 5 ?? also would it be able to mirror the root parition ? Thanks. any advice would be cool. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
On Wed, 29 Oct 2003, Jeff Roberson wrote: On Thu, 30 Oct 2003, Bruce Evans wrote: Test for scheduling buildworlds: cd /usr/src/usr.bin for i in obj depend all do MAKEOBJDIRPREFIX=/somewhere/obj time make -s -j16 $i done /tmp/zqz 21 (Run this with an empty /somewhere/obj. The all stage doesn't quite finish.) On an ABIT BP6 system with a 400MHz and a 366MHz CPU, with /usr (including /usr/src) nfs-mounted (with 100 Mbps ethernet and a reasonably fast server) and /somewhere/obj ufs1-mounted (on a fairly slow disk; no soft-updates), this gives the following times: SCHED_ULE-yesterday, with not so careful setup: 40.37 real 8.26 user 6.26 sys 278.90 real59.35 user41.32 sys 341.82 real 307.38 user69.01 sys SCHED_ULE-today, run immediately after booting: 41.51 real 7.97 user 6.42 sys 306.64 real59.66 user40.68 sys 346.48 real 305.54 user69.97 sys SCHED_4BSD-yesterday, with not so careful setup: [same as today except the depend step was 10 seconds slower (real)] SCHED_4BSD-today, run immediately after booting: 18.89 real 8.01 user 6.66 sys 128.17 real58.33 user43.61 sys 291.59 real 308.48 user72.33 sys SCHED_4BSD-yesterday, with a UP kernel (running on the 366 MHz CPU) with many local changes and not so careful setup: 17.39 real 8.28 user 5.49 sys 130.51 real60.97 user34.63 sys 390.68 real 310.78 user60.55 sys Summary: SCHED_ULE was more than twice as slow as SCHED_4BSD for the obj and depend stages. These stages have little parallelism. SCHED_ULE was only 19% slower for the all stage. ... I reran this with -current (sched_ule.c 1.68, etc.). Result: no significant change. However, with a UP kernel there was no significant difference between the times for SCHED_ULE and SCHED_4BSD. There was a significant difference on UP until last week. I'm working on SMP now. I have some patches but they aren't quite ready yet. I have commited my SMP fixes. I would appreciate it if you could post update results. ULE now outperforms 4BSD in a single threaded kernel compile and performs almost identically in a 16 way make. I still have a few more things that I can do to improve the situation. I would expect ULE to pull further ahead in the months to come. The nice issue is still outstanding, as is the incorrect wcpu reporting. Cheers, Jeff Test 5 for fair scheduling related to niceness: for i in -20 -16 -12 -8 -4 0 4 8 12 16 20 do nice -$i sh -c while :; do echo -n;done done time top -o cpu With SCHED_ULE, this now hangs the system, but it worked yesterday. Today it doesn't get as far as running top and it stops the nfs server responding. To unhang the system and see what the above does, run a shell at rtprio 0 and start top before the above, and use top to kill processes (I normally use killall sh to kill all the shells generated by tests 1-5, but killall doesn't work if it is on nfs when the nfs server is not responding). This shows problems much more clearly with UP kernels. It gives the nice -20 and -16 processes approx. 55% and 50% of the CPU, respectively (the total is significantly more than 100%), and it gives approx. 0% of the CPU to the other sh processes (perhaps exactly 0). It also apparently gives gives 0% of the CPU to some important nfs process (I couldn't see exactly which) so the nfs server stops responding. SCHED_4BSD errs in the opposite direction by giving too many cycles to highly niced processes so it is naturally immune to this problem. With SMP, SCHED_ULE lets many more processes run. I seem to have broken something related to nice. I only tested interactivity and performance after my last round of changes. I have a standard test that I do that is similar to the one that you have posted here. I used it to gather results for my paper (http://www.chesapeake.net/~jroberson/ULE.pdf). There you can see what the intended nice curve is like. Oddly enough, I ran your test again on my laptop and I did not see 55% of the cpu going to nice -20. It was spread proportionally from -20 to 0 with postive nice values not receiving cpu time, as intended. It did not, however, let interactive processes proceed. This is certainly a bug and it sounds like there may be others which lead to the problems that you're having. The nfs server also sometimes stops reponding with only non-negatively niced processes (0 through 20 in the above), but it takes longer. The nfs server restarts if enough of the hog processes are killed. Apparently nfs has some critical process running at only user
Re: buildworld failed for current ..cvs 12.30 pm. 10-30-2003
On Thu, 30 Oct 2003, Kris Kennaway wrote: On Thu, Oct 30, 2003 at 08:08:08PM -0800, SteAltH FanThoM wrote: yes it does! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html 21.4.2 Check /etc/make.conf Examine the files /etc/defaults/make.conf and /etc/make.conf. The first contains some default defines - most of which are commented out. To make use of them when you rebuild your system from source, add them to /etc/make.conf. Keep in mind that anything you add to /etc/make.conf is also used every time you run make, so it is a good idea to set them to something sensible for your system. A typical user will probably want to copy the CFLAGS and NOPROFILE lines found in /etc/defaults/make.conf to /etc/make.conf and uncomment them. Bad advice. A typical user should not change CFLAGS or NOPROFILE. Examine the other definitions (COPTFLAGS, NOPORTDOCS and so on) and decide if they are relevant to you. Better advice. Examine these and change them if you can decide that they are relevant to you or want to learn what they do by making mistakes with them. Sure, but.. a good choice. I read the handbook and it advises to add the ... CFLAGS -0 -pipe and NOPROFILE= YES to /etc/make.conf. ^^ No it doesn't ;-) ..it doesn't say anything about -0 -pipe, which is a syntax error. Indded. What it says it to copy the CFLAGS and NOPROFILE lines from /etc/defaults/make.conf to /etc/make.conf and uncomment them. Copying CFLAGS and uncommenting is bogus since it just gives -O -pipe if correctly copied, but -O -pipe is the default. If incorrectly copied, then it gives a syntax error. Copying and uncommenting the NOPROFILE gives a small optimization if profiling is not used. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on ia64/ia64
TB --- 2003-10-31 10:45:30 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-31 10:45:30 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-10-31 10:45:30 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-10-31 10:47:37 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-10-31 11:52:26 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri Oct 31 11:52:26 GMT 2003 Kernel build for GENERIC completed on Fri Oct 31 12:08:34 GMT 2003 TB --- 2003-10-31 12:08:34 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- /usr/bin/make -B LINT TB --- 2003-10-31 12:08:34 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Oct 31 12:08:34 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/firewire/if_fwe.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/firewire/sbp.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/fxp/if_fxp.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath
Re: Still getting NFS client locking up
--- Original Message --- From: Matt Smith [EMAIL PROTECTED] Sent: Fri, 31 Oct 2003 08:55:49 + To: Robert Watson [EMAIL PROTECTED] Subject: Re: Still gettnig NFS client locking up Robert Watson wrote: On Tue, 28 Oct 2003, Soren Schmidt wrote: I'm now running a kernel/world of October 26th on both NFS client and server machines. I am still seeing NFS lockups as reported by several people in these threads: Me too!! Hmm. I'm unable to reproduce this so far, and I'm pounding several 5.x NFS clients and servers. I've been checking out using CVS over NFS, performing dd's of big files, etc. There must be something more I'm missing in reproducing this. What network interface cards are you using (client, server)? Are you using DHCP on the client or server? What commands trigger it -- what part of the NFS namespace, etc? Are you running the commands as root, or another user? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories I'm also experiencing lockups with NFS, but it's the server that locks up on mine. Both client and server are -CURRENT. Server was fresh as of two days ago, and the client is a week or two old. They are connected via bfe (server) and vr (client). The server, I've found, will last much longer if the mount options on the client include 'tcp' and 'nfsv3' (supposed to be default, but I'm just calling it like it is). Reading files seems to be okay, and I've managed to get as far as compiling a kernel on an NFS-mounted /usr, but a buildworld will hang in 30 minutes. The server is running dhcp and pf. All commands are being run as root. Kelley ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jumbograms ( em) nfs a no go
On Thu, 30 Oct 2003, Doug Ambrisko wrote: Michal Mertl writes: | On Thu, 30 Oct 2003, Sam Leffler wrote: | | On Thursday 30 October 2003 04:46 am, Michal Mertl wrote: | I wanted to test gigabit network performance and found out that current | (from 5.0 to up to date -current) doesn't fully work with jumbograms (MTU | set to 6000), Intel adapters and nfs (both UDP and TCP). | | I checked that the same thing works with 4.9. | | I then left one computer at 4.9 and upgraded the other to 5.0. When I | mount a partition from 5.0 machine I found out, that copying reliably | works only from 5.0 to 4.9. The other way around I see messages 'em0: | discard oversize frame (ether type 800 flags 3 len 67582 max 6014)' on | 5.0 and the copying stalls. On 4.9 machine I later see 'nfs server | 10.0.0.2:/usr: not responding'. The interface is stuck for some time - can | be revived by changing mtu back to 1500 and down/up sequence. | | I've ran many jumbogram tests of machines connected with a cross-over cable | and em devices at each end. If you've got a swtch in the middle make sure it | does the right thing. | | I also used exclusively crossover cable. The same configuration worked | with 4.9. The problem appears only with NFS. You might want to try this patch: Index: if_em.c === RCS file: /cvs/src/sys/dev/em/if_em.c,v retrieving revision 1.32 diff -c -r1.32 if_em.c *** if_em.c 15 Oct 2003 05:34:41 - 1.32 --- if_em.c 30 Oct 2003 19:39:49 - *** *** 2454,2460 BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ MCLBYTES,/* maxsize */ !1, /* nsegments */ MCLBYTES,/* maxsegsize */ BUS_DMA_ALLOCNOW,/* flags */ NULL,/* lockfunc */ --- 2454,2460 BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ MCLBYTES,/* maxsize */ !2, /* nsegments */ MCLBYTES,/* maxsegsize */ BUS_DMA_ALLOCNOW,/* flags */ NULL,/* lockfunc */ There was a few bugs in the system before in that there was insufficient error check in the bus_dma stuff. The issue was that HW was writing more then was the allocated due to (nsegments=1). This isn't the right fix but might help point to the issue. I don't have access to the HW to test it out anymore. Doug A. I'm afraid it doesn't help. The problem doesn't occur with FTP. For the last tests I've got two -current machines from Oct 30th. One exports a filesystem (server) and the other mounts it R/W (client). Copying /usr/src from server to client stalls (with 'em0: discard oversized frame...' on the receiver) and from client to server stalls too. NFS doesn't work (cp is uninterruptible and other access to remote fs stalls too). Client shows after some time 'nfs server 10.0.0.1:/usr: not responding'. At the time NFS doesn't work I can ping the other machine, so the interface isn't completely stuck. Copying one large file works from server to client but not the other way around. -- Michal Mertl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
Jeff Roberson [EMAIL PROTECTED] wrote: On Wed, 29 Oct 2003, Jeff Roberson wrote: On Thu, 30 Oct 2003, Bruce Evans wrote: Test for scheduling buildworlds: cd /usr/src/usr.bin for i in obj depend all do MAKEOBJDIRPREFIX=/somewhere/obj time make -s -j16 $i done /tmp/zqz 21 (Run this with an empty /somewhere/obj. The all stage doesn't quite finish.) On an ABIT BP6 system with a 400MHz and a 366MHz CPU, with/usr (including /usr/src) nfs-mounted (with 100 Mbps ethernet and a reasonably fast server) and /somewhere/obj ufs1-mounted (on a fairly slow disk; no soft-updates), this gives the following times: SCHED_ULE-yesterday, with not so careful setup: 40.37 real 8.26 user 6.26 sys 278.90 real59.35 user41.32 sys 341.82 real 307.38 user69.01 sys SCHED_ULE-today, run immediately after booting: 41.51 real 7.97 user 6.42 sys 306.64 real59.66 user40.68 sys 346.48 real 305.54 user69.97 sys SCHED_4BSD-yesterday, with not so careful setup: [same as today except the depend step was 10 seconds slower (real)] SCHED_4BSD-today, run immediately after booting: 18.89 real 8.01 user 6.66 sys 128.17 real58.33 user43.61 sys 291.59 real 308.48 user72.33 sys SCHED_4BSD-yesterday, with a UP kernel (running on the 366 MHz CPU) with many local changes and not so careful setup: 17.39 real 8.28 user 5.49 sys 130.51 real60.97 user34.63 sys 390.68 real 310.78 user60.55 sys Summary: SCHED_ULE was more than twice as slow as SCHED_4BSD for the obj and depend stages. These stages have little parallelism. SCHED_ULE was only 19% slower for the all stage. ... I reran this with -current (sched_ule.c 1.68, etc.). Result: no significant change. However, with a UP kernel there was no significant difference between the times for SCHED_ULE and SCHED_4BSD. There was a significant difference on UP until last week. I'm working on SMP now. I have some patches but they aren't quite ready yet. I have commited my SMP fixes. I would appreciate it if you could post update results. ULE now outperforms 4BSD in a single threaded kernel compile and performs almost identically in a 16 way make. I still have a few more things that I can do to improve the situation. I would expect ULE to pull further ahead in the months to come. I recently had to complete a little piece of software in a course on parallel computing. I've put it online[1] (we only had to write the pract2.cpp file). It calculates the inverse of a Vandermonde matrix and allows you to spawn multiple slave-processes who each perform a part of the work. Everything happens in memory so I've used it lately to test the different changes you made to sched_ule.c and these last fixes do improve the performance on my dual p3 machine a lot. Here are the results of my (very limited tests) : sched4bsd --- dimension slaves time 10001 90.925408 10002 58.897038 200 1 0.735962 200 2 0.676660 sched_ule 1.68 --- dimension slaves time 10001 90.951015 10002 70.402845 200 1 0.743551 200 2 1.900455 sched_ule 1.70 --- dimension slaves time 10001 90.782309 10002 57.207351 200 1 0.739998 200 2 0.383545 I'm not really sure if this is very relevant to you, but from the end-user point of view (me :-)) this does means something. Thanks! [1] http://users.pandora.be/bomberboy/mptest/final.tar.bz2 It can be used by running testpract2 with two arguments, the dimension of the matrix and the number of slaves. example './testpract2 200 2' will create a matrix with dimension 200 and 2 slaves. -- Bruno ... And then there's the guy who bought 20,000 bras, cut them in half, and sold 40,000 yamalchas with chin straps ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jumbograms ( em) nfs a no go
On Thu, 30 Oct 2003, Barney Wolff wrote: On Thu, Oct 30, 2003 at 08:04:58AM -0800, Sam Leffler wrote: I've ran many jumbogram tests of machines connected with a cross-over cable and em devices at each end. If you've got a swtch in the middle make sure it does the right thing. Just a minor note: GigE should not require a crossover cable. It's supposed to work to connect two GigE adapters with a straight-thru cable. I verified this with two Intel em NICs, quite a while ago. As I recall, when I used a crossover cable, I could not get the adapters to go to 1000, only 100. That might have been the cable, or not. I can confirm it works equally well with crossover as with straight cable. -- Michal Mertl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone object to the following change in libc?
On Fri, 31 Oct 2003 18:01:34 +1100 (EST), Bruce Evans [EMAIL PROTECTED] said:
POSIX requires in addition [u]int{8,16,32}_t, and [u]int64_t if 64 bit
integer types exist. It says that the existence of int8_t implies
that a byte is 8 bits and CHAR_BIT is 8. I'm not sure what prevents
int8_t being smaller than char.
Nothing can be smaller than char (except bitfields, which you can't
take the size of anyway).
The full story:
The POSIX sockets standard (I forget which letter it had) introduced
uint8_t et al, but was aligned to C90. That amendment was integrated
into the main text at the same time as C99 was, and late in the
process we realized that C99's definition of uint8_t is much stricter
than what the socket standard expected. (Specifically, the socket
standard allows uint8_t to have padding bits that do not participate
in the domain of the type, but C99 does not.) Faced with the choice
of having to invent from whole cloth a completely new set of
interfaces to describe packing and unpacking eight-bit network data in
nine- or sixteen-bit characters, or specifying an explicit byte size,
we chose the latter. It helped that there were no more 36-bit
platforms to be concerned about. (Some would say that this was a
rather belated recognition of a choice the industry made two decades
ago There was, however, a 36-bit implementation of FIPS 151-2, by
UNISYS.)
-GAWollman
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone object to the following change in libc?
On Fri, Oct 31, 2003 at 10:06:43AM -0500, Garrett Wollman wrote:
On Fri, 31 Oct 2003 18:01:34 +1100 (EST), Bruce Evans [EMAIL PROTECTED] said:
POSIX requires in addition [u]int{8,16,32}_t, and [u]int64_t if 64 bit
integer types exist. It says that the existence of int8_t implies
that a byte is 8 bits and CHAR_BIT is 8. I'm not sure what prevents
int8_t being smaller than char.
Nothing can be smaller than char (except bitfields, which you can't
take the size of anyway).
Perhaps not smaller in terms of the sizeof operator, but why can't one
have a 16-bit char, and an int8_t which occupies 16 bits, but only uses
8 of them - the other 8 being padding?
The full story:
The POSIX sockets standard (I forget which letter it had) introduced
uint8_t et al, but was aligned to C90. That amendment was integrated
into the main text at the same time as C99 was, and late in the
process we realized that C99's definition of uint8_t is much stricter
than what the socket standard expected. (Specifically, the socket
standard allows uint8_t to have padding bits that do not participate
in the domain of the type, but C99 does not.) Faced with the choice
Where in C99 does it say that uint8_t can't have padding bits?
I can't find anything in n869.txt to that effect.
As far as I can tell, the only type that is not allowed to have any
padding bits or trap representations is unsigned char.
of having to invent from whole cloth a completely new set of
interfaces to describe packing and unpacking eight-bit network data in
nine- or sixteen-bit characters, or specifying an explicit byte size,
we chose the latter. It helped that there were no more 36-bit
platforms to be concerned about. (Some would say that this was a
rather belated recognition of a choice the industry made two decades
ago There was, however, a 36-bit implementation of FIPS 151-2, by
UNISYS.)
--
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR ip_dummynet.c:1138
just for info ~~~cur~~~ lock order reversal 1st 0xc0962ba0 dummynet (dummynet) @ /usr/src/sys/netinet/ip_dummynet.c:1138 2nd 0xc2229a90 rtentry (rtentry) @ /usr/src/sys/netinet/ip_dummynet.c:1200 Stack backtrace: backtrace(c0875f98,c2229a90,c087c023,c087c023,c087d2ec) at backtrace+0x17 witness_lock(c2229a90,8,c087d2ec,4b0,c0667043) at witness_lock+0x672 _mtx_lock_flags(c2229a90,0,c087d2ec,4b0,b3) at _mtx_lock_flags+0xba dummynet_io(c138ee00,399,1,cb620b78,cb620b4c) at dummynet_io+0x2c5 ip_output(c138ee00,0,c220f03c,0,0) at ip_output+0x7b3 tcp_output(c2210590,c1f93450,c2038e40,16b,c1f93450) at tcp_output+0xce6 tcp_usr_connect(c2247550,c1f93450,c2038e40,0,cb620cc4) at tcp_usr_connect+0x114 soconnect(c2247550,c1f93450,c2038e40,0,bfbffbe0) at soconnect+0x61 kern_connect(c2038e40,c,c1f93450,c1f93450,c21d5250) at kern_connect+0x88 connect(c2038e40,cb620d10,c0890579,3f0,3) at connect+0x43 syscall(2f,2f,2f,bfbffbfc,2) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (98), eip = 0x283613af, esp = 0xbfbffbcc, ebp = 0xbfbffc18 --- ~~~cut~~~ and then after kernel panic ~~~cut~~~ (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc063febc in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc0640247 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc063607b in propagate_priority (td=0x0) at /usr/src/sys/kern/kern_mutex.c:124 #4 0xc0636889 in _mtx_lock_sleep (m=0xc0962ba0, opts=0, file=0xc087d2ec /usr/src/sys/netinet/ip_dummynet.c, line=748) at /usr/src/sys/kern/kern_mutex.c:635 #5 0xc06362d7 in _mtx_lock_flags (m=0xc0962ba0, opts=0, file=0xc087d2ec /usr/src/sys/netinet/ip_dummynet.c, line=748) at /usr/src/sys/kern/kern_mutex.c:333 #6 0xc06d0312 in dummynet (unused=0x0) at /usr/src/sys/netinet/ip_dummynet.c:748 #7 0xc0650748 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:225 #8 0xc062c0a2 in ithread_loop (arg=0xc137cc80) at /usr/src/sys/kern/kern_intr.c:540 #9 0xc062b0a4 in fork_exit (callout=0xc062bf10 ithread_loop, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:793 (kgdb) up 4 #4 0xc0636889 in _mtx_lock_sleep (m=0xc0962ba0, opts=0, file=0xc087d2ec /usr/src/sys/netinet/ip_dummynet.c, line=748) at /usr/src/sys/kern/kern_mutex.c:635 635 propagate_priority(td); (kgdb) list 630 * Save who we're blocked on. 631 */ 632 td-td_blocked = m; 633 td-td_lockname = m-mtx_object.lo_name; 634 TD_SET_LOCK(td); 635 propagate_priority(td); 636 637 if (LOCK_LOG_TEST(m-mtx_object, opts)) 638 CTR3(KTR_LOCK, 639 _mtx_lock_sleep: p %p blocked on [%p] %s, td, m, ~~~cut~~~ Jiri ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
I could have caused error in gnu on current buildworld.
A few days ago I lost some files in /usr/src/gnu and erased /usr/src/gnu/* cvsuped to recover the files and now my build world stops in sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 strfile /usr/obj/usr/src/i386/legacy/usr/games === gnu/usr.bin/gperf make: don't know how to make bsd.README. Stop *** Error code 2 Did I miss something in my cvsup or is there a problem. Thanks, ed - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-R and 5.1-C floppies will not boot on SuperMicro 6023P-8R
Does anyone have any thoughts regarding this? I would like to get 5.1 on this server. Thank you, Stephane Raimbault. - Original Message - From: Stephane Raimbault [EMAIL PROTECTED] Newsgroups: mailing.freebsd.current Sent: Wednesday, October 29, 2003 4:07 PM Subject: 5.1-R and 5.1-C floppies will not boot on SuperMicro 6023P-8R Hi, I'm trying to install 5.1-R or 5.1-C from floppies redirected output to = serial port and it won't boot to the install screen. 4.9-R floppies = with output redirected to serial port works and installs properly. This = is what I get on my serial console when I try to boot on 5.1-C (similar = to 5.1-R) seems to hang after the vga0 shows up during boot. Is there anything I can do or provide to resolve my install problem? Uncompressing ... done Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 633kB/4061120kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Wed Oct 29 04:14:01 GMT 2003) include /boot/device.hints set hint.fdc.0.at=3Disa set hint.fdc.0.port=3D0x3F0 set hint.fdc.0.irq=3D6 set hint.fdc.0.drq=3D2 set hint.fd.0.at=3Dfdc0 set hint.fd.0.drive=3D0 set hint.fd.1.at=3Dfdc0 set hint.fd.1.drive=3D1 set hint.ata.0.at=3Disa set hint.ata.0.port=3D0x1F0 set hint.ata.0.irq=3D14 set hint.ata.1.at=3Disa set hint.ata.1.port=3D0x170 set hint.ata.1.irq=3D15 set hint.adv.0.at=3Disa set hint.adv.0.disabled=3D1 set hint.bt.0.at=3Disa set hint.bt.0.disabled=3D1 set hint.aha.0.at=3Disa set hint.aha.0.disabled=3D1 set hint.aic.0.at=3Disa set hint.aic.0.disabled=3D1 set hint.atkbdc.0.at=3Disa set hint.atkbdc.0.port=3D0x060 set hint.atkbd.0.at=3Datkbdc set hint.atkbd.0.irq=3D1 set hint.atkbd.0.flags=3D0x1 set hint.psm.0.at=3Datkbdc set hint.psm.0.irq=3D12 set hint.vga.0.at=3Disa set hint.sc.0.at=3Disa set hint.sc.0.flags=3D0x100 set hint.vt.0.at=3Disa set hint.vt.0.disabled=3D1 set hint.apm.0.disabled=3D1 set hint.apm.0.flags=3D0x20 set hint.pcic.0.at=3Disa set hint.pcic.0.port=3D0x3e0 set hint.pcic.0.maddr=3D0xd set hint.pcic.1.at=3Disa set hint.pcic.1.irq=3D11 set hint.pcic.1.port=3D0x3e2 set hint.pcic.1.maddr=3D0xd4000 set hint.pcic.1.disabled=3D1 set hint.sio.0.at=3Disa set hint.sio.0.port=3D0x3F8 set hint.sio.0.flags=3D0x10 set hint.sio.0.irq=3D4 set hint.sio.1.at=3Disa set hint.sio.1.port=3D0x2F8 set hint.sio.1.irq=3D3 set hint.sio.2.at=3Disa set hint.sio.2.disabled=3D1 set hint.sio.2.port=3D0x3E8 set hint.sio.2.irq=3D5 set hint.sio.3.at=3Disa set hint.sio.3.disabled=3D1 set hint.sio.3.port=3D0x2E8 set hint.sio.3.irq=3D9 set hint.ppc.0.at=3Disa set hint.ppc.0.irq=3D7 set hint.ed.0.at=3Disa set hint.ed.0.disabled=3D1 set hint.ed.0.port=3D0x280 set hint.ed.0.irq=3D10 set hint.ed.0.maddr=3D0xd8000 set hint.cs.0.at=3Disa set hint.cs.0.disabled=3D1 set hint.cs.0.port=3D0x300 set hint.sn.0.at=3Disa set hint.sn.0.disabled=3D1 set hint.sn.0.port=3D0x300 set hint.sn.0.irq=3D10 set hint.ie.0.at=3Disa set hint.ie.0.disabled=3D1 set hint.ie.0.port=3D0x300 set hint.ie.0.irq=3D10 set hint.ie.0.maddr=3D0xd set hint.fe.0.at=3Disa set hint.fe.0.disabled=3D1 set hint.fe.0.port=3D0x300 set hint.le.0.at=3Disa set hint.le.0.disabled=3D1 set hint.le.0.port=3D0x300 set hint.le.0.irq=3D5 set hint.le.0.maddr=3D0xd set hint.lnc.0.at=3Disa set hint.lnc.0.disabled=3D1 set hint.lnc.0.port=3D0x280 set hint.lnc.0.irq=3D10 set hint.lnc.0.drq=3D0 load /kernel /kernel text=3D0x23b500 data=3D0x2f024+0x4bedc / echo \007\007 echo Please insert MFS root floppy and press enter: Please insert MFS root floppy and press enter: read load -t mfs_root /mfsroot set hint.acpi.0.disabled=3D1 set driver_floppy=3DYES set module_path=3D/modules;/dist echo \007\007 autoboot 10 Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/kernel]... 131072K of memory above 4GB ignored Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD 5.1-CURRENT-20031029-JPSNAP #0: Wed Oct 29 04:30:49 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BOOTMFS Preloaded elf kernel /kernel at 0xc0af1000. Preloaded mfs_root /mfsroot at 0xc0af12c0. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) Origin =3D GenuineIntel Id =3D 0xf25 Stepping =3D 5 = Features=3D0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PG= E,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory =3D 4160225280 (3967 MB) avail memory =3D 4043710464 (3856 MB) Pentium Pro MTRR support enabled md0: Preloaded image /mfsroot 4423680 bytes at
Re: __fpclassifyd problem
Scott Long wrote: M. Warner Losh wrote: In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : To respond to myself, I got ahold of a 4.8 libm.so and made sure that the : linker used it. No change in the problem, and it still hints that the : native libc is being linked in. You might want to enable debugging of ld.so to confirm. Warner This was already resolved. Java does a dlopen() on /usr/lib/libc.so. Rumor has it that this is fixed. Scott But still after importing e_scalb.c or e_scalbf.c and rebuilding gives me this: cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c i387_s_tan.S -o i387_s_tan.So building shared library libm.so.2 e_scalb.So: In function `__ieee754_scalbf': e_scalb.So(.text+0x0): multiple definition of `__ieee754_scalbf' e_scalbf.So(.text+0x0): first defined here *** Error code 1 /John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
On Fri, 31 Oct 2003, Jeff Roberson wrote: I have commited my SMP fixes. I would appreciate it if you could post update results. ULE now outperforms 4BSD in a single threaded kernel compile and performs almost identically in a 16 way make. I still have a few more things that I can do to improve the situation. I would expect ULE to pull further ahead in the months to come. My simple make benchmark now takes infinitely longer with ULE under SMP, since make -j 16 with ULE under SMP now hangs nfs after about a minute. 4BSD works better. However, some networking bugs have developed in the last few days. One of their manifestations is that SMP kernels always panic in sbdrop() on shutdown. The nice issue is still outstanding, as is the incorrect wcpu reporting. It may be related to nfs processes not getting any cycles even when there are no niced processes. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Fri, Oct 31, 2003, John Angelmo wrote: But still after importing e_scalb.c or e_scalbf.c and rebuilding gives me this: cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c i387_s_tan.S -o i387_s_tan.So building shared library libm.so.2 e_scalb.So: In function `__ieee754_scalbf': e_scalb.So(.text+0x0): multiple definition of `__ieee754_scalbf' e_scalbf.So(.text+0x0): first defined here *** Error code 1 Sounds like you might have accidentally imported e_scalbf.c twice---once as e_scalbf.c and once as e_scalb.c. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone object to the following change in libc?
On Fri, Oct 31, 2003 at 04:43:37PM +0100, Erik Trulsson wrote: Perhaps not smaller in terms of the sizeof operator, but why can't one have a 16-bit char, and an int8_t which occupies 16 bits, but only uses 8 of them - the other 8 being padding? 7.18.1.1 Exact-width integer types 1 The typedef name intN_t designates a signed integer type with width N, no padding bits, and a two's complement representation. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits. Where in C99 does it say that uint8_t can't have padding bits? I can't find anything in n869.txt to that effect. As far as I can tell, the only type that is not allowed to have any padding bits or trap representations is unsigned char. uint8_t is int8_t's corresponding unsigned type. This means sizeof(uint8_t) == sizeof(int8_t), thus uint8_t can't have padding bits either. Cheers, Stefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone object to the following change in libc?
On Fri, Oct 31, 2003 at 06:20:17PM +0100, Stefan Farfeleder wrote: On Fri, Oct 31, 2003 at 04:43:37PM +0100, Erik Trulsson wrote: Perhaps not smaller in terms of the sizeof operator, but why can't one have a 16-bit char, and an int8_t which occupies 16 bits, but only uses 8 of them - the other 8 being padding? 7.18.1.1 Exact-width integer types 1 The typedef name intN_t designates a signed integer type with width N, no padding bits, and a two's complement representation. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits. I see. My confusion stems from the fact that n869.txt (the last publically available draft of the C99 standard) says 7.18.1.1 Exact-width integer types [#1] The typedef name intN_t designates a signed integer type with width N. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits. The , no padding bits part is apparently one of the things that were changed between n869.txt and the final standard. Note to self: I really need to get a copy of the final C99 standard as soon as I can afford one. Where in C99 does it say that uint8_t can't have padding bits? I can't find anything in n869.txt to that effect. As far as I can tell, the only type that is not allowed to have any padding bits or trap representations is unsigned char. uint8_t is int8_t's corresponding unsigned type. This means sizeof(uint8_t) == sizeof(int8_t), thus uint8_t can't have padding bits either. Yes, with the quote from the standard you supplied above, that becomes clear. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jumbograms ( em) nfs a no go
On Fri, Oct 31, 2003 at 12:56:11AM -0800, Terry Lambert wrote: Michal Mertl wrote: I then left one computer at 4.9 and upgraded the other to 5.0. When I mount a partition from 5.0 machine I found out, that copying reliably works only from 5.0 to 4.9. The other way around I see messages 'em0: discard oversize frame (ether type 800 flags 3 len 67582 max 6014)' on 5.0 and the copying stalls. On 4.9 machine I later see 'nfs server 10.0.0.2:/usr: not responding'. The interface is stuck for some time - can be revived by changing mtu back to 1500 and down/up sequence. Implies the sending host is not honoring the MTU restriction when deciding whether or not to frag packets. 67582 looks awfully bogus even as a pre-frag length. How could that come over the wire? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Fri, Oct 31, 2003 at 05:55:46PM +0100, John Angelmo wrote: This was already resolved. Java does a dlopen() on /usr/lib/libc.so. Rumor has it that this is fixed. Scott But still after importing e_scalb.c or e_scalbf.c and rebuilding gives me this: cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c i387_s_tan.S -o i387_s_tan.So building shared library libm.so.2 e_scalb.So: In function `__ieee754_scalbf': e_scalb.So(.text+0x0): multiple definition of `__ieee754_scalbf' e_scalbf.So(.text+0x0): first defined here *** Error code 1 Apart from your libm problem (which I didn't see when I did this locally), the fix to the java ports are not yet committed. Kris pgp0.pgp Description: PGP signature
Re: I could have caused error in gnu on current buildworld.
On Fri, Oct 31, 2003 at 08:36:38AM -0800, [EMAIL PROTECTED] wrote: A few days ago I lost some files in /usr/src/gnu and erased /usr/src/gnu/* cvsuped to recover the files and now my build world stops in sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 strfile /usr/obj/usr/src/i386/legacy/usr/games === gnu/usr.bin/gperf make: don't know how to make bsd.README. Stop *** Error code 2 Did I miss something in my cvsup or is there a problem. How do we know unless you show us your cvsupfile? :-) Kris pgp0.pgp Description: PGP signature
Re: More ULE bugs fixed.
On Friday 31 October 2003 09:04 am, Bruce Evans wrote: My simple make benchmark now takes infinitely longer with ULE under SMP, since make -j 16 with ULE under SMP now hangs nfs after about a minute. 4BSD works better. However, some networking bugs have developed in the last few days. One of their manifestations is that SMP kernels always panic in sbdrop() on shutdown. I'm looking at something similar now. If you have a stack trace please send it to me (along with any other info). You might also try booting debug.mpsafenet=0. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: runningbufspace related lock-ups with md(4)/UFS/SU (PATCH ?)
Brian F. Feldman [EMAIL PROTECTED] wrote: Kirk McKusick [EMAIL PROTECTED] wrote: I have been able to reproduce your hang on my system and your suggested fix does prevent it. I am going to run some more buffer starvation-type tests on it this week and if they do not cause other problems, I will put in your suggested fix. Thanks, Kirk; seems everyone who's been able to reproduce it can't do so anymore when the synchers are disallowed from waiting on runningbufspace (a couple extra people testing it that haven't spoken up on the list). Replying to myself -- anyone with any further thoughts, objections, desire to fix this one way or another? -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
David Schultz wrote: On Fri, Oct 31, 2003, John Angelmo wrote: But still after importing e_scalb.c or e_scalbf.c and rebuilding gives me this: cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c i387_s_tan.S -o i387_s_tan.So building shared library libm.so.2 e_scalb.So: In function `__ieee754_scalbf': e_scalb.So(.text+0x0): multiple definition of `__ieee754_scalbf' e_scalbf.So(.text+0x0): first defined here *** Error code 1 Sounds like you might have accidentally imported e_scalbf.c twice---once as e_scalbf.c and once as e_scalb.c. I used this: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/lib/msun/src/e_scalb.c?rev=1.10content-type=text/plainonly_with_tag=HEAD and this: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/lib/msun/src/e_scalbf.c?rev=1.8content-type=text/plainonly_with_tag=HEAD for the diffrent files, and I checked/tested multiple times now, the files are imported correcty (simple copy paste) I'm using 5.1-p10 and get that error /John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADSUP: if_xname changes incoming
I will be commiting the if_xname changes momentairly. If you experience any problems with this commit, please let me know ASAP. I'll send an all clear once I've sucessfully built a world/kernel from CVS. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Weird behavior with /dev/mem
Weird thing. I updated my system today (October 31), and now I can't list routes from syscons. But I still can list routes from Konsole, on X. Following a suggestion by Genesys, I checked permissions of /dev/mem and netstat and... for some reason, I can't stat /dev/mem under syscons! Here are a couple of typescripts I got: [0] [EMAIL PROTECTED]:/opt/home/dcs$ cat from_konsole Script started on Fri Oct 31 17:25:04 2003 [EMAIL PROTECTED]:/opt/home/dcs$ ls -ld /dev dr-xr-xr-x 4 root wheel 512 Oct 31 13:56 /dev [EMAIL PROTECTED]:/opt/home/dcs$ ls -l /dev/mem crw-r- 1 root kmem2, 0 Oct 31 15:54 /dev/mem [EMAIL PROTECTED]:/opt/home/dcs$ ls -l /usr/bin/netstat -r-xr-sr-x 1 root kmem 108664 Oct 31 13:18 /usr/bin/netstat [EMAIL PROTECTED]:/opt/home/dcs$ netstat -nr Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default10.0.11.1 UGSc00 fxp0 10/16 link#1 UC 00 fxp0 10.0.2.72 00:04:23:2a:13:7b UHLW01 fxp0881 10.0.11.1 00:10:54:cd:58:40 UHLW 280 fxp0 1197 10.0.12.13100:01:30:26:e0:00 UHLW00 fxp0 1186 10.0.14.20 00:02:55:58:22:0a UHLW639928 fxp0975 127.0.0.1 127.0.0.1 UH 06lo0 [EMAIL PROTECTED]:/opt/home/dcs$ exit exit Script done on Fri Oct 31 17:25:20 2003 [0] [EMAIL PROTECTED]:/opt/home/dcs$ cat from_syscons Script started on Fri Oct 31 17:26:01 2003 [EMAIL PROTECTED]:/root$ ls -ld /dev dr-xr-xr-x 4 root wheel 512 Oct 31 13:56 /dev [EMAIL PROTECTED]:/root$ ls -l /dev/mem ls: /dev/mem: Permission denied [EMAIL PROTECTED]:/root$ ls -l /usr/bin/netstat -r-xr-sr-x 1 root kmem 108664 Oct 31 13:18 /usr/bin/netstat [EMAIL PROTECTED]:/root$ netstat -nr netstat: kvm not available Routing tables rt_tables: symbol not in namelist [EMAIL PROTECTED]:/root$ exit exit Script done on Fri Oct 31 17:26:18 2003 [0] [EMAIL PROTECTED]:/opt/home/dcs$ which ls /bin/ls [0] [EMAIL PROTECTED]:/opt/home/dcs$ type ls ls is aliased to `ls -G' [0] [EMAIL PROTECTED]:/opt/home/dcs$ unalias ls [0] [EMAIL PROTECTED]:/opt/home/dcs$ ls -l /dev/mem crw-r- 1 root kmem2, 0 Oct 31 15:54 /dev/mem I'm CCing phk on the grounds of Mr Devfs, and Sam as I blamed the networking code earlier... :-) -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Ignisecond, n.: The overlapping moment of time when the hand is locking the car door even as the brain is saying, my keys are in there! -- Rich Hall, Sniglets ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Toshiba Portege R100: 5.1-JPSNAP install CD hangs
Hi, booting a Toshiba Portege R100 off Wednesday's 5.1-JPSNAP install CD hangs early during the boot, with or without ACPI. It may be related to probing the graphics chip, see the attached snapshot. I've also attached the 4.9 dmesg - 4.9 boots fine off its install CD - in case that helps. Any ideas? Thanks, Lars PS: Sorry for posting an image - the laptop has no serial port. -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.9-RELEASE #0: Mon Oct 27 17:51:09 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz CPU: Intel(R) Pentium(R) M processor 1000MHz (997.50-MHz 686-class CPU) Origin = GenuineIntel Id = 0x695 Stepping = 5 Features=0xa7e9f9bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE real memory = 805085184 (786216K bytes) avail memory = 777445376 (759224K bytes) Preloaded elf kernel kernel at 0xc053f000. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 7 entries at 0xc00f0200 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 agp0: Intel 82855 host to AGP bridge mem 0xc000-0xcfff at device 0.0 on pci0 pcib1: PCI to PCI bridge (vendor=8086 device=3341) at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: Trident model 2100 VGA-compatible display device at 0.0 irq 11 uhci0: Intel 82801DB (ICH4) USB controller USB-A port 0xefe0-0xefff irq 11 at device 29.0 on pci0 usb0: Intel 82801DB (ICH4) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801DB (ICH4) USB controller USB-B port 0xef80-0xef9f irq 11 at device 29.1 on pci0 usb1: Intel 82801DB (ICH4) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: USB controller at 29.7 pcib2: PCI to PCI bridge (vendor=8086 device=2448) at device 30.0 on pci0 pci2: PCI bus on pcib2 fxp0: Intel 82801DB (ICH4) Pro/100 VE Ethernet port 0xcf40-0xcf7f mem 0xdfdff000-0xdfdf irq 11 at device 8.0 on pci2 fxp0: Ethernet address 00:08:0d:3b:4c:17 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci2: unknown card (vendor=0x8086, dev=0x1043) at 10.0 irq 11 pci_cfgintr_linked: linked (60) to hard-routed irq 11 pci_cfgintr: 2:11 INTA routed to irq 11 pcic0: Toshiba ToPIC100 PCI-CardBus Bridge irq 11 at device 11.0 on pci2 pcic0: PCI Memory allocated: 0x8800 pccard0: PC Card 16-bit bus (classic) on pcic0 pci2: unknown card (vendor=0x1179, dev=0x0805) at 13.0 isab0: PCI to ISA bridge (vendor=8086 device=24cc) at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Generic PCI ATA controller port 0xbfa0-0xbfaf,0xbfe4-0xbfe7,0xbfe8-0xbfef,0xbff4-0xbff7,0xbff8-0xbfff irq 11 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: unknown card (vendor=0x8086, dev=0x24c5) at 31.5 pci0: unknown card (vendor=0x8086, dev=0x24c6) at 31.6 orm0: Option ROMs at iomem 0xc-0xcbfff,0xe-0xe on isa0 pmtimer0 on isa0 fdc0: ready for input in output fdc0: cmd 3 failed at out byte 1 of 3 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 sio1: configured irq 3 not in bitmap of probed irqs 0 ppc0: parallel port not found. ad0: 38147MB TOSHIBA MK4004GAH [77506/16/63] at ata0-master BIOSDMA Mounting root from ufs:/dev/ad0s2a smime.p7s Description: S/MIME Cryptographic Signature
Re: Weird behavior with /dev/mem
On Fri, 31 Oct 2003, Daniel C. Sobral wrote: Weird thing. I updated my system today (October 31), and now I can't list routes from syscons. But I still can list routes from Konsole, on X. Following a suggestion by Genesys, I checked permissions of /dev/mem and netstat and... for some reason, I can't stat /dev/mem under syscons! You didn't mount that filesystem nosuid, did you? Here are a couple of typescripts I got: [0] [EMAIL PROTECTED]:/opt/home/dcs$ cat from_konsole Script started on Fri Oct 31 17:25:04 2003 [EMAIL PROTECTED]:/opt/home/dcs$ ls -ld /dev dr-xr-xr-x 4 root wheel 512 Oct 31 13:56 /dev [EMAIL PROTECTED]:/opt/home/dcs$ ls -l /dev/mem crw-r- 1 root kmem2, 0 Oct 31 15:54 /dev/mem [EMAIL PROTECTED]:/opt/home/dcs$ ls -l /usr/bin/netstat -r-xr-sr-x 1 root kmem 108664 Oct 31 13:18 /usr/bin/netstat [EMAIL PROTECTED]:/opt/home/dcs$ netstat -nr Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default10.0.11.1 UGSc00 fxp0 10/16 link#1 UC 00 fxp0 10.0.2.72 00:04:23:2a:13:7b UHLW01 fxp0881 10.0.11.1 00:10:54:cd:58:40 UHLW 280 fxp0 1197 10.0.12.13100:01:30:26:e0:00 UHLW00 fxp0 1186 10.0.14.20 00:02:55:58:22:0a UHLW639928 fxp0975 127.0.0.1 127.0.0.1 UH 06lo0 [EMAIL PROTECTED]:/opt/home/dcs$ exit exit Script done on Fri Oct 31 17:25:20 2003 [0] [EMAIL PROTECTED]:/opt/home/dcs$ cat from_syscons Script started on Fri Oct 31 17:26:01 2003 [EMAIL PROTECTED]:/root$ ls -ld /dev dr-xr-xr-x 4 root wheel 512 Oct 31 13:56 /dev [EMAIL PROTECTED]:/root$ ls -l /dev/mem ls: /dev/mem: Permission denied [EMAIL PROTECTED]:/root$ ls -l /usr/bin/netstat -r-xr-sr-x 1 root kmem 108664 Oct 31 13:18 /usr/bin/netstat [EMAIL PROTECTED]:/root$ netstat -nr netstat: kvm not available Routing tables rt_tables: symbol not in namelist [EMAIL PROTECTED]:/root$ exit exit Script done on Fri Oct 31 17:26:18 2003 [0] [EMAIL PROTECTED]:/opt/home/dcs$ which ls /bin/ls [0] [EMAIL PROTECTED]:/opt/home/dcs$ type ls ls is aliased to `ls -G' [0] [EMAIL PROTECTED]:/opt/home/dcs$ unalias ls [0] [EMAIL PROTECTED]:/opt/home/dcs$ ls -l /dev/mem crw-r- 1 root kmem2, 0 Oct 31 15:54 /dev/mem I'm CCing phk on the grounds of Mr Devfs, and Sam as I blamed the networking code earlier... :-) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird behavior with /dev/mem
Doug White wrote: On Fri, 31 Oct 2003, Daniel C. Sobral wrote: Weird thing. I updated my system today (October 31), and now I can't list routes from syscons. But I still can list routes from Konsole, on X. Following a suggestion by Genesys, I checked permissions of /dev/mem and netstat and... for some reason, I can't stat /dev/mem under syscons! You didn't mount that filesystem nosuid, did you? No. And, as a matter of fact, the error is user-agnostic. In fact, in the example below the problem happen with the root user, while user dcs is home free. MM... I know what it is. It's something with mac, because X is run with /usr/sbin/setpmac mls/equal. (tests) Yep, that's it. Ok, rwatson, it's all your fault. Sneaky, sneaky. Here are a couple of typescripts I got: [0] [EMAIL PROTECTED]:/opt/home/dcs$ cat from_konsole Script started on Fri Oct 31 17:25:04 2003 [EMAIL PROTECTED]:/opt/home/dcs$ ls -ld /dev dr-xr-xr-x 4 root wheel 512 Oct 31 13:56 /dev [EMAIL PROTECTED]:/opt/home/dcs$ ls -l /dev/mem crw-r- 1 root kmem2, 0 Oct 31 15:54 /dev/mem [EMAIL PROTECTED]:/opt/home/dcs$ ls -l /usr/bin/netstat -r-xr-sr-x 1 root kmem 108664 Oct 31 13:18 /usr/bin/netstat [EMAIL PROTECTED]:/opt/home/dcs$ netstat -nr Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default10.0.11.1 UGSc00 fxp0 10/16 link#1 UC 00 fxp0 10.0.2.72 00:04:23:2a:13:7b UHLW01 fxp0881 10.0.11.1 00:10:54:cd:58:40 UHLW 280 fxp0 1197 10.0.12.13100:01:30:26:e0:00 UHLW00 fxp0 1186 10.0.14.20 00:02:55:58:22:0a UHLW639928 fxp0975 127.0.0.1 127.0.0.1 UH 06lo0 [EMAIL PROTECTED]:/opt/home/dcs$ exit exit Script done on Fri Oct 31 17:25:20 2003 [0] [EMAIL PROTECTED]:/opt/home/dcs$ cat from_syscons Script started on Fri Oct 31 17:26:01 2003 [EMAIL PROTECTED]:/root$ ls -ld /dev dr-xr-xr-x 4 root wheel 512 Oct 31 13:56 /dev [EMAIL PROTECTED]:/root$ ls -l /dev/mem ls: /dev/mem: Permission denied [EMAIL PROTECTED]:/root$ ls -l /usr/bin/netstat -r-xr-sr-x 1 root kmem 108664 Oct 31 13:18 /usr/bin/netstat [EMAIL PROTECTED]:/root$ netstat -nr netstat: kvm not available Routing tables rt_tables: symbol not in namelist [EMAIL PROTECTED]:/root$ exit exit Script done on Fri Oct 31 17:26:18 2003 [0] [EMAIL PROTECTED]:/opt/home/dcs$ which ls /bin/ls [0] [EMAIL PROTECTED]:/opt/home/dcs$ type ls ls is aliased to `ls -G' [0] [EMAIL PROTECTED]:/opt/home/dcs$ unalias ls [0] [EMAIL PROTECTED]:/opt/home/dcs$ ls -l /dev/mem crw-r- 1 root kmem2, 0 Oct 31 15:54 /dev/mem I'm CCing phk on the grounds of Mr Devfs, and Sam as I blamed the networking code earlier... :-) -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Ten years of rejection slips is nature's way of telling you to stop writing. -- R. Geis ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Toshiba Portege R100: 5.1-JPSNAP install CD hangs
Lars Eggert wrote: hangs early during the boot, with or without ACPI. It may be related to probing the graphics chip, see the attached snapshot. Seems to have been stripped off, find it here: http://www.isi.edu/larse/misc/5.1-brief.jpg Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Weird behavior with /dev/mem
On Fri, 31 Oct 2003, Daniel C. Sobral wrote: Doug White wrote: On Fri, 31 Oct 2003, Daniel C. Sobral wrote: Weird thing. I updated my system today (October 31), and now I can't list routes from syscons. But I still can list routes from Konsole, on X. Following a suggestion by Genesys, I checked permissions of /dev/mem and netstat and... for some reason, I can't stat /dev/mem under syscons! You didn't mount that filesystem nosuid, did you? No. And, as a matter of fact, the error is user-agnostic. In fact, in the example below the problem happen with the root user, while user dcs is home free. MM... I know what it is. It's something with mac, because X is run with /usr/sbin/setpmac mls/equal. (tests) Yep, that's it. Ok, rwatson, it's all your fault. Sneaky, sneaky. Hey, imagine that, a security check preventing something insecure :-). With MLS enabled, /dev/kmem and /dev/mem are labeled as mls/high since they potentially hold state associated with processes and objects with high labels. As a result, users without the necessary clearance to via mls/high data can't use tools that grub around in kernel memory. Tools that use sysctl, on the other hand, are generally no problem. The usual fixes are: (1) Teach netstat not to use kmem, instead use a more controlled export method. (2) Make netstat exempt from the policy (i.e., run with setpmac mls/equal netstat, or we could introduce a transition mechanism for MLS). (3) Only run netstat from contexts that are either allowed to access kernel memory (generally, mls/high), or are exempt (mls/equal). Are you using kdm/xdm to log in, or using startx? It's fairly likely xdm/kdm aren't setting your label on login, and so you're getting the label from the context they were run from. Whereas when you log in using login(1) login, your label is set properly. getpmac should reveal whether this is the case. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories Here are a couple of typescripts I got: [0] [EMAIL PROTECTED]:/opt/home/dcs$ cat from_konsole Script started on Fri Oct 31 17:25:04 2003 [EMAIL PROTECTED]:/opt/home/dcs$ ls -ld /dev dr-xr-xr-x 4 root wheel 512 Oct 31 13:56 /dev [EMAIL PROTECTED]:/opt/home/dcs$ ls -l /dev/mem crw-r- 1 root kmem2, 0 Oct 31 15:54 /dev/mem [EMAIL PROTECTED]:/opt/home/dcs$ ls -l /usr/bin/netstat -r-xr-sr-x 1 root kmem 108664 Oct 31 13:18 /usr/bin/netstat [EMAIL PROTECTED]:/opt/home/dcs$ netstat -nr Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default10.0.11.1 UGSc00 fxp0 10/16 link#1 UC 00 fxp0 10.0.2.72 00:04:23:2a:13:7b UHLW01 fxp0881 10.0.11.1 00:10:54:cd:58:40 UHLW 280 fxp0 1197 10.0.12.13100:01:30:26:e0:00 UHLW00 fxp0 1186 10.0.14.20 00:02:55:58:22:0a UHLW639928 fxp0975 127.0.0.1 127.0.0.1 UH 06lo0 [EMAIL PROTECTED]:/opt/home/dcs$ exit exit Script done on Fri Oct 31 17:25:20 2003 [0] [EMAIL PROTECTED]:/opt/home/dcs$ cat from_syscons Script started on Fri Oct 31 17:26:01 2003 [EMAIL PROTECTED]:/root$ ls -ld /dev dr-xr-xr-x 4 root wheel 512 Oct 31 13:56 /dev [EMAIL PROTECTED]:/root$ ls -l /dev/mem ls: /dev/mem: Permission denied [EMAIL PROTECTED]:/root$ ls -l /usr/bin/netstat -r-xr-sr-x 1 root kmem 108664 Oct 31 13:18 /usr/bin/netstat [EMAIL PROTECTED]:/root$ netstat -nr netstat: kvm not available Routing tables rt_tables: symbol not in namelist [EMAIL PROTECTED]:/root$ exit exit Script done on Fri Oct 31 17:26:18 2003 [0] [EMAIL PROTECTED]:/opt/home/dcs$ which ls /bin/ls [0] [EMAIL PROTECTED]:/opt/home/dcs$ type ls ls is aliased to `ls -G' [0] [EMAIL PROTECTED]:/opt/home/dcs$ unalias ls [0] [EMAIL PROTECTED]:/opt/home/dcs$ ls -l /dev/mem crw-r- 1 root kmem2, 0 Oct 31 15:54 /dev/mem I'm CCing phk on the grounds of Mr Devfs, and Sam as I blamed the networking code earlier... :-) -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Ten years of rejection slips is nature's way of telling you to stop writing. -- R. Geis ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird behavior with /dev/mem
[trimming CC list and quotes] Robert Watson wrote: Are you using kdm/xdm to log in, or using startx? It's fairly likely xdm/kdm aren't setting your label on login, and so you're getting the label from the context they were run from. Whereas when you log in using login(1) login, your label is set properly. getpmac should reveal whether this is the case. Put this in ttys: ttyvb /usr/sbin/setpmac mls/equal /usr/X11R6/bin/xdm -nodaemon xterm on secure Indeed, my label is mls/equal. As X works, I'm satisfied for now. :-) This machine only run mac so I can test stuff in it anyway. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The means-and-ends moralists, or non-doers, always end up on their ends without any means. -- Saul Alinsky ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: if_xname changes incoming
On Fri, Oct 31, 2003 at 10:27:35AM -0800, Brooks Davis wrote:
I will be commiting the if_xname changes momentairly. If you experience
any problems with this commit, please let me know ASAP. I'll send an
all clear once I've sucessfully built a world/kernel from CVS.
Ok, we're mostly clear. World builds, but I've had to disconnect
ipfstat, ipnat, and ipftest from the build because they need
modifications and are on vendor branch. IP Filter users may wish to
wait to upgrade until this issue is resolve or they may apply the
following patch locally.
The following ports are known to be broken by this commit:
devel/libgtop
devel/libgtop2
net/wmnet
net/wmnet2
Some possiably outdated patches are available at:
http://people.freebsd.org/~brooks/patches/xname-ports/
-- Brooks
Index: contrib/ipfilter/ipt.c
===
RCS file: /home/ncvs/src/contrib/ipfilter/ipt.c,v
retrieving revision 1.1.1.12
diff -u -p -r1.1.1.12 ipt.c
--- contrib/ipfilter/ipt.c 15 Feb 2003 06:27:40 - 1.1.1.12
+++ contrib/ipfilter/ipt.c 31 Oct 2003 20:20:23 -
@@ -443,7 +443,8 @@ char *getifname(ptr)
void *ptr;
{
#if defined(NetBSD) (NetBSD = 199905) (NetBSD 1991011) || \
-defined(__OpenBSD__)
+defined(__OpenBSD__) || \
+defined(__FreeBSD__) (__FreeBSD_version = 501113)
#else
char buf[32], *s;
int len;
@@ -458,7 +459,8 @@ void *ptr;
if (kmemcpy((char *)netif, (u_long)ptr, sizeof(netif)) == -1)
return X;
#if defined(NetBSD) (NetBSD = 199905) (NetBSD 1991011) || \
-defined(__OpenBSD__)
+defined(__OpenBSD__) || \
+defined(__FreeBSD__) (__FreeBSD_version = 501113)
return strdup(netif.if_xname);
#else
if (kmemcpy(buf, (u_long)netif.if_name, sizeof(buf)) == -1)
Index: contrib/ipfilter/kmem.c
===
RCS file: /home/ncvs/src/contrib/ipfilter/kmem.c,v
retrieving revision 1.1.1.10
diff -u -p -r1.1.1.10 kmem.c
--- contrib/ipfilter/kmem.c 15 Feb 2003 06:27:40 - 1.1.1.10
+++ contrib/ipfilter/kmem.c 31 Oct 2003 20:20:23 -
@@ -204,7 +204,8 @@ void *ptr;
return ifname;
#else
# if defined(NetBSD) (NetBSD = 199905) (NetBSD 1991011) || \
-defined(__OpenBSD__)
+defined(__OpenBSD__) || \
+defined(__FreeBSD__) (__FreeBSD_version = 501113)
#else
char buf[32];
int len;
@@ -219,7 +220,8 @@ void *ptr;
if (kmemcpy((char *)netif, (u_long)ptr, sizeof(netif)) == -1)
return X;
# if defined(NetBSD) (NetBSD = 199905) (NetBSD 1991011) || \
-defined(__OpenBSD__)
+defined(__OpenBSD__) || \
+defined(__FreeBSD__) (__FreeBSD_version = 501113)
return strdup(netif.if_xname);
# else
if (kstrncpy(buf, (u_long)netif.if_name, sizeof(buf)) == -1)
Index: sbin/Makefile
===
RCS file: /home/ncvs/src/sbin/Makefile,v
retrieving revision 1.128
diff -u -p -r1.128 Makefile
--- sbin/Makefile 31 Oct 2003 18:54:46 - 1.128
+++ sbin/Makefile 31 Oct 2003 20:20:23 -
@@ -87,7 +87,9 @@ SUBDIR+=devd
.if !defined(NO_IPFILTER)
SUBDIR+=ipf \
ipfs \
- ipmon
+ ipfstat \
+ ipmon \
+ ipnat
.endif
.if !defined(NOINET6)
Index: usr.sbin/Makefile
===
RCS file: /home/ncvs/src/usr.sbin/Makefile,v
retrieving revision 1.277
diff -u -p -r1.277 Makefile
--- usr.sbin/Makefile 31 Oct 2003 18:54:46 - 1.277
+++ usr.sbin/Makefile 31 Oct 2003 20:20:23 -
@@ -142,7 +142,8 @@ SUBDIR+=mld6query \
.endif
.if !defined(NO_IPFILTER)
-SUBDIR+=ipresend \
+SUBDIR+=ipftest \
+ ipresend \
ipsend \
iptest
.endif
Index: rescue/rescue/Makefile
===
RCS file: /home/ncvs/src/rescue/rescue/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- rescue/rescue/Makefile 31 Oct 2003 19:48:40 - 1.20
+++ rescue/rescue/Makefile 31 Oct 2003 20:20:23 -
@@ -128,7 +128,7 @@ CRUNCH_PROGS_sbin+= vinum
.endif
.if !defined(NO_IPFILTER)
-CRUNCH_PROGS_sbin+= ipf ipfs ipmon
+CRUNCH_PROGS_sbin+= ipf ipfs ipfstat ipmon ipnat
.endif
# crunchgen does not like C++ programs; this should be fixed someday
--
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgp0.pgp
Description: PGP signature
weird tr output with czech locale
Hi, strange thing is happening here on two week old -CURRENT world. This simple command: $ echo CATALOG | tr 'a-z' 'A-Z' CATALOG but $ echo CATALOG | LANG=cs_CZ.ISO8859-2 tr 'a-z' 'A-Z' bAAkf Other locales works, except sk_SK fails in same way. It used to work fine a month or two ago, I don't know exactly. It's invoked by xmlcatmgr script. According to CVS last change in tr was 2 months ago by ache, and last change to czech collate 18 months ago. I'm not sure what I should point my finger at. -- Pav Lucistnik [EMAIL PROTECTED] What do we know about love? Love is like a pear. Pear is sweet and have a specific shape. Try to exactly define the shape of a pear. -- Marigold: 50 Years Of Poetry signature.asc Description: Toto je =?iso-8859-2?Q?digit=E1ln=EC?= =?ISO-8859-1?Q?_podepsan=E1?= =?iso-8859-2?Q?_=E8=E1st?= =?ISO-8859-1?Q?_zpr=E1vy?=
Re: weird tr output with czech locale
V p, 31. 10. 2003 v 22:06, Pav Lucistnik pe: $ echo CATALOG | LANG=cs_CZ.ISO8859-2 tr 'a-z' 'A-Z' bAAkf Further playing with CVS revealed that str.c rev 1.17 is ok, str.c rev 1.18 is broken. Commit log reads: POSIX requires 'c-c' must conform collate and be in collation order and the change looks non-trivial to my unskilled eye. Andrey? -- Pav Lucistnik [EMAIL PROTECTED] What do we know about love? Love is like a pear. Pear is sweet and have a specific shape. Try to exactly define the shape of a pear. -- Marigold: 50 Years Of Poetry signature.asc Description: Toto je =?iso-8859-2?Q?digit=E1ln=EC?= =?ISO-8859-1?Q?_podepsan=E1?= =?iso-8859-2?Q?_=E8=E1st?= =?ISO-8859-1?Q?_zpr=E1vy?=
Re: wi problem with message 7400 bytes
On Thu, 30 Oct 2003, Lars Eggert wrote: Daniel Eischen wrote: Could you post a tcpdump for each case? I wonder if this is related to a fragmentation issue I've seen in the past. 22:46:43.513038 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52198:[EMAIL PROTECTED]) 22:46:48.522475 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52199:[EMAIL PROTECTED]) 22:46:53.532018 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52200:[EMAIL PROTECTED]) 22:46:58.541178 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52201:[EMAIL PROTECTED]) 22:47:03.553048 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52202:[EMAIL PROTECTED]) 22:47:08.568862 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52203:[EMAIL PROTECTED]) 22:47:13.583328 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52204:[EMAIL PROTECTED]) 22:47:18.578512 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52205:[EMAIL PROTECTED]) 22:47:23.609098 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52206:[EMAIL PROTECTED]) 22:47:28.597680 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52207:[EMAIL PROTECTED]) 22:47:33.607059 gpz.foo.bar.com.38340 vespa.12345: udp 7393 (frag 52208:[EMAIL PROTECTED]) It's not what I've seen in the past - but also pretty strange! Only the first fragment seems to be received. Wonder what happened to the other fragments... I guess the problem was with the access point. Once I swapped it with a Linksys WAP-11, it worked. For future reference, the bad access point was a Dell TrueMobile-branded Intel 1170 Wireless Base Station (Model WLGW2011). -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: weird tr output with czech locale
On Fri, Oct 31, 2003 at 10:06:50PM +0100, Pav Lucistnik wrote: Hi, strange thing is happening here on two week old -CURRENT world. This simple command: $ echo CATALOG | tr 'a-z' 'A-Z' CATALOG but $ echo CATALOG | LANG=cs_CZ.ISO8859-2 tr 'a-z' 'A-Z' bA?Ak?f It is incorrect tr usage (a-z range length and letters sequence is not equal to A-Z range length and letters sequence for cs_CZ locale, see cs_CZ locale data definition). Correct usage will be LANG=cs_CZ.ISO8859-2 tr '[:lower:]' '[:upper:]' or LANG=C tr 'a-z' 'A-Z' -- Andrey Chernov | http://ache.pp.ru/ pgp0.pgp Description: PGP signature
[current tinderbox] failure on i386/pc98
TB --- 2003-10-31 21:13:21 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-31 21:13:21 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-10-31 21:13:21 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-10-31 21:16:08 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. [...] cc -O -pipe -mcpu=pentiumpro -DUSE_INET6 -DIPL_NAME=\/dev/ipl\ -DSTATETOP -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/ipfstat/../../sys/contrib/ipfilter/netinet -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/ipfstat/../../sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/ipfstat/../../contrib/ipfilter -DRESCUE -c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/ipfilter/opt.c cc -O -pipe -mcpu=pentiumpro -DUSE_INET6 -DIPL_NAME=\/dev/ipl\ -DSTATETOP -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/ipfstat/../../sys/contrib/ipfilter/netinet -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/ipfstat/../../sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/ipfstat/../../contrib/ipfilter -DRESCUE -c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/ipfilter/kmem.c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/ipfilter/kmem.c: In function `getifname': /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/ipfilter/kmem.c:225: error: structure has no member named `if_name' /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/ipfilter/kmem.c:227: error: structure has no member named `if_unit' /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/ipfilter/kmem.c:229: error: structure has no member named `if_unit' /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/ipfilter/kmem.c:231: error: structure has no member named `if_unit' /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/ipfilter/kmem.c:236: error: structure has no member named `if_unit' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/ipfstat. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/rescue/rescue. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/rescue/rescue. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/rescue. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-10-31 22:03:28 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-10-31 22:03:28 - TB --- ERROR: failed to build world TB --- 2003-10-31 22:03:28 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NULL td passed to propagate_priority() when using xmms...
Howdy. I'm not sure if this is a ULE bug or a KSE bug, or both, but,
for those interested (this is using ule 1.67, rebuilding world now),
here's my stack. I couldn't figure out where td was being set to
NULL. :( Oh! Where is TD_SET_LOCK defined? egrep -r didn't turn up
anything. -sc
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc0530569 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc0530948 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc06e6bc6 in trap_fatal (frame=0xd675dc2c, eva=0)
at /usr/src/sys/i386/i386/trap.c:820
#4 0xc06e6203 in trap (frame=
{tf_fs = -881065960, tf_es = 16, tf_ds = -881065968, tf_edi = 0, tf_esi =
-871763664, tf_ebp = -696918912, tf_isp = -696918952, tf_ebx = 24, tf_edx = 24, tf_ecx
= -871763664, tf_eax = -879614080, tf_trapno = 12, tf_err = 0, tf_eip = -1068208110,
tf_cs = 8, tf_eflags = 66051, tf_esp = -874093984, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:252
#5 0xc06d6a68 in calltrap () at {standard input}:102
#6 0xc05257ac in propagate_priority (td=0x0)
at /usr/src/sys/kern/kern_mutex.c:152
#7 0xc0525bf9 in _mtx_lock_sleep (m=0xc0796b40, opts=0, file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:635
#8 0xc051a2c4 in ithread_loop (arg=0xcb7a6b00)
at /usr/src/sys/kern/kern_intr.c:539
#9 0xc0518f51 in fork_exit (callout=0xc051a100 ithread_loop, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:796
(kgdb) frame 9
#9 0xc0518f51 in fork_exit (callout=0xc051a100 ithread_loop, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:796
796 callout(arg, frame);
(kgdb) list
791 * cpu_set_fork_handler intercepts this function call to
792 * have this call a non-return function to stay in kernel mode.
793 * initproc has its own fork handler, but it does return.
794 */
795 KASSERT(callout != NULL, (NULL callout in fork_exit));
796 callout(arg, frame);
797
798 /*
799 * Check if a kernel thread misbehaved and returned from its main
800 * function.
(kgdb) frame 8
#8 0xc051a2c4 in ithread_loop (arg=0xcb7a6b00)
at /usr/src/sys/kern/kern_intr.c:539
539 mtx_lock(Giant);
(kgdb) list
534 wakeup(ih);
535 mtx_unlock(ithd-it_lock);
536 goto restart;
537 }
538 if ((ih-ih_flags IH_MPSAFE) == 0)
539 mtx_lock(Giant);
540 ih-ih_handler(ih-ih_argument);
541 if ((ih-ih_flags IH_MPSAFE) == 0)
542 mtx_unlock(Giant);
543 }
(kgdb) frame 7
#7 0xc0525bf9 in _mtx_lock_sleep (m=0xc0796b40, opts=0, file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:635
635 propagate_priority(td);
(kgdb) list
630 * Save who we're blocked on.
631 */
632 td-td_blocked = m;
633 td-td_lockname = m-mtx_object.lo_name;
634 TD_SET_LOCK(td);
635 propagate_priority(td);
636
637 if (LOCK_LOG_TEST(m-mtx_object, opts))
638 CTR3(KTR_LOCK,
639 _mtx_lock_sleep: p %p blocked on [%p] %s, td, m,
(kgdb) frame 6
#6 0xc05257ac in propagate_priority (td=0x0)
at /usr/src/sys/kern/kern_mutex.c:152
152 sched_prio(td, pri);
(kgdb) list
147 * XXXKSE this gets a lot more complicated under threads
148 * but try anyhow.
149 */
150 if (TD_ON_RUNQ(td)) {
151 MPASS(td-td_blocked == NULL);
152 sched_prio(td, pri);
153 return;
154 }
155 /*
156 * Adjust for any other cases.
---
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x38
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0547012
stack pointer = 0x10:0xd6763c6c
frame pointer = 0x10:0xd6763c80
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 33 (irq12: psm0)
trap number = 12
panic: page fault
syncing disks, buffers remaining...
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x38
fault code = supervisor read, page not present
instruction
Re: Toshiba Portege R100: 5.1-JPSNAP install CD hangs
Hi, Hi, booting a Toshiba Portege R100 off Wednesday's 5.1-JPSNAP install CD hangs early during the boot, with or without ACPI. It may be related to probing the graphics chip, see the attached snapshot. I've also attached the 4.9 dmesg - 4.9 boots fine off its install CD - in case that helps. Any ideas? R100 has problem with PnP for FreeBSD. My Toshiba Portege R100 on FreeBSD 5.1-RELEASE can boot by below process. 1) enter BIOS setup (booting with press ESC) 2) [Device Config] change to All Devices from Setup by OS -- Takayama Fumihiko [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on ia64/ia64
TB --- 2003-10-31 22:03:29 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-31 22:03:29 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-10-31 22:03:29 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-10-31 22:05:36 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. [...] cc -O -pipe -DUSE_INET6 -DIPL_NAME=\/dev/ipl\ -DSTATETOP -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/ipfstat/../../sys/contrib/ipfilter/netinet -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/ipfstat/../../sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/ipfstat/../../contrib/ipfilter -DRESCUE -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/ipfilter/opt.c cc -O -pipe -DUSE_INET6 -DIPL_NAME=\/dev/ipl\ -DSTATETOP -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/ipfstat/../../sys/contrib/ipfilter/netinet -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/ipfstat/../../sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/ipfstat/../../contrib/ipfilter -DRESCUE -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/ipfilter/kmem.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/ipfilter/kmem.c: In function `getifname': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/ipfilter/kmem.c:225: error: structure has no member named `if_name' /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/ipfilter/kmem.c:227: error: structure has no member named `if_unit' /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/ipfilter/kmem.c:229: error: structure has no member named `if_unit' /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/ipfilter/kmem.c:231: error: structure has no member named `if_unit' /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/ipfilter/kmem.c:236: error: structure has no member named `if_unit' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/ipfstat. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/rescue/rescue. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/rescue/rescue. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/rescue. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-10-31 22:57:24 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-10-31 22:57:24 - TB --- ERROR: failed to build world TB --- 2003-10-31 22:57:24 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: exclusive sleep mutex mntvnode r = 0 (0xffffffff80758220) locked @ /a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172
On Thu, Oct 30, 2003 at 10:18:43AM -0800, Kris Kennaway wrote: One of the amd64 machines died with the following. The kernel is a few weeks old, so this might already be fixed. Kris malloc() of 64 with the following non-sleepable locks held: exclusive sleep mutex mntvnode r = 0 (0x80758220) locked @ /a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172 recursed on non-recursive lock (sleep mutex) mntvnode @ /a/asami/portbuild/amd64/src-client/sys/kern/vfs_subr.c:1054 first acquired @ /a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172 panic: recurse Debugger(panic) Stopped at Debugger+0x4b: xchgl %ebx,0x31599f db where Debugger() at Debugger+0x4b panic() at panic+0x169 witness_lock() at witness_lock+0x383 _mtx_lock_flags() at _mtx_lock_flags+0x9c insmntque() at insmntque+0x2a vclean() at vclean+0x35b vgonel() at vgonel+0x51 vrecycle() at vrecycle+0x5b ufs_inactive() at ufs_inactive+0x22c ufs_vnoperate() at ufs_vnoperate+0x14 vrele() at vrele+0x11a ffs_sync() at ffs_sync+0x24f sync() at sync+0xdb syscall() at syscall+0x320 Xfast_syscall() at Xfast_syscall+0xa7 --- syscall (36, FreeBSD ELF64, sync), rip = 0x402084, rsp = 0x7648, rbp = 0x3 --- db Another one: malloc() of 256 with the following non-sleepable locks held: exclusive sleep mutex mntvnode r = 0 (0x80758220) locked @ /a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172 Sleeping on drainvp with the following non-sleepable locks held: exclusive sleep mutex mntvnode r = 0 (0x80758220) locked @ /a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172 panic: sleeping thread (pid 12604) owns a mutex Debugger(panic) Stopped at Debugger+0x4b: xchgl %ebx,0x31599f db where Debugger() at Debugger+0x4b panic() at panic+0x169 propagate_priority() at propagate_priority+0xdd _mtx_lock_sleep() at _mtx_lock_sleep+0x273 _mtx_lock_flags() at _mtx_lock_flags+0x86 insmntque() at insmntque+0x2a vclean() at vclean+0x35b vgonel() at vgonel+0x51 vrecycle() at vrecycle+0x5b ufs_inactive() at ufs_inactive+0x22c ufs_vnoperate() at ufs_vnoperate+0x14 vput() at vput+0x131 handle_workitem_remove() at handle_workitem_remove+0x1c9 process_worklist_item() at process_worklist_item+0x183 softdep_process_worklist() at softdep_process_worklist+0xc9 sched_sync() at sched_sync+0x35b fork_exit() at fork_exit+0xd9 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0x98721d30, rbp = 0 --- db pgp0.pgp Description: PGP signature
Digital Camera not working after 10-30-03
FreeBSD 5.1-CURRENT #0: Thu Oct 30 17:49:13 EST 2003 Digital camera (Canon PowerShot S50) is not accessible after latest buildworld. I use gtkam to connect to the camera. /dev shows ugen devices as before. No error at CLI. Errors from gtkam: An error uccured in tje io-library )could not find the requested device on the USB port'): Could not find USB device (class 0x28a09032, subclass 0x80dfc00, protocol 0x28a14b60). Make sure that this device is connected to the computer. Previous build (10-14-03) worked well. I was able to access camera as user and as a root. Neither is working now. Michal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Sticky mouse with SCHED_ULE 10-30-03
FreeBSD 5.1-CURRENT #0: Thu Oct 30 17:49:13 EST 2003 When kernel compiled with SCHED_ULE, USB mouse (MS USB Intellimouse) is almost unusable. Even if CPU is idle, mouse feels sticky. When loading mozilla or compiling comething mouse freezes for several seconds and is nonresponsive in general. Switched back to SCHED_4BSD and mouse is better than ever. No problems at all when loading programs or compiling. To me subjective feeling mouse respomds worse than month ago with SCHED_ULE and much better with SCHED_4BSD than before. Michal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
On Fri, 31 Oct 2003, Bruno Van Den Bossche wrote: Jeff Roberson [EMAIL PROTECTED] wrote: On Wed, 29 Oct 2003, Jeff Roberson wrote: On Thu, 30 Oct 2003, Bruce Evans wrote: Test for scheduling buildworlds: cd /usr/src/usr.bin for i in obj depend all do MAKEOBJDIRPREFIX=/somewhere/obj time make -s -j16 $i done /tmp/zqz 21 (Run this with an empty /somewhere/obj. The all stage doesn't quite finish.) On an ABIT BP6 system with a 400MHz and a 366MHz CPU, with/usr (including /usr/src) nfs-mounted (with 100 Mbps ethernet and a reasonably fast server) and /somewhere/obj ufs1-mounted (on a fairly slow disk; no soft-updates), this gives the following times: SCHED_ULE-yesterday, with not so careful setup: 40.37 real 8.26 user 6.26 sys 278.90 real59.35 user41.32 sys 341.82 real 307.38 user69.01 sys SCHED_ULE-today, run immediately after booting: 41.51 real 7.97 user 6.42 sys 306.64 real59.66 user40.68 sys 346.48 real 305.54 user69.97 sys SCHED_4BSD-yesterday, with not so careful setup: [same as today except the depend step was 10 seconds slower (real)] SCHED_4BSD-today, run immediately after booting: 18.89 real 8.01 user 6.66 sys 128.17 real58.33 user43.61 sys 291.59 real 308.48 user72.33 sys SCHED_4BSD-yesterday, with a UP kernel (running on the 366 MHz CPU) with many local changes and not so careful setup: 17.39 real 8.28 user 5.49 sys 130.51 real60.97 user34.63 sys 390.68 real 310.78 user60.55 sys Summary: SCHED_ULE was more than twice as slow as SCHED_4BSD for the obj and depend stages. These stages have little parallelism. SCHED_ULE was only 19% slower for the all stage. ... I reran this with -current (sched_ule.c 1.68, etc.). Result: no significant change. However, with a UP kernel there was no significant difference between the times for SCHED_ULE and SCHED_4BSD. There was a significant difference on UP until last week. I'm working on SMP now. I have some patches but they aren't quite ready yet. I have commited my SMP fixes. I would appreciate it if you could post update results. ULE now outperforms 4BSD in a single threaded kernel compile and performs almost identically in a 16 way make. I still have a few more things that I can do to improve the situation. I would expect ULE to pull further ahead in the months to come. I recently had to complete a little piece of software in a course on parallel computing. I've put it online[1] (we only had to write the pract2.cpp file). It calculates the inverse of a Vandermonde matrix and allows you to spawn multiple slave-processes who each perform a part of the work. Everything happens in memory so I've used it lately to test the different changes you made to sched_ule.c and these last fixes do improve the performance on my dual p3 machine a lot. Here are the results of my (very limited tests) : sched4bsd --- dimension slaves time 10001 90.925408 10002 58.897038 200 1 0.735962 200 2 0.676660 sched_ule 1.68 --- dimension slaves time 10001 90.951015 10002 70.402845 200 1 0.743551 200 2 1.900455 sched_ule 1.70 --- dimension slaves time 10001 90.782309 10002 57.207351 200 1 0.739998 200 2 0.383545 I'm not really sure if this is very relevant to you, but from the end-user point of view (me :-)) this does means something. Thanks! I welcome the feedback, positive or negative, as it helps me improve things. Thanks for the report! Could you run this again under 4bsd and ULE with the following in your .cshrc: set time= ( 5 %Uu %Ss %E %P %X+%Dk %I+%Oio %Fpf+%Ww %cc/%ww ) And then time ./testpract 200 2, etc. This will give me a few hints about what's impacting your performance. Thanks! Jeff [1] http://users.pandora.be/bomberboy/mptest/final.tar.bz2 It can be used by running testpract2 with two arguments, the dimension of the matrix and the number of slaves. example './testpract2 200 2' will create a matrix with dimension 200 and 2 slaves. -- Bruno ... And then there's the guy who bought 20,000 bras, cut them in half, and sold 40,000 yamalchas with chin straps
Re: Sticky mouse with SCHED_ULE 10-30-03
On Fri, 31 Oct 2003, Michal wrote: FreeBSD 5.1-CURRENT #0: Thu Oct 30 17:49:13 EST 2003 When kernel compiled with SCHED_ULE, USB mouse (MS USB Intellimouse) is almost unusable. Even if CPU is idle, mouse feels sticky. When loading mozilla or compiling comething mouse freezes for several seconds and is nonresponsive in general. Switched back to SCHED_4BSD and mouse is better than ever. No problems at all when loading programs or compiling. To me subjective feeling mouse respomds worse than month ago with SCHED_ULE and much better with SCHED_4BSD than before. Are you using moused? Is this SMP or UP? What CPUs are you using? Thanks, Jeff Michal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic with locks and networking as of a day ago
I'm getting this panic a fair amount when dhclient is running on with the an(4) driver. My Atheros based card appears to have broke so I can't use that now (it doesn't work in Windows either). Here is the dmesg: lock order reversal 1st 0xc2ebaf08 vm object (vm object) @ vm/swap_pager.c:1319 2nd 0xc0735600 swap_pager swhash (swap_pager swhash) @ vm/swap_pager.c:1835 3rd 0xc103565c vm object (vm object) @ vm/uma_core.c:876 Stack backtrace: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0595952 stack pointer = 0x10:0xd0135a40 frame pointer = 0x10:0xd0135afc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 854 (ssh) trap number = 12 panic: page fault syncing disks, buffers remaining... panic: sleeping thread (pid 854) owns a mute x Uptime: 10m22s Dumping 255 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 and the trace is: kgdb) where #0 doadump () at ../../../kern/kern_shutdown.c:240 #1 0xc050f61c in boot (howto=260) at ../../../kern/kern_shutdown.c:372 #2 0xc050f9a7 in panic () at ../../../kern/kern_shutdown.c:550 #3 0xc05057db in propagate_priority (td=0x0) at ../../../kern/kern_mutex.c:124 #4 0xc0505fe9 in _mtx_lock_sleep (m=0xc072a76c, opts=0, file=0xc06aa995 ../../../netinet/tcp_timer.c, line=489) at ../../../kern/kern_mutex.c:635 #5 0xc0505a37 in _mtx_lock_flags (m=0xc072a76c, opts=0, file=0xc06aa995 ../../../netinet/tcp_timer.c, line=489) at ../../../kern/kern_mutex.c:333 #6 0xc05a1f10 in tcp_timer_rexmt (xtp=0xc3116164) at ../../../netinet/tcp_timer.c:489 #7 0xc051fea8 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:225 #8 0xc04fb802 in ithread_loop (arg=0xc16c1c80) at ../../../kern/kern_intr.c:540 #9 0xc04fa804 in fork_exit (callout=0xc04fb670 ithread_loop, arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:793 (kgdb) I have the core so I can run other commands if needed. BTW before that update to -current I was getting panics when I would insert or remove a card. Dhclient would end up being the process running and the kernel would crash in in_pcbconnect_setup when it did this check: if (ro-ro_rt !(ro-ro_rt-rt_ifp-if_flags IFF_LOOPBACK)) The ro-ro_rt-rt_ifp would be pointing the the ifp that was gone and panic. This one wasn't to bad except for crashing during a suspend/ resume sequence the other panic is happening randomly through the day. Hopefully someone can shed some light on this. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Flash card reader error
FreeBSD 5.1-CURRENT #0: Thu Oct 30 17:49:13 EST 2003 This problem persists since I tried to use flash reader (~1.5 month) I have SimpleTech flash card reader (FlashLink). Connecting to USB ports causes the following errors: umass0: USB Mass Storage, rev 1.10/1.13 addr3 umass0: Max Lun not supported (STALLED) umass0: BBBreset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOEROR umass0: BBB bulk-out clear stall failed, IOERROR . . . . . GEOM: create disk da2 dp = 0xc7241850 da2: (umass-sim0:0:0:0) got CAM status 0x4 da2: (umass-sim0:0:0:0) fatal error, failed to attach to device da2: (umass-sim0:0:0:0) lost device GEOM: destroy disk da2 dp = 0x7241850 GEOM: removing device entry Michal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NULL td passed to propagate_priority() when using xmms...
Howdy. I'm not sure if this is a ULE bug or a KSE bug, or both, but, for those interested (this is using ule 1.67, rebuilding world now), here's my stack. I couldn't figure out where td was being set to NULL. :( Oh! Where is TD_SET_LOCK defined? egrep -r didn't turn up anything. -sc sched_ule.c v1.70 fixes this. -sc -- Sean Chittenden ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic with locks and networking as of a day ago
On Friday 31 October 2003 07:49 pm, Doug Ambrisko wrote: I'm getting this panic a fair amount when dhclient is running on with the an(4) driver. My Atheros based card appears to have broke so I can't use that now (it doesn't work in Windows either). Here is the dmesg: lock order reversal 1st 0xc2ebaf08 vm object (vm object) @ vm/swap_pager.c:1319 2nd 0xc0735600 swap_pager swhash (swap_pager swhash) @ vm/swap_pager.c:1835 3rd 0xc103565c vm object (vm object) @ vm/uma_core.c:876 Stack backtrace: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0595952 stack pointer = 0x10:0xd0135a40 frame pointer = 0x10:0xd0135afc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 854 (ssh) trap number = 12 panic: page fault syncing disks, buffers remaining... panic: sleeping thread (pid 854) owns a mute x Uptime: 10m22s Dumping 255 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 and the trace is: kgdb) where #0 doadump () at ../../../kern/kern_shutdown.c:240 #1 0xc050f61c in boot (howto=260) at ../../../kern/kern_shutdown.c:372 #2 0xc050f9a7 in panic () at ../../../kern/kern_shutdown.c:550 #3 0xc05057db in propagate_priority (td=0x0) at ../../../kern/kern_mutex.c:124 #4 0xc0505fe9 in _mtx_lock_sleep (m=0xc072a76c, opts=0, file=0xc06aa995 ../../../netinet/tcp_timer.c, line=489) at ../../../kern/kern_mutex.c:635 #5 0xc0505a37 in _mtx_lock_flags (m=0xc072a76c, opts=0, file=0xc06aa995 ../../../netinet/tcp_timer.c, line=489) at ../../../kern/kern_mutex.c:333 #6 0xc05a1f10 in tcp_timer_rexmt (xtp=0xc3116164) at ../../../netinet/tcp_timer.c:489 #7 0xc051fea8 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:225 #8 0xc04fb802 in ithread_loop (arg=0xc16c1c80) at ../../../kern/kern_intr.c:540 #9 0xc04fa804 in fork_exit (callout=0xc04fb670 ithread_loop, arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:793 (kgdb) I have the core so I can run other commands if needed. This is new. Please contact me offline with a way to collect the kernel+core. BTW before that update to -current I was getting panics when I would insert or remove a card. Dhclient would end up being the process running and the kernel would crash in in_pcbconnect_setup when it did this check: if (ro-ro_rt !(ro-ro_rt-rt_ifp-if_flags IFF_LOOPBACK)) The ro-ro_rt-rt_ifp would be pointing the the ifp that was gone and panic. This one wasn't to bad except for crashing during a suspend/ resume sequence the other panic is happening randomly through the day. I have a line on this one and should have a fix soon. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-R and 5.1-C floppies will not boot on SuperMicro 6023P-8R
At Fri, 31 Oct 2003 16:56:43 + (UTC), Stephane Raimbault wrote: Does anyone have any thoughts regarding this? I would like to get 5.1 on this server. How about trying with -v at boot? -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
