We are experiencing some problems which I think *could* be related to
timeout problems with poll().
1) mysql-3.23.48 + FreeBSD 4.2-RELEASE (also happens with prior mysql
releases)
CPU: Pentium III/Pentium III Xeon/Celeron (796.54-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x683 Stepping = 3
Features=0x387fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE>
FreeBSD/SMP: Multiprocessor motherboard
cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000
cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000
io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000
MySQL works fine for a while (sometimes a day, sometimes only an
hour) but then switches into "busy mode". Attaching a "truss" to the
pid gives the following:
poll(0x8253000,0x3,0x2690) = 1 (0x1)
gettimeofday(0x283512e8,0x0) = 0 (0x0)
poll(0x8253000,0x3,0x268f) = 1 (0x1)
gettimeofday(0x283512e8,0x0) = 0 (0x0)
poll(0x8253000,0x3,0x268e) = 1 (0x1)
gettimeofday(0x283512e8,0x0) = 0 (0x0)
poll(0x8253000,0x3,0x268e) = 1 (0x1)
gettimeofday(0x283512e8,0x0) = 0 (0x0)
poll(0x8253000,0x3,0x268e) = 1 (0x1)
gettimeofday(0x283512e8,0x0) = 0 (0x0)
poll(0x8253000,0x3,0x268d) = 1 (0x1)
gettimeofday(0x283512e8,0x0) = 0 (0x0)
poll(0x8253000,0x3,0x268d) = 1 (0x1)
over and over and over again with a lot of those loops per second
(however it still works correctly answering queries and that) using
one of the two CPUs at nearly 100%.
To me it looks like poll() returns from a timeout as I can't see
any read()/write() syscalls in the trace and I assume they should be
visible if a I/O operation on a FD would be ready, causing poll()
to return.
2) Mutt 1.2.5i + FreeBSD 4.4-RELEASE [using ncurses 5.1]
CPU: Pentium III/Pentium III Xeon/Celeron (995.68-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x686 Stepping = 6
Features=0x387fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE>
FreeBSD/SMP: Multiprocessor motherboard
cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000
cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000
io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000
If the user terminates the X session the xterm dies, but the bash
and the mutt survive and from that point mutt does nearly the same
as above (sorry no trace avail):
poll(), gettimeofday(), check mailbox, poll(), ...
at a *very* high rate. Here I also assume timeout as the reason for
returning from poll.
I've checked the PRs (open and closed) but couldn't find a problems I
would put in relation to our problems.
Has anybody else encountered this kind of problems? Any solutions?
If you need more information, I'll try my best to provide them.
Thanks,
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
proportional to the amount of vacuity between the ears of the admin"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
