ACPI
I'v cvsup'ed from 5.0-RELEASE to RELENG_5_0_0 last night and ACPI doesn't work now. When booting I'v got a message: "ACPI autoload failed - no such file or directory". How to fix? Sem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S
I have been using diskless boots for some time, and selecting different
kernels is very easy, see
ftp://ftp.cs.huji.ac.il/users/danny/freebsd/diskless-boot
danny
>
> :Seems like diskless clients would have to have separate kernels with
> :the "option BOOTP" while any servers must omit this option.
> :
> :How do you keep them separate? or am I missing something fundamental?
> :
> :Thanks.
>
> You can compile pxeboot with the LOADER_TFTP_SUPPORT=YES option.
> Add LOADER_TFTP_SUPPORT=YES to your /etc/make.conf and recompile
> /usr/src/sys/boot (make clean; make obj; make; make install from
> within /usr/src/sys/boot).
>
> If you do this pxeboot will attempt to load the kernel via TFTP
> instead of via NFS. You then put your kernel in /tftpboot right along
> side a copy of pxeboot.
>
> This allows you to netboot a different kernel then the one in the
> server's root directory.
>
> :PS: could you show me your dhcpd.conf so I can see how you're
> :specifying your root filesystem? Mine's currently:
> : option root-path"192.168.255.185:/";
>
> subnet 216.240.41.0 netmask 255.255.255.192 {
> range ...;
>
> server-name "apollo.backplane.com";
> option subnet-mask 255.255.255.192;
> option domain-name-servers 216.240.41.2;
> option domain-name "backplane.com";
> option broadcast-address 216.240.41.63;
> option routers 216.240.41.15;
>
> group {
> filename "pxeboot";
> option root-path "216.240.41.2:/";
>
> host net1 {
> # Alternative server to boot -current
> # option root-path "216.240.41.12:/";
> # next-server 216.240.41.12;
> hardware ethernet ...;
> }
> host net2 {
> hardware ethernet ...;
> }
> ...
> }
> }
>
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [Re: cc: Internal error: Illegal instruction (program as)
Vallo Kallaste wrote: > On Sat, Feb 22, 2003 at 11:43:01AM -0500, "Paul A. Howes" > <[EMAIL PROTECTED]> wrote: > > I am receiving some strange errors during a buildworld of 5.0-RELEASE-p2 > > from 5.0-RELEASE-p1. The location of where the failure varies, but the > > program that causes the failure is the same every time: "as". > > > > The errors are a variety of signal 10 and signal 4. I do find an > > "as.core" file under /usr/obj, but as is stripped, so there are no > > debugging symbols or listing that I can provide. > > > > The strange thing is that I have been able to successfully build > > XFree86, KDE, and many other ports on this system. I followed the > > 4.x-to-5.0 upgrade directions to the letter about a month ago, and have > > had no major problems before this. > > > > Any help would be greatly appreciated! > > As John Hay suggested, add DISABLE_PSE and DISABLE_PG_G to your > kernel configuration and rebuild/install kernel. I was having > _exactly_ same behaviour; at the beginning of test runs to narrow > the problem a bit I did _large_ ports builds, which ran for 1,5 > days.. flawlessly, as you had seen. Then changed test method to > parallel (make -j4) buildworld and the problem occasionally appeared > from nowhere again. The flags mentioned before will work, as I > haven't had any problems after enabling them (months of time now). I thought this was the default in 5.x GENERIC; has someone turned these options off in the default config?!? I certainly haven't seen changes to locore.s, pmap.c, and machdep.c that would fix the problem by working around the CPU bug. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: ipsec packet filtering change
This may affect your ipfw/ipf rules. If you are happy with the current behaviour then add IPSEC_FILTERGIF to your kernel config file. Sam - Original Message - From: "Sam Leffler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, February 22, 2003 4:47 PM Subject: cvs commit: src/sys/netinet ip_input.c src/sys/conf NOTES options > sam 2003/02/22 16:47:07 PST > > Modified files: > sys/netinet ip_input.c > sys/conf NOTES options > Log: > Add a new config option IPSEC_FILTERGIF to control whether or not > packets coming out of a GIF tunnel are re-processed by ipfw, et. al. > By default they are not reprocessed. With the option they are. > > This reverts 1.214. Prior to that change packets were not re-processed. > After they were which caused problems because packets do not have > distinguishing characteristics (like a special network if) that allows > them to be filtered specially. > > This is really a stopgap measure designed for immediate MFC so that > 4.8 has consistent handling to what was in 4.7. > > PR: 48159 > Reviewed by:Guido van Rooij <[EMAIL PROTECTED]> > MFC after: 1 day > > Revision ChangesPath > 1.1129+11 -0 src/sys/conf/NOTES > http://cvsweb.FreeBSD.org/src/sys/conf/NOTES.diff?r1=1.1128&r2=1.1129 > 1.374 +1 -0 src/sys/conf/options > http://cvsweb.FreeBSD.org/src/sys/conf/options.diff?r1=1.373&r2=1.374 > 1.226 +7 -0 src/sys/netinet/ip_input.c > http://cvsweb.FreeBSD.org/src/sys/netinet/ip_input.c.diff?r1=1.225&r2=1.226 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current buildworld fails 24 hours
I have the following error with make buildworld since Feb. 21th, 0900GMT with my P3x2 box. boot2 seems exceeding the size limit, any fix? ::: sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s rm -f boot2.s.tmp as -o boot2.o boot2.s ld -nostdlib -static -N --gc-sections -Ttext 0x2000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.01 size=780 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=1691 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1f25 text=114 data=1e11 org=0 entry=0 -293 bytes available *** Error code 1 1 error *** Error code 2 1 error To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SSH (TCP?) lag
On Sun, 23 Feb 2003, Giorgos Keramidas wrote: > On 2003-02-22 20:05, Andre Guibert de Bruet <[EMAIL PROTECTED]> wrote: > > > I noticed the same thing... then > > > > > > try sysctl net.inet.tcp.delayed_ack=0 > > > > > > fixed the issue > > > > That worked. Shouldn't this sysctl be turned off by default? > > Nah. Not really. Delaying acks can save quite a lot of of bandwidth > for bulk data transfers. Having read up on the issue, I can understand the reasoning for wanting delayed_ack on by default. >From tuning(7): With delayed acks turned off, the acknowledgement may be sent in its own packet, before the remote service has a chance to echo the data it just received. This same concept also applies to any interactive protocol (e.g. SMTP, WWW, POP3), and can cut the number of tiny packets flowing across the network in half. The FreeBSD delayed ACK implementation also follows the TCP protocol rule that at least every other packet be acknowledged even if the standard 100ms timeout has not yet passed. Normally the worst a delayed ACK can do is slightly delay the teardown of a connection, or slightly delay the ramp-up of a slow- start TCP connection. I find myself waiting up to two seconds for data to flush to the terminal on a 28 line 'ls -l'. net.inet.tcp.delayed_ack doesn't appear to cause this behavior on 4.7-stable. Did we inadvertently break the 100ms clause with the latest TCP patches? Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S
Matthew Dillon <[EMAIL PROTECTED]> writes: > If you do this pxeboot will attempt to load the kernel via TFTP > instead of via NFS. You then put your kernel in /tftpboot right along > side a copy of pxeboot. > This allows you to netboot a different kernel then the one in the > server's root directory. Ah... [sound of lightbulb going on] I was wondering why it would be useful to get the kernel via TFTP rather than the NFS mount. Makes sense. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BOOT2_UFS=UFS1_ONLY works for today's current
keramida> Just in case anyone tries to build today's current and sees keramida> it fail because of boot2, you can always set BOOT2_UFS=UFS1_ONLY keramida> or BOOT2_UFS=UFS2_ONLY in your make.conf and rebuild. It should work, but it can't be used for a release distribution:) -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SSH (TCP?) lag
On 2003-02-22 20:05, Andre Guibert de Bruet <[EMAIL PROTECTED]> wrote: > > I noticed the same thing... then > > > > try sysctl net.inet.tcp.delayed_ack=0 > > > > fixed the issue > > That worked. Shouldn't this sysctl be turned off by default? Nah. Not really. Delaying acks can save quite a lot of of bandwidth for bulk data transfers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
BOOT2_UFS=UFS1_ONLY works for today's current
Just in case anyone tries to build today's current and sees it fail because of boot2, you can always set BOOT2_UFS=UFS1_ONLY or BOOT2_UFS=UFS2_ONLY in your make.conf and rebuild. Note that you should have at least one alternative boot method (floppy or CDROM) if you happen to accidentally use UFS1_ONLY on a ufs version-2 system or vice versa. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S
:Seems like diskless clients would have to have separate kernels with
:the "option BOOTP" while any servers must omit this option.
:
:How do you keep them separate? or am I missing something fundamental?
:
:Thanks.
You can compile pxeboot with the LOADER_TFTP_SUPPORT=YES option.
Add LOADER_TFTP_SUPPORT=YES to your /etc/make.conf and recompile
/usr/src/sys/boot (make clean; make obj; make; make install from
within /usr/src/sys/boot).
If you do this pxeboot will attempt to load the kernel via TFTP
instead of via NFS. You then put your kernel in /tftpboot right along
side a copy of pxeboot.
This allows you to netboot a different kernel then the one in the
server's root directory.
:PS: could you show me your dhcpd.conf so I can see how you're
:specifying your root filesystem? Mine's currently:
: option root-path"192.168.255.185:/";
subnet 216.240.41.0 netmask 255.255.255.192 {
range ...;
server-name "apollo.backplane.com";
option subnet-mask 255.255.255.192;
option domain-name-servers 216.240.41.2;
option domain-name "backplane.com";
option broadcast-address 216.240.41.63;
option routers 216.240.41.15;
group {
filename "pxeboot";
option root-path "216.240.41.2:/";
host net1 {
# Alternative server to boot -current
# option root-path "216.240.41.12:/";
# next-server 216.240.41.12;
hardware ethernet ...;
}
host net2 {
hardware ethernet ...;
}
...
}
}
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S
Matthew Dillon <[EMAIL PROTECTED]> writes: > # ls -lR /conf > drwxr-xr-x 5 root wheel 512 Dec 21 10:37 base > drwxr-xr-x 3 root wheel 512 Dec 19 21:56 default ... > /conf/base/etc: > -rw-r--r-- 1 root wheel 18 Dec 19 22:10 diskless_remount > -rw-r--r-- 1 root wheel 6 Dec 19 22:22 md_size ... > /conf/default/etc: > -rw-r--r-- 1 root wheel 184 Feb 18 18:16 fstab > -rw-r--r-- 1 root wheel 867 Dec 21 00:04 rc.conf > -rw-r--r-- 1 root wheel 197 Feb 18 18:19 rc.local I fiddled "standard-supfile" to get CURRENT (rather than RELENG_5_0) and am now able to boot with a config like you describe. Thanks! You appear to be doing as diskless(8) suggests: mount the server's "/" and therefore get its /etc and boot it's kernel (no need to populate a different directory with clone_root). But that kernel must have "option BOOTP" according to the manpage. If I recompile my server's kernel with this, the diskless client boots but if the server will no longer boot because it's hung sending out bootp requests which noone answers. Seems like diskless clients would have to have separate kernels with the "option BOOTP" while any servers must omit this option. How do you keep them separate? or am I missing something fundamental? Thanks. PS: could you show me your dhcpd.conf so I can see how you're specifying your root filesystem? Mine's currently: option root-path"192.168.255.185:/"; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SSH (TCP?) lag
On Sat, 22 Feb 2003, Erik Greenwald wrote: > On Sat, Feb 22, 2003 at 10:28:02AM -0500, Andre Guibert de Bruet wrote: > > > > I'm experiencing some rather severe lag during ssh sessions, while running > > GENERIC on -current (cvsupped as of 5 minutes ago). This symptom first > > started occuring a couple of days ago with the merging of some TCP > > patches. > > > > I noticed the same thing... then > > try sysctl net.inet.tcp.delayed_ack=0 > > fixed the issue That worked. Shouldn't this sysctl be turned off by default? > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/share/man/man4 Makefile
In message: <[EMAIL PROTECTED]> "James E. Flemer" <[EMAIL PROTECTED]> writes: : There are some non-if_* modules in there now that seem to : be only documented in /usr/src, exca is a good example. exca is there just for the pleasure of cbb (and soon pcic)... No one would load it on their own. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VIA8235 audio support
The VIA8233/8235 audio driver has undergone another revision in an attempt to provide support for the VIA8235. The code is in -CURRENT as of 5 minutes ago. Several people have reported quiet/inaudible sound on P4 boards with this southbridge. If you have a VIA8235 based board, I'd be interested to know if it works for you as several people have reported quiet/near-silent operation with this chipset and I do not have the relevant h/w. The new code paths are used by the h/w that I do have access to (VIA8233C) so testing this code is low risk: the worst case is no sound :-) If you have a suitable board, but are not running -CURRENT. Let me know what version of FreeBSD you'd like it for and I'll do the relevant work for some small number of requests since I really want to resolve this issue. Thanks - Orion To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TCP connections timing out "real fast"
On 2003-02-22 11:47, Robert Watson <[EMAIL PROTECTED]> wrote: > Maybe I'm just too impatient, but it strikes me that I used to get more > time before TCP gave up during a brief outage. FWIW, I'm seeing delays in interactive sessions, and lots of timeouts for `fetchmail -v' runs. I just started rebuilding a kernel with: % cd /usr/src/sys % cvs up -APd -D '2003-02-17 08:00 UTC' to see if I can track down the change that caused this. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT kernel freezing or rebooting
Daniel Flickinger wrote:
kernels built from cvsup date tags:
1200 GMT 21 Feb 2003
1200 GMT 22 Feb 2003
either hang hard or freeze and fall out to reboot. No
error messages logged. Both were full make world, etc.
followed by mergemaster. apache 1.3.27, X, Mozilla, etc
running.
Previous build from cvsup date tag 1200 GMT 14 Feb 2003 ran
the week with zero problems. Will try again tomorrow morning
(1200 GMT) if there are "interesting" kernel commits.
And you managed to build it at all?
I get the following on a cvsup from about few ours ago.
dd if=/dev/zero of=boot2.ldr bs=276 count=1 2>/dev/null
nm -t d boot1.out | awk '/([0-9])+ T xread/ { x = $1 - ORG1; printf("#define XREADORG
%#x\n", REL1 +
x) }' ORG1=`printf "%d" 0x7c00` REL1=`printf "%d" 0x700` > boot2.h
cc -elf -ffreestanding -Os -fno-builtin -fno-guess-branch-probability
-fomit-frame-pointer -mno-align
-long-strings -mrtd -DUFS1_AND_UFS2 -I/usr/src/sys/boot/i386/boot2/../../common
-I/usr/src/sys/boo
t/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align
-Wmissing-decl
arations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow
-Wstrict-prototypes -Wwrite-s
trings -ffreestanding -mpreferred-stack-boundary=2-S -o boot2.s.tmp
/usr/src/sys/boot/i386/boot2/b
oot2.c
sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s
rm -f boot2.s.tmp
as -o boot2.o boot2.s
as --defsym SIOPRT=0x3f8 --defsym SIOFMT=0x3 --defsym SIOSPD=9600
/usr/src/sys/boot/i386/boot2/sio.s -o sio.o
ld -nostdlib -static -N --gc-sections -Ttext 0x2000 -o boot2.out
/usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o
objcopy -S -O binary boot2.out boot2.bin
btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l
boot2.ldr -o boot2.ld -P 1 boot2.bin
kernel: ver=1.01 size=780 load=9000 entry=9010 map=16M pgctl=1:1
client: fmt=bin size=1691 text=0 data=0 bss=0 entry=0
output: fmt=bin size=1f25 text=114 data=1e11 org=0 entry=0
-293 bytes available
*** Error code 1
Stop in /usr/src/sys/boot/i386/boot2.
*** Error code 1
Stop in /usr/src/sys/boot/i386.
*** Error code 1
Stop in /usr/src/sys/boot.
*** Error code 1
Stop in /usr/src/sys.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: network stalls in top of the tree current
In article you write: >/me too. Try sysctl net.inet.tcp.delayed_ack=0. > >I suspect that commit: > >http://docs.freebsd.org/cgi/getmsg.cgi?fetch=678980+0+current/cvs-src Yes, it looks like I screwed up. Turn off delayed_acks until get a fix (being tested) into the tree. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[Re: cc: Internal error: Illegal instruction (program as)
On Sat, Feb 22, 2003 at 11:43:01AM -0500, "Paul A. Howes" <[EMAIL PROTECTED]> wrote: > I am receiving some strange errors during a buildworld of 5.0-RELEASE-p2 > from 5.0-RELEASE-p1. The location of where the failure varies, but the > program that causes the failure is the same every time: "as". > > The errors are a variety of signal 10 and signal 4. I do find an > "as.core" file under /usr/obj, but as is stripped, so there are no > debugging symbols or listing that I can provide. > > The strange thing is that I have been able to successfully build > XFree86, KDE, and many other ports on this system. I followed the > 4.x-to-5.0 upgrade directions to the letter about a month ago, and have > had no major problems before this. > > Any help would be greatly appreciated! As John Hay suggested, add DISABLE_PSE and DISABLE_PG_G to your kernel configuration and rebuild/install kernel. I was having _exactly_ same behaviour; at the beginning of test runs to narrow the problem a bit I did _large_ ports builds, which ran for 1,5 days.. flawlessly, as you had seen. Then changed test method to parallel (make -j4) buildworld and the problem occasionally appeared from nowhere again. The flags mentioned before will work, as I haven't had any problems after enabling them (months of time now). -- Vallo Kallaste To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SSH (TCP?) lag
On Sat, Feb 22, 2003 at 10:28:02AM -0500, Andre Guibert de Bruet wrote: > Hi, > > I'm experiencing some rather severe lag during ssh sessions, while running > GENERIC on -current (cvsupped as of 5 minutes ago). This symptom first > started occuring a couple of days ago with the merging of some TCP > patches. > I noticed the same thing... then try sysctl net.inet.tcp.delayed_ack=0 fixed the issue -- -Erik <[EMAIL PROTECTED]> [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: network stalls in top of the tree current
On 19:48+0200, Feb 22, 2003, Giorgos Keramidas wrote: > I've been seeing huge delays and a major drop of performance in > network performace in recent -current kernels. I was wondering, has > anyone else seen something similar or should I just look at other > things? A typical example of what I see the past 2-3 days is: > > [EMAIL PROTECTED]:40]/home/giorgos$ fetchmail -a -K > fetchmail: No mail for keramida at igloo.linux.gr > 22 messages for keramida at diogenis.ceid.upatras.gr (85546 octets). > reading message [EMAIL PROTECTED]:1 of 22 (8987 octets) flushed > reading message [EMAIL PROTECTED]:2 of 22 (3230 octets) ... flushed > reading message [EMAIL PROTECTED]:3 of 22 (2615 > octets) .fetchmail: timeout after 60 seconds. > fetchmail: socket error while fetching from diogenis.ceid.upatras.gr > fetchmail: Query status=2 (SOCKET) > > It used to take just 2-3 seconds to get a message with fetchmail, and > now it times out so often that sometimes I have to use scp to copy my > mail at home. Similarly long delays often happen with scp too. /me too. Try sysctl net.inet.tcp.delayed_ack=0. I suspect that commit: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=678980+0+current/cvs-src -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem in /usr/src/sys/boot/i386/boot2
[EMAIL PROTECTED] wrote: > Hello, I have a problem with -CURRENT. As I try to btxld: > > /usr/src/sys/boot/i386/boot2 > > btxld -v -E 0x2000 -f bin -b > /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o > boot2.ld -P 1 boot2.bin > kernel: ver=1.01 size=780 load=9000 entry=9010 map=16M pgctl=1:1 > client: fmt=bin size=1691 text=0 data=0 bss=0 entry=0 > output: fmt=bin size=1f25 text=114 data=1e11 org=0 entry=0 > -293 bytes available > *** Error code 1 > > Assumption: -293 bytes available is due to some sector mapping on the > disk of some kind, where we need boot2 to fit into. This is caused by Kirk Mckusick's recent commits to src/sys/ufs/ffs/fs.h where he changed a couple of macros to do operations with 64 bit precision instead of 32 bit like before (and that was a bug). Unfortunately, gcc/i386 is really inefficient at doing 64 bit operations and this has blown boot2's code size through the roof. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
usb patch: outgoing interrupt pipes
Hi,
I have a patch that adds outgoing interrupt pipes to the usb stack. I
needed it to make a Lego infrared tower work with FreeBSD. Outgoing
interrupt pipes are part of the USB 1.1 spec, but I think our usb
code comes from before that, so it only have incoming interrupt pipes.
Is there anybody that would like to review this or shall I just go
ahead and commit it? One thing to note is that the patch only fix
it for uhci controllers. I haven't been able to get my hands on an
ohci controller.
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
Index: share/man/man4/ugen.4
===
RCS file: /home/ncvs/src/share/man/man4/ugen.4,v
retrieving revision 1.2
diff -u -r1.2 ugen.4
--- share/man/man4/ugen.4 22 Nov 2001 11:56:54 - 1.2
+++ share/man/man4/ugen.4 14 Feb 2003 10:20:01 -
@@ -104,9 +104,12 @@
should be used.
All I/O operations on a bulk endpoint are unbuffered.
.Pp
-The interrupt transfer mode can only be in.
-To perform input from an interrupt endpoint
+The interrupt transfer mode can be in or out depending on the
+endpoint.
+To perform I/O on an interrupt endpoint
.Xr read 2
+and
+.Xr write 2
should be used.
A moderate amount of buffering is done
by the driver.
Index: sys/dev/usb/ugen.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ugen.c,v
retrieving revision 1.66
diff -u -r1.66 ugen.c
--- sys/dev/usb/ugen.c 21 Jan 2003 08:55:44 - 1.66
+++ sys/dev/usb/ugen.c 12 Feb 2003 16:05:24 -
@@ -419,6 +419,13 @@
edesc = sce->edesc;
switch (edesc->bmAttributes & UE_XFERTYPE) {
case UE_INTERRUPT:
+ if (dir == OUT) {
+ err = usbd_open_pipe(sce->iface,
+ edesc->bEndpointAddress, 0, &sce->pipeh);
+ if (err)
+ return (EIO);
+ break;
+ }
isize = UGETW(edesc->wMaxPacketSize);
if (isize == 0) /* shouldn't happen */
return (EINVAL);
@@ -764,6 +771,30 @@
DPRINTFN(1, ("ugenwrite: transfer %d bytes\n", n));
err = usbd_bulk_transfer(xfer, sce->pipeh, 0,
sce->timeout, buf, &n,"ugenwb");
+ if (err) {
+ if (err == USBD_INTERRUPTED)
+ error = EINTR;
+ else if (err == USBD_TIMEOUT)
+ error = ETIMEDOUT;
+ else
+ error = EIO;
+ break;
+ }
+ }
+ usbd_free_xfer(xfer);
+ break;
+ case UE_INTERRUPT:
+ xfer = usbd_alloc_xfer(sc->sc_udev);
+ if (xfer == 0)
+ return (EIO);
+ while ((n = min(UGETW(sce->edesc->wMaxPacketSize),
+ uio->uio_resid)) != 0) {
+ error = uiomove(buf, n, uio);
+ if (error)
+ break;
+ DPRINTFN(1, ("ugenwrite: transfer %d bytes\n", n));
+ err = usbd_intr_transfer(xfer, sce->pipeh, 0,
+ sce->timeout, buf, &n,"ugenwi");
if (err) {
if (err == USBD_INTERRUPTED)
error = EINTR;
Index: sys/dev/usb/uhci.c
===
RCS file: /home/ncvs/src/sys/dev/usb/uhci.c,v
retrieving revision 1.130
diff -u -r1.130 uhci.c
--- sys/dev/usb/uhci.c 21 Jan 2003 08:55:44 - 1.130
+++ sys/dev/usb/uhci.c 12 Feb 2003 16:27:48 -
@@ -149,6 +149,7 @@
/* Interrupt pipe */
struct {
int npoll;
+ int isread;
uhci_soft_qh_t **qhs;
} intr;
/* Bulk pipe */
@@ -2032,6 +2033,7 @@
uhci_soft_td_t *data, *dataend;
uhci_soft_qh_t *sqh;
usbd_status err;
+ int isread, endpt;
int i, s;
if (sc->sc_dying)
@@ -2045,8 +2047,15 @@
panic("uhci_device_intr_transfer: a request\n");
#endif
- err = uhci_alloc_std_chain(upipe, sc, xfer->length, 1, xfer->flags,
- &xfer->dmabuf, &data, &dataend);
+ endpt = upipe->pipe.endpoint->edesc->bEndpointAddress;
+ isread = UE_GET_DIR(endpt) == UE_DIR_IN;
+ sqh = upipe->u.bulk.sqh;
+
+ upipe->u.intr.isread = isread;
+
+ err = uhci_alloc_std_chain(upipe, sc, xfer->length, isread,
+
Re: cc: Internal error: Illegal instruction (program as)
On Sat, Feb 22, 2003 at 11:43:01AM -0500, Paul A. Howes wrote: > All, > > I am receiving some strange errors during a buildworld of 5.0-RELEASE-p2 > from 5.0-RELEASE-p1. The location of where the failure varies, but the > program that causes the failure is the same every time: "as". > > The errors are a variety of signal 10 and signal 4. I do find an > "as.core" file under /usr/obj, but as is stripped, so there are no > debugging symbols or listing that I can provide. > > The strange thing is that I have been able to successfully build > XFree86, KDE, and many other ports on this system. I followed the > 4.x-to-5.0 upgrade directions to the letter about a month ago, and have > had no major problems before this. > > Any help would be greatly appreciated! > > -- > Paul A. Howes > > > > > Hardware > > Tyan S2099GNNR motherboard > Intel P4-2.4/533 > Crucial 512 MB PC2100 DIMM > Maxtor 20 GB hard drive. > > I see it is a P4, try adding options DISABLE_PSE and DISABLE_PG_G to your kernel. My 1.8G P4 do the same without them. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Elaboração de cartas comerciais
COMUNICADO IMPORTANTE!! Estamos lançando o KIT DE CARTAS COMERCIAIS, que sana suas dúvidas na elaboração de: agradecimentos, atestados e declarações, avisos, cartas de cobrança, cartas em inglês, comunicados, convites, contratos, propostas, empregos, solicitações e pedidos, telegramas, cartas por e-mail, etc. Composto de 02 (dois) disquetes com 150 modelos de documentos cada um, mais livreto 20 páginas, com técnicas de redação comercial. Indicado para: secretárias em geral, gerências, Rh, executivos, estudantes e empresas de toda ordem. Este kit possui um preço ínfimo em relação ao que poderá gerar no aperfeiçoamento da comunicação de sua empresa. Acesse nossa Home Page para mais detalhes: http://www.redacaodecartas.ihp.com.br Ps: Caso não queira receber novas mensagens e novidades sobre esse assunto, acesse: http://www.remova-me.ihp.com.br To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
On Saturday, 22. February 2003 12:31, [EMAIL PROTECTED] wrote: > In message <[EMAIL PROTECTED]>, Michael Class writes: > >Hello, > > > >just as a data-point. I am seeing the same behaviour. It started with a > >kernel from Feb 21th. The kernel from Feb. 20th works o.k. > > > >Enclosed is the dmesg out, if that helps. > > Please try "boot -v" and send dmesg. > > Also, please try entering "?" to root device prompt to see what devices > are available. Unfortunately, I can't send you the requested output, because I've no serial console here to be able to trace the boot infos, and further, I can't get the kernel to create a crash dump. I do have a line saying 'dumpdev="ad0s3b"' in my loader.conf but the kernel seems to ignore my wishes when it panics :-(. Christian. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
network stalls in top of the tree current
I've been seeing huge delays and a major drop of performance in network performace in recent -current kernels. I was wondering, has anyone else seen something similar or should I just look at other things? A typical example of what I see the past 2-3 days is: [EMAIL PROTECTED]:40]/home/giorgos$ fetchmail -a -K fetchmail: No mail for keramida at igloo.linux.gr 22 messages for keramida at diogenis.ceid.upatras.gr (85546 octets). reading message [EMAIL PROTECTED]:1 of 22 (8987 octets) flushed reading message [EMAIL PROTECTED]:2 of 22 (3230 octets) ... flushed reading message [EMAIL PROTECTED]:3 of 22 (2615 octets) .fetchmail: timeout after 60 seconds. fetchmail: socket error while fetching from diogenis.ceid.upatras.gr fetchmail: Query status=2 (SOCKET) It used to take just 2-3 seconds to get a message with fetchmail, and now it times out so often that sometimes I have to use scp to copy my mail at home. Similarly long delays often happen with scp too. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT kernel freezing or rebooting
Do you have the debugging options enabled? makeoptions DEBUG=-g options DDB at the VERY least. Try also compiling with INVARIANTS and INVARIANT_SUPPORT... On Sat, Feb 22, 2003 at 05:10:15PM +, Daniel Flickinger wrote: > kernels built from cvsup date tags: > > 1200 GMT 21 Feb 2003 > 1200 GMT 22 Feb 2003 > > either hang hard or freeze and fall out to reboot. No > error messages logged. Both were full make world, etc. > followed by mergemaster. apache 1.3.27, X, Mozilla, etc > running. > > Previous build from cvsup date tag 1200 GMT 14 Feb 2003 ran > the week with zero problems. Will try again tomorrow morning > (1200 GMT) if there are "interesting" kernel commits. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TCP connections timing out "real fast"
On Sat, 22 Feb 2003, Bosko Milekic wrote: > On Sat, Feb 22, 2003 at 10:57:05AM -0500, Robert Watson wrote: > > > > Don't yet have any quantitative evidence that this is the case, but I feel > > like TCP sessions have been timing out on me a lot faster than they used > > to. For example, yesterday a machine got unplugged from the network for > > about 15 seconds: in that time, the SSH sessions to the machine timed out > > and disconnected. This morning, a machine generated a lot of output to > > the serial console keeping it substantially busy for about 20 seconds; in > > that time, the SSH session to it timed out. I'm going to see if I can't > > generate some tcpdump traces later today to confirm my suspicions, but was > > wondering if anyone else (annecdotally or not) has seen similar things? > > I have (annecdotally) but I believe I'm seeing it on -STABLE too... > it's tough to tell... how recent are your -CURRENT machines, though, > and is it something that you think just started happening or has it > been happening for a while now? FWIW, I can't say for sure that this > is related to TCP connection timeouts. Here's a packet trace. cboss.gw.tislabs.com is running the January 30 5.0-CURRENT. crash2.gw.tislabs.com is running a -CURRENT from yesterday. Here's the output from the ssh session: crash2:~> sysctl -a | grep witnessRead from remote host crash2.gw.tislabs.com: Operation timed out Connection to crash2.gw.tislabs.com closed. cboss:/data/stock/src/sys/kern> The sysctl -a takes a little while to run because it currently generates a boatload of serial console output due to sleep warnings. Running it on the console takes about 35 seconds to complete. The disconnect appears to happen half way through that time. Here's the trace, as recorded on cboss.gw.tislabs.com, starting about when I hit enter at the end of the sysctl command line; it looks like it takes about 20 seconds to decide to disconnect after a series of rapid retransmissions: cboss# tcpdump -r /tmp/packets 11:40:36.826529 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: P 347024 1365:3470241385(20) ack 49959986 win 33304 ( DF) [tos 0x10] 11:40:36.845660 crash2.gw.tislabs.com.ssh > cboss.gw.tislabs.com.49423: P 1:21(2 0) ack 20 win 33304 (DF) [tos 0x10] 11:40:36.940001 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: . ack 21 win 33304 (DF) [tos 0x10] 11:40:37.758432 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: P 20:40( 20) ack 21 win 33304 (DF) [tos 0x10] 11:40:37.775625 crash2.gw.tislabs.com.ssh > cboss.gw.tislabs.com.49423: P 21:41( 20) ack 40 win 33304 (DF) [tos 0x10] 11:40:37.868677 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: . ack 41 win 33304 (DF) [tos 0x10] 11:40:40.780735 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: P 40:60( 20) ack 41 win 33304 (DF) [tos 0x10] 11:40:41.008779 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: P 40:60( 20) ack 41 win 33304 (DF) [tos 0x10] 11:40:41.268786 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: P 40:60( 20) ack 41 win 33304 (DF) [tos 0x10] 11:40:41.588797 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: P 40:60( 20) ack 41 win 33304 (DF) [tos 0x10] 11:40:42.028822 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: P 40:60( 20) ack 41 win 33304 (DF) [tos 0x10] 11:40:42.708951 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: P 40:60( 20) ack 41 win 33304 (DF) [tos 0x10] 11:40:43.868880 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: P 40:60( 20) ack 41 win 33304 (DF) [tos 0x10] 11:40:45.988960 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: P 40:60( 20) ack 41 win 33304 (DF) [tos 0x10] 11:40:48.109027 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: P 40:60( 20) ack 41 win 33304 (DF) [tos 0x10] 11:40:50.229094 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: P 40:60( 20) ack 41 win 33304 (DF) [tos 0x10] 11:40:52.349177 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: P 40:60( 20) ack 41 win 33304 (DF) [tos 0x10] 11:40:54.469236 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: P 40:60( 20) ack 41 win 33304 (DF) [tos 0x10] 11:40:56.589311 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: P 40:60( 20) ack 41 win 33304 (DF) [tos 0x10] 11:40:58.709370 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: R 60:60( 0) ack 41 win 33304 (DF) [tos 0x10] 11:41:15.784279 crash2.gw.tislabs.com.ssh > cboss.gw.tislabs.com.49423: . ack 60 win 33304 (DF) [tos 0x10] 11:41:15.784337 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: R 347024 1425:3470241425(0) win 0 (DF) [tos 0x10] 11:41:15.785617 crash2.gw.tislabs.com.ssh > cboss.gw.tislabs.com.49423: . ack 60 win 33304 (DF) [tos 0x10] 11:41:15.785659 cboss.gw.tislabs.com.49423 > crash2.gw.tislabs.com.ssh: R 347024 1425:3470241425(0) win 0 (DF) [tos 0x10] 11:41:15.785693 crash2.gw.tislabs.com.ssh > cboss.gw.tislabs.com.49423: . ack 60 win 33304 (DF) [
cc: Internal error: Illegal instruction (program as)
All, I am receiving some strange errors during a buildworld of 5.0-RELEASE-p2 from 5.0-RELEASE-p1. The location of where the failure varies, but the program that causes the failure is the same every time: "as". The errors are a variety of signal 10 and signal 4. I do find an "as.core" file under /usr/obj, but as is stripped, so there are no debugging symbols or listing that I can provide. The strange thing is that I have been able to successfully build XFree86, KDE, and many other ports on this system. I followed the 4.x-to-5.0 upgrade directions to the letter about a month ago, and have had no major problems before this. Any help would be greatly appreciated! -- Paul A. Howes Hardware Tyan S2099GNNR motherboard Intel P4-2.4/533 Crucial 512 MB PC2100 DIMM Maxtor 20 GB hard drive. dmesg Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-RELEASE-p1 #2: Thu Feb 13 08:39:59 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src-5.0/sys/HYDROGEN Preloaded elf kernel "/boot/kernel/kernel" at 0xc047. Preloaded userconfig_script "/boot/kernel.conf" at 0xc04700a8. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04700f8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2430010060 Hz CPU: Pentium 4 (2430.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff real memory = 536805376 (511 MB) avail memory = 516771840 (492 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled VESA: v2.0, 8128k memory, flags:0x0, mode table:0xc03b34a2 (122) VESA: ATI MACH64 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE31 Using $PIR table, 11 entries at 0xc00fdeb0 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe000-0xe3ff at device 0.0 o n pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 uhci0: port 0xd800-0xd81f irq 12 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd000-0xd01f irq 5 at d evice 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xd400-0xd41f irq 11 at device 29.2 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 pci2: at device 1.0 (no driver attached) ahc0: port 0xc400-0xc4ff mem 0xe6042000-0xe604 2fff irq 11 at device 4.0 on pci2 aic7880: Ultra Single Channel A, SCSI Id=6, 16/253 SCBs pci2: at device 8.0 (no driver attached) em0: port 0xcc00-0xcc3f mem 0xe602-0xe603,0xe600-0xe601 irq 12 at device 10.0 on pci2 em0: Speed:100 Mbps Duplex:Full isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0 x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 31.3 (no driver attached) speaker0 port 0x61 on acpi0 fdc0: port 0x3f7,0x3f0-0 x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xd1000-0xd27ff,0xd-0xd07ff,0xc8000-0xc,0xc -0xc7fff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to den y, logging disabled acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% ad0: 19541MB [39703/16/63] at ata0-master UDMA66 ad1: 38172MB [77557/16/63] at ata0-slave UDMA100 acd0: CDROM at ata1-slave PIO3 Waiting 2 seconds for SCSI devices to settle sa0 at ahc0 bus 0 target 4 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 11) Mounting root from ufs:/dev/ad0s1a fxp0: port 0xc800-0xc83f mem 0xe604-0xe6040fff irq 10 at device 8.0 on pci2 fxp0: Ethernet address 00:e0:81:50:23:90 inph
Problem in /usr/src/sys/boot/i386/boot2
Hello, I have a problem with -CURRENT. As I try to btxld: /usr/src/sys/boot/i386/boot2 btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.01 size=780 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=1691 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1f25 text=114 data=1e11 org=0 entry=0 -293 bytes available *** Error code 1 Assumption: -293 bytes available is due to some sector mapping on the disk of some kind, where we need boot2 to fit into. My guess is that this is due to the first time I try to compile the kernel with gcc version: Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.2 [FreeBSD] 20030205 (release) Which makes the resulting boot2 too big. Is there any way to fix this problem? -- Jesper ./programmer < coffee > code To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TCP connections timing out "real fast"
On Sat, 22 Feb 2003, Bosko Milekic wrote: > On Sat, Feb 22, 2003 at 10:57:05AM -0500, Robert Watson wrote: > > > > Don't yet have any quantitative evidence that this is the case, but I feel > > like TCP sessions have been timing out on me a lot faster than they used > > to. For example, yesterday a machine got unplugged from the network for > > about 15 seconds: in that time, the SSH sessions to the machine timed out > > and disconnected. This morning, a machine generated a lot of output to > > the serial console keeping it substantially busy for about 20 seconds; in > > that time, the SSH session to it timed out. I'm going to see if I can't > > generate some tcpdump traces later today to confirm my suspicions, but was > > wondering if anyone else (annecdotally or not) has seen similar things? > > I have (annecdotally) but I believe I'm seeing it on -STABLE too... > it's tough to tell... how recent are your -CURRENT machines, though, > and is it something that you think just started happening or has it > been happening for a while now? FWIW, I can't say for sure that this > is related to TCP connection timeouts. The workstation the sessions originated from is 5.0-RELEASE from Jan 16; the build box running sshd is 5.x from Jan 30. I.e., all before recent TCP changes. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TCP connections timing out "real fast"
On Sat, Feb 22, 2003 at 10:57:05AM -0500, Robert Watson wrote: > > Don't yet have any quantitative evidence that this is the case, but I feel > like TCP sessions have been timing out on me a lot faster than they used > to. For example, yesterday a machine got unplugged from the network for > about 15 seconds: in that time, the SSH sessions to the machine timed out > and disconnected. This morning, a machine generated a lot of output to > the serial console keeping it substantially busy for about 20 seconds; in > that time, the SSH session to it timed out. I'm going to see if I can't > generate some tcpdump traces later today to confirm my suspicions, but was > wondering if anyone else (annecdotally or not) has seen similar things? > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > [EMAIL PROTECTED] Network Associates Laboratories I have (annecdotally) but I believe I'm seeing it on -STABLE too... it's tough to tell... how recent are your -CURRENT machines, though, and is it something that you think just started happening or has it been happening for a while now? FWIW, I can't say for sure that this is related to TCP connection timeouts. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
TCP connections timing out "real fast"
Don't yet have any quantitative evidence that this is the case, but I feel like TCP sessions have been timing out on me a lot faster than they used to. For example, yesterday a machine got unplugged from the network for about 15 seconds: in that time, the SSH sessions to the machine timed out and disconnected. This morning, a machine generated a lot of output to the serial console keeping it substantially busy for about 20 seconds; in that time, the SSH session to it timed out. I'm going to see if I can't generate some tcpdump traces later today to confirm my suspicions, but was wondering if anyone else (annecdotally or not) has seen similar things? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SSH (TCP?) lag
On Sat, 22 Feb 2003, Andre Guibert de Bruet wrote: > I'm experiencing some rather severe lag during ssh sessions, while running > GENERIC on -current (cvsupped as of 5 minutes ago). This symptom first > started occuring a couple of days ago with the merging of some TCP > patches. > > I've checked all of the obvious causes. I've even gone as far as > rebuilding the client system with 5.0-R and upgrading from there. > > Doing an ls -l in a directory with lots of files over ssh lists files in > chunks. I noticed that pressing a key on the keyboard makes more text > appear. > > Hardware is: > Server: Dual Athlon 2000+ MP w/1GB DDR, gigabit nge nic. FreeBSD 4.7. > Client: Athlon 1900+ XP w/1GB DDR, 100mbit dc0 nic. FreeBSD -current. > Network is switched 100mbit fastether. > > I've tried this (reproduceably) with the following software configuration: > 1. Server and client running sshd2/ssh2 from ports/security/ssh2. > 2. Server running sshd2 from ports. Client running openssh. > > This setup has been working great for well over a year; Has anyone else > recently started having problems? Hello again, I just noticed something else that could relate to this issue. I just tried to install apache2 from ports and the machine locked up while running configure at the following line: checking if TCP_NODELAY setting is inherited from listening sockets... Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SSH (TCP?) lag
Hi, I'm experiencing some rather severe lag during ssh sessions, while running GENERIC on -current (cvsupped as of 5 minutes ago). This symptom first started occuring a couple of days ago with the merging of some TCP patches. I've checked all of the obvious causes. I've even gone as far as rebuilding the client system with 5.0-R and upgrading from there. Doing an ls -l in a directory with lots of files over ssh lists files in chunks. I noticed that pressing a key on the keyboard makes more text appear. Hardware is: Server: Dual Athlon 2000+ MP w/1GB DDR, gigabit nge nic. FreeBSD 4.7. Client: Athlon 1900+ XP w/1GB DDR, 100mbit dc0 nic. FreeBSD -current. Network is switched 100mbit fastether. I've tried this (reproduceably) with the following software configuration: 1. Server and client running sshd2/ssh2 from ports/security/ssh2. 2. Server running sshd2 from ports. Client running openssh. This setup has been working great for well over a year; Has anyone else recently started having problems? > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gethostbyname_r and realpath_r (FreeBSD or Linux for your MySQL Server)
On Sat, Feb 22, 2003 at 11:23:55AM +0100, Martin Blapp wrote: > Many of you know that we still do not have threadsafe > versions of gethostbyname and realpath. > > There are some patches around since a while. Nobody did commit > them. Is someone working on this ? I am working on those interfaces that go through nsdispatch (e.g. gethostbyname_r but not realpath_r). Cheers, -- Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Witness This
Robert Watson wrote: > > On Fri, 21 Feb 2003, Daniel C. Sobral wrote: > > > backtrace(c032e7d9,c25af500,c25a98d4,c046236e,c04623ec) at > > backtrace+0x17 > > > > witness_lock(c25af500,8,c04623ec,1b8,c) at witness_lock+0x660 > > _mtx_lock_flags(c25af500,0,c04623ec,1b8,8095) at > > _mtx_lock_flags+0xb1 chn_intr(c25a9880,c,1,208,c25af7c0) at > > chn_intr+0x2f cmi_intr(c25a9800,0,c0329618,217,c25ae9ec) at > > cmi_intr+0xa6 ithread_loop(c25a9000,cd2ced48,c032948d,366,55ff44fd) at > > ithread_loop+0x182 fork_exit(c01cd420,c25a9000,cd2ced48) at > > fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, > > eip = 0, esp = 0xcd2ced7c, ebp = 0 --- > > This one is probably not my fault, but may well be of interest to > Jeffrey Hsu. Yeah, I know this one isn't yours. I just decided to take the opportunity and send a single message about all this stuff. > > Now, witness biba: > > Is there any change you have the console output about three or four lines Did you mean "chance" instead of "change"? I'm not sure exactly what do you mean here, but this one followed right on the heels of the previous one on my screen. Not at the same time, though, iirc. At one time I switched to the console, I saw this extra output there. I'll see if it gets reproduced on monday. > above this? It identifies the locks in the lock order reversal. It > sounds like a lock might be held in getnewvnode() across > mac_destroy_vnode_label, which in the original design it wasn't intended > to be, and that might result in the reversal. I'll have to take a closer > look at that. > > > Finally, trace this: > ... > > #8 0xc01eb0bb in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:528 > > td = (struct thread *) 0xc0ecba50 > > bootopt = 256 > > newpanic = 1 > > buf = "mac_mls_single_in_range: a not single", '\0' > > #9 0xc0277274 in mac_mls_single_in_range (single=0x0, range=0xc2605e80) > > at /usr/src/sys/security/mac_mls/mac_mls.c:225 > > No locals. > > #10 0xc0278cb6 in mac_mls_check_ifnet_transmit (ifnet=0xc25ebc00, > > ifnetlabel=0x0, m=0xc0eda000, mbuflabel=0x0) > > at /usr/src/sys/security/mac_mls/mac_mls.c:1462 > > p = (struct mac_mls *) 0x0 > > i = (struct mac_mls *) 0x0 > > #11 0xc01dad7a in mac_check_ifnet_transmit (ifnet=0xc25ebc00, > > mbuf=0xc0eda000) > > at /usr/src/sys/kern/kern_mac.c:2269 > > mpc = (struct mac_policy_conf *) 0xc2605e80 > > error = 0 > > I'm a bit puzzled by this; it could be this relates to recent changes > regarding when socket state is discarded. Especially odd are the > ifnetlabel and mbuflabel arguments being NULL, as well as the two mac_mls > pointers. Really they should be non-NULL, or you would have panicked > earlier, so perhaps there's stack corruption. If you still have this > dump, you might consider walking back up the stack to these two frames, > and printing the contents of *ifnetlabel and *mbuflabel, as well as > the two struct mac_mls values in mac_mls_check_ifnet_transmit. MMMm. Frames #10 and #11? I see mbuflabel=0x0 on frame #10! I can do it. I could send kernel and core to freefall too, if the disk space problem has been solved. MM. We'll see. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Spellng is overated anywy. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic on Celeron 700 laptop in -current.
agp0: mem 0xe000-0xe3ff at device 0.0 on pci0
agp0: allocating GATT for aperture of size 0M
panic: contigmalloc1: size must not be 0
Debugger("panic")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db>
This is just from booting the latest image from current.freebsd.org.
Are there any articles on how to produce useful panic output's?
Thanks.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
It seems Anders Andersson wrote: > On Sat, Feb 22, 2003 at 01:02:33PM +0100, [EMAIL PROTECTED] wrote: > > If you say int broke in the 20feb timeframe I think sos@' ATA megacommit > > is the main suspect... > > Yes, sos ATA commit is what broke my sparc64 also (already informed sos > in private mail), but he didnt have any direct ideas about the cause. Your problem is different, you dont see the disks due to missing interrupts, here the disks are found and read from but it falls apart later... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
On Sat, Feb 22, 2003 at 01:02:33PM +0100, [EMAIL PROTECTED] wrote: > If you say int broke in the 20feb timeframe I think sos@' ATA megacommit > is the main suspect... Yes, sos ATA commit is what broke my sparc64 also (already informed sos in private mail), but he didnt have any direct ideas about the cause. -- Anders Andersson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
In message <[EMAIL PROTECTED]>, Michael Class writes: >> Please try "boot -v" and send dmesg. >> >> Also, please try entering "?" to root device prompt to see what devices >> are available. > >Hello, enclosed is the boot -v output that you were asking for. >Mounting root from ufs:/dev/ad0s4a >Root mount failed: 22 If you say int broke in the 20feb timeframe I think sos@' ATA megacommit is the main suspect... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
Please try "boot -v" and send dmesg. Also, please try entering "?" to root device prompt to see what devices are available. Hello, enclosed is the boot -v output that you were asking for. Michael -- - michael class, viktor-renner str. 39, 72074 tuebingen, frg E-Mail: [EMAIL PROTECTED] Phone: +49 7031 14-3707 (work) +49 7071 81950 (private) - Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sat Feb 22 08:29:29 MET 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/MCSMP2 Preloaded elf kernel "/boot/kernel.test/kernel" at 0xc0565000. Preloaded elf module "/boot/kernel.test/acpi.ko" at 0xc05650bc. Calibrating clock(s) ... i8254 clock: 1193225 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz Calibrating TSC clock ... TSC clock: 996553246 Hz CPU: Intel Pentium III (996.55-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383fbff real memory = 1073676288 (1023 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0058f000 - 0x3ffd, 1067782144 bytes (260689 pages) avail memory = 1037225984 (989 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 bios32: Found BIOS32 Service Directory header at 0xc00fdad0 bios32: Entry = 0xfdae0 (c00fdae0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdb01 pnpbios: Found PnP BIOS data at 0xc00f6e40 pnpbios: Entry = f:5c04 Rev = 1.0 Other BIOS signatures found: null: random: mem: Pentium Pro MTRR support enabled SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 pci_open(1):mode 1 addr port (0x0cf8) is 0x80010048 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=06911106) pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00f7530 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded01A 0x01 3 4 5 7 9 10 11 12 14 15 embedded01B 0x02 3 4 5 7 9 10 11 12 14 15 embedded01C 0x03 3 4 5 7 9 10 11 12 14 15 embedded01D 0x05 3 4 5 7 9 10 11 12 14 15 embedded07A 0xfe 14 embedded07B 0xff 15 embedded07C 0x03 3 4 5 7 9 10 11 12 14 15 embedded07D 0x05 3 4 5 7 9 10 11 12 14 15 slot 1 09A 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 09B 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 09C 0x05 3 4 5 7 9 10 11 12 14 15 slot 1 09D 0x01 3 4 5 7 9 10 11 12 14 15 slot 2 0 10A 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 0 10B 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 10C 0x01 3 4 5 7 9 10 11 12 14 15 slot 2 0 10D 0x02 3 4 5 7 9 10 11 12 14 15 slot 3 0 11A 0x05 3 4 5 7 9 10 11 12 14 15 slot 3 0 11B 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 11C 0x02 3 4 5 7 9 10 11 12 14 15 slot 3 0 11D 0x03 3 4 5 7 9 10 11 12 14 15 slot 4 0 12A 0x01 3 4 5 7 9 10 11 12 14 15 slot 4 0 12B 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 12C 0x03 3 4 5 7 9 10 11 12 14 15 slot 4 0 12D 0x05 3 4 5 7 9 10 11 12 14 15 slot 5 0 13A 0x02 3 4 5 7 9 10 11 12 14 15 slot 5 0 13B 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 13C 0x05 3 4 5 7 9 10 11 12 14 15 slot 5 0 13D 0x01 3 4 5 7 9 10 11 12 14 15 embedded0 14A 0x03 3 4 5 7 9 10 11 12 14 15 embedded0 14B 0x05 3 4 5 7 9 10 11 12 14 15 embedded0 14C 0x01 3 4 5 7 9 10 11 12 14 15 embedded0 14D 0x02 3 4 5 7 9 10 11 12 14 15 acpi0: power button is handled as a fixed feature programming model. ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2
Re: Mounting Root fails with error 22 (EINVAL)
In message <[EMAIL PROTECTED]>, Michael Class writes: >Hello, > >just as a data-point. I am seeing the same behaviour. It started with a >kernel from Feb 21th. The kernel from Feb. 20th works o.k. > >Enclosed is the dmesg out, if that helps. Please try "boot -v" and send dmesg. Also, please try entering "?" to root device prompt to see what devices are available. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
gethostbyname_r and realpath_r (FreeBSD or Linux for your MySQLServer)
Hi all, Have you already read this page ? (FreeBSD or Linux for your MySQL Server?) http://jeremy.zawodny.com/blog/archives/000203.html Many of you know that we still do not have threadsafe versions of gethostbyname and realpath. There are some patches around since a while. Nobody did commit them. Is someone working on this ? Martin Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
Christian Gusenbauer wrote: Hi! I've just cvsupped current and rebuilt world and now I'm getting this error when I boot with the new kernel. I had a look at the archives and found out that such a problem existed in January, too and I verified, that I do have the right revision of src/sys/ufs/ffs/fs.h (1.38). A kernel dated Feb. 14th boots without problems. Did I miss something? Hello, just as a data-point. I am seeing the same behaviour. It started with a kernel from Feb 21th. The kernel from Feb. 20th works o.k. Enclosed is the dmesg out, if that helps. Michael -- - michael class, viktor-renner str. 39, 72074 tuebingen, frg E-Mail: [EMAIL PROTECTED] Phone: +49 7031 14-3707 (work) +49 7071 81950 (private) - Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Mon Feb 17 19:59:15 MET 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/MCSMP2 Preloaded elf kernel "/boot/kernel/kernel" at 0xc0566000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05660a8. Timecounter "i8254" frequency 1193182 Hz CPU: Intel Pentium III (996.55-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383fbff real memory = 1073676288 (1023 MB) avail memory = 1037221888 (989 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Using $PIR table, 8 entries at 0xc00f7530 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_cpu0: port 0x530-0x537 on acpi0 acpi_cpu1: port 0x530-0x537 on acpi0 acpi_tz0: port 0x530-0x537 on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xb800-0xb81f irq 9 at device 7.2 on pci0 uhci0: LegSup = 0xa000 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ulpt0: Hewlett-Packard DeskJet 990C, rev 1.10/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode uhci1: port 0xbc00-0xbc1f irq 9 at device 7.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub1: port error, restarting port 1 uhub1: port error, giving up port 1 uhub1: port error, restarting port 2 uhub1: port error, giving up port 2 viapropm0: SMBus I/O base at 0x400 viapropm0: port 0x400-0x40f at device 7.4 on pci0 viapropm0: SMBus revision code 0x40 smb0: on smbus0 pcm0: port 0xc000-0xc003,0xc400-0xc403,0xc800-0xc8ff irq 10 at device 7.5 on pci0 pcm0: xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xb400-0xb47f mem 0xdffdff80-0xdffd irq 5 at device 9.0 on pci0 xl0: Ethernet address: 00:10:5a:d7:dd:9c miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci1: port 0xcc00-0xccff,0xd000-0xd003,0xd400-0xd407,0xd800-0xd803,0xdc00-0xdc07 irq 10 at device 10.0 on pci0 ata2: at 0xdc00 on atapci1 ata3: at 0xd400 on atapci1 bktr0: mem 0xdedfe000-0xdedfefff irq 9 at device 11.0 on pci0 bktr0: Hauppauge Model 61344 D121 bktr0: Detected a MSP3410D-B4 at 0x80 bktr0: Hauppauge WinCast/TV, Philips FR1216 PAL FM tuner, msp3400c stereo, remote control. pci0: at device 11.1 (no driver attached) sym0: <875> port 0xa800-0xa8ff mem 0xdffde000-0xdffdefff,0xdffdfe00-0xdffdfeff irq 11 at device 12.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: SCAN FOR LUNS disabled for targets 0 1 2 3 4 5 6 8 9 10 11 12 13 14 15. acpi_button1: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 por
