Re: AHCI timeouts - 8.1-PRERELEASE
Hi. Phil wrote: Is it expected behaviour that ahci performs a time-out during boot, even though camcontrol indicates success? This is on 8.1-PRERELEASE csup'ed today. I've enclosed dmesg, camcontrol and pciconf information. The timeout is approximately 12 to 14 seconds for each connected disk-drive. If I run with only usb devices, there are no timeouts. The following dmesg is when I connect two HDD's on a VIA SN18000 motherboard, and the BIOS has ahci selected, i.e. not IDE nor RAID. # pciconf -lv | grep -A 4 ahci ah...@pci0:0:15:0: class=0x010601 card=0x62871106 chip=0x62871106 rev=0x20 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT8251 AHCI Controller' class = mass storage subclass = SATA It seems like timeout during Port Multiplier probe. I don't have such chip to test it, but I can see that Linux disables PMP and NCQ support for it. You may try it in different combinations by adding to respective line in device list in the beginning of the ahci.c quirks AHCI_Q_NOPMP and AHCI_Q_NONCQ. Instead of AHCI_Q_NONCQ (if it is needed for you) you may try to set AHCI_Q_EDGEIS. Report me please about the result. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Buzzing snd_emu10kx enabled card with r206173
On 30/05/2010 08:31, Garrett Cooper wrote: On Wed, May 26, 2010 at 12:05 PM, Mark Stapper st...@mapper.nl wrote: On 25/05/2010 20:05, Garrett Cooper wrote: On Tue, May 25, 2010 at 3:06 AM, Mark Stapper st...@mapper.nl wrote: On 18/05/2010 08:14, Mark Stapper wrote: On 18/05/2010 00:22, Garrett Cooper wrote: On Mon, May 17, 2010 at 11:21 AM, Mark Stapper st...@mapper.nl wrote: I have the same problem. I'll try compiling the driver in the kernel. FWIW I've compiled the driver into the kernel for several iterations now and it works like a champ, so there's something with the sound subsystem that isn't jiving properly when loading from modules... HTH, -Garrett Thanks for the info. I've noticed that when I load the kernel module at startup (by adding it to loader.conf) chances of it working improve. If I load it afterwards, the nice huff puff sounds come out of my speaker again. Compiling the new and improved kernel today. Thanks for your help. I compiled the emu10kx driver into the kernel. That seemed to work, but now the hissing and buzzing is back. I really don't know what is going on anymore.. Any thoughts? What modules have you compiled and loaded? Kernel config and kldstat output pasted below [...] Everything I saw there appeared sane (it would have been nice to grab the -v output from kldstat, but that's ok...). Let's try doing the following: 1. Add `options EMU_MTX_DEBUG' to your kernconf. 2. Add set the sysctl: dev.emu10kx.0.debug=1 . Let's see if anything changes... Also, if you could provide some more hardware stats (say dmesg.boot and/or devinfo -v) and version stats (I already know that you're running amd64 from your kernel config) for the OS that would be helpful as well. I'm going to try upgrading my kernel and I'll try these steps as well. The locking between this driver and some other sound drivers isn't exactly the same (interestingly enough this driver uses Giant locking for some bits, while the ich one doesn't), and there were some past bugs with other branches of *BSD's drivers related to pci bus commands, etc; the other BSDs have dramatically different soundsystems -- I assume the old school soundsystem, s.t. the issues are probably not the same. Thanks, -Garrett I'm building the new kernel as we e-mail. The option EMU_MTX_DEBUG doesn't seem to excist thought. Used SND_DEBUG instead. here are the requested outputs: nexus0 apic0 ram0 acpi0 cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.C000 acpi_perf0 powernow0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.C001 acpi_perf1 powernow1 cpufreq1 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.C002 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.C003 acpi_button0 pnpinfo _HID=PNP0C0C _UID=0 at handle=\_SB_.PWRB pcib0 pnpinfo _HID=PNP0A08 _UID=1 at handle=\_SB_.PCI0 pci0 unknown pnpinfo vendor=0x10de device=0x02f4 subvendor=0x10de subdevice=0x02f0 class=0x05 at slot=0 function=0 unknown pnpinfo vendor=0x10de device=0x02fa subvendor=0x10de subdevice=0x02fa class=0x05 at slot=0 function=1 unknown pnpinfo vendor=0x10de device=0x02fe subvendor=0x10de subdevice=0x02fe class=0x05 at slot=0 function=2 unknown pnpinfo vendor=0x10de device=0x02f8 subvendor=0x10de subdevice=0x02f8 class=0x05 at slot=0 function=3 unknown pnpinfo vendor=0x10de device=0x02f9 subvendor=0x10de subdevice=0x02f9 class=0x05 at slot=0 function=4 unknown pnpinfo vendor=0x10de device=0x02ff subvendor=0x10de subdevice=0x02ff class=0x05 at slot=0 function=5 unknown pnpinfo vendor=0x10de device=0x027f subvendor=0x10de subdevice=0x027f class=0x05 at slot=0 function=6 unknown pnpinfo vendor=0x10de device=0x027e subvendor=0x10de subdevice=0x027e class=0x05 at slot=0 function=7 pcib1 pnpinfo vendor=0x10de device=0x02fb subvendor=0x10de subdevice=0x class=0x060400 at slot=4 function=0 handle=\_SB_.PCI0.XVRA pci1 vgapci0 pnpinfo vendor=0x10de device=0x0193 subvendor=0x10de subdevice=0x0420 class=0x03 at slot=0 function=0 vgapm0 nvidia0 drm0 unknown pnpinfo vendor=0x10de device=0x0369 subvendor=0x10de subdevice=0xcb84 class=0x05 at slot=8 function=0 isab0 pnpinfo vendor=0x10de device=0x0360 subvendor=0x10de subdevice=0xcb84 class=0x060100 at slot=9 function=0 handle=\_SB_.PCI0.LEG0 isa0 orm0 sc0 vga0 atkbdc0 atkbd0 psm0 ppc0 uart1 unknown pnpinfo vendor=0x10de device=0x0368 subvendor=0x10de subdevice=0xcb84 class=0x0c0500 at slot=9 function=1 handle=\_SB_.PCI0.SMB0 unknown pnpinfo vendor=0x10de
freebsd-update with non-GENERIC kerrnel
I find the way freebsd-update handles a system that runs a non-GENERIC
kernel less than helpful.
It is doing this:
| fourquid.3:~$ sudo freebsd-update upgrade -r 8.1-BETA1
| Password:
| Looking up update.FreeBSD.org mirrors... 3 mirrors found.
| Fetching metadata signature for 8.0-RELEASE from update5.FreeBSD.org... done.
| Fetching metadata index... done.
| Fetching 2 metadata patches.. done.
| Applying metadata patches... done.
| Inspecting system... done.
|
| WARNING: This system is running a fourquid kernel, which is not a
| kernel configuration distributed as part of FreeBSD 8.0-RELEASE.
| This kernel will not be updated: you MUST update the kernel manually
| before running /usr/sbin/freebsd-update install.
|
| The following components of FreeBSD seem to be installed:
| src/base src/bin src/cddl src/contrib src/crypto src/etc src/games
| src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue
| src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin
| world/base world/catpages world/dict world/doc world/games world/info
| world/lib32 world/manpages world/proflibs
|
| The following components of FreeBSD do not seem to be installed:
| kernel/generic
|
| Does this look reasonable (y/n)? n
I do have the kernel sources installed, so I would like to have them
updated. I don't even mind to have a GENERIC kernel temporarily
installed, until I compile my own (fortunately, they are not that
different).
It is nice that it tells me that I MUST update the kernel manually,
but it gives me no help in getting the sources and doing that. (Can the
new kernel even be built in all cases with old tools? NetBSD offers a
nice cross-building system for that.)
For my previous update to 8.0-RELEASE-p2 I patched freebsd-update simply
to think that my kernel *is* GENERIC,
--- /usr/sbin/freebsd-update2009-12-22 17:16:01.0 +0100
+++ /tmp/freebsd-update 2010-05-11 10:35:05.0 +0200
@@ -631,6 +631,7 @@
# we're running an SMP kernel. This mis-identification is a bug
# which was fixed in 6.2-STABLE.
KERNCONF=`uname -i`
+ KERNCONF=GENERIC
if [ ${KERNCONF} = SMP-GENERIC ]; then
KERNCONF=SMP
fi
but that seems riskier as updates get a bit bigger.
The official way seems to be to reboot using GENERIC, upgrade (with a
reboot with new GENERIC), rebuild new CUSTOM kernel, reboot again. At
least the first reboot ought to be avoided...
-Olaf.
--
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd-update with non-GENERIC kerrnel
freebsd-update made for only GENERIC kerndel due to binary diff patches.
After you rebuild world and kernel you'll be not able to apply binary
patches.
2010/6/1 Olaf Seibert o.seib...@cs.ru.nl
I find the way freebsd-update handles a system that runs a non-GENERIC
kernel less than helpful.
It is doing this:
| fourquid.3:~$ sudo freebsd-update upgrade -r 8.1-BETA1
| Password:
| Looking up update.FreeBSD.org mirrors... 3 mirrors found.
| Fetching metadata signature for 8.0-RELEASE from update5.FreeBSD.org...
done.
| Fetching metadata index... done.
| Fetching 2 metadata patches.. done.
| Applying metadata patches... done.
| Inspecting system... done.
|
| WARNING: This system is running a fourquid kernel, which is not a
| kernel configuration distributed as part of FreeBSD 8.0-RELEASE.
| This kernel will not be updated: you MUST update the kernel manually
| before running /usr/sbin/freebsd-update install.
|
| The following components of FreeBSD seem to be installed:
| src/base src/bin src/cddl src/contrib src/crypto src/etc src/games
| src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue
| src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin
| world/base world/catpages world/dict world/doc world/games world/info
| world/lib32 world/manpages world/proflibs
|
| The following components of FreeBSD do not seem to be installed:
| kernel/generic
|
| Does this look reasonable (y/n)? n
I do have the kernel sources installed, so I would like to have them
updated. I don't even mind to have a GENERIC kernel temporarily
installed, until I compile my own (fortunately, they are not that
different).
It is nice that it tells me that I MUST update the kernel manually,
but it gives me no help in getting the sources and doing that. (Can the
new kernel even be built in all cases with old tools? NetBSD offers a
nice cross-building system for that.)
For my previous update to 8.0-RELEASE-p2 I patched freebsd-update simply
to think that my kernel *is* GENERIC,
--- /usr/sbin/freebsd-update2009-12-22 17:16:01.0 +0100
+++ /tmp/freebsd-update 2010-05-11 10:35:05.0 +0200
@@ -631,6 +631,7 @@
# we're running an SMP kernel. This mis-identification is a bug
# which was fixed in 6.2-STABLE.
KERNCONF=`uname -i`
+ KERNCONF=GENERIC
if [ ${KERNCONF} = SMP-GENERIC ]; then
KERNCONF=SMP
fi
but that seems riskier as updates get a bit bigger.
The official way seems to be to reboot using GENERIC, upgrade (with a
reboot with new GENERIC), rebuild new CUSTOM kernel, reboot again. At
least the first reboot ought to be avoided...
-Olaf.
--
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: IPMI Console: No luck once OS is booted
PaulFr wrote: Larry Rosenman wrote: On Sun, 10 Aug 2008, David Duchscher wrote: On Aug 10, 2008, at 10:22 AM, Larry Rosenman wrote: I don't have that IPMI card but I can say we have other cards of theirs working. I would make sure the card is at the latest version of firmware. The AOC-SIMSO(+) card was not detected correctly until we upgraded. I don't know why the card is going away when freebsd boots since I assume you are on the dedicated LAN interface with its own IP address. Yes. It's not going away, just doesn't see the key strokes. Looking through your dmesg file, I don't see a USB keyboard being attached. On my system, the virtual keyboard is a USB keyboard. ukbd0:Peppercon AG Multidevice, class 0/0, rev 2.00/0.01, addr 2 on uhub3 kbd2 at ukbd0 Good catch. When I set it to disable USB Mass Storage when no image is loaded, the ukbd came alive, and I'm typing this on the IPMI Console. Thanks! -- DaveD Larry I have a similar problem as you describe in this posting using a SuperMicro X8SIL-F motherboard with onboard IPMI. The console redirection works fine during boot until the OS (pfSense - FreebSD 7.2 Release p5) boots and then I can't enter anything from the keyboard. Screen output is OK. I notice there is also no usb keyboard being detected during boot - instead a usb mass storage device is added. Thus I suspect I am seeing the same issue as you did. When you mentioned When I set it to disable USB Mass Storage when no image is loaded, the ukbd came alive... how did you do that? Can you try to boot FreeBSD 8 or 7.3 live system, not installer? I had same problem with 7.2 installer, but IPMI works with installed 7.2 GENERIC kernel from HDD. 8.0 installer and installed GENERIC kernel works fine in both case. So I think there is some bug in older releases. Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: nfe0 loses network connectivity (8.0-RELEASE-p2)
I do have the same problem with my nic but I do seem to get no IP address from time to time after reboot. Ifconfig nfe0 down follow by dhclient nfe0 couple of times does usually the trick. Will look at the mbuf counters next times it looses connection in the middle of an afpd session tho. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Adding a second device to my zfs pool
I am having problems getting my head around a small ZFS issue. If I build a fileserver, say for example a 20 x 1TB disk server with zfs and create a file server, it can work fine and I can have RADIZ or RAIDZ2 or whatever. I could create 4 groups of 5 1TB HDD's and do all things like that...It's shared using iSCSI or samba or whatever, desktops and servers can see the files, everything works fine. But one day I run out of space, so I think right, build an exact copy of the one I have so I have another 20 TB server, given me 40TB, but I want nothing to change for the desktops/servers and as far as they know nothing as happened. But my problem is I could set that second server up, but how do I add the space to my existing pools? I create my RAIDZ2 zpools of hard drives, the raid works and everything, but now I want to increase my existing storage. I could go to my first server and simply add the storage to my groups, thus increasing the size...but then if that server fails I will lose all data? will I not? Basically I'm having trouble finding information on what happens when you add a second file server to increase your space. I see lots of guides and documents for 1 device and adding more HDD's to that device, but not when you need to add a second device (run out of HDD space in the device for example) Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Make ZFS auto-destroy snapshots when the out of space?
On 05/31/10 08:48, Paul Mather wrote: Devd already receives several ZFS-based events (failed vdev, I/O error, checksum mismatch, etc.), so perhaps it would be useful to add another, e.g., space which is set to be triggered when a pool attains a certain percentage full. This could default to 100%, but be capable of being set lower by an associated kernel sysctl. You could then have any auto-pruning/snapshot management script triggered from devd. (You'd probably also have to figure out some kind of throttling mechanism for this devd event, too.) I think that's probably the best alternative. Again, I could see that being used for a lot of things. It would be a nice general solution that wouldn't touch any (or very little) non-FreeBSD code. -- Kirk Strauser ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Locking a file backed mdconfig into memory
On Monday 31 May 2010 2:45:25 pm Jeremy Chadwick wrote: On Mon, May 31, 2010 at 11:25:51AM -0700, Dave Hayes wrote: Jeremy Chadwick free...@jdc.parodius.com writes: Is the mfsroot file compressed (.gz extension)? Reason I ask is that the OP states he's using RELENG_7... Yes it is compressed. http://jdc.parodius.com/freebsd/pxeboot_serial_install_7.html#step7 Thanks much for this. I did a simple test, I rebuilt a DVD that wasn't booting to use a lower level of compression (gzip -9 to gzip -6) on mfsroot without changing anything else. This caused it to boot normally. I'm not sure it's conclusive evidence, but it certainly looks like a weak datapoint supporting this kernel bug being the source of my problem. Is this problem fixed in 8.0 or by a patch? With regards to said bug, gzip compression seems to work fine on RELENG_8, at least in my experiences: http://jdc.parodius.com/freebsd/pxeboot_serial_install_8.html I'm not sure the level of compression is what triggers the bug though; I haven't tested all levels (1 through 9). CC'ing jhb@ since he last updated PR kern/120127 (which I would say is still a problem on RELENG_7 :-) ). John, are you aware of any gzip decompression / mfsroot changes which might explain the problem on RELENG_7? I haven't done a thorough series of tests, but on my testbed boxes RELENG_8 works fine with a gzip'd mfsroot. Ok, if you are using a stock mfsroot from a release build, that should work fine. If you have built a custom mfsroot that is larger, then you may need to increase NKPT on i386. In very recent 7 and later you can do this by setting it to a new value in your kernel config. In older versions you can do this by manually adding a #define to set a new value of NKPT in opt_global.h or hacking on the source directly. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: need better POSIX semaphore support
On Sunday 30 May 2010 11:06:22 am Kostik Belousov wrote: On Sun, May 30, 2010 at 06:30:35PM +0400, Dmitry Marakasov wrote: Hi! Not long ago, POSIX semaphores support was enabled by default as it's becoming more widely used, by e.g. firefox. However, the support for these is still incomplete: we only have systemwide limit of 30 semaphores, and that doesn't seem to be configurable neither online with sysctl, nor at boottime from loader.conf. I only was able to raise semaphore count by changing SEM_MAX in kernel sources. The real appliaction which needs more semaphores is lightspark (graphics/lightspark-devel) flash plugin - it uses ~40 sems for simple clips and ~250 for something like youtube videos. Until there more apps that require proper semaphore support, I guess we need to improve it asap. Given the amount of memory used by ksem, the least can be done is SEM_MAX bumped up to 5120 or so for non-embedded kernels. 5120 semaphores require just 644k of kernel memory (judging by vmstat), and is ought to be enough for anybody. Another good thing would be to make it configurable at boot-time or even better in runtime. HEAD contains different implementation. Apparently, it did not made into stable/8 yet, so it will not appear in the 8.1. The one thing I don't like about this approach is you can write the variable even when sem.ko isn't loaded. The SEM_* values should really only exist when sem.ko is loaded I think, which requires moving them into uipc_sem.c. Try this, I could try to squeeze it into 8.1. diff --git a/sys/kern/posix4_mib.c b/sys/kern/posix4_mib.c index 5242b31..41e28da 100644 --- a/sys/kern/posix4_mib.c +++ b/sys/kern/posix4_mib.c @@ -57,6 +57,9 @@ SYSCTL_DECL(_p1003_1b); #define P1B_SYSCTL(num, name) \ SYSCTL_INT(_p1003_1b, num, \ name, CTLFLAG_RD, facility + num - 1, 0, ); +#define P1B_SYSCTL_RW(num, name) \ +SYSCTL_INT(_p1003_1b, num, \ + name, CTLFLAG_RW, facility + num - 1, 0, ); #else @@ -65,6 +68,9 @@ SYSCTL_DECL(_kern_p1003_1b); #define P1B_SYSCTL(num, name) \ SYSCTL_INT(_kern_p1003_1b, OID_AUTO, \ name, CTLFLAG_RD, facility + num - 1, 0, ); +#define P1B_SYSCTL_RW(num, name) \ +SYSCTL_INT(_kern_p1003_1b, OID_AUTO, \ + name, CTLFLAG_RW, facility + num - 1, 0, ); SYSCTL_NODE(_kern, OID_AUTO, p1003_1b, CTLFLAG_RW, 0, P1003.1B); #endif @@ -91,7 +97,7 @@ P1B_SYSCTL(CTL_P1003_1B_DELAYTIMER_MAX, delaytimer_max); P1B_SYSCTL(CTL_P1003_1B_MQ_OPEN_MAX, mq_open_max); P1B_SYSCTL(CTL_P1003_1B_PAGESIZE, pagesize); P1B_SYSCTL(CTL_P1003_1B_RTSIG_MAX, rtsig_max); -P1B_SYSCTL(CTL_P1003_1B_SEM_NSEMS_MAX, sem_nsems_max); +P1B_SYSCTL_RW(CTL_P1003_1B_SEM_NSEMS_MAX, sem_nsems_max); P1B_SYSCTL(CTL_P1003_1B_SEM_VALUE_MAX, sem_value_max); P1B_SYSCTL(CTL_P1003_1B_SIGQUEUE_MAX, sigqueue_max); P1B_SYSCTL(CTL_P1003_1B_TIMER_MAX, timer_max); -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: need better POSIX semaphore support
On Tue, Jun 01, 2010 at 11:41:09AM -0400, John Baldwin wrote:
On Sunday 30 May 2010 11:06:22 am Kostik Belousov wrote:
On Sun, May 30, 2010 at 06:30:35PM +0400, Dmitry Marakasov wrote:
Hi!
Not long ago, POSIX semaphores support was enabled by default as it's
becoming more widely used, by e.g. firefox. However, the support
for these is still incomplete: we only have systemwide limit of 30
semaphores, and that doesn't seem to be configurable neither online with
sysctl, nor at boottime from loader.conf. I only was able to raise
semaphore count by changing SEM_MAX in kernel sources.
The real appliaction which needs more semaphores is lightspark
(graphics/lightspark-devel) flash plugin - it uses ~40 sems for simple
clips and ~250 for something like youtube videos.
Until there more apps that require proper semaphore support, I guess
we need to improve it asap. Given the amount of memory used by ksem,
the least can be done is SEM_MAX bumped up to 5120 or so for
non-embedded kernels. 5120 semaphores require just 644k of kernel
memory (judging by vmstat), and is ought to be enough for anybody.
Another good thing would be to make it configurable at boot-time
or even better in runtime.
HEAD contains different implementation. Apparently, it did not made
into stable/8 yet, so it will not appear in the 8.1.
The one thing I don't like about this approach is you can write the
variable even when sem.ko isn't loaded. The SEM_* values should really
only exist when sem.ko is loaded I think, which requires moving them
into uipc_sem.c.
I think the values should exist always, because sysconf(3) returns
error (i.e. -1 and errno set) when sysctl fails. sysconf(3) interprets
0 result as feature not supported.
I modified the patch to only allow change of value when the module is loaded.
Also, the module unload now clears mib. As usual, module unload races are
not handled.
diff --git a/sys/kern/posix4_mib.c b/sys/kern/posix4_mib.c
index 5242b31..cbe140d 100644
--- a/sys/kern/posix4_mib.c
+++ b/sys/kern/posix4_mib.c
@@ -45,6 +45,8 @@ __FBSDID($FreeBSD$);
static int facility[CTL_P1003_1B_MAXID - 1];
static int facility_initialized[CTL_P1003_1B_MAXID - 1];
+static int p31b_sysctl_proc(SYSCTL_HANDLER_ARGS);
+
/* OID_AUTO isn't working with sysconf(3). I guess I'd have to
* modify it to do a lookup by name from the index.
* For now I've left it a top-level sysctl.
@@ -55,16 +57,21 @@ static int facility_initialized[CTL_P1003_1B_MAXID - 1];
SYSCTL_DECL(_p1003_1b);
#define P1B_SYSCTL(num, name) \
-SYSCTL_INT(_p1003_1b, num, \
- name, CTLFLAG_RD, facility + num - 1, 0, );
+ SYSCTL_INT(_p1003_1b, num, name, CTLFLAG_RD, facility + num - 1, 0, );
+#define P1B_SYSCTL_RW(num, name) \
+ SYSCTL_PROC(_p1003_1b, num, name, CTLTYPE_INT | CTLFLAG_RW, NULL, num, \
+ p31b_sysctl_proc, I, );
#else
SYSCTL_DECL(_kern_p1003_1b);
#define P1B_SYSCTL(num, name) \
-SYSCTL_INT(_kern_p1003_1b, OID_AUTO, \
- name, CTLFLAG_RD, facility + num - 1, 0, );
+ SYSCTL_INT(_kern_p1003_1b, OID_AUTO, name, CTLFLAG_RD, \
+ facility + num - 1, 0, );
+#define P1B_SYSCTL_RW(num, name) \
+ SYSCTL_PROC(_p1003_1b, OID_AUTO, name, CTLTYPE_INT | CTLFLAG_RW, NULL, \
+ num, p31b_sysctl_proc, I, );
SYSCTL_NODE(_kern, OID_AUTO, p1003_1b, CTLFLAG_RW, 0, P1003.1B);
#endif
@@ -91,13 +98,28 @@ P1B_SYSCTL(CTL_P1003_1B_DELAYTIMER_MAX, delaytimer_max);
P1B_SYSCTL(CTL_P1003_1B_MQ_OPEN_MAX, mq_open_max);
P1B_SYSCTL(CTL_P1003_1B_PAGESIZE, pagesize);
P1B_SYSCTL(CTL_P1003_1B_RTSIG_MAX, rtsig_max);
-P1B_SYSCTL(CTL_P1003_1B_SEM_NSEMS_MAX, sem_nsems_max);
+P1B_SYSCTL_RW(CTL_P1003_1B_SEM_NSEMS_MAX, sem_nsems_max);
P1B_SYSCTL(CTL_P1003_1B_SEM_VALUE_MAX, sem_value_max);
P1B_SYSCTL(CTL_P1003_1B_SIGQUEUE_MAX, sigqueue_max);
P1B_SYSCTL(CTL_P1003_1B_TIMER_MAX, timer_max);
#define P31B_VALID(num)((num) = 1 (num) CTL_P1003_1B_MAXID)
+static int
+p31b_sysctl_proc(SYSCTL_HANDLER_ARGS)
+{
+ int error, num, val;
+
+ num = arg2;
+ if (!P31B_VALID(num))
+ return (EINVAL);
+ val = facility_initialized[num] ? facility[num - 1] : 0;
+ error = sysctl_handle_int(oidp, val, 0, req);
+ if (error == 0 req-newptr != NULL facility_initialized[num])
+ facility[num - 1] = val;
+ return (error);
+}
+
/* p31b_setcfg: Set the configuration
*/
void
@@ -110,6 +132,14 @@ p31b_setcfg(int num, int value)
}
}
+void
+p31b_unsetcfg(int num)
+{
+
+ facility[num - 1] = 0;
+ facility_initialized[num -1] = 0;
+}
+
int
p31b_getcfg(int num)
{
diff --git a/sys/kern/uipc_sem.c b/sys/kern/uipc_sem.c
index d9229ea..0b8f132 100644
--- a/sys/kern/uipc_sem.c
+++ b/sys/kern/uipc_sem.c
@@ -976,6 +976,8 @@ ksem_module_destroy(void)
sx_destroy(ksem_dict_lock);
mtx_destroy(ksem_count_lock);
mtx_destroy(sem_lock);
+
Re: need better POSIX semaphore support
On Tuesday 01 June 2010 1:05:26 pm Kostik Belousov wrote: On Tue, Jun 01, 2010 at 11:41:09AM -0400, John Baldwin wrote: On Sunday 30 May 2010 11:06:22 am Kostik Belousov wrote: On Sun, May 30, 2010 at 06:30:35PM +0400, Dmitry Marakasov wrote: Hi! Not long ago, POSIX semaphores support was enabled by default as it's becoming more widely used, by e.g. firefox. However, the support for these is still incomplete: we only have systemwide limit of 30 semaphores, and that doesn't seem to be configurable neither online with sysctl, nor at boottime from loader.conf. I only was able to raise semaphore count by changing SEM_MAX in kernel sources. The real appliaction which needs more semaphores is lightspark (graphics/lightspark-devel) flash plugin - it uses ~40 sems for simple clips and ~250 for something like youtube videos. Until there more apps that require proper semaphore support, I guess we need to improve it asap. Given the amount of memory used by ksem, the least can be done is SEM_MAX bumped up to 5120 or so for non-embedded kernels. 5120 semaphores require just 644k of kernel memory (judging by vmstat), and is ought to be enough for anybody. Another good thing would be to make it configurable at boot-time or even better in runtime. HEAD contains different implementation. Apparently, it did not made into stable/8 yet, so it will not appear in the 8.1. The one thing I don't like about this approach is you can write the variable even when sem.ko isn't loaded. The SEM_* values should really only exist when sem.ko is loaded I think, which requires moving them into uipc_sem.c. I think the values should exist always, because sysconf(3) returns error (i.e. -1 and errno set) when sysctl fails. sysconf(3) interprets 0 result as feature not supported. I modified the patch to only allow change of value when the module is loaded. Also, the module unload now clears mib. As usual, module unload races are not handled. I think this looks good, thanks! -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd-update with non-GENERIC kerrnel
The only way to have freebsd-update to work on a non-GENERIC kernel is to run
your own freebsd-update server based off an iso that has your custom kernel
within the release.
I've been doing this for some time now.
On Jun 1, 2010, at 2:57 AM, c0re wrote:
freebsd-update made for only GENERIC kerndel due to binary diff patches.
After you rebuild world and kernel you'll be not able to apply binary
patches.
2010/6/1 Olaf Seibert o.seib...@cs.ru.nl
I find the way freebsd-update handles a system that runs a non-GENERIC
kernel less than helpful.
It is doing this:
| fourquid.3:~$ sudo freebsd-update upgrade -r 8.1-BETA1
| Password:
| Looking up update.FreeBSD.org mirrors... 3 mirrors found.
| Fetching metadata signature for 8.0-RELEASE from update5.FreeBSD.org...
done.
| Fetching metadata index... done.
| Fetching 2 metadata patches.. done.
| Applying metadata patches... done.
| Inspecting system... done.
|
| WARNING: This system is running a fourquid kernel, which is not a
| kernel configuration distributed as part of FreeBSD 8.0-RELEASE.
| This kernel will not be updated: you MUST update the kernel manually
| before running /usr/sbin/freebsd-update install.
|
| The following components of FreeBSD seem to be installed:
| src/base src/bin src/cddl src/contrib src/crypto src/etc src/games
| src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue
| src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin
| world/base world/catpages world/dict world/doc world/games world/info
| world/lib32 world/manpages world/proflibs
|
| The following components of FreeBSD do not seem to be installed:
| kernel/generic
|
| Does this look reasonable (y/n)? n
I do have the kernel sources installed, so I would like to have them
updated. I don't even mind to have a GENERIC kernel temporarily
installed, until I compile my own (fortunately, they are not that
different).
It is nice that it tells me that I MUST update the kernel manually,
but it gives me no help in getting the sources and doing that. (Can the
new kernel even be built in all cases with old tools? NetBSD offers a
nice cross-building system for that.)
For my previous update to 8.0-RELEASE-p2 I patched freebsd-update simply
to think that my kernel *is* GENERIC,
--- /usr/sbin/freebsd-update2009-12-22 17:16:01.0 +0100
+++ /tmp/freebsd-update 2010-05-11 10:35:05.0 +0200
@@ -631,6 +631,7 @@
# we're running an SMP kernel. This mis-identification is a bug
# which was fixed in 6.2-STABLE.
KERNCONF=`uname -i`
+ KERNCONF=GENERIC
if [ ${KERNCONF} = SMP-GENERIC ]; then
KERNCONF=SMP
fi
but that seems riskier as updates get a bit bigger.
The official way seems to be to reboot using GENERIC, upgrade (with a
reboot with new GENERIC), rebuild new CUSTOM kernel, reboot again. At
least the first reboot ought to be avoided...
-Olaf.
--
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
= Re-posted from freebsd-hardware@, since this is more of a bug report than a hardware comparability inquiry / buying strategy discussion. == All: Has anyone upgraded their PowerEdge 1850s to 8.0-PL or RELENG_8 -stable? We're seeing problems where 7.2-PL and 6.3-PL were not affected on the same hardware. The problem is that forcing the duplex 100/full on both sides no longer functions. Configuration: - A variety of Cisco L2/L3 switches over the last decade: -- 2848G-L3 -- 2950 -- 2960s -- 3550-12Ts -- 3550XLs -- Duplex forced 100/full on Cisco side - FreeBSD/amd64 RELENG_8 or 9-CURRENT with duplex forced '100baseTX mediaopt full-duplex', - This configuration has worked since FreeBSD 5.4 When connected to PowerEdge 1850r1/r2, with the onboard Intel 82541EI, the parenthesis show an actual media speed/duplex of: media: Ethernet 100baseTX full-duplex (100baseTX half-duplex) The same configuration using a Dell-sold Intel dual port 82546EB, in the same system, on the same switch, works fine. - ifconfig(8): - em3: flags=8843UP,BROADCAST,RUNNING,SIMPLEX, \r MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:13:72:4f:70:81 inet 192.168.97.20 netmask 0xff80 broadcast 192.168.97.127 media: Ethernet 100baseTX full-duplex (100baseTX half-duplex) status: active - em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,\ MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:04:23:c8:fe:ac media: Ethernet 100baseTX full-duplex status: active - - pciconf(8): - e...@pci0:7:8:0:class=0x02 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (82541EI)' class = network subclass = ethernet e...@pci0:3:11:0: class=0x02 card=0x10128086 chip=0x10108086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (Copper) (82546EB)' class = network subclass = ethernet - rc.conf(5) for shits giggles: ifconfig_em0=inet X netmask Y media 100baseTX mediaopt full-duplex ifconfig_em3=inet Z netmask F media 100baseTX mediaopt full-duplex Example IOS switch config: interface FastEthernet0/39 description I hate Dell switchport access vlan 100 switchport mode access speed 100 duplex full spanning-tree portfast end I've been clearing interface counters on the switch side, but I'll send 'netstat -i', 'show interface counters', and 'sudo sysctl -w dev.em.3.stats=1' ASAP to illustrate connectivity errors soon. Are we being punished for patronizing Dell? Is it possible that ifconfig(8) output has simply changed? Are the values in the parenthesis on the right the Ethernet auto-sense desired values where as outside the parenthesis the current active values? In 6.3/7.2, once you forced a speed/duplex, the values in parenthesis went away entirely. The only way I've been able to make that happen is to #define in src/sys/dev/e1000/if_em.h: #define DO_AUTO_NEG 0 /* * This parameter control whether or not the driver will wait for * autonegotiation to complete. * 1 - Wait for autonegotiation to complete * 0 - Don't wait for autonegotiation to complete */ Also seems odd that some ICs are affected but not others. Its also possible that my problems are pf(4) + setfib(8) related and I that this is a separate issue. Two new notes since the original post: - I have confirmed this problem on two revisions of the Dell 8th gen hardware in two different datacenters - The problem persists on -CURRENT from 05/2010 - RELENG_7 does not seem to be impacted - More stats below. Thanks, ~BAS --- em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em0: Excessive collisions = 0 em0: Sequence errors = 0 em0: Defer count = 0 em0: Missed Packets = 0 em0: Receive No Buffers = 0 em0: Receive Length Errors = 0 em0: Receive errors = 0 em0: Crc errors = 0 em0: Alignment errors = 0 em0: Collision/Carrier extension errors = 0 em0: RX overruns = 0 em0: watchdog timeouts = 0 em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 em0: XON Rcvd = 0 em0: XON Xmtd = 0 em0: XOFF Rcvd = 0 em0: XOFF Xmtd = 0 em0: Good Packets Rcvd = 1319916 em0: Good Packets Xmtd = 1070646 em0: TSO Contexts Xmtd = 0 em0: TSO Contexts Failed = 0 em1: Excessive collisions = 0 em1: Sequence errors = 0 em1: Defer count = 0 em1: Missed Packets = 0
Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On Tue, Jun 01, 2010 at 03:18:39PM -0400, Brian A. Seklecki wrote: = Re-posted from freebsd-hardware@, since this is more of a bug report than a hardware comparability inquiry / buying strategy discussion. == All: Has anyone upgraded their PowerEdge 1850s to 8.0-PL or RELENG_8 -stable? We're seeing problems where 7.2-PL and 6.3-PL were not affected on the same hardware. The problem is that forcing the duplex 100/full on both sides no longer functions. Configuration: - A variety of Cisco L2/L3 switches over the last decade: -- 2848G-L3 -- 2950 -- 2960s -- 3550-12Ts -- 3550XLs -- Duplex forced 100/full on Cisco side - FreeBSD/amd64 RELENG_8 or 9-CURRENT with duplex forced '100baseTX mediaopt full-duplex', - This configuration has worked since FreeBSD 5.4 When connected to PowerEdge 1850r1/r2, with the onboard Intel 82541EI, the parenthesis show an actual media speed/duplex of: media: Ethernet 100baseTX full-duplex (100baseTX half-duplex) The same configuration using a Dell-sold Intel dual port 82546EB, in the same system, on the same switch, works fine. - ifconfig(8): - em3: flags=8843UP,BROADCAST,RUNNING,SIMPLEX, \r MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:13:72:4f:70:81 inet 192.168.97.20 netmask 0xff80 broadcast 192.168.97.127 media: Ethernet 100baseTX full-duplex (100baseTX half-duplex) status: active - em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,\ MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:04:23:c8:fe:ac media: Ethernet 100baseTX full-duplex status: active - - pciconf(8): - e...@pci0:7:8:0: class=0x02 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (82541EI)' class = network subclass = ethernet e...@pci0:3:11:0: class=0x02 card=0x10128086 chip=0x10108086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (Copper) (82546EB)' class = network subclass = ethernet - rc.conf(5) for shits giggles: ifconfig_em0=inet X netmask Y media 100baseTX mediaopt full-duplex ifconfig_em3=inet Z netmask F media 100baseTX mediaopt full-duplex Example IOS switch config: interface FastEthernet0/39 description I hate Dell switchport access vlan 100 switchport mode access speed 100 duplex full spanning-tree portfast end I've been clearing interface counters on the switch side, but I'll send 'netstat -i', 'show interface counters', and 'sudo sysctl -w dev.em.3.stats=1' ASAP to illustrate connectivity errors soon. Are we being punished for patronizing Dell? Is it possible that ifconfig(8) output has simply changed? Are the values in the parenthesis on the right the Ethernet auto-sense desired values where as outside the parenthesis the current active values? In 6.3/7.2, once you forced a speed/duplex, the values in parenthesis went away entirely. The only way I've been able to make that happen is to #define in src/sys/dev/e1000/if_em.h: #define DO_AUTO_NEG 0 /* * This parameter control whether or not the driver will wait for * autonegotiation to complete. * 1 - Wait for autonegotiation to complete * 0 - Don't wait for autonegotiation to complete */ Also seems odd that some ICs are affected but not others. Its also possible that my problems are pf(4) + setfib(8) related and I that this is a separate issue. Two new notes since the original post: - I have confirmed this problem on two revisions of the Dell 8th gen hardware in two different datacenters - The problem persists on -CURRENT from 05/2010 - RELENG_7 does not seem to be impacted - More stats below. Thanks, ~BAS --- em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em0: Excessive collisions = 0 em0: Sequence errors = 0 em0: Defer count = 0 em0: Missed Packets = 0 em0: Receive No Buffers = 0 em0: Receive Length Errors = 0 em0: Receive errors = 0 em0: Crc errors = 0 em0: Alignment errors = 0 em0: Collision/Carrier extension errors = 0 em0: RX overruns = 0 em0: watchdog timeouts = 0 em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 em0: XON Rcvd = 0 em0: XON Xmtd = 0 em0: XOFF Rcvd = 0 em0: XOFF Xmtd =
usb multicardreader probes only first slot after update
Hi, I just noticed that a usb multicardreader that I have used for a few years stopped working after an update from 8-STABLE around January 10th to 8-STABLE from May 29th. Reason appears to be that now only the first slot (which is empty) is probed instead of all four slots like before. dmesg output from after the update: ugen4.2: ICSI at usbus4 umass0: Bulk on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x umass0:0:0:-1: Attached to scbus0 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) ugen4.2: ICSI at usbus4 (disconnected) umass0: at uhub4, port 6, addr 2 (disconnected) ugen4.2: ICSI at usbus4 umass0: Bulk on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x umass0:0:0:-1: Attached to scbus0 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) ugen4.2: ICSI at usbus4 (disconnected) umass0: at uhub4, port 6, addr 2 (disconnected) Before the update dmesg output looked like this: ugen4.2: vendor 0x0dda at usbus4 umass0: vendor 0x0dda product 0x2001, class 0/0, rev 2.00/1.6e, addr 2 on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x umass0:0:0:-1: Attached to scbus0 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present (probe0:umass-sim0:0:0:0): Unretryable error da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: ICSI CF Card CF 1.6E Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 (probe0:umass-sim0:0:0:1): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:1): SCSI Status: Check Condition (probe0:umass-sim0:0:0:1): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:1): Medium not present (probe0:umass-sim0:0:0:1): Unretryable error da1 at umass-sim0 bus 0 scbus0 target 0 lun 1 da1: ICSI MS Card MS 1.6E Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present (probe0:umass-sim0:0:0:2): TEST UNIT READY. CDB: 0 40 0 0 0 0 (probe0:umass-sim0:0:0:2): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:2): SCSI Status: Check Condition (probe0:umass-sim0:0:0:2): UNIT ATTENTION asc:28,0 (probe0:umass-sim0:0:0:2): Not ready to ready change, medium may have changed (probe0:umass-sim0:0:0:2): Retrying Command (per Sense Data) da2 at umass-sim0 bus 0 scbus0 target 0 lun 2 da2: ICSI SD Card MMC/SD 1.6E Removable Direct Access SCSI-0 device da2: 40.000MB/s transfers da2: 1886MB (3862528 512 byte sectors: 255H 63S/T 240C) (probe0:umass-sim0:0:0:3): TEST UNIT READY. CDB: 0 60 0 0 0 0 (probe0:umass-sim0:0:0:3): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:3): SCSI Status: Check Condition (probe0:umass-sim0:0:0:3): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:3): Medium not present (probe0:umass-sim0:0:0:3): Unretryable error da3 at umass-sim0 bus 0 scbus0 target 0 lun 3 da3: ICSI SM Card SM 1.6E Removable Direct Access SCSI-0 device da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present GEOM: da2: partition 1 does not start on a track boundary. GEOM: da2: partition 1 does not end on a track boundary. Apr 5 21:32:04 vulcan su: wolfgang to root on /dev/pts/3 ugen4.2: vendor 0x0dda at usbus4 (disconnected) umass0: at uhub4, port 6, addr 2 (disconnected) (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry (da1:umass-sim0:0:0:1): lost device (da1:umass-sim0:0:0:1): removing device entry (da2:umass-sim0:0:0:2): lost device (da2:umass-sim0:0:0:2): removing device entry (da3:umass-sim0:0:0:3): lost device (da3:umass-sim0:0:0:3): removing device entry I have not yet tried what happens if I actually put a CF card in the reader (that would be the first slot). Wolfgang ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Locking a file backed mdconfig into memory
On Tue, 1 Jun 2010, John Baldwin wrote: On Monday 31 May 2010 2:45:25 pm Jeremy Chadwick wrote: On Mon, May 31, 2010 at 11:25:51AM -0700, Dave Hayes wrote: Jeremy Chadwick free...@jdc.parodius.com writes: Is the mfsroot file compressed (.gz extension)? Reason I ask is that the OP states he's using RELENG_7... Yes it is compressed. http://jdc.parodius.com/freebsd/pxeboot_serial_install_7.html#step7 Thanks much for this. I did a simple test, I rebuilt a DVD that wasn't booting to use a lower level of compression (gzip -9 to gzip -6) on mfsroot without changing anything else. This caused it to boot normally. I'm not sure it's conclusive evidence, but it certainly looks like a weak datapoint supporting this kernel bug being the source of my problem. Is this problem fixed in 8.0 or by a patch? With regards to said bug, gzip compression seems to work fine on RELENG_8, at least in my experiences: http://jdc.parodius.com/freebsd/pxeboot_serial_install_8.html I'm not sure the level of compression is what triggers the bug though; I haven't tested all levels (1 through 9). CC'ing jhb@ since he last updated PR kern/120127 (which I would say is still a problem on RELENG_7 :-) ). John, are you aware of any gzip decompression / mfsroot changes which might explain the problem on RELENG_7? I haven't done a thorough series of tests, but on my testbed boxes RELENG_8 works fine with a gzip'd mfsroot. Ok, if you are using a stock mfsroot from a release build, that should work fine. If you have built a custom mfsroot that is larger, then you may need to increase NKPT on i386. In very recent 7 and later you can do this by setting it to a new value in your kernel config. In older versions you can do this by manually adding a #define to set a new value of NKPT in opt_global.h or hacking on the source directly. This is the original post I found confirming all this: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2004-02/0241.html I can also confirm your changes that allow it to be a kernel config option works as well. :) It's nice to essentially have a full livefs as your mfsroot for non-sysinstall installs. Charles -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: need better POSIX semaphore support
* Kostik Belousov (kostik...@gmail.com) wrote: I've tried the second patch, it works fine. It would be very nice to see it in 8.1, thanks. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: IPMI Console: No luck once OS is booted
Miroslav Lachman wrote: PaulFr wrote: Larry Rosenman wrote: On Sun, 10 Aug 2008, David Duchscher wrote: On Aug 10, 2008, at 10:22 AM, Larry Rosenman wrote: I don't have that IPMI card but I can say we have other cards of theirs working. I would make sure the card is at the latest version of firmware. The AOC-SIMSO(+) card was not detected correctly until we upgraded. I don't know why the card is going away when freebsd boots since I assume you are on the dedicated LAN interface with its own IP address. Yes. It's not going away, just doesn't see the key strokes. Looking through your dmesg file, I don't see a USB keyboard being attached. On my system, the virtual keyboard is a USB keyboard. ukbd0:Peppercon AG Multidevice, class 0/0, rev 2.00/0.01, addr 2 on uhub3 kbd2 at ukbd0 Good catch. When I set it to disable USB Mass Storage when no image is loaded, the ukbd came alive, and I'm typing this on the IPMI Console. Thanks! -- DaveD Larry I have a similar problem as you describe in this posting using a SuperMicro X8SIL-F motherboard with onboard IPMI. The console redirection works fine during boot until the OS (pfSense - FreebSD 7.2 Release p5) boots and then I can't enter anything from the keyboard. Screen output is OK. I notice there is also no usb keyboard being detected during boot - instead a usb mass storage device is added. Thus I suspect I am seeing the same issue as you did. When you mentioned When I set it to disable USB Mass Storage when no image is loaded, the ukbd came alive... how did you do that? Can you try to boot FreeBSD 8 or 7.3 live system, not installer? I had same problem with 7.2 installer, but IPMI works with installed 7.2 GENERIC kernel from HDD. 8.0 installer and installed GENERIC kernel works fine in both case. So I think there is some bug in older releases. Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Miroslav I will try out your suggestion if I get a chance but it maybe some time as the server is in production. In the meantime, I came across a workaround which works for FreeBSD and the version of IPMI (v1.29) on the Supermicro motherboard I am using (X8SIL-F). It involves changing the mouse input mode of the console launched from either IPMIView (Java based, v2.7.13) or the browser interface to the IPMI from Absolute (Windows) to Relative (Linux). Once this change was applied, FreeBSD immediately detected a new USB device (keyboard) on the same USB port as the mouse. Keyboard input then worked in the IPMI remote console. The mouse mode change is stored in the IPMI NVRAM and so it does not have to be set again. Regards Paul -- View this message in context: http://old.nabble.com/IPMI-Console%3A-No-luck-once-OS-is-booted-tp18910013p28748926.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: IPMI Console: No luck once OS is booted
On Mon, May 31, 2010 at 9:53 PM, PaulFr pfcompt...@gmail.com wrote: When you mentioned When I set it to disable USB Mass Storage when no image is loaded, the ukbd came alive... how did you do that? I would assume the kernel was rebuilt without device umass Maybe setting it in make.conf WITHOUT_MODULES would be a good idea too. -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: panic: rtqkill route really not free on freebsd 8.0-release
I worte: Hi all, I have four heavy load mysql database servers which system is 8.0-release got panic: rtqkill route really not free this week. We have a gateway set up by OpenBSD have a icmp route redirect function between two subnets, I suspect the FreeBSD panic at trying to delete routes sent from that gateway. So I set sysctl net.inet.icmp.drop_redirect=1, no more panic in past 24 hours. I guess maybe miss some locks or wrong delete route path in 8.0-release. Did any one meet this problem before? After four days research we think the problem is between function in_matroute and in_rtqkill. This two functions' conflicted at processing RTPRF_OURS flag routes. In my opinion, it is a design problem, so I have no idea about how to resolve it. The simple way I think is change the panic assert in in_rtqkill, treat it as a normal state not assert a panic. -- The Power to Serve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
