Core v7.0beta1

[andyj]

What happens if you set the copy2fs.flg and load them all? It's strange that rootfs only shows 20M used. I have 260+ loops and it shows 500M on my system.

[coreplayer2]

I think I've figured out the problem, but the jury is not out yet..

Increased vmalloc to 256MB at the grub2 command line and hopefully that will accommodate the massive video card that appears to be causing the issue.



"UPDATE"  this was the fix, I should have looked at dmesg sooner :p  problem solved   
thanks

[curaga]

@coreplayer2:

If you boot without that option, what does "grep -i vmalloc /proc/meminfo" say (after hitting that mount error)? How big a GPU do you have?
edit: On a Qemu boot, there's 900mb reserved.

@andyj

There is a new kernel driver for the VMWare mouse, supposed to enable a better experience, but it requires Xorg and the vmmouse driver. Seems like you need a bootcode, psmouse.proto=imps, to disable the new vmmouse driver.

It's unfortunate this can't be detected at runtime. We can either:
- disable that driver, but then the VMWare mouse experience might suffer in the future, when they remove the userspace mouse sync from xf86-input-vmmouse
- just document that vmware + Xvesa needs that

Adding absolute pointer support (vmmouse, touch screens) to Xvesa would also be possible, but it's not something I'm interested in doing.

[andyj]

The boot code fixes the mouse problem with Xvesa, insofar as it now exhibits the behavior of TC 6 where the mouse works but you have to manually ungrab the mouse to move it out of the window. The built in vmmouse driver also explains why manually ungrabbing the mouse in TC 7 wasn't required, even though the mouse wasn't working in Xvesa. I would answer the question this way: If someone is using VMware, then they will probably use Xorg and open-vm-tools to get the video and mouse functionality they need. If not and they stick with Xvesa then they know what they are getting. If they are using ESX then the video driver doesn't really matter because they are either using VNC to see the console, or in my case not running X at all and using SSH. I'm not having any luck changing this after boot, either through sysctl. /proc or /sys. Would adding this bootcode to the command line for the ISO image affect other platforms? Then we could go the documentation route, by pointing out during the "add boot codes" phase of the installation process that this is needed for VMware VM's using Xvesa and not Xorg.

[curaga]

Adding the bootcode by default might break others' mice, especially laptop touchpads, so that's not an option. I don't think there's any runtime way, but I asked the VMWare people, maybe they have an idea.

[andyj]

I was think along the lines of adding a "boot in a VMware VM" selection to the boot menu on the ISO image with the boot code appended to APPEND, not as a general default for an installed command line. I wouldn't think this would affect anything else.

[curaga]

The VMWare people confirmed the userspace support is not going away, so we can disable the kernel vmmouse driver safely, without impacting Xorg users.

Andyj, can you post the contents of /proc/bus/input/devices?

cat /proc/bus/input/devices | nc termbin.com 9999

[andyj]

I think the netcat worked, but here is the output since it's kinda short. There does seem to be a lot of mice:

Code: [Select]

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=LNXPWRBN/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
U: Uniq=
H: Handlers=kbd event0
B: PROP=0
B: EV=3
B: KEY=100000 0 0 0

I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/devices/platform/i8042/serio0/input/input1
U: Uniq=
H: Handlers=sysrq kbd leds event1
B: PROP=0
B: EV=120013
B: KEY=4 2000000 3803078 f800d001 feffffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7

I: Bus=0011 Vendor=0002 Product=0013 Version=0006
N: Name="VirtualPS/2 VMware VMMouse"
P: Phys=isa0060/serio1/input1
S: Sysfs=/devices/platform/i8042/serio1/input/input4
U: Uniq=
H: Handlers=event2
B: PROP=0
B: EV=b
B: KEY=70000 0 0 0 0 0 0 0 0
B: ABS=3

I: Bus=0011 Vendor=0002 Product=0013 Version=0006
N: Name="VirtualPS/2 VMware VMMouse"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input3
U: Uniq=
H: Handlers=mouse0 event3
B: PROP=1
B: EV=7
B: KEY=30000 0 0 0 0 0 0 0 0
B: REL=103

I: Bus=0010 Vendor=001f Product=0001 Version=0100
N: Name="PC Speaker"
P: Phys=isa0061/input0
S: Sysfs=/devices/platform/pcspkr/input/input5
U: Uniq=
H: Handlers=kbd event4
B: PROP=0
B: EV=40001
B: SND=6

I: Bus=0003 Vendor=0e0f Product=0003 Version=0110
N: Name="VMware VMware Virtual USB Mouse"
P: Phys=usb-0000:02:00.0-1/input0
S: Sysfs=/devices/pci0000:00/0000:00:11.0/0000:02:00.0/usb2/2-1/2-1:1.0/0003:0E0F:0003.0001/input/input6
U: Uniq=
H: Handlers=mouse1 event5
B: PROP=0
B: EV=17
B: KEY=ff0000 0 0 0 0 0 0 0 0
B: REL=103
B: MSC=10


[coreplayer2]

@coreplayer2:

If you boot without that option, what does "grep -i vmalloc /proc/meminfo" say (after hitting that mount error)? How big a GPU do you have?
edit: On a Qemu boot, there's 900mb reserved.

Sorry got busy...
Tests after booting without the vmalloc=256 boot code
with and without swap partition

Code: [Select]

withswap
clean after bootup
tc@box:~$ grep -i vmalloc /proc/meminfo
VmallocTotal:     122880 kB
VmallocUsed:        7984 kB
VmallocChunk:     114596 kB
withswap
after running build script
tc@box:~$ grep -i vmalloc /proc/meminfo
VmallocTotal:     122880 kB
VmallocUsed:        8036 kB
VmallocChunk:     114220 kB
tc@box:~$

noswap
clean after bootup
tc@box:~$ grep -i vmalloc /proc/meminfo
VmallocTotal:     122880 kB
VmallocUsed:        5108 kB
VmallocChunk:     117596 kB
noswap
after running build script
tc@box:~$ grep -i vmalloc /proc/meminfo
VmallocTotal:     122880 kB
VmallocUsed:        5160 kB
VmallocChunk:     117556 kB
tc@box:~$
results in 120MB allocation

With vmalloc=256MB bootcode

Code: [Select]

tc@box:~$ grep -i vmalloc /proc/meminfo
VmallocTotal:     262144 kB
VmallocUsed:       52584 kB
VmallocChunk:     196052 kB
tc@box:~$results in 256MB allocation

Since setting the bootcode that one time I haven't been able to reproduce the loop error
even after removing the bootcode,  but I'll keep trying

I'm fairly sure the 4GB memory installed on the video card has a lot to do with this issue

Code: [Select]

VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] (rev a1)
Subsystem: eVga.com. Corp. Device 2974
Kernel driver in use: nvidia


[curaga]

Thanks. With 4gb RAM + big gpu you really should run a 64-bit kernel, there's not enough address space for everything on a 32-bit one.

[coreplayer2]

Under normal conditions I boot to corepure64 and occasionally core64 which do not have this issue, obviously...   But there are times when I need to compile something on x86, so I usually configure the boot config capable to boot either one of the three variations.    The vmalloc boot code had slipped my mind so I'm thankful to you for reminding me.

Now if I can just get the Nvidia driver to compile on corepure64.. 

[curaga]

Oh, you can use a 64-bit kernel for that still

"linux32 bash" will start a bash shell that claims to be 32-bit in uname -m. This is useful for some configure scripts that check for it.