I have dataset in big-query (Rows : 4,703,154,740 & size : 978 GB). Tableau Desktop running on Windows box with config :
OS : Windows Server 2008 R2 Standard Service Pack 1
Processor : Intel Xeon ES620 2.40 GHz (2 Processors)
Installed Ram : 128 GB (32 G Usable)
System Type : 64 Bits
How do I create a display filter, because I am getting out of memory error when I try to create report ?
Related
vmware: 7.0u2
I have created 10 VM's with 6 CPU per host with 8 GB of RAM, putted in vmx file:
- sched.cpu.latencySensitivity = "medium"
- sched.cpu.units = "mhz"
- sched.cpu.min = "999"
But when I see in "UI/Navigator/Hosts" the barprogress only show "2 Ghz" of usage when the "Memory" barprogress a 50% of usage.
If I go to "UI/Navigator/Virtual Machines" I can see VM's only work with 18 Mhz or 141 Mhz!
[1] Why my VM's don't work with the min: 999 Mhz?
[2] How I can force the VM's work always with "1 Ghz" min????
The "UI/Navigator/Virtual Machines" Show values several values but is not the reference clock speed in to VM.
When I go in to VM (auth) and I check the clock speed in "Task Manager/Performance" in Windows I see the correct value.
In Linux I checked with "lscpu" command and I see the correct value.
Cordially.
there!
I haven’t been able to use the Shader Editor. Im using Blender 2.9.1. I have proved different versions and only works in my computer in Blender 2.69.
1- I open Blender 2.9.1 (empty project)
2-I switch to Shader Editor (Shift F3)
3- Blender crashes
This hapens with Cycles, Eevee and Workbench. Any suggestions?
PC info:
Ubuntu 14.04
Intel core i7
7.7 Gb RAM
Intel corporation 3rd Gen Core Graphics Controller (rev 09)
This is the crash log file of Blender:
Blender 2.90.1, Commit date: 2020-09-23 06:43, Hash 3e85bb34d0d7
bpy.context.space_data.context = ‘RENDER’ # Property
bpy.context.area.ui_type = ‘ShaderNodeTree’ # Property
backtrace
/snap/blender/47/blender(BLI_system_backtrace+0x20) [0x81fdd40]
/snap/blender/47/blender() [0xe2329d]
/lib/x86_64-linux-gnu/libc.so.6(+0x36cb0) [0x7f6f851e7cb0]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x2ea2fe) [0x7f6f6785d2fe]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x2e13f6) [0x7f6f678543f6]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x2e1496) [0x7f6f67854496]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x2e07c8) [0x7f6f678537c8]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x2e2c25) [0x7f6f67855c25]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x2a7b45) [0x7f6f6781ab45]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x2e2178) [0x7f6f67855178]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x2a7b45) [0x7f6f6781ab45]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x2e12ca) [0x7f6f678542ca]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x2e076c) [0x7f6f6785376c]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x2a7b45) [0x7f6f6781ab45]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x2eb3fa) [0x7f6f6785e3fa]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x423131) [0x7f6f67996131]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x37b1e0) [0x7f6f678ee1e0]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x21823e) [0x7f6f6778b23e]
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x1308ea) [0x7f6f676a38ea]
/snap/blender/47/blender(GPU_shader_create_ex+0x687) [0x6f1a7a7]
/snap/blender/47/blender(GPU_shader_create+0x12) [0x6f1b032]
/snap/blender/47/blender(GPU_shader_create_from_arrays_impl+0xb7) [0x6f1b0f7]
/snap/blender/47/blender(GPU_shader_get_builtin_shader_with_config+0x1c2) [0x6f1b772]
/snap/blender/47/blender(GPU_batch_program_set_builtin_with_config+0xd) [0x6f03b9d]
/snap/blender/47/blender() [0x184275c]
/snap/blender/47/blender(nodelink_batch_end+0x28) [0x1843d98]
/snap/blender/47/blender(node_draw_nodetree+0x11d) [0x184781d]
/snap/blender/47/blender() [0x1847967]
/snap/blender/47/blender(drawnodespace+0x449) [0x1847dc9]
/snap/blender/47/blender(ED_region_do_draw+0x811) [0x1487631]
/snap/blender/47/blender(wm_draw_update+0x4da) [0x10deb5a]
/snap/blender/47/blender(WM_main+0x30) [0x10dcab0]
/snap/blender/47/blender(main+0x317) [0xd5ec67]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f6f851d2f45]
/snap/blender/47/blender() [0xe1fa83]
Python backtrace
I'm using a USB CD/DVD drive without built-in sound decoder and controlling it via ALSA, which already works. The host is a Raspberry Pi 3B with the current Raspbian. Here is the corresponding config file:
pi#autoradio:/etc $ cat asound.conf
pcm.dmixer {
type dmix
ipc_key 1024
ipc_perm 0666
slave {
pcm "hw:0,0"
period_time 0
period_size 1024
buffer_size 4096
rate 192000
format S32_LE
channels 2
}
bindings {
0 0
1 1
}
}
pcm.dsnooper {
type dsnoop
ipc_key 2048
ipc_perm 0666
slave
{
pcm "hw:0,0"
period_time 0
period_size 1024
buffer_size 4096
rate 192000
format S32_LE
channels 2
}
bindings {
0 0
1 1
}
}
pcm.duplex {
type asym
playback.pcm "dmixer"
capture.pcm "dsnooper"
}
pcm.!default {
type plug
slave.pcm "duplex"
}
ctl.!default {
type hw
card 0
}
To read the music from CD-DA, I'm gonna use the CDIO++ library. Its cd-info utility recognises both the drive, and the audio CD:
pi#autoradio:/etc $ cd-info
cd-info version 2.1.0 armv7l-unknown-linux-gnueabihf
CD location : /dev/cdrom
CD driver name: GNU/Linux
access mode: IOCTL
Vendor : MATSHITA
Model : CD-RW CW-8124
Revision : DA0D
Hardware : CD-ROM or DVD
Can eject : Yes
Can close tray : Yes
Can disable manual eject : Yes
Can select juke-box disc : No
Can set drive speed : No
Can read multiple sessions (e.g. PhotoCD) : Yes
Can hard reset device : Yes
Reading....
Can read Mode 2 Form 1 : Yes
Can read Mode 2 Form 2 : Yes
Can read (S)VCD (i.e. Mode 2 Form 1/2) : Yes
Can read C2 Errors : Yes
Can read IRSC : Yes
Can read Media Channel Number (or UPC) : Yes
Can play audio : Yes
Can read CD-DA : Yes
Can read CD-R : Yes
Can read CD-RW : Yes
Can read DVD-ROM : Yes
Writing....
Can write CD-RW : Yes
Can write DVD-R : No
Can write DVD-RAM : No
Can write DVD-RW : No
Can write DVD+RW : No
__________________________________
Disc mode is listed as: CD-DA
I've already got some code to send the PCM data to the sound card and some insight regarding the (rather poorly documented) CDIO API (I know that the readSectors() method is used for reading sound data from the CD sector after sector), but not really a clue on how to hand over the data from the CD-DA input to the ALSA output routine correctly.
Please nopte that mplayer is off-limits to me as this routine will be a part of a larger solution.
Any help would be greatly appreciated.
UPDATE: Does the different block size of an audio CD (2,352 bytes) and of the sound output (910 bytes, at least in my particular case) matter?
CD audio data is just two channels of little-endian 16-bit samples at 44.1 kHz.
If you output the data to the standard output, you can pipe it into your sound-playing program, or aplay:
./my-read-cdda | ./play 44100 2 99999
./my-read-cdda | aplay --file-type raw --format cd
If you want to do everything in a single program, replace the read(0, ...) with readSectors(). (The buffer size does not need to have any relation with ALSA's period size or buffer size.)
I've Ubuntu 14.0.4 & Windows 7 installed in Virtual Box.
I ran the below command to increase the virtual box allocation size
VBoxManage modifyhd "/home/myname/VirtualBox VMs/Windows 7 RC/Windows 7 RC.vdi" --resize 52200
It gave me
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
And the size becomes:-
VBoxManage showhdinfo "/home/myname/VirtualBox VMs/Windows 7 RC/Windows 7 RC.vdi"
UUID: 47c148a5-b97f-4cf3-97c1-69b39f9b2208
Parent UUID: base
State: created
Type: normal (base)
Location: /home/myname/VirtualBox VMs/Windows 7 RC/Windows 7 RC.vdi
Storage format: VDI
Format variant: dynamic default
Capacity: 52200 MBytes
Size on disk: 25523 MBytes
The problem here is Capacity has been increased to 52 GB but the Actual Size is not increasing.
Format variant: dynamic default not fixed
I'd deeply appreciate any help.
Problem solved!!
I went to Disk Management >> Disk Extend Volume >> Updated the disk size to Unallocated space.
Now it looks like below.
I am working on an Embedded ARM9 development board. In that i want rearrange my nand partitions. Can anybody tell me how to do that ?
In my u-boot shell if i give the command mtdparts which gives following information .
Boardcon> mtdparts
device nand0 <nandflash0>, # parts = 7
#: name size offset mask_flags
0: bios 0x00040000 0x00000000 0
1: params 0x00020000 0x00040000 0
2: toc 0x00020000 0x00060000 0
3: eboot 0x00080000 0x00080000 0
4: logo 0x00100000 0x00100000 0
5: kernel 0x00200000 0x00200000 0
6: root 0x03c00000 0x00400000 0
active partition: nand0,0 - (bios) 0x00040000 # 0x00000000
defaults:
mtdids : nand0=nandflash0
mtdparts: mtdparts=nandflash0:256k#0(bios),128k(params),128k(toc),512k(eboot),1024k(logo),2m(kernel),-(root)
Kernel boot message shows the following :
Creating 3 MTD partitions on "NAND 64MiB 3,3V 8-bit":
0x000000000000-0x000000040000 : "Boardcon_Board_uboot"
0x000000200000-0x000000400000 : "Boardcon_Board_kernel"
0x000000400000-0x000003ff8000 : "Boardcon_Board_yaffs2"
Anybody can please explain me what is the relation between both these messages . And which one either kernel or u-boot is responsible for creating partions on nand flash?. As for as i know kernel is not creating partitions on each boot but why the message "Creating 3 MTD partitions"?
For flash devices, either NAND or NOR, there is no partition table on the device itself. That is, you can't read the device in a flash reader and find some table that indicates how many partitions are on the device and where each partition begins and ends. There is only an undifferentiated sequence of blocks. This is a fundamental difference between MTD flash devices and devices such as disks or FTL devices such as MMC.
The partitioning of the flash device is therefore in the eyes of the beholder, that is, either U-Boot or the kernel, and the partitions are "created" when beholder runs. That's why you see the message Creating 3 MTD partitions. It reflects the fact that the flash partitions really only exist in the MTD system of the running kernel, not on the flash device itself.
This leads to a situation in which U-Boot and the kernel can have different definitions of the flash partitions, which is apparently what has happened in the case of the OP.
In U-Boot, you define the flash partitions in the mtdparts environment variable. In the Linux kernel, the flash partitions are defined in the following places:
In older kernels (e.g. 2.6.35 for i.MX28) the flash partitioning could be hard-coded in gpmi-nfc-mil.c or other driver source code. (what a bummer!).
In the newer mainline kernels with device tree support, you can define the MTD paritions in the device tree
In the newer kernels there is usually support for kernel command line partition definition using a command line like root=/dev/mmcblk0p2 rootwait console=ttyS2,115200 mtdparts=nand:6656k(all),1m(squash),-(jffs2)
The type of partitioning support that you have in the kernel therefore depends on the type of flash you are using, whether it's driver supports kernel command line parsing and whether your kernel has device tree support.
In any event, there is an inherent risk of conflict between the U-Boot and kernel partitioning of the flash. Therefore, my recommendation is to define the flash partitions in the U-Boot mtdparts variable and to pass this to the kernel in the U-Boot kernel command line, assuming that your kernel support this option.
you can set the mtdparts environment variable to do so in uboot, and the kernel only use this if you pass this in kernel boot commandline, or else it'll default to the nand partition structure in the kernel source code for your platform, which in this case the 3 MTD partition default.