X | 1 Aug 03:07 2008
Picon

X wants to chat

-----------------------------------------------------------------------

X wants to stay in better touch using some of Google's coolest new
products.

If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-a713375744-fe97ad4575-8e433225c0d39cc3
You'll need to click this link to be able to chat with X.

To get Gmail - a free email account from Google with over 2,800 megabytes of
storage - and chat with X, visit:
http://mail.google.com/mail/a-a713375744-fe97ad4575-9868416691

Gmail offers:
- Instant messaging right inside Gmail
- Powerful spam protection
- Built-in search for finding your messages and a helpful way of organizing
  emails into "conversations"
- No pop-up ads or untargeted banners - just text ads and related information
  that are relevant to the content of your messages

All this, and its yours for free. But wait, there's more! By opening a Gmail
account, you also get access to Google Talk, Google's instant messaging
service:

http://www.google.com/talk/

Google Talk offers:
- Web-based chat that you can use anywhere, without a download
- A contact list that's synchronized with your Gmail account
(Continue reading)

Bernd Ernesti | 1 Aug 09:26 2008
Picon

Re: ACPI/APM suspend errors related to yds

On Thu, Jul 31, 2008 at 01:48:37PM +0200, Bernd Ernesti wrote:

I opened a pr about this problem, since this thread moves away
from my yds related problem: port-i386/39259

Bernd

David Young | 3 Aug 22:16 2008
Picon

Re: ACPI/APM suspend errors related to yds

On Thu, Jul 31, 2008 at 01:48:37PM +0200, Bernd Ernesti wrote:
> On Sun, Jul 27, 2008 at 07:11:51PM +0200, Bernd Ernesti wrote:
> > On Sun, Jul 27, 2008 at 12:47:55PM -0400, Jared D. McNeill wrote:
> > > Bernd Ernesti wrote:
> > > >Hi,
> > > >
> > > >I need a kernel without any ACPI support, because ACPI is broken for me
> > > >on a specific notebook.
> > > 
> > > Did you raise a PR on it?
> > 
> > No, because I don't expect that it can be fixed, because of the age of the BIOS,
> > which is 8 years old. IMHO the ACPI implmentation is too broken to be fixed, but
> > I would like to be proven wrong.
> 
> I just tried a 4.99.71 and it seems to work better.
> Now I remember my problem which was related to suspend to disk.
> 
> > I need apm too for suspend to disk too.
> 
> Fn + F12 didn't supsend with ACPI. Nothing happens so I tried it without
> ACPI and with apm and the first message was this (both devicies are attached
> to yds0):
>   Devices without power management support: opl0 mpu0
> 
> Then I got some BIOS message:
> 
> PCI Parity Error On Bus/Device/Function 0048h
> PCI System Error On Bus/Device/Function 0060h
> PCI Parity Error On Bus/Device/Function 0060h
(Continue reading)

Pierre Pronchery | 4 Aug 01:36 2008

Re: ACPI quirk for ASUS CUR-DLS

			Hi,

It's been a while, but I just tried a -current kernel again, which I got
there:
ftp://ftp.netbsd.org/pub/NetBSD-daily/HEAD/200808020002Z/i386/binary/kernel/netbsd-GENERIC.gz

On 2008-05-19, Joerg Sonnenberger <joerg <at> britannica.bec.de> wrote:
> On Sun, May 18, 2008 at 10:10:12PM +0000, Pierre Pronchery wrote:
>> I wrote a while ago about an issue with the CUR-DLS motherboard from
>> ASUS:
>> http://mail-index.netbsd.org/port-i386/2008/02/14/msg000199.html
>
> Does the same behavior happen in NetBSD current as well?
> Jared and I have been discussing to ignore AML breakpoints by default,
> this is not the only reported case of them leaking into normal code
> pathes.

I get inside the breakpoint again. If I force it to continue, the kernel
hangs with:
cpu1: failed to start

I could then drop into ddb. If you know anything I could do that would
be useful to diagnose this better, I'd be glad to hear it. Even though
this machine is in production it's not used 100% of the time. It's just
awfully slow to boot it :(

BTW, I tried to flash the BIOS with the official AWARD image from Asus
instead of the latest Phoenix one available from HP, but the Asus flash
utility refused to burn it. I have a spare BIOS chip, so I can risk
something if anyone can give me a hint regarding this. I'll post the
(Continue reading)

Manuel Bouyer | 6 Aug 16:32 2008

Re: wm problem, the dmesg output

On Thu, Jul 17, 2008 at 01:10:05PM +0300, Jukka Marin wrote:
> [...]
> 
> pci6: i/o space, memory space enabled
> wm2 at pci6 dev 0 function 0: Intel PRO/1000 PT (82571EB), rev. 6
> wm2: interrupting at ioapic0 pin 16, event channel 3
> wm2: PCI-Express bus
> wm2: 65536 word (16 address bits) SPI EEPROM
> wm2: Ethernet address 00:15:17:6d:4b:ae
> igphy0 at wm2 phy 1: Intel IGP01E1000 Gigabit PHY, rev. 0
> igphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto

I think I've the same chip in a box at work but I can't check right now
(it's not a remotely-accessible system). Your issue could be wrong interrupt
routing, or not enough nmbclusters

--

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer <at> lip6.fr
     NetBSD: 26 ans d'experience feront toujours la difference
--

Jukka Marin | 6 Aug 17:19 2008
Picon

Re: wm problem, the dmesg output

On Wed, Aug 06, 2008 at 04:32:01PM +0200, Manuel Bouyer wrote:
> > pci6: i/o space, memory space enabled
> > wm2 at pci6 dev 0 function 0: Intel PRO/1000 PT (82571EB), rev. 6
> > wm2: interrupting at ioapic0 pin 16, event channel 3
> > wm2: PCI-Express bus
> > wm2: 65536 word (16 address bits) SPI EEPROM
> > wm2: Ethernet address 00:15:17:6d:4b:ae
> > igphy0 at wm2 phy 1: Intel IGP01E1000 Gigabit PHY, rev. 0
> > igphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
> 
> I think I've the same chip in a box at work but I can't check right now
> (it's not a remotely-accessible system). Your issue could be wrong interrupt
> routing, or not enough nmbclusters

Thanks for the reply.  I got timeout errors in the log:

wm2: device timeout (txfree 4024 txsfree 0 txnext 72)
wm2: device timeout (txfree 4028 txsfree 0 txnext 68)
wm2: device timeout (txfree 4025 txsfree 0 txnext 71)
wm2: device timeout (txfree 4032 txsfree 0 txnext 64)

and after a while, it complained about nmbcluster shortage, but I think that
was caused by the wm transmit problem.

How can I check if interrupt routing works?  (This is a production system
which should stay up all the time, but I want to get the additional Ethernet
ports working, too..)

  -jm

(Continue reading)

Manuel Bouyer | 6 Aug 17:29 2008

Re: wm problem, the dmesg output

On Wed, Aug 06, 2008 at 06:19:03PM +0300, Jukka Marin wrote:
> On Wed, Aug 06, 2008 at 04:32:01PM +0200, Manuel Bouyer wrote:
> > > pci6: i/o space, memory space enabled
> > > wm2 at pci6 dev 0 function 0: Intel PRO/1000 PT (82571EB), rev. 6
> > > wm2: interrupting at ioapic0 pin 16, event channel 3
> > > wm2: PCI-Express bus
> > > wm2: 65536 word (16 address bits) SPI EEPROM
> > > wm2: Ethernet address 00:15:17:6d:4b:ae
> > > igphy0 at wm2 phy 1: Intel IGP01E1000 Gigabit PHY, rev. 0
> > > igphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
> > 
> > I think I've the same chip in a box at work but I can't check right now
> > (it's not a remotely-accessible system). Your issue could be wrong interrupt
> > routing, or not enough nmbclusters
> 
> Thanks for the reply.  I got timeout errors in the log:
> 
> wm2: device timeout (txfree 4024 txsfree 0 txnext 72)
> wm2: device timeout (txfree 4028 txsfree 0 txnext 68)
> wm2: device timeout (txfree 4025 txsfree 0 txnext 71)
> wm2: device timeout (txfree 4032 txsfree 0 txnext 64)
> 
> and after a while, it complained about nmbcluster shortage, but I think that
> was caused by the wm transmit problem.
> 
> How can I check if interrupt routing works?  (This is a production system
> which should stay up all the time, but I want to get the additional Ethernet
> ports working, too..)

I'd look at the outout of vmstat -i, assuming wm2 doens't use a shared
(Continue reading)

Jukka Marin | 6 Aug 17:48 2008
Picon

Re: wm problem, the dmesg output

On Wed, Aug 06, 2008 at 05:29:41PM +0200, Manuel Bouyer wrote:
> > How can I check if interrupt routing works?  (This is a production system
> > which should stay up all the time, but I want to get the additional Ethernet
> > ports working, too..)
> 
> I'd look at the outout of vmstat -i, assuming wm2 doens't use a shared
> interrupt.

Well..

wm2 at pci6 dev 0 function 0: Intel PRO/1000 PT (82571EB), rev. 6
wm2: interrupting at ioapic0 pin 16, event channel 3
...
wm3 at pci6 dev 0 function 1: Intel PRO/1000 PT (82571EB), rev. 6
ioapic0: int17 1a9c0<vector=c0,delmode=1,logical,actlo,level,masked,dest=0> f000000<target=f>
wm3: interrupting at ioapic0 pin 17, event channel 6

and

interrupt                                     total     rate
...
vcpu0 ioapic0 pin 16                       68529180       37
vcpu0 ioapic0 pin 18                       54273505       29
vcpu0 ioapic0 pin 19                      154071320       84
vcpu0 ioapic0 pin 17                            218        0

and (from dmesg.boot):

ioapic0: pin 16 attached to pci0 device 0 INT_A (type 0<type=0> flags f<pol=3=Act Lo,trig=3=Level>)
ioapic0: pin 16 attached to pci0 device 2 INT_A (type 0<type=0> flags f<pol=3=Act Lo,trig=3=Level>)
(Continue reading)

Manuel Bouyer | 6 Aug 17:51 2008

Re: wm problem, the dmesg output

On Wed, Aug 06, 2008 at 06:48:21PM +0300, Jukka Marin wrote:
> 
> wm2 at pci6 dev 0 function 0: Intel PRO/1000 PT (82571EB), rev. 6
> wm2: interrupting at ioapic0 pin 16, event channel 3
> ...
> wm3 at pci6 dev 0 function 1: Intel PRO/1000 PT (82571EB), rev. 6
> ioapic0: int17 1a9c0<vector=c0,delmode=1,logical,actlo,level,masked,dest=0> f000000<target=f>
> wm3: interrupting at ioapic0 pin 17, event channel 6
> 
> and
> 
> interrupt                                     total     rate
> ...
> vcpu0 ioapic0 pin 16                       68529180       37
> vcpu0 ioapic0 pin 18                       54273505       29
> vcpu0 ioapic0 pin 19                      154071320       84
> vcpu0 ioapic0 pin 17                            218        0
> 
> and (from dmesg.boot):
> 
> ioapic0: pin 16 attached to pci0 device 0 INT_A (type 0<type=0> flags f<pol=3=Act Lo,trig=3=Level>)
> ioapic0: pin 16 attached to pci0 device 2 INT_A (type 0<type=0> flags f<pol=3=Act Lo,trig=3=Level>)
> ioapic0: pin 16 attached to pci0 device 8 INT_A (type 0<type=0> flags f<pol=3=Act Lo,trig=3=Level>)
> ioapic0: pin 16 attached to pci0 device 28 INT_B (type 0<type=0> flags f<pol=3=Act Lo,trig=3=Level>)
> ioapic0: pin 16 attached to pci0 device 29 INT_D (type 0<type=0> flags f<pol=3=Act Lo,trig=3=Level>)
> ioapic0: pin 16 attached to pci1 device 0 INT_A (type 0<type=0> flags f<pol=3=Act Lo,trig=3=Level>)
> ioapic0: pin 16 attached to pci2 device 0 INT_A (type 0<type=0> flags f<pol=3=Act Lo,trig=3=Level>)
> ioapic0: pin 16 attached to pci3 device 0 INT_A (type 0<type=0> flags f<pol=3=Act Lo,trig=3=Level>)
> ioapic0: pin 16 attached to pci6 device 0 INT_A (type 0<type=0> flags f<pol=3=Act Lo,trig=3=Level>)
> ioapic0: pin 16 attached to pci7 device 2 INT_A (type 0<type=0> flags f<pol=3=Act Lo,trig=3=Level>)
(Continue reading)

Andrew Ball | 10 Aug 07:53 2008

Sysinst "bypass fdisk" option?


Hello,

    This may have already been considered and rejected, but
I have to ask the question.

    I am a NetBSD/i386 user who generally installs on
machines that will only ever be running NetBSD. I would much
prefer being able to skip fdisk and simply write a BSD disk-
label.  This would save me having to deal with fdisk quirks
such as it having a different idea of the disk's geometry
and it misreporting the end sector of each partition.  I
fully understand that fdisk should be the default on i386
because many people will want to dual boot with operating
systems that depend on it, but I really wish it weren't
mandatory.

- Andy Ball.


Gmane