panic: ata_dmasetup: transfer active on this device!
Hello, My laptop freeze *systematically* while resuming from suspend mode (ACPI) with recent (as of yesterday) kernels. I experienced the same problem with old (January 25th) kernels, but only from time to time (once every 3-5 times I would say) PS: there is no disk activity when i suspend the laptop (in the sense of: the disk led is off, and i stop all disk consuming activities). But seeing the panic message, it seems this is not actually true ;-) PPS: my world is not in sync with the new kernel, i'm a bit reluctant to sync with a kernel no more being able to resume. But perhaps this is the root of my problem Anybody else experiencing that ? Here is a backtrace: Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: bdwrite: buffer is not busy panic messages: --- panic: ata_dmasetup: transfer active on this device! syncing disks, buffers remaining... panic: bdwrite: buffer is not busy Uptime: 3h16m31s Dumping 255 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 239 dumping++; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 #1 0xc02b6222 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371 #2 0xc02b6483 in panic () at /usr/src/sys/kern/kern_shutdown.c:542 #3 0xc02fc43d in bdwrite (bp=0xc767d580) at /usr/src/sys/kern/vfs_bio.c:994 #4 0xc03b85e1 in ffs_update (vp=0xc28af920, waitfor=0) at /usr/src/sys/ufs/ffs/ffs_inode.c:125 #5 0xc03cdaef in ffs_fsync (ap=0xcd17dac8) at /usr/src/sys/ufs/ffs/ffs_vnops.c:314 #6 0xc03cca47 in ffs_sync (mp=0xc2731000, waitfor=2, cred=0xc0eb2e80, td=0xc04dd680) at vnode_if.h:612 #7 0xc031269b in sync (td=0xc04dd680, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:138 #8 0xc02b5e0c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280 #9 0xc02b6483 in panic () at /usr/src/sys/kern/kern_shutdown.c:542 #10 0xc019c763 in ata_dmastart (atadev=0x0, data=0x0, count=0, dir=0) at /usr/src/sys/dev/ata/ata-dma.c:254 #11 0xc019da21 in ad_transfer (request=0xc265e600) at /usr/src/sys/dev/ata/ata-disk.c:494 #12 0xc018f569 in ata_start (ch=0xc2602300) at /usr/src/sys/dev/ata/ata-all.c:678 #13 0xc019d3b2 in adstrategy (bp=0x0) at /usr/src/sys/dev/ata/ata-disk.c:300 #14 0xc027b0dc in g_disk_start (bp=0xc2a1b000) at /usr/src/sys/geom/geom_disk.c:225 #15 0xc027deb6 in g_io_schedule_down (tp=0xc0ec8000) at /usr/src/sys/geom/geom_io.c:427 #16 0xc027e338 in g_down_procbody () at /usr/src/sys/geom/geom_kern.c:111 #17 0xc02a0fd3 in fork_exit (callout=0xc027e310 g_down_procbody, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:871 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: ata_dmasetup: transfer active on this device!
On Wed, 05 Mar 2003, Ruslan Ermilov wrote: A known issue. Soren is working on that. Ok, I knew in fact that Soren was working on that. What strikes me is that, from what i see, the situation degrades from kernel to kernel. So I posted a backtrace in case of an interaction with other recent commits, beside Soren's work, not yet known But anyway, I will wait patiently until this issue is eradicated :) Thanks, - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What is the highest 'safe' CPUTYPE for intel?
On Fri, 06 Dec 2002, Cliff L. Biffle wrote: On Friday 06 December 2002 01:11 pm, leafy wrote: CPUTYPE=pentium4 is know to be broken. What is the known working highest CPUTYPE then? pentium3 or pentium2? Well, I know this isn't quite what you were asking, but I wanted to let the group know that the world and kernel seem quite stable using the athlon-tbird optimizations. Not to mention smokingly fast. Incidentally, I know this is a scary, scary thing, but how do I turn off the various debugging options that are on in GENERIC? I'd like to compile a hotrod kernel/world for testing...is it just a matter of commenting out DEBUG=-g? You need mainly to comment the INVARIANTS and WITNESS options, and to remove the debug options from malloc (see most notably the a j flags for malloc.conf) UPDATING should give you more info on that subject I think. Cheers, - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OpenOffice and FreeBSD 5.0-Current
On Sun, 24 Nov 2002, a wrote: Hi I am running FreeBSD 5.0-CURRENT (22 Nov 22:52 CET) I did a download of a precompiled OpenOffice 1.0.1_4 package (it is for FreeBSD Current) and installed that one with pkg_add. Ok, that one went fine. But after that, i was not able to start OpenOffice. I get an Segmentation fault, and thats it. Have you procfs mounted ? if not you should: this is mandatory to use openoffice (/proc is not mounted by default in the -current land) Regards, - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problems reading vmcores
On Sat, 31 Aug 2002, Kris Kennaway wrote: I'm having difficulty reading vmcore images with gdb (either the system version or the port). (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 But you need to specify the -k flag to gdb to use it against kernel dumps, I'm sure it will give much better results :) regards, - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problems reading vmcores
On Sat, 31 Aug 2002, Kris Kennaway wrote: On Sat, Aug 31, 2002 at 03:00:43PM -0700, Kris Kennaway wrote: On Sat, Aug 31, 2002 at 11:42:01PM +0200, Yann Berthier wrote: On Sat, 31 Aug 2002, Kris Kennaway wrote: I'm having difficulty reading vmcore images with gdb (either the system version or the port). (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 But you need to specify the -k flag to gdb to use it against kernel dumps, I'm sure it will give much better results :) Oops, pasted the wrong thing: gohan10# gdb -k kernel.debug vmcore.0 GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... /a/vmcore.0: Undefined error: 0. Also gohan10# bin/gdb52 -k kernel.debug vmcore.0 GNU gdb 5.2 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-portbld-freebsd5.0... /a/vmcore.0: Bad file descriptor. Sorry, I can't help you: I never uncountered this behavior, and certainly not on the recent kernel dumps I have under the hood. PS: I must admit I was a bit surprised by your initial post, I have classified it in the 'he must be aspleep / under caffeined ' category :) - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1759] Re: Call for testers: acpica-unix-20020815
On Wed, 28 Aug 2002, Mitsuru IWASAKI wrote: 1) Fix the ASL so that it compiles without errors or warnings 2) Override the BIOS version of the table with your new one. (I don't know how this is done on FreeBSD, someone else will have to help you. Attached patches will fix the ASL. It seems that no ... :( In fact, enabling the printer port in the bios, as you requested in another post, have the nice side effect to silence the can't fetch resources for \\_SB_.PCI0.FNC0.PRT_ - AE_BAD_DATA warning. I have now anyway: full suspend / resume with acpi, and routed interrupts so I can now use my embedded wi card, those are two big steps forward. Thanks to all for this ! - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
On Tue, 27 Aug 2002, Mitsuru IWASAKI wrote: Hi, Could you put the following lines into /boot/loader.conf and send dmesg output again? debug.acpi.layer=ACPI_ALL_COMPONENTS debug.acpi.level=ACPI_LV_ERROR Of course, here we go :) [sent privately to not spam the lists with my dump files] On Mon, 26 Aug 2002, Mitsuru IWASAKI wrote: FYI, I have now a can't fetch resources for \\_SB_.PCI0.FNC0.PRT_ - AE_BAD_DATA with acpica-unix-20020815 during boot. I'd like to make sure if AE_BAD_DATA error occurred w/ previous versions (acpica-unix-20020725, 20020611, 20020404...) ? Or first time w/ acpica-unix-20020815 ? This error did not happened with previous versions of acpi Hmmm... OK, I put your full ASL at: http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Tecra8200.asl?rev=1.1content-type=text/x-cvsweb-markupcvsroot=freebsd-jp Thanks a lot. I must apologize though, I had the same error with previous versions of acpi (I should have checked, sorry, I confounded 2 laptops) Thanks, - yann Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #29: Tue Aug 27 21:35:25 CEST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TAZ Preloaded elf kernel /boot/kernel/kernel at 0xc06a7000. Preloaded elf module /boot/kernel/usb.ko at 0xc06a70a8. Preloaded elf module /boot/kernel/ums.ko at 0xc06a7150. Preloaded elf module /boot/kernel/vga_pci.ko at 0xc06a71f8. Preloaded elf module /boot/kernel/acpi.ko at 0xc06a72a4. ACPI_DEBUG: set 'ACPI_ALL_COMPONENTS' ACPI_DEBUG: set 'ACPI_LV_ERROR' ACPI debug layer 0xfff debug level 0x8 Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 847427840 Hz CPU: Pentium III/Pentium III Xeon/Celeron (847.43-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 267780096 (261504K bytes) avail memory = 252694528 (246772K bytes) Pentium Pro MTRR support enabled netsmb_dev: loaded Using $PIR table, 9 entries at 0xc00f0300 npx0: math processor on motherboard npx0: INT 16 interface acpi0: TOSHIB 750 on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 pcib1: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib2 vga_pci0: Generic PCI VGA mem 0xf7ff8000-0xf7ff,0xf800-0xf9ff,0xfbc0-0xfbff,0xfc00-0xfdff irq 11 at device 0.0 on pci1 pcib3: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib3 pcm0: Yamaha DS-1E (YMF754) port 0xdf3c-0xdf3f,0xdf40-0xdf7f mem 0xf7df8000-0xf7df irq 11 at device 7.0 on pci2 fxp0: Intel Pro/100 Ethernet port 0xdec0-0xdeff mem 0xf7df7000-0xf7df7fff irq 11 at device 8.0 on pci2 fxp0: Ethernet address 00:00:39:ee:60:38 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcib3: device is routed to IRQ 11 pcic0: TI PCI-1410 PCI-CardBus Bridge irq 11 at device 12.0 on pci2 pcic0: PCI Memory allocated: 0xf7d0 pcic0: TI12XX PCI Config Reg: [pwr save][pci only] pccard0: PC Card 16-bit bus (classic) on pcic0 pcic1: Toshiba ToPIC95B PCI-CardBus Bridge irq 11 at device 13.0 on pci2 pcic1: PCI Memory allocated: 0xf7d01000 pccard1: PC Card 16-bit bus (classic) on pcic1 pcic2: Toshiba ToPIC95B PCI-CardBus Bridge irq 11 at device 13.1 on pci2 pcic2: PCI Memory allocated: 0xf7d02000 pccard2: PC Card 16-bit bus (classic) on pcic2 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 ATA100 controller port 0xcff0-0xcfff at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xcf80-0xcf9f irq 11 at device 31.2 on pci0 usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.00, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. uhci1: Intel 82801BA/BAM (ICH2) USB controller USB-B port 0xcf60-0xcf7f irq 11 at device 31.4 on pci0 usb1: Intel 82801BA/BAM (ICH2) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: simple comms at device 31.6 (no driver attached) atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
On Tue, 27 Aug 2002, Moore, Robert wrote:
This looks like the (in)famous implicit return problem that is in some
Toshiba ASL files.
Method(_CRS) {
CRS_(0x10)
}
This does NOT actually return a value and the ASL code is incorrect. It has
to be:
Method(_CRS) {
Return (CRS_(0x10))
}
The iASL compiler generates warnings for all instances of this erroneous
code.
Thanks a lot for your input. What is the best way for me to verify
this ?
- yann
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Call for testers: acpica-unix-20020815
On Mon, 26 Aug 2002, Mitsuru IWASAKI wrote: I have a Dell Latitude C640 and my screen won't come back after a suspend. The machine works fine besides that. OK, I think this is not related with ACPI CA code update. If that was not clear, it also didn't work before. understood. I meant that ACPI CA code changes won't solve the individual device problems in many cases. If you have this problem w/ X running, and don't have w/o X, please try attached patches. It's unrelated to X. Other ideas? How about this one? http://people.freebsd.org/~iwasaki/acpi/vga_pci-20020228.tar.gz This simply set PCI_POWERSTATE_D0 for VGA device on wakeup. It seems to solve the acpi resume on my laptop (Toshiba Tecra 8200) Thanks, - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is it just me or has -current suddenly got massively unstable?
On Tue, 23 Jul 2002, Peter Wemm wrote: [snip] Thanks for the independent confirmation. Here's a workaround patch that you might like to try: --- kern_thread.c 17 Jul 2002 23:43:55 - 1.8 +++ kern_thread.c 22 Jul 2002 23:31:06 - @@ -198,7 +198,7 @@ thread_zone = uma_zcreate(THREAD, sizeof (struct thread), thread_ctor, thread_dtor, thread_init, thread_fini, - UMA_ALIGN_CACHE, 0); + UMA_ALIGN_CACHE, UMA_ZONE_NOFREE); } /* I haven't paniced yet with that change. :-) For some unknown reason, selwakeup() is dereferencing pointers to threads that have long gone and the backing store has been freed. The patch above is a bandaid, not a solution. It basically prevents threads ever being freed back to the general pool, even though everything here supposedly does not need that. (unlike struct proc and socket, for example). Thanks a lot, patch applied, and all is going fine. Peter: I knew you would come up with a solution :) (well, feel free to call it bandaid, but it solves the problem BTW) - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is it just me or has -current suddenly got massively unstable?
On Mon, 22 Jul 2002, Peter Wemm wrote: It might be just me because I swapped an ISA 'si' card for a PCI version, but the problems I've been seeing are pretty spectacular. I'm regularly seeing the following panics: - selwakeup() taking fatal traps (always while running postfix/smtpd, presumably this is happening during the traditional 'select collision' window - the locking looks rather suspect there too). This killed my box 3 times today alone. eg: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc44a01b4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc027f945 current process = 4078 (smtpd) trap number = 12 Same here: 2 panics with a kernel from today while running postfix/smtpd. Sorry, I have no more info to give for now though - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mouse wheel.
On Sun, 07 Jul 2002, Thomas Ugland wrote: On Sun, 2002-07-07 at 20:10, Scott Long wrote: On Sun, Jul 07, 2002 at 07:59:50PM +0200, Thomas Ugland wrote: I'm not sure if this is current releated or XFree releated, but I'm giving it a go here. I updated from -current Jun 27, to a Jul 07 version today, and since that fixed the problem with compiling XFree86-4-Server and libs, I recompiled those and upgraded those. (new'er port versions). Now my mouse wheel only works in one 'direction'. If I try to use the wheel, it looks like it emits the same signal, even if I move it up or down. (It scrolls down). It used to work before I did the upgrades, just cant figure out where the problem is.. (mwheel works correctly in other OS'es). This happened to me too, and I thought I was going crazy. When I disabled moused and let X talk directly to the mouse, the wheel worked correctly. When I turned on moused debugging, it showed that it was receiving the correct events from the mouse, so I can only assume that the problem is higher up. I don't use the mouse daemon normally, but tried it out to see if it would work while using it. But I still had the same problem, so I'm stuck with the half functioning mouse wheel :) Not sure if it will work for you, but I should use '-z 4 5' with moused to overcome this problem. Ciao, - yann. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current installworld breakage
On Thu, 18 Apr 2002, Eric Brunner-Williams in Portland Maine wrote: # uname -a FreeBSD nic-naa.net 4.5-STABLE FreeBSD 4.5-STABLE #0: Wed Apr 17 10:35:32 EDT 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/ABENAKI i386 [snip ...] install -c -s -o root -g wheel -m 555 chflags /bin install -c -o root -g wheel -m 444 chflags.1.gz /usr/share/man/man1 === usr.bin/chpass [ ! -e /usr/bin/chpass ] || chflags noschg /usr/bin/chpass || true *** Signal 12 Stop in /usr/src/usr.bin/chpass. *** Error code 1 Stop in /usr/src/usr.bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 You need to install and boot on the new kernel before the installworld : eaccess(2) is now used by test, but is not supported by your running kernel. BTW, the error code say precisely that : non existent syscall. - yann -- [EMAIL PROTECTED] -*- HSC -*- http://www.hsc.fr/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI timecounter help needed!
On Mon, 25 Feb 2002, Poul-Henning Kamp wrote: Machines with ACPI timecounters will now print 10 lines at boot when the timer is tested. If you are lucky you will see ten times something like: ACPI timer looks GOOD min = 3, max = 3, width = 1 That means that you have well implemented ACPI timer. If you are unlucky, one, several or all 10 lines will be marked as BAD. Please send me an email with these 10 lines and the output of pciconf -l -v for your machine. I'm am interested in reports both from good and bad machines. If your machine starts to mysteriously hang after this commit, try to increase the 15 to 31 in this line: } while (u1 u2 || u2 u3 || (u3 - u1) 15); Hello, FYI, the increase from 15 to 31 in acpi_timer.c was needed for me to have my kernel boot with acpi loaded (ie no hang during boot). Anyway, my system died after 2 hours or so of use, after a bunch of: Feb 25 18:05:34 ogoun kernel: ACPI-0954: *** Error: AcpiEvGpeDispatch: Unable to queue handler for GPE[0], disabling event Feb 25 18:05:35 ogoun kernel: -0185: *** Error: UtAllocate: Could not allocate size 18 Feb 25 18:05:35 ogoun kernel: ACPI-0188: *** Error: ExAllocateNameString: Could not allocate size 24 I have no debug information, but I can provide some if needed. BTW, it's the first time I see this with ACPI, I had no problem before with it. I was even able to suspend / resume my laptop (Toshiba Tecra 8000), which seems not everyone's case :) Regards, yann. -- [EMAIL PROTECTED] -*- HSC -*- http://www.hsc.fr/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildkernel target breaks on pcivar.h
On Wed, 13 Dec 2000, Sheldon Hearn wrote: On Tue, 12 Dec 2000 11:10:43 MST, Warner Losh wrote: I just tried it here and it seemed to work... I also built a kernel last night too. Given that I've had one "works here" and no "I see it too", it's probably safe to assume that I'm doing something stupid. Ok, so I'm afraid I'm doing the same stupid thing, because I'm bitten by the pcivar.h thing during my kernel builds, too :( Regards, Yann. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
