how to detach ata w/ new ATA_CAM layer?
How am I suppose to detach an ata controller with the new ATA_CAM layer? On the old layer when pulling drives like CF cards, I would always detach, to ensure that nothing would be going on when I pulled the drive, but a quick glance through camcontrol's man page I don't see a way to do that. Anyone have a clue? Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
Le 30.10.2011 01:31, Daniel O'Connor a écrit : On 30/10/2011, at 24:40, David Marec wrote: But, now running FreeBSD 9, I get new usb/devd behavior issues. First, the ulpt module is always loaded. Is there any elegant way to get rid of this 'self loading' behavior, except to remove it from /boot/modules ? Anyway, it sounds like HPLIP is now working with the ulpt module loaded. I'm not sure what would load it automatically - it may be built into the kernel though. Anyway, as you say it should work with ulpt loaded anyway. I'm quite sure it was not; I mean, if ulpt.ko has been manually removed from /boot/modules, this module is not loaded when I plugged in the printer. And, how to handle them with devd ? I have a similar problem.. [ ATTACH statement in devd.conf] However this doesn't seem to work anymore, it certainly used to.. :( Yep, sounds like it is the same here. I tried adding the system, subsystem type parts and changing device-name to cdev but no luck.. I also tried to add entries into /usr/local/etc/devd/devd.conf instead of /etc/devd.conf. And some more unsuccessful attempts, like changing system/subsystem and others, as you did. -- David Marec, mailto:david.ma...@davenulle.org http://user.lamaiziere.net/david/Site http://www.diablotins.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: how to detach ata w/ new ATA_CAM layer?
On 30/10/2011, at 17:22, John-Mark Gurney wrote: How am I suppose to detach an ata controller with the new ATA_CAM layer? On the old layer when pulling drives like CF cards, I would always detach, to ensure that nothing would be going on when I pulled the drive, but a quick glance through camcontrol's man page I don't see a way to do that. Anyone have a clue? If it's not mounted I don't think it matters. However, you could try using camcontrol eject nnn on the device. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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 -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: [9.0-RC1 FreeBSD] [amd64] buildworld fails on building lib/libss with CLANG
This is a bug in clang, llvm supports amdfam10 but the clang counterpart wasnt updated. Thank you for the report! On Sat, Oct 29, 2011 at 03:44:30PM +0200, David Marec wrote: hi list, Running FreebSD 9.0 RC-1, the make buildworld processing failed on the following error on its attempt to build 'lib/libssp': === gnu/lib/libssp/libssp_nonshared (obj,depend,all,install) rm -f .depend CC='clang' mkdep -f .depend -a-DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp/libs sp_nonshared/.. -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/g cclibs/libssp -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcc libs/include -DPIC /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/ gcclibs/libssp/ssp-local.c clang -O2 -pipe -march=native -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp/libssp_n onshared/.. -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gccl ibs/libssp -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gccli bs/include -fPIC -DPIC -fvisibility=hidden -std=gnu99 -fstack-protector -c /usr /src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-loca l.c error: unknown target CPU 'amdfam10' *** Error code 1 Stop in /usr/src/gnu/lib/libssp/libssp_nonshared. *** Error code 1 The sources files were updated yesterday evening. I did not try to process this with gcc yet. -- David Marec, mailto:david.ma...@davenulle.org http://user.lamaiziere.net/david/Site http://www.diablotins.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 ___ 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: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
Le 29.10.2011 21:58, Jilles Tjoelker a écrit :
On Sat, Oct 29, 2011 at 04:10:46PM +0200, David Marec wrote:
So, what's should be the news groupuser's rights required by HPLIP/cups
on FreeBSD 9 ?
And, how to handle them with devd ?
Use devfs rules.
Doing this, device rights become unreliable.
[devfsrules_mybox=10]
add path 'fd0*' mode 660
What are the user rights that the devfs interface should set ?
mode 0666 for all usb entries ('usb*') ?
- ugen stands for generic usb support. -
Setting 'cups:hplip' rights for 'ugen[0-9]' doesn't do the trick
anymore: HPlip needs the suitable rights on 'usb/x.y.*' too, which are
now targeted by the ugenx.y links.
--
David Marec, mailto:david.ma...@davenulle.org
http://user.lamaiziere.net/david/Site
http://www.diablotins.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: [9.0-RC1 FreeBSD] [amd64] buildworld fails on building lib/libss with CLANG
On Sun, Oct 30, 2011 at 08:28:42AM +0100, Roman Divacky wrote: This is a bug in clang, llvm supports amdfam10 but the clang counterpart wasnt updated. Thank you for the report! fwiw, I fixed it in clang r143305, so in the next import this will work just fine :) roman ___ 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: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
It would be nice, If somebody would write updated manual documenting whole process of setting up hplip. In past, I could only get it to the point of printing test pages (sigh...) Before release preferably? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Freebsd-9-amd64-USB-HPLIP-what-s-the-new-right-way-to-manage-hplip-usb-plugged-printers-running-Free9-tp4948737p4949780.html Sent from the freebsd-current mailing list archive at Nabble.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: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
Or just extend hplip section in handbook. http://www.freebsd.org/doc/handbook/printing-lpd-alternatives.html It could be roughly based upon this: http://freebsd.kde.org/howtos/hplip.php -- View this message in context: http://freebsd.1045724.n5.nabble.com/Freebsd-9-amd64-USB-HPLIP-what-s-the-new-right-way-to-manage-hplip-usb-plugged-printers-running-Free9-tp4948737p4949796.html Sent from the freebsd-current mailing list archive at Nabble.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: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
Le 30.10.2011 10:04, Jakub Lach a écrit : Or just extend hplip section in handbook. http://www.freebsd.org/doc/handbook/printing-lpd-alternatives.html It should be a good idea, I agree. Especially in this case, where nobody now knows how and where HPLIP rights have to be settled. It could be roughly based upon this: http://freebsd.kde.org/howtos/hplip.php This one is really outdated. It seems that `hpiod` and `hpssd` are not useful in any way, and, mostly, the use of devfs stands for :setting rights for everyone (or close to) on USB system. -- Et je vais rater ma béarnaise si je continue à répondre. http://user.lamaiziere.net/david/Site http://www.diablotins.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: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
Le 30.10.2011 08:28, David Marec a écrit :
I have a similar problem..
Le 30.10.2011 08:28, David Marec a écrit :
I have a similar problem..
A new behavior occurs since I updated the world kernel this morning.
`devd` now executes the entry for hplip, as I defined it inside
/usr/local/etc/devd/devd.conf.
But, with `ulpt0` forwarded as device node.
That sounds ok since ulpt has been loaded and attached by devd (or some
other stuff, i dont know);
What comes now as the major issue.
hold it... since the update, ulpt keeps on being quiet while the printer
gets plugged..
So, I changed my script to:
#!/bin/sh
#
# set up /dev/$1.$2.* to cups:hplip -rw-rw---
#
logger HPLIP printer found on $1.$2
logger setting suitable rights for $1.$2
/usr/sbin/chown cups:hplip /dev/usb/$1.$2.[0-9]
/bin/chmod g+rw /dev/usb/$1.$2.[0-9]
...and used the nomatch key instead of the attach key into
/usr/local/etc/devd/devd.conf
nomatch 100 {
match vendor 0x03f0;
match product 0x4712;
action /root/sbin/ugen-hdle $port $devaddr;
};
'looks like it works .
--
David Marec, mailto:david.ma...@davenulle.org
http://user.lamaiziere.net/david/Site
http://www.diablotins.org/
A new behavior occurs since i update the world kernel this morning.
`devd` now executes the entry for hplip, as I defined it inside
/usr/local/etc/devd/devd.conf.
But, with `ulpt0` forwarded as device node.
That sounds ok since ulpt has been loaded and attached by devd (or some
other stuff, i dont know);
What comes now as the major issue.
And, up to now, ulpt keep on being stuck.
So, i change my script to
#!/bin/sh
#
# set up /dev/$1.$2.* to cups:hplip -rw-rw---
#
logger HPLIP printer found on $1.$2
logger setting suitable rights for $1.$2
/usr/sbin/chown cups:hplip /dev/usb/$1.$2.[0-9]
/bin/chmod g+rw /dev/usb/$1.$2.[0-9]
And uses nomatch instead of attach into /usr/local/etc/devd/devd.conf
nomatch 100 {
match vendor 0x03f0;
match product 0x4712;
action /root/sbin/ugen-hdle $port $devaddr;
};
seems to work finally.
--
Délicieuse cette béarnaise.
http://user.lamaiziere.net/david/Site
http://www.diablotins.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
In-kernel API for tasks, which could wait?
Hello, Current. It was explained to me, that all three GEOM threads (up, down and ctl) could not execute code, which should sleep. It looks sound for up and down, but not for ctl, but it is so now. So, I have question: what should I do if I need to perofrm ONE action, which could block for some time (for example, open file or create ALQ)? I could create thread for this. But it looks strange and too heavy: create thread to call one function once. Maybe, kernel has some API to postpone such task to one, always-running idle thread? -- // Black Lion AKA Lev Serebryakov l...@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: In-kernel API for tasks, which could wait?
On Sun, Oct 30, 2011 at 06:54:51PM +0400, Lev Serebryakov wrote: So, I have question: what should I do if I need to perofrm ONE action, which could block for some time (for example, open file or create ALQ)? I could create thread for this. But it looks strange and too heavy: create thread to call one function once. Maybe, kernel has some API to postpone such task to one, always-running idle thread? See taskqueue(9). On the other hand, waiting for the enqueued task to finish is itself the sleepable action. pgpei4uyxuJ1X.pgp Description: PGP signature
Re: In-kernel API for tasks, which could wait?
Hello, Kostik. You wrote 30 октября 2011 г., 19:03:39: See taskqueue(9). On the other hand, waiting for the enqueued task to finish is itself the sleepable action. I'll not wait for finishing. Task will put result to volatile atomic field, and it's all. -- // Black Lion AKA Lev Serebryakov l...@serebryakov.spb.ru ___ 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: [9.0-RC1 FreeBSD] [amd64] buildworld fails on building lib/libss with CLANG
Le 30.10.2011 08:52, Roman Divacky a écrit : On Sun, Oct 30, 2011 at 08:28:42AM +0100, Roman Divacky wrote: This is a bug in clang, llvm supports amdfam10 but the clang counterpart wasnt updated. Thank you for the report! fwiw, I fixed it in clang r143305, so in the next import this will work just fine :) Thank you for getting involved. -- David Marec, mailto:david.ma...@davenulle.org http://user.lamaiziere.net/david/Site http://www.diablotins.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
x86: how to get maximum possible CPU frequency ?
Assume we are running on the single-package X86 machine, how to answer the question: what is the possible maximum tsc frequency ? I read tsc_levels_changed(), is it the right way to query the max frequency for the general purpose driver ? If yes, could the code be made into the utility function ? BTW, there is some usage of the barriers in sysctl_machdep_tsc_freq() that I do not understand. When the read from tsc_freq is performed with the acquire semantic ? Why there are two store barriers when tsc_freq and tsc_timecounter.tc_frequency are written ? I would think that a single barrier on the last write is enough, but is it needed at all ? pgpG9zwXR7qbc.pgp Description: PGP signature
Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
On Sunday 30 October 2011 01:31:21 Daniel O'Connor wrote: I'm not sure what would load it automatically - it may be built into the kernel though. Anyway, as you say it should work with ulpt loaded anyway. Hi, ulpt is autoloaded by /etc/devd/usb.conf --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
Re: lockup during probing because of a memory stick
On Saturday 29 October 2011 23:26:29 deeptec...@gmail.com wrote: If a USB mass storage device was connected when the computer was turned on or reset and the device is left connected, then the system locks up somewhere around the ``acpi0: A M I OEMXSDT on motherboard'' line (not exactly deterministically at that line). Otherwise (if the device is connected or disconnected just before FreeBSD started booting, or if the device is nowhere near the computer for the whole booting process), the system boots fine. I'm using a -CURRENT kernel. Hi, I don't recall this case happening some time ago. But now, this happens with and without the NEW_PCIB option. I mention this because ``acpi0: A M I OEMXSDT on motherboard'' is shortly followed by ``acpi0: reservation of 0, a (3) failed'', whatever that means. Have you tried to turn off USB legacy support in the BIOS? ACPI involves some USB BIOS code most likely which is causing the crash. I think this is maybe not a FreeBSD issue, but if you can binary search the revisions to find exactly what commit broke your system, them I can look further at your issue. --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
Re: [9.0-RC1 FreeBSD] [amd64] buildworld fails on building lib/libss with CLANG
On 2011-10-30 17:55, David Marec wrote:
Le 30.10.2011 08:52, Roman Divacky a écrit :
On Sun, Oct 30, 2011 at 08:28:42AM +0100, Roman Divacky wrote:
This is a bug in clang, llvm supports amdfam10 but the clang counterpart
wasnt updated. Thank you for the report!
fwiw, I fixed it in clang r143305, so in the next import this will work just
fine :)
Thank you for getting involved.
I pulled Roman's fixes into head in r226951. This will be merged to
stable/9 later, but if you want to try it out in the meantime, please
use the attached diff.
Index: contrib/llvm/tools/clang/lib/Basic/Targets.cpp
===
--- contrib/llvm/tools/clang/lib/Basic/Targets.cpp (revision 226948)
+++ contrib/llvm/tools/clang/lib/Basic/Targets.cpp (working copy)
@@ -1282,6 +1282,7 @@ class X86TargetInfo : public TargetInfo {
CK_K8SSE3,
CK_Opteron,
CK_OpteronSSE3,
+CK_AMDFAM10,
/// This specification is deprecated and will be removed in the future.
/// Users should prefer \see CK_K8.
@@ -1381,6 +1382,7 @@ class X86TargetInfo : public TargetInfo {
.Case(k8-sse3, CK_K8SSE3)
.Case(opteron, CK_Opteron)
.Case(opteron-sse3, CK_OpteronSSE3)
+ .Case(amdfam10, CK_AMDFAM10)
.Case(x86-64, CK_x86_64)
.Case(geode, CK_Geode)
.Default(CK_Generic);
@@ -1441,6 +1443,7 @@ class X86TargetInfo : public TargetInfo {
case CK_K8SSE3:
case CK_Opteron:
case CK_OpteronSSE3:
+case CK_AMDFAM10:
case CK_x86_64:
return true;
}
@@ -1459,12 +1462,10 @@ void X86TargetInfo::getDefaultFeatures(llvm::Strin
Features[ssse3] = false;
Features[sse41] = false;
Features[sse42] = false;
+ Features[sse4a] = false;
Features[aes] = false;
Features[avx] = false;
- // LLVM does not currently recognize this.
- // Features[sse4a] = false;
-
// FIXME: This *really* should not be here.
// X86_64 always has SSE2.
@@ -1561,6 +1562,11 @@ void X86TargetInfo::getDefaultFeatures(llvm::Strin
setFeatureEnabled(Features, sse3, true);
setFeatureEnabled(Features, 3dnowa, true);
break;
+ case CK_AMDFAM10:
+setFeatureEnabled(Features, sse3, true);
+setFeatureEnabled(Features, sse4a, true);
+setFeatureEnabled(Features, 3dnowa, true);
+break;
case CK_C3_2:
setFeatureEnabled(Features, mmx, true);
setFeatureEnabled(Features, sse, true);
@@ -1604,6 +1610,8 @@ bool X86TargetInfo::setFeatureEnabled(llvm::String
else if (Name == avx)
Features[avx] = Features[sse] = Features[sse2] = Features[sse3] =
Features[ssse3] = Features[sse41] = Features[sse42] = true;
+else if (Name == sse4a)
+ Features[sse4a] = true;
} else {
if (Name == mmx)
Features[mmx] = Features[3dnow] = Features[3dnowa] = false;
@@ -1630,6 +1638,8 @@ bool X86TargetInfo::setFeatureEnabled(llvm::String
Features[aes] = false;
else if (Name == avx)
Features[avx] = false;
+else if (Name == sse4a)
+ Features[sse4a] = false;
}
return true;
@@ -1826,6 +1836,11 @@ void X86TargetInfo::getTargetDefines(const LangOpt
Builder.defineMacro(__k8__);
Builder.defineMacro(__tune_k8__);
break;
+ case CK_AMDFAM10:
+Builder.defineMacro(__amdfam10);
+Builder.defineMacro(__amdfam10__);
+Builder.defineMacro(__tune_amdfam10__);
+break;
case CK_Geode:
Builder.defineMacro(__geode);
Builder.defineMacro(__geode__);
___
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: lockup during probing because of a memory stick
On Sun, Oct 30, 2011 at 9:27 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Saturday 29 October 2011 23:26:29 deeptec...@gmail.com wrote: I don't recall this case happening some time ago. But now, this happens with and without the NEW_PCIB option. I mention this because ``acpi0: A M I OEMXSDT on motherboard'' is shortly followed by ``acpi0: reservation of 0, a (3) failed'', whatever that means. ACPI involves some USB BIOS code most likely which is causing the crash. I think this is maybe not a FreeBSD issue, but if you can binary search the revisions to find exactly what commit broke your system, them I can look further at your issue. Actually, I've just tested a pre-compiled 7.3-RELEASE GENERIC kernel, and the lockup also occurs there. Have you tried to turn off USB legacy support in the BIOS? Hmm. Interesting, only a combination of the following result in the lockup: - Legacy USB Support: Auto (enable if and only if a USB device is connected) or Enabled, - USB 2.0 Controller: Enabled, - USB 2.0 Controller Mode: HiSpeed, - the memory stick is plugged in when the computer starts, and - the memory stick is plugged in when FreeBSD boots. Note that, to reproduce the lockup, it is not sufficient to just have the said BIOS settings (Legacy USB Support: Enabled, etc.), it is also required that the mutherboard recognize the memory stick when the computer starts, and to have the memory stick connected when FreeBSD boots. (If I disable 2.0 support, or set the speed to FullSpeed, or disable legacy support, or do not have the stick plugged in when the computer starts, or do not have the stick plugged in when FreeBSD boots, then the lockup does not occur.) But Windows XP does not produce any lockups in the case where FreeBSD does. Furthermore, in all cases, the memory stick is usable from FreeBSD if FreeBSD boots successfully. So why should I expect FreeBSD to lock up? ___ 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: lockup during probing because of a memory stick
On Oct 30, 2011, at 6:47 PM, deeptec...@gmail.com wrote: On Sun, Oct 30, 2011 at 9:27 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Saturday 29 October 2011 23:26:29 deeptec...@gmail.com wrote: I don't recall this case happening some time ago. But now, this happens with and without the NEW_PCIB option. I mention this because ``acpi0: A M I OEMXSDT on motherboard'' is shortly followed by ``acpi0: reservation of 0, a (3) failed'', whatever that means. ACPI involves some USB BIOS code most likely which is causing the crash. I think this is maybe not a FreeBSD issue, but if you can binary search the revisions to find exactly what commit broke your system, them I can look further at your issue. Actually, I've just tested a pre-compiled 7.3-RELEASE GENERIC kernel, and the lockup also occurs there. Have you tried to turn off USB legacy support in the BIOS? Hmm. Interesting, only a combination of the following result in the lockup: - Legacy USB Support: Auto (enable if and only if a USB device is connected) or Enabled, - USB 2.0 Controller: Enabled, - USB 2.0 Controller Mode: HiSpeed, - the memory stick is plugged in when the computer starts, and - the memory stick is plugged in when FreeBSD boots. Note that, to reproduce the lockup, it is not sufficient to just have the said BIOS settings (Legacy USB Support: Enabled, etc.), it is also required that the mutherboard recognize the memory stick when the computer starts, and to have the memory stick connected when FreeBSD boots. (If I disable 2.0 support, or set the speed to FullSpeed, or disable legacy support, or do not have the stick plugged in when the computer starts, or do not have the stick plugged in when FreeBSD boots, then the lockup does not occur.) But Windows XP does not produce any lockups in the case where FreeBSD does. Furthermore, in all cases, the memory stick is usable from FreeBSD if FreeBSD boots successfully. So why should I expect FreeBSD to lock up? Vendor hacks and limited testing on other OSes is the most likely cause, if it's not a bug within FreeBSD. Just to narrow things down a bit... 1. Are there are BIOS updates for your motherboard? 2. Do you have ACPI 2.0 support enabled in the BIOS (I was reminded of this because some ASUS MBs default this setting to off -- which may or may not cause problems with FreeBSD)? -Garrett ___ 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: lockup during probing because of a memory stick
On Mon, Oct 31, 2011 at 3:01 AM, Garrett Cooper yaneg...@gmail.com wrote: On Oct 30, 2011, at 6:47 PM, deeptec...@gmail.com wrote: On Sun, Oct 30, 2011 at 9:27 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Saturday 29 October 2011 23:26:29 deeptec...@gmail.com wrote: I don't recall this case happening some time ago. But now, this happens with and without the NEW_PCIB option. I mention this because ``acpi0: A M I OEMXSDT on motherboard'' is shortly followed by ``acpi0: reservation of 0, a (3) failed'', whatever that means. ACPI involves some USB BIOS code most likely which is causing the crash. I think this is maybe not a FreeBSD issue, but if you can binary search the revisions to find exactly what commit broke your system, them I can look further at your issue. Actually, I've just tested a pre-compiled 7.3-RELEASE GENERIC kernel, and the lockup also occurs there. Have you tried to turn off USB legacy support in the BIOS? Hmm. Interesting, only a combination of the following result in the lockup: - Legacy USB Support: Auto (enable if and only if a USB device is connected) or Enabled, - USB 2.0 Controller: Enabled, - USB 2.0 Controller Mode: HiSpeed, - the memory stick is plugged in when the computer starts, and - the memory stick is plugged in when FreeBSD boots. Note that, to reproduce the lockup, it is not sufficient to just have the said BIOS settings (Legacy USB Support: Enabled, etc.), it is also required that the mutherboard recognize the memory stick when the computer starts, and to have the memory stick connected when FreeBSD boots. (If I disable 2.0 support, or set the speed to FullSpeed, or disable legacy support, or do not have the stick plugged in when the computer starts, or do not have the stick plugged in when FreeBSD boots, then the lockup does not occur.) But Windows XP does not produce any lockups in the case where FreeBSD does. Furthermore, in all cases, the memory stick is usable from FreeBSD if FreeBSD boots successfully. So why should I expect FreeBSD to lock up? Vendor hacks and limited testing on other OSes is the most likely cause, if it's not a bug within FreeBSD. Just to narrow things down a bit... 1. Are there are BIOS updates for your motherboard? Yes, and I have the latest non-beta version (v1019 (dated 2004-11-08) for P4P800 mutherboards). 2. Do you have ACPI 2.0 support enabled in the BIOS (I was reminded of this because some ASUS MBs default this setting to off -- which may or may not cause problems with FreeBSD)? Yes (also, I've just tried disabling ACPI 2.0, with no luck). ___ 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
