Opened 12 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)

OBELIX-20120330-acpi-3.20.01.zip (58.1 KB) - added by yoda 12 years ago.
ATOM-20120405-acpi-3.20.01.zip (72.1 KB) - added by yoda 12 years ago.

Download all attachments as: .zip

Change History (13)

Changed 12 years ago by yoda

comment:1 Changed 12 years ago by yoda

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.

comment:2 Changed 12 years ago by David Azarewicz

Priority: majorminor
Status: newassigned
Type: defectenhancement

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.

comment:3 Changed 12 years ago by yoda

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 in reply to:  3 Changed 12 years ago by yoda

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 Changed 12 years ago by yoda

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.

Changed 12 years ago by yoda

comment:6 Changed 12 years ago by Gabriele Gamba

Cc: ggamba@… added

comment:7 Changed 12 years ago by David Azarewicz

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.

comment:8 Changed 12 years ago by yoda

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.

comment:9 in reply to:  8 ; Changed 12 years ago by David Azarewicz

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 in reply to:  9 Changed 12 years ago by yoda

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 Changed 12 years ago by David Azarewicz

Resolution: Unrelated
Status: assignedclosed
Note: See TracTickets for help on using tickets.