daily CVS update output

[NetBSD source update]

Updating src tree:
P src/lib/libc/shlib_version
P src/lib/libc/gen/siglist.c
P src/lib/libc/sys/fork.2
P src/lib/libc/sys/sigaction.2
P src/share/man/man7/signal.7
P src/sys/arch/amd64/amd64/locore.S
P src/sys/arch/arm/omap/omap2_gpio.c
P src/sys/arch/arm/omap/omap_edma.c
P src/sys/arch/evbmips/loongson/yeeloong_machdep.c
P src/sys/arch/hpcmips/tx/tx3912video.c
P src/sys/arch/i386/i386/locore.S
P src/sys/arch/x86/x86/pmap.c
P src/sys/external/bsd/drm2/dist/drm/radeon/radeon_ttm.c
P src/sys/kern/subr_kobj.c
P src/sys/kern/subr_kobj_vfs.c
P src/sys/rump/Makefile.rump
P src/sys/sys/kobj_impl.h

Updating xsrc tree:
P xsrc/external/mit/xf86-video-siliconmotion/dist/src/smi_driver.c
P xsrc/external/mit/xorg-server/dist/hw/xfree86/vgahw/vgaHW.h
P xsrc/external/mit/xorg-server.old/dist/hw/xfree86/vgahw/vgaHW.h


Killing core files:

Running the SUP scanner:
SUP Scan for current starting at Sun Jul 10 03:01:43 2016
SUP Scan for current completed at Sun Jul 10 03:02:03 2016
SUP Scan for mirror starting at Sun Jul 10 03:02:03 2016
SUP Scan for mirror completed at Sun Jul 10 03:04:54 2016




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  53506592 Jul 10 03:06 ls-lRA.gz

Re: Unexpected kernel device dependency for 'vga* at pci?'

[Robert Elz]

Date:Sun, 10 Jul 2016 08:32:24 +0800 (PHT)
From:Paul Goyette 
Message-ID:  

  | "Common" yes, but they should not be normal.  The whole point of the 
  | config(1) mess is to be able to properly specify dependencies.

Well, really, the point was to make it easier to build the config files,
that before config(1 or 8) appeared used to be built by hand.  Adding forms
of dependency handling has been a more recent add on - and config files
have (since I first saw one I think) never been "anything goes" - there have
always been "of course if you config X you also need Y" type stuff (apart
from the obvious ones that config itself complains about if you mess up, like
a device at pci, and no pci at anything).

  | As I indicated in a follow-up Email, I still need to include a
  | 
  | vga* at pci? dev ? func ?
  | 
  | to avoid a compiler error.  But I have already removed the
  | 
  | wsdisplay* at vga? console ?
  | 
  | line.  The only wsdisplay line I currently have is
  | 
  | wsdisplay* at radeondrmkmsfb0

That's interesting, I don't have that (or anything like it) in my config
at all - not even commented out.

What I have is (aside from the "at vga?" line) is ...

wsdisplay*  at wsemuldisplaydev?

That one seems to be enough for the kernel to config ...

wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation)

The other related config that I have are ...

i915drmkms* at pci? dev ? function ?
intelfb*at intelfbbus?

  | which, according to the dmesg, is where it actually gets attached!

which is what gets attached in my case.   I assume one of the files files
has something that makes an intelfb attach a wsemuldisplaydev, or that the
latter is some kind of macro device for the various fb devices.
But I am just guessing...

And as I (kind of said) I never actually tried a config with the "vga* at pci?"
config included but the wsdisplay* at vga? console ?" omitted, it was both
or neither for me (just the way it worked out.)

kre

Re: Another dependency problem: radeon (also?) depends on agp

[Paul Goyette]

On Sun, 10 Jul 2016, Paul Goyette wrote:


I've also discovered that if you have a radeon, you also need to have

agp* at pchb?

configured.  Otherwise you get the following errors while compiling 
radeon_ttm.c


/build/netbsd-local/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_ttm.c: 
In function 'radeon_ttm_tt_populate':
/build/netbsd-local/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_ttm.c:612:24: 
error: variable 'rdev' set but not used [-Werror=unused-but-set-variable]

 struct radeon_device *rdev;
   ^
/build/netbsd-local/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_ttm.c: 
In function 'radeon_ttm_tt_unpopulate':
/build/netbsd-local/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_ttm.c:677:24: 
error: variable 'rdev' set but not used [-Werror=unused-but-set-variable]

 struct radeon_device *rdev;
   ^
cc1: all warnings being treated as errors


I just committed a fix for this issue.

Still need to investigate the 'vga* at pci? ...' issue more closely.


+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

Re: Unexpected kernel device dependency for 'vga* at pci?'

[Paul Goyette]

On Sun, 10 Jul 2016, Robert Elz wrote:


   Date:Sun, 10 Jul 2016 07:00:11 +0800 (PHT)
   From:Paul Goyette 
   Message-ID:  

 | While doing this, I've discovered that a radeondrmkmsfb0-based kernel
 | requires that I retain the
 |
 |  vga* at pci? dev ? func ?
 |
 | line in the configuration, even though no such device is ever attached.

I saw the exact same problem a month or so ago, but with a system using
integrated intel graphics (core i3 processor).

I didn't bother to mention it as config file inter-dependencies and weirdness
are just "normal" ...


"Common" yes, but they should not be normal.  The whole point of the 
config(1) mess is to be able to properly specify dependencies.



I think I concluded/assumed that the issue may have really related to the

wsdisplay*  at vga? console ?

line that also had to be deleted (there being no vga? at anything left
in the config - or in the console messages on a GENERIC boot) leaving
nothing marked as "console" - whether that's actually true or not I didn't
bother to find out - I put that entry back, and so had to also return the
vga? at .. config, and after that, it all worked.


As I indicated in a follow-up Email, I still need to include a

vga* at pci? dev ? func ?

to avoid a compiler error.  But I have already removed the

wsdisplay* at vga? console ?

line.  The only wsdisplay line I currently have is

wsdisplay* at radeondrmkmsfb0

which, according to the dmesg, is where it actually gets attached!


+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

Re: Unexpected kernel device dependency for 'vga* at pci?'

[Robert Elz]

Date:Sun, 10 Jul 2016 07:00:11 +0800 (PHT)
From:Paul Goyette 
Message-ID:  

  | While doing this, I've discovered that a radeondrmkmsfb0-based kernel 
  | requires that I retain the
  | 
  | vga* at pci? dev ? func ?
  | 
  | line in the configuration, even though no such device is ever attached.

I saw the exact same problem a month or so ago, but with a system using
integrated intel graphics (core i3 processor).

I didn't bother to mention it as config file inter-dependencies and weirdness
are just "normal" ...

I think I concluded/assumed that the issue may have really related to the

wsdisplay*  at vga? console ?

line that also had to be deleted (there being no vga? at anything left
in the config - or in the console messages on a GENERIC boot) leaving
nothing marked as "console" - whether that's actually true or not I didn't
bother to find out - I put that entry back, and so had to also return the
vga? at .. config, and after that, it all worked.

When it wasn't working, the symptoms were as you described (though I probably 
did less tests.)

kre

Another dependency problem: radeon (also?) depends on agp

[Paul Goyette]

I've also discovered that if you have a radeon, you also need to have

agp* at pchb?

configured.  Otherwise you get the following errors while compiling 
radeon_ttm.c


/build/netbsd-local/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_ttm.c: In 
function 'radeon_ttm_tt_populate':
/build/netbsd-local/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_ttm.c:612:24:
 error: variable 'rdev' set but not used [-Werror=unused-but-set-variable]
  struct radeon_device *rdev;
^
/build/netbsd-local/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_ttm.c: In 
function 'radeon_ttm_tt_unpopulate':
/build/netbsd-local/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_ttm.c:677:24:
 error: variable 'rdev' set but not used [-Werror=unused-but-set-variable]
  struct radeon_device *rdev;
^
cc1: all warnings being treated as errors


+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

Unexpected kernel device dependency for 'vga* at pci?'

[Paul Goyette]

I've been getting a new (well, new-to-me!) system up and running, and 
one of my usual steps is to build a minimal kernel.  Starting with a 
GENERIC kernel and its dmesg(8) output, I remove all the device drivers 
that I don't need/use/want, and hard-wire most of the others.


While doing this, I've discovered that a radeondrmkmsfb0-based kernel 
requires that I retain the


vga* at pci? dev ? func ?

line in the configuration, even though no such device is ever attached.

If I remove that config line, the kernel will still build and link, but 
when booting the resulting kernel it fails.  The system starts to come 
up normally, but at the point where it would normally "change the 
display mode" (from large-font to tiny-font) the screen just goes blank. 
When it "returns" the display is totally blank (except for the small, 
non-blinking cursor) and the system is hung.  It's not just a "display 
failure" since blind typing doesn't do anything, either.  (I boot in 
single-user, so either ddb should accept a reboot command, or init 
should access a "return for /bin/sh" followed by a reboot command!)


I'm guessing that somewhere in the radeon code there's some .ifdef'd 
code that calls some common vga routine(s) if available.  (I suspect it 
might be related to VGA_POST, but have no evidence to support.)


It seems to me that, if the radeon code needs something from the vga 
driver, some sort of proper dependency should be used.  Perhaps the 
"common vga routines" should be extracted into a separate file which can 
be required by both vga and radeon drivers, or the radeon driver can be 
dependent on the vga driver?


The dmesg of the system in question is attached in case anyone wants to 
look at this more closely.



+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016
The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.

NetBSD 7.99.33 (TEST 2016-07-07 22:19:31) #7: Sun Jul 10 05:35:20 PHT 2016

p...@pokey.whooppee.com:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/TEST
total memory = 7613 MB
avail memory = 7378 MB
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
Gateway SX2185 ()
mainbus0 (root)
ACPI: RSDP 0x000F0490 24 (v02 ACRSYS)
ACPI: XSDT 0x9CC0C080 7C (v01 ACRSYS ACRPRDCT 01072009 AMI  
00010013)
ACPI: FACP 0x9CC12698 00010C (v05 ACRSYS ACRPRDCT 01072009 AMI  
00010013)
ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid Length 
but zero Address: 0x/0x1 (20160422/tbfadt-684)
ACPI: DSDT 0x9CC0C188 00650D (v02 ACRSYS ACRPRDCT  INTL 
20051117)
ACPI: FACS 0x9D0D3080 40
ACPI: APIC 0x9CC127A8 7E (v03 ACRSYS ACRPRDCT 01072009 AMI  
00010013)
ACPI: FPDT 0x9CC12828 44 (v01 ACRSYS ACRPRDCT 01072009 AMI  
00010013)
ACPI: MCFG 0x9CC12870 3C (v01 ACRSYS ACRPRDCT 01072009 MSFT 
00010013)
ACPI: MSDM 0x9CC128B0 55 (v03 ACRSYS ACRPRDCT 01072009 AMI  
00010013)
ACPI: HPET 0x9CC12908 38 (v01 ACRSYS ACRPRDCT 01072009 AMI  
0005)
ACPI: SSDT 0x9CC12940 0005E0 (v01 AMDAGESA0001 AMD  
0001)
ACPI: SSDT 0x9CC12F20 0046B7 (v02 AMDAGESA0002 MSFT 
0400)
ACPI: CRAT 0x9CC175D8 000278 (v01 AMDAGESA0001 AMD  
0001)
ACPI: SSDT 0x9CC17850 2B (v01 AMDCPMXPRES 0001 INTL 
20051117)
ACPI: SSDT 0x9CC17880 0010E8 (v01 AMDCPMCMN   0001 INTL 
20051117)
ACPI: Executed 1 blocks of module-level executable AML code
ACPI: 5 ACPI AML tables successfully acquired and loaded

ioapic0 at mainbus0 apid 3: pa 0xfec0, version 0x21, 24 pins
ioapic1 at mainbus0 apid 4: pa 0xfec01000, version 0x21, 32 pins
cpu0 at mainbus0 apid 0
cpu0: AMD E1-2500 APU with Radeon(TM) HD Graphics, id 0x700f01
cpu1 at mainbus0 apid 1
cpu1: AMD E1-2500 APU with Radeon(TM) HD Graphics, id 0x700f01
acpi0 at mainbus0: Intel ACPICA 20160422
acpi0: X/RSDT: OemId , AslId 
acpi0: MCFG: segment 0, bus 0-255, address 0xe000
acpi0: SCI interrupting at int 9
timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000
AMDN (PNP0C01) at acpi0 not configured
BROD (PNP0C02) at acpi0 not configured
SIO1 (PNP0C02) at acpi0 not configured
NBRM (PNP0C02) at acpi0 not configured
attimer0 at acpi0 (TMR, PNP0100): io 

Re: Issues with netstat -ia

[Thomas Klausner]

On Sat, Jul 09, 2016 at 03:34:46PM +0100, Dave Tyson wrote:
> Anyone else seeing this?

Yes, but my mail with more debugging info seems to be stuck in mailing
list maintainer approval :)
 Thomas

Issues with netstat -ia

[Dave Tyson]

Just upgraded an amd64 system to the latest current - checked out and compiled 
8/7/16.

NetBSD dell.anduin.org.uk 7.99.33 NetBSD 7.99.33 (GENERIC) #0: Fri Jul  8 
15:30:25 BST 2016  
r...@dell.anduin.org.uk:/usr/obj/sys/arch/amd64/compile/GENERIC amd64

I was building pkgsrc firefox 17.0.1 today and it seemed to be taking an 
inordinate time to configure and this appears to be due one of tools issuing 
netstat -ia and running up CPU.

A quick check showed netstat -i seems OK:

Name  Mtu   Network Address  Ipkts IerrsOpkts Oerrs Colls
bge0  1500b8:ac:6f:c3:50:df   656074 0   337913 0 0
bge0  1500  default fe80::baac:6fff:f   656074 0   337913 0 0
bge0  1500  192/0   dell.anduin.org.u   656074 0   337913 0 0
lo0   336246 06 0 0
lo0   33624 127.0.0.1/32 localhost   6 06 0 0
lo0   33624 default ::1  6 06 0 0
lo0   33624 default fe80::1  6 06 0 0

but netstat -ia loops:

Name  Mtu   Network  Address  Ipkts IerrsOpkts Oerrs Colls
bge0  1500 b8:ac:6f:c3:50:df   655869 0   337865 0 0
bge0  1500  default  fe80::baac:6fff:f   655869 0   337865 0 0
netstat: kvm_read: Bad address
bge0  1500  192/0dell.anduin.org.u 
netstat: kvm_read: Bad address
  default   
netstat: kvm_read: Bad address
  default 
...

Anyone else seeing this?

Dave


-- 

Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk

Re: umass1: failed to create xfers

[Thomas Klausner]

On Fri, Jul 08, 2016 at 12:55:25PM +0200, Thomas Klausner wrote:
> On Thu, Jul 07, 2016 at 10:37:20AM +0100, Nick Hudson wrote:
> > I can't see the problem and it works for me Maybe update to HEAD and send
> > the debug log?
> 
> I've tried again with USBDEBUG and UMASSDEBUG kernel on head, and
> can't reproduce it.
> 
> I'll probably try again with a kernel without these flags.

I tried with the same sources and without the debug flags, and it
still works. Weird.

I'll report if it happens again, but for now, let's forget about it :)
 Thomas