Re: umass media size off-by-one?

[Craig Boston]

On Mon, Mar 05, 2007 at 09:37:33PM -0700, Scott Long wrote:
> Fixed in 7-CURRENT.  Contact Warner Losh to make sure that your device
> is quirked appropriately.

Ah, thanks!  I see the commit now.  Looks like it should be simple to
backport to RELENG_6.

Fortunately all 3 of the machines I intend to use this drive with have
their own local svk branches of the src tree ;)

I'll mail Warner with the vendor and product IDs for my enclosure.

Craig
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: umass media size off-by-one?

[Scott Long]

Craig Boston wrote:

Hi all, I ran into this while trying to use geli to encrypt an external
usb-2 hard drive.  It appears that sometimes the media size reported by
umass is one sector too big.  For example:

umass0: Prolific Technology Inc. Mass Storage Device, rev 2.00/1.00, addr 2
da0 at umass-sim0 bus 0 target 0 lun 0
da0:  Fixed Direct Access SCSI-0 device 
da0: 40.000MB/s transfers

da0: 171705MB (351651889 512 byte sectors: 255H 63S/T 21889C)

# dd if=/dev/zero of=/dev/da0 oseek=351651888 count=1
dd: /dev/da0: Input/output error
1+0 records in
0+0 records out
0 bytes transferred in 0.002951 secs (0 bytes/sec)

# dd if=/dev/zero of=/dev/da0 oseek=351651887 count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.000982 secs (521360 bytes/sec)

This is with a "high speed, power 100 mA, config 1, Mass Storage
Device(0x3507), Prolific Technology Inc.(0x067b), rev 1.00" enclosure.
I tested with two USB flash memory devices and those seem to report the
correct size.

I'm currently rebuilding a kernel with USB_DEBUG to see if it's specific
to a certain protocol and try to figure out if it's a bug in one of them
or if the enclosure is lying.  Has anyone run into this before?

Craig


Fixed in 7-CURRENT.  Contact Warner Losh to make sure that your device
is quirked appropriately.

Scott
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: fork wedging (I think)

[Daniel O'Connor]

On Tuesday 06 March 2007 05:04, Peter Jeremy wrote:
> How difficult would it be to build a test system somewhere where the
> console was accessible?  I don't think you are going to make progress
> without console access.

Not possible, I can't move the system as it is very remote and there are no 
(clueful) local people.

We may be going up their on other business but Murphy dictates the problem 
wouldn't surface while we were :)

I haven't been able to replicate the problem here either.

Would a crash dump be useful? I think I will be able to update the ataraid 
stuff to allow a dump onto the array.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


pgp4AlpDkHPcA.pgp
Description: PGP signature

Re: Portaudit

[Sergey N. Voronkov]

On Mon, Mar 05, 2007 at 01:55:50PM +0100, Stephane Thomas wrote:
> Hello,
> 
> I just installed portaudit and now I cannot build mozilla anymore because of
> three vulnerabilities. Is there a way to force building of a port even if
> there are knows vulnerabilities ? I guess I can add some portaudit_fixed=
> lines in /usr/local/etc/portaudit.conf but as the vulnerabilities aren't
> really fixed I'm not sure this is the right thing to do.
> 
> I read portaudit's man and freebsd handbook but I can't figure out the good
> method. Thx in advance.

Try to build seamonkey - it is mozilla replacement...

Serg.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Boot prompt for Intel AMT

[Charles Sprickman]

On Mon, 5 Mar 2007, Jeremy Chadwick wrote:


On Tue, Mar 06, 2007 at 12:15:04AM +0300, Artem Kuchin wrote:

The othe question, is there such technology for Supermicro mainboards?


Yes, Supermicro makes IPMI add-on cards (they require IPMI capability on
the mainboard, however).

Be warned about these cards, however.  A friend of mine at Yahoo!  has
encountered a major BIOS/IPMI oversight, where in the case that the IPMI
event log becomes full, the system BIOS upon boot will _require_ someone
hit F1 to continue on the console, until the IPMI history is cleared.
Ultimately this requires someone to go to the datacenter and manually
hit F1 on the console, clear the IPMI log, and let the machine boot up.
Wonderful oversight.


I might also add that we tried that on a few Supermicro boxes and found 
the whole mess to be not as reliable as you'd like an OOB management tool 
to be.  The java client is spotty at best, really wants to be run in 
Windows, and basically falls apart when doing simple console redirection 
in the client.  Never really saw it work well.



Now it seems more and more problems are coming to light with vendor IPMI
implementations (Broadcom's pseudo-iLO causes ARP storms because there
is no dedicated NIC for iLO and the NIC technically has two MAC
addresses, Supermicro's IPMI and the event log problem, yadda yadda.)


Yeah, I was a little disappointed in this - when I read about IPMI I 
thought that it was something of a standard and that I'd be able to pick 
and choose clients that run natively on FreeBSD or OS-X.  That does not 
seem to be the case at all.



Seems to me the only vendors who got this right were 1) HP/Compaq with
their true iLO/iLO2, and 2) Sun.


Which is a shame as the Supermicro cards were sub-$100...

Charles


--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networkinghttp://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, USA |
| Making life hard for others since 1977.   PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: PATCH : ARP problem with 6.2-STABLE Intel PRO/1000 NIC, latest em driver

[Mark Costlow]

On Mon, Mar 05, 2007 at 02:13:36PM -0800, Jack Vogel wrote:
[...snip...]
> >>
> >> Don't bother installing CURRENT, just got out of my meeting and I found
> >> out what the problem is. There is indeed an issue with management, and
> >> its something our test group isnt set up to test. I will send a patch to
> >> try sometime before end of day.
> 
> OK, here is the patch, this should fix it...

Hi Jack, the patch didn't seem to have any effect.  When I run "tcpdump -n arp"
after rebooting with this patch, I still see 2-3 ARPs per minute instead of
100-200 per minute.

I was patching against:
/*$FreeBSD: src/sys/dev/em/if_em.c,v 1.65.2.22 2007/03/01 17:32:27 csjp Exp $*/

Is that correct?

I tried both SMP and non-SMP kernels, with same results.  Is there
anything I can do to gather some additional debug information from the
system while it's running?

I neglected to mention before the specific motherboard model:
Supermicro X7DVL-E.  There is no IPMI card installed, and no
IPMI setting in the BIOS.

Thanks,

Mark
-- 
Mark Costlow| Southwest Cyberport | Fax:   +1-505-232-7975
[EMAIL PROTECTED] | Web:   www.swcp.com | Voice: +1-505-232-7992

abq-strange.com -- Interesting photos taken in Albuquerque, NM
   Last post: Art Is OK...And Dangerous - 2007-03-02 10:27:17

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

umass media size off-by-one?

[Craig Boston]

Hi all, I ran into this while trying to use geli to encrypt an external
usb-2 hard drive.  It appears that sometimes the media size reported by
umass is one sector too big.  For example:

umass0: Prolific Technology Inc. Mass Storage Device, rev 2.00/1.00, addr 2
da0 at umass-sim0 bus 0 target 0 lun 0
da0:  Fixed Direct Access SCSI-0 device 
da0: 40.000MB/s transfers
da0: 171705MB (351651889 512 byte sectors: 255H 63S/T 21889C)

# dd if=/dev/zero of=/dev/da0 oseek=351651888 count=1
dd: /dev/da0: Input/output error
1+0 records in
0+0 records out
0 bytes transferred in 0.002951 secs (0 bytes/sec)

# dd if=/dev/zero of=/dev/da0 oseek=351651887 count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.000982 secs (521360 bytes/sec)

This is with a "high speed, power 100 mA, config 1, Mass Storage
Device(0x3507), Prolific Technology Inc.(0x067b), rev 1.00" enclosure.
I tested with two USB flash memory devices and those seem to report the
correct size.

I'm currently rebuilding a kernel with USB_DEBUG to see if it's specific
to a certain protocol and try to figure out if it's a bug in one of them
or if the enclosure is lying.  Has anyone run into this before?

Craig
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Boot prompt for Intel AMT

[Jeremy Chadwick]

On Tue, Mar 06, 2007 at 12:15:04AM +0300, Artem Kuchin wrote:
> The othe question, is there such technology for Supermicro mainboards?

Yes, Supermicro makes IPMI add-on cards (they require IPMI capability on
the mainboard, however).

Be warned about these cards, however.  A friend of mine at Yahoo!  has
encountered a major BIOS/IPMI oversight, where in the case that the IPMI
event log becomes full, the system BIOS upon boot will _require_ someone
hit F1 to continue on the console, until the IPMI history is cleared.
Ultimately this requires someone to go to the datacenter and manually
hit F1 on the console, clear the IPMI log, and let the machine boot up.
Wonderful oversight.

Yes, there are IPMI management utilities for some OSes, but many of them
are closed-source, only work on certain versions of the OS, or for the
open-source ones do not let you control/monitor as much as you would
under the native utility from the vendor.

Now it seems more and more problems are coming to light with vendor IPMI
implementations (Broadcom's pseudo-iLO causes ARP storms because there
is no dedicated NIC for iLO and the NIC technically has two MAC
addresses, Supermicro's IPMI and the event log problem, yadda yadda.)

Seems to me the only vendors who got this right were 1) HP/Compaq with
their true iLO/iLO2, and 2) Sun.

-- 
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networkinghttp://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, USA |
| Making life hard for others since 1977.   PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Boot prompt for Intel AMT

[Steven Hartland]

Artem Kuchin wrote:

I hope some people will understand what  i am talking about, because
the technology, i think, is not very popular, but can come VERY handy.

...

The othe question, is there such technology for Supermicro mainboards?


You might want to checkout the IPMI modules from Supermicro.

   Steve



This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to [EMAIL PROTECTED]

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Boot prompt for Intel AMT

[Jack Vogel]

On 3/5/07, Artem Kuchin <[EMAIL PROTECTED]> wrote:

Hello!

I hope some people will understand what  i am talking about, because
the technology, i think, is not very popular, but can come VERY handy.

Intel AMT Serial over LAN (SOL, why is it called 'over LAN' if it is really
'OVER IP'?) allows to boot into BIOS of a remote machine
and even, as seen in their demo, can be used to control MS DOS prompt.


well because it isnt using IP, besides SOIP is uninspiring :)


However, i tried it and did not see any boot prompt over SOL connection.
As i understand it does not use bios for input/output and therefore data is
not sent/received over SOL connection. Thisis a pitty because of boot prompt
would work over SOL then remote source upgrade would be much plainless
and less risky than now. For example, i could just book old kernel if something
goes wrong.

Is there a way to make boot prompt work over SOL?

The othe question, is there such technology for Supermicro mainboards?


It doesnt work the way you think it works, its not just some serial port
that spits ASCII characters, rather I believe it requires you to speak
IPMI to it.

Of course, if you happen to have an IBM Bladecenter, then it does just
look like a serial port on the blade, but you still have to deal with the
management controller stuff on the incoming side.

After you deal with all this stuff for a while you will LONG for the good
old days of a simple UART :)

Cheers,

Jack
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

PATCH : ARP problem with 6.2-STABLE Intel PRO/1000 NIC, latest em driver

[Jack Vogel]

On 3/5/07, Mark Costlow <[EMAIL PROTECTED]> wrote:

On Mon, Mar 05, 2007 at 10:02:26AM -0800, Jack Vogel wrote:
> On 3/5/07, Jack Vogel <[EMAIL PROTECTED]> wrote:
> >On 3/5/07, Mark Costlow <[EMAIL PROTECTED]> wrote:
> >> On Mon, Mar 05, 2007 at 08:41:01AM -0800, Jack Vogel wrote:
> >> > >
> >> > >Maybe more of your dmesg might help as it could show interrrupt issues
> >> > >that perhaps others could help diagnose
> >> >
> >> > Yes, agreed, this might be revealing.
> >>
> >> Here's the full dmesg.  Thanks for looking at this.
> >>
> >> 
> >> Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation.
> >> FreeBSD 6.2-STABLE #0: Sun Mar  4 22:40:38 MST 2007
> >> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
> >> ACPI APIC Table: 
> >> Timecounter "i8254" frequency 1193182 Hz quality 0
> >> CPU: Intel(R) Xeon(R) CPU5130  @ 2.00GHz (2000.08-MHz
> >686-class CPU)
> >>   Origin = "GenuineIntel"  Id = 0x6f6  Stepping = 6
> >>
> 
>Features=0xbfebfbff >> MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> >>
> >Features2=0x4e33d,CX16,,,>
> >>   AMD Features=0x2000
> >>   AMD Features2=0x1
> >>   Cores per package: 2
> >> real memory  = 3489005568 (3327 MB)
> >> avail memory = 3414384640 (3256 MB)
> >> ioapic0  irqs 0-23 on motherboard
> >> ioapic1  irqs 24-47 on motherboard
> >> kbd1 at kbdmux0
> >> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413,
> >RF5413)
> >> acpi0:  on motherboard
> >> acpi0: Power Button (fixed)
> >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
> >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
> >> cpu0:  on acpi0
> >> acpi_throttle0:  on cpu0
> >> pcib0:  port 0xcf8-0xcff on acpi0
> >> pci0:  on pcib0
> >> pcib1:  at device 2.0 on pci0
> >> pci1:  on pcib1
> >> pcib2:  irq 16 at device 0.0 on pci1
> >> pci2:  on pcib2
> >> pcib3:  irq 16 at device 0.0 on pci2
> >> pci3:  on pcib3
> >> pcib4:  irq 18 at device 2.0 on pci2
> >> pci4:  on pcib4
> >> em0:  port
> >0x2000-0x201f m
> >> em 0xda00-0xda01 irq 18 at device 0.0 on pci4
> >> em0: Ethernet address: 00:30:48:8c:71:54
> >> em1:  port
> >0x2020-0x203f m
> >> em 0xda02-0xda03 irq 19 at device 0.1 on pci4
> >> em1: Ethernet address: 00:30:48:8c:71:55
> >> pcib5:  at device 0.3 on pci1
> >> pci5:  on pcib5
> >> 3ware device driver for 9000 series storage controllers, version:
> >3.60.02.012
> >> twa0: <3ware 9000 series Storage Controller> port 0x3000-0x303f mem
> >0xd800-0
> >> xd9ff,0xda10-0xda100fff irq 24 at device 1.0 on pci5
> >> twa0: [GIANT-LOCKED]
> >> twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-4LP, 4
> >ports, Firm
> >> ware FE9X 3.04.01.011, BIOS BE9X 3.04.00.002
> >> pci0:  at device 8.0 (no driver attached)
> >> pcib6:  irq 17 at device 28.0 on pci0
> >> pci6:  on pcib6
> >> uhci0:  port 0x1800-0x181f irq 17 at
> >device 29.0
> >> on pci0
> >> uhci0: [GIANT-LOCKED]
> >> usb0:  on uhci0
> >> usb0: USB revision 1.0
> >> uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> >> uhub0: 2 ports with 2 removable, self powered
> >> uhci1:  port 0x1820-0x183f irq 19 at
> >device 29.1
> >> on pci0
> >> uhci1: [GIANT-LOCKED]
> >> usb1:  on uhci1
> >> usb1: USB revision 1.0
> >> uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> >> uhub1: 2 ports with 2 removable, self powered
> >> uhci2:  port 0x1840-0x185f irq 18 at
> >device 29.2
> >> on pci0
> >> uhci2: [GIANT-LOCKED]
> >> usb2:  on uhci2
> >> usb2: USB revision 1.0
> >> uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> >> uhub2: 2 ports with 2 removable, self powered
> >> uhci3:  port 0x1860-0x187f irq 16 at
> >device 29.3
> >> on pci0
> >> uhci3: [GIANT-LOCKED]
> >> usb3:  on uhci3
> >> usb3: USB revision 1.0
> >> uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> >> uhub3: 2 ports with 2 removable, self powered
> >> ehci0:  mem 0xda60-0xda6003ff irq
> >17 at d
> >> evice 29.7 on pci0
> >> ehci0: [GIANT-LOCKED]
> >> usb4: EHCI version 1.0
> >> usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
> >> usb4:  on ehci0
> >> usb4: USB revision 2.0
> >> uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
> >> uhub4: 8 ports with 8 removable, self powered
> >> pcib7:  at device 30.0 on pci0
> >> pci7:  on pcib7
> >> pci7:  at device 1.0 (no driver attached)
> >> isab0:  at device 31.0 on pci0
> >> isa0:  on isab0
> >> atapci0:  port
> >0x1f0-0x1f7,0x3f6,0x170-0x177,
> >> 0x376,0x1880-0x188f at device 31.1 on pci0
> >> ata0:  on atapci0
> >> ata1:  on atapci0
> >> pci0:  at device 31.3 (no driver attached)
> >> acpi_button0:  on acpi0
> >> atkbdc0:  port 0x60,0x64 irq 1 on acpi0
> >> atkbd0:  irq 1 on atkbdc0
> >> kbd0 at atkbd0
> >> atkbd0: [GIANT-LOCKED

Boot prompt for Intel AMT

[Artem Kuchin]

Hello!

I hope some people will understand what  i am talking about, because
the technology, i think, is not very popular, but can come VERY handy.

Intel AMT Serial over LAN (SOL, why is it called 'over LAN' if it is really
'OVER IP'?) allows to boot into BIOS of a remote machine
and even, as seen in their demo, can be used to control MS DOS prompt.

However, i tried it and did not see any boot prompt over SOL connection.
As i understand it does not use bios for input/output and therefore data is
not sent/received over SOL connection. Thisis a pitty because of boot prompt
would work over SOL then remote source upgrade would be much plainless
and less risky than now. For example, i could just book old kernel if something
goes wrong.

Is there a way to make boot prompt work over SOL?

The othe question, is there such technology for Supermicro mainboards?

--
Regards,
Artem
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up

[Scott Long]

Kostik Belousov wrote:

On Mon, Mar 05, 2007 at 10:17:14PM +0300, Yar Tikhiy wrote:

On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote:

On Monday 05 March 2007 08:23, Yar Tikhiy wrote:
= > How will it break them?  swap backing only touches swap if there is
= > memory pressure, i.e. precisely the situation in which malloc backing
= > will panic.
= 
= I forgot that in BSD swap wouldn't be allocated in advance to its

= consumers.  Then removing the -M flag and making swap backing the
= default is a very sound choice.  Thank you for correcting me.

Yar, would you change the man-page's advice and the default, then?

Yes, I'll be glad to if no objections arise until I finish updating
my CURRENT machine, i.e., tomorrow. :-)


Someone still needs to look into the panic... Who would that be?

Obviously, Mr(s). Someone. :-)

The md case exposes a quite tangled nature of the problem.  Funnily
enough, kernel malloc() cannot just fail in the case because it
must not fail if called with M_WAITOK.  This means that the system
has quite a rough choice:

- put the requesting thread to sleep forever;
- grow kmem_map, eventually sacrifice all RAM to the greedy thread
  and die sooner or later;
- panic immediately.

If all malloc() callers in the kernel were ready to deal with
allocation failure, the system could just tell the greedy thread
to buzz off.  But too many kernel parts depend on malloc(M_WAITOK)
never failing.  Perhaps it's the root of the problem.


Mark callers that are ready for M_WAITOK failure with some additional
flag, like M_FAILOK (feel free to propose meaningful name there).
At least malloc()-based md could then use it.


The panic is a chronic problem that really needs to be fixed in general.
However, the md code should probably be modified to reject any 
malloc-backed size larger than some trivial (and arbitrary) value, like 
say 1MB.  It's really inferior to being swap-backed, and it only 
encourages foot-shooting and these unclear panics.


Scott

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up

[Yar Tikhiy]

On Mon, Mar 05, 2007 at 09:30:22PM +0200, Kostik Belousov wrote:
> On Mon, Mar 05, 2007 at 10:17:14PM +0300, Yar Tikhiy wrote:
> > On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote:
> > > On Monday 05 March 2007 08:23, Yar Tikhiy wrote:
> > > = > How will it break them?  swap backing only touches swap if there is
> > > = > memory pressure, i.e. precisely the situation in which malloc backing
> > > = > will panic.
> > > = 
> > > = I forgot that in BSD swap wouldn't be allocated in advance to its
> > > = consumers.  Then removing the -M flag and making swap backing the
> > > = default is a very sound choice.  Thank you for correcting me.
> > > 
> > > Yar, would you change the man-page's advice and the default, then?
> > 
> > Yes, I'll be glad to if no objections arise until I finish updating
> > my CURRENT machine, i.e., tomorrow. :-)
> > 
> > > Someone still needs to look into the panic... Who would that be?
> > 
> > Obviously, Mr(s). Someone. :-)
> > 
> > The md case exposes a quite tangled nature of the problem.  Funnily
> > enough, kernel malloc() cannot just fail in the case because it
> > must not fail if called with M_WAITOK.  This means that the system
> > has quite a rough choice:
> > 
> > - put the requesting thread to sleep forever;
> > - grow kmem_map, eventually sacrifice all RAM to the greedy thread
> >   and die sooner or later;
> > - panic immediately.
> > 
> > If all malloc() callers in the kernel were ready to deal with
> > allocation failure, the system could just tell the greedy thread
> > to buzz off.  But too many kernel parts depend on malloc(M_WAITOK)
> > never failing.  Perhaps it's the root of the problem.
> 
> Mark callers that are ready for M_WAITOK failure with some additional
> flag, like M_FAILOK (feel free to propose meaningful name there).
> At least malloc()-based md could then use it.

The problem isn't that we don't have such a flag yet.  It's that
some parts of the kernel would rather we didn't have it. :-)  Of
course, introducing the flag or changing semantics of malloc() in
a similar way is a necessary start.

-- 
Yar
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up

[Kostik Belousov]

On Mon, Mar 05, 2007 at 10:17:14PM +0300, Yar Tikhiy wrote:
> On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote:
> > On Monday 05 March 2007 08:23, Yar Tikhiy wrote:
> > = > How will it break them?  swap backing only touches swap if there is
> > = > memory pressure, i.e. precisely the situation in which malloc backing
> > = > will panic.
> > = 
> > = I forgot that in BSD swap wouldn't be allocated in advance to its
> > = consumers.  Then removing the -M flag and making swap backing the
> > = default is a very sound choice.  Thank you for correcting me.
> > 
> > Yar, would you change the man-page's advice and the default, then?
> 
> Yes, I'll be glad to if no objections arise until I finish updating
> my CURRENT machine, i.e., tomorrow. :-)
> 
> > Someone still needs to look into the panic... Who would that be?
> 
> Obviously, Mr(s). Someone. :-)
> 
> The md case exposes a quite tangled nature of the problem.  Funnily
> enough, kernel malloc() cannot just fail in the case because it
> must not fail if called with M_WAITOK.  This means that the system
> has quite a rough choice:
> 
> - put the requesting thread to sleep forever;
> - grow kmem_map, eventually sacrifice all RAM to the greedy thread
>   and die sooner or later;
> - panic immediately.
> 
> If all malloc() callers in the kernel were ready to deal with
> allocation failure, the system could just tell the greedy thread
> to buzz off.  But too many kernel parts depend on malloc(M_WAITOK)
> never failing.  Perhaps it's the root of the problem.

Mark callers that are ready for M_WAITOK failure with some additional
flag, like M_FAILOK (feel free to propose meaningful name there).
At least malloc()-based md could then use it.


pgp7l3bai5KMT.pgp
Description: PGP signature

Re: 'panic: bad pte' error on 6.2-RELEASE (amd64)

[Kostik Belousov]

On Mon, Mar 05, 2007 at 06:28:30PM +, Gavin Atkinson wrote:
> On Mon, 5 Mar 2007, Kostik Belousov wrote:
> 
> >On Mon, Mar 05, 2007 at 12:05:32AM -0800, Peter Losher wrote:
> >>We recently updated one of our dual Opteron systems (w/ 4GB RAM) from
> >>5.5 to 6.2 (amd64 wipe and reinstalled) and about once a week, it panics
> >>with the below message:
> >>
> >>-=-
> >>TPTE at 0x840028a0  IS ZERO @ VA 800514000
> >>panic: bad pte
> >>cpuid = 2
> >>KDB: stack backtrace:
> >>panic() at 0x803fdd03 = panic+0x253
> >>pmap_remove_pages() at 0x806072a3 = pmap_remove_pages+0x283
> >>exec_new_vmspace() at 0x803e18e6 = exec_new_vmspace+0x216
> >>exec_elf64_imgact() at 0x803cbb73 = exec_elf64_imgact+0x273
> >>kern_execve() at 0x803e2107 = kern_execve+0x457
> >>execve() at 0x803e2bed = execve+0x5d
> >>syscall() at 0x8060d141 = syscall+0x4d1
> >>Xfast_syscall() at 0x805f8128 = Xfast_syscall+0xa8
> >>--- syscall (59, FreeBSD ELF64, execve), rip = 0x80069838c, rsp =
> >>0x7fffe7c8, rbp = 0x7fffecd0 ---
> >>Uptime: 4d16h55m46s
> >>-=-
> >>
> >>I do have a dump, and can make that available if need be.  Has anyone
> >>encountered this recently and can shed any light on what might be
> >>causing this?
> >
> >Did rev. 1.516.2.9 of sys/amd64/amd64/pmap.c changed (or even fixed) the
> >problem ? (This is the same patch I already sent you).
> 
> Do you know if this patch is likely to fix the other "bad pte" panics that 
> have been seen (usually during process exit())?  e.g.
> 
> http://docs.freebsd.org/cgi/mid.cgi?1148482556.35287.18.camel
> http://lists.freebsd.org/pipermail/freebsd-current/2004-August/034909.html
Yes, the problem there seems to be fixed by Tor' commit into the i386/pmap.c
at the 2006/02/16. My commit is MFi386 of the fix to the amd64.

> I have a couple of amd64 machines I'm reluctant to make live until this is 
> sorted...  I'll cvsup in the next day or two to see, although it wasn't 
> consistantly reproduceable.
I am interested in testing results.


pgpM4QJ0xYFHJ.pgp
Description: PGP signature

Re: Very slow umass in 6.2-RC2

[Kevin Oberman]

> Date: Thu, 22 Feb 2007 10:45:03 +0100 (CET)
> From: Oliver Fromme <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
> 
> Alexander Shikoff wrote:
>  > Oliver Fromme wrote:
>  > > Alexander Shikoff wrote:
>  > > > Wang Yi wrote:
>  > > > > Alexander Shikoff wrote:
>  > > > > > I have Apacer Flash:
>  > > > > > 
>  > > > > > umass0: vendor 0x1005 USB FLASH DRIVE, rev 2.00/1.00, addr 2
>  > > > > > da0 at umass-sim0 bus 0 target 0 lun 0
>  > > > > > da0: < USB FLASH DRIVE 34CH> Removable Direct Access SCSI-0 device
>  > > > > > da0: 40.000MB/s transfers
>  > > > > > da0: 3936MB (8060928 512 byte sectors: 255H 63S/T 501C)
>  > > > > > 
>  > > > > > Writing to this device is very slow.
>  > > > > > 
>  > > > > > Time taken to copy file of 1,4G is near 30 min.
>  > > > > 
>  > > > > Did you try it under Windows? How time does it spend?
>  > > > 
>  > > > You may laugh but I have no Windows-based boxes with USB 2.0... :)
>  > > > Whatever it seems that this Apacer flash drive under Windows and USB 
> 1.0 
>  > > > is faster than under FreeBSD and USB 2.0...
>  > > > 
>  > > > Soon I will have a possibility to compare Apacer 4GB with Transcend 
>  > > > flash. I'll report detailed results here.
>  > > 
>  > > Are you sure that your USB device supports hi-speed?
>  > http://www.apacer.com/en/products/Handy_Steno_AH320_features.htm
> 
> And is it connected to your ehci device (not ohci/uhci)?
> (To find out you have to look at "dmesg" an "sysctl dev".)
> 
> E.g. I have this one:
> 
> umass0: vendor 0x090c Cn Memory, rev 2.00/11.00, addr 2
> da0 at umass-sim0 bus 0 target 0 lun 0
> da0: < Cn Memory 1100> Removable Direct Access SCSI-0 device
> da0: 40.000MB/s transfers
> da0: 1935MB (3963904 512 byte sectors: 255H 63S/T 246C)
> 
> dev.umass.0.%parent: uhub4
> dev.uhub.4.%parent: usb4
> 
> usb4: EHCI version 1.0
> usb4:  on ehci0
> uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
> ehci0:  mem 0xb004-0xb00403ff 
> irq 23 at device 29.7 on pci0
> 
> i.e. umass0 is connected to uhub4 which is a child of usb4
> which belongs to ehci0.
> 
> That stick has about 20 Mbit/s write and 30 Mbit/s read
> speed.  That's not terribly fast either, but definitely
> beyond the 12 Mbit/s limit of full-speed devices.  I can
> fill that 2 GB stick up in about 15 minutes.  The system
> CPU is 95% during that, so I assume it's the USB stick
> that's the limiting factor.
> 
> However, it would be interesting to test the performance
> with HPS' new USB code.

Well, I have learned a bit more about the performance I have been
seeing. Whether it is common to Alexander's problem, I can't say, but I
am suspicious.

First, my devices that were running so slow are formatted as FAT32. This
is most common for such devices, but I am not sure if that is the case
for all reported systems.

After batting against a wall for a time I tried running fsck_msdosfs on
the slice. After running it my transfer rate went from about .2 MB/sec
to about 17 MB/sec. It moved the drive from useless for files of any
size to at least reasonable to use. Oddly, fsck_msdosfs reported no
errors. Also, oddly, the writes before running fsck were all successful
and the drive worked fine. 

Under Windows, the drive was fine before the fsck, so something was
seriously upsetting FreeBSD that did not impact Windows.

In any case, my drive is happy again.

USB drives are often disconnected while mounted and so this may turn out
to be a very common issue. Since FAT drives are not "marked" as unclean
like FFS systems, this is easy to over-look.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


pgpOzuQeFBCWB.pgp
Description: PGP signature

Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up

[Yar Tikhiy]

On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote:
> On Monday 05 March 2007 08:23, Yar Tikhiy wrote:
> = > How will it break them?  swap backing only touches swap if there is
> = > memory pressure, i.e. precisely the situation in which malloc backing
> = > will panic.
> = 
> = I forgot that in BSD swap wouldn't be allocated in advance to its
> = consumers.  Then removing the -M flag and making swap backing the
> = default is a very sound choice.  Thank you for correcting me.
> 
> Yar, would you change the man-page's advice and the default, then?

Yes, I'll be glad to if no objections arise until I finish updating
my CURRENT machine, i.e., tomorrow. :-)

> Someone still needs to look into the panic... Who would that be?

Obviously, Mr(s). Someone. :-)

The md case exposes a quite tangled nature of the problem.  Funnily
enough, kernel malloc() cannot just fail in the case because it
must not fail if called with M_WAITOK.  This means that the system
has quite a rough choice:

- put the requesting thread to sleep forever;
- grow kmem_map, eventually sacrifice all RAM to the greedy thread
  and die sooner or later;
- panic immediately.

If all malloc() callers in the kernel were ready to deal with
allocation failure, the system could just tell the greedy thread
to buzz off.  But too many kernel parts depend on malloc(M_WAITOK)
never failing.  Perhaps it's the root of the problem.

-- 
Yar
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 'panic: bad pte' error on 6.2-RELEASE (amd64)

[Gavin Atkinson]

On Mon, 5 Mar 2007, Kostik Belousov wrote:


On Mon, Mar 05, 2007 at 12:05:32AM -0800, Peter Losher wrote:

We recently updated one of our dual Opteron systems (w/ 4GB RAM) from
5.5 to 6.2 (amd64 wipe and reinstalled) and about once a week, it panics
with the below message:

-=-
TPTE at 0x840028a0  IS ZERO @ VA 800514000
panic: bad pte
cpuid = 2
KDB: stack backtrace:
panic() at 0x803fdd03 = panic+0x253
pmap_remove_pages() at 0x806072a3 = pmap_remove_pages+0x283
exec_new_vmspace() at 0x803e18e6 = exec_new_vmspace+0x216
exec_elf64_imgact() at 0x803cbb73 = exec_elf64_imgact+0x273
kern_execve() at 0x803e2107 = kern_execve+0x457
execve() at 0x803e2bed = execve+0x5d
syscall() at 0x8060d141 = syscall+0x4d1
Xfast_syscall() at 0x805f8128 = Xfast_syscall+0xa8
--- syscall (59, FreeBSD ELF64, execve), rip = 0x80069838c, rsp =
0x7fffe7c8, rbp = 0x7fffecd0 ---
Uptime: 4d16h55m46s
-=-

I do have a dump, and can make that available if need be.  Has anyone
encountered this recently and can shed any light on what might be
causing this?


Did rev. 1.516.2.9 of sys/amd64/amd64/pmap.c changed (or even fixed) the
problem ? (This is the same patch I already sent you).


Do you know if this patch is likely to fix the other "bad pte" panics that 
have been seen (usually during process exit())?  e.g.


http://docs.freebsd.org/cgi/mid.cgi?1148482556.35287.18.camel
http://lists.freebsd.org/pipermail/freebsd-current/2004-August/034909.html

I have a couple of amd64 machines I'm reluctant to make live until this is 
sorted...  I'll cvsup in the next day or two to see, although it wasn't 
consistantly reproduceable.


Thanks,

Gavin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ARP problem with 6.2-STABLE Intel PRO/1000 NIC, latest em driver

[Mark Costlow]

On Mon, Mar 05, 2007 at 10:02:26AM -0800, Jack Vogel wrote:
> On 3/5/07, Jack Vogel <[EMAIL PROTECTED]> wrote:
> >On 3/5/07, Mark Costlow <[EMAIL PROTECTED]> wrote:
> >> On Mon, Mar 05, 2007 at 08:41:01AM -0800, Jack Vogel wrote:
> >> > >
> >> > >Maybe more of your dmesg might help as it could show interrrupt issues
> >> > >that perhaps others could help diagnose
> >> >
> >> > Yes, agreed, this might be revealing.
> >>
> >> Here's the full dmesg.  Thanks for looking at this.
> >>
> >> 
> >> Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation.
> >> FreeBSD 6.2-STABLE #0: Sun Mar  4 22:40:38 MST 2007
> >> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
> >> ACPI APIC Table: 
> >> Timecounter "i8254" frequency 1193182 Hz quality 0
> >> CPU: Intel(R) Xeon(R) CPU5130  @ 2.00GHz (2000.08-MHz 
> >686-class CPU)
> >>   Origin = "GenuineIntel"  Id = 0x6f6  Stepping = 6
> >>   
> >Features=0xbfebfbff >> MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> >>   
> >Features2=0x4e33d,CX16,,,>
> >>   AMD Features=0x2000
> >>   AMD Features2=0x1
> >>   Cores per package: 2
> >> real memory  = 3489005568 (3327 MB)
> >> avail memory = 3414384640 (3256 MB)
> >> ioapic0  irqs 0-23 on motherboard
> >> ioapic1  irqs 24-47 on motherboard
> >> kbd1 at kbdmux0
> >> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, 
> >RF5413)
> >> acpi0:  on motherboard
> >> acpi0: Power Button (fixed)
> >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
> >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
> >> cpu0:  on acpi0
> >> acpi_throttle0:  on cpu0
> >> pcib0:  port 0xcf8-0xcff on acpi0
> >> pci0:  on pcib0
> >> pcib1:  at device 2.0 on pci0
> >> pci1:  on pcib1
> >> pcib2:  irq 16 at device 0.0 on pci1
> >> pci2:  on pcib2
> >> pcib3:  irq 16 at device 0.0 on pci2
> >> pci3:  on pcib3
> >> pcib4:  irq 18 at device 2.0 on pci2
> >> pci4:  on pcib4
> >> em0:  port 
> >0x2000-0x201f m
> >> em 0xda00-0xda01 irq 18 at device 0.0 on pci4
> >> em0: Ethernet address: 00:30:48:8c:71:54
> >> em1:  port 
> >0x2020-0x203f m
> >> em 0xda02-0xda03 irq 19 at device 0.1 on pci4
> >> em1: Ethernet address: 00:30:48:8c:71:55
> >> pcib5:  at device 0.3 on pci1
> >> pci5:  on pcib5
> >> 3ware device driver for 9000 series storage controllers, version: 
> >3.60.02.012
> >> twa0: <3ware 9000 series Storage Controller> port 0x3000-0x303f mem 
> >0xd800-0
> >> xd9ff,0xda10-0xda100fff irq 24 at device 1.0 on pci5
> >> twa0: [GIANT-LOCKED]
> >> twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-4LP, 4 
> >ports, Firm
> >> ware FE9X 3.04.01.011, BIOS BE9X 3.04.00.002
> >> pci0:  at device 8.0 (no driver attached)
> >> pcib6:  irq 17 at device 28.0 on pci0
> >> pci6:  on pcib6
> >> uhci0:  port 0x1800-0x181f irq 17 at 
> >device 29.0
> >> on pci0
> >> uhci0: [GIANT-LOCKED]
> >> usb0:  on uhci0
> >> usb0: USB revision 1.0
> >> uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> >> uhub0: 2 ports with 2 removable, self powered
> >> uhci1:  port 0x1820-0x183f irq 19 at 
> >device 29.1
> >> on pci0
> >> uhci1: [GIANT-LOCKED]
> >> usb1:  on uhci1
> >> usb1: USB revision 1.0
> >> uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> >> uhub1: 2 ports with 2 removable, self powered
> >> uhci2:  port 0x1840-0x185f irq 18 at 
> >device 29.2
> >> on pci0
> >> uhci2: [GIANT-LOCKED]
> >> usb2:  on uhci2
> >> usb2: USB revision 1.0
> >> uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> >> uhub2: 2 ports with 2 removable, self powered
> >> uhci3:  port 0x1860-0x187f irq 16 at 
> >device 29.3
> >> on pci0
> >> uhci3: [GIANT-LOCKED]
> >> usb3:  on uhci3
> >> usb3: USB revision 1.0
> >> uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> >> uhub3: 2 ports with 2 removable, self powered
> >> ehci0:  mem 0xda60-0xda6003ff irq 
> >17 at d
> >> evice 29.7 on pci0
> >> ehci0: [GIANT-LOCKED]
> >> usb4: EHCI version 1.0
> >> usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
> >> usb4:  on ehci0
> >> usb4: USB revision 2.0
> >> uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
> >> uhub4: 8 ports with 8 removable, self powered
> >> pcib7:  at device 30.0 on pci0
> >> pci7:  on pcib7
> >> pci7:  at device 1.0 (no driver attached)
> >> isab0:  at device 31.0 on pci0
> >> isa0:  on isab0
> >> atapci0:  port 
> >0x1f0-0x1f7,0x3f6,0x170-0x177,
> >> 0x376,0x1880-0x188f at device 31.1 on pci0
> >> ata0:  on atapci0
> >> ata1:  on atapci0
> >> pci0:  at device 31.3 (no driver attached)
> >> acpi_button0:  on acpi0
> >> atkbdc0:  port 0x60,0x64 irq 1 on acpi0
> >> atkbd0:  irq 1 on atkbdc0
> >> kbd0 at atkbd0
> >> atkbd0: [GIANT-LOCKED]
> >> psm0:  irq 12 on atkbdc0
> >

Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up

[Mikhail Teterin]

On Monday 05 March 2007 08:23, Yar Tikhiy wrote:
= > How will it break them?  swap backing only touches swap if there is
= > memory pressure, i.e. precisely the situation in which malloc backing
= > will panic.
= 
= I forgot that in BSD swap wouldn't be allocated in advance to its
= consumers.  Then removing the -M flag and making swap backing the
= default is a very sound choice.  Thank you for correcting me.

Yar, would you change the man-page's advice and the default, then?

Someone still needs to look into the panic... Who would that be?

-mi
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: fork wedging (I think)

[Peter Jeremy]

On 2007-Mar-05 11:36:41 +1030, Daniel O'Connor <[EMAIL PROTECTED]> wrote:
>I was incrementally dumping sysctl trees and when I got to vm it hung..
>
>eureka:~>sysctl vm
>load: 0.07  cmd: sysctl 72864 [user map] 0.00u 0.00s 0% 852k
>load: 0.07  cmd: sysctl 72864 [user map] 0.00u 0.00s 0% 852k
>load: 0.07  cmd: sysctl 72864 [user map] 0.00u 0.00s 0% 852k
>load: 0.05  cmd: sysctl 72864 [user map] 0.00u 0.00s 0% 852k
>
>I tried to reboot in another window but..
>eureka:~>reboot
>load: 0.06  cmd: csh 71159 [allproc] 0.03u 0.00s 0% 4652k

The fact that reboot eventually came back shows that the system is not
deadlocked.  "user map" and "allproc" refer to the wait channel names.
"user map" is not very helpful to me (it's the lock associated with a
class of vm maps and tracking where it's waited on is not easy).
"allproc" refers to allproc_lock.

The output from "vmstat -i" would be interesting, though it may not
respond...

How difficult would it be to build a test system somewhere where the
console was accessible?  I don't think you are going to make progress
without console access.

-- 
Peter Jeremy


pgpDLePiwDGc9.pgp
Description: PGP signature

Re: Can't get sound to work!

[Vince]

Karl Denninger wrote:
> Tried to apply that, and got a mess.
> 
> Did you put that on RELENG_6 cleanly?  It drops a bunch of files in the top
> level SRC directory (NOT under /sys!) if applied against /usr/src; it
> appears to apply cleanly but a kernel build subsequent to that fails.
> 
> --
Actually i just checked properly and thats a newer patch than the one i
had been using (i switched to current on a whim and havent switched back
yet) The command i was using to apply the previous version was
"patch -d /usr/src -p0 <
/root/src/snd_RELENG_6_20070111_139_lowlatency.diff"
(excuse line wrap)
which worked fine against a clean cvsup of -STABLE until at least the
end of January.
My guess is you didnt patch with the -p0 option to create missing
directories.
The README at http://people.freebsd.org/~ariff/README gives Ariffs
instructions for applying.

  The other option is the binaries in
http://people.freebsd.org/~ariff/lowlatency/
again read the README


Vince

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ARP problem with 6.2-STABLE Intel PRO/1000 NIC, latest em driver

[Jack Vogel]

On 3/5/07, Jack Vogel <[EMAIL PROTECTED]> wrote:

On 3/5/07, Mark Costlow <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 05, 2007 at 08:41:01AM -0800, Jack Vogel wrote:
> > >
> > >Maybe more of your dmesg might help as it could show interrrupt issues
> > >that perhaps others could help diagnose
> >
> > Yes, agreed, this might be revealing.
>
> Here's the full dmesg.  Thanks for looking at this.
>
> 
> Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation.
> FreeBSD 6.2-STABLE #0: Sun Mar  4 22:40:38 MST 2007
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
> ACPI APIC Table: 
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: Intel(R) Xeon(R) CPU5130  @ 2.00GHz (2000.08-MHz 686-class 
CPU)
>   Origin = "GenuineIntel"  Id = 0x6f6  Stepping = 6
>   
Features=0xbfebfbff MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>   Features2=0x4e33d,CX16,,,>
>   AMD Features=0x2000
>   AMD Features2=0x1
>   Cores per package: 2
> real memory  = 3489005568 (3327 MB)
> avail memory = 3414384640 (3256 MB)
> ioapic0  irqs 0-23 on motherboard
> ioapic1  irqs 24-47 on motherboard
> kbd1 at kbdmux0
> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
> acpi0:  on motherboard
> acpi0: Power Button (fixed)
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
> cpu0:  on acpi0
> acpi_throttle0:  on cpu0
> pcib0:  port 0xcf8-0xcff on acpi0
> pci0:  on pcib0
> pcib1:  at device 2.0 on pci0
> pci1:  on pcib1
> pcib2:  irq 16 at device 0.0 on pci1
> pci2:  on pcib2
> pcib3:  irq 16 at device 0.0 on pci2
> pci3:  on pcib3
> pcib4:  irq 18 at device 2.0 on pci2
> pci4:  on pcib4
> em0:  port 
0x2000-0x201f m
> em 0xda00-0xda01 irq 18 at device 0.0 on pci4
> em0: Ethernet address: 00:30:48:8c:71:54
> em1:  port 
0x2020-0x203f m
> em 0xda02-0xda03 irq 19 at device 0.1 on pci4
> em1: Ethernet address: 00:30:48:8c:71:55
> pcib5:  at device 0.3 on pci1
> pci5:  on pcib5
> 3ware device driver for 9000 series storage controllers, version: 3.60.02.012
> twa0: <3ware 9000 series Storage Controller> port 0x3000-0x303f mem 
0xd800-0
> xd9ff,0xda10-0xda100fff irq 24 at device 1.0 on pci5
> twa0: [GIANT-LOCKED]
> twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-4LP, 4 ports, 
Firm
> ware FE9X 3.04.01.011, BIOS BE9X 3.04.00.002
> pci0:  at device 8.0 (no driver attached)
> pcib6:  irq 17 at device 28.0 on pci0
> pci6:  on pcib6
> uhci0:  port 0x1800-0x181f irq 17 at device 
29.0
> on pci0
> uhci0: [GIANT-LOCKED]
> usb0:  on uhci0
> usb0: USB revision 1.0
> uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub0: 2 ports with 2 removable, self powered
> uhci1:  port 0x1820-0x183f irq 19 at device 
29.1
> on pci0
> uhci1: [GIANT-LOCKED]
> usb1:  on uhci1
> usb1: USB revision 1.0
> uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub1: 2 ports with 2 removable, self powered
> uhci2:  port 0x1840-0x185f irq 18 at device 
29.2
> on pci0
> uhci2: [GIANT-LOCKED]
> usb2:  on uhci2
> usb2: USB revision 1.0
> uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub2: 2 ports with 2 removable, self powered
> uhci3:  port 0x1860-0x187f irq 16 at device 
29.3
> on pci0
> uhci3: [GIANT-LOCKED]
> usb3:  on uhci3
> usb3: USB revision 1.0
> uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub3: 2 ports with 2 removable, self powered
> ehci0:  mem 0xda60-0xda6003ff irq 17 
at d
> evice 29.7 on pci0
> ehci0: [GIANT-LOCKED]
> usb4: EHCI version 1.0
> usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
> usb4:  on ehci0
> usb4: USB revision 2.0
> uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
> uhub4: 8 ports with 8 removable, self powered
> pcib7:  at device 30.0 on pci0
> pci7:  on pcib7
> pci7:  at device 1.0 (no driver attached)
> isab0:  at device 31.0 on pci0
> isa0:  on isab0
> atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,
> 0x376,0x1880-0x188f at device 31.1 on pci0
> ata0:  on atapci0
> ata1:  on atapci0
> pci0:  at device 31.3 (no driver attached)
> acpi_button0:  on acpi0
> atkbdc0:  port 0x60,0x64 irq 1 on acpi0
> atkbd0:  irq 1 on atkbdc0
> kbd0 at atkbd0
> atkbd0: [GIANT-LOCKED]
> psm0:  irq 12 on atkbdc0
> psm0: [GIANT-LOCKED]
> psm0: model Generic PS/2 mouse, device ID 0
> sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> sio0: type 16550A
> sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
> sio1: type 16550A
> fdc0:  port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
> fdc0: [FAST]
> ppc0:  port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on 
ac
> pi0
> ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
> ppc0: FIFO w

Re: Can't get sound to work!

[frzburn]

Well, here's what I did:
I got the files:

  - sndkld_releng6_amd64_lowlatency.tar.gz (since I use FreeBSD amd64)
  - soundcard.h
  - README

from 
http://people.freebsd.org/~ariff/lowlatency/
.
Then just follow the README! =)

frzburn


On 3/5/07, Karl Denninger <[EMAIL PROTECTED]> wrote:


Tried to apply that, and got a mess.

Did you put that on RELENG_6 cleanly?  It drops a bunch of files in the
top
level SRC directory (NOT under /sys!) if applied against /usr/src; it
appears to apply cleanly but a kernel build subsequent to that fails.

--
--
Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights
Activist
http://www.denninger.netMy home on the net - links to everything I
do!
http://scubaforum.org   Your UNCENSORED place to talk about
DIVING!
http://genesis3.blogspot.comMusings Of A Sentient Mind

On Mon, Mar 05, 2007 at 12:05:18PM +, Vince wrote:
> Karl Denninger wrote:
> > Is there any intent to backport that into -STABLE?
> >
> > How ugly would that be to do?
> >
> > --
> Almost certainly I hope :) if not the patch is available at
>
http://people.freebsd.org/~ariff/snd_RELENG_6_20070305_148_lowlatency.diff.gz
> doesnt look too ugly for me, and worked well too.
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]
"
>
>
> %SPAMBLOCK-SYS: Matched [EMAIL PROTECTED], message ok


%SPAMBLOCK-SYS: Matched [EMAIL PROTECTED], message ok
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ARP problem with 6.2-STABLE Intel PRO/1000 NIC, latest em driver

[Jack Vogel]

On 3/5/07, Mark Costlow <[EMAIL PROTECTED]> wrote:

On Mon, Mar 05, 2007 at 08:41:01AM -0800, Jack Vogel wrote:
> >
> >Maybe more of your dmesg might help as it could show interrrupt issues
> >that perhaps others could help diagnose
>
> Yes, agreed, this might be revealing.

Here's the full dmesg.  Thanks for looking at this.


Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation.
FreeBSD 6.2-STABLE #0: Sun Mar  4 22:40:38 MST 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
ACPI APIC Table: 
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(R) CPU5130  @ 2.00GHz (2000.08-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6f6  Stepping = 6
  Features=0xbfebfbff
  Features2=0x4e33d,CX16,,,>
  AMD Features=0x2000
  AMD Features2=0x1
  Cores per package: 2
real memory  = 3489005568 (3327 MB)
avail memory = 3414384640 (3256 MB)
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0:  on motherboard
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
cpu0:  on acpi0
acpi_throttle0:  on cpu0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 2.0 on pci0
pci1:  on pcib1
pcib2:  irq 16 at device 0.0 on pci1
pci2:  on pcib2
pcib3:  irq 16 at device 0.0 on pci2
pci3:  on pcib3
pcib4:  irq 18 at device 2.0 on pci2
pci4:  on pcib4
em0:  port 0x2000-0x201f m
em 0xda00-0xda01 irq 18 at device 0.0 on pci4
em0: Ethernet address: 00:30:48:8c:71:54
em1:  port 0x2020-0x203f m
em 0xda02-0xda03 irq 19 at device 0.1 on pci4
em1: Ethernet address: 00:30:48:8c:71:55
pcib5:  at device 0.3 on pci1
pci5:  on pcib5
3ware device driver for 9000 series storage controllers, version: 3.60.02.012
twa0: <3ware 9000 series Storage Controller> port 0x3000-0x303f mem 0xd800-0
xd9ff,0xda10-0xda100fff irq 24 at device 1.0 on pci5
twa0: [GIANT-LOCKED]
twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-4LP, 4 ports, Firm
ware FE9X 3.04.01.011, BIOS BE9X 3.04.00.002
pci0:  at device 8.0 (no driver attached)
pcib6:  irq 17 at device 28.0 on pci0
pci6:  on pcib6
uhci0:  port 0x1800-0x181f irq 17 at device 29.0
on pci0
uhci0: [GIANT-LOCKED]
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1:  port 0x1820-0x183f irq 19 at device 29.1
on pci0
uhci1: [GIANT-LOCKED]
usb1:  on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2:  port 0x1840-0x185f irq 18 at device 29.2
on pci0
uhci2: [GIANT-LOCKED]
usb2:  on uhci2
usb2: USB revision 1.0
uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhci3:  port 0x1860-0x187f irq 16 at device 29.3
on pci0
uhci3: [GIANT-LOCKED]
usb3:  on uhci3
usb3: USB revision 1.0
uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
ehci0:  mem 0xda60-0xda6003ff irq 17 at d
evice 29.7 on pci0
ehci0: [GIANT-LOCKED]
usb4: EHCI version 1.0
usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
usb4:  on ehci0
usb4: USB revision 2.0
uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub4: 8 ports with 8 removable, self powered
pcib7:  at device 30.0 on pci0
pci7:  on pcib7
pci7:  at device 1.0 (no driver attached)
isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci0:  port 0x1f0-0x1f7,0x3f6,0x170-0x177,
0x376,0x1880-0x188f at device 31.1 on pci0
ata0:  on atapci0
ata1:  on atapci0
pci0:  at device 31.3 (no driver attached)
acpi_button0:  on acpi0
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0:  irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model Generic PS/2 mouse, device ID 0
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
fdc0:  port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FAST]
ppc0:  port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on ac
pi0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/9 bytes threshold
ppbus0:  on ppc0
plip0:  on ppbus0
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
pmtimer0 on isa0
orm0:  at iomem 0xc-0xcafff,0xcb000-0xcc7ff on isa0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
rue0: USBKR100 USB 10/100 LAN, rev 1.10/1.00, addr 2
m

Re: Can't get sound to work!

[Karl Denninger]

Tried to apply that, and got a mess.

Did you put that on RELENG_6 cleanly?  It drops a bunch of files in the top
level SRC directory (NOT under /sys!) if applied against /usr/src; it
appears to apply cleanly but a kernel build subsequent to that fails.

--
-- 
Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist
http://www.denninger.netMy home on the net - links to everything I do!
http://scubaforum.org   Your UNCENSORED place to talk about DIVING!
http://genesis3.blogspot.comMusings Of A Sentient Mind

On Mon, Mar 05, 2007 at 12:05:18PM +, Vince wrote:
> Karl Denninger wrote:
> > Is there any intent to backport that into -STABLE?
> > 
> > How ugly would that be to do?
> > 
> > --
> Almost certainly I hope :) if not the patch is available at
> http://people.freebsd.org/~ariff/snd_RELENG_6_20070305_148_lowlatency.diff.gz
> doesnt look too ugly for me, and worked well too.
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 
> 
> %SPAMBLOCK-SYS: Matched [EMAIL PROTECTED], message ok


%SPAMBLOCK-SYS: Matched [EMAIL PROTECTED], message ok
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ARP problem with 6.2-STABLE Intel PRO/1000 NIC, latest em driver

[Mark Costlow]

On Mon, Mar 05, 2007 at 08:41:01AM -0800, Jack Vogel wrote:
> >
> >Maybe more of your dmesg might help as it could show interrrupt issues
> >that perhaps others could help diagnose
> 
> Yes, agreed, this might be revealing.

Here's the full dmesg.  Thanks for looking at this.


Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation.
FreeBSD 6.2-STABLE #0: Sun Mar  4 22:40:38 MST 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
ACPI APIC Table: 
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(R) CPU5130  @ 2.00GHz (2000.08-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6f6  Stepping = 6
  Features=0xbfebfbff
  Features2=0x4e33d,CX16,,,>
  AMD Features=0x2000
  AMD Features2=0x1
  Cores per package: 2
real memory  = 3489005568 (3327 MB)
avail memory = 3414384640 (3256 MB)
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0:  on motherboard
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
cpu0:  on acpi0
acpi_throttle0:  on cpu0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 2.0 on pci0
pci1:  on pcib1
pcib2:  irq 16 at device 0.0 on pci1
pci2:  on pcib2
pcib3:  irq 16 at device 0.0 on pci2
pci3:  on pcib3
pcib4:  irq 18 at device 2.0 on pci2
pci4:  on pcib4
em0:  port 0x2000-0x201f m
em 0xda00-0xda01 irq 18 at device 0.0 on pci4
em0: Ethernet address: 00:30:48:8c:71:54
em1:  port 0x2020-0x203f m
em 0xda02-0xda03 irq 19 at device 0.1 on pci4
em1: Ethernet address: 00:30:48:8c:71:55
pcib5:  at device 0.3 on pci1
pci5:  on pcib5
3ware device driver for 9000 series storage controllers, version: 3.60.02.012
twa0: <3ware 9000 series Storage Controller> port 0x3000-0x303f mem 0xd800-0
xd9ff,0xda10-0xda100fff irq 24 at device 1.0 on pci5
twa0: [GIANT-LOCKED]
twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-4LP, 4 ports, Firm
ware FE9X 3.04.01.011, BIOS BE9X 3.04.00.002
pci0:  at device 8.0 (no driver attached)
pcib6:  irq 17 at device 28.0 on pci0
pci6:  on pcib6
uhci0:  port 0x1800-0x181f irq 17 at device 29.0 
on pci0
uhci0: [GIANT-LOCKED]
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1:  port 0x1820-0x183f irq 19 at device 29.1 
on pci0
uhci1: [GIANT-LOCKED]
usb1:  on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2:  port 0x1840-0x185f irq 18 at device 29.2 
on pci0
uhci2: [GIANT-LOCKED]
usb2:  on uhci2
usb2: USB revision 1.0
uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhci3:  port 0x1860-0x187f irq 16 at device 29.3 
on pci0
uhci3: [GIANT-LOCKED]
usb3:  on uhci3
usb3: USB revision 1.0
uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
ehci0:  mem 0xda60-0xda6003ff irq 17 at d
evice 29.7 on pci0
ehci0: [GIANT-LOCKED]
usb4: EHCI version 1.0
usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
usb4:  on ehci0
usb4: USB revision 2.0
uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub4: 8 ports with 8 removable, self powered
pcib7:  at device 30.0 on pci0
pci7:  on pcib7
pci7:  at device 1.0 (no driver attached)
isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci0:  port 0x1f0-0x1f7,0x3f6,0x170-0x177,
0x376,0x1880-0x188f at device 31.1 on pci0
ata0:  on atapci0
ata1:  on atapci0
pci0:  at device 31.3 (no driver attached)
acpi_button0:  on acpi0
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0:  irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model Generic PS/2 mouse, device ID 0
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
fdc0:  port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FAST]
ppc0:  port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on ac
pi0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/9 bytes threshold
ppbus0:  on ppc0
plip0:  on ppbus0
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
pmtimer0 on isa0
orm0:  at iomem 0xc-0xcafff,0xcb000-0xcc7ff on isa0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
rue0: USBKR100 USB 10/100 LAN, rev 1.10/1.00, addr 2
miibus0:  on rue0
ruephy0:  on miibus0
ruephy0:  

Re: ARP problem with 6.2-STABLE Intel PRO/1000 NIC, latest em driver

[Mark Costlow]

On Sun, Mar 04, 2007 at 11:37:01PM -0800, Jack Vogel wrote:
> 
> These are one of our latest NICs, I have had no trouble with these
> but I'm used to using them on an Intel design, not SuperMicro.
> 
> First question, do you get the same behavior on both ports?
> My first guess is that this is a BIOS/management problem.
> 
> Double check SM website and see if there's any support updates
> to firmware for the system.

I left out a couple of things.  Yes, it does the same thing on both
em0 and em1.  And, the inhouse linux advocate loaded debian on the
box and that worked as expected.

I'll check SM's web site for BIOS updates today.

Mark
-- 
Mark Costlow| Southwest Cyberport | Fax:   +1-505-232-7975
[EMAIL PROTECTED] | Web:   www.swcp.com | Voice: +1-505-232-7992

abq-strange.com -- Interesting photos taken in Albuquerque, NM
   Last post: Art Is OK...And Dangerous - 2007-03-02 10:27:17

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ARP problem with 6.2-STABLE Intel PRO/1000 NIC, latest em driver

[Jack Vogel]

On 3/4/07, Duane Whitty <[EMAIL PROTECTED]> wrote:

On Sun, Mar 04, 2007 at 11:30:07PM -0700, Mark Costlow wrote:
> The Machine:
>
> I have a dual Xeon 5130 machine, Supermicro motherboard, with
> the 82563EB NIC.  From dmesg:
>
> CPU: Intel(R) Xeon(R) CPU5130  @ 2.00GHz (2000.08-MHz 686-class 
CPU)
> cpu0:  on acpi0
> em0:  port 
0x2000-0x201f mem 0xda00-0xda01 irq 18 at device 0.0 on pci4
>
> The machine has 4G RAM and a 3ware 9000 series RAID controller with 2 drives.
>
> pciconf -l says:
>
> [EMAIL PROTECTED]:0:0:   class=0x02 card=0x15d9 chip=0x10968086 
rev=0x01 hdr=0x00
> [EMAIL PROTECTED]:0:1:   class=0x02 card=0x15d9 chip=0x10968086 
rev=0x01 hdr=0x00
>
>
> The symptom:
>
> The machine boots OK, but can only intermittently make netork connections.
> Eventually determined that it seems to only see a few ARP packets, so
> it's falling out of other machines' ARP tables, and is often unable to
> see the replies to its own ARP requests.  It does see SOME ARPs
> though.  When it is able to communicate with another machine, it
> does not appear to drop any packets between them (e.g. I scp'd a 500M file
> at 300Mbps to this machine).
>
> When I run "tcpdump -n arp" I see a few ARPs, but not many.  In a 1-minute
> period, I saw 3 ARP who-has/reply packets.  On a different machine on
> the same ethernet switch, I saw 225 who-has/reply packets in the same
> 1-minute period.
>
> I've tried different cables, and a different switch.  I started with
> 6.2-RELEASE, and then went to 6.2-STABLE on 3/3/07 to get the latest
> em driver fixes.  I've used SMP and GENERIC kernels.  I get the same
> results in all cases.
>
> There are no firewall rules installed.
>
> I plugged in a USB ethernet adapter (realtek), and it works straight away.
> "tcpdump -n arp" sees the same noise as other machines on that LAN.
>

Sounds like it could be bad hardware.  Can you swap nics?


No he can't these are LOMs (on the motherboard).


> I read through the recent threads on the em driver, but didn't see any
> reported symptoms like this.  Has anyone seen anything like this?  Got
> any hints for me?  Am I doing something stupid?  Did I leave out any
> useful information about my configuration?
>

Maybe more of your dmesg might help as it could show interrrupt issues
that perhaps others could help diagnose


Yes, agreed, this might be revealing.

Jack
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Clamav-90_2 Lockup with freebsd 6.2 (fwd)

[Martin Blapp]

After further analyzing I think that pthread_cond_timedwait() in 
libpthread.so.2 has some issues.


While the default clamd worker timeout of 30 seconds is reached with
libc_r.so.6 and libthr.so.2 and pthread_cond_timedwait() returns ETIMEDOUT
there, libpthread.so doesn't get any ETIMEDOUT errors back at all, and the code
can never reach the part where the worker thread gets detached and the thread
count gets decreased.

With libpthread.so.2 pthread_cond_timedwait() returns always 0.

The manpage tells me:


The pthread_cond_timedwait() function atomically blocks the current
thread waiting on the condition variable specified by cond, and unblocks
the mutex specified by mutex.  The waiting thread unblocks only after
another thread calls pthread_cond_signal(3), or pthread_cond_broadcast(3)
with the same condition variable, or if the system time reaches the time
specified in abstime, and the current thread reacquires the lock on
mutex.


That doesn't seem to work with libpthread.so.2. Any hints ?

--
Martin

Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: 
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Portaudit

[Randy Pratt]

On Mon, 5 Mar 2007 13:55:50 +0100
"Stephane Thomas" <[EMAIL PROTECTED]> wrote:

> Hello,
> 
> I just installed portaudit and now I cannot build mozilla anymore because of
> three vulnerabilities. Is there a way to force building of a port even if
> there are knows vulnerabilities ? I guess I can add some portaudit_fixed=
> lines in /usr/local/etc/portaudit.conf but as the vulnerabilities aren't
> really fixed I'm not sure this is the right thing to do.
> 
> I read portaudit's man and freebsd handbook but I can't figure out the good
> method. Thx in advance.

If you're sure you want to override portaudit you can use

make DISABLE_VULNERABILITIES=yes

followed by any other arguments for building a port (see man 7 ports).
If you want to disable portaudit for portupgrade, use something like:

portupgrade -m "DISABLE_VULNERABILITIES=yes"

followed by any other arguments needed.

HTH,

Randy
-- 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Portaudit

[Karol Kwiatkowski]

Stephane Thomas wrote:
> Hello,
> 
> I just installed portaudit and now I cannot build mozilla anymore
> because of
> three vulnerabilities. Is there a way to force building of a port even if
> there are knows vulnerabilities ?

After 'man 7 ports':

% ENVIRONMENT
% [...]
%  DISABLE_VULNERABILITIES
%  If defined, disable check for security vulnerabilities
%  using portaudit(1) (ports/security/portaudit) when
%  installing new ports.

Cheers,

Karol

-- 
Karol Kwiatkowski   
OpenPGP 0x06E09309



signature.asc
Description: OpenPGP digital signature

panic on FreeBSD 6.2 (dump included)

[Nikolay Pavlov]

Hi, folks. I have a panic on FreeBSD 6.2:

kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug vmcore.3
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-marcel-freebsd".

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xc096f0
fault code  = supervisor read, page not present
instruction pointer = 0x20:0xc096f120
stack pointer   = 0x28:0xf5becbf0
frame pointer   = 0x28:0x0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 755 (httpd)
trap number = 12
panic: page fault
Uptime: 3h16m4s
Dumping 2046 MB (2 chunks)
  chunk 0: 1MB (159 pages) ... ok
  chunk 1: 2046MB (523760 pages) 2030 2014 1998 1982 1966 1950 1934 1918
1902 1886 1870 1854 1838 1822 1806 1790 1774 1758 1742 1726 1710 1694
1678 1662 1646 1630 1614 1598 1582 1566 1550 1534 1518 1502 1486 1470
1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246
1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022
1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734
718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446
430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158
142 126 110 94 78 62 46 30 14

#0  doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:165
#1  0xc0672afe in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2  0xc0672d94 in panic (fmt=0xc08db5c1 "%s") at 
/usr/src/sys/kern/kern_shutdown.c:565
#3  0xc0885a04 in trap_fatal (frame=0xf5becbb0, eva=12621552) at 
/usr/src/sys/i386/i386/trap.c:837
#4  0xc088576b in trap_pfault (frame=0xf5becbb0, usermode=0, eva=12621552) at 
/usr/src/sys/i386/i386/trap.c:745
#5  0xc08853a9 in trap (frame=
  {tf_fs = -944504824, tf_es = 40, tf_ds = -172097496, tf_edi =
-1066957550, tf_esi = -172045336, tf_ebp = 0, tf_isp = -172045348,
tf_ebx = 0, tf_edx = -944490096, tf_ecx = -944478804, tf_eax =
-172045200, tf_trapno = 12, tf_err = 0, tf_eip = -1063849696, tf_cs =
32, tf_eflags = 66118, tf_esp = -172045332, tf_ss = 0}) at
/usr/src/sys/i386/i386/trap.c:435
#6  0xc0873a7a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7  0xc096f120 in M_SELECT_uninit_sys_uninit ()

-- 
==  
- Best regards, Nikolay Pavlov. <<<---
==  

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up

[Yar Tikhiy]

On Sun, Mar 04, 2007 at 10:59:46PM -0500, Kris Kennaway wrote:
> On Sun, Mar 04, 2007 at 10:59:46AM +0300, Yar Tikhiy wrote:
> > On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote:
> > > On Tuesday 27 February 2007 15:53, Alex Kozlov wrote:
> > > = > Yes, I switched to swap-backed md already. But the malloc-based 
> > > variety is 
> > > = > currently the _default_ (see /etc/defaults/rc.conf)...
> > > = Bad default.
> > > 
> > > Filing a PR.
> > 
> > Keep in mind that changing the default can break existing setups.
> > Such setups are likely to be broken anyway, but...  E.g., if we
> > drop the -M flag, it will break systems with tons of RAM but little
> > swap using tmpmfs.
> 
> How will it break them?  swap backing only touches swap if there is
> memory pressure, i.e. precisely the situation in which malloc backing
> will panic.

I forgot that in BSD swap wouldn't be allocated in advance to its
consumers.  Then removing the -M flag and making swap backing the
default is a very sound choice.  Thank you for correcting me.

-- 
Yar
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Portaudit

[Stephane Thomas]

Hello,

I just installed portaudit and now I cannot build mozilla anymore because of
three vulnerabilities. Is there a way to force building of a port even if
there are knows vulnerabilities ? I guess I can add some portaudit_fixed=
lines in /usr/local/etc/portaudit.conf but as the vulnerabilities aren't
really fixed I'm not sure this is the right thing to do.

I read portaudit's man and freebsd handbook but I can't figure out the good
method. Thx in advance.

Stef
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Can't get sound to work!

[Vince]

Karl Denninger wrote:
> Is there any intent to backport that into -STABLE?
> 
> How ugly would that be to do?
> 
> --
Almost certainly I hope :) if not the patch is available at
http://people.freebsd.org/~ariff/snd_RELENG_6_20070305_148_lowlatency.diff.gz
doesnt look too ugly for me, and worked well too.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 'panic: bad pte' error on 6.2-RELEASE (amd64)

[Kostik Belousov]

On Mon, Mar 05, 2007 at 12:05:32AM -0800, Peter Losher wrote:
> We recently updated one of our dual Opteron systems (w/ 4GB RAM) from
> 5.5 to 6.2 (amd64 wipe and reinstalled) and about once a week, it panics
> with the below message:
> 
> -=-
> TPTE at 0x840028a0  IS ZERO @ VA 800514000
> panic: bad pte
> cpuid = 2
> KDB: stack backtrace:
> panic() at 0x803fdd03 = panic+0x253
> pmap_remove_pages() at 0x806072a3 = pmap_remove_pages+0x283
> exec_new_vmspace() at 0x803e18e6 = exec_new_vmspace+0x216
> exec_elf64_imgact() at 0x803cbb73 = exec_elf64_imgact+0x273
> kern_execve() at 0x803e2107 = kern_execve+0x457
> execve() at 0x803e2bed = execve+0x5d
> syscall() at 0x8060d141 = syscall+0x4d1
> Xfast_syscall() at 0x805f8128 = Xfast_syscall+0xa8
> --- syscall (59, FreeBSD ELF64, execve), rip = 0x80069838c, rsp =
> 0x7fffe7c8, rbp = 0x7fffecd0 ---
> Uptime: 4d16h55m46s
> -=-
> 
> I do have a dump, and can make that available if need be.  Has anyone
> encountered this recently and can shed any light on what might be
> causing this?

Did rev. 1.516.2.9 of sys/amd64/amd64/pmap.c changed (or even fixed) the
problem ? (This is the same patch I already sent you).


pgplMx9lBVjjg.pgp
Description: PGP signature

Sata controller Sil 3512 - Kernel Panic.

[Peter Ankerstål]

Hi,

I've recently installed a new sata-controller on a fresh installed FreeBSD 6.2.
I gave the manual ata(4) a quick look before I bought the controller and it 
tells me this chip should be supported. But the machine panics every few minutes 
when I have a disk connected to it.


Is there a way to fix this? heh.

kernel: atapci0:  port 
0xdff0-0xdff7,0xdfe4-0xdfe7,0xdfa8-0xdfaf,0xdfe0-0xdfe3,0xdf90-0xdf9f mem 
0xfe5ffc00-0xfe5ffdff irq 22 at device 11.0 on pci1


kernel: ad6: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=244892063

fee kernel:

fee kernel:

kernel: Fatal trap 12: page fault while in kernel mode

kernel: fault virtual address   = 0x28

kernel: fault code  = supervisor read, page not present

kernel: instruction pointer = 0x20:0xc0685de4

kernel: stack pointer   = 0x28:0xcbeeac28

kernel: frame pointer   = 0x28:0xcbeeac30

kernel: code segment= base 0x0, limit 0xf, type 0x1b

kernel: = DPL 0, pres 1, def32 1, gran 1

kernel: processor eflags= interrupt enabled, resume, IOPL = 0

kernel: current process = 6 (thread taskq)
kernel: trap number = 12

kernel: panic: page fault

kernel: Uptime: 33m38s

kernel: Cannot dump. No dump device defined.

kernel: Automatic reboot in 15 seconds - press a key on the console to abort

kernel: Rebooting...

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

'panic: bad pte' error on 6.2-RELEASE (amd64)

[Peter Losher]

We recently updated one of our dual Opteron systems (w/ 4GB RAM) from
5.5 to 6.2 (amd64 wipe and reinstalled) and about once a week, it panics
with the below message:

-=-
TPTE at 0x840028a0  IS ZERO @ VA 800514000
panic: bad pte
cpuid = 2
KDB: stack backtrace:
panic() at 0x803fdd03 = panic+0x253
pmap_remove_pages() at 0x806072a3 = pmap_remove_pages+0x283
exec_new_vmspace() at 0x803e18e6 = exec_new_vmspace+0x216
exec_elf64_imgact() at 0x803cbb73 = exec_elf64_imgact+0x273
kern_execve() at 0x803e2107 = kern_execve+0x457
execve() at 0x803e2bed = execve+0x5d
syscall() at 0x8060d141 = syscall+0x4d1
Xfast_syscall() at 0x805f8128 = Xfast_syscall+0xa8
--- syscall (59, FreeBSD ELF64, execve), rip = 0x80069838c, rsp =
0x7fffe7c8, rbp = 0x7fffecd0 ---
Uptime: 4d16h55m46s
-=-

I do have a dump, and can make that available if need be.  Has anyone
encountered this recently and can shed any light on what might be
causing this?

Best Wishes - Peter



signature.asc
Description: OpenPGP digital signature

Re: ARP problem with 6.2-STABLE Intel PRO/1000 NIC, latest em driver

[Duane Whitty]

On Sun, Mar 04, 2007 at 11:30:07PM -0700, Mark Costlow wrote:
> The Machine:
> 
> I have a dual Xeon 5130 machine, Supermicro motherboard, with
> the 82563EB NIC.  From dmesg:
> 
> CPU: Intel(R) Xeon(R) CPU5130  @ 2.00GHz (2000.08-MHz 686-class 
> CPU)
> cpu0:  on acpi0
> em0:  port 
> 0x2000-0x201f mem 0xda00-0xda01 irq 18 at device 0.0 on pci4
> 
> The machine has 4G RAM and a 3ware 9000 series RAID controller with 2 drives.
> 
> pciconf -l says:
> 
> [EMAIL PROTECTED]:0:0:   class=0x02 card=0x15d9 chip=0x10968086 
> rev=0x01 hdr=0x00
> [EMAIL PROTECTED]:0:1:   class=0x02 card=0x15d9 chip=0x10968086 
> rev=0x01 hdr=0x00
> 
> 
> The symptom:
> 
> The machine boots OK, but can only intermittently make netork connections.
> Eventually determined that it seems to only see a few ARP packets, so
> it's falling out of other machines' ARP tables, and is often unable to
> see the replies to its own ARP requests.  It does see SOME ARPs
> though.  When it is able to communicate with another machine, it
> does not appear to drop any packets between them (e.g. I scp'd a 500M file
> at 300Mbps to this machine).
> 
> When I run "tcpdump -n arp" I see a few ARPs, but not many.  In a 1-minute
> period, I saw 3 ARP who-has/reply packets.  On a different machine on
> the same ethernet switch, I saw 225 who-has/reply packets in the same
> 1-minute period.
> 
> I've tried different cables, and a different switch.  I started with
> 6.2-RELEASE, and then went to 6.2-STABLE on 3/3/07 to get the latest
> em driver fixes.  I've used SMP and GENERIC kernels.  I get the same
> results in all cases.
> 
> There are no firewall rules installed.
> 
> I plugged in a USB ethernet adapter (realtek), and it works straight away.
> "tcpdump -n arp" sees the same noise as other machines on that LAN.
> 

Sounds like it could be bad hardware.  Can you swap nics?

> I read through the recent threads on the em driver, but didn't see any
> reported symptoms like this.  Has anyone seen anything like this?  Got
> any hints for me?  Am I doing something stupid?  Did I leave out any
> useful information about my configuration?
> 

Maybe more of your dmesg might help as it could show interrrupt issues
that perhaps others could help diagnose

--Duane

> Thanks,
> 
> Mark
> -- 
> Mark Costlow| Southwest Cyberport | Fax:   +1-505-232-7975
> [EMAIL PROTECTED] | Web:   www.swcp.com | Voice: +1-505-232-7992
> 
> abq-strange.com -- Interesting photos taken in Albuquerque, NM
>Last post: Art Is OK...And Dangerous - 2007-03-02 10:27:17
> 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"