Hide Forgot
Description of problem: Seeing this message on tty1 Version-Release number of selected component (if applicable): anaconda-10.1.1.87-1 tree: RHEL4-U7-re20080423.0 How reproducible: always Steps to Reproduce: 1. Start a PV Xen guest {on i386} with 5/8GB memory 2. After stage2 is started observe tty1 (see attached screen shot) 3. Actual results: mmap /dev/mem: Bad address message appears several times Expected results: no such message Additional info: Additionally we're seeing a message reported in bug #443844 which is a separate issue. The other message: ERROR: failed to initialize lmri library is seen most of the times but not consistently. It's not seen during text install (even if it was there it would have been overwritten probably).
Created attachment 303626 [details] screen shot of the message on tty1
Created attachment 303627 [details] messages on tty1 when X crashed after a few repetitive installs X crashed and the install was rebooted. 1) after formatting discs and package install started (GUI) I switched to tty1 2) stayed there for about 5-10 minutes 3) switched to GUI (tty7) and saw that it was waiting to be rebooted at the final scrren 4) didn't reboot and switched to tty1 again 5) X died and the install rebooted. saw only the mmap message but nothing for lmri.
seeing this on Xen/PV guest with 512 MB memory also
Does this happen in other environments that are not XEN?
(In reply to comment #6) > Does this happen in other environments that are not XEN? Tried with bare metal but didn't see the error message. Maybe it's Xen specific.
Requesting 4.7 exception flag so we can consider this for a later Snapshot (not a Beta blocker)
I think the error message comes from isys/smp.c: static void *mem_chunk(size_t base, size_t len, const char *devmem) { void *p; int fd; size_t mmoffset; void *mmp; if((fd=open(devmem, O_RDONLY))==-1) { --->>> perror(devmem); return NULL; } The same function in isys/acpi.c has the perror line commented out. Given that devmem has the value of "/dev/mem" I still can't explain the message itself. Fom the perror manual page: First (if s is not NULL and *s is not a null byte (’\0’)) the argument string s is printed, followed by a colon and a blank. Then the message and a new-line. so this should result in a message like: /dev/mem: Bad address and not mmap /dev/mem: Bad address I don't know where "mmap" is coming from. Correct me if I'm wrong.
At the top of smp.c /* [_Anarchy_(alan@lightning.swansea.uk.linux.org)] you should do one check though - if the board seems to be SMP and the CPU in /proc/cpuinfo is non intel dont install an SMP kernel - thats a dual pentium board with a cyrix or similar single cpu in it */ My dom0 machine is 4 (dual cores) AMD CPUs (I think) reported as 8 CPUs from /proc/cpuinfo. The domU is seeing a SMP board probably but the CPUs are reported as AuthenticAMD (/proc/cpuinfo from inside anaconda). I haven't seen this error on machine with Intel CPUs.
hitting this only with Xen and not bare metal (multi CPU AMD machine) with latest 4.7 compose. Still not sure what's the impact. Seems to work just fine.
Per Alex, moving to 4.8 - error is confusing but doesnt seem to actually break anything.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
priority low and it does not have an IT. If this issue causes the system to not be installable this bug will be considered for rhel4.8
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.