Re: Random signals in {build,install}world recently?
On Mon, Oct 27, 2003 at 02:46:03PM -0500, Andre Guibert de Bruet [EMAIL PROTECTED] wrote: On Tue, 21 Oct 2003, Vallo Kallaste wrote: I went back to last known good kernel/world combination, which is from September 16. The next and problematic kernel/world pair is from September 30. So the problem was introduced between these dates. Well, I have a system from the 25th that works just fine, we're looking between the dates of 9/25 - 9/30. It is fixed, grab newer sources. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1 - stl Kernel compile fails
i added a stallion easy i/o to a 5.1 box. compiling the kernel fails with a lot of errors in stallion.c. any chance that this gets corrected soon? -- Best regards / Mit freundlichen Gruessen, Karl M. Joch http://www.freebsd.at - Das Power Betriebssystem ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1 - stl Kernel compile fails
On Tue, Oct 28, 2003 at 08:11:33AM +0100, Karl M. Joch wrote: i added a stallion easy i/o to a 5.1 box. compiling the kernel fails with a lot of errors in stallion.c. any chance that this gets corrected soon? Post the errors you're seeing so we don't have to guess. Kris pgp0.pgp Description: PGP signature
5.1-p10 lockups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Last days i'm having big troubles with my 5.1-p10 box. It's dual p3 1.2MHz, 1G of ecc ram with 900G on pst0 raid5 disk array. Kernel configuration is attached. My problems are lockups when i test apache (2.0.47, php 4.3.3 + turck mmcache and horde imp webmail) this machine with JMeter. Machine locks up after approx. 5-10 seconds of jmeter test. That weird, becouse if i stress test mail server on this machine, it passes 24 test without problem. When lockup accours, there are no kernel messages on console, machine stop responding to echo requests (ping). There is nothing in syslog logs... Bad hardware is not an option. Should i rebuild kernel with debugging options? But as far i see, kernel does not crash, it just locks up. Regards, Brane -BEGIN PGP SIGNATURE- iD8DBQE/nhyQfiC/E+t8hPcRAoApAJ9gYXlon+QvSFJvwMclpsYZCz1dfQCfUmc8 OtpIIZrW4Tand1kwR9G/oe8= =1cOM -END PGP SIGNATURE- # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.384.2.2 2003/05/31 15:18:41 scottl Exp $ machine i386 cpu I686_CPU ident MYNAME options SCHED_4BSD #4BSD scheduler options INET#InterNETworking options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options CD9660 #ISO 9660 Filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O device isa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering # RAID controllers device pst # Promise Supertrak SX6000 # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver # devicesplash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. #device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device fxp # Intel EtherExpress PRO/100B (82557, 82558) # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device loop# Network loopback device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory disks # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # device
Re: ULE page fault with sched_ule.c 1.67
Hi, Jeff Roberson wrote: On Mon, 27 Oct 2003, Jonathan Fosburgh wrote: On Monday 27 October 2003 12:06 pm, Arjan van Leeuwen wrote: Hi, I just cvsupped and built a new kernel that includes sched_ule.c 1.67. I'm getting a page fault when working in Mozilla Firebird. It happens pretty soon, after opening one or two pages. The trace shows that it panics at sched_prio(). I should have said, I am getting the same panic, same trace, but not using Mozilla. I get it shortly after launching my KDE session, though I'm not sure where in my session the problem is being hit. It's KSE. You can disable it to work around temporarily. I will fix it tonight. I tried KSE with sched_ule.c 1.65 this weekend, and my computer would freeze hard very soon after starting X. I assumed it to be a problem with ULE+KSE, so I disabled KSE again. Would this problem be related to or the same as the one described here? Thanks, /Eirik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
GL slowdown with latest kernel
I see a ~3x reduced GL performance as measured by glxgears. This is on a dual Athlon sysmem with Radeon 9000 Pro. Old kernel: [EMAIL PROTECTED] uname -a FreeBSD ice.irfu.se 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Wed Oct 22 10:15:08 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ICE i386 [EMAIL PROTECTED] glxgears 7128 frames in 5.0 seconds = 1425.600 FPS 8738 frames in 5.0 seconds = 1747.600 FPS 8689 frames in 5.0 seconds = 1737.800 FPS 8725 frames in 5.0 seconds = 1745.000 FPS 8727 frames in 5.0 seconds = 1745.400 FPS 8717 frames in 5.0 seconds = 1743.400 FPS 8717 frames in 5.0 seconds = 1743.400 FPS 8720 frames in 5.0 seconds = 1744.000 FPS 8711 frames in 5.0 seconds = 1742.200 FPS New kernel: [EMAIL PROTECTED] uname -a FreeBSD ice.irfu.se 5.1-CURRENT FreeBSD 5.1-CURRENT #6: Tue Oct 28 09:06:24 CET 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ICE i386 [EMAIL PROTECTED] glxgears 2851 frames in 5.0 seconds = 570.200 FPS 2961 frames in 5.0 seconds = 592.200 FPS 2873 frames in 5.0 seconds = 574.600 FPS 2866 frames in 5.0 seconds = 573.200 FPS 2877 frames in 5.0 seconds = 575.400 FPS 2863 frames in 5.0 seconds = 572.600 FPS 2884 frames in 5.0 seconds = 576.800 FPS 3436 frames in 5.0 seconds = 687.200 FPS X connection to :0.0 broken (explicit kill or server shutdown). [EMAIL PROTECTED] glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_make_current_read client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_SGI_video_sync OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 20030328 AGP 1x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.3 Mesa 5.0.2 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2a 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2b 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2d 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16
Re: Anyone object to the following change in libc?
(Cc set to current).
On Tue, 28 Oct 2003, Jordan K Hubbard wrote:
JKHBack in the pre-panther timeframe, we received the following bug report:
JKH
JKHEarlier versions of Mac OS X (e.g., 10.2.6) return a value of -1 with
JKHthe following program:
JKH
JKH#include stdlib.h
JKH
JKHmain()
JKH{ int ret, x;
JKH ret = sscanf (123, %*d%d, x);
JKH printf(ret is %d\n, ret);
JKH}
JKH
JKHOn Panther, the return value is zero. It affects packages like GMP,
JKHwhose automated test sequence assumes that -1 is the proper return
JKHvalue.
JKH
JKHA little investigation revealed that FreeBSD had changed vfscanf()
JKHabout 6 years ago, but it was the only Unix to do so and everyone
JKHelse has stuck with the more traditional behavior of returning an error
JKHin this case. We've done some investigation and consulted SUSv3, but
JKHit's unfortunately vague on what the proper behavior should be so it
JKHseems that it's been left to the various implementations to decide for
JKHthemselves what constitutes correct behavior. Given the fact that
JKHFreeBSD appears to be the odd-man out, we plan to revert back to the
JKH10.2.6 behavior for vfscanf() in 10.4, but it seems a pity to have
JKHFreeBSD diverge here (not just from Mac OS X past and future but from
JKHLinux and Solaris) in ways that break known 3rd-party software and for
JKHreasons which remain obscure.
JKH
JKHSo, two questions:
JKH
JKH1. Are the reasons not as obscure as I think? I'd welcome an
JKHexplanation as to why this was done.
I think ISO-C is pretty clear here. Basically three things happen when
the scanf() finds a format specifier: it matches the input string
according to the format specifier, if that match is not empty it converts
the value to the corresponding type and, if assignment suppression was
not specified it assigns the value.
When applying %*d%d to the string 123 the first 'd' format matches
the string 123 and the conversion yields the number 123. This is then
thrown away because assignment is suppressed. The next format specified
finds an EOF condition on the stream so this counts as an input error
according to paragraph 9, last sentence of 7.19.6.2.
According to to paragraph 18 (The fscanf function returns the value of
the macro EOF if an input failure occurs before any conversion. Otherwise,
the function returns the number of input items assigned, which can be
fewer than provided for, or even zero, in the event of an early matching
failure.) the function returns 0, because there was a succesful
conversion but no assignment.
I just had a look at the v7 implementation. In this implementation a
suppressed assignment is not counted as a match even if the
match was successful. This explains the return of -1 if the first
not-suppressed conversion failes.
I think changing current behaviour would be a regression with regard to
ISO-C (and Posix).
harti
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Still gettnig NFS client locking up
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: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1296172+0+archive/2003/freebsd-current/20031026.freebsd-current http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1333116+0+archive/2003/freebsd-current/20031026.freebsd-current http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1477462+0+archive/2003/freebsd-current/20031026.freebsd-current http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1469939+0+archive/2003/freebsd-current/20031026.freebsd-current http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1467159+0+archive/2003/freebsd-current/20031026.freebsd-current http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1314547+0+archive/2003/freebsd-current/20031026.freebsd-current I just tried port upgrading bind9 and it got 10% through downloading and locked up. I tried an ls /usr/ports and there was no response. I had to umount -f /usr/ports to get the processes to exit. Poul-Henning's patch did not have any effect because it appears to be the client at fault not the server as Marc Olzheim mentioned that he has the same issue with a 4.x NFS server machine using a 5.1-current client. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still gettnig NFS client locking up
It seems Matt 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: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1296172+0+archive/2003/freebsd-current/20031026.freebsd-current http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1333116+0+archive/2003/freebsd-current/20031026.freebsd-current http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1477462+0+archive/2003/freebsd-current/20031026.freebsd-current http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1469939+0+archive/2003/freebsd-current/20031026.freebsd-current http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1467159+0+archive/2003/freebsd-current/20031026.freebsd-current http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1314547+0+archive/2003/freebsd-current/20031026.freebsd-current I just tried port upgrading bind9 and it got 10% through downloading and locked up. I tried an ls /usr/ports and there was no response. I had to umount -f /usr/ports to get the processes to exit. Poul-Henning's patch did not have any effect because it appears to be the client at fault not the server as Marc Olzheim mentioned that he has the same issue with a 4.x NFS server machine using a 5.1-current client. Me too!! -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Radeon 7500 w/ DRI locking on restart of X
On Fri, 2003-10-24 at 11:06, Sean Welch wrote: Eric, I updated my 5.1-RELEASE system to CURRENT dated today at approx. 9:10 CDT to give your changes a try. I had a bit of a fright at first with kernel panics right at the end of the boot sequence but it turned out I had forgotten to disable the ltmdm code -- the kernel module compiled under -RELEASE wasn't friendly to -CURRENT. I've got just a basic install with my custom kernel. I'm using the packages for X from the 5.1-RELEASE cd running twm. Hangs on restart are gone! I restarted about 10 times in a row and ran glxinfo and glxgears each time to verify DRI was still activated and working -- no issues. VT switches are fine (even while running glxgears). The one thing that does not work is resume from acpiconf -s 4 (disk) -- there is a failure to refresh in X and no ability *apparently* to switch to a VT; the keystrokes just generate beeps. Interestingly, the cursor still changed between the different modes when mousing over the xterm and onto the background. Also, Alt-Cntl-Del did work just fine. Suspend/resume is doesn't work well. You might get lucky with the -current DRM with XFree86-4-Server-snap. The only other thing I noticed is that there seems to be a syslog entry for every instance of running glxgears that reads: [MP SAFE] drm0 Is this expected behavior? I noticed that same message (in brackets) in front of each of my disks as they were probed during boot. That printout happens whenever an mpsafe interrupt handler is installed. It gets installed upon initializing the DRI in the server. I don't think any drivers do it more often. It may happen frequently if glxgears is your only app running, in which case you'll get a server regenerate on exit of glxgears. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1 - stl Kernel compile fails
Kris Kennaway wrote: On Tue, Oct 28, 2003 at 08:11:33AM +0100, Karl M. Joch wrote: i added a stallion easy i/o to a 5.1 box. compiling the kernel fails with a lot of errors in stallion.c. any chance that this gets corrected soon? Post the errors you're seeing so we don't have to guess. Kris there is a remark that it is broken. this is why i havnt attached the output. -- Best regards / Mit freundlichen Gruessen, Karl M. Joch /usr/src/sys/i386/isa/stallion.c /usr/src/sys/i386/isa/stallion.c:59:2: warning: #warning The stallion pci attachment is broken and not compiled /usr/src/sys/i386/isa/stallion.c:442: warning: `struct isa_device' declared inside parameter list /usr/src/sys/i386/isa/stallion.c:442: warning: its scope is only this definition or declaration, which is probably not what you want /usr/src/sys/i386/isa/stallion.c:443: warning: `struct isa_device' declared inside parameter list /usr/src/sys/i386/isa/stallion.c:468: error: syntax error before stlintr /usr/src/sys/i386/isa/stallion.c:468: warning: type defaults to `int' in declaration of `stlintr' /usr/src/sys/i386/isa/stallion.c:468: warning: data definition has no type or storage class /usr/src/sys/i386/isa/stallion.c:502: error: variable `stldriver' has initializer but incomplete type /usr/src/sys/i386/isa/stallion.c:503: warning: excess elements in struct initializer /usr/src/sys/i386/isa/stallion.c:503: warning: (near initialization for `stldriver') /usr/src/sys/i386/isa/stallion.c:504: warning: excess elements in struct initializer /usr/src/sys/i386/isa/stallion.c:504: warning: (near initialization for `stldriver') /usr/src/sys/i386/isa/stallion.c:505: warning: excess elements in struct initializer /usr/src/sys/i386/isa/stallion.c:505: warning: (near initialization for `stldriver') /usr/src/sys/i386/isa/stallion.c:507: warning: excess elements in struct initializer /usr/src/sys/i386/isa/stallion.c:507: warning: (near initialization for `stldriver') /usr/src/sys/i386/isa/stallion.c:508: warning: type defaults to `int' in declaration of `COMPAT_ISA_DRIVER' /usr/src/sys/i386/isa/stallion.c:508: warning: parameter names (without types) in function declaration /usr/src/sys/i386/isa/stallion.c:508: warning: data definition has no type or storage class /usr/src/sys/i386/isa/stallion.c:564: warning: `struct isa_device' declared inside parameter list /usr/src/sys/i386/isa/stallion.c:565: error: conflicting types for `stlprobe' /usr/src/sys/i386/isa/stallion.c:442: error: previous declaration of `stlprobe' /usr/src/sys/i386/isa/stallion.c: In function `stlprobe': /usr/src/sys/i386/isa/stallion.c:573: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:576: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:576: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:576: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:576: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:576: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:578: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:582: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:582: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:582: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:582: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:582: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:588: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c: At top level: /usr/src/sys/i386/isa/stallion.c:621: warning: `struct isa_device' declared inside parameter list /usr/src/sys/i386/isa/stallion.c:622: error: conflicting types for `stlattach' /usr/src/sys/i386/isa/stallion.c:443: error: previous declaration of `stlattach' /usr/src/sys/i386/isa/stallion.c: In function `stlattach': /usr/src/sys/i386/isa/stallion.c:630: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:647: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:648: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:649: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c:651: error: dereferencing pointer to incomplete type /usr/src/sys/i386/isa/stallion.c: At top level: /usr/src/sys/i386/isa/stallion.c:1716: warning: `stlintr' was used with no prototype before its definition /usr/src/sys/i386/isa/stallion.c:1716: error: `stlintr' redeclared as different kind of symbol /usr/src/sys/i386/isa/stallion.c:468: error: previous declaration of `stlintr' /usr/src/sys/i386/isa/stallion.c:1716: warning: `stlintr' was declared `extern' and later `static' /usr/src/sys/i386/isa/stallion.c:502:
Re: Repeatable panic from 'camcontrol devlist'
* Greg 'groggy' Lehey, 2003-10-27 : I'm running a -CURRENT kernel built about a week ago, and on 'camcontrol devlist' I get the following repeatable panic: Fixed in vfs_bio.c rev. 1.418. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam related panic
* Stuart Walsh, 2003-10-18 : I have an easily reproducable panic when using atapicam. Vague trace This has nothing to do whatsoever with ATAPI/CAM! this is an inconsistency between cam_periph.c and vfs_bio.c, you need to update the latter to rev. 1.418 or newer. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Forward: HEADS UP! Default value of ip6_v6only changed
Hi, Our default of net.inet6.ip6.v6only was off in 4.X, and was changed to on on 5.X to follow NetBSD's practice. This behavior on 5.X breaks RFC2553/3493, and the change was intentional from security consideration. But, NetBSD changed it off by default. How do you think our default of on? ---BeginMessage--- The default value of ip6_v6only (sysctl net.inet6.ip6.v6only) has been changed. The new value brings us closer in line with current RFC-defined behavior and practices. Itojun still has significant concerns about the new default behavior. His concerns have been well-documented in ftp://ftp.itojun.org/pub/paper/draft-cmetz-v6ops-v4mapped-api-harmful-00.txt Best Regards, NetBSD OS PMC (core) -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ---End Message--- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GBDE performance on ZIP disks
Robert Watson, 28.10.03, 03:26h CET: [...slow gbde encrypted ZIP disk...] How do things look performance-wise if you do a raw sector read comparison with dd at various blocksizes? My recollection is that our msdos code Here are a few numbers (for reading - the ones for writing don't really differ): [13:45] [EMAIL PROTECTED] sudo dd if=/dev/da1 of=/dev/null bs=512 count=1000 1000+0 records in 1000+0 records out 512000 bytes transferred in 20.559991 secs (24903 bytes/sec) [13:45] [EMAIL PROTECTED] sudo dd if=/dev/da1 of=/dev/null bs=8192 count=1000 1000+0 records in 1000+0 records out 8192000 bytes transferred in 25.996819 secs (315115 bytes/sec) [13:46] [EMAIL PROTECTED] sudo dd if=/dev/da1 of=/dev/null bs=32768 count=1000 1000+0 records in 1000+0 records out 32768000 bytes transferred in 46.302189 secs (707699 bytes/sec) [13:47] [EMAIL PROTECTED] sudo dd if=/dev/da1 of=/dev/null bs=65536 count=1000 1000+0 records in 1000+0 records out 65536000 bytes transferred in 77.230242 secs (848579 bytes/sec) would benefit hugely from the addition of clustering support, but UFS2 with a fragment size matching GBDE's notion shouldn't present the same problem... The fragment size practically doesn't matter; I tried newfs's defaults (block size 16384, frag size 2048) as well as a fragment size matching gbde's sector size (- block size 4096, frag size 512), and the time difference for copying the mentioned 37 MB of data was 1 second. Stefan pgp0.pgp Description: PGP signature
Re: Anyone object to the following change in libc?
On Tue, 28 Oct 2003, Harti Brandt wrote:
(Cc set to current).
On Tue, 28 Oct 2003, Jordan K Hubbard wrote:
JKHBack in the pre-panther timeframe, we received the following bug report:
JKH
JKHEarlier versions of Mac OS X (e.g., 10.2.6) return a value of -1 with
JKHthe following program:
JKH
JKH#include stdlib.h
JKH
JKHmain()
JKH{ int ret, x;
JKH ret = sscanf (123, %*d%d, x);
JKH printf(ret is %d\n, ret);
JKH}
JKH
JKHOn Panther, the return value is zero. It affects packages like GMP,
JKHwhose automated test sequence assumes that -1 is the proper return
JKHvalue.
JKH
JKHA little investigation revealed that FreeBSD had changed vfscanf()
JKHabout 6 years ago, but it was the only Unix to do so and everyone
JKHelse has stuck with the more traditional behavior of returning an error
JKHin this case. We've done some investigation and consulted SUSv3, but
JKHit's unfortunately vague on what the proper behavior should be so it
JKHseems that it's been left to the various implementations to decide for
JKHthemselves what constitutes correct behavior. Given the fact that
JKHFreeBSD appears to be the odd-man out, we plan to revert back to the
JKH10.2.6 behavior for vfscanf() in 10.4, but it seems a pity to have
JKHFreeBSD diverge here (not just from Mac OS X past and future but from
JKHLinux and Solaris) in ways that break known 3rd-party software and for
JKHreasons which remain obscure.
JKH
JKHSo, two questions:
JKH
JKH1. Are the reasons not as obscure as I think? I'd welcome an
JKHexplanation as to why this was done.
I think ISO-C is pretty clear here. Basically three things happen when
the scanf() finds a format specifier: it matches the input string
according to the format specifier, if that match is not empty it converts
the value to the corresponding type and, if assignment suppression was
not specified it assigns the value.
When applying %*d%d to the string 123 the first 'd' format matches
the string 123 and the conversion yields the number 123. This is then
thrown away because assignment is suppressed. The next format specified
finds an EOF condition on the stream so this counts as an input error
according to paragraph 9, last sentence of 7.19.6.2.
According to to paragraph 18 (The fscanf function returns the value of
the macro EOF if an input failure occurs before any conversion. Otherwise,
the function returns the number of input items assigned, which can be
fewer than provided for, or even zero, in the event of an early matching
failure.) the function returns 0, because there was a succesful
conversion but no assignment.
I just had a look at the v7 implementation. In this implementation a
suppressed assignment is not counted as a match even if the
match was successful. This explains the return of -1 if the first
not-suppressed conversion failes.
I think changing current behaviour would be a regression with regard to
ISO-C (and Posix).
I agree, and to add a little snippet of POSIX:
RETURN VALUE
Upon successful completion, these functions shall return the
number of successfully matched and assigned input items; this
number can be zero in the event of an early matching failure.
If the input ends before the first matching failure or
conversion, EOF shall be returned. If a read error occurs, the
error indicator for the stream is set, EOF shall be returned,
and errno shall be set to indicate the error.
There is no matching failure, but there is a conversion. I think
%*d just counts as an assignment suppression but does not suppress
the fact that a conversion occurred.
On the other hand, Solaris 8 does seem to return -1...
--
Dan Eischen
___
[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 Tue, 28 Oct 2003, Daniel Eischen wrote:
DEOn Tue, 28 Oct 2003, Harti Brandt wrote:
DE
DE
DE (Cc set to current).
DE
DE On Tue, 28 Oct 2003, Jordan K Hubbard wrote:
DE
DE JKHBack in the pre-panther timeframe, we received the following bug report:
DE JKH
DE JKHEarlier versions of Mac OS X (e.g., 10.2.6) return a value of -1 with
DE JKHthe following program:
DE JKH
DE JKH#include stdlib.h
DE JKH
DE JKHmain()
DE JKH{ int ret, x;
DE JKH ret = sscanf (123, %*d%d, x);
DE JKH printf(ret is %d\n, ret);
DE JKH}
DE JKH
DE JKHOn Panther, the return value is zero. It affects packages like GMP,
DE JKHwhose automated test sequence assumes that -1 is the proper return
DE JKHvalue.
DE JKH
DE JKHA little investigation revealed that FreeBSD had changed vfscanf()
DE JKHabout 6 years ago, but it was the only Unix to do so and everyone
DE JKHelse has stuck with the more traditional behavior of returning an error
DE JKHin this case. We've done some investigation and consulted SUSv3, but
DE JKHit's unfortunately vague on what the proper behavior should be so it
DE JKHseems that it's been left to the various implementations to decide for
DE JKHthemselves what constitutes correct behavior. Given the fact that
DE JKHFreeBSD appears to be the odd-man out, we plan to revert back to the
DE JKH10.2.6 behavior for vfscanf() in 10.4, but it seems a pity to have
DE JKHFreeBSD diverge here (not just from Mac OS X past and future but from
DE JKHLinux and Solaris) in ways that break known 3rd-party software and for
DE JKHreasons which remain obscure.
DE JKH
DE JKHSo, two questions:
DE JKH
DE JKH1. Are the reasons not as obscure as I think? I'd welcome an
DE JKHexplanation as to why this was done.
DE
DE I think ISO-C is pretty clear here. Basically three things happen when
DE the scanf() finds a format specifier: it matches the input string
DE according to the format specifier, if that match is not empty it converts
DE the value to the corresponding type and, if assignment suppression was
DE not specified it assigns the value.
DE
DE When applying %*d%d to the string 123 the first 'd' format matches
DE the string 123 and the conversion yields the number 123. This is then
DE thrown away because assignment is suppressed. The next format specified
DE finds an EOF condition on the stream so this counts as an input error
DE according to paragraph 9, last sentence of 7.19.6.2.
DE
DE According to to paragraph 18 (The fscanf function returns the value of
DE the macro EOF if an input failure occurs before any conversion. Otherwise,
DE the function returns the number of input items assigned, which can be
DE fewer than provided for, or even zero, in the event of an early matching
DE failure.) the function returns 0, because there was a succesful
DE conversion but no assignment.
DE
DE I just had a look at the v7 implementation. In this implementation a
DE suppressed assignment is not counted as a match even if the
DE match was successful. This explains the return of -1 if the first
DE not-suppressed conversion failes.
DE
DE I think changing current behaviour would be a regression with regard to
DE ISO-C (and Posix).
DE
DEI agree, and to add a little snippet of POSIX:
DE
DE RETURN VALUE
DE
DEUpon successful completion, these functions shall return the
DEnumber of successfully matched and assigned input items; this
DEnumber can be zero in the event of an early matching failure.
DEIf the input ends before the first matching failure or
DEconversion, EOF shall be returned. If a read error occurs, the
DEerror indicator for the stream is set, EOF shall be returned,
DEand errno shall be set to indicate the error.
DE
DEThere is no matching failure, but there is a conversion. I think
DE%*d just counts as an assignment suppression but does not suppress
DEthe fact that a conversion occurred.
DE
DEOn the other hand, Solaris 8 does seem to return -1...
But Solaris 8 and 9 also don't understand 'hh' modifiers and therefor are
neither ISO nor Posix conform. While we have Solaris 10 here, we have yet
to install it somewhere.
harti
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forward: HEADS UP! Default value of ip6_v6only changed
Hajimu UMEMOTO wrote: Hi, Our default of net.inet6.ip6.v6only was off in 4.X, and was changed to on on 5.X to follow NetBSD's practice. This behavior on 5.X breaks RFC2553/3493, and the change was intentional from security consideration. But, NetBSD changed it off by default. How do you think our default of on? As long as it is documented well, and the workaround (setting the IPV6_V6ONLY sockopt off) is referenced, I don't think it really matters. Application programmers realize they have *some* work to do when porting applications to V6. A single sockopt call is not unreasonable. I think on for the security reasons outlined is the right call - it will at least make people think about those issues, and most would not without something bringing it up. (That said, it would be nice if NetBSD would pick a direction and keep it.) jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GL slowdown with latest kernel
On Tue, Oct 28, 2003 at 09:39:28AM +0100, Yuri Khotyaintsev wrote: I see a ~3x reduced GL performance as measured by glxgears. This is on a dual Athlon sysmem with Radeon 9000 Pro. I don't see a slowdown with a dual Athlon and Radeon 7500. Also, mouse is much smoother with glxgears in full-screen window - used to be jerky on that test. (This is with sched_bsd; haven't run _ule.) -- 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: Anyone object to the following change in libc?
I think ISO-C is pretty clear here. It would be wise to raise this on comp.std.c which is read by several of the ISO C standard authors. Things that seem pretty clear often turn out not to be... -- Richard ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Random signals in {build,install}world recently?
On Tue, Oct 28, 2003 at 09:01:35AM +0200, Vallo Kallaste wrote: Well, I have a system from the 25th that works just fine, we're looking between the dates of 9/25 - 9/30. It is fixed, grab newer sources. It seems mostly but not completely fixed. I got one sig11 (on touch :) building ports. Retrying the port (Mozilla 1.5, pretty big) succeeded, and I got no further sigs doing portupgrade -ap. As always, I can't completely rule out h/w, but the system has never produced any sigs doing builds on RELENG_5_1 or -current before 9/24. However the behavior is very much improved, as -currents after 9/24 until the pmap.c fix would get sigs every few minutes. (Reminder, this is a dual-athlon.) -- 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]
Instant panic when trying to unload nvidia.ko
Hi, I'm running -CURRENT from yesterday. In a futile attempt to make some use of my rusty RivaTNT card, I installed the nvidia kernel port, but it seems to be doing some weird stuff with memory. This appeared in the messages log: ... Oct 28 16:04:33 scienide kernel: malloc() of 32 with the following non-sleepable locks held: Oct 28 16:04:33 scienide kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc39d478c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidi a_subr.c:753 Oct 28 16:04:33 scienide kernel: malloc() of 32 with the following non-sleepable locks held: Oct 28 16:04:33 scienide kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc39d478c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidi a_subr.c:753 Oct 28 16:04:33 scienide kernel: malloc() of 4096 with the following non-sleepable locks held: Oct 28 16:04:33 scienide kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc39d478c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidi a_subr.c:753 ... And now, the fun part. After booting, if I try to unload the module I get the attached panic. I know the nvidia kernel is proprietary code and yada yada, but the problem seems to be in the open source part of the code, so I have some hope I can get to fix it with a little help :-) Cheers, -- Miguel Mendez [EMAIL PROTECTED] http://www.energyhq.es.eu.org debug.log Description: Binary data ___ [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 Tue, Oct 28, 2003 at 04:07:13PM +, Richard Tobin wrote: I think ISO-C is pretty clear here. It would be wise to raise this on comp.std.c which is read by several of the ISO C standard authors. Things that seem pretty clear often turn out not to be... This topic is discussed almost once per year in comp.std.c, see e.g. http://groups.google.com/groups?selm=esvRTfAyaFy2Ewgv%40on-the-train.demon.co.uk for a reply from a member of JTC1/SC22/WG14. FreeBSD's *scanf() implementation seems to be just fine. Cheers, Stefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Mon, 27 Oct 2003, David Schultz wrote: I'm just catching up on -CURRENT, but I wanted to point out that this was fixed last night in: src/lib/msun/src/e_scalbf.c,v1.8 src/lib/msun/src/e_scalb.c,v1.10 The fix was to use the old versions of isnan() and isinf() specifically in the two places in libm where they are needed. okay, so the $65,000 question is: Does this make the Diablo JDKs work? :) -- 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: 5.1-p10 lockups
On Tue, 28 Oct 2003, [ISO-8859-1] Branko F. Grac(nar wrote: Last days i'm having big troubles with my 5.1-p10 box. It's dual p3 1.2MHz, 1G of ecc ram with 900G on pst0 raid5 disk array. Kernel configuration is attached. My problems are lockups when i test apache (2.0.47, php 4.3.3 + turck mmcache and horde imp webmail) this machine with JMeter. Machine locks up after approx. 5-10 seconds of jmeter test. That weird, becouse if i stress test mail server on this machine, it passes 24 test without problem. When lockup accours, there are no kernel messages on console, machine stop responding to echo requests (ping). There is nothing in syslog logs... Is the console responsive? Try compiling with DDB and hitting Ctrl-Alt-Esc when it locks up to drop to DDB. See the Handbook for the sorts of things to run while you're there (see the section on kenrel debugging). The network will stop if you run out of mbufs. If you're running with default tuning options, you're probably hitting a resource limit. Check netstat -m, sysctl vm.vm_stats, etc. for any overages. You ight have to run these in a loop while you're running the load test to see what the trending is before it hangs. Bad hardware is not an option. You haven't been using PC hardware long enough if you're already discounting this as an option :) -- 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: UFS file system problem in either stable or current
On Tuesday 28 October 2003 08:42 am, Dan Strick wrote: On Wed, 22 Oct 2003 06:23:20 -0500, Peter Schultz wrote: Dan Strick wrote: There seems to be an inconsistency between release 4.9-RC and 5.1 ufs support. If I fsck the same ufs (type 1 of course) file system on both releases, each claims that the other has left incorrect summary data in the superblock. Presumably only one can be correct. I just don't know which to blame. ... There is no problem AFAIK, you just have to fsck with the matching executable. A lot has changed with FreeBSD 5, spend some time with the -current archive and you will learn more. I'm sure you noticed how your findings are consistently inconsistent. Thanks for the pointer. I eventually found at least part of the discussion in the -current archive. I interpret the discussion as follows: The 5.x UFS1 file system turns out to be slightly incompatible with earlier UFS file systems. The problem is only that it keeps the summary data in a different location in the superblock, but that is sufficient to make the file systems incompatible. There seems to be no interest in making them compatible. I need them to be compatible if possible. I'm working on a few related problems, so I'm becoming more familiar with the code. I'm willing to help if you have an approach in mind. Do you know why the change was made? Suggestion: if FreeBSD 5 used a different clean flag and FreeBSD 4/5 always cleared the other's clean flag whenever they rewrote a superblock, the file systems would automatically be refscked whenever you switched between operating systems but not after a normal reboot. If somebody does so, please don't use the fs_state field; I have a local patch that uses that for a different (incompatible) purpose that I'd like to commit soon. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1 - stl Kernel compile fails
On Tue, Oct 28, 2003 at 12:21:09PM +0100, Karl M. Joch wrote: Kris Kennaway wrote: On Tue, Oct 28, 2003 at 08:11:33AM +0100, Karl M. Joch wrote: i added a stallion easy i/o to a 5.1 box. compiling the kernel fails with a lot of errors in stallion.c. any chance that this gets corrected soon? Post the errors you're seeing so we don't have to guess. Kris there is a remark that it is broken. this is why i havnt attached the output. OK, it's been marked broken since January 2001. I wouldn't hold your breath on a fix, unless you can come up with one yourself. Indeed, it will probably be removed from the tree in the medium-term future. Kris pgp0.pgp Description: PGP signature
[current tinderbox] failure on alpha/alpha
TB --- 2003-10-28 17:00:00 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-28 17:00:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-10-28 17:00:00 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-10-28 17:01:56 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/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/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-10-28 18:04:41 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Tue Oct 28 18:04:41 GMT 2003 Kernel build for GENERIC completed on Tue Oct 28 18:16:30 GMT 2003 TB --- 2003-10-28 18:16:30 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-10-28 18:16:30 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Oct 28 18:16:30 GMT 2003 [...] ext2_linux_balloc.o(.text2+0x4): relocation truncated to fit: BRADDR .text ext2_linux_balloc.o(.text2+0x8): relocation truncated to fit: BRADDR .text ext2_linux_ialloc.o: In function `ext2_free_inode': ext2_linux_ialloc.o(.text+0x5c8): relocation truncated to fit: BRADDR .text2 ext2_linux_ialloc.o: In function `ext2_new_inode': ext2_linux_ialloc.o(.text+0xae4): relocation truncated to fit: BRADDR .text2 ext2_linux_ialloc.o(.text2+0x0): relocation truncated to fit: BRADDR .text ext2_linux_ialloc.o(.text2+0x4): relocation truncated to fit: BRADDR .text *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-10-28 18:27:36 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-10-28 18:27:36 - TB --- ERROR: failed to build lint kernel TB --- 2003-10-28 18:27:36 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel hangs with SMP/Hyperthreading
hi, i built a kernel with APIC_IO and SMP for my p4 with hyperthreading. when i try to boot the kernel it hangs during boot at: APIC_IO: Testing 8254 interrupt delivery doing while (read_intr_count(8) 6) ; /* nothing */ (sys/i386/isa/clock.c:1030) read_intr_count(8) returns 0 forever... i dont know how to provide a dmesg as i cant get to a shell. this computer is a laptop with sis 645dx chipset. anyone have a fix for that? regards, bernhard ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
sound LOR patches
Hello All,
I tried to fix some LOR in -current and attached you will find
some patches.
I sent these to the -sound list but I didn't get a response.
(Maybe I should mention that I'm also part of the -sound list). So
now I don't know what's going in with sound and -current.
Anyway, the fixes are:
dsp_open: rearrange to only hold one lock at a time
dsp_close: ditto
mixer_hwvol_init: delete locking, the only consumer seems to
be the ess driver and it only call it a creation time, I
think the device will be stable across the sleepable malloc
in the dyn. sysctl allocation
cmi interrupt routine: Release locks while caller chn_intr,
We could either this or do what emu10k1 does which is have
no locks at in the interrupt handler.
Cheers,
--Mat
--
I don't even know what street Canada is on.
- Al Capone
--- dspold.cSun Sep 14 17:49:38 2003
+++ dsp.c Tue Oct 21 14:38:44 2003
@@ -174,6 +174,8 @@
intrmask_t s;
u_int32_t fmt;
int devtype;
+ int rdref;
+ int error;
s = spltty();
d = dsp_get_info(i_dev);
@@ -209,6 +211,8 @@
panic(impossible devtype %d, devtype);
}
+ rdref = 0;
+
/* lock snddev so nobody else can monkey with it */
pcm_lock(d);
@@ -251,67 +255,66 @@
return EBUSY;
}
/* got a channel, already locked for us */
- }
-
- if (flags FWRITE) {
- /* open for write */
- wrch = pcm_chnalloc(d, PCMDIR_PLAY, td-td_proc-p_pid, -1);
- if (!wrch) {
- /* no channel available */
- if (flags FREAD) {
- /* just opened a read channel, release it */
- pcm_chnrelease(rdch);
- }
- /* exit */
- pcm_unlock(d);
- splx(s);
- return EBUSY;
- }
- /* got a channel, already locked for us */
- }
-
- i_dev-si_drv1 = rdch;
- i_dev-si_drv2 = wrch;
-
- /* Bump refcounts, reset and unlock any channels that we just opened,
-* and then release device lock.
-*/
- if (flags FREAD) {
if (chn_reset(rdch, fmt)) {
pcm_chnrelease(rdch);
i_dev-si_drv1 = NULL;
- if (wrch (flags FWRITE)) {
- pcm_chnrelease(wrch);
- i_dev-si_drv2 = NULL;
- }
pcm_unlock(d);
splx(s);
return ENODEV;
}
+
if (flags O_NONBLOCK)
rdch-flags |= CHN_F_NBIO;
pcm_chnref(rdch, 1);
CHN_UNLOCK(rdch);
+ rdref = 1;
+ /*
+* Record channel created, ref'ed and unlocked
+*/
}
+
if (flags FWRITE) {
- if (chn_reset(wrch, fmt)) {
- pcm_chnrelease(wrch);
- i_dev-si_drv2 = NULL;
- if (flags FREAD) {
- CHN_LOCK(rdch);
- pcm_chnref(rdch, -1);
- pcm_chnrelease(rdch);
- i_dev-si_drv1 = NULL;
- }
- pcm_unlock(d);
- splx(s);
- return ENODEV;
+ /* open for write */
+ wrch = pcm_chnalloc(d, PCMDIR_PLAY, td-td_proc-p_pid, -1);
+ error = 0;
+
+ if (!wrch)
+ error = EBUSY; /* XXX Right return code? */
+ else if (chn_reset(wrch, fmt))
+ error = ENODEV;
+
+ if (error != 0) {
+ if (wrch) {
+ /*
+* Free play channel
+*/
+ pcm_chnrelease(wrch);
+ i_dev-si_drv2 = NULL;
}
- if (flags O_NONBLOCK)
- wrch-flags |= CHN_F_NBIO;
- pcm_chnref(wrch, 1);
- CHN_UNLOCK(wrch);
+ if (rdref) {
+ /*
+* Lock, deref and release previously created record channel
+*/
+ CHN_LOCK(rdch);
+ pcm_chnref(rdch, -1);
+ pcm_chnrelease(rdch);
+ i_dev-si_drv1 = NULL;
+ }
+
+ pcm_unlock(d);
+ splx(s);
+ return error;
+ }
+
+ if (flags O_NONBLOCK)
+ wrch-flags |= CHN_F_NBIO;
+ pcm_chnref(wrch, 1);
+
Re: kernel hangs with SMP/Hyperthreading
Hi, There is a discussion going on about strange interactions between the boot menu and SMP that sounds very much like what you describe. FOr a workaround, at the boot menu, select option 6, then type 'boot' at the prompt. Scott On Tue, 28 Oct 2003, Bernhard Valenti wrote: hi, i built a kernel with APIC_IO and SMP for my p4 with hyperthreading. when i try to boot the kernel it hangs during boot at: APIC_IO: Testing 8254 interrupt delivery doing while (read_intr_count(8) 6) ; /* nothing */ (sys/i386/isa/clock.c:1030) read_intr_count(8) returns 0 forever... i dont know how to provide a dmesg as i cant get to a shell. this computer is a laptop with sis 645dx chipset. anyone have a fix for that? regards, bernhard ___ [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: 5.1 - stl Kernel compile fails
On Tue, Oct 28, 2003 at 08:11:33AM +0100, Karl M. Joch wrote: i added a stallion easy i/o to a 5.1 box. compiling the kernel fails with a lot of errors in stallion.c. any chance that this gets corrected soon? Is this an ISA or PCI card? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newfs by fstab directory name?
On Mon, Oct 27, 2003 at 01:26:23PM -0800, Wes Peters wrote: At work we do a lot of dynamic filesystem creation, so we added the ability to specify the 'special file' argument to newfs via the fstab mount point directory. Please see the attached patch. If nobody objects, I'll commit this in a couple of days. Not objecting, but I don't follow how the change is to be used. Can you post an example? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE page fault with sched_ule.c 1.67
On Monday 27 October 2003 23:31, Jeff Roberson wrote: On Mon, 27 Oct 2003, Jonathan Fosburgh wrote: On Monday 27 October 2003 12:06 pm, Arjan van Leeuwen wrote: Hi, I just cvsupped and built a new kernel that includes sched_ule.c 1.67. I'm getting a page fault when working in Mozilla Firebird. It happens pretty soon, after opening one or two pages. The trace shows that it panics at sched_prio(). I should have said, I am getting the same panic, same trace, but not using Mozilla. I get it shortly after launching my KDE session, though I'm not sure where in my session the problem is being hit. It's KSE. You can disable it to work around temporarily. I will fix it tonight. Thanks for the fast response, seems to be fixed in 1.68 :) Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR
Hello! When I establish a dialup link with my ISP using ppp(8), I get the following LOR (very recent -current): lock order reversal 1st 0xc47ab790 rtentry (rtentry) @ /usr/src/sys/net/rtsock.c:388 2nd 0xc442367c radix node head (radix node head) @ /usr/src/sys/net/route.c:133 Stack backtrace: backtrace(c0654bae,c442367c,c065a582,c065a582,c065a5d8) at backtrace+0x17 witness_lock(c442367c,8,c065a5d8,85,246) at witness_lock+0x672 _mtx_lock_flags(c442367c,0,c065a5d8,85,117) at _mtx_lock_flags+0xba rtalloc1(c478de6c,1,1,3d7,ddb62b44) at rtalloc1+0x79 rt_setgate(c47ab700,c44f1280,c478de6c,184,0) at rt_setgate+0x268 route_output(c1929b00,c4581100,7c,c1929b00,1f84) at route_output+0x62e raw_usend(c4581100,0,c1929b00,0,0) at raw_usend+0x73 rts_send(c4581100,0,c1929b00,0,0) at rts_send+0x35 sosend(c4581100,0,ddb62c7c,c1929b00,0) at sosend+0x44d soo_write(c4504088,ddb62c7c,c478df00,0,c4783ab0) at soo_write+0x70 dofilewrite(c4783ab0,c4504088,3,bfbfec40,7c) at dofilewrite+0xf8 write(c4783ab0,ddb62d10,c066536b,3ed,3) at write+0x6e syscall(2f,2f,2f,3,3) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (4), eip = 0x2827b35f, esp = 0xbfbfebfc, ebp = 0xbfbfec28 --- This LOR appeared after massive network stack locking changes by sam@ (but I am not 100% sure that they cause it). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Another ATAng failure.
I have tried several times in recent days to burn DVDs with burncd, growisofs and cdrecord ... all of which worked before atang. Growisofs complains that it can't flush it's buffers. Burncd doesn't complain ... but the resulting disk is not mountable. I thought at one point that some DVD images were writable. I havn't cvsup'd several times since them. No images appear writable now ... so the problem appears to have gotten worse. Burning CDR and CDRW appears to work fine, however. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
page fault in propagate_priority
I've gotten the following panic twice in the last few days. I'm pretty sure truss has something to do with it, since I just started trussing something when it paniced. No crashdumps unfortunately, and the system locks up hard so I have to reset it. The fault address is 0x24 so it looks like a null pointer dereference of some sort. I've added asserts to propagate_priority any place a pointer to a structure is dereferenced, so if it happens again I should have the line number at least. panic1 was on an Oct 15 kernel, panic2 was on an Oct 27 kernel. -- Dan Nelson [EMAIL PROTECTED] Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = 0300 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc056f9d6 stack pointer = 0x10:0xdc1dcc34 frame pointer = 0x10:0xdc1dcc48 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 = 13 (swi8: tty:sio clock) trap number = 12 panic: page fault cpuid = 0; lapic.id = 0300 Stack backtrace: panic(c0728cc3,c0754b62,c29a58f4,1,1,c05913e7,c29a9380,42fabcd6,0,f,dc1dd09b,c059) at panic+0x1ec trap_fatal(dc1dcbf4,24,c047cf65,c3fe69c0,24) at trap_fatal+0x281 trap(dc1d0018,c0580010,c29a0010,24,0) at trap+0x4bc calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc056f9d6, esp = 0xdc1dcc34, ebp = 0xdc1dcc48 --- propagate_priority(c29a6ab0,90605411,0,dc1dcc74,c29a6ad0) at propagate_priority+0x66 _mtx_lock_sleep(c07bb9a0,0,0,0,c05b76a0) at _mtx_lock_sleep+0x197 softclock(0,0,0,0,c29a6ab0) at softclock+0x35d ithread_loop(c29a3d00,dc1dcd48,0,0,0) at ithread_loop+0x187 fork_exit(c05645f0,c29a3d00,dc1dcd48) at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xdc1dcd7c, ebp = 0 --- boot() called on cpu#0 syncing disks, buffers remaining... panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled cpuid = 0; lapic.id = 0300 boot() called on cpu#0 Uptime: 6d7h17m43s Dumping 1023 MB Dump failed. Partition too small. pfs_vncache_unload(): 28 entries remaining Shutting down ACPI panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled cpuid = 0; lapic.id = 0300 boot() called on cpu#0 Uptime: 6d7h17m43s Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = 0300 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0575b16 stack pointer = 0x10:0xdc1dcc34 frame pointer = 0x10:0xdc1dcc48 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 = 13 (swi8: tty:sio clock) trap number = 12 panic: page fault cpuid = 0; lapic.id = 0300 Stack backtrace: panic(c0730edd,c075d59e,c29a58f4,1,1,c0590206,c05a,c7433372,0,f,dc1dd09b,c05a) at panic+0x1ec trap_fatal(dc1dcbf4,24,dc1dcbc4,c059759b,24) at trap_fatal+0x281 trap(c29a0018,dc1d0010,c0580010,24,0) at trap+0x4bc calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc0575b16, esp = 0xdc1dcc34, ebp = 0xdc1dcc48 --- propagate_priority(c29a6ab0,c48af390,4,dc1dcc7c,c29a6ad0) at propagate_priority+0x66 _mtx_lock_sleep(c07c4520,0,0,0,c062d5b0) at _mtx_lock_sleep+0x197 softclock(0,0,0,0,c29a6ab0) at softclock+0x35d ithread_loop(c29a3d00,dc1dcd48,0,0,0) at ithread_loop+0x187 fork_exit(c056a370,c29a3d00,dc1dcd48) at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xdc1dcd7c, ebp = 0 --- boot() called on cpu#0 syncing disks, buffers remaining... panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled cpuid = 0; lapic.id = 0300 boot() called on cpu#0 Uptime: 7h16m36s Dumping 1023 MB Dump failed. Partition too small. pfs_vncache_unload(): 27 entries remaining Shutting down ACPI panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled cpuid = 0; lapic.id = 0300 boot() called on cpu#0 Uptime: 7h16m36s [-- 20 minutes passes --] spin lock sched lock held by 0xc29a6ab0 for 5 seconds ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
OpenLDAP/nss_ldap/pam_ldap
Question ? I am using FreeBSD 5.1 I have a linux server with openldap running on it authenticating Solaris and Linux box and now FreeBSD 5.1 I have gotten FreeBSD 5.1 to authenticate user remotely ssh ing to the box. They can log in, but when they log in, the system shows their userid instead of the username when you do a ps. this tells me something might be wrong with nss_ldap. but not sure what i am doing wrong. I can do id username which it returns the user information. does anyone have an idea what i didn't do during my setup of OpenLDAP/nss_ldap/pam_ldap ? Thanks. Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: page fault in propagate_priority
On 28-Oct-2003 Dan Nelson wrote: I've gotten the following panic twice in the last few days. I'm pretty sure truss has something to do with it, since I just started trussing something when it paniced. No crashdumps unfortunately, and the system locks up hard so I have to reset it. The fault address is 0x24 so it looks like a null pointer dereference of some sort. I've added asserts to propagate_priority any place a pointer to a structure is dereferenced, so if it happens again I should have the line number at least. panic1 was on an Oct 15 kernel, panic2 was on an Oct 27 kernel. It might help some if you could use gdb -k on your kernel.debug and do 'l *propagate_priority+0x66' to see where it is dying. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newfs by fstab directory name?
On Tuesday 28 October 2003 12:05, David O'Brien wrote:
On Mon, Oct 27, 2003 at 01:26:23PM -0800, Wes Peters wrote:
At work we do a lot of dynamic filesystem creation, so we added the
ability to specify the 'special file' argument to newfs via the
fstab mount point directory. Please see the attached patch. If
nobody objects, I'll commit this in a couple of days.
Not objecting, but I don't follow how the change is to be used.
Can you post an example?
Sure. Example from /etc/fstab:
/dev/ad0s1d/tmpufs rw 2 2
/dev/ad0s1f/usrufs rw 2 2
/dev/ad0s1e/varufs rw 2 2
/dev/acd0 /cdrom cd9660 ro,noauto 0 0
/dev/da0s1e/spool ufs rw,noauto 0 0
The disk space on /spool is managed by the application and isn't
guaranteed to be on-line or even existent when the system portion
loads and starts the application. This space is entirely transient
data that doesn't need to be saved across reboots. When the
application starts, it checks to see if /spool is clean; if so it
just mounts it, if not it newfs's it and then mounts it. This
space isn't necessarily always da0s1e but it is always /spool
across different hardware platforms. We prefer to:
newfs /spool
rather than
. {some file full of shell variables describing the hardware}
newfs $SPOOL_PARTITION
because the former is slightly more concise. We had a local patch to do
this in our 4.x code base, but it seemed a general enough change that
others might find it useful as well. I recall ecountering this same
problem at DoBox so it appears to be a general problem for disk-based
appliances, at least if you want to support differing hardware.
--
Where am I, and what am I doing in this handbasket?
Wes Peters [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenLDAP/nss_ldap/pam_ldap
Hi, Steve!
On Tue, Oct 28, 2003 at 02:52:51PM -0800, Steve Lee wrote:
Question ?
I am using FreeBSD 5.1
I have gotten FreeBSD 5.1 to authenticate user remotely
ssh ing to the box. They can log in, but when they log
in, the system shows their userid instead of the username
when you do a ps. this tells me something might be
wrong with nss_ldap. but not sure what i am doing wrong.
I can do id username which it returns the user information.
does anyone have an idea what i didn't do during my setup of
OpenLDAP/nss_ldap/pam_ldap ? Thanks.
I would like to confirm that such weirdness exists... I do use
nss_ldap and also noticed, that some of the programs, like ls,
show numeric id of the user, when other, like top, show normal
username, retrieved from LDAP server.
Short investigation brought me to the conclusion, that the behaviour
differs depending if the program was linked against libc statically
or dynamically...
This short code exposes the problem:
#include stdio.h
#include pwd.h
int main () {
struct passwd *pw = getpwuid(1002);
printf(%s\n, (pw) ? pw-pw_name : none);
}
Instead of 1002 put the uid of the user from LDAP.
If you compile this program as:
gcc test.c -o test
Which normally implies dynamic linking, when you should get username in
the output.
If you compile it as:
gcc -static test.c -o test
When none will be printed instead...
So, the problem lays somewhere in the libc, in the way, how getpwuid and
friends work in the dynamic and static context with NSS... I don't know,
is this a bug or a feature :) If first, then, probably, PR should be created.
With regards,
Timur.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenLDAP/nss_ldap/pam_ldap
On Tuesday 28 October 2003 23:52, Steve Lee wrote: I have gotten FreeBSD 5.1 to authenticate user remotely ssh ing to the box. They can log in, but when they log in, the system shows their userid instead of the username when you do a ps. this tells me something might be wrong with nss_ldap. but not sure what i am doing wrong. I can do id username which it returns the user information. You need to build FreeBSD with dynamic libraries... It only works under -CURRENT with the WITH_DYNAMICROOT=true option in your make.conf. I think it is supposed to be the default for 5.2-RELEASE. Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newfs by fstab directory name?
Wes Peters wrote:
On Tuesday 28 October 2003 12:05, David O'Brien wrote:
On Mon, Oct 27, 2003 at 01:26:23PM -0800, Wes Peters wrote:
At work we do a lot of dynamic filesystem creation, so we added the
ability to specify the 'special file' argument to newfs via the
fstab mount point directory. Please see the attached patch. If
nobody objects, I'll commit this in a couple of days.
Not objecting, but I don't follow how the change is to be used.
Can you post an example?
Sure. Example from /etc/fstab:
/dev/ad0s1d/tmpufs rw 2 2
/dev/ad0s1f/usrufs rw 2 2
/dev/ad0s1e/varufs rw 2 2
/dev/acd0 /cdrom cd9660 ro,noauto 0 0
/dev/da0s1e/spool ufs rw,noauto 0 0
The disk space on /spool is managed by the application and isn't
guaranteed to be on-line or even existent when the system portion
loads and starts the application. This space is entirely transient
data that doesn't need to be saved across reboots. When the
application starts, it checks to see if /spool is clean; if so it
just mounts it, if not it newfs's it and then mounts it. This
space isn't necessarily always da0s1e but it is always /spool
across different hardware platforms. We prefer to:
newfs /spool
rather than
. {some file full of shell variables describing the hardware}
newfs $SPOOL_PARTITION
because the former is slightly more concise. We had a local patch to do
this in our 4.x code base, but it seemed a general enough change that
others might find it useful as well. I recall ecountering this same
problem at DoBox so it appears to be a general problem for disk-based
appliances, at least if you want to support differing hardware.
This would also be useful for anyone doing any sort of benchmarking
using data sets- I did a code port of LADDIS/SFS to Linux ages ago to do
some NFS/SMB fileserver testing, and I can say, quite a LOT of entirely
temporary data is generated...
Scott
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
buildworld fails with with de_AT locale
hi, a buildworld with a de_AT locale fails in src/lib/libedit, the file fcnl.h that gets created is broken. i found that problem in the mailing list(april this year), and wonder if this has still not been fixed? regards, bernhard ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenLDAP/nss_ldap/pam_ldap
Sorry for my ignorance, i am new to FreeBSD. i have tried to use it in the past ( 2years ago ) but decided to wait to till the nss_ldap support was added for nsswitch so i can use openldap. Now, when you say rebuild, how would i rebuild FreeBSD dynamically, or are you saying to rebuild the application that were statically linked dynamically ? I just checked the FreeBSD site and do not see any release 5.2 Once i can hurl this obsticle, i think FreeBSD might be a viable solution for me. Thanks again for your time. On Wed, 29 Oct 2003, Antoine Jacoutot wrote: On Tuesday 28 October 2003 23:52, Steve Lee wrote: I have gotten FreeBSD 5.1 to authenticate user remotely ssh ing to the box. They can log in, but when they log in, the system shows their userid instead of the username when you do a ps. this tells me something might be wrong with nss_ldap. but not sure what i am doing wrong. I can do id username which it returns the user information. You need to build FreeBSD with dynamic libraries... It only works under -CURRENT with the WITH_DYNAMICROOT=true option in your make.conf. I think it is supposed to be the default for 5.2-RELEASE. Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: page fault in propagate_priority
In the last episode (Oct 28), John Baldwin said:
On 28-Oct-2003 Dan Nelson wrote:
I've gotten the following panic twice in the last few days. I'm
pretty sure truss has something to do with it, since I just started
trussing something when it paniced. No crashdumps unfortunately,
and the system locks up hard so I have to reset it.
The fault address is 0x24 so it looks like a null pointer
dereference of some sort. I've added asserts to propagate_priority
any place a pointer to a structure is dereferenced, so if it
happens again I should have the line number at least.
panic1 was on an Oct 15 kernel, panic2 was on an Oct 27 kernel.
It might help some if you could use gdb -k on your kernel.debug and
do 'l *propagate_priority+0x66' to see where it is dying.
Yes, definitely :)
(gdb) l *propagate_priority+0x66
0xc0575b36 is in propagate_priority (../../../kern/kern_mutex.c:178).
171m = td-td_blocked;
172MPASS(m != NULL);
173
174/*
175 * Check if the thread needs to be moved up on
176 * the blocked chain
177 */
178if (td == TAILQ_FIRST(m-mtx_blocked)) {
179continue;
180}
181
182td1 = TAILQ_PREV(td, threadqueue, td_lockq);
So I guess m was NULL here. If I had INVARIANTS enabled, it would have
paniced at line 172. Time to re-enable those kernel debug options :)
--
Dan Nelson
[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 sparc64/sparc64
TB --- 2003-10-29 00:12:38 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-29 00:12:38 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-10-29 00:12:38 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-10-29 00:14:32 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/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/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include -- cd /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src; MAKEOBJDIRPREFIX=/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64 MACHINE_ARCH=sparc64 MACHINE=sparc64 CPUTYPE= GROFF_BIN_PATH=/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/legacy/usr/bin GROFF_FONT_PATH=/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/legacy/usr/share/groff_font GROFF_TMAC_PATH=/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/legacy/usr/share/tmac DESTDIR=/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386 _SHLIBDIRPREFIX=/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386 INSTALL=sh /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/too! ls/install.sh PATH=/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/legacy/usr/sbin:/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/legacy/usr/bin:/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/legacy/usr/games:/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/sbin:/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/bin:/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/make.i386/make -f Makefile.inc1 SHARED=symlinks p! ar-includes === share/info cd /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/share/info; /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/make.i386/make buildincludes; /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/make.i386/make installincludes === include cd /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/include; /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/make.i386/make buildincludes; /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/make.i386/make installincludes make: don't know how to make strhash.h. Stop *** Error code 2 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/include. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-10-29 00:20:44 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-10-29 00:20:44 - TB --- ERROR: failed to build world TB --- 2003-10-29 00:20:44 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forward: HEADS UP! Default value of ip6_v6only changed
Hajimu UMEMOTO [EMAIL PROTECTED] wrote: Our default of net.inet6.ip6.v6only was off in 4.X, and was changed to on on 5.X to follow NetBSD's practice. This behavior on 5.X breaks RFC2553/3493, and the change was intentional from security consideration. But, NetBSD changed it off by default. OpenBSD's behavior is equivalent to v6only on, and OpenBSD doesn't even provide a knob. Note that the default choice has a major impact on 3rd party software (ports). If we ship with a default of v6only off, then people will not fix software to open two sockets. This in turn means that turning v6only on will break this software. I predict that a good many people will then consider the v6only option to be useless. I understand that itojun would like to see this aspect of RFC2553 amended. I don't know what the prospects of this happening are on the IETF level. -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenLDAP/nss_ldap/pam_ldap
Steve Lee wrote: Sorry for my ignorance, i am new to FreeBSD. i have tried to use it in the past ( 2years ago ) but decided to wait to till the nss_ldap support was added for nsswitch so i can use openldap. Now, when you say rebuild, how would i rebuild FreeBSD dynamically, or are you saying to rebuild the application that were statically linked dynamically ? I just checked the FreeBSD site and do not see any release 5.2 You might do best to sit back and wait a little while and try again. 5.2 is not available yet. I don't know what the current schedule is, exactly, but I'm guessing 3 months or so in the future. To the get the dynamic root capability that Antoine spoke of, you'll need to update your 5.1 FreeBSD to the latest development sources, which can be rather dicey (especially if you're new to FreeBSD). If you want to try it, the docs are here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cutting-edge.html If you decide to try upgrading to -CURRENT to try this feature out, don't hesitate to ask this (or the [EMAIL PROTECTED]) list if you have problems, we'll help. After you do the cvsup, but before doing the make steps, you'll need to create a custom /etc/make.conf to tell FreeBSD to build a dynamic root. Just create the file /etc/make.conf and put the line WITH_DYNAMICROOT=true in it (you can also add other build options to /etc/make.conf per the docs). Then run the make steps in the documentation. Hope this helps. On Wed, 29 Oct 2003, Antoine Jacoutot wrote: On Tuesday 28 October 2003 23:52, Steve Lee wrote: I have gotten FreeBSD 5.1 to authenticate user remotely ssh ing to the box. They can log in, but when they log in, the system shows their userid instead of the username when you do a ps. this tells me something might be wrong with nss_ldap. but not sure what i am doing wrong. I can do id username which it returns the user information. You need to build FreeBSD with dynamic libraries... It only works under -CURRENT with the WITH_DYNAMICROOT=true option in your make.conf. I think it is supposed to be the default for 5.2-RELEASE. Antoine -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic route.c:565
FreeBSD 5.1-CURRENT #3: Tue Oct 28 23:51:52 CET 2003 ~~~cut~~~ recursed on non-recursive lock (sleep mutex) rtentry @ /usr/src/sys/net/route.c:565 first acquired @ /usr/src/sys/net/route.c:182 panic: recurse ~~~cut~~~ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ethercons: ethernet console driver for 5-current
Terry Lambert writes: If Linux is using 0x0666, we should probably pick a different number since we're not wire compatible. Though coming up with a common protocol would be even better. 0x666 hex is 1638 decimal, and it's taken: cnip1638/tcp CableNet Info Protocol cnip1638/udp CableNet Info Protocol Basically, this is just an experimental protocol that's being played with here, and if it ever becomes real, then it will need an IANA protocol number assignment before it's widely deployed. Sure you're not mistaking tcp port numbers for ip protocol numbers now? ;) - arnvid - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
problems with sysinstall
The first one: when I install -current on disk where WinXP on first slice, sysinstall brakes WinXP boot complete. I got 'Missing operation system' everytime. Even I've tried 'fixboot' and reinstall WinXP. Helps only 'dd if=/dev/zero of=/dev/ad0 count=100' and reinstall WinXP on clean disk. When I've installed first -current on first slice and second -current on second slice I got booting only first one. I use grub and either I set root(hd1,0) or root(hd1,1) (yes, it's a second disk) and 'chainloader +1' and 'boot' I've got always first -current boot. Looks like problem with boot sector where hardcoded booting from first slice (?). The second: when I've tried to save results from Fdisk or Label menu I've got the message: 'ERROR: Unable to write data to disk ad0!' Why? I can change slices and partitions only when I boot from CD-ROM. Sem. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic route.c:565
On Tuesday 28 October 2003 04:40 pm, Jiri Mikulas wrote: FreeBSD 5.1-CURRENT #3: Tue Oct 28 23:51:52 CET 2003 ~~~cut~~~ recursed on non-recursive lock (sleep mutex) rtentry @ /usr/src/sys/net/route.c:565 first acquired @ /usr/src/sys/net/route.c:182 panic: recurse ~~~cut~~~ Any chance you can get a stack trace the next time this happens? The LOR by itself is hard to go from... Sam ___ [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?
Harti Brandt wrote: When applying %*d%d to the string 123 the first 'd' format matches the string 123 and the conversion yields the number 123. This is then thrown away because assignment is suppressed. The next format specified finds an EOF condition on the stream so this counts as an input error according to paragraph 9, last sentence of 7.19.6.2. According to to paragraph 18 (The fscanf function returns the value of the macro EOF if an input failure occurs before any conversion. Otherwise, the function returns the number of input items assigned, which can be fewer than provided for, or even zero, in the event of an early matching failure.) the function returns 0, because there was a succesful conversion but no assignment. Paragraph 6 of: http://www.opengroup.org/onlinepubs/007904975/functions/sscanf.html Implies that the lack of characters in the string following the conversion, due to failure in assignment, should result in an Input failure. Note also that stdio.h defines EOF as -1. I think it can be interpreted either way, still. I just had a look at the v7 implementation. In this implementation a suppressed assignment is not counted as a match even if the match was successful. This explains the return of -1 if the first not-suppressed conversion failes. I think changing current behaviour would be a regression with regard to ISO-C (and Posix). I really hate the idea of conforming to Linux; if I wanted to run Linux, I'd run Linux. On the other hand, there's a lot to be said for least common denominator, and it's not like Linux' great idea of updating the select struct timeval here: pretty much everyone has the same behaviour as Linux, which is to say, -1. I think with a suppressed assignment, it's simply not possible to distinguish an error return from an EOF return, which really makes me tempted to say return -1. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Radeon 7500 w/ DRI locking on restart of X
Okay. I won't worry about the messages then. I mentioned the suspend/resume problem only because it actually worked correctly when using option ForcePCIMode; I was shocked when it did and was hoping that your fix for AGP accelerated DRI would pull off the same trick. I should note here that I didn't see any of the panics other people did before your last iteration of the fix. I'm guessing it is because I didn't actually compile the code into my kernel but instead let it build new modules. Any idea why that would make the difference? Sean -Original Message- From: Eric Anholt [EMAIL PROTECTED] Sent: Oct 27, 2003 11:48 PM To: Sean Welch [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Radeon 7500 w/ DRI locking on restart of X On Fri, 2003-10-24 at 11:06, Sean Welch wrote: Eric, I updated my 5.1-RELEASE system to CURRENT dated today at approx. 9:10 CDT to give your changes a try. I had a bit of a fright at first with kernel panics right at the end of the boot sequence but it turned out I had forgotten to disable the ltmdm code -- the kernel module compiled under -RELEASE wasn't friendly to -CURRENT. I've got just a basic install with my custom kernel. I'm using the packages for X from the 5.1-RELEASE cd running twm. Hangs on restart are gone! I restarted about 10 times in a row and ran glxinfo and glxgears each time to verify DRI was still activated and working -- no issues. VT switches are fine (even while running glxgears). The one thing that does not work is resume from acpiconf -s 4 (disk) -- there is a failure to refresh in X and no ability *apparently* to switch to a VT; the keystrokes just generate beeps. Interestingly, the cursor still changed between the different modes when mousing over the xterm and onto the background. Also, Alt-Cntl-Del did work just fine. Suspend/resume is doesn't work well. You might get lucky with the -current DRM with XFree86-4-Server-snap. The only other thing I noticed is that there seems to be a syslog entry for every instance of running glxgears that reads: [MP SAFE] drm0 Is this expected behavior? I noticed that same message (in brackets) in front of each of my disks as they were probed during boot. That printout happens whenever an mpsafe interrupt handler is installed. It gets installed upon initializing the DRI in the server. I don't think any drivers do it more often. It may happen frequently if glxgears is your only app running, in which case you'll get a server regenerate on exit of glxgears. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS file system problem in either stable or current
On Wed, 22 Oct 2003 06:23:20 -0500, Peter Schultz wrote: Dan Strick wrote: There seems to be an inconsistency between release 4.9-RC and 5.1 ufs support. If I fsck the same ufs (type 1 of course) file system on both releases, each claims that the other has left incorrect summary data in the superblock. Presumably only one can be correct. I just don't know which to blame. ... There is no problem AFAIK, you just have to fsck with the matching executable. A lot has changed with FreeBSD 5, spend some time with the -current archive and you will learn more. I'm sure you noticed how your findings are consistently inconsistent. Thanks for the pointer. I eventually found at least part of the discussion in the -current archive. I interpret the discussion as follows: The 5.x UFS1 file system turns out to be slightly incompatible with earlier UFS file systems. The problem is only that it keeps the summary data in a different location in the superblock, but that is sufficient to make the file systems incompatible. There seems to be no interest in making them compatible. Suggestion: if FreeBSD 5 used a different clean flag and FreeBSD 4/5 always cleared the other's clean flag whenever they rewrote a superblock, the file systems would automatically be refscked whenever you switched between operating systems but not after a normal reboot. Dan Strick [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 alpha/alpha
TB --- 2003-10-29 05:00:00 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-29 05:00:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-10-29 05:00:00 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-10-29 05:01:56 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/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/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-10-29 06:04:39 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Oct 29 06:04:39 GMT 2003 Kernel build for GENERIC completed on Wed Oct 29 06:16:29 GMT 2003 TB --- 2003-10-29 06:16:29 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-10-29 06:16:29 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Oct 29 06:16:29 GMT 2003 [...] ext2_linux_balloc.o(.text2+0x4): relocation truncated to fit: BRADDR .text ext2_linux_balloc.o(.text2+0x8): relocation truncated to fit: BRADDR .text ext2_linux_ialloc.o: In function `ext2_free_inode': ext2_linux_ialloc.o(.text+0x5c8): relocation truncated to fit: BRADDR .text2 ext2_linux_ialloc.o: In function `ext2_new_inode': ext2_linux_ialloc.o(.text+0xae4): relocation truncated to fit: BRADDR .text2 ext2_linux_ialloc.o(.text2+0x0): relocation truncated to fit: BRADDR .text ext2_linux_ialloc.o(.text2+0x4): relocation truncated to fit: BRADDR .text *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-10-29 06:27:34 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-10-29 06:27:34 - TB --- ERROR: failed to build lint kernel TB --- 2003-10-29 06:27:34 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
