Bugzilla – Bug 481299
Yast Auto Scanner Detection and Model and Driver User Defined Takes an Inordinate Amount of Time
Last modified: 2009-04-16 08:15:55 UTC
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.6) Gecko/2009012700 SUSE/3.0.6-0.1 Firefox/3.0.6 I attached a Cannon USB scanner and went to Yast>Hardware>Scanner to configure it. This Yast Model consumes vast system resources and 10% mac CPU and as Much Physical RAM as it want to constrict the driver database. Auto detection took over 2 Minutes. Once the scanner Model is auto found I edited the selection to ensure the most appropriate selection - again System Resources were swallowed up like nothing on earth. This process took over 2 Minutes Once the List of Drivers were displayed I entered a search string which again started to devour more resources again taking over two minutes. Once Again selecting the "Show Complete List" took over 3 mins and consumed more resources. My PC is a Processor (CPU): AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ Speed: 2,410.96 MHz Cores: 2 with Total memory (RAM): 1.7 GB Free memory: 696.9 MB (+ 412.2 MB Caches) Free swap: 10.0 GB The Free memory amount started at 980MB and this small yast program has reduced it to a current 696.9MB and is dropping all the time Reproducible: Always Steps to Reproduce: 1.Auto detect any USB Scanner and monitor sysinfo in Konqueror as above 2. 3. Actual Results: Totally unacceptable and unrestrained use of system resources and inordinate wait times - we must and can do much better with this module! Expected Results: I am sure we dont need 1 Yast module to be 1 able to access seemingly unrestricted resources and I am sure we can either index the data base better to cut down searches and possibly consider using a bubble sort rather than straight index sort. The PC has been processing "Show complete List for over 5 minutes now and available RAM has dropped to 580MB and going down
The PC I was working on for the above test - shut down as CPU and RAM reached over 60C. The CPU temp initiated total shutdown of PC, which it has never done before, as it was the result of just adding and configuring a USB scanner. Adjusting Priority! I am always happy to provide any logs in the event you are unable to duplicate the above.
It works well on my 3 GHZ dual core workstation with 500 MB RAM. Only creating the database can take some seconds (e.g. 20 seconds) but all the rest works with reasonable speed for me. Therefore it is no issue in the YCP code of the scanner module but perhaps something in the YaST base system (or even at a lower level).
Have a look at bug #442173 which describes a related issue. But the issue in this bug here is different because here for the user almost every step takes minutes. Scott Couston, to verify if it is perhaps a YaST GUI issue, run it in text-only mode. As root call yast scanner and test if it works reasonable fast in text-only mode.
No problem I will reply from today +7 My apologies for my 2 weeks absence, I got flooded out in my region and am only getting things slowly back together.
I re-ran test. I logged out of GUI session and chose to login via console. I logged in as root no problems - I received the "have lots of fun" welcome. I entered Yast2 - deleted the current entry>Exit Yast2>Hardware>Scanner>Default Auto detect took less than 2 seconds! A 'Search' string only took 3 seconds max The 'Show All' took less than 3 seconds Text based Yast2 - unreal response Re-enter KWIN I just clicked on -Show All" and I have made a cup of coffee and had 2 smokes and come back to complete this bug and its sill in the process of 'Show All" Appear from the grab for all resources and the enormity of the task that just happens to be running there appears there in NO error level in exceeded time. Thats the biggest problem with Yast - If ANY action - no matter the cause - the user cannot terminate the process and there is no error level time exceeded and the O/S kill continue to devote resources until the process can be fulfilled. Many Yast Processes can take a very very long time if they cannot (for any reason) complete the task, however this one is like no other given times in initial comment. Here the Abort key does nothing as its only usage is to exit out of any Yast process without saving the changes. As a conventional user the only option now is to shut down/restart the PC which will now take a good 3 minutes to do. Can I help be providing ANY log information ??????
Since things work fine in text mode this seems to be a problem with the graphical UI. Scott, could you please provide the YaST logs so we can investigate closer?
Sure can provide YAST2 Logs, however please give me a few days to trash my test PC - its currently running gnome and the error is not present under Yast in Gnome. I will trash test PC and install KDE in both 11.0 and 11.1 for you. Leave on Needinfo for date plus 7
FYI: Regarding the bad side-effect which is mentioned in comment #5 that "Abort key does nothing" compare https://bugzilla.novell.com/show_bug.cgi?id=442173#c4
Just to gather some more data points: Scott, Johannes, is there a difference when using gnome, kde3 or kde4? Maybe we are seeing an issue in qt here...
Yes Gnome on Version 11.0 Yast runs light lightening, just a bit faster than text Yast. I can provide logs and details of V11.0 KDE and 11.1 KDE in due course - cannot answer that 11.1 KDE is also very slow atm - Test was done on 11.0 KDE.
BTW This is another reason why case in point of Bug 442475 needs action rather than just the perpetual INVALID close. If ' Skip Refresh can work well why does the Cancel button become useless? I believe this issue is purely related to KDE 4.x X Windows Manager as this problem was not evident in KDE 3.5,Not Evident in text, Not evident in V11.0 Gnome, and not evident in 11.1 in Gmome. I have noted the massive amount of Extra Resources that KDE4.n requires to support ALL X Windows Function which I am sure you have noticed before in monitoring both 11.0 and 11.1 KDE - which demands huge resources no matter what application is opened and running - not only Yast
The issue has major implication on Bug 442475 to fix the inability to halt ANY YAST Application using the ABORT function as it was useless when ANY Yast application misbehaves - It was closed as wontfix as I was told in no uncertain terms that it was not possible for the ABORT button to stop any YAST application that misbehaves - Bug 442475 has implications to case in point on all other bug reports on misbehaving YAST bugs as well as this one. Yast logs in a few hours of date
Created attachment 282090 [details] startup log
Created attachment 282091 [details] system log
Created attachment 282092 [details] Yast2 logs
2009-03-26 09:34:19 <1> linux-ncbv(6392) [YCP] Scanner.ycp:327 Executing bash commandline: /usr/lib/YaST2/bin/create_scanner_database YCP >/var/lib/YaST2/scanner_database.ycp 2009-03-26 09:34:40 <1> linux-ncbv(6392) [YCP] Scanner.ycp:327 Executing bash commandline: /usr/lib/YaST2/bin/determine_active_scanners YCP >/var/lib/YaST2/active_scanners.ycp This takes 21 seconds; whole run of yast2-scanner takes c.a. 30 seconds, at most 50 seconds (there is a 20-second gap in the log before another module is started); this is tne only run of the scanner module which I found in the logs Would it be possible to get logs (ideally with Y2DEBUG=1 environment variable) showing that any operation really takes at least minutes?
create_scanner_database takes 21 seconds for the reporter exactly as I wrote in comment #2 - just have a look.
How can I help with logs on the reported X64 PC? Have you also tried inserting new scanner USB device (or any other USB device for that matter) in a different Bus slot in PC and the booting it?
Scott, can you please attach logs from a run with all those minute-long delays?
I can do that - give me +5 days to trash my Test PC and install and provide logs. If I get time I will do the same for 11.1 -I will leave bug at 11.0, but provide logs for 11.1 FYI - that is unless you want this difference in version in 2 separate bugs - If so I can clone. Leave on NEEDINFO
Before I get to logs - I assume the normal Yast logs? Also some question on how Linux responds to some Hardware variables and this may answer why when I insert a new USB device into a New BUS ID the boot process is halted - no time out after 30 mins and no further than boot detecting new USB device. Q. With X_64 AMD we have the option to run in cool and quiet mode or not. Most of us choose disable as the CPU starts at very low frequency and is pathetically slow to up to nominal CPU clock frequency - so most of us leave it disabled to enjoy the performance benefits. 1. Benefits of Disable are CPU clock remains constant, however All ACPI, _PCC, _PSS, _PCT calls are rejected from the O/S and Bios Manages the cooling Policy. 2. Benefits of Enable is that the above O/S calls are not ignored, BUT the CPU clock start at minimum and is so very very very late in placing the CPU clock to its normal frequency and the O/S has to demand CPU performance for quite a long while. Other BIOS Questions related are Plug and Play device can only be set to O/S or BIOS - which do you wish -does it matter. Is legacy support for USB required or will support for V1.1 and V2.0 all o.k? Do I need to enable ACPI SRAT Table Y/N Can you get back to me on the above and I will assume logs are normal Yast Logs. By supplying this info you may well have solved USB device issues!?
Sorry Scott, I can't answer any of those questions. That would be more something for our kernel folks. Maybe open a separate bug for that as this does not seems to relate to the original report (which was no delay in gtk/ncurses but very slow with qt, if I read the bug correctly). Normal yast logs will be ok. Just something that shows where exactly the delay is.
Sure I will supply - But I can make this New USB device hang forever if I Deny/Modify USB BIOS Settings as their is NO Default for the above for Linux only M.S - Logs in date +2
Johannes, your #2 hits right home in your reference to a possible lower level issue. Note the only major variable here between your test and mine is X_64 AND/OR the actual Scanner Device. So traditional debug makes sense in 'what is fundamentally different about your test and mine for me to get such a different delay and USB issue. So I now started with the 'differences' or the usual 'What has changed' type question to myself and come up with 2 variables. 1. The scanner is USB dependant on its power source and the other is my X_64 Arch. Can you help in directing questions of mine in #23 to some one in Kernel Support for the answer as I can change the ACPI/USB/CPU BUS/ in above and come up with two entirely different build and recognition times. BIOS defaults only help with M.S O/S so I cannot rely on those. I think we need answers to #23 because I can either halt startup - Period! or start-up runs as normal and scanner database builds in a reasonable time frame. So for us to move forward I need a level playing field and advise on what we, as Linux O/S expect the defaults in X_64 to be particularly in our USB Legacy?Support and/or version support + ACPI questions. This bug may very well be a software non-issue, and I am inclined to agree with this thought, however we all need to learn about AMD X_64 Arch and CPU to move forward in a predictable manner in many issues, including this one. So Why am I bugging you - I dont know who to place Needinfo for answers to #23 in Kernel Support - Can you help redirect appropriately...TA To all in above - As always I may appear to be standing on my head, living in the Southern Hemisphere but sometimes I would like to think I am still rational ;-)
I am afraid I am neither a kernel expert nor a USB expert so that I cannot provide substantional help regarding low-level kernel or USB issues. But I don't think the root cause of this bug is at such a low level like kernel or USB because then it would happen regardless of the UI in YaST. Because it runs with reasonable spped in text mode and in GTK according to your comment #5 and comment #10 (i.e. it happens only with QT - perhaps only with QT4 in openSUSE 11.0) the root cause is somewhere in the QT related layers (either the QT UI in YaST or the lower level QT libraries) which again indicates that it is in the end a duplicate of bug #442173 or at least a similar issue. If the root cause of this bug is also the QT UI in YaST (or the lower level QT libraries) there are usually no messages in y2log what the GUI is doing, see https://bugzilla.novell.com/show_bug.cgi?id=442173#c0 ----------------------------------------------------------- By default (i.e.when YaST doesn't run in debugging mode) there is nothing in y2log which indicates where it hangs. ----------------------------------------------------------- and https://bugzilla.novell.com/show_bug.cgi?id=442173#c8 ----------------------------------------------------------- You can run YaST in debugging mode. Then y2log fills up with zillions of messages what the GUI is doing ----------------------------------------------------------- Regarding comment #23: What I know from user reports regarding low-level kernel or USB issues with scanners is: a) http://en.opensuse.org/SDB:Configuring_Scanners_from_SUSE_LINUX_9.2 "USB Cable Connection and Additional USB Hubs" and "USB Hardware + USB Kernel Modules + hotplug" b) It may help to use explicitely the slower USB 1 (and not USB 2 which might be too fast for your hardware) via unloading/loading appropriate kernel module(s), see https://bugzilla.novell.com/show_bug.cgi?id=470959#c1
HI Johannes - please see text in #23. I just wanted you to re-set NEEDINFO to someone who IS in Kernel Support - I am sure you known the names of people in Kernel development as I do not. Quote********* Johannes Can you help in directing questions of mine in #23 to some one in Kernel Support for the answer as I can change the ACPI/USB/CPU BUS/ in above and come up with two entirely different build and recognition times. Unquote***************
To me it looks we are hunting two separate problems here. Scott, I think the best would be if you open a separate bug for the USB issue (maybe copy commet 23 over to it) and assign to kernel-maintainers@forge.provo.novell.com.
Steffen - I do not have the authority to directly assign a bug unless the assignee requests it. Yes there is a taint of Hardware issues here but the scanner device, its USB connection and the PC Architecture are inseparable. That is why my test results in speed and time of this module are so vastly different that those in #2. Also this bug is not found in gnome. Once we can all start off the with same X_64 standard BIOS options in EVERY AM2 socket motherboard, ALL with the same AMD features we can move forward. If Kernel development tells us that Yast/Kernel/KDE4 provides 2 different environments totally depend and on 2 X AMD X_64 standard BIOS Option we can move to correct this....The how here in yet to be known. However IF Kernel Development can tell us that this 2 X AMD X_64 standard BIOS Option matters nothing to do with the way we manage the USB Bus - Then I am mad and the reason for this massive difference will require me to work out "What is different about your #2 results environment and my own massive differences" it may well be that I close this bug until I can work out what the difference is - and this may prove to be allusive for some time to come. Just to re-cap- I just want to start off with the same level playing field now with my X_64 Arch and AMD stand BIOS options x 2 that is present in you X32 P3 in #2 and only Kernel Development will have the answer to start this process.
Scott, then please at least open a new bug. The usb issue cannot be resolved here.
I have raised bug long past that solely details our lack of ability to find any new/change in BUS ID Connections in version 10.3. All I can do is trust in it being fixed at some point in time. Back to this issue. Using the very very smallest scope of this Bug I will provide 2 x logs for this solitary issue. 1'st = Yast logs where a device is known to exist on the same USB BUS after boot. 2'nd = Yast logs where I want to edit the driver assigned to the same device. In that way you can solve the issue in the Yast scanner config that takes us inordinate time to edit the driver of a known device as this bug title is confined to. I will need a +2 days to trash my test PC - Happy to confine this issue to pure software as you have now request this to be so. Leave on Needinfo to action by date + 2
Created attachment 285176 [details] As Requested O.K - Level Playing Field with New Kernel - Change Status Allow Kernel to control ACPI Functions at BIOS Attached Yast2 logs as requested. Issue was the unreal amount of time this service takes to both Auto-Detect Scanner Device for the first time, and then the amount of time to Display All Models in edit mode and the amount of time taken to just 'Edit' the Auto detection
Thanks, Scott! Johannes, could you please have a look at these logs?
In attachment #285176 [details] there are y2log-9 y2log-8 y2log-7 y2log-6 y2log-5 y2log-4 y2log-3 y2log-2 y2log-1 and y2log but only in y2log there is ------------------------------------------------------------------------ 2009-04-10 08:32:25 ... Scanner module started 2009-04-10 08:48:08 ... Finishing scanner module ------------------------------------------------------------------------ so that I looked only at y2log. Looking at the timestapms, I found the following longer delays: ------------------------------------------------------------------------ 2009-04-10 08:32:26 ... /usr/lib/YaST2/bin/create_scanner_database 2009-04-10 08:32:48 ... ------------------------------------------------------------------------ Creating the scanner database takes 22 seconds which is o.k. see comment #2 and comment #19 FYI: ------------------------------------------------------------------------ 2009-04-10 08:32:48 ... /usr/lib/YaST2/bin/autodetect_scanners 2009-04-10 08:32:49 ... Autodetected scanners: ... ------------------------------------------------------------------------ Scanner autodetection in about one second is perfect. It might also take several seconds but here it is perfectly fast. In the worst case /usr/lib/YaST2/bin/autodetect_scanners needs two times 10 seconds until it aborts because of timeouts. ------------------------------------------------------------------------ 2009-04-10 08:32:55 ... OverviewDialog returns: `edit 2009-04-10 08:32:56 ... YCPDialogParser.cc(parseInputField):1603 2009-04-10 08:40:26 ... No preselected model shown to the user. The filter_string is: '' ------------------------------------------------------------------------ This is the well known delay as described in bug #442173 see comment #3 Therefore from my point of view this one is just one more duplicate of bug #442173 compare also https://bugzilla.novell.com/show_bug.cgi?id=442173#c16 I wonder why you YaST people re-assign your same old issuse again and again to me for more and more analysis? I already described how to reproduce it in bug #442173 but I cannot fix your YaST-internal issues for you.
It's a duplicate of bug 442173. *** This bug has been marked as a duplicate of bug 442173 ***