old laptop panics in agp_generic_attach

[Mikhail T.]

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 usbus0

core dumps onto ZFS

[Mikhail T.]

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

[Mikhail T.]

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&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

[Mikhail T.]

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

[Mikhail T.]

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

[Mikhail T.]

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

[Mikhail T.]

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"

Re: cp from NFS to ZFS hung in "fifoor"

[Mikhail T.]

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"

cp from NFS to ZFS hung in "fifoor"

[Mikhail T.]

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"

hyperv fails to build, when "nodevice ata" is set in kernel-config

[Mikhail T.]

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"

Re: runtime linker on 9.x/i386: clang vs. gcc

[Mikhail T.]

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"

runtime linker on 9.x/i386: clang vs. gcc

[Mikhail T.]

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 
 -- 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 
) 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"

smbfus: panic on the second attempt to reach unavailable server

[Mikhail T.]

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 = 
ts1 = 
td = 
   #8  0x80550e52 in _mtx_unlock_sleep (m=0xfe0105ecd8f0,
   opts=, file=, line=) at /cache/src/sys/kern/kern_mutex.c:715
ts = (struct turnstile *) 0x0
   #9  0x8101a0cd in smb_iod_invrq (iod=) 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 = 
iod = (struct smbiod *) 0xfe009483b800
error = 
__func__ = "uЪ", '\220' 
   #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 = 
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 = 
pbuf = 0x0
encpass = 0x0
error = 
plen = 1
upper = 0
   #13 0x8101ad1a in smb_iod_thread (arg=) at
   /cache/src/sys/modules/smbfs/../../netsmb/smb_iod.c:206
iod = (struct smbiod *) 0xfe009483b800
   #14 0x805365df in fork_exit (callout=0x8101aa83
   , arg=0xfe009483b800, frame=0xff8366917c40) at
   /cache/src/sys/kern/kern_fork.c:992
p = (struct proc *) 0xfe0181104000
td = (struct thread *) 0xfe0056eec490
   #15 0x8075145e in fork_tra

Re: FreeBSD-9.1 would not boot on pentium3 laptop

[Mikhail T.]

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?

[Mikhail T.]

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?

[Mikhail T.]

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"

Licensing zealotism (Re: Why can't gcc-4.2.1 build usable libreoffice?)

[Mikhail T.]

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?

[Mikhail T.]

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 
 
all talk about build failures (except the 176269 
, filed today). There 
are no relevant bug-reports against LibreOffice, that mention "gcc-4.2.1" 
 or "gcc 
4.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"

Re: Why can't gcc-4.2.1 build usable libreoffice?

[Mikhail T.]

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?

[Mikhail T.]

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 
 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 
 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?

[Mikhail T.]

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?

[Mikhail T.]

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?

[Mikhail T.]

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"

Why can't gcc-4.2.1 build usable libreoffice?

[Mikhail T.]

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::WeakImplHelper1::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

[Mikhail T.]

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

[Mikhail T.]

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"

Re: FreeBSD-9.1 would not boot on pentium3 laptop

[Mikhail T.]

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: FreeBSD-9.1 would not boot on pentium3 laptop

[Mikhail T.]

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

[Mikhail T.]

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

[Mikhail T.]

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"

FreeBSD-9.1 would not boot on pentium3 laptop

[Mikhail T.]

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: What is "negative group permissions"? (Re: narawntapu security run output)

[Mikhail T.]

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)

[Mikhail T.]

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"

Re: xz(1) keeps SEGFAULT-ing

[Mikhail T.]

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"

xz(1) keeps SEGFAULT-ing

[Mikhail T.]

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"

syslogd spinning the CPU, not logging...

[Mikhail T.]

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"

Re: Can't compile ath(4) into kernel

[Mikhail T.]

 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"

Can't compile ath(4) into kernel

[Mikhail T.]

 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: Strange buildworld error (uuid_*)

[Mikhail T.]

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_*)

[Mikhail T.]

 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

[Mikhail T.]

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

[Mikhail T.]

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)
  -- recent
   * pkg_add(1) pkg-routines ignore the recorded md5 checksums
  -- 8 years old
   * bikeshed entry of Handbook is wrong
  -- 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 
 (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
 
 (firewire enabled -- no hang. This is one extracted from
 /var/log/messages and is a little garbled.)
   * 8.1-PRERELEASE July 5
 
 (firewire disabled -- otherwise hangs)
   * 8.1-PRERELEASE July 14
 
 (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"

Re: today's 8.1/i386: panic: bad pte

[Mikhail T.]

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"

today's 8.1/i386: panic: bad pte

[Mikhail T.]

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:
   <6>pid 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: panic: handle_written_inodeblock: bad size

[Mikhail T.]

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"

panic: handle_written_inodeblock: bad size

[Mikhail T.]

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 ,
   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: openldap client GSSAPI authentication segfaults in fbsd8stablei386

[Mikhail T.]

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"

panic: __lockmgr_args: recursing on non recursive lockmgr ntnode @ (null):0

[Mikhail T.]

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"

sshd would not start (another 8.x grudge)

[Mikhail T.]

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"

Re: net-booting the install disks (Re: 8.x grudges)

[Mikhail T.]

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"

Re: 8.x grudges

[Mikhail T.]

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: 8.x grudges

[Mikhail T.]

08.07.2010 17:06, Peter Jeremy написав(ла):

On 2010-Jul-07 14:22:22 -0400, "Mikhail T."  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: net-booting the install disks (Re: 8.x grudges)

[Mikhail T.]

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 
 (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 
" 
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: net-booting the install disks (Re: 8.x grudges)

[Mikhail T.]

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: 8.x grudges

[Mikhail T.]

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"

Re: net-booting the install disks (Re: 8.x grudges)

[Mikhail T.]

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"

net-booting the install disks (Re: 8.x grudges)

[Mikhail T.]

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";
filename"pxeboot";
   }

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 
, 
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: 8.x grudges

[Mikhail T.]

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"

Re: 8.x grudges

[Mikhail T.]

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 throug

8.x grudges

[Mikhail T.]

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
 ), 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: 7.3: instant panic upon connecting a umass

[Mikhail T.]

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"

7.3: instant panic upon connecting a umass

[Mikhail T.]

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:  on ehci0
usb4: USB revision 2.0
uhub4:  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: binding on 127.0.0.1 not working after upgrade to 7.3

[Mikhail T.]

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=8008 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"

binding on 127.0.0.1 not working after upgrade to 7.3

[Mikhail T.]

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: An old gripe: Reading via mmap stinks

[Mikhail T.]

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"

Re: An old gripe: Reading via mmap stinks

[Mikhail T.]

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"

An old gripe: Reading via mmap stinks

[Mikhail T.]

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"

openoffice stuck in _umtx_op

[Mikhail T.]

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"

Re: Can close-ing a pipe trigger a SIGPIPE?

[Mikhail T.]

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"

Re: Can close-ing a pipe trigger a SIGPIPE?

[Mikhail T.]

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?

[Mikhail T.]

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?

[Mikhail T.]

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"

Can close-ing a pipe trigger a SIGPIPE?

[Mikhail T.]

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"

process stuck in "umtxn"

[Mikhail T.]

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"

Re: backup strategy (Re: dump | restore fails)

[Mikhail T.]

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"

backup strategy (Re: dump | restore fails)

[Mikhail T.]

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: dump | restore fails: unknown tape header type 1853384566

[Mikhail T.]

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

[Mikhail T.]

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"

support quality (Re: dump | restore fails: unknown tape header type 1853384566)

[Mikhail T.]

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

[Mikhail T.]

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"

Re: dump | restore fails: unknown tape header type 1853384566

[Mikhail T.]

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

[Mikhail T.]

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

[Mikhail T.]

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

[Mikhail T.]

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

[Mikhail T.]

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

[Mikhail T.]

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

[Mikhail T.]

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

[Mikhail T.]

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"

dump | restore fails: unknown tape header type 1853384566

[Mikhail T.]

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"

panic: ffs_truncate: readonly filesystem

[Mikhail T.]

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]"

"software" vs. "hardware" memory holes (fault on nofault entry panic)

[Mikhail T.]

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 )
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]"

another: supervisor read, page not present

[Mikhail T.]

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 , memsz=158641, 
filsz=158641, prot=5 '\005', pagesize=4096)
at ../../../kern/imgact_elf.c:386
#14 0x8027fc1c in 

panic in vm_page_splay

[Mikhail T.]

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:
<6>pid 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 = 659828

panic in g_up

[Mikhail T.]

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 , 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 /var/src/sys/kern/sche

plugging in a new SATA drive causes panic

[Mikhail T.]

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  at ata5-master SATA150
ad8: 476940MB  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 , 
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 = 0x805c3e80, devclass = 0xff95db80, unit = 5, 
  nameunit = 0xf

panic: vinvalbuf: dirty bufs

[Mikhail T.]

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

[Mikhail T.]

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]"