Opened 13 years ago
Closed 12 years ago
#536 closed enhancement (Unrelated)
Slow boot/load of BASEDEVs
| Reported by: | yoda | Owned by: | David Azarewicz |
|---|---|---|---|
| Priority: | minor | Milestone: | Release 4.00 |
| Component: | ACPI PSD | Version: | 3.20.01 |
| Keywords: | Cc: | ggamba@… |
Description
ASUS A8N SLI Premium AMD 3800X2 NForce 4 chipset Award 6.0PG BIOS 3GB RAM.
System can now boot for first time in full SMP mode. However, it takes 30-50 secs to load all BASEDEVs, measured from BM to ACPI banner. Rest of config.sys loads normally. In /PIC or /VW mode (or without PSD) same takes 7-8 secs.
Attachments (2)
Change History (13)
by , 13 years ago
| Attachment: | OBELIX-20120330-acpi-3.20.01.zip added |
|---|
comment:1 by , 13 years ago
comment:2 by , 13 years ago
| Priority: | major → minor |
|---|---|
| Status: | new → assigned |
| Type: | defect → enhancement |
This is not a defect in the PSD. Please read the updated Known Problems: http://svn.netlabs.org/acpi/wiki/KnownProblems
I happen to have the same motherboard that you do. It also has the AwardBIOS v6.00PG. The only difference is that I have a 2.2Ghz AMD Athlon 64 X2 4200+ dual core CPU and 1G of RAM in mine. The time from BM to PSD banner on my system is 12 seconds.
I am using this ticket as a place for collecting logs in case there may be something I can do for some subset of the systems that have this characteristic.
follow-up: 4 comment:3 by , 13 years ago
Try use altf2on.$$$ That seems to increase it even more - and more for debug versions of PSD.
This MoBo have worked with all previous ACPI builds (2.0-3.18) fast, and with no problems - so the old code did it well.
BTW, when I try in /VW mode, it traps in krnl when PM initializes. Due to 3GB RAM, I haven't 'caught' it yet. If it works for you, I'll try a way to 'grab' it.
Anyway, as I mentioned, my ATOM board do have same slowness - but HW is completely different
comment:4 by , 13 years ago
Replying to yoda:
BTW, when I try in /VW mode, it traps in krnl when PM initializes.
From your update of Wiki, I guess you reproduced the trap. I remember now from your description, that we had this problem with much earlier ACPI drivers. Pasha created some code in ACPI to catch these wild interupts (0x53?), and added a switch to enable the fix. L8r, it was put in as a general fix, and the switch was removed again. You should be able to find the workaround in the sources.
comment:5 by , 13 years ago
Just to clarify; the slowness seems to affect all chipssets/BIOS.
On my Asrock A330gc board with Intel chipset and AMI BIOS:
BM -> ACPI Banner (all basedevs) with 3.19.15: 2 secs (without altf2.$$$ I think it is less than 1 - I can't really hand time it ;-) )
BM -> ACPI Banner (all basedevs) with 3.20.01: 15 secs
That is an 700% increase !
The rest of config.sys - Acpi Banner -> Desktop loads in same time on both drivers.
by , 13 years ago
| Attachment: | ATOM-20120405-acpi-3.20.01.zip added |
|---|
comment:6 by , 13 years ago
| Cc: | added |
|---|
comment:7 by , 12 years ago
This ticket references a problem with the JFS boot loader, not a defect in the PSD. As such, there is nothing that can be done in the PSD regarding this issue. This issue must be fixed in the JFS boot loader. Work has already been done to address this issue in the JFS project, but this is not the place to discuss JFS issues.
This ticket will be closed with an "unrelated" resolution.
follow-up: 9 comment:8 by , 12 years ago
That is not entirely true. I re-timed my ATOM board - 19 seconds to boot BASEDEVS using ACPI 3.20.1 Now with ACPI 3.21.01 it was only 9 seconds; so you have clearly got things back on the right track here. After that test, I added the new JFS boot loader. With the mentioned new JFS boot loader - we are now down to 4 seconds to load the BASEDEVS; so you are right that JFS was a problem too.
I have not yet had a chance to try it on the Nvidea system - but since you have the same system, I assume it will show equal better results with these new drivers.
follow-up: 10 comment:9 by , 12 years ago
Replying to yoda:
That is not entirely true.
Yes it is absolutely true. I am the one writing the code, I completely understand the problem, and I am absolutely certain.
The PSD is operating the way it is required to. ABSOLUTELY NOTHING was changed in the PSD that might have affected this ticket and nothing will be changed in the PSD regarding this ticket.
As I said before, this is a JFS issue, not a defect in the PSD. This is is not the place to discuss JFS issues.
This ticket will be closed with an "unrelated" resolution.
comment:10 by , 12 years ago
Replying to dazarewicz:
The PSD is operating the way it is required to. ABSOLUTELY NOTHING was changed in the PSD that might have affected this ticket ...
Didn't you read what I wrote ?
3.20.1 = 19 secs
3.21.1 = 9 secs
(no JFS fixes applied for these times)
So something was clearly changed in the PSD, that made it boot faster again.
This ticket will be closed with an "unrelated" resolution.
Weird idea, since something was fixed; but who cares...
comment:11 by , 12 years ago
| Resolution: | → Unrelated |
|---|---|
| Status: | assigned → closed |
Tested same driver on Asrock A330GC Atom cpu
Driver 3.19.15 used to boot from BM to Desktop in 24 secs on this board. Driver 3.20.1 uses 37 secs for same operation.