Greetings,
That's looking likely, but it seems that 48M are being eaten somewhere (quite possably SMA). Unless you actually want an SMA that big, it might be good to look at the registers for SMA using lspci after a LinuxBIOS boot. You'll probably have to add some code to initialize that/those registers. It could be that SMA is taking 48M due to an undocumented or reserved value in the register.
If this is the cause, the corruption could be infrequent with video not initialized.
The test to confirm will be examining the registers with LinuxBIOS vs. OEM BIOS and setting SMA register explicitly to a smaller value and see if the mem= parameter can be larger in that case.
G'day, sjames
On Mon, 9 Dec 2002, Munjun Kang wrote:
Thanks for your concerning.
Greetings,
Any poassability that the amount of memory passed to the kernel is too high and the crashes are due to using non-existant memory for a buffer or struct?
I've installed the 128MB(in one bank) Memory. But, my Northbridge uses SMA(shared memory architecture) for interal graphics core(savage 4). For SMA, NB reserves the 8~32MB physical memory. I did test in various SMA size, 0, 8, 32 etc. In my think, this causes the problem.
1st test is check reported memory on boot, 2nd is memtest86, 3rd is to pass mem=(some small value) to the kernel and see what happens.
1st. memory reporting through e820 memmap is good. 2nd. memtest86 has no error, but often shows 1 error/day. 3rd. command line mem=xxm option show the many symptom. below mem=80m, it works good. but, over mem=80m to 120m , it show kernel panic after found compressed or segmentation fault in harddisk access.
G'day, sjames
On Mon, 2 Dec 2002, Munjun Kang wrote:
Thanks for reading.
Malas. (Munjun Kang)
"Ronald G. Minnich" rminnich@lanl.gov writes:
any ideas?
ron
---------- Forwarded message ---------- Date: Fri, 29 Nov 2002 15:35:52 +0900 From: Munjun Kang malas@pinetron.com To: Ronald G. Minnich rminnich@lanl.gov Subject: Re: file system error
Thanks for your reply.
I tried as your suggest.
dd if=/dev/zero of=/dev/hda bs=1024 count=10000 ~ 100000 Segmentation fault's are occured in random by count.
and then, turn off the UDMA feature by hdparm option. But, I can see same symptom.
All DMA is turned off hdparm -d0 /dev/hda ??
Yes, I did it.
In this time, I tried to attach SCSI & IEEE1394 SBP-2 devices. case1. Adaptec 2930 SCSI adapter + 8GB Seagate SCSI HDD case2. IEEE1394 Interface card + external IEEE1394 HDD both cases show the same problem.
The northbridge having DMA problems is still a canidate. SCSI disks do DMA as well.
Now, I think it's not a DMA problem. I'm in the maze. hmmmm......
Is there any clear hint?
Past history with the Athlon problems on VIA chipsets says that some VIA northbridges have problems with burst traffic.
And either DMA or a fast memory copy could trigger it. memtest86 currently does not have an optimized memcpy so it could miss that problem.
Currently I consider your northbridge to be the best canidate. The same kernel is run under both BIOSes?
I tried in several cases.
- Build-in BIOS + 2.4.18-13 (redhat 8.0) => work
- Linuxbios + 2.4.18-13 (redhat 8.0) => don't work
- Linuxbios + 2.4.19 => don't work
Compared to your previous BIOS are there any unknown settings in the northbridge?
In particular what are the differences between, on both boards, and can you account for the differences. lspci -s 0:0.0 -xxx And can you account for all differences.
In work, 00:00.0 Host bridge: VIA Technologies, Inc. VT8605 [ProSavage PM133] 00: 06 11 05 06 06 00 10 a2 00 00 00 06 00 08 00 00 10: 08 00 00[e8]00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00[06 11 05 06] 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: fd db c8 be 05 00 08 08 c0 00 08 08 08 08 08 08 60: 03[aa]00[20]e6 d5 d5 00 43 38 86 0d 08 21 00 00 70: c4 88[cc]0c 0e 81 52 00 01 b4 09 00 00 00 00 00 80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2f 02 04 00 b0: 40 ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 06 00 32 42 00 b0 00 00 00 00
In problem, 00:00.0 Class 0600: 1106:0605 00: 06 11 05 06 06 00 10 a2 00 00 00 06 00 08 00 00 10: 08 00 00[f8]00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00[00 00 00 00] 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: fd db c8 be 05 00 08 08 c0 00 08 08 08 08 08 08 60: 03[00]00[00]e6 d5 d5 00 43 38 86 0d 08 21 00 00 70: c4 88[4c]0c 0e 81 52 00 01 b4 09 00 00 00 00 00 80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2f 02 04 00 b0: 40 ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 06 00 32 42 00 b0 00 00 00 00
0x13 : Graphics Aperature Base 0x2c : I don't know. maybe same with vendor & device ID 0x61, 0x62 : shadow ram setting 0x72 : CPU to PCI Flow control. difference bit 7 is described as follow. 7bit Retry Status 0 No retry occurred -------- default 1 Retry occurred ----------- write 1 to clear
In my opinion, there are not special differences.
Eric
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
-- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743