Re: USB memory stick

2006-09-17 Thread FloW

Gergo Szakal wrote:

Matthew Dillon wrote:


I don't know about OpenBSD but
I assume they have something similar.  You should be able to burn and
boot the appropriate CD and test your USB without actually installing
anything or modifying your hard drive in any way.


Well, OpenBSD do not even distribute CD images. I recommend using 
OliveBSD [1] which is a live CD based upon OpenBSD.


Hope I could help avoiding a bit of headache. :-)

[1] http://g.paderni.free.fr/olivebsd/


Thanks for the support. I have FreeBSD installed and ehci works, not as 
stable and fast as one would wish, but sufficient for my work.


I will have a look into the sources one of the next days. I should have 
the theoretical background but I'm neither experienced with system code 
nor with C. So you're likely to hear some more questions from my side ;-)


Regards

FloW




login-shell

2006-09-17 Thread Christian Hennig
Moin,

it's a simple question: How it ist possible to set the login shell. Or is a 
normal user allowed to edit his passwd row?

THx 4 help

CU

Christian


Re: login-shell

2006-09-17 Thread Joerg Sonnenberger
On Sun, Sep 17, 2006 at 09:44:12PM +0200, Christian Hennig wrote:
 it's a simple question: How it ist possible to set the login shell. Or
 is a normal user allowed to edit his passwd row?

chsh.

Joerg


Re: login-shell

2006-09-17 Thread Gergo Szakal

Christian Hennig wrote:

Moin,

it's a simple question: How it ist possible to set the login shell. Or is a 
normal user allowed to edit his passwd row?

THx 4 help


chsh

If you are unfamiliar with vi, use this way:

 env EDITOR=ee chsh

and it will be opened in ee, of course you can put the command for your 
favourite editor there.


Alternatively, this is the fast way:

 chsh -s /bin/sh

Hope this helps.


Re: login-shell

2006-09-17 Thread Victor Balada Diaz
On Sun, Sep 17, 2006 at 09:44:12PM +0200, Christian Hennig wrote:
 Moin,
 
 it's a simple question: How it ist possible to set the login shell.
 Or is a normal user allowed to edit his passwd row?

Every user can change his login and other information with chsh(1).
The shell is changed with -s option.

You can find more info about modifying user account settings here:
http://leaf.dragonflybsd.org/~justin/handbook/users-modifying.html

-- 
La prueba más fehaciente de que existe vida inteligente en otros
planetas, es que no han intentado contactar con nosotros. 


Re: Hints on kernel config for a dula pII/450 system anyone?

2006-09-17 Thread Gergo Szakal
Oh, forgot: I am using another DF box with bridging (an xl and an rl 
NIC) and it has been running for like 2 weeks with no problem.


Re: Hints on kernel config for a dula pII/450 system anyone?

2006-09-17 Thread Gergo Szakal

Matthew Dillon wrote:


I'm not sure why the mbuf is shared at that point,
but the assertion is definitely in the wrong part of the code path.

I am going to move the assertion.   Could you try that patch and
tell me if it works for compiled-in bridging?


No, it does not seem to help. I am telling more:
I have 2 cards, sk0 (public IP) and sk1 (IP-less) - bridged. I use pf, 
all the filtering is done on sk1.
When only sk0 is plugged in, the crash comes after a few minutes. When 
only sk1 is plugged in, the crash comes right after logging in.

Attaching the dmesg from the last crash.
Copyright (c) 2003, 2004, 2005, 2006 The DragonFly Project.
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
DragonFly 1.6.1-RELEASE #5: Sun Sep 17 00:26:38 CEST 2006
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP
TSC clock: 446442108 Hz, i8254 clock: 1193240 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (446.42-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x652  Stepping = 2
  
Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real memory  = 536870912 (524288K bytes)
avail memory = 509067264 (497136K bytes)
Programming 32 pins in IOAPIC #0
DragonFly/MP: Multiprocessor motherboard
 cpu0 (BSP): apic id:  1, version: 0x00040011, at 0xfee0
 cpu1 (AP):  apic id:  0, version: 0x00040011, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x001f0011, at 0xfec0
Preloaded elf kernel /kernel at 0xc073b000.
Pentium Pro MTRR support enabled
md0: Malloc disk
pcibios: BIOS version 2.10
Using $PIR table, 15 entries at 0xc00fded0
npx0: math processor on motherboard
npx0: INT 16 interface
compare 0
legacypci0 on motherboard
pcib0: Intel 82443GX host to PCI bridge on legacypci0
pci0: PCI bus on pcib0
agp0: Intel 82443GX host to PCI bridge mem 0xfa80-0xfaff at device 
0.0 on pci0
pcib1: Intel 82443GX (440 GX) PCI-PCI (AGP) bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci0: unknown card (vendor=0x110a, dev=0x0015) at 2.0
pcib2: DEC 21152 PCI-PCI bridge at device 3.0 on pci0
pci2: PCI bus on pcib2
pci2: Cirrus Logic GD5446 SVGA controller at 0.0
sym0: 895 port 0x2000-0x20ff mem 0xfa209000-0xfa209fff,0xfa20a000-0xfa20a0ff 
irq 17 at device 1.0 on pci2
sym0: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking
sym0: open drain IRQ line driver, using on-chip SRAM
sym0: using LOAD/STORE-based firmware.
skc0: Marvell Gigabit Ethernet port 0x2400-0x24ff mem 0xfa20-0xfa203fff 
irq 18 at device 8.0 on pci2
skc0: bad VPD resource id: expected 82 got 55
skc0: (null)
sk0: Marvell Semiconductor, Inc. Yukon on skc0
miibus0: MII bus on sk0
e1000phy0: Marvell Semiconductor 88E1000* gigabit PHY on miibus0
e1000phy0:  1000baseTX-FDX, 100baseTX-FDX, 100baseTX, 10baseTX-FDX, 10baseTX, 
auto
sk0: MAC address: 00:30:4f:37:9a:91
skc1: Marvell Gigabit Ethernet port 0x2800-0x28ff mem 0xfa204000-0xfa207fff 
irq 19 at device 10.0 on pci2
skc1: bad VPD resource id: expected 82 got 55
skc1: (null)
sk1: Marvell Semiconductor, Inc. Yukon on skc1
miibus1: MII bus on sk1
e1000phy1: Marvell Semiconductor 88E1000* gigabit PHY on miibus1
e1000phy1:  1000baseTX-FDX, 100baseTX-FDX, 100baseTX, 10baseTX-FDX, 10baseTX, 
auto
sk1: MAC address: 00:30:4f:36:17:dc
pci0: unknown card (vendor=0x110a, dev=0x001d) at 4.0 irq 2
isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX4 ATA33 controller port 0x1800-0x180f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0x1400-0x141f irq 16 at 
device 7.2 on pci0
usb0: Intel 82371AB/EB (PIIX4) USB controller 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
pci0: Intel 82371AB Power management controller at 7.3
orm0: Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xc87ff on isa0
fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
ppbus0: Parallel port bus on ppc0
plip0: PLIP network interface on ppbus0
lpt0: Printer on ppbus0
lpt0: Interrupt-driven port
ppi0: Parallel I/O on ppbus0
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via IOAPIC #0 intpin 2
SMP: AP CPU #1 Launched!
ad0: 8223MB ST38410A [16708/16/63] at ata0-master PIO4
Waiting 5 seconds for SCSI 

Re: Hints on kernel config for a dula pII/450 system anyone?

2006-09-17 Thread Gergo Szakal

Bill Hacker wrote:
Might sound harsh, but you'd be time and money (electric bill alone) 
ahead to scrap that PII/450 antique.


You are absolutely right, if this were an option, I'd do it, but this is 
not my machine, a friend asked me to set this up as a filtering bridge 
for him, and I wanted to install an OS that is a) capable of powerful 
packet filtering, b) has good SMP support (otherwise I'd have installed 
OpenBSD and forget, but now that's harsh :-P).
I'll convince the guy to get another machine, but TBH I'd like to try 
out DF in a production environment on a multiprocessor machine.


Re: Hints on kernel config for a dula pII/450 system anyone?

2006-09-17 Thread Gergo Szakal

Bill Hacker wrote:


*BSD folk, unlike Penguins, are generally agnostic.

 Use whatever is the best 'fit for the purpose'.



Using only 1 processor is not enough. An AMD K62/450 is not enough for 
the amount of traffic going through. theoretically, DF *should* run on 
this flawlessly, that's why I even bothered reporting (and mde thers 
bother too :-P).


Therein lies justification for (perhaps), a mere Intel Dual-Core 3 GHz 
at 'remaindered' just-obsoleted silicon prices. Cheaper than latest' 
Intel and AMD-64.


I wanted to avoid polluting the group with personal stuff, but machines 
of this category are not options now. In the future I'll summarize all 
this crap, translate to English and post somewhere to terrify people. :-)))


Re: Hints on kernel config for a dula pII/450 system anyone?

2006-09-17 Thread Bill Hacker

Gergo Szakal wrote:


Bill Hacker wrote:



*BSD folk, unlike Penguins, are generally agnostic.

 Use whatever is the best 'fit for the purpose'.



Using only 1 processor is not enough. An AMD K62/450 is not enough for 
the amount of traffic going through. theoretically, DF *should* run on 
this flawlessly, that's why I even bothered reporting (and mde thers 
bother too :-P).


Therein lies justification for (perhaps), a mere Intel Dual-Core 3 GHz 
at 'remaindered' just-obsoleted silicon prices. Cheaper than latest' 
Intel and AMD-64.



I wanted to avoid polluting the group with personal stuff, but machines 
of this category are not options now. In the future I'll summarize all 
this crap, translate to English and post somewhere to terrify people. :-)))


We've all been (still are) there w/r the economics.

But when funds are needed elsewhere, and 'run what hardware you have' is 
mandatory, then DFLY would not be the best choice.


For that to change sooner, rather than someday-maybe, best to leave the 'scarce 
resource' DFLY dev team to concentrate on current, reasonably-mainstream hardware.


Hard enough to keep up with 5-week/month-old goods, let alone 5+ *years* old.

Bill