Re: FreeBSD 8.2-RC3/7.4-RC3 Available...
On 01/-10/-28163 20:59, Ken Smith wrote: The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 8.0-RELEASE, 8.1-RELEASE, 8.2-BETA1, 8.2-RC1 or 8.2-RC2 can upgrade as follows: # freebsd-update upgrade -r 8.2-RC3 While it does work on i386, it fails on amd64: Fetching metadata signature for 8.2-RC3 from update5.FreeBSD.org... failed. Fetching metadata signature for 8.2-RC3 from update4.FreeBSD.org... failed. Fetching metadata signature for 8.2-RC3 from update2.FreeBSD.org... failed. Fetching metadata signature for 8.2-RC3 from update3.FreeBSD.org... failed. In contrast to the other releases, betas, and candidates, there is no amd64 directory listed for 8.2-RC3, only i386: http://update4.freebsd.org/8.2-RC3/ (It has been this way for a few days now, but since there was no announcement, I thought it was still being worked on.) Cheers, Jan Henrik ___ 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 8.2-RC3/7.4-RC3 Available...
On 02/06/2011 10:30, Thomas Steen Rasmussen wrote: On 03.02.2011 23:38, Jan Henrik Sylvester wrote: On 01/-10/-28163 20:59, Ken Smith wrote: The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 8.0-RELEASE, 8.1-RELEASE, 8.2-BETA1, 8.2-RC1 or 8.2-RC2 can upgrade as follows: # freebsd-update upgrade -r 8.2-RC3 While it does work on i386, it fails on amd64: Fetching metadata signature for 8.2-RC3 from update5.FreeBSD.org... failed. Fetching metadata signature for 8.2-RC3 from update4.FreeBSD.org... failed. Fetching metadata signature for 8.2-RC3 from update2.FreeBSD.org... failed. Fetching metadata signature for 8.2-RC3 from update3.FreeBSD.org... failed. In contrast to the other releases, betas, and candidates, there is no amd64 directory listed for 8.2-RC3, only i386: http://update4.freebsd.org/8.2-RC3/ (It has been this way for a few days now, but since there was no announcement, I thought it was still being worked on.) Hello, For what it's worth, I am still seeing the same thing on an AMD64 8.2-RC2 system: $ sudo freebsd-update -v debug upgrade -r 8.2-RC3 Looking up update.FreeBSD.org mirrors... 4 mirrors found. Fetching public key from update4.FreeBSD.org... fetch: http://update4.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. Fetching public key from update5.FreeBSD.org... fetch: http://update5.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. Fetching public key from update2.FreeBSD.org... fetch: http://update2.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. Fetching public key from update3.FreeBSD.org... fetch: http://update3.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. No mirrors remaining, giving up. That is not the same thing. It is looking for "8.2-PRERELEASE": Your system is not on a binary release (a RELEASE, a BETA, or a RC) and cannot (regularly) be updated by freebsd-update. I have done freebsd-updates 8.1-RELEASE -> 8.2-BETA1 -> 8.2-RC1 -> 8.2-RC2 on amd64 successfully (as well as 8.2-RC1 -> 8.2-RC2 on i386). The bits are all there. For 8.2-RC3 and 7.4-RC3 the amd64 signatures are missing while the i386 ones are there: http://update4.freebsd.org/8.2-RC3/ Both amd64 and i386 are there for 8.2-RC2 (and every other RELEASE, BETA, and RC): http://update4.freebsd.org/8.2-RC2/ Interestingly, while the signature is missing, the binary patches are there for amd64 (and i386): http://update4.freebsd.org/to-8.2-RC3/ Cheers, Jan Henrik ___ 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 and release candidates
On 01/-10/-28163 20:59, Renato Botelho wrote: On Tue, Feb 22, 2011 at 11:04 AM, Svein Skogen wrote: I'm in the process of setting up a small network of FreeBSD installations. My plan (this time) is to keep them on branches available to freebsd-update, instead of depending on source being checked out from CVS. However, I'm a wee bit curious of whether I will be able to upgrade from 8.2RC3 or if I should wait until 8.2 is actually released with the setup (I _CAN_ wait a week or two). If you are running 8.2-RC3, you can safely run freebsd-update to go to 8.2-RELEASE. # freebsd-update -r 8.2-RELEASE upgrade You can see for yourself, which releases are supported by freebsd-update: http://update4.freebsd.org/ Since 7.2, every BETA, RC, and RELEASE has been available via freebsd-update (i386 and amd64). I think, the binary diffs are not generated for every combination, but since freebsd-update will fallback to downloading the whole files, even leaving out a few releases should always work. The official announcements usually contain a list of releases supported by freebsd-update, for example 8.2-RC3 was available from 8.0-RELEASE, 8.1-RELEASE, 8.2-BETA1, 8.2-RC1, 8.2-RC2, and "earlier FreeBSD releases (FreeBSD 7.x)". BTW: The 8.2-RELEASE bits are on freebsd-update for almost a day already, the ISOs even a little bit longer, but as always: Wait for the official announcement that is scheduled for today. Cheers, Jan Henrik ___ 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 9.1-BETA1 Available...
On 07/17/2012 05:38, Ken Smith wrote: The first test build of the 9.1-RELEASE release cycle is now available on the FTP servers for amd64, i386, powerpc64, and sparc64. The What about freebsd-update -- is it going to be available for this BETA1? Cheers, Jan Henrik ___ 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"
GSSAPI (for OpenLDAP) on FreeBSD 8?
I have got problems with GSSAPI authentication to OpenLDAP: ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) There were at least two discussions, multiple bug reports, and patches about broken GSSAPI on FreeBSD 8, the longest (I found) starting here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057734.html After reading through these discussions, I do not know what the proper fix is -- I would like to change as little as possible introducing SASL authentication to a (production) OpenLDAP server. I have got: An i386 kerberos server, a ldap server in a jail on i386, some amd64 clients -- all running 8.1-RELEASE. Eventually there need to be some Debian/Ubuntu clients using GSSAPI/SASL, too. What do I need to "fix"? Just the ldap server? Is it enough to change the jail or does the host needs to be patches, too? Or do I need to fix the client, too? The kerberos server? From the discussion, multiple fixes were possible. Patching libgssapi and reinstalling everything depending on it (what?), installing the heimdal-1.0 port (while FreeBSD 8 comes with heimdal-1.1), installing an unofficial heimdal-1.2 port, ... Is that correct? Anything new after the discussion in July? From the discussion, some patches should already be in 8-STABLE, but I could not find the revision (after 8.1-RELEASE). If I upgraded the ldap jail to 8-STABLE, I guess the host needs to be updated, too. Hence I would prefer to just change ports or update single libraries. Does anyone have OpenLDAP+GSSAPI running on FreeBSD 8? With the libgssapi patch? With the heimdal-1.2 port? Thanks, Jan Henrik ___ 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: GSSAPI (for OpenLDAP) on FreeBSD 8?
On 01/-10/-28163 20:59, Matthias Andree wrote: Am 01.09.2010 18:33, schrieb Jan Henrik Sylvester: I have got problems with GSSAPI authentication to OpenLDAP: ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) Did you run kinit to obtain tickets? You didn't mention that. Yes, I did, and klist shows the tgt and the ldap ticket -- the latter only after the call. You do get a "Local error" and not "Other" if you have no ticket. (And the ldap ticket is in /etc/krb5.keytab on the ldap server and owner by ldap.) Thanks, Jan Henrik ___ 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: GSSAPI (for OpenLDAP) on FreeBSD 8?
On 09/02/2010 13:50, Jeremy Chadwick wrote: On Wed, Sep 01, 2010 at 06:33:03PM +0200, Jan Henrik Sylvester wrote: I have got problems with GSSAPI authentication to OpenLDAP: ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) There were at least two discussions, multiple bug reports, and patches about broken GSSAPI on FreeBSD 8, the longest (I found) starting here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057734.html After reading through these discussions, I do not know what the proper fix is -- I would like to change as little as possible introducing SASL authentication to a (production) OpenLDAP server. I have got: An i386 kerberos server, a ldap server in a jail on i386, some amd64 clients -- all running 8.1-RELEASE. Eventually there need to be some Debian/Ubuntu clients using GSSAPI/SASL, too. What do I need to "fix"? Just the ldap server? Is it enough to change the jail or does the host needs to be patches, too? Or do I need to fix the client, too? The kerberos server? From the discussion, multiple fixes were possible. Patching libgssapi and reinstalling everything depending on it (what?), installing the heimdal-1.0 port (while FreeBSD 8 comes with heimdal-1.1), installing an unofficial heimdal-1.2 port, ... Is that correct? Anything new after the discussion in July? From the discussion, some patches should already be in 8-STABLE, but I could not find the revision (after 8.1-RELEASE). If I upgraded the ldap jail to 8-STABLE, I guess the host needs to be updated, too. Hence I would prefer to just change ports or update single libraries. Does anyone have OpenLDAP+GSSAPI running on FreeBSD 8? With the libgssapi patch? With the heimdal-1.2 port? Can you please try the patch I proposed and see if it improves your situation? Thanks. http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057830.html I had already tried the gss_release_buffer patch. It fixes that crash doing the GSSAPI operation from i386 and brings i386 in par with amd64 -- to the error message I mentioned above. I have also tried the change to /usr/bin/krb5-config before building OpenLDAP -- with no effect, either. I have not tried the "big" libgssapi patch from kern/147454 as I was hoping to do a smaller change. Cheers, Jan Henrik ___ 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: GSSAPI (for OpenLDAP) on FreeBSD 8?
On 09/02/2010 14:30, Reko Turja wrote: -- From: "Jan Henrik Sylvester" Sent: Wednesday, September 01, 2010 7:33 PM To: "stable-list freebsd" Subject: GSSAPI (for OpenLDAP) on FreeBSD 8? Does anyone have OpenLDAP+GSSAPI running on FreeBSD 8? With the libgssapi patch? With the heimdal-1.2 port? I got running and fully functional Heimdal/GSSAPI setup with Benjamins patch from http://www.freebsd.org/cgi/query-pr.cgi?pr=147454&cat=kern, although I didn't test it with LDAP. Still my question, do I only have to patch the ldap server or the client doing gssapi ldap queries -- or even the kerberos server? Would a heimdal port be an alternative? Would that only have to be running on the ldap server or the client, too? Sorry, my understanding of gssapi is limited. Thanks, Jan Henrik ___ 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"
aesni(?) corrupts data on 8.2-BETA1
I just upgraded my main laptop from 8.1-RELEASE (GENERIC, amd64) to 8.2-BETA1 and added aesni_load="YES" to my /boot/loader.conf. (If my interpretation is correct:) With aesni loaded, I see many files corrupted on my geli encrypted volume. Without aesni loaded, they are ok. I have got a journaling UFS2 on gjournal on geli on a FreeBSD partition on a MBR slice on a disk with ahci loaded. Story: First I noticed some weirdness of Thunderbird not showing the "upgraded" message properly and reloading IMAP messages that have already been read, but did not think of anything. Only during my usual rsyncing of the encrypted volume, I saw that some files could not be read (invalid file descriptor?). I rebooted without aesni and got a different error message. I created checksums of all files on that encrypted volume with and without aesni loaded (rebooting in between): 150 Differences (one files could not be read in both cases). Just to make sure, I tried to rsync with "--checksum" and "--dry-run" to the other machine that is supposed to have the same files: With aesni, many files were scheduled to be synced and one could not be read, but without aesni, only that one file was scheduled to be synced -- it probably got corrupted for good with aesni loaded. It is especially weird that I did not attempt to write to the file that got corrupted on disk with aesni loaded. Is there anything I am doing wrong or is it really aesni or the processor failing? The processor is a Core i7-M620 (with AESNI of course). Before I investigate any further, I have to make a real backup... rsyncing does not prevent silent corruption. I am lucky that it was not so silent after all. Jan Henrik ___ 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: aesni(?) corrupts data on 8.2-BETA1
On 12/12/2010 15:26, Mike Tancsa wrote: On 12/12/2010 3:43 AM, Kostik Belousov wrote: Please try this patch on the latest HEAD or RELENG_8. I tried both on i386 and amd64 and all looks good! I did 1000 iterations of cryptotest -c -z -t 10 without issue! Thanks for the quick fix! I redid my testing on a (read-only attached) geli provider (now with XTS instead of CBC) taking checksums of all files: 8.2-BETA1 without patch without aesni loaded: all checksums ok. 8.2-BETA1 with patch without aesni loaded: all checksums ok. 8.2-BETA1 without patch with aesni loaded: 124 of 18209 failures. 8.2-BETA1 with patch with aesni loaded: all checksums ok. The patch seems to fix my geli problem on 8.2-BETA1 amd64, too. Thanks! Jan Henrik ___ 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: LevelOne WPC-0301 11g Wireless CardBus
Oliver wrote: > I bought a LevelOne WPC-0301 11g Wireless CardBus Adapter > today. According to the box it is "v6". The ral(4) man- > page mentions only v2, but that one is ancient and can't > be bought anymore. I do not know about the WPC-0301, but I since I bought a wrong WNC-0301 (PCI version), I did some research looking at the IDs and additionally Windows drivers: v.1 is Marvel, v.2 is the old Ralink, v.3 is the never Ralink, and v.5 (and v.6?) is RealTek. (v.4 does not have a Windows driver at the LevelOne homepage.) BTW: I did summit this info to http://linux-wless.passys.nl/ -- it is a pretty good overview, especially if you want to check which vendors switch chipset manufacturers from one revision to the next. My guess would be that you are out of luck, if it is not detected at 7-STABLE. Look at the sys files in the Windows driver, if there is one. Of course, you can try ndis, but I would not go for it. If you shop for a card, most of the 108Mbps are Atheros, which works better than Ralink in my experience. Since you are from Germany, too: geizhals.at lists TP-Link TL-WN610G for less than 15 Euros, which has an Atheros chipset according to the site I mentioned above. If you are looking on Ebay, I can really recommend Philips SNN6500, which does a/b/g and the proprietary Atheros stuff (TURBOP, BURST). Cheers, Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
iwn on 7.1-RC1
Short version: Is there any chance to get iwn working on 7.1-RC1
reliably? I have got one problem with the initial perforce version and
the backport from gavin always crashes. Long version:
I have been using the initial perforce version of iwn on 7-STABLE for a
few month now, since the next version is already "vap'ify iwn". Usually,
the connection to my WPA2 ap is established on boot, but pretty often I
get an error instead:
iwn0: error, INTR=8200 STATUS=0x1
iwn0: iwn_config: could not set power mode, error 35
Doing one or two "kldunload if_iwn" fixes the problem.
Rarely, I had crashes (on boot).
Today, I found that gavin did a backport of iwn in September:
http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045234.html
As it had some changes compared to the initial perforce version, I tried
that version instead. I always get a crash on boot:
[...]
iwn0: iwn_read_eeprom_ht40: no entry for channel 10
iwn0: iwn_read_eeprom_ht40: no entry for channel 11
iwn0: iwn_read_eeprom_ht40: no entry for channel 12
iwn0: iwn_read_eeprom_ht40: no entry for channel 13
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xc5bb5004
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc1543935
stack pointer = 0x28:0xc18207f8
frame pointer = 0x28:0xc1820858
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processsor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 1s
Automatic reboot in 15 seconds - press a key on the console to abort
I do not remember, if the crash is the same as I had with the initial
perforce version, which I cannot reproduce.
Does anyone have a better version of iwn without vap? Does anyone know
which current / perforce change could address the error mentioned above?
There are only a few differences between the initial perforce version
and the backport by gavin (besides man page). I will attach them below.
Cheers,
Jan Henrik
diff -u perforce/sys/dev/iwn/if_iwn.c gavin/sys/dev/iwn/if_iwn.c
--- perforce/sys/dev/iwn/if_iwn.c 2008-12-19 15:19:14.0
+0100
+++ gavin/sys/dev/iwn/if_iwn.c 2008-12-19 15:16:57.0 +0100
@@ -124,6 +124,7 @@
void iwn_rx_statistics(struct iwn_softc *, struct
iwn_rx_desc *);
void iwn_tx_intr(struct iwn_softc *, struct iwn_rx_desc *);
void iwn_cmd_intr(struct iwn_softc *, struct iwn_rx_desc *);
+static voidiwn_bmiss(void *, int);
void iwn_notif_intr(struct iwn_softc *);
void iwn_intr(void *);
void iwn_read_eeprom(struct iwn_softc *);
@@ -292,7 +293,8 @@
taskqueue_start_threads(&sc->sc_tq, 1, PI_NET, "%s taskq",
device_get_nameunit(dev));
-TASK_INIT(&sc->sc_opstask, 0, iwn_ops, sc );
+TASK_INIT(&sc->sc_ops_task, 0, iwn_ops, sc );
+TASK_INIT(&sc->sc_bmiss_task, 0, iwn_bmiss, sc );
/*
* Put adapter into a known state.
@@ -379,6 +381,8 @@
#endif
| IEEE80211_C_WME /* WME */
;
+#if 0
+ /* XXX disable until HT channel setup works */
ic->ic_htcaps =
IEEE80211_HTCAP_SMPS_ENA /* SM PS mode enabled
*/
| IEEE80211_HTCAP_CHWIDTH40 /* 40MHz channel width
*/
@@ -391,7 +395,7 @@
| IEEE80211_HTC_AMPDU /* tx A-MPDU */
| IEEE80211_HTC_AMSDU /* tx A-MSDU */
;
-
+#endif
/* read supported channels and MAC address from EEPROM */
iwn_read_eeprom(sc);
@@ -1594,6 +1598,15 @@
wakeup(&ring->cmd[desc->idx]);
}
+static void
+iwn_bmiss(void *arg, int npending)
+{
+ struct iwn_softc *sc = arg;
+ struct ieee80211com *ic = sc->sc_ifp->if_l2com;
+
+ ieee80211_beacon_miss(ic);
+}
+
void
iwn_notif_intr(struct iwn_softc *sc)
{
@@ -1652,7 +1665,8 @@
if (ic->ic_state == IEEE80211_S_RUN && misses >
5)
(void) iwn_init_sensitivity(sc);
if (misses >= ic->ic_bmissthreshold)
- ieee80211_beacon_miss(ic);
+ taskqueue_enqueue(taskqueue_swi,
+ &sc->sc_bmiss_task);
break;
}
case IWN_UC_READY: {
@@ -2398,7 +2412,7 @@
static const struct iwn_chan_band iwn_bands[] = {
{ IWN_EEPROM_BAND1, IEEE80211_CHAN_G, 14,
{ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 } },
- { IWN_EEPROM_BAND2, IEEE80211_CHAN_A, 13,
+/* { IWN_EEPROM_BAND2, IEE
7.1-RC2: link_elf: symbol cp_time undefined
During boot I see: link_elf: symbol cp_time undefined I have realized it now with RC2, but looking at my logs, I have had that message during boot since upgrading this machine from 7.0-RELEASE to 7.1-RC1 via freebsd-update a at Dec-8. (I did recompile kernel modules from ports: fusefs-kmod and kqemu-kmod.) What is the easiest way to find out what tried to link to the unknown symbol? The context in which the messages appear is: savecore: no dumps found Initial i386 initialization:. Additional ABI support: linux. Starting local daemons:kldload: can't load ntfs: File exists link_elf: symbol cp_time undefined kldload: can't load linprocfs: No such file or directory link_elf: symbol cp_time undefined mount: linprocfs : Operation not supported by device . Updating motd. Starting fusefs. fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 Mounting late file systems:. In my rc.local, I have kldload ntfs kldload linprocfs mount -t linprocfs linprocfs /usr/compat/linux/proc which used to work (I think). /boot/kernel/linprocfs.ko does exist. Cheers, Jan Henrik ___ 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: 7.1-RC2: link_elf: symbol cp_time undefined
Garrett Cooper wrote: On Dec 25, 2008, at 3:44, Jan Henrik Sylvester wrote: During boot I see: link_elf: symbol cp_time undefined I have realized it now with RC2, but looking at my logs, I have had that message during boot since upgrading this machine from 7.0-RELEASE to 7.1-RC1 via freebsd-update a at Dec-8. (I did recompile kernel modules from ports: fusefs-kmod and kqemu-kmod.) What is the easiest way to find out what tried to link to the unknown symbol? The context in which the messages appear is: savecore: no dumps found Initial i386 initialization:. Additional ABI support: linux. Starting local daemons:kldload: can't load ntfs: File exists link_elf: symbol cp_time undefined kldload: can't load linprocfs: No such file or directory link_elf: symbol cp_time undefined mount: linprocfs : Operation not supported by device . Updating motd. Starting fusefs. fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 Mounting late file systems:. In my rc.local, I have kldload ntfs kldload linprocfs mount -t linprocfs linprocfs /usr/compat/linux/proc which used to work (I think). /boot/kernel/linprocfs.ko does exist. Cheers, Jan Henrik Did you compile your kernel from scratch? -Garrett No, it came with freebsd-update (every possible freebsd-update since the install from the 7.0-BETA4 CD). Outside /etc, the IDS function of freebsd-update only reports a mismatch for /boot/kernel/linker.hints -- can this be the problem? (I will try to replace it tomorrow.) Cheers, Jan Henrik ___ 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: 7.1-RC2: link_elf: symbol cp_time undefined
Garrett Cooper wrote: On Dec 25, 2008, at 17:36, Jan Henrik Sylvester wrote: Garrett Cooper wrote: On Dec 25, 2008, at 3:44, Jan Henrik Sylvester wrote: During boot I see: link_elf: symbol cp_time undefined I have realized it now with RC2, but looking at my logs, I have had that message during boot since upgrading this machine from 7.0-RELEASE to 7.1-RC1 via freebsd-update a at Dec-8. (I did recompile kernel modules from ports: fusefs-kmod and kqemu-kmod.) What is the easiest way to find out what tried to link to the unknown symbol? The context in which the messages appear is: savecore: no dumps found Initial i386 initialization:. Additional ABI support: linux. Starting local daemons:kldload: can't load ntfs: File exists link_elf: symbol cp_time undefined kldload: can't load linprocfs: No such file or directory link_elf: symbol cp_time undefined mount: linprocfs : Operation not supported by device . Updating motd. Starting fusefs. fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 Mounting late file systems:. In my rc.local, I have kldload ntfs kldload linprocfs mount -t linprocfs linprocfs /usr/compat/linux/proc which used to work (I think). /boot/kernel/linprocfs.ko does exist. Cheers, Jan Henrik Did you compile your kernel from scratch? -Garrett No, it came with freebsd-update (every possible freebsd-update since the install from the 7.0-BETA4 CD). Outside /etc, the IDS function of freebsd-update only reports a mismatch for /boot/kernel/linker.hints -- can this be the problem? (I will try to replace it tomorrow.) Cheers, Jan Henrik It shouldn't be the hints file. I would think it's a lack of Linux support built into the updated kernel. I've never used freebsd-upgrade though.. -Garrett Thanks for your answer. The problem is entirely my fault. From 7.0, I still had /boot/ulegeneric in my kern.module_path instead of /boot/kernel -- and /boot/ulegeneric is still there containing a 7.0-p6 kernel with ULE scheduler, of which the modules do not work with the 7.1-RC2 kernel (booted from /boot/kernel). Sorry for the fuss. Cheers, Jan Henrik ___ 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"
7.1 manpages: "first appeared in FreeBSD 8.0"
I found a 7.1-RELEASE manpage stating "first appeared in FreeBSD 8.0". A little bit of grepping revealed a few more: setfib(1) setfib(2) ffs(3) ffsl(3) ffsll(3) fls(3) flsl(3) flsll(3) memchr(3) memrchr(3) malo(4) crashinfo(8) savecore(8) Some others are correctly stating "7.1" for example textdump(4). Cheers, Jan Henrik ___ 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: iwn driver on 7.1
Da Rock wrote: On Sun, 2009-01-18 at 14:17 -0600, Brandon Gooch wrote: I have a working driver for the Intel 4965, aka iwn(4), loaded on my Lenovo X300 running FreeBSD 7.1-RELEASE (amd64). This driver is a slightly-modified version of the iwn(4) driver backported from 8.0-CURRENT by Gavin Atkinson: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=221758+0+/usr/local/www/db/text/2008/freebsd-stable/20080928.freebsd-stable I was seeing the same symptoms described in these threads (among others): http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045264.html http://www.freebsd.org/cgi/getmsg.cgi?fetch=1334322+1338147+/usr/local/www/db/text/2009/freebsd-questions/20090118.freebsd-questions http://www.freebsd.org/cgi/getmsg.cgi?fetch=1418632+1421765+/usr/local/www/db/text/2009/freebsd-questions/20090118.freebsd-questions ...so I debugged and modified Gavin's driver for my system. The driver and the source tree diff can be downloaded here for any brave souls wanting to test it out: http://sites.google.com/site/bsdgooch/files I'm using the driver now to send this e-mail over a link to my TP-LINK TL-WR941ND access point (with WPA2). Feedback and bug reports would be useful. -brandon Sounds like you got to it before I did- thank god! :) Question though: have you got it figured for a channels yet? I'll test it for you and keep you updated with my results. Thanks for working on the driver! The only difference to the version of gavin that I could see is that the bands in iwn_bands that got commented out were brought back. Or did I miss something? Do you know why they were commented out and it was unnecessary? Or was it just to fix the crash? I did a few test runs: It does not crash immediately as the version from gavin, but the error I had with the perforce version iwn0: error, INTR=8200 STATUS=0x1 iwn0: iwn_config: could not set power mode, error 35 is there -- in 3 out of 3 tries. So nothing improved there. (I hit that error on first use in about 50% of the cases before.) Moreover, at 3 out of 4 tries to 'kldunload if_iwn' after hitting the error (after '/etc/rc.d/netif stop iwn0' and 'ifconfig iwn0 down'), there was a crash: 2 page faults and 1 freeze. I have not had that with the perforce version. (Maybe once long ago, but I think I forgot to stop iwn0 at that time.) The one time I actually got the (WPA2) connection up, I was able to transfer with a similar speed as with the perforce version. Thus, for me, there are no improvement over the (old) perforce version. Probably by chance, but I had more crashes. I think the thread on stable@ should rather be continued than the one on questions@, but since Da Rock answered on questions@, I reinclude both. Cheers, Jan Henrik ___ 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: iwn driver on 7.1
Torfinn Ingolfsen wrote: On Sun, 18 Jan 2009 14:17:39 -0600 Brandon Gooch wrote: I have a working driver for the Intel 4965, aka iwn(4), loaded on my Lenovo X300 running FreeBSD 7.1-RELEASE (amd64). FWIW, I am using the latest perforce version of the iwn driver as documented here[1] on a ThinkPad T61 running FreeBSD 7.1-stable / i386 - no modifications necessary. It works great. I just use the p4fetch.rb script to get the driver. HTH References: 1) http://clearchain.com/wiki/iwn Since from that address, you are using the latest version of the benjsc perforce branch, you are probably using the same as I, since I took the initial version from the sam_vap branch (before vap got introduced). I do not know how far it is, but there is vap_releng7 in the sam perforce and projects/vap7 in svn on which Sam Leffler is actively working: http://lists.freebsd.org/pipermail/svn-src-projects/2009-January/thread.html I would like to have if_iwn working on a otherwise unmodified 7.1-RELEASE-pX and help to test it, but maybe waiting on sam to bring vap to 7 would be a better way to go. Cheers, Jan Henrik ___ 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: if_wpi is all kinds of broken
On 01/-10/63 19:59, Dominic Fandrey wrote: The if_wpi driver is all kinds of broken. The reported problems I have had trouble with all Intel drivers, ipw, iwi, wpi, and iwn. (As an exception, recently, iwn was very stable on 8-STABLE.) For most notebooks, I bought Atheros based MiniPCI(e) cards and everything was fine. Where do I have to put my cash to make somebody fix this? 5 to 10 Euros on Ebay including shipping. Initially, I was hesitant, too, because I wanted the hardware I already got to work, but eventually I decided that it is not worse it. ath simply works. (I have had wi, ral, ural, rum, and zyd, too. Over the years, nothing was as unproblematic as ath.) For most notebooks, the wireless MiniPCI(e) card is very easy to replace. Cheers, Jan Henrik ___ 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 with fusefs-ntfs on FreeBSD 9 RC1 amd64
On 09/18/2012 18:14, Marcelo Gondim wrote: I installed the package ntfs-fusefs on two different servers and both causes kernel panic when trying to copy anything. I got panics, too, but found some patch that I attached to ports/169165. Unfortunately, the maintainer of sysutils/fusefs-kmod (Cced) did not reply for the last four weeks. It could be committed due to a maintainer timeout. Cheers, Jan Henrik ___ 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: libopie problems after upgrade to 10.2
On 08/15/2015 20:47, Chris Anderson wrote: > just upgraded from 10.1-RELEASE-p16 to 10.2-RELEASE using freebsd-update. > > after the upgrade, I began getting errors because pam_opie.so.5 has an > unsatisfied link to libopie.so.7 (my system only has libopie.so.8). > > I notice a fresh install of 10.2-RELEASE does indeed contain libopie.so.7, > so I'm curious how I managed to get into this state in the first place and > whether it is anything I should worry about. This machine has only been > upgraded using freebsd-update and I'm pretty sure it started from > 10.0-RELEASE. I did the same update using freebsd-update and I do not have libopie.so.8 that should not be in any 10.X-RELEASE. libopie.so.8 was in stable/10 shortly after 10.0-RELEASE, but was set back again to libopie.so.7 between 10.1-RC1 and 10.1-RELEASE: https://svnweb.freebsd.org/base/releng/10.1/lib/libopie/Makefile?view=log&pathrev=273169 Your problem was probably not introduced during the 10.1-RELEASE to 10.2-RELEASE upgrade but earlier. I have a system that had just about every BETA, RC, and RELEASE starting from 9.0-RC1 using freebsd-update binary upgrades only, including some BETA or RC of 10.1 with libopie.so.8... that system has only libopie.so.7 now as it should have. Maybe you forgot the "removing of old libraries" step of "freebsd-update install" after "freebsd-update upgrade" around 10.1-RC3, because you did not expect it on a stable branch? Cheers, Jan Henrik ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: libopie problems after upgrade to 10.2
On 08/16/2015 19:47, Kimmo Paasiala wrote: > On Sun, Aug 16, 2015 at 8:40 PM, Jan Henrik Sylvester wrote: >> On 08/15/2015 20:47, Chris Anderson wrote: >>> just upgraded from 10.1-RELEASE-p16 to 10.2-RELEASE using freebsd-update. >>> >>> after the upgrade, I began getting errors because pam_opie.so.5 has an >>> unsatisfied link to libopie.so.7 (my system only has libopie.so.8). >>> >>> I notice a fresh install of 10.2-RELEASE does indeed contain libopie.so.7, >>> so I'm curious how I managed to get into this state in the first place and >>> whether it is anything I should worry about. This machine has only been >>> upgraded using freebsd-update and I'm pretty sure it started from >>> 10.0-RELEASE. >> >> I did the same update using freebsd-update and I do not have >> libopie.so.8 that should not be in any 10.X-RELEASE. >> >> libopie.so.8 was in stable/10 shortly after 10.0-RELEASE, but was set >> back again to libopie.so.7 between 10.1-RC1 and 10.1-RELEASE: >> >> https://svnweb.freebsd.org/base/releng/10.1/lib/libopie/Makefile?view=log&pathrev=273169 >> >> Your problem was probably not introduced during the 10.1-RELEASE to >> 10.2-RELEASE upgrade but earlier. >> >> I have a system that had just about every BETA, RC, and RELEASE starting >> from 9.0-RC1 using freebsd-update binary upgrades only, including some >> BETA or RC of 10.1 with libopie.so.8... that system has only >> libopie.so.7 now as it should have. Maybe you forgot the "removing of >> old libraries" step of "freebsd-update install" after "freebsd-update >> upgrade" around 10.1-RC3, because you did not expect it on a stable branch? >> >> Cheers, >> Jan Henrik > > > As far as I know freebsd-update(8) should handle the obsolete files > automatically, it's only when you're building from source you have to > remember to do 'make delete-old delete-old-libs'. If freebsd-update(8) > fails to delete the obsolete files it's a flaw in it that should be > reported with a PR. In general, you need 3 runs of "freebsd-update install", one for installing the kernel, one for installing the userland, and one for removing obsolete shared libraries (see install_files in freebsd-update). Of course, the third run is usually not needed during minor version upgrades, but it was needed between 10.1-RC2 and 10.1-RC3. Although you get a message about the necessary third run, you may forget about it anyhow. That was my speculation. Rethinking the problem, that is probably not it, since both libopie.so.7 and libopie.so.8 would be present in that case. Cheers, Jan Henrik ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: usb mouse
Vladimir Botka wrote: > Can anybody help me please with usb mouse? There is uhid driver > attached. Keyboard works fine. When I once tried a Microsoft cordless USB mouse, I only got an uhid0, too. After some research, the best answer I found was this: http://lists.freebsd.org/pipermail/freebsd-hardware/2006-July/003621.html Later, I came across this, which might have something to do with it: http://www.freebsd.org/cgi/query-pr.cgi?pr=63837&cat= Since I had already given up on the MS mouse and replaced it with something civilized, I do not know if it is the same problem, if the "better" code from NetBSD got imported by now, and -- in case the former has to be answered with "no" -- if the patch is of any help. If you do further research, I would like to hear of the results. Thanks. Regards, Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.3-BETA1: acpi_tz0: _TMP value is absurd, ignored (-13.4C)
I upgraded an old machine from 6.2-RELEASE-p7 to 6.3-BETA1 (via freebsd-update). Now every ten seconds I get: acpi_tz0: _TMP value is absurd, ignored (-13.4C) At the same time, I have: hw.acpi.thermal.tz0.temperature: -273.2C The machine has a Gigabyte GA-686BX board with Intel 82440 BX chipset (nine years old). I do not know what the temperature was on 6.2, but I did not get the dmesg output. If that is interesting, I could rollback the upgrade. Anything I can do but setting hw.acpi.thermal.polling_rate to 0? Thanks, Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
freebsd-update 6.2-R -> 6.3-B1 rollback failed
I tried to rollback the freebsd-update 6.2-R -> 6.3-B1. (The reason was to freebsd-update to 6.3-B2 with the possibility of doing a rollback to 6.2-R.) It printed quite a few lines of /libexec/ld-elf.so.1: grep: Undefined symbol "__sbmaskrune" and /libexec/ld-elf.so.1: sort: Undefined symbol "__sbmaskrune" but finished with a 'done.' Thus I did a reboot. It rebooted into 6.3-B1 and because of the missing symbol nothing but the stuff in /rescue works. I guess it was my fault, because on some of my 6.2 machines I had a patch for libexec/rtld-elf/rtld.c adding the symbol _dlsym that was needed for linux-flashplugin-7 at some time. This was probably one of these machines that had a GENERIC/SMP kernel but modified elf loader. Anyhow, if that really is the cause, IMHO the update should have complained about the incorrect file and not have the rollback fail. (6.3-B1 was running fine.) Now, how do I get this machine running again? I tried to replace ld-elf.so.1 with a copy from a GENERIC 6.2-R, but this obviously cannot work, since the kernel booting is still 6.3-B1. I guess I need the file from that version, but I do not have another 6.3-B* here. Could anybody send me ld-elf.so.1 from 6.3-B* via email? Or do I have it in some temporary directory from freebsd-update? In case I get the machine to boot again, how should I proceed? Is the machine now a mixture of 6.2-R and 6.3-B1? Can I get it into a sane state without recompiling the kernel? (The machine is _really_ slow.) If my modified 6.2-R version of ld-elf.so.1 was the cause of all this, freebsd-update should print a warning asking the user if really all of the kernel is GENERIC/SMP or better check for it. Otherwise, this really is a bug. At least now I do know what /rescue is for... Thanks, Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-update 6.2-R -> 6.3-B1 rollback failed
Colin Percival wrote: Jan Henrik Sylvester wrote: I tried to rollback the freebsd-update 6.2-R -> 6.3-B1. To confirm that I understand what you're saying here: You upgraded from FreeBSD 6.2-RELEASE to 6.3-BETA1, then you ran "freebsd-update rollback" to move back to FreeBSD 6.2-RELEASE, right? 'sh freebsd-update.sh -f freebsd-update.conf rollback' was the command, but that is correct. Nope, not your fault -- I screwed up the rollback code. I did not think I was the first to do this rollback -- good that I tested it. Now, how do I get this machine running again? I believe that your system is now 6.3-BETA1 with a few shared libraries from 6.2-RELEASE mixed in. If you can get a copy of /lib/*.so.* and /usr/lib/*.so.* from a 6.3-BETA1 system and install those into place (in fact, probably all you need is /lib/libc.so.6) your system should be ok. Let me know if you need any help with this. I guess I can download a 6.3-BETA1 cd and copy the files over from there. If you have a better way, please, let me know. Getting the system back to 6.2-RELEASE might be more difficult, now that the FreeBSD Update code thinks that it has rolled back its updates, but I might be able to find a way to do that for you -- is it a disaster if this system ends up stuck at 6.3-BETA1? Not to be able to go back to 6.2-RELEASE is ok. If updating to 6.3-BETA2 (and eventually perhaps 7.0) is not possible because of the mixed system, it will limit my testing and I will have to reinstall at some point, which would not be a disaster, either. (Sometimes I do testing that feels rather save on my main working machine -- I am glad I was not so insane this time.) Is there any cleanup to do besides replacing the libs (such as removing temporary freebsd-update directories)? Since your blog seems not to tell and there is no other documentation: Is freebsd-update -r supposed to work if not all files are from GENERIC/SMP? Does it skip files or overwrite them with GENERIC versions? (For security updates, the former might be desirable, but for updates between releases, only the latter would make sense to me.) Thanks, Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-update 6.2-R -> 6.3-B1 rollback failed
Colin Percival wrote: Jan Henrik Sylvester wrote: Colin Percival wrote: I believe that your system is now 6.3-BETA1 with a few shared libraries from 6.2-RELEASE mixed in. If you can get a copy of /lib/*.so.* and /usr/lib/*.so.* from a 6.3-BETA1 system and install those into place (in fact, probably all you need is /lib/libc.so.6) your system should be ok. Let me know if you need any help with this. I guess I can download a 6.3-BETA1 cd and copy the files over from there. If you have a better way, please, let me know. That's probably the safest approach. Theoretically you could get all of There are no more BETA1 images on FTP -- I should have thought of that. My next idea would be to use libs from a BETA2 cd to try to make the system bootable again. If that worked, I would have a system with BETA1 / BETA2 mixture... would freebsd-update be able to bring that to BETA2 or would it fail? (I could answer that myself, if I knew the answer to the question at the bottom.) Or should I install BETA2 from cd on top of it? (I have never done that, but I assume that is possible without reinstalling all packages as well.) In short, as long as you don't build a custom kernel but call it "GENERIC" or "SMP", FreeBSD Update should automatically DTRT. That is exactly my question. On 6.2-RELEASE, I sometimes used a modified ld-elf.so.1 or a single patched module without recompiling the kernel. What does using freebsd-update (accidentally or deliberately) do in that case? By accident, I discovered that it does not always fail. Does it skip the modified files, overwrite them with new versions, or overwrite them with an unpredictable bdiff merge that is likely garbage? (From my observations, I assume that it does the second -- but maybe that was just luck.) Thanks, Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-update 6.2-R -> 6.3-B1 rollback failed
Colin Percival wrote: Depending on the UpdateIfUnmodified option in freebsd-update.conf, it will either update files to "clean" new versions or print a warning message and not touch them. There's also an IgnorePaths directive which you can use to tell FreeBSD Update not to touch some files (even if they haven't been modified locally). FreeBSD Update will never produce mangled files as a result of applying a bsdiff patch to the wrong file -- it checks file hashes before and after applying patches and gracefully falls back to downloading complete files if it can't generate a file via patching. If freebsd-update allowed an 'upgrade' to the version already installed, one could (mis)use it as a tool to repair a 'broken' system... (probably a naive idea.) Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Monitor not working for iwi on 7.0-BETA4
After reading that someone had problems with 802.11i/WPA2, I tested my iwi device, too. 802.11i (as client) works, but disconnects about every five minutes briefly, which is nothing new -- I had the same issue with 6.2-RELEASE. In contrast to 6.2-RELEASE, monitor does not work. Kismet does not receive anything, while it does with ath or ural (even at the same time). dmesg with debug.iwi=2 is below -- anything unusual? Moreover, "ifconfig iwi0 scan" sometimes just hangs, which never happened on 6.2-RELEASE. I currently cannot reproduce it, though. Another behavior that changed is "iwi0: radio turned off" being always displayed when something fails because of it -- and not as the switch is turned off. "iwi0: radio turned on" is never displayed. I guess that is expected. (I think I like the new behavior better.) Something that really got better is that the device sometimes recovers from firmware errors without me kldunloading if_iwi and I have yet to see not enough dma memory for the firmware. (Firmware errors happened regularly with 6.2-RELEASE. I did not test enough to say if that got any better.) BTW: Playing around with iwi, ath, and ural removing and plugging back in the devices (not iwi), I had two crashes. I am not sure how to investigate that, though. (It produced vmcores on reboot -- I guess I have to read that chapter on kernel debugging in the handbook.) Regards, Jan Henrik iwi_newstate: INIT -> INIT flags 0x0 enter FW state 1 Setting MAC address to 00:0e:35:91:2b:0b sending command idx=0 type=11 len=6 Configuring adapter sending command idx=1 type=6 len=20 Setting power mode to 0 sending command idx=2 type=17 len=4 Setting RTS threshold to 2346 sending command idx=3 type=15 len=4 Setting fragmentation threshold to 2346 sending command idx=4 type=16 len=4 Setting .11bg supported rates (12) sending command idx=5 type=22 len=16 Setting .11a supported rates (0) sending command idx=6 type=22 len=16 Setting initialization vector to 3524349664 sending command idx=7 type=34 len=4 Setting wep key index 0 len 0 sending command idx=8 type=18 len=20 Setting wep key index 1 len 0 sending command idx=9 type=18 len=20 Setting wep key index 2 len 0 sending command idx=10 type=18 len=20 Setting wep key index 3 len 0 sending command idx=11 type=18 len=20 Enabling adapter sending command idx=12 type=2 len=0 iwi_newstate: INIT -> RUN flags 0x1 iwi_newstate: RUN -> RUN flags 0x1 exit FW state 1 Setting WME parameters sending command idx=13 type=25 len=96 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Status of PCIe Hotplug?
On 09/27/2016 12:16, Borja Marcos wrote: > I have noticed that the GENERIC kernel in 11-STABLE includes the PCI_HP > option, and the > hotplug bits seem to be present in the kernel, but I don’t see any userland > support for it. > > Is it somewhat complete and in that case am I missing something? I do not know kind of userland support you mean. I just tried: Plugging in my USB 3.0 ExpressCard while 11.0 is running, the controller was detected and I was able to use USB devices with it. Great. Unplugging the ExpressCard led to a panic two out of two trials, no matter if I had used it for USB devices before or not. So we have hotplug, but no hotunplug... With 10.3, it was the other way around. Of course, there was no hotplug, but when I accidentally pulled the ExpressCard, the USB controller would just disappear and never reappear without a panic. I do not know what I like better, though. Cheers, Jan Henrik ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Status of PCIe Hotplug?
On 09/27/2016 17:51, Eric van Gyzen wrote: > In the case of Jan's USB 3.0 ExpressCard, it's possible that one or all > of the USB controller drivers (xhci, ehci, uhci) didn't cope with the > surprise removal of the controller. Before removing the card, try > detaching the driver(s) with "devctl detach xhciN". There might be more > than one device. Use "pciconf -lc" to find the HotPlug-capable pcib > devices (bridges). Use devinfo to find which one is your ExpressCard > slot and find all the devices attached to it. Then use devctl to detach > the devices. There could be a tree of devices; in that case, you can > usually start at the level immediately under pcibN; you don't need to > detach every device from the bottom up. Once all the devices are > detached, you should be able to remove the card safely. Doing "devctl detach xhci0" before the removal of the USB 3.0 ExpressCard, there is no panic, the device gets deattached properly, and I can reconnect it later. Anyhow, because the mechanism holding the ExpressCard is not completely reliable, on the third time inserting the card, it did not hold and I got a panic, because it was immediately ejected without devctl detach. Due to the card not holding firmly, I often pulled it together with the usb device on 10.3-RELEASE and never got a panic. I guess it is a regression in the usb driver dealing with sudden loss of the device. The panic message is below, I guess I should take this discussion to freebsd-usb@, CCed. Thanks, Jan Henrik Fatal trap 9: general protection fault while in kernel mode cpuid = 1; acpic id = 01 instruction pointer = 0x20:0x80b1549c stack pointer = 0x28:0xfe022f62ca00 frame pointer = 0x28:0xfe022f62ca70 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 14 (usbus1) trap number = 9 panic: general protection fault cpuid = 1 KDB: stack backtrace: #0 0x80b24077 at kdb_backtrace+0x67 #1 0x80ad93e2 at vpanic+0x182 #2 0x80ad9253 at panic+0x43 #3 0x80fa0d31 at trap_fatal+0x351 #4 0x80fa09c8 at trap+0x768 #5 0x80f84141 at calltrap+0x8 #6 0x808f2f63 at usb_detach_device+0xf3 #7 0x808f1d5b at usb_unconfigure+0x2b #8 0x808f5623 at usb_free_device+0x103 #9 0x808f58b1 at usb_bus_detach+0x161 #10 0x80903e95 at usb_process+0x125 #11 0x80a90055 at fork_exit+0x85 #12 0x80f8467e at fork_trampoline+0xe Uptime: 18m27s Automatic reboot in 15 seconds - press a key on the console to abort ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sysutils/fusefs-ntfs working for anyone?
On 6.2-RELEASE using fusefs-kmod-0.3.0_4, fusefs-libs-2.6.2, and fusefs-ntfs-0.20070207RC1, I can mount my existing (Windows XP) NTFS partition with 'ntfs-3g /dev/ad0s1 /mnt/ad0s1'. The following error messages about missing /proc/filesystems and modprobe can be ignored, since defaults are assumed in case of missing information. (I read about it on a fusefs mailing list concerning Darwin.) Reading from the ntfs slice works ok as I get about 12MB/s copying a 200MB file, but writing to it does not give the results I was expecting from the claims at the ntfs-3g website: only 44KB/s copying a 4MB file. Thus, basically it works thought writing is terribly slow. Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RT2561 does not work (was: [CALL FOR TESTERS] (was: ral(4) and second/third gen devices))
Hi! I have got a RT2561 based card (not deliberately, wanted RT2500): ral0: mem 0xd800-0xd8007fff irq 10 at device 10.0 on pci0 ral0: MAC/BBP RT 2661B, RF RT2527 ral0: Ethernet address: 00:80:5a:38:XX:XX Some searching led me to: http://samodelkin.net/~fjoe/if_ral.diff -- which compiles on 6.2-RELEASE and, loaded as module, makes the card available. At first, I could not see (ifconfig ral0 up scan) any APs. After many tries I tried on a Linux system installed parallel with the vendor supplied RT61 driver -- the AP showed up (iwlist ra0 scanning). (Connecting was not possible due to unrelated wpa_supplicant problems on Linux.) Rebooting to FreeBSD (directly after seeing the AP on Linux), the AP showed up and I was able to associate to it using wpa_supplicant. With the appropriate configuration, this link was reestablished automatically on the next few reboots. Anyhow, it did not run totally satisfactorily as I was only able to scp with 150KB/s (for comparison I plugged in a ural device and got 1.5MB/s). Later I could not see the AP, again. After kldunloading and kldloading if_ral it reappeared (downing and upping with ifconfig did not help). A few days later (the computer was unplugged), the AP does not show up anymore no matter what I try, but it is visible from Linux. Any ideas? Is it possible that some state is kept in the card on reboot (from Linux to FreeBSD) or is it totally unrelated that I first saw the AP directly after seeing it on Linux? Is it possible that the driver does not correctly initialize the card? Is there any newer driver available? Do you want any other tests or information? Any chance that I get that running reliable? (The connection speed problem is not that important. I hoped to replace an unreliable Debian Sarge/zyd(USB-ZD1211) system with FreeBSD/ral(PCI-RT2500), what did not work out quite as expected...) Thanks Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
freebsd-update changes kernel to SMP-GENERIC
Hello! Before the last freebsd-update, I had a GENERIC kernel installed. Now 'uname -v -i' gives me: FreeBSD 6.2-RELEASE-p2 #0: Tue Feb 27 22:56:09 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP SMP-GENERIC Did something go wrong? Does SMP have any negative side effects (Pentium M)? Should I rollback? (Is this related to FreeBSD-EN-07:05.freebsd-update.asc?) Thanks Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
freebsd-update changes kernel to SMP-GENERIC
Colin Percival wrote: > Jan Henrik Sylvester wrote: > > Before the last freebsd-update, I had a GENERIC kernel installed. > > Are you sure? :-) I was... since I "always" had one, but looking at my old logs, I found: FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP Sorry for bothering you! (kern.bootfile: /boot/kernel/kernel) Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
