Re: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's using poudriere-devel to build armv7 ports on aarch64 (cortex-a72) system
Hi Mark, On Tue, Mar 09, 2021 at 03:39:42PM -0800, Mark Millard via freebsd-arm wrote: > After using poudriere to build ports for native cortex-a72 > on the MACCHIATObin Double Shot (and similarly for > cortex-a57 on the OverDrive 1000) I attempted to do my > usual bulk build targeting cortex-a7 via poudriere-devel: > > # poudriere jail -i -jFBSDFSSDjailArmV7 > Jail name: FBSDFSSDjailArmV7 > Jail version: 14.0-CURRENT > Jail arch: arm.armv7 > Jail method: null > Jail mount:/usr/obj/DESTDIRs/clang-armv7-installworld-poud > Jail fs: > Jail updated: 2021-01-27 14:47:10 > Jail pkgbase: disabled > > But I got some SIGSEGV failures that I've never before > had analogous failures. I'll show the 6 backtraces. > They all have a similar type-of-context but in various > programs, summarized as (from the lldb bt outputs): > FREEBSD_COMPAT32 was indeed broken on arm64, and the process would crash when receiving a signal. I believe I fixed it in -CURRENT with commit c328f64d81079bad5064c8a387883df50ab5aaed Regards, Olivier ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic on boot after SVN r328988
Hi Michael, On Fri, Feb 16, 2018 at 10:13:07AM -0500, Michael Butler wrote: > On 02/16/18 10:05, Andrey V. Elsukov wrote: > > On 16.02.2018 17:44, Michael Butler wrote: > >>> do you have some specific optimization flags in make.conf? > >>> Can you show the output of `head -40 /var/run/dmesg.boot`? > >>> > >> > >> The only relevant flags in /etc/make.conf are .. > >> > >> CPUTYPE?=pentium3 > >> KERNCONF=SARAH > >> NO_MODULES=YES > >> > >> Boot log from last night's failure attached, > > > > Ok, it seems ConcurrencyKit was not tested with Pintium3. > > Can you show the output from kgdb: > > > > disassemble *0xc0991ff0 > > That'd do it .. :-( [...] Sorry about this. It should be fixed with r329388. Can you update and let me know how it goes ? Thanks ! Olivier ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ARM pcpu changes, was Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Fri, Mar 01, 2013 at 02:20:16PM +0100, Svatopluk Kraus wrote: > On Tue, Feb 26, 2013 at 1:39 PM, Konstantin Belousov > wrote: > > On Tue, Feb 26, 2013 at 09:06:51PM +1300, Andrew Turner wrote: > >> Does anyone know if it is only curthread that needs to be atomic? If so > >> this should work. Reading the cpuid from the system currently is a > >> single instruction, however it appears the code will need to be reworked > >> for use with multiple levels of affinity, for example when there > >> are clusters of cores the current code will number two cores on > >> different clusters with the same id. > >> > >> I don't think we need to use ldrex/strex to read/write the values, my > >> understanding is the rest should be safe to access without atomic > >> functions. > > > > I read about ARM architecture some time ago. What I am saying below is not > > a proposal, but rather a way for me to learn more about the architecture. > > > > From my reading of the docs, ARM has the shadow registers, in particular, > > the r13 (stack pointer) is shadowed for all privileged modes. Is the shadow > > used by our kernel, is it correctly restored on the context switch ? > > > > If yes, you can easily recover the pcb address from the current sp, > > without accessing any coprocessor registers, and even without any > > assignment of the global register for curthread (which needs to be > > done at the kernel entry). Just align the stack > > start on the 2*PAGE_SIZE boundary (like it is already done for MIPS), > > and do the mask operation on the sp value to get the end of pcb. > > This is atomic and context-switch safe. > > > > pcb us already per-thread, and can store the thread pointer. > > More, you can store the curcpu or cpuid pointer into pcb too, > > and update it on the context switch. > > > > amd64 has an architecturally-defined special register (k)gsbase, which > > effectively must be correctly initialized at each kernel entry, and > > restored on the return to usermode. Since the initialization on entry > > and restoration on exit is not atomic wrt the entry/exit itself, amd64 > > periodically gets a bugs which cause kernel running with user gsbase. > > This is the fatal bug, destroying the kernel structures and allowing the > > CPU privilege mode switch for normal user. > > > > Using the shadow registers for this purpose eliminate the whole source > > of the bugs. > > Well, IMHO, the both kernel and user thread stacks must correctly be > set for current threads, otherwise it doesn't work. So, the idea to > save things on a thread stack and update them on a context switch will > work in general. However, the stack must be aligned to its size. And > this is the price. I have no idea how this kernel stack alignment can > impact kernel virtual space fragmentation. > OTOH, as you say, this kernel stack storage can be used for many things. > Hi, FWIW, I have a proof-of-ooncept patch that does just that, and it seems to work well. Regards, Olivier ___ 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] i386 pmap sysmaps_pcpu[] atomic access
On Mon, Feb 25, 2013 at 04:26:14PM -0500, John Baldwin wrote: > On Monday, February 25, 2013 7:47:47 am Olivier Houchard wrote: > > On Mon, Feb 25, 2013 at 07:09:20PM +1300, Andrew Turner wrote: > > > On Thu, 21 Feb 2013 10:43:49 -0500 > > > John Baldwin wrote: > > > > > > > On Thursday, February 21, 2013 7:53:52 am Svatopluk Kraus wrote: > > > > > On Wed, Feb 20, 2013 at 4:22 PM, John Baldwin > > > > > wrote: > > > > > > On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: > > > > > >> On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov > > > > > >> wrote: > > > > > >> > On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus > > > > > >> > wrote: > > > > > >> >> On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov > > > > > >> >> wrote: > > > > > >> >> Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP > > > > > >> >> case was simple. SMP case is more complex and rather new for > > > > > >> >> me. Recently, I was solving a problem with PCPU stuff. For > > > > > >> >> example, PCPU_GET is implemented by one instruction on i386 > > > > > >> >> arch. So, a need of atomicity with respect to interrupts can > > > > > >> >> be overlooked. On load-store archs, the implementation which > > > > > >> >> works in SMP case is not so simple. And what works in UP case > > > > > >> >> (single PCPU), not works in SMP case. Believe me, mysterious > > > > > >> >> and sporadic 'mutex not owned' assertions and others ones > > > > > >> >> caused by curthreads mess, it takes a while ... > > > > > >> > Note that PCPU_GET() is not needed to be atomic. The reason is > > > > > >> > that the code which uses its result would not be atomic > > > > > >> > (single-instruction or whatever, see below). Thus, either the > > > > > >> > preemption should not matter since the action with the per-cpu > > > > > >> > data is advisory, as is in the case of i386 pmap you noted. or > > > > > >> > some external measures should be applied in advance to the > > > > > >> > containing region (which you proposed, by bracing with > > > > > >> > sched_pin()). > > > > > >> > > > > > >> So, it's advisory in the case of i386 pmap... Well, if you can > > > > > >> live with that, I can too. > > > > > >> > > > > > >> > > > > > > >> > Also, note that it is not interrupts but preemption which is > > > > > >> > concern. > > > > > >> > > > > > >> Yes and no. In theory, yes, a preemption is a concern. In > > > > > >> FreeBSD, however, sched_pin() and critical_enter() and their > > > > > >> counterparts are implemented with help of curthread. And > > > > > >> curthread definition falls to PCPU_GET(curthread) if not defined > > > > > >> in other way. So, curthread should be atomic with respect to > > > > > >> interrupts and in general, PCPU_GET() should be too. Note that > > > > > >> spinlock_enter() definitions often (always) use curthread too. > > > > > >> Anyhow, it's defined in MD code and can be defined for each arch > > > > > >> separately. > > > > > > > > > > > > curthread is a bit magic. :) If you perform a context switch > > > > > > during an interrupt (which will change 'curthread') you also > > > > > > change your register state. When you resume, the register state > > > > > > is also restored. This means that while something like > > > > > > 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' > > > > > > never is. However, it is true that actually reading curthread > > > > > > has to be atomic. If your read of curthread looks like: > > > > > > > > > > > > mov , r0 > > > > > > add , r0 > > > > > > ld r0, r1 > > > > > > > > > > > > Then
Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
> > > Privileged. The other ones are respectively User Read only and User > > > Read Write. For now, we are using the Privileged one to store pcpu > > > pointer (curthread is correctly set during each context switch). > > > Thus, using a coprocessor register means that reading of curthread > > > is not a single instruction implementation now. After we figured > > > out the curthread issue in SMP case, using a fixed (processor) > > > register for pcpu is an option. Meanwhile, we disable interrupts > > > before reading of curthread and enable them after. The same is done > > > for other PCPU stuff. For now we have not stable system enough for > > > profiling, however, when it will be, it would be interesting to > > > learn how various implementations of curthread reading impact > > > system performance. > > > > curthread is read _a lot_, so I would expect this to hurt. What we > > did on Alpha was to use a fixed register for pcpu access, but we used > > the equivalent of a coprocessor register to also store the value so > > we could set that fixed register on entry to the kernel (userland was > > free to use the register for its own purposes). > > > > The current code on ARM is not atomic, it loads the base address of the > pcpu data from the coprocessor then loads curthread from this address. > One solution I discussed with Olivier Houchard is to keep the data in > the coprocessor but to then load it into a dedicated register when we > enter the kernel. > > Reading curthread would then be a single load instruction thanks to > ARM's ldr using an immediate offset [1], e.g. to load from r12 into r1 > it would be 'ldr r1, [r12]'. > Wouldn't it be doable to either use the extra coprocessor register for curthread, setting it when entering the kernel as John suggested, or just using the privileged one for curthread, and changing get_pcpu() to be __pcpu[cpuid], and then making sure pcpu accesses are atomic, either by disabling interrupts or using ldrex/strex ? I take it curthread (and curpcb, which we can get from curthread) is by far the most used, and it wouldn't hurt that badly to pessimize the other pcpu variables ? Olivier ___ 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] turning devctl into a "multiple openable" device
On Wed, Nov 30, 2011 at 06:04:50PM +0200, Kostik Belousov wrote: > > > I wonder why the waiting_threads stuff is needed at all. The cv could > > > be woken up unconditionally everytime. What is the reason for the cv_wait > > > call in cdevpriv data destructor ? You cannot have a thread doing e.g. > > > read on the file descriptor while destructor is run. > > > > > > > What will prevent you from having a thread stuck in read(), while an > > another > > one close() the fd ? > > > Nothing, but file reference count goes to zero only after the thread > stuck in read is unstuck. Cdevpriv destructor is run only when file > reference count becomes zero, i.e. there can be no any accessing threads, > and new accesses are impossible since file descriptors also own references > on the file. Right, I was a bit confused, this part can be removed. Regards, Olivier ___ 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] turning devctl into a "multiple openable" device
On Wed, Nov 30, 2011 at 05:46:36PM +0200, Kostik Belousov wrote: > On Wed, Nov 30, 2011 at 10:05:11AM -0500, John Baldwin wrote: > > On Wednesday, November 30, 2011 7:43:20 am Baptiste Daroussin wrote: > > > Hi all, > > > > > > With the help of cognet, I wrote a patch to turn devctl into a multiple > > > openable > > > device, that mean that it will allow to open /dev/devctl in multiple > > > programs, > > > for example hald and everythings that want to receive notification from > > > the > > > device won't need to depend on haveing devd running. > > > > > > here is the patch: > > > http://people.freebsd.org/~bapt/devctl_multi_open.diff > > > > Shouldn't devctl_queue_data_f() use the requested malloc() flags instead of > > hardcoding M_NOWAIT? > This is an obvious fallback of holding mutex around the call to > per_devctl_queue_data_f(), which caused the author a trouble to use > M_WAITOK. > > Having n readers causes the patch to queue each message n times, that looks > like a waste. > Queuing the message only one time would require to somehow keep a state, to know which thread read which message, and figuring out when to free a message can be an headache. Given I don't think they'll be a lot of readers, I'm not sure it's worth the trouble. > I wonder why the waiting_threads stuff is needed at all. The cv could > be woken up unconditionally everytime. What is the reason for the cv_wait > call in cdevpriv data destructor ? You cannot have a thread doing e.g. > read on the file descriptor while destructor is run. > What will prevent you from having a thread stuck in read(), while an another one close() the fd ? Regards, Olivier ___ 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: Crossbuild failure on 8-stable
On Thu, Jun 30, 2011 at 11:22:36AM +0200, Hans Petter Selasky wrote: > Hi, > > Trying to cross build ARM fails in the following way on 8-stable: > > 8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011 > > make toolchain TARGET=arm > > Is this perhaps also an issue in 9-current? > > Any clues? > Hi Hans Peter, Not sure if it is your problem, but I think it should be make toolchain TARGET_ARCH=arm Regards, Olivier ___ 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: `panic: run_interrupt_driven_config_hooks: waited too long' on HP DV8
On Mon, Mar 14, 2011 at 02:01:38AM +0300, Yuri Pankov wrote: > Hi, > > I'm getting the following panic trying to boot March 5 snapshot on > HP Pavilion DV8 notebook (8.2-RELEASE GENERIC kernel seems to boot on > the same hardware just fine): > > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config > panic: run_interrupt_driven_config_hooks: waited too long > cpuid = 0 > KDB: enter: panic > [ thread pid 0 tid 10 ] > Stopped atkdb_enter+03xb: movq$0,0x800ab2(%rip) > db> bt > Tracing pid 0 tid 10 td 0x80ee83e30 > kdb_enter() at kdb_enter+0x3b > panic() at panic+0x180 > boot_run_interrupt_driven_config_hooks() at > boot_run_interrupt_driven_config_hooks+0xb3 > mi_startup() at mi_startup+0x77 > btext() at btext+0x2c > > Any hints or additional information I should provide to troubleshoot > this? Hi Yuri, If I remember correctly, the problem came from the sbp driver (SCSI over firewire). Can't tell why it happens though, as I didn't need it I just disabled it. Regards, Olivier ___ 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: bind fails with sig11 on start / pthread failure on ARM?
>
> Strange:
Not so much, the first values for ras_start/end were chosen to be immediate
values, so you could just mov them, but the new one aren't.
Try something like the patch attached instead (untested, I have no arm setup
here, but you'll get the idea).
Regards,
Olivier
Index: contrib/bind9/lib/isc/arm/include/isc/atomic.h
===
--- contrib/bind9/lib/isc/arm/include/isc/atomic.h (revision 203777)
+++ contrib/bind9/lib/isc/arm/include/isc/atomic.h (working copy)
@@ -49,26 +49,22 @@
static inline isc_int32_t
isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val)
{
- register int done, ras_start;
+ register int done, ras_start = #0x1004;
__asm __volatile("1:\n"
"adr%1, 1b\n"
- "mov%0, #0xe004\n"
"str%1, [%0]\n"
- "mov%0, #0xe008\n"
"adr%1, 2f\n"
- "str%1, [%0]\n"
+ "str%1, [%0, #4]\n"
"ldr%1, [%2]\n"
"cmp%1, %3\n"
"streq %4, [%2]\n"
"2:\n"
"mov%3, #0\n"
- "mov%0, #0xe004\n"
"str%3, [%0]\n"
"mov%3, #0x\n"
- "mov%0, #0xe008\n"
- "str%3, [%0]\n"
- : "=r" (ras_start), "=r" (done)
+ "str%3, [%0, #4]\n"
+ : "+r" (ras_start), "=r" (done)
,"+r" (p), "+r" (cmpval), "+r" (val) : : "memory");
return (done);
___
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: 5.1-RELEASE panic, trace included
On Sat, Jun 14, 2003 at 04:36:28PM +0200, Maxime Henrion wrote: > Pawel Jakub Dawidek wrote: > > On Sat, Jun 14, 2003 at 02:28:33AM -0400, Robert Watson wrote: > > +> If you have the kernel.debug for this kernel, could you send the gdb -k > > +> output of: > > +> > > +> l *in6_pcbbind+0x2a7 > > > > I've looked at objdump -d kernel, and it looks like this is somewhere here: > > > > 214:t = in_pcblookup_local(pcbinfo, > > 215:sin.sin_addr, lport, > > 216:INPLOOKUP_WILDCARD); > > 217:if (t && > > 218:(so->so_cred->cr_uid != > > 219: t->inp_socket->so_cred->cr_uid) && > > 220:(ntohl(t->inp_laddr.s_addr) != > > 221: INADDR_ANY || > > 222: INP_SOCKAF(so) == > > 223: INP_SOCKAF(t->inp_socket))) > > 224:return (EADDRINUSE); > > > > We're talking about this line: > > > > test%eax,%eax > > je c03ac9c7 > > mov 0x64(%eax),%eax > > mov %eax,0xffd0(%ebp) > > => mov 0xc4(%eax),%edx > > mov 0xc4(%esi),%eax > > mov 0x4(%eax),%eax > > cmp 0x4(%edx),%eax > > je c03ac9c7 > > > > We're loading inp_socket->so_cred to edx here. > > So it looks like inp_socket is NULL. Hmm, it is possible? > > Yes, since jlemon's reduced TCP state work. Olivier > ([EMAIL PROTECTED]) has a fix for this, so I added him to the Cc: line. Hi, I believe this patch : http://people.FreeBSD.org/~cognet/in6_pcb.c.diff fixes this issue. Unfortunately, I haven't been able to get it properly reviewed before 5.1-RELEASE. Cheers, Olivier ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SB Live goes silent after pcm commit
On Tue, Feb 25, 2003 at 11:13:23PM +0100, ?yvind Rakv?g wrote:
> I believe the commit Feb 20 17:31:11 2003 UTC on
> src/sys/dev/sound/pci/emu10k1.c broke something.
>
> With a kernel built from 17:00 sources sound works, from 19:00 there is
> only the sound of silence. Everything looks OK, xmms, mpg123 etc play,
> but no sound.
>
> The pcm driver is compiled into the kernel, i haven't tested loading as
> module.
>
> dmesg|grep pcm:
> pcm0: port 0x9400-0x941f irq 5 at device 13.0 on pci0
> pcm0:
>
> Soundcard: Soundblaster Live 1024! Player
> Motherboard: Asus A7V133, Via Apollo KT133A chipset
>
> Soundcard is sharing irq with an Intel NIC and the onboard USB
> controller.
Hi,
Could you please try the attached patch (to be applied in
/sys/dev/sound/pci).
Thanks,
Olivier
Index: emu10k1.c
===
RCS file: /home/ncvs/src/sys/dev/sound/pci/emu10k1.c,v
retrieving revision 1.32
diff -u -p -r1.32 emu10k1.c
--- emu10k1.c 23 Feb 2003 01:06:58 - 1.32
+++ emu10k1.c 26 Feb 2003 00:43:54 -
@@ -1022,9 +1022,9 @@ emu_intr(void *p)
static void
emu_setmap(void *arg, bus_dma_segment_t *segs, int nseg, int error)
{
- void **phys = arg;
+ bus_addr_t *phys = arg;
- *phys = error? 0 : (void *)segs->ds_addr;
+ *phys = error? 0 : (bus_addr_t)segs->ds_addr;
if (bootverbose) {
printf("emu: setmap (%lx, %lx), nseg=%d, error=%d\n",
@@ -1043,7 +1043,7 @@ emu_malloc(struct sc_info *sc, u_int32_t
if (bus_dmamem_alloc(sc->parent_dmat, &buf, BUS_DMA_NOWAIT, &map))
return NULL;
if (bus_dmamap_load(sc->parent_dmat, map, buf, sz, emu_setmap, addr, 0)
- || !addr)
+ || !*addr)
return NULL;
return buf;
}
@@ -1094,7 +1094,7 @@ emu_memalloc(struct sc_info *sc, u_int32
ofs = 0;
for (idx = start; idx < start + blksz; idx++) {
mem->bmap[idx >> 3] |= 1 << (idx & 7);
- tmp = (u_int32_t)(u_long)((u_int8_t *)&blk->buf_addr + ofs);
+ tmp = (u_int32_t)(u_long)((u_int8_t *)blk->buf_addr + ofs);
/* printf("pte[%d] -> %x phys, %x virt\n", idx, tmp, ((u_int32_t)buf)
+ ofs); */
mem->ptb_pages[idx] = (tmp << 1) | idx;
ofs += EMUPAGESIZE;
Re: [Fwd: panic: don't do that ?]
On Wed, Feb 12, 2003 at 12:23:53AM +0100, David Vidal Rodr?guez wrote:
Hi,
> 1)
> If they aren't loaded (I forgot them on the 1st try by mistake), the
> kernel panics if I try to change hw.snd.maxautovchans (that odd "bwrite:
> buffer is not busy???" message again!). That shouldn't happen: if I
> don't have any soundcards, this oid shouldn't _exist_ either!
I'm afraid I don't know anything about that. The oid doesn't exist for
me if I don't load the kernel module.
> 2)
> If they're loaded, an attempt to unload snd_via82c686.ko results in a
> panic with the funny message in the subject. But: Aren't modules
> supposed to be unloadable? What's the fun with modules then?
I believe it has been fixed on -CURRENT. You may try this patch :
http://people.FreeBSD.org/~cognet/sound.c.diff
> Any hints on solving this?
>
> My attempt to load modules instead of the monolithic solution (which
> always works) comes due to an odd behaviour of pcm0 (multiplexed with
> hw.snd.pcm0.vchans=8) telling that some /dev/dsp{W,}0.[0-7] devices are
> busy after their first usage. I wanted to address it by unloading the
> affected module and loading it again, but... that'll panic the system.
AFAIK, The device being busy issue is fixed by Brian Feldman's recent commit.
You can find the patch here :
http://people.FreeBSD.org/~cognet/dsp.c.diff
Cheers,
Olivier Houchard
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ?deleted include file sys/sys/bus_private.h
On Thu, Oct 03, 2002 at 12:22:42AM +, attila! wrote: > 5.0-CURRENT slice as of 2002.10.02.12.0.0 > > cvs log: > > Delete src/sys/sys/bus_private.h > > kernel compile log: > > /usr/src/sys/dev/trm/trm.c:71:29: \ > sys/bus_private.h: No such file or directory > > updating at 1800 does not show the file restored. > > 3762 Sep 5 2001 bus_private.h > > Is there any external consequences adding bus_private.h > to the sys/dev/trm directory for the DC395 controller? > > I placed a copy of bus_private.h in the trm directory > and it compiles and the driver works... > > all's well that ends well? > > hopefully the Tekram DC395U/W will be officially > committed Hi, Could you please try this one: http://www.ci0.org/trm/trm.tar.gz ? It should fix your problem. Cheers, Olivier Houchard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TekRam 395U[W] is ready for commit
On Wed, Sep 25, 2002 at 09:47:36PM +, attila! wrote: > David: > > DC395U on CURRENT from Houchard's driver works like a > champ on 'da' (ZIP 100) and 'cd (Creative DVD-RAM) > devices; I haven't had an 'sa' device since my Exabyte > died. > > I've been beating on the driver for 10 days and it looks > good --works as advertised on the oldest kernel I have > around (20 Feb 2002), and at least 5 kernels this month. > > I would say it's worth committing; can you take it > from here? > Hi, A commit for this driver is planned by Joerg Wunsch, according to freebsd-scsi. It is not this one, if I remember well Joerg said Tekram driver needed some fixes (and this one is just the one provided by Tekram updated a bit), but I don't know what this fixes are. By the way the version you downloaded is not the last one, which may be found at http://www.ci0.org/trm (I don't really remember what the diff are, certainly mainly style changes). Cheers. Olivier Houchard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gvim weird linkage
On Sat, Mar 09, 2002 at 10:41:32PM +0200, Vallo Kallaste wrote: > On Sat, Mar 09, 2002 at 02:19:40PM +, Simon Dick <[EMAIL PROTECTED]> wrote: > > > > Any hints? Seems like some environment configuration problem or > > > latent bug somewhere.. > > > > I just rebuild my current today and gvim has started working for me > > again now > > I did cvsup, world and new kernel, just in case.. but it really > doesn't matter. Same problem. You may try to compile vim with ./configure --disable-xim too. It worked for me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
