Compact Flash panic integer divide fault

[Ted Lindgreen]

Hi,

Since some time FreeBSD-current panics with a compact flash disk
in a pccard adapter. The kernel panics with integer divide fault
as soon as the card is encountered.

I first saw the integer divide fault with a kernel build on
November 6th.
With a newer kerner (Nov 10th) the panic changed into
 panic: page fault.
Now, the panic: integer divide fault is back again.

Appended is a log from a kernel build last Friday (after a cvsup).

The system is a Toshiba Portege 7220, the compact flash disk is a
SanDisk. I tried it with two different cards (a 128 and a 32 Mb).
Both cards work fine with an older system (build in Sept 2003).

-- ted

Nov 16 22:00:30 petje kernel: Copyright (c) 1992-2003 The FreeBSD Project.
Nov 16 22:00:30 petje kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 
1992, 1993, 1994
Nov 16 22:00:30 petje kernel: The Regents of the University of California. All rights 
reserved.
Nov 16 22:00:30 petje kernel: FreeBSD 5.1-CURRENT #5: Fri Nov 14 21:45:08 CET 2003
Nov 16 22:00:30 petje kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PETJE
Nov 16 22:00:30 petje kernel: Preloaded elf kernel /boot/kernel/kernel at 0xc0996000.
Nov 16 22:00:30 petje kernel: Preloaded userconfig_script /boot/kernel.conf at 
0xc0996294.
Nov 16 22:00:30 petje kernel: Timecounter i8254 frequency 1193182 Hz quality 0
Nov 16 22:00:30 petje kernel: CPU: Intel Pentium III (646.83-MHz 686-class CPU)
Nov 16 22:00:30 petje kernel: Origin = GenuineIntel  Id = 0x686  Stepping = 6
Nov 16 22:00:30 petje kernel: 
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
Nov 16 22:00:30 petje kernel: real memory  = 201195520 (191 MB)
Nov 16 22:00:30 petje kernel: avail memory = 185786368 (177 MB)
Nov 16 22:00:30 petje kernel: Pentium Pro MTRR support enabled
Nov 16 22:00:30 petje kernel: npx0: [FAST]
Nov 16 22:00:30 petje kernel: npx0: math processor on motherboard
Nov 16 22:00:30 petje kernel: npx0: INT 16 interface
Nov 16 22:00:30 petje kernel: pcibios: BIOS version 2.10
Nov 16 22:00:30 petje kernel: Using $PIR table, 8 entries at 0xc00f0190
Nov 16 22:00:30 petje kernel: apm0: APM BIOS on motherboard
Nov 16 22:00:30 petje kernel: apm0: found APM BIOS v1.2, connected at v1.2
Nov 16 22:00:30 petje kernel: pcib0: Intel 82443BX (440 BX) host to PCI bridge at 
pcibus 0 on motherboard
Nov 16 22:00:30 petje kernel: pci0: PCI bus on pcib0
Nov 16 22:00:30 petje kernel: pci_cfgintr: 0:5 INTD BIOS irq 11
Nov 16 22:00:30 petje kernel: pci_cfgintr: 0:9 INTA BIOS irq 11
Nov 16 22:00:30 petje kernel: pci_cfgintr: 0:12 INTA BIOS irq 11
Nov 16 22:00:30 petje kernel: agp0: Intel 82443BX (440 BX) host to PCI bridge mem 
0xe800-0xefff at device 0.0 on pci0
Nov 16 22:00:30 petje kernel: pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0
Nov 16 22:00:30 petje kernel: pci1: PCI bus on pcib1
Nov 16 22:00:30 petje kernel: pci_cfgintr: 1:0 INTA BIOS irq 11
Nov 16 22:00:30 petje kernel: pci1: display, VGA at device 0.0 (no driver attached)
Nov 16 22:00:30 petje kernel: isab0: PCI-ISA bridge at device 5.0 on pci0
Nov 16 22:00:30 petje kernel: isa0: ISA bus on isab0
Nov 16 22:00:30 petje kernel: atapci0: Intel PIIX4 UDMA33 controller port 
0xfff0-0x at device 5.1 on pci0
Nov 16 22:00:30 petje kernel: ata0: at 0x1f0 irq 14 on atapci0
Nov 16 22:00:30 petje kernel: ata0: [MPSAFE]
Nov 16 22:00:30 petje kernel: ata1: at 0x170 irq 15 on atapci0
Nov 16 22:00:30 petje kernel: ata1: [MPSAFE]
Nov 16 22:00:30 petje kernel: uhci0: Intel 82371AB/EB (PIIX4) USB controller port 
0xff80-0xff9f irq 11 at device 5.2 on pci0
Nov 16 22:00:30 petje kernel: usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0
Nov 16 22:00:30 petje kernel: usb0: USB revision 1.0
Nov 16 22:00:30 petje kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, 
addr 1
Nov 16 22:00:30 petje kernel: uhub0: 2 ports with 2 removable, self powered
Nov 16 22:00:30 petje kernel: ums0: Logitech USB Mouse, rev 1.10/6.b4, addr 2, iclass 
3/1
Nov 16 22:00:30 petje kernel: ums0: 3 buttons and Z dir.
Nov 16 22:00:30 petje kernel: pci0: bridge, PCI-unknown at device 5.3 (no driver 
attached)
Nov 16 22:00:30 petje kernel: pci0: unknown at device 9.0 (no driver attached)
Nov 16 22:00:30 petje kernel: cbb0: ToPIC100 PCI-CardBus Bridge at device 11.0 on 
pci0
Nov 16 22:00:30 petje kernel: cardbus0: CardBus bus on cbb0
Nov 16 22:00:30 petje kernel: pccard0: 16-bit PCCard bus on cbb0
Nov 16 22:00:30 petje kernel: pci_cfgintr: 0:11 INTA routed to irq 11
Nov 16 22:00:30 petje kernel: cbb0: [MPSAFE]
Nov 16 22:00:30 petje kernel: cbb1: ToPIC100 PCI-CardBus Bridge at device 11.1 on 
pci0
Nov 16 22:00:30 petje kernel: cardbus1: CardBus bus on cbb1
Nov 16 22:00:30 petje kernel: pccard1: 16-bit PCCard bus on cbb1
Nov 16 22:00:30 petje kernel: pci_cfgintr: 0:11 INTB routed to irq 11
Nov 16 22:00:30 petje kernel: cbb1: [MPSAFE]
Nov 16 22:00:30 petje kernel: pcm0: ESS Technology Maestro-2E port 0xfc00-0xfcff irq 
11 at device 12.0 on pci0
Nov 16 22:00:30 petje 

Re: Re Regression: Playing QT files from mplayer stopped working in5.1

[Ted Lindgreen]

[Quoting Robert Watson, on Jun  9,  0:37, in Re: Re Regression: P ...]

 So one interesting question would be: if you ktrace on both 4.x and 5.x,
 do both pass in the bad value to close(), or is there something else in
 5.x triggering the use of negative file descriptor numbers?

I have no 4.x system with an old mplayer at hand at the moment, but
I can check it tomorrow if really necessary.

However, I guess that mplayer has had this error already, but that
a change in uthread_close.c as of May 31 has caused this problem
to show up now.
In particular: the unprotected usage of a very large value of fd
in _thread_fd_table[fd] leads to the segmentation violation.

Previously the systemcall just returned an error without getting
into a segmentation violation.

===
RCS file: uthread_close.c,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- uthread_close.c 2002/08/29 23:06:06 1.13
+++ uthread_close.c 2003/05/31 05:20:44 1.14
@@ -49,9 +49,11 @@
struct stat sb;
struct fd_table_entry   *entry;
 
-   if ((fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1])) {
+   if ((fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1]) ||
+   (_thread_fd_table[fd] == NULL)) {
/*
-* Don't allow silly programs to close the kernel pipe.
+* Don't allow silly programs to close the kernel pipe
+* and non-active descriptors.
 */
errno = EBADF;
ret = -1;
===

So, there is a problem and a question:

Problem:
  mplayer calls close() with a bogus value.

Question:
  shouldn't _close in uthread_close.c do some sanity check on fd
  before using it as an array index?

Regards,
-- ted
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Re Regression: Playing QT files from mplayer stopped working in5.1

[Ted Lindgreen]

[Quoting Alexander Leidinger, on Jun  9, 11:23, in Re: Re Regression: P ...]

shouldn't _close in uthread_close.c do some sanity check on fd
before using it as an array index?
 
 Try the attached patch.

 + if ((fd  0) || (fd = _thread_dtablesize) ||

This test looks perfectly right (should have been here already
when the _thread_fd_table[fd] reference was added, I guess).

I've tested it as cleanly as possible (make update, apply patch,
make world/kernel, and portupgrade -f multimedia/mplayer).
Is works fine and I haven't found any complications.
I think it's save to commit.

Thanks and regards,
-- ted
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re Regression: Playing QT files from mplayer stopped working in 5.1

[Ted Lindgreen]

 Since a short time (don't know exactly when it happened) it's not possible 
 anymore to play Quicktime files (.mov) with mplayer on 5.1-CURRENT. It has to 
 be a change in -CURRENT, I haven't updated mplayer.

I do not have the right fix, but the cause of the problem is
that in loader/win32.c at line 2077:

 2076 if (v1  2)
 2077 if (!close(v1a))

close is called with a ridiciously large value. In previous
FreeBSD releases this appearently did not cause a fatal problem,
but since a week or so mplayer aborts on it.

A stupid, but effective workaround is not to call close if v1
is too large, f.i.:

 2072 static int WINAPI expCloseHandle(long v1)
 2073 {
 2074 dbgprintf(CloseHandle(0x%x) = 1\n, v1);
 2075 /* do not close stdin,stdout and stderr */
 2076 if (v1  2  v1  128)
 2077 if (!close(v1))
 2078 return 0;
 2079 return 1;
 2080 }

Of course for the real fix one needs to delve deeper into mplayer
to find out where the large valued filedescriptor comes from.

-- ted
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

CPU slowdown using ACPI on a Toshiba Portege 7220cte

[Ted Lindgreen]

Some experiences with ACPI and APM on a Toshiba Portege 7220cte.
Interesting is the extreme CPU slow-down after suspend/resume
using ACPI.

Running current, (cvsup-ed Aug. 30).  A fixed-up ASL (similar to
the Tecra8200.asl diff from Mitsuru IWASAKI) is used with
acpi_dsdt_load=YES in /boot/loader.conf.  I have device apm in
the kernelconfig, so that I can easily switch between APM and ACPI
with hint.acpi.0.disable=1/0 in /boot/loader.conf.

With ACPI:

- At first everything seems to work allright, screen darkening,
  suspend/resume, batterie state, etc.
- However, it turns out that after a suspend/resume the system
  runs extremely slow: xengine, normally at 1800-1900 RPM,
  drops to 100-150 RPM. Sofar, I've only been able to restore
  the normal performance by rebooting.
- Connecting/removing power produces a kernel-logmessage:
system power profile changed to performance/economy
  but does not seem to have any other effect.
- Using Fn-F2, which normally switches between 3 power-states
  (low, user-setting, and high) does not work. The other Fn-Fx
  functions do work.
- A minor problem is that X-screen darkening does not switch
  off the backlight, whether or not DPMS is specified in the
  XF86Config. (Using Fn-F1 does turn off the backlight, so
  that's a fine workaround).
- I have used the standard and the fixed-up ASL, but I have seen
  no difference besides kernel logmessages like:
   ACPI: DSDT was overridden.

Using APM:
- Suspending in X freezes the system. I've not found any way
  out of that, other than hard resetting the system.
- Suspending in a vty-screen does works. So, having vidcontrol
  in rc.suspend/rc.resume makes suspend/resume work fine.
- There is no slowdown after suspend/resume.
- In contrast to ACPI above, the Fn-F2 works fine. In high-power
  mode xengine runs at 1800-1900 RPM, in low-power mode it slows
  down to 800-900 RPM. In user-setting it depend on what is set, but
  I have not been able to reproduce the extreme slow-down as when
  running ACPI.
- Like ACPI above, connecting/removing power produces a logmessage,
  but nothing else.
- Like ACPI above, X-screen darkening does not switch off the
  backlight, whether or not DPMS is specified.
- The apm command produces somewhat different output running
  APM, than running ACPI: with APM it shows the APM capabilities,
  with ACPI it says unknown. And when running on external power,
  onder APM it shows battery status and remaining time, while
  under ACPI this is unknown. However, when running on
  battery-power, status and life work both under APM and ACPI.

If I can do any other tests or try out anything, please ask.

Regards,
-- ted

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: CPU slowdown using ACPI on a Toshiba Portege 7220cte

[Ted Lindgreen]

[Quoting David Malone, on Sep  2, 12:22, in Re: CPU slowdown usi ...]

 On Mon, Sep 02, 2002 at 11:52:20AM +0200, Ted Lindgreen wrote:
  - Suspending in X freezes the system. I've not found any way
out of that, other than hard resetting the system.
 
 Could you try running acpidump before and after running X?  On my

Done: output of acpidump is identical before starting X, when running X,
and after stopping X.

-- ted


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Mousewheel problem after compiling X on CURRENT

[Ted Lindgreen]

After re-compiling XFree86-Server-4.2.0_3 on current, my mousewheel
(Logitech usb wheel mouse, connected via sysmouse) produces only
downward, or button-5, events on scrolling either up or down.

The problem appears to be the compilation of line 1508 in
/usr/ports/x11-servers/XFree86-4-Server/work/xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c

Changing this line:

 dz = ((char)(pBuf[5]  1) + (char)(pBuf[6]  1)) / 2;
into
 dz = ((signed char)(pBuf[5]  1) + (signed char)(pBuf[6]  1))  1;

works around the problem.

I copied this change from an earlier change to moused.c in
revision 1.56 to work around the same problem there.

-- ted



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message