file system error (fwd)

Munjun Kang malas at pinetron.com
Wed Dec 4 20:05:01 CET 2002


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 at lanl.gov> writes:
> > > 
> > > > any ideas?
> > > > 
> > > > ron
> > > > 
> > > > ---------- Forwarded message ----------
> > > > Date: Fri, 29 Nov 2002 15:35:52 +0900
> > > > From: Munjun Kang <malas at pinetron.com>
> > > > To: Ronald G. Minnich <rminnich at 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.
> > 1. Build-in BIOS + 2.4.18-13 (redhat 8.0)        => work
> > 2. Linuxbios + 2.4.18-13 (redhat 8.0)               => don't work     
> > 3. 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 at clustermatic.org
> > > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > > 
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at 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
> -----------------------------------------------------------------------
> 
> 




More information about the coreboot mailing list