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: IBMTP-1Gon 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: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Sleep Button 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=0x3febf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,P AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 267780096 (255 MB) avail memory = 253579264 (241 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor 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
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
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: 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
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: 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
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
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=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 268369920 (255 MB) avail memory = 253554688 (241 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTDRSDT 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: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Sleep Button on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_acad0: AC adapter on acpi0 acpi_cmbat0: Control method Battery on acpi0 acpi_cmbat1: Control method Battery on acpi0 pcib0: ACPI Host-PCI bridge 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: ACPI PCI bus on pcib0 agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge 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: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 2.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0x10c0-0x10cf at device 2.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0x1060-0x107f irq 10 at device 2.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller 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: bridge, PCI-unknown at device 2.3 (no driver attached) cbb0: TI1251B PCI-CardBus Bridge mem 0x1000-0x1fff irq 3 at device 3.0 on pci0 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 cbb1: TI1251B PCI-CardBus Bridge mem 0x2000-0x2fff irq 3 at device 3.1 on pci0 cardbus1: CardBus bus on cbb1 pccard1: 16-bit PCCard bus on cbb1 pci0: simple comms at device 6.0 (no driver attached) pci0: multimedia, audio at device 7.0 (no driver attached) atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
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
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
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
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
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
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
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
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
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
subscribe
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
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
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
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: 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
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=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX AMD Features=0x8800SYSCALL,3DNow! real memory = 201310208 (191 MB) avail memory = 189706240 (180 MB) Initializing GEOMetry subsystem K6-family MTRR support enabled (2 registers) npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS P5A 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: CPU on acpi0 pcib0: ACPI Host-PCI bridge 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
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
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
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
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
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: 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
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: 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: [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: [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. 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 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
