Re: Updated acpi_cpu patch

2003-12-02 Thread Lukas Ertl
On Tue, 2 Dec 2003, Nate Lawson wrote:

 Um, you have no _ACx values so the fan will be controlled by the BIOS.  We
 should probably provide a way for users to supply their own _ACx values if
 they're not happy with the BIOS's but I'm not sure your ASL exports a
 power resource for the fan object.  Do you have an object with id PNP0C0B?

No, there's no PNP0C0B device.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Updated acpi_cpu patch

2003-12-02 Thread Lukas Ertl
On Tue, 2 Dec 2003, Nate Lawson wrote:

 Build with options ACPI_DEBUG and boot with this in loader.conf:
 debug.acpi.layer=ACPI_POWER
 debug.acpi.level=ACPI_LV_OBJECTS

 It will print any power resources you have.

Unfortunately, there's no power resource listed.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Updated acpi_cpu patch

2003-11-26 Thread Lukas Ertl
On Wed, 26 Nov 2003, Nate Lawson wrote:

 It's possible the fan is under BIOS control so make sure you have an
 up-to-date bios.  If not, you should get a console printout when acpi
 switches the fan on.  sysctl hw.acpi.thermal

Nope, no ACPI messages, and I can't find a FAN device in my ASL. (At least
no 'standard' one - anyone knows what hides behind this HKEY device
every ThinkPad seems to have?)

 You are correct.  _PSV is not currently implemented by FreeBSD but I hope
 to do it at some point.  Once we have all methods of processor control
 (cpufreq, Cx, and throttling), we can use them to implement _PSV.  In any
 case, I think the _PSV value is set high because your platform designer
 expects active cooling to be the most effective and passive, since it
 slows down performance, is a last resort.

Ah, sounds reasonable, thanks for the explaination.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Updated acpi_cpu patch

2003-11-26 Thread Lukas Ertl
On Wed, 26 Nov 2003, Nate Lawson wrote:

 On Wed, 26 Nov 2003, Lukas Ertl wrote:
  On Wed, 26 Nov 2003, Nate Lawson wrote:
   It's possible the fan is under BIOS control so make sure you have an
   up-to-date bios.  If not, you should get a console printout when acpi
   switches the fan on.  sysctl hw.acpi.thermal
 
  Nope, no ACPI messages, and I can't find a FAN device in my ASL. (At least
  no 'standard' one - anyone knows what hides behind this HKEY device
  every ThinkPad seems to have?)

 It's not called FAN.  It is a device with a certain PNP id and controlled
 by a power resource.

That's what I meant, actually.

 I need the output of sysctl hw.acpi.thermal to see your _ACx values.

hw.acpi.thermal.tz0.temperature: 3072
hw.acpi.thermal.tz0.active: -1
hw.acpi.thermal.tz0.thermal_flags: 0
hw.acpi.thermal.tz0._PSV: 3627
hw.acpi.thermal.tz0._HOT: -1
hw.acpi.thermal.tz0._CRT: 3662
hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Updated acpi_cpu patch

2003-11-22 Thread Lukas Ertl
On Sat, 22 Nov 2003, Lukas Ertl wrote:

 Ah, this would explain why I can see the C3 states change after a
 suspend/resume - USB is dead then :-)

 I'm gonna try without USB and send you the output again.

Yes, looks better now:

hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185
hw.acpi.cpu.cx_lowest: 3
hw.acpi.cpu.cx_history: 0/0 451979/0 2361/15 805279/27634

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ACPI and APM testing on Dell Inspiron 8200

2003-11-22 Thread Lukas Ertl
On Sat, 22 Nov 2003, Ryan Sommers wrote:

 I'm having difficulty getting battery and thermal status. If I compile the
 kernel with APM support I get battery statistics but if I try to put
 APM/ACPI in the kernel ACPI reports that another PM system is enabled and
 doesn't load the /dev/acpi device.

Yes, you can have either ACPI or APM, but not both at the same time.

 If I take APM out and compile in ACPI I get /dev/acpi and all that goes
 with it; but the battery status does not show up correctly.

The log you have posted shows that you're running on AC, that's why
battery time is 0.  Plus, you somehow made it to fill up the battery to
118%. :-)

The log also shows that you're loading a customized DSDT at boot, maybe
that is borked.

 (Which brings me to the point, in the NOTES file it's noted
 that device acpi is deprecated, but if you don't add the device you don't
 get acpi support...)

Yes, this info is currently out-of-date.  There were some recent changes
to the interrupt code that made it necessary to compile acpi into the
kernel.  I'm not sure if someone already works on making it a module
again.

Generally, you should use acpidump(8) to dump your ACPI tables and ASL,
put it on a website and post a link to it here.  Maybe someone can take a
look at it then.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Updated acpi_cpu patch

2003-11-21 Thread Lukas Ertl
On Fri, 21 Nov 2003, Nate Lawson wrote:

   On Tue, 18 Nov 2003, Lukas Ertl wrote:
I'm gonna try some buildkernelstones with the different settings.  If
you have some special benchmarks in mind I'd be happy to run them.
  
   That's probably ok.  It has a lot of IO.
 
  Now I've tried running make buildkernel and tarring /usr/src to a
  different location, with different setting for hw.acpi.cpu.cx_lowest.  I
  couldn't see any real difference - neither in performance nor in heat
  emission.

 Well, heat emission will be high during benchmarks because the CPU is
 rarely idle.  My fan always comes on my laptop during buildworld.  But the
 difference is when it's mostly idle (checking email, web browsing).  With
 machdep.cpu_idle_hlt=0, the fan is always on even when the box is sitting
 there.  With cpu_idle_hlt=0 and cx_lowest=0 (C1), the fan goes off but the
 box is still warm.  With cx_lowest=2 (C3, 120 us transition time), the box
 is very cool but some IO gets a little slower (serial port).  But not
 much.

The problem is that the fan in this machine always kicks in after several
minutes, and then stays on.  This is very annoying.

BTW, I'm having another ACPI question, do these figures here make sense?

hw.acpi.thermal.tz0._PSV: 3627
hw.acpi.thermal.tz0._CRT: 3662

If I understood the ACPI spec correctly, _PSV is the temperature where
passive cooling actions begin, and _CRT is the critical temp, where the OS
should initiate a shutdown.  First, _PSV seems to be way to high, and
second, they are so close to each other.

 Those are what is more interesting.  Also, can you send me your sysctl
 hw.acpi.cpu.cx_history after you've used it for a while with the maximum
 cx_lowest setting?

Ok, no problem.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Updated acpi_cpu patch

2003-11-21 Thread Lukas Ertl
On Fri, 21 Nov 2003, Nate Lawson wrote:

 On Sat, 22 Nov 2003, Lukas Ertl wrote:
  On Fri, 21 Nov 2003, Nate Lawson wrote:
 
   Those are what is more interesting.  Also, can you send me your sysctl
   hw.acpi.cpu.cx_history after you've used it for a while with the maximum
   cx_lowest setting?
 
  hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185
  hw.acpi.cpu.cx_lowest: 3
  hw.acpi.cpu.cx_history: 0/0 1143097/0 0/0 0/0
 
  This is after 1:22h doing things like eMail, web surfing, IRC...

 Ah, I see the C3 states aren't being used.  If you are playing mp3s or
 have usb enabled in your kernel, they won't be used (because we can't use
 them when bus mastering transfers are active.)  Try making usb a module
 and not loading it and test this again.

Ah, this would explain why I can see the C3 states change after a
suspend/resume - USB is dead then :-)

I'm gonna try without USB and send you the output again.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Updated acpi_cpu patch

2003-11-20 Thread Lukas Ertl
On Tue, 18 Nov 2003, Nate Lawson wrote:

 On Tue, 18 Nov 2003, Lukas Ertl wrote:
 
  I'm gonna try some buildkernelstones with the different settings.  If
  you have some special benchmarks in mind I'd be happy to run them.

 That's probably ok.  It has a lot of IO.

Now I've tried running make buildkernel and tarring /usr/src to a
different location, with different setting for hw.acpi.cpu.cx_lowest.  I
couldn't see any real difference - neither in performance nor in heat
emission.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Updated acpi_cpu patch

2003-11-18 Thread Lukas Ertl
On Tue, 18 Nov 2003, Nate Lawson wrote:

 Below you'll find the update patch for acpi_cpu.  Please test this,
 especially for SMP and laptops with _CST objects in their ASL.

Looks good here on a Centrino based laptop, which has a _CST method in
its ASL:

acpi_cpu0: CPU on acpi0
acpi_cpu0: C2 state 1 lat
acpi_cpu0: C3 state 85 lat

hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85
hw.acpi.cpu.cx_lowest: 0
hw.acpi.cpu.cx_history: 86231/0 0/0 0/0

Although it seems I have lost a C3 state (before, I had an additional
C3/185).

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Updated acpi_cpu patch

2003-11-18 Thread Lukas Ertl
On Tue, 18 Nov 2003, Lukas Ertl wrote:

 hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85
 hw.acpi.cpu.cx_lowest: 0
 hw.acpi.cpu.cx_history: 86231/0 0/0 0/0

 Although it seems I have lost a C3 state (before, I had an additional
 C3/185).

Correction: every other boot I get the additional C3/185 - strange,
indeed.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Updated acpi_cpu patch

2003-11-18 Thread Lukas Ertl
On Tue, 18 Nov 2003, Nate Lawson wrote:

 On Tue, 18 Nov 2003, Lukas Ertl wrote:

  hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85
  hw.acpi.cpu.cx_lowest: 0
  hw.acpi.cpu.cx_history: 86231/0 0/0 0/0

 Try settings of cx_lowest of 1 and 2 (and 3 when the last C3 state is
 available).  I'm interested in any benchmark results, especially IO.  I'm
 hoping the scheduling of sleeps is good enough that you don't experience
 much performance loss even with lower sleeps.

I'm gonna try some buildkernelstones with the different settings.  If
you have some special benchmarks in mind I'd be happy to run them.

  Although it seems I have lost a C3 state (before, I had an additional
  C3/185).

 _CST can change dynamically at runtime.  If you booted with the AC adapter
 attached, your laptop may not offer all the sleep states.  When you unplug
 the AC adapter, we get a notify on _CST to re-evaluate it and look for new
 states.  However, that code is currently disabled due to complex locking
 issues (i.e. what to do when a Cx state is being accessed but _CST is
 being re-evaluated).  _CST re-evaluation won't be enabled until after
 5.2R.  However, you can reboot your laptop with the AC adapter detached
 (or attached) to see what states are available.

Ah, yes, that would explain it - I just booted on battery.

 This excerpt from truckman@'s asl shows that 4 Cx states are only
 available when the AC adapter is not attached.  (The C*NA memory addresses
 appear to be managed by the BIOS and not the AML but the PSR access is
 clear).

This part of the ASL looks the one here - let me guess, is it a ThinkPad?
:-)

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Updated acpi_cpu patch

2003-11-18 Thread Lukas Ertl
On Tue, 18 Nov 2003, Nate Lawson wrote:

 On Tue, 18 Nov 2003, Don Lewis wrote:
 
  Yup, a Thinkpad R40, which refuses to actually power down in ACPI mode
  when I run shutdown -p.

 That's an old problem that Linux is also trying to work around.  It
 appears to be buggy hw.

Just for the record: shutdown -p works fine on the T40.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


usb0: cannot start

2003-11-17 Thread Lukas Ertl
Hi,

running a kernel from Sat Nov 15 21:58:25 CET 2003, I get the following
messages when resuming from ACPI suspend:

usb0: cannot start
usb1: cannot start
usb2: cannot start
usb0: host system error
usb0: host controller process error
usb0: host controller halted
usb1: host system error
usb1: host controller process error
usb1: host controller halted
usb2: host system error
usb2: host controller process error
usb2: host controller halted
usb3: unrecoverable error, controller halted
usb3: blocking intrs 0x10
uhub3: illegal enable change, port 1

Then the USB ports are dead.  Any ideas?

pciconv -lv says:

[EMAIL PROTECTED]:29:0:   class=0x0c0300 card=0x052d1014 chip=0x24c28086 rev=0x01 
hdr=0x00
vendor   = 'Intel Corporation'
device   = '82801DB/DBM (ICH4/M) USB UHCI Controller #1'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:1:   class=0x0c0300 card=0x052d1014 chip=0x24c48086 rev=0x01 
hdr=0x00
vendor   = 'Intel Corporation'
device   = '82801DB/DBM (ICH4/M) USB UHCI Controller #2'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:2:   class=0x0c0300 card=0x052d1014 chip=0x24c78086 rev=0x01 
hdr=0x00
vendor   = 'Intel Corporation'
device   = '82801DB/DBM (ICH4/M) USB UHCI Controller #3'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:7:   class=0x0c0320 card=0x052e1014 chip=0x24cd8086 rev=0x01 
hdr=0x00
vendor   = 'Intel Corporation'
device   = '82801DB/DBM (ICH4/M) USB EHCI Controller'
class= serial bus
subclass = USB


And in the dmesg I get:

usb0: Intel 82801DB (ICH4) USB controller USB-A 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: Intel 82801DB (ICH4) USB controller USB-B port 0x1820-0x183f irq 11 at device 
29.1 on pci0
usb1: Intel 82801DB (ICH4) USB controller USB-B 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: Intel 82801DB (ICH4) USB controller USB-C port 0x1840-0x185f irq 11 at device 
29.2 on pci0
usb2: Intel 82801DB (ICH4) USB controller USB-C 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
ehci0: EHCI (generic) USB 2.0 controller mem 0xc000-0xc3ff irq 11 at device 
29.7 on pci0
ehci_pci_attach: companion usb0
ehci_pci_attach: companion usb1
ehci_pci_attach: companion usb2
usb3: EHCI version 1.0
usb3: companion controllers, 2 ports each: usb0 usb1 usb2
usb3: EHCI (generic) USB 2.0 controller on ehci0
usb3: USB revision 2.0
uhub3: (0x8086) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub3: 6 ports with 6 removable, self powered

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: cvs commit: src/sys/dev/acpica acpi_cpu.c src/share/man/man4 acpi.4 src/sys/conf files src/sys/modules/acpi Makefile

2003-11-16 Thread Lukas Ertl
On Sat, 15 Nov 2003, Nate Lawson wrote:

 Please test this to be sure that it boots ok on your machine, especially
 SMP boxes.  Throttling should still work ok also.

Seems to work here:

hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185
hw.acpi.cpu.cx_lowest: 0
hw.acpi.cpu.cx_history: 173839/0 0/0 0/0 0/0

I've no idea if it actually has an effect.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: named pipes memory leak?

2003-11-11 Thread Lukas Ertl
On Mon, 10 Nov 2003, Don Lewis wrote:

 On 10 Nov, Lukas Ertl wrote:
  On Mon, 10 Nov 2003, Don Lewis wrote:
 
  If fifo_open() is interrupted, fifo_close() never gets called, and the
  resources are not recovered.  I wish doing the resource recovery in
  fifo_inactive() would have worked ...
 
  Try this patch:
 
  Thanks, your patch seems so solve this problem effectively.

 The patch has been committed.  Thanks for testing it.

Unfortunately, we are still seeing a problem here: we are running uvscan
(virus scanner), and while running it we are still seeing increasing unpcb
usage and orphaned unix domain sockets.

We added some debug printfs to the fifo routines and found out that
fifo_cleanup is called from fifo_close with a vnode which has v_usecount
== 2 so the socket close calls aren't reached.

Any ideas?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: named pipes memory leak?

2003-11-11 Thread Lukas Ertl
On Tue, 11 Nov 2003, Lukas Ertl wrote:

 Unfortunately, we are still seeing a problem here: we are running uvscan
 (virus scanner), and while running it we are still seeing increasing unpcb
 usage and orphaned unix domain sockets.

 We added some debug printfs to the fifo routines and found out that
 fifo_cleanup is called from fifo_close with a vnode which has v_usecount
 == 2 so the socket close calls aren't reached.

Sorry, I probably missed an important part: we're creating the FIFOs on
nullfs mounts - the test script works great on plain UFS mounts, but the
null layer seems to VREF the vnode once again, so v_usecount is 2, thus it
is missong the check in fifo_cleanup().

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: named pipes memory leak?

2003-11-11 Thread Lukas Ertl
On Tue, 11 Nov 2003, Don Lewis wrote:

 Now that I've had some time to think about it, if you reuse the same
 fifo, you'll run into the same problem that caused me to abandon my
 previous fifo_inactive() version of the cleanup code, which is stale
 data being left in the fifo after both ends have been closed.  You may
 be stuck with plan B below ...

  As a workaround could you create a little mdfs to hold the fifo?

We could get away with it by just using symlinks instead of null mounts,
so, with your patch, it isn't a real problem for us anymore.  Thanks
again.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


named pipes memory leak?

2003-11-10 Thread Lukas Ertl
Hi,

is there a known problem with named pipes in -CURRENT?

The following shell script freezes a machine in several minutes and needs
a power cycle.  You can see the increasing memory in vmstat -z (unpcb) and
netstat -u.  The kernel is FreeBSD 5.1-CURRENT Tue Nov 4 14:08:23 CET 2003.

---8---
#/bin/sh

FIFO=/tmp/foo

for i in `jot 5 1`; do
   mkfifo ${FIFO}
   echo blubb  ${FIFO} 
   kill $!
   rm ${FIFO}
done
---8---

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: panic on mount_cd9660

2003-11-10 Thread Lukas Ertl
On Mon, 10 Nov 2003, Pav Lucistnik wrote:

 #7  0xc054bf48 in g_destroy_provider (pp=0xc3e84000) at 
 /usr/src/sys/geom/geom_subr.c:416
 #8  0xc0548f25 in g_orphan_register (pp=0xc2e32700) at 
 /usr/src/sys/geom/geom_event.c:143
 #9  0xc054904c in one_event () at /usr/src/sys/geom/geom_event.c:169
 #10 0xc0549275 in g_run_events () at /usr/src/sys/geom/geom_event.c:202
 #11 0xc054a2a5 in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:134
 #12 0xc056dff0 in fork_exit (callout=0xc054a280 g_event_procbody, arg=0x0, 
 frame=0x0) at /usr/src/sys/kern/kern_fork.c:793

 (kgdb) up 7
 #7  0xc054bf48 in g_destroy_provider (pp=0xc3e84000) at 
 /usr/src/sys/geom/geom_subr.c:416
 416 devstat_remove_entry(pp-stat);

 (kgdb) print pp
 $1 = (struct g_provider *) 0xc3e84000
 (kgdb) print *pp
 $2 = {name = 0x0, provider = {le_next = 0x0, le_prev = 0x0}, geom = 0x0, consumers = 
 {lh_first = 0x0}, acr = 0, acw = 0, ace = 0, error = 0, orphan = {tqe_next = 0x0, 
 tqe_prev = 0x0}, index = 0,
   mediasize = 0, sectorsize = 0, stripesize = 0, stripeoffset = 0, stat = 0x0, 
 nstart = 0, nend = 0, flags = 0}

What does pp look like in frame 8?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: named pipes memory leak?

2003-11-10 Thread Lukas Ertl
On Mon, 10 Nov 2003, Don Lewis wrote:

 On 10 Nov, Lukas Ertl wrote:
 
  The following shell script freezes a machine in several minutes and needs
  a power cycle.  You can see the increasing memory in vmstat -z (unpcb) and
  netstat -u.  The kernel is FreeBSD 5.1-CURRENT Tue Nov 4 14:08:23 CET 2003.
 
  ---8---
  #/bin/sh
 
  FIFO=/tmp/foo
 
  for i in `jot 5 1`; do
 mkfifo ${FIFO}
 echo blubb  ${FIFO} 
 kill $!
 rm ${FIFO}
  done
  ---8---

 If fifo_open() is interrupted, fifo_close() never gets called, and the
 resources are not recovered.  I wish doing the resource recovery in
 fifo_inactive() would have worked ...

 Try this patch:

Thanks, your patch seems so solve this problem effectively.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: panic on mount_cd9660

2003-11-10 Thread Lukas Ertl
On Mon, 10 Nov 2003, Pav Lucistnik wrote:

 V po, 10. 11. 2003 v 22:24, Lukas Ertl pí?e:
  On Mon, 10 Nov 2003, Pav Lucistnik wrote:
 
   #7  0xc054bf48 in g_destroy_provider (pp=0xc3e84000) at 
   /usr/src/sys/geom/geom_subr.c:416
   #8  0xc0548f25 in g_orphan_register (pp=0xc2e32700) at 
   /usr/src/sys/geom/geom_event.c:143
   #9  0xc054904c in one_event () at /usr/src/sys/geom/geom_event.c:169
   #10 0xc0549275 in g_run_events () at /usr/src/sys/geom/geom_event.c:202
   #11 0xc054a2a5 in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:134
   #12 0xc056dff0 in fork_exit (callout=0xc054a280 g_event_procbody, arg=0x0, 
   frame=0x0) at /usr/src/sys/kern/kern_fork.c:793
  
   (kgdb) up 7
   #7  0xc054bf48 in g_destroy_provider (pp=0xc3e84000) at 
   /usr/src/sys/geom/geom_subr.c:416
   416 devstat_remove_entry(pp-stat);
 
   (kgdb) print pp
   $1 = (struct g_provider *) 0xc3e84000
   (kgdb) print *pp
   $2 = {name = 0x0, provider = {le_next = 0x0, le_prev = 0x0}, geom = 0x0, 
   consumers = {lh_first = 0x0}, acr = 0, acw = 0, ace = 0, error = 0, orphan = 
   {tqe_next = 0x0, tqe_prev = 0x0}, index = 0,
 mediasize = 0, sectorsize = 0, stripesize = 0, stripeoffset = 0, stat = 0x0, 
   nstart = 0, nend = 0, flags = 0}
 
  What does pp look like in frame 8?

 $1 = {name = 0xc2da2250 acd0, provider = {le_next = 0xc07653e0, le_prev = 0x0}, 
 geom = 0xc0765404, consumers = {lh_first = 0x0}, acr = -1017072896, acw = 
 -1025385856, ace = -1025380968, error = 1,
   orphan = {tqe_next = 0xc04925a0, tqe_prev = 0x0}, index = 0, mediasize = 
 3226015152, sectorsize = 3226015776, stripesize = 3268839424, stripeoffset = 0, stat 
 = 0x0, nstart = 0, nend = 0, flags = 0}

There's something seriously foobared... is this panic repeatable or was it
a one timer?  ATAPI CD was GEOMified just a week ago, so there might
still be some bugs in.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


panic: Most recently used by mount

2003-11-09 Thread Lukas Ertl
/src/sys/vm/swap_pager.c:1323
 2nd 0xc07d2ec0 swap_pager swhash (swap_pager swhash) @ 
/usr/src/sys/vm/swap_pager.c:1838
 3rd 0xc103340c vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876
Stack backtrace:
---8---

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


new interrupt code: panic when going multiuser

2003-11-04 Thread Lukas Ertl
Hi,

I've yet to find out if I can get a good vmcore + backtrace, but I'm
having a machine that panics when going from singleuser to multiuser on
boot with a new kernel from today.

The panicking process is 'idle', the trap number is 30, and it says
unknown/reserved trap.  More info is coming as soon as I get a good
backtrace.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: new interrupt code: panic when going multiuser

2003-11-04 Thread Lukas Ertl
On Tue, 4 Nov 2003, Lukas Ertl wrote:

 I've yet to find out if I can get a good vmcore + backtrace, but I'm
 having a machine that panics when going from singleuser to multiuser on
 boot with a new kernel from today.

 The panicking process is 'idle', the trap number is 30, and it says
 unknown/reserved trap.  More info is coming as soon as I get a good
 backtrace.

I somehow can't get at a good vmcore :-(.  But I found out that the
machine boots fine in Safe Mode, where DMA and hw.ata.wc is turned off.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: new interrupt code: panic when going multiuser

2003-11-04 Thread Lukas Ertl
On Tue, 4 Nov 2003, Lukas Ertl wrote:

 I somehow can't get at a good vmcore :-(.  But I found out that the
 machine boots fine in Safe Mode, where DMA and hw.ata.wc is turned off.

Ok, if I set hw.ata.ata_dma=0 in loader.conf, it boots fine.  Could there
be some issue with ATAng + new interrupt code?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: new interrupt code: panic when going multiuser

2003-11-04 Thread Lukas Ertl
On Tue, 4 Nov 2003, John Baldwin wrote:


 On 04-Nov-2003 Lukas Ertl wrote:
  On Tue, 4 Nov 2003, Lukas Ertl wrote:
 
  I somehow can't get at a good vmcore :-(.  But I found out that the
  machine boots fine in Safe Mode, where DMA and hw.ata.wc is turned off.
 
  Ok, if I set hw.ata.ata_dma=0 in loader.conf, it boots fine.  Could there
  be some issue with ATAng + new interrupt code?

 Can you provide a dmesg please?  There may be a weird issue with
 some PPro's for example that I haven't been able to test.

Sorry for the noise, I think I found the problem: I had to put options
SMP and device apic into the kernel, now everythings seems to run fine.
I thought they were only needed for SMP kernels, that's at least what
the comment in GENERIC says...  If you still want the dmesg, I can send it
to you.

sorry,
regards.
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: new interrupt code: panic when going multiuser

2003-11-04 Thread Lukas Ertl
On Tue, 4 Nov 2003, John Baldwin wrote:

 Well, a kernel without SMP and just 'device apic' should work fine, and
 a kernel with both SMP and 'device apic' should also work fine.

But 'device apic' is necessary nowadays?  Maybe that should be noted
somewhere.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: hw.ata.atapi_dma problem

2003-11-04 Thread Lukas Ertl
On Tue, 4 Nov 2003, Harald Schmalzbauer wrote:

 ad0: 39083MB Maxtor 4D040H2 [79408/16/63] at ata0-master UDMA100
 acd0: CDROM SONY CDU4811 at ata1-master PIO4

 So dma is NOT enabled although the sysctl is 1

For ATAPI devices you need hw.ata.atapi_dma=1.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


panic in in_pcb.c:866

2003-11-03 Thread Lukas Ertl
Hi,

I'm not sure if this is a known problem; I'm getting the following panic
on my laptop quite often, with a kernel from Sun Nov  2 21:57:32 CET 2003.
The only active network interface is an ath(4) Cardbus WLAN card.

Backtrace is attached, if you need more info I have the backtrace
available:

---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x24
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc053e64b
stack pointer   = 0x10:0xcdcc3bb0
frame pointer   = 0x10:0xcdcc3bc4
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 = 13 (swi8: tty:sio clock)
Dumping 255 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
Reading symbols from /boot/kernel/ng_ubt.ko...done.
Loaded symbols for /boot/kernel/ng_ubt.ko
Reading symbols from /boot/kernel/netgraph.ko...done.
Loaded symbols for /boot/kernel/netgraph.ko
Reading symbols from
/usr/obj/usr/src/sys/KORBEN/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/KORBEN/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/KORBEN/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/KORBEN/modules/usr/src/sys/modules/linux/linux.ko.debug
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc044c885 in db_fncall (dummy1=0, dummy2=0, dummy3=0,
dummy4=0xcdcc39dc @EtÀ\f) at /usr/src/sys/ddb/db_command.c:548
#2  0xc044c5d2 in db_command (last_cmdp=0xc0743be0, cmd_table=0x0,
aux_cmd_tablep=0xc06fa4b0, aux_cmd_tablep_end=0xc06fa4b4)
at /usr/src/sys/ddb/db_command.c:346
#3  0xc044c715 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#4  0xc044f735 in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_trap.c:73
#5  0xc068c97c in kdb_trap (type=12, code=0, regs=0xcdcc3b70)
at /usr/src/sys/i386/i386/db_interface.c:171
#6  0xc069e4d6 in trap_fatal (frame=0xcdcc3b70, eva=0)
at /usr/src/sys/i386/i386/trap.c:818
#7  0xc069db23 in trap (frame=
  {tf_fs = -1068171240, tf_es = -1022427120, tf_ds = -1049821168,
tf_edi = 0, tf_esi = 36, tf_ebp = -842253372, tf_isp = -842253412, tf_ebx
= 0, tf_edx = -1066490503, tf_ecx = -1024585424, tf_eax = 36, tf_trapno =
12, tf_err = 0, tf_eip = -1068243381, tf_cs = 8, tf_eflags = 66195, tf_esp
= 14, tf_ss = -842253312})
at /usr/src/sys/i386/i386/trap.c:252
#8  0xc068e328 in calltrap () at {standard input}:102
#9  0xc053ea99 in _mtx_lock_sleep (m=0x24, opts=0, file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:635
#10 0xc05dafd9 in in_losing (inp=0xc2ed8460)
at /usr/src/sys/netinet/in_pcb.c:866
#11 0xc05ec414 in tcp_timer_rexmt (xtp=0xc2eda590)
at /usr/src/sys/netinet/tcp_timer.c:568
#12 0xc055b6de in softclock (dummy=0x0) at
/usr/src/sys/kern/kern_timeout.c:225
#13 0xc05331a8 in ithread_loop (arg=0xc16c0c80)
at /usr/src/sys/kern/kern_intr.c:540
#14 0xc0531e50 in fork_exit (callout=0xc0532fd0 ithread_loop, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:793
---

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: newfs by fstab directory name?

2003-10-27 Thread Lukas Ertl
On Mon, 27 Oct 2003, Wes Peters wrote:

 At work we do a lot of dynamic filesystem creation, so we added the
 ability to specify the 'special file' argument to newfs via the fstab
 mount point directory.  Please see the attached patch.  If nobody
 objects, I'll commit this in a couple of days.

Wouldn't this be a good candidate to be added directly to libufs?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: em0: invalid EEPROM checksum

2003-10-23 Thread Lukas Ertl
On Tue, 21 Oct 2003, Lukas Ertl wrote:

 I just found that the em0 interface in one of my boxes stopped working
 after an upgrade from 5.1-RELEASE to 5.1-CURRENT, this is what the kernel
 spits out:

 $ dmesg | grep em0
 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.16 port
 0xb000-0xb03f mem 0xe200-0xe201 irq 12 at device 5.0 on pci2
 em0: [MPSAFE]
 em0: The EEPROM Checksum Is Not Valid
 em0: Unable to initialize the hardware
 device_probe_and_attach: em0 attach returned 5

Oh, I forgot to add, this is what pciconf has to say about it:

[EMAIL PROTECTED]:5:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02
hdr=0x00
vendor   = 'Intel Corporation'
device   = '82544XT PRO/1000 MT Gigabit Ethernet Controller'
class= network
subclass = ethernet

A solution would be highly appriciated.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


em0: invalid EEPROM checksum

2003-10-21 Thread Lukas Ertl
Hi there,

I just found that the em0 interface in one of my boxes stopped working
after an upgrade from 5.1-RELEASE to 5.1-CURRENT, this is what the kernel
spits out:

$ dmesg | grep em0
em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.16 port
0xb000-0xb03f mem 0xe200-0xe201 irq 12 at device 5.0 on pci2
em0: [MPSAFE]
em0: The EEPROM Checksum Is Not Valid
em0: Unable to initialize the hardware
device_probe_and_attach: em0 attach returned 5

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Kernel build breaks in dev/cardbus

2003-10-19 Thread Lukas Ertl
Hi,

a buildkernel from a fresh cvsup breaks with these errors:

cc -O -pipe -mcpu=pentiumpro  -D_KERNEL -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual  -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I-   -I. -I@
-I@/../include -finline-limit=15000 -fno-common -g -mno-align-long-strings
-mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -std=c99 -c /usr/src/sys/dev/cardbus/cardbus.c
/usr/src/sys/dev/cardbus/cardbus_cis.c: In function `decode_tuple_copy':
/usr/src/sys/dev/cardbus/cardbus_cis.c:205: error: invalid application of
`sizeof' to an incomplete type
/usr/src/sys/dev/cardbus/cardbus_cis.c:209: error: invalid application of
`sizeof' to an incomplete type
/usr/src/sys/dev/cardbus/cardbus_cis.c:214: error: invalid use of
undefined type `struct cis_tupleinfo'
/usr/src/sys/dev/cardbus/cardbus_cis.c:214: error: dereferencing pointer
to incomplete type
/usr/src/sys/dev/cardbus/cardbus_cis.c:215: error: invalid use of
undefined type `struct cis_tupleinfo'
/usr/src/sys/dev/cardbus/cardbus_cis.c:215: error: dereferencing pointer
to incomplete type
/usr/src/sys/dev/cardbus/cardbus_cis.c:216: error: invalid use of
undefined type `struct cis_tupleinfo'
/usr/src/sys/dev/cardbus/cardbus_cis.c:216: error: dereferencing pointer
to incomplete type
/usr/src/sys/dev/cardbus/cardbus_cis.c:217: error: invalid use of
undefined type `struct cis_tupleinfo'
/usr/src/sys/dev/cardbus/cardbus_cis.c:217: error: dereferencing pointer
to incomplete type
/usr/src/sys/dev/cardbus/cardbus_cis.c: In function `cardbus_cis_free':
/usr/src/sys/dev/cardbus/cardbus_cis.c:1124: error: invalid use of
undefined type `struct cis_tupleinfo'
/usr/src/sys/dev/cardbus/cardbus_cis.c:1124: error: dereferencing pointer
to incomplete type
/usr/src/sys/dev/cardbus/cardbus.c:380: error: `card_cis_read_desc'
undeclared here (not in a function)
/usr/src/sys/dev/cardbus/cardbus.c:380: error: initializer element is not
constant
/usr/src/sys/dev/cardbus/cardbus.c:380: error: (near initialization for
`cardbus_methods[27].desc')
/usr/src/sys/dev/cardbus/cardbus.c:380: error: initializer element is not
constant
/usr/src/sys/dev/cardbus/cardbus.c:380: error: (near initialization for
`cardbus_methods[27]')
/usr/src/sys/dev/cardbus/cardbus.c:381: error: `card_cis_free_desc'
undeclared here (not in a function)
/usr/src/sys/dev/cardbus/cardbus.c:381: error: initializer element is not
constant
/usr/src/sys/dev/cardbus/cardbus.c:381: error: (near initialization for
`cardbus_methods[28].desc')
/usr/src/sys/dev/cardbus/cardbus.c:381: error: initializer element is not
constant
/usr/src/sys/dev/cardbus/cardbus.c:381: error: (near initialization for
`cardbus_methods[28]')
/usr/src/sys/dev/cardbus/cardbus.c:384: error: initializer element is not
constant
/usr/src/sys/dev/cardbus/cardbus.c:384: error: (near initialization for
`cardbus_methods[29]')
/usr/src/sys/dev/cardbus/cardbus.c:385: error: initializer element is not
constant
/usr/src/sys/dev/cardbus/cardbus.c:385: error: (near initialization for
`cardbus_methods[30]')
/usr/src/sys/dev/cardbus/cardbus.c:386: error: initializer element is not
constant
/usr/src/sys/dev/cardbus/cardbus.c:386: error: (near initialization for
`cardbus_methods[31]')
/usr/src/sys/dev/cardbus/cardbus.c:387: error: initializer element is not
constant
/usr/src/sys/dev/cardbus/cardbus.c:387: error: (near initialization for
`cardbus_methods[32]')
/usr/src/sys/dev/cardbus/cardbus.c:388: error: initializer element is not
constant
/usr/src/sys/dev/cardbus/cardbus.c:388: error: (near initialization for
`cardbus_methods[33]')
/usr/src/sys/dev/cardbus/cardbus.c:389: error: initializer element is not
constant
/usr/src/sys/dev/cardbus/cardbus.c:389: error: (near initialization for
`cardbus_methods[34]')
/usr/src/sys/dev/cardbus/cardbus.c:390: error: initializer element is not
constant
/usr/src/sys/dev/cardbus/cardbus.c:390: error: (near initialization for
`cardbus_methods[35]')
/usr/src/sys/dev/cardbus/cardbus.c:391: error: initializer element is not
constant
/usr/src/sys/dev/cardbus/cardbus.c:391: error: (near initialization for
`cardbus_methods[36]')
/usr/src/sys/dev/cardbus/cardbus.c:392: error: initializer element is not
constant
/usr/src/sys/dev/cardbus/cardbus.c:392: error: (near initialization for
`cardbus_methods[37]')
/usr/src/sys/dev/cardbus/cardbus.c:394: error: initializer element is not
constant
/usr/src/sys/dev/cardbus/cardbus.c:394: error: (near initialization for
`cardbus_methods[38]')
*** Error code 1
*** Error code 1
2 errors
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140

Re: IBCS2 compatibility regression in FreeBSD 5??

2003-10-16 Thread Lukas Ertl
On Thu, 16 Oct 2003, Paul Mather wrote:

 Does anyone know whether the IBCS2 emulation functionality regressed
 going from FreeBSD 4 to FreeBSD 5?  I ask because I have a
 statically-linked SCO binary that works under FreeBSD 4.8-STABLE but
 not under FreeBSD 5.1-RELEASE-p10 (or a version of 5.1-CURRENT).
 (This binary is the statically-linked SCO ADSM V2 client---practically
 the only solution for doing Tivoli TSM backup/archive under FreeBSD.)

I have exactly the same problem - the SCO ADSM client just borks.  I
managed to get around using the Linux client and some nullfs remounts -
ugly, but works more or less.

I've already written IBM, and of course they do not plan to release a
native client :-/.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Improvements to fsck performance in -current ...?

2003-10-01 Thread Lukas Ertl
On Tue, 30 Sep 2003, Steve Kargl wrote:

 On Wed, Oct 01, 2003 at 01:04:51AM +0200, Lukas Ertl wrote:
  
   are either of these enhancements back-patchable to the 4.x fsck, or do
   they require some non-4.x compatible changes to work?
 
  It's not just the fsck application itself, background fsck basically needs
  file system snapshots, which are only available on UFS2, and I'm not sure
  if they can be backported to UFS1 at all.

 As soon as Kirk committed the snapshot capability, snapshot became available
 on UFS1.  The only requirement is softupdates and softupdates pre-dates
 UFS2.

Oh, yeah, sorry, I think I got that wrong :-/.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Improvements to fsck performance in -current ...?

2003-09-30 Thread Lukas Ertl
On Tue, 30 Sep 2003, Marc G. Fournier wrote:

 Now,I don't/wouldn't have softupdates enabled on / .. does the 'background
 fsck' know to not background if softupdates are not enabled?

Yes, this is no problem, if the FS doesn't have SU, it just checks it the
old way.  Since / is usually rather small, this is acceptable.

  I suspect that these enhancements may both require that soft updates be
  enabled for the file systems.

 are either of these enhancements back-patchable to the 4.x fsck, or do
 they require some non-4.x compatible changes to work?

It's not just the fsck application itself, background fsck basically needs
file system snapshots, which are only available on UFS2, and I'm not sure
if they can be backported to UFS1 at all.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Panic in _mtx_lock_sleep

2003-09-23 Thread Lukas Ertl
=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:635
td = (struct thread *) 0x0
td1 = (struct thread *) 0x0
v = 0
#7  0xc0299f7d in tcp_timer_delack (xtp=0xc885f6f4)
at /usr/src/sys/netinet/tcp_timer.c:180
tp = (struct tcpcb *) 0xc885f6f4
inp = (struct inpcb *) 0x6
#8  0xc021181e in softclock (dummy=0x0) at
/usr/src/sys/kern/kern_timeout.c:225
c_func = (void (*)(void *)) 0xc0299f30 tcp_timer_delack
c_arg = (void *) 0xc885f6f4
c_flags = 6
c = (struct callout *) 0x0
bucket = (struct callout_tailq *) 0xd41daf80
curticks = 5219084
steps = 6
depth = 9
mpcalls = 2
gcalls = 7
#9  0xc01e9158 in ithread_loop (arg=0xc3b0cd00)
at /usr/src/sys/kern/kern_intr.c:534
ithd = (struct ithd *) 0xc3b0cd00
ih = (struct intrhand *) 0xc3b04a40
td = (struct thread *) 0xc3b0fd10
p = (struct proc *) 0xc3b0e3c8
#10 0xc01e7d91 in fork_exit (callout=0xc01e8f80 ithread_loop, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:796
p = (struct proc *) 0xc3b0e3c8
td = (struct thread *) 0x0


regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: latest -CURRENT kernel fails to build

2003-09-18 Thread Lukas Ertl
On Wed, 17 Sep 2003, Vincent Poy wrote:

 -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
 -Wcast-qual  -fformat-extensions -std=c99 -g -nostdinc -I-  -I.
 -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica
 -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath
 -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h
 -fno-common -finline-limit=15000 -fno-strict-aliasing
 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding
 -Werror  vers.c
 linking kernel.debug
 if_ath.o: In function `ath_attach':
 /usr/src/sys/dev/ath/if_ath.c:192: undefined reference to `ath_hal_attach'

Do you have device ath_hal in your kernel config?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


ath(4) stopped working

2003-09-16 Thread Lukas Ertl
Hi,

I just built a kernel with latest sources, unfortunately, my ath(4) card
stopped working.  The device is there, devd sets ip address, route etc.,
just as it did before the upgrade - the problem is that the link is dead,
there's _nothing_ going over the link.  It also seems to re-associate with
the AP quite often.

A kernel from Fri Sep 12 works correctly, with the same configuration.  I
guess the ath/ieee80211 commits from yesterday/today broke something.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ath(4) stopped working

2003-09-16 Thread Lukas Ertl
On Tue, 16 Sep 2003, Sam Leffler wrote:

  A kernel from Fri Sep 12 works correctly, with the same configuration.  I
  guess the ath/ieee80211 commits from yesterday/today broke something.

 I need more help than this.  Try supplying some information like the card
 type (e.g. 5212) and your setup (station, adhoc, hostap, 11a, 11b, 11g).

Yes, it's a 5212 card (a Netgear WAG511, to be more specific).  I'm using
it in 11g mode with a Netgear AP.

 Also try sysctl debug.ieee80211=1 and/or ifconfig ath0 debug and look at
 the debug messages.

Ok, here's what I got:

---8---
Sep 16 22:40:17 korben kernel: ath0: Atheros 5212 mem 0x2000-0x2000 irq 11 
at device 0.0 on cardbus1
Sep 16 22:40:17 korben kernel: ath0: [MPSAFE]
Sep 16 22:40:17 korben kernel: ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 
36Mbps 48Mbps 54Mbps
Sep 16 22:40:17 korben kernel: ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
Sep 16 22:40:17 korben kernel: ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 
12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
Sep 16 22:40:17 korben kernel: ath0: 802.11 address: 00:09:5b:41:8d:ac
Sep 16 22:40:17 korben kernel: ieee80211_newstate: INIT - SCAN
Sep 16 22:40:17 korben kernel: ieee80211_next_scan: chan 1-2
Sep 16 22:40:17 korben kernel: ieee80211_newstate: SCAN - SCAN
Sep 16 22:40:17 korben kernel: ieee80211_newstate: SCAN - INIT
Sep 16 22:40:17 korben kernel: ieee80211_newstate: INIT - SCAN
Sep 16 22:40:17 korben kernel: ieee80211_next_scan: chan 2-3
Sep 16 22:40:17 korben kernel: ieee80211_newstate: SCAN - SCAN
Sep 16 22:40:18 korben kernel: ieee80211_next_scan: chan 3-4
Sep 16 22:40:18 korben kernel: ieee80211_newstate: SCAN - SCAN
Sep 16 22:40:18 korben kernel: ieee80211_next_scan: chan 4-5
Sep 16 22:40:18 korben kernel: ieee80211_newstate: SCAN - SCAN
Sep 16 22:40:18 korben kernel: ieee80211_next_scan: chan 5-6
Sep 16 22:40:18 korben kernel: ieee80211_newstate: SCAN - SCAN
Sep 16 22:40:18 korben kernel: ieee80211_next_scan: chan 6-7
Sep 16 22:40:18 korben kernel: ieee80211_newstate: SCAN - SCAN
Sep 16 22:40:18 korben kernel: ieee80211_next_scan: chan 7-8
Sep 16 22:40:18 korben kernel: ieee80211_newstate: SCAN - SCAN
Sep 16 22:40:19 korben kernel: ieee80211_next_scan: chan 8-9
Sep 16 22:40:19 korben kernel: ieee80211_newstate: SCAN - SCAN
Sep 16 22:40:19 korben kernel: ieee80211_next_scan: chan 9-10
Sep 16 22:40:19 korben kernel: ieee80211_newstate: SCAN - SCAN
Sep 16 22:40:19 korben kernel: ieee80211_next_scan: chan 10-11
Sep 16 22:40:19 korben kernel: ieee80211_newstate: SCAN - SCAN
Sep 16 22:40:19 korben kernel: ieee80211_next_scan: chan 11-1
Sep 16 22:40:19 korben kernel: ieee80211_newstate: SCAN - SCAN
Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: new probe response on chan 1 (bss 
chan 1) LESSID from 00:09:5b:67:48:85
Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: caps 0x411 bintval 100 erp 0x0
Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: beacon on chan 1 (bss chan 1) 
LESSID from 00:09:5b:67:48:85
Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: caps 0x411 bintval 100 erp 0x0
Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: beacon on chan 1 (bss chan 1) 
LESSID from 00:09:5b:67:48:85
Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: caps 0x411 bintval 100 erp 0x0
Sep 16 22:40:19 korben kernel: ieee80211_next_scan: chan 1-2
Sep 16 22:40:19 korben kernel: ieee80211_newstate: SCAN - SCAN
Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: ignore probe response on channel 2 
marked for channel 1
Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: ignore beacon on channel 2 marked 
for channel 1
Sep 16 22:40:20 korben kernel: ieee80211_recv_mgmt: ignore beacon on channel 2 marked 
for channel 1
Sep 16 22:40:20 korben kernel: ieee80211_newstate: SCAN - AUTH
Sep 16 22:40:20 korben kernel: ieee80211_newstate: AUTH - ASSOC
Sep 16 22:40:20 korben kernel: ieee80211_newstate: ASSOC - RUN
Sep 16 22:40:36 korben kernel: ath_rate_ctl: 54M - 48M (1 ok, 9 err, 9 retr)
Sep 16 22:41:09 korben kernel: ath_rate_ctl: 48M - 36M (0 ok, 1 err, 1 retr)
Sep 16 22:41:10 korben kernel: ath_rate_ctl: 36M - 24M (0 ok, 1 err, 1 retr)
Sep 16 22:41:11 korben kernel: ath_rate_ctl: 24M - 18M (0 ok, 1 err, 1 retr)
Sep 16 22:41:12 korben kernel: ath_rate_ctl: 18M - 12M (0 ok, 1 err, 1 retr)
Sep 16 22:41:13 korben kernel: ath_rate_ctl: 12M - 11M (0 ok, 1 err, 1 retr)
---8---

The rate control shift at the end starts as soon as I start pinging some
hosts.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ATAng - delay probing for non-existent drive

2003-09-13 Thread Lukas Ertl
On Fri, 12 Sep 2003, Bryan Liesner wrote:

 The last change to ata-lowlevel (rev 1.11) causes a 10-15 second delay
 probing for a drive that's not there:

 ata2: at 0xb400 on atapci0
 ata2: [MPSAFE]

   hangs here for about 15 seconds

 ata3: at 0xa800 on atapci0
 ata3: [MPSAFE]

I can confirm this delay, but I haven't yet tried to revert ata-lowlevel.c
to rev. 1.10.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Bluetooth stack for FreeBSD (Netgraph)

2003-09-08 Thread Lukas Ertl
On Mon, 8 Sep 2003, Maksim Yevmenkin wrote:

 Dear Hackers,

 After a very long delay (sorry!) I'm pleased to announce that I'm still around
 and new a snapshot can be downloaded from

 http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030908.tar.gz

Max,

many thanks from a happy FreeBSD Bluetooth user!  I'm going to try the new
snapshot as soon as possible.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


New kernels won't boot

2003-09-05 Thread Lukas Ertl
Hi,

I'm currently having the problem that newer kernels won't boot anymore on
a HP Proliant DL380G3.  The latest kernel I can boot is from Sun Aug 31
15:22:44 CEST 2003.

Every attempt to boot a newer one (regardless whether UP or SMP) hangs at:

vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounter TSC frequency 2387622296 Hz quality 800
Timecounters tick every 10.000 msec

And then... silence.  Any ideas?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: New kernels won't boot

2003-09-05 Thread Lukas Ertl
On Fri, 5 Sep 2003, Lukas Ertl wrote:

 I'm currently having the problem that newer kernels won't boot anymore on
 a HP Proliant DL380G3.  The latest kernel I can boot is from Sun Aug 31
 15:22:44 CEST 2003.

 Every attempt to boot a newer one (regardless whether UP or SMP) hangs at:

 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
 Timecounter TSC frequency 2387622296 Hz quality 800
 Timecounters tick every 10.000 msec

Ok, I've found out that if I boot -v I get further than this and see the
following messages:

(probe9:ciss0:0:9:0): Request completed with CAM_REQ_CMP_ERR
(probe9:ciss0:0:9:0): error 5
(probe9:ciss0:0:9:0): Retries Exausted
(probe10:ciss0:0:10:0): Request completed with CAM_REQ_CMP_ERR
(probe10:ciss0:0:10:0): error 5
(probe10:ciss0:0:10:0): Retries Exausted
(probe11:ciss0:0:11:0): Request completed with CAM_REQ_CMP_ERR
(probe11:ciss0:0:11:0): error 5
(probe11:ciss0:0:11:0): Retries Exausted
(probe12:ciss0:0:12:0): Request completed with CAM_REQ_CMP_ERR
(probe12:ciss0:0:12:0): error 5
(probe12:ciss0:0:12:0): Retries Exausted
(probe13:ciss0:0:13:0): Request completed with CAM_REQ_CMP_ERR
(probe13:ciss0:0:13:0): error 5
(probe13:ciss0:0:13:0): Retries Exausted
(probe14:ciss0:0:14:0): Request completed with CAM_REQ_CMP_ERR
(probe14:ciss0:0:14:0): error 5
(probe14:ciss0:0:14:0): Retries Exausted
ciss0: command status 0x1 (target status) scsi status 0x2
(probe0:ciss0:0:0:0): error 22
(probe0:ciss0:0:0:0): Unretryable Error
ciss0: command status 0x1 (target status) scsi status 0x2
(probe1:ciss0:0:1:0): error 22

Anything CAM/SCSI-related?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Another pmap related panic

2003-08-26 Thread Lukas Ertl
On Fri, 22 Aug 2003, Mark Tinguely wrote:

 
   I got another pmap related panic on my HTT SMP machine.  If I don't get
   that completely wrong, it dies again after accessing the return value of
   pmap_pte_quick().

 I haven't buried myself in the 5.x pmap/vm code, but I did a visual inspection
 of the Bosko Milekic PSE changes and they do look correct to me -- good job.

 Do these crashes happen with the HTT turned off?

 It appears interesting that both sources of your panics are in a pv_list loop.
 I guess I don't know the vm_page_queue_mtx locking well enough, but I see
 asserts if MA_OWNED, but I see how these are set to limit one processor
 in the queue.

I have now applied Boskos Patch to a recent -CURRENT and also turned on
INVARIANTS - same panic, same place in pmap_is_modified().

A UP kernel seems to be ok, but I would need to let it run longer.

I'm starting to think of bad RAM.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Another pmap related panic

2003-08-26 Thread Lukas Ertl
On Tue, 26 Aug 2003, Mark Tinguely wrote:

 It could be a memory problem. Could you also please apply an assert
 to pmap_enter_quick() + INVARIANTS. This is a quick test that checks
 all the other paths that call pmap_enter_quick() are locked out so
 that two processors cannot be using the PADDR1/PMAP1 at the same time.

 --- pmap.c.orig   Mon Aug 25 08:46:03 2003
 +++ pmap.cTue Aug 26 07:16:06 2003
 @@ -2056,6 +2056,7 @@ pmap_enter_quick(pmap_t pmap, vm_offset_
   pt_entry_t *pte;
   vm_paddr_t pa;

 + mtx_assert(vm_page_queue_mtx, MA_OWNED);
   /*
* In the case that a page table page is not
* resident, we are creating it here.

This panics the machine at boot time:

panic: mutex vm page queue mutex not owned at /usr/src/sys/i386/i386/pmap.c:2012

cpuid = 0; lapic.id = 
Debugger(panic)
Stopped at  Debugger+0x55:  xchgl   %ebx,in_Debugger.0
db where
Debugger(c06809e2,0,c0680099,dff17880,100) at Debugger+0x55
panic(c0680099,c06910df,c0695c11,7dc,c0c35378) at panic+0x15f
_mtx_assert(c06e9800,1,c0695c11,7dc,c1a45600) at _mtx_assert+0xec
pmap_enter_quick(c25d60b0,8048000,c1a45600,0,7) at pmap_enter_quick+0x33
vm_map_pmap_enter(c25d6000,8048000,c0c35378,0,0) at vm_map_pmap_enter+0x26d
vm_map_insert(c25d6000,c0c35378,0,0,8048000) at vm_map_insert+0x2ef
elf32_map_insert(c25d6000,c0c35378,0,0,8048000) at elf32_map_insert+0x2ea
elf32_load_section(c25c7d3c,c25d6000,c67b77fc,c0c35378,0) at elf32_load_section+0x12a
exec_elf32_imgact(dff17b3c,0,c067e454,105,c06ddfe0) at exec_elf32_imgact+0x273
kern_execve(c25c8720,bfb2,bfbfffe4,0,0) at kern_execve+0x38c
execve(c25c8720,dff17cf0,0,0,dff17cd8) at execve+0x30
start_init(0,dff17d48,c067e5ac,314,0) at start_init+0x43e
fork_exit(c04cfbd0,0,dff17d48) at fork_exit+0xcf
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xdff17d7c, ebp = 0 ---

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Another pmap related panic

2003-08-26 Thread Lukas Ertl
On Tue, 26 Aug 2003, Mark Tinguely wrote:


 MY APOLOGIES, I am s embarrassed.

 I should have placed that in pmap_pte_quick(), not pmap_enter_quick().

This one panics, too, right at boot time.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Another pmap related panic

2003-08-22 Thread Lukas Ertl
 (/usr/src/sys/i386/i386/pmap.c:2836).
2831continue;
2832}
2833#endif
2834
2835pte = pmap_pte_quick(pv-pv_pmap, pv-pv_va);
2836pbits = *pte;
2837if (pbits  bit) {
2838if (bit == PG_RW) {
2839if (pbits  PG_M) {
2840vm_page_dirty(m);
(kgdb) quit
[EMAIL PROTECTED] crash]# exit

Script done on Fri Aug 22 10:01:07 2003

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ath0 card: CardBus card activiation failed

2003-08-21 Thread Lukas Ertl
On Wed, 20 Aug 2003, M. Warner Losh wrote:

 Looks like 1.91,1.92 broke things, and 1.93 fixes it.  Please let me
 know if I'm smoking the happy weed or not :-)

Yay, it works! :-)

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


ath0 card: CardBus card activiation failed

2003-08-20 Thread Lukas Ertl
Hi,

with a kernel from this morning I can't get my ath0 Cardbus device up
again, when I plug it in, I get:

cbb1: CardBus card activation failed

The card has worked fine up until now.  Maybe some of the recent commits
to pccbb.c/pccard.c broke something?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ath0 card: CardBus card activiation failed

2003-08-20 Thread Lukas Ertl
On Wed, 20 Aug 2003, Martin Jessa wrote:

 It works, unplug the card once or twice and try again.
 Same shit happens to me pretty frequently.

The card has worked _perfectly_ on first plug-in before I built the kernel
this morning, so I'd say there's a regression somewhere.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ath0 card: CardBus card activiation failed

2003-08-20 Thread Lukas Ertl
On Wed, 20 Aug 2003, M. Warner Losh wrote:

 In message: [EMAIL PROTECTED]
 Lukas Ertl [EMAIL PROTECTED] writes:
 : On Wed, 20 Aug 2003, Martin Jessa wrote:
 :
 :  It works, unplug the card once or twice and try again.
 :  Same shit happens to me pretty frequently.
 :
 : The card has worked _perfectly_ on first plug-in before I built the kernel
 : this morning, so I'd say there's a regression somewhere.

 When was your previous kernel?

Built last night after cvsup (times are CEST):

$ ls -l /boot/kernel.old/kernel
-r-xr-xr-x  1 root  wheel  4164476 20 Aug 00:03 /boot/kernel.old/kernel

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ath0 card: CardBus card activiation failed

2003-08-20 Thread Lukas Ertl
On Wed, 20 Aug 2003, M. Warner Losh wrote:

 In message: [EMAIL PROTECTED]
 Lukas Ertl [EMAIL PROTECTED] writes:
 : Built last night after cvsup (times are CEST):
 :
 : $ ls -l /boot/kernel.old/kernel
 : -r-xr-xr-x  1 root  wheel  4164476 20 Aug 00:03 /boot/kernel.old/kernel

 I was afraid you'd say that.  Are you building from a tree you check
 out of CVS, or a tree managed directly by cvsup?

A tree managed directly by cvsup.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ath0 card: CardBus card activiation failed

2003-08-20 Thread Lukas Ertl
On Wed, 20 Aug 2003, M. Warner Losh wrote:

 OK.  I think I can't do much more until I get home and try it again on
 my machine.  Unless you can back out last night's changes to pccbb.c
 and try again.  From the debug you sent me, that's the only thing in
 the loop.

Reverting to rev. 1.90 of pccbb.c fixes the problem and the card works
again.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Bluetooth on -current

2003-08-16 Thread Lukas Ertl
On Sat, 16 Aug 2003, Kim Culhan wrote:

 Does anyone know the status of Max Yevmenkin's bluetooth stack
 for -current?

 There appears to be bluetooth support with netgraph, is this working?

 Any expriences with bluetooth on -current are very greatly appreciated.

I've successfully used Bluetooth to connect to my mobile phone and use it
as a modem to connect to the internet.

So far, I'd say that Bluetooth support is fine in -CURRENT.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Bluetooth on -current

2003-08-16 Thread Lukas Ertl
On Sat, 16 Aug 2003, Kim Culhan wrote:

   Does anyone know the status of Max Yevmenkin's bluetooth stack
   for -current?

  I've successfully used Bluetooth to connect to my mobile phone and use it
  as a modem to connect to the internet.
 
  So far, I'd say that Bluetooth support is fine in -CURRENT.

 Would you describe the procedure you used to make this work?

I mostly followed the info on
http://www.oook.cz/bsd/handbook/bluetooth.html.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: driver maintainers, please help

2003-08-14 Thread Lukas Ertl
On Wed, 13 Aug 2003, Soeren Schmidt wrote:

  *) ata(4) - what are the supported UDMA levels for SiS 652, 751, and 752?

  { ATA_SIS652,  0x00, SIS_SOUTH, 0, ATA_UDMA6, SiS 652 }
  { ATA_SIS751,  0x00, SIS_SOUTH, 0, ATA_UDMA6, SiS 751 }
  { ATA_SIS752,  0x00, SIS_SOUTH, 0, ATA_UDMA6, SiS 752 }

 Or so it seems, it depends on the southbridge on the board, so this is
 the max, but depending on the actual HW it can be UDMA5.

Thanks, Soren.

 The ATA driver is in violent flux currently, but I will update the
 man page when I'm done with the changes..

So would you like to handle docs/55512 yourself?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


buildworld breaks

2003-08-14 Thread Lukas Ertl
Hi,

buildworld is current broken:

=== sys/boot/i386/libi386
cc -O -pipe -mcpu=pentiumpro -ffreestanding -DCOMPORT=0x3f8 -DCOMSPEED=9600 -DTERM_EMU 
-I/usr/src/sys/boot/i386/libi386/../../common 
-I/usr/src/sys/boot/i386/libi386/../btx/lib  
-I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica  
-I/usr/src/sys/boot/i386/libi386/../../.. -I. 
-I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -ffreestanding 
-mpreferred-stack-boundary=2   -c /usr/src/sys/boot/i386/libi386/biosacpi.c
In file included from /usr/src/sys/contrib/dev/acpica/acfreebsd.h:165,
 from /usr/src/sys/boot/i386/libi386/biosacpi.c:33:
/usr/obj/usr/src/i386/usr/include/ctype.h:88: error: syntax error before int
*** Error code 1

Stop in /usr/src/sys/boot/i386/libi386.
*** Error code 1

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Weird reboots from bootmgr or loader

2003-08-14 Thread Lukas Ertl
On Tue, 5 Aug 2003, Florian Smeets wrote:

 I got a really anoying Problem today. 3 different boxes started to reboot
 when i hit enter at the bootmgr, or when i don't hit enter and wait for it
 to boot FreeBSD it reboots when the loader should apear. I can see that it
 prints out some numbers but its to fast to recognise anything. I did not
 mess with the disk configuration on any of the boxes. I only rebuild world
 and kernel as usual every few days. They all had sources from 3rd or 4th
 of august. I don't have my serial cable handy i'll try to get it back this

I saw _exactly_ the same problem on one of my boxes today: it was
shutdowned correctly yesterday, and today it wouldn't boot, but panic
right after boot0. The only thing I could see were some hex numbers and
BTX halted for a split second, then immediately reboot. It's a -current
box from Sunday evening CEST.

I managed to fix it by booting from floppies and running the Fixit floppy,
writing a new disklabel, which seems to have become corrupted somehow.

HTH,
regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ffsinfo missing in 5.1-RELEASE

2003-08-14 Thread Lukas Ertl
On Wed, 13 Aug 2003, Robert Watson wrote:

 The only problem with this patch is that we lose the ability to do the
 START BLOCK SUMMARY AND POSITION TABLE display for UFS1.  I'm not sure
 this is a big issue; I will go ahead and commit it with those #ifdef'd
 out (rather than removed as is the case in the patch) and look for advice
 on reintroducing them from someone with more UFS expertise than me.

Robert,

I'll have a look at it once it's back in the tree, maybe I find out what
to do about it.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ffsinfo missing in 5.1-RELEASE

2003-08-14 Thread Lukas Ertl
On Wed, 13 Aug 2003, Ulrich Spoerlein wrote:

 I just used growfs (nice tool btw) and noticed that growfs(8) has a
 reference to ffsinfo(8). But neither ffsinfo(8) nor the binary are
 present on my 5.1 System.

I already submitted a PR bin/53517, which has a patch that repairs ffsinfo
on -CURRENT.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: buildworld breaks

2003-08-14 Thread Lukas Ertl
On Thu, 7 Aug 2003, Lukas Ertl wrote:

 buildworld is current broken:

 === sys/boot/i386/libi386
 cc -O -pipe -mcpu=pentiumpro -ffreestanding -DCOMPORT=0x3f8 -DCOMSPEED=9600 
 -DTERM_EMU -I/usr/src/sys/boot/i386/libi386/../../common 
 -I/usr/src/sys/boot/i386/libi386/../btx/lib  
 -I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica  
 -I/usr/src/sys/boot/i386/libi386/../../.. -I. 
 -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -ffreestanding 
 -mpreferred-stack-boundary=2   -c /usr/src/sys/boot/i386/libi386/biosacpi.c
 In file included from /usr/src/sys/contrib/dev/acpica/acfreebsd.h:165,
  from /usr/src/sys/boot/i386/libi386/biosacpi.c:33:
 /usr/obj/usr/src/i386/usr/include/ctype.h:88: error: syntax error before int
 *** Error code 1

 Stop in /usr/src/sys/boot/i386/libi386.
 *** Error code 1

I think I found the error:

Rev. 1.18 of sys/contrib/dev/acpica/acfreebsd.h introduced an '#include
ctype.h', which has a declaration of isascii().  The problem is that
biosacpi.c includes stand.h, which defines isascii() already, and you end
up with this (from the preprocessor output):

int _tolower(int);
int _toupper(int);
int (((int)  ~0x7F) == 0);
int toascii(int);

So either remove the inclusion if ctype.h in acfreebsd.h or remove the
inclusion of stand.h in biosacpi.c.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: [HEADSDOWN] swap_pager.c calming down...

2003-08-14 Thread Lukas Ertl
On Wed, 6 Aug 2003, Poul-Henning Kamp wrote:

 In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
 Hello Poul,
 
 Can you please look into problems reported on current@ list,
 the thread with subject Weird reboots from bootmgr or loader,
 as it seems to related with your recent changes for the swap code.

 There is no way my work could cause reboots from the bootmgr or loader.

It seems to be related to the fact that some people have swap as their
first partition.

John-Mark Gurney said:

| If so, make sure your swap isn't at the start of
| your disk.  If it is, phk was nice enough to only blow away your boot
| blocks instead of your disk label too. :)  Swap currently uses all but
| the first page (4k on i386).

My disklabel looks like this:

$ bsdlabel ad0s1
# /dev/ad0s1:
8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  a:   307200  10488574.2BSD 2048 16384 0
  b:  10485760  swap
  c: 1562963220unused0 0 # raw part, don't edit
  d: 155247730  1048592 vinum

And since a few days, whenever I install a new world/kernel, I need to
boot a fixit floppy and rewrite the boot blocks/disklabel.  You're sure
there's no relation between your recent swap changes?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Weird reboots from bootmgr or loader

2003-08-14 Thread Lukas Ertl
On Tue, 5 Aug 2003, John-Mark Gurney wrote:

 Are you running -current w/ a kernel from the last 24 hrs?  (After phk's
 mass swap check in?)  If so, make sure your swap isn't at the start of
 your disk.  If it is, phk was nice enough to only blow away your boot
 blocks instead of your disk label too. :)  Swap currently uses all but
 the first page (4k on i386).

Argl, YES, swap _is_ the first partition:

$ bsdlabel ad0s1
# /dev/ad0s1:
8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  a:   307200  10488574.2BSD 2048 16384 0
  b:  10485760  swap
  c: 1562963220unused   0 0 # raw part, don't edit
  d: 155247730  1048592 vinum

As you can see, first comes swap, then the rest of the drive is dedicated
to vinum.

Does that mean I have to rearranged or never build world again?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


driver maintainers, please help

2003-08-14 Thread Lukas Ertl
Hi there,

this is a call for help from the various driver maintainers.  In a recent
discussion on -doc it has come out that several manpages are not in sync
with what's listed in the 5.1 Hardware Notes, and I'm currently trying to
update those manpages.  Unfortunately, for some devices (especially older
ones) I'd need some info that I just can't find on the web, so I hope some
of the maintainers or authors can give me a hint (and of course anyone
else who knows).

What I would like to know so far:

*) ata(4) - what are the supported UDMA levels for SiS 652, 751, and 752?
*) Adaptec 1510 and 1535 - are these supported by aha(4)?

I'm sure there's more to come but this is all for now.

Of course, it would be very helpful here if the driver maintainers could
have a look at their manpages and compare them to the Hardware Notes and
catch up with what isn't in the respective man page.

Thanks so far,
regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: New panics

2003-08-14 Thread Lukas Ertl
On Mon, 11 Aug 2003, Lukas Ertl wrote:

 Closest comes pmap_is_modified, I guess.

Gang,

I gladly managed to get a crashdump on the latest panic.  It's now clear
it happends in pmap_is_modified().

This is a FreeBSD 5.1-CURRENT #18: Tue Aug 12 18:42:23 CEST 2003 kernel,
but with the DISABLE_PSE patch from Bosko (I don't think it has to do with
the patch - the same panic happened before, too).

Following is the DDB backtrace and the bt and bt full from gdb.

Stopped at  pmap_is_modified+0x75:  testb   $0x40,0(%eax)
db trace
pmap_is_modified(c1d2bb30,0,e19a4b90,c0551956,c1d2bb30) at pmap_is_modified+0x75
vm_page_test_dirty(c1d2bb30,40,d2d25f10,c68e7248,d2f93978) at vm_page_test_dirty+0x1a
vfs_setdirty(d2f93978,2137000,0,d2f93978,d2f93978) at vfs_setdirty+0x136
vfs_busy_pages(d2f93978,1,d2d71078,0,c40) at vfs_busy_pages+0x3c
bwrite(d2f93978,4000,c3f,0,67380) at bwrite+0x380
vfs_bio_awrite(d2f93978,12,c653a260,c653a260,c653a260) at vfs_bio_awrite+0x289
flushbufqueues(0,c06fce40,44,c06a2842,64) at flushbufqueues+0x227
buf_daemon(0,e19a4d48,0,0,0) at buf_daemon+0x13c
fork_exit(c0550e40,0,e19a4d48) at fork_exit+0xb1
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe19a4d7c, ebp = 0 ---


Script started on Wed Aug 13 14:17:29 2003
[EMAIL PROTECTED] crash]# gdb -k kernel.5 vmcore.5
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 2; lapic.id = 0600
fault virtual address   = 0xbfcadf10
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc065eee5
stack pointer   = 0x10:0xe19a4b44
frame pointer   = 0x10:0xe19a4b50
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 = 40 (bufdaemon)
Dumping 1023 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 
384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 
720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
---
Reading symbols from 
/usr/obj/usr/src/sys/NEWSCORE/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for 
/usr/obj/usr/src/sys/NEWSCORE/modules/usr/src/sys/modules/acpi/acpi.ko.debug
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc04495d5 in db_fncall (dummy1=0, dummy2=0, dummy3=1999,
dummy4=0xe19a4928 àRnÀÈ\203rÀDI\232á\r)
at /usr/src/sys/ddb/db_command.c:548
#2  0xc0449322 in db_command (last_cmdp=0xc06e4980, cmd_table=0x0,
aux_cmd_tablep=0xc06b5fb8, aux_cmd_tablep_end=0xc06b5fbc)
at /usr/src/sys/ddb/db_command.c:346
#3  0xc0449465 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#4  0xc044c485 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
#5  0xc064780c in kdb_trap (type=12, code=0, regs=0xe19a4b04)
at /usr/src/sys/i386/i386/db_interface.c:172
#6  0xc0661b86 in trap_fatal (frame=0xe19a4b04, eva=0)
at /usr/src/sys/i386/i386/trap.c:816
#7  0xc0661832 in trap_pfault (frame=0xe19a4b04, usermode=0, eva=3217743632)
at /usr/src/sys/i386/i386/trap.c:735
#8  0xc066138d in trap (frame=
  {tf_fs = -958660584, tf_es = 409141264, tf_ds = -463536112, tf_edi = -964805744, 
tf_esi = -755418760, tf_ebp = -509981872, tf_isp = -509981904, tf_ebx = -579812704, 
tf_edx = 409186304, tf_ecx = -463514956, tf_eax = -1077223664, tf_trapno = 12, tf_err 
= 0, tf_eip = -1067061531, tf_cs = 8, tf_eflags = 66050, tf_esp = -958598736, tf_ss = 
729563136}) at /usr/src/sys/i386/i386/trap.c:420
#9  0xc0649248 in calltrap () at {standard input}:103
#10 0xc061c1fa in vm_page_test_dirty (m=0xdd70c2a0)
at /usr/src/sys/vm/vm_page.c:1700
#11 0xc0551956 in vfs_setdirty (bp=0xd2f93978)
at /usr/src/sys/kern/vfs_bio.c:2297
#12 0xc055399c in vfs_busy_pages (bp=0xc67e3b90, clear_modify=1)
at /usr/src/sys/kern/vfs_bio.c:3335
#13 0xc054dff0 in bwrite (bp=0xd2f93978) at /usr/src/sys/kern/vfs_bio.c:859
#14 0xc05505d9 in vfs_bio_awrite (bp=0xd2f93978)
at /usr/src/sys/kern/vfs_bio.c:1707
#15 0xc0551417 in flushbufqueues (flushdeps=0)
at /usr/src/sys/kern/vfs_bio.c:2169
#16 0xc0550f7c in buf_daemon () at /usr/src/sys/kern/vfs_bio.c:2070
#17 0xc04ec991 in fork_exit (callout=0xc0550e40 buf_daemon, arg=0x0,
---Type return to continue, or q return to quit---
frame=0x0) at /usr/src/sys/kern/kern_fork.c:790
(kgdb) bt full
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c

New panics

2003-08-14 Thread Lukas Ertl
 = {lo_class = 0xc03c9aec,
lo_name = 0xc039bfd7 g_xup, lo_type = 0xc039bfd7 g_xup,
lo_flags = 196608, lo_list = {tqe_next = 0x0, tqe_prev = 0x0},
lo_witness = 0x0}, mtx_lock = 3256655424, mtx_recurse = 0, mtx_blocked = {
tqh_first = 0x0, tqh_last = 0xdf150cd4}, mtx_contested = {le_next = 0x0,
le_prev = 0x0}}
#13 0xc01c8c38 in g_up_procbody () at /usr/src/sys/geom/geom_kern.c:92
p = (struct proc *) 0x0
tp = (struct thread *) 0xc21c9e40
#14 0xc01ec6d1 in fork_exit (callout=0xc01c8c10 g_up_procbody, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:790
td = (struct thread *) 0x0
---Type return to continue, or q return to quit---
p = (struct proc *) 0xc60931e4
(kgdb) quit
[EMAIL PROTECTED] crash]# exit

Script done on Sun Aug 10 22:12:40 2003

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: -current want't boot this morning

2003-08-14 Thread Lukas Ertl
On Thu, 7 Aug 2003, Gordon Bergling wrote:

 I tried to boot my -current this morning but the boot process only goes
 to bootmgr. She shows normal

 F1FreeBSD
 F2Other   (not sure if this is (Other||Unknown)

 After pressing F1-Key the computer resets himself. I tried to wait but
 on autoboot the same thing happens.

Let me guess: your swap partition is the first partition?

 The -current was build yesterday with recent sources.

You need to boot a fixit floppy and re-write your bootblocks. Then cvsup
to the very latest -current. This problem should be fixed already.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: New panics

2003-08-11 Thread Lukas Ertl
On Sun, 10 Aug 2003, Lukas Ertl wrote:

 5.1-CURRENT FreeBSD 5.1-CURRENT #12: Wed Aug  6 21:49:32 CEST 2003

 Fatal trap 12: page fault while in kernel mode
 cpuid = 3; lapic.id = 0700
 fault virtual address = 0xbfcb09a0
 fault code= supervisor read, page not present
 instruction pointer   = 0x8:0xc035ea65
 stack pointer = 0x10:0xe0ba4acc
 frame pointer = 0x10:0xe0ba4ad8
 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   = 40 (bufdaemon)
 trap number   = 12
 panic: page fault
 cpuid = 3; lapic.id = 0700
 boot() called on cpu#3

 syncing disks, buffers remaining...

 Fatal trap 12: page fault while in kernel mode
 cpuid = 3; lapic.id = 0700
 fault virtual address = 0x24
 fault code= supervisor read, page not present
 instruction pointer   = 0x8:0xc01f8ddb
 stack pointer = 0x10:0xdf150b74
 frame pointer = 0x10:0xdf150b88
 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   = 3 (g_up)
 trap number   = 12
 panic: page fault
 cpuid = 3; lapic.id = 0700
 boot() called on cpu#3
 Uptime: 1d0h49m45s
 Dumping 1023 MB
  16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 
 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 
 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
 ---

Forget that backtrace, at least for this current problem, it seems like
the kernel panicked inside the coredump routine again, and I got the
coredump of the second panic :-/. (This would correspond to the
instruction pointer of the second panic, which shows as
propagate_priority in nm kernel.

If I run nm /usr/local/crash/kernel.3 | grep c035e (the IP of the first
panic message), I get this:

c035ef70 t i386_protection_init
c035e030 T pmap_change_wiring
c035ecf0 T pmap_clear_modify
c035ee30 T pmap_clear_reference
c035e0a0 T pmap_copy
c035e690 T pmap_copy_page
c035e9f0 T pmap_is_modified
c035efb0 T pmap_mapdev
c035e7e0 T pmap_page_exists_quick
c035ea90 T pmap_page_protect
c035e840 T pmap_remove_pages
c035ebf0 T pmap_ts_referenced
c035e390 T pmap_zero_page
c035e4c0 T pmap_zero_page_area
c035e5f0 T pmap_zero_page_idle
c035e350 t pmap_zpi_switchin12
c035e370 t pmap_zpi_switchin2
c035e380 t pmap_zpi_switchin3

Closest comes pmap_is_modified, I guess.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: [Fwd: cvs commit: src/sys/i386/i386 pmap.c]

2003-08-10 Thread Lukas Ertl
On Wed, 6 Aug 2003, Alan L. Cox wrote:

 If your i386 system has panic()ed in pmap_remove_all() recently, I would
 encourage you to update your pmap.c.

This is definitely good news! Thanks!

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Weird reboots from bootmgr or loader

2003-08-06 Thread Lukas Ertl
On Tue, 5 Aug 2003, Florian Smeets wrote:

 Lukas Ertl wrote:
  I managed to fix it by booting from floppies and running the Fixit floppy,
  writing a new disklabel, which seems to have become corrupted somehow.
 

 Yes this really did the trick! :-)

May I ask if you boot from a vinum volume?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ath0 driver

2003-08-06 Thread Lukas Ertl
On Wed, 6 Aug 2003, Sam Leffler wrote:

 Verify you have the latest HAL using

 sysctl hw.ath

 The version should be 0.9.5.3 or better (can't remember if I committed .4
 or .3).

Shouldn't that be 0.9.5.2?  I run the latest current, and
hw.ath.hal.version is 0.9.5.2.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Bootstrap: Machine keeps booting ? (boot0/mbr) ?

2003-08-06 Thread Lukas Ertl
On Wed, 6 Aug 2003, Stephan van Beerschoten wrote:

 I installed the Bootloader for my dualboot machine, and when it comes up
 during boot:

 F1 ??
 F2 FreeBSD

 and I press F2, it autmatically reboots again. Please note it DID work
 yesterday, but somehow my laptops keeps booting on my now. (-CURRENT ?
 why?)

You probably have your swap partition as the first partition on your
drive.  Boot up to a fixit floppy and rewrite your boot blocks.  Then
re-cvsup to the very latest current, phk@ has already fixed this problem.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


panic every few hours, pmap related?

2003-08-05 Thread Lukas Ertl
va = 3218006016
vm = (struct vmspace *) 0x0
map = 0x1
rv = 1
ftype = 2 '\002'
td = (struct thread *) 0xc613a390
p = (struct proc *) 0xc6139d3c
#10 0xc036141d in trap (frame=
  {tf_fs = -963313640, tf_es = 409075728, tf_ds = -474808304, tf_edi = 
-1057538592, tf_esi = 16, tf_ebp = -524649808, tf_isp = -524649852, tf_ebx = 
-1044790456, tf_edx = 0, tf_ecx = -474795080, tf_eax = -1076958608, tf_trapno = 12, 
tf_err = 2, tf_eip = -1070213752, tf_cs = 8, tf_eflags = 66118, tf_esp = -963262032, 
tf_ss = 1000980480}) at /usr/src/sys/i386/i386/trap.c:420
td = (struct thread *) 0xc613a390
p = (struct proc *) 0xc6139d3c
sticks = 3323175824
i = 0
ucode = 0
type = 12
code = 2
eva = 3218008688
#11 0xc0349298 in calltrap () at {standard input}:103
No locals.
#12 0xc0253a08 in vfs_busy_pages (bp=0xc0f73de0, clear_modify=1)
at /usr/src/sys/kern/vfs_bio.c:3370
m = 0xc1b9c348
obj = 0x0
foff = 7438336
---Type return to continue, or q return to quit---
i = 16
bogus = 0
#13 0xc024df20 in bwrite (bp=0xd28d1d48) at /usr/src/sys/kern/vfs_bio.c:859
oldflags = 1677721604
newbp = (struct buf *) 0xd298d638
#14 0xc024eb0c in bawrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1148
No locals.
#15 0xc0257f2e in cluster_wbuild (vp=0xc6437b68, size=16384, start_lbn=456,
len=6) at /usr/src/sys/kern/vfs_cluster.c:985
bp = (struct buf *) 0xd28d1d48
tbp = (struct buf *) 0xd298d638
i = 6
j = 4
totalwritten = 98304
dbsize = 32
#16 0xc02504dd in vfs_bio_awrite (bp=0xd29fdc08)
at /usr/src/sys/kern/vfs_bio.c:1691
i = 6
j = 0
lblkno = 450
vp = (struct vnode *) 0xc6437b68
ncl = 0
nwritten = 0
size = 16384
maxcl = 8
#17 0xc02f6872 in ffs_fsync (ap=0xe0ba7cc4)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:268
vp = (struct vnode *) 0xc6437b68
ip = (struct inode *) 0xd29fdc08
bp = (struct buf *) 0xd29fdc08
nbp = (struct buf *) 0xd2b9cf00
error = 0
wait = 0
passes = 4
skipmeta = 0
---Type return to continue, or q return to quit---
lbn = 456
#18 0xc02622b4 in sched_sync () at vnode_if.h:627
slp = (struct synclist *) 0xc61994ec
vp = (struct vnode *) 0xc6437b68
mp = (struct mount *) 0xc636b200
starttime = 1060033156
td = (struct thread *) 0xc613a390
#19 0xc01ec621 in fork_exit (callout=0xc02620b0 sched_sync, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:794
td = (struct thread *) 0x0
p = (struct proc *) 0xc6139d3c
(kgdb) quit
[EMAIL PROTECTED] crash]# exit

Script done on Mon Aug  4 23:58:35 2003

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: panic every few hours, pmap related?

2003-08-05 Thread Lukas Ertl
On Tue, 5 Aug 2003, Poul-Henning Kamp wrote:


 If you are running with version 1.64 or later of sys/geom/geom_dev.c,
 try updating to you get my patches from this morning.

 If that doesn't help, try commenting out the Giant drop/pickup
 around the call to strategy in fs/specfs/specfs_vnops.c

I tried that, but unfortunately the problem still exists :-/

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Bug in GEOM or in gstat?

2003-08-04 Thread Lukas Ertl
Hi there,

when running gstat I'm seeing things like this:

dT: 0.509  flag_I 50us  sizeof 240  i -1
 L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/w   %busy Name
1189149   21136.2 39785   20.6   87.8| da0
1226218   8891   14.2  8785   24.6   94.3| da1
0104 49   2144   10.7 55   7037   34.0   58.3| da2
1189149   21136.2 39785   20.9   88.4| da0s1
1226218   8891   14.2  8785   24.7   94.4| da1s1
0104 49   2144   10.8 55   7037   34.1   58.4| da2s1
0  0  0  00.0  0  00.00.0| da0s1a
0  2  2  8   10.9  0  00.02.1| da0s1b
0  0  0  00.0  0  00.00.0| da0s1c
0  0  0  00.0  0  00.00.0| da0s1d
0  0  0  00.0  0  00.00.0| da0s1e
0  0  0  00.0  0  00.00.0| da0s1f
 4294967295187147   21056.2 39785   21.2   99.0| da0s1g
0  0  0  00.0  0  00.00.0| da1s1c
0  0  0  00.0  0  00.00.0| da1s1d
 4294967295226218   8891   14.3  8785   24.8   89.7| da1s1e
0  0  0  00.0  0  00.00.0| da2s1c
0  0  0  00.0  0  00.00.0| da2s1d
0104 49   2144   10.8 55   7037   34.3   58.5| da2s1e

Notice the high numbers in the L(q) row, this seems like an underflow
somewhere.  The numbers don't stay like that, they are fluctuating.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Bug in GEOM or in gstat?

2003-08-04 Thread Lukas Ertl
On Mon, 4 Aug 2003, Poul-Henning Kamp wrote:


 Hi Lucas,

 Which versions ?  5.0, 5.1 or -current ?

CURRENT from this morning CEST.

 Does the large numbers persist when the system is idle, or do they
 fall back to zero ?

This is a snapshot from an idle system:

dT: 0.510  flag_I 50us  sizeof 240  i -1
 L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/w   %busy Name
0  4  0  00.0  4 63   10.52.6| da0
0 20  0  00.0 20314   25.1   10.0| da1
0  2  0  00.0  2 318.51.7| da2
0  4  0  00.0  4 63   10.62.6| da0s1
0 20  0  00.0 20314   25.2   10.0| da1s1
0  2  0  00.0  2 318.51.7| da2s1
0  0  0  00.0  0  00.00.0| da0s1a
0  0  0  00.0  0  00.00.0| da0s1b
0  0  0  00.0  0  00.00.0| da0s1c
0  0  0  00.0  0  00.00.0| da0s1d
0  0  0  00.0  0  00.00.0| da0s1e
0  0  0  00.0  0  00.00.0| da0s1f
 4294967293  4  0  00.0  4 63   10.6  561.0| da0s1g
0  0  0  00.0  0  00.00.0| da1s1c
0  0  0  00.0  0  00.00.0| da1s1d
 4294967294 20  0  00.0 20314   25.2   10.0| da1s1e
0  0  0  00.0  0  00.00.0| da2s1c
0  0  0  00.0  0  00.00.0| da2s1d
0  2  0  00.0  2 318.51.7| da2s1e

561% busy is nice, too :-)

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Bug in GEOM or in gstat?

2003-08-04 Thread Lukas Ertl
On Mon, 4 Aug 2003, Lukas Ertl wrote:

 This is a snapshot from an idle system:

 dT: 0.510  flag_I 50us  sizeof 240  i -1
 0  0  0  00.0  0  00.00.0| da0s1f
  4294967293  4  0  00.0  4 63   10.6  561.0| da0s1g
 0  0  0  00.0  0  00.00.0| da1s1c
 0  0  0  00.0  0  00.00.0| da1s1d
  4294967294 20  0  00.0 20314   25.2   10.0| da1s1e

To clarify that: on the idle system the high numbers for L(q) don't fall
back to 0 again.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


ath(4) related panic after suspend/resume

2003-08-04 Thread Lukas Ertl
Hi,

I got the following panic after resuming from apm suspend state on my
laptop with a Netgear WAG511 PCMCIA card.

$ uname -a
FreeBSD korben 5.1-CURRENT FreeBSD 5.1-CURRENT #22: Sun Aug  3 14:25:10
CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KORBEN  i386


Script started on Tue Aug  5 00:03:34 2003
[EMAIL PROTECTED] crash]# gdb -k kernel.debug vmcore.3
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: resource_list_release: can't find resource
panic messages:
---
panic: resource_list_release: can't find resource

syncing disks, buffers remaining... 1892 1892 1892 1892 1892 1892 1892 1892 1892 1892 
1892 1892 1892 1892 1892 1892 1891 1891 1891 1891 1891 1891 1891 1891 1891 1891 1891 
1891 1891 1891 1891 1891 1891 1891 1891 1891
giving up on 1088 buffers
Uptime: 5h28m23s
Dumping 255 MB
ata0: resetting devices ..
done
[CTRL-C to abort]  16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
Reading symbols from 
/usr/obj/usr/src/sys/KORBEN/modules/usr/src/sys/modules/apm/apm.ko.debug...done.
Loaded symbols for 
/usr/obj/usr/src/sys/KORBEN/modules/usr/src/sys/modules/apm/apm.ko.debug
Reading symbols from /boot/kernel/ng_ubt.ko...done.
Loaded symbols for /boot/kernel/ng_ubt.ko
Reading symbols from /boot/kernel/netgraph.ko...done.
Loaded symbols for /boot/kernel/netgraph.ko
Reading symbols from 
/usr/obj/usr/src/sys/KORBEN/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for 
/usr/obj/usr/src/sys/KORBEN/modules/usr/src/sys/modules/linux/linux.ko.debug
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt full
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
No locals.
#1  0xc0241154 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
No locals.
#2  0xc02414f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
td = (struct thread *) 0xc0ecb390
bootopt = 256
newpanic = 0
ap = 0xcd23eb24 \001
buf = resource_list_release: can't find resource, '\0' repeats 213 times
#3  0xc025b6c5 in resource_list_release (rl=0x0, bus=0xc0ec9c00,
child=0xc266bd00, type=1, rid=0, res=0xc260a080)
at /usr/src/sys/kern/subr_bus.c:1673
rle = (struct resource_list_entry *) 0x0
#4  0xc025c288 in bus_generic_rl_release_resource (dev=0xc0ec9c00,
child=0xc266bd00, type=0, rid=0, r=0x0)
at /usr/src/sys/kern/subr_bus.c:1990
rl = (struct resource_list *) 0x0
#5  0xc025c639 in bus_release_resource (dev=0x0, type=1, rid=0, r=0xc260a080)
at bus_if.h:133
No locals.
#6  0xc01686e4 in ath_pci_attach (dev=0xc266bd00)
at /usr/src/sys/dev/ath/if_ath_pci.c:204
psc = (struct ath_pci_softc *) 0xc0ec9c00
sc = (struct ath_softc *) 0xc32aa000
cmd = 3260490032
error = 12
rid = 0
#7  0xc025ae5a in device_probe_and_attach (dev=0xc266bd00) at device_if.h:39
bus = 0xc252d098
error = -1033454336
hasclass = 0
#8  0xc016947f in cardbus_attach_card (cbdev=0xc0ec9c00)
at /usr/src/sys/dev/cardbus/cardbus.c:200
dinfo = (struct cardbus_devinfo *) 0xc266bd00
---Type return to continue, or q return to quit---
cardbusfunchigh = 0
brdev = 0xc266bd00
cardattached = 0
curr_bus_number = 2
bus = 5
slot = 0
func = -1034760040
#9  0xc018acd1 in cbb_insert (sc=0xc25b8400) at card_if.h:66
sockevent = 0
sockstate = 3260490112
#10 0xc018a9f4 in cbb_event_thread (arg=0xc25b8400)
at /usr/src/sys/dev/pccbb/pccbb.c:954
sc = (struct cbb_softc *) 0xc2572180
err = 0
#11 0xc022a151 in fork_exit (callout=0xc018a950 cbb_event_thread, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:794
td = (struct thread *) 0x0
p = (struct proc *) 0xc0ed23c8
(kgdb) quit
[EMAIL PROTECTED] crash]#

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Failed to make buildkernel with device ath

2003-07-30 Thread Lukas Ertl
On Wed, 30 Jul 2003, David Lodeiro wrote:

 I've tried to rebuild the kernel a couple of times now with device   ath  to
 add support for my 54g card. The system was cvsup to current yesterday (
 29/07/03) and make buildworld completed succesfully. However rebuilding the
 kernel fails on this :

 if_ath.o: In function `ath_attach':
 /usr/src/sys/i386/compile/DAVESSERVER/../../../dev/ath/if_ath.c:198: undefined
 reference to `ath_hal_attach'

Do you have

 device ath_hal
 device wlan

in your kernel config?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: fixed another leak in USB code

2003-07-29 Thread Lukas Ertl
On Mon, 28 Jul 2003, John-Mark Gurney wrote:

 Ok, those of you coming with panics due to kmem exhaustion w/ USB, I
 have fixed another leak.  For some reason I assumed that big blocks
 were being deallocated upon free, not being put back on the freelist.
 (Have I mentioned how much it sucks that the USB code it self has five
 different allocators?)

 As mentioned in the commit message, I did some testing, and a simple
 bulk transfer over aue did not increase the devbuf memory usage, while
 before this patch, I got it quickly over 20megs and growing.

 Sorry for the breakage.

Thanks!

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Highly loaded machine getting slower and slower

2003-07-29 Thread Lukas Ertl
On Mon, 28 Jul 2003, Poul-Henning Kamp wrote:

 In message [EMAIL PROTECTED], Lukas Ertl writes:
 Hi there,
 
 I'm having again problems with a highly loaded 5.1-current machine.  The
 box is a 2.4GHz Dual Xeon (HTT enabled) with 1GB RAM and acts as a news
 server/feeder running diablo.  It's pumping out 120+Mbit/sec over Gigabit
 without a glitch, but after some time, it's getting slower and slower,
 until it seems to completely freeze, but it's still alive, just _very_
 unresponsive and in fact has to be rebooted.

 Run a shell script in cron every 5 minutes where you record
   date
   sysctl kern.malloc
   sysctl vm.zone
   swapinfo
   ps -axlw

 and look out for anything which just gobbles up more and more
 memory.

Unfortunately, this didn't show anything significant.  But I've played
around a little and built a kernel without WITNESS and friends, but with
options ADAPTIVE_MUTEXES.  Now the box is up for almost five hours and
is still running, which really surprised us. :-)  Throughput is ok, but
the limiting factor currently seems to be disk I/O.  It's a pity that
ciss(4) isn't more performant right now.  Anyway, we hope the box stays up
and we'll keep monitoring that.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: device driver memory leak in 5.1-20030726?

2003-07-28 Thread Lukas Ertl
On Sun, 27 Jul 2003, John-Mark Gurney wrote:

 Lukas Ertl wrote this message on Sun, Jul 27, 2003 at 16:43 +0200:
  I have different core dumps and backtraces available, but they don't seem
  to be of much use in this case. I really suspect the USB stuff to be
  leaking.

 Ok, if you truely think this is the case, recompile w/ USB_DEBUG, and
 after everything is setup, and you see devbuf steadily increasing, set
 the sysctl hw.usb.debug to 7.  Take about 10k or so of that, and send
 it to me.  That should let me know if we are leaking.

You can find lots of logging at
http://mailbox.univie.ac.at/~le/usb.debug.log.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: broken world

2003-07-28 Thread Lukas Ertl
On Mon, 28 Jul 2003, Jan Willem Knopper wrote:

 /usr/src/contrib/isc-dhcp/common/dispatch.c:47: error: syntax error
 before string constant
 /usr/src/contrib/isc-dhcp/common/dispatch.c:44:1: unterminated #ifndef
 *** Error code 1

 This error also occurs in isc-dhcp/includes/dhcpd.h:45 an possibly in
 more files.

 The source looks like:

 #ifndef lint
 $FreeBSD: src/contrib/isc-dhcp/includes/dhcpd.h,v 1.2 2003/07/28 08:30:11 mbr Exp 
 $\n;
 #endif /* not lint */

This was fixed in rev. 1.3 of src/contrib/isc-dhcp/common/dispatch.c.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Highly loaded machine getting slower and slower

2003-07-28 Thread Lukas Ertl
Hi there,

I'm having again problems with a highly loaded 5.1-current machine.  The
box is a 2.4GHz Dual Xeon (HTT enabled) with 1GB RAM and acts as a news
server/feeder running diablo.  It's pumping out 120+Mbit/sec over Gigabit
without a glitch, but after some time, it's getting slower and slower,
until it seems to completely freeze, but it's still alive, just _very_
unresponsive and in fact has to be rebooted.

A kernel without WITNESS checks survives a few hours, a kernel with
WITNESS and friends stays up longer, but in fact after one, two weeks it's
the same picture.

If the machine seems to be stuck again and you break into the debugger,
you always get something like this:

db where
_mtx_lock_sleep(c03fa6f0,0,0,0,) at _mtx_lock_sleep+0x1e6
msleep(c21be0ec,c03fa6f0,44,c03ad35b,0) at msleep+0x888
acquire(e3a81a38,100,600,11000,c6f23d10) at acquire+0xbe
lockmgr(c21be0ec,2,0,c6f23d10,11000) at lockmgr+0x3f7
_vm_map_lock(c21be0b0,0,0,e3a81a7c,e3a81a84) at _vm_map_lock+0x5d
kmem_alloc_wait(c21be0b0,11000,c6f2b4b0,c1618378,120) at
kmem_alloc_wait+0x38
kern_execve(c6f23d10,bfbff410,bfbff2fc,bfbffd60,0) at kern_execve+0x219
execve(c6f23d10,e3a81d10,c,c022c1e6,3) at execve+0x30
syscall(2f,2f,2f,bfbff490,bfbff2fc) at syscall+0x2b0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (59, FreeBSD ELF32, execve), eip = 0x481132df, esp =
0xbfbff2ec, ebp = 0  378 ---

The machine is running about 250+ concurrent diablo/dnewslink processes.

Any hints or ideas?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: device driver memory leak in 5.1-20030726?

2003-07-27 Thread Lukas Ertl
On Sun, 27 Jul 2003, Mark Blackman wrote:

 Perhaps it's a USB bug. There seems to be some correspondence between
 the use of the USB Speedtouch ADSL modem and the out-of-control
 devbuf allocations.

I'm too seeing these annoying kmem_malloc panics on recent -current
kernels. The laptop I'm using is way off of being overloaded at all, the
only thing I do is going online using a Bluetooth USB dongle. As soon as I
generate some network traffic, devbuf allocations go up, until at some
point the machine panics randomly in kmem_malloc.

I have different core dumps and backtraces available, but they don't seem
to be of much use in this case. I really suspect the USB stuff to be
leaking.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: device driver memory leak in 5.1-20030726?

2003-07-27 Thread Lukas Ertl
On Sun, 27 Jul 2003, John-Mark Gurney wrote:

 Lukas Ertl wrote this message on Sun, Jul 27, 2003 at 16:43 +0200:
 
  I'm too seeing these annoying kmem_malloc panics on recent -current
  kernels. The laptop I'm using is way off of being overloaded at all, the
  only thing I do is going online using a Bluetooth USB dongle. As soon as I
  generate some network traffic, devbuf allocations go up, until at some
  point the machine panics randomly in kmem_malloc.

 I must note that the USB changes only allocates memory in the M_USB
 area which is described by:
 usb.c:MALLOC_DEFINE(M_USB, USB, USB);

 So, that means it wouldn't be in the devbuf area.  (This is the one of
 the points of malloc areas is to help track down stray allocations and
 memory leaks).

Then I have no explanation.  I'm running the box with a WiFi card,
generating lots of network traffic, and the box is running fine, no
panics, and low devbuf allocation.  I'm running the box with the USB
Bluetooth dongle, generating much less traffic (it's just a 9.6kbit GSM
link), and the box panics within half an hour in kmem_malloc, with devbuf
allocation up to 74MB.  It must be either in the Bluetooth code or in the
USB code.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ufs2 snapshots in 5.1 still broken

2003-07-19 Thread Lukas Ertl
On Sat, 19 Jul 2003, [iso-8859-2] Branko F. Gra?nar wrote:

 This only accours if there is alot (several 100 thousand) of small files
 on a filesystem.

 During snapshot creation all userland I/O hangs until snapshot is made.
 Machine doesn't respond even on ping!. After snapshot is created,
 everything works okay. If you want to remove that snapshot file the same
 scenario is repeated. Ideas, suggestions?

I'm not use what you mean. The suspension of I/O during creation of a
snapshot is the intended behaviour, but it doesn't take long. For example,
/usr here has about 185000 files:

# time mksnap_ffs /usr /usr/snapshot

real0m3.059s
user0m0.001s
sys 0m0.143s

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX-Systemadministrator   Tel.:  (+43 1) 4277-14073
Zentraler Informatikdienst (ZID)   Fax.:  (+43 1) 4277-9140
der Universität Wien   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


fix print/gv (was: Re: Fixing gcc 3.3 compile failures)

2003-07-18 Thread Lukas Ertl
On Thu, 17 Jul 2003, Kris Kennaway wrote:

 Most of the new compile failures are caused by 3 or 4 types of failure
 mode (all of which have to do with stricter standards compliance in
 the new compiler suite).  I haven't yet looked at how to fix most of
 them: if you figure out a patch for a class of failures, please post
 it in response to this email so we can all see how to do it.

http://bento.freebsd.org/errorlogs/i386-5-latest/gv-3.5.8_3.log

In file included from Aaa.c:49:
Aaa_intern.h:44:27: pasting / and Xlib does not give a valid
preprocessing token
Aaa_intern.h:44:27: pasting h and  does not give a valid
preprocessing token
Aaa_intern.h:45:32: pasting / and Xresource does not give a valid
preprocessing token
Aaa_intern.h:45:32: pasting h and  does not give a valid
preprocessing token

etc. etc.

Put this patch as patch-source::paths.h into ports/print/gv/files:

---8---
--- source/paths.h.orig Sun Apr  6 00:00:00 1997
+++ source/paths.h  Fri Jul 18 19:18:09 2003
@@ -34,9 +34,9 @@
 #   define INC_XMU(aaa) XMU_DIRECTORY/aaa
 #   define INC_XAW(aaa) XAW_DIRECTORY/aaa
 #else
-#   define INC_X11(aaa) X11/##aaa##
-#   define INC_XMU(aaa) X11/Xmu/##aaa##
-#   define INC_XAW(aaa) X11/Xaw3d/##aaa##
+#   define INC_X11(aaa) X11/aaa
+#   define INC_XMU(aaa) X11/Xmu/aaa
+#   define INC_XAW(aaa) X11/Xaw3d/aaa
 #endif

 #endif /* _PATHS_H_ */
---8---

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX-Systemadministrator   Tel.:  (+43 1) 4277-14073
Zentraler Informatikdienst (ZID)   Fax.:  (+43 1) 4277-9140
der Universität Wien   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: escalation stage 2 [was:RE: Big and ugly bug in 5.1-release]

2003-07-16 Thread Lukas Ertl
On Wed, 16 Jul 2003, Harald Schmalzbauer wrote:

 Now after resetting the machine which was hung by sysinstall it claims
 that ad4 (one of two mirrored 30GB 2.5 disks was absent (see dmesg below)
 Now the controller warns me that one drive is bad (which in fact is
 definatley not) and allows me to select continue boot

Did you try to replace that defective drive?

 That's what I do and after kernel probing the machine reboots with the
 folowing error (well, this takes some time to typewrite it from my monchrome
 screen):

 Fatal trap 12: page fault while in kernel mode
 fault virtual address = 0x10
 fault code=   supervisor read, page not present
 instruction pinter=   0x8:0xc014a0a6
 stack pointer=0x10:0xcce65bd8
 frame pointer=0x10:0xcce65c58
 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   = 4(g_down)
 trap number   = 12
 panic: page fault

 Then it reboots!

Can you get a coredump and a backtrace? That would be very helpful in
debugging.

 Now please give me a hint what to do. This is my brand new fileserver which
 collected all improtant data from the last decade and since it's brand new I
 didn't manage any backup.

Funny, there's always an excuse why there are no backups.

 When testing the hardware (unplugging one drive while the machine was
 running) I had the same error but I thought that would never happen under
 normal circumstances.

Well, if you did run tests and saw the errors, why did you think it
wouldn't happen under normal circumstances?

IMHO it would be better if you start over with a clean machine and two new
disks. Sounds very much like you damaged the drive.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX-Systemadministrator   Tel.:  (+43 1) 4277-14073
Zentraler Informatikdienst (ZID)   Fax.:  (+43 1) 4277-9140
der Universität Wien   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Experiences with ath(4)

2003-07-05 Thread Lukas Ertl
Hi there,

I just bought a Netgear WAG511 card and a Netgear WG602 Accesspoint. I
run the card in 11g mode under current, and I'm having some problems:

*) Powersavemode seems to be not supported at all (and thus it eats the
battery like a make world):

# ifconfig ath0 powersave on
ifconfig: SIOCS80211: Invalid argument


*) Shared Key Authentication seems to be not supported either:

# ifconfig ath0 authmode shared
ifconfig: SIOCS80211: Invalid argument


*) If I turn on the debug.ieee80211 sysctl, I see the following messages
in 30sec- to 2min-intervals:

ieee80211_new_state: RUN - AUTH
ieee80211_new_state: AUTH - AUTH
ieee80211_new_state: AUTH - ASSOC
ieee80211_new_state: ASSOC - RUN

   (I'm not sure if this is normal behaviour.)


*) I'm seeing a lot of input errors on the interface:

# netstat -i -I ath0
NameMtu Network   Address  Ipkts IerrsOpkts Oerrs
Coll
ath0   1500 Link#3  00:09:5b:41:8d:ac 2054 67646 205842
0


*) Finally, there seems to be a problem with interaction between the AP
and my ADSL router (I'm not sure if this is a FreeBSD problem, I need to
test with WinXP too). My LAN looks something like this:

   WLAN Client )))  ((( AP --- Switch --- ADSL router
 |
 |
 other hosts in LAN

The ADSL router (a Speedtouch 510) does NAT. Everything seems to work
fine, but after some time, all connections from the WLAN client to the
outside world have died. I can connect to the other hosts in the LAN just
fine, though, and there are no further messages in the log files.
The quickest way to make it work again, is pulling the card out and plug
it back it. Any ideas?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX-Systemadministrator   Tel.:  (+43 1) 4277-14073
Zentraler Informatikdienst (ZID)   Fax.:  (+43 1) 4277-9140
der Universität Wien   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Experiences with ath(4)

2003-07-05 Thread Lukas Ertl
On Sat, 5 Jul 2003, Lukas Ertl wrote:

 *) Finally, there seems to be a problem with interaction between the AP
 and my ADSL router (I'm not sure if this is a FreeBSD problem, I need to
 test with WinXP too). My LAN looks something like this:

WLAN Client )))  ((( AP --- Switch --- ADSL router
  |
  |
  other hosts in LAN

 The ADSL router (a Speedtouch 510) does NAT. Everything seems to work
 fine, but after some time, all connections from the WLAN client to the
 outside world have died. I can connect to the other hosts in the LAN just
 fine, though, and there are no further messages in the log files.
 The quickest way to make it work again, is pulling the card out and plug
 it back it. Any ideas?

Ok, I've investigated this further. The strange thing is: whenever the
connections to the outside drop, I can ping and connect to any host in my
LAN (10.0.0.0/24), but I _cannot_ ping 10.0.0.138 from the WLAN client,
which is the inside interface of the ADSL router and thus the default
route. I can't explain why. ifconfig ath0 down  ifconfig ath0 up
solves this lock-up. Could this be a driver bug?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX-Systemadministrator   Tel.:  (+43 1) 4277-14073
Zentraler Informatikdienst (ZID)   Fax.:  (+43 1) 4277-9140
der Universität Wien   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Experiences with ath(4)

2003-07-05 Thread Lukas Ertl
On Sat, 5 Jul 2003, Robert Watson wrote:

 On Sat, 5 Jul 2003, Lukas Ertl wrote:

  Ok, I've investigated this further. The strange thing is: whenever the
  connections to the outside drop, I can ping and connect to any host in
  my LAN (10.0.0.0/24), but I _cannot_ ping 10.0.0.138 from the WLAN
  client, which is the inside interface of the ADSL router and thus the
  default route. I can't explain why. ifconfig ath0 down  ifconfig ath0
  up  solves this lock-up. Could this be a driver bug?

 Just to check: you're not using multiple NATs in this configuration,
 right?

No, the access point has no NAT functionality.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX-Systemadministrator   Tel.:  (+43 1) 4277-14073
Zentraler Informatikdienst (ZID)   Fax.:  (+43 1) 4277-9140
der Universität Wien   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Experiences with ath(4)

2003-07-05 Thread Lukas Ertl
On Sat, 6 Jul 2003, Andrew Thompson wrote:

 On Sun, 2003-07-06 at 05:30, Lukas Ertl wrote:
 
  Ok, I've investigated this further. The strange thing is: whenever the
  connections to the outside drop, I can ping and connect to any host in my
  LAN (10.0.0.0/24), but I _cannot_ ping 10.0.0.138 from the WLAN client,
  which is the inside interface of the ADSL router and thus the default
  route. I can't explain why. ifconfig ath0 down  ifconfig ath0 up
  solves this lock-up. Could this be a driver bug?

 You could look at 'arp -a' and 'route get 10.0.0.138' to make sure its
 sending to the right mac address and out the right interface.

Yes, I've already done that. arp -an shows a correct arp table, and
route get 10.0.0.138 hangs until the connection is up again, but I guess
the route is ok.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX-Systemadministrator   Tel.:  (+43 1) 4277-14073
Zentraler Informatikdienst (ZID)   Fax.:  (+43 1) 4277-9140
der Universität Wien   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Experiences with ath(4)

2003-07-05 Thread Lukas Ertl
On Sat, 5 Jul 2003, Lukas Ertl wrote:

 Ok, I've investigated this further. The strange thing is: whenever the
 connections to the outside drop, I can ping and connect to any host in my
 LAN (10.0.0.0/24), but I _cannot_ ping 10.0.0.138 from the WLAN client,
 which is the inside interface of the ADSL router and thus the default
 route. I can't explain why. ifconfig ath0 down  ifconfig ath0 up
 solves this lock-up. Could this be a driver bug?

Another update:

Jul  5 22:38:39 korben kernel: ath0: device timeout
Jul  5 22:38:40 korben kernel: ath_hal_wait: timeout on reg 0x8:
0x  0x0004 != 0x
Jul  5 22:38:40 korben kernel: ieee80211_new_state: RUN - INIT
Jul  5 22:38:40 korben kernel: ath0: unable to reset hardware; hal status 3
Jul  5 22:39:02 korben kernel: ath0: unable to reset hardware; hal status 3

Then the card is dead. According to the manpage, this should not happen
:-)

If I pull it out and plug it back in, I get:

Jul  5 22:39:46 korben kernel: ath0: detached
Jul  5 22:39:57 korben kernel: ath0: Atheros 5212 mem
0x2000-0x2000 irq 11 at device 0.0 on cardbus1
Jul  5 22:40:54 korben kernel: ath0: failed to allocate descriptors: 12
Jul  5 22:40:54 korben kernel: device_probe_and_attach: ath0 attach
returned 12
Jul  5 22:40:54 korben kernel: cbb1: CardBus card activation failed

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX-Systemadministrator   Tel.:  (+43 1) 4277-14073
Zentraler Informatikdienst (ZID)   Fax.:  (+43 1) 4277-9140
der Universität Wien   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


make buildkernel currently broken in sys/pci/agp_intel.c

2003-05-27 Thread Lukas Ertl
cc -c -O -pipe -march=athlon -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/src/sys -I/usr/src/sys/dev
-I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL
-include opt_global.h -fno-common  -mno-align-long-strings
-mpreferred-stack-boundary=2 -ffreestanding -Werror  /usr/src/sys/pci/agp_intel.c
/usr/src/sys/pci/agp_intel.c: In function `agp_intel_attach':
/usr/src/sys/pci/agp_intel.c:173: `value' undeclared (first use in this
function)
/usr/src/sys/pci/agp_intel.c:173: (Each undeclared identifier is reported
only once
/usr/src/sys/pci/agp_intel.c:173: for each function it appears in.)
*** Error code 1

This is probably because of rev. 1.13, which jhb@ committed just about an
hour ago.

Fix:

---8---
Index: sys/pci/agp_intel.c
===
RCS file: /u/cvs/cvs/src/sys/pci/agp_intel.c,v
retrieving revision 1.13
diff -u -r1.13 agp_intel.c
--- sys/pci/agp_intel.c 27 May 2003 18:23:56 -  1.13
+++ sys/pci/agp_intel.c 27 May 2003 19:28:38 -
@@ -131,6 +131,7 @@
struct agp_gatt *gatt;
u_int32_t type = pci_get_devid(dev);
int error;
+   u_long value;

error = agp_generic_attach(dev);
if (error)
---8---

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX-Systemadministrator   Tel.:  (+43 1) 4277-14073
Zentraler Informatikdienst (ZID)   Fax.:  (+43 1) 4277-9140
der Universität Wien   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 5.0 and Thinkpad T20: ACPI related panics

2003-01-22 Thread Lukas Ertl
Hi -current,

just FYI regarding my suspend/resume problem on the T20 (seems like other
people have the same problem):

 On Wed, 22 Jan 2003, Lukas Ertl wrote:

  I think I've found the culprit: it's the sound device. If I remove device
  pcm from the kernel, I can suspend/resume after switching to a different
  vty (suspend in X still deadlocks, though).

 Ok guys,

 I now have a partial solution for this problem. Please take a look at
 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/sound/pci/csa.c.

 As you can see, there was a code change in rev. 1.24 that was MFC'd later,
 but the merged code was removed from the stable tree because it caused
 panics. That's exactly what has hit me. I removed the few lines from
 csa.c, and now I can happily suspend/resume, but only if I

 1) switch to a non-X vty (easy with the vidcontrol/ampd.conf hack)
 2) suspend by either pushing the suspend button or closing the lid.

 Using zzz from an xterm or using wmapm to suspend still locks the box
 up, I don't know why.

 So I ask if it is possible to revert csa.c to rev. 1.23?

 best regards,
 le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX-Systemadministrator   Tel.:  (+43 1) 4277-14073
Zentraler Informatikdienst (ZID)   Fax.:  (+43 1) 4277-9140
der Universität Wien   http://mailbox.univie.ac.at/~le/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



suspend/resume panic on Thinkpad T20

2003-01-21 Thread Lukas Ertl
Hi -current,

I already posted my problem to -mobile and got some useful tips there, but
I still need some advice from you, and I hope someone can take a look at
my problem.

I upgraded my laptop from 4.7 to 5.0 via make world. The upgrade went
quite smooth, but then I recognized that suspend/resume doesn't work at
all when ACPI is enabled (please see my thread at -mobile for this).

So I disabled ACPI and put APM back in, since APM worked very well under
4.7. Now I can suspend and resume on the console, but if I suspend when
I'm in X, the machine gets stuck in a deadlock (so I have to power cycle).

Someone on -mobile suggested to switch to a different vty before
suspending. Ok, I did, and suspend works, but when I resume I hit a kernel
panic. The strange thing is that it doesn't dump core onto swap although I
configured dumpdev and everything (and I usually get a nice core dump if
the machine panics).

So the only information I have so far is this:

pcm0: unregister: mixer busy
csa: card is Thinkpad 600X/A20/T20
panic: resource_list_alloc: resource entry is busy

syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
Uptime: 4m5s
Dumping 255 MB  it says so, but it doesn't do it
ata0: resetting devices ..

Fatal trap 12: page fault while in kernel mode
fault virtual address= 0x24
fault code   = supervisor read, page not present
instruction pointer  = 0x8:0xc025c166
stack pointer= 0x10:0xcd26ec88
frame pointer= 0x10:0xcd26ec88
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  = 20 (irq11: cbb0 cbb1+++)
trap number  = 12
panic: page fault
Uptime: 4m5s
pfs_vncache_unload(): 1 entries remaining
Automatic reboot in 15 seconds - press a key on the console to abort
-- Press a key on the console to reboot,
-- or switch off the system now.
Rebooting...

Since the current process seems to have something to do with cardbus
(cbb0, cbb1), I tried to remove it from the kernel. I still got the same
panic, but with fxp0, uhci0+ as process number 20 on irq 11.

I'm currently building with DDB, so maybe I can get a core dump.

Any tips or suggestions are appreciated.

Please keep me CC'ed.

thanks,
le

-- 
Lukas Ertl  eMail: [EMAIL PROTECTED]
UNIX-SystemadministratorTel.:  (+43 1) 4277-14073
Zentraler Informatikdienst (ZID)Fax.:  (+43 1) 4277-9140
der Universität Wienhttp://mailbox.univie.ac.at/~le/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message