On Wed, 3 Sep 2003, Jens Rehsack wrote:
> Michal Mertl wrote:
> > I found 2 bugs and some potential problems in bktr(4) code.
> >
> > Bug 1:
> > Compilation with options BKTR_USE_FREEBSD_SMBUS failes. Error is
> > that code tries to use iicbus which isn't defi
John-Mark Gurney wrote:
Jens Rehsack wrote this message on Wed, Sep 03, 2003 at 22:03 +:
Michal Mertl wrote:
I found 2 bugs and some potential problems in bktr(4) code.
Bug 1:
Compilation with options BKTR_USE_FREEBSD_SMBUS failes. Error is
that code tries to use iicbus which isn't de
Jens Rehsack wrote this message on Wed, Sep 03, 2003 at 22:03 +:
> Michal Mertl wrote:
> >I found 2 bugs and some potential problems in bktr(4) code.
> >
> >Bug 1:
> >Compilation with options BKTR_USE_FREEBSD_SMBUS failes. Error is
> >that code tries to use ii
Michal Mertl wrote:
I found 2 bugs and some potential problems in bktr(4) code.
Bug 1:
Compilation with options BKTR_USE_FREEBSD_SMBUS failes. Error is
that code tries to use iicbus which isn't defined where it looks for
it. I added it there and the compilation and detection goes fine. I
On Sun, Aug 03, 2003 at 03:35:17PM +0200, Guido Berhoerster wrote:
> Hello,
> I've got some trouble with the bktr-driver on FreeBSD 5.x. With
> fxtv the video-output is distorted and choppy, it appears that
> only odd scanlines are redrawn regularly while even scanlines
> re
On Sun, 3 Aug 2003, Guido Berhoerster wrote:
> I've got some trouble with the bktr-driver on FreeBSD 5.x. With fxtv the
> video-output is distorted and choppy, it appears that only odd scanlines
> are redrawn regularly while even scanlines remain for like half a second
> as &qu
Hello,
I've got some trouble with the bktr-driver on FreeBSD 5.x. With
fxtv the video-output is distorted and choppy, it appears that
only odd scanlines are redrawn regularly while even scanlines
remain for like half a second as "ghost images". When the fxtv
window is overlappe
Hello -
This concerns PR kern/47453: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/47453
A friend and I have the same problem with the LeadTek card. Applying the solution in
the PR does fix it on both of our machines.
Can this be committed to -CURRENT?
Thanks
David
___
I found 2 bugs and some potential problems in bktr(4) code.
Bug 1:
Compilation with options BKTR_USE_FREEBSD_SMBUS failes. Error is
that code tries to use iicbus which isn't defined where it looks for
it. I added it there and the compilation and detection goes fine. I don't
know how t
On Mon, Mar 25, 2002 at 10:21:49PM +0100, Nicolas Souchu wrote:
> Hi there,
>
> *Sorry* for the breakage. I'm currently fixing it.
>
> smbus.h is due to the missing rule, smbus.h removed from OBJS.
>
> bktr_i2c.c is due to its automatic inclusion in kernel by conf/files:
> conditional compilati
Hi there,
*Sorry* for the breakage. I'm currently fixing it.
smbus.h is due to the missing rule, smbus.h removed from OBJS.
bktr_i2c.c is due to its automatic inclusion in kernel by conf/files:
conditional compilation inserted.
pcf.c breakage is due to iicbus_alloc_bus() removed, device_add_ch
* David O'Brien ([EMAIL PROTECTED]) wrote:
> > Hmm, I am not alone I see here.. Already filed a PR about it.
>
> What was the PR number. I already fixed it. For build problem things
> like this, emailing the list is better as people will see it MUCH
> quicker.
kern/36298, but it's already clos
On Mon, Mar 25, 2002 at 12:14:26PM +0100, Emiel Kollof wrote:
> * Crist J. Clark ([EMAIL PROTECTED]) wrote:
> > I believe the recent changes to the bktr(4) module Makefile broke it,
> >
> > ===> bktr
> > ===> bktr/bktr
> > make: don't know ho
>Date: Mon, 25 Mar 2002 08:43:30 -0800 (PST)
>From: David Wolfskill <[EMAIL PROTECTED]>
>linking kernel.debug
>pcf.o: In function `pcf_attach':
>/usr/src/sys/i386/isa/pcf.c(.text+0x1f1): undefined reference to `iicbus_alloc_bus'
>*** Error code 1
>Looks to me like a declaration & a reference, bu
>Date: Mon, 25 Mar 2002 00:59:37 -0800
>From: Brooks Davis <[EMAIL PROTECTED]>
>FWIW, if you uncomment "option BKTR_USE_FREEBSD_SMBUS" in NOTES, the
>resulting LINT will compile. Unfortunatly, it won't link due to a
>different error related to this commit that I haven't tracked down.
Would that
* Crist J. Clark ([EMAIL PROTECTED]) wrote:
> I believe the recent changes to the bktr(4) module Makefile broke it,
>
> ===> bktr
> ===> bktr/bktr
> make: don't know how to make smbus.h. Stop
> *** Error code 2
>
> Stop in /usr/src/sys/modules/bktr.
> *** E
- VIA chipset SMBus controllers added
> : - alpm driver updated
> : - Support for dynamic modules added
> : - bktr FreeBSD smbus updated but not tested
> ^
> : - cleanup
FWIW, if you uncomment &quo
/work/src/sys/../include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -ffreestanding -include
opt_global.h -fno-common -malign-functions=4 -fno-builtin
-mpreferred-stack-boundary=2 -Werror -pg -mprofiler-epilogue
/work/src/sys/dev/bktr/bktr_i2c.c
/work/src/sys/dev/bktr/bktr_i2c.c: In function
I believe the recent changes to the bktr(4) module Makefile broke it,
===> bktr
===> bktr/bktr
make: don't know how to make smbus.h. Stop
*** Error code 2
Stop in /usr/src/sys/modules/bktr.
*** Error code 1
.
.
.
A fresh checkout on freefall still seems to have this problem.
--
Cri
In message: <[EMAIL PROTECTED]>
"Matthew N. Dodd" <[EMAIL PROTECTED]> writes:
: On Tue, 5 Mar 2002, M. Warner Losh wrote:
: > You should never need to define that option, so it means that the range
: > clipping is (still) bogus :-(.
:
: Yes, the code is probably still not checking bot
On Tue, 5 Mar 2002, M. Warner Losh wrote:
> You should never need to define that option, so it means that the range
> clipping is (still) bogus :-(.
Yes, the code is probably still not checking both acceptable ranges
against the request.
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E
In message: <[EMAIL PROTECTED]>
"Michael D. Harnois" <[EMAIL PROTECTED]> writes:
: On Tue, 2002-03-05 at 12:10, M. Warner Losh wrote:
:
: > Humor me and compile PCI_ALLOW_UNSUPPORTED_IO_RANGE
:
: You da man. Thanks!
You should never need to define that option, so it means that the
r
On Tue, 2002-03-05 at 12:10, M. Warner Losh wrote:
> Humor me and compile PCI_ALLOW_UNSUPPORTED_IO_RANGE
You da man. Thanks!
--
Michael D. Harnois bilocational bivocational
Pastor, Redeemer Lutheran ChurchWashburn, Iowa
1L, UST School of Law
In message: <[EMAIL PROTECTED]>
"Michael D. Harnois" <[EMAIL PROTECTED]> writes:
: I used to be able to use my Brooktree card with no problem. However, a
: month or so ago, I started getting this at boot:
:
: bktr0: mem 0xf500-0xf5000fff irq 9 at device 12.0 on pci2
: bktr0: coul
I used to be able to use my Brooktree card with no problem. However, a
month or so ago, I started getting this at boot:
bktr0: mem 0xf500-0xf5000fff irq 9 at device 12.0 on pci2
bktr0: could not map memory
device_probe_and_attach: bktr0 attach returned 6
pci2: at device 12.1 (no driver atta
rface
which is used by bktr, lpbb, viapm. Unfortunatly, I could not test the bktr
changes...
I need volonteers to test the bktr changes before I can commit the patch to -current.
The patch is organised as follows:
iic-current.diffs shall be applied to sys/
iic_mods.tgz contains the sys/modules/i2c an
Hi, all.
I cannot make a kernel on FreeBSD-current. I get a following compile
error message.
/work/src/sys/modules/bktr/bktr/../../../dev/bktr/bktr_os.c: In
function `bktr_detach':
/work/src/sys/modules/bktr/bktr/../../../dev/bktr/bktr_os.c:484:
`unit' undeclared (first use in thi
T
>
> Modified files:
>sys/conf files
>sys/dev/bktr bktr_os.c
>sys/dev/md md.c
>sys/i386/confGENERIC
>sys/i4b/driver i4b_ctl.c i4b_rbch.c i4b_tel.c
> i4b_trace.c
>
I've committed my changes to make the bktr Bt848/bt878 driver compile
on the Alpha to -current.
Please can someone test it on an experimental Alpha box.
It may panic your machine. (this is quite possible!!!)
so please only do this on a machine you are willing to experiment with.
Please
Kenneth Culver wrote...
> It seems that the bktr driver is still broken. I have looked through the
> code for the driver, and have yet to find the problem. here is a dmesg
> output with the error that seems to be causeing my problem:
>
> bktr0: irq 9 at device 17.0 on pci0
>
It seems that the bktr driver is still broken. I have looked through the
code for the driver, and have yet to find the problem. here is a dmesg
output with the error that seems to be causeing my problem:
bktr0: irq 9 at device 17.0 on pci0
bktr0: Hauppauge Model 61291 D110
Warning - Unknown
I have included a link screenshot of what the picture is doing on my tv
card. It seems that since gcc 2.95.2 has been introduced as the default
compiler on FreeBSD-CURRENT, the behavior in the jpeg has been occuring. I
have tried to locate the source of the problem in the driver, but I don't
know
Alright, it seems I have my first problem with gcc 2.95.2, (well, I'm not
really sure that it's a gcc problem). The problem is that now, after
having upgraded the compiler, fxtv will only display every other scanline
instead of all of them.
==
I'm happy to report that for my WinTV card, the bktr drivers are working
well with the latest changes. Keep up the good work.
=
| Kenneth Culver | FreeBSD: The best OS around.|
| Unix Systems Administrator
main Bt848 code, the audio, tuner and card
detetion code
and the operating system specific things (probe/attach and cdev).
In addition, the new driver now lives in /sys/dev/bktr
So, those of you using -current, keep an eye out next time you CVSup and
please report any breakages.
I intend to merg
kernel "kernel" at 0xc029c000.
Pentium Pro MTRR support enabled
npx0: on motherboard
npx0: INT 16 interface
apm0: on motherboard
apm: found APM BIOS v1.2, connected at v1.2
pcib0: on motherboard
pci0: on pcib0
WARNING: "bktr" is usurping "bktr"'s cdevsw[]
pcib1:
>
> The problems might be wholly unrelated. I've just reconfigured my BIOS
> to put everything onto irq 11
>
> uhci0: irq 11 at device 1.2 on
> pci0
> ohci0: irq 11 at device 9.0 on
> pci0
> vga-pci0: irq 11 at device 10.0 on pci0
> ed1: irq 11 at device 11.0 on pci0
Hmm. I just remembered
ver wrote:
>
> > It seems I have the classic IRQ conflict going on here.
> > I have 4 devices that all seem to want the same irq. For some reason the
> > USB port, the pcm driver, the bktr driver, and one other thing (I havn't
> > figured out what) all want IRQ 11. Th
the sound card and PCI system (PNP fixes), please try at
least rev 1.117 of pci.c .
The bktr problem, might be unrelated. I'll have a quick look and kick
Roger Hardiman, maybe he knows.
I'd say you should be able to sort out the problems for the various
parts independently and ignore the
I have 4 devices that all seem to want the same irq. For some reason the
> USB port, the pcm driver, the bktr driver, and one other thing (I havn't
> figured out what) all want IRQ 11. The pcm driver is driving an aureal
> vortex right now. I have never had this problem before,
'clone' of the other and
> only cards that can cope with sharing PCI INT pins should be used in those
> 2 slots. Your motherboard manual will have more information.
Yeah, it has 5 pci slots and 2 ISA, and one of the PCI is shared. I think
I may have had the soundcard, and the bkt
> On Fri, 3 Sep 1999, Kenneth Culver wrote:
> > Also, my bios is really freaky. It refuses to assign any irqs except
> > 10 and 11 to installed PCI devices. I can't figure it out. I've
> > completely rearranged everything and it still refuses to work
> > properly.
>
> The BIOS usually lets you ma
On Fri, 3 Sep 1999, Kenneth Culver wrote:
> Also, my bios is really freaky. It refuses to assign any irqs except
> 10 and 11 to installed PCI devices. I can't figure it out. I've
> completely rearranged everything and it still refuses to work
> properly.
The BIOS usually lets you mark IRQs as 're
Well, as it turns out, my ethernet, and my bktr device have no problem
shareing IRQ's, but my soundcard has plenty of problems, even when it gets
it's own irq... it plays sound through the sound-in just fine, but the dsp
doesn't work quit right: Applications can play sound (alth
> It seems I have the classic IRQ conflict going on here.
> I have 4 devices that all seem to want the same irq. For some reason the
> USB port, the pcm driver, the bktr driver, and one other thing (I havn't
> figured out what) all want IRQ 11.
This is your BIOS' fault. Y
It seems I have the classic IRQ conflict going on here.
I have 4 devices that all seem to want the same irq. For some reason the
USB port, the pcm driver, the bktr driver, and one other thing (I havn't
figured out what) all want IRQ 11. The pcm driver is driving an aureal
vortex right now. I
46 matches
Mail list logo
