Re: 9.2-RC3 - suspend/resume causes slow system performance
on 01/09/2013 02:40 Adrian Chadd said the following: On 31 August 2013 10:35, Mike Harding mvhard...@gmail.com mailto:mvhard...@gmail.com wrote: I've tracked this down to a single line, details in http://www.freebsd.org/cgi/query-pr.cgi?pr=181632. Basically, the code is now doing a 'sti, hlt' vs. a 'sti' in some code that is only supposed to run if idle is disabled. Given that 'hlt' is the idle instruction, this doesn't seem right. Wow, nice! Avg - can we get this fixed? Or just revert this! Thank you for trying to be helpful. But let's not jump to conclusions. BTW, I am following up on the problem in the PR. -- 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: Some PR never seen to delete
On 30.08.2013 22:30, Jakub Lach wrote: Why would you want to have valid ones closed? They are not all valids anymore. For instance burncd(1) is deprecated and does not work with ahci IIRC. I don't have xfce4 crash anymore. And the random ACPI panics have been fixed. For the other, they are almost 3 years old. Cheers ___ 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: Lost CAM Access to DVD Writer
Hi, sorry for breaking this message thread. I was not subscribed when i found it and so i have no Message Id to refer to. I am only a casual user of CAM for DVD burning (once per release cycle of libburn). But i can analyse some of the relation between growisofs and the error messages. when a blank is inserted: Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): CAM status: SCSI Status Error Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): SCSI status: Check Condition Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) ... Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): READ(10). CDB: 28 00 00 00 00 00 00 00 01 00 I doubt that his is caused by growisofs, which knows how to recognize a blank DVD. It is not overly smart to try reading from a blank medium. Whatever process or driver did this, it should have checked the reply of READ DISC INFORMATION for Disc Status first. The reaction of the drive is plausible in this case. Especially the caller was able to bring a READ command to the drive and to get an answer. So there is, at least partly, access to the drive. :-( Unable to CAMGETPASSTHRU for /dev/cd0 Inappropriate ioctl for device. The message with the frown comes from growisofs.c. union ccb ccb; ... ccb.ccb_h.func_code = XPT_GDEVLIST; if (ioctl (in_fd,CAMGETPASSTHRU,ccb) 0) There are also two occasions in transport.hxx. All three are associated with function code XPT_GDEVLIST. Both identifiers bring me to http://www.unix.com/man-page/FreeBSD/4/pass/ If the call in growisofs.c had succeeded, then growisofs.c would have used the result for sprintf (pass,/dev/%.15s%u,ccb.cgdl.periph_name,ccb.cgdl.unit_number); cam = cam_open_pass (pass,O_RDWR,NULL); ... ioctl_handle = (void *)cam; In transport.hxx, a private variable cam is set by a similar gesture and later used to send SCSI commands: if ((ret = cam_send_ccb(cam, ccb)) 0) So i assume the failed ioctl is essential for growisofs to get a connection to the drive. -- My own software libburn does not use ioctl CAMGETPASSTHRU in its FreeBSD adapter. It opens e.g. d-devname = /dev/cd0 by: cam = cam_open_device(d-devname, O_RDWR); ... d-cam = cam; and then sends SCSI commands via err = cam_send_ccb(d-cam, ccb); See also libburn/sg-freebsd.c of: http://www.freshports.org/devel/libburn (Ping: The stable release is 1.3.2 meanwhile, not 1.2.4.) /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u The equivalent with program cdrskin out of the libburn port would be ... -P 'cdrskin -v dev=/dev/cd0 -eject -' ... I am not sure whether growisofs does the auto-eject/auto-reload dance on FreeBSD. One should eject after burning to force the device drivers into forgetting their cached medium status. If you want to keep DVD-R or DVD+R writable for further sessions, then add option -multi (won't work with DVD+RW and alike). -- The actual program, cdrecord, works when invoked from the command line. growisofs does not depend on cdrecord, but rather on mkisofs. It does all its burning activities on its own. To my opinion, it handles the various media types more properly than cdrecord. -- About the /dev/fd/0 discussion: The growisofs command growisofs -Z /dev/cd0=/dev/fd/0 surely pipes the standard input of growisofs into a burn run on /dev/cd0. The pseudo-path /dev/fd/0 is not used with open(2) or alike, but interpreted in growisofs.c main(): if (sscanf(in_image,/dev/fd/%u,imgfd) == 1) imgfd = dup (imgfd); /* validate descriptor */ I.e. growisofs uses /dev/fd/ as keyword to obtain the number of an open file descriptor. In this case: 0 = standard input. -- Have a nice day :) Thomas ___ 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: Some PR never seen to delete
On Sun, Sep 1, 2013 at 3:53 AM, David Demelier demelier.da...@gmail.com wrote: On 30.08.2013 22:30, Jakub Lach wrote: Why would you want to have valid ones closed? They are not all valids anymore. For these, they should be closed. I closed 2010/09/16 kern/150628 [acd] [ata] burncd(1) can't write to optical drive 2011/01/25 ports/154288 glewis[patch] games/nethack*: remove old ports and cleanup latest 2012/12/23 ports/174650 xfcex11-wm/xfce4 crash with Which of the others are completely invalid now (as opposed to just old?) For the other, they are almost 3 years old. Merely being old doesn't mean they won't be fixed: I have committed fixes for 10 year old PRs. ;) -- Eitan Adler ___ 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
Lost CAM Access to DVD Writer - Maybe ATA Related
I am only a casual user of CAM for DVD burning (once per release cycle of libburn). But i can analyse some of the relation between growisofs and the error messages. when a blank is inserted: Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): CAM status: SCSI Status Error Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): SCSI status: Check Condition Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) ... Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): READ(10). CDB: 28 00 00 00 00 00 00 00 01 00 I doubt that his is caused by growisofs, which knows how to recognize a blank DVD. It is not overly smart to try reading from a blank medium. Whatever process or driver did this, it should have checked the reply of READ DISC INFORMATION for Disc Status first. The reaction of the drive is plausible in this case. Especially the caller was able to bring a READ command to the drive and to get an answer. So there is, at least partly, access to the drive. This error concerning a blank disk in the drive on the system console is long standing and I have been ignoring it for a while. It is a 'red herring' on this problem. Thank you for this information, it gives me a little more information. :-( Unable to CAMGETPASSTHRU for /dev/cd0 Inappropriate ioctl for device. The message with the frown comes from growisofs.c. union ccb ccb; ... ccb.ccb_h.func_code = XPT_GDEVLIST; if (ioctl (in_fd,CAMGETPASSTHRU,ccb) 0) There are also two occasions in transport.hxx. All three are associated with function code XPT_GDEVLIST. Both identifiers bring me to http://www.unix.com/man-page/FreeBSD/4/pass/ If the call in growisofs.c had succeeded, then growisofs.c would have used the result for sprintf (pass,/dev/%.15s%u,ccb.cgdl.periph_name,ccb.cgdl.unit_number); cam = cam_open_pass (pass,O_RDWR,NULL); ... ioctl_handle = (void *)cam; In transport.hxx, a private variable cam is set by a similar gesture and later used to send SCSI commands: if ((ret = cam_send_ccb(cam, ccb)) 0) So i assume the failed ioctl is essential for growisofs to get a connection to the drive. I think that this is the root cause of my problem. That is why I am starting another thread on this topic. I don't have this problem using the dump utility on my laptop running FreeBSD 9.2-RC3 like I have on the other computers. The only difference is that the laptop uses AHCI and all of my other computers use ATA. I had an old drive on the shelf that still had FreeBSD 9.1 STABLE from last Winter that I was going to install to see if my problem existed before FreeBSD 9.2 tag was released. That drive sat too long and won't spin up. Could someone else try to make a 'dump to DVD' backup using the example at the bottom of the DUMP (8) man page to confirm that it works or doesn't for them? /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u I will enter a PR if my results are duplicated. It doesn't work for me on 3 ATA based computers using new drives and media. It DOES work on one AHCI based computer. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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: Some PR never seen to delete
Am 01.09.2013 16:20, schrieb Eitan Adler: On Sun, Sep 1, 2013 at 3:53 AM, David Demelier demelier.da...@gmail.com wrote: On 30.08.2013 22:30, Jakub Lach wrote: Why would you want to have valid ones closed? They are not all valids anymore. For these, they should be closed. I closed 2010/09/16 kern/150628 [acd] [ata] burncd(1) can't write to optical drive 2011/01/25 ports/154288 glewis[patch] games/nethack*: remove old ports and cleanup latest 2012/12/23 ports/174650 xfcex11-wm/xfce4 crash with Which of the others are completely invalid now (as opposed to just old?) May I suggest two ports more, which were not mentioned on the list before: 2013/07/30 ports/180945: gdal-1.10.0 committed on 20130821. 2013/08/30 ports/181667: openoffice-devel fix committed on 2013/08/31 For the other, they are almost 3 years old. Merely being old doesn't mean they won't be fixed: I have committed fixes for 10 year old PRs. ;) ___ 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: Lost CAM Access to DVD Writer
Hi, :-( Unable to CAMGETPASSTHRU for /dev/cd0 Inappropriate ioctl for device. Could someone else try to make a 'dump to DVD' backup [...] /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u A test with less disk load would be to write e.g. 100 MB of zeros to e.g. DVD+RW media (in order to reduce waste): dd if=/dev/zero bs=1M count=100 | growisofs -Z /dev/cd0=/dev/fd/0 Have a nice day :) Thomas ___ 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: 9.2-RC3 - suspend/resume causes slow system performance
On 31 August 2013 23:41, Andriy Gapon a...@freebsd.org wrote: I've tracked this down to a single line, details in http://www.freebsd.org/cgi/query-pr.cgi?pr=181632. Basically, the code is now doing a 'sti, hlt' vs. a 'sti' in some code that is only supposed to run if idle is disabled. Given that 'hlt' is the idle instruction, this doesn't seem right. Wow, nice! Avg - can we get this fixed? Or just revert this! Thank you for trying to be helpful. But let's not jump to conclusions. BTW, I am following up on the problem in the PR. Sure, I'd like to know why it's behaving badly. But since we're so close to 9.2-REL, do you think you can get it sorted out and bug-free on all the existing platforms that people are using 9.2 on (including server, desktop and laptop) without reverting it? Reverting and fixing it later seems like the safest option to me. Is there a bigger problem that you tried to fix in that patch that wasn't as obvious? Thanks, -adrian ___ 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: 9.2-RC3 - suspend/resume causes slow system performance
on 01/09/2013 23:40 Adrian Chadd said the following: On 31 August 2013 23:41, Andriy Gapon a...@freebsd.org mailto:a...@freebsd.org wrote: I've tracked this down to a single line, details in http://www.freebsd.org/cgi/query-pr.cgi?pr=181632. Basically, the code is now doing a 'sti, hlt' vs. a 'sti' in some code that is only supposed to run if idle is disabled. Given that 'hlt' is the idle instruction, this doesn't seem right. Wow, nice! Avg - can we get this fixed? Or just revert this! Thank you for trying to be helpful. But let's not jump to conclusions. BTW, I am following up on the problem in the PR. Sure, I'd like to know why it's behaving badly. But since we're so close to 9.2-REL, do you think you can get it sorted out and bug-free on all the existing platforms that people are using 9.2 on (including server, desktop and laptop) without reverting it? Do you have any evidence that there is anybody else besides Mike who has this problem? Also, I usually try to sort out things after there is a clear understanding of what the problem is and how it should be fixed. Reverting and fixing it later seems like the safest option to me. Is there a bigger problem that you tried to fix in that patch that wasn't as obvious? I do not see any problem with the code*.* I do not see any explanation of the root cause of the problem that Mike has. I do not see why anything has to be reverted. Especially because since we're so close to 9.2-REL. Just in case, I'll remind that the commit in question is in stable/9 since Dec 23 2012. -- 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: 9.2-RC3 - suspend/resume causes slow system performance
On 1 September 2013 14:35, Andriy Gapon a...@freebsd.org wrote: Do you have any evidence that there is anybody else besides Mike who has this problem? Nope! but we can't assume that users are reporting all the system slowdowns. And honestly, I've heard enough strange stories on mailing lists and IRC of things like during disk IO, blah would be really slow, when I change timekeeping or halt from ACPI to something else, things get better. So I can't discount that this is affecting people and they either don't know, or just chalk it up as shitty hardware. Also, I usually try to sort out things after there is a clear understanding of what the problem is and how it should be fixed. Well, the big change is that it's now going into a sleep state on a HT core, right? Are you able to go into an ACPI sleep state on a HT logical CPU, rather than the physical core? Or am I mis-understanding what's going on? Reverting and fixing it later seems like the safest option to me. Is there a bigger problem that you tried to fix in that patch that wasn't as obvious? I do not see any problem with the code*.* I do not see any explanation of the root cause of the problem that Mike has. I do not see why anything has to be reverted. Especially because since we're so close to 9.2-REL. Just in case, I'll remind that the commit in question is in stable/9 since Dec 23 2012. Right, but I also know a lot of people who just have stayed with 8.x or 9.0-RELEASE and haven't bothered upgrading. Again, I can't assume that everyone has been keeping up to date with stable/9 and providing feedback. Thanks, -adrian ___ 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: 9.2-RC3 - suspend/resume causes slow system performance
on 02/09/2013 00:58 Adrian Chadd said the following: On 1 September 2013 14:35, Andriy Gapon a...@freebsd.org mailto:a...@freebsd.org wrote: Do you have any evidence that there is anybody else besides Mike who has this problem? Nope! but we can't assume that users are reporting all the system slowdowns. Why? And honestly, I've heard enough strange stories on mailing lists and IRC of things like during disk IO, blah would be really slow, when I change timekeeping or halt from ACPI to something else, things get better. So I can't discount that this is affecting people and they either don't know, or just chalk it up as shitty hardware. Strange stories are just that. Also, I usually try to sort out things after there is a clear understanding of what the problem is and how it should be fixed. Well, the big change is that it's now going into a sleep state on a HT core, right? Are you able to go into an ACPI sleep state on a HT logical CPU, rather than the physical core? Or am I mis-understanding what's going on? Most likely. I do not see how the change is HT-specific or HT-related at all. Reverting and fixing it later seems like the safest option to me. Is there a bigger problem that you tried to fix in that patch that wasn't as obvious? I do not see any problem with the code*.* I do not see any explanation of the root cause of the problem that Mike has. I do not see why anything has to be reverted. Especially because since we're so close to 9.2-REL. Just in case, I'll remind that the commit in question is in stable/9 since Dec 23 2012. Right, but I also know a lot of people who just have stayed with 8.x or 9.0-RELEASE and haven't bothered upgrading. Again, I can't assume that everyone has been keeping up to date with stable/9 and providing feedback. I am positive that it's not everyone who uses (up-to-date) stable/9. Still, I believe that a user-base of stable/9 is 1. -- 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: 9.2-RC3 - suspend/resume causes slow system performance
.. well, when is that pointer NULL? It looks like it's supposed to be NULL for one pair of the two HT CPUs? Are you taking the whole core into an ACPI idle state if one of two logical CPUs representing a core is going idle? -adrian ___ 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: 9.2-RC3 - suspend/resume causes slow system performance
This would be a 'strange story' if I had not tracked this down. The disk works, only much slower than normal. I only noticed it because I was doing a buildworld. There is no crash, no dmesg, no console logs. I'll ask again, why change that line? Did you feel that the original author of the code had made a mistake? The code in question is from Oct. 2005. Also why move the check for the HT in front of the check for the disabled idle? The only change that affects my system is that idle is enabled in a code path that should only be run when idle is disabled. I don't know the larger context but I also don't know why the code was changed. It looks like the intent of the code has been changed (don't suspend if this flag is set) and I don't know what benefit this provides. The code path seems to only be run during startup, shutdown and wake from sleep. Contact me via email and I'll set up remote access. This is a personal machine so this is a bit awkward. ___ 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: Lost CAM Access to DVD Writer
Hi, :-( Unable to CAMGETPASSTHRU for /dev/cd0 Inappropriate ioctl for device. Could someone else try to make a 'dump to DVD' backup [...] /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u A test with less disk load would be to write e.g. 100 MB of zeros to e.g. DVD+RW media (in order to reduce waste): dd if=/dev/zero bs=1M count=100 | growisofs -Z /dev/cd0=/dev/fd/0 I got the same result and error message as I did when trying to dump the file system on all of the computers that use ATA for disk access. On the one PC that uses AHCI, it was able to write to the DVD. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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: 9.2-RC3 - suspend/resume causes slow system performance
on 02/09/2013 01:21 Adrian Chadd said the following:
.. well, when is that pointer NULL?
It's never NULL. But that is besides the point as we are talking about a
different check.
* if (is_idle_disabled(sc)) {*
- ACPI_ENABLE_IRQS();
+ acpi_cpu_c1();
It looks like it's supposed to be NULL for
one pair of the two HT CPUs?
Are you taking the whole core into an ACPI idle state if one of two logical
CPUs
representing a core is going idle?
--
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: 9.2-RC3 - suspend/resume causes slow system performance
on 02/09/2013 02:13 Mike Harding said the following: I'll ask again, why change that line? I got your question the first few times you asked it. I do not see why you keep asking it when nobody has a clear explanation of what exactly is going on on your system and I've already told that I want to investigate / analyze that first. -- 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: 9.2-RC3 - suspend/resume causes slow system performance
Why not put this out to stable and take a survey with more than 2 members? I am sure that there are those who will be delighted, as I was with 9.1, to discover that suspend/resume worked without rebooting the machine. I can make the system available to you, contact me at this email. I am in the PDT time zone. ___ 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
