Re: ext2fs and NFS exporting wackyness
On Thu, 28 Nov 2002, Maxime Henrion wrote: > Emiel Kollof wrote: > > * Emiel Kollof ([EMAIL PROTECTED]) wrote: > > > > There were stupid mistakes in this patch. Can you try this one instead ? > > > > > > Yes, this one seems to work. > > > > Hold on.. now remote hosts _see_ the ext2fs share, but mounting will not > > work. Yes it will mount without failing, but accessing won't work. > > > > >From a remote host (A FreeBSD STABLE one): > > > > [root@tiamat]:/root> mount 10.0.0.11:/storage /mnt/azazel > > [root@tiamat]:/root> cd /mnt/azazel > > /mnt/azazel: Input/output error. > > This looks like a totally different problem. I'm not sure if NFS > exported ext2fs partitions actually ever work. Bruce, any input on this > one ? ISTR them working. There were a lot of problems with getdirentries() but I thought that they were fixed. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ext2fs and NFS exporting wackyness
On Thu, 28 Nov 2002, Maxime Henrion wrote:
> Maxime Henrion wrote:
> > Emiel Kollof wrote:
> > > Can this be patched by doing some subtitutions in the files that use the
> > > "old" mount syscall? Or is it more hairy than that?
> >
> > Can you try the attached patch and tell me if it works ?
>
> There were stupid mistakes in this patch. Can you try this one instead ?
Urk. The patch demonstrates the full awfulness of the nmount(2) interface.
nmount() requires constructing a huge iov instead of using some simple
pointers and flags. E.g.:
% @@ -1812,8 +1854,26 @@ do_mount(ep, grp, exflags, anoncrp, dirp
%* Also, needs to know how to export all types of local
%* exportable filesystems and not just "ufs".
%*/
% - while (mount(fsb->f_fstypename, dirp,
% - fsb->f_flags | MNT_UPDATE, (caddr_t)&args) < 0) {
% +retry:
% + if (do_nmount) {
% + iov[0].iov_base = "fstype";
% + iov[0].iov_len = strlen(iov[0].iov_base) + 1;
% + iov[1].iov_base = fsb->f_fstypename;
% + iov[1].iov_len = strlen(iov[1].iov_base) + 1;
% + iov[2].iov_base = "fspath";
% + iov[2].iov_len = strlen(iov[2].iov_base) + 1;
% + iov[3].iov_base = dirp;
% + iov[3].iov_len = strlen(iov[3].iov_base) + 1;
% + iov[4].iov_base = "export";
% + iov[4].iov_len = strlen(iov[4].iov_base) + 1;
% + iov[5].iov_base = eap;
% + iov[5].iov_len = sizeof(*eap);
% + error = nmount(iov, 6, fsb->f_flags | MNT_UPDATE);
% + } else {
% + error = mount(fsb->f_fstypename, dirp,
% + fsb->f_flags | MNT_UPDATE, &args);
% + }
% + if (error) {
% if (cp)
% *cp-- = savedc;
% else
This change breaks mounting of ext2fs using old kernels and a current mountd
in mountd like it has already been broken in mount_ext2fs, since there is
no fallback to using the old mount.
This patch also introduces a style bug: a weird continuation indent of 12
instead of the KNF continuation indent of 4 for the mount() lines.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: C++ Issue On -CURRENT
Cy Schubert - CITS Open Systems Group wrote: > > does the problem still occur if you add in 'using namespace std'? > > Thanks. That also fixed it. Yeah. Just remember that the "standard" namespace isn't. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ksetest program cause the system crash!
Hi, everybody, Have somebody use the "/usr/src/tools/KSE/ksetest/ksetest"? I want to test about "KSE". I cvsuped my box a few days ago. my "kern_thread.c" version is 1.66. When I use the ksetest, the box is crashed. the information as follow: Current# ./ksetest main() : 0x804c000 eip -> 0x280ae973 uts() at : 0x8048e40 uts stack at : 0x814d000 - 0x8155000 main() : 0x804c400 eip -> 0x280ae973 uts() at : 0x8048e40 uts stack at : 0x8255000 - 0x825d000 thread_start() : 0x804c800 804c800 thread_start() : 0x826d000 826d000 kse_create() -> 0 kse_create() -> 0 main() : 0x826d800 eip -> 0x280ae973 uts() at : 0x8048e40 uts stack at : 0x837e000 - 0x8386000 main() : 0x826dc00 eip -> 0x280ae973 uts() at : 0x8048e40 uts stack at : 0x8486000 - 0x848e000 thread_start() : 0x848e000 848e000 thread_start() : 0x848e800 848e800 thread_start() : 0x84af000 84af000 kse_create() -> 0 A panic: deallocate_dependencies: Un Where can I search the example programs or documents about "KSE"? Thank everybody! 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: DP2 + Thinkpad 660X = PC Card card activation failed
Try adding hw.pccard.cis_debug=1 to /boot/loader.conf and let me know the results. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DP2 + Thinkpad 660X = PC Card card activation failed
My Thinkpad 600X doesn't recognize any PC cards since I installed 5.0-DP2. PC cards worked fine on it under -CURRENT back in February (before the NEWCARD merge and rc_ng) and they worked fine under -STABLE since then. I haven't been tracking -CURRENT since February, so maybe I missed something important or maybe there's something about the 600X that makes it fail with DP2? Dmesg shows several reassuring messages early in the boot sequence: cbb0: mem 0x50103000-0x50103fff irq 11 at device 2.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: mem 0x50102000-0x50102fff irq 11 at device 2.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 But later, bad news: pccard0: Card has no functions! cbb0: PC Card card activation failed I've searched the mailing lists and have found no reports of similar problems so it may be a configuration error on my end. I do recall seeing something about cbb.memory_start being at a non-standard address on the 600X. I'm unclear on the relationship between devd and pccardd. I gather that there's no need for pccardd now that devd is here, but I'd appreciate some clarification on this. How should rc.conf look on a laptop these days? The full boot message sequence follows the signature. All advice appreciated. Thanks, Bob Nov 30 13:20:56 OutBound syslogd: kernel boot file is /boot/kernel/kernel Nov 30 13:20:56 OutBound kernel: Copyright (c) 1992-2002 The FreeBSD Project. Nov 30 13:20:56 OutBound kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Nov 30 13:20:56 OutBound kernel: The Regents of the University of California. All rights reserved. Nov 30 13:20:56 OutBound kernel: FreeBSD 5.0-DP2 #1: Sat Nov 16 13:38:33 GMT 2002 Nov 30 13:20:56 OutBound kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Nov 30 13:20:56 OutBound kernel: Preloaded elf kernel "/boot/kernel/kernel" at 0xc0679000. Nov 30 13:20:56 OutBound kernel: Preloaded elf module "/boot/kernel/acpi.ko" at 0xc06790a8. Nov 30 13:20:56 OutBound kernel: Timecounter "i8254" frequency 1193182 Hz Nov 30 13:20:56 OutBound kernel: Timecounter "TSC" frequency 498274020 Hz Nov 30 13:20:56 OutBound kernel: CPU: Pentium III/Pentium III Xeon/Celeron (498.27-MHz 686-class CPU) Nov 30 13:20:56 OutBound kernel: Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Nov 30 13:20:56 OutBound kernel: Features=0x383f9ff Nov 30 13:20:56 OutBound kernel: real memory = 268238848 (255 MB) Nov 30 13:20:56 OutBound kernel: avail memory = 253636608 (241 MB) Nov 30 13:20:56 OutBound kernel: Initializing GEOMetry subsystem Nov 30 13:20:56 OutBound kernel: Pentium Pro MTRR support enabled Nov 30 13:20:56 OutBound kernel: npx0: on motherboard Nov 30 13:20:56 OutBound kernel: npx0: INT 16 interface Nov 30 13:20:56 OutBound kernel: acpi0: on motherboard Nov 30 13:20:56 OutBound kernel: Using $PIR table, 6 entries at 0xc00f9d70 Nov 30 13:20:56 OutBound kernel: acpi0: power button is handled as a fixed feature programming model. Nov 30 13:20:56 OutBound kernel: Timecounter "ACPI-safe" frequency 3579545 Hz Nov 30 13:20:56 OutBound kernel: ACPI-0351: *** Error: Could not install PciConfig handler for PCI0, AE_ALREADY_EXISTS Nov 30 13:20:56 OutBound kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0xef08-0xef0b on acpi0 Nov 30 13:20:56 OutBound kernel: acpi_cpu0: on acpi0 Nov 30 13:20:56 OutBound kernel: acpi_tz0: on acpi0 Nov 30 13:20:56 OutBound kernel: acpi_tz1: on acpi0 Nov 30 13:20:56 OutBound kernel: acpi_tz2: on acpi0 Nov 30 13:20:56 OutBound kernel: acpi_tz3: on acpi0 Nov 30 13:20:56 OutBound kernel: acpi_lid0: on acpi0 Nov 30 13:20:56 OutBound kernel: acpi_button0: on acpi0 Nov 30 13:20:56 OutBound kernel: pcib0: port 0xcf8-0xcff on acpi0 Nov 30 13:20:56 OutBound kernel: initial configuration Nov 30 13:20:56 OutBound kernel: \_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.7.3 Nov 30 13:20:56 OutBound kernel: \_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.2.0 Nov 30 13:20:56 OutBound kernel: \_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.2.1 Nov 30 13:20:56 OutBound kernel: \_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.3.0 Nov 30 13:20:56 OutBound kernel: \_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.5.0 Nov 30 13:20:56 OutBound kernel: \_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.6.0 Nov 30 13:20:56 OutBound kernel: before setting priority for links Nov 30 13:20:56 OutBound kernel: \_SB_.LNKD: Nov 30 13:20:56 OutBound kernel: interrupts: 3 4 5 6 7 9 1011121415 Nov 30 13:20:56 OutBound kernel: penalty: 1660 1660 660 1660 1660 660 660 660 1660 10660 10660 Nov 30 13:20:56 OutBound kernel: references:1 Nov 30 13:20:56 OutBound ke
Re: The great perl script rewrite - progress report
[to follow-up on what I said in a different thread...] On my 5.0-dp2 system, if I ignore /usr/local and /usr/ports, it looks like the following files installed by -dp2 are perl scripts: /usr/bin/mmroff /usr/bin/afmtodit /usr/sbin/adduser /usr/sbin/rmuser /usr/share/examples/cvs/contrib/clmerge /usr/share/examples/cvs/contrib/cln_hist /usr/share/examples/cvs/contrib/commit_prep /usr/share/examples/cvs/contrib/cvs_acls /usr/share/examples/cvs/contrib/log /usr/share/examples/cvs/contrib/log_accum /usr/share/examples/cvs/contrib/mfpipe /usr/share/examples/cvs/contrib/rcslock /usr/share/examples/cvs/contrib/easy-import /usr/X11R6/bin/mkhtmlindex /usr/X11R6/bin/bdftruncate.pl /usr/X11R6/bin/ucs2any.pl /usr/compat/linux/usr/bin/mtrace Perhaps some of these have been converted to something else since 5.0-dp2, and I expect we don't care about the /usr/share/examples ones anyway. (my 5.0-dp2 system is the full-distribution install of dp2, including X11, src, ports, and linux-compat, but no extra ports or pkgs installed. This did bring in perl, although I was never asked about perl per se) If my search of the -current mailing list is correct, a plain-shell version of rmuser was done, but apparently was never committed. It also looks like http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/45337 has a version of rmuser rewritten in C. As near as I can tell, no one has rewritten adduser as a plain-shell script or in C. Do we need to get these rewrites in for 5.0-release? Do any of the other remaining perl scripts listed above need to be rewritten for 5.0-release? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pw_user.c change for samba
At 7:06 PM -0800 11/27/02, Terry Lambert wrote: NAKAJI Hiroyuki wrote: > My /usr/sbin/adduser, updated on Nov/23/2002 21:58 JST, does > not call pw command. It adds account to /etc/master.passwd and > invokes 'pwd_mkdb'. > See 'sub new_users' function in /usr/sbin/adduser. There are two "adduser" scripts. One is perl, and one was written to use "pw" and provide the same semantics, in a shell script, as part of the "perl purge" that happened recently. One of them pukes on the trailing $, and the other doesn't. It's confusing, unless you caught that we were talking about most recent -current. Well, I took Terry's earlier patch to 'pw', and modified it so that login names can include a trailing '$' (among other things). I tried this, and immediately ran into the problem that 'pw' wants to create a group-name the same as the login-name. Perhaps it would be best for us just to leave it such that any valid login name is also a valid group name. So, I should probably redo this update again, because it can be much simpler. However, that doesn't answer the question of which 'adduser' is actually expected to be used in 5.0-current. Does someone have the shell-script (non-perl) version of adduser? Is it named something else, perhaps? Or are we going to ship 5.0-release with an 'adduser' that does require perl, even though perl is not in the base system? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Where is APM0 ???
Sergey V Golitzyn wrote: Hello, i have a little problem with APM (Adv. Power Managment) I migrate from 4.7-STABLE to 5.0-CURRENT version. But in process i have lost apm0 device in "dmesg". Device /dev/apm is in, but apmd daemon does not start cozz /dev/apmctl device not exist. kozaczek# kldload apm kozaczek# ls -l /dev/apm crw-rw-r-- 1 root operator 39, 0 Dec 1 02:49 /dev/apm kozaczek# Try it as a module. But generally ACPI should be suprerior. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: C++ Issue On -CURRENT
In message <002501c298d3$63c3c150$[EMAIL PROTECTED]>, "Matthew
Emmerton" w
rites:
> > In message <[EMAIL PROTECTED]>
> > , Garret
> > t Rooney writes:
> > > > The following program builds and runs under 4.7-STABLE:
> > > >
> > > > #include
> > > >
> > > > int main()
> > > > {
> > > > cout<<"Hello World\n";
> > > > }
> > > >
> > > > ... but under 5.0-CURRENT it gives me the following errors:
> > > >
> > > > cwtest$ g++ -o foo foo.cc
> > > > foo.cc: In function `int main()':
> > > > foo.cc:5: `cout' undeclared (first use this function)
> > > > foo.cc:5: (Each undeclared identifier is reported only once for each
> > > > function
> > > >it appears in.)
> > >
> > > does the problem still occur if you add in 'using namespace std'?
> >
> > Thanks. That also fixed it.
>
> You will also get these sorts of errors if you've got stale g++ headers in
> /usr/include/g++. Make sure that you clean out this directory before doing
> an installworld.
My email that started this thread stated that I had already done this.
Actually, I had done this months ago when I installed current on my new
(well... old) testbed. I did it yet again (and reinstalled world) just
to make sure I did it right.
--
Cheers, Phone: 250-387-8437
Cy SchubertFax: 250-387-5231
Team Leader, Sun/Alpha Team Email: [EMAIL PROTECTED]
Open Systems Group, CITS
Ministry of Management Services
Province of BC
FreeBSD UNIX: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Where is APM0 ???
Hello, i have a little problem with APM (Adv. Power Managment) I migrate from 4.7-STABLE to 5.0-CURRENT version. But in process i have lost apm0 device in "dmesg". Device /dev/apm is in, but apmd daemon does not start cozz /dev/apmctl device not exist. Tell me please how to modify this strings in /boot/device hints to Enable APM device: hint.apm.0.at="nexus" hint.apm.0.enable="1" hint.apm.0.disabled="0" hint.apm.0.flags="0x20" Or i must use another device like VIAPM KERNCONF file contains : device apm when i include device VIAPM, system does not booted at all. Command zzz prints: acpi0: AcpiGetSleepTypeData failed - AE_NOT_FOUND Command "shutdown -p now" going to reboot. Dmesg file included. Thanks, Best Regrads Sergey V. Golitzyn (Russia) // Dmesg file 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 #17: Sun Dec 1 02:50:49 MSK 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HIHIHAHA Preloaded elf kernel "/boot/kernel/kernel" at 0xc0463000. Preloaded elf module "/boot/kernel/vesa.ko" at 0xc04630a8. Preloaded elf module "/boot/kernel/linux.ko" at 0xc0463154. Preloaded elf module "/boot/kernel/snd_emu10k1.ko" at 0xc0463200. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc04632b0. Preloaded elf module "/boot/kernel/bktr.ko" at 0xc046335c. Preloaded elf module "/boot/kernel/bktr_mem.ko" at 0xc0463408. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1336371473 Hz CPU: AMD Athlon(tm) XP 1500+ (1336.37-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383f9ff AMD Features=0xc048 real memory = 268369920 (255 MB) avail memory = 256053248 (244 MB) Initializing GEOMetry subsystem bktr_mem: memory holder loaded Pentium Pro MTRR support enabled VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc040dc42 (122) VESA: NVidia npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Using $PIR table, 7 entries at 0xc00fdef0 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xd000-0xd7ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) bktr0: mem 0xe200-0xe2000fff irq 10 at device 9.0 on pci0 bktr0: AVer Media TV/FM, Philips PAL tuner. pci0: at device 9.1 (no driver attached) pcm0: port 0xd000-0xd01f irq 11 at device 12.0 on pci0 isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0xd800-0xd80f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xdc00-0xdc1f irq 10 at device 17.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Logitech USB Mouse, rev 1.10/6.20, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. uhci1: port 0xe000-0xe01f irq 10 at device 17.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe400-0xe41f irq 10 at device 17.4 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 orm0: at iomem 0xd-0xd7fff,0xc-0xcc7ff 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 WARNING: apm_saver module requires apm enabled acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% ad0: 39266MB [79780/16/63] at ata0-master UDMA100 acd0: DVD-ROM at ata0-slave PIO4 acd1: CD-RW at ata1-master PIO4 acd2: CDROM at ata1-slave PIO4 MBREXT Slice 5 on ad0s4: 00 01 81 08 0b fe ff 8c 3f 00 00 00 06 63 55 02 |?cU.| [0] f:0
Re: C++ Issue On -CURRENT
> In message <[EMAIL PROTECTED]>
> , Garret
> t Rooney writes:
> > > The following program builds and runs under 4.7-STABLE:
> > >
> > > #include
> > >
> > > int main()
> > > {
> > > cout<<"Hello World\n";
> > > }
> > >
> > > ... but under 5.0-CURRENT it gives me the following errors:
> > >
> > > cwtest$ g++ -o foo foo.cc
> > > foo.cc: In function `int main()':
> > > foo.cc:5: `cout' undeclared (first use this function)
> > > foo.cc:5: (Each undeclared identifier is reported only once for each
> > > function
> > >it appears in.)
> >
> > does the problem still occur if you add in 'using namespace std'?
>
> Thanks. That also fixed it.
You will also get these sorts of errors if you've got stale g++ headers in
/usr/include/g++. Make sure that you clean out this directory before doing
an installworld.
--
Matt Emmerton
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Hell notebook (Vaio R505TL)
Barkley Vowk wrote: I've got a notebook running current, and I've got a horde of problems I need some help fixing... 1) ACPI lets me control fans and cpu speed nicely, and the notebook will suspend nicely, and it almost resumes properly. When the notebook wakes up it comes back on the network and the keyboard works properly, but the display stays black. Suspending is the #1 concern I have right now. The X11 problem has a simple cause -> XFree doesn't know a witt about ACPI. First step to make this working again would be to make V86 calls working again istead of instant lockup as it is now becouse XFree is using VESA system ioctl to set the resolution on for example the LynxEM chipset. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: C++ Issue On -CURRENT
In message <[EMAIL PROTECTED]>
, Garret
t Rooney writes:
> > The following program builds and runs under 4.7-STABLE:
> >
> > #include
> >
> > int main()
> > {
> > cout<<"Hello World\n";
> > }
> >
> > ... but under 5.0-CURRENT it gives me the following errors:
> >
> > cwtest$ g++ -o foo foo.cc
> > foo.cc: In function `int main()':
> > foo.cc:5: `cout' undeclared (first use this function)
> > foo.cc:5: (Each undeclared identifier is reported only once for each
> > function
> >it appears in.)
>
> does the problem still occur if you add in 'using namespace std'?
Thanks. That also fixed it.
--
Cheers, Phone: 250-387-8437
Cy SchubertFax: 250-387-5231
Team Leader, Sun/Alpha Team Email: [EMAIL PROTECTED]
Open Systems Group, CITS
Ministry of Management Services
Province of BC
FreeBSD UNIX: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: C++ Issue On -CURRENT
In message <[EMAIL PROTECTED]>, Craig Rodrigues writes:
> On Sat, Nov 30, 2002 at 03:48:00PM -0800, Cy Schubert - CITS Open Systems Gro
> up wrote:
> > I've been working on getting the tripwire port to build on -CURRENT.
> > Through this process I've stumbled across an issue. Searching through
> > the mailing lists, I haven't found a solution to this.
> >
> > The following program builds and runs under 4.7-STABLE:
> >
> > #include
> >
> > int main()
> > {
> > cout<<"Hello World\n";
> > }
>
> Should be:
>
> std::cout<<"Hello World\n";
That fixed it. Thanks.
--
Cheers, Phone: 250-387-8437
Cy SchubertFax: 250-387-5231
Team Leader, Sun/Alpha Team Email: [EMAIL PROTECTED]
Open Systems Group, CITS
Ministry of Management Services
Province of BC
FreeBSD UNIX: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: C++ Issue On -CURRENT
On Sat, Nov 30, 2002 at 03:48:00PM -0800, Cy Schubert - CITS Open Systems Group wrote:
> I've been working on getting the tripwire port to build on -CURRENT.
> Through this process I've stumbled across an issue. Searching through
> the mailing lists, I haven't found a solution to this.
>
> The following program builds and runs under 4.7-STABLE:
>
> #include
>
> int main()
> {
> cout<<"Hello World\n";
> }
Should be:
std::cout<<"Hello World\n";
Pick up a good C++ book like Stroustrup's C++ Programming Language
( http://www.research.att.com/~bs/3rd.html ), and learn about
the std namespace.
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: C++ Issue On -CURRENT
The following program builds and runs under 4.7-STABLE:
#include
int main()
{
cout<<"Hello World\n";
}
... but under 5.0-CURRENT it gives me the following errors:
cwtest$ g++ -o foo foo.cc
foo.cc: In function `int main()':
foo.cc:5: `cout' undeclared (first use this function)
foo.cc:5: (Each undeclared identifier is reported only once for each
function
it appears in.)
does the problem still occur if you add in 'using namespace std'?
-garrett
--
garrett rooneyRemember, any design flaw you're
[EMAIL PROTECTED] sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
C++ Issue On -CURRENT
I've been working on getting the tripwire port to build on -CURRENT.
Through this process I've stumbled across an issue. Searching through
the mailing lists, I haven't found a solution to this.
The following program builds and runs under 4.7-STABLE:
#include
int main()
{
cout<<"Hello World\n";
}
... but under 5.0-CURRENT it gives me the following errors:
cwtest$ g++ -o foo foo.cc
foo.cc: In function `int main()':
foo.cc:5: `cout' undeclared (first use this function)
foo.cc:5: (Each undeclared identifier is reported only once for each
function
it appears in.)
cwtest$
I built world on one of my -STABLE machines (it's faster that way),
then remove /usr/include/g++ (on the -CURRENT system) and installworld
on my -CURRENT system. Yet, the above error occurs.
I suspect that someone else here has encountered this and solved this.
Would anyone care to point me in the right direction?
--
Cheers, Phone: 250-387-8437
Cy SchubertFax: 250-387-5231
Team Leader, Sun/Alpha Team Email: [EMAIL PROTECTED]
Open Systems Group, CITS
Ministry of Management Services
Province of BC
FreeBSD UNIX: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: missing: usr.bin/rdist - used: ports/net/rdist6
"M. Warner Losh" wrote: > : > - Please consider restoring rdist to FreeBSD. Thanks. > > And the number of security problems with rdist are legion. A large > component of the decision to remove it from the base was the high > incidence of security problems with the original code. That, coupled > with the rdist6 incompatibility and the better alternatives, lead us > to remove it from the tree rather than update the code. Thanks Warner, OK "security problems ... legion" ... fair enough ! > Next thing you'll be wanting perl back in the base system :-) , not me :-) I didn't want to consume list time on a discussion if rdist had been previously debated & lost, but I had no idea current had debated it. rdist might have been one of those commits that just slip through without much review sometimes. I haven't been tracking current for a long time prior to call for DP2 tester, (so perhaps I'm a good tester, 'cos I'll trip & fall on what you long term current folk know to step over/round, & not trip on), but I Did first first ask: Has this been well debated already ? or should I file a Send-PR ? & until my last post, I saw no indication of previous debate. Only then did I get: Mark M's "Debate over." Kris's: [...Other stale arguments deleted...] (which probably crossed with mail batch reading & timezones, with mine). Julian Stacey jhs @ berklix.com Computer Systems Engineer, Unix & Net Consultant, Munich. Ihr Rauchen = mein allergischer Kopfschmerz ! Schnupftabak probieren. European BSD Conference, Munich Pre-Planning http://berklix.org/conf/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dump(8) + UFS2
On Sun, 1 Dec 2002, Jan Srzednicki wrote: > Hm, this is weird. I'm sure I have dumped an UFS2 filesystem earlier and > it worked. Now I get similar error messages as you. Yes, I'm absolutely > sure that the filesystem was UFS2 - played with extattrctl on it, checked > it with dumpfs and was not able to mount it under -STABLE. dump utility is > exacly the same (except that it now resides on a different disk). The > filesystem after restore does not seem to be corrupted in any way (well, > except that linux-*-jdk-* stuff SEGVs - kinda weird). This thing gets > spooky a bit.. ;) > > Both my disks are IDEs, if that matters in any way. Erm, s/extattrctl/setextattr and getextattr/. -- -- 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
Re: system locks with vnode backed md(4)
Robert Watson wrote: > On Sat, 30 Nov 2002, Michal Mertl wrote: > > I'm now unable to make it dead-lock again. Yet it happened quite easily. > > I had more md backing files in the same directory at the beginning (to > > test Terry's suspicion mentioned in thread 'jail' on hackers@). > > I've noticed that chroot() environments tend to make existing deadlock > opportunities more likely. I'm not quite sure why that is. :-) Lock to parent. It's the same reason you can lock up if you use automount, with all the automount mount points happening in the same subdirectory. > There are a fair number of vnode locking deadlock scenarios that are > unavoidable where we rely on grabbing vnode locks out of the directory > structure lock order. This occurs for vnode-backed md devices, quotas, > and UFS1 extended attributes, and probably some other situations. I > suspect that Terry is correct that operations on the vnode backing file > storage directory are triggering the problem, since that increases the > chances that a vnode lock "race to root" will occur from both the file > system backed into the md device, and for the md backing vnodes during > blocking I/O. See other postings. The "race to root" is the one I was originally commenting on. I'm not sure that it applies in this case, I think this case might be the "out of memory to create new soft dependencies" case, where you can end up holding a lock on a buffer that needs to be flushed to recover memory, until you can satisfy the request to create a dependency (starvation deadlock). The "race to root" is a "deadly embrace" deadlock. > If you can avoid directory operations on the md backing > directory, that would probably be one way to avoid triggering the bug. Yes. By placing each vnconfiged device in its own subdirectory, you avoid them. There's still a window on your host OS doing it's own traversal, but that's (effectively) a "whole FS lock", so it doesn't trigger a problem. > Seeing it reproduced would probably confirm that this is the case. It's a pain. I wasted a couple of days trying to reproduce, without a box I could wipe and make into a wscratch box, with little luck. I think that it requires reproducing the failing box in detail, which I wasn't willing to do (hence the workaround). > On the > other hand, there may be other deadlocks in the vnode/ufs/md code that can > be more easily corrected than this general VFS problem, so details there > would be very useful. There are a number of them; they are all a pain. It's really tempting to just refactor the code so that all locking occurs at the same logical layer, without being held across function calls. That'd be a heck of a lot of work, though... probably worth it, in the end. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dump(8) + UFS2
On Sat, 30 Nov 2002, Matthias Schuendehuette wrote: > > I just have made dump and restore of my 3GB UFS2 /usr partition and > > did not experience any problems with that. Working on -CURRENT from > > Nov 24th. > > Sure you dumped an UFS2 filesystem? > > Here's my try: > > root@current - /root > 104 # uname -a > FreeBSD current.best-eng.de 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Thu Nov > 28 21:59:11 CET 2002 > [EMAIL PROTECTED]:/disk/obj/usr/src/sys/CURRENT i386 Hm, this is weird. I'm sure I have dumped an UFS2 filesystem earlier and it worked. Now I get similar error messages as you. Yes, I'm absolutely sure that the filesystem was UFS2 - played with extattrctl on it, checked it with dumpfs and was not able to mount it under -STABLE. dump utility is exacly the same (except that it now resides on a different disk). The filesystem after restore does not seem to be corrupted in any way (well, except that linux-*-jdk-* stuff SEGVs - kinda weird). This thing gets spooky a bit.. ;) Both my disks are IDEs, if that matters in any way. -- -- 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
Re: system locks with vnode backed md(4)
Michal Mertl wrote: > I'm now unable to make it dead-lock again. Yet it happened quite easily. I > had more md backing files in the same directory at the beginning (to test > Terry's suspicion mentioned in thread 'jail' on hackers@). > > After the first lock-up I tried 'while(1);tar xzf ports.tgz; rm -rf > ports;end' on normal filesystem, let it run for long time (> 1h) and then > I found the system almost dead-locked too (the system worked, but anything > accessing disk was painfully slow - it might be the same problem or it > might be different. It never ended (at least for > ~30 mins when I didn't > (weren't able) anything on it). syncer and bufdaemon and others were in > wdrain. Disk as seen in systat -v showed maximal usage yet no inodes were > resolved. Sometimes during that test I had lock order reversal: Hmm. This isn't actually the same, I think. This is just the point at which you have run out of available memory to maintain additional dependencies, and giant held. The key to this diagnosis is that you "let it run for a long time" before it "locked up". The deadlock condition requires that two people do directory traversals at the same time in vnode backed files in the same directory. It has to do with the locks on the backing files as a result of root vnode traversal vs. the backing vnode in the parent directory. I haven't characterized it better than that. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Hell notebook (Vaio R505TL)
I've got a notebook running current, and I've got a horde of problems I need some help fixing... 1) ACPI lets me control fans and cpu speed nicely, and the notebook will suspend nicely, and it almost resumes properly. When the notebook wakes up it comes back on the network and the keyboard works properly, but the display stays black. Suspending is the #1 concern I have right now. When I power the system down using the power button, I cannot turn the notebook back on until I have removed the battery (and power adapter) for a few seconds first. 2) CardBus doesn't work. When I compile cardbus support in I see: cbb0: Unsupported card type detected Inserting a card into the slot causes an instant panic: 3 DiX kernel: Fatal trap 18: integer divide fault while in kernel mode 3 DiX kernel: instruction pointer = 0x8:0xc25bae04 3 DiX kernel: stack pointer = 0x10:0xcb4c5cac 3 DiX kernel: frame pointer = 0x10:0xcb4c5cc0 3 DiX kernel: code segment= base 0x0, limit 0xf, type 0x1b 3 DiX kernel: = DPL 0, pres 1, def32 1, gran 1 3 DiX kernel: processor eflags= interrupt enabled, IOPL = 0 3 DiX kernel: current process = 21 (irq9: cbb0 uhci0++) In addition, while cardbus is in the kernel the fxp0 device fails to work (which makes getting tracebacks from the notebook a pain in the ass, it has no serial console either). 3) USB has stopped working, usb had previously been working quite well, but in the last upgrade, usb now fails to attach any devices: 8 DiX kernel: uhub0: device problem, disabling port 2 4 DiX kernel: uhub0: device problem, disabling port 1 0 DiX kernel: uhub0: device problem, disabling port 1 0 DiX kernel: uhub0: port error, restarting port 1 I've tried 3 devices that all previously worked quite well. I can change nothing in the bios really, I can turn plug and play on and off and the motion logo on boot, and that about covers it. I've attached a dmesg and acpidump. Any help would be greatly appreciated. -- Snip Snip -- 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: Sun Nov 24 23:37:18 MST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DIX Preloaded elf kernel "/boot/kernel/kernel" at 0xc052. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05200a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 645877648 Hz CPU: Pentium III/Pentium III Xeon/Celeron (645.88-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 199753728 (190 MB) avail memory = 188391424 (179 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard Using $PIR table, 9 entries at 0xc00fdf30 Timecounter "ACPI-fast" frequency 3579545 Hz 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 pcib0: port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.LNKA irq 9: [ 9] low,level,sharable 0.1.0 \\_SB_.LNKB irq 9: [ 9] low,level,sharable 0.1.1 \\_SB_.LNKC irq 0: [ 9] low,level,sharable 0.1.2 \\_SB_.LNKD irq 0: [ 9] low,level,sharable 0.1.3 \\_SB_.LNKA irq 9: [ 9] low,level,sharable 0.2.0 \\_SB_.LNKB irq 9: [ 9] low,level,sharable 0.31.1 \\_SB_.LNKH irq 9: [ 9] low,level,sharable 0.31.2 \\_SB_.LNKD irq 0: [ 9] low,level,sharable 0.31.3 before setting priority for links \\_SB_.LNKC: interrupts: 9 penalty: 830 references: 1 priority: 0 \\_SB_.LNKD: interrupts: 9 penalty: 830 references: 2 priority: 0 before fixup boot-disabled links - \\_SB_.LNKD: interrupts: 9 penalty: 830 references: 2 priority: 1660 \\_SB_.LNKC: interrupts: 9 penalty: 830 references: 1 priority: 830 after fixup boot-disabled links -- \\_SB_.LNKD: interrupts: 9 penalty: 830 references: 2 priority: 1660 \\_SB_.LNKC: interrupts: 9 penalty: 830 references: 1 priority: 830 arbitrated configuration - \\_SB_.LNKA irq 9: [ 9] low,level,sharable 0.1.0 \\_SB_.LNKB irq 9: [ 9] low,level,sharable 0.1.1 \\_SB_.LNKC irq 0: [ 9] low,level,sharable 0.1.2 \\_SB_.LNKD irq 0: [ 9] low,level,sharable 0.1.3 \\_SB_.LNKA irq 9: [ 9] low,level,sharable 0.2.0 \\_SB_.LNKB irq 9: [ 9] low,level,sharable 0.31.1 \\_SB_.LNKH irq 9: [ 9] low,level,sharable 0.31.2 \\_SB_.LNKD irq 0: [ 9] low,level,
Re: dump(8) + UFS2
On Saturday 30 November 2002 23:24, you wrote: > On Sat, 30 Nov 2002, Manfred Antar wrote: > > I guess dump is not ready for UFS2 > > I just have made dump and restore of my 3GB UFS2 /usr partition and > did not experience any problems with that. Working on -CURRENT from > Nov 24th. Sure you dumped an UFS2 filesystem? Here's my try: root@current - /root 104 # uname -a FreeBSD current.best-eng.de 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Thu Nov 28 21:59:11 CET 2002 [EMAIL PROTECTED]:/disk/obj/usr/src/sys/CURRENT i386 root@current - /root 103 # dump 0af /dev/nsa0 /usr DUMP: Date of this level 0 dump: Sat Nov 30 23:50:24 2002 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/da3s1g (/usr) to /dev/nsa0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: SIGSEGV: ABORTING! Speicherschutzverletzung (core dumped) Or is it a SCSI-problem? Did you dump from an ATA or SCSI-Disk? To an ATA or SCSI tape-device? Astonishing... -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) Powered by FreeBSD 5.0-CURRENT To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Are SysV semaphores thread-safe on CURRENT?
Daniel Eischen wrote: > > No, libc_r doesn't properly handle flock. Usually, all syscalls > > that take file descriptors as arguments honor the non-blocking > > mode of the file if set. I guess flock(2) doesn't and has its > > own option to the operation argument (LOCK_NB). > > > > I hacked libc_r to periodically check (every 100msecs) the > > flock. See if this fixes things: Same thing I suggested, only I think he was really using fcntl(), not flock()? My patch wasn't integral to the library (it was more of a hack), and my default time was 1S, not 100uS. Same non-FIFO request ordering, too. 8-(. I guess the real question is what is an fcntl()/flock() supposed to do on a blocking call against a non-blocking fd? I could not tell, so I punted. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FYI - 4.3-stable to 5.0 upgrade success
I recently upgraded a Dell Lattitude C600 from some version of -stable after 4.3 to 5.0-current. I first upgraded it to 4.7-stable, then to 5.0-current. I followed the instructions at the end of src/UPDATING pretty much to the letter. I haven't recompiled any applications for 5.0, so they're all running OK under -current (KDE and some other stuff). -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Are SysV semaphores thread-safe on CURRENT?
Brian Smith wrote:
> On Mon, 18 Nov 2002 22:05:34 -0800, Terry Lambert wrote:
> >Use mmap of a backing-store file, and then use file locking to
> >do record locking in the shared memory segment.
>
> Ok, I did this, and it actually works considerably better than
> the SysV shared memory. However flock() has the same problem
> as the SysV semaphores, where they block the entire process,
> allowing the same deadlock situation to occur. Has this flock()
> behavior changed in CURRENT?
>
> It seems like this behavior is much more likely to change than
> the SysV code.
Do you mean "flock()", or do you mean "fcntl(fs, F_SETLKW, ...)"?
If you are using range locks, then you mean fcntl().
That's unfortunate: there's an easy way to convert blocking
file locks into non-blocking, plus a context switch. I
thought th threads library already did this for you in the
fcntl() wrapper, in /usr/src/lib/libc_r/uthread/uthread_fcntl.c,
but apparently it doesn't. 8-(.
The easy way to do this is to convert the blocking request into
a non-blocking request, with a retry; e.g., where you have a
call to:
err = fcntl( fd, F_SETLKW, &flock);
Replace it with:
while( ( err = fcntl( fs, F_SETLK, &flock)) == -1 && errno == EAGAIN) {
sleep( 1); /* use nanosleep(), if 1 second is too big */
}
This will cause the processor to be yielded to other threads for
as long as the lock can't be acquired, an acquisititon will be
retried until it succeeds (effectively, blocking only that thread
in "sleep()"). The difference between F_SETLKW and F_SETLK is why
I suggested the approach in the first place (FWIW).
The cost of doing this is that blocking requests will not be
serviced in FIFO order, as they would if F_SETLKW were being
used. This may get expensive if you have a highly contended
resource, because you are effectively implementing a low cost
polling to obtain the lock. The answer to this is that you
are not supposed to use semaphores for highly contended resources,
or if you do, use a spin-lock before you use the semaphore, so
you can fail early at reduced expense.
Probably making the above code into an line function and/or
actually modifiying the _fcntl() implementation in the threads
library is the way to go.
Worse comes to worse, I can give you a kernel patch so that an
fcntl() to assert a blocking lock on a non-blocking fd returns
the EWOULDBLOCK error, with a patch against _fcntl() similar to
the code in _read().
I didn't do that this time, because I don't know how much code
really depends on a lock assert on a non-blocking fd blocking
anyway, and no matter how you slice it, it's still going to
have the same non-FIFO ordering, unless I implemented a FIFO
ordered request queue, as well (it'd have to, to be correct).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: installworld of 5.0 broken on 4.x?
On Sat, Nov 30, 2002 at 05:40:59PM -0500, Craig Rodrigues wrote: > > ===> etc/sendmail > > rm -f freefall.cf > > (cd /local0/src-5.x/etc/sendmail && m4 >-D_CF_DIR_=/local0/src-5.x/etc/sendmail/../../contrib/sendmail/cf/ >/local0/src-5.x/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 freefall.mc) > >freefall.cf > > m4: not found > > *** Error code 127 > > > Is this related? > >http://www.freebsd.org/cgi/getmsg.cgi?fetch=30158+0+/usr/local/www/db/text/2002/freebsd-current/20020915.freebsd-current Hmm..this machine runs ntpd, so I don't think timestamping is a problem. Kris msg47830/pgp0.pgp Description: PGP signature
Re: installworld of 5.0 broken on 4.x?
On Sat, Nov 30, 2002 at 02:35:32PM -0800, Kris Kennaway wrote: > I get this when building 5.0 under 4.x, for the purposes of installing > into a temporary directory. Any ideas? > > Kris > > ===> etc/sendmail > rm -f freefall.cf > (cd /local0/src-5.x/etc/sendmail && m4 >-D_CF_DIR_=/local0/src-5.x/etc/sendmail/../../contrib/sendmail/cf/ >/local0/src-5.x/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 freefall.mc) > >freefall.cf > m4: not found > *** Error code 127 Is this related? http://www.freebsd.org/cgi/getmsg.cgi?fetch=30158+0+/usr/local/www/db/text/2002/freebsd-current/20020915.freebsd-current -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Update to UFS2 Superblock Format
Poul-Henning Kamp wrote: From the next branch on -current, it is my intent to not install BSD labels anymore, but switch to GPT instead, (possibly encapsulated in an BSD MBR slice for legacy systems). Do you mean this GPT: http://www.microsoft.com/hwdev/tech/storage/GPT_FAQ.asp or are you speaking of something else? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
installworld of 5.0 broken on 4.x?
I get this when building 5.0 under 4.x, for the purposes of installing into a temporary directory. Any ideas? Kris ===> etc/sendmail rm -f freefall.cf (cd /local0/src-5.x/etc/sendmail && m4 -D_CF_DIR_=/local0/src-5.x/etc/sendmail/../../contrib/sendmail/cf/ /local0/src-5.x/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 freefall.mc) > freefall.cf m4: not found *** Error code 127 Stop in /local0/src-5.x/etc/sendmail. *** Error code 1 Stop in /local0/src-5.x/etc. *** Error code 1 msg47827/pgp0.pgp Description: PGP signature
weird panic on alpha
I'm getting this on several of my alphas. Any ideas? The traceback and panic message is weird. Kris axp4# gdb -k kernel.debug vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "alpha-undermydesk-freebsd"... panic: bremfree: bp 0xfe0002acbbf0 not locked panic messages: --- dmesg: kvm_read: --- #0 0xfc425e58 in doadump () at /local0/src-client/sys/kern/kern_shutdown.c:231 231 /local0/src-client/sys/kern/kern_shutdown.c: No such file or directory. in /local0/src-client/sys/kern/kern_shutdown.c (kgdb) bt #0 0xfc425e58 in doadump () at /local0/src-client/sys/kern/kern_shutdown.c:231 #1 0xfc426474 in boot (howto=260) at /local0/src-client/sys/kern/kern_shutdown.c:364 (kgdb) msg47826/pgp0.pgp Description: PGP signature
Re: dump(8) + UFS2
On Sat, 30 Nov 2002, Manfred Antar wrote: > I guess dump is not ready for UFS2 I just have made dump and restore of my 3GB UFS2 /usr partition and did not experience any problems with that. Working on -CURRENT from Nov 24th. -- -- 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
Re: unkillable process - 'mdconfig -t vnode' on small file
In message <[EMAIL PROTECTED]>, Michal Mertl writes: >Subject says it all. Fixed in md.c revision 1.74 - this was discussed here a few days ago, but I was just waiting for approval to commit the fix. Ian 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, Nov 24, 2002 at 01:08:51PM +0100, 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 :) If you set bit 5 of ppc(4) 'flags' lpt will do polling. But lptcontrol won't change it anymore. Nicholas -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: corrupted UFS2 label after ffs_vfsops.c,v 1.198
On Sat, 30 Nov 2002, Kirk McKusick wrote: > Date: Sat, 30 Nov 2002 11:36:21 -0800 > From: Kirk McKusick <[EMAIL PROTECTED]> > To: Michael Reifenberger <[EMAIL PROTECTED]> > Cc: FreeBSD-Current <[EMAIL PROTECTED]> > Subject: Re: corrupted UFS2 label after ffs_vfsops.c,v 1.198 > ... > Once you have upgraded your fsck to the current version, it will only > check converted UFS2 filesystems. To convert your UFS2 filesystem, > simply mount it with your new kernel. Once you have done that, you > will be able to unmount it and run the new fsck. Similarly, if you > have an older kernel (vintage last four months of -current) then it > will back-convert your UFS2 filesystems every time you run it and thus > you will have to forward convert before fsck will run on it again. This worked fine. Thanks! Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Update to UFS2 Superblock Format
In message <[EMAIL PROTECTED]>, Ju lian Elischer writes: >isn't it about time we got away from puting the bootblocks in a >filesystem partition? I actually reached that conclusion back when we realized that the UFS2 bootblocks did not fit the 8k magic zone. >From the next branch on -current, it is my intent to not install BSD labels anymore, but switch to GPT instead, (possibly encapsulated in an BSD MBR slice for legacy systems). But lets burn that bridge once we have crossed it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Update to UFS2 Superblock Format
isn't it about time we got away from puting the bootblocks in a filesystem partition? "Here, all these planets^H^H^H^H^H^Hblocks are yours, to do as you please, except the first 16 blocks.. attempt no landing there" (or however it went).. (Appologies to Mr. Clark). On Fri, 29 Nov 2002, Kirk McKusick wrote: > Date: Fri, 29 Nov 2002 23:16:51 -0800 > To: Kirk McKusick <[EMAIL PROTECTED]> > From: Manfred Antar <[EMAIL PROTECTED]> > Subject: Re: Update to UFS2 Superblock Format > Cc: [EMAIL PROTECTED], Robert Watson <[EMAIL PROTECTED]>, > [EMAIL PROTECTED], Poul-Henning Kamp <[EMAIL PROTECTED]> > In-Reply-To: <[EMAIL PROTECTED]> > X-ASK-Info: Whitelist match To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: corrupted UFS2 label after ffs_vfsops.c,v 1.198
Date: Sat, 30 Nov 2002 00:44:10 +0100 (CET) From: Michael Reifenberger <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: FreeBSD-Current <[EMAIL PROTECTED]> Subject: corrupted UFS2 label after ffs_vfsops.c,v 1.198 Hi, after cvsupping a kernel with the mentioned version of ffs_vfsops.c I tried to upgrade my kernel from a some weeks aged -current. After that I'm no longer able to mount or fsck a UFS2 formatted disk. My dmesg is attached. Trying fsck_ffs /dev/da0s1a gives: (nihil)(root) # fsck_ffs /dev/da0s1a ** /dev/da0s1a Cannot find file system superblock LOOK FOR ALTERNATE SUPERBLOCKS? [yn] y Fließkommafehler (floating point error in german) Any possible alternate superblock given with -b gives a fp-error also. How to resolve this? Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS Once you have upgraded your fsck to the current version, it will only check converted UFS2 filesystems. To convert your UFS2 filesystem, simply mount it with your new kernel. Once you have done that, you will be able to unmount it and run the new fsck. Similarly, if you have an older kernel (vintage last four months of -current) then it will back-convert your UFS2 filesystems every time you run it and thus you will have to forward convert before fsck will run on it again. Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UFS Snapshot deadlock
Your deadlock should now be fixed. Kirk McKusick =-=-=-=-= From: Kirk McKusick <[EMAIL PROTECTED]> Date: Fri, 29 Nov 2002 23:27:12 -0800 (PST) To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/sys/ufs/ffs ffs_snapshot.c X-FreeBSD-CVS-Branch: HEAD mckusick2002/11/29 23:27:12 PST Modified files: sys/ufs/ffs ffs_snapshot.c Log: Fix two deadlocks in snapshots: 1) Release the snapshot file lock while suspending the system. Otherwise a process trying to read the lock may block on its containing directory preventing the suspension from completing. Thanks to Sean Kelly <[EMAIL PROTECTED]> for finding this deadlock. 2) Replace some bdwrite's with bawrite's so as not to fill all the buffers with dirty data. The buffers could not be cleaned as the snapshot vnode was locked hence the system could deadlock when making snapshots of really massive filesystems. Thanks to Hidetoshi Shimokawa <[EMAIL PROTECTED]> for figuring this out. Sponsored by: DARPA & NAI Labs. Revision ChangesPath 1.51 +7 -2 src/sys/ufs/ffs/ffs_snapshot.c =-=-=-=-=-= Date: Wed, 30 Oct 2002 03:57:52 -0600 From: Sean Kelly <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: UFS Snapshot deadlock While playing with UFS snapshots on a UFS2 filesystem I mounted specifically for this purpose, I encountered a little problem. It seems I have processes deadlocked on each other. Steps to repeat: /# mount /dev/ad2a /mnt ; cd /mnt /dev/ad2a on /mnt (ufs, local, soft-updates, multilabel) # UFS2 /mnt# cd /mnt; mount -u -o snapshot /mnt/snapshot /mnt *switch vtys* /# cd /mnt; ls -l *ls deadlocks* *I get bored and ^C the mount on the other vty about 30 minutes later* /mnt# ls *this ls deadlocks too* For the record, /mnt was a new filesystem. It had *nothing* in it. No directories or anything. So now, I've got these: UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 1133 669 0 -4 0 692 548 ufsD+v10:00.00 ls 1001 939 856 0 -4 0 696 560 ufsD+v20:00.00 ls -l 0 937 1 0 -4 0 560 336 ufsD v10:00.65 mount -u -o snapshot /mnt/snapshot /mnt Now for some numbers. db> trace 937 mi_switch(c71aab60,50,c03375c6,c7,c03ad2f8) at mi_switch+0x158 msleep(c75098dc,c03a9358,50,c034f732,0) at msleep+0x3b4 acquire(c75098dc,140,600,e6,3a9) at acquire+0xa7 lockmgr(c75098dc,1010002,c7509818,c71aab60,e5b076a8) at lockmgr+0x2f7 vop_stdlock(e5b076c4,e5b076e0,c021e306,e5b076c4,0) at vop_stdlock+0x2c ufs_vnoperate(e5b076c4,0,c033dd28,e5b076e0,c01ba4a5) at ufs_vnoperate+0x18 vn_lock(c7509818,10002,c71aab60,815,c7509818) at vn_lock+0xd6 vget(c7509818,2,c71aab60,470,0) at vget+0xd6 ffs_sync(c74c5400,1,c726a780,c71aab60,c74f1000) at ffs_sync+0x126 vfs_write_suspend(c74c5400,c74ffcb8,d351f08c,1,c2c06e80) at vfs_write_suspend+0x70 ffs_snapshot(c74c5400,bfbffd1d,70,c033990d,252) at ffs_snapshot+0xa48 ffs_mount(c74c5400,c745ce80,bfbff000,e5b07bf0,c71aab60) at ffs_mount+0x548 vfs_mount(c71aab60,c6d2b780,c745ce80,101,bfbff000) at vfs_mount+0x85e mount(c71aab60,e5b07d14,c03590ba,409,4) at mount+0xb8 syscall(2f,2f,2f,bfbfeffc,bfbff9f4) at syscall+0x22e Xint0x80_syscall() at Xint0x80_syscall+0x1d db> trace 939 mi_switch(c74260d0,50,c03375c6,c7,1cc) at mi_switch+0x158 msleep(c74ffd7c,c03a9688,50,c034f732,0) at msleep+0x3b4 acquire(c74ffd7c,140,600,e6,3ab) at acquire+0xa7 lockmgr(c74ffd7c,1010002,c74ffcb8,c74260d0,e5bfd83c) at lockmgr+0x2f7 vop_stdlock(e5bfd858,e5bfd874,c021e306,e5bfd858,246) at vop_stdlock+0x2c ufs_vnoperate(e5bfd858,246,0,c74f1000,0) at ufs_vnoperate+0x18 vn_lock(c74ffcb8,10002,c74260d0,7f,3) at vn_lock+0xd6 vget(c74ffcb8,10002,c74260d0,7f,c74260d0) at vget+0xd6 ufs_ihashget(c74cce00,3,2,e5bfd98c,e5bfd8f0) at ufs_ihashget+0xd2 ffs_vget(c74c5400,3,2,e5bfd98c,e5bfd994) at ffs_vget+0x44 ufs_lookup(e5bfdac0,e5bfdafc,c0207a24,e5bfdac0,e5bfdc3c) at ufs_lookup+0xdae ufs_vnoperate(e5bfdac0,e5bfdc3c,e5bfdc50,3ab,c74260d0) at ufs_vnoperate+0x18 vfs_cache_lookup(e5bfdb70,e5bfdb9c,c020bd39,e5bfdb70,c7509818) at vfs_cache_lookup+0x2e4 ufs_vnoperate(e5bfdb70,c7509818,e5bfdc50,e5bfdb5c,c74260d0) at ufs_vnoperate+0x18 lookup(e5bfdc28,0,c033d6ad,a4,c74260d0) at lookup+0x309 namei(e5bfdc28,c03ade38,c03ade10,c03b42a0,0) at namei+0x1e0 lstat(c74260d0,e5bfdd14,c03590ba,409,2) at lstat+0x52 syscall(2f,2f,2f,80d3200,80d1040) at syscall+0x22e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (190, FreeBSD ELF32, lstat), eip = 0x805838b, esp = 0xbfbff3dc, ebp = 0xbfbff468 --- db> trace 1133 mi_switch(c6d31680,50,c03375c6,c7,2) at mi_switch+0x158 msleep(c75098dc,c03a9358,50,c034f732,0) at msleep+0x3b4 acquire(c75098dc,140,600,e6,46d) at acquire+0xa7 lockmgr(c75098dc,1030002,c7509818,c6d31680,e3887ad0) at lockmgr+0x2f7 vop_stdlock(e3887aec,e3887b08,c021e306,e3887aec,0) at vop_stdlock+0x2c ufs_vnoperate(e3887aec,0,c033e1ac,360,c01e3af0) at ufs_vnopera
Re: dump(8) + UFS2
At 10:56 AM 11/30/2002 -0200, Daniel C. Sobral wrote: >Matthias Schuendehuette wrote: >> >> Hello, >> >> it seems to me that 'dump' (8) is not able to dump UFS2 Filesystems. >> >> First it shows an extraordirarily large number of estimated tape blocks >> for my tiny /var-partition and after that it dumps core while trying to >> dump my not so tiny /usr partition. >> >> Is this a known issue? Are there any recommendations how to backup UFS2 >> filesystems reliably? > >Well, I once restored something to UFS2 (converting my partitions...). >It was quite funny to see 102.7% was complete, and it would end in 0 >(minutes, one assume). > Here are further messages from console when trying to dump UFS2 It seems like a controller error also: (da0:ahc0:0:0:0): Unretryable error (da0:ahc0:0:0:0): READ(10). CDB: 28 0 b3 9b 97 60 0 0 1 0 (da0:ahc0:0:0:0): CAM Status: SCSI Status Error (da0:ahc0:0:0:0): SCSI Status: Check Condition (da0:ahc0:0:0:0): ILLEGAL REQUEST asc:21,0 (da0:ahc0:0:0:0): Logical block address out of range field replaceable unit: 3: Command byte 2 bit 7 is invalid Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: system locks with vnode backed md(4)
Ok, I got another one. DDB output attached. I did all kinds of operations to trigger it - had 3 md mounted from the same dir, in 2 of them doing my ports.tgz torture test and in root file system I had 'find . -inum 1231231' running. One find finished succesfully but then it finally locked-up. > Yeah, vnode locks and other lockmgr locks don't show up in 'show locks', > since only SMPng locking primitives are tracked by WITNESS. I see. > There are a fair number of vnode locking deadlock scenarios that are > unavoidable where we rely on grabbing vnode locks out of the directory > structure lock order. This occurs for vnode-backed md devices, quotas, > and UFS1 extended attributes, and probably some other situations. I > suspect that Terry is correct that operations on the vnode backing file > storage directory are triggering the problem, since that increases the > chances that a vnode lock "race to root" will occur from both the file > system backed into the md device, and for the md backing vnodes during > blocking I/O. If you can avoid directory operations on the md backing > directory, that would probably be one way to avoid triggering the bug. I'm afraid this doesn't sound too good for me. > Seeing it reproduced would probably confirm that this is the case. On the > other hand, there may be other deadlocks in the vnode/ufs/md code that can > be more easily corrected than this general VFS problem, so details there > would be very useful. May be the attached one will allow someone to track something down. PS: Sorry if you have problems with attachment, I myself find them difficult to read (I'm receivind digest of this list - isn't there a possibility to have it in mime form (like Buqtraq and others)? -- Michal Mertl [EMAIL PROTECTED] db> show lockedvnods Locked vnodes 0xc3ef8b90: tag ufs, type VDIR, usecount 1, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 1993 ino 6593, on dev ad0s1a (4, 4) 0xc3efea68: tag ufs, type VREG, usecount 2, writecount 0, refcount 0, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 599 ino 6596, on dev ad0s1a (4, 4) 0xc4ac7818: tag devfs, type VCHR, usecount 1297, writecount 0, refcount 30, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by pid 8 0xc574f250: tag ufs, type VREG, usecount 2, writecount 1, refcount 8, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 1919 ino 7, on dev ad0s2e (4, 10) 0xc3f3c940: tag ufs, type VREG, usecount 2, writecount 1, refcount 225, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 439 ino 3, on dev ad0s2e (4, 10) 0xc559d940: tag ufs, type VREG, usecount 0, writecount 0, refcount 0, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 1965 ino 4, on dev ad0s2e (4, 10) 0xc5c84cb8: tag ufs, type VREG, usecount 2, writecount 1, refcount 426, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 810 ino 5, on dev ad0s2e (4, 10) 0xc4a5a000: tag ufs, type VDIR, usecount 0, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 1990 ino 96988, on dev md0 (4, 12) 0xc444f128: tag ufs, type VDIR, usecount 1, writecount 0, refcount 2, lock type ufs: EXCL (count 1) by pid 1964 ino 14330, on dev md0 (4, 12) 0xc4454818: tag ufs, type VNON, usecount 1, writecount 0, refcount 0, lock type ufs: EXCL (count 1) by pid 1964 ino 14336, on dev md0 (4, 12) 0xc5183de0: tag ufs, type VDIR, usecount 0, writecount 0, refcount 2, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 1992 ino 5090, on dev md1 (4, 14) db> show locks exclusive sleep mutex Giant r = 0 (0xc0399660) locked @ ../../../kern/kern_intr.c:534 db> ps pid proc addruid ppid pgrp flag stat wmesgwchan cmd 1993 c4819938 e17970000 1737 1993 0004002 norm[SLPQ newbuf c03ede10][SLP] find 1992 c481b3b0 e179c0000 547 1992 0004002 norm[SLPQ getblk ce3eabb8][SLP] rm 1990 c4819b10 e17980000 1962 1990 0004002 norm[SLPQ getblk ce2d1ba4][SLP] cp 1965 c4819000 e174e0000 1964 1964 0006002 norm[SLPQ newbuf c03ede10][SLP] gzip 1964 c481b938 e179f0000 436 1964 0004002 norm[SLPQ biord ce2f743c][SLP] tar 1962 c4b57000 e17c30000 1958 1962 2004002 norm[SLPQ pause e17c3000][SLP] csh 1958 c4b571d8 e17c4000 1001 1779 1958 0004102 norm[SLPQwait c4b571d8][SLP] su 1919 c48193b0 e175e0000 0 0 204 norm[SLPQ newbuf c03ede10][SLP] md2 1779 c4819588 e175f000 1001 1778 1779 2004002 norm[SLPQ pause e175f000][SLP] tcsh 1778 c4b59000 e17cb000 1001 1775 360 100 norm[CVQ select c039cbe4][SLP] sshd 1775 c4b59588 e18040000 360 360 100 norm[SLPQ sbwait c3f00e64][SLP] sshd 1737 c4b591d8 e17cc0000 1736 1737 2004002 norm[SLPQ pause e17cc000][SLP] csh 1736 c48191d8 e174f000 1001 458 1736 0004102 norm[SLPQwait c48191d8][SLP] su 810 c4b57ce8 e17ca0000 0 0
newfs chokes, cores, & dies if inode density too high; patch attached
Date: Fri, 1 Nov 2002 00:43:38 + From: Ceri Davies <[EMAIL PROTECTED]> To: David Wolfskill <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: newfs chokes, cores, & dies if inode density too high; patch attached In-Reply-To: <[EMAIL PROTECTED]> I don't have time to test this right now, but see also PR bin/30959. Ceri -- you can't see when light's so strong you can't see when light is gone Better late than never, this bug has been fixed. From: Kirk McKusick <[EMAIL PROTECTED]> Date: Sat, 30 Nov 2002 10:28:26 -0800 (PST) To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/sbin/newfs mkfs.c newfs.c mckusick2002/11/30 10:28:26 PST Modified files: sbin/newfs mkfs.c newfs.c Log: Add some more checks to newfs so that it will not build filesystems that the kernel will refuse to mount. Specifically it now enforces the MAXBSIZE blocksize limit. This update also fixes a problem where newfs could segment fault if the selected fragment size was too large. PR: bin/30959 Submitted by: Ceri Davies <[EMAIL PROTECTED]> Sponsored by: DARPA & NAI Labs. Revision ChangesPath 1.66 +24 -14src/sbin/newfs/mkfs.c 1.66 +5 -1 src/sbin/newfs/newfs.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dump(8) + UFS2
At 10:56 AM 11/30/2002 -0200, Daniel C. Sobral wrote:
>Matthias Schuendehuette wrote:
>>
>> Hello,
>>
>> it seems to me that 'dump' (8) is not able to dump UFS2 Filesystems.
>>
>> First it shows an extraordirarily large number of estimated tape blocks
>> for my tiny /var-partition and after that it dumps core while trying to
>> dump my not so tiny /usr partition.
>>
>> Is this a known issue? Are there any recommendations how to backup UFS2
>> filesystems reliably?
>
>Well, I once restored something to UFS2 (converting my partitions...).
>It was quite funny to see 102.7% was complete, and it would end in 0
>(minutes, one assume).
I just converted my /var and /usr partitions to UFS2 on an i386 machine
and tried to do a dump of /var (500mb -- 37mb used)
(disklabel)594}dump 0fua /dev/nsa0 /dev/da0s1e
DUMP: Date of this level 0 dump: Sat Nov 30 10:16:44 2002
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/da0s1e (/var) to /dev/nsa0
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: read error from /dev/da0s1e: Input/output error: [block -7236860474136607228]:
count=8192
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607228]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607227]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607226]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607225]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607224]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607223]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607222]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607221]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607220]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607219]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607218]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607217]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607216]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607215]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607214]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-7236860474136607213]: count=512
DUMP: corrupted directory, inumber 5169
DUMP: read error from /dev/da0s1e: Input/output error: [block -3126763002007185064]:
count=8192
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185064]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185063]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185062]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185061]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185060]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185059]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185058]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185057]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185056]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185055]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185054]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185053]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185052]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185051]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185050]: count=512
DUMP: read error from /dev/da0s1e: Input/output error: [sector
-3126763002007185049]: count=512
DUMP: corrupted directory, inumber 5169
DUMP: corrupted directory, inumber 5169
DUMP: corrupted directory, inumber 5596
DUMP: read error from /dev/da0s1e: Input/output error: [block -8093102966837667782]:
count=8192
DUMP: More than 32 block read errors from /dev/da0s1e
DUMP: This is an unrecoverable error.
DUMP: Do you want to attempt to continue?: ("yes" or "no") no
DUMP: The ENTIRE dump is aborted.
I guess dump is not ready for UFS2
==
|| [EMAIL PROTECTED] ||
|| Ph.
Re: system locks with vnode backed md(4)
On Sat, 30 Nov 2002, Michal Mertl wrote: > I'm now unable to make it dead-lock again. Yet it happened quite easily. > I had more md backing files in the same directory at the beginning (to > test Terry's suspicion mentioned in thread 'jail' on hackers@). I've noticed that chroot() environments tend to make existing deadlock opportunities more likely. I'm not quite sure why that is. :-) > I'll try to get more problems and get more info (show lockedvnods, show > locks). > > show locks with first dead-lock showed only Giant AFAIR. Yeah, vnode locks and other lockmgr locks don't show up in 'show locks', since only SMPng locking primitives are tracked by WITNESS. There are a fair number of vnode locking deadlock scenarios that are unavoidable where we rely on grabbing vnode locks out of the directory structure lock order. This occurs for vnode-backed md devices, quotas, and UFS1 extended attributes, and probably some other situations. I suspect that Terry is correct that operations on the vnode backing file storage directory are triggering the problem, since that increases the chances that a vnode lock "race to root" will occur from both the file system backed into the md device, and for the md backing vnodes during blocking I/O. If you can avoid directory operations on the md backing directory, that would probably be one way to avoid triggering the bug. Seeing it reproduced would probably confirm that this is the case. On the other hand, there may be other deadlocks in the vnode/ufs/md code that can be more easily corrected than this general VFS problem, so details there would be very useful. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: system locks with vnode backed md(4)
On Sat, 30 Nov 2002, Michal Mertl wrote: Including rwatson because of the thread on hackers@. Sorry for follow-up to myself. > Recently there was a discussion about jails on some freebsd list. Someone > recommended vnconfig(8)ed file-backed disk for jail file systems. Terry > wrote there are problems with it. I liked the idea and played with > mdconfig(8)ed devices on current. Terry was right - I can easily make the > system deadlock. I really like the idea of jails in vnode-backed I'm now unable to make it dead-lock again. Yet it happened quite easily. I had more md backing files in the same directory at the beginning (to test Terry's suspicion mentioned in thread 'jail' on hackers@). After the first lock-up I tried 'while(1);tar xzf ports.tgz; rm -rf ports;end' on normal filesystem, let it run for long time (> 1h) and then I found the system almost dead-locked too (the system worked, but anything accessing disk was painfully slow - it might be the same problem or it might be different. It never ended (at least for > ~30 mins when I didn't (weren't able) anything on it). syncer and bufdaemon and others were in wdrain. Disk as seen in systat -v showed maximal usage yet no inodes were resolved. Sometimes during that test I had lock order reversal: ../../../kern/kern_synch.c:152: sleeping with "mntvnode" locked from ../../../kern/vfs_subr.c:3016 lock order reversal 1st 0xc03a0aa0 mntvnode (mntvnode) @ ../../../kern/vfs_subr.c:3016 The 2nd isn't unfortunately saved in logs but it was Giant. I'll try to get more problems and get more info (show lockedvnods, show locks). show locks with first dead-lock showed only Giant AFAIR. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
unkillable process - 'mdconfig -t vnode' on small file
Subject says it all.
I wanted to make vnode-backed md(4) and forgot to specify size, thas it
after 'touch mdfile;mdconfig -a -t vnode -f mdfile' mdconfig process can't
be killed. It's wchan ('ps axO wchan|grep mdconf') is mddest.
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Are SysV semaphores thread-safe on CURRENT?
On Sat, 30 Nov 2002, Daniel Eischen wrote:
> On Sat, 30 Nov 2002, Brian Smith wrote:
>
> > On Mon, 18 Nov 2002 22:05:34 -0800, Terry Lambert wrote:
> >
> > >Use mmap of a backing-store file, and then use file locking to
> > >do record locking in the shared memory segment.
> >
> > Ok, I did this, and it actually works considerably better than
> > the SysV shared memory. However flock() has the same problem
> > as the SysV semaphores, where they block the entire process,
> > allowing the same deadlock situation to occur. Has this flock()
> > behavior changed in CURRENT?
>
> No, libc_r doesn't properly handle flock. Usually, all syscalls
> that take file descriptors as arguments honor the non-blocking
> mode of the file if set. I guess flock(2) doesn't and has its
> own option to the operation argument (LOCK_NB).
>
> I hacked libc_r to periodically check (every 100msecs) the
> flock. See if this fixes things:
Oops, I had the wrong operators. See below.
> --
> Dan Eischen
>
> Index: lib/libc_r/uthread/uthread_flock.c
> ===
> RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_flock.c,v
> retrieving revision 1.10
> diff -u -r1.10 uthread_flock.c
> --- lib/libc_r/uthread/uthread_flock.c10 Apr 2001 04:19:20 - 1.10
> +++ lib/libc_r/uthread/uthread_flock.c30 Nov 2002 16:23:59 -
> @@ -32,6 +32,7 @@
> * $FreeBSD: src/lib/libc_r/uthread/uthread_flock.c,v 1.10 2001/04/10 04:19:20
>deischen Exp $
> */
> #include
> +#include
> #include
> #include "pthread_private.h"
>
> @@ -40,10 +41,40 @@
> int
> _flock(int fd, int operation)
> {
> - int ret;
> + struct pthread *curthread;
> + struct timespec ts;
> + int ret;
>
> if ((ret = _FD_LOCK(fd, FD_RDWR, NULL)) == 0) {
> - ret = __sys_flock(fd, operation);
> + if ((operation & LOCK_NB) != 0) {
> + ret = __sys_flock(fd, operation);
> + }
> + else {
> + curthread = _get_curthread();
> + ts.tv_sec = 0;
> + ts.tv_nsec = 1; /* 100msecs */
> + while (((ret = __sys_flock(fd, operation | LOCK_NB)) == 0)
> + || (errno == EWOULDBLOCK)) {
The above two lines should be:
while (((ret = __sys_flock(fd, operation | LOCK_NB)) != 0)
&& (errno == EWOULDBLOCK)) {
> + curthread->data.fd.fd = fd;
> + _thread_kern_set_timeout(&ts);
> +
> + /* Reset the interrupted operation flag: */
> + curthread->interrupted = 0;
> +
> + _thread_kern_sched_state(PS_SLEEP_WAIT,
> + __FILE__, __LINE__);
> +
> + /*
> + * Check if the operation was interrupted
> + * by a signal
> + */
> + if (curthread->interrupted) {
> + errno = EINTR;
> + ret = -1;
> + break;
> + }
> + }
> + }
> _FD_UNLOCK(fd, FD_RDWR);
> }
> return (ret);
>
>
>
> 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: Are SysV semaphores thread-safe on CURRENT?
On Sat, 30 Nov 2002, Brian Smith wrote:
> On Mon, 18 Nov 2002 22:05:34 -0800, Terry Lambert wrote:
>
> >Use mmap of a backing-store file, and then use file locking to
> >do record locking in the shared memory segment.
>
> Ok, I did this, and it actually works considerably better than
> the SysV shared memory. However flock() has the same problem
> as the SysV semaphores, where they block the entire process,
> allowing the same deadlock situation to occur. Has this flock()
> behavior changed in CURRENT?
No, libc_r doesn't properly handle flock. Usually, all syscalls
that take file descriptors as arguments honor the non-blocking
mode of the file if set. I guess flock(2) doesn't and has its
own option to the operation argument (LOCK_NB).
I hacked libc_r to periodically check (every 100msecs) the
flock. See if this fixes things:
--
Dan Eischen
Index: lib/libc_r/uthread/uthread_flock.c
===
RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_flock.c,v
retrieving revision 1.10
diff -u -r1.10 uthread_flock.c
--- lib/libc_r/uthread/uthread_flock.c 10 Apr 2001 04:19:20 - 1.10
+++ lib/libc_r/uthread/uthread_flock.c 30 Nov 2002 16:23:59 -
@@ -32,6 +32,7 @@
* $FreeBSD: src/lib/libc_r/uthread/uthread_flock.c,v 1.10 2001/04/10 04:19:20
deischen Exp $
*/
#include
+#include
#include
#include "pthread_private.h"
@@ -40,10 +41,40 @@
int
_flock(int fd, int operation)
{
- int ret;
+ struct pthread *curthread;
+ struct timespec ts;
+ int ret;
if ((ret = _FD_LOCK(fd, FD_RDWR, NULL)) == 0) {
- ret = __sys_flock(fd, operation);
+ if ((operation & LOCK_NB) != 0) {
+ ret = __sys_flock(fd, operation);
+ }
+ else {
+ curthread = _get_curthread();
+ ts.tv_sec = 0;
+ ts.tv_nsec = 1; /* 100msecs */
+ while (((ret = __sys_flock(fd, operation | LOCK_NB)) == 0)
+ || (errno == EWOULDBLOCK)) {
+ curthread->data.fd.fd = fd;
+ _thread_kern_set_timeout(&ts);
+
+ /* Reset the interrupted operation flag: */
+ curthread->interrupted = 0;
+
+ _thread_kern_sched_state(PS_SLEEP_WAIT,
+ __FILE__, __LINE__);
+
+ /*
+* Check if the operation was interrupted
+* by a signal
+*/
+ if (curthread->interrupted) {
+ errno = EINTR;
+ ret = -1;
+ break;
+ }
+ }
+ }
_FD_UNLOCK(fd, FD_RDWR);
}
return (ret);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Problem with ntpdate
On Sat, 30 Nov 2002, Daniel C. Sobral wrote: > Giorgos Keramidas wrote: > > > > On 2002-11-28 17:00, "Daniel C. Sobral" <[EMAIL PROTECTED]> wrote: > > > I found out that ntpdate just doesn't seem to be working at all > > > during boot. Ntpd dies because of the time differential (windows > > > changes the time two hours because of the TZ). No message from > > > ntpdate (I'll next try to divert it to syslog). > > > > You could always fix the broken date in the CMOS setup. This will > > always work, and it won't make already started processes behave in > > unexpected ways because of the sudden clock change when ntpdate > > changes the time :-/ > > What? Enter BIOS setup and fix the clock each time I alternate between > Windows and FreeBSD? Just because something in the boot isn't working > correctly? Now, this is just my machine, and besides my getting the You could use the same time under FreeBSD as under Windows (local time). Then you would only have to fix the clock at most twice a year when both Windows and FreeBSD adjust it for DST. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: X11, KDE, WM, Gnome and current
I have no problems at all running KDE on DP2. Did you load a sound driver? The complaints about /dev/dsp not existing seem to indicate that you didn't load a sound driver. You might want to check your XF86Config file again, because I'm sure you can find an explanation for the default resolution thing there. Good luck, Arjan On Saturday 30 November 2002 12:45, Cliff Sarginson wrote: > I rebuilt the whole of KDE on DP2 (upto date as of a couple of days > ago). Apart from me growing older in the process nothing worked well, > despite using the same configuration as on 4.7. > - It starts but no sound arises > - The mouse moves, responds to clicks sometimes, but when I bring up the > menu and move the mouse it brings up the box asking what command you > want to run. > - Lots of errors reported about bad file descriptors. > - Gives a default resolution that is not the one I set. > - I.e unusable. > > Windowmaker does not work, either...sort of similarly. Also says > /dev/dsp does not exist. > > Gnome ... well it bitched about the window manager, but otherwise showed > similar symptoms to KDE. > > I think the problem must lie in X itself. > > Well it exercised DP2 pretty well in building it. > But it did not produce a usable GUI in all 3 cases. > > System is 512MB, PIII 1Ghz, Matrox G450 AGP, Soundblaster Live! Value. > Plus Logitech Cordless USB Optical Mouse. > > Am I being premature, there does not seem to be a KDE Package for 5.0. > When I tried to fetch it all I got was one file, that new groovy theme > that KDE comes with. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Are SysV semaphores thread-safe on CURRENT?
On Mon, 18 Nov 2002 22:05:34 -0800, Terry Lambert wrote: >Use mmap of a backing-store file, and then use file locking to >do record locking in the shared memory segment. Ok, I did this, and it actually works considerably better than the SysV shared memory. However flock() has the same problem as the SysV semaphores, where they block the entire process, allowing the same deadlock situation to occur. Has this flock() behavior changed in CURRENT? It seems like this behavior is much more likely to change than the SysV code. Thanks! Brian Smith To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with ntpdate
"Daniel C. Sobral" wrote: > Giorgos Keramidas wrote: > > On 2002-11-28 17:00, "Daniel C. Sobral" <[EMAIL PROTECTED]> wrote: > > > I found out that ntpdate just doesn't seem to be working at all > > > during boot. Ntpd dies because of the time differential (windows > > > changes the time two hours because of the TZ). No message from > > > ntpdate (I'll next try to divert it to syslog). If you want to add code to fix this, it's trivial: 1) Read the CMOS clock directly 2) Read the CMOS clock via vm86() 3) If there is a difference measured in round units, apply it as an adjustment to the value each time you read directly. Problem solved. Basically, it comes down to initializing an integer at boot time via a SYSCONFIG() created for that purpose. Personally, I don't have any boxes with a BIOS that's still broken. I used to have one, but I disassembled it with Frank van Gilluwe's "Sourcer", hacked the timezone adjustment out of the code, assembled the new code with MASM, and burnt some new PROMs for it. That was back in 1997. If you are looking for advice, my advice is to fix your BIOS... it's easier. 8-). Otherwise, it wouldn't be hard at all to hack the described fix into machdep.c, to make FreeBSD more tolerant of broken hardware (always one in the "plus" column). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with ntpdate
Giorgos Keramidas wrote: > > On 2002-11-28 17:00, "Daniel C. Sobral" <[EMAIL PROTECTED]> wrote: > > I found out that ntpdate just doesn't seem to be working at all > > during boot. Ntpd dies because of the time differential (windows > > changes the time two hours because of the TZ). No message from > > ntpdate (I'll next try to divert it to syslog). > > You could always fix the broken date in the CMOS setup. This will > always work, and it won't make already started processes behave in > unexpected ways because of the sudden clock change when ntpdate > changes the time :-/ What? Enter BIOS setup and fix the clock each time I alternate between Windows and FreeBSD? Just because something in the boot isn't working correctly? Now, this is just my machine, and besides my getting the lunch time wrong and seeing weird times in mail, this isn't much of an issue. But having once been responsible for mere ~35 machines, I *assure* you that either the OS Does The Right Thing during boot, or you are in for a LOT of trouble. And just to repeat, so I'm not misunderstood, the tcp changes in current might or might not be a contributing factor in my problem, but the real culprit turned out to be the network, not FreeBSD. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "Fundamentalist Debianites, core children of the Linuxen sounds like it could come from the Book of Mormon, or Tolkien on a bad day..." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dump(8) + UFS2
Matthias Schuendehuette wrote: > > Hello, > > it seems to me that 'dump' (8) is not able to dump UFS2 Filesystems. > > First it shows an extraordirarily large number of estimated tape blocks > for my tiny /var-partition and after that it dumps core while trying to > dump my not so tiny /usr partition. > > Is this a known issue? Are there any recommendations how to backup UFS2 > filesystems reliably? Well, I once restored something to UFS2 (converting my partitions...). It was quite funny to see 102.7% was complete, and it would end in 0 (minutes, one assume). -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "Fundamentalist Debianites, core children of the Linuxen sounds like it could come from the Book of Mormon, or Tolkien on a bad day..." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
system locks with vnode backed md(4)
Recently there was a discussion about jails on some freebsd list. Someone
recommended vnconfig(8)ed file-backed disk for jail file systems. Terry
wrote there are problems with it. I liked the idea and played with
mdconfig(8)ed devices on current. Terry was right - I can easily make the
system deadlock. I really like the idea of jails in vnode-backed
filesystems - it performs really well (with small files at least) and it's
a pity it can't really be used. I also assume one may encounter the same
dadlock using vnode backed swap which is recommended all over the place.
I tried to measure performance a bit ('time tar xzf ports.tgz' and 'time
rm -rf ports' on real filesystem and it vnode backed one). I got the
system to lock-up. I am able to get to DDB so I'm posting 'ps' output
here.
To recreate the problem use something like this (but for first dadlock I
wasn't stressing the system that much - I just used it):
mdconfig -a -t vnode -f /some/path/file -s 500m
newfs -U /dev/md0
mount /dev/md0 /some/mount/point
cd /some/mount/point
while (1)
tar xzf /path/to/ports.tgz
rm -rf ports
end
DDB 'ps' output when the system is deadlocked (sorry for the line-wrap):
pid proc addruid ppid pgrp flag stat wmesgwchan cmd
537 c403a000 e1722000 1001 533 537 812 norm[SLPQ newbuf
c03ede10][SLP] tcsh
533 c403a1d8 e1723000 1001 532 533 0004002 norm[SLPQ ppwait
c403a1d8][SLP] tcsh
532 c403a3b0 e1724000 1001 529 359 100 norm[CVQ select
c039cbe4][SLP] sshd
529 c403c000 e1760 359 359 100 norm[SLPQ sbwait
c3f00764][SLP] sshd
528 c403a588 e17250000 527 527 0006002 norm[SLPQ newbuf
c03ede10][SLP] gzip
527 c3e4a760 e04e0 454 527 0004002 norm[SLPQ getblk
ce4140f4][SLP] tar
526 c403c3b0 e1762000 1001 521 526 0004002 norm[SLPQ newbuf
c03ede10][SLP] find
521 c403c1d8 e1761000 1001 520 521 2004002 norm[SLPQ pause
e1761000][SLP] tcsh
520 c3f3d760 e1701000 1001 517 359 100 norm[CVQ select
c039cbe4][SLP] sshd
517 c403ace8 e175f0000 359 359 100 norm[SLPQ sbwait
c3f00b64][SLP] sshd
507 c403a938 e175d0000 0 0 204 norm[SLPQ newbuf
c03ede10][SLP] md0
454 c3f3d3b0 e16ff0000 453 454 2004002 norm[SLPQ pause
e16ff000][SLP] csh
453 c3f3d000 e16fd000 1001 446 453 0004102 norm[SLPQwait
c3f3d000][SLP] su
446 c3e4ab10 e04e2000 1001 445 446 2004002 norm[SLPQ pause
e04e2000][SLP] tcsh
445 c3f3db10 e1703000 1001 442 359 100 norm[CVQ select
c039cbe4][SLP] sshd
442 c3f3d938 e17020000 359 359 100 norm[SLPQ sbwait
c3f00264][SLP] sshd
440 c3f3d1d8 e16fe0000 1 440 0004002 norm[SLPQ ttyin
c3fbb410][SLP] getty
439 c3e4d3b0 e051c0000 1 439 0004002 norm[SLPQ ttyin
c3fbb810][SLP] getty
438 c3e4d588 e051d0000 1 438 0004002 norm[SLPQ ttyin
c3fbbc10][SLP] getty
437 c3e4d760 e051e0000 1 437 0004002 norm[SLPQ ttyin
c3f39010][SLP] getty
436 c3e4d938 e051f0000 1 436 0004002 norm[SLPQ ttyin
c3f38810][SLP] getty
435 c3e4db10 e0520 1 435 0004002 norm[SLPQ ttyin
c3ef9c10][SLP] getty
434 c3e4dce8 e05210000 1 434 0004002 norm[SLPQ ttyin
c3f38410][SLP] getty
432 c3d27ce8 e04d30000 1 432 0004002 norm[SLPQ ttyin
c1201010][SLP] getty
424 c3f3d588 e1700 1 424 000 norm[SLPQ nanslp
c03c8e34][SLP] cron
359 c3e4a1d8 e04dd0000 1 359 100 norm[CVQ select
c039cbe4][SLP] sshd
209 c3e4a000 e04dc0000 1 209 000 norm[CVQ select
c039cbe4][SLP] syslogd
33 c3e4ace8 e04e30000 0 0 204 norm[SLPQ vlruwt
c3e4ace8][SLP] vnlru
9 c3e4d000 e051a0000 0 0 204 norm[SLPQ newbuf
c03ede10][SLP] syncer
8 c3e4d1d8 e051b0000 0 0 204 norm[SLPQ newbuf
c03ede10][SLP] bufdaemon
7 c3cc0588 d781b0000 0 0 20c norm[SLPQ pgzero
c03ef2a4][SLP] pagezero
6 c3cc0760 d78520000 0 0 204 norm[SLPQ psleep
c03ef2bc][SLP] vmdaemon
5 c3cc0938 d78530000 0 0 204 norm[SLPQ psleep
c03a9718][SLP] pagedaemon
32 c3cc0b10 d78540000 0 0 204 new [IWAIT] irq8: rtc
31 c3cc0ce8 d78550000 0 0 204 new [IWAIT] irq0: clk
30 c3d27000 e04cc0000 0 0 204 new [IWAIT] irq4: sio0
29 c3d271d8 e04cd0000 0 0 204 norm[IWAIT] swi0: tty:sio
28 c3d273b0 e04ce0000 0 0 204 norm[CPU 0] irq1: atkbd0
27 c3d27588 e04cf0000 0 0 204 new [IWAIT] irq15: ata1
26 c3d27760 e04d0 0 0 204 norm[IWAIT] irq14: ata0
25 c3d27938 e04d10000 0 0 204 new [IWAIT] irq5: pcm0
24 c120e1d8 d6640 0 0 204 norm[IWAIT] irq10: rl0
bktr3+++
23 c120e3b0 d66410000 0 0 204 new [IWAIT] irq6: bktr2
bktr5++
22 c120e588 d66420000 0 0 204 new [IWAIT] irq7: bktr1
bktr4++
21 c120e760 d66430000
Re: [acpi-jp 2004] ACPI errors w/ latest ACPI code on GA BX2000 based system
* Mitsuru IWASAKI ([EMAIL PROTECTED]):
Iwasaki-san,
list members,
> > > ACPI-0438: *** Error: Looking up [FAN_] in namespace, AE_NOT_FOUND
> > > ACPI-1287: *** Error: Method execution failed, AE_NOT_FOUND
>
> I think that this was caused by the following spec changes.
> From CHANGES.txt:
>
> 22 October 2002. Summary of changes for version 20021022.
>
> 1) ACPI CA Core Subsystem:
>
> Implemented a restriction on the Scope operator that the
> target must already exist in the namespace at the time the
> operator is encountered (during table load or method
> execution). In other words, forward references are not
> allowed and Scope() cannot create a new object. This changes
> the previous behavior where the interpreter would create the
> name if not found. This new behavior correctly enables the
> search-to-root algorithm during namespace lookup of the target
> name. Because of this upsearch, this fixes the known Compaq
> _SB_.OKEC problem and makes both the AML interpreter and iASL
> compiler compatible with other ACPI implementations.
>
>
> Could you send your acpidump output to this acpi-jp ML?
Of course. And thank you very much for working on this. Please see the
attached file.
--Thomas
/*
RSD PTR: Checksum=226, OEMID=COMPAQ, RsdtAddress=0x0fff3000
*/
/*
RSDT: Length=40, Revision=1, Checksum=17,
OEMID=COMPAQ, OEM Table ID=AWRDACPI, OEM Revision=0x42302e31,
Creator ID=AWRD, Creator Revision=0x0
*/
/*
Entries={ 0x0fff3040 }
*/
/*
DSDT=0xfff30c0
INT_MODEL=PIC
SCI_INT=9
SMI_CMD=0xb2, ACPI_ENABLE=0xa1, ACPI_DISABLE=0xa0, S4BIOS_REQ=0xa4
PM1a_EVT_BLK=0x4000-0x4003
PM1a_CNT_BLK=0x4004-0x4005
PM2_TMR_BLK=0x4008-0x400b
PM2_GPE0_BLK=0x400c-0x400f
P_LVL2_LAT=90ms, P_LVL3_LAT=900ms
FLUSH_SIZE=0, FLUSH_STRIDE=0
DUTY_OFFSET=1, DUTY_WIDTH=0
DAY_ALRM=13, MON_ALRM=0, CENTURY=0
Flags={WBINVD,PROC_C1,SLP_BUTTON}
*/
/*
DSDT: Length=10553, Revision=1, Checksum=88,
OEMID=COMPAQ, OEM Table ID=AWRDACPI, OEM Revision=0x1000,
Creator ID=MSFT, Creator Revision=0x10c
*/
DefinitionBlock (
"acpi_dsdt.aml",//Output filename
"DSDT", //Signature
0x1,//DSDT Revision
"COMPAQ", //OEMID
"AWRDACPI", //TABLE ID
0x1000 //OEM Revision
)
{
Scope(\_PR_) {
Processor(\_PR_.CPU0, 1, 0x4010, 0x6) {
}
}
Name(\_S0_, Package(0x2) {
0x5,
0x5,
})
OperationRegion(CMOS, SystemIO, 0x70, 0x2)
Field(CMOS, ByteAcc, NoLock, Preserve) {
INX_, 8,
DTA_, 8
}
Store(0x8, Local0)
Store(0x54, INX_)
Store(DTA_, Local1)
And(Local1, Local0, Local1)
If(LEqual(Local1, 0x8)) {
Name(\_S3_, Package(0x2) {
0x1,
0x1,
})
}
Else {
Name(\_S1_, Package(0x2) {
0x4,
0x4,
})
}
Name(\_S4_, Package(0x2) {
Zero,
Zero,
})
Name(\_S5_, Package(0x2) {
Zero,
Zero,
})
OperationRegion(\DEBG, SystemIO, 0x80, 0x1)
Field(\DEBG, ByteAcc, NoLock, Preserve) {
DBG1, 8
}
OperationRegion(\MUS1, SystemIO, 0x64, 0x1)
Field(\MUS1, ByteAcc, NoLock, Preserve) {
MUSE, 8
}
OperationRegion(EXTM, SystemMemory, 0x000ff830, 0x10)
Field(EXTM, WordAcc, NoLock, Preserve) {
ROM1, 16,
RMS1, 16,
ROM2, 16,
RMS2, 16,
ROM3, 16,
RMS3, 16,
AMEM, 32
}
OperationRegion(VGAM, SystemMemory, 0x000c0002, 0x1)
Field(VGAM, ByteAcc, NoLock, Preserve) {
VGA1, 8
}
OperationRegion(\TRAP, SystemIO, 0x402f, 0x1)
Field(\TRAP, ByteAcc, NoLock, Preserve) {
, 1,
TR13, 1
}
OperationRegion(PMES, SystemIO, 0x4015, 0x1)
Field(PMES, ByteAcc, NoLock, Preserve) {
, 1,
PME_, 1
}
OperationRegion(\GBLE, SystemIO, 0x4021, 0x1)
Field(\GBLE, ByteAcc, NoLock, Preserve) {
ESMI, 8
}
Name(CMDB, Buffer(0x8) { })
CreateByteField(CMDB, 0x0, BYT0)
CreateByteField(CMDB, 0x1, BYT1)
CreateByteField(CMDB, 0x2, BYT2)
CreateByteField(CMDB, 0x3, BYT3)
CreateByteField(CMDB, 0x4, BYT4)
CreateByteField(CMDB, 0x5, BYT5)
CreateByteField(CMDB, 0x6, BYT6)
CreateByteField(CMDB, 0x7, BYT7)
Name(IDEB, Buffer(0x38) { })
CreateField(IDEB, 0x0, 0x38, CMD0)
CreateField(IDEB, 0x38, 0x38, CMD1)
CreateField(IDEB, 0x70, 0x38, CMD2)
CreateField(IDEB, 0xa8, 0x38, CMD3)
CreateField(IDEB, 0xe0, 0x38, CMD4)
CreateField(IDEB, 0x0118, 0x38, CMD5)
CreateField(IDEB, 0x0150, 0x38, CMD6)
CreateField(IDEB, 0x0188, 0x38, CMD7)
OperationRegion(APMP, SystemIO, 0xb2, 0x2)
Field(APMP, ByteAcc, NoLock, Preserve) {
APMC, 8,
APMD, 8
}
OperationRegion(ELCR, SystemIO, 0x04d0, 0x2)
Field(ELCR, ByteAcc, NoLock, Preserve) {
ELC1, 8,
ELC2, 8
}
OperationRegion(GPOB, SystemIO, 0x4034, 0x4)
Field(GPOB, ByteAcc, NoLock, Preserve) {
GP00, 1,
GP01, 1,
GP02, 1,
GP03, 1,
GP04, 1,
GP05, 1,
GP06, 1,
GP07,
Re: X11, KDE, WM, Gnome and current
FWIW, I recently build KDE3 on a 5.0-DP2 notebook. I just copied the /etc/X11/XF86Config from the working 4.7-Stable partition, kld-loaded the pcm sound, and voilà, everything works fine. do you know if your XF86Config is correct ? have you loaded the sound driver ? Cheers, TfH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
X11, KDE, WM, Gnome and current
I rebuilt the whole of KDE on DP2 (upto date as of a couple of days ago). Apart from me growing older in the process nothing worked well, despite using the same configuration as on 4.7. - It starts but no sound arises - The mouse moves, responds to clicks sometimes, but when I bring up the menu and move the mouse it brings up the box asking what command you want to run. - Lots of errors reported about bad file descriptors. - Gives a default resolution that is not the one I set. - I.e unusable. Windowmaker does not work, either...sort of similarly. Also says /dev/dsp does not exist. Gnome ... well it bitched about the window manager, but otherwise showed similar symptoms to KDE. I think the problem must lie in X itself. Well it exercised DP2 pretty well in building it. But it did not produce a usable GUI in all 3 cases. System is 512MB, PIII 1Ghz, Matrox G450 AGP, Soundblaster Live! Value. Plus Logitech Cordless USB Optical Mouse. Am I being premature, there does not seem to be a KDE Package for 5.0. When I tried to fetch it all I got was one file, that new groovy theme that KDE comes with. -- Regards Cliff Sarginson The Netherlands [ This mail has been checked as virus-free ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Update to UFS2 Superblock Format
In message <[EMAIL PROTECTED]>, Kirk McKusick wr ites: >You will have to ask Puol-Henning Kamp, but I do not believe that >he has yet put together a bootstrap for the i386 platform that can >boot from a UFS2 filesystem. As such, I believe that you are >required to have a UFS1 root on the i386 at this time. I have >copied Poul-Henning Kamp so that he can correct me if I am incorrect >on this point. It is possible to boot UFS2 on i386, but the bootblocks are larger than 8k and the foot-shooting potential is therefore over my threshold for something I want to try to rush into 5.0. The basic procedure is: compile boot2 with BOOT2_UFS=yes change the BBSIZE #define in the disklabel program and recompile. Make sure you don't trash your filesystem when you write the new bootblocks. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: usb modem problem
On Thu, Nov 28, 2002 at 11:44:10PM -0700, [EMAIL PROTECTED] wrote: > Hello, > > I am trying to use an usb modem under freebsd. It is detected during boot. > My system is current as of yesterday sources. Dmesg output is attached. > > Modem is recognized as /dev/ugen0 and there is another node /dev/ugen0.1 > > I setup my ppp.conf file to use /dev/ugen0 when I try to use it the result > is below: > test# ppp > Working in interactive mode > Using interface: tun0 > ppp ON test> term > deflink: Entering terminal mode on /dev/ugen0 > Type '~?' for help > ugenpool: no edesc > ugenpool: no edesc > ppp ON test> q > test# ugen0 is a generic raw usb device, which is used as a fallback if no specific driver is available. ugen is not a tty type as expected by ppp. Did you compile ucom and umodem in your kernel? > uhci0: port 0x2440-0x245f irq 11 at >device 31.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 > ugen0: STMicroelectronics USB Communicator, rev 1.00/1.01, addr 2 -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Update to UFS2 Superblock Format
Kirk McKusick wrote: > Ah > No wonder, I tried editing the /sys/boot/i386/boot2/Makefile > to enable UFS2 bootblock but then disklabel complained that > boot2 was too big. I will have to revert to UFS1 > Thanks > Manfred > > You have hit upon the exact problem. UFS2 has a much bigger area > reserved for the boot block, but the programs that set up disk labels > and boot blocks don't know about it yet so assume that they have to > cram into the much smaller UFS1 boot-block area. Seems to be a candidate to explain the disklabel corruption, actually. The disklabel is expected to follow the initial boot code, and preceed the region(s) it describes... Basically, the boot blocks are going to have to know the disklabel offset, as promiscuous knowledge (i.e. hard-wired intot he code). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA patches for PC98 - Please test!
It seems Takahashi Yoshihiro wrote: > In article <[EMAIL PROTECTED]> > Soeren Schmidt <[EMAIL PROTECTED]> writes: > > > I'm trying to get this into 5.0 (I know its late, but life's tough) > > > > This brings ATA support to the PC98 arch will all bells and whistles. > > > > --- sys/conf/files 28 Nov 2002 01:17:48 - 1.738 > > +++ sys/conf/files 28 Nov 2002 20:01:52 - > > @@ -290,6 +290,7 @@ > > dev/asr/asr.c optional asr pci > > dev/ata/ata-all.c optional ata > > dev/ata/ata-isa.c optional ata isa > > +dev/ata/ata-cbus.c optional ata pc98 > > This should be 'dev/ata/ata-cbus.c optional ata isa' and moved into > files.pc98. Well, this gives the exact same behavior, but I'm not religious about it :) > > --- sys/pc98/conf/GENERIC 31 Oct 2002 12:14:05 - 1.220 > > +++ sys/pc98/conf/GENERIC 27 Nov 2002 10:06:46 - > > @@ -78,11 +78,18 @@ > > # Floppy drives > > device fdc > > > > -# IDE controller and disks > > -device wdc 1 > > +# ATA and ATAPI devices > > +device ata > > +device atadisk # ATA disk drives > > +device atapicd # ATAPI CDROM drives > > +device atapifd # ATAPI floppy drives > > +device atapist # ATAPI tape drives > > +optionsATA_STATIC_ID # Static device numbering > > > > +# IDE controller and disks > > +#devicewdc 1 > > # ATAPI devices on wdc > > -device wcd 1 #IDE CD-ROM > > +#devicewcd 1 #IDE CD-ROM > > #devicewfd 1 #IDE Floppy (e.g. LS-120) > > #devicewst 1 #IDE Tape (e.g. Travan) > > What about GENERIC.hints? Good point, it should also be in /boot/loader/device.hints. > > --- /dev/null Fri Nov 29 21:35:31 2002 > > +++ sys/dev/ata/ata-cbus.c Thu Oct 31 19:32:25 2002 > > @@ -0,0 +1,270 @@ > > +/*- > > + * Copyright (c) 2002 Søren Schmidt <[EMAIL PROTECTED]> > > + * All rights reserved. > > The original author of this file is IMAI Takeshi. Where is his > copyright? Excuse me ? I wrote this file, I looked in other pc98 drivers in the tree for hints and style however, if that demands that I put other copyrights in the file let me know... > Where is vaild bank checking code? I'm not sure what you mean here, please explain... > And, what about all atapi-* changes? These changes are needed to > support buggy atapi devices. Are you refering to the old ATAPI CDROM's that think they are disk/floppy devices ? I must remind you that this is NOT based on the PC98 ATA patches floating around, that patch is way to intrusive, and demands way too many changes to the generic code, which IMHO are not nessesary -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
