Re: `cat /dev/io` leads to system lockup.
On Thu, Dec 19, 2002 at 11:35:01PM -0800, Nate Lawson wrote: > On Fri, 20 Dec 2002, Sean Kelly wrote: > > On my 5.0-CURRENT kernel built 45 minutes ago, I can bring my system to its > > knees by doing > > > > # cat /dev/io > > > > While I understand that this isn't exactly something one would normally be > > doing, is it really something that should bring the system down? > > You're running as root. So does "yes > /dev/da0" and "cat /dev/urandom > > /dev/mem" and ... (infinity) While I don't really care to test it, I wager that `yes >/dev/da0` will not cause the system to lock hard. But you seem to be talking abot something very different. You are talking about WRITING. I am talking about READING. # cat /dev/da0 # cat /dev/urandom None of these bring the system to its knees. So why does # cat /dev/io totally lock my system solid? According to the manpage: The special file /dev/io is a controlled security hole that allows a pro- cess to gain I/O privileges (which are normally reserved for kernel- internal code). Any process that holds a file descriptor on /dev/io open will get its IOPL bits in the flag register set, thus allowing it to per- form direct I/O operations. This says nothing about what happens if you attempt to read() from /dev/io, as `cat /dev/io` would be expected to do. At the least, there should be a big, fat, blinking WARNING on the manpage telling you that `cat /dev/io` will bring your system down. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org msg49107/pgp0.pgp Description: PGP signature
Re: `cat /dev/io` leads to system lockup.
On Fri, 20 Dec 2002, Sean Kelly wrote: > On my 5.0-CURRENT kernel built 45 minutes ago, I can bring my system to its > knees by doing > > # cat /dev/io > > While I understand that this isn't exactly something one would normally be > doing, is it really something that should bring the system down? No. Writing to /dev/io is not supported. write(2) to a device that doesn't support writing should return -1 and set errno to ENODEV. This was broken mainly by removing the default case from mem.c:mmrw(). This causes mmrw() to loop endlessly without giving up control. Giant locking in -current makes this especially fatal -- mmrw() holds Giant so even most interrupt handlers are blocked. In RELENG_4 the only bug near here is that mmrw() returns ENXIO instead of ENODEV for writes to /dev/io. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> sys/boot/sparc64/loader In file included from /tinderbox/sparc64/src/sys/boot/sparc64/loader/locore.S:15: machine/asm.h:105:1: warning: "__FBSDID" redefined In file included from machine/asm.h:46, from /tinderbox/sparc64/src/sys/boot/sparc64/loader/locore.S:15: /tinderbox/sparc64/src/sys/sys/cdefs.h:239:1: warning: this is the location of the previous definition /tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: `zipfs_fsops' undeclared here (not in a function) /tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: initializer element is not constant /tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: (near initialization for `file_system[2]') *** Error code 1 Stop in /tinderbox/sparc64/src/sys/boot/sparc64/loader. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/boot/sparc64. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/boot. *** Error code 1 Stop in /tinderbox/sparc64/src/sys. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh authentification broken, only public keys work
> I got this tonight on my ultra. I thought it was sparc64 specific, glad > I saw your post. I cvsup'd 2 days ago. > > Im going to build OpenSSH from ports and see if it has the same error. I posted here about three or four days ago, saying that using the ports' version is a workaround to this issue. Apparently our base's version does not use PAM (it has a line "#undef USE_PAM" there). It's accompanied with a commentary that says to not use PAM for password authentication as the challenge/response mechanism is better. .fs -- "Succumb to natural tendencies. Be hateful and boring." msg49110/pgp0.pgp Description: PGP signature
Re: `cat /dev/io` leads to system lockup.
Sean Kelly wrote: On Thu, Dec 19, 2002 at 11:35:01PM -0800, Nate Lawson wrote: >On Fri, 20 Dec 2002, Sean Kelly wrote: > >>On my 5.0-CURRENT kernel built 45 minutes ago, I can bring my system to its >>knees by doing >> >># cat /dev/io >> >>While I understand that this isn't exactly something one would normally be >>doing, is it really something that should bring the system down? > >You're running as root. So does "yes > /dev/da0" and "cat /dev/urandom > >/dev/mem" and ... (infinity) While I don't really care to test it, I wager that `yes >/dev/da0` will not cause the system to lock hard. But you seem to be talking abot something very different. You are talking about WRITING. I am talking about READING. # cat /dev/da0 # cat /dev/urandom None of these bring the system to its knees. So why does # cat /dev/io totally lock my system solid? According to the manpage: The special file /dev/io is a controlled security hole that allows a pro- cess to gain I/O privileges (which are normally reserved for kernel- internal code). Any process that holds a file descriptor on /dev/io open will get its IOPL bits in the flag register set, thus allowing it to per- form direct I/O operations. This says nothing about what happens if you attempt to read() from /dev/io, as `cat /dev/io` would be expected to do. At the least, there should be a big, fat, blinking WARNING on the manpage telling you that `cat /dev/io` will bring your system down. Many peripheral hardware device do not like having their registers blindly read (it's quite common for a read operation on a register to signal an ASIC that it's ok to do a certain action) and will respond with nasty things like interrupt storms, endless PCI target aborts, etc. Whether this is silly or not is not the point; this is just one of the many places in Unix that have no seatbelts and assume that the superuser knows what he is doing. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
On Thu, Dec 19, 2002 at 08:46:44PM -0800, Sam Leffler <[EMAIL PROTECTED]> wrote: > > #ifndef PFIL_HOOKS > > #error "You must specify PFIL_HOOKS when using ipfilter" > > #endif > > > > Unfortunately there's no way that I know to express this if ipfilter is > > loaded as a module. > > Duh, there'll probably be unresolved symbols if you try to load ipl.ko w/o > PFIL_HOOKS defined in the kernel. Yes, and this "undefined symbols" message will make no sense from user perspective. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh authentification broken, only public keys work
On Fri, Dec 20, 2002 at 08:27:53AM +0100, Martin Blapp <[EMAIL PROTECTED]> wrote: > > Since yesterday I cannot login to my CURRENT machine anymore > after a world and reboot ... > > I really hope this doesn't got MFC'd to RELENG_5_0 ... > debug1: Calling cleanup 0x8061180(0x0) > debug1: PAM: cleanup > debug3: mm_pam_query: waiting for MONITOR_ANS_PAM_QUERY > debug3: mm_request_receive_expect entering: type 45 > debug3: mm_request_receive entering > > Then the connection times just out. The "ssh_msg_send: write" > message appears without debug mode. > > Note that I did run mergemaster ... pam files are all on their > place. Somthing is completly screwed up. Disable ChallengeResponseAuthentication, set it to "no" and you'll have ssh again. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh authentification broken, only public keys work
Hi, > Disable ChallengeResponseAuthentication, set it to "no" and you'll > have ssh again. > -- Thanks, I'll try it at home this evening ... Shouldn't we fix this the default config ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh authentification broken, only public keys work
On Fri, Dec 20, 2002 at 12:09:39PM +0100, Martin Blapp <[EMAIL PROTECTED]> wrote: > > Disable ChallengeResponseAuthentication, set it to "no" and you'll > > have ssh again. > > -- > > Thanks, I'll try it at home this evening ... > > Shouldn't we fix this the default config ? I think it will disable PAM authentication and the overall trend for FreeBSD is to enable PAM for everything. That's my impression I've got by following the -current list. I'll hope this PAM mess will stabilise soon, before everybody will make this 'no' setting permanent local hack. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working)
On Thu, Dec 19, 2002 at 05:11:32PM -0800, Matthew Dillon wrote:
> I found another couple of bugs, this time in OHCI's DMA
> buffer chaining code.
Great.
> A patch for this with additional debugging code is
> included below (for current). There are two bugs.
> I do not know if -stable is effected.
>
> First, the calculation of dataphysend is totally bogus.
> You can just take the physical address and add (len - 1)
> to it. You have to take the virtual address, add len - 1
> to it, and convert it to a physical address. I can
> crash my machine simply by doing a
>
> 'newfs -f 1024 -b 8192 /dev/da2s1a'
>
> On the disk-on-key USB device.
>
> Second, I believe the OpenBSD and NetBSD code is broken.
> The range can be one or two pages, but the remaining bytes
> may be less then one page and this has to be taken into
> account.
The NetBSD code is already different:
1.48 (augustss 15-Sep-99): /* The OHCI hardware can handle at
most one page crossing. */
1.48 (augustss 15-Sep-99): if (OHCI_PAGE(dataphys) == dataphysend
||
1.48 (augustss 15-Sep-99): OHCI_PAGE(dataphys) +
OHCI_PAGE_SIZE == dataphysend) {
1.48 (augustss 15-Sep-99): /* we can handle it in this TD
*/
1.48 (augustss 15-Sep-99): curlen = len;
1.48 (augustss 15-Sep-99): } else {
1.48 (augustss 15-Sep-99): /* must use multiple TDs, fill
as much as possible. */
1.120(augustss 03-Feb-02): curlen = 2 * OHCI_PAGE_SIZE -
1.48 (augustss 15-Sep-99): (dataphys &
(OHCI_PAGE_SIZE-1));
1.78 (augustss 20-Mar-00): /* the length must be a
multiple of the max size */
1.78 (augustss 20-Mar-00): curlen -= curlen %
UGETW(opipe->pipe.endpoint->edesc->wMaxPacketSize);
1.78 (augustss 20-Mar-00): #ifdef DIAGNOSTIC
1.78 (augustss 20-Mar-00): if (curlen == 0)
1.128(provos 27-Sep-02): panic("ohci_alloc_std:
curlen == 0");
1.78 (augustss 20-Mar-00): #endif
1.48 (augustss 15-Sep-99): }
To bad we did not catch it.
--
B.Walter COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Current hangs in reboot
On Wed, 11 Dec 2002, Taavi Talvik wrote: After testing, it turns out, that 'hang on reboot' problem maybe related to mainboard (Gigabyte GA-8PE667 Ultra) and/or USB driver for Intel 82801DB. After turning off onboard USB rebooting works even if ACPI is enabled. It was necessary to disable only Intel 82801DB (ICH4) devices. kernel: uhci0: port 0xb800-0xb81f irq 14 at device 29.0 on pci0 kernel: usb0: on uhci0 kernel: usb0: USB revision 1.0 kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 kernel: uhub0: 2 ports with 2 removable, self powered kernel: uhci1: port 0xb000-0xb01f irq 14 at device 29.1 on pci0 kernel: usb1: on uhci1 kernel: usb1: USB revision 1.0 kernel: uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 kernel: uhub1: 2 ports with 2 removable, self powered kernel: uhci2: port 0xb400-0xb41f irq 15 at device 29.2 on pci0 kernel: usb2: on uhci2 kernel: usb2: USB revision 1.0 kernel: uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 kernel: uhub2: 2 ports with 2 removable, self powered kernel: pci0: at device 29.7 (no driver attached) kernel: ohci0: mem 0xdf00-0xdf000fff irq 14 at device 7.0 on pci2 kernel: usb3: OHCI version 1.0 kernel: usb3: on ohci0 kernel: usb3: USB revision 1.0 kernel: uhub3: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 kernel: uhub3: 3 ports with 3 removable, self powered kernel: ohci1: mem 0xdf001000-0xdf001fff irq 15 at device 7.1 on pci2 kernel: usb4: OHCI version 1.0 kernel: usb4: on ohci1 kernel: usb4: USB revision 1.0 kernel: uhub4: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 kernel: uhub4: 2 ports with 2 removable, self powered best regards, taavi > On Wed, 11 Dec 2002, Nate Lawson wrote: > > On Wed, 11 Dec 2002, Taavi Talvik wrote: > > > On Wed, 11 Dec 2002, Taavi Talvik wrote: > > > > Current as of yesterday (actually problem presist about > > > > month) hangs on reboot. > > > > > > > > Only message: > > > > > > > > Waiting (max 60 seconds) for system process `vnlru' to stop...stopped > > > > > > Turning off ACPI makes it reboot. Thanks for suggestion Gerrit! > > > > > > But how is ACPI related to problem? Why rebooting hangs between > > > stoping `vnlru' and `bufdaemon' in ACPI case? > > > > The next message you'd see if it was working is "Stopping ACPI". So acpi > > shutdown is probably what is hanging. > > > No, Stopping ACPI appears normally only after stoping 'syncer' also. But > in my situation hang happens between 'vnlru' and 'bufdaemon'. > > If console output is not buffered, what happens that last two prompts are > not diapleyed? Any hints how I can futher debug it? > > Waiting (max 60 seconds) for system process `vnlru' to stop...stopped > Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped > Waiting (max 60 seconds) for system process `syncer' to stop...stopped > > syncing disks, buffers remaining... 2 2 > done > Uptime: 9m6s To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh authentification broken, only public keys work
On 2002-12-20 08:27:53 (+0100), Martin Blapp <[EMAIL PROTECTED]> wrote: > Since yesterday I cannot login to my CURRENT machine anymore > after a world and reboot ... Same problem here (on Alpha and on i386, if it matters). Logging in with a public key works, without doesn't. > Then the connection times just out. The "ssh_msg_send: write" > message appears without debug mode. Yeps. Setting ChallengeResponse... to 'no' in the config file works, but I'm weary of local hacks. I can't seem to find the commit that caused this either. But perhaps I'm not awake enough to grep properly :-) - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. BOFH Excuse #376: Budget cuts forced us to sell all the power cords for the servers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
xcpustate broken
Can someone figure out why this port has recent become broken on i386 and alpha? http://bento.freebsd.org/errorlogs/i386-5-latest/xcpustate-2.5.log Kris msg49119/pgp0.pgp Description: PGP signature
Panic in jail [patch].
Hello. Initiated mutex for prison isn't destroyed on error. Kernel will on every error. Here You got patch for this: --- kern_jail.c.origFri Dec 20 15:11:10 2002 +++ kern_jail.c Fri Dec 20 15:14:03 2002 @@ -103,6 +103,7 @@ PROC_UNLOCK(p); crfree(newcred); bail: + mtx_destroy(&pr->pr_mtx); FREE(pr, M_PRISON); return (error); } --- BTW. Maybe is time to implement jail with more features? Multiple ips, protecting statfs-like calls or even multi level jail? As multi level jail I understand jail created in jail, etc. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg49120/pgp0.pgp Description: PGP signature
Re: Panic in jail [patch].
Pawel Jakub Dawidek wrote: > Hello. > > Initiated mutex for prison isn't destroyed on error. > Kernel will on every error. I just committed your patch, thanks! Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
if_tap is working ?
hi, guys. Does anyone have VMware2 port running successfully on -current ? my VMware2 port's startup script says /usr/local/etc/rc.d/vmware.sh: cannot create /compat/linux/dev/vmnet1: Device not configured I digged into this a little and found that this message is from the line echo -n > $dev_vmnet1 here, $dev_vmnet1 points to /usr/compat/linux/dev/vmnet1. if_tap is loaded as KLD as follows: 291 0xc3acd000 4000 if_tap.ko my -current is built yesterday and I've even re-installed VMware2 port a few times. CPUTYPE and no special CFLAGS etc are not defined in make.conf. same script works on -stable. Am I missing anything obvious ? Thanks in advance. Y.Kasazaki // To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
Vallo Kallaste wrote:
> On Thu, Dec 19, 2002 at 08:46:44PM -0800, Sam Leffler <[EMAIL PROTECTED]> wrote:
> > > #ifndef PFIL_HOOKS
> > > #error "You must specify PFIL_HOOKS when using ipfilter"
> > > #endif
> > >
> > > Unfortunately there's no way that I know to express this if ipfilter is
> > > loaded as a module.
> >
> > Duh, there'll probably be unresolved symbols if you try to load ipl.ko w/o
> > PFIL_HOOKS defined in the kernel.
>
> Yes, and this "undefined symbols" message will make no sense from
> user perspective.
Then fix it. The fix is trivial:
1) Create accessor/mutator functions which are *not*
protected by "#ifndef PFIL_HOOKS".
2) Use the accessor/mutator functions from within the
ipfilter code to register and deregister use of the
hooks.
3) In the case of the "#ifndef PFIL_HOOKS", cause the
accessor/mutator functions to return errors.
Like so:
#ifdef PFIL_HOOKS
pfil_hook_t *pfil_hook_func;
#endif
int
pfil_set_hook( pfil_hook_t *func)
{
#ifdef PFIL_HOOKS
pfil_hook_func = func;
return( 0);
#else /* !PFIL_HOOKS */
return( -1);
#endif /* !PFIL_HOOKS */
}
...the (in this example) mutator function will always be defined,
and the error in a kernel without "PFIL_HOOKS" defined can be
trapped by the caller during the module registration phase, at
which point a console error can be printed.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: if_tap is working ?
Hello,
Yoshinori KASAZAKI wrote:
hi, guys.
Does anyone have VMware2 port running successfully on -current ?
i'm :)
my VMware2 port's startup script says
/usr/local/etc/rc.d/vmware.sh: cannot create /compat/linux/dev/vmnet1: Device not configured
I digged into this a little and found that this message is from the line
echo -n > $dev_vmnet1
here, $dev_vmnet1 points to /usr/compat/linux/dev/vmnet1.
if_tap is loaded as KLD as follows:
291 0xc3acd000 4000 if_tap.ko
what does `ls -la /usr/compat/linux/dev/vmnet1' say?
/usr/compat/linux/dev/vmnet1 should be symlink to /dev/vmnet1
vmware2 still wants to create device nodes under /linux/dev/
not symlinks. someone please fix
--- pre-install.origFri Dec 20 09:40:06 2002
+++ pre-install Fri Dec 20 09:40:43 2002
@@ -18,7 +18,8 @@
mknod ${linux_dev}/null c 2 2
chmod 666 ${linux_dev}/null
echo Creating vmnet1 node
-mknod /compat/linux/dev/vmnet1 c 149 65537
+rm /compat/linux/dev/vmnet1
+ln -s /dev/vmnet1 /compat/linux/dev/vmnet1
echo Creating $linux_dev/hd\?
mknod ${linux_dev}/hda b 0 0x00010002
mknod ${linux_dev}/hdb b 0 0x0001000a
my -current is built yesterday and I've even re-installed VMware2 port a few times.
CPUTYPE and no special CFLAGS etc are not defined in make.conf.
same script works on -stable.
Am I missing anything obvious ?
not really :) just a DEVFS side effect
thanks,
max
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working)
:The NetBSD code is already different:
:1.48 (augustss 15-Sep-99): /* The OHCI hardware can handle at
:most one page crossing. */
:1.48 (augustss 15-Sep-99): if (OHCI_PAGE(dataphys) ==
:dataphysend ||
:1.48 (augustss 15-Sep-99): OHCI_PAGE(dataphys) +
:OHCI_PAGE_SIZE == dataphysend) {
:1.48 (augustss 15-Sep-99): /* we can handle it in this
:TD */
:1.48 (augustss 15-Sep-99): curlen = len;
:1.48 (augustss 15-Sep-99): } else {
:1.48 (augustss 15-Sep-99): /* must use multiple TDs,
:fill as much as possible. */
:1.120(augustss 03-Feb-02): curlen = 2 * OHCI_PAGE_SIZE -
:1.48 (augustss 15-Sep-99): (dataphys &
:(OHCI_PAGE_SIZE-1));
:1.78 (augustss 20-Mar-00): /* the length must be a
:multiple of the max size */
:1.78 (augustss 20-Mar-00): curlen -= curlen %
:UGETW(opipe->pipe.endpoint->edesc->wMaxPacketSize);
:1.78 (augustss 20-Mar-00): #ifdef DIAGNOSTIC
:1.78 (augustss 20-Mar-00): if (curlen == 0)
:1.128(provos 27-Sep-02):
:panic("ohci_alloc_std: curlen == 0");
:1.78 (augustss 20-Mar-00): #endif
:1.48 (augustss 15-Sep-99): }
:
:
:To bad we did not catch it.
:
:--
:B.Walter COSMO-Project http://www.cosmo-project.de
Well, that's the curlen fix, which doesn't apply to us at all
(in FreeBSD we do not try to optimize for two physically contiguous
pages). I'm not sure why they are using a mod there, I think
it is as simple as if (curlen > len) curlen = len, but I don't
understand the 'the length must be a multiple of the max size'
comment so maybe there is some magic there that I haven't considered.
The fix that applies to both FreeBSD and NetBSD was the calculation of
dataphysend just above the code you indicate. When I look at ohci.c
via cvsweb for NetBSD, their 1.135, they have not fixed the
dataphysend calculation yet.
They still have (which is WRONG):
dataphysend = OHCI_PAGE(dataphys + len - 1);
The correct answer is:
dataphysend = OHCI_PAGE(DMAADDR(dma, len - 1));
I am going to attempt to add [EMAIL PROTECTED] to this thread, I
don't know if that is a valid email address :-)
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
pam_setenv() crashes rshd...
The rshd started to crash on my system after the recent -current
upgrade. It does not dump core (why?), but with a lot of syslog() I
narrowed the trouble spot down to the pam_setenv() calls -- the very
first one of them, in rshd.c never returned... The libpam is:
/usr/lib/libpam.so.2:
$FreeBSD: src/lib/csu/i386-elf/crti.S,v 1.6 2002/05/15 04:19:49 obrien
Exp $
$FreeBSD: src/lib/csu/i386-elf/crtn.S,v 1.5 2002/05/15 04:19:49 obrien
Exp $
$FreeBSD: src/lib/libpam/libpam/pam_std_option.c,v 1.10 2002/04/14
18:30:03 des Exp $
$FreeBSD: src/lib/libpam/libpam/pam_debug_log.c,v 1.8 2002/04/14 16:44:04
des Exp $
The following patch fixes (works around?) the problem for me (pam_setenv
is rather inefficiently implemented by the vendor, BTW), but is probably
wrong in some other aspect. If it is not, it will probably make rshd a
bit cleaner and faster...
Please, review... Thanks!
-mi
Index: rshd.c
===
RCS file: /home/ncvs/src/libexec/rshd/rshd.c,v
retrieving revision 1.46
diff -U2 -r1.46 rshd.c
--- rshd.c 2002/06/26 17:09:08 1.46
+++ rshd.c 2002/12/20 19:44:33
@@ -182,6 +182,4 @@
}
-extern char **environ;
-
void
doit(struct sockaddr *fromp)
@@ -476,10 +474,9 @@
if (*pwd->pw_shell == '\0')
pwd->pw_shell = bshell;
- (void) pam_setenv(pamh, "HOME", pwd->pw_dir, 1);
- (void) pam_setenv(pamh, "SHELL", pwd->pw_shell, 1);
- (void) pam_setenv(pamh, "USER", pwd->pw_name, 1);
- (void) pam_setenv(pamh, "PATH", _PATH_DEFPATH, 1);
- environ = pam_getenvlist(pamh);
(void) pam_end(pamh, pam_err);
+ (void) setenv("HOME", pwd->pw_dir, 1);
+ (void) setenv("SHELL", pwd->pw_shell, 1);
+ (void) setenv("USER", pwd->pw_name, 1);
+ (void) setenv("PATH", _PATH_DEFPATH, 1);
cp = strrchr(pwd->pw_shell, '/');
if (cp)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: `cat /dev/io` leads to system lockup.
On Fri, 20 Dec 2002, Scott Long wrote: > Many peripheral hardware device do not like having their registers > blindly read (it's quite common for a read operation on a register to > signal an ASIC that it's ok to do a certain action) and will respond > with nasty things like interrupt storms, endless PCI target aborts, etc. > Whether this is silly or not is not the point; this is just one of the > many places in Unix that have no seatbelts and assume that the superuser > knows what he is doing. This is irrelevant, since "cat /dev/io" doesn't access device registers. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_tap is working ?
hi.
On Fri, 20 Dec 2002 09:42:46 -0800
Maksim Yevmenkin <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Yoshinori KASAZAKI wrote:
>
> >hi, guys.
> >
> >Does anyone have VMware2 port running successfully on -current ?
> >
> i'm :)
that's great :)
> >my VMware2 port's startup script says
> >/usr/local/etc/rc.d/vmware.sh: cannot create /compat/linux/dev/vmnet1: Device
>not configured
> >
> >I digged into this a little and found that this message is from the line
> >echo -n > $dev_vmnet1
> >here, $dev_vmnet1 points to /usr/compat/linux/dev/vmnet1.
> >
> >if_tap is loaded as KLD as follows:
> >291 0xc3acd000 4000 if_tap.ko
> >
> what does `ls -la /usr/compat/linux/dev/vmnet1' say?
tower# ls -al /usr/compat/linux/dev/vmnet1
crw-r--r-- 1 root wheel 149, 0x00010001 12 21 05:54 /usr/compat/linux/dev/vmnet1
> /usr/compat/linux/dev/vmnet1 should be symlink to /dev/vmnet1
>
> vmware2 still wants to create device nodes under /linux/dev/
> not symlinks. someone please fix
>
> --- pre-install.origFri Dec 20 09:40:06 2002
> +++ pre-install Fri Dec 20 09:40:43 2002
> @@ -18,7 +18,8 @@
> mknod ${linux_dev}/null c 2 2
> chmod 666 ${linux_dev}/null
> echo Creating vmnet1 node
> -mknod /compat/linux/dev/vmnet1 c 149 65537
> +rm /compat/linux/dev/vmnet1
> +ln -s /dev/vmnet1 /compat/linux/dev/vmnet1
> echo Creating $linux_dev/hd\?
> mknod ${linux_dev}/hda b 0 0x00010002
> mknod ${linux_dev}/hdb b 0 0x0001000a
yes, that's it !!
Thanks a lot !!
> >same script works on -stable.
> >Am I missing anything obvious ?
> >
> not really :) just a DEVFS side effect
I see.
> thanks,
> max
thanks again, max :)
Y.Kasazaki
//
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
On Fri, Dec 20, 2002 at 08:30:42AM -0800, Terry Lambert <[EMAIL PROTECTED]> wrote: > Vallo Kallaste wrote: > > On Thu, Dec 19, 2002 at 08:46:44PM -0800, Sam Leffler > > <[EMAIL PROTECTED]> wrote: > > > > #ifndef PFIL_HOOKS #error "You must specify PFIL_HOOKS when > > > > using ipfilter" #endif > > > > > > > > Unfortunately there's no way that I know to express this if > > > > ipfilter is loaded as a module. > > > > > > Duh, there'll probably be unresolved symbols if you try to > > > load ipl.ko w/o PFIL_HOOKS defined in the kernel. > > > > Yes, and this "undefined symbols" message will make no sense > > from user perspective. > > > Then fix it. The fix is trivial: [description of possible fix snipped] As I've stated several times and as you most certainly know I'm not developer. What are you trying to accomplish by the phrase "then fix it"? Put me down, eh? I have encountered this problem several times and for the first time the message about unresolved symbol(s) made no sense and forced me to do time consuming searches over the 'Net to get a clue what's going on. Will we want to get possible users using FreeBSD or will we want argue about it to death? The users get bored and move on, that's it. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VLAN v.s. NIC with VLAN hardware support bug.
If there somebody failing to configure vlans on a nic with vlan-hardware support - read the PR 46405 (patch attached). It's apply to both current and stable. Dan -- Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206 root of FIONet, KolejNET, webmaster of www.freebsd.cz AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VLAN v.s. NIC with VLAN hardware support bug.
Hi, Does this bug show up in the trunk ports statistics as runt packets ? ---Mike At 10:22 PM 20/12/2002 +0100, Dan Lukes wrote: If there somebody failing to configure vlans on a nic with vlan-hardware support - read the PR 46405 (patch attached). It's apply to both current and stable. Dan -- Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206 root of FIONet, KolejNET, webmaster of www.freebsd.cz AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
On Fri, 20 Dec 2002, Vallo Kallaste wrote: > On Fri, Dec 20, 2002 at 08:30:42AM -0800, Terry Lambert > <[EMAIL PROTECTED]> wrote: > > > Vallo Kallaste wrote: > > > On Thu, Dec 19, 2002 at 08:46:44PM -0800, Sam Leffler > > > <[EMAIL PROTECTED]> wrote: > > > > > #ifndef PFIL_HOOKS #error "You must specify PFIL_HOOKS when > > > > > using ipfilter" #endif > > > > > > > > > > Unfortunately there's no way that I know to express this if > > > > > ipfilter is loaded as a module. > > > > > > > > Duh, there'll probably be unresolved symbols if you try to > > > > load ipl.ko w/o PFIL_HOOKS defined in the kernel. > > > > > > Yes, and this "undefined symbols" message will make no sense > > > from user perspective. > > > > > > Then fix it. The fix is trivial: > [description of possible fix snipped] > > As I've stated several times and as you most certainly know I'm not > developer. What are you trying to accomplish by the phrase "then fix > it"? Put me down, eh? > I have encountered this problem several times and for the first time > the message about unresolved symbol(s) made no sense and forced me > to do time consuming searches over the 'Net to get a clue what's > going on. Will we want to get possible users using FreeBSD or will > we want argue about it to death? The users get bored and move on, > that's it. > Unfortunately nobody cares to look into PR database (conf/44576) In case PFIL_HOOKS really slows IP processing I don't mind keeping this out of GENERIC, however it should be noted in UPDATING and release notes. I did not do any time consuming searches the first time I tried to load ipl.ko, but I've spent some time reading NOTES before upgrading to -CURRENT and I am using IP Filter for about three years now on Solaris and FreeBSD (thanks, Darren). IMHO GENERIC is not supposed to be fast, but to be useable out-of-the box. Bringing in PFIL_HOOKS with the appropriate comment about things being more complicated and slow will ease 4.0->5.0 upgrade and do not prevent someone from building custom kernel without it. Sincerely yours, Sergey Mokryshev. -- Sergey S. Mokryshev <[EMAIL PROTECTED]> SMP453, MOKR-RIPN To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_tap is working ?
This is coincidence, I was bored by this also today for making the symlink
for the Nth time.
Your patch however should be applied only on -CURRENT and not on -STABLE.
(Also a 'ln -sf' would make the line above it unnecessary)
If you could pursue this to a commit I and others would be very grateful ;-)
Thanks
Mark
On Fri, Dec 20, 2002 at 09:42:46AM -0800, Maksim Yevmenkin wrote:
> --- pre-install.origFri Dec 20 09:40:06 2002
> +++ pre-install Fri Dec 20 09:40:43 2002
> @@ -18,7 +18,8 @@
> mknod ${linux_dev}/null c 2 2
> chmod 666 ${linux_dev}/null
> echo Creating vmnet1 node
> -mknod /compat/linux/dev/vmnet1 c 149 65537
> +rm /compat/linux/dev/vmnet1
> +ln -s /dev/vmnet1 /compat/linux/dev/vmnet1
> echo Creating $linux_dev/hd\?
> mknod ${linux_dev}/hda b 0 0x00010002
> mknod ${linux_dev}/hdb b 0 0x0001000a
--
Mark SantcroosRIPE Network Coordination Centre
http://www.ripe.net/home/mark/New Projects Group/TTM
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
netinet/tcp.h compile error
Hi, when trying to install adasockets I got the following error message: /usr/include/netinet/tcp.h:44: syntax error before "tcp_seq" /usr/include/netinet/tcp.h:44: warning: data definition has no type or storage class /usr/include/netinet/tcp.h:45: syntax error before "tcp_cc" /usr/include/netinet/tcp.h:45: warning: data definition has no type or storage class /usr/include/netinet/tcp.h:55: syntax error before "u_short" I replaced #include with #include to make it work. Is this a bug? //David Holm To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
Sergey Mokryshev wrote: > Unfortunately nobody cares to look into PR database (conf/44576) > > In case PFIL_HOOKS really slows IP processing I don't mind keeping this > out of GENERIC, however it should be noted in UPDATING and release notes. > > I did not do any time consuming searches the first time I tried to load > ipl.ko, but I've spent some time reading NOTES before upgrading to > -CURRENT and I am using IP Filter for about three years now on Solaris > and FreeBSD (thanks, Darren). > > IMHO GENERIC is not supposed to be fast, but to be useable out-of-the box. This is a reasonable argument... if it's possible to tune it so that it's fast. Hacking in the IP Filter hooks unonditionally for code that can't really be distributed as part of the system because of its license, and thus making things slower, with no chance to make them faster later, is not my idea of A Really Good Thing(tm). I'm really not a fan of "NO_PFIL_HOOKS" as an option. Probably the correct thing to do is to wire in ipfilter as a Netgraph module. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
On Fri, 20 Dec 2002, Terry Lambert wrote: > Sergey Mokryshev wrote: > > Unfortunately nobody cares to look into PR database (conf/44576) > > > > In case PFIL_HOOKS really slows IP processing I don't mind keeping this > > out of GENERIC, however it should be noted in UPDATING and release notes. > > > > I did not do any time consuming searches the first time I tried to load > > ipl.ko, but I've spent some time reading NOTES before upgrading to > > -CURRENT and I am using IP Filter for about three years now on Solaris > > and FreeBSD (thanks, Darren). > > > > IMHO GENERIC is not supposed to be fast, but to be useable out-of-the box. > > This is a reasonable argument... if it's possible to tune it so > that it's fast. Hacking in the IP Filter hooks unonditionally > for code that can't really be distributed as part of the system > because of its license, and thus making things slower, with no > chance to make them faster later, is not my idea of A Really > Good Thing(tm). > > I'm really not a fan of "NO_PFIL_HOOKS" as an option. > I'm not talking about NO_PFIL_HOOKS but "options PFIL_HOOKS" in GENERIC. Too many people may foot shoot themselves trying to upgrade from 4-STABLE to 5.0. "dd" in vi is really quick. We still can remove this options from BOOTMFS kernel to keep it small. > Probably the correct thing to do is to wire in ipfilter as a > Netgraph module. > AFAIK Solaris, HP-UX and others lack Netgraph support, but support pfil. Darren may (or may not) explain it further. IMHO it is almost impossible and pointless (I did not look in the code, just MHO). Sergey Mokryshev -- Sergey S. Mokryshev <[EMAIL PROTECTED]> SMP453, MOKR-RIPN To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VLAN v.s. NIC with VLAN hardware support bug.
Dan Lukes wrote: > > If there somebody failing to configure vlans on a nic with > vlan-hardware support - read the PR 46405 (patch attached). > > It's apply to both current and stable. Does fxp have hardware support for vlans? I use vlans extensively and never noticed a problem. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "You are as old as you feel." "Then I broke a few medical records." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: netinet/tcp.h compile error
On Sat, Dec 21, 2002 at 12:47:22AM +0100, David Holm wrote: > Hi, > when trying to install adasockets I got the following error message: > > /usr/include/netinet/tcp.h:44: syntax error before "tcp_seq" > /usr/include/netinet/tcp.h:44: warning: data definition has no type or > storage > class > /usr/include/netinet/tcp.h:45: syntax error before "tcp_cc" > /usr/include/netinet/tcp.h:45: warning: data definition has no type or > storage > class > /usr/include/netinet/tcp.h:55: syntax error before "u_short" > > I replaced #include with #include to make it work. > > Is this a bug? Most likely an application bug, yes. Please submit a PR to fix the port. Kris msg49138/pgp0.pgp Description: PGP signature
Re: mod_php4 4.2.3 under 5.0-CURRENT
Muhannad Asfour wrote: Hi, I was searching on groups.google.com recently to try to find out how to get mod_php4 compiled under 5.0-CURRENT, and I found your message and thought you might be of some assistance. I recently built a new server and wanted to run 5.0-CURRENT on it. I installed 5.0, cvsupped sources, rebuilt world, updated all of the ports. Everything works great, except the mod_php4 won?t build (Yes, I e-mailed the port maintainer, no reply yet) :( . I was wondering if you got it to build? Here is my error if you might be able to help me: ===> Building for mod_php4-4.2.3 Making all in Zend /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../main -DMOD_SSL=208112 -DMOD_PERL -DUSE_PERL_SSI -DAPPLLIB_EXP="/usr/local/lib/perl5/5.6.1/BSDPAN" -DEAPI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -I../TSRM -O -pipe -march=pentium4 -I/usr/local/include -prefer-pic -c zend_execute_API.c zend_execute_API.c: In function `zend_set_timeout': zend_execute_API.c:782: storage size of `t_r' isn't known zend_execute_API.c:788: `ITIMER_PROF' undeclared (first use in this function) zend_execute_API.c:788: (Each undeclared identifier is reported only once zend_execute_API.c:788: for each function it appears in.) zend_execute_API.c: In function `zend_unset_timeout': zend_execute_API.c:806: storage size of `no_timeout' isn't known zend_execute_API.c:810: `ITIMER_PROF' undeclared (first use in this function) *** Error code 1 Stop in /usr/ports/www/mod_php4/work/php-4.2.3/Zend. *** Error code 1 Stop in /usr/ports/www/mod_php4/work/php-4.2.3. *** Error code 1 Stop in /usr/ports/www/mod_php4. *** Error code 1 Stop in /usr/ports/www/mod_php4. Any help would greatly be appreciated, since this is a brand new server that needs to be up and running ASAP. Hi Muhannad, I just need a little bit more information to help you, cause I didn't run into compiler errors but in linker errors. Please send me your dmesg output and use the script(1) command to log your entire mod_php4 build process and send me that output, too. And please do not expect fast answers. It's 3:45 am here and I'm going to sleep in near future :-) Thanks, Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: <[EMAIL PROTECTED]> Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
WEIRD! div() broken on -CURRENT?
Okay, I must be losing my mind. Does anyone know why the following
program compiled with stock gcc-3.2.1, stock CFLAGS, and no CPUTYPE
produces:
ddy.quot = 1
ddy.rem = -1077937744
on -CURRENT, and:
ddy.quot = 8
ddy.rem = 0
On -stable?
#include
#include
main(void) {
div_t ddy;
int dy, dy_frac;
ddy = div (768, 96);
dy = ddy.quot;
dy_frac = ddy.rem;
printf("ddy.quot = %d\n", dy);
printf("ddy.rem = %d\n", dy_frac);
return 0;
}
> cc -O -pipe -o xxx xxx.c
I'm doing something wrong, right? I mean, this can't be right. I've
verified this now on a P4 running:
FreeBSD jclarke-pc.cisco.com 5.0-RC FreeBSD 5.0-RC #0: Mon Dec 16
02:54:55 EST 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/JCLARKE-PC i386
And a PIII running:
FreeBSD sysinfo.mezzweb.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Dec
16 09:44:28 CST 2002
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/BSDROCKS i386
Both machines produce the same result, while my -stable machines produce
the correct result. Both machines have fresh -CURRENT headers. Oh, and
if I move the xxx binary from my -stable machine to my -CURRENT machine,
it produces the correct result. Both machines have WITNESS and
INVARIANTS disabled. The PIII has MATH_EMULATE compiled in, but the P4
does not. Any help would be most appreciated as I think this is causing
Nautilus crashes on -CURRENT. Thanks.
Joe
--
PGP Key : http://www.marcuscom.com/pgp.asc
signature.asc
Description: This is a digitally signed message part
No memory to boot
Hi :))) I am trying to give boot with the cd of the FreeBSD 5.0-rc1 alone that not of the o boot, gives acknowledgment of that kernel did not obtain to place memory enough to give boot. The machine is a AMD Ahtlon 900MHz with 256MB Ram. With the cd of the 4.4-release and the 4.6-release of the o boot without problem. Regards, Vitor de Matos Carvalho System Network Administrator - Softinfo Network FreeBSD - The Power To Serve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mod_php4 4.2.3 under 5.0-CURRENT
Muhannad Asfour wrote: Here's the dmesg output: Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of tie University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Fri Dec 20 00:32:59 EST 2002\M^J [EMAIL PROTECTED]:/usr/src/sys/I386/compile/QUBIX Preloaded elf kernel "/boot/kernel/kernel" at 0xc052. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05200a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2394014604 Hz CPU: Pentium 4 (2394.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM ,> real memory = 536854528 (511 MB) avail memory = 516100096 (492 MB) Initializing GEOMetry subsystem 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, 10 entries at 0xc00f1b20 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 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1\^Zisab0: at device 2.0 on pci0 isa0: on isab0 ohci0: mem 0xf780-0xf7800fff irq 10 at device 2.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xf700-0xf7000fff irq 5 at device 2.3 on pci0 usb1: OHCI version!1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered atapci0: port 0xd800-0xd80f at device 2.5(on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 sis0: port 0xb000-0xb0ff mem 0xf680-0xf6800fff irq 12 at device 3.0 on pci0 sis0: Ethernet address: 00:e0:18:ab:17:b8 sis0: MII without any PHY! device_probe_and_attach: sis0 attach returned 6 pcm0: port 0xa800-0xa8ff irq 11 at device 5.0 on pci0 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xa400-0xa47f mem 0xf600-0xf67f irq 11 at device 9.0 on pci0 xl0: Ethernet address: 00:01:02:84:e3:7e miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes vhreshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 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/16 bytes threshold tlip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0y60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 orm0: at iomem 0xc8000-0xc87ff on isa0 pmtimer0 on isa0 Timecounters tick every 10.000 msec acpi_cpu: CPU throttling enabled, 8 steps from 100% to 12.5% ad0: 117246MB [238216/16/63] at ata0-master UDMA33 ad1: 38182MB [77578/16/63] at ata0-slave UDMA33 acd0: CDROM at ata1-master PIO\M-4 Mounting root from ufs:/dev/ad0s1a Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks, buffers remaining... 8 8 done Uptime: 36s Power system off using ACPI... Copyright (c) 1992-2002 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: Fri Dec 20 00:32:59 EST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/QUBIX Preloaded elf kernel "/boot/kernel/kernel" at 0xc052. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05200a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2394010816 Hz CPU: Pentium 4 (2394.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM ,> real memory = 536854528 (511 MB) avail memory = 515989504 (492 MB) Initializing GEOMetry subsystem 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, 10 entries at 0xc00f1b20 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 0x
Re: WEIRD! div() broken on -CURRENT?
On Fri, Dec 20, 2002 at 09:24:39PM -0500, Joe Marcus Clarke wrote:
> Okay, I must be losing my mind. Does anyone know why the following
> program compiled with stock gcc-3.2.1, stock CFLAGS, and no CPUTYPE
> produces:
>
> ddy.quot = 1
> ddy.rem = -1077937744
>
> on -CURRENT, and:
>
> ddy.quot = 8
> ddy.rem = 0
>
> On -stable?
>
> #include
> #include
>
> main(void) {
> div_t ddy;
> int dy, dy_frac;
>
> ddy = div (768, 96);
> dy = ddy.quot;
> dy_frac = ddy.rem;
>
> printf("ddy.quot = %d\n", dy);
> printf("ddy.rem = %d\n", dy_frac);
>
> return 0;
> }
>
> > cc -O -pipe -o xxx xxx.c
>
> I'm doing something wrong, right? I mean, this can't be right. I've
> verified this now on a P4 running:
[...]
I can reproduce it here. It looks like gcc is using a strange calling
convention that the i386 div.S does not understand (MI div.c seems to, though).
It's generating the following code:
0x8048541 : mov$0x0,%eax
0x8048546 :sub%eax,%esp
0x8048548 :lea0xfff8(%ebp),%eax
0x804854b :sub$0x4,%esp
0x804854e :push $0x60
0x8048550 :push $0x300
0x8048555 :push %eax
0x8048556 :call 0x80483ec
0x804855b :add$0xc,%esp
At the time of the call to div():
(gdb) x/4w $esp
0xbfbffbbc: 0x0804855b 0xbfbffbe8 0x0300 0x0060
It looks like gcc might be pushing the address of "ddy" and expecting div()
to put the result in there.
Microsoft C 12 generates this code:
sub esp, 8
push96 ; 0060H
push768 ; 0300H
call_div
add esp, 8
mov DWORD PTR [ebp], eax
mov DWORD PTR [ebp+4], edx
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
LOR while copying file to nfs
lock order reversal 1st 0xc35f0648 vnode interlock (vnode interlock) @ /usr/src/sys/nfsclient/nfs_vnops.c:2629 2nd 0xc043d678 vm page queue mutex (vm page queue mutex) @ /usr/src/sys/vm/vm_kern.c:424 I got this just now while copying a large file (155187200 bytes) to a nfs volume (sparc client, i386 server, GENERIC kernel built last night) Kris msg49144/pgp0.pgp Description: PGP signature
Re: LOR while copying file to nfs
On Fri, Dec 20, 2002 at 08:09:54PM -0800, Kris Kennaway wrote: > lock order reversal > 1st 0xc35f0648 vnode interlock (vnode interlock) @ >/usr/src/sys/nfsclient/nfs_vnops.c:2629 > 2nd 0xc043d678 vm page queue mutex (vm page queue mutex) @ >/usr/src/sys/vm/vm_kern.c:424 > > I got this just now while copying a large file (155187200 bytes) to a > nfs volume (sparc client, i386 server, GENERIC kernel built last > night) Oops, my mistake..I hadn't rebooted into the new kernel yet. FreeBSD panther2.freebsd.org 5.0-RC1 FreeBSD 5.0-RC1 #0: Sat Dec 7 11:02:43 GMT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC sparc64 Kris msg49145/pgp0.pgp Description: PGP signature
Re: WEIRD! div() broken on -CURRENT?
* De: Tim Robbins <[EMAIL PROTECTED]> [ Data: 2002-12-20 ] [ Subjecte: Re: WEIRD! div() broken on -CURRENT? ] > On Fri, Dec 20, 2002 at 09:24:39PM -0500, Joe Marcus Clarke wrote: > > I'm doing something wrong, right? I mean, this can't be right. I've > > verified this now on a P4 running: > [...] > > I can reproduce it here. It looks like gcc is using a strange calling > convention that the i386 div.S does not understand (MI div.c seems to, though). TenDRA and GCC3 use a different struct return format than we used to use (see http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01783.html) and we never had a flag day for the old format, and there's no UPDATING or whatnot notes about this AFAIK. This means at least div has to change to use the new calling convention. Of course, this only applies to things in assembly, as everything else returning a struct (in C) already uses the format of the compiler that compiled it. Sure changing div will break dynamically linked programs using the old calling convention, but anything else returning a struct has already gone through this. This will only affect non-native compilers generating code on a running FreeBSD 5 system which use the old struct return format. Older FreeBSD programs will of course use the old format with an old libc using the old format, and so it will work if compatability libraries are used. What we need now is a belated UPDATING, HEADS UP, as surely this will affect some edge case, much like the __sF hiding did, though certainly not that exact same edge case. More likely someone calling div() in libc from assembly (though why they'd do that is beyond me). Thanx, juli. -- Juli Mallett <[EMAIL PROTECTED]> OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i386 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- >>> stage 4: building libraries -- ===> lib/libc /local0/scratch/des/src/lib/libc/gen/getcap.c: In function `getent': /local0/scratch/des/src/lib/libc/gen/getcap.c:251: warning: passing arg 3 of `cdbget' discards qualifiers from pointer target type /local0/scratch/des/src/lib/libc/gen/getcap.c: In function `cgetmatch': /local0/scratch/des/src/lib/libc/gen/getcap.c:576: warning: assignment discards qualifiers from pointer target type /local0/scratch/des/src/lib/libc/gen/getcap.c:581: warning: assignment discards qualifiers from pointer target type /local0/scratch/des/src/lib/libc/gen/getcap.c: In function `getent': /local0/scratch/des/src/lib/libc/gen/getcap.c:251: warning: passing arg 3 of `cdbget' discards qualifiers from pointer target type /local0/scratch/des/src/lib/libc/gen/getcap.c: In function `cgetmatch': /local0/scratch/des/src/lib/libc/gen/getcap.c:576: warning: assignment discards qualifiers from pointer target type /local0/scratch/des/src/lib/libc/gen/getcap.c:581: warning: assignment discards qualifiers from pointer target type In file included from /local0/scratch/des/src/include/rpc/rpc.h:46, from /local0/scratch/des/src/lib/libc/rpc/getrpcent.c:55: /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include/sys/socket.h:43:27: machine/param.h: Interrupted system call *** Error code 1 Stop in /local0/scratch/des/src/lib/libc. *** Error code 1 Stop in /local0/scratch/des/src/lib. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
In some email I received from Terry Lambert, sie wrote:
> Sergey Mokryshev wrote:
> > Unfortunately nobody cares to look into PR database (conf/44576)
> >
> > In case PFIL_HOOKS really slows IP processing I don't mind keeping this
> > out of GENERIC, however it should be noted in UPDATING and release notes.
> >
> > I did not do any time consuming searches the first time I tried to load
> > ipl.ko, but I've spent some time reading NOTES before upgrading to
> > -CURRENT and I am using IP Filter for about three years now on Solaris
> > and FreeBSD (thanks, Darren).
> >
> > IMHO GENERIC is not supposed to be fast, but to be useable out-of-the box.
>
> This is a reasonable argument... if it's possible to tune it so
> that it's fast. Hacking in the IP Filter hooks unonditionally
> for code that can't really be distributed as part of the system
> because of its license, and thus making things slower, with no
> chance to make them faster later, is not my idea of A Really
> Good Thing(tm).
I don't understand this paragraph at all.
pfil(9) comes from NetBSD. It's not quite upto date with the
NetBSD code because I'm waiting for them to sort out how to deal
with bridging before updating again.
The purpose of pfil(9) is not to facilitate ipfilter but to act
as a mechanism for anything to filter packets to use it as the
way to receive packets. Ideally ipfw* should also use pfil(9)
and not have those large chunks of code in ip_{in,out}put.c.
> Probably the correct thing to do is to wire in ipfilter as a
> Netgraph module.
If/when the joining between layer 2 and layer 3 in the kernel
uses netgraph rather than the current mechanisms, then it would
be appropriate to use netgraph for ipfilter.
Darren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: WEIRD! div() broken on -CURRENT?
On Fri, Dec 20, 2002 at 08:43:25PM -0800, Juli Mallett wrote: > * De: Tim Robbins <[EMAIL PROTECTED]> [ Data: 2002-12-20 ] > [ Subjecte: Re: WEIRD! div() broken on -CURRENT? ] > > On Fri, Dec 20, 2002 at 09:24:39PM -0500, Joe Marcus Clarke wrote: > > > I'm doing something wrong, right? I mean, this can't be right. I've > > > verified this now on a P4 running: > > [...] > > > > I can reproduce it here. It looks like gcc is using a strange calling > > convention that the i386 div.S does not understand (MI div.c seems to, though). > > TenDRA and GCC3 use a different struct return format than we used to > use (see http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01783.html) and > we never had a flag day for the old format, and there's no UPDATING or > whatnot notes about this AFAIK. This means at least div has to change > to use the new calling convention. [...] I've imported the versions of div.S and ldiv.S from NetBSD HEAD which work properly with the new calling convention. Thanks for mentioning (on IRC) that the pcc struct return convention had something to do with it. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VLAN v.s. NIC with VLAN hardware support bug.
Daniel C. Sobral wrote, On 12/21/02 00:31: Dan Lukes wrote: > > If there somebody failing to configure vlans on a nic with > vlan-hardware support - read the PR 46405 (patch attached). > > It's apply to both current and stable. Does fxp have hardware support for vlans? I use vlans extensively and never noticed a problem. IFAIK no. I tried it also during debug of my problem. But it doesn't support 1000BaseTX, so it isn't decision for my purpose. The only cards with HW vlan support on STABLE are nge, bge, txp, gx, em, ti (ti aren't affected by reported bug as it strips the priority bits at driver level). Dan -- Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206 root of FIONet, KolejNET, webmaster of www.freebsd.cz AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VLAN v.s. NIC with VLAN hardware support bug.
> At 10:22 PM 20/12/2002 +0100, Dan Lukes wrote: > If there somebody failing to configure vlans on a nic with > vlan-hardware support - read the PR 46405 (patch attached). > Mike Tancsa wrote, On 12/20/02 22:46: > Does this bug show up in the trunk ports statistics as runt > packets ? Did you mean the statistics on switch ? No, it doesn't affect the switch statistic because bug is in receive part of FreeBSD driver - it doesn't affect packets sent out to switch. Dan -- Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206 root of FIONet, KolejNET, webmaster of www.freebsd.cz AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VLAN v.s. NIC with VLAN hardware support bug.
At 02:45 AM 12/21/2002 +0100, Dan Lukes wrote: > At 10:22 PM 20/12/2002 +0100, Dan Lukes wrote: > If there somebody failing to configure vlans on a nic with > vlan-hardware support - read the PR 46405 (patch attached). > Mike Tancsa wrote, On 12/20/02 22:46: > Does this bug show up in the trunk ports statistics as runt > packets ? Did you mean the statistics on switch ? Yes Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 6031000 bits/sec, 877 packets/sec 5 minute output rate 3104000 bits/sec, 1160 packets/sec 1631516276 packets input, 4237296754 bytes Received 161839 broadcasts, 212836721 runts, 0 giants, 0 throttles 212836725 input errors, 0 CRC, 4 frame, 0 overrun, 84223 ignored 0 watchdog, 0 multicast 0 input packets with dribble condition detected 194910163 packets output, 3947790078 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out No, it doesn't affect the switch statistic because bug is in receive part of FreeBSD driver - it doesn't affect packets sent out to switch. It doesnt seem to affect performance. When I did some benchmarks way back with netperf, the difference in vlan performance vs native fxp performance was barely significant. ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications, [EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-CURRENT panic on SMP Athlon box.
My SMP Athlon box paniced again tonight, and this time my serial console caught it in the act. I have no idea what has caused this, and have no idea if it has any significance for 5.0-R or not. I wonder if we have a memory leak ? Poul-Henning login: panic: kmem_malloc(4096): kmem_map too small: 275378176 total allocated cpuid = 1; lapic.id = 0100 panic(c033e881,1000,1069f000,e752c714,1) at panic+0x10a kmem_malloc(c082e07c,1000,4,e752c76c,c02c6a7b) at kmem_malloc+0x11d page_alloc(c083a600,1000,e752c75f,4,c0330243) at page_alloc+0x27 slab_zalloc(c083a600,0,c038bd1c,c083a73c,57e) at slab_zalloc+0xfb uma_zone_slab(c083a600,0,15f,c038bd1c,c083a73c) at uma_zone_slab+0x9e uma_zalloc_bucket(c083a600,0,c0340146,57e,c038d03c) at uma_zalloc_bucket+0x18d uma_zalloc_arg(c083a600,0,0,c0340628,252c820) at uma_zalloc_arg+0x304 vm_object_allocate_wait(2,1,0,0,e752c850) at vm_object_allocate_wait+0x38 vm_object_allocate(2,1,0,89,0) at vm_object_allocate+0x28 vnode_pager_alloc(d4116ce4,200,0,0,0) at vnode_pager_alloc+0x172 vop_stdcreatevobject(e752c954,e752c93c,c02af0a8,e752c954,e752c968) at vop_stdcre atevobject+0x175 vop_defaultop(e752c954,e752c968,c022f4fa,e752c954,1) at vop_defaultop+0x18 ufs_vnoperate(e752c954,1,c0337335,c8e,c034c6a0) at ufs_vnoperate+0x18 vfs_object_create(d4116ce4,cc6921c0,ceb3e480,a4,cc6921c0) at vfs_object_create+0 x5a namei(e752cbd8,cc6921c0,ceb3e480,100,cc6921c0) at namei+0x2f6 vn_open_cred(e752cbd8,e752ccd8,1,ceb3e480,e752ccc4) at vn_open_cred+0x258 vn_open(e752cbd8,e752ccd8,1,295,6) at vn_open+0x29 kern_open(cc6921c0,805dca8,0,5,1) at kern_open+0x183 open(cc6921c0,e752cd10,c0344225,407,3) at open+0x30 syscall(2f,2f,2f,805dc00,80533c0) at syscall+0x28e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5), eip = 0x280b78d3, esp = 0xbfbff94c, ebp = 0xbfbffb18 --- boot() called on cpu#1 yncing disks, buffers remaining... panic: bremfree: bp 0xd42a9240 not locked cpuid = 1; lapic.id = 0100 boot() called on cpu#1 Uptime: 17h37m0s Terminate ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset called on cpu#1 cpu_reset: Stopping other CPUs cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 1 Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS drive E: is disk3 BIOS drive F: is disk4 BIOS 633kB/2096048kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Thu Dec 19 09:30:06 CET 2002) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x2489a8 data=0x2f25c+0x3e128 syms=[0x4+0x30fe0+0x4+0x3 afeb] Hit [Enter] to boot immediately, or any other key for command prompt. ^MBooting [/boot/kernel/kernel] in 9 seconds... ^MBooting [/boot/kernel/kernel] in 8 seconds... ^MBooting [/boot/kernel/kernel] in 7 seconds... ^MBooting [/boot /kernel/kernel] in 6 seconds... ^MBooting [/boot/kernel/kernel] in 5 seconds... Booting [/boot/kernel/kernel] in 4 seconds... ^MBooting [/boot/kernel/kernel] in 3 seconds... ^MBooting [/boot/kernel/kernel] in 2 seconds... ^MBooting [/boot/k ernel/kernel] in 1 second... ^MBooting [/boot/kernel/kernel]... /boot/kernel/acpi.ko text=0x39930 data=0x1a58+0xb48 syms=[0x4+0x5810+0x4+0x7495] Copyright (c) 1992-2002 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 #2: Fri Dec 20 09:21:19 CET 2002 [EMAIL PROTECTED]:/bang/src/sys/i386/compile/BANG Preloaded elf kernel "/boot/kernel/kernel" at 0xc046e000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc046e0a8. Timecounter "i8254" frequency 1193182 Hz CPU: AMD Athlon(TM) MP 1800+ (1533.40-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc048 real memory = 2147401728 (2047 MB) avail memory = 2085785600 (1989 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: 0x00040010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Initializing GEOMetry subsystem 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, 9 entries at 0xc00f24a0 acpi0: power button is handled as a fixed feature programming model. acpi0: sleep button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 IOAPIC #0 intpin 16 -> irq 2 IOAPIC #0 intpin 17 -> irq 10 agp0: port 0xe800-0xe803 mem 0xfb80-0xfb800fff, 0xfc00-0xfdff at device 0.0 on pci0 pcib1: at device
