Re: ttydev_cdevsw has no d_purge
Hi,
I've updated the ucom patch.
1) Use unrhdr. Suggested by ed.
2) Implement tty_set_softc() and use that when dereffing ucom unit numbers.
Please test and report back.
--HPS
=== sys/tty.h
==
--- sys/tty.h (revision 239054)
+++ sys/tty.h (local)
@@ -199,6 +199,7 @@
#define tty_opened(tp) ((tp)-t_flags TF_OPENED)
#define tty_gone(tp) ((tp)-t_flags TF_GONE)
#define tty_softc(tp) ((tp)-t_devswsoftc)
+#define tty_set_softc(tp,sc) do { (tp)-t_devswsoftc = (sc); } while (0)
#define tty_devname(tp) devtoname((tp)-t_dev)
/* Status line printing. */
=== dev/usb/serial/usb_serial.c
==
--- dev/usb/serial/usb_serial.c (revision 239054)
+++ dev/usb/serial/usb_serial.c (local)
@@ -146,7 +146,7 @@
static int ucom_unit_alloc(void);
static void ucom_unit_free(int);
static int ucom_attach_tty(struct ucom_super_softc *, struct ucom_softc *);
-static void ucom_detach_tty(struct ucom_softc *);
+static void ucom_detach_tty(struct ucom_super_softc *, struct ucom_softc *);
static void ucom_queue_command(struct ucom_softc *,
usb_proc_callback_t *, struct termios *pt,
struct usb_proc_msg *t0, struct usb_proc_msg *t1);
@@ -178,14 +178,33 @@
MODULE_DEPEND(ucom, usb, 1, 1, 1);
MODULE_VERSION(ucom, 1);
-#define UCOM_UNIT_MAX 128 /* limits size of ucom_bitmap */
+#define UCOM_UNIT_MAX 128 /* maximum number of units */
+#define UCOM_TTY_PREFIX U
-static uint8_t ucom_bitmap[(UCOM_UNIT_MAX + 7) / 8];
-static struct mtx ucom_bitmap_mtx;
-MTX_SYSINIT(ucom_bitmap_mtx, ucom_bitmap_mtx, ucom bitmap, MTX_DEF);
+static struct unrhdr *ucom_unrhdr;
-#define UCOM_TTY_PREFIX U
+static void
+ucom_init(void *arg)
+{
+ DPRINTF(\n);
+ ucom_unrhdr = new_unrhdr(0, UCOM_UNIT_MAX - 1, NULL);
+}
+SYSINIT(ucom_init, SI_SUB_KLD, SI_ORDER_ANY, ucom_init, NULL);
+static void
+ucom_uninit(void *arg)
+{
+ struct unrhdr *hdr;
+ hdr = ucom_unrhdr;
+ ucom_unrhdr = NULL;
+
+ DPRINTF(\n);
+
+ if (hdr != NULL)
+ delete_unrhdr(hdr);
+}
+SYSUNINIT(ucom_uninit, SI_SUB_KLD, SI_ORDER_ANY, ucom_uninit, NULL);
+
/*
* Mark a unit number (the X in cuaUX) as in use.
*
@@ -197,21 +216,14 @@
{
int unit;
- mtx_lock(ucom_bitmap_mtx);
-
- for (unit = 0; unit UCOM_UNIT_MAX; unit++) {
- if ((ucom_bitmap[unit / 8] (1 (unit % 8))) == 0) {
- ucom_bitmap[unit / 8] |= (1 (unit % 8));
- break;
- }
+ /* sanity checks */
+ if (ucom_unrhdr == NULL) {
+ DPRINTF(ucom_unrhdr is NULL\n);
+ return (-1);
}
-
- mtx_unlock(ucom_bitmap_mtx);
-
- if (unit == UCOM_UNIT_MAX)
- return -1;
- else
- return unit;
+ unit = alloc_unr(ucom_unrhdr);
+ DPRINTF(unit %d is allocated\n, unit);
+ return (unit);
}
/*
@@ -220,11 +232,13 @@
static void
ucom_unit_free(int unit)
{
- mtx_lock(ucom_bitmap_mtx);
-
- ucom_bitmap[unit / 8] = ~(1 (unit % 8));
-
- mtx_unlock(ucom_bitmap_mtx);
+ /* sanity checks */
+ if (unit 0 || unit = UCOM_UNIT_MAX || ucom_unrhdr == NULL) {
+ DPRINTF(cannot free unit number\n);
+ return;
+ }
+ DPRINTF(unit %d is freed\n, unit);
+ free_unr(ucom_unrhdr, unit);
}
/*
@@ -248,11 +262,21 @@
return (EINVAL);
}
+ ssc-sc_ref = malloc(sizeof(*ssc-sc_ref), M_USBDEV,
+ M_WAITOK | M_ZERO);
+ if (ssc-sc_ref == NULL)
+ return (ENOMEM);
+
/* allocate a uniq unit number */
ssc-sc_unit = ucom_unit_alloc();
- if (ssc-sc_unit == -1)
+ if (ssc-sc_unit == -1) {
+ free(ssc-sc_ref, M_USBDEV);
return (ENOMEM);
+ }
+ /* store unit number for later */
+ ssc-sc_ref-unit = ssc-sc_unit;
+
/* generate TTY name string */
snprintf(ssc-sc_ttyname, sizeof(ssc-sc_ttyname),
UCOM_TTY_PREFIX %d, ssc-sc_unit);
@@ -260,7 +284,7 @@
/* create USB request handling process */
error = usb_proc_create(ssc-sc_tq, mtx, ucom, USB_PRI_MED);
if (error) {
- ucom_unit_free(ssc-sc_unit);
+ ucom_free(ssc-sc_ref);
return (error);
}
ssc-sc_subunits = subunits;
@@ -277,6 +301,10 @@
ucom_detach(ssc, sc[0]);
return (error);
}
+ /* increment unit reference count */
+ ssc-sc_ref-refs++;
+
+ /* set subunit attached */
sc[subunit].sc_flag |= UCOM_FLAG_ATTACHED;
}
@@ -310,16 +338,19 @@
usb_proc_drain(ssc-sc_tq);
+ /* if there are no TTYs we need to free the ref structure */
+ if (ssc-sc_ref-refs == 0)
+ ucom_free(ssc-sc_ref);
+
for (subunit = 0; subunit ssc-sc_subunits; subunit++) {
if (sc[subunit].sc_flag UCOM_FLAG_ATTACHED) {
- ucom_detach_tty(sc[subunit]);
+ ucom_detach_tty(ssc, sc[subunit]);
/* avoid duplicate detach */
sc[subunit].sc_flag = ~UCOM_FLAG_ATTACHED;
}
}
- ucom_unit_free(ssc-sc_unit);
usb_proc_free(ssc-sc_tq);
}
@@ -356,7 +387,6 @@
sc-sc_tty = tp;
DPRINTF(ttycreate: %s\n, buf);
- cv_init(sc-sc_cv, ucom);
/* Check if this device should be a console */
if ((ucom_cons_softc == NULL)
@@ -388,7 +418,7 @@
}
static void
-ucom_detach_tty(struct ucom_softc *sc)
+ucom_detach_tty(struct ucom_super_softc *ssc,
Re: geom mirror now rebuilding on every reboot?
Alexander Motin wrote: I think the right answer would be to remove stale Promise format RAID metadata from the disk. You should be able to do it by booting from any source and doing `graid list -a` to see all RAID GEOMs (even broken) and then remove them with `graid remove Promise ad4`. thanks, that fixed it. tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Speaking of ship blockers for 9....
Ian, On Tue, Aug 07, 2012 at 08:17:56PM +0200, Ian FREISLICH wrote: I I have a problem that's been getting progressively worse as the I source progresses. So much so that it's had me searching all the I way from 8.0-RELEASE to 10-CURRENT without luck on both amd64 and I i386. I I pf(4) erroneously mismatches state and then blocks an active flow. I It seems that 8.X does so silently and 9 to -CURRENT do so verbosely. I Whether silent or loud, the effect on traffic makes it impracticle I to use FreeBSD+PF for a firewall in any setting (my use is home, I small office, large office and moderately large datacenter core I router). It appears that this has actually been a forever problem I that just being tickled more now. ... I ... I state-mismatch2777673.6/s I I That's 277767 flows terminated in the last almost 22 hours due to I this pf bug. (!!!) I I 9.1-PRERELEASE logs (as does -CURRENT): I Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:60985, a1: 192.41.162.30:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Let me give you link to my branch of pf: http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006643.html http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006662.html In that branch the code that puts the reverse pointer on state keys, as well as the m_addr_changed() function and the pf_compare_state_keys() had been cut away. So, this exact bug definitely can't be reproduced there. However, others may hide in :) Let me encourage you to try and test my branch (instructions in URLs above). P.S. I plan to merge it to head at the and of August. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/8/2012 2:39 PM, Mike Tancsa wrote: On 8/8/2012 7:27 AM, John Baldwin wrote: Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able to see the 8006 controller I added. Ugh, ok. A few questions: 1) Does the driver see any attached drives/volumes? Yes 2) If it does, does basic I/O to the drives work? yes 3) Can you add some debugging printfs to twe_ioctl() to see what, if anything, fails in that routine when tw_cli makes a request? Yes, for sure. Let me know what you would like me to add. One more data point, /dev/twe0 does not exist with the patch and I think thats why the utils fail outright. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [clang] kernel build failure
On Thu, Aug 09, 2012 at 04:15:36PM +0400, Boris Samorodov wrote: Hi! The kernel build fails at fresh CURRENT... And then I get an error: - linking kernel.debug cam_periph.o: In function `cam_periph_error': /usr/src/sys/cam/cam_periph.c:1776: undefined reference to `scsi_extract_sense_ccb' scsi_cd.o: In function `cdasync': /usr/src/sys/cam/scsi/scsi_cd.c:571: undefined reference to `scsi_extract_sense_ccb' scsi_da.o: In function `daasync': /usr/src/sys/cam/scsi/scsi_da.c:1394: undefined reference to `scsi_extract_sense_ccb' *** [kernel.debug] Error code 1 - The system...: - % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #21 r238828M: Fri Jul 27 16:26:02 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 - I had no trouble (just now); was running: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #645 239138M: Wed Aug 8 04:44:43 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 now running: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #646 239148M: Thu Aug 9 05:04:05 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpAKLjALFtGI.pgp Description: PGP signature
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/9/12 8:22 AM, Mike Tancsa wrote: On 8/8/2012 2:39 PM, Mike Tancsa wrote: On 8/8/2012 7:27 AM, John Baldwin wrote: Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able to see the 8006 controller I added. Ugh, ok. A few questions: 1) Does the driver see any attached drives/volumes? Yes 2) If it does, does basic I/O to the drives work? yes Ok, so that's good. I didn't break anything fundamental with driver commands. 3) Can you add some debugging printfs to twe_ioctl() to see what, if anything, fails in that routine when tw_cli makes a request? Yes, for sure. Let me know what you would like me to add. One more data point, /dev/twe0 does not exist with the patch and I think thats why the utils fail outright. Oh, hmm. That's odd. Do you get any error messages on the console when twe0 attaches? Also, you have INVARIANTS enabled, yes? (make_dev() panics when it fails if INVARIANTS is enabled). Maybe try something like this (relative to the patched driver): --- //depot/user/jhb/cleanup/sys/dev/twe/twe_freebsd.c 2012-08-03 18:10:04.0 +++ /Users/jhb/work/p4/cleanup/sys/dev/twe/twe_freebsd.c2012-08-03 18:10:04.0 @@ -342,9 +342,12 @@ /* * Create the control device. */ +device_printf(sc-twe_dev, Calling make_dev()\n); sc-twe_dev_t = make_dev(twe_cdevsw, device_get_unit(sc-twe_dev), UID_ROOT, GID_OPERATOR, S_IRUSR | S_IWUSR, twe%d, device_get_unit(sc-twe_dev)); sc-twe_dev_t-si_drv1 = sc; +device_printf(sc-twe_dev, make_dev() returned %p (%s)\n, sc-twe_dev_t, + sc-twe_dev_t-si_name); /* * Schedule ourselves to bring the controller up once interrupts are available. * This isn't strictly necessary, since we disable interrupts while probing the -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkg and portmaster: Downgrading ports? Why? portmaster messes up ...
On 7 Aug 2012 15:50, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: On 08/07/12 15:39, Bryan Drewery wrote: On 8/7/2012 4:31 AM, O. Hartmann wrote: ports-mgmt/portmaster installs still the old fashioned style folders of ports in /var/db/pkg. I thought ith the new scheme of pkg, everything is going into a file based SQLite3 DB? Also ensure WITH_PKGNG=yes is in your /etc/make.conf. My last comment still stands though, portmaster will store distifile information in /var/db/pkg. WITH_PKGNG=yes is set in /etc/make.conf. Also in your portmasterrc? Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkg and portmaster: Downgrading ports? Why? portmaster messes up ...
2012/8/9 Chris Rees utis...@gmail.com: On 7 Aug 2012 15:50, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: On 08/07/12 15:39, Bryan Drewery wrote: On 8/7/2012 4:31 AM, O. Hartmann wrote: ports-mgmt/portmaster installs still the old fashioned style folders of ports in /var/db/pkg. I thought ith the new scheme of pkg, everything is going into a file based SQLite3 DB? Also ensure WITH_PKGNG=yes is in your /etc/make.conf. My last comment still stands though, portmaster will store distifile information in /var/db/pkg. WITH_PKGNG=yes is set in /etc/make.conf. Also in your portmasterrc? Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org You can use this patch. patch-portmaster-pkgng-3.13.13 Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/9/2012 9:16 AM, John Baldwin wrote:
One more data point, /dev/twe0 does not exist with the patch and I think
thats why the utils fail outright.
Oh, hmm. That's odd. Do you get any error messages on the console
when twe0 attaches? Also, you have INVARIANTS enabled, yes?
(make_dev() panics when it fails if INVARIANTS is enabled).
I have INVARIANTS in the kernel, sorry, do I need to do something to
make it active ?
0{offsite2}# sysctl -a | grep -i invar
kern.features.invariant_support: 1
options INVARIANT_SUPPORT
options INVARIANTS
kern.timecounter.invariant_tsc: 1
TSC: P-state invariant, performance statistics
TSC: P-state invariant, performance statistics
TSC: P-state invariant, performance statistics
TSC: P-state invariant, performance statistics
0{offsite2}#
Nothing odd in dmesg
ZFS filesystem version 5
ZFS storage pool version 28
Timecounters tick every 1.000 msec
twed0 on twe0
twed0: 953878MB (1953542144 sectors)
usbus0: 480Mbps High Speed USB v2.0
usbus1: 480Mbps High Speed USB v2.0
pci6: ACPI PCI bus on pcib6
twe0: 3ware Storage Controller. Driver version 1.50.01.002 port
0x2000-0x200f mem 0xe281-0xe281000f,0xe200-0xe
27f at device 0.0 on pci6
twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048
isab0: PCI-ISA bridge at device 31.0 on pci0
Patch below is causing a panic now on boot. Just going to add debugging
to the serial console to see what it is and
0{offsite2}# kldload twe
twe0: 3ware Storage Controller. Driver version 1.50.01.002 port
0x2000-0x200f mem 0xe281-0xe281000f,0xe200-0xe27f at device
0.0 on pci6
twe0: [GIANT-LOCKED]
Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address = 0x3
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x81813eb3
stack pointer = 0x28:0xff84529d33f0
frame pointer = 0x28:0xff84529d3430
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 = 1324 (kldload)
[ thread pid 1324 tid 100146 ]
Stopped at twe_setup+0x153:movzbl 0x3(%rdx),%eax
db
Maybe try something like this (relative to the patched driver):
--- //depot/user/jhb/cleanup/sys/dev/twe/twe_freebsd.c2012-08-03
18:10:04.0
+++ /Users/jhb/work/p4/cleanup/sys/dev/twe/twe_freebsd.c 2012-08-03
18:10:04.0
@@ -342,9 +342,12 @@
/*
* Create the control device.
*/
+device_printf(sc-twe_dev, Calling make_dev()\n);
sc-twe_dev_t = make_dev(twe_cdevsw, device_get_unit(sc-twe_dev),
UID_ROOT, GID_OPERATOR,
S_IRUSR | S_IWUSR, twe%d,
device_get_unit(sc-twe_dev));
sc-twe_dev_t-si_drv1 = sc;
+device_printf(sc-twe_dev, make_dev() returned %p (%s)\n,
sc-twe_dev_t,
+ sc-twe_dev_t-si_name);
/*
* Schedule ourselves to bring the controller up once interrupts
are available.
* This isn't strictly necessary, since we disable interrupts while
probing the
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ttydev_cdevsw has no d_purge
On Aug 8, 2012, at 11:41 AM, Hans Petter Selasky wrote: On Wednesday 08 August 2012 19:24:18 Ed Schouten wrote: Ed: I would really like to see a custom argument for the tsw_free(), because it only needs to know the unit number, and the xsc for UCOM is freed when this is called and cannot be referred. Is it possible to have a separate void * for the tsw_free() function? Is this something which you can implement? We could extend the TTY code to allow the softc to be changed, e.g. tty_set_softc(). This function could be called right before calling tty_rel_gone(). Still, I would prefer it if these kind of things would Are you sure that the new softc won't be used in any callbacks when tty_rel_gone() is called, except for tsw_free() ? not be part of the API. Is there really no way the deallocation of the softc can be delayed until tsw_free() is called? Yes, but that is inconvenient. We use the automatically allocated softc given to the driver by newbus. When detach() returns, the softc is freed. Then we need to block in detach, and that is causing the problem! I thought the detach protocol was such that you shouldn't return from detach until all dangling references were gone. you could use tsw_free to wake up the detach sleeper, no? Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/9/12 10:31 AM, Mike Tancsa wrote:
On 8/9/2012 9:16 AM, John Baldwin wrote:
One more data point, /dev/twe0 does not exist with the patch and I think
thats why the utils fail outright.
Oh, hmm. That's odd. Do you get any error messages on the console
when twe0 attaches? Also, you have INVARIANTS enabled, yes?
(make_dev() panics when it fails if INVARIANTS is enabled).
I have INVARIANTS in the kernel, sorry, do I need to do something to
make it active ?
0{offsite2}# sysctl -a | grep -i invar
kern.features.invariant_support: 1
options INVARIANT_SUPPORT
options INVARIANTS
kern.timecounter.invariant_tsc: 1
TSC: P-state invariant, performance statistics
TSC: P-state invariant, performance statistics
TSC: P-state invariant, performance statistics
TSC: P-state invariant, performance statistics
0{offsite2}#
Nothing odd in dmesg
ZFS filesystem version 5
ZFS storage pool version 28
Timecounters tick every 1.000 msec
twed0 on twe0
twed0: 953878MB (1953542144 sectors)
usbus0: 480Mbps High Speed USB v2.0
usbus1: 480Mbps High Speed USB v2.0
pci6: ACPI PCI bus on pcib6
twe0: 3ware Storage Controller. Driver version 1.50.01.002 port
0x2000-0x200f mem 0xe281-0xe281000f,0xe200-0xe
27f at device 0.0 on pci6
twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048
isab0: PCI-ISA bridge at device 31.0 on pci0
Patch below is causing a panic now on boot. Just going to add debugging
to the serial console to see what it is and
0{offsite2}# kldload twe
twe0: 3ware Storage Controller. Driver version 1.50.01.002 port
0x2000-0x200f mem 0xe281-0xe281000f,0xe200-0xe27f at device
0.0 on pci6
twe0: [GIANT-LOCKED]
Odd, the patched driver shouldn't be triggering this message.
Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address = 0x3
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x81813eb3
stack pointer = 0x28:0xff84529d33f0
frame pointer = 0x28:0xff84529d3430
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 = 1324 (kldload)
[ thread pid 1324 tid 100146 ]
Stopped at twe_setup+0x153:movzbl 0x3(%rdx),%eax
db
Humm, I wonder if this module has a mix of old and new .o files somehow?
Perhaps try rebuilding twe.ko from scratch after doing a 'make clean'?
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/9/2012 1:21 PM, John Baldwin wrote:
Humm, I wonder if this module has a mix of old and new .o files somehow?
Perhaps try rebuilding twe.ko from scratch after doing a 'make clean'?
I think you are right. I nuked all the kernel files and recompiled
again, and it no longer panics and I see the entry in /dev now!?
0{offsite2}# kldload twe
twe0: 3ware Storage Controller. Driver version 1.50.01.002 port
0x2000-0x200f mem 0xe281-0xe281000f,0xe200-0xe27f at device
0.0 on pci6
twe0: [GIANT-LOCKED]
twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048
twe0: Calling make_dev()
twe0: make_dev() returned 0xfe0122105200 (twe0)
twed0 on twe0
twed0: 953878MB (1953542144 sectors)
0{offsite2}#
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/9/2012 3:28 PM, Mike Tancsa wrote:
On 8/9/2012 1:21 PM, John Baldwin wrote:
Humm, I wonder if this module has a mix of old and new .o files somehow?
Perhaps try rebuilding twe.ko from scratch after doing a 'make clean'?
I think you are right. I nuked all the kernel files and recompiled
again, and it no longer panics and I see the entry in /dev now!?
0{offsite2}# kldload twe
twe0: 3ware Storage Controller. Driver version 1.50.01.002 port
0x2000-0x200f mem 0xe281-0xe281000f,0xe200-0xe27f at device
0.0 on pci6
twe0: [GIANT-LOCKED]
twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048
twe0: Calling make_dev()
twe0: make_dev() returned 0xfe0122105200 (twe0)
twed0 on twe0
twed0: 953878MB (1953542144 sectors)
0{offsite2}#
OK, some more mystery.
If I load it as a kld,
I see the device. (Note, I added MDT into the version string)
0{offsite2}# twe0: 3ware Storage Controller. Driver version
1.50.01.002MDT port 0x2000-0x200f mem
0xe281-0xe281000f,0xe200-0xe27f at device 0.0 on pci6
twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048
twe0: Calling make_dev()
twe0: make_dev() returned 0xfe0026581a00 (twe0)
twed0 on twe0
twed0: 953878MB (1953542144 sectors)
0{offsite2}# ls -l /dev/tw*
crw--- 1 root operator - 0, 37 Aug 9 16:58 /dev/twa0
crw--- 1 root operator - 0, 173 Aug 9 17:00 /dev/twe0
crw-r- 1 root operator - 0, 174 Aug 9 17:00 /dev/twed0
Start up the tw_cli client
0{offsite2}# tw_cli
//offsite2 show
Ctl Model(V)Ports Drives Units NotOpt RRate VRate BBU
c09650SE-2LP 2 21 0 1 1 -
//offsite2 exit
0{offsite2}# ls -l /dev/tw*
crw--- 1 root operator - 0, 37 Aug 9 16:58 /dev/twa0
crw-r- 1 root operator - 0, 174 Aug 9 17:00 /dev/twed0
0{offsite2}#
It then disappears ?!
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
