FYI: ACPI buffer overflow
-- Forwarded Message -- Subject: Re: MacBookPro 5,1 Date: Sunday 17 October 2010, 15:47:56 From: Hans Petter Selasky hsela...@c2i.net To: freebsd-a...@freebsd.org CC: linux-a...@vger.kernel.org Hi, CC'ing the Linux guys, hence I belive you are using the same ACPI code like in FreeBSD. It appears that when a string is present in the extended interrupt descriptor (6.4.3.6, ACPIspec30.pdf), then this is not handled correctly, meaning that the precomputed buffer space when encoding to AML, is incorrect and that data is written beyond the destination buffer! The error is catched on a MacBookPro 5,1 and is visible if you zero-pad all ACPI allocations to 4096 bytes, and verify that the freed buffer is not written beyond the allocation. Also the Extended interrupt descriptor must be the last element encoded in the AML. The quick patch is to disable these elements. I tried to figure out why this happens, but this particular handling in the code looks very obfuscated to me. src/sys/contrib/dev/acpica %svk diff === resources/rsmisc.c == --- resources/rsmisc.c (revision 213698) +++ resources/rsmisc.c (local) @@ -311,6 +311,8 @@ case ACPI_RSC_SOURCEX: + break; /* RSC_SOURCEX is broken */ + /* * Optional ResourceSource (Index and String). This is the more * complicated case used by the Interrupt() macro @@ -537,6 +539,8 @@ case ACPI_RSC_SOURCEX: + break; /* RSC_SOURCEX is broken */ + /* * Optional ResourceSource (Index and String) */ Any comments are welcome! --HPS - ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
bge0 does not work anymore
I am using FreeBSD 9.0-CURRENT (amd64) on a DELL Latitude D630. With todays kernel the driver 'bge0' does not work anymore. With kernel from October 9th it does. The network controller is a Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x00a002; CHIP ID 0xa0002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E. The entry in /etc/rc.conf is 'ifconfig_bge0=DHCP. Does anyone else observe this behaviour? Is there something I can try? Thanks in advance, Rainer Hurling ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bge0 does not work anymore
At 09:06 AM 10/17/2010, Rainer Hurling wrote: I am using FreeBSD 9.0-CURRENT (amd64) on a DELL Latitude D630. With todays kernel the driver 'bge0' does not work anymore. With kernel from October 9th it does. The network controller is a Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x00a002; CHIP ID 0xa0002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E. The entry in /etc/rc.conf is 'ifconfig_bge0=DHCP. Does anyone else observe this behaviour? Is there something I can try? Thanks in advance, Rainer Hurling Same here, the last time it worked was Oct 14. with Current source. uname -a : FreeBSD pozo.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Thu Oct 14 14:13:47 PDT 2010 r...@pozo.com:/sys/i386/compile/COMPAQ i386 i have ifconfig_bge0=inet 192.168.0.5 netmask 255.255.255.0 in rc.conf == || n...@pozo.com || || Ph. (415) 681-6235 || == -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Setting up IPv6 in /etc/rc.conf
On Sat, Oct 16, 2010 at 3:15 AM, Mark Murray ma...@freebsd.org wrote: Bjoern A. Zeeb writes: On Fri, 15 Oct 2010, Mark Murray wrote: Alexey Shuvaev writes: gifconfig_gif0_ipv6=2001:::::2 2001:::::1 prefixlen 128 I suppose you should prefix it with inet6 keyword. There are 2 examples in rc.conf (search for Sample IPv6). Ah! It didn't occur to me that I might need TWO inet6's! I'll give that a go when I play with this again tomorrow. It's just one inet6; put there what you would pass to ifconfig on the command line. The fact that ifconfig defaults to inet is the problem leading to more confusion. In which case, I'm back to square one. What should work doesn't. I have the necessary commands in /etc/rc.local to bring up IPv6. I think the samples in defaults/rc.conf will be more clear soon. Cool! Thanks. You have a few syntax errors in your rc.conf, try these adjustments and everything should work (as it works for me on a recent CURRENT.) gif_interfaces=gif0 gifconfig_gif0=192.168.0.2 11.22.33.44 ifconfig_gif0_ipv6=inet6 2001:::::2 2001:::::1 prefixlen 128 ipv6_defaultrouter=2001:::::1 -- Chris - http://twitter.com/chrisattack http://chrisattack.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Is nvidia-driver 256.53 expected to work on -current?
Y'all will probably recall that I had a lot of problems with the nvidia-driver, and video generally (esp. flash) on i386 -current. Well I haven't had any problems recently because I haven't been using FreeBSD. :) But I have things I need to catch up on, so here's what I did: 1. Bought a new hard drive, and installed a snapshot of amd64 -current (this was actually done a while ago). 2. Yesterday I started configuring stuff, updated my source and ports trees, rebuilt the world, customized the kernel, etc. 3. With a newly up to date system I built the latest version of the nvidia-driver port, and started using it. My experience with it has been exactly the same as older versions of the port on previous versions of i386 -current. Sometimes it runs fine for a while, but when I exit the window manager (openbox) the system hangs and I never get back to the command prompt. (I'm using startx to try and minimize the number of variables.) Sometimes it will work fine for an hour, maybe two, then the whole thing just hangs. All the stuff is displayed on the screen, but the mouse won't move, I can't zap X, or even switch to the console. I have to power off. This is particularly frustrating because I haven't even loaded flash (or for that matter firefox) yet. Windows and linux (ubuntu, with the nvidia driver) work great on this same hardware, so I'm pretty thoroughly convinced that the problem is with freebsd/current somewhere. In addition to the -current partition I also installed amd64 8.1-RELEASE so I'll give that a go next, but I wanted to ask here first if anyone else was having problems on -current. Doug -- Breadth of IT experience, and| Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is nvidia-driver 256.53 expected to work on -current?
Doug Barton wrote: Y'all will probably recall that I had a lot of problems with the nvidia-driver, and video generally (esp. flash) on i386 -current. Well I haven't had any problems recently because I haven't been using FreeBSD. :) But I have things I need to catch up on, so here's what I did: 1. Bought a new hard drive, and installed a snapshot of amd64 -current (this was actually done a while ago). 2. Yesterday I started configuring stuff, updated my source and ports trees, rebuilt the world, customized the kernel, etc. 3. With a newly up to date system I built the latest version of the nvidia-driver port, and started using it. My experience with it has been exactly the same as older versions of the port on previous versions of i386 -current. Sometimes it runs fine for a while, but whe n I exit the window manager (openbox) the system hangs and I never get back to the command prompt. (I'm using startx to try and minimize the number of variables.) Sometimes it will work fine for an hour, maybe two, then the whole thing just hangs. All the stuff is displayed on the screen, but the mouse won't move, I can't zap X, or even switch to the console. I have to power off. This is particularly frustrating because I haven't even loaded flash (or for that matter firefox) yet. Windows and linux (ubuntu, with the nvidia driver) work great on this same hardware, so I'm pretty thoroughly convinced that the problem is with freebsd/current somewhere. In addition to the -current partition I also installed amd64 8.1-RELEASE so I'll give that a go next, but I wanted to ask here first if anyone else was having problems on -current. Doug I am currently running the Nvidia 195 driver on amd64 9 - current from the ports tree. It works without problems. When I tried to compile the 256 driver, it would not compile and said that it was not meant to work with 9 - current. Hope this helps. Ralph Ellis ralphell...@netscape.ca ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is nvidia-driver 256.53 expected to work on -current?
On Sun Oct 17 10, Ralph Ellis wrote: Doug Barton wrote: Y'all will probably recall that I had a lot of problems with the nvidia-driver, and video generally (esp. flash) on i386 -current. Well I haven't had any problems recently because I haven't been using FreeBSD. :) But I have things I need to catch up on, so here's what I did: 1. Bought a new hard drive, and installed a snapshot of amd64 -current (this was actually done a while ago). 2. Yesterday I started configuring stuff, updated my source and ports trees, rebuilt the world, customized the kernel, etc. 3. With a newly up to date system I built the latest version of the nvidia-driver port, and started using it. My experience with it has been exactly the same as older versions of the port on previous versions of i386 -current. Sometimes it runs fine for a while, but whe n I exit the window manager (openbox) the system hangs and I never get back to the command prompt. (I'm using startx to try and minimize the number of variables.) Sometimes it will work fine for an hour, maybe two, then the whole thing just hangs. All the stuff is displayed on the screen, but the mouse won't move, I can't zap X, or even switch to the console. I have to power off. This is particularly frustrating because I haven't even loaded flash (or for that matter firefox) yet. Windows and linux (ubuntu, with the nvidia driver) work great on this same hardware, so I'm pretty thoroughly convinced that the problem is with freebsd/current somewhere. In addition to the -current partition I also installed amd64 8.1-RELEASE so I'll give that a go next, but I wanted to ask here first if anyone else was having problems on -current. Doug I am currently running the Nvidia 195 driver on amd64 9 - current from the ports tree. It works without problems. When I tried to compile the 256 driver, it would not compile and said that it was not meant to work with 9 - current. i'm running 256.52 on HEAD (amd64) without any issues. the 260.X drivers all freze my computer when i exit X. it's quite easy to work around the isse that the nvidia drivers fail to compile on HEAD. simply change the line #if __FreeBSD_version = 90 in src/nv-freebsd.h to #if __FreeBSD_version = 100. cheers. alex Hope this helps. Ralph Ellis ralphell...@netscape.ca -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is nvidia-driver 256.53 expected to work on -current?
On Sun, Oct 17, 2010 at 15:55, Doug Barton do...@freebsd.org wrote: Windows and linux (ubuntu, with the nvidia driver) work great on this same hardware, so I'm pretty thoroughly convinced that the problem is with freebsd/current somewhere. In addition to the -current partition I also installed amd64 8.1-RELEASE so I'll give that a go next, but I wanted to ask here first if anyone else was having problems on -current. I am running 256.53 on amd64 current (r213747). I don't use anything linux (the module isn't loaded) and built the driver with all options off except ACPI_PM. My custom kernel does not have device agp. I use XFCE 4, don't really run anything graphically intense, and shutdown at night. I haven't had any problems, but IIRC from your past threads, the issues sort of build over time so I simply may not be aggravating the problem enough. The system is a HP Pavillion dv6405us laptop with a GeForce Go 6150. This is a pretty crappy card, even in Windows (the whole system was $500 3 years ago - it was one of those computers that supposedly was Vista Ready but could barely boot it), so I doubt I am gaining much over vesa though. -- Rob Farmer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is nvidia-driver 256.53 expected to work on -current?
On Sun, Oct 17, 2010 at 16:18, Ralph Ellis ralphell...@netscape.ca wrote: I am currently running the Nvidia 195 driver on amd64 9 - current from the ports tree. It works without problems. When I tried to compile the 256 driver, it would not compile and said that it was not meant to work with 9 - current. Some necessary support was removed recently, but it has be re-added. See r213739. -- Rob Farmer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is nvidia-driver 256.53 expected to work on -current?
On 18/10/2010 10:18, Ralph Ellis wrote: Doug Barton wrote: Y'all will probably recall that I had a lot of problems with the nvidia-driver, and video generally (esp. flash) on i386 -current. Well I haven't had any problems recently because I haven't been using FreeBSD. :) But I have things I need to catch up on, so here's what I did: 1. Bought a new hard drive, and installed a snapshot of amd64 -current (this was actually done a while ago). 2. Yesterday I started configuring stuff, updated my source and ports trees, rebuilt the world, customized the kernel, etc. 3. With a newly up to date system I built the latest version of the nvidia-driver port, and started using it. My experience with it has been exactly the same as older versions of the port on previous versions of i386 -current. Sometimes it runs fine for a while, but whe n I exit the window manager (openbox) the system hangs and I never get back to the command prompt. (I'm using startx to try and minimize the number of variables.) Sometimes it will work fine for an hour, maybe two, then the whole thing just hangs. All the stuff is displayed on the screen, but the mouse won't move, I can't zap X, or even switch to the console. I have to power off. This is particularly frustrating because I haven't even loaded flash (or for that matter firefox) yet. Windows and linux (ubuntu, with the nvidia driver) work great on this same hardware, so I'm pretty thoroughly convinced that the problem is with freebsd/current somewhere. In addition to the -current partition I also installed amd64 8.1-RELEASE so I'll give that a go next, but I wanted to ask here first if anyone else was having problems on -current. Doug I am currently running the Nvidia 195 driver on amd64 9 - current from the ports tree. It works without problems. When I tried to compile the 256 driver, it would not compile and said that it was not meant to work with 9 - current. Hope this helps. Ralph Ellis ralphell...@netscape.ca I have not had any trouble with the new Nvidia drivers at all - but I'm running i386, so it might be an amd64 issue. No compilation issues at all, no problems running, switching to VT etc. (and yes, I had the same problems as Doug a while ago) Kernel and world are not from today, but fairly recent though: FreeBSD 9.0-CURRENT #48 r213491M: Thu Oct 7 See: (--) PCI:*(0:1:0:0) 10de:06e4:1458:349c nVidia Corporation G98 [GeForce 8400 GS] rev 161, Mem @ 0xf200/16777216, 0xe000/268435456, 0xf000/33554432, I/O @ 0x2100/128, BIOS @ 0x/65536 (II) extmod will be loaded by default. (II) dbe will be loaded by default. (II) glx will be loaded. This was enabled by default and also specified in the config file. (II) record will be loaded by default. (II) dri will be loaded by default. (II) dri2 will be loaded by default. (II) LoadModule: glx (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so (II) Module glx: vendor=NVIDIA Corporation compiled for 4.0.2, module version = 1.0.0 Module class: X.Org Server Extension (II) NVIDIA GLX Module 256.53 Fri Aug 27 20:49:59 PDT 2010 (II) Loading extension GLX (II) LoadModule: extmod (II) Loading /usr/local/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor=X.Org Foundation compiled for 1.7.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: dbe (II) Loading /usr/local/lib/xorg/modules/extensions/libdbe.so (II) Module dbe: vendor=X.Org Foundation compiled for 1.7.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: record (II) Loading /usr/local/lib/xorg/modules/extensions/librecord.so (II) Module record: vendor=X.Org Foundation compiled for 1.7.5, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: dri (II) Loading /usr/local/lib/xorg/modules/extensions/libdri.so (II) Module dri: vendor=X.Org Foundation compiled for 1.7.5, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: dri2 (II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so (II) Module dri2: vendor=X.Org Foundation compiled for 1.7.5, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: nvidia (II) Loading /usr/local/lib/xorg/modules/drivers/nvidia_drv.so (II) Module nvidia: vendor=NVIDIA Corporation compiled
Re: Is nvidia-driver 256.53 expected to work on -current?
On 10/17/2010 4:49 PM, Rob Farmer wrote: I am running 256.53 on amd64 current (r213747). I don't use anything linux (the module isn't loaded) and built the driver with all options off except ACPI_PM. My custom kernel does not have device agp. Hmm. I had all the options off except linux. I'll try with your combination and see if that improves things. Thanks, Doug -- Breadth of IT experience, and| Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bge0 does not work anymore
my last known usable kernel revision is r213813 with r213920, leds are extinguished when executing dhclient On Mon, Oct 18, 2010 at 2:07 AM, Manfred Antar n...@pozo.com wrote: At 09:06 AM 10/17/2010, Rainer Hurling wrote: I am using FreeBSD 9.0-CURRENT (amd64) on a DELL Latitude D630. With todays kernel the driver 'bge0' does not work anymore. With kernel from October 9th it does. The network controller is a Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x00a002; CHIP ID 0xa0002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E. The entry in /etc/rc.conf is 'ifconfig_bge0=DHCP. Does anyone else observe this behaviour? Is there something I can try? Thanks in advance, Rainer Hurling Same here, the last time it worked was Oct 14. with Current source. uname -a : FreeBSD pozo.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Thu Oct 14 14:13:47 PDT 2010 r...@pozo.com:/sys/i386/compile/COMPAQ i386 i have ifconfig_bge0=inet 192.168.0.5 netmask 255.255.255.0 in rc.conf == || n...@pozo.com || || Ph. (415) 681-6235 || == -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is nvidia-driver 256.53 expected to work on -current?
On Sun, Oct 17, 2010 at 11:32:00PM +, Alexander Best wrote: i'm running 256.52 on HEAD (amd64) without any issues. the 260.X drivers all freze my computer when i exit X. it's quite easy to work around the isse that the nvidia drivers fail to compile on HEAD. simply change the line #if __FreeBSD_version = 90 in src/nv-freebsd.h to #if __FreeBSD_version = 100. Or install from ports, which also patch the driver to support -CURRENT. ./danfe ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps
Hey,
I am not 100% sure this is the right list to approach with this problem but
let's try this one.
So I am trying to use dtrace on the previously mentioned system, I followed
the usual kernel rebuild process using the following wiki:
http://wiki.freebsd.org/DTrace
Dtrace works fine and I am able to trace the kernel.[1]
My problem is: I can't trace any user land application including PostgreSQL
and Ruby.
I added the following lines to the /etc/make.conf as it is written in the
wiki:
STRIP=
CFLAGS+=-fno-omit-frame-pointer
I compiled both of the softwares and trying to trace them but there are no
bindings in the dtrace -l ouput
# dtrace -l | grep -i ruby
i might have overlooked something important but not sure what.
Any help is appreciated. Pls cc my email since i am not on this list.
Thank you in advance.
I.
1.
[r...@freebsd9 ~]# uname -a
FreeBSD freebsd9 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Fri Oct 8 21:09:20 UTC
2010 r...@freebsd9:/usr/obj/usr/src/sys/DTRACE amd64
[r...@freebsd9 ~]# kldstat
Id Refs AddressSize Name
1 26 0x8010 f49bb0 kernel
21 0x81212000 ad8 dtraceall.ko
31 0x81213000 4a59 profile.ko
4 11 0x81218000 3e2f opensolaris.ko
53 0x8121c000 3db0 cyclic.ko
69 0x8122 13af4b dtrace.ko
71 0x8135b000 fce0 systrace.ko
81 0x8136b000 4128 sdt.ko
91 0x8137 44b8 lockstat.ko
101 0x81375000 b94e fasttrap.ko
111 0x81381000 61ab fbt.ko
121 0x81388000 4a67 dtnfsclient.ko
131 0x8138d000 4118 dtmalloc.ko
[r...@freebsd9 ~]#
[r...@freebsd9 ~]# cat d.d
vfs:namecache:enter:done
{
@distribution = quantize(strlen((string)arg1));
}
[r...@freebsd9 ~]# dtrace -s d.d
dtrace: script 'd.d' matched 1 probe
^C
value - Distribution - count
2 | 0
4 |@@@ 1
8 |@5
16 | 0
--
the sun shines for all
http://blog.l1x.me
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
2TB HDD = TIMEOUT - READ_DMA48 ....
As another body that today bought a 2TB HDD, I can confirm the presence of kernel messages relating to READ_DMA48 with FreeBSD 8. The drive in question is a Hitachi one, not a Samsung. Is it the drive, system or operating system? Well, the drive works without any such error with both Windows 7 and NetBSD 5.1. So it looks like the finger is now pointing as a bug in FreeBSD... and if it is fixed in HEAD then it needs to be merged into the branch for 8.1. Darren ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Netdump for review and testing -- preliminary version
On Fri, 15 Oct 2010, Robert N. M. Watson wrote: On 15 Oct 2010, at 20:39, Garrett Cooper wrote: But there are already some cases that aren't properly handled today in the ddb area dealing with dumping that aren't handled properly. Take for instance the following two scenarios: 1. Call doadump twice from the debugger. 2. Call doadump, exit the debugger, reenter the debugger, and call doadump again. Both of these scenarios hang reliably for me. I'm not saying that we should regress things further, but I'm just noting that there are most likely a chunk of edgecases that aren't being handled properly when doing dumps that could be handled better / fixed. Even thinking about calling doadump even once from within the debugger is an error. I was asleep when the similar error for panic was committed, and this error has propagated. Debuggers should use a trampoline to call the any function, not the least so that they can be used to debug the any function without the extra complications to make themself reentrant. I think gdb has always used a trampoline for this outside of the kernel. Not sure what it does within the kernel, but it would have even larger problems than in userland finding a place for the trampoline. In the kernel, there is the additional problem of keeping control while the any function is run. Other CPUs must be kept stopped and interrupts must be kept masked, except when the any function really needs other CPUs or unmasked interrupts. Single stepping also needs this and doesn't have it (other CPUs and interrupt handlers can run and execute any number of instructions while you are trying to execute a single one). All ddb commands that change the system state are really non-ddb commands that should use an external function via a trampoline. Panicing and dumping are just the largest ones, so they are the most impossible to do correctly as commands and the most in need of ddb to debug them. Right: one of the points I've made to Attilio is that we need to move to a more principled model as to what sorts of things we allow in various kernel environments. The early boot is a special environment -- so is the debugger, but the debugger on panic is not the same as the debugger when you can continue. Likewise, the crash dumping code is special, but also not the same as the debugger. Right now, exceptional behaviour to limit hangs/etc is done inconsistently. We need to develop a set of principles that tell us what is permitted in what contexts, and then use that to drive design decisions, normalizing what's there already. ENONUNIXEDITOR. Format not recovered. panic() from within a debugger (or a fast interrupt handler, or a fast interrupt handler that has trappeded to the debugger by request...) is, although an error, not too bad since panic() must be prepared to work starting from the any state anyway, and as you mention it doesn'tneed to be able to return (except for RESTARTABLE_PANICS, which makes things impossibly difficult). Continuing from a debugger is feasible mainly because in the usual case the system state is not changed (except for time-dependent things). If you use it to modify memory or i/o or run one of its unsafe commands then you have to be careful. This is not dissimilar to what we do with locking already, BTW: we define a set of kernel environments (fast interrupt handlers, non-sleepable threads, sleepable thread holding non-sleepable locks, etc), and based on those principles prevent significant sources of instability that might otherwise arise in a complex, concurrent kernel. We need to apply the same sort of approach to handling kernel debugging and crashing. Locking has imposed considerable discipline, which if followed by panic() would should how wrong most of the things done by panic() are -- it will hit locks, but shouldn't even be calling functions that have locks, since such functions expect their locks to work. The rules for fast interrupt handlers are simple and mostly not followed. They are that a fast interrupt handler may not access any state not specially locked by its subsystem. This means that they may not call any other subsystem or any upper layer except the null set of ones documented to be safe to call. In practice, this means not calling the any function, but it is necessary for atomic ops, bus space accesses, and a couple of scheduling functions to be safe enough. BTW, my view is that except in very exceptional cases, it should not be possible to continue after generating a dump. Dumps often cause disk controllers to get reset, which may leave outstanding I/O in nasty situations. Unless the dump device and model is known not to interfere with operation, we should set state indicating that the system is non-continuable once a dump has occurred. It might be safe if the system reinitialized everything. Too hard for just dumping, but it is needed after resume anyway. So the following could reasonably work: -
Re: 2TB HDD = TIMEOUT - READ_DMA48 ....
Hi, On Wed, Oct 13, 2010 at 3:59 PM, Darren Reed darr...@fastmail.net wrote: As another body that today bought a 2TB HDD, I can confirm the presence of kernel messages relating to READ_DMA48 with FreeBSD 8. The drive in question is a Hitachi one, not a Samsung. Is it the drive, system or operating system? Well, the drive works without any such error with both Windows 7 and NetBSD 5.1. So it looks like the finger is now pointing as a bug in FreeBSD... and if it is fixed in HEAD then it needs to be merged into the branch for 8.1. Have you tried the new ahci(4) driver? What controller are you using by the way? Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 2TB HDD = TIMEOUT - READ_DMA48 ....
on 14/10/2010 01:59 Darren Reed said the following: As another body that today bought a 2TB HDD, I can confirm the presence of kernel messages relating to READ_DMA48 with FreeBSD 8. Sounds like sector number possibly overflowing 32-bit integer. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
