I noticed this question has been asked many times in the past and surfing the web I found many pages about it. However, it seems like the proposed solutions rarely work and, in my case, the problem does not refer to a program that I wrote. So I'll give it another try here.
I recently installed Linux Mint 14 on my laptop. After the OS was spick and span, I started to install the software I need, and among these netgen (a Mesh Generator software). I tried both ways: download+unpack+compile+install and synaptic. Either way, this is the output I get when I try to execute the program
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Serial number of failed request: 490
Current serial number in output stream: 491
As I said, I surfed the web, and apparently, this is thought to be linked to some problem in the X server configuration. And here start the mess. Someone says I should modify /etc/X11/Xorg.conf, adding the lines
Option "Videoram" "65536"
Option "Cachelines" "1980"
Under the section "Device." Unfortunately, I have no such file, as apparently in recent distros, the X configuration file has been moved to /usr/share/X11/xorg.conf.d/* and it's now split into different files. The one about the monitor and graphics should be called 10-monitor.conf...which I don't have. I tried to create one, following the instruction at this link, and then add those lines, but nothing happened. To be fair, I'm not 100% sure I generated the file correctly since I am not sure how to detect the driver for my graphics card.
I don't know how much and which information people would need to have an idea of how to fix this problem. Here's what I see might be useful.
The output of 'lspci | grep VGA' is
01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
ATI RS880M [Mobility Radeon HD 4200 Series]
My current /usr/share/X11/xorg.conf.d/10-monitor.conf is the following
Section "Monitor"
Identifier "Monitor0"
Modeline "1920x1080_60.00" 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -HSync +Vsync
EndSection
Section "Device"
Identifier "LVSD"
Driver "fglrx" #Choose the driver used for this monitor
EndSection
Section "Screen"
Identifier "Screen0"
Device "LVDS"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1920x1080_60.00" "1366x768"
EndSubSection
EndSection
Under the section "Device." Unfortunately, I have no such file
Try creating your own xorg.conf file, placing it in this location will override your X settings after restarting X or simply by restarting the computer.
mkdir -p /etc/X11/xorg.conf.d/
cp /etc/X11/xorg.conf.d/xorg.conf /etc/X11/xorg.conf.d/xorg.conf.bk # in case it exists
cp /usr/share/X11/xorg.conf.d/10-monitor.conf /etc/X11/xorg.conf.d/xorg.conf
The content of /etc/X11/xorg.conf.d/xorg.conf would look like (adding your options):
Section "Monitor"
Identifier "Monitor0"
Modeline "1920x1080_60.00" 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -HSync +Vsync
EndSection
Section "Device"
Identifier "LVSD"
Driver "fglrx" #Choose the driver used for this monitor
Option "Videoram" "65536"
Option "Cachelines" "1980"
EndSection
Section "Screen"
Identifier "Screen0"
Device "LVDS"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1920x1080_60.00" "1366x768"
EndSubSection
EndSection
This also could be related to the driver you're using, there are other common drivers available like
Driver "fbdev"
Driver "vesa"
Driver "fglrx"
The fbdev driver supports all hardware where a framebuffer driver is available.
The vesa driver supports most VESA-compatible video cards. There are some known exceptions, and those should be listed here.
fglrx is a X.org(7x) driver for ATI (Mobility(TM)) RADEON® and (Mobility(TM)) FireGL(TM) based video cards. The driver provides hardware acceleration for 3D graphics and video playback. It includes support for dual displays, TV Output and as of version 8.21.7 also OpenGL 2.0 (GLSL).
Depending on which driver you choose, certain options/functionality/compatibility would be enabled or not, you could change the driver and test with the options you said would work.
Finally, you have hundreds of options here to play with X11.
When I had made written a lot text to my program I took similiar error. When I reduce the text size the error was disappeared. I think you should reduce too showing things or reorganise how they are looking on screen.
I hope I could help you with this broken English ;)
Related
1- i will start by writing the general configurations(system, version, smart contract overall idea).
2- then i will show the main problem(with small code line, that i think it need edit).
3- third part i will show what i try until now and the results
4- at the end of i will add the github link for my full code.
note: the full original code produced by mr. PatrickAlphaC.
a- general configurations(system, version, smart contract overall idea):
a1- operation system: opensuse leap 15.3
a2- hardhat version: 2.8.3
a3- node version: v14.18.3
a4- npm version: 8.3.0
a5- metamask wallet addone to firefox
a6- target block chain: polygon(main net, test net)
a7- smart contract overall idea: use svg to create erc-721 nft, where it's metadata totally stored on chain(the smart contract mint tokenurl to polygon chain).
b- the main problem:
every thing work good as the size of minted file (tokenurl) less than 23.8kb(small than 23.8 kb). where i target mint file that twice this size (every tokenurl equal 50kb). so when try mint tokenurl with size (23.8 Kb < size < 50 Kb) i recive next error message.
An unexpected error occurred:
Error: ERROR processing /home/naive/demos/secondtry/deploy/01_Deploy_SVGNFT.js:
Error: cannot estimate gas; transaction may fail or may require manual gas limit (error={"name":"ProviderError","code":-
32000,"_isProviderError":true}, method="estimateGas", transaction={"from":"metamask wallet address","to":"contract address",
c- what i try until now and the results:
c1- try set the gas limit in "hardhat.config" but did not make any effect(it was during search so i do not remmber the form or values).
c2- in "01_Deploy_SVGNFT" add gaslimit to tx, so the code line look like next.
c2-0 origonal code line before edit it: tx = await svgNFT.create(svg)
c2-1 code line after edit it: tx = await svgNFT.create(svg, {gasLimit: 3000000 })
c2-2 the result: give me some error message about wrong syntic (forum, typing)
c3- in "01_Deploy_SVGNFT" add gaslimit to tx, so the code line look like next.
c3-0 origonal code line before edit it: tx = await svgNFT.create(svg)
c3-1 code line after edit it: tx = await svgNFT.create({svg}, {gasLimit: 3000000 })
c3-2 the results:
3-2-0 contract deploying, svg uploading, contract verifying, the matic value decrease in metamask wallet(gas value transfer succeed) all thing look good.
3-2-1 when go to opensea there's no image appears.
3-2-2 when go to polygonscan or etherscan and use token id to see the token uri it return nothing (ther's no metadata string appears, nothing appears).
d- the next github link for full code(contracts, deploy, hardhat.config.js, helper-hardhat-config.js and img folder that contains (preproduced tokenurl)
https://github.com/naive2022/onchainfork
hope help me find how can mint preproduced tokenurl(every file size is 50kb) without face this problem when use polygon test or polygon main network.
the final results rinkeby network can not accept(mint token url) with size above 23 kb approximately
I've a tape contains a corrupt tar file.
I'm using Unix SunOS 5.5.1.
So when I run this command :
dd if=/dev/rmt/0 of=/tmp/outputfile.tar
I get this error message :
warning /pci#1f, 0/pci#1/pci#1/sunw, isptwo#4/st#4,0 (st4):
Error for command : read Error Level: Fatal
Requested Block : 11900 Error Block : 11900
Vendor : TANDBERG Serial Number: =:CREATED081
Sense Key: Media Error
ASC: 0x11 (unrecorded read error), ASCQ: 0x1, FRU: 0x0
Please Help me I really need solution for this problem
Finally I solved my problem ^^' it was the bs format type :D
Data was written in 512 so I did this :
dd if=/dev/rmt/0 of=/tmp/outputfile.tar bs=512 and all is fine :)))
The bad news is that the tape drive is reporting a media error.
Now this still can mean a few things:
Bad tape drive
This is possible, but rather uncommon. To test it: check if it can read other tapes (it wrote itself), or read tapes other drives wrote.
Dirty heads
Tape drives heads do need periodic cleaning. Esp if they are kept in less that spotless conditions this is very important. Cleaning tapes are commercially available, do match them with the right drive and do not overuse them either.
Mismatch between tape drive and tape medium
Different tape formats (e.g. LTO) have generations (e.g. LTO-3), and there is a need for compatibility between the tape medium and the tape drive.
Bad tape
Tapes do wear out, and need replacement to prevent that. Moreover a written tape has a limited shelf life just as well.
In this last case, you might be able to find a commercial recovery service to try to do something, but I'd not bet the farm on the results ... And data recovery services are expensive ...
I'm making a Turbo Pascal 7.0 program for my class, it has to be on Graphic Mode.
A message pops up
BGI Error: Graphics not initialized (use InitGraph).
I'm already using InitGraph and graph.tpu and I specified the route as "C:\TP7\BGI".
My S.O is Windows 7 and I'm using DosBox 0.74, I already tried to paste all the files from the folder BGI into BIN.
What should I do?
Since dos doesn't have system graphic drivers, the BGI functions as such for BP7.
So in short, use a BGI suitable for your videocard. The ones supplied with BP7 are very old, there are newer, VESA ones that you could try.
Afaik 3rd party BGI needs to be registered explicitly in code though.
At first I have had this "missing Graph.tpu"- ... and later the "Use Initgraph"-issue too.
After hours trying (and reading some not politeful comments in the internet) I finally got Turbo Pascal 7 succesfully running (in Windows 10, x64). In summary I want to share "some secrets":
install the "TP(WDB)-7.3.5-Setup.msi" (comes from clever people in Vietnam)
make sure, that there's the CORRECT PATH to the "BGI"-directory in your program-code. For example:
driver := Detect;
InitGraph (driver, modus, 'c:\TPWDB\BGI');
(By the way: This is ALL, what's there to do with "Initgraph".)
make sure, that in TP7 under "Options" --> "Directories" are the CORRECT PATHS both to "C:\TPWDB\UNITS" and Your actual working dir e.g. "C:\TPWDB\myPrograms"
THAT's IT.
Annotations: The "Graph.TPU" (usually) is already in "UNITS" (together with "Graph3.tpu" by the way).
Hazzling around old driver's isn't needed even... :)
Just the correct paths... :)
Hope, that can help ...
TI OMAP 4460 + Android file system + Android Linux kernel 3.0
I have set CONFIG_LOGO, CONFIG_VT and CONFIG_FRAMEBUFFER_CONSOLE in kernel config, logo image type is CLUT224.
Then I saw strange things, almost 10 seconds later after kernel booting, a broken image appeared, looked like the head of the penguin, only several pixels of lines on the top of sreen. Then I reboot again and agian, sometimes I saw the 'ANDROID' characters, just below the penguin's head, but sometimes not.
see the linkenter link description here
My colleague reminded me I should disable the Android booting logo('ANDROID' characters, to be exactly), because it needs to open a tty console. That might have effect on something?
Besides, why the penguin logo showed up so late? I added some print in drivers/video/fbmem.c
fb_do_show_logo(), this function was called at 3 seconds after kernel booting. Why I saw the logo at 10 seconds?
The log rotation for Plone product installation would be a nice feature. What are the current best practices regarding the log rotation integration into Plone?
I found this article: http://encolpe.wordpress.com/2010/06/17/how-to-get-log-files-rotate-in-zope-with-buildout/ but as there are no documentation on plone.org I'd like to ping the community for the good known best practices not to fill up their hard disks.
ZConfig has support for the standard library RotatingFileHandler and TimedRotatingFileHandler. Taking an example from the ZConfig tests:
<eventlog>
<logfile>
path /path/to/file.log
level debug
when D
interval 3
old-files 11
</logfile>
</eventlog>
This will roll over the logs every three days, keeping 11 old files.
You place these config snippets your buildout using the event-log-custom/access-log-custom parameters in your instance recipe. plone.recipe.zope2instance
Similar to what Laurence said above but keeps size under 10mb and saves only 1 old file.
<eventlog>
level INFO
<logfile>
path /path/to/plone4/var/log/client1.log
max-size 10mb
old-files 1
</logfile>
</eventlog>
plone.recipe.zope2instance can generate this now. For example, you can specify the following options:
event-log-max-size = 10mb
event-log-old-files = 3
Here's what we do, it's simple but works:
In your buildout you add this part:
[logrotate]
recipe = collective.recipe.template
input = ${buildout:directory}/templates/logrotate.conf
output = ${buildout:directory}/etc/logrotate.conf
And in templates/logrotate.conf
rotate 4
weekly
create
compress
delaycompress
missingok
${buildout:directory}/var/log/instance1.log ${buildout:directory}/var/log/instance1-Z2.log {
sharedscripts
postrotate
/bin/kill -USR2 $(cat ${buildout:directory}/var/instance1.pid)
endscript
}
${buildout:directory}/var/log/instance2.log ${buildout:directory}/var/log/instance2-Z2.log {
sharedscripts
postrotate
/bin/kill -USR2 $(cat ${buildout:directory}/var/instance2.pid)
endscript
}
Add whatever other log rotations you need. Then it's about linking /etc/logrotate.conf to the generated file.
Mikko, you should ask me directly ;)
My blog article is still good and this feature is still undocumented in Zope2. It can be used with Plone 4 and Plone 5. The extension iw.rotatelogs was designed for Plone 3 only.
Using logrotate is not fine because it doesn't handle the case of logwriting during the rotation. It can make your instance crash silently and writing logs in RAM until your restart the instance.
I've been using iw.rotatezlogs since at least early Plone 3 very successfully. I see from your link that I should no longer need iw.rotatezlogs.
I don't like to rely on logrotate, since it's not usable on the one Windows server I have to deploy to.
As near as I can tell, the pure-zope solution (which I stil haven't tested) doesn't do logfile compression (at least I can't see it in ZConfig/components/logger/handlers.xml which is where I think it should be defined), so I suspect I'll be staying with iw.rotatezlogs.