old laptop panics in agp_generic_attach
Hello! I wanted to take an old laptop with me for a trip, but decided to update the OS on it (it was running 8.1). Long story short, both 11.2 and 12.0 panic on boot... I can boot 8.2 via pxeboot (dmesg attached) off of my server, which is neat, but that's it. When it crashes -- and it does that whether I boot from the local disk or via pxeboot -- it happens so fast, I could not even see, where exactly. Fortunately, an HD-60 video-recording captured the panic: * make_dev_sv * make_dev * agp_generic_attach Are there any boot-time options I can supply to load 12.0 -- and then build custom kernel with a chance of working? -mi Copyright (c) 1992-2011 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-RELEASE #0: Fri Feb 18 02:24:46 UTC 2011 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1000MHz (992.34-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x695 Family = 6 Model = 9 Stepping = 5 Features=0xa7e9f9bf Features2=0x180 real memory = 805306368 (768 MB) avail memory = 767971328 (732 MB) kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.3 (no driver attached) vgapci0: port 0x1800-0x1807 mem 0xe800-0xefff,0xe000-0xe007 irq 9 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 3964k stolen memory agp0: aperture size is 128M vgapci1: mem 0xf000-0xf7ff,0xe008-0xe00f at device 2.1 on pci0 uhci0: port 0x1820-0x183f irq 9 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1840-0x185f irq 9 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1860-0x187f at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xe010-0xe01003ff at device 29.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib1: at device 30.0 on pci0 pci_link5: BIOS IRQ 3 for 2.5.INTA is invalid pci2: on pcib1 cbb0: irq 9 at device 5.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] fwohci0: mem 0xe0211000-0xe02117ff at device 5.1 on pci2 fwohci0: [ITHREAD] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 08:00:46:03:01:7a:95:99 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1068000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 0a:00:46:7a:95:99 fwe0: Ethernet address: 0a:00:46:7a:95:99 fwip0: on firewire0 fwip0: Firewire address: 08:00:46:03:01:7a:95:99 @ 0xfffe, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x, SelfID Count=1, CYCLEMASTER mode fxp0: port 0x3000-0x303f mem 0xe021-0xe0210fff irq 9 at device 8.0 on pci2 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow fxp0: Ethernet address: 08:00:46:b7:cc:24 fxp0: [ITHREAD] ath0: mem 0xe020-0xe020 irq 9 at device 11.0 on pci2 ath0: [ITHREAD] ath0: unable to attach hardware; HAL status 13 device_attach: ath0 attach returned 6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc-0xc,0xd-0xd17ff,0xd8000-0xdbfff,0xdc000-0xd pnpid ORM on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 est0: on cpu0 p4tcc0: on cpu0 Timecounter "TSC" frequency 992335582 Hz quality 800 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at
core dumps onto ZFS
Hello!
Last night I was trying to get KDE5 to start up on my new machine, and a
couple of KDE's processes kept crashing, dumping cores like the one below:
-rw--- 1 mi wheel 45780992 Jul 23 22:28 ksplashqml.core
After, maybe, 10 such rounds -- each generating two core-dump -- ZFS
hung... The machine was otherwise responsive, but any attempts to access
the ZFS filesystems would hang as NFS would, when the remote server
stops responding...
Pressing Ctrl-T would show the process in the state named "zfs".
According to "systat -vm", all four disks involved in the raidz1 were
writing in excess of 100MB/s, so I let it be for a few minutes, but
nothing improved -- and the writes continued...
I pressed Ctrl-Alt-Del, which initiated a shutdown, but the shutdown
hung as well ("some processes would not die") and I had to do a power
cycle...
The sole zpool consists of 4 3TB drives and a 16GB log (on an SSD) thus:
NAME STATE READ WRITE CKSUM
aldan ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
da0 ONLINE 0 0 0
ada1 ONLINE 0 0 0
da2 ONLINE 0 0 0
da1 ONLINE 0 0 0
logs
ada0e ONLINE 0 0 0
It reports no data-errors after reboot. There are multiple filesystems
on it, among them /home. The box is running a very recent
FreeBSD-11/amd64 (r336626). It has 4 Xeon cores and 128GB of RAM. The
pool was created under FreeBSD-10 -- after this incident I upgraded it.
What happened? Thanks! Yours,
-mi
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: error compiling sys/netinet/tcp_syncache.c on i386
On 12.08.2017 19:16, Michael Tuexen wrote: Just my luck -- deciding to update to the latest 10.x today... sys/netinet/tcp_syncache.c:280:50: error: implicit conversion from 'long long' to 'time_t' (aka 'int') changes value from -9223372036854775808 to 0 [-Werror,-Wconstant-conversion] V_tcp_syncache.hashbase[i].sch_last_overflow = INT64_MIN; ~ ^ ./x86/_stdint.h:89:41: note: expanded from macro 'INT64_MIN' #define INT64_MIN (-0x7fffLL-1) Yours, Right... I need to MFC alsohttps://svnweb.freebsd.org/base?view=revision=317244 Will do that tomorrow. Thanks for reminding me... You are welcome, but this means, stable is not currently buildable on i386 -- a Tier1-platform... Is not that monitored for? On the ports side of things, I'd be getting an automated build-failure notice shortly after making a change, that breaks a build... I applied the diff you linked to by hand and the kernel-build moved on, thank you! Yours, -mi -mi ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
error compiling sys/netinet/tcp_syncache.c on i386
Just my luck -- deciding to update to the latest 10.x today... sys/netinet/tcp_syncache.c:280:50: error: implicit conversion from 'long long' to 'time_t' (aka 'int') changes value from -9223372036854775808 to 0 [-Werror,-Wconstant-conversion] V_tcp_syncache.hashbase[i].sch_last_overflow = INT64_MIN; ~ ^ ./x86/_stdint.h:89:41: note: expanded from macro 'INT64_MIN' #define INT64_MIN (-0x7fffLL-1) Yours, -mi ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Nasty state after running out of swap
On 08.06.2016 18:24, Mark Johnston wrote: >> Is it yet to recover from the "out of swap" situation? I'm sure, a >> > reboot will fix everything, but I expected FreeBSD to be better than >> > that... Running 10.3-stable from April 18 here. Thanks! > There was a memory leak in CAM at that point. It's fixed in r299531, but > the vmstat output is needed to verify that this is the problem you're > hitting. Sorry, the system was completely dead by the time I got home to it (no console, ssh-connections hanging after the first handshake)... I reset it and built a new world/kernel, which seem to be working Ok now. Thanks! -mi ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Nasty state after running out of swap
In my absence my desktop managed to run out of memory and had to kill a number of processes: pid 47493 (firefox), uid 105, was killed: out of swap space pid 1665 (thunderbird), uid 105, was killed: out of swap space pid 975 (kdeinit4), uid 105, was killed: out of swap space pid 1344 (mysqld), uid 105, was killed: out of swap space pid 898 (Xorg), uid 0, was killed: out of swap space pid 1430 (pidgin), uid 105, was killed: out of swap space While that's unfortunate in its own right, the current state of the machine is just weird... After the massacre the swap-usage is down to 5% and memory is plentiful. top(1) reports: last pid: 85719; load averages: 0.17, 0.15, 0.11 up 25+21:17:34 16:50:27 123 processes: 1 running, 102 sleeping, 11 stopped, 8 zombie, 1 waiting CPU: 0.1% user, 0.0% nice, 1.8% system, 0.3% interrupt, 97.7% idle Mem: 17M Active, 7276K Inact, 9876M Wired, 10M Cache, 1032M Buf, 28M Free ARC: 1114M Total, 264M MFU, 282M MRU, 69K Anon, 44M Header, 524M Other Swap: 12G Total, 616M Used, 11G Free, 5% Inuse And yet, various commands hang for a while in either pfault or zombie state upon completion. For example, top, when I tried to exit it, hung for about a minute with Ctrl-T reporting: load: 0.13 cmd: top 85718 [pfault] 19.04r 0.00u 0.01s 0% 2532k Why would a machine with so much free memory continue to act this way? Is it yet to recover from the "out of swap" situation? I'm sure, a reboot will fix everything, but I expected FreeBSD to be better than that... Running 10.3-stable from April 18 here. Thanks! -mi ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
DSM TRIM errors from an SSD-drive
Hello! I have an older Dell laptop with an SSD-drive (LITEONIT LCT-256M3S-41 7mm 256GB FDE SRDB). I installed 10.3-RC2 on it and then used ``tunefs -t enable’’ to turn trimming on for all of the filesystems on the drive (/, /home, and /var). Things work, but every once in a while kernel logs the following error: (ada0:ahcich0:0:0:0): DSM TRIM. ACB: 06 01 00 00 00 40 00 00 00 00 01 00 (ada0:ahcich0:0:0:0): CAM status: ATA Status Error (ada0:ahcich0:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (ada0:ahcich0:0:0:0): RES: 51 04 00 01 00 40 00 00 00 00 00 (ada0:ahcich0:0:0:0): Retrying command Any idea, what is happening? Thanks! Yours, -mi ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
cp from NFS to ZFS hung in "fifoor"
I was copying /home from an old server (narawntapu) to a new one (aldan). The narawntapu:/home is mounted on aldan as /mnt with flags ro,intr. On narawntapu /home was simply located on an SSD, but on aldan I created a ZFS filesystem for it. The copying was started thus: root@aldan:/home (435) cp -Rpn /mnt/* . for a while this was proceeding at a decent clip with cp making newnfsreq-uests: load: 0.78 cmd: cp 38711 [newnfsreq] 802.84r 1.57u 140.63s 20% 10768k /mnt/mi/.kde/share/apps/kmail/dimap/.42838394.directory/sent/cur/1219621413.32392.hd8cl:2,S -> ./mi/.kde/share/apps/kmail/dimap/.42838394.directory/sent/cur/1219621413.32392.hd8cl:2,S 100% load: 1.23 cmd: cp 38711 [newnfsreq] 874.19r 1.66u 154.74s 17% 4576k /mnt/mi/.kde/share/apps/kmail/dimap/.42838394.directory/ML/cur/1219595347.32392.rMDFf:2,S -> ./mi/.kde/share/apps/kmail/dimap/.42838394.directory/ML/cur/1219595347.32392.rMDFf:2,S 100% ZFS on the destination compressing and writing stuff out and the traffic between the two ranging from 30 to 50Mb/s (according to systat), but then something happened and the cp-process is now hung: load: 0.55 cmd: cp 38711 [fifoor] 1107.67r 2.09u 194.12s 0% 3300k load: 0.50 cmd: cp 38711 [fifoor] 1112.66r 2.09u 194.12s 0% 3300k load: 0.22 cmd: cp 38711 [fifoor] 1642.37r 2.09u 194.12s 0% 3300k There is nothing in the logs on the new system, but the old one has a number of entries like: Nov 28 10:28:45 narawntapu kernel: sonewconn: pcb 0xf80086231930: Listen queue overflow: 8 already in queue awaiting acceptance (62 occurrences) Nov 28 10:29:45 narawntapu kernel: sonewconn: pcb 0xf80086231930: Listen queue overflow: 8 already in queue awaiting acceptance (50 occurrences) Nov 28 10:30:46 narawntapu kernel: sonewconn: pcb 0xf80086231930: Listen queue overflow: 8 already in queue awaiting acceptance (59 occurrences) Nov 28 10:31:46 narawntapu kernel: sonewconn: pcb 0xf80086231930: Listen queue overflow: 8 already in queue awaiting acceptance (57 occurrences) Nov 28 10:32:46 narawntapu kernel: sonewconn: pcb 0xf80086231930: Listen queue overflow: 8 already in queue awaiting acceptance (68 occurrences) Both systems are largely idle now. I'm not in a hurry -- is anybody interested in investigating it in situ? What is "fifoor" -- does this point to a trouble in the ZFS, the NFS-client, or the NFS-server? Both systems run FreeBSD/amd64 of recent 10.x-vintage. Thanks! -mi ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: cp from NFS to ZFS hung in "fifoor"
On 28.11.2015 17:41, Jilles Tjoelker wrote: > Although cp -R will normally copy a fifo by calling mkfifo at the > destination, it may open one if a regular file is replaced with a fifo > between the time it reads the directory and it copies that file. The sole fifo under /home here was mi/.licq/licq_fifo, created in 2003. I echoed something into it (on the NFS-client side) and the cp-process resumed. I then performed a simple test: 1. Create a fifo in an NFS-exported directory and try to copy it with the -R flag mi@narawntapu:/cache/src (792) mkfifo /green/tmp/test mi@narawntapu:/cache/src (793) cp -Rpn /green/tmp/test /tmp/ mi@narawntapu:/cache/src (794) ls -l /tmp/test prw-r--r-- 1 mi wheel 0 29 лис 00:05 /tmp/test The above worked fine. 2. Now, when I try to do the same thing via an NFS mount, I get the same hang in fifoor: root@aldan:ports/x11/kde4 (475) cp -Rpn /green/tmp/test /tmp/ load: 0.42 cmd: cp 38299 [fifoor] 1.15r 0.00u 0.00s 0% 1868k So, the good news is, this is not ZFS' fault. The bad news is, there is still a bug... Unless, of course, this is some known "feature" of the NFS... Compare, for example, how stat(1) describes the same named pipe from both machines: Local FS: 92 74636334 prw-r--r-- 1 mi wheel 0 0 "Nov 29 00:05:51 2015" "Nov 29 00:05:51 2015" "Nov 29 00:05:51 2015" "Nov 29 00:05:51 2015" 16384 0 0 /green/tmp/test NFS-client: 973143811 74636334 ?rw-r--r-- 1 mi wheel 4294967295 0 "Nov 29 00:05:51 2015" "Nov 29 00:05:51 2015" "Nov 29 00:05:51 2015" "Dec 31 18:59:59 1969" 16384 0 0 /green/tmp/test That question-mark in the node-type (instead of the "p") is, I guess, what confuses cp into trying to read from it instead of creating a fifo. Should I file a PR? Thank you! -mi ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
hyperv fails to build, when "nodevice ata" is set in kernel-config
All my drives here are using ahci and the currently-used 9.2-PRERELEASE kernel sees them thus: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 ada3 at ahcich4 bus 0 scbus4 target 0 lun 0 I'm trying to upgrade to 10.2 getting the following error from buildkernel working with the same kernel-config file as before: /usr/src/sys/dev/hyperv/stordisengage/hv_ata_pci_disengage.c:76:10: fatal error: 'ata_if.h' file not found #include ^ 1 error generated. mkdep: compile failed Please, advise. Thanks! Yours, -mi ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
runtime linker on 9.x/i386: clang vs. gcc
Hello! I'm seeing a strange problem with clang-compiled binaries on 9.x/i386 system. Here it is: if a shared library A needs a symbol provided by a shared library B, libA will fail to load into a process even if the executable is linked with libB. The only fix (work-around?) is to relink libA to explicitly depend on libB. A temporary work-around is to use LD_PRELOAD to list all of the necessary libBs... One example of this is reported in ports/180473 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/180473 -- the libprldap6.so refuses to load because of the symbols it needs from libnspr4.so. For some reason, the fact, that -lnspr4 is linked into the executable (seamonkey or thunderbird), is not sufficient... As the ticket suggests, using gcc46 (Mozilla rejects gcc-4.2.x nowadays) instead of clang solves the problem (though an even better solution is in place since this weekend). Another example is xorg-server, which, for me, can not load some of the drivers because they complain of missing symbols: (EE) Failed to load /opt/lib/xorg/modules/drivers/vboxvideo_drv.so: /opt/lib/xorg/modules/drivers/vboxvideo_drv.so: Undefined symbol DRIFinishScreenInit The DRIFinishScreenInit is provided by libdri.so, which the server also loads... But, somehow, that is not sufficient. Rebuilding vboxvideo_drv.so (provided by emulators/virtualbox-ose-additions http://www.freshports.org/emulators/virtualbox-ose-additions) with the stock cc (gcc-4.2.1) resolves the linking problem -- even if Xorg executable and the libdri.so remain clang-compiled. I am not prepared to argue, whether that's a right or wrong behavior -- but it certainly is inconsistent, because it is only manifested on i386 and only when the compiler is clang. Any thoughts? -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: runtime linker on 9.x/i386: clang vs. gcc
10/14/13 4:31 PM, Dimitry Andric ???(??): There is a problem when clang does tail-call optimization on i386 with PIC in effect, and it emits GOT relocations for the tail-called functions, instead of PLT relocations. In some scenarios, such as with the way X.org does lazy dynamic linking, this can cause problems. See alsohttp://llvm.org/PR15086 (which I unfortunately did not get much response on). Ouch... That seems like a show-stopper for clang-adoption... At least, on i386. For now, a workaround is to recompile the affected .so files with -fno-optimize-sibling-calls (if you are optimizing). Maybe, our clang (both src/ and ports/) should be compiled with that being in effect by default on i386? -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
smbfus: panic on the second attempt to reach unavailable server
Hello!
I have my FreeBSD-server dump nightly backups onto an entertainment device
running embedded Linux.
The device has no NFS-server, but does run Samba (3.0.30). It allows access to
its internal hard-drive, which my server mounts as:
//dune/hdd750_..._32 /dune smbfs rw,noauto,-N,-Ekoi8-u:utf-8
There are two nightly cronjob using dump(8), xz(1), and ccrypt(1) to dump two
important filesystems (/var/spool/imap and /home). The imap one kicks off at
3:11am and the home -- at 3:31am.
This normally works perfectly fine every night, except when somebody
accidentally sits on top of the remote-control of the entertainment device in
the living room -- or somehow else managed to turn the box off. When this
happens, the first dump simply fails, as one would expect:
cannot create /dune/backups/narawntapu.imap.1.Tuesday.dump.xz.cpt: No such
file or directory
DUMP: Date of this level 1 dump: Tue Mar 12 03:11:07 2013
DUMP: Date of last level 0 dump: Wed Mar 6 01:31:07 2013
DUMP: Dumping snapshot of /dev/da0a (/var/spool/imap) to standard output
DUMP: mapping (Pass I) [regular files]
DUMP: Cache 16 MB, blocksize = 65536
DUMP: mapping (Pass II) [directories]
DUMP: estimated 169895 tape blocks.
DUMP: dumping (Pass III) [directories]
DUMP: Broken pipe
DUMP: The ENTIRE dump is aborted.
However, when the second job tries to do the same twenty minutes later, the
machine panics. This morning I was able to get a kernel coredump:
...
#6 0x80750f2f in calltrap () at
/cache/src/sys/amd64/amd64/exception.S:228
No locals.
#7 0x805a46ca in turnstile_broadcast (ts=0x0, queue=0) at
/cache/src/sys/kern/subr_turnstile.c:838
_tid = value optimized out
ts1 = value optimized out
td = value optimized out
#8 0x80550e52 in _mtx_unlock_sleep (m=0xfe0105ecd8f0,
opts=value optimized out, file=value optimized out, line=value
optimized out) at /cache/src/sys/kern/kern_mutex.c:715
ts = (struct turnstile *) 0x0
#9 0x8101a0cd in smb_iod_invrq (iod=value optimized out) at
/cache/src/sys/modules/smbfs/../../netsmb/smb_iod.c:91
rqp = (struct smb_rq *) 0xfe0105ecd800
#10 0x8101b172 in smb_iod_addrq (rqp=0xfe0105ecd800) at
/cache/src/sys/modules/smbfs/../../netsmb/smb_iod.c:418
vcp = value optimized out
iod = (struct smbiod *) 0xfe009483b800
error = value optimized out
__func__ = uЪ, '\220' repeats 12 times
#11 0x81017da2 in smb_rq_simple (rqp=0xfe0105ecd800) at
/cache/src/sys/modules/smbfs/../../netsmb/smb_rq.c:168
vcp = (struct smb_vc *) 0xfe011f957000
error = value optimized out
i = 0
#12 0x81016202 in smb_smb_treeconnect (ssp=0xfe015f069200,
scred=0xfe009483b868) at
/cache/src/sys/modules/smbfs/../../netsmb/smb_smb.c:574
vcp = (struct smb_vc *) 0xfe011f957000
rq = {sr_state = 1720810032, sr_vc = 0xfe0002a8c490, sr_share =
0xff8366917a90, sr_mid = 40352, sr_seqno = 4294967295, sr_rseqno =
1720810112, sr_rq = {mb_top = 0x80574fea, mb_cur = 0x10001,
mb_mleft = 1458488464, mb_count = -512, mb_copy = 0xff8366917a80,
mb_udata = 0x80755149}, sr_rqflags = 0 '\0', sr_rqflags2 = 0,
sr_wcount = 0x0, sr_bcount = 0xff8366917ac0, sr_rp = {md_top =
0x8057546d, md_cur = 0x0, md_pos = 0xfe0056eec490
\2005л\200}, sr_rpgen = -1803307004, sr_rplast = -512, sr_flags =
1458488464, sr_rpsize = -512, sr_cred = 0xfe009483b804, sr_timo =
1458488464, sr_rexmit = -512, sr_sendcnt = 1720810208, sr_timesent = {tv_sec
= 582, tv_nsec = -2196531595260}, sr_lerror = 0, sr_rqsig =
0xff8366917b10
\200{\221f\203ЪЪЪ\206╚V\200\200{\221f\203ЪЪЪ\035є\001\201п\a, sr_rqtid
= 0x805a0e97, sr_rquid = 0xff8366917b10, sr_errclass = 1 '\001',
sr_serror = 0, sr_error = 0, sr_rpflags = 208 'п', sr_rpflags2 = 0, sr_rptid
= 0, sr_rppid = 0, sr_rpuid = 0, sr_rpmid = 0, sr_slock = {lock_object =
{lo_name = 0xff8366917b80
Ю{\221f\203ЪЪЪ\032ґ\001\201П{\221f\203ЪЪЪ\230╦\203\224, lo_flags =
2153163654, lo_data = 4294967295, lo_witness = 0xff8366917b80}, mtx_lock
= 8592098960413}, sr_t2 = 0x8102517c, sr_link = {tqe_next =
0x9483b820, tqe_prev = 0x0}}
rqp = (struct smb_rq *) 0xfe0105ecd800
mbp = (struct mbchain *) 0xfe0105ecd828
pp = value optimized out
pbuf = 0x0
encpass = 0x0
error = value optimized out
plen = 1
upper = 0
#13 0x8101ad1a in smb_iod_thread (arg=value optimized out) at
/cache/src/sys/modules/smbfs/../../netsmb/smb_iod.c:206
iod = (struct smbiod *) 0xfe009483b800
#14 0x805365df in fork_exit
Re: FreeBSD-9.1 would not boot on pentium3 laptop
15.02.2013 08:49, John Baldwin ???(??):
Were you able to test this patch?
Yes, with the patch my laptop boots -- even after I removed the
work-around (hint.ichss.0.disabled=1 from device.hints). powerd is
also able to regulate the frequency -- I'm not sure, how else to test
the functionality.
Thank you. Yours,
-mi
Index: ichss.c
===
--- ichss.c(revision 246122)
+++ ichss.c(working copy)
@@ -67,7 +67,7 @@ struct ichss_softc {
#define PCI_DEV_82801BA 0x244c /* ICH2M */
#define PCI_DEV_82801CA 0x248c /* ICH3M */
#define PCI_DEV_82801DB 0x24cc /* ICH4M */
-#define PCI_DEV_82815BA 0x1130 /* Unsupported/buggy part */
+#define PCI_DEV_82815_MC 0x1130 /* Unsupported/buggy part */
...
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why can't gcc-4.2.1 build usable libreoffice?
20.02.2013 15:41, Peter Jeremy ???(??): You left out: 4. Code relies on language features that are not supported by the compiler. (It's not a bug that gcc 4.2.1 (eg) doesn't suppert C++11) If a compiler does not support a feature, it is supposed to error-out upon encountering it, not generate invalid code. If this was, in fact, the reason for the problem, it would've been a compiler bug. 5. Code relies on specific compiler features Depending on what you mean by compiler features here, this is simply a duplicate of either your own 4 or my 1. Feel free to answer your own question if it's important to you. No-one else is particularly interested. Is that why you decided to chime-in? Because you are not particularly interested? Maybe, you should've remained outside this lovely discussion, if this was really true? Jung-uk Kim answered my question, though. As others have indicated, the toolchain provided in the base system is intended only for building the base system. This was never true before and it is rather sad, if it were really becoming the truth now. More than likely, though, this is just a cheap excuse. Kind of like: you did not pay for the code, did you, so don't expect it to work. -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why can't gcc-4.2.1 build usable libreoffice?
18.02.2013 15:26, Chris Rees ???(??): I'm sure you understand that our compiler in base is rather elderly, and that a project as insanely huge as Libreoffice is going to be highly sensitive to minute changes. No, Chris... I do not understand this wonderfully PR-esque response. See, my understanding always was, the only possible reasons for a compiler to produce a non-starting executable are: 1. The code is buggy. 2. The compiler is buggy. 3. Both of the above. My question was, which is it? 19.02.2013 00:35, Kevin Oberman ???(??): Just for the record, is find that it works fine for me with gcc-4.6. 9.1-STABLE on i386 system. Building it with the default compiler results in a successful build, but the program would simply exit after a few seconds with no error. The exist status was 0. No messages. When I built with 4.6, it builds and runs fine Yes, 4.6 is supposed to work and is supported by the office@ team. My question was about 4.2.1, which happens to be the base cc/c++ in 8.x and in 9.x as well, if world was built WITHOUT_CLANG. I too observe the 4.2.1-compiled office die at start-up -- the splash screen starts nicely and exits after kicking off the actual soffice.bin which segfaults. -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why can't gcc-4.2.1 build usable libreoffice?
On 19.02.2013 09:45, Chris Rees wrote: a. The code is buggy. b. The compiler is buggy. c.Both of the above. My question was, which is it? My answer is that it is almost certainly (b). Are there identified, known problems with the version? From what little I've heard, our cc had some bug-fixes merged-in from newer versions. For example, graphics/vigra now compiles fine with the stock cc in 9.1, whereas it used to need a newer one. Maybe, there are already fixes available for whatever is needed for the office to build properly as well? The older version may be allowed to miss some optimization opportunities or be less descriptive in warnings, but it must produce valid binaries from valid code [Captain Obvious hat off] You are welcome to ask upstream about it, but I doubt they would show much interest in such an old compiler. Upstream gcc? They may not be very interested, indeed, but it is FreeBSD, that delivered this compiler to me -- in the most recent stable version of the OS. This is why I'm asking stable@'s opinion on the matter... We aren't really so bad, BTW -- Red Hat Enterprise 5.7 (the latest in their 5.x line) still has cc, that identifes itself as: gcc version 4.1.2 20080704 (Red Hat 4.1.2-51) I think it's insanity that we still use this version for ports by default, but never mind. I find it perfectly reasonable, that ports use the base cc and c++ by default. But I agree, that it is insane, that the base compiler can not compile one of the most popular open-source application-suits... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why can't gcc-4.2.1 build usable libreoffice?
On 19.02.2013 12:23, Adrian Chadd wrote: I bet *office just uses a bunch of either horrible syntax that breaks things, or newer C/C++ features that are buggy in older compilers. Well, yes, this is, what I wanted to find out -- which case is it. There was a point, when we had a special compiler-port just for OpenOffice.org: http://www.freshports.org/lang/gcc-ooo That port was building gcc-3.4.1, which was NOT too old for the office only a few years ago (when gcc-4.2.1 already existed). I'd love to see a comment from people, who /know/ what is going on. Then we may be able to either patch-up the base compiler, or the office, code or both. And let the healing begin[TM]. I'm afraid, though, the compiler-people are too cool to use an office suit -- finding vi (and, perhaps, TeX) sufficient for their documents, while the office@ maintainers prefer the easy way of just adding the newer compiler to the requirements. Getting these two distinct groups to meet in one thread was the point of this topic... On 19.02.2013 12:35, Ian Lepore wrote: In any case, why hasn't that port been blessed with the requires gcc 4.6+ port option/dependency? I thought that's why we_have_ that. It has been. The OP stated the he disabled that and forced use of gcc 4.2.1, and is now complaining that it doesn't work after specifically taking steps to make it not-work. Ian, contrary to your accusation, I never complained that the port does not work. Moreover, to prevent that suspicion from entering sincere minds, I explicitly said: I do not blame the office@ team -- the port did not want to use gcc-4.2.1, I forced it to. Did you not see that sentence, or do deliberately misrepresent my original post? -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why can't gcc-4.2.1 build usable libreoffice?
On 19.02.2013 13:19, Ian Lepore wrote: All strike me as being complaints, but if that seems like a mis-characterization to you, then I apologize. These were, indeed, complaints, but not about the port not working after I broke it. My complaint is that, though the port works out of the box, the office@ maintainers have given up on the base compiler too easily -- comments in the makefile make no mention of any bug-reports filed with anyone, for example. It sure seems, no attempts were made to analyze the failures... I don't think, such going with the flow is responsible and am afraid, the inglorious days of building a special compiler just for the office will return... Maybe, it is just an omission -- and the particular shortcomings of the base compiler (and/or the rest of the toolchain) are already known and documented somewhere else? Licensing prevents us from updating gcc in the base. Licensing? Could you elaborate, which aspect of licensing you have in mind? Maintainers of large opensource suites are likely to have little interest in supporting LibreOffice's own Native_Build page https://wiki.documentfoundation.org/Development/Native_Build makes no mention of a required compiler version. Unless a compiler is documented to not support a required feature, it is supposed to work. Thus, filing a bug-report with LibreOffice could've been fruitful -- if it is the code, rather than the toolchain, that are at fault... a buggy old compiler years after it has been obsoleted by newer versions. So, it is your conclusion too, that our base compiler is buggy -- and that little can be done about it. Am I really the only one here disturbed by the fact, that the compilers shipped as cc(1) and/or c++(1) in our favorite operating system's most recent stable versions (9.1 and 8.3) are considered buggy? Not just old -- and thus unable to process more modern language-standards/features, but buggy -- processing those features incorrectly? There is certainly nothing in our errata http://www.freebsd.org/releases/9.1R/errata.html about it... On 19.02.2013 13:05, Adrian Chadd wrote: .. I think the compiler people just use the port as compiled with the compiler that is known to work with it, and move on. Such people would, perhaps, be even better served by an RPM-based system, don't you think? But I don't think so -- the amount of OPTIONS in the port is large, and a lot of people are likely to build their own. Not because they like it, but because they want a PostgreSQL driver or KDE4 (or GTK3) interface or... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why can't gcc-4.2.1 build usable libreoffice?
On 19.02.2013 14:15, Jung-uk Kim wrote: What do we go from here? I don't know. One thing I know for sure is we cannot support every possible build/runtime environment. Feel free to suggest your ideas and thoughts. Well, support for every possible combination is, of course, a toll order, but support for the base cc/c++ is a reasonable expectation, in my opinion... And if there is a *good* reason to reject the base compiler, I'd expect such good reason to be documented -- preferably with bug-reports filed against either the FreeBSD and its toolchain or against the LibreOffice code. Or both... On 19.02.2013 14:21, Jeremy Chadwick wrote: There are damn good reasons all my systems have WITHOUT_CLANG=true in src.conf. Actually, clang, whatever faults you may have seen in it, would've produced a working libreoffice build. But it is not the cc/c++ on 9.1 and 8.3... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why can't gcc-4.2.1 build usable libreoffice?
On 19.02.2013 14:45, Jung-uk Kim wrote: Actually, I tried very hard to build sane LO with gcc 4.2 but it wasn't fruitful. Eventually, I gave up on adding kludges after kludges because LO is moving away from pre-C++11 compilers anyway.:-( Should not a pre-C++11 compiler simply /fail/ upon encountering C++11 code? And if there is a*good* reason to reject the base compiler, I'd expect such good reason to be documented -- preferably with bug-reports filed against either the FreeBSD and its toolchain or against the LibreOffice code. Or both... I believe there were plenty PRs already. I can not find any :-( The ones against FreeBSD http://www.freebsd.org/cgi/query-pr-summary.cgi?category=severity=priority=class=state=sort=nonetext=libreofficeresponsible=multitext=originator=release= all talk about build failures (except the 176269 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/176269, filed today). There are no relevant bug-reports against LibreOffice, that mention gcc-4.2.1 https://bugassistant.libreoffice.org/buglist.cgi?quicksearch=gcc-4.2.1 or gcc 4.2.1 https://bugassistant.libreoffice.org/buglist.cgi?quicksearch=gcc%204.2.1. -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Licensing zealotism (Re: Why can't gcc-4.2.1 build usable libreoffice?)
On 19.02.2013 14:54, Jeremy Chadwick wrote: Licensing zealotism benefits no user, but I can see it benefiting certain companies whose commercial products are reliant on FreeBSD. So out with it already. But support from (and even mere adoption by) large companies benefits FreeBSD in a number of ways. In any case, this is a matter for a separate thread, if any. -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why can't gcc-4.2.1 build usable libreoffice?
19.02.2013 17:30, Jung-uk Kim ???(??): I really love to build LO with GCC 4.2, too. I really do. However, I don't see much point of mentioning that fact in PR. You mentioned earlier, that you believe there were plenty PRs already. Are the patches contained in them currently in the port's files/ subdirectory? I'd like to see, where I can get with LibreOffice people -- but I don't want to file duplicate PRs, obviously... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Why can't gcc-4.2.1 build usable libreoffice?
Hello! I just finished building editors/libreoffice with gcc-4.2.1 -- had to edit the port's Makefile to prevent it from picking a different compiler. Everything built and installed, but libreoffice dies on start-up (right after flashing the splash-window): (gdb) where #0 0x00080596c1aa in cppu::__getTypeEntries () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #1 0x00080596c333 in cppu::__queryDeepNoXInterface () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #2 0x00080596d4a2 in cppu::WeakImplHelper_query () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #3 0x0008116f2b03 in cppu::WeakImplHelper1com::sun::star::lang::XEventListener::queryInterface () from /opt/lib/libreoffice/ure/lib/bootstrap.uno.so #4 0x000805970347 in cppu::OInterfaceContainerHelper::disposeAndClear () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #5 0x0008059705b2 in cppu::OMultiTypeInterfaceContainerHelper::disposeAndClear () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #6 0x00080593309f in cppu::OComponentHelper::dispose () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #7 0x000805963d00 in cppu::OFactoryComponentHelper::dispose () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #8 0x0008116ec296 in stoc_smgr::OServiceManager::disposing () from /opt/lib/libreoffice/ure/lib/bootstrap.uno.so #9 0x00080596af05 in cppu::WeakComponentImplHelperBase::dispose () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #10 0x0008116e6244 in stoc_smgr::ORegistryServiceManager::dispose () from /opt/lib/libreoffice/ure/lib/bootstrap.uno.so #11 0x00080596a573 in cppu::WeakComponentImplHelperBase::release () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #12 0x0008059482f6 in (anonymous namespace)::createTypeRegistry () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #13 0x0008059487bf in cppu::defaultBootstrap_InitialComponentContext () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #14 0x000805948918 in cppu::defaultBootstrap_InitialComponentContext () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #15 0x00080212f883 in desktop::Desktop::InitApplicationServiceManager () from /opt/lib/libreoffice/program/libmergedlo.so #16 0x00080211f362 in desktop::Desktop::Init () from /opt/lib/libreoffice/program/libmergedlo.so #17 0x000807622113 in InitVCL () from /opt/lib/libreoffice/program/libvcllo.so #18 0x000807623151 in ImplSVMain () from /opt/lib/libreoffice/program/libvcllo.so #19 0x0008076232d5 in SVMain () from /opt/lib/libreoffice/program/libvcllo.so #20 0x00080214942e in soffice_main () from /opt/lib/libreoffice/program/libmergedlo.so #21 0x00400773 in main () I do not blame the office@ team -- the port did not want to use gcc-4.2.1, I forced it to. But I'd like to know, what is wrong with the compiler shipped by FreeBSD-9.1 (and the only one, if WITHOUT_CLANG is defined), that prevents building a healthy libreoffice? Is there a bug fixed in gcc-4.6? Or is it some (incorrect) assumption made by libreoffice code? Thank you, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-9.1 would not boot on pentium3 laptop
On 07.02.2013 13:16, John Baldwin wrote: Can you get pciconf -lc output? Here: hostb0@pci0:0:0:0: class=0x06 card=0x chip=0x11308086 rev=0x02 hdr=0x00 cap 09[88] = vendor (length 4) Intel cap 15 version 1 cap 02[a0] = AGP 4x 2x 1x SBA disabled pcib1@pci0:0:1:0: class=0x060400 card=0x chip=0x11318086 rev=0x02 hdr=0x01 pcib2@pci0:0:30:0: class=0x060400 card=0x chip=0x24488086 rev=0x02 hdr=0x01 isab0@pci0:0:31:0: class=0x060100 card=0x chip=0x244c8086 rev=0x02 hdr=0x00 atapci0@pci0:0:31:1:class=0x010180 card=0x45418086 chip=0x244a8086 rev=0x02 hdr=0x00 uhci0@pci0:0:31:2: class=0x0c0300 card=0x45418086 chip=0x24428086 rev=0x02 hdr=0x00 vgapci0@pci0:1:0:0: class=0x03 card=0x00a31028 chip=0x4d461002 rev=0x00 hdr=0x00 cap 02[50] = AGP 4x 2x 1x SBA disabled cap 01[5c] = powerspec 2 supports D0 D1 D2 D3 current D0 pcm0@pci0:2:3:0:class=0x040100 card=0x00a31028 chip=0x1998125d rev=0x10 hdr=0x00 cap 01[c0] = powerspec 2 supports D0 D1 D2 D3 current D0 xl0@pci0:2:6:0: class=0x02 card=0x645610b7 chip=0x605510b7 rev=0x10 hdr=0x00 cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 none0@pci0:2:6:1: class=0x078000 card=0x615b10b7 chip=0x100710b7 rev=0x10 hdr=0x00 cap 01[50] = powerspec 2 supports D0 D2 D3 current D0 cbb0@pci0:2:15:0: class=0x060700 card=0x00a31028 chip=0xac42104c rev=0x00 hdr=0x02 cap 01[a0] = powerspec 2 supports D0 D1 D2 D3 current D0 cbb1@pci0:2:15:1: class=0x060700 card=0x00a31028 chip=0xac42104c rev=0x00 hdr=0x02 cap 01[a0] = powerspec 2 supports D0 D1 D2 D3 current D0 none1@pci0:2:15:2: class=0x0c0010 card=0x00a31028 chip=0x8027104c rev=0x00 hdr=0x00 cap 01[44] = powerspec 2 supports D0 D2 D3 current D0 Thanks! Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-9.1 would not boot on pentium3 laptop
On 06.02.2013 02:13, YongHyeon PYUN wrote: Disabling Wake on LAN in the BIOS solved this problem. Now xl0 is seen and functional. Solved. Because I added WOL support xl(4) in the past I'm interested in knowing whether that change broke your controller when BIOS enables WOL. I can not reproduce this -- after enabling WOL in BIOS, both kernels (mine and 9.1-R GENERIC) still see xl0 now. Maybe, it is a BIOS issue -- I'm using Lattitude's BIOS version A02, but the last update from Dell before they stopped supporting the laptop is A23. Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD-9.1 would not boot on pentium3 laptop
Hello! I have an old Dell Latitude C800 laptop (with Pentium3 CPU in it). FreeBSD 6.3-STABLE was running fine on it, but I decided to update the machine to 9.1-STABLE. Well, neither my own custom kernel, nor even the official 9.1-RELEASE CD1 would boot... In both cases the boot process runs up to detecting uhub0, then either hangs forever or shuts off after a short while. Again, I thought I screwed-up the build, but the official CD would not boot either, so here I am. Flipping through the old CDs I have, the 7.3 hangs at boot similarly (after reporting loading the memory image and warning me about dangerously low battery). The 3.2-STABLE (September 1999) boots fine -- and goes into sysinstall. Freesbie-2.0.1 (which is based on FreeBSD-6.2) booted too. What happened between 6.x and 7.x? Any ideas? Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-9.1 would not boot on pentium3 laptop
On 05.02.2013 23:50, Erich Dollansky wrote: USB? That would be a shame -- I'm dressing up this old machine to be used with a couple of USB-devices. I have had a Fujitsu LifeBook which I only could use with 7.x out for the same reason. Is there a PR? Thanks, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-9.1 would not boot on pentium3 laptop
On 05.02.2013 23:38, Mikhail T. wrote: What happened between 6.x and 7.x? Ok, what happened is that device cpufreq is now in GENERIC and the ichss0 along with it. Setting set hint.ichss.0.disabled=1 on the loader prompt allows me to boot -- both my own kernel as well as the 9.1-RELEASE from CD. Solved... Annoying beyond belief, but solved. Now, if only I could figure out, why my network card (3COM's 3C556 Mini PCI) is not seen by the 9.1... It was working perfectly fine with 6.3 -- and still works with the FreeSBIE-2.0.1 -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-9.1 would not boot on pentium3 laptop
On 06.02.2013 01:24, Mikhail T. wrote: Now, if only I could figure out, why my network card (3COM's 3C556 Mini PCI) is not seen by the 9.1... Disabling Wake on LAN in the BIOS solved this problem. Now xl0 is seen and functional. Solved. I struggle to understand, how a less seasoned user could be expected to figure these two issues out... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-9.1 would not boot on pentium3 laptop
On 06.02.2013 01:57, Erich Dollansky wrote: I have had a Fujitsu LifeBook which I only could use with 7.x out for the same reason. Is there a PR? Thanks, No. I did not want to bother people for such an old device. You should have. If it is listed as supported, it should be working. And FreeBSD still supports 486 CPUs (though not the 386). Testing old devices is difficult for developers, so they'd rely on users like yourself to tell them about regressions... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: What is negative group permissions? (Re: narawntapu security run output)
On 23.12.2012 11:48, Chris Rees wrote: They involve a lot of thought to get right, as well as chmod g-w on something where you probably meant chmod go-w is a disastrous but (perhaps) common error. Chris Well, in (over 20) years of dealing with Unix, I've never made a mistake like that, nor do I understand, how it can be considered common ... Got to admit, I was surprised to see it. It made me think, I do not understand something -- or that FreeBSD is becoming overly paternalistic. It turned out to be the latter... I doubt, it is useful. Worse, issuing such warnings routinely, only reinforces the unfortunate misconceptions like the one Barney demonstrated in this thread. When originally added, the check was meant to be off by default: r215213 | brooks | 2010-11-12 19:40:43 -0500 (пт, 12 лис 2010) | 7 lines Add an (off by default) check for negative permissions (where the group on a object has less permissions that everyone). These permissions will not work reliably over NFS if you have more than 14 supplemental groups and are usually not what you mean. MFC after: 1 week perhaps, it should have remained off? Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
What is negative group permissions? (Re: narawntapu security run output)
On 23.12.2012 03:05, Charlie Root wrote: Checking negative group permissions: 8903027 -rw--w-r-- 1 miwww794277 Oct 23 07:47:45 2007 /home/mi/public_html/syb/order/download.log Hello! The above started to appear in the daily security run output after I upgraded to 9.1. I don't understand, what this check is doing or why the above file is reported -- what's abnormal (warning-worthy) about allowing the web-server to write to, but not read a file? I did it on purpose to keep all files associated with a project together, but without inadvertently serving some of them... The actual script generating this warning (110.neggrpperm) was added in 2010 and meant to be off by default. There is no explicit mention of the knob daily_status_security_neggrpperm_enable in the log for etc/defaults/periodic.conf... I understand, I can explicitly disable it, but I'm curious... Whether it should run by default or not, what is the purpose of it? Thanks, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
xz(1) keeps SEGFAULT-ing
Hello! I've set up several nightly backups all using the pipe-chain of dump | xz -9 | ccrypt /remote/backups/fs.xz.cpt On one system these just work every night without a problem. On another I see xz SEGFAULT-ing about 90% through almost every night for one of the filesystems (the bigger of the two). This is, what cron emails me: DUMP: WARNING: should use -L when dumping live read-write filesystems! DUMP: Date of this level 1 dump: Sat Dec 22 03:23:00 2012 DUMP: Date of last level 0 dump: Thu Dec 6 01:23:02 2012 DUMP: Dumping /dev/ad4s1g (/home) to standard output DUMP: mapping (Pass I) [regular files] DUMP: Cache 16 MB, blocksize = 65536 DUMP: mapping (Pass II) [directories] DUMP: estimated 2157823 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 11.50% done, finished in 0:38 at Sat Dec 22 04:07:55 2012 DUMP: 17.80% done, finished in 0:46 at Sat Dec 22 04:20:37 2012 DUMP: 24.32% done, finished in 0:46 at Sat Dec 22 04:26:05 2012 DUMP: 31.23% done, finished in 0:44 at Sat Dec 22 04:28:27 2012 DUMP: 36.16% done, finished in 0:44 at Sat Dec 22 04:33:34 2012 DUMP: 43.21% done, finished in 0:39 at Sat Dec 22 04:33:51 2012 DUMP: 54.86% done, finished in 0:28 at Sat Dec 22 04:28:14 2012 DUMP: 60.63% done, finished in 0:25 at Sat Dec 22 04:30:24 2012 DUMP: 65.83% done, finished in 0:23 at Sat Dec 22 04:32:47 2012 DUMP: 70.54% done, finished in 0:20 at Sat Dec 22 04:35:18 2012 DUMP: 75.15% done, finished in 0:18 at Sat Dec 22 04:37:37 2012 DUMP: 80.28% done, finished in 0:14 at Sat Dec 22 04:39:10 2012 DUMP: 85.57% done, finished in 0:10 at Sat Dec 22 04:40:23 2012 DUMP: 90.50% done, finished in 0:07 at Sat Dec 22 04:41:46 2012 DUMP: SIGSEGV: ABORTING! DUMP: DUMP: DUMP: SIGSEGV: ABORTING! SIGSEGV: ABORTING! SIGSEGV: ABORTING! DUMP: SIGSEGV: ABORTING! Following xz's fault, all other processes (dump, ccrypt, sh) dump their cores to, but, according to dmesg, the culprit is always xz. According to core, the fault is somewhere inside liblzma.so.5. I recompiled the library to enable debugging and am trying to investigate, but, perhaps, someone has already run into this? Both systems used to run FreeBSD-8/amd64, when I first set the jobs up. I have since upgraded the troublesome server to 9.1, but that did not fix the problem. The remote filesystem (where ccrypt writes encrypted output) is mounted via smbfs on both servers, but I doubt that matters... Any ideas? Thanks, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: xz(1) keeps SEGFAULT-ing
On 22.12.2012 11:39, Adrian Chadd wrote: Is it dumping core? Yes, and, as I type this, I'm trying to reproduce the crash using the version of liblzma.so.5 compiled with -O0 -g (under valgrind). So far (25%) everything is clean and valgrind has no complaints either. Yours, -mi Following xz's fault, all other processes (dump, ccrypt, sh) dump their cores to, but, according to dmesg, the culprit is always xz.*According to core, the fault is somewhere inside liblzma.so.5*. I recompiled the library to enable debugging and am trying to investigate, but, perhaps, someone has already run into this? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
syslogd spinning the CPU, not logging...
On FreeBSD/amd64 8.2-STABLE as of Sun Feb 27. I dismissed this problem the first time (a week or two ago), but just saw it again. Something triggers syslogd into spinning all available CPU -- while not logging anything. Attempts to log anything -- such as by invoking logger(1) -- simply hang. sendmail hangs too -- now new e-mail is coming. It is not pretty. ktrace-ing the process yields empty file -- it is not doing system-calls, while spinning. Attaching the debugger several times shows the same stack: #0 0x0008007cb1d6 in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 #1 0x0008007cd9fb in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 #2 0x0008007d4825 in free () from /lib/libc.so.7 #3 0x0008007c5aab in catopen () from /lib/libc.so.7 #4 0x0008007c5410 in strerror_r () from /lib/libc.so.7 #5 0x0008007c556d in strerror () from /lib/libc.so.7 #6 0x00403c10 in ?? () ... Among the logging-destinations in my syslog.conf there is a program, that exits sometimes -- but never too fast. Normally, syslogd simply restarts it without an issue... Any ideas? Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Can't compile ath(4) into kernel
My laptop's kernel config file reads: device wlan# 802.11 support device ath device ath_ar5212 device ath_rate_onoe Config raises no objections and the compilation succeeds, but linking the kernel breaks: ... linking kernel.debug ah.o(.text+0x218): In function `ath_hal_rfprobe': /home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__start_set_ah_rfs' ah.o(.text+0x21d):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' ah.o(.text+0x236):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' *** Error code 1 What could this be? All modules (including ath_hal) build correctly... Thank you! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Can't compile ath(4) into kernel
On 8/25/2010 8:27 AM, John Baldwin wrote: You are missing: options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors But I don't have the ar5416 chipset... Mine is AR2312... And it is an option, so should not it be optional? Anyway, I tried adding that option and the error is the same (did cleandepend depend, saw ah.c recompiled anew). For the 6.x - 8 upgrade you are doing, I strongly suggest looking at the changes to GENERIC across your upgrade. It would save you several e-mails to the mailing list Thanks, I did that. After several attempts to fiddle with options/devices, the wireless section now looks like: # Wireless NIC cards device wlan# 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's options IEEE80211_SUPPORT_MESH # enable 802.11s draft support device wlan_wep# 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device ath device ath_rate_sample # SampleRate tx rate control for ath device ath_ar5212 #device ath_rate_onoe #optionsAH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors Generic simply uses the entire ath_hal, but ath_hal(4) suggests, that picking out a single driver should work... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Strange buildworld error (uuid_*)
23.08.2010 08:17, John Baldwin написав(ла): With some trickery (had to define: WITHOUT_CDDL, WITHOUT_SSP, WITH_GCC3, NO_WERROR) I upgraded my laptop directly from 6.3 to 8.1-STABLE. It now boots nicely. I'd like to make another round of buildworld/buildkernel -- using the existing tools... That, however, breaks in the most unexpected place: Your libstand is too stale. The only libstand found on the computer (/usr/lib/libstand.a) is from August 19th -- the version built by FreeBSD-6's gcc-3 from FreeBSD-8.1's sources. According to nm, the library does define both uuid_equal and uuid_is_nil: m...@vaio:~ (106) nm /usr/lib/libstand.a | grep uuid uuid_equal.o: T uuid_equal U uuid_is_nil uuid_is_nil.o: T uuid_is_nil Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Strange buildworld error (uuid_*)
Hello! With some trickery (had to define: WITHOUT_CDDL, WITHOUT_SSP, WITH_GCC3, NO_WERROR) I upgraded my laptop directly from 6.3 to 8.1-STABLE. It now boots nicely. I'd like to make another round of buildworld/buildkernel -- using the existing tools... That, however, breaks in the most unexpected place: /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0xad5): In function `bd_opendisk': : undefined reference to `uuid_is_nil' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0xf62): In function `bd_opendisk': : undefined reference to `uuid_equal' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0xf8a): In function `bd_opendisk': : undefined reference to `uuid_equal' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0x10fe): In function `bd_opendisk': : undefined reference to `uuid_is_nil' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0x160a): In function `bd_print': : undefined reference to `uuid_equal' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0x16b2): In function `bd_print': : undefined reference to `uuid_equal' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0x1701): In function `bd_print': : undefined reference to `uuid_equal' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0x18cd): In function `bd_print': : undefined reference to `uuid_equal' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0x19ba): In function `bd_print': : undefined reference to `uuid_equal' *** Error code 1 1 error Any suggestions? Thanks! Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.x grudges
31.07.2010 01:17, Peter Jeremy написав(ла): kenv(1) (in the base) should as well. Cool! Here it is: smbios.bios.reldate=08/13/2003 smbios.bios.vendor=American Megatrends Inc. smbios.bios.version=3.13 smbios.chassis.maker=Chassis Manufacture smbios.chassis.serial=Chassis Serial Number smbios.chassis.tag=Asset-1234567890 smbios.chassis.version=Chassis Version smbios.memory.enabled=1048576 smbios.planar.maker=ASUSTeK Computer INC. smbios.planar.product=A7N8X-LA smbios.planar.serial=X312345678 smbios.planar.version=Rev 1.xx smbios.socket.enabled=1 smbios.socket.populated=1 smbios.system.maker= smbios.system.product= smbios.system.serial= smbios.system.uuid=00020003-0004-0005-0006-000700080009 smbios.system.version= smbios.version=2.3 Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.x grudges
09.07.2010 05:49, Peter Jeremy ???(??): I doubt I'm personally in a position to debug this and don't personally use splash screens. Can you reproduce it using an image that you can re-distribute? Ok, the splash-screen problem went away after I put back the original video-card. The one I tried with (a high-end, but old) worked fine in text mode, but, apparently, had issues in the graphical mode... Retracted... 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. It was a valid device for FreeBSD-7. The UPDATING-file enumerates a number of things, that need to be changed, when updating to 8, but the removal of ugen is not mentioned there. Well, the definitive list is sys/conf/NOTES and sys/$(uname -m)/conf/NOTES The NOTES files are code, not documentation... If the UPDATING file did not exist, I'd be looking elsewhere for the changes. But it does exist and so should be complete (perhaps, it should be auto-generated based on the commit-history of the NOTES and GENERIC kernel-configs?) but I agree that the ugen(4) man page is incorrect and a case could be made for having better details of USB2 in UPDATING. I did not even realize, the ugen(4) still exists in 8.1 (and would've thought, it was a remnant from 7.x), if I saw it. My grudge was that the UPDATING file did not tell me about neither it, nor about the sio being broken. How would you like to write up patches and submit a PR? I have some -- much more involved -- patches sitting in the PR database for years, so, pardon me for not accepting your invitation to file more at this time... The ones most ripe for committing are: * handle SIGINFO in sleep(1) http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/139345 -- recent * pkg_add(1) pkg-routines ignore the recorded md5 checksums http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/34628 -- 8 years old * bikeshed entry of Handbook is wrong http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/86342 -- a doc-one, 5 years old now, still valid... Search the PR-db for others, where a dialog/discussion might be necessary -- the above ones are only those completely ready... That's why I asked for the output up to the hang - which might show where the problem is. If you don't have a serial console, take a photo and put it up on the web. Ok, here is the screen-shot http://aldan.algebra.com/%7Emi/tmp/hung-1394-shot.png (firewire enabled in BIOS). Hanging while probing USB-devices... BTW, in all writing you've done, you've never mentioned what FreeBSD version you are running beyond a vague 8.1 prerelease, what motherboard you have (despite my request for this) and only indirectly given the architecture (via the config file you posted). Well, the version was also implied -- 8.1/prerelease as of (approximately) the date of the posting. The motherboard version -- I'm not sure still. Something like nVidia nForce2 -- does that identify it enough? The verbose dmesg.boots are: * 7.3-PRERELEASE Feb 5 http://aldan.algebra.com/%7Emi/tmp/quokka.dmesg.7.3.txt (firewire enabled -- no hang. This is one extracted from /var/log/messages and is a little garbled.) * 8.1-PRERELEASE July 5 http://aldan.algebra.com/%7Emi/tmp/quokka.dmesg.Jul-05.txt (firewire disabled -- otherwise hangs) * 8.1-PRERELEASE July 14 http://aldan.algebra.com/%7Emi/tmp/quokka.dmesg.Jul-14.txt (firewire disabled. Interestingly, the July 14th version reports slightly different memory base) Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
today's 8.1/i386: panic: bad pte
Some part of KDE4's kdm crashed at start-up and seems to have taken the entire machine with it: kgdb /boot/kernel/kernel /var/crash/vmcore.22 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: 6pid 18398 (drkonqi), uid 0: exited on signal 11 (core dumped) TPTE at 0xbfca9488 IS ZERO @ VA 2a522000 panic: bad pte Uptime: 2h28m24s Physical memory: 1263 MB Dumping 195 MB: 180 164 148 132 116 100 84 68 52 36 20 4 Reading symbols from /boot/kernel/splash_pcx.ko...Reading symbols from /boot/kernel/splash_pcx.ko.symbols...done. done. Loaded symbols for /boot/kernel/splash_pcx.ko Reading symbols from /boot/kernel/vesa.ko...Reading symbols from /boot/kernel/vesa.ko.symbols...done. done. Loaded symbols for /boot/kernel/vesa.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko #0 doadump () at pcpu.h:231 231 __asm __volatile(movl %%fs:0,%0 : =r (td)); (kgdb) bt full #0 doadump () at pcpu.h:231 No locals. #1 0xc05d10a4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 _giantcnt = Variable _giantcnt is not available. (kgdb) where #0 doadump () at pcpu.h:231 #1 0xc05d10a4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc05d12b1 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc07f0406 in pmap_remove_pages (pmap=0xc85bbc78) at /usr/src/sys/i386/i386/pmap.c:4198 #4 0xc079516b in vmspace_exit (td=0xc51f3a00) at /usr/src/sys/vm/vm_map.c:409 #5 0xc05a7253 in exit1 (td=0xc51f3a00, rv=139) at /usr/src/sys/kern/kern_exit.c:303 #6 0xc05d3296 in sigexit (td=0xc51f3a00, sig=139) at /usr/src/sys/kern/kern_sig.c:2872 #7 0xc05d47a8 in postsig (sig=11) at /usr/src/sys/kern/kern_sig.c:2759 #8 0xc06082f8 in ast (framep=0xe5fafd38) at /usr/src/sys/kern/subr_trap.c:234 #9 0xc07e2c44 in doreti_ast () at /usr/src/sys/i386/i386/exception.s:368 Does this look familiar to anyone? Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: today's 8.1/i386: panic: bad pte
20.07.2010 12:47, Alan Cox написав(ла): Historically, this panic has indicated flakey memory. This panic occurs because a memory location within a page table has unexpectedly changed to zero. Ouch... Thanks for the hint (maybe, the panic should say something like that?) In any case, is there a way to identify the the flakey DIMM? I did run memtest on this box and haven't received any errors... Thanks! Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
panic: handle_written_inodeblock: bad size
An 8.1-prerelease machine I have throws the panic in subject quite often. Does anyone care? Is this evidence of some filesystem corruption here, or a known problem that's (almost) solved already? The stacks all look the same: panic: handle_written_inodeblock: bad size ts_to_ct(1279145603.245753580) = [2010-07-14 22:13:23] ... #0 doadump () at pcpu.h:230 #1 0xc05be054 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc05be261 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc07501b9 in softdep_disk_write_complete (bp=0xd81bcc30) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4615 #4 0xc062c386 in bufdone_finish (bp=0xd81bcc30) at buf.h:411 #5 0xc062c7bd in bufdone (bp=0xd81bcc30) at /usr/src/sys/kern/vfs_bio.c:3275 #6 0xc0565bb5 in g_vfs_done (bip=0xc497e8c0) at /usr/src/sys/geom/geom_vfs.c:97 #7 0xc0626db9 in biodone (bp=0xc497e8c0) at /usr/src/sys/kern/vfs_bio.c:3110 #8 0xc056301f in g_io_schedule_up (tp=0xc4044000) at /usr/src/sys/geom/geom_io.c:675 #9 0xc05633c8 in g_up_procbody () at /usr/src/sys/geom/geom_kern.c:95 #10 0xc0595f5f in fork_exit (callout=0xc0563360 g_up_procbody, arg=0x0, frame=0xe46a5d38) at /usr/src/sys/kern/kern_fork.c:844 #11 0xc07cf704 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:273 Please, advise. Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: panic: handle_written_inodeblock: bad size
19.07.2010 07:31, Jeremy Chadwick написав(ла): If you boot the machine in single-user, and run fsck manually, are there any errors? Thanks, Jeremy... I wish, there was a way to learn, /which/ file-system is giving trouble... However, after sending the question out last night, I tried to pkg_delete a package on the machine, and was very lucky to see a file-system error (inode something or other) before the panic struck. That, at least, told me, which file-system was in trouble (/var). I dump-ed it out, re-created, and then restored it... Although dumping went smooth, there were two errors at which restore offered to abort. I told it not to and got (most of the) file-system restored. (The dump is available to anyone wishing to investigate -- contact me privately. I'm not posting it publicly because of the passwd-file backup under /var). So far seems quiet -- no panics for two more hours before I went to bed. Only thing I can think of off the top of my head: there's a known situation (also applies to RELENG_7) where a background fsck doesn't correct all errors after a system crash/unclean shutdown. I mention this because I see softdep in the above stack trace (usually refers to softupdates). I don't know if this got fixed, but the workaround is to use background_fsck=no in rc.conf. Yes, after a crash this means you have to wait for the entire fsck to run. When setting up my main machine 4 years ago, I turned off background fsck... But I thought, things have improved sufficiently enough since then :-( Maybe, background fsck should still be disabled by default? And, IMO, at the very least, *any panic related to a file-system must clearly identify the file-system in question*... What do you think? Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On 17.07.2010 09:41, Jeremy Chadwick wrote: The test system is amd64. I'm not doubting the issue may be more apparent/easier to occur on i386, but pure luck on amd64 is a bit surprising. I'll build an i386 version of my testbox and start the procedure over again. Set the malloc(3) flags to paranoid (like AJ or AZ). You should then be able to reproduce it on any platform... Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: net-booting the install disks (Re: 8.x grudges)
08.07.2010 09:53, Jeremy Chadwick написав(ла): Then don't modify loader.conf. Instead, once the Welcome to FreeBSD! portion of loader appears, press 6 to shell to the loader prompt and type: set vfs.root.mountfrom=ufs:/dev/md0 boot Yes, that works... It just should not be necessary. Red Hat's kickstart does not require one to extract CD-images to fiddle with a couple of lines, and FreeBSD comes tantalizingly close to offer the same functionality. Just not quite :-( -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: net-booting the install disks (Re: 8.x grudges)
08.07.2010 12:40, Jeremy Chadwick написав(ла): set vfs.root.mountfrom=ufs:/dev/md0 boot Yes, that works... It just should not be necessary. Okay, so let me get this straight. First the complaint was that you had to modify loader.conf, which involved extracting the CD image, editing the file, yadda yadda. Now that you've been shown you don't have to edit loader.conf, the complaint is it shouldn't be necessary.:-) No, I initially complained, that I had to fiddle with loader's options at boot-time (item 8 -- instead of setting mountfrom, I set init to sysinstall -- don't recall the exact syntax). You then claimed, that you /can't reproduce/ my problem -- and referred me to your instructions http://jdc.parodius.com/freebsd/pxeboot_serial_install_8.html (nice ones, BTW, even for those, who don't need serial-port install), where you explain, how to perform the install via netboot. I pointed out, that your recipe is not a valid counter-example, because -- instead of fiddling with loader's options at boot-time, you fiddle with the loader.conf (and have to extract the entire CD/DVD-image to do that one-line change). One way or the other, some -- very minor -- manual changes are required... It is, of course, an accepted fact, that installing (or upgrading) an OS would require fiddling, but this particular little aspect can be eliminated, I think... The bottom line: the PXE booting framework in FreeBSD could be improved. Even Randi would agree with this point, I think. I perfectly understand -- and am not complaining -- about substantial work not done in any particular area. It is the little things, that could've been done with negligible /marginal/ cost, that are my target. RedHat's kickstart http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/ch-kickstart2.html can do an entire install based on pre-configured rules. Implementing something like that for FreeBSD would, probably, take quite a bit of effort. But being able to just boot straight into install from a CD (or CD-image) across the LAN doesn't seem very complicated, considering, how close we already are... Yes, it is important to me. No, I can not do it myself. I do, what I can in my area of expertise. If this area is not being improved for lack of time/resources, then fine... But I don't think, that's the case, for it seems to me, that the developers, who can do this little improvement, simply don't see a need for it. Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.x grudges
08.07.2010 17:06, Peter Jeremy написав(ла): On 2010-Jul-07 14:22:22 -0400, Mikhail T.mi+t...@aldan.algebra.com wrote: In no particular order: 1. A picture, that one of the systems was displaying at boot (and then used as a screen-saver), stopped showing properly. The colors are right, but the picture is distorted beyond recognition. The relevant part of loader.conf is: splash_pcx_load=YES vesa_load=YES bitmap_load=YES bitmap_name=/boot/187426-9-quokka-dreaming.pcx It's a bit difficult to provide any useful input without some idea of what the picture should and does look like. Can you please post the actual bitmap as well as a picture of your screen showing the problem. I don't want to post it publicly for copyright reasons. I can e-mail it to you (or anyone else) directly, though. 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. Can you please advise where it is documented that device ugen is valid in a FreeBSD-8 config file? It was a valid device for FreeBSD-7. The UPDATING-file enumerates a number of things, that need to be changed, when updating to 8, but the removal of ugen is not mentioned there. 5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. I haven't seen this on any of my systems. Can you please provide details of your motherboard, BIOS and the output from a verbose boot up to the hang. Is there a BIOS update available and have you tried installing it? No BIOS updates :-( I can e-mail boot's output to you directly (please, confirm interest). It would be with the device disabled though, because the boot never completes, if it is enabled. 6. Despite the reported improvements in the USB area, my USB keyboard /still/ does not work during boot. It during POST and then after the booting is complete. But in single-user mode -- no... Had to fish-out the PS2 keyboard... I have had similar problems on one of my USB-only desktops. In my case, moving the keyboard to a different USB port solved the problem. All I can suggest is to work your way through all the USB ports you have available and see if they all behavee the same. I'll try that next time I reboot this system. Thanks, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.x grudges
08.07.2010 17:36, Lucas Holt написав(ла): Most of us work on open source for free in our own time, and it's impossible to test every possible configuration before a release. I tested several particular configurations -- on several machines -- and reported the overlooked issues. I didn't write a pamphlet, and I didn't post it to Slashdot as evidence of BSD is dying -- I reported it to the developers. No need to get defensive -- or call it rant. Whoever is in a position to fix a particular problem, can now do that... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: net-booting the install disks (Re: 8.x grudges)
12.07.2010 13:11, Adam Vande More wrote: Roll it into your media You lost me right here... Rolling one's own media (for every release and release-candidate) may be Ok for someone in charge of making, at least, several installations per week. For someone like myself, who just wanted to use a downloaded CD-image straight (without burning it first), there is got to be a way to use the FreeBSD-distributed images... I'm not asking for the full power offered by kickstart et al, I just want the booting image to be a little bit smarter than it already is and do The Right Thing^TM regardless of whether it is booting from the local CD-ROM or remotely. Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
sshd would not start (another 8.x grudge)
The sshd would not start after the upgrade from 7.x to 8.1 on one of the systems: Starting sshd. cipher_encrypt: bad plaintext length 553 /etc/rc.d/sshd: WARNING: failed to start sshd Archiving the 3-year old /etc/ssh/ssh_host_rsa_key and having it recreated solved the immediate problem, but the connecting clients weren't happy about it... If anyone is interested, the old ssh_host_rsa_key is available by direct e-mail. -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
panic: __lockmgr_args: recursing on non recursive lockmgr ntnode @ (null):0
A laptop I'm helping configure (remotely) just crashed under me... Upon reboot I found the following in the messages file (quite amazed, that the message got there, actually): Jul 12 22:06:01 s syslogd: kernel boot file is /boot/kernel/kernel Jul 12 22:06:01 s kernel: panic: __lockmgr_args: recursing on non recursive lockmgr *ntnode* @ (null):0 Jul 12 22:06:01 s kernel: Jul 12 22:06:01 s kernel: cpuid = 0 Jul 12 22:06:01 s kernel: Uptime: 6h10m53s Jul 12 22:06:01 s kernel: Cannot dump. Device not defined or unavailable. Jul 12 22:06:01 s kernel: Automatic reboot in 15 seconds - press a key on the console to abort Jul 12 22:06:01 s kernel: Rebooting... Jul 12 22:06:01 s kernel: cpu_reset: Stopping other CPUs The system just finished installing a new port of OpenOffice and cleaning up WRKSRC afterwards (a huge collection of files), and was running /etc/periodic/weekly/310.locate explicitly, when the crash happened. Is this something, that's already solved and I just need to upgrade? The current kernel is: FreeBSD 8.1-PRERELEASE #0: Wed Jul 7 19:04:57 CEST 2010, i386. 4 CPUs (Full dmesg.boot available upon request.) Does the ntnode above point to the NTFS filesystems on this laptop? The laptop uses Windows' swap-file as its own swap (via md(4)) and uses Windows' TrueType fonts as well... Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
net-booting the install disks (Re: 8.x grudges)
07.07.2010 14:30, Randi Harper написав(ла):
8.
I tried to do an install on one of the systems via netbooting
(pxeload) the disk1-image. It booted, but the sysinstall had to be
started manually and, once started, did not act the same as when
booted off of CD-ROM. Seems like a simple bit to correct so that
setting init to/usr/sbin/sysinstall/manually on every boot/ is
not necessary...
This shouldn't be the case. IIRC, nothing has changed that would cause
this. More info on your environment please?
Well, I never tried /this/ part before, so I'm not claiming, there is
/re/gression here. Just lack of /pro/gress :-)
I have the following special entry in the dhcpd.conf:
subnet 192.168.1.0 netmask 255.255.255.0 {
range dynamic-bootp 192.168.1.150 192.168.1.186;
next-server 192.168.1.140;
option broadcast-address 192.168.1.255;
option routers 192.168.1.1;
option root-path 192.168.1.140:/cdrom;
filenamepxeboot;
}
The filesystem accessible as /cdrom was an md-accessed
FreeBSD-8.1-RC1-i386-disc1.iso (or bootonly). Can't easily recreate
this, because the netbooting machine has now gone back to its owner.
The problem did not surprise me, because I followed (loosely) the
instructions
http://www.freebsdwiki.net/index.php/Installing_FreeBSD_with_netboot,
where it was mentioned -- along with a work-around. If some simple logic
can be put into the boot-image to allow it to do the right thing without
manual fiddling, it would be great. Thanks!
-mi
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: net-booting the install disks (Re: 8.x grudges)
07.07.2010 16:00, Randi Harper написав(ла): So you're complaining that you have to modify the loader.conf? I fail to see the problem. This is by design, and isn't a lack of progress. Yes, I complain, that I have to modify a loader.conf embedded in a CD-image. If extracting hundreds of mega-bytes of files to make a one-line modification is by design, then the design is flawed. Especially, when the effect achieved by the one-line modification can be arrived to automatically -- without such modifications. Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.x grudges
07.07.2010 16:50, Marcel Moolenaar написав(ла): Not to mention that if you change uart(4) to create dev entries like sio(4) after uart(4) has been in the tree for more than 6 years creating ttyu* entries, you actually introduce a gratuitous change. If sio and uart could co-exist, then you'd be right. But sio no longer builds under 8.x, so some kind of aliasing (either by uart itself or by devfs) would be useful. -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
8.x grudges
I'm upgrading several systems these days to the 8.1 (pre-release) and have hit the following troubles... I could file a formal PR for each, I suppose, but, maybe, this way will get the right people's attention sooner. In no particular order: 1. A picture, that one of the systems was displaying at boot (and then used as a screen-saver), stopped showing properly. The colors are right, but the picture is distorted beyond recognition. The relevant part of loader.conf is: splash_pcx_load=YES vesa_load=YES bitmap_load=YES bitmap_name=/boot/187426-9-quokka-dreaming.pcx the picture file is identified as: PCX 772x551 772x551+0+0 8-bit PseudoClass 256c 454KB 0.039u 0:00.093 2. FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and thus not an option) -- the kernel-config files, that worked with 7.x, break without this option in them (in addition to all the nuisance, that's documented in UPDATING -- which, somehow, makes the breakage acceptable). config(8) would not warn about this, but kernel build fails. 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. 4. The sio(4) is described in UPDATING as removed, but rouses no complaint from config(8) either. It just breaks the kernel build... It should be an alias for uart, IMHO -- all I want is for my serial ports to be usable, whether their driver is called Serial Input/Output or Universal Asynchronous Receiver and Transmitter. (BTW, about the /dev-entries -- do we /really/ have to change the names of the serial port-devices every couple of years? It is rather painful to reconfigure the fax- and ppp-software, etc.) How does the Microsoft world manage to stay with the COM1, COM2 for decades?) 5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. 6. Despite the reported improvements in the USB area, my USB keyboard /still/ does not work during boot. It during POST and then after the booting is complete. But in single-user mode -- no... Had to fish-out the PS2 keyboard... 7. All my dangerously dedicated disks lost the s1 in the subdevice-names after the upgrade: /dev/da1s1d became /dev/da1d, etc. I like the shorter names (and there are, indeed, no slices there), but having to fix them manually upon reboot was unpleasant and uncalled for. As with uart/sio, backward-compatibility aliases are a fine idea and really improves user's experience... 8. I tried to do an install on one of the systems via netbooting (pxeload) the disk1-image. It booted, but the sysinstall had to be started manually and, once started, did not act the same as when booted off of CD-ROM. Seems like a simple bit to correct so that setting init to /usr/sbin/sysinstall/manually on every boot/ is not necessary... 9. The k8temp utility (installed by sysutils/k8temp http://www.freshports.org/sysutils/k8temp), which worked fine on both of my AMD-machines, no longer works on the Athlon one (still works on the Opteron-based server). I reinstalled the port, but that did not help -- the utility runs, but does not say anything. Requeting debug-info is of little help: *ro...@quokka:~ (101) k8temp *ro...@quokka:~ (102) k8temp -d CPUID: Vendor: AuthenticAMD, 0x6a0: Model=0a Family=6+0 Stepping=0 Advanced Power Management=0x1 Temperature sensor: Yes Frequency ID control: No Voltage ID control: No THERMTRIP support: No HW Thermal control: No SW Thermal control: No 100MHz multipliers: No HW P-State control: No TSC Invariant: No If any of the above can be corrected or, at least, documented, before release, we stand a little bit better chance of getting the praise otherwise well-deserved by FreeBSD... Thanks. Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.x grudges
07.07.2010 14:59, Jeremy Chadwick ???(??): FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and thus not an option) -- the kernel-config files, that worked with 7.x, break without this option in them (in addition to all the nuisance, that's documented in UPDATING -- which, somehow, makes the breakage acceptable). config(8) would not warn about this, but kernel build fails. We don't use this option (meaning it's removed from our kernels). It's definitely not required. All it does is ensure your kernel can comprehend executables/binaries built on 7.x. Attached is the kernel config-file (i386), that worked fine under 7.x. The kernel-compile will break (some *freebsd7* structs undefined), without the COMPAT_FREEBSD7 option. Try it for yourself... 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. This sounds like you not including all of the necessary USB/device framework in your kernel configuration. You're not providing enough output for us to help diagnose the problem, though. Put device ugen back into the attached kernel-config file and see config's error yourself. 4. The sio(4) is described in UPDATING as removed, but rouses no complaint from config(8) either. It just breaks the kernel build... It should be an alias for uart, IMHO -- all I want is for my serial ports to be usable, whether their driver is called Serial Input/Output or Universal Asynchronous Receiver and Transmitter. I disagree (re: it should be an alias). sio(4) is deprecated (meaning it's not used by default any more), and it's left in the driver tree solely as a fall-back method if someone runs into uart(4) problems. If it were merely deprecated it would've still worked. It does not -- put device sio into the attached kernel-config and try building -- you'll get the compile-error. Whether deliberately or through bit-rot, uart /replaced/ sio... I'll take a moment to point out that your complaints about the kernel configuration file, so far, seem to stem from you not migrating your kernel configuration from 7.x to 8.x. Things change -- that's the reality of the situation. The way I do this is, when upgrading major releases (7.x-8.x), to start fresh using GENERIC as my base template and then adding/adjusting while comparing against the older kernels' config. Others do it differently, this is just how I do it. Yes, your way is fine. But so is mine. It is perfectly reasonable to expect my method to work just as well -- the 7-8 is not revolutionary, but simply the next step. I read the UPDATING file and, though annoyed a little, took care of things mentioned in there... The remaining things are enumerated here... (BTW, about the /dev-entries -- do we /really/ have to change the names of the serial port-devices every couple of years? It is rather painful to reconfigure the fax- and ppp-software, etc.) How does the Microsoft world manage to stay with the COM1, COM2 for decades?) Like I said: things change. Well, pardon the political pun, but I don't believe in change for the sake of change. These particular changes are gratuitous. If sio is no longer available -- and replaced by uart, why change the /dev-entries?.. 5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. This is a commonly-reported problem, assuming at boot you mean while the kernel is starting. Or unless you're using a certain model of Shuttle box, but that turned out to be literally a BIOS bug: http://koitsu.wordpress.com/2009/05/22/shuttle-sg45h7-firewire-bug-in-bios-sg45u10o/ No, this is not it /at all/. The link above describes a crash in the BIOS (and no POST), if firewire circuitry is disabled in BIOS. My problem is with FreeBSD kernel hanging on boot, if the firewire circuitry is enabled in BIOS. The boot was fine under 7.x, so this can not be due to a BIOS-bug -- the only thing, that changed, is the OS... This is also a commonly-reported problem (and one I've harped on as well). When you say during boot: does it work during loader (the screen with the FreeBSD logo on it)? Yes. If the keyboard works during loader but not once the kernel + kernel USB stack loads (e.g. when booting into single-user), then look at the very bottom of this page for a couple things to try: http://wiki.freebsd.org/BugBusting/Commonly_reported_issues Will do, thanks! Still, I was hoping, things will just work with 8.1... Regardless, this is one of the reasons I still have not made the move to USB keyboards and stick with PS/2 keyboards on FreeBSD. While renovating the house, I ran USB-, audio-, and video-cables through the walls from server room to
Re: 8.x grudges
07.07.2010 16:34, Randi Harper ???(??): Attached is the kernel config-file (i386), that worked fine under 7.x. The kernel-compile will break (some *freebsd7* structs undefined), without the COMPAT_FREEBSD7 option. Try it for yourself... Don't use a kernel config from 7. We've already told you this. Your telling me this is just as valid as warning me against using computer-cases of a particular color. It is a silly requirement. My expecting things, that worked for 7, to work in 8 is reasonable. There may be (documented!) exceptions, but it ought to just work. Yes, your way is fine. But so is mine. It is perfectly reasonable to expect my method to work just as well -- the 7-8 is not revolutionary, but simply the next step. I read the UPDATING file and, though annoyed a little, took care of things mentioned in there... The remaining things are enumerated here... Your way clearly isn't fine, as it doesn't work. That's an obviously flawed argument -- this line of thinking can be used against ANY ONE reporting ANY BUG -- if one has a problem, then one's way of doing things clearly isn't fine. These changes aren't gratuitous. Did you read the commit messages behind each of the changes? I'm guessing that you haven't. No, and I'm not going to. A commercial OS would've been the laughing stock, if one hand to change C: to 1: between releases, for example... Again: this particular change seems gratuitous. It's not. You didn't bother researching before complaining. I bothered to type up my list. Presumably, problem-reports are welcome. I've been a Unix-user since 1990, a FreeBSD user since 1993 (or 94?), and a project-member for a decade. If *I* have a problem, then newer users certainly will too. And, guess what, they'll simply go with something, that does not give as much grief... To put it in simple terms, there were changes made to geom, and the way that sysinstall writes out dedicated disks wasn't compatible. Search the mailing list archives. If this is a known problem, it is even more of an outrage, that some shim was not introduced to keep the users from hitting this particular bump. The modification should be necessary. Why? Why should a netboot act differently from a local boot from CD? Just because you don't want to make the modification doesn't mean it was made that way by accident. No, I never claimed this to have been an accident... That variable can be set to any number of things. We don't advertise the iso image just working out of the box for pxe booting. You don't. But there is very little, that needs to be added there for it to just work over both netboot and local CD, and you should do it, instead of arguing with me here... No, I don't know, what it is exactly, but I'm quite certain, it can't be very much. In fact, the article about PXE booting on the official freebsd website says nothing about using the ISO. You just found some article that said it was possible (and it is) and complained because you didn't like the process? Yes, exactly. I didn't like process -- it is needlessly complicated. The same CD-image, /should/ also be usable out of the box for netbooting. Funny. It works just fine in 8.0 on my Athlon. Have you tried updating the port? Yes, I have -- and I said so in my very first e-mail on this subject. For someone, who expects people to research mailing lists, you do a terrible job of following a one-day-old thread... Also, even if it didn't work, this is an issue you should take up with the author of the port. Tom -- the maintainer -- is still in CC... From the man page: The amdtemp driver provides support for the on-die digital thermal sensor present in AMD K8, K10 and K11 processors. I know nothing about the driver. But a utility I regularly used stopped working after upgrade, so I added that to my list of upgrade-related grudges. -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
7.3: instant panic upon connecting a umass
Hello! I'm suffering from a fully reproducible panic, that strikes, when I connect a umass storage device (Blackberry Pearl with a mini-SD card inserted) to the EHCI USB port. The system runs a freshly rebuilt 7.3-stable/amd64. The crash is somewhere inside USB-stack. The stack, as produced by kgdb, can be found at: http://aldan.algebra.com/~mi/tmp/usb-crash.txt The usb4-process -- the current process at the panic-time -- is associated with: usb4: EHCI version 1.0 usb4: companion controllers, 3 ports each: usb2 usb3 usb4: NEC uPD 720100 USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: NEC EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb4 The system is running has 6Gb of RAM and 2 dual-core Opterons. The connection was just fine with 7.2-stable from March 5th, although that kernel was not an SMP one (by mistake). Please, advise. Thank you, -mi P.S. Is the USB supposed to work in 7.x, or do I have to go to 8.x for it to work reliably? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 7.3: instant panic upon connecting a umass
Jeremy Chadwick написав(ла): Regarding your problem: it likely has nothing to do with SMP, so don't worry about that aspect of it. Thanks for the reassuring response, Jeremy. If this is not about SMP, then there is a (bad) regression -- the 7.2-kernel from March 5 never crashed this way... I connected the same phone numerous times, as well as the camera... I shall await response from USB-maintainers... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
binding on 127.0.0.1 not working after upgrade to 7.3
Hello!
I just rebuilt my system from 7.2-stable to 7.3. The first thing to fail
upon restart was the PostgreSQL-server. But there are other failures --
for example, webmin is unreachable at its usual https://localhost:1/
ktrace-ing postgres reveals:
19875 postgres CALL bind(0x3,0x8015190f0,0x10)
19875 postgres STRU struct sockaddr { AF_INET, 127.0.0.1:5432 }
19875 postgres RET bind -1 errno 49 Can't assign requested address
19875 postgres CALL socket(PF_LOCAL,SOCK_DGRAM,0)
19875 postgres RET socket 4
I rebuilt postgress server anew, just in case, but it is still
failing... Changing the listen_addresses from 'localhost' to
'my.lan.ip.add' allows the server to start-up, but now I need to change
the configuration of the local applications...
Similarly, 'ssh localhost' no longer works, although `ssh my.lan.ip.add'
works...
The only unusual thing about my system is that I build with
`NO_INET6=yes'. But it all worked with the kernel from a month ago...
The ::1-definition in /etc/hosts is now commented-out, but that didn't
help any...
Please, advise. Thanks!
-mi
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: binding on 127.0.0.1 not working after upgrade to 7.3
Jeremy Chadwick написав(ла): Check ifconfig -a and make sure lo0 appears / has a correct IP address, and the interface is up. You are right, it is not up: lo0: flags=8008LOOPBACK,MULTICAST metric 0 mtu 16384 Manually running `ifconfig lo0 127.0.0.1' fixed the problem for the time being... But why? What changed so significantly in the last few month, that lo0 broke, of all things? :-) Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: An old gripe: Reading via mmap stinks
01/14/10 21:56, Matthew Dillon написав(ла): This would explain why the performance is not as bad as linux but is not as good as a properly pipelined case. For what it may be worth, here are the stats for Solaris as well: * Solaris 8, native, 32-bit binary (using -lcrypto instead of -lmd): mmap: 103.54u 27.18s 2:56.46 74.0% read: 99.12u 40.37s 2:53.06 80.6% * Solaris 10, native, 32-bit binary (using -lcrypto instead of -lmd): mmap: 159.36u 83.23s 5:28.25 73.9% read: 173.50u 104.16s 4:48.30 96.3% * Solaris 10, using the 32-bit binary built on Solaris-8: mmap: 217.74u 101.20s 5:58.89 88.8% All of the read results on Solaris (and earlier on Linux) were obtained from using ``openssl md5 largefile''. Seems like BSD is not the only OS, where the mmap's theoretical promise lags behind the actual offering -- read wins on Solaris overall too, despite being quite a bit more expensive in sys-time. Would still be nice to be the first to deliver... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
An old gripe: Reading via mmap stinks
03/25/06 14:03, John-Mark Gurney wrote: The other useful/interesting number would be to compare system time between the mmap case and the read case to see how much work the kernel is doing in each case... After adding begin- and end-offset options to md5(1) -- implemented using mmap (see bin/142814) -- I, once again, am upset over the slowness of pagefaulting-in compared to the reading-in. (To reproduce my results, patch your /usr/src/sbin/md5/ with http://aldan.algebra.com/~mi/tmp/md5-offsets.patch Then use plain ``md5 LARGE_FILE'' to use read and ``md5 -b 0 LARGE_FILE'' to use the mmap-method.) The times for processing an 8Gb file residing on a reasonable IDE drive (on a recent FreeBSD-7.2-StABLE/i386) are thus: mmap: 43.400u 9.439s 2:35.19 34.0%16+184k 0+0io 106994pf+0w read: 41.358u 23.799s 2:12.04 49.3% 16+177k 67677+0io 0pf+0w Observe, that even though read-ing is quite taxing on the kernel (high sys-time), the mmap-ing loses overall -- at least, on an otherwise idle system -- because read gets the full throughput of the drive (systat -vm shows 100% disk utilization), while pagefaulting gets only about 69%. When I last brought this up in 2006, it was revealed, that read(2) uses heuristics to perform a read-ahead. Why can't the pagefaulting-in implementation use the same or similar trickery was never explained... Now, without a clue on how these things are implemented, I'll concede, that, probably, it may /sometimes/ be difficult for VM to predict, where the next pagefault will strike, but in the cases, when the process: a) mmaps up to 1Gb at a time; b) issues an madvise MADV_SEQUENTIAL over the entire mmap-ed region mmaping ought to offer the same -- or better -- performance, than read. For example, a hit on a page inside a region marked as SEQUENTIAL ought to bring in the next page or two. VM has all the information and the hints, just does not use them... Shame, is not it? -mi P.S. If it is any consolation, on Linux things seem to be even worse. Processing a 9Gb file on kernel 2.6.18/i386: mmap: 26.222u 6.336s 6:01.75 8.9% 0+0k 0+0io 61032pf+0w read: 25.991u 7.686s 3:43.70 15.0%0+0k 0+0io 23pf+0w although the absolute times can't be compared with us due to hardware differences, the mmap being nearly twice slower is a shame... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: An old gripe: Reading via mmap stinks
01/14/10 17:15, Andrew Snow wrote: Hi Mikhail, I assume these tests were done on UFS. Have you tried ZFS? I'm curious to see the results. I suspect, it would be harder for me to setup ZFS, than for you to apply my patch for to md5.c :-) -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
openoffice stuck in _umtx_op
Hello! I'm trying to start OOo, and it hangs at start-up -- after popping up its banner page. ktrace shows the following, slowly repeating, sequence of events: [...] 32726 soffice.bin CALL _umtx_op(0x805d09060,0x8,0x1,0x805d09040,0x7fbfeef0) 32726 soffice.bin RET _umtx_op -1 errno 60 Operation timed out 32726 soffice.bin CALL gettimeofday(0x7fbfef70,0) 32726 soffice.bin RET gettimeofday 0 32726 soffice.bin CALL clock_gettime(0,0x7fbfef00) 32726 soffice.bin RET clock_gettime 0 32726 soffice.bin CALL _umtx_op(0x805d09060,0x8,0x1,0x805d09040,0x7fbfeef0) 32726 soffice.bin RET _umtx_op -1 errno 60 Operation timed out 32726 soffice.bin CALL gettimeofday(0x7fbfef70,0) 32726 soffice.bin RET gettimeofday 0 32726 soffice.bin CALL clock_gettime(0,0x7fbfef00) 32726 soffice.bin RET clock_gettime 0 32726 soffice.bin CALL _umtx_op(0x805d09060,0x8,0x1,0x805d09040,0x7fbfeef0) [...] what's happening? `ipcs -a' does not show anything extraordinary and there is nothing in syslog either... The machine is running 7.2-STABLE/amd64 (as of Oct 25). Any ideas? Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Can close-ing a pipe trigger a SIGPIPE?
Hello! I'm investigating a problem caused by (what seems like a spurious) SIGPIPE. The program creates a child process using pipe, exchanges a few messages with the child (via write and read) and closes the pipe. Some times -- in about 60% of the cases -- this causes a SIGPIPE to be delivered to the parent... Now, it is quite possible for the child to have already exited by the time the parent closes its end of the pipe -- but why should that cause a SIGPIPE, unless the parent tries to write something to the widowed pipe, which it does not? From pipe(2): A pipe that has had an end closed is considered widowed. Writing on such a pipe causes the writing process to receive a SIGPIPE signal. There is no other mention of SIGPIPE in that manual page... I set SIGPIPE on ignore around the pipe-closing as a work-around, but I think, this is a bug... The thing is part of TclX' self-test (test signal-3.0) -- and it was not dying from SIGPIPE before the FreeBSD-7.x, as far as I can remember... It still seems to be fine on Linux... Have there been any changes in this area in FreeBSD? Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Can close-ing a pipe trigger a SIGPIPE?
Kostik Belousov написав(ла): Take ktrace of both parent and child. Great idea! Here is the kdump's listing for both (after ktrace -i): http://aldan.algebra.com/~mi/tmp/tclx-kdump.txt (it is large, so be sure to use a compressing browser). Once loaded, look for substring: Error SIGPIPE signal received while closing file5. The parent process-ID is 92722. The child -- 92723. Thanks! Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Can close-ing a pipe trigger a SIGPIPE?
Kostik Belousov написав(ла): Take ktrace of both parent and child. I can see the curious piece right here: The child exits: 92723 tclsh8.5 CALL exit(0) The parent masks SIGPIPE (as part of my workaround): 92722 tclsh8.5 CALL sigaction(SIGPIPE,0x7fffa9e0,0) 92722 tclsh8.5 RET sigaction 0 This 0-size write must be part of the pipe-closing -- descriptors 4 and 5 must be the pipe's: 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) 92722 tclsh8.5 RET write -1 errno 32 Broken pipe 92722 tclsh8.5 PSIG SIGPIPE caught handler=0x800f126d0 mask=0x0 code=0x0 92722 tclsh8.5 CALL sigreturn(0x7fffa0c0) 92722 tclsh8.5 RET sigreturn JUSTRETURN 92722 tclsh8.5 CALL close(0x5) 92722 tclsh8.5 RET close 0 92722 tclsh8.5 CALL close(0x4) 92722 tclsh8.5 RET close 0 Why would it write 0 bytes? Is doing so triggering a SIGPIPE now -- but, perhaps, didn't use to? Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Can close-ing a pipe trigger a SIGPIPE?
Jilles Tjoelker написав(ла): It seems unwise to assume that a write(2) of 0 bytes is a noop. Even if it is, doing it is a waste of a system call. This is not my code -- it is part of the implementation of Tcl's close command. I'm trying to unravel, where this write coming from, but, meanwhile, it would be useful to find out, if FreeBSD's handling of such writes changed recently, wouldn't it? Because this self-test used to pass cleanly before, so either FreeBSD changed, or the Tcl did (not the TclX extension, which did not change in years). Thanks for your help... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Can close-ing a pipe trigger a SIGPIPE?
Kostik Belousov написав(ла): This 0-size write must be part of the pipe-closing -- descriptors 4 and 5 must be the pipe's: 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) 92722 tclsh8.5 RET write -1 errno 32 Broken pipe 92722 tclsh8.5 PSIG SIGPIPE caught handler=0x800f126d0 mask=0x0 code=0x0 92722 tclsh8.5 CALL sigreturn(0x7fffa0c0) 92722 tclsh8.5 RET sigreturn JUSTRETURN 92722 tclsh8.5 CALL close(0x5) 92722 tclsh8.5 RET close 0 92722 tclsh8.5 CALL close(0x4) 92722 tclsh8.5 RET close 0 Why would it write 0 bytes? Is doing so triggering a SIGPIPE now -- but, perhaps, didn't use to? Obviously, I cannot answer the question. This is something that should be read from source code or asked by authors. You -- or someone else -- could comment like: a) Yeah, the meaning of write-ing 0 bytes changed in version such and such to conform to such and such standard. or b) No, nothing changed in that area of FreeBSD for years -- there must be something in Tcl itself. Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
process stuck in umtxn
Hello! I noticed, that my build of KDE4 ports got suspiciously quiet... Pressing Ctrl-T shows: load: 0.01 cmd: automoc4 78507 [umtxn] 0.00u 0.00s 0% 3552k According to gdb, the process' stack is: #0 0x000800d9620a in __error () from /lib/libthr.so.3 #1 0x000800d95f0c in __error () from /lib/libthr.so.3 #2 0x000800d911eb in pthread_mutex_getyieldloops_np () from /lib/libthr.so.3 #3 0x000800f0941b in _malloc_postfork () from /lib/libc.so.7 #4 0x000800d93c60 in fork () from /lib/libthr.so.3 #5 0x000800778e4a in QProcessPrivate::startProcess () from /opt/lib/qt4/libQtCore.so.4 #6 0x00080073f2c6 in QProcess::start () from /opt/lib/qt4/libQtCore.so.4 My system is 7.2-PRERELEASE/amd64 from April 9th. Please, advise. Thanks! Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
backup strategy (Re: dump | restore fails)
Greg Black написав(ла): Sorry, this person is *not* making backups in any meaningful fashion. Unless you verify regularly (preferably every time you make a backup) that you can restore both parts of the backup and the entire thing, you are not making backups. To qualify for your (and your kind's) recognition then, a person needs to have at least as much extra storage capacity as the largest filesystem they are backing up. They also need non-trivial scripting abilities, because the OS doesn't include anything like what you are describing (and I already do consider scheduling dumps via cron trivial, which may be a stretch). Yours may thus be an acceptable requirement for a multi-computer shop with dedicated system administration personnel, but for a private home user with only one computer this simply is not reasonable. Stating this as a requirement is ridiculous -- unless you are prepared to say, that such people should not own a computer (with worthy data) at all. And that's even more ridiculous... Make your pick. I would agree with you, if the chosen backup method involved some complex or third-party tools. But if the simple, OS-supplied orthogonal dump/restore don't work together, then the OS is broken -- plain and simple, and pointing a finger at the user: Well, it is all your fault, because you relied on us providing you with working utilities, ha-ha-ha! -- is the lamest excuse imaginable. -mi P.S. Some people have actually volunteered to help debug this problem and I'm working on providing them with data (the troublesome partition is, sadly, over 170Gb, so it takes a while). Any results/conclusions will be posted under the original subject. P.P.S. The data transferred fine using tar, but that is not the point -- the bug (confirmed by at least one more person) -- needs to be fixed before a higher-profile embarrassment... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: backup strategy (Re: dump | restore fails)
Andrew Snow написав(ла): Mikhail T. wrote: To qualify for your (and your kind's) recognition then, a person needs to have at least as much extra storage capacity as the largest filesystem they are backing up. They also need non-trivial scripting abilities, because the OS doesn't include anything like what you are describing Mikhail, users would be well advised to check their backups using this option, without having to have the space to restore: -N Do the extraction normally, but do not actually write any changes to disk. This can be used to check the integrity of dump media or other test purposes. And then another purist will reject this as a fake and not sufficiently conclusive test... Just ask around... Because, you see, until you extract all data back and run a bit-by-bit comparison with the original, you don't really know, do you? -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dump | restore fails: unknown tape header type 1853384566
Greg Black написав(ла): On 2009-03-24, Mikhail T. wrote: That's true. I just wanted to point out, that someone running dump only (to make backups) is not going to know, whether his dumps are usable (for whichever of the two reasons), until he needs them... Such a person is not making backups and deserves what he gets. But he *is* making backups -- kindly re-read my paragraph above... He just is not routinely using them and thus does not know, that they aren't usable... It is not unreasonable to expect the two utilities to just work, so I wouldn't be blaming such a person for not testing restore. That such a scenario is possible, despite the user making diligent regular backups, is a very bad sign... I haven't got anything to say about dump/restore because I haven't bothered with them for years. I do know that dumps from mounted file systems will often appear to work, but will fail when it matters. This is not a bug and is expected behaviour to which the solution is obvious. FS being mounted read-only should not be a problem. And even read-write mounted filesystems will be Ok, although possibly inconsistent (a file modified during backup may get to into dump as of any point). But an idle FS is Ok to dump. Generally, when dumping read-write mounted filesystems, one is supposed to use snapshots, but that is very buggy on its own (leading to kernel crashes), so it is safer to rely on the FS being idle, if it can not be forced into read-only for some other reason. -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dump | restore fails: unknown tape header type 1853384566
Daniel O'Connor написав(ла): On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote: I'm trying to migrate a filesystem from one disk to another using: dump a0hCf 0 32 - /old | restore -rf - (/old is already mounted read-only). The process runs for a while and then stops with: [...] DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009 DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009 DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009 unknown tape header type 1853384566 abort? [yn] Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's dump's output? What happens if you don't use the cache? No big difference: dump a0f - /old | restore -rf - [...] DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009 DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009 DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009 unknown tape header type -621260722 abort? [yn] Looks like a junk value somewhere... Unitialized variable or some such. -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dump | restore fails: unknown tape header type 1853384566
Danny Braniss написав(ла): Daniel O'Connor написав(ла): On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote: I'm trying to migrate a filesystem from one disk to another using: dump a0hCf 0 32 - /old | restore -rf - (/old is already mounted read-only). The process runs for a while and then stops with: [...] DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009 DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009 DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009 unknown tape header type 1853384566 abort? [yn] Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's dump's output? What happens if you don't use the cache? No big difference: dump a0f - /old | restore -rf - [...] DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009 DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009 DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009 unknown tape header type -621260722 abort? [yn] Looks like a junk value somewhere... Unitialized variable or some such. can you try splitting it in 2, ie no pipe? dump a0f some.file /old (or dump 0f - /old | gzip -c file.dump.gz) restore rf some.file danny Well, the first part (the dump) runs almost to the completion, but hangs at the very end for some reason: dump 0aCf 64 /ibm/ibmo.0.2009-03-24.dump /old DUMP: WARNING: should use -L when dumping live read-write filesystems! DUMP: Date of this level 0 dump: Tue Mar 24 05:59:27 2009 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/ad2s1e (/ibmo) to /ibm/ibmo.0.2009-03-24.dump DUMP: mapping (Pass I) [regular files] DUMP: Cache 64 MB, blocksize = 65536 DUMP: mapping (Pass II) [directories] DUMP: estimated 152357442 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 0.83% done, finished in 9:59 at Tue Mar 24 16:04:19 2009 DUMP: 2.74% done, finished in 5:55 at Tue Mar 24 12:05:07 2009 DUMP: 4.66% done, finished in 5:06 at Tue Mar 24 11:21:27 2009 DUMP: 6.58% done, finished in 4:43 at Tue Mar 24 11:03:37 2009 ... DUMP: 91.54% done, finished in 0:23 at Tue Mar 24 10:38:15 2009 DUMP: 93.41% done, finished in 0:18 at Tue Mar 24 10:38:02 2009 DUMP: 95.27% done, finished in 0:13 at Tue Mar 24 10:37:50 2009 DUMP: 97.15% done, finished in 0:07 at Tue Mar 24 10:37:36 2009 DUMP: 99.03% done, finished in 0:02 at Tue Mar 24 10:37:23 2009 DUMP: DUMP: 152769349 tape blocks on 1 volume DUMP: finished in 16706 seconds, throughput 9144 KBytes/sec [... Hang ...] load: 0.18 cmd: dump 10105 [sbwait] 72.53u 383.14s 0% 73048k load: 0.19 cmd: dump 10102 [sbwait] 164.93u 314.87s 0% 75008k load: 0.10 cmd: dump 10102 [running] 164.93u 314.87s 0% 75008k The timestamp on the output file is, indeed, 10:38 and the dumping process is hanging ever since then (over 90 minutes already). Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dump | restore fails: unknown tape header type 1853384566
Danny Braniss написав(ла): can you try splitting it in 2, ie no pipe? dump a0f some.file /old (or dump 0f - /old | gzip -c file.dump.gz) restore rf some.file Same problem: restore -rf ibmo.0.2009-03-24.dump load: 0.55 cmd: restore 11303 [nbufkv] 3.53u 3.91s 4% 27980k unknown tape header type 213474529 abort? [yn] Please, advise. Thanks! Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dump | restore fails: unknown tape header type 1853384566
Andrew Snow написав(ла): Mikhail T. wrote: dump 0aCf 64 /ibm/ibmo.0.2009-03-24.dump /old DUMP: WARNING: should use -L when dumping live read-write filesystems! I thought you said it was a read-only filesystem? It was yesterday. Today I remounted it rw to remove some junk-files, which I don't need to transfer. I don't believe, this is causing the problems. In my experience, restore can sometimes throw warnings if you dump a live filesystem. It might be causing your errors? If possible, can you try completely unmounting the filesystem you are dumping and trying again? I don't think, restore can even figure this out, much less throw a warning -- it is dump, that complains... But the dump started this morning is still hanging (in sbwait) -- I've never seen this before. I'm also very troubled, that such an important functionality (dump/restore!) is sooo problem-prone, and yet so few people seem to care... Is the official view, that dump is obsolete (and already bit-rotten), perhaps, and use of tar is encouraged instead? -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dump | restore fails: unknown tape header type 1853384566
Daniel O'Connor написав(ла): morning is still hanging (in sbwait) -- I've never seen this before. I'm also very troubled, that such an important functionality (dump/restore!) is sooo problem-prone, and yet so few people seem to care... Well, works for me. Well, would like a login on this system to take a look for yourself? I can reproduce the problem easily. Is the official view, that dump is obsolete (and already bit-rotten), perhaps, and use of tar is encouraged instead? I've never had dump fail but it IS rather crusty and slow.. That said tar doesn't cover all the information I believe. So, if dump/restore ain't it, does FreeBSD have a supported way of making filesystem-level backups, that's both modern and covers all aspects (like flags)? That said, I point out, that for me, dump is not failing (although it did hang this morning). It is the restore, which fails to read dump's output: unknown tape header type 213474529 abort? [yn] n resync restore, skipped 502 blocks expected next file 54, got 0 unknown tape header type -954356454 abort? [yn] n resync restore, skipped 29 blocks expected next file 54, got 0 unknown tape header type -1754938223 abort? [yn] n resync restore, skipped 482 blocks expected next file 54, got 0 unknown tape header type -915868704 abort? [yn] n resync restore, skipped 29 blocks expected next file 54, got 0 unknown tape header type 1790084751 abort? [yn] n resync restore, skipped 482 blocks expected next file 54, got 0 unknown tape header type 903667267 abort? [yn] n ... Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dump | restore fails: unknown tape header type 1853384566
Yoshihiro Ota написав(ла): No big difference: dump a0f - /old | restore -rf - [...] DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009 DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009 DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009 unknown tape header type -621260722 abort? [yn] Looks like a junk value somewhere... Unitialized variable or some such. -mi -a option seems to be the problem. Try without it. As could be expected, it failed exactly the same without the obviously unrelated -a option: r...@symbion:/ibm (113) dump 0f - /ibmo | restore -rf - DUMP: Date of this level 0 dump: Tue Mar 24 21:31:19 2009 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/ad2s1e (/ibmo) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 152357442 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 0.16% done, finished in 242:05 at Sat Apr 4 00:00:21 2009 DUMP: 4.29% done, finished in 10:24 at Wed Mar 25 08:24:02 2009 DUMP: 8.56% done, finished in 5:52 at Wed Mar 25 03:56:43 2009 DUMP: 11.76% done, finished in 4:35 at Wed Mar 25 02:43:29 2009 DUMP: 16.00% done, finished in 3:38 at Wed Mar 25 01:52:05 2009 DUMP: 19.28% done, finished in 3:15 at Wed Mar 25 01:33:43 2009 DUMP: 22.74% done, finished in 2:55 at Wed Mar 25 01:18:49 2009 unknown tape header type 1431655765 abort? [yn] n resync restore, skipped 9 blocks expected next file 1599492, got 0 DUMP: 24.50% done, finished in 3:27 at Wed Mar 25 02:05:41 2009 unknown tape header type 1508167078 abort? [yn] n resync restore, skipped 66 blocks expected next file 1599492, got 0 unknown tape header type -1493630979 abort? [yn] y dump core? [yn] n DUMP: Broken pipe DUMP: The ENTIRE dump is aborted. Now can one get /real/ support for the most basic functionality of the most advanced modern Unix in the world? Thanks, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dump | restore fails: unknown tape header type 1853384566
Andrew Snow написав(ла): Mikhail T. wrote: Now can one get /real/ support for the most basic functionality of the most advanced modern Unix in the world? Thanks, I think before this goes any further, you will need to try rebooting/unmouting it, running fsck on it, and then dump the unmounted partition and see how that goes. The system's uptime is only 3 days -- I had to reboot it to put in the new disk... But I will try your suggestion next, after the current attempt (using restore's -v switch) ends. If it chokes on the same file every time, that would be a clue... Thanks, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dump | restore fails: unknown tape header type 1853384566
Daniel O'Connor написав(ла): That said, I point out, that for me, dump is not failing (although it did hang this morning). It is the restore, which fails to read dump's output: You can't tell the difference between dump producing mangled output or restore bombing out on valid input.. That's true. I just wanted to point out, that someone running dump only (to make backups) is not going to know, whether his dumps are usable (for whichever of the two reasons), until he needs them... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dump | restore fails: unknown tape header type 1853384566
Daniel O'Connor написав(ла): On Wednesday 25 March 2009 13:10:23 Mikhail T. wrote: Now can one get /real/ support for the most basic functionality of the most advanced modern Unix in the world? Thanks, Maybe you should return it to the shop and ask for your money back. Well, if this response is the best one can get, may be I should also revoke my own 15 years worth of contributions to the project... Except, why would I? I always supported people, who had problems with any of my work -- and the attitude of the rest of the contributors /used to be/ the same... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
support quality (Re: dump | restore fails: unknown tape header type 1853384566)
Daniel O'Connor написав(ла): People ARE helping you, just because they haven't come up with an answer is no reason to send snarky comments to the list. No, sorry, people aren't. They are trying, yes, but not even close. The suggestion to eliminate the -a switch (a no-op, in fact) was particularly unhelpful -- and deserving of mockery. Later on someone with a similar problem will find this thread with a search engine and will be trying to follow the posted advices -- to no avail, of course, plunging FreeBSD further into disrepute. Outrage (fake or otherwise) that people don't seem to be taking your particular problem seriously is unhelpful and probably counter-productive. It is fairly obvious by now, that no real help will be forthcoming, for whatever reason. Thus any talk of productivity is moot. Thanks for trying. -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dump | restore fails: unknown tape header type 1853384566
Andrew Snow написав(ла): I think before this goes any further, you will need to try rebooting/unmouting it, running fsck on it, and then dump the unmounted partition and see how that goes. Rebooted, reran `fsck -y /old' (all clean). Same problem... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
dump | restore fails: unknown tape header type 1853384566
Hello! I'm trying to migrate a filesystem from one disk to another using: dump a0hCf 0 32 - /old | restore -rf - (/old is already mounted read-only). The process runs for a while and then stops with: [...] DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009 DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009 DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009 unknown tape header type 1853384566 abort? [yn] Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's dump's output? The system runs 7.0-STABLE from July 6th, i386. I just tried updating the dump and restore from source (latest 7.x) -- the error is the same... Please, advise. Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
software vs. hardware memory holes (fault on nofault entry panic)
Hello! My FreeBSD/amd64 system has two processors, each with 2 out of 4 memory slots filled. The total RAM is 4Gb. In the BIOS there are options to enable Software memory hole and Hardware memory hole. The only way to have the entire 4Gb of physical RAM enabled is to have Software memory hole only. Enabling the hardware hole leads to the detection of only 3.6Gb. From /var/run/dmesg.boot: usable memory = 3783233536 (3607 MB) avail memory = 3597369344 (3430 MB) Unfortunately, when Software memory hole is enabled -- regardless of whether the hardware one is enabled or not -- trying to transfer a file via firewire: fwcontrol -M mpg -R /store/videos/tape1.mpg leads to a panic instantly: Unread portion of the kernel message buffer: panic: vm_fault: fault on nofault entry, addr: b0796000 cpuid = 0 Uptime: 2m10s Physical memory: 4087 MB Dumping 295 MB:fwohci0: Isochronous receive err 8402(long) fwohci0: Isochronous receive err 8402(long) fwohci0: Isochronous receive err 8402(long) fwohci0: Isochronous receive err 8402(long) fwohci0: Isochronous receive err 8402(long) fwohci0: Isochronous receive err 8402(long) fwohci0: Isochronous receive err 8402(long) fwohci0: Isochronous receive err 8402(long) 280fwohci0: Isochronous receive err 8402(long) fwohci0: Isochronous receive err 8402(long) 264fwohci0: Isochronous receive err 8402(long) 248fwohci0: Isochronous receive err 8402(long) 232fwohci0: Isochronous receive err 8402(long) fwohci0: Isochronous receive err 8402(long) 216fwohci0: Isochronous receive err 8402(long) fwohci0: Isochronous receive err 8402(long) fwohci0: Isochronous receive err 8402(long) 200 184 168 152 136 120 104 88 72 56 40 24 8 #0 doadump () at pcpu.h:194 194 __asm __volatile(movq %%gs:0,%0 : =r (td)); (kgdb) #0 doadump () at pcpu.h:194 #1 0x0004 in ?? () #2 0x802e8b60 in boot (howto=260) at /var/src/sys/kern/kern_shutdown.c:409 #3 0x802e8f7d in panic (fmt=0x104 Address 0x104 out of bounds) at /var/src/sys/kern/kern_shutdown.c:563 #4 0x80424f63 in vm_fault (map=0xff000100, vaddr=18446744072375328768, fault_type=1 '\001', fault_flags=0) at /var/src/sys/vm/vm_fault.c:275 #5 0x8045a4ff in trap_pfault (frame=0xb05cc8d0, usermode=0) at /var/src/sys/amd64/amd64/trap.c:630 #6 0x8045ae49 in trap (frame=0xb05cc8d0) at /var/src/sys/amd64/amd64/trap.c:410 #7 0x8043f17e in calltrap () at /var/src/sys/amd64/amd64/exception.S:169 #8 0x804596db in copyout () at /var/src/sys/amd64/amd64/support.S:257 #9 0x802f0440 in uiomove (cp=0xb0795e00, n=588, uio=0xb05ccb00) at /var/src/sys/kern/kern_subr.c:168 #10 0x8021901a in fw_read (dev=) at /var/src/sys/dev/firewire/fwdev.c:403 #11 0x80297ca4 in devfs_read_f (fp=0xff0003fa9348, uio=0xb05ccb00, cred=) at /var/src/sys/fs/devfs/devfs_vnops.c:880 #12 0x8031da7d in dofileread (td=0xff00038b49c0, fd=3, fp=0xff0003fa9348, auio=0xb05ccb00, offset=) at file.h:242 #13 0x8031ddee in kern_readv (td=0xff00038b49c0, fd=3, auio=0xb05ccb00) at /var/src/sys/kern/sys_generic.c:192 #14 0x8031dedc in read (td=0x612a94, uap=0xb0796000) at /var/src/sys/kern/sys_generic.c:108 #15 0x8045a700 in syscall (frame=0xb05ccc70) at /var/src/sys/amd64/amd64/trap.c:852 #16 0x8043f38b in Xfast_syscall () at /var/src/sys/amd64/amd64/exception.S:290 #17 0x00080070a34c in ?? () (kgdb) Having the hardware hole ONLY enabled allows for video transfers... Please, advise. Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: ffs_truncate: readonly filesystem
Hello! I tried, accidentally, to save a video-file (via firewire) to a read-only location. The entire system paniced with the message in subject. Why did it happen? Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
another: supervisor read, page not present
The kernel is from:
FreeBSD 6.3-STABLE #0: Thu Feb 7 ... amd64
The crash:
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0xffe3ffe3e010
fault code = supervisor read data, page not present
instruction pointer = 0x8:0x80414d98
stack pointer = 0x10:0xd62714d0
frame pointer = 0x10:0xff016e6ce9e0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 10919 (kdeinit)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 19h29m22s
Dumping 4095 MB (3 chunks)
chunk 0: 1MB (156 pages) ... ok
chunk 1: 2047MB (524016 pages) 2031 2015 1999 1983 1967 1951 1935 1919 1903
1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 (CTRL-C to abort)
(CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort)
1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471
1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215
1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959
943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639
623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319
303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 ... ok
chunk 2: 2048MB (524288 pages) 2033 2017 2001 1985 1969 1953 1937 1921 1905
1889 1873 1857 1841 1825 1809 1793 1777 1761 1745 1729 1713 1697 1681 1665 1649
1633 1617 1601 1585 1569 1553 1537 1521 1505 1489 1473 1457 1441 1425 1409 1393
1377 1361 1345 1329 1313 1297 1281 1265 1249 1233 1217 1201 1185 1169 1153 1137
1121 1105 1089 1073 1057 1041 1025 1009 993 977 961 945 929 913 897 881 865 849
833 817 801 785 769 753 737 721 705 689 673 657 641 625 609 593 577 561 545 529
513 497 481 465 449 433 417 401 385 369 353 337 321 305 289 273 257 241 225 209
193 177 161 145 129 113 97 81 65 49 33 17 1
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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 amd64-marcel-freebsd...
(kgdb) #0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x802ba757 in boot (howto=260)
at ../../../kern/kern_shutdown.c:409
#3 0x802badf1 in panic (
fmt=0xff013c235be0 X\223і[EMAIL PROTECTED])
at ../../../kern/kern_shutdown.c:565
#4 0x8041e31f in trap_fatal (frame=0xff013c235be0,
eva=18446742979543995224) at ../../../amd64/amd64/trap.c:669
#5 0x8041e69c in trap_pfault (frame=0xd6271420, usermode=0)
at ../../../amd64/amd64/trap.c:580
#6 0x8041e953 in trap (frame=
{tf_rdi = -1099511627776, tf_rsi = 16386, tf_rdx = -120260927488, tf_rcx
= 4503599627366400, tf_r8 = 0, tf_r9 = 5, tf_rax = -120260927472, tf_rbx = 0,
tf_rbp = -1093364028960, tf_r10 = 0, tf_r11 = 1, tf_r12 = 34365251584, tf_r13 =
-1093364028960, tf_r14 = -1093237757744, tf_r15 = 5, tf_trapno = 12, tf_addr =
-120260927472, tf_flags = 0, tf_err = 0, tf_rip = -2143203944, tf_cs = 8,
tf_rflags = 66178, tf_rsp = -702081824, tf_ss = 0})
at ../../../amd64/amd64/trap.c:353
#7 0x8040456b in calltrap () at ../../../amd64/amd64/exception.S:168
#8 0x80414d98 in pmap_enter_quick_locked (pmap=0xff016e6ce9e0,
va=34365251584, m=0xff0175f3a8d0, prot=5 '\005', mpte=0x0)
at ../../../amd64/amd64/pmap.c:2298
#9 0x80414fdf in pmap_enter_object (pmap=0xff016e6ce9e0,
start=34365251584, end=18446743953448624128, m_start=0xff0175f3a8d0,
prot=5 '\005') at ../../../amd64/amd64/pmap.c:2235
#10 0x803ee67d in vm_map_pmap_enter (map=0xff016e6ce880,
addr=34365251584, prot=5 '\005', object=0xff0174b899a0,
pindex=18446742980345522304, size=18446742980472635672, flags=0)
at ../../../vm/vm_map.c:1539
#11 0x803ee9e4 in vm_map_insert (map=0xff016e6ce880,
object=0xff0174b899a0, offset=0, start=34365251584, end=34365411328,
prot=5 '\005', max=7 '\a', cow=0) at ../../../vm/vm_map.c:1069
#12 0x8027f646 in elf64_map_insert (map=0xff016e6ce880,
object=0xff0174b899a0, offset=0, start=34365251584, end=34365411328,
prot=5 '\005', cow=-1843184) at ../../../kern/imgact_elf.c:327
#13 0x8027f74f in elf64_load_section (vmspace=0xff016e6ce880,
object=0xff0174b899a0, offset=16386,
vmaddr=0x800542000 Address 0x800542000 out of bounds, memsz=158641,
filsz=158641, prot=5 '\005', pagesize=4096)
at ../../../kern/imgact_elf.c:386
panic in vm_page_splay
Hello!
The machine is running 6.3-PRERELEASE as of Dec 30th. It just paniced in
the middle of web-session as I was browsing for a file to upload via a
web-form... The firefox in use is native (amd64), not a Linux-binary.
The firefox process had over 550Mb of memory to its name -- it was
running for many days. The box has 2Gb of RAM and was performing fine
despite 4 SETI-processes in the background.
Please, advise. Thanks!
-mi
Unread portion of the kernel message buffer:
6pid 1759 (firefox-bin), uid 105: exited on signal 10
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x37
fault code = supervisor read data, page not present
instruction pointer = 0x8:0x803f61ec
stack pointer = 0x10:0xd569d550
frame pointer = 0x10:0xff000eb7dd20
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1759 (firefox-bin)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 12d23h10m1s
Dumping 2047 MB (2 chunks)
chunk 0: 1MB (156 pages) ... ok
chunk 1: 2047MB (524016 pages) 2031 2015 1999 1983 1967 1951 1935 1919 1903
1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647
1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391
1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135
1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207
191 175 159 143 127 111 95 79 63 47 31 15
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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 amd64-marcel-freebsd...
(kgdb) #0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x802b9a47 in boot (howto=260)
at /var/src/sys/kern/kern_shutdown.c:409
#3 0x802ba0e1 in panic (fmt=0xff0050186980 XCРH)
at /var/src/sys/kern/kern_shutdown.c:565
#4 0x8041d53f in trap_fatal (frame=0xff0050186980,
eva=18446742975421760344) at /var/src/sys/amd64/amd64/trap.c:669
#5 0x8041d8bc in trap_pfault (frame=0xd569d4a0, usermode=0)
at /var/src/sys/amd64/amd64/trap.c:580
#6 0x8041db73 in trap (frame=
{tf_rdi = 6954, tf_rsi = -1095227851400, tf_rdx = -1, tf_rcx =
-714484384, tf_r8 = -1097410313744, tf_r9 = 1, tf_rax = -1, tf_rbx =
-1097426921984, tf_rbp = -1099264697056, tf_r10 = -2140891880, tf_r11 =
-1097890882032, tf_r12 = 0, tf_r13 = 4, tf_r14 = 0, tf_r15 = 4, tf_trapno = 12,
tf_addr = 55, tf_flags = -1098167850624, tf_err = 0, tf_rip = -2143329812,
tf_cs = 8, tf_rflags = 66182, tf_rsp = -714484384, tf_ss = 16}) at
/var/src/sys/amd64/amd64/trap.c:353
#7 0x8040373b in calltrap ()
at /var/src/sys/amd64/amd64/exception.S:168
#8 0x803f61ec in vm_page_splay (pindex=6954, root=0xff00ff553d78)
at /var/src/sys/vm/vm_page.c:554
#9 0x803f6491 in vm_page_remove (m=0xff007c421600)
at /var/src/sys/vm/vm_page.c:696
#10 0x803f67cf in vm_page_free_toq (m=0xff007c421600)
at /var/src/sys/vm/vm_page.c:1113
#11 0x803f6a96 in vm_page_free (m=0xff007c421600)
at /var/src/sys/vm/vm_page.c:471
#12 0x803f34c9 in vm_object_terminate (object=0xff000eb7dd20)
at /var/src/sys/vm/vm_object.c:652
#13 0x803f4a06 in vm_object_deallocate (object=0xff000eb7dd20)
at /var/src/sys/vm/vm_object.c:585
#14 0x803ef036 in vm_map_delete (map=0xff006f9f0880,
start=1844674297854560, end=140737488355328)
at /var/src/sys/vm/vm_map.c:2311
#15 0x803ef32c in vmspace_exit (td=0xff0050186980)
at /var/src/sys/vm/vm_map.c:324
#16 0x8029995d in exit1 (td=0xff0050186980, rv=10)
at /var/src/sys/kern/kern_exit.c:295
#17 0x802be2ec in sigexit (td=0xff0050186980, sig=10)
at /var/src/sys/kern/kern_sig.c:2459
#18 0x802a0dac in kse_thr_interrupt (td=0xff0050186980,
uap=0xd569dbc0) at /var/src/sys/kern/kern_kse.c:239
#19 0x8041e431 in syscall (frame=
{tf_rdi = 0, tf_rsi = 4, tf_rdx = 10, tf_rcx = 9, tf_r8 = 5374312, tf_r9
= 1, tf_rax = 382, tf_rbx = 0, tf_rbp = 5386240, tf_r10 = -1097592722432,
tf_r11 = 515, tf_r12 = 512, tf_r13 = 10, tf_r14 = 10, tf_r15 = 34365240304,
tf_trapno = 9, tf_addr = 0, tf_flags = 160, tf_err = 2, tf_rip = 34413158236,
tf_cs = 43, tf_rflags = 582, tf_rsp = 6598280, tf_ss
panic in g_up
Hello!
I was working remotely, when suddenly the server dropped off the 'net.
Upon reboot it was stuck in unexpected softupdates inconsistency (I
did not have fsck_y_enable set).
Here is the panic:
Unread portion of the kernel message buffer:
Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 01
instruction pointer = 0x8:0x803be0ed
stack pointer = 0x10:0xb1ae0b10
frame pointer = 0x10:0xff005fa23380
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 3 (g_up)
trap number = 9
panic: general protection fault
cpuid = 1
Uptime: 29m52s
Dumping 2047 MB (2 chunks)
chunk 0: 1MB (156 pages) ... ok
chunk 1: 2047MB (524016 pages) 2031 2015 1999 1983 1967 1951 1935 1919 1903
1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647
1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391
1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135
1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207
191 175 159 143 127 111 95 79 63 47 31 15
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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 amd64-marcel-freebsd...
(kgdb) #0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x802b2d87 in boot (howto=260)
at /var/src/sys/kern/kern_shutdown.c:409
#3 0x802b3421 in panic (fmt=0xff007b9e7000 ╟ж═{)
at /var/src/sys/kern/kern_shutdown.c:565
#4 0x804140ff in trap_fatal (frame=0xff007b9e7000,
eva=18446742976272062128) at /var/src/sys/amd64/amd64/trap.c:668
#5 0x80414602 in trap (frame=
{tf_rdi = -1098100966016, tf_rsi = -1097437646848, tf_rdx =
164931039068161, tf_rcx = 0, tf_r8 = -6241704602446071034, tf_r9 = -2141060032,
tf_rax = 0, tf_rbx = -1099511589376, tf_rbp = -1097907162240, tf_r10 =
-2141060032, tf_r11 = -2144905952, tf_r12 = -1616167584, tf_r13 = -2144915520,
tf_r14 = 0, tf_r15 = -1097907162240, tf_trapno = 9, tf_addr = 0, tf_flags =
-1097437646848, tf_err = 0, tf_rip = -2143559443, tf_cs = 8, tf_rflags = 66050,
tf_rsp = -1313993952, tf_ss = 16}) at /var/src/sys/amd64/amd64/trap.c:470
#6 0x803fb35b in calltrap ()
at /var/src/sys/amd64/amd64/exception.S:168
#7 0x803be0ed in softdep_disk_write_complete (bp=0x9fab3d60)
at /var/src/sys/ufs/ffs/ffs_softdep.c:4755
#8 0x8030edba in bufdone (bp=0x9fab3d60) at buf.h:440
#9 0x802755a5 in g_vfs_done (bip=0x0)
at /var/src/sys/geom/geom_vfs.c:87
#10 0x80272d3d in g_io_schedule_up (tp=0xff005414fd80)
at /var/src/sys/geom/geom_io.c:490
#11 0x8027304c in g_up_procbody () at /var/src/sys/geom/geom_kern.c:95
#12 0x80297e17 in fork_exit (
callout=0x80272fc0 g_up_procbody, arg=0x0,
frame=0xb1ae0c50) at /var/src/sys/kern/kern_fork.c:821
#13 0x803fb6be in fork_trampoline ()
at /var/src/sys/amd64/amd64/exception.S:394
#14 0x in ?? ()
#15 0x in ?? ()
#16 0x0001 in ?? ()
#17 0x in ?? ()
#18 0x in ?? ()
#19 0x in ?? ()
#20 0x in ?? ()
#21 0x in ?? ()
#22 0x in ?? ()
#23 0x in ?? ()
#24 0x in ?? ()
#25 0x in ?? ()
#26 0x in ?? ()
#27 0x in ?? ()
#28 0x in ?? ()
#29 0x in ?? ()
#30 0x in ?? ()
#31 0x in ?? ()
#32 0x in ?? ()
#33 0x in ?? ()
#34 0x in ?? ()
#35 0x in ?? ()
#36 0x in ?? ()
#37 0x in ?? ()
#38 0x in ?? ()
#39 0x in ?? ()
#40 0x in ?? ()
#41 0x in ?? ()
#42 0x in ?? ()
#43 0x in ?? ()
#44 0x in ?? ()
#45 0x in ?? ()
#46 0x00824000 in ?? ()
#47 0xff007ba0d6b0 in ?? ()
#48 0x0104 in ?? ()
#49 0x in ?? ()
#50 0xff007ba0d6b0 in ?? ()
#51 0xff007b9e7be0 in ?? ()
#52 0xb1ae0818 in ?? ()
#53 0xff007b9e7000 in ?? ()
#54 0x802ca546 in sched_switch (td=0x0, newtd=0x0, flags=0)
at
plugging in a new SATA drive causes panic
I'm not 100% certain, this is a legal thing to do. But I think
it is.
I hooked up a brand new hard-drive (Seagate) to the free SATA port,
and then connected the power cable. Before that I had just one SATA
drive (ad8).
The kernel crashed in ata_identify(). I'll keep the core around for
some time -- let me know, if you need more investigation...
The kernel is 6.2-STABLE #1: Thu Jun 7 22:11:33 EDT 2007 ... amd64
-mi
Unread portion of the kernel message buffer:
ad10: 715404MB Seagate ST3750640AS 3.AAE at ata5-master SATA150
ad8: 476940MB HDS725050KLA360 K2AOA11A at ata4-master SATA150
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x50
fault code = supervisor read data, page not present
instruction pointer = 0x8:0x802cb59d
stack pointer = 0x10:0xb1b0db00
frame pointer = 0x10:0xff004ed45100
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 8 (thread taskq)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 17d10h1m11s
Dumping 2047 MB (2 chunks)
chunk 0: 1MB (156 pages) ... ok
chunk 1: 2047MB (524016 pages) 2031 2015 1999 1983 1967 1951 1935 1919 1903
1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647
1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391
1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135
1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to
abort) 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127
111 95 79 63 47 31 15
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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 amd64-marcel-freebsd...
(kgdb) #0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x802b12b7 in boot (howto=260)
at /var/src/sys/kern/kern_shutdown.c:409
#3 0x802b1951 in panic (fmt=0xff007b9e8720 )
at /var/src/sys/kern/kern_shutdown.c:565
#4 0x80410faf in trap_fatal (frame=0xff007b9e8720,
eva=18446742976271941632) at /var/src/sys/amd64/amd64/trap.c:668
#5 0x8041132c in trap_pfault (frame=0xb1b0da50, usermode=0)
at /var/src/sys/amd64/amd64/trap.c:580
#6 0x804115e3 in trap (frame=
{tf_rdi = -1098189090560, tf_rsi = 4, tf_rdx = 0, tf_rcx = 1, tf_r8 =
-2141067120, tf_r9 = -1097437640928, tf_rax = 2, tf_rbx = -1098189090560,
tf_rbp = -1098189090560, tf_r10 = 72, tf_r11 = 1, tf_r12 = 0, tf_r13 = 0,
tf_r14 = 4294967295, tf_r15 = 10, tf_trapno = 12, tf_addr = 80, tf_flags = 0,
tf_err = 0, tf_rip = -2144553571, tf_cs = 8, tf_rflags = 66118, tf_rsp =
-1313809648, tf_ss = 0}) at /var/src/sys/amd64/amd64/trap.c:353
#7 0x803f825b in calltrap ()
at /var/src/sys/amd64/amd64/exception.S:168
#8 0x802cb59d in device_attach (dev=0xff004ed45100)
at /var/src/sys/kern/subr_bus.c:278
#9 0x802cc76f in bus_generic_attach (dev=0xff004ed45100)
at /var/src/sys/kern/subr_bus.c:2883
#10 0x801b48cd in ata_identify (dev=0xff007b98eb00)
at /var/src/sys/dev/ata/ata-all.c:718
#11 0x801b5891 in ata_sata_phy_event (context=0xff004ed45100,
dummy=4) at /var/src/sys/dev/ata/ata-chipset.c:273
#12 0x802d8b35 in taskqueue_run (queue=0xff902d00)
at /var/src/sys/kern/subr_taskqueue.c:257
#13 0x802d9885 in taskqueue_thread_loop (arg=0xff004ed45100)
at /var/src/sys/kern/subr_taskqueue.c:376
#14 0x80296347 in fork_exit (
callout=0x802d9800 taskqueue_thread_loop,
arg=0x8062a0f0, frame=0xb1b0dc50)
at /var/src/sys/kern/kern_fork.c:821
#15 0x803f85be in fork_trampoline ()
at /var/src/sys/amd64/amd64/exception.S:394
#16 0x in ?? ()
#17 0x in ?? ()
[...]
#127 0x in ?? ()
#128 0x in ?? ()
(kgdb) #10 0x801b48cd in ata_identify (dev=0xff007b98eb00)
at /var/src/sys/dev/ata/ata-all.c:718
718 bus_generic_attach(dev);
(kgdb) $1 = {ops = 0xff907000, link = {tqe_next = 0x0,
tqe_prev = 0xff007b98ec08}, devlink = {tqe_next = 0xff007b8fde00,
tqe_prev = 0xff007b98ec18}, parent = 0xff007b8fd800, children = {
tqh_first = 0xffe4db00, tqh_last = 0xff007b7e0308},
driver =
panic: vinvalbuf: dirty bufs
I was ripping one CD (SCSI CD-drive) and inserting another CD into an ATA CD-DRIVE. Suddenly the machine paniced... Although I have the crash dump, it seems corrupted -- kgdb can't print out the stack. The panic is: vinvalbuf: dirty bufs. Please, advise. Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
OS suddenly VERY busy
Hello! After a couple of huge tarball extracts (`make extract' in jdk14 and jdk15) I noticed, things are a little slower. During the extracts, the mouse was moving with visible jerks. Indeed, the system seems VERY busy: 11 usersLoad 1.18 1.52 1.40 Jul 20 00:14 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 1060360 105932 1341624 145252 151016 count All 1750432 115908 8911872 174532 pages zfod Interrupts Proc:r p d s wCsw Trp Sys Int Sof Fltcow1277 total 4 1146 1819 345 443k 1640 672 266572 wire 4 irq1: atkb 1204008 act1004 irq0: clk 84.7%Sys 0.0%Intr 15.3%User 0.0%Nice 0.0%Idl 241536 inact irq6: fdc0 |||||||||| 62232 cache 128 irq8: rtc ==88784 freeirq9: acpi daefr 113 irq12: psm Namei Name-cacheDir-cache prcfr irq15: ata Calls hits% hits% react irq16: ahc 3030 3030 100 pdwak26 irq17: pcm pdpgs irq18: fwo Disks da0 cd0 cd1 pass0 pass1 pass2 intrn irq19: ohc KB/t 4.00 0.00 0.00 0.00 0.00 0.00 218912 buf irq27: skc tps 2 0 0 0 0 0 21 dirty 2 irq29: cis MB/s 0.01 0.00 0.00 0.00 0.00 0.00 10 desiredvnodes % busy0 0 0 0 0 0 92043 numvnodes The machine is idle and is not doing anything in user-space according to both top and vmstat's pigs display. Yet it is noticably slower. Trying to compile something pushes the load above 2. What is it doing? This is a single-CPU Opteron running: FreeBSD 5.4-STABLE #0: Fri Jun 10 09:11:30 EDT 2005 amd64 The box has 2Gb of RAM, but NO SWAP. Any ideas? Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
