On Mon, Mar 07, 2022 at 05:29:09PM +0100, Thomas Bogendoerfer wrote: > On Fri, Mar 04, 2022 at 05:11:44PM +0000, Maciej W. Rozycki wrote: > > On Fri, 4 Mar 2022, Thomas Bogendoerfer wrote: > > > > > > > With this patch, when add "mem=3G" to the command-line, the > > > > > kernel boots successfully, we can see the following messages: > > > > > > > > unfortunately this patch would break platforms without memory detection, > > > > which simply use mem=32M for memory configuration. Not sure how many > > > > rely on this mechanism. If we can make sure nobody uses it, I'm fine > > > > with your patch. > > > > > > maybe we could add a CONFIG option, which will be selected by > > > platforms, which don't need/want this usermem thing. > > > > FWIW I don't understand what the issue is here beyond that we have a bug > > that causes a system to hang when "mem=3G" is passed on the kernel command > > line. That is assuming that system does have contiguous RAM available for > > the kernel to use from address 0 up to 3GiB; otherwise it's a user error > > to tell the kernel it has that memory available (I did get bitten by that > > myself too): garbage in, garbage out. > > I did a quick test with an IP30: > > >> bootp(): ip=dhcp root=/dev/nfs console=ttyS0 mem=384M > Setting $netaddr to 192.168.8.208 (from server ) > Obtaining from server > 9012640+181664 entry: 0xa800000020664a60 > Linux version 5.17.0-rc3+ (tbogendoerfer@adalid) (mips64-linux-gnu-gcc (GCC) 6.1.1 20160621 (Red Hat Cross 6.1.1-2), GNU ld version 2.27-3.fc24) #155 SMP Mon Mar 7 13:12:01 CET 2022 > ARCH: SGI-IP30 > PROMLIB: ARC firmware Version 64 Revision 0 > printk: bootconsole [early0] enabled > CPU0 revision is: 00000934 (R10000) > FPU revision is: 00000900 > Detected 512MB of physical memory. > User-defined physical RAM map overwrite > Kernel sections are not in the memory maps > IP30: Slot: 0, PrID: 00000934, PhyID: 0, VirtID: 0 > IP30: Slot: 1, PrID: 00000934, PhyID: 1, VirtID: 1 > IP30: Detected 2 CPU(s) present. > Primary instruction cache 32kB, VIPT, 2-way, linesize 64 bytes. > Primary data cache 32kB, 2-way, VIPT, no aliases, linesize 32 bytes > Unified secondary cache 1024kB 2-way, linesize 128 bytes. > Zone ranges: > DMA32 [mem 0x0000000000000000-0x00000000ffffffff] > Normal empty > Movable zone start for each node > Early memory node ranges > node 0: [mem 0x0000000000000000-0x0000000017ffffff] > node 0: [mem 0x0000000020004000-0x00000000208c7fff] > Initmem setup node 0 [mem 0x0000000000000000-0x00000000208c7fff] > > after that it's dead (it doesn't have memory starting at 0x0). > Most SGI systems will act broken with mem= in one way or another. > And I already had the need to limit the amount of memory. > > > I think having a CONFIG option automatically selected to disable the > > ability to give a memory map override would handicap people in debugging > > their systems or working around firmware bugs, so I would rather be > > against it. > > I'm thinking about a CONFIG option, which isn't user selectable, but > selected via Kconfig only. But that would give to differents semantics > for mem= > > So can I just limit amount of memory without interfering with normal > memory detection ? Maybe it's better to add a new encoding to mem= that will have the semantics of limiting amount of memory? E.g. mem=384M@ would mean "only use 384M of memory that firmware reported" while mem=384M would mean "set memory to 0 - 384M" as it does now. I think it's fine to have this MIPS specific because there is anyway no consistency among architectures in mem= handling. > Thomas. > > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > good idea. [ RFC1925, 2.3 ] -- Sincerely yours, Mike.
