Re: resume slow on Thinkpad T42 FreeBSD 8-STABLE
On Sat, 25 Sep 2010, Vitaly Magerya wrote: Ian Smith wrote: On Wed, 22 Sep 2010, Ted Faber wrote: Sorry, Ian, I don't have anything new, wrt the ATA. Thanks Ted. Interesting that nobody else seems to have run into this issue, must be a (some?) Thinkpads thing .. FWIW, my Thinkpad T40 does the same thing on 8.1: after resume from S3 it's unusably slow (it takes seconds between a key is pressed and it's displayed on screen), and then after a while it works ok. That's interesting; since my original report last December I discovered that same behaviour with 8.0-R. During the 60s resume stall period, iff I'd suspended from a VTY, I found I could slowly (like maybe 3 seconds per character echoed) type a command, and some commands - possibly those cached? as there's no HD access - would run after another few seconds. In this way I discovered that 'date' commands reported the time some seconds after the resume (perhaps hours ago, or yesterday) until the stall ended, disk light flashed and normality resumed, sometimes with calcru: time went backwards .. messages, most often for devd. Since upgrading to 8.1-STABLE that clue? has gone; nothing typed is echoed. Are you referring to 8.1-RELEASE or to 8-STABLE as at some date? This has been like this in 7.0 too (except I don't know if it ever recovered the speed; I remember shutting it down as soon as I saw how slow it is). That's a difference then; 7.0-R then 7.2-STABLE (late December, anyway) had no such issues here on my T23. When it clears up after a wet week and I have some spare power again I'll try building a debug kernel, perhaps omitting and kldoading USB, and do some more tests before reporting further, probably in mobile@ and acpi@ again. I'll copy you and Ted when I do so. Thanks, Ian ___ 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: resume slow on Thinkpad T42 FreeBSD 8-STABLE
On Mon, 27 Sep 2010, Ian Smith wrote: In this way I discovered that 'date' commands reported the time some seconds after the resume (perhaps hours ago, or yesterday) until the Sorry, that should say 'seconds after the _suspend_', not the resume. stall ended, disk light flashed and normality resumed, sometimes with calcru: time went backwards .. messages, most often for devd. Since upgrading to 8.1-STABLE that clue? has gone; nothing typed is echoed. cheers, Ian ___ 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
snd_hda: how to duplicate output
Hi list, this is an exerpt from 8.1R detailed Release Notes: 2.2.2.1 Multimedia Support [snipped] The snd_hda(4) driver now supports multichannel (4.0 and 7.1) playback support. The 5.1 mode support is disabled now due to unidentified synchronization problem. Devices which supports the 7.1 mode can handle the 5.1 operation via software upmix done by sound(4). Note that stereo stream is no longer duplicated to all ports. I'm interesting in what way can I restore the old behaviour, when stereo stream is duplicated to the black and grey sound card output connectors? Thanks, Serguey. ___ 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: Problem running 8.1R on KVM with AMD hosts
on 27/09/2010 14:45 Luke Marsden said the following: Hi FreeBSD-stable, I'm having problems booting 8.1R on a KVM virtualised host backed on AMD hardware. It works flawlessly on Intel backed KVM. Please find attached ^ I tried but I can't. Maybe post a link? the message I get on boot. This loops endlessly. Can anyone give me any advice on how to start tracking this down? I'm happy to give developers access to some paid instances on ElasticHosts where this problem occurs, if it helps debugging it. (It works fine in ElasticHosts' lon-p and sat-p data centres, but not in lon-b, and Intel vs. AMD is apparently the difference). -- Andriy Gapon ___ 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: Problem running 8.1R on KVM with AMD hosts
on 27/09/2010 16:53 Luke Marsden said the following: On Mon, 2010-09-27 at 15:24 +0300, Andriy Gapon wrote: on 27/09/2010 14:45 Luke Marsden said the following: Hi FreeBSD-stable, I'm having problems booting 8.1R on a KVM virtualised host backed on AMD hardware. It works flawlessly on Intel backed KVM. Please find attached ^ I tried but I can't. Maybe post a link? Sorry, I guess the mailing list filters out attachments. Here you go: http://lukemarsden.net/8.1R-KVM-AMD-failure.png Do you have DDB+KDB options in your kernel? Are you able to capture any output before panic happens? Perhaps via serial console. P.S. how many CPUs are configured on the systems? Both total physical in hardware and visible to FreeBSD. -- Andriy Gapon ___ 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: Problem running 8.1R on KVM with AMD hosts
http://lukemarsden.net/8.1R-KVM-AMD-failure.png This picture is useless. No debug symbols == no useful information. 1. Please, build your kernel with debug symbols. Your kernel configuration file should contain string makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols 2. Show kgdb output, as described here: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html ___ 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: snd_hda: how to duplicate output
S.N.Grigoriev wrote: this is an exerpt from 8.1R detailed Release Notes: 2.2.2.1 Multimedia Support [snipped] The snd_hda(4) driver now supports multichannel (4.0 and 7.1) playback support. The 5.1 mode support is disabled now due to unidentified synchronization problem. Devices which supports the 7.1 mode can handle the 5.1 operation via software upmix done by sound(4). Note that stereo stream is no longer duplicated to all ports. I'm interesting in what way can I restore the old behaviour, when stereo stream is duplicated to the black and grey sound card output connectors? The only way is to change channel mapping (chmap array) for stereo streams in hdac_stream_setup() function. -- Alexander Motin ___ 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: Problem running 8.1R on KVM with AMD hosts
Hi all, Thanks for your responses. 1. Please, build your kernel with debug symbols. 2. Show kgdb output I will build a debug kernel as per your instructions and post the results as soon as I can. Likely in the next couple of days. I have secured us test hardware at ElasticHosts to debug this as necessary. As a reference point, 8.0R runs fine on this particular infrastructure: Linux KVM on AMD hardware. More detail to follow. Thank you. -- Best Regards, Luke Marsden Hybrid Logic Ltd. Web: http://www.hybrid-cluster.com/ Hybrid Web Cluster - cloud web hosting based on FreeBSD and ZFS Mobile: +447791750420 ___ 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: snd_hda: how to duplicate output
Alexander Motin wrote: S.N.Grigoriev wrote: this is an exerpt from 8.1R detailed Release Notes: 2.2.2.1 Multimedia Support [snipped] The snd_hda(4) driver now supports multichannel (4.0 and 7.1) playback support. The 5.1 mode support is disabled now due to unidentified synchronization problem. Devices which supports the 7.1 mode can handle the 5.1 operation via software upmix done by sound(4). Note that stereo stream is no longer duplicated to all ports. I'm interesting in what way can I restore the old behaviour, when stereo stream is duplicated to the black and grey sound card output connectors? The only way is to change channel mapping (chmap array) for stereo streams in hdac_stream_setup() function. Alexander, thank you for your responce. Regards, Serguey. ___ 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: resume slow on Thinkpad T42 FreeBSD 8-STABLE
Ian Smith wrote: [...] During the 60s resume stall period, iff I'd suspended from a VTY, I found I could slowly (like maybe 3 seconds per character echoed) type a command, and some commands - possibly those cached? as there's no HD access - would run after another few seconds. In this way I discovered that 'date' commands reported the time some seconds after the resume (perhaps hours ago, or yesterday) until the stall ended, disk light flashed and normality resumed, sometimes with calcru: time went backwards .. messages, most often for devd. Yes, same here. I must add that some peripherals do not work normally after the resume: - the mouse doesn't work until I restart moused manually - the network doesn't work: there's a message in dmesg about em0 going down before the sleep, and although ifconfig says that it's UP, only after a manual ifconfig em0 up it starts working again (except for host name resolution, which I can't repair for some reason) - if there's a flash drive inserted, it fails to reattach, sometimes saying something like this: usbus3: port reset timeout uhub_reattach_port: port 1 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 1 Sometimes there's no message about USB timeout, but mounting that drive still fails with this error: mount_msdosfs: /dev/da0: Input/output error And this appears in the dmesg output: (da0:umass-sim0:0:0:0): AutoSense failed If I remove and insert the drive again, everything works though. I also often (but not always) have this in dmesg: acpi_ec0: warning: EC done before starting even wait I don't know if the above information will be useful to anyone, but if someone wants to look into it, I can provide any further information on request. Are you referring to 8.1-RELEASE or to 8-STABLE as at some date? 8.1-RELEASE-p1. This has been like this in 7.0 too (except I don't know if it ever recovered the speed; I remember shutting it down as soon as I saw how slow it is). That's a difference then; 7.0-R then 7.2-STABLE (late December, anyway) had no such issues here on my T23. That may have been a separate issue, but I can't recall the exact symptoms now; I've been under impression that sleep will never work on my laptop so I didn't experiment much (the fact that it does sort of work now is news to me). When it clears up after a wet week and I have some spare power again I'll try building a debug kernel, perhaps omitting and kldoading USB, and do some more tests before reporting further, probably in mobile@ and acpi@ again. I'll copy you and Ted when I do so. Please do. ___ 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: resume slow on Thinkpad T42 FreeBSD 8-STABLE
On Monday 27 September 2010 02:55 pm, Vitaly Magerya wrote: Ian Smith wrote: [...] During the 60s resume stall period, iff I'd suspended from a VTY, I found I could slowly (like maybe 3 seconds per character echoed) type a command, and some commands - possibly those cached? as there's no HD access - would run after another few seconds. In this way I discovered that 'date' commands reported the time some seconds after the resume (perhaps hours ago, or yesterday) until the stall ended, disk light flashed and normality resumed, sometimes with calcru: time went backwards .. messages, most often for devd. Yes, same here. I must add that some peripherals do not work normally after the resume: - the mouse doesn't work until I restart moused manually --- 8 --- SNIP!!! --- 8 --- If the mouse is connected to PS/2 port, the following device flags may help. psm(4): bit 13 HOOKRESUME The built-in PS/2 pointing device of some laptop computers is somehow not operable immediately after the system `resumes' from the power saving mode, though it will eventually become available. There are reports that stimulating the device by performing I/O will help waking up the device quickly. This flag will enable a piece of code in the psm driver to hook the `resume' event and exercise some harmless I/O operations on the device. bit 14 INITAFTERSUSPEND This flag adds more drastic action for the above problem. It will cause the psm driver to reset and re-initialize the pointing device after the `resume' event. It has no effect unless the HOOKRESUME flag is set as well. I always use hint.psm.0.flags=0x6000 in /boot/loader.conf, i.e., turn on both HOOKRESUME and INITAFTERSUSPEND, to work around similar problem on different laptop. Can you please report other problems in the appropriate ML? em - freebsd-net@ usb - freebsd-usb@ acpi_ec - freebsd-acpi@ BTW, USB stack issue is known problem AFAIK. Jung-uk Kim ___ 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
CPU time accounting broken on 8-STABLE machine after a few hours of uptime
CPU time accounting is broken on one of my machines running 8-STABLE. I ran a test with a simple program that just loops and consumes CPU time: % time ./a.out 94.544u 0.000s 19:14.10 8.1%62+2054k 0+0io 0pf+0w The display in top shows the process with WCPU at 100%, but TIME increments very slowly. Several hours after booting, I got a bunch of calcru: runtime went backwards messages, but they stopped right away and never appeared again. Aug 23 13:40:07 scratch ntpd[1159]: ntpd 4.2.4p5-a (1) Aug 23 13:43:18 scratch ntpd[1160]: kernel time sync status change 2001 Aug 23 18:05:57 scratch dbus-daemon: [system] Reloaded configuration Aug 23 18:06:16 scratch dbus-daemon: [system] Reloaded configuration Aug 23 18:12:40 scratch ntpd[1160]: time reset +18.059948 s [snip] Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 6836685136 usec to 5425839798 usec for pid 1526 (csh) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 4747 usec to 2403 usec for pid 1519 (csh) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 5265 usec to 2594 usec for pid 1494 (hald-addon-mouse-sy) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 7818 usec to 3734 usec for pid 1488 (console-kit-daemon) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 977 usec to 459 usec for pid 1480 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 958 usec to 450 usec for pid 1479 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 957 usec to 449 usec for pid 1478 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 952 usec to 447 usec for pid 1477 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 959 usec to 450 usec for pid 1476 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 975 usec to 458 usec for pid 1475 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 1026 usec to 482 usec for pid 1474 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 1333 usec to 626 usec for pid 1473 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 2469 usec to 1160 usec for pid 1440 (inetd) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 719 usec to 690 usec for pid 1402 (sshd) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 120486 usec to 56770 usec for pid 1360 (cupsd) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 6204 usec to 2914 usec for pid 1289 (dbus-daemon) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 179 usec to 84 usec for pid 1265 (moused) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 22156 usec to 10407 usec for pid 1041 (nfsd) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 1292 usec to 607 usec for pid 1032 (mountd) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 8801 usec to 4134 usec for pid 664 (devd) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 19 usec to 9 usec for pid 9 (sctp_iterator) If I reboot and run the test again, the CPU time accounting seems to be working correctly. % time ./a.out 1144.226u 0.000s 19:06.62 99.7% 5+168k 0+0io 0pf+0w I'm not sure how long this problem has been present. I do remember seeing the calcru messages with an August 23rd kernel. I have not seen the calcru messages when running -CURRENT on the same hardware. I also have not seen this same problem on my other Athlon 64 box running the August 23rd kernel. Before reboot: # sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-fast kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 4294967295 kern.timecounter.tc.i8254.counter: 3534 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 8685335 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 1000 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 2204228369 kern.timecounter.tc.TSC.frequency: 2500018183 kern.timecounter.tc.TSC.quality: 800 kern.timecounter.invariant_tsc: 0 After reboot: % sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-fast kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 4294967295 kern.timecounter.tc.i8254.counter: 2241 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 4636239 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 1000 kern.timecounter.tc.TSC.mask:
Re: CPU time accounting broken on 8-STABLE machine after a few hours of uptime
On Mon, Sep 27, 2010 at 09:25:10PM -0700, Don Lewis wrote: CPU time accounting is broken on one of my machines running 8-STABLE. I ran a test with a simple program that just loops and consumes CPU time: % time ./a.out 94.544u 0.000s 19:14.10 8.1% 62+2054k 0+0io 0pf+0w The display in top shows the process with WCPU at 100%, but TIME increments very slowly. Several hours after booting, I got a bunch of calcru: runtime went backwards messages, but they stopped right away and never appeared again. Aug 23 13:40:07 scratch ntpd[1159]: ntpd 4.2.4p5-a (1) Aug 23 13:43:18 scratch ntpd[1160]: kernel time sync status change 2001 Aug 23 18:05:57 scratch dbus-daemon: [system] Reloaded configuration Aug 23 18:06:16 scratch dbus-daemon: [system] Reloaded configuration Aug 23 18:12:40 scratch ntpd[1160]: time reset +18.059948 s [snip] Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 6836685136 usec to 5425839798 usec for pid 1526 (csh) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 4747 usec to 2403 usec for pid 1519 (csh) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 5265 usec to 2594 usec for pid 1494 (hald-addon-mouse-sy) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 7818 usec to 3734 usec for pid 1488 (console-kit-daemon) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 977 usec to 459 usec for pid 1480 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 958 usec to 450 usec for pid 1479 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 957 usec to 449 usec for pid 1478 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 952 usec to 447 usec for pid 1477 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 959 usec to 450 usec for pid 1476 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 975 usec to 458 usec for pid 1475 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 1026 usec to 482 usec for pid 1474 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 1333 usec to 626 usec for pid 1473 (getty) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 2469 usec to 1160 usec for pid 1440 (inetd) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 719 usec to 690 usec for pid 1402 (sshd) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 120486 usec to 56770 usec for pid 1360 (cupsd) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 6204 usec to 2914 usec for pid 1289 (dbus-daemon) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 179 usec to 84 usec for pid 1265 (moused) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 22156 usec to 10407 usec for pid 1041 (nfsd) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 1292 usec to 607 usec for pid 1032 (mountd) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 8801 usec to 4134 usec for pid 664 (devd) Aug 23 23:49:06 scratch kernel: calcru: runtime went backwards from 19 usec to 9 usec for pid 9 (sctp_iterator) If I reboot and run the test again, the CPU time accounting seems to be working correctly. % time ./a.out 1144.226u 0.000s 19:06.62 99.7% 5+168k 0+0io 0pf+0w I'm not sure how long this problem has been present. I do remember seeing the calcru messages with an August 23rd kernel. I have not seen the calcru messages when running -CURRENT on the same hardware. I also have not seen this same problem on my other Athlon 64 box running the August 23rd kernel. Before reboot: # sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-fast kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 4294967295 kern.timecounter.tc.i8254.counter: 3534 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 8685335 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 1000 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 2204228369 kern.timecounter.tc.TSC.frequency: 2500018183 kern.timecounter.tc.TSC.quality: 800 kern.timecounter.invariant_tsc: 0 After reboot: % sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-fast kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 4294967295 kern.timecounter.tc.i8254.counter: 2241 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215
