(snapshot) to 13.2-RC3 freebsd-update's
> upgrade sequence did not go well relative to my being
> prompted to do the right thing to establish /etc/machine-id .
> After the last reboot (kernel upgrade, presumably) it had me
> continue with. . .
>
> # /usr/sbin/freebsd-updat
On Fri, Mar 17, 2023 at 9:53 PM Mark Millard wrote:
> This may all be fine. But it still leaves me expecting
> that there should be man page(s) covering these hostid
> and machine-id files and how they should be handled to
> match the usages to which they are put, such as the nfs
&g
On Mar 17, 2023, at 19:04, Mark Millard wrote:
> On Mar 17, 2023, at 18:24, Mark Millard wrote:
>
>> The 13.1-RELEASE (snapshot) to 13.2-RC3 freebsd-update's
>> upgrade sequence did not go well relative to my being
>> prompted to do the right thing to establish /
On Mar 17, 2023, at 18:24, Mark Millard wrote:
> The 13.1-RELEASE (snapshot) to 13.2-RC3 freebsd-update's
> upgrade sequence did not go well relative to my being
> prompted to do the right thing to establish /etc/machine-id .
> After the last reboot (kernel upgrade, pres
The 13.1-RELEASE (snapshot) to 13.2-RC3 freebsd-update's
upgrade sequence did not go well relative to my being
prompted to do the right thing to establish /etc/machine-id .
After the last reboot (kernel upgrade, presumably) it had me
continue with. . .
# /usr/sbin/freebsd-update instal
ing to the latest
>> code -- CCing bapt and tijl just in case since they're more familiar with
>> this
>> than I am.
>>
>> Colin Percival
>>
>> On 3/16/23 15:55, Mark Millard wrote:
>>> # cat /etc/hostid /etc/machine-id /var/d
e latest
>> code -- CCing bapt and tijl just in case since they're more familiar with
>> this
>> than I am.
>
> A question may be if past dbus port related activity might
> have established a /var/db/machine-id independent of the
> recent FreeBSD activity. That mi
amiliar with this
> than I am.
A question may be if past dbus port related activity might
have established a /var/db/machine-id independent of the
recent FreeBSD activity. That might not be able to be
classified as a "broken version":
Before upgrade:
/etc/hostid (old style)
/var/db/m
5, Mark Millard wrote:
# cat /etc/hostid /etc/machine-id /var/db/machine-id
a4f7fbeb-f668-11de-b280-ebb65474e619
a4f7fbebf66811deb280ebb65474e619
7227cd89727a462186e3ba680d0ee142
(I'll not be keeping these values for the example system.)
# ls -Tld /etc/hostid /etc/machine-id /var/db/machine-i
On Mar 16, 2023, at 15:55, Mark Millard wrote:
> # cat /etc/hostid /etc/machine-id /var/db/machine-id
> a4f7fbeb-f668-11de-b280-ebb65474e619
> a4f7fbebf66811deb280ebb65474e619
> 7227cd89727a462186e3ba680d0ee142
>
> (I'll not be keeping these values for the example syste
# cat /etc/hostid /etc/machine-id /var/db/machine-id
a4f7fbeb-f668-11de-b280-ebb65474e619
a4f7fbebf66811deb280ebb65474e619
7227cd89727a462186e3ba680d0ee142
(I'll not be keeping these values for the example system.)
# ls -Tld /etc/hostid /etc/machine-id /var/db/machine-id
-rw-r--r-- 1
On Mar 4, 2023, at 06:32, Tijl Coosemans wrote:
>
> On Fri, 3 Mar 2023 10:36:20 -0800 Mark Millard wrote:
>> What are the properties for the content of /etc/hostid
>> in FreeBSD? Where are they documented?
>>
>> /etc/machine-id has strong property guarnatee
>
Mike Karels wrote on
Date: Fri, 03 Mar 2023 16:12:50 UTC :
> On 3 Mar 2023, at 9:40, Tijl Coosemans wrote:
>
> > On Wed, 1 Mar 2023 18:18:33 GMT Baptiste Daroussin wrote:
> >> The branch main has been updated by bapt:
> >>
> >> URL:
>
… Search results suggest that this might be _not_ an issue with
poudriere, I'm not sure how to proceed. …
Worked around by restarting the OS.
From <https://bsd.to/m8dh/raw>:
[00:00:28] Starting jail main-default
[00:00:28] Error: Unable to execute id(1) in jail. Emulation or ABI wrong.
– and:
[00:00:14] Starting jail 13-default
[00:00:14] Error: Unable to execute id(1) in jail. Emulation or ABI wrong.
Search results sugges
id, owner;
int count, ret;
id = TID(curthread);
if (PMUTEX_OWNER_ID(m) == id)
return (mutex_self_lock(m, abstime));
mutex_self_lock() may return EDEADLK for PTHREAD_MUTEX_ERRORCHECK mutex type,
which is default.
Is it possible that "id
>> I tested on zfs, perhaps there is something extra going on on other
filesystems.
I tested on UFS2, and I get nothing out of the patched fuser.c.
On Thu, Oct 18, 2018 at 11:24 PM Mateusz Guzik wrote:
> On 10/17/18, Ali Abdallah wrote:
> >> diff --git a/usr.bin/fstat/fuser.c b/usr.bin/fstat/f
On 10/17/18, Ali Abdallah wrote:
>> diff --git a/usr.bin/fstat/fuser.c b/usr.bin/fstat/fuser.c
>> index b4225328fc1f..17d06f1c5b13 100644
>> --- a/usr.bin/fstat/fuser.c
>> +++ b/usr.bin/fstat/fuser.c
>> @@ -92,7 +92,7 @@ struct consumer {
>>STAILQ_ENTRY(consumer) next;
>> };
>> struct r
> diff --git a/usr.bin/fstat/fuser.c b/usr.bin/fstat/fuser.c
> index b4225328fc1f..17d06f1c5b13 100644
> --- a/usr.bin/fstat/fuser.c
> +++ b/usr.bin/fstat/fuser.c
> @@ -92,7 +92,7 @@ struct consumer {
>STAILQ_ENTRY(consumer) next;
> };
> struct reqfile {
> - uint32_tfsid;
>
Hi there,
Op di 16 okt. 2018 om 15:05 schreef Mateusz Guzik :
> struct reqfile {
> - uint32_tfsid;
> + uint64_tfsid;
> uint64_tfileid;
Considering that these are based on sb.st_{ino,dev}, maybe better to
use the occasion to switch these fields to dev_t
On 10/16/18, Ali Abdallah wrote:
> Hello,
>
> On FreeBSD 12 ALPHA9
>
>> less .vimrc
>> fuser .vimrc
> .vimrc:
>
> gives no pid, on FreeBSD 11.2 the above works as expected.
>
try this:
diff --git a/usr.bin/fstat/fuser.c b/usr.bin/fstat/fuser.c
index b4225328fc1f..17d06f1c5b13 100644
--- a/usr.bin
Hello,
On FreeBSD 12 ALPHA9
> less .vimrc
> fuser .vimrc
.vimrc:
gives no pid, on FreeBSD 11.2 the above works as expected.
Regards,
Ali
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubsc
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231810
> >
> > Thanks
> >
> > matthias
> >
>
> Hi Matthias,
>
> I've updated the Severity, but the Version is better left at the lowest
> (earliest) reported/confirmed version,
On 30/09/2018 5:52 pm, Matthias Apitz wrote:
>
> Hello,
>
> Can some kind soul please modify this PR to reflect the Version and the
> affected people:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231810
>
> Thanks
>
> matthias
>
Hi Matth
Hello,
Can some kind soul please modify this PR to reflect the Version and the
affected people:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231810
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http
On Tue, Jun 19, 2018 at 5:11 AM, Rick Macklem wrote:
> Steve Wills wrote:
> On 06/18/18 17:42, Rick Macklem wrote:
> >> Steve Wills wrote:
> >>> Would it be possible or reasonable to use the client ID to log a
> message
> >>> telling the admin to ena
Steve Wills wrote:
On 06/18/18 17:42, Rick Macklem wrote:
>> Steve Wills wrote:
>>> Would it be possible or reasonable to use the client ID to log a message
>>> telling the admin to enable a sysctl to enable the hacks?
>> Yes. However, this client implementation
Hi,
On 06/18/18 17:42, Rick Macklem wrote:
Steve Wills wrote:
Would it be possible or reasonable to use the client ID to log a message
telling the admin to enable a sysctl to enable the hacks?
Yes. However, this client implementation id is only seen by the server
when the client makes a mount
Steve Wills wrote:
>Would it be possible or reasonable to use the client ID to log a message
>telling the admin to enable a sysctl to enable the hacks?
Yes. However, this client implementation id is only seen by the server
when the client makes a mount attempt.
I suppose it could log the m
s is by far the
best solution. The above should really only be a stop-gap, but would be
extensible should this sort of thing become more of the norm than is
desired.
Warner
On Mon, Jun 18, 2018 at 3:21 PM, Steve Wills wrote:
> Would it be possible or reasonable to use the client ID to log a
Would it be possible or reasonable to use the client ID to log a message
telling the admin to enable a sysctl to enable the hacks?
Steve
On 06/17/18 08:35, Rick Macklem wrote:
Hi,
Andreas Nagy has been doing a lot of testing of the NFSv4.1 client in ESXi 6.5u1
(VMware) against the FreeBSD
point people to the issues that should be
> addressed
> in the ESXi client.
> 2 - Put the hacks in, but only enable them based on a sysctl not enabled by
> default.
> (The main problem with this is when the server also has non-ESXi mounts.)
> 3 - Enable the hacks
a sysctl not enabled by
default.
(The main problem with this is when the server also has non-ESXi mounts.)
3 - Enable the hacks for ESXi client mounts only, using the implementation ID
it presents at mount time in its ExchangeID arguments.
- This is my preferred solution, but the RFC
> I have a few (3) new files in the projects/pnfs-planb-server subversion tree
> that all have the 2 clause FreeBSD copyright.
>
> Do I just add the "SPDX..." line for this license at the top of the copyright
> comment
> or is there some other exercise needed to be done for this?
Just add the SP
I have a few (3) new files in the projects/pnfs-planb-server subversion tree
that all have the 2 clause FreeBSD copyright.
Do I just add the "SPDX..." line for this license at the top of the copyright
comment
or is there some other exercise needed to be done for this?
Thanks, rick
__
osticReader.cpp
> -o Frontend/Se!
> rializedDiagnosticReader.o
> /usr/src/contrib/llvm/tools/clang/lib/Frontend/SerializedDiagnosticReader.cpp:5:1:
> error: expected unqualified-id
> /7 This fi!is dW0<8B>ibut[d<8C>nder ,<9C>
> University of IllinEV<90>Open
no-exceptions -fno-rtti -gline-tables-only -stdlib=libc++
-Wno-c++11-extensions -c
/usr/src/contrib/llvm/tools/clang/lib/Frontend/SerializedDiagnosticReader.cpp
-o Frontend/Se!
rializedDiagnosticReader.o
/usr/src/contrib/llvm/tools/clang/lib/Frontend/SerializedDiagnosticReader.cpp:5:1:
error: expe
Can I get someone to look at this RACCT destroy panic?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222027
It's been fixed before (see xref in the bug), but it's back.
Thanks!
--
Larry Rosenman https://people.FreeBSD.org/~ler/
Phone: +1 21
Can I get someone to look at:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222027
It's a bug that's been fixed before, but it's back.
Thanks!
--
Larry Rosenman https://people.FreeBSD.org/~ler/
Phone: +1 214-642-9640 E-Mail: l...
On Mon, Aug 21, 2017 at 6:51 AM, Julian Elischer wrote:
>
> I have the following (Azure) device (disk) id:
>
> dev.storvsc..%pnpinfo: classid=32412632-86cb-44a2-9b5c-50d1417354f5
> deviceid=-0001-8899--
>
> the question is: "how can I map that d
I have the following (Azure) device (disk) id:
dev.storvsc..%pnpinfo: classid=32412632-86cb-44a2-9b5c-50d1417354f5
deviceid=-0001-8899--
the question is: "how can I map that do /dev/da1"..
I know that for my device it IS /dev/da1
but how can I prove it? th
Greetings,
I'm seeing what looks like the same panic that was fixed for:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210315 on -CURRENT when
running
poudriere runs.
I have a TEXTDUMP.
The info file:
Dump header from device: /dev/mfid0p3
Architecture: amd64
Archite
Hello Vitalij;
Hello.
After updating my system to 11.0-ALPHA2 #20 r301583
I'm found that at last some application is broken.
here backtrace for xterm
#0 0x0008022d48b4 in mbsrtowcs_l () from /lib/libc.so.7
[New Thread 804816000 (LWP 102346/)]
(gdb) bt
#0 0x0008022d48b4 in mbsrtowcs_
Hello.
After updating my system to 11.0-ALPHA2 #20 r301583
I'm found that at last some application is broken.
here backtrace for xterm
#0 0x0008022d48b4 in mbsrtowcs_l () from /lib/libc.so.7
[New Thread 804816000 (LWP 102346/)]
(gdb) bt
#0 0x0008022d48b4 in mbsrtowcs_l () from /lib/
Hi,
Am Mittwoch, 30. März 2016 12:21 CEST, Kurt Jaeger schrieb:
> Hi!
>
> > > in mid 2015 I did submit a patch[1] to add an USB product ID to
> > > improve the out-of-the-box experience for owners of i-tec USB 2.0
> > > Docking Stations. As there is no
Hi!
> > in mid 2015 I did submit a patch[1] to add an USB product ID to
> > improve the out-of-the-box experience for owners of i-tec USB 2.0
> > Docking Stations. As there is no state change on the report since
> > then, I am wondering if I did address this the wrong way.
On 03/30/16 11:32, Kurt Jaeger wrote:
Hi!
in mid 2015 I did submit a patch[1] to add an USB product ID to
improve the out-of-the-box experience for owners of i-tec USB 2.0
Docking Stations. As there is no state change on the report since
then, I am wondering if I did address this the wrong way
Hi!
> in mid 2015 I did submit a patch[1] to add an USB product ID to
> improve the out-of-the-box experience for owners of i-tec USB 2.0
> Docking Stations. As there is no state change on the report since
> then, I am wondering if I did address this the wrong way.
You did everyt
Hi,
in mid 2015 I did submit a patch[1] to add an USB product ID to improve the
out-of-the-box experience for owners of i-tec USB 2.0 Docking Stations. As
there is no state change on the report since then, I am wondering if I did
address this the wrong way. I'd appreciate of one o
>
>
>
>> - uint32_t -> m_flowid_t is plain gratuitous. Now we need to include
>>mbuf.h in more places just to get this definition. What's the
>>advantage of this? style(9) isn't too fond of typedefs either. Also,
>>drivers *do* need to know the width of the flowid. At least lagg(4)
On 08/20/14 12:25, Hans Petter Selasky wrote:
On 08/20/14 20:44, Navdeep Parhar wrote:
On 08/20/14 00:34, Hans Petter Selasky wrote:
Hi,
A month has passed since the last e-mail on this topic, and in the
meanwhile some new patches have been created and tested:
Basically the approach has been
On 08/20/14 20:44, Navdeep Parhar wrote:
On 08/20/14 00:34, Hans Petter Selasky wrote:
Hi,
A month has passed since the last e-mail on this topic, and in the
meanwhile some new patches have been created and tested:
Basically the approach has been changed a little bit:
- The creation of hardwa
On 08/20/14 00:34, Hans Petter Selasky wrote:
Hi,
A month has passed since the last e-mail on this topic, and in the
meanwhile some new patches have been created and tested:
Basically the approach has been changed a little bit:
- The creation of hardware transmit rings has been made independen
rlapped in scope,
> >>both will be used (in the backend) to select a specific
> >>tx queue. I don't have a solution but would like to know
> >>how do you plan to address this -- does one have priority
> >>over the other, etc.
> >>
&
;
>> I have a few comments/concerns:
>>
>> + looks like flowid and txringid are overlapped in scope,
>>both will be used (in the backend) to select a specific
>>tx queue. I don't have a solution but would like to know
>>how do you plan to addres
-- does one have priority
over the other, etc.
Not 100% . In some cases the flowID is used differently than the
txringid, though it might be possible to join the two. Would need to
investigate current users of the flow ID.
+ related to the above, a (possibly unavoidable) side effect
of thi
On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky
wrote:
> Hi,
>
> A month has passed since the last e-mail on this topic, and in the
> meanwhile some new patches have been created and tested:
>
> Basically the approach has been changed a little bit:
>
> - The creation of hardware transmit rin
ERNEL
#include
#include
+#include
#include
#include
#endif
@@ -177,7 +178,8 @@
u_char inp_ip_ttl; /* (i) time to live proto */
u_char inp_ip_p; /* (c) protocol proto */
u_char inp_ip_minttl; /* (i) minimum TTL or drop */
- uint32_t inp_flowid; /* (x) flow id / queue id */
+ m_flowid_t i
ling parameters (all it does is bandwidth right now).
Hi Navdeep,
After reviewing your patch, we've concluded that we can't use your
flow-ID API's AS-IS for the mlxen hardware. We are working on a new
patch proposal after the feedback received here, and will probably post
s
On Wed, Jul 09, 2014 at 04:36:53PM +0200, Hans Petter Selasky wrote:
> On 07/08/14 21:17, Navdeep Parhar wrote:
...
> >
> >I think we need to design this to be as generic as possible. I have
> >quite a bit of code that does this stuff but I haven't pushed it
> >upstream or even offered it for revi
On 07/08/14 21:17, Navdeep Parhar wrote:
On 07/08/14 10:46, Hans Petter Selasky wrote:
Hi,
I'm working on a new feature which will allow TCP connections to be
timing controlled by the ethernet hardware driver, actually the mlxen
driver. The main missing piece in the kernel is to allow the mbuf'
't upset packet reordering and can be used by things like RSS for
scaling, and instead introduce a new connection ID to be used for your
purpose. That way the existing use of flowid for packet ordering and
flowid/flowtype for doing network scaling and netisr selection can
work together wit
On 07/08/14 10:46, Hans Petter Selasky wrote:
> Hi,
>
> I'm working on a new feature which will allow TCP connections to be
> timing controlled by the ethernet hardware driver, actually the mlxen
> driver. The main missing piece in the kernel is to allow the mbuf's
> flowid value to be overwritten
d many more places. Where would the right place be to put such
a definition? In "sys/mbuf.h"?
Comments are appreciated!
--HPS
=== sys/netinet/in_pcb.c
==
--- sys/netinet/in_pcb.c (revision 268358)
+++ sys/netinet/in_pcb.c (local)
On Sun, 14 Jul 2013 18:15:52 +0200
cpghost wrote:
> On 07/13/13 03:03, Dan Mack wrote:
> > I'm not sure exactly when but recently I've lost the subversion id
> > from kern.version and hence uname and motd.
> >
> > Subsequent fresh rebuilds from source don&
On Sun, 14 Jul 2013 18:15:52 +0200
cpghost wrote:
> On 07/13/13 03:03, Dan Mack wrote:
> > I'm not sure exactly when but recently I've lost the subversion id
> > from kern.version and hence uname and motd.
> >
> > Subsequent fresh rebuilds from source don&
On 07/13/13 03:03, Dan Mack wrote:
> I'm not sure exactly when but recently I've lost the subversion id
> from kern.version and hence uname and motd.
>
> Subsequent fresh rebuilds from source don't bring it back even after
> wiping out the tree.
>
> Toda
On Fri, Jul 12, 2013 at 08:03:45PM -0500, Dan Mack wrote:
> I'm not sure exactly when but recently I've lost the subversion id
> from kern.version and hence uname and motd.
>
> Subsequent fresh rebuilds from source don't bring it back even after
> wiping out the
I'm not sure exactly when but recently I've lost the subversion id from
kern.version and hence uname and motd.
Subsequent fresh rebuilds from source don't bring it back even after
wiping out the tree.
Today it looks like this:
root@olive:~ # uname -a
FreeBSD olive.example.c
On 01/15/2012 23:31, deeptec...@gmail.com wrote:
> Apparently, some upstream files have the following VCS Id:
> # $FreeBSD$
> and that anulls version checking.
Your src tree is not checked out properly. This usually happens because
at some point in the subversion 1.6 days you u
dically, all changes in /etc.
I was surprized that today, mergemaster did not mention one of my
changes in /etc:
*** Temp ./etc/rc.d/bgfsck and installed have the same CVS Id, deleting
So it now seems that it actually is intended for mergemaster to
mention only files that have changed in the ups
c.d/bgfsck and installed have the same CVS Id, deleting
So it now seems that it actually is intended for mergemaster to
mention only files that have changed in the upstream since the last
mergemaster run, but that funtionality fails. Apparently, some
upstream files have the following VCS Id:
# $Fr
On Wed Jul 6 11, Alexander Best wrote:
> On Wed Jul 6 11, Sergey Kandaurov wrote:
> > On 6 July 2011 13:19, Alexander Best wrote:
> > > hi there,
> > >
> > > any reason why bin/139389 hasn't been committed, yet? i think seeing the
> > > th
On Wed Jul 6 11, Sergey Kandaurov wrote:
> On 6 July 2011 13:19, Alexander Best wrote:
> > hi there,
> >
> > any reason why bin/139389 hasn't been committed, yet? i think seeing the
> > thread
> > id in top -H output is extremely useful!
>
> I thin
On 6 July 2011 13:19, Alexander Best wrote:
> hi there,
>
> any reason why bin/139389 hasn't been committed, yet? i think seeing the
> thread
> id in top -H output is extremely useful!
I think the main reason is that tid takes a log of space (6 digits + 2 spaces),
and top al
hi there,
any reason why bin/139389 hasn't been committed, yet? i think seeing the thread
id in top -H output is extremely useful!
cheers.
alex
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
On Mon, Nov 10, 2003 at 04:35:31PM +0100, Alexander Leidinger wrote:
> On Mon, 10 Nov 2003 16:19:27 +0100
> Bernd Walter <[EMAIL PROTECTED]> wrote:
>
> > USB2 hubs are currently not supported with high speed uplinks.
> > That's the reason why there is no EHCI support in GENERIC.
> > EHCI needs int
On Mon, 10 Nov 2003 16:19:27 +0100
Bernd Walter <[EMAIL PROTECTED]> wrote:
> USB2 hubs are currently not supported with high speed uplinks.
> That's the reason why there is no EHCI support in GENERIC.
> EHCI needs interrupt transfers first to support usb2.0 hubs at high
> speed uplinks with high s
On Mon, Nov 10, 2003 at 03:54:23PM +0100, Alexander Leidinger wrote:
> On Mon, 10 Nov 2003 13:55:39 +0100
> Bernd Walter <[EMAIL PROTECTED]> wrote:
>
> > But ehci doesn't control low/full speed ports.
> > The physical ports are multiplexed between ehci and ohci/uhci ports.
> > The switching is don
On Mon, 10 Nov 2003 13:55:39 +0100
Bernd Walter <[EMAIL PROTECTED]> wrote:
> But ehci doesn't control low/full speed ports.
> The physical ports are multiplexed between ehci and ohci/uhci ports.
> The switching is done without driver interaction.
Attached to the port is a
uhub1: NEC Corporation
On Mon, Nov 10, 2003 at 01:50:02PM +0100, Alexander Leidinger wrote:
> On Mon, 10 Nov 2003 13:19:12 +0100
> Bernd Walter <[EMAIL PROTECTED]> wrote:
>
> > I really doubt that you have a high speed mouse.
> > EHCI only supports high speed devices itself.
>
> But it shouldn't stop the entire system
On Mon, 10 Nov 2003 13:19:12 +0100
Bernd Walter <[EMAIL PROTECTED]> wrote:
> I really doubt that you have a high speed mouse.
> EHCI only supports high speed devices itself.
But it shouldn't stop the entire system if I attach an USB 1.1 mouse to
an ehci controlled port.
Bye,
Alexander.
--
On Mon, Nov 10, 2003 at 10:03:20AM +0100, Alexander Leidinger wrote:
> On Mon, 10 Nov 2003 00:11:37 +0100
> Bernd Walter <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Nov 09, 2003 at 11:56:19PM +0100, Pav Lucistnik wrote:
> > > It's that easy? Just adding device
On Mon, 10 Nov 2003 00:11:37 +0100
Bernd Walter <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 09, 2003 at 11:56:19PM +0100, Pav Lucistnik wrote:
> > It's that easy? Just adding device ID? I was under impression that you
> > need to write/modify a driver for a new chip.
On Sun, Nov 09, 2003 at 11:56:19PM +0100, Pav Lucistnik wrote:
> It's that easy? Just adding device ID? I was under impression that you
> need to write/modify a driver for a new chip.
Adding the ID is just beautifying the boot messages.
EHCI controllers are all compatible (modulo bug
#x27;
> > class= serial bus
> > subclass = USB
> > ---snip---
> >
> > It's an Intel 865PE chipset.
>
> Will take this - there is already a ticket open with a new ID - maybe the
> same.
It's that easy? Just adding device ID? I was under impres
class = USB
> ---snip---
>
> It's an Intel 865PE chipset.
Will take this - there is already a ticket open with a new ID - maybe the
same.
--
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECT
Hi,
I get this in the dmesg:
---snip---
ehci0: mem 0xfc00-0xfc0003ff irq 12 at d
evice 29.7 on pci0
ehci0: (New EHCI DeviceId=0x24dd8086)
---snip---
pciconv tells me:
---snip---
[EMAIL PROTECTED]:29:7:class=0x0c0320 card=0x24dd17f2 chip=0x24dd8086 rev=0x02
hdr=0x00
vendor = '
Hello Pav,
[ CC'ed to [EMAIL PROTECTED] ]
To all FreeBSD Bluetooth users
Please do not hesitate to ask questions! No question is too dumb.
When asking questions please CC to one of the FreeBSD mailing lists.
mobile@, net@ and [EMAIL PROTECTED] seems like a good choice.
This way your questions/re
mem 0xe000-0xefff
>at device
> > 0.0
> >
> > I added some debug output to agp_via.c to see what was going on:
> >
> > agp0: id is 0x6051106 (<- it prints the device id returned by
> > pci_get_devid(dev))
>
> Could you print
t;system.
> Anyway, with the standard agp module preloaded I get the following:
>
> pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND
>
> With my modified version I get:
>
> Preloaded elf module "/boot/kernel/agp.ko" at 0xc055115
http://lxr.linux.no/source/drivers/char/agp/agp.h
The linux kernel uses ID 0x0605 as well!
//David Holm
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND
With my modified version I get:
Preloaded elf module "/boot/kernel/agp.ko" at 0xc0551154.
agp0: mem 0xe000-0xefff at
device 0.0
on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ -
AE_NOT_FOUND
I added some de
On Mon, 13 Jan 2003 16:16:51 -0500 (EST)
John Baldwin <[EMAIL PROTECTED]> wrote:
>
> On 13-Jan-2003 David Holm wrote:
>
> What is the output of 'dmesg | grep agp' both with and without the patch?
>
Now this is strange. I cvsupped before recompiling the kernel. Now all I get when
loading the
m
table for \\_SB_.PCI0.AGP_ -
>AE_NOT_FOUND
>
> and I had to set the AGP rate to 0, otherwise the machine will hang randomly (not
>OpenGL related
> this time since it will hang even though I haven't run any OpenGL apps).
> I have tried not loading agp.ko and using nvidias agp
en though I haven't run any OpenGL apps).
I have tried not loading agp.ko and using nvidias agp (by enabling in XF86Config), but
that
yields the same result as agp_via.c without the added ID.
Now this is very strange, I did a search and indeed, the id is 0691. I was unable to
find the
page
On 11-Jan-2003 David Holm wrote:
> Hi,
> the FreeBSD kernel is missing the PCI ID for the Apollo Pro 133A PCI bridge even
>though it is
> supported by the agp_via code.
>
> Please see this pr:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=46983
>
> //David Holm
A
Hi,
the FreeBSD kernel is missing the PCI ID for the Apollo Pro 133A PCI bridge even
though it is
supported by the agp_via code.
Please see this pr:
http://www.freebsd.org/cgi/query-pr.cgi?pr=46983
//David Holm
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-cu
On Fri, 19 Apr 2002, Gregory Neil Shapiro wrote:
> This could lead to security problems.
Yes, I stipulated that.
> Although I really would prefer that people who are building from source pay
> attention to things like the handbook section on what to do when building
> from source:
In message: <[EMAIL PROTECTED]>
Gregory Neil Shapiro <[EMAIL PROTECTED]> writes:
: .if !defined(NO_SENDMAIL)
: mtree -deU -f ${.CURDIR}/mtree/sendmail.root.dist -p ${DESTDIR}/
: .endif
Wow! I hadn't read this before making my suggestion. Honest :-)
I like his solution.
Warne
1 - 100 of 150 matches
Mail list logo
