Re: ENOMEM error diagnosis?
In message <[EMAIL PROTECTED]>, "Lucky Green" writes: >> Poul-Henning wrote: >> > Make sure you have rev 1.9 of src/sys/geom/bde/g_bde_crypt.c >> > I hadn't done my math and before that rev gbde would request >> > very large lumps of ram from malloc(9). > >For a few hours, I thought that rev 1.9 may have fixed the problem, but >I just received another "ENOMEM 0xchanging_digits on >0xc1c7c700(ad4s1c.bde)" after remaking the world and recompiling the >kernel with a cvsup from last night. g_bde_crypt.c is v 1.9 from >2003/03/07. Seems a bug continues to persist in GBDE. Hi Lucky, Sorry for the lack of response, I got hit by influenza and am only slowly making my way though the todo list. I'll try to get through your email this morning. ENOMEM in gbde is a tricky issue which I need to find a better solution for. What is there is at best a workaround it seems. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: ENOMEM error diagnosis?
> Poul-Henning wrote: > > Make sure you have rev 1.9 of src/sys/geom/bde/g_bde_crypt.c > > I hadn't done my math and before that rev gbde would request > > very large lumps of ram from malloc(9). For a few hours, I thought that rev 1.9 may have fixed the problem, but I just received another "ENOMEM 0xchanging_digits on 0xc1c7c700(ad4s1c.bde)" after remaking the world and recompiling the kernel with a cvsup from last night. g_bde_crypt.c is v 1.9 from 2003/03/07. Seems a bug continues to persist in GBDE. --Lucky To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ENOMEM error diagnosis?
In message <[EMAIL PROTECTED]>, "Lucky Green" writes: >I am seeing a lot of crashes of GBDE, causing "ENOMEM" errors to scroll >rapidly on the console. Whenever this happens, the server becomes >unresponsive to keyboard or any other input and has to be power cycled. >Is there some debug setting that I can set which would help diagnose the >problem further? This is on a minimally-loaded test machine with no >other users and no significant load from any services. Make sure you have rev 1.9 of src/sys/geom/bde/g_bde_crypt.c I hadn't done my math and before that rev gbde would request very large lumps of ram from malloc(9). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ENOMEM error diagnosis?
Lucky Green (Fri, Mar 14, 2003 at 06:40:58PM -0800) wrote:
> I am seeing a lot of crashes of GBDE, causing "ENOMEM" errors to scroll
> rapidly on the console. Whenever this happens, the server becomes
> unresponsive to keyboard or any other input and has to be power cycled.
> Is there some debug setting that I can set which would help diagnose the
> problem further? This is on a minimally-loaded test machine with no
> other users and no significant load from any services.
I stumbled upon this problem when I was messing around with the
swapoff() system call and /dev/md. If you do the following:
# swapoff (one after another...
# mdconfig -a -t swap -s 30M -u 3
# newfs /dev/md0
(nice unkillable loop)
So, doing some research indicates that one way of fixing this
problem was to detect if swap was available at all, in the
md{start,done}_swap() routines, but not sure if that is the best
fix.
The ENOMEM error occurs in geom_io.c:g_io_deliver(). I have not
familiarized myself with the GEOM code yet, but I could get a
stack trace by just shoving panic() into g_io_deliver(). If you
are running X or some sort of window system, you will not be
able to use it, as Lucky Green said, it will be just hang.
Going into DDB will not help because it hasn't crashed, and even
doing so, will just give you a trace of the fork_trampoline(),
ithd_loop() stuff... i.e. nothing which helps with the problem.
The error looks like:
"ENOMEM (0x) on (0x)..." in my case.
Cheers.
-- Hiten
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
