Bug 140558 - nvram module does not support reading extra bank 128 bytes found in newer RTC implementations
Summary: nvram module does not support reading extra bank 128 bytes found in newer RTC...
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Peter Martuccelli
QA Contact: Brian Brock
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-23 16:40 UTC by James Olin Oden
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-23 18:58:17 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Adds support for extra 128 byte bank in RTC's NVRAM on some chipsets (5.71 KB, patch)
2004-11-23 16:42 UTC, James Olin Oden
no flags Details | Diff

Description James Olin Oden 2004-11-23 16:40:03 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Description of problem:
Many of the newer (within the last few years) chipsets RTC's support 
a second bank of 128 bytes of NVRAM.  AMI BIOS presently uses some of 
the registers in the second 128 bytes.  Thus in order to back up the 
NVRAM settings you need access to the second bank.  Presently, this 
is not supported in the nvram module.  Someone backing up their NVRAM 
settings using the current NVRAM module, may or may not, depending on 
the chipset of their system get a good backup.

Chipsets that have this feature include the Intel E7521, E7500 and 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
On a machine using the E7521 chipset, and thus using the 6300ESB ICH
cat the contents of /dev/nvram to a file (after of course creating 
the device and loading the module).  Once having done look at the 
size of the file.  It should be 242 bytes (256 - 14 [i.e. both 128 
byte banks, less the 14 bytes that comprise the RTC data region]), but
will be 114 bytes.

Actual Results:  It only reads 114 bytes.

Expected Results:  It should read 242 bytes.

Additional info:

I am attaching a patch that adds this functionality to the nvram 
module, and the asm-i386/mc146818rtc.h header.  It tries to detect
whether it a supporting ICH is being used, but that I think is the 
weakest part of the patch.

Comment 1 James Olin Oden 2004-11-23 16:42:16 UTC
Created attachment 107310 [details]
Adds support for extra 128 byte bank in RTC's NVRAM on some chipsets

Adds support in device to read extra 128 bytes on supporting devices. 
Detection scheme I think is weak, would like any feed back that would make it 

Comment 3 James Olin Oden 2005-02-16 20:19:07 UTC
Just wondering if you have had a chance to look at this?


Comment 4 Michael Andrew Webster 2005-05-04 21:42:01 UTC
Where did you find out about the E7521, E7500, and E7501 chipset sizes?  We are
using a E7505 based motherboard.  Trying to decide if we should apply this patch
to our nvram module.


Comment 5 James Olin Oden 2005-05-05 17:22:16 UTC
I read it in Intel's data sheets for the respective chipsets.  I think they all 
are all now available on Intel's web site (at the time the E7520 was not).
Basically, you lookup the info on the embedded RTC in the south bridge.  I 
suspect it is true of the E7505, but more experimenting on older mother boards 
that happened to have the extended nvram area also.  I suspect it does support 
it, but know way of know short of adding the patch and giving a whirl or 
reading the respective chipset's data sheet.


Comment 6 Peter Martuccelli 2007-01-23 18:58:17 UTC
Closing out as wontfix in RHEL3, minimal interest, no upstream acceptance.

Comment 7 James Olin Oden 2007-01-23 20:19:27 UTC
OK, its is a fact that many of the newer RTC's support 2 128 byte banks, yet 
the nvram driver only shows the first bank, so you are saying there is no 
interest in supporting what is pretty common hardware, or that my detection 
algorithm was wrong (which I know to be the case)?   

This patch, though needing improvement, helps in the area that linux is sorely 
lacking, which is being able to configure linux BIOS's.  Its only a step along 
the way of course, as what is needed is mapps of different BIOS's nvram 
utilization, but without being able to access the 2nd bank, your pretty much 

Anyway, I can cary the patch along just fine, I just don't understand the lack 
of upstream acceptance, nor the lack of interest.  It would be nice if you 
could enlighten me.

Note You need to log in before you can comment on or make changes to this bug.