Re: [Where] is OpenOffice 1.0.1_4 package available?
On 2002-11-25 08:30 +, [EMAIL PROTECTED] wrote: > > http://projects.imp.ch/openoffice/ > > But, i tried to install that package on my FreeBSD 5.0-CURRENT, well it > went fine, but when i try to run openoffice, i will get a "Segmentation > fault". > Hope you will have more luck. As it says in the README, you need procfs to run it. This dependency will supposedly be removed in the (near?) future. -- Munish Chopra To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Where] is OpenOffice 1.0.1_4 package available?
Hi. Daniel Flickinger <[EMAIL PROTECTED]> schrieb am 25.11.2002, 07:09:09: > package OpenOffice 1.0.1_4 is not available on > snapshot and there is no FreeBSD copy on > OpenOffice.org... > > where does it reside? http://projects.imp.ch/openoffice/ But, i tried to install that package on my FreeBSD 5.0-CURRENT, well it went fine, but when i try to run openoffice, i will get a "Segmentation fault". Hope you will have more luck. asg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Where] is OpenOffice 1.0.1_4 package available?
On 2002-11-25 06:09 +, Daniel Flickinger wrote: > package OpenOffice 1.0.1_4 is not available on > snapshot and there is no FreeBSD copy on > OpenOffice.org... > > where does it reside? http://projects.imp.ch/openoffice/ > > I would compile it, but I would need to reorganize > one of my disks and relabel for the 4 gig partition > stated as required to compile it. > > If mozilla-1.1_1,1 is currently installed, does it need > to be reinstalled with OpenOffice, or should I just go > ahead and upgrade to mozilla-1.1_2,1? Err, I think it'll be fine to just upgrade. Don't shoot me if I'm wrong though. -- Munish Chopra To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Where] is OpenOffice 1.0.1_4 package available?
Hi, you can find it on http://projects.imp.ch/openoffice/. At Mon, 25 Nov 2002 06:09:09 + (GMT), Daniel Flickinger wrote: > > package OpenOffice 1.0.1_4 is not available on > snapshot and there is no FreeBSD copy on > OpenOffice.org... > > where does it reside? > > I would compile it, but I would need to reorganize > one of my disks and relabel for the 4 gig partition > stated as required to compile it. > > If mozilla-1.1_1,1 is currently installed, does it need > to be reinstalled with OpenOffice, or should I just go > ahead and upgrade to mozilla-1.1_2,1? > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Polled mode with device.hints
On Sun, 24 Nov 2002, Marc Fonvieille wrote: > Hello, > > I'm currently updating some part of the Handbook for 5.X, and I need > to know how to put some ports like sio0 or ppc0 in polled mode. > > I did a search and tried some syntax like "0" for the irq etc. but no > way to put something in polled mode or to find an info on it. > > It's a "lack" of device.hints(5) and some devices manual pages :) For sio, polled mode is configured by not creating an irq resource. Leave the irq out of the device line in the config file for RELENG_4, and don''t configure a hint for the irq in 5.x. This might not actually work since PNP or ACPI etc may always create an irq resource. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Update to UFS2 Superblock Format
Some of these fields could usefully be made unsigned others not (for example fs_pendingblocks and fs_pendinginodes). So just going through and making everything unsigned is not the right approach. I will make a pass through and consider changing some of these fields once the tree opens back up, but not at this point in time when we are trying to keep changes to a minimum and do not have time for extensive testing. Kirk McKusick =-=-=-=-= Date: Sun, 24 Nov 2002 21:28:38 -0800 (PST) From: Julian Elischer <[EMAIL PROTECTED]> To: Kirk McKusick <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED], Robert Watson <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: Update to UFS2 Superblock Format In-Reply-To: <[EMAIL PROTECTED]> X-ASK-Info: Whitelist match I do have one question re: UFS2, not specifically about this change however.. I notice that the fields of the disk structure are signed. Wouldn;t it make more sence at this early stage to declare them as unsigned? For example take this snippet from struct fs int64_t fs_size; /* number of blocks in fs */ int64_t fs_dsize; /* number of data blocks in fs */ ufs2_daddr_t fs_csaddr; /* blk addr of cyl grp summary area */ int64_t fs_pendingblocks; /* blocks in process of being freed */ int32_t fs_pendinginodes; /* inodes in process of being freed */ int32_t fs_snapinum[FSMAXSNAP];/* list of snapshot inode numbers */ int32_t fs_avgfilesize;/* expected average file size */ int32_t fs_avgfpdir; /* expected # of files per directory */ int32_t fs_save_cgsize;/* save real cg size to use fs_bsize */ int32_t fs_sparecon32[27]; /* reserved for future constants */ int32_t fs_contigsumsize; /* size of cluster summary array */ int32_t fs_maxsymlinklen; /* max length of an internal symlink */ int32_t fs_old_inodefmt; /* format of on-disk inodes */ u_int64_t fs_maxfilesize; /* maximum representable file size */ int64_t fs_qbmask; /* ~fs_bmask for use with 64-bit size */ int64_t fs_qfmask; /* ~fs_fmask for use with 64-bit size */ int32_t fs_state; /* validate fs_clean field */ int32_t fs_old_postblformat; /* format of positional layout tables */ int32_t fs_old_nrpos; /* number of rotational positions */ How can any of these values be meaningfully -ve? Making them signed just gives fsck a harder time to check the values. (as we saw this week). I have run a system with many of these made unsigned and it made no difference to the system. It was binarily compatible too. i.e it mounted existing filesystemd with no problems. julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld fails on x86
On Mon, 25 Nov 2002, Dan Lukes wrote: > The problem you hit is that the pthread stub functions as declared > within src/lib/libc/gen/_pthread_stubs.c are optimized-out by "-O3" > causing undefined symbol errors later during build. I don't know if it > is gcc's optimiser bug or there is something wrong with _pthread_stubs.c > code, but someone who knows should report and/or repair it. Optimizing away static functions is OK. The problem seems to be just the old one that the references to the static functions are hidden in asms. They are weak references in this case. The kernel had this problem with hidden references to sysctl infrastructure. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Update to UFS2 Superblock Format
I do have one question re: UFS2, not specifically about this change however.. I notice that the fields of the disk structure are signed. Wouldn;t it make more sence at this early stage to declare them as unsigned? For example take this snippet from struct fs int64_t fs_size; /* number of blocks in fs */ int64_t fs_dsize; /* number of data blocks in fs */ ufs2_daddr_t fs_csaddr; /* blk addr of cyl grp summary area */ int64_t fs_pendingblocks; /* blocks in process of being freed */ int32_t fs_pendinginodes; /* inodes in process of being freed */ int32_t fs_snapinum[FSMAXSNAP];/* list of snapshot inode numbers */ int32_t fs_avgfilesize;/* expected average file size */ int32_t fs_avgfpdir; /* expected # of files per directory */ int32_t fs_save_cgsize;/* save real cg size to use fs_bsize */ int32_t fs_sparecon32[27]; /* reserved for future constants */ int32_t fs_contigsumsize; /* size of cluster summary array */ int32_t fs_maxsymlinklen; /* max length of an internal symlink */ int32_t fs_old_inodefmt; /* format of on-disk inodes */ u_int64_t fs_maxfilesize; /* maximum representable file size */ int64_t fs_qbmask; /* ~fs_bmask for use with 64-bit size */ int64_t fs_qfmask; /* ~fs_fmask for use with 64-bit size */ int32_t fs_state; /* validate fs_clean field */ int32_t fs_old_postblformat; /* format of positional layout tables */ int32_t fs_old_nrpos; /* number of rotational positions */ How can any of these values be meaningfully -ve? Making them signed just gives fsck a harder time to check the values. (as we saw this week). I have run a system with many of these made unsigned and it made no difference to the system. It was binarily compatible too. i.e it mounted existing filesystemd with no problems. julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
[ ... Objective C ... ] Chad David wrote: > And I thought this thread was dead :). It just showed up in the inbox last night; it must have been stuck in your mail server. Sorry about that. > I don't really feel a need to "convince". If people are too busy (or > just do not care) to maintain ObjC within FreeBSD, then I'll just have > to do it locally. That's kind of what I was implying would be the correct course of action for a while. 8-). > > I have gotten literally hundreds of patches into FreeBSD by > > ignoring the FreeBSD process, and submitting the patches back > > to the vendor from which FreeBSD obtains the code, so this is > > a success strategy. > > Manipulation is a life stategy :). Anything that works is better than anything that doesn't. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Update to UFS2 Superblock Format
On Tuesday Nov 26th I plan to make an update to the UFS2 superblock. It will not affect UFS1 filesystems so should be generally transparent to most -current users. For those using UFS2 filesystems, the new kernel will update the superblock to the new format the first time that your UFS2 filesystem is mounted read-write. Once updated it will not be able to be mounted by older kernels unless the `zapsb' program (see below) is run to revert it to the old format. The only really noticable problem arises when you are booting from a UFS2 root partition. Here, you must follow the following steps: 1) boot new kernel 2) mount -u / 3) install new bootstrap Once the new kernel has converted the filesystem format for the root partition, the old bootstrap will no longer recognize it, so if you do not have a new bootstrap, you will no longer be able to boot from it. Note that you cannot update to the new bootstrap until the filesystem has been converted as the new bootstrap will not recognize the old superblock format. Again, this change will only affect you if you are using a UFS2 filesystem as your root filesystem. The changes that I plan to apply can be viewed at: http://www.freebsd.org/~mckusick/UFS2_update.diffs The program `zapsb.c' that reverts a UFS2 filesystem to its previous state can be found at: http://www.freebsd.org/~mckusick/zapsb.c If this change is going to cause you undue hardship, please send me mail ([EMAIL PROTECTED]). Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
about GEOM 'geoms' chain question
Hi, Poul-Henning This is my DP2 box's info about 'GEOM' when power on with 'boot -v'. GEOM: new disk da0 GEOM: new disk da1 GEOM: new disk da2 MBR Slice 1 on da0: 80 01 01 00 a5 fe ff 7b 3f 00 00 00 3d a8 da 00 |...{?...=...| [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):123/254/255 s:63 l:14329917 GEOM: Add da0s1, start 32256 length 7336917504 end 7336949759 GEOM: Configure da0c, start 0 length 36701167104 end 36701167103 GEOM: Configure da0e, start 0 length 36701167104 end 36701167103 MBR Slice 1 on da1: 80 01 01 00 a5 fe ff 7b 3f 00 00 00 3d a8 da 00 |...{?...=...| [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):123/254/255 s:63 l:14329917 GEOM: Add da1s1, start 32256 length 7336917504 end 7336949759 GEOM: Configure da1c, start 0 length 36701167104 end 36701167103 MBR Slice 1 on da2: 80 01 01 00 a5 fe bf 7c 3f 00 00 00 fe 25 9c 00 |...|?%..| [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):124/254/191 s:63 l:10233342 GEOM: Add da2s1, start 32256 length 5239471104 end 5239503359 MBR Slice 2 on da2: 80 00 81 7d a5 fe ff ff 3d 26 9c 00 3d 26 9c 00 |...}=&..=&..| [1] f:80 typ:165 s(CHS):125/0/129 e(CHS):255/254/255 s:10233405 l:10233405 GEOM: Add da2s2, start 5239503360 length 5239503360 end 10479006719 GEOM: Configure da0s1a, start 0 length 134217728 end 134217727 GEOM: Configure da0s1b, start 134217728 length 244629504 end 378847231 GEOM: Configure da0s1c, start 0 length 7336917504 end 7336917503 GEOM: Configure da0s1d, start 378847232 length 268435456 end 647282687 GEOM: Configure da0s1e, start 647282688 length 268435456 end 915718143 GEOM: Configure da0s1f, start 915718144 length 6421199360 end 7336917503 GEOM: Configure da1s1a, start 0 length 134217728 end 134217727 GEOM: Configure da1s1b, start 134217728 length 244629504 end 378847231 GEOM: Configure da1s1c, start 0 length 7336917504 end 7336917503 GEOM: Configure da1s1d, start 378847232 length 268435456 end 647282687 GEOM: Configure da1s1e, start 647282688 length 268435456 end 915718143 GEOM: Configure da1s1f, start 915718144 length 6421199360 end 7336917503 GEOM: Configure da2s1c, start 0 length 5239471104 end 5239471103 GEOM: Configure da2s1e, start 0 length 5239471104 end 5239471103 GEOM: Configure da2s2c, start 0 length 5239503360 end 5239503359 GEOM: Configure da2s2e, start 0 length 524288000 end 524287999 I am studying your geom code, let me talk my understanding firstly: 'geoms' is a globe var, from the above info and code, my point is: begin: geoms.tqh_first=NULL, geoms.tqe_prev=&geoms.tqh_first; end: geoms chain is -> -> -> ->->->->->-> -> geoms da0 da1 da2 Mda0 Sda0 Mda1 Sda1 Mda2 Sda2_1 Sda2_2- ^| <- <- <- <-<-<-<-<-<- <- | - - - - - - - - - - - - - - - - - - - - - I am not sure whether this chain is right? If we add a partition 'da0s1h' to the box, when we excute the g_attach() function, it will call redo_rank(). My viewpoint is that the 'DEV'(da0s1h) should been added between 'Sda0' and 'Mda1'. Based my understanding on 'redo_rank', this function will change all the 'rank' of the elements on the chain, right? 'ad1', 'ad2' and their branches is irrelevant to 'ad0', why their rank must change? Thank your help so much! Best Regards Ouyang Kai _ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
On Sun, Nov 24, 2002 at 05:06:05PM -0800, Terry Lambert wrote: > Chad David wrote: > > On Wed, Oct 30, 2002 at 02:19:43AM -0800, David O'Brien wrote: > > > Perhaps because maintaining them in the FreeBSD repo might be the wrong > > > place. To answer your other questiion -- because a change to fix one > > > thing for one person might break things for 10 others. > > > > Which brings us back to my original question... why are ObjC threads > > disabled? I don't much care about my other patches, I just want > > to know who the 10 others are who will break if we enable threads, > > and how to fix that breakage. My minor patches were only posted because > > you asked :). > > > > I do have other patches for thr-posix, but I agree that it would be > > better if they went to gcc, and didn't get stacked locally. And I thought this thread was dead :). > > The answer is that your other patches have not been committed > to gcc, so any changes to gcc, other than configuration, would > have to be maintained in the FreeBSD repository. > > I personally have no problem with this, if it makes Objective C > work where it didn't before, and doesn't impact and other code, > or non-Objective C compilations. But I am not the maintainer, > and David O'Brien is, so it is him you have to convince, since > it is for him you are making extra work. I don't really feel a need to "convince". If people are too busy (or just do not care) to maintain ObjC within FreeBSD, then I'll just have to do it locally. Its actually less work for me to keep my patches to myself, and I'm certainly not trying to volunteer obrien for more work. We are all busy and ObjC is hardly a priority for many. > > It may seem the slow way around, but you should submit your > patches to the gcc folks first, and wait for them to be included, > such that FreeBSD will need only configuration changes. I've done that, but have not yet received any feedback. > > I have gotten literally hundreds of patches into FreeBSD by > ignoring the FreeBSD process, and submitting the patches back > to the vendor from which FreeBSD obtains the code, so this is > a success strategy. Manipulation is a life stategy :). -- Chad David[EMAIL PROTECTED] www.FreeBSD.org [EMAIL PROTECTED] ISSci Inc.Calgary, Alberta Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
reproducable panic with todays current. and xl0 NIC
Hi, I can reproducable panic todays CURRENT by running ifconfig xl0 up (My rl0 NIC works fine). The xl0 NIC works on STABLE. Any help/ideas appreciated. regards tilman polly# ifconfig xl0 up panic: invalid ife->ifm_data (0x6000) in mii_phy_setmedia Debugger("panic") Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db> tr Debugger(c03ce03a,c0459e20,c03afc98,cfc7185c,1) at Debugger+0x54 panic(c03afc98,6000,c0d34f00,c1f2879c,cf52f000) at panic+0xab mii_phy_setmedia(c1f2f540,c1f281a8,c1f2f540,c1f2f6c0,cfc718c8) at mii_phy_setmedia+0x99 exphy_service(c1f2f540,c1f2f6c0,2,cf52f800,c1f28000) at exphy_service+0x56 mii_mediachg(c1f2f6c0,246,cfc71900,c1f2f6c0,c1f28000) at mii_mediachg+0x32 xl_init(c1f28000,c03cc50a,cc,8020690c,c1f28000) at xl_init+0x673 ether_ioctl(c1f28000,8020690c,c2277400,c042d100,c2277400) at ether_ioctl+0x70 xl_ioctl(c1f28000,8020690c,c2277400,0,cfc71b04) at xl_ioctl+0x1e3 in6_ifinit(c1f28000,c2277400,cfc71aac,1,c0256894) at in6_ifinit+0xa5 in6_update_ifa(c1f28000,cfc71a9c,0,c0273ffb,cfc71a50) at in6_update_ifa+0x4aa in6_ifattach_linklocal(c1f28000,0,c0256894,c02d7c00,cfc71b64) at in6_ifattach_linklocal+0x124 in6_ifattach(c1f28000,0,0,0,0) at in6_ifattach+0x208 in6_if_up(c1f28000,c1f2527c) at in6_if_up+0x1b if_route(c1f28000,1,0,cfc71bd0,c02b65a3) at if_route+0x67 if_up(c1f28000,515,0,cfc71c00,8803) at if_up+0x21 ifhwioctl(80206910,c1f28000,cfc71c54,c22952a0,c045cf18) at ifhwioctl+0x273 ifioctl(c209a200,80206910,cfc71c54,c22952a0,c2296418) at ifioctl+0xe4 soo_ioctl(c201e4b0,80206910,cfc71c54,c22c4300,c22952a0) at soo_ioctl+0x19c ioctl(c22952a0,cfc71d10,c03ebf3a,407,3) at ioctl+0x4b6 syscall(2f,2f,2f,3,1) at syscall+0x28e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x804f967, esp = 0xbfbffa5c, ebp = 0xbfbffaa8 --- dmesg: Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Mon Nov 25 03:19:33 CET 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/POLLY Preloaded elf kernel "/boot/kernel/kernel" at 0xc0584000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05840a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 400910740 Hz CPU: AMD-K6(tm) 3D processor (400.91-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bf AMD Features=0x8800 real memory = 201310208 (191 MB) avail memory = 189706240 (180 MB) Initializing GEOMetry subsystem K6-family MTRR support enabled (2 registers) npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard Using $PIR table, 8 entries at 0xc00f0d00 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-safe" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xec08-0xec0b on acpi0 acpi_cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 initial configuration \_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.12.0 \_SB_.LNKB irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.12.1 \_SB_.LNKC irq 0: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.12.2 \_SB_.LNKD irq 9: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.12.3 \_SB_.LNKB irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.11.0 \_SB_.LNKC irq 0: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.11.1 \_SB_.LNKD irq 9: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.11.2 \_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.11.3 \_SB_.LNKC irq 0: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.10.0 \_SB_.LNKD irq 9: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.10.1 \_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.10.2 \_SB_.LNKB irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.10.3 \_SB_.LNKD irq 9: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.9.0 \_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.9.1 \_SB_.LNKB irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.9.2 \_SB_.LNKC irq 0: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.9.3 \_SB_.LNKD irq 9: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.13.0 \_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.13.1 \_SB_.LNKB irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.13.2 \_SB_.LNKC irq 0: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.13.3 \_SB_.LNKE irq 0: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.2.0 \_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.2.1 \_SB_.LNKB irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.2.2 \_SB_.LNKC irq 0: [ 1 3 4 5 6 7 9 10 11 12 14
Re: OpenOffice and FreeBSD 5.0-Current
On 2002-11-24 23:33 +, Yann Berthier wrote: > On Sun, 24 Nov 2002, a wrote: > > > Hi > > > > I am running FreeBSD 5.0-CURRENT (22 Nov 22:52 CET) > > I did a download of a precompiled OpenOffice 1.0.1_4 package (it is for FreeBSD >Current) and installed that one with "pkg_add". > > Ok, that one went fine. > > But after that, i was not able to start OpenOffice. I get an Segmentation fault, >and thats it. > >Have you procfs mounted ? if not you should: this is mandatory to use >openoffice (/proc is not mounted by default in the -current land) > Yes, as the README says, procfs is necessary for now. Is there any update on when this dependency will be kicked out? Martin? -- Munish Chopra To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld fails on x86
On Friday 22 November 2002 09.03, David Holm wrote: > Hi, > I've tried to build world since yesterday, doing cvsup's inbetween hopi= ng > for a fix. But it always fails on bin/cat with a bunch of unresolvable > pthread symbols at linking. I have cleared out my old /usr/obj. > cat cat.o > /usr/obj/usr/src/i386/usr/lib/libc.a(atexit.o): In function `atexit': > atexit.o(.text+0xc7): undefined reference to `_pthread_mutex_unlock' > atexit.o(.text+0xd8): undefined reference to `_pthread_mutex_lock' > atexit.o(.text+0xe8): undefined reference to `_pthread_mutex_unlock' > atexit.o(.text+0x109): undefined reference to `_pthread_mutex_lock' > atexit.o(.text+0x11a): undefined reference to [EMAIL PROTECTED] wrote, On 11/22/02 11:52: > Ok, > found it. I forgot to disable my CFLAGS for ports ;). Well, we shouldn't use optimisation (-O3) during buildworlds as it's not recommended. On the oposite side, we should try to produce the optimisable source code. The problem you hit is that the pthread stub functions as declared within src/lib/libc/gen/_pthread_stubs.c are optimized-out by "-O3" causing undefined symbol errors later during build. I don't know if it is gcc's optimiser bug or there is something wrong with _pthread_stubs.c code, but someone who knows should report and/or repair it. Dan -- Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206 root of FIONet, KolejNET, webmaster of www.freebsd.cz AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
Chad David wrote: > On Wed, Oct 30, 2002 at 02:19:43AM -0800, David O'Brien wrote: > > Perhaps because maintaining them in the FreeBSD repo might be the wrong > > place. To answer your other questiion -- because a change to fix one > > thing for one person might break things for 10 others. > > Which brings us back to my original question... why are ObjC threads > disabled? I don't much care about my other patches, I just want > to know who the 10 others are who will break if we enable threads, > and how to fix that breakage. My minor patches were only posted because > you asked :). > > I do have other patches for thr-posix, but I agree that it would be > better if they went to gcc, and didn't get stacked locally. The answer is that your other patches have not been committed to gcc, so any changes to gcc, other than configuration, would have to be maintained in the FreeBSD repository. I personally have no problem with this, if it makes Objective C work where it didn't before, and doesn't impact and other code, or non-Objective C compilations. But I am not the maintainer, and David O'Brien is, so it is him you have to convince, since it is for him you are making extra work. It may seem the slow way around, but you should submit your patches to the gcc folks first, and wait for them to be included, such that FreeBSD will need only configuration changes. I have gotten literally hundreds of patches into FreeBSD by ignoring the FreeBSD process, and submitting the patches back to the vendor from which FreeBSD obtains the code, so this is a success strategy. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
I'm impressed, but ...
Hi guys - I accidently upgraded my workstation to -CURRENT over the weekend (forgot a tag=RELENG_4 in my supfile and let it cook). It being a workstation and containing no critical data, I decided to just stick with it and give it a go. The machine's been running for a day and a bit now, and it appears to be quite stable, but there's a couple of things worrying me. I'd be happy to help analyse the problems further if someone tells me how :-) 1. When I boot my machine, it gives me the following messages: | [...] | vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 | unknown: can't assign resources (port) | unknown: can't assign resources (irq) | unknown: can't assign resources (port) | unknown: can't assign resources (port) | unknown: can't assign resources (port) | unknown: can't assign resources (port) | unknown: can't assign resources (port) | Timecounters tick every 10.000 msec | ahc0: Someone reset channel A | [...] All my hardware (the stuff I've tested anyway) appears to work. Any idea which device is being unknown, or how I could find out? 2. This one's the most irritating. I use Mutt as my mailclient using Maildirs for storage. It occasionally happens that Mutt just 'hangs' reading a directory, and there's no way for me to kill it. Ps axl shows it as being in state Ds or Ds+ and blocked by ufs. 3. I can't seem to restart my machine properly. This might be related to the above, as the only reason for me to restart the machine is the fact that I can't kill Mutt however much I try, and really would like to read my mail. It will sync disks and say 'done', but then it just sits there doing nothing until I flip the power-switch. As I said, I'm happy to help analyse and debug these issues, but I don't know where to look :-) Thanks :-) - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. The only way to make up for being lost is to make record time while you are lost. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sshd and lastlog permissions
On Sun, Nov 24, 2002 at 05:09:19PM -0500, John Von Essen wrote: > Like I said, this is a fresh install with no config changes. Any ideas as > to what is going on? This is a known problem. Kris msg47387/pgp0.pgp Description: PGP signature
using 5.0-RELEASE
Hi, just a question to the possibilies using 5.0-RELEASE. In the "early adopters guide" (chapter 1) it's written, that 5.0-RELEASE should be as stable as possible to "getting a large number of users to test". But if it's not recommented to use it in production environments, what test results do you expect? Wouldn't it better to say: 5.0-CURRENT is not recommented for production environments (as it's said 'bout using -STABLE blindly), 5.0-RELEASE may be used in non-critical environment, but heavily use of backup tool is recommented? I know many companies located in Halle (where we resides) which are using linux, not because it's more stable but because SuSE tells: it's 8.0 and we tested and it's great. The simply believe the recommendation of SuSE (or whoever) and if sth. fails, they think: Hmm - nothing paid, who really cares? And if I take a look to may AIX box, FBSD 5.0-CURRENT is more stable than my AIX 4.3.3, because of the ports tree (in AIX I must do all by myself). Bye, Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: <[EMAIL PROTECTED]> Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenOffice and FreeBSD 5.0-Current
On Sun, 24 Nov 2002, a wrote: > Hi > > I am running FreeBSD 5.0-CURRENT (22 Nov 22:52 CET) > I did a download of a precompiled OpenOffice 1.0.1_4 package (it is for FreeBSD >Current) and installed that one with "pkg_add". > Ok, that one went fine. > But after that, i was not able to start OpenOffice. I get an Segmentation fault, and >thats it. Have you procfs mounted ? if not you should: this is mandatory to use openoffice (/proc is not mounted by default in the -current land) Regards, - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenOffice and FreeBSD 5.0-Current
a wrote: Hi I am running FreeBSD 5.0-CURRENT (22 Nov 22:52 CET) I did a download of a precompiled OpenOffice 1.0.1_4 package (it is for FreeBSD Current) and installed that one with "pkg_add". Ok, that one went fine. But after that, i was not able to start OpenOffice. I get an Segmentation fault, and thats it. So, it is a common problem, or just a problem with my machine (Acer Laptop 512T, 160 MB RAM, 366 Celeron CPU). So, i cant install OpenOffice from the ports, my machine is to slow, and i dont have that much diskspace. asg Maybe others know what's wrong. Can you try to start open office from a terminal and when it's dumping core again, start it using $ gdb -c core [openoffice] and generate a back trace and send them to the list (and maybe to the open office guys). But wait a few minutes - maybe someone other knows what really helps. Bye, jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: <[EMAIL PROTECTED]> Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
OpenOffice and FreeBSD 5.0-Current
Hi I am running FreeBSD 5.0-CURRENT (22 Nov 22:52 CET) I did a download of a precompiled OpenOffice 1.0.1_4 package (it is for FreeBSD Current) and installed that one with "pkg_add". Ok, that one went fine. But after that, i was not able to start OpenOffice. I get an Segmentation fault, and thats it. So, it is a common problem, or just a problem with my machine (Acer Laptop 512T, 160 MB RAM, 366 Celeron CPU). So, i cant install OpenOffice from the ports, my machine is to slow, and i dont have that much diskspace. asg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sshd and lastlog permissions
Maybe I am missing something, but... On my -CURRENT box (current as of last night). After a fresh install (no tinkering with settings), when I use ssh to connect from a remote host, I get the following error: sshd[pid]: /var/log/lastlog: Permission denied Also, the following processes are running: root PID ... ?? I 0:00.xx sshd: user [priv] (sshd) user PID ... ?? I 0:00.xx sshd: user@ttyp0 (sshd) On my 4.7-STABLE box, when I connect with ssh, I get the following process: root PID ... ?? I 0:00.xx sshd: user@ttyp0 (sshd) So obviously, there is this difference in ownership of sshd: user@ttyp0 (sshd). Like I said, this is a fresh install with no config changes. Any ideas as to what is going on? -John Von Essen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf header bloat ?
On Sun, 24 Nov 2002, Andrew Gallatin wrote: > > If we're going to nitpick the mbuf system, a much, much worse problem > is that you cannot allocate an mbuf chain w/o holding Giant, which > stems from the mbuf system eventually calling kmem_malloc(). This > effectively prevents any network driver from being giant-free. When > mbufs are low, mb_alloc() calls mb_pop_cont(). This, in turn, calls > kmem_malloc() which requires Giant... > > The mbuf system calls malloc in other ways too. The first time you > use a cluster, m_ext.ext_ref_cnt is malloc()'ed, and malloc is called > when the mbuf map is expanded... I assume malloc will eventually > call kmem_malloc(), leading to the same locking problems. > > I know that both tru64 and aix just malloc their mbufs. I think we tied that and went back to a separate allocator, but I have no idea why.. maybe someone else can enlighten me.. > > Drew > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf header bloat ?
Julian Elischer writes: > > > On Sat, 23 Nov 2002, Andrew Gallatin wrote: > > > > > As you eloquently state, there are a number of tradeoffs involved. On > > a 64-bit platform, 99% of users are paying 40 bytes/pkt for something > > that they will never use. On x86, 99.99% of users are paying 20 > > bytes/pkt for a feature they will never use. At least a signifigant > > fraction of nics make use of csum offloading (xl, ti, bge, em, myri). > > > the downside to the TAG stuff is that you need to allocate a separate > tag storage, and that is a malloc.. which has certain characteristics > vs the mbuf allocator. We have a special allocator for mbufs for a > reason. (I'm not sure how many of the original reasons still apply). > so it's worth looking at whether malloc is a suitable method of > allocating all that stuff before we take it out of the mbuf. > If we're going to nitpick the mbuf system, a much, much worse problem is that you cannot allocate an mbuf chain w/o holding Giant, which stems from the mbuf system eventually calling kmem_malloc(). This effectively prevents any network driver from being giant-free. When mbufs are low, mb_alloc() calls mb_pop_cont(). This, in turn, calls kmem_malloc() which requires Giant... The mbuf system calls malloc in other ways too. The first time you use a cluster, m_ext.ext_ref_cnt is malloc()'ed, and malloc is called when the mbuf map is expanded... I assume malloc will eventually call kmem_malloc(), leading to the same locking problems. I know that both tru64 and aix just malloc their mbufs. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
Sun Nov 24 13:00:02 PST 2002 ? sys/alpha/conf/LINT U sys/boot/efi/loader/main.c U sys/conf/options.ia64 U sys/ia64/ia64/machdep.c U sys/ia64/ia64/mca.c U sys/ia64/include/cpu.h cvs [update aborted]: cannot make directory include: File exists To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
UFS2 and disklabel fstype
Hello there, As UFS2 is not backward compatible at all, I wonder why the old fstype in disklabel is being kept: #size offsetfstype [fsize bsize bps/cpg] a: 102400004.2BSD 2048 16384 64008 # (Cyl.0 - 63*) c: 186103260unused0 0 # (Cyl.0 - 1158*) d: 17586326 10240004.2BSD 2048 16384 28552 # (Cyl. 63*- 1158*) This is a disklabel of my newly installed -DP2 system. Partition "a" is formatted as UFS, while "d" is UFS2. I wonder, is there any reason for not distincting these filesystems on disklabel level? Would specyfying different fstype for UFS2 (whatever you call it then) break something? It's not a real problem, but in some cases may confuse someone. I've done some googling, but didn't find any discussion on this topic, so I'm writing here. -- -- wrzask --= v =-- Winfried --=-- GG# 3838383 --=-- JS500-RIPE -- -- [EMAIL PROTECTED] --- [EMAIL PROTECTED] --===-- http://violent.dream.vg/ --- --=< Ride the wild wind - push the envelope, don't sit on the fence, --- -- Ride the wild wind - live life on the razor's edge! >=-- Queen -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problems with FreeBSD 5.0-DP2
Hi! I don't get very far when trying FreeBSD 5.0-DP2. Everything starts up OK but when trying to write down my partition information the box freezes... After awhile it reboots. The box is a Dual AMD 1400+ MP, with 512 DDR RAM, IDE 40 GB (IBM). Tyan Tiger mothboard and a Intel 107100 NIC (fxp). FreeBSD 4.7 worked perfectly fine on this box! Since I'm not subscribing to freebsd-current all questions should be Cc'ed to me... / Stefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI error messages
Hackers, on yesterday's -current i see ACPI-0432: *** Error: Handler for [EmbeddedControl] returned AE_ERROR ACPI-1354: *** Error: Method execution failed, AE_ERROR this is IBM ThinkPad 390x laptop. dmesg and acpidump are attached. any ideas? thanks max Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #2: Sat Nov 23 22:45:21 PST 2002 root@:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc06ac000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc06ac0a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 447692565 Hz CPU: Pentium III/Pentium III Xeon/Celeron (447.69-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff real memory = 268369920 (255 MB) avail memory = 253554688 (241 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard Using $PIR table, 8 entries at 0xc00fdf40 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-safe" frequency 3579545 Hz can't fetch resources for \\_SB_.PCI0.ISA_.FIR_ - AE_AML_INVALID_RESOURCE_TYPE acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.PCI0.ISA_.LNKD irq 10: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.2.3 \\_SB_.PCI0.ISA_.LNKA irq 3: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.3.0 \\_SB_.PCI0.ISA_.LNKA irq 3: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.3.1 \\_SB_.PCI0.ISA_.LNKA irq 3: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.4.0 \\_SB_.PCI0.ISA_.LNKC irq 7: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.4.1 \\_SB_.PCI0.ISA_.LNKC irq 7: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.6.0 \\_SB_.PCI0.ISA_.LNKB irq 5: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.7.0 before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - \\_SB_.PCI0.ISA_.LNKD irq 10: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.2.3 \\_SB_.PCI0.ISA_.LNKA irq 3: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.3.0 \\_SB_.PCI0.ISA_.LNKA irq 3: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.3.1 \\_SB_.PCI0.ISA_.LNKA irq 3: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.4.0 \\_SB_.PCI0.ISA_.LNKC irq 7: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.4.1 \\_SB_.PCI0.ISA_.LNKC irq 7: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.6.0 \\_SB_.PCI0.ISA_.LNKB irq 5: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.7.0 pci0: on pcib0 agp0: mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 initial configuration \\_SB_.PCI0.ISA_.LNKA irq 3: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 1.0.0 before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - \\_SB_.PCI0.ISA_.LNKA irq 3: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 1.0.0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 2.0 on pci0 isa0: on isab0 atapci0: port 0x10c0-0x10cf at device 2.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0x1060-0x107f irq 10 at device 2.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 2.3 (no driver attached) cbb0: mem 0x1000-0x1fff irq 3 at device 3.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: mem 0x2000-0x2fff irq 3 at device 3.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pci0: at device 6.0 (no driver attached) pci0: at device 7.0 (no driver attached) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 acpi_ec0: port 0x66,0x62 on acpi0 orm0: at iomem 0xc-0xcbfff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec acpi_cpu: CPU throttling
Polled mode with device.hints
Hello, I'm currently updating some part of the Handbook for 5.X, and I need to know how to put some ports like sio0 or ppc0 in polled mode. I did a search and tried some syntax like "0" for the irq etc. but no way to put something in polled mode or to find an info on it. It's a "lack" of device.hints(5) and some devices manual pages :) Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.2.1 release import?
On Sat, Nov 23, 2002 at 10:06:52PM -0800, Terry Lambert <[EMAIL PROTECTED]> wrote: > > > But who will bell the cat? I vote for Snuffles. > > > > Don't understand. Some inside joke or something based on US centric > > TV? What are you trying to tell me? Remember I'm not native. > > 1930's/1940's cartoon character, "Snuffles, the mouse". Was in > a lot of cartoons. Played the "Why?" game that children play, > to the annoyance of his chosen victim, and the amusement of the > people. > > One story was a script based on the Aesop's Fable about belling > the cat. Here is a short reprise: > > 1)All of the mice decided that Something Needs To Be Done > About The Cat(tm) > 2)They had a big meeting > 3)Finally, one mouse, who no one listened to very often, > suggests that they put a bell around its neck, so they > will be able to tell whic it's coming, and escape, to > live in peace, in their mousey ways > 4)No one wants to bell the cat; it's a perfect idea, which > lacks for implementation, and there are no potential > implementors to take the risk on behalf of the group > > In the cartoon version, at this point, the mouse who made the > suggestion is volunteered by his "comrades" for the deadly duty > ("Snuffles"). Heh, OK :-) I'm also quite sure that gcc3.2.1 release will not find it's way to 5.0 and understand the technical points taken to guard this position. That's why I put "possibility and IMHO" at the end of my sentence. A patch will be good to have nevertheless, so we can test things out even if it's not going to 5.0-RELEASE. So this boils down to simple question of time, necessity and willingness to do the patch. Let's end this thread. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kde crashes in _thread_kern_scheduler () from /usr/lib/libc_r.so.5
Hi, Fairly new current system. Brand new KDE built from ports. Crashes immediately I press the "k" start button. Kcrash reports: 0x28f37893 in poll () from /usr/lib/libc.so.5 #0 0x28f37893 in poll () from /usr/lib/libc.so.5 #1 0x28ee1221 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5 #2 0x28ee0c20 in _thread_kern_scheduler () from /usr/lib/libc_r.so.5 #3 0xd0d0d0d0 in ?? () #4 0x0001 in ?? () #5 0x28cc in ?? () System details: tbird:~> uname -a FreeBSD tbird.home.lan 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Fri Nov 22 18:16:30 EST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 tbird:~> pkg_info | egrep "kde|qt" kde-3.0.5 The "meta-port" for KDE kdeartwork-3.0.4Additional themes, sounds, wallpapers and window styles for kdebase-3.0.5 Base modules for the KDE integrated X11 desktop kdegames-3.0.4 Games for the KDE integrated X11 desktop kdegraphics-3.0.4 Graphics utilities for the KDE3 integrated X11 desktop kdelibs-3.0.5_1 Libraries for KDE kdemultimedia-3.0.4 Multimedia utilities for the KDE integrated X11 desktop kdenetwork-3.0.5Network modules for KDE3 kdeutils-3.0.4_1Utilities for the KDE integrated X11 desktop qt-3.0.5_5 A C++ X GUI toolkit Any ideas as to obvious places to look? Regards/Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installworld and stale {include,lib} fun
> I've never ever needed to cleanup lib. Are you sure that's absolutely > required? Also, for upgrading from 4.x already has the bit about > nuking /usr/include/gcc. I've never needed to do more. What > libraries are bad that need to be removed, specifically? Or is this > just paranoia inspired? Kerberos/Heimdal have sometimes failed with old libraries. Also, ports can find wrong libraries at configure time and behave strangely. M -- Mark Murray Beware! I'm umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
Sun Nov 24 01:00:03 PST 2002 ... U release/doc/en_US.ISO8859-1/hardware/alpha/proc-alpha.sgml ? sys/alpha/conf/LINT U sys/cam/scsi/scsi_cd.c U sys/cam/scsi/scsi_da.c U sys/dev/acpica/acpi.c U sys/dev/ata/atapi-cd.c U sys/dev/pccbb/pccbb.c U sys/dev/pccbb/pccbbreg.h U sys/i386/acpica/acpi_wakeup.c cvs [update aborted]: cannot make directory include: File exists To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf header bloat ?
On Sat, 23 Nov 2002, Andrew Gallatin wrote: > > As you eloquently state, there are a number of tradeoffs involved. On > a 64-bit platform, 99% of users are paying 40 bytes/pkt for something > that they will never use. On x86, 99.99% of users are paying 20 > bytes/pkt for a feature they will never use. At least a signifigant > fraction of nics make use of csum offloading (xl, ti, bge, em, myri). the downside to the TAG stuff is that you need to allocate a separate tag storage, and that is a malloc.. which has certain characteristics vs the mbuf allocator. We have a special allocator for mbufs for a reason. (I'm not sure how many of the original reasons still apply). so it's worth looking at whether malloc is a suitable method of allocating all that stuff before we take it out of the mbuf. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI Errors - IBM Thinkpad A31p
Hi Folks, I see this error while booting into BSD and I presume this might be the problem that acpi on my TP does not work. The errors are something like this. acpi0: on motherboard Using $PIR table, 14 entries at 0xc00fdeb0 ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 Dmesg on the box FreeBSD 5.0-CURRENT #0: Fri Nov 22 17:37:35 IST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0618000. Preloaded elf module "/boot/kernel/snd_ich.ko" at 0xc06180a8. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc0618154. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0618200. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1198990668 Hz CPU: Pentium 4 (1198.99-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febf9ff real memory = 267780096 (255 MB) avail memory = 253579264 (241 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface uname -a FreeBSD tango 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Fri Nov 22 17:37:35 IST 2002 root@tango:/usr/obj/usr/src/sys/GENERIC i386 Any fix for this ? I am unable to use ACPI in FBSD. TIA Regards Sid -- The church is near but the road is icy; the bar is far away but I will walk carefully. -- Russian Proverb Sid Carter - http://khader.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message