I've tried beta3/4/5/6 and they all hang right after printing: Entering /boot/kernel/kernel at 0xe000000004058000... How-To-Repeat: Just boot the iso.
Hi, Is there any progress here? Do you need more info? -- Jens Axboe
Responsible Changed From-To: freebsd-bugs->freebsd-ia64 This may be processor-specific.
On 10/7/2004 11:02 PM, Mark Linimon wrote: > This may be processor-specific. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=72128 I just tested that the 5.3-beta7 works fine on a 4 way Tiger with 1GB RAM. I don't think there have been critical bug fixes between beta6 and beta7 that affect the tiger. Also, on a 4GB machine, FreeBSD ignores RAM above 1GB. Jens, were you using a serial console ? FreeBSD doesn't support a VGA console yet on ia64. -Arun
On 10/8/2004 2:24 PM, Arun Sharma wrote: > On 10/7/2004 11:02 PM, Mark Linimon wrote: > >> This may be processor-specific. >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=72128 > > > I just tested that the 5.3-beta7 works fine on a 4 way Tiger with 1GB > RAM. I don't think there have been critical bug fixes between beta6 and > beta7 that affect the tiger. Also, on a 4GB machine, FreeBSD ignores RAM > above 1GB. I meant to say FreeBSD ignores RAM above 4GB physical. So depending on your memory map, this may or may not be a problem. -Arun
On Fri, Oct 08 2004, Arun Sharma wrote: > On 10/7/2004 11:02 PM, Mark Linimon wrote: > > >This may be processor-specific. > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=72128 > > I just tested that the 5.3-beta7 works fine on a 4 way Tiger with 1GB RAM. > I don't think there have been critical bug fixes between beta6 and beta7 > that affect the tiger. Also, on a 4GB machine, FreeBSD ignores RAM above > 1GB. > > Jens, were you using a serial console ? FreeBSD doesn't support a VGA > console yet on ia64. I am. I did attach a monitor as well for testing since I didn't know if freebsd utilized the serial console automatically. I since looked at the boot loader config and saw that it did and the config was correct. -- Jens Axboe
On Fri, Oct 08 2004, Arun Sharma wrote: > On 10/8/2004 2:24 PM, Arun Sharma wrote: > >On 10/7/2004 11:02 PM, Mark Linimon wrote: > > > >>This may be processor-specific. > >> > >>http://www.freebsd.org/cgi/query-pr.cgi?pr=72128 > > > > > >I just tested that the 5.3-beta7 works fine on a 4 way Tiger with 1GB > >RAM. I don't think there have been critical bug fixes between beta6 and > >beta7 that affect the tiger. Also, on a 4GB machine, FreeBSD ignores RAM > >above 1GB. > > I meant to say FreeBSD ignores RAM above 4GB physical. So depending on your > memory map, this may or may not be a problem. I can verify my memory map in Linux, I'll send it in on the next boot. -- Jens Axboe
On Sat, Oct 09 2004, Jens Axboe wrote: > On Fri, Oct 08 2004, Arun Sharma wrote: > > On 10/8/2004 2:24 PM, Arun Sharma wrote: > > >On 10/7/2004 11:02 PM, Mark Linimon wrote: > > > > > >>This may be processor-specific. > > >> > > >>http://www.freebsd.org/cgi/query-pr.cgi?pr=72128 > > > > > > > > >I just tested that the 5.3-beta7 works fine on a 4 way Tiger with 1GB > > >RAM. I don't think there have been critical bug fixes between beta6 and > > >beta7 that affect the tiger. Also, on a 4GB machine, FreeBSD ignores RAM > > >above 1GB. > > > > I meant to say FreeBSD ignores RAM above 4GB physical. So depending on your > > memory map, this may or may not be a problem. > > I can verify my memory map in Linux, I'll send it in on the next boot. Sorry about the delay, was away on business. These are the only comments that Linux gives about the memory layout: efi.trim_top: ignoring 4KB of memory at 0x0 due to granule hole at 0x0 efi.trim_top: ignoring 24KB of memory at 0x1000 due to granule hole at 0x0 efi.trim_top: ignoring 8KB of memory at 0x7000 due to granule hole at 0x0 efi.trim_top: ignoring 484KB of memory at 0x9000 due to granule hole at 0x0 efi.trim_top: ignoring 4KB of memory at 0x84000 due to granule hole at 0x0 efi.trim_top: ignoring 108KB of memory at 0x85000 due to granule hole at 0x0 efi.trim_bottom: ignoring 15360KB of memory at 0x100000 due to granule hole at 0x0 efi.trim_bottom: ignoring 7168KB of memory at 0x7d900000 due to granule hole at 0x7d000000 Virtual mem_map starts at 0xa0007fffffc70000 On node 0 totalpages: 64916 DMA zone: 64916 pages, LIFO batch:4 Normal zone: 0 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 Built 1 zonelists Let me know if you need more info! -- Jens Axboe
On 10/18/2004 4:34 AM, Jens Axboe wrote: > On Sat, Oct 09 2004, Jens Axboe wrote: >> On Fri, Oct 08 2004, Arun Sharma wrote: >> > On 10/8/2004 2:24 PM, Arun Sharma wrote: >> > >On 10/7/2004 11:02 PM, Mark Linimon wrote: >> > > >> > >>This may be processor-specific. >> > >> >> > >>http://www.freebsd.org/cgi/query-pr.cgi?pr=72128 >> > > >> > > >> > >I just tested that the 5.3-beta7 works fine on a 4 way Tiger with 1GB >> > >RAM. I don't think there have been critical bug fixes between beta6 and >> > >beta7 that affect the tiger. Also, on a 4GB machine, FreeBSD ignores RAM >> > >above 1GB. >> > >> > I meant to say FreeBSD ignores RAM above 4GB physical. So depending on your >> > memory map, this may or may not be a problem. >> >> I can verify my memory map in Linux, I'll send it in on the next boot. > > Sorry about the delay, was away on business. > > These are the only comments that Linux gives about the memory layout: > I can't reproduce your problem on a tiger4 with 4GB RAM. Attached is the memory map obtained via memmap EFI command and the dmesg. -Arun
Hi, Here's the memmap on my box: Shell> memmap Type Start End # Pages Attributes BS_data 0000000000000000-0000000000000FFF 0000000000000001 0000000000000009 available 0000000000001000-0000000000006FFF 0000000000000006 0000000000000009 BS_data 0000000000007000-0000000000008FFF 0000000000000002 0000000000000009 available 0000000000009000-0000000000081FFF 0000000000000079 0000000000000009 RT_data 0000000000082000-0000000000083FFF 0000000000000002 8000000000000009 available 0000000000084000-0000000000084FFF 0000000000000001 0000000000000009 BS_data 0000000000085000-000000000009FFFF 000000000000001B 0000000000000009 RT_code 00000000000C0000-00000000000FFFFF 0000000000000040 8000000000000009 available 0000000000100000-000000000FF7FFFF 000000000000FE80 000000000000000B BS_data 000000000FF80000-000000000FFFFFFF 0000000000000080 000000000000000B available 0000000010000000-000000007D8FFFFF 000000000006D900 000000000000000B BS_code 000000007D900000-000000007F97FFFF 0000000000002080 000000000000000B available 000000007F980000-000000007F9FFFFF 0000000000000080 000000000000000B RT_code 000000007FA00000-000000007FDFFFFF 0000000000000400 8000000000000009 PAL_code 000000007FE00000-000000007FE3FFFF 0000000000000040 8000000000000009 RT_code 000000007FE40000-000000007FE97FFF 0000000000000058 8000000000000009 available 000000007FE98000-000000007FEE5FFF 000000000000004E 000000000000000B BS_data 000000007FEE6000-000000007FF08FFF 0000000000000023 000000000000000B available 000000007FF09000-000000007FF27FFF 000000000000001F 000000000000000B BS_data 000000007FF28000-000000007FF2FFFF 0000000000000008 000000000000000B Shell> 000000007FF30000-000000007FFFFFFF 00000000000000D0 8000000000000009 MemMapIO 00000000FE000000-00000000FEFFFFFF 0000000000001000 0000000000000001 RT_data 00000000FF000000-00000000FFFFFFFF 0000000000001000 8000000000000001 available 0000000180000000-00000001FEFAFFFF 000000000007EFB0 000000000000000B LoaderData 00000001FEFB0000-00000001FEFB7FFF 0000000000000008 000000000000000B LoaderCode 00000001FEFB8000-00000001FEFFDFFF 0000000000000046 000000000000000B available 00000001FEFFE000-00000001FF453FFF 0000000000000456 000000000000000B BS_data 00000001FF454000-00000001FF800FFF 00000000000003AD 000000000000000B available 00000001FF801000-00000001FF88BFFF 000000000000008B 000000000000000B BS_data 00000001FF88C000-00000001FF9F9FFF 000000000000016E 000000000000000B available 00000001FF9FA000-00000001FF9FAFFF 0000000000000001 000000000000000B BS_data 00000001FF9FB000-00000001FF9FDFFF 0000000000000003 000000000000000B available 00000001FF9FE000-00000001FFD7FFFF 0000000000000382 000000000000000B BS_code 00000001FFD80000-00000001FFDFDFFF 000000000000007E 000000000000000B available 00000001FFDFE000-00000001FFE11FFF 0000000000000014 000000000000000B RT_code 00000001FFE12000-00000001FFE7DFFF 000000000000006C 8000000000000009 available 00000001FFE7E000-00000001FFFB5FFF 0000000000000138 000000000000000B RT_data 00000001FFFB6000-00000001FFFFFFFF 000000000000004A 8000000000000009 MemMapIO 00000FFFF8000000-00000FFFFBFFFFFF 0000000000004000 8000000000000001 MemPortIO 00000FFFFC000000-00000FFFFFFFFFFF 0000000000004000 8000000000000001 LoaderCode: 70 Pages (286,720) LoaderData: 8 Pages (32,768) BS_code : 8,446 Pages (34,594,816) BS_data : 1,511 Pages (6,189,056) RT_code : 1,284 Pages (5,259,264) RT_data : 4,380 Pages (17,940,480) available : 1,036,877 Pages (4,247,048,192) MemMapIO : 20,480 Pages (83,886,080) MemPortIO : 16,384 Pages (67,108,864) PAL_code : 64 Pages (262,144) Total Memory: 4,111 MB (4,311,613,440) Bytes -- Jens Axboe
Jens Axboe wrote: > Hi, > > Here's the memmap on my box: > > Shell> memmap Looks pretty similar to my 4GB box. It looks like your serial console is working fine for EFI. Could you please check the settings for the kernel in the boot loader ? I use something like: hw.uart.console="io:0x2f8,br:57600" Your baud rate might be different. But you certainly need to change the io to 0x2f8 (COM2) from the default of 0x3f8 (COM1) on the Tiger. -Arun
On Thu, Oct 21 2004, Arun Sharma wrote: > Jens Axboe wrote: > >Hi, > > > >Here's the memmap on my box: > > > >Shell> memmap > > Looks pretty similar to my 4GB box. It looks like your serial console is > working fine for EFI. Could you please check the settings for the kernel > in the boot loader ? > > I use something like: > > hw.uart.console="io:0x2f8,br:57600" > > Your baud rate might be different. But you certainly need to change the > io to 0x2f8 (COM2) from the default of 0x3f8 (COM1) on the Tiger. That might just be it, I actually suspected this earlier today. But I thought the serial port on the tiger _was_ on 0x3f8. I'll give it a shot tomorrow, thanks. -- Jens Axboe
Was it the console setting and if yes, can this PR be closed? Thanks, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
State Changed From-To: open->closed The PR describes the typical case of not using a serial console or not having the serial console setup correctly. Given that the box does not create the DIG64 HCDP table, there's no other way to tell the kernel which serial port to use than setting the hw.uart.console variable.